インターネット及びオンプレミス環境との通信
ここまでVPC内の通信を見てきましたが、次に、EC2インスタンスがインターネットやオンプレミス環境へパケットを送る時は何が起こっているのか見てみましょう。
まず新しく「エッジ」というコンポーネントが出てきます。具体的には「インターネットゲートウェイ」（IGW）や「仮想プライベートゲートウェイ」（VGW）などがそれに相当します。
VPCのルートテーブルではインターネットやオンプレミス環境のネットワーク（CIDR）への経路がこれら「エッジ」へ向かうように設定します（IGWの設定とVGWの設定）。一方、前述のVPC内の経路はLocalルートとして設定されています。
エッジを経由する通信は、異なるサブネットとの通信と同じように、送信元ゲストOSがデフォルトゲートウェイへ送信したパケットをもとに、ServerがMapping Serviceで送信先IPアドレス（この場合、インターネット上のアドレスだったりオンプレミス環境のアドレスだったりになります）を検索すると「エッジ」のIPアドレスを取得できるので、VPC IDでカプセル化して当該エッジへ送ります。その際のパケットはこんな感じになります。
ここからは各エッジで処理が異なってきます。
インターネット経由の場合
エッジ（IGW）ではカプセル化されたパケットを取り出し、そのままIPパケットとして送信します。
ここで、一つ問題があります。それは見ての通り「送信元ゲスト OS IP」がプライベートIPアドレスのままだということです。このままでは当然パケットは戻ってこられません。そこで、送信元IPアドレスを1:1 NATし、グローバルIPアドレスに変換します。その際に使われるグローバルIPアドレスが、AWSで言うところの「パブリックIPアドレス」や「Elastic IPアドレス」です。
なお、ここで出てくるNATは、NATインスタンスやNATゲートウェイによるNATとは違い、特に設定しなくてもパブリックサブネットからインターネットへの通信が発生する際に、AWS側で必ず実施されるNATのことです。
1:1 NATされた後のパケットはこんな感じになります。
ところで唐突ですが、南アフリカに行くと「ケープペンギン」と呼ばれるペンギンがおり、別名「黒足ペンギン」（Blackfoot penguin）とも呼ばれているそうです。EC2ネットワークにおける「エッジ」はLinuxベースで開発されたものですが、（Linuxのマスコットがペンギンであることから）Blackfootという名前が付けられているそうです。また、BlackfootはAWSのシアトルオフィスの名前でもあります。
VPN経由の場合
エッジ（VGW）ではVPC IDでカプセル化された元のパケットを取り出し暗号化した上で、再度IPsecヘッダでカプセル化しカスタマーゲートウェイへ送信します。
ここで「VGW IP」は仮想プライベートゲートウェイのグローバルIPアドレス、「CGW IP」はカスタマーゲートウェイのグローバルIPアドレス、ESPはIPsecのEncapsulating Security Payloadを示します。よく見るとVPC IDでカプセル化されていたものが、代わりにIPsecヘッダ（ESP）でカプセル化されているだけともいえます。
この後、VGWからCGWへパケットが辿る経路はパケットが普通のインターネットを経由していく処理と同じと考えていただいて差し支えありません。またオンプレミスのホストからEC2インスタンスへのパケットは、この逆の過程をたどってEC2インスタンスまで到達します。
Direct Connect経由の場合
VPN経由の場合と似ていますが、エッジ（VGW）ではVPC IDでカプセル化された元のパケットを取り出した後、IEEE802.1QのVLANタグ（Direct Connectの仮想インターフェースを作成する時に指定する値を使います）でカプセル化した上で、顧客ルーター宛てに送信します。
なお、VPN経由の場合はインターネットを経由し送信されますが、Direct Connectの場合はAWS側ルータの1ホップ先につながっている（物理的に接続されている）顧客ルーターへVLANタグの付いたEthernetフレームとして送信されます。
「AWSのネットワーク」のまとめ
これで「AWSのネットワーク」のヒミツが明らかになりました。
全体を通して解説して分かることは、物理設計においても論理設計においても、設計の初めの段階からスケーラビリティを非常に重要な設計目標としていることです。
EC2ネットワークではMapping Serviceという概念を導入することで物理設計と論理設計の分離を実現し、スケーラブルな仮想ネットワークの構築を可能としました。一方、Mapping Serviceは非常に重要な機能であるため、キャッシュやその他の手法によりシステムとしての可用性を担保しています。
また、「サービス」の可用性を上げるために単純にデータセンターの信頼性を高めることを目標とせず、アベイラビリティーゾーンという概念を導入することでユーザーにアプリケーションのレイヤでの安定性を実現できるような手段を提供し、より現実的で実質的な安定性の向上を実現できるよう設計されています。
「クラウド」というと特にネットワーク部分は謎テクノロジーでできていると思われがちです。しかし、ここまでご案内した通り、その設計や概念は当然ですが既存のネットワークを踏襲しており、ただし拡張性や安定性を高めるために実装に当たっては少し違ったアプローチをとっているだけであることを分かっていただけたかと思います。
ですので、クラウドを使ったシステムを構成される際も、「クラウド」だからといってネットワークを無視する必要はなく、むしろここまで紹介したような内容をベースに置きながら、設計をしていただけるとよいと思います。また逆に、既存ネットワークの構成をそのまま持ってくる（例：NICの二枚挿し）だけでなく、どのように動いているかを念頭に置きつつ、より適切な設計へと最適化していく際の一助に本稿がなれれば、筆者としても嬉しいです。
次回は、簡単にAWSのネットワークにおけるベストプラクティスと、過去に発生した問題をご紹介したいと思います。
なお、アマゾン ウェブ サービス ジャパン株式会社ではクラウドサポートエンジニアを絶賛募集中です。 誰よりもAWSの仕組みを深く知り、最先端の技術に触れられる刺激的な仕事です（本稿よりももっと突っ込んだところを知ることができますよ！）。
興味を持ってくださった方はこちらからオープンハウス参加の登録をお願いいたします。
