re:Invent 2024: AWSネットワーキングの新機能とVPC高度設計
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Amazon VPC: Advanced design and what’s new (NET301)
この動画では、AWSのネットワーキングサービスの最新機能と高度なVPCアーキテクチャについて解説しています。34のRegion、41のLocal Zone、141のDirect Connect POPを持つAWSのグローバルインフラの現状から始まり、VPC Lattice、AWS Verified Access、CloudFront、Cloud WANなど、2024年にリリースされた新機能を詳しく紹介しています。特に注目すべき機能として、Security Group VPC Associations、VPC Block Public Access、PrivateLinkのUDPサポート、クロスリージョンサポートなどが挙げられます。また、CloudWatch Flow MonitorやEthtoolなどのObservabilityツールを活用したネットワークモニタリングの手法についても具体的に説明しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Advanced VPC Designセッションの概要と登壇者紹介
皆様、Advanced VPC DesignとAmazon VPCの新機能についてのセッションへようこそ。このセッションは7年間続いており、皆様にご参加いただき大変感謝しております。このセッションでは、高度なVPCアーキテクチャについて説明し、この1年間の新機能についてお話しします。スライドとコンテンツがたくさんありますが、スライドの撮影を逃してしまっても心配いりません。セッションの最後にQRコードをご用意しており、重要なコンテンツをすべて含む要約版にアクセスできます。
私はEC2 Networkingチームの Senior Principal Solutions ArchitectのMatt Lehwessです。そして私はStrategic AccountsのPrincipal Network Specialist Solutions ArchitectのAlexandra Huidesです。それでは始めましょう。これは300レベルのセッションですが、いつものように100レベルから始めて徐々にレベルを上げていきたいと思います。このような基本的な内容を驚くべき速さで説明することは、もはやミーム化しているほどですが、超高速で進めていきます。
AWSインフラストラクチャとAmazon VPCの基本
まず、AWSのインフラストラクチャがグローバルにどのように展開されているかについてですが、 現在34のRegion、41のLocal Zone、そして141のDirect Connect POPがあります。私が2013年に始めた頃は確か16しかありませんでした。現在では600万マイルのファイバーを保有しており、 すべてのAWS Regionを相互接続する巨大なバックボーンネットワークを形成しています。
Regionについて詳しく見ていきましょう。US-West-2（PDX Region）を例に取ると、Regionはデータセンターで構成されています。 これらのデータセンターは、相互に接続された耐障害性のあるグループとしてAvailability Zoneにまとめられています。 Amazon VPCはRegionレベルの構成要素で、その地理的Regionのすべてのデータセンターにまたがっており、データセンターのラックに物理的に存在するEC2インスタンスをデプロイすることができます。
コンソール内でVPCを操作する立場から見ると、Internet GatewayやIPv6を使用する場合はEgress-only Internet Gatewayを通じてパブリックインターネットと通信することができます。 プライベートサブネット、セキュリティサブネット、NATを処理するNAT Gatewayサブネットがあり、そのサブネットには潜在的にAWS Network Firewallが配置されています。 VPC内でAuto Scalingを可能にするElastic Load Balancerを設置することもでき、これによってクラウドの真の力を引き出すことができます。
また、S3のようにVPCの外部に公開されているサービスもあります。これはAmazon VPCよりも前からある機能です。通常、お客様は複数のVPCを持っており、Peeringを使用して接続することができます。 2018年にリリースされたTransit Gatewayでは、最大5000個のVPCを接続することができ、実際に数千個のVPCを環境内にデプロイしているお客様も見受けられます。 Transit Gatewayはリージョンレベルの構成要素で、他のリージョンとも接続が可能です。
SD-WANヘッドエンド経由でオンプレミス環境に接続する場合はTransit Gateway Connectを利用でき、 Direct Connectを介したハイブリッド接続も提供しています。VPN接続やDirect Connect POPを経由したDirect Connectを使用することができます。 Cloud WANは基本的にほぼすべてのリージョンをカバーするグローバルサービスです。 Cloud WAN Connectも利用可能で、 2016年か2017年からサービスを開始しているPrivateLinkを使用すると、VPC内のサービスとのプライベート接続が可能です。
AWS PrivateLinkやインターフェースエンドポイントを使用してパブリックサービスに接続したり、独自のカスタムサービスを構築したりすることができます。 独自のスケーラブルなファイアウォールフリートをデプロイしたい場合は、Gateway Load Balancerがあります。新しい追加機能としてVPC Latticeがあり、本日はこれに関する高度なアーキテクチャについて多く取り上げる予定です。 2年前にプレビューとしてローンチしたAWS Verified Accessがあります。これは、VPCへのVPNレス接続を可能にするZero Trustサービスです。このサービスについても新機能がありますが、これで2023年12月までの説明となります。
2024年のIPアドレス管理とIPv6サポートの進展
2023年12月の時点で、これらのコンポーネントを全て使用したアーキテクチャはこのようになります。 そして2024年に入ります。 2024年には、ご存知の通り、この1年間で多くの機能がリリースされました。これから基礎から高度なアーキテクチャまでを見ていきますが、まずはIPアドレス管理から始めましょう。
AWSには、Amazon VPC IPAMというIPアドレス管理サービスがあり、 複数のリージョンや複数のアカウントにまたがるIPv4とIPv6のアドレス管理を効率化することができます。 2024年には、いくつかの機能がローンチされました。その中には、任意のインターネットレジストリに登録されたIPに対するBYOIPや、リージョン内の複数アカウントでAmazon提供の連続したIPv4ブロックを使用できる機能、そしてすべてのAWS Local ZonesでのBYOIPとBYOASNのサポートが含まれています。これは エッジにコンピューティングをデプロイするお客様にとって重要な機能です。
今回ご紹介する新機能は、IPAMにおけるOU-levelフィルタリングです。AWSのお客様から、特定の環境をIPAMの管理対象から除外して管理範囲を最小限に抑えたいというニーズをお聞きしており、OU-levelフィルタリングはまさにそのニーズに応えるものです。 さて、IPアドレス管理について話す際、AWSにおけるIPv6について触れないわけにはいきません。 2024年には20以上のIPv6サポートに関する発表があり、これは素晴らしい進展です。個人的にも非常に興奮しています。Amazon VPC Private IPv6 Addressingの導入や、EC2 Instance Connect IPv6サポートなど、特に後者は私のお気に入りの機能の一つです。というのも、もはやインスタンスにSSH接続する際にパブリックIPv4アドレスが不要になったからです。
Private IPv6 Addressingについて、IPv6は通常パブリックなものと考えられているため、疑問に思われる方もいらっしゃるかもしれません。Amazon VPCでは2種類のIPv6アドレスをサポートしています：AWSからインターネットにアドバタイズされるパブリックIPv6アドレスと、プライベートIPv6アドレスです。プライベートIPv6アドレスには3つのタイプがあります。 1つ目は、AWSからインターネットにアドバタイズされないBYOIP IPv6 GUAで、アドバタイズの状態を完全にコントロールできます。 2つ目は、ULA（Unique-Local Addressing）のサポートです。ULAはプロトコル定義上、インターネットにアドバタイズできないため、インターネット接続にはアドレス変換が必要になることにご注意ください。 最後に、一見矛盾しているように思えるかもしれませんが、Private GUAがあります。これは、お客様になじみのあるIPv4の構成に対応するもので、インターネットに決してアドバタイズされないプライベートIPv6アドレスをVPC内で柔軟に使用できます。
VPCセキュリティの強化：Security GroupsとBlock Public Access
さて、基礎の中の基礎であるIPアドレッシングについて説明したところで、スタックを上に進めて Amazon VPCネットワーキングについて、VPCのセキュリティ基盤を見ていきましょう。AWSにおいて、セキュリティは最優先事項の1、2、3位を占めており、私たちは徹底的にセキュリティに焦点を当てています。製品を構築する際は、常にセキュリティを第一に考えています。VPCに関しては、Network Access Control ListsとSecurity Groupsという2つの主要なツールから始まる、より多くのセキュリティ機能をVPCに組み込むことを常に検討しています。
Network Access Control ListsとSecurity Groupsの実際の姿について、皆さんもおそらく使用したことがあるでしょう。 Network Access Control Listは基本的にサブネットに適用するステートレスなルールであり、一方Security Groupはインスタンスやその他のエンティティ（主にインスタンス）に適用するステートフルなルールです。
実際、Security Groupは相互に参照することができます。ここでご覧いただけるように、WebアプリケーションのALB Security Groupを参照して、そのSecurity Group内のものからWebアプリケーションへのアクセスを許可するという設定が可能で、皆さんも今日このような設定をされているのではないでしょうか。Security Groupsはリソースレベルのステートフルなエンティティで、 従来はVPCの境界内で定義されます。
今年リリースした新しい Security Group の機能について説明していきましょう。まず、VPC アソシエーションが追加されました。これは、アカウント内で作成した Security Group を複数の VPC で使用できるようになったということです。具体的に見ていきますと、ここに2つの VPC があり、以前は Security Group は VPC レベルの構成要素でした。ユーザーの皆さんが異なる VPC で同じ Security Group ルールを設定しようとすると、その都度新しい Security Group ID が生成され、これは少し面倒でした。現在は、異なる VPC 内のエンティティに対して Security Group を関連付けることができます。
Security Group は現在、アカウントレベルの構成要素となっています。また、VPC 間で関連付けできるのは非デフォルトの Security Group のみです。さらに、Security Group の共有機能も提供しています。VPC シェアリングは多くの方々が利用している機能です。最初、VPC シェアリングをローンチした時は、なぜ新しい VPC を作って Transit Gateway のようなもので接続しないのかと懐疑的でした。しかし今では完全に納得しています。VPC オーナーとして VPC やルーティング、VPC の構成要素すべてを所有し、別のアカウントとサブネットを共有して、そのパーティシパントが VPC 内でリソースをスピンアップできるようにする - これは非常に便利なツールです。
基本的な構成としては、VPC があり、複数のアカウントにまたがってサブネットが共有されています。このサブネットは実際にはVPC シェアリングによって共有されています。VPC Security Group シェアリングでは、その VPC のパーティシパントと Security Group を共有できるようになりました。以前は Security Group は VPC オーナーだけのものでしたが、現在はパーティシパントも使用できます。これは Security Group 周りでの作業をより簡単にする新しい方法です。ここで考慮すべき点がいくつかあります。パーティシパントは必要に応じて自身の Security Group を使用し続けることもできますし、共有された Security Group も使用できます。これが最も重要なポイントです。また、デフォルトの Security Group やデフォルトの VPC では使用できません。
最後に、これは本当に最新のニュースで、たしか数週間前の発表だと思いますが、私自身は昨日から使い始めました。Block Public Access は、お客様からの要望に応えて実装された機能です。「VPC があり、Security Group や NACL、ルーティング、IGW、Elastic IP などで制御できるけれど、この VPC へのパブリックアクセスを完全に遮断するための単純なレバーが欲しい」という声に応えたものです。VPC の構成を見てみると、さまざまなコンポーネントがあることがわかります。IPv4 または IPv6 アドレスを持つパブリックサブネット、そして IPv6 の場合は Egress-only Internet Gateway を介して、IPv4 の場合は NAT Gateway を介して通信するプライベートサブネットがあります。
基本的にこれらの異なるコンポーネントをすべてコントロールして、特定のサブネットへのアクセスをブロックし、そのポリシーを制御する必要があります。ここでの Internet Gateway は双方向のトラフィックを許可し、Egress-only Internet Gateway は一方向のみとなっています。Block Public Access では、基本的にこの VPC へのすべてのパブリックアクセスをオフにすることができます。VPC に対してワンクリックで宣言的に制御できます。必要に応じて、サブネットレベルでの除外設定も可能です。実際には双方向モードと入力専用モードという2つのモードがあり、これは非常に便利です。Network Access Analyzer を使用して影響を評価することもできます。
Network Access Analyzerは、特にコンプライアンスの目的では十分に活用されていないサービスの1つです。一般ユーザーとしても、私自身もっと活用すべきかもしれません。Block Public Accessの設定によってドロップされたパケットについても、フローレベルの可視性が得られます。
VPC接続性の進化：PeeringからTransit Gateway、Cloud WANまで
ここからは、数千のVPCを持つユーザーのためのVPC接続性について説明します。 VPCの接続性について話す理由は、AWSのデフォルトアーキテクチャがもはや単一のVPCと単一のアカウントではないからです。マルチアカウント、マルチVPCのアーキテクチャが現在のスタンダードとなり、AWS Well-Architected Frameworkに沿ったものとなっています。複数のVPCについて話す際、私たちはVPC同士の接続について議論することになります。
VPCを接続する最初のオプションは、Amazon VPC Peeringです。 VPC PeeringはVPC向けの分散型接続モデルです。これはポイントツーポイントの接続モデルで、非推移的であることを覚えておいてください。これは他の接続オプションを見ていく上で重要です。VPC Peeringでは限られた数のVPCを相互接続できます。VPC Peeringの利点は、追加の遅延がないことと、スループットの制限がインスタンスの利用可能な帯域幅によってのみ制限されることです。基本的なVPC接続オプションとしてどのように機能するか見てみましょう。2つのVPCをペアリングする際、各VPCのルートとルートテーブルを柔軟に追加できます。
注意すべき重要なポイントがいくつかあります：ピアリングは推移的ではありません。また、同一リージョン内のVPC Peeringではセキュリティグループの参照が可能です。このトピックについては後ほど再度取り上げます。また、同一リージョン内でVPC Peeringを使用する場合、ネットワークアドレスの使用量やVPCのリソース数、それらのマッピングが積み重なっていくことにも注意が必要です。
マルチVPC、マルチアカウントのアーキテクチャをスケールさせていくと、数百から数千のVPC間の接続が一般的になってきます。 ここで登場するのがAWS Transit Gatewayです。多くの方がすでにご存じかもしれません。私がまだカスタマーだった最初のre:Inventで発表されたサービスです。 Transit Gatewayでは、ハブアンドスポーク型の接続モデルを採用しています。ここでのハブはTransit Gatewayで、数千のVPCを相互接続し、 同一リージョン内でハイブリッド接続を提供することで、運用と管理を簡素化します。
Transit Gatewayの仕組みを見てみましょう。非常にシンプルです。VPCやリソースをTransit Gatewayにアタッチし、その後、複数のルートテーブルを設定して、それらのアタッチメントをルートテーブルに関連付け（associate）、伝播（propagate）させることができます。ここで、お客様とよく話題になる重要な区別があります。関連付けと伝播には大きな違いがあるのです。アタッチメントをルートテーブルに関連付けると、そのアタッチメントからそのルートテーブルに入ってくるトラフィックは、そのルートテーブルのルーティングルールに従うことになります。アタッチメントをTransit Gateway上の多くのルートテーブルに伝播させると、それらのルートテーブルに自動的にルートが追加されます。
少数のVPCでVPC Peeringを使用し始め、その後マルチアカウントアーキテクチャに成長したお客様からよくある質問は、VPC PeeringとTransit Gatewayが共存できるかということです。答えはイエスです。なぜなら、VPC Peeringはポイントツーポイントの接続オプション、つまり非常に具体的なルーティングオプションであるのに対し、Transit Gatewayはルーティングハブだからです。この例のように、Transit Gatewayを通じてサマリールートを設定し、VPC Peeringを通じて具体的なポイントツーポイントルートを維持することができます。
先ほど、Security Groupの参照について後で説明すると言いましたが、Mattは2つのSecurity Group機能について説明しました：Security Group VPC AssociationsとShared VPCの参加アカウントとのSecurity Groupの共有です。しかし、Security Groupの主要な機能の1つは、VPC内および同一リージョン内でピアリングされたVPC間でのSecurity Groupの参照でした。そして現在、Transit Gatewayを介したSecurity Groupの参照もサポートしています。これは、Transit Gatewayの開始当初からリクエストされていた機能で、おそらくTransit Gatewayに対する最大の機能要望の1つでした。
この機能を使用すると、Transit Gatewayと共にSecurity Groupの参照設定を使用し、リソースのアイデンティティを維持することができます。これは、Transit Gatewayを通過する接続におけるSecurity Groupの動作を示しています。重要なポイントとして：Security Groupの参照設定は、VPC内やVPC Peering間で行っていたのと全く同じように、Security Group IDを使用して設定します。ただし、Transit Gatewayでは、インバウンドルールのみが許可され、Transit Gateway全体でSecurity Group参照を有効にし、さらにSecurity Group参照を機能させたい特定のアタッチメントでも有効にする必要があります。最後によく質問される点として：Security Group Sharing、Security Group Reference、Security Group VPC Associationsを併用できますか？答えは、もちろんイエスです。どの機能を使用するかは、ユースケースによって大きく異なります。
そして今、リージョン内のTransit Gatewayルーティングハブについて、AWSでのネットワークアーキテクチャの進化について話してきました。VPCとアカウント、マルチVPC、マルチアカウントピアリングTransit Gatewayについて説明しました。そして今、AWSでの次のレベルのアーキテクチャについて話しています。それはマルチリージョン接続です。アプリケーションの要件は、クライアントの場所や耐障害性の要件、あるいは各サービスの要件に応じて、マルチリージョンデプロイメントを必要とします。では、グローバルな接続性をどのように実現し、Transit Gateway同士をピアリングしてそれらのピアリング接続を管理する必要のない、シンプルなモデルをどのように実現できるでしょうか？
アプリケーションネットワーキングの新展開：PrivateLinkとVPC Lattice
ここで AWS Cloud WAN の出番です。このサービスはかなり前からありましたが、ここ数年で機能が充実してきており、今日はそのいくつかについてお話しします。AWS Cloud WAN は、ネットワークエンジニアやネットワーク関係者の間でネットワークインテントを表現することを可能にします。ネットワークインテントという言葉は、ネットワーク接続について語る際に重要な意味を持つ用語で、AWS Cloud WAN ではポリシーを通じてこれを実現し、統合されたトラフィックセグメンテーションと包括的なモニタリングを提供します。
さて、Cloud WAN には、新機能の説明に入る前に確認しておくべきコンポーネントがいくつかあります。Core Network、Core Network Edge、Policy Segment、そして Attachment です。それぞれを見ていきましょう。まず Core Network ですが、これはAWS が管理するグローバルな構成要素で、ネットワークポリシーで定義した地域にまたがって存在します。各リージョンで、Cloud WAN は Core Network Edge を維持しており、これがそのリージョンのルーティングハブとなります。すべての Attachment はここに関連付けられます。
これらの設定は、Transit Gateway のような設定方法とは異なります。Transit Gateway では、オブジェクトを作成してARN を取得するという流れでしたが、ここではすべてが Core Network Policy を通じて設定されます。ここで、BGP において各 CNE が独自の自律システム番号を持つように、Cloud WAN Core Network の自律システム番号の範囲を定義します。また、Cloud WAN Core Network が存在するエッジロケーションを定義し、Attachment ポリシーも定義します。これらの Attachment ポリシーが具体的に何をするのか、すぐにご説明しますが、Cloud WAN のような構成に対して環境内の個々の Attachment を手動で設定する必要がなくなります。ポリシーを設定すると、グローバルネットワークでよく必要とされるグローバルセグメンテーションの意図を表現できるようになります。
Cloud WAN は現在、5種類の Attachment をサポートしています。新しいものに入る前に、基本的なものから始めましょう：VPC、GRE ベースの Connect Attachment、トンネルレス Connect、Transit Gateway ルートテーブル、そして Site-to-Site VPN です。全員が理解を共有できるよう、それぞれを確認していきましょう。
VPC Attachment については、VPC を Core Network に接続すると、Core Network は各 Availability Zone に1つずつ Elastic Network Interface を維持します。VPC CIDR は、Attachment ポリシーで指定されたセグメントに自動的に伝播されます。IPv4 と IPv6 の CIDR の両方が自動的にセグメントに伝播されます。ただし、VPC ルートテーブルの制御権は維持されます。つまり、VPC 側では Cloud WAN へのルーティングを自由に決定できます。Cloud WAN は VPC ルートテーブルに自動的にルートを注入することはありません。
GRE Connectについて、多くのお客様から、SD-WANアプライアンスやセキュリティアプライアンスをCloud WANやTransit Gatewayとシンプルな方法で統合したいというご要望をいただいています。GRE Connectには、VPC AttachmentとConnect Attachmentというトランスポートアタッチメントがあり、その上にCore Network Edgeとの間でBGPセッションを確立するConnect Peersがあります。お客様からGRE Connectベースのトンネルは5Gbpsに制限されているとのフィードバックをいただき、私たちはそれに応えて、SD-WANアプライアンスのネイティブ統合のためにCloud WANでトンネルレスConnectを導入しました。GREトランスポートトンネルを使用しないトンネルレス方式であるため、スループット制限なしでインスタンスの帯域幅全体をCloud WANへの接続に使用できます。
Transit Gateway Route Table Attachment Typeは、既存のTransit Gateway環境との移行や統合を簡素化するために設計されています。これには、Transit GatewayとCore Networkのピアリングが必要で、Transit Gateway上の各ルートテーブルをCore Network Segmentにアタッチする必要があります。Core Networkに拡張するルートテーブルを選択できます。双方向の動的ルーティングが可能で、Transit Gatewayは自動的にそのルートテーブル内のすべてのルートをCloud WANにアドバタイズし、Cloud WANは自動的にそのセグメント内のすべてのルートをTransit Gatewayにアドバタイズします。つまり、静的ルーティングを設定する必要がないというわけです。
Site-to-Site VPNについては、皆様もよくご存知のことと思いますが、Transit Gatewayでもサポートされています。お客様から強く要望されていたCloud WANでのネイティブなDirect Connect接続のサポートを、Direct Connect Gateway Attachmentとして提供開始しました。現在では、Direct Connect GatewayをCloud WANのCore Network Segmentに直接アタッチできます。Direct Connect Gatewayをアタッチする際には、どのRegionにアタッチするかを指定する必要があります。Direct Connect Gatewayはグローバルな構成要素であることを覚えておいてください。そのため、Cloud WANにアタッチする際、Cloud WANはCore Network Policyで定義した一連のRegionにわたって動作します。どのCore Network EdgeがDirect Connect Gatewayからルートを自動的に学習すべきかを指定する必要があります。
特別なルーティングシナリオがない限り、ベストプラクティスとしては、Direct Connect GatewayをすべてのCore Network Edgeにアタッチまたは関連付けることをお勧めします。これにより、不要なクロスリージョンの依存関係を作成することなく、Core NetworkとDirect Connect Gateway間で直接ルーティングが行われます。もう一つの重要な点は、複数のDirect Connect GatewayをCloud WANのCore Networkに接続できることです。
AWS Verified AccessとCloudFrontの新機能
お客様は、AWS Cloud WANでのセグメンテーションをハイブリッド環境全体で維持するエンドツーエンドのネットワークセグメンテーションを選択することも、Direct Connectをハイブリッドセグメントに取り込んでセグメント間のインスペクションを設定することもできます。インスペクションについて触れましたが、AWS Cloud WANは、集中型のエグレスインスペクションやクロスセグメントインスペクションなど、お客様の集中型インスペクションの実装を簡素化します。
Service Insertionについて見ていきましょう。 これは今年のReinforceで発表した機能です。 Network Function Groupという新しいコンポーネントがあります。インスペクションから始めて、この設定方法を見ていきましょう。3つのリージョンにまたがってCloud WANのCore Networkが展開されています。 Network Functionを含むVPCが必要です。Network Functionは必ずしもVPC内にある必要はありません - 例えばTransit Gatewayに接続されていたり、オンプレミス環境にあっても構いません。ただし、 この例では、Cloud WANとVPCに直接接続されているケースを考えます。
ステップ1はNetwork Function Groupの作成です。これはポリシー定義です。Network Function Groupは、 Core Networkを作成したリージョン全体でグローバルな構成要素として作成され、Core Network内の1つのSegmentを使用します。ステップ2では、 Network Function Groupのアタッチメントポリシーが非常に重要です。VPCアタッチメントやRoute Tableアタッチメントが作成されると、適切なSegmentに関連付けられます。その後、VPCからアタッチメントを作成すると、それらのアタッチメントは自動的にNetwork Function Groupにマッピングされます。
ステップ4は私のお気に入りのステップです。なぜなら、これは意図を文書化することを意味するからです。インスペクションアーキテクチャで何をしようとしているのか、どのSegmentが集中型Egressを必要とするのかという参照情報です。この表は、すべての顧客の方々にWikiページやドキュメントページで管理していただくようお願いしているものです。 これを文書化したら、Cloud WAN Core Networkポリシーに変換し、Segment Actionを設定できます。 これらのSegment Actionは、インスペクションが必要なすべてのSegmentに対して個別に設定でき、 Cloud WANのRoute Tableに注入されるルートに変換されます。
Send-toアクションは集中型Egressに特有のもので、 これを設定すると、これらのルートがRoute Tableに伝播されます。 インスペクションVPCがないリージョンがある場合は、 Edge Overrideを使用して集中型Egressをオーバーライドできます。クロスSegmentのService Insertionやインスペクションについては、同じベースラインアーキテクチャから始めます。 2つのリージョンとそれぞれにインスペクションアタッチメントがある状態で、やはり意図を文書化する必要があります。文書化したら、 今度はSend-via Segment Actionを使用してネットワークポリシーに変換します。これにより、トラフィックのSegmentやルーティングの対称性を維持するための 適切なルートがRoute Tableに伝播されます。
トラフィックがFirewallを通過する際、Firewallがそのセッションを認識できるように、出力トラフィックと戻りトラフィック、つまり送信と受信の両方のトラフィックが同じFirewallを通過する必要があります。Send-viaアクションはこれを維持するのに役立ち、設定には Single HopとDual Hopの2つのモードがあります。 ここまで、すべてレイヤー3の接続について話してきました。Transit Gatewayやクラウド内のPeeringについて説明してきましたが、AWSでのネットワーキングと接続の進化に向かうと、Application Networkingの領域に入ります。これは数年前に私たちが作った用語で、既存のAWSサービスと新しいサービスのいくつかをApplication Networkingとしてまとめています。まずはElastic Load Balancingから始めましょう。
AWSのLoad Balancerには、Application Load Balancer、Network Load Balancer、Gateway Load Balancerの3種類があります。Application Load Balancerは、ヘッダーの操作や変更など、多くのユーザーから要望のあった機能が追加され、非常に実りある1年となりました。Network Load Balancerも充実した1年でした。高可用性やゾーンフェイルオーバーに関連する多くの機能が追加され、TCPタイムアウトの設定も可能になりました。
API Gatewayは大きな進展があった1年で、個人的に最も気に入っているのは、プライベートカスタムドメインとIPv6のサポートです。ここで、アプリケーションネットワーキングの2つの基本的なサービスについて説明しましょう。導入部分でお話しした AWS PrivateLinkは、AWSマネージドサービスやサードパーティのサービスへのアクセスを提供します。現在、PrivateLinkと統合された190以上のAWSサービスエンドポイントがあり、多くのSaaSプロバイダーもネイティブに統合されています。
基本的な部分に目を向けると、PrivateLinkを通じてアクセスできるAWSサービスには2つのタイプがあります。Amazon S3とDynamoDBについては、これらのゲートウェイエンドポイントはVPCサブネットのIPアドレスを使用しませんが、ルートテーブルの更新が必要です。インターフェースエンドポイントを使用すると、VPC内のElastic Network Interfaceを使用して、AWSマネージドサービスやカスタムマネージドサービスと通信できます。
カスタムマネージドサービスについても、VPCインターフェースエンドポイントと同じ原理が適用されます。これらを作成する際は、まずNetwork Load Balancerとエンドポイントサービスを作成する必要があります。これがサービス側となり、コンシューマー側のインターフェースエンドポイントを提供します。考慮すべき点として、クロスアカウント接続が利用可能で、カスタムマネージドサービスではIPv4とIPv6がサポートされており、重複するIPアドレスも使用できます。DNSに関しては、AWSマネージドサービスではプライベートDNSが管理されており、カスタムマネージドサービスの場合は、サービスプロバイダーがDNSを管理するか、プライベートホストゾーンを使用してVPC上でDNSを管理することができます。
非常に興味深い新機能として、長年待ち望まれていたAWS PrivateLinkのUDPサポートが実現しました。ここで重要なのは、コンシューマー側からIPv6とIPv4の両方でPrivateLinkサービスに接続できるということです。ただし、ターゲットグループはIPv6である必要があります。ターゲットはデュアルスタック機能を持つことができますが、ターゲットグループへの登録はIPv6を使用して行う必要があります。
最後になりましたが、VPC Resourcesの日曜日のローンチについてお話しします。お客様から、ロードバランシングを必要としない、あるいはNetwork Load Balancerを前段に置けないサービスをPrivateLink形式で公開できるようにしてほしいという要望がありました。Resourcesには、いくつかの新しい構成要素があります。その1つがResource Gatewayで、これはVPC内でリソースへの接続を可能にする構成要素です。もう1つのResource Configurationでは、ARN、IP、またはDNSによってリソースを定義します。これらのリソースは、Resource GatewayがアクセスできるVPC内に存在します。
これらのリソースは、オンプレミスに存在することも、Resource Gatewayが配置されているVPCがレイヤー3アクセスを持っている場合は、他のVPCに存在することも可能です。クライアント側となるEndpoint側については、VPC Endpointとの通信では、Resource Configuration1つにつき1つのEndpointが許可され、リモートVPCやアカウント内のこれらのリソースにアクセスすることができます。
考慮事項として、Resource Gatewayには複数のResource Configurationを関連付けることができることを覚えておいてください。これらのResource Configurationは、オンプレミス、クロスリージョン、またはPrivateLinkとして設定できます。この会場にいらっしゃる多くの方々は、PrivateLinkとクロスリージョンサポートを使用したクロスリージョンPrivateLinkについて考えてこられたと思います。それが実現しました。クロスリージョンVPC Endpointを通じて、PrivateLinkを利用したカスタムサービスにアクセスできるようになりました。
必要な作業は、管理している既存および新規サービスについて、そのサービスを利用したいリージョンを有効にするだけです。サービスの再デプロイ、Network Load Balancerの再デプロイ、Endpointの再作成は必要ありません。すべてが揃っています。非常に重要な点として、これは現在、AWSマネージドサービスではなく、カスタムマネージドサービスでのみサポートされています。
VPC Latticeの詳細と新機能
そして最後のサービス、そして私個人が最も期待しているのが、アプリケーションネットワーキング分野のAmazon VPC Latticeです。VPC Latticeを使用することで、AWS上での接続性の簡素化、スケーリング、セキュリティ確保が可能になります。現在はECSやECS Fargateを含むすべてのAWSコンピューティングオプションと統合されています。これについても説明しますが、統合されたトラフィック制御機能を提供します。
VPC Latticeのコンポーネントは、この4つのシンプルなものです。それぞれについて見ていきましょう。VPC Latticeには、リスナー、ルーティングルール、ターゲット、そしてターゲットグループを持つサービスがあります。2つ目はService Directoryで、アカウントでサービスを作成したり、Resource Access Managerを通じてサービスが共有されたりすると、このService Directoryに表示されます。そして3つ目がService Network で、これは同じセキュリティと接続要件を持つサービスとクライアントを結びつける論理的な構成要素です。
サービスとService Networkの両方がRAMで共有可能な構成要素です。運用モデルに応じて、どちらを共有するか選択できます。サービスをService Networkに関連付けることができます。ポリシーは、運用モデルの粒度に応じて、Service Network、サービス、またはその両方で設定できます。これらは実際にはIAMポリシーなので、お客様がAWSマネージドサービスを利用する際に馴染みのあるものです。
アクセスの観点からは、クライアント側のService Network Associationを通じてService Networkにアクセスでき、そこでセキュリティグループを設定できます。ルーティングはVPC Latticeが自動的に処理します。ルートは自動的にルートテーブルに追加されます。DNS関連では、AWS PrivateLinkと同じモデルを採用しており、カスタム名でプライベートホストゾーンを更新することができます。今年新しく登場したRoute 53プロファイルを使用することで、この作業を簡素化することもできます。
先ほど触れたECSとECS Fargateもサポートされており、最近のローンチの一つです。ECSやECS Fargateのサービスを、Lattice Service Networkと自動的に統合することができます。以前のような方法で使用していたApplication Load Balancerは、もう必要ありません。もう一つの大きな要望だったのが、TLSパススルーまたはTLSリスナーで、これによりサービス間でMTLSを使用した通信が可能になります。これは、エンドツーエンドの暗号化を実装するお客様にとって非常に一般的なユースケースです。
TLSリスナーを使用すると、VPC Latticeは単なるトランスポート層として機能し、VPC内のクライアントが直接サービスを利用できるようになります。本日のローンチには、PrivateLinkと同様に、VPC LatticeでサポートされるようになったVPCリソースが含まれています。お客様から、ロードバランサーを使用しないリソースもVPC Latticeに関連付けられるようにしてほしいという要望がありました。ご存知の通り、Resource Gateway Resource設定、ARNベース、IPベース、またはDNSベースの同じ契約を、Service Metricに関連付けることができます。
ここまでで、Service Networkに組み込むことができるすべてのサービスタイプを振り返ると、それらすべてを利用することができます。 VPC Latticeの最後の機能として、Service Network Associationsについてお話しします。 Service Network Associationsは、Service Networkを利用するためのデフォルトの方法です。IP Destinationsに使用されるIPアドレスはVPCからのものではありません。 これはGateway Endpointと非常によく似た動作をします。Service Network Endpointsでは、 PrivateLink Interface Endpointsと非常によく似ており、VPCのEndpointを使用してService NetworkやService Network内のサービスにアクセスすることができます。PrivateLink Endpointと同様の仕組みで、作成するとVPCのIPアドレスを使用します。
これにより、VPCから複数のService Networkにアクセスすることが可能になります。 お客様から多く寄せられているリクエストの一つとして、オンプレミスからService Network Endpointsにアクセスできるようにすることがあります。 VPCのIPアドレスを使用するため、他のリージョンからもアクセスが可能です。VPC Latticeでのクロスリージョン通信について、 私たちは2つのオプションを強調したいと思います。1つは、既に環境に導入されているレイヤー3の接続メカニズムを使用する方法、もう1つは、VPC Service Network EndpointsとPrivate Connectivityのクロスリージョンサポートという2つの新機能を最大限に活用して、ネイティブな構成要素を使用して異なるリージョン間のクライアントとサービス間でエンドツーエンドの通信を実現する方法です。
ここまでがアプリケーションとネットワーキングの話でした。次はZero Trustについて見ていきましょう。接続性には多くの側面があります。ここ数年、私たちはVPC同士の接続に本当に注力してきました。 私は特にVPC Latticeが大好きです - これは最新のサービスの1つで、アプリケーションやユーザーがアプリケーションに接続しやすくなっています。では、Zero TrustまたはAWS Verified Accessについて話しましょう。実は社内では「AVA」と呼んでいます - これは公式名称ではありませんが、皆さんもそう呼んでいただいて構いません。
AWS Verified Accessの考え方は、VPCは本質的に囲われた庭のようなものだということから始まります。その囲われた庭へのアクセスを許可する際、Security GroupsやNACLsは別として、その中のすべてにアクセスできるということを意味します。Verified Accessでは、VPC内のエンティティへのアクセスに関するポリシーコントロールを設定する機能を実現したいと考えました。従来、 Verified AccessはHTTPとHTTPSのエンドポイントをサポートしており、これらのエンドポイントへの接続に使用できました。基本的な構成は次のようになっています：右側にサブネットがあり、Access Groupと呼ばれるTarget Groupsを持つALBまたはNLBがあります。Verified Accessは、内部VPCサービスにアクセスするためのフロントエンドまたはパブリックフェイシングサービスです。また、デバイスポスチャーやセキュリティポリシーコントロール、セキュリティパートナーとの統合も行います。AWS WAFも組み込まれています。ユーザーはパブリックインターネットからアクセスし、AVAを通じてセキュリティポリシーチェックを受け、その後HTTPおよびHTTPSアプリケーションにアクセスできるようになります。
現在、非HTTP/Sアプリケーション向けのプレビューを提供しています。 基本的な考え方は、HTTPプロトコルを使用しないフロントエンドではないアプリケーションへのアクセスにもAWS Verified Accessを使用できるようにすることです。それでは、具体的にどのようなものか見ていきましょう。
私たちは、AWS Verified Accessを一時的なリソースへのアクセスに使用する必要があるユーザー向けにこれを実装したいと考えていました。VPC内のホストにSSH接続する場合、Bastionホストを使用することができ、実際に多くの人々が長年Bastionホストを使用してきました。しかし、AWS Verified Accessを使えば、BastionホストやVPC内のCIDRレンジ内にある一時的なエンティティに接続することが可能になります。
基本的には、TCPエンドポイントを持つAmazon VPCがこのような形になります。 例えば、RDSなどの場合や、VPC内に割り当てたCIDRレンジがある場合です。そのCIDRレンジ内にSSHエンドポイントなどのサービスを追加すると、自動的に検出してエンドポイントとして追加されます。これにより、AWS Verified Accessを使用してそれらのサービスに接続できるようになりました。 以前はHTTPSのみでしたが、現在ではTCPや一時的なサービスもパブリックインターネット経由でサポートされています。
AWSネットワークのObservability向上：各種モニタリングツールの紹介
ここで考慮すべき点がいくつかあります。VPC内のリソースにVPNなしでアクセスできるようにするというのが全体的なアイデアでしたが、AWS Verified Accessはその機能を確実に実現しました。では次に、エッジについて見ていきましょう。 エッジとCloudFrontについては丸々1セッション使えるほどの内容があります。それだけそれらのチームが非常に忙しく活動してきたということですね。 CloudFrontチームは今年、いくつかの異なる機能に取り組んできました。時間が限られているので、簡単に列挙するだけにしましょう：Private VPC Origins、CloudFrontのAnycast IPのサポート、Embedded POP、そしてgRPCのサポートです。
Private VPC Originsについては、お客様から長年要望をいただいていた機能です。CloudFrontを使用する際、オリジンとしてパブリックエンドポイントがあり、人々がCDNをバイパスしようとしてそのオリジンにアクセスを試みる可能性がありました。S3などを使用している場合は、そのエンドポイントをロックダウンすることができます。しかし今では、Private Originsを使用することで、パブリックにアクセス可能ではないVPC内のエンドポイントを持ち、CloudFrontからそこにアクセスすることができます。また、Global Acceleratorと同様に、静的なAnycast IPを取得できるCloudFrontのAnycast IPもサポートしています。
現在、約600のEmbedded POPを含む、約1,700のCloudFront POPがあります。Embedded POPとは、従来のCloudFront POPを小型化し、プロバイダーのネットワークのラストマイルに組み込むことで、エンドユーザーにできるだけ近い場所に配置したものです。Embedded POPは従来のPOPよりもはるかに速くデプロイでき、ユーザーにより近い場所に設置することができます。また、APIエンドポイントがgRPCを使用している場合でも、CloudFrontを利用できるようgRPCもサポートしています。
次は、AWSでお客様とお話をする際によく出てくるトピックについてお話しします。それは、Observabilityです。これは、VPC内で実行されているものや、VPC内のトラフィックの可視化に関するものです。最近、この分野で多くの取り組みを行っており、お客様が行っていることの1つとして、EC2インスタンスを使用したインスタンスベースのモニタリングと、ENIアダプターで開発したEthtoolというツールの使用があります。
Ethtoolは、EC2インスタンスインターフェースで発生しているリソース制限の超過に関する詳細を提供します。EC2インスタンスには、PPSつまり1秒あたりのパケット数のスループットなど、さまざまな制限やリソースが適用されています。Ethtoolを使用すると、このインスタンスでPPS制限を超過しているかどうかを確認できます。 ここでEthtoolのコンソール出力を簡単にお見せします。ご覧のように、大量のConntrack許容値が利用可能な状態になっています。このインスタンスでは特に何も起動していませんが、Ethtoolの出力がどのように見えるかをお示ししたかったのです。
多くの方々が、Ethtoolからの出力をPrometheus Agentなどを通じてGrafanaに転送しています。ダッシュボードでインスタンスレベルの統計情報を取得し、単一の管理画面を構築しようとしており、Ethtoolがそれを大きくサポートしています。私たちは、Ethtoolの将来的な可能性についても検討を進めています。
また、インフラストラクチャのパフォーマンスについても見ていきましょう。私たちが受けたフィードバックの1つに、Availability Zone間のレイテンシーを判断するためにインフラストラクチャ上でエージェントを実行する必要があるという点がありました。 実際のところ、Availability Zoneは互いに等距離にあるわけではありません。このような状況で、複数のAZにまたがってアプリケーションを実行している場合、レイテンシーが増加する可能性があります。
この問題に対処するために、 アプリケーションをどこにデプロイすべきかを知る必要があるかもしれません。Infrastructure PerformanceはNetwork Manager内にあり、 左側のInfrastructure Performanceに移動すると、すべてのAvailability ZoneとRegionのレイテンシーの状況を確認できます。ここで簡単に見てみましょう。 下部には実際のレイテンシーの履歴が表示されています。これは非常に便利な機能で、レイテンシーを確認するためにインスタンスを起動する必要がありません。 この機能は以前からありましたが、最近お話しした方々があまり使用していないようでしたので、ここで特に言及する価値があると思いました。
また、約1年前にリリースされた CloudWatch Internet Monitor には、いくつかの新機能が追加されています。インターネット障害マップ、クロスアカウントサポート、そして Network Load Balancer と Application Load Balancer のワンクリック統合です。簡単にプレビューをお見せしますと、左側の CloudWatch の下に 新しいサービスがあり、これについては時間があれば後ほど説明させていただきます。 ここでは、発生中のインターネット障害やインターネットの状況マップを確認できます。特定の場所にいて、その地域で発生している特定のイベントに関心がある場合、モニターを設定することができます。
今年1月頃にリリースされた Network Monitor に移りましょう。これはハイブリッドネットワークに焦点を当てています。CloudWatch Network Monitor を通じてモニターを設定し、ターゲットエンドポイントを指定することができます。ここでは一連のプローブを設定します。左側に小さなピークアイコンが表示されているのがお分かりいただけると思いますが、ハイブリッド環境のターゲットエンドポイントを監視します。 これにより、Direct Connect を経由するトラフィックの状況についてフィードバックを得ることができます。ここでは冗長化された Direct Connect の構成とその考慮事項について示しています。そのため、 これは資料としてお持ち帰りいただけます。
時間が迫ってきましたので、まとめに入らせていただきます。最後に、 つい最近リリースされた CloudWatch Flow Monitor についてお話しします。これは私が心待ちにしていた非常に優れた機能です。 Amazon Linux に Flow Monitor エージェントをパッケージとして組み込むか、バイナリとしてデプロイすることができ、トラフィックの統計情報を収集します。 このエージェントを通過するトラフィックを EBPF スタイルの技術を使用して実際に監視し、Amazon Cloud にエクスポートします。これにより、 EC2 インスタンス上のトラフィックが通過するパスのネットワーク状態について、詳細な情報が得られます。
これは VPC 内の EC2 インスタンス間だけでなく、 Transit Gateway のようなサービスも対象となります。Network Flow Monitor を使用することで、Transit Gateway 内で実際に稼働しているエンティティのネットワーク状態を報告し、 Transit Gateway サービスに問題があるかどうかを特定することができます。ぜひこの機能をチェックしていただければと思います。
2024年のAWSネットワーキング機能まとめと締めくくり
最後のまとめに入りましょう。たくさんの内容でしたね。2023年12月にここからスタートし、2024年を通じて、 みなさまからご要望いただいた多くの機能をリリースしてきました。IPv6から始まり、現在では EC2 Instance Connect での IPv6 接続、Security Group の関連付け、VPC Block Public Access、 Transit Gateway の Security Group 参照、Cloud WAN、Direct Connect サポート、サービス挿入、Application Load Balancer、Network Load Balancer、 そして API Gateway の機能が利用可能になっています。PrivateLink 向けの VPC リソース、UDP サポート、クロスリージョンサポートを追加し、 VPC Lattice については、ECS および Fargate との統合、TLS リスナー、サービスネットワークエンドポイント、 そして VPC リソースのサポートを追加しました。
まさに目まぐるしい展開でしたね。この約60分で、Connectivityに関する全ての章について、これらの機能を網羅してきました。そして最後にObservabilityで締めくくりました。これが2024年12月時点での私たちの現状です。2025年12月が今から本当に楽しみですね。本当にありがとうございました。皆さんが写真を撮るのをお好きなのは存じ上げています。このセッションでのアーキテクチャ図について多くの方からリクエストをいただいていたので、Mattが素晴らしいアイデアを出してくれました。Security Codeとスライドの要約版を持ち帰っていただけるようにしたのです。本日は最後までご参加いただき、誠にありがとうございました。素晴らしいre:Inventをお過ごしください。また来年お会いしましょう。本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion