Amazon EC2 Instance scheduled for retirement.

AWSのインスタンスリタイアお知らせが来た時の対処を参考にしてみた。

ルートデバイス: ebs
「ebs」の場合は、インスタンスの停止、そしてその後起動、でOKです。

のハズだったのだが、今後同様のお知らせが来た時に自動的に対応し、対応されたことを通知するためにAutoScaling Groupにアタッチすることを検討して実施してみたところ即時インスタンスの再起動が再作成された。。。

が、インスタンスの状態がテンプレートの状態に戻ってしまった。

おそらく設定が正しくなく?、インスタンスの削除→再作成になっていて、インスタンスが削除されたときにebsボリュームまで削除された可能性が高い。。。。

幸いアカウントの登録までしかしていなかったインスタンスだったので軽傷だったが、マネジメントコンソールでインスタンスに関係する設定変更をするときにはスナップショットを取るなど注意するようにしたい。

インターネットゲートウェイとNATゲートウェイの違い

AWSのVPC設定にはインターネットゲートウェイとNATゲートウェイがあるが、よくわからない。

パブリックIPを設定しているインスタンスは、インターネットゲートウェイだけ設定していればよいが、パブリックIPを設定していないインスタンスは、インターネットゲートウェイになぜか到達できない。

例えば、
VPC A(172.31.0.0/16)に対して、subnet X(172.31.0.0/20), subnet Y(172.31.16.0/20)を設定したうえで、subet Xに所属するインスタンス 1は、パブリックIPを保持しており、同じsubnet Xに所属するインスタンス 2とsubnet Yに所属するインスタンス 3は、パブリックIPを保持していないとする。

この時、VPC Aに対して、インターネットゲートウェイだけが設定されている場合、
インスタンス 1はインターネット(VPCの外)へ接続できるが、インスタンス 2, インスタンス 3はインターネット(VPCの外)へ接続できない。
次に、subnet Z(172.31.32.0/20)を作成し、subet Zに所属するインスタンス 4を作成し、subnet Y, subnet Zに対して、作成したNATゲートウェイをデフォルトゲートウェイに設定したルートテーブルを紐づけるとインターネット(VPCの外)へ接続できるようになる。

ここで、subet XについてもNATゲートウェイと紐づける(デフォルトゲートウェイをインターネットゲートウェイからNATゲートウェイに変更する)とそもそもインスタンス1に接続できなくなる。(パブリックIPを持っているにも関わらず接続できないということは、パブリックIPへのルートテーブルがなくなっているということになるのだろうか??)

理解に苦しむ点は次の通り
1.インターネットゲートウェイをデフォルトゲートウェイに設定しているにもかかわらず、パブリックIPがインターネットと接続できない点
(インスタンスで設定されているゲートウェイはサブネット内に設定されているホスト(ネットワークアドレスの最初のアドレス/例:上述のsubnet Xは172.31.0.1)になっていて、対象ホストとはICMPで接続できない。同一サブネットなのにもかかわらず接続できないということは、ICMP Echoが無効になっているだけなのだろうか? 次に外部(VPCの外のドメイン)にtracerouteしても名前解決はされるのに、到達できない)

2.インターネットゲートウェイの代わりにNATゲートウェイをデフォルトゲートウェイに入れ替えるとパブリックIPアドレスに接続できなくなる点
(パブリックIPアドレスへのルートテーブルがなくなってしまうということなのだろうか?)

NATゲートウェイは、サブネットをElasticIPに紐づける機能を持っており、
インターネットゲートウェイは、VPCとルートテーブル機能を使って紐づけることが出来る。
Egree Onlyインターネットゲートウェイというものもあり、ネットワーク設計を行う上で違いと仕組みを整理しておく必要がある。

Elastic IPの運用上の注意

Elastic IPは、固定のグローバルIPアドレスを意味する(Elastic IPを割り当てない場合には、インスタンスを再起動するたびにIPアドレスが変わる)が、インスタンスにアタッチされていないか、アタッチされたインスタンスが稼働中でない場合には、0.005USD/時間 課金されてしまう。
無料枠の中で(=課金されないように)試そうとすると、必ずインスタンスにアタッチした上で、該当インスタンスを停止させないようにしなければならない。
なお、インスタンスはオンデマンドインスタンスの場合、無料枠対象のt2.microを選択することとなるが、オハイオリージョンの場合で Amazon Linuxで0.0116USD/時間、Windows Serverで0.0162USD/時間課金されるので、無料枠を使い切った場合には、インスタンスにアタッチしない状態が一番安く済むことになる。

Amazon EC2 料金 オンデマンド料金より抜粋
Elastic IP アドレス
実行中のインスタンスに関連付けられた Elastic IP(EIP)アドレスを無料で 1 つ取得できます。追加の EIP をそのインスタンスに関連付ける場合は、追加の EIP 毎に時間当たり(プロラタベース)の料金が請求されます。追加の EIP は Amazon VPC でのみ利用可能です。

Elastic IP アドレスを効率的に使用するため、これらの IP アドレスが実行中のインスタンスに関連付けられていない場合や、停止しているインスタンスやアタッチされていないネットワークインターフェイスに関連付けられている場合は、時間毎に小額の料金をご請求します

AWS Workspaces

Workspacesは仮想デスクトップを簡単に構築できるサービス。
非力なマシンであっても、仮想デスクトップなので最新のコンピュータ環境を利用できる。
昔のシンクライアントのようなものである。
例えば有期雇用で短期間人を雇うようなケースにおいて、一時的にOfficeが利用できるマシンを必要とするような場合に有用である。

WorkSpacesを削除しても、ディレクトリは削除されない。
ディレクトリが残っているとWindowsのライセンスが課金されてしまう。
自分の場合には半月気づかず、14ドル課金されてしまった。

FortigateVM

FortigateVMは、Fortigate製品の仮想アプライアンスになっているのだが、ちょっと構成が分かりにくい。

技術仕様によれば、モデルによって性能差異が記述されており、製品機能一覧の4ページ目によれば、ハイパバイザーによって利用できる機能は制限されるが、原則的には、FortiOSの機能をすべて利用でき、期待しているスループットが出るかどうかは別として、割と何でもできる万能型のUTMとして使えるように見える。

ところが、下記のようにライセンス形態が構成されており、オプションになっているものがあり、本体(ベース)ライセンスでは、利用できる機能が制限されている。

  • 本体
  • アンチウィルス(オプション)
  • UTMバンドル(オプション)
  • Enterpriseバンドル(オプション)
  • NGFW(オプション)
  • Webフィルタリング(オプション)

本体ライセンスで使用できる範囲がよくわからないので、FortiVMを採用する場合には、よく気をつけた方がよさそうだ。Amazon EC2でも15日間お試しできる(ただし、仮想マシン費用は掛かり、無料枠の対象にはならない)ので、ちょっと調査をしてみようと思う。

参考)株式会社データコントロール社での販売価格表

AlexaDaysに参加してきました

JWAS-UG金沢のイベントとして、AlexaDaysに参加してきました。
zoomというテレビ会議システム(日本の代理店サイト?はこちら)で全国のJAWSUGの支部と韓国の合計18拠点?で接続していましたが日本語と韓国語の同時通訳とサンフランシスコからの英語セッションもあって、金沢にいても時差を気にしなければ全く問題ない会議が出来ることに衝撃的だった。。。
内容はtwitterで#alexadays で見ることができますよ。
音声がインターフェイスになるというのは人間同士の会話であれば当たり前だけど、コンピューターを通して会話できるということが未来のようですぐそこにまできているということがよくわかった。
ニュース記事
JAWS-UG15支部と韓国のAWSKRUGが「Alexa Days」を共同開催
YouTubeの映像
Echo Dotを音声コントロール(Amazon Alexa)-AV Watch
アマゾンエコーはあらたなる購買形式に成り得るか?使用感と将来性をレポート!
[English Sub] 話題のAmazon Echo 紹介!/ Introducing…

CloudFrontを利用して静的コンテンツを高速化する

このブログサイトをCloudFrontを使って高速化してみた。
早くなったかどうかはちょっとわからないが、Googleからのリクエスト速度は間違いなく上がっているので、検索順位向上には寄与している(と思いたい)。
CloudFrontはCDN(Content Delivery Network)のサービスだが、EC2やLamdaなどのAWSのサービス以外にも利用できる。
昔はCDNなんてakamaiぐらいしかなく、個人が使えるようなサービスではなかった。
CloudFrontを独自ドメインで利用するメリットは下記が挙げられる。
1.全世界からのアクセスが高速化できる。(CDNの導入目的と同じ)
例えば、当ブログサイトのドメインに割り当てられているアドレスd2p33equgohrri.cloudfront.netを正引きすると以下のように8つのアドレスが返される。
このアドレスは、リクエスト元の地域(リージョン)によって変わることになる。
>nslookup -q=A d2p33equgohrri.cloudfront.net
権限のない回答:
名前: d2p33equgohrri.cloudfront.net
Addresses: 54.230.111.20
54.230.111.187
54.230.111.227
54.230.111.55
54.230.111.251
54.230.111.57
54.230.111.220
54.230.111.238
2.Webサーバへのリクエストを減らすことが出来る=負荷を軽減できる。(CDNの導入目的と同じ)
3.(D)Dos攻撃にも耐えられる。(CDNの導入目的と同じ/但し、リクエスト数が増大するので、課金がかさむことになる)
4.CloudFrontをSSL化しておいて、CloudFront→Webサーバ 間をHTTP通信にすることにより、昨今のセキュリティ要求に対応しながら、SSL通信にかかる負荷を軽減できる。
5.SSL証明書が無料で利用できる(CloudFront独自のメリット/但し、IPベースにすると毎月600ドル課金されるので注意)
6.AWSの無料枠の対象なので、気軽に試せる(CloudFront独自のメリット)
7.HTTP/2に対応できる。(CloudFront独自のメリット?/リクエストが高速になる)
SSL証明書はLet’s Encryptを利用する方法もあるが、CloudFrontを利用すると証明書の期限が13ヵ月になっているうえ、更新が自動で行われる点がビジネス目的に耐えられる点で優れている。
CloudFrontを利用するにはWebの画面だけで完結できるが、日本語化されておらず少しハードルは高い。
ただ、WordPressサイトをCloudFrontで配信するの説明が非常に分かりやすい。
上記サイトでは、WordPressサイトの登録を変更していたが、
Origin Domain Name には、CDN用のエイリアスFQDN(例:cdn.blog.development-network.net)
Alternate Domain Names には、オリジナルのFQDN(例:blog.development-network.net)
を登録し、cdn.blog.development-network.netのCNAMEに登録後に表示されるDomain Name(例:d2p33equgohrri.cloudfront.net)をDNSに登録すればよい。
SSL証明書の発行手順は、認証がメールベースになっているので、独自ドメインのメールエイリアスを登録できるようになっている必要がある。
SSL証明書を発行しても、すぐに独自ドメイン用のSSL証明書に切り替わらず、証明書エラーが表示されるので、少し焦るがCloudFrontのStatusがDeployedになるまでは待ってみることをお勧めする(焦った)

AzureDNS

先日AWSのDNSサービスを利用したmydnsからroute53へ移行するを紹介したが、Windows AzureでもAzure DNSがあるようだ。
価格を見ると、AWSとほぼ変わらないか、少し高い感じがする。
ところで2/11からzaiteku.jpドメインをroute53へ移行した金額を下記に公開する。
現時点では、mydnsと2重化している(下記Whois情報参考)ので、4/6のクエリになっていると推測される。
請求金額
請求明細.jpg
参考)Whois情報
$ whois zaiteku.jp
[ JPRS database provides information on network administration. Its use is ]
[ restricted to network administration purposes. For further information, ]
[ use ‘whois -h whois.jprs.jp help’. To suppress Japanese output, add’/e’ ]
[ at the end of command, e.g. ‘whois -h whois.jprs.jp xxx/e’. ]
Domain Information: [ドメイン情報]
[Domain Name] ZAITEKU.JP
[登録者名] Development Network
[Registrant] Development Network
[Name Server] ns-1447.awsdns-52.org
[Name Server] ns-2016.awsdns-60.co.uk
[Name Server] ns-229.awsdns-28.com
[Name Server] ns-925.awsdns-51.net
[Name Server] ns0.mydns.jp
[Name Server] ns1.mydns.jp