本稿でお伝えするのは下記の第2回の内容です。全3回に渡って解説していきます。
- AWSのネットワークの物理的な側面 ⇒ 第1回
- AWSのネットワークの論理的な側面 ⇒ 第2回
- AWSのネットワークにおけるベストプラクティス ⇒ 第3回
- AWSのネットワークにおいて過去に発生した問題の事例 ⇒ 第3回
必ずしもAWSの使い方といった内容ではないので、今日すぐに使える知識にはならないかもしれませんが、AWSのネットワークがどのようにできているかをご理解いただくことで、AWSをより効果的・効率的に使っていただく際の参考にしていただけると思います。
AWSのネットワークの論理的な側面
まずは、AWSのネットワークの論理的な側面についてお話しします。具体的には「Amazon Virtual Private Cloud（VPC）」と呼ばれる仮想ネットワークについてのお話になります。VPCではお客さまが仮想ネットワークを定義することができ、その中にEC2インスタンスなどのAWSのリソースを起動できます。
VPC内でAmazon EC2インスタンスがどのように通信をおこなっているかを理解することが、すなわちAWSのネットワークの論理的な側面の理解へとつながっていきます。
Mapping Service
まず、唐突ですが、VPCを理解する上で重要な概念となる「Mapping Service」をご紹介します。VPCを使うだけであれば知る必要はありませんが、その仕組みを理解するためには必須の概念となります。
Mapping Sericeは分散参照システムであり、VPC IDとEC2インスタンスのIPアドレスの組を「Server」と対応付ける機能を提供します。具体例としては上図のVPC ID「青」＋IPアドレス「10.0.0.2」という組をServer「192.168.0.3」と対応付けるということになります。
「Server」とは「仮想サーバホスト」や「ホストコンピュータ」と呼ばれており、要するにEC2インスタンスが動作している場所です。
では、以下で実際にEC2インスタンスが通信する際、Mapping Serviceがどのように使われているかを見ていきましょう。なお、これ以降EC2インスタンス内で動いているOSを「ゲストOS」と呼んでいます。
VPCにおける同一サブネット内の通信（1）
初めに同一サブネット内の通信、つまりレイヤ2での通信を見ていきます。同一サブネット内の通信のためルーターはまだ出てきません。
ARP（Address Resolution Protocol）
まず通常のサブネット内の通信と同じく、ゲストOSが送信先のIPアドレスからMACアドレスを得るためにARPリクエストを送信します。するとServerがすかさずリクエストを横取りし、Mapping Serviceに「VPC ID xxxx 内でIPアドレスが x.x.x.x のEC2インスタンスはどこのServerにいるのか？」と聞きに行きます。
送信先は同じVPC内なのでVPC IDは送信元と同じとなります。先の図にて具体的には、10.0.0.2のゲストOSが10.0.0.3に対するARPリクエストを出すと、送信元ServerはMapping Serviceに「VPC ID 青でIPアドレスが10.0.0.3のインスタンスのServerはどこ？」というリクエストを送り、リプライは「Serverは192.168.1.4。MACアドレスはx:x:x:x:x:x。」となります。
Mapping ServiceよりMACアドレスを取得した送信元Serverは、送信元ゲストOSへとMACアドレスを返します。送信先ServerのIPアドレスはゲストOSには意味が無いため当然返されません。また、ここで送信元ゲストOSが出したARPリクエストは送信先ゲストOSへは到達していないことにご注意ください。
以上のように、各ServerはMapping Serviceで「VPC IDとEC2インスタンスのIPアドレス」をキーに「送信先インスタンスが存在するServerのIPアドレスと、送信先インスタンスのIPアドレスに対応するMACアドレス」を検索している、ということになります。逆に言うと、インスタンスが開始される際には各インスタンスのVPC ID、IPアドレス、MACアドレス、ServerのIPアドレスなどをMapping Serverに登録しておく必要があるということになります。
