AWS re:Invent2013参加レポート #17 From One to Many: Evolving VPC Design

大人気のセッションでした。スピーカーはこちらの方です。

Robert Alexander - Solutions Architect , Amazon Web Services

セッションの目的は、1つのVPCから利用を始めて、複数のVPCへ、複数のリージョンへと構成が成長していくなかで、どのように設計や設定を行うべきか、例をたくさん用いて解説するというものです。

VPCを徐々に発展させる

まずは注意事項からです。今日話すことは実際にやってみてね〜と軽いノリでスタートしましたが、しゃべりはダンディーです。

1. AWS CloudFormationを知る

まずは、簡単にデプロイできるCloudFormationを使ってみましょう。

• データセンターのソースのコードのバージョンをコントロールします。
• 1発コマンドでインフラをデプロイします。
• どこでも数分でインフラを再現します。
• インフラと開発の職務内容の分離(Segregation of Duties)を行うことが出来ます。

2. IPの帯域を把握しておく

サブネットの切り方を間違えると直ぐに使えるIPが減ってしまいます。

• 将来的にリージョンが増えることを考えておく。
• 将来的に社内ネットワークと接続することを考えておく。
• サブネットの設計を考えておく。
• VPCは、/16から/28までしか設定できない。
• CIDRは一度作成すると変更できない。

起動時に動的なPublicIPアドレスを自動的に設定する機能

なにげに嬉しい機能です。AutoScalingするときに使えますね。EIPとは違い動的なPublicIPが付いてきます。

3. メインのルートテーブルは1つにしておく

シンプルが一番

Network ACLとSecurity Groupの比較

NACLsの特徴

• サブネットに1つみ設定する
• ステートレス
• Allow / Deny
• ルールは順番に適応される

それぞれの特徴

Network ACLの特徴

• サブネットに1つ設定
• ステートレス
• ブラックリスト形式
• ルールを順番に記述

Security Group

• ENIに5つまで設定
• ステートフル
• ホワイトリスト形式
• ルールは全体を評価
• 同じVPC内のセキュリティグループを参照できる

全体の共通としてセキュリティポリシー設定を行う場合にNACLの利用が考えられます。そのため、できるだけシンプルに記述するべきです。外向き通信のセキュリティポリシーを記述することがベストです。内向きのセキュリィポリシー設定をしてしまいますと、エフェメラルポートの設定などで間違った設定をしてしまいがちですから気をつけましょう。あとは、NACLの削除権限は限られた人に持たせてください。間違って削除してしまいますと全通信が通りませんw。笑えないですね。

4. IAM VPC管理グループを作成する

VPCを管理するコマンドに対してIAMポリシーを設定できるようになりました。全体への影響度が大きい削除系の操作については、限られたユーザーのみが行えるようにするべきですね。

5. NATのAMIって何をやっているか？

• IPフォワーディングを有効に設定
• iptablesでIP NATマスカレードを有効に設定
• Source/Destinationチェックを無効に設定

帯域を必要とするプロセスは、NATの後ろに必要か考えてみます。アプリケーションコンポーネントを必要な帯域で分けたい時、PublicとPrivateに分けます。多くの場合はPublicサブネットに置いて実行します。ゴールは全てのトラフィックがPrivateサブネットの外で実行されることです。Auto Scalingはインスタンス起動時に自動的に動的なPublicIPが付きますからPublicサブネットに置きましょう。それでも未だPrivateサブネットに残っている必要がある場合はNATを使って外部と通信をします。例えば、Privateサブネットに置いていあるインスタンスが、SQS,SNS,SWF,S3,DynamoDBなどのサービスに接続する必要がある場合にNATを利用します。

タグ付け

各種リソースへのタグ付けの戦略は初期に行っておくべきです。プロジェクトコード、コストセンター、環境、チーム、部門などのタグを付けます。タグはリソースが生成された後に付き、リソース毎にパーミッションを付けられます。AWS Billingもタグに対応しています。タグの編集権限については、IAMで制限をしましょう。

ロードバランサーをサブネット内に置く

ELBはサブネット内にあるEC2で、プライベートアドレスを使用します。サブネットを分けるということはコントロールも分かれます。アプリケーション層とロードバランサー層を明確に分けます。

上記の図を見ますと、IGW（インターネットゲートウェイ）とInternal ELBの間にPublicサブネットのProxyサーバー（Squid等）が配置されています。Proxyはセキュリティグループの設定で、ロードバランサーからの通信のみ許可しています。ProxyはS3のURLなど決められた通信のみ許可するようになっています。NACLsはHTTP/HTTPSの外向き通信のみを許可します。

Squidのサンプルコードを示しました。この他詳しいサンプルは以下のサイトで解説されています。

Using Squid Proxy Instances for Web Service Access in Amazon VPC: An Example

VPC内のDirectoryとName Service

VPCで自動的に発行されるEC2インスタンスのDNS名ですが役割が分かりづらいですよね。例えば、Active DirectoryとDNSをVPC内に置くことで分かりやすいドメイン名を付けられるようにします。

これが、以下のようになります。

これらの構成をゼロから構築するのは大変ですからCloudFormationなどを使って自動化しましょう。詳しくは以下のサイトを参考にしてください。

Deploy a Microsoft SharePoint 2010 Server Farm in the AWS Cloud in 6 Simple Steps

バックオフィスから使う

インターネットゲートウェイからではなく、VPNを使ってバックオフィスから接続する場合の構成です。

まとめ

VPC環境を徐々に発展させる設計について考え方のヒントになればと思っています。次は、複数のVPCを束ねてAWS Direct Connetと接続する例を紹介したいと思います。

参考資料

AWS re:Invent - ARC401 - From One to Many: Evolving VPC Design