【レポート】パケットの気持ちになって辿るAmazon VPCのルーティング #AWSSummit

どうも、もこ@札幌オフィスです。

今年はAWS Summit Onlineという事で、2020/9/8〜9/9の間のライブセッションと、09/30まで視聴可能なAWS認定セッション、お客様事例セッション、 セルフペースハンズオン、Partner Discovery Session (パートナーセッション) などなど、場所を選ばずにオンラインで、好きな時に好きなだけ学べるような環境になっています。

本記事ではライブセッション Day2 Track2 11:30〜12:00の「パケットの気持ちになって辿るAmazon VPCのルーティング」のセッションレポートとなります。

後日ライブセッションのアーカイブも公開されると思いますので、合わせてご覧下さい。

セッション情報

パケットの気持ちになって辿るAmazon VPCのルーティング

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 エンタープライズソリューション部 ソリューションアーキテクト 岡本 京

Amazon Virtual Private Cloud (VPC) はクラウド内に論理的に分離された仮想ネットワークを自由に定義することができるサービスです。きめ細かいルーティングやフィルタリングを実現可能ですが、オンプレミスのルーター/スイッチに慣れ親しんだ方には直観的に理解しづらい部分もあるかと思います。本セッションではパケットの動きを追うことで VPC における設定ポイントやルーティングの動作を説明し、今後の設計において下地となる「クラウドネットワーキングの感覚」を掴んで頂きます。

レポート

• オンプレミスのルーター/スイッチに慣れ親しんだ型には直観的に理解しづらい部分があるかもしれない
• パケットの動きを追いかけてVPCのルーティングの設定ポイント・動作を説明して、下地となるような感覚をつかむ

   

• Amazon Virtual Private Cloud(VPC)

  • AWSはリージョンと呼ばれるデータセンタークラスターを提供
  • リージョンの中にはアベイラビリティーゾーンが提供
    • 略してAZ
  • 各AZは電源・ネットワークなどが独立していて他のAZに影響が及ばない
  • 複数のAZにまたがる構成を推奨

• VPCの中にはサブネットを作成出来る
  • サブネットはAZ単位
  • サブネットごとに「インターネットにでれるサブネット/でれないサブネット」を制御

• サブネット単位でルーティングする事が可能な"ルートテーブル"
  • 暗黙的に存在するルーターの経路設定
  • EC2から見るとデフォルトゲートウェイ

• その他にも、ゲートウェイ各種がある
  • 内部で冗長化されているが、単一として見えるタイプと、サブネット単位でNICが生えてくる物がある

• オンプレミスとの比較
  • VPCを作る = ルーターとDNSを設定する
  • サブネットを作る = スイッチ(VLAN)とDHCPを設定する
    • ルートテーブルで各サブネットごとで経路を制御可能
  • EC2を作る = サーバーにOSインストール、初期設定を施しスイッチに接続する

• VPCは仮想ネットワーク
  • EC2はハイパーバイザーを搭載した物理ホスト上に起動される
• EC2 AからEC2 BにHTTP通信したい場合
  • EC2 BのMAC Adress解決のためにARPが飛ぶ
  • ARPを受けてマッピングサービスに問い合わせる
  • マッピングサービスから結果が帰ってくる
  • EC2 AはEC2 Bに対してHTTPリクエストを投げる

• VPC IDでカプセル化してパケットを投げる

• 届いた通信が正規の通信かどうかをマッピングサービスに問い合わせて、正規のインスタンスからの通信からかを確認して、カプセル化を解く

• これらの裏の仕組みは意識しなくていい
  • VPC上だけみると Layer 2/3通信が行われている
• VPCにおける設計パターン
  • VPC< = > インターネット
  • VPC< = > オンプレミス
  • VPC< = > VPC

パケットの気持ちで設計を考える

• VPC内からNAT GWを介してInternetにアクセス
  • Public SubnetにNAT GWを配置
  • パケットはEC2から発生
  • 自サブネット外なのでフォルトゲートウェイに送信
  • ルートテーブルにNAT GWへの経路を書く
  • NAT GWはルートテーブルを参照して一致したエントリーに従ってInternet Gatewayに行く
    • NAT GWはルーティングしない
  • Internet Gateway後はマネージド
  • IGWが持つ経路情報はユーザーには参照出来ない(参照する必要が無い)
• VPC内からVGWを介してオンプレミスにアクセス
  • AWS Direct Connectを利用
  • Equinixなど
  • BGPを利用して経路交換をする
  • AWSの終端はVGWまたはDirect Connectがある

• VPCにあるEC2からオンプレミスに通信したい場合
  • デフォルトゲートウェイのルートテーブルにパケットが届く
  • ルートテーブルを見て、VGWに行く
  • VGWの経路をみてCGWに送信
  • VGWの経路は見れない、トラブルシューティングなどで必要な場合はサポートケースで問い合わせる

• VPC内からTGWを介して他のVPCにアクセス
  • TGWの用語について
    • TGWを作るとルートテーブルを必要数作成可能
    • TGWとつなぎたいVPCはNICをはやすアタッチメントを作成する
    • アソシエーションでVPCからのOutbound通信を制御
      • どのルートテーブルを使うのかを制御
    • Inbound通信はプロパゲーションでVPCへの経路情報を渡す

• VPC AのEC2からVPC BのEC2に通信したい場合
  • EC2 Aサブネットのルートテーブルを見る
    • TGWを見るエントリーに従いTGWに送信(アタッチメントを介して)
  • TGWはアソシエーションの設定に従ってルートテーブルを参照
  • 一致したエントリーに従ってVPC BのアタッチメントからEC2 Bに到達

• 複雑なネットワークなどで生かせる、次のステップ
  • 外部接続VPCを作って全てのOutbound通信を集約したい場合: TGW
  • VPCへのInbound通信をセキュリティー製品などのアプライアンスに通す場合: Ingress Routing
  • オンプレミスから海外リージョンに接続したい場合: Direct Conenct Gateway
  • オンプレミスとAWSの多対多接続をしたい場合: Direct Connect Gateway + TGW

まとめ

• ルーティング設計に必要な知識はオンプレミスと同じ
• 可用性やスケーラビリティはクラウドに任せられる
  • お客様は経路設計に集中出来る
• クラウドの利点を活用してクールなネットワークを設計出来る
  • 従量課金、必要な時にすぐに作成、削除が出来る
  • APIによる自動化とInfrastracture as Codeを利用した運用も可能
  • VPC自体の利用は無料で、データ転送料金は国際回線も含めてオンデマンドの従量課金