re:Invent 2024: AWSのCloud WANとVPC Latticeで実現する安全なグローバル接続
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Build scalable, secure, global connectivity with AWS (NET311)
この動画では、AWS Cloud WANを中心としたグローバルネットワークの構築方法について詳しく解説しています。Cloud WANのService Insertionによる集中型の検査アーキテクチャや、Direct Connect Native Attachmentによるハイブリッド接続の簡素化など、最新の機能を具体的に紹介しています。また、VPC Latticeを活用したZero Trustのサービス間通信や、AWS Verified Accessによるクライアント・サービス間通信など、アプリケーションレベルのネットワーキングについても説明しています。Werner Vogelsが提唱する「複雑な要件に対応できるシンプルなシステム」という考え方に基づき、AWSのグローバルインフラストラクチャを活用した実践的なネットワーク設計のアプローチを示しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Cloud WANの概要と進化するネットワーキング
みなさん、こんにちは。re:Inventの4日目にお越しいただき、ありがとうございます。多くの方が列に並んでいらっしゃるのを拝見しました。本日のセッションでも、この熱意を持続させていきましょう。今日は、Amazon Bedrockと大規模言語モデルの活用方法についてお話しする...なんて冗談です。私はSidhartha（Sid）Chauhanで、本日はScott Morrisonと共に、大規模言語モデルの魔法から少し離れて、頭をリフレッシュする時間を持ちたいと思います。正直なところ、ベストプラクティスやこれから話すシナリオを含めて、グローバルネットワークを大規模に構築するようにLLMを学習させる方法は、まだ見つけられていません。
そこで、今日は少し昔ながらのやり方で、ネットワークアーキテクトやエンジニアとしてのコアなネットワーキングの概念についてお話ししましょう。ITインフラの管理がオンプレミスのネットワークだけを扱えば良かった時代を覚えていますか？そしてクラウドが登場し、柔軟性とスケーラビリティの約束とともに、 ハイブリッドネットワーキングの時代に突入しました。実は私は過去8年間、ハイブリッドネットワーキングのセッションを行ってきました。それほど重要なトピックなのです。しかし、グローバル経済とモバイルファーストユーザーの台頭により、アプリケーションはもはや1つのAWSリージョンだけでは済まなくなってきています。 アプリケーションを異なるAWSリージョンにスケールアップするにつれて、ネットワーク接続も進化する必要があります。
これを大規模に実現することは難しく、管理も困難です。本日のキーノートで、Werner Vogelsは非常に興味深い概念を提示しました。複雑な要件に対応できるシンプルなシステム、シンプルなアーキテクチャを構築するという考え方です。そのようなアプローチの1つが、 AWSのグローバルインフラストラクチャとソフトウェア定義サービスであるAWS Cloud WANを中心に据えることです。Cloud WANはネットワークの頭脳として機能します。Wernerはまた、複雑さは作り出すことも破壊することもできず、ただ一つの場所から別の場所に移転できるだけだと述べました - 魅力的な概念ですね。私たちは、ネットワークから複雑さを取り除き、それをAWSに任せることで、差別化されない重労働を私たちが担当したいと考えています。
新しいネイティブのCloud WAN to Direct Connect統合を使用して、オンプレミスのデータセンターをAWSに接続できます。リモートユーザーやリモートオフィスには、Site-to-Site VPN、Client VPN、あるいはVPNを使用しないAWS Verified Accessを利用できます。これらのトピックについては、本日Scottが詳しく説明します。このハイブリッド接続を設定する際には、厳格なセキュリティと検査の要件があります。ここでトラフィック検査が重要になってきます。これはハイブリッド接続だけでなく、 リージョン間のアプリケーション間接続、 さらには同一リージョン内でも、Cloud WANのサービスインサーションで非常にシンプルに実現できます。
Cloud WANはエッジにおけるネットワークの中核です。多くの方が特殊なアプリケーションネットワーキングの要件をお持ちでしょう。Zero Trustのサービス間通信、クライアント・サービス間通信、そしてオンデマンドでトラフィックをシフトさせたいトラフィック管理などです。これらの要件に対しては、VPC LatticeとPrivateLinkがあり、これらのサービスに対する機能強化も行っています。これについても、Scottが彼のパートで説明します。それでは、 Cloud WANについて話し始めましょう。
AWS Cloud WANの基本構成とルーティング
では、手を挙げていただきたいのですが、現在Cloud WANをご利用の方は何人いらっしゃいますか？はい、あまり多くないようですね。そこで、より高度な概念に入る前に、AWS Cloud WANについて簡単におさらいしたいと思います。まず、Core Networkの作成から始めます。これは、サービスによってお客様に代わって管理されるAWSのネットワークコンポーネントをすべて含む上位レベルの構成要素です。Cloud WANでの操作はすべてネットワークポリシーを通じて行われます。最初に、Core Networkを拡張したいAWSリージョンを指定してネットワークポリシーを定義します。ここでは3つのリージョンで実施しています。
このポリシーを実行すると、Cloud WANはCore Network Edges（CNEs）を作成します。これは、すべての接続に対応する、リージョナルで可用性が高く、高い回復力を持つリージョナルエンドポイントです。CNEは相互に完全メッシュ化されており、eBGPピアリングを通じてルートとトラフィックを交換します。次に、Cloud WANにおいて重要な要素であるセグメントを作成します。これはグローバルに分離されたルーティング境界です。ここでは、Production、Development、Hybridという3つのセグメントを作成するネットワークポリシーを定義します。実際、Hybridセグメントは2つのリージョンにのみ拡張しています。デフォルトでは、セグメント内でエンドツーエンドのグローバルな到達性が確保されますが、これを逆にすることも可能です。
セグメント内のこのグローバルな到達性は、isolate attachmentsフラグを使用して制御できます。これをtrueに設定すると、そのセグメントに接続・関連付けられたすべてのネットワークが相互に通信できなくなります。次に、アタッチメントについてですが、VPCをAWS Cloud WANに接続するにはVPCアタッチメントを使用します。これは可用性が高くスケーラブルな完全マネージド型の接続ソリューションです。SD-WAN接続については、GREトンネルを使用して接続できます。また、最近発表したtunnel-less connectでは、SD-WANアプライアンスがGREトンネルを必要とせずにCloud WAN CNEsとルートを交換できるようになりました。
Transit GatewayをAWS Cloud WANに接続することができ、さらに強力な機能として、個々のルートテーブルをCloud WANセグメントに関連付け、Transit GatewayのルートテーブルとCloud WANのセグメント間でBGPダイナミックルーティングを設定することができます。ハイブリッド接続については、Direct Connect ネイティブアタッチメントがあり、本日はその仕組みについて説明する時間を設けています。また、Site-to-Site VPNもサポートしています。これらが、AWS Cloud WANでサポートしている異なるネイティブアタッチメントです。これらのアタッチメントを作成しても、まだセグメントには関連付けられていません。そのためには、アタッチメントポリシーを作成する必要があります。これには複数の方法がありますが、私のお気に入りはタグを使用する方法です。
このポリシーでは、Cloud WANがアタッチメントのタグを確認し、タグの値とセグメントの名前を照合して、そのアタッチメントをセグメントに関連付けます。この単一のポリシーで、何千ものアタッチメントをセグメントに関連付けることができます。しかし、こんな疑問をお持ちかもしれません：誰かが間違ってアタッチメントにタグを付け、開発用のVPCを本番セグメントに関連付けてしまったらどうなるのか？そのために、require attachment acceptanceというフラグがあり、これをtrueに設定すると、人による承認ステップが追加されます。これはセグメントレベルで設定できるので、本番セグメントではアタッチメントの関連付けに人による承認を必要とし、開発やテスト環境では、Cloud WANがタグに基づいて自動的に関連付けを行うように指定できます。
アソシエーションを完了したことで、リージョン間のProd同士は通信できるようになりましたが、セグメント間のトラフィックのルーティングはまだできません。つまり、ProdはDevと通信できず、HybridはProdやDev環境と通信できない状態です。このようなトラフィックフローを有効にしたい場合は、セグメントルートを共有する別のポリシーを作成する必要があります。ここでは、Hybridセグメントを開発環境と本番環境のセグメントと共有します。これを行うと、Hybrid Work トラフィックフローが有効になります。以上が、AWS Cloud WANのセットアップ方法の簡単な復習でした。
Cloud WAN Service Insertionによるトラフィック検査
しかし、これらのグローバルネットワークのセットアップと構築は第一段階に過ぎません。それらを安全に保ち、コンプライアンスに準拠させることが非常に重要です。そこで活用されるのがCloud WAN Service Insertionです。AWS Cloud WAN Service Insertionを使用することで、集中型の検査アーキテクチャの展開が非常にシンプルになります。静的ルートを作成する制約からも解放されます。必要なのは、トラフィックをどのように検査したいかをCloud WANに指示する、シンプルなネットワークポリシーを記述することだけです。Cloud WANはそれを理解し、実現に必要なすべての設定を行います。その結果、スケーラブルなコンプライアント・ネットワークを構築することができます。
Service Insertionを機能させるために、Network Functions Group（NFG）という新しいコンセプトを導入しました。これは先ほど見たCloud WANセグメントに似ていますが、ファイアウォールやセキュリティインフラストラクチャに接続するために特別に設計されています。すべてが管理されていますが、バックグラウンドのルートについても完全な可視性が得られます。次のスライドでいくつかの例を説明します。それぞれの例で、ネットワークポリシーとその目的を示し、さらにCloud WANが裏側で行う処理、つまり作成される具体的なルートと自動化の仕組みについても説明します。ここでは、2つのセグメントを持つ2つのAWS Cloud WANリージョンがあります。
まずは開発セグメントに焦点を当ててみましょう。任意のリージョンにおいて、1つのリージョナル開発ルートテーブルには、ローカルに接続されたVPCとして172.16が、そしてリージョン2のCNE2を経由して1ホップ先に172.17があります。同様にリージョン2では、172.17が直接接続され、172.16が1ホップ先にあります。
次にNetwork Functions Groupを作成し、検査用VPCをNFGに接続します。そして、シンプルなポリシーを記述します。ここで実現しようとしているのは、セグメント、特に開発セグメントからの出力トラフィックを検査することです。このポリシーは、開発セグメントから出るすべてのトラフィックをNFG1に送信するように指定します。このポリシーを記述すると、Cloud WANはルートテーブルにデフォルトルートを挿入します。リージョン1では、デフォルトルートがローカルの検査用VPCであるVPC Inspection 1を指し、リージョン2では、デフォルトルートがそのリージョンのローカル検査用VPCであるVPC Inspection 2を指すようになっているのが確認できます。
VPCからインターネットへのEgressトラフィックを開始すると、そのトラフィックはDevelopmentセグメントに入り、デフォルトルートにマッチします。トラフィックはNetwork Firewallに送られ、そこからInternet Gatewayへと転送されます。Internet Gatewayはレスポンスの検査のためにパケットをNetwork Firewallに送り返し、その後、DevelopmentのVPCルートが設定されているNetwork Functions Groupに到達します。これにより、すべての集中管理されたトラフィックをグローバルに検査することが可能になります。
次に、このポリシーを作成することの利点が分かる別のシナリオを見てみましょう。US East 2リージョンにグローバルプレゼンスを拡大する場合で、このリージョンにInspection VPCがない場合、リージョン2のDevelopmentルートテーブルには、他のDevelopment VPCに到達するためのCNE1とCNE2経由のルートがあります。同じポリシーを作成します：Developmentセグメントから出るすべてのトラフィックをNetwork Functions Group 1に送ります。リージョン2には独自のInspection VPCがないため、CNE2からの距離が等しいInspection VPC 1またはInspection VPC 2のいずれかにトラフィックを送ることができます。
DevelopmentのVPCからインターネットに向かうトラフィックは、US West 2に向かうことになります。US East 2からのトラフィックは、最も遅延の少ない経路としてUS East 1を使用することが理想的ですが、Cloud WANはランダムに1つのリージョンを選択します。Edge Overridesポリシーを使用することで、使用したいリージョンを指定できます。US East 2の場合、エッジロケーションとしてUS East 1を使用するように指定することで、出口パスを確実に制御できます。これは以前は非常に困難で複数のルートテーブルが必要でしたが、現在は1つのポリシーで実現できます。
次に、Productionセグメントに同じポリシーを作成する別のシナリオを見てみましょう。これまでの例では、インターネットへのEgressトラフィックについて説明してきました。しかし、「Productionセグメントから出るすべてのトラフィック」というポリシーで「すべてのトラフィック」と言う場合、インターネットトラフィックだけでなく、他のセグメントへのトラフィックも含まれます。Development セグメントに向かうトラフィックの場合を考えてみましょう。パケットはProduction セグメントから開始され、デフォルトルートにマッチしてNetwork Firewallに送られます。Network Firewallが検査を行い、Network Functions Groupに送り返します。しかし、この時点でNetwork Functions GroupにはProductionのVPCルートしか設定されていないため、DevelopmentのVPCへのトラフィックの送り方が分からず、結果としてトラフィックはドロップされてしまいます。
ここで、もう1つポリシーを追加してみましょう。Developmentセグメント用のSend-toポリシーを作成すると、NFGにDevelopment VPCのルートも設定されます。同じトラフィックがProductionからDevelopmentに流れる場合、まずProductionセグメントに来て、そこからNetwork Firewallを経由し、Network Functions Groupに送られます。今度はNetwork Functions GroupにVPCへのルートが存在するため、トラフィックをルーティングできます。戻りのトラフィックも同じパスを通り、ProductionとDevelopment間でトラフィックをルーティングすることができます。
2つのセグメントにSend-toポリシーを使用すると、すべての出力トラフィックの検査を有効にするだけでなく、セグメント間トラフィックの検査も有効になります。これが意図的な設定であれば問題ありませんが、そうでない場合は、このような動作が発生することに注意が必要で、Firewallでそのトラフィックをドロップするように設定する必要があります。では、これがリージョン間で発生する場合について見ていきましょう。あるリージョンのProduction VPCから別のリージョンのDevelopment VPCへトラフィックが発生すると、そのトラフィックはProductionセグメントに向かい、デフォルトルートにマッチしてNetwork Firewallに送られます。その後、DevelopmentとProduction VPCのルートをすべて把握しているNetwork Function Groupに到達し、そこからクロスリージョンでDevelopment VPCにトラフィックが送られます。
Direct Connect Native Attachmentの導入と利点
リクエストはVPC Inspect oneで検査され、戻りトラフィックはDevelopmentセグメントに到達し、デフォルトルートにヒットして、リージョン2のFirewallを経由してNetwork Function Groupに返され、最終的にProduction VPCに戻ります。ここで注目すべき点は、リクエストは一方の検査用Firewallを通り、レスポンスは別の検査用Firewallを通ったということです。これにより、クロスリージョンの非対称検査が発生し、ステートフルなFirewallはそのトラフィックをドロップすることになります。セグメント間で本当に検査を行いたい場合は、異なるタイプのポリシーを実装する必要があります。
では、セグメント間のトラフィックを検査するポリシーについて説明しましょう。ポリシーの構造は、ProductionセグメントがDevelopmentにトラフィックを送信する際、NFG経由で送信するというものです。対称性を維持するために、2つのオプションがあります：Single Hopを指定すると、リクエストとレスポンスの両方が1つの検査用VPCで決定論的に検査され、Dual Hopでは、リクエストとレスポンスの両方が2つの検査用VPCで検査されます。モードを指定しない場合は、デフォルトでSingle Hopになります。
Dual Hopポリシーについて詳しく見ていきましょう。非常にシンプルで、ProductionからDevelopmentにトラフィックを送信する際、Dual Hop Network Function Groupを使用して送信するというものです。これらのポリシーは非常に直感的です。ProductionとDevelopment間のルーティングを行うため、CNE oneのProductionルートテーブルとCNE twoのDevelopmentルートテーブルを見てみましょう。このポリシーを実行すると、ProductionとDevelopmentセグメントのCloud WANは、クロスセグメントルートが同一リージョンの検査用VPCを指すようにエントリを追加します。そしてNFGについては、クロスリージョンルートがクロスリージョンの検査用VPCを指すようになります。
トラフィックはProduction VPCで発生し、同一リージョンの検査用VPCに送信するProductionセグメントに向かいます。トラフィックがNFGに到達し、これがクロスリージョンルートの場合、NFGロジックはそれをクロスリージョンの検査用VPCに送信します。検査が行われた後、Development VPCに送信されます。戻りトラフィックは同じルートを通ります。このポリシーにより二重検査が可能になります。次に、より興味深いSingle Hopモードについて見ていきましょう。
シングルホップでは、同一のルートテーブルにおいて、Cloud WANの自動化により、ローカルリージョンのクロスセグメントルートが、ローカルのインスペクションVPCをネクストホップとして指定されます。ルートが設定される様子が確認できます。Lはローカルリージョンのクロスセグメントを、Rはクロスリージョンのクロスセグメントルートを示しています。ネクストホップは選択されたインスペクションVPCとなります。Cloud WANはランダムに1つのVPCを選択し、そのVPCを選択されたインスペクションVPCとして、このクロスリージョントラフィックの検査を担当させます。このシナリオでは、Region-1のインスペクションVPCが選択されたインスペクションVPCとなり、それらのルートが設定されます。Network Function Groupは、開発環境と本番環境のすべてのVPCのルートを学習しますが、ここではNFGに関して特別な処理は発生しません。
パケットフローを見てみましょう。トラフィックはRegion-2の開発VPCから発生し、開発セグメントに送られ、クロスリージョンクロスセグメントを示すRのルートにマッチして、インスペクションVPC-1に送られます。ローカルのインスペクションVPCではなく、選択されたインスペクションVPCにトラフィックが送られ、その後本番環境に送られます。戻りのトラフィックも全く同じパスをたどります。ランダムに選択されるインスペクションVPCをコントロールできないのではないかと考える方も多いと思いますが、実際にはコントロールすることができます。
Edge Overridesの機能を使用すると、エッジセットに対して使用するエッジロケーションを指定できます。ここでは、us-east-1とus-west-2に対してエッジロケーションとしてus-west-2を使用するように指定しています。選択されたインスペクションVPCをRegion-1からRegion-2に変更すると、ルートが自動的に更新されます。これで、トラフィックが選択されたインスペクションVPCを経由してフローし、Region-1のインスペクションVPCは検査するパケットがない状態となります。
Direct Connect Gatewayのルーティング動作と最適化
以上が、Cloud WAN Service InsertionとPolicyを使用して、決定論的にトラフィック検査を実行する方法でした。次に、最新のアナウンスメントであるAWS Cloud WAN Direct Connect Native Attachmentについて説明します。Cloud WAN Native Direct Connect Attachmentにより、ハイブリッド接続アーキテクチャーが大幅に簡素化されます。オンプレミスデータセンターとAWS間のパスでTransit Gatewayを作成して使用する必要がなくなりました。また、特殊なハイブリッドセグメントアーキテクチャーも実現可能になります。
この新機能が発表される前は、Transit Gatewayのレイヤーを設定し、Direct Connect接続をDirect Connectロケーションに確立する必要がありました。そこから、Transit GatewayをDirect Connect Gatewayに接続し、さらにAWS Transit Gatewayへの接続を設定して、それをCloud WANに関連付ける必要がありました。Direct Connect GatewayからTransit Gateway、そしてCloud WAN CNEへの動的なルート伝播はありましたが、逆方向では、クォータ制限が200プレフィックスの静的ルートを設定する必要がありました。さらに、Transit Gatewayは経路上の余分なホップとなっていました。
新しいアナウンスにより、これらの手順は全て不要になりました。必要なのは、たった1回のAPI呼び出しで、Direct Connect gatewayに接続したいEdge locationとCNEを指定するだけです。そうすると、その接続はAWSによって完全に管理され、エンドツーエンドのBGPルーティングが提供されます。オンプレミスルーターからDirect Connect gatewayへのBGPルート交換が行われ、さらにDirect Connect gatewayからCNEへのBGPピアリングが確立されます。ただし、Cloud WANの基本的な原則は依然として適用されます。つまり、これらのVPCルートをProductionやDevelopmentのセグメントやVPCと共有したい場合は、HybridセグメントとProductionおよびDevelopmentセグメント間でルートを共有するためのポリシーを作成する必要があります。
このネイティブアタッチメントを設定した際のルート交換の仕組みを詳しく見ていきましょう。まずは、オンプレミスからAWSへの流れ、つまりDirect Connect gatewayからCNEまでの流れを見ていきます。Direct Connect gatewayは全てのTransit VIFルートを全てのCNEにアドバタイズします。
この構成では、3つのオンプレミスデータセンターが192.168.1.0/24、192.168.2.0/24、192.168.3.0/24をアドバタイズしています。Direct Connect gatewayはこれらのルートを学習し、192.168.1.0/24、192.168.2.0/24、192.168.3.0/24を全てのCNEにアドバタイズします。自動的なサマライゼーションは行われません - アドバタイズしたものがそのままCloud WANに送信されます。CNEはフルメッシュで相互に通信を行うため、これらのルートを互いに交換します。
AWSからオンプレミスへの方向では、CNEは接続されているローカルネットワークのみをアドバタイズします。ここでご覧のように、CNE oneは10.1.0.1のみを、CNE twoは10.2.0.1のみを、CNE threeは10.3.0.1のみをアドバタイズします。リモートリージョンのルートはアドバタイズしません。つまり、CNE oneは技術的にはUS East 1やUS West 1、EU West 1へのパスを持っているにもかかわらず、Direct Connect gatewayにそれを通知することはありません。これが重要な理由については後ほど説明します。また、Direct Connect以外のアタッチメントに対してスタティックルートが設定されている場合、それらも同様にアドバタイズされますが、この例では明示的には示していません。
このようなルーティング動作を実装している理由は、オンプレミスのトラフィックのグローバルルーティングをDirect Connectのデータプレーンだけで処理するためです。例を使って説明しましょう。Dublinのオンプレミスデータセンターから発信されたトラフィックがUS Westに向かう場合、つまり大陸間を横断する場合、トラフィックは最寄りのDirect Connect locationを経由してDirect Connect gatewayに送られます。そこから、Direct Connect gatewayがトラフィックをCNEを経由してUS West 2のVPCにルーティングします。トラフィックはEU West 1のCNEにはルーティングされず、Cloud WANのデータプレーンは使用されません。
同様に、戻りのトラフィックはCNE 1に送られます。CNE 1はそのトラフィックをDirect Connect Gatewayに直接送信するか、あるいはデータプレーンを通じてCNE 3に送り、そこから下に送ることができますが、CNE 1はCloud WANのデータパスを使用せず、Direct Connect Gatewayに直接送信します。これは重要なポイントです。なぜなら、本日のKeynoteでも触れましたが、セルベースのアーキテクチャによる障害分離境界と回復性について議論したからです。ハイブリッドトラフィックについては、リージョンの依存関係を持たせたくありません。US Westからオンプレミスのデータセンターにトラフィックを送信する場合、US East 1やEU West 1といったリージョンに依存すべきではありません。これらのリージョンは独立した障害分離境界として機能すべきであり、私たちはこの原則に従っています。
次に、データセンターからデフォルトルートや集約ルートをアドバタイズするシナリオを見てみましょう。データセンターには192.168.1.0/24、192.168.2.0/24、192.168.3.0/24が存在しますが、すべてのDirect Connect接続ポイントを通じて集約ルート192.168.0.0/16をアドバタイズしているとします。これは非常によくあるシナリオで、特にMPLSやサービスプロバイダーを使用している場合、通常はデフォルトルートや集約ルートをアドバタイズします。US West 2 VPCからDublinのオンプレミスデータセンター宛てのトラフィックが発生した場合、トラフィックはCNEに到達し、自動的にDirect Connect Gatewayに送信されます。
Direct Connect Gatewayには3つのルートがあります - Seattle、Northern Virginia、Dublinのいずれかにトラフィックを送信できます。これは同じプレフィックスを3つの場所すべてから受け取っているためです。では、どこに送信されるのでしょうか？ドキュメントを見ると、各Direct Connect接続ポイントには関連付けられたリージョンがあり、接続ポイントとリージョンの間にはアフィニティが存在することがわかります。このアフィニティは重要で、ルーティングの決定は常にこのアフィニティを優先します。US West Oregon（US West 2）の場合、SeattleのDirect Connect接続ポイントが関連付けられており、アフィニティを持っているため、トラフィックはSeattle経由で送信されます。
複数のDirect Connect Gatewayを活用したカスタムルーティング
では、障害が発生してSeattleの接続ポイントが利用できなくなった場合、あるいはそもそも存在しない場合はどうなるでしょうか？
トラフィックの流れを見てみましょう。トラフィックはDirect Connect Gatewayに戻り、その後ロードバランスされます。US West 2から発信されたトラフィックは、Northern VirginiaとDublinのDirect Connect接続ポイントの間でロードバランスされるようになります。ホームまたはアフィニティベースのDirect Connect接続ポイントが利用できない場合、トラフィックはロードバランスされます。しかし、US WestからDublinのデータセンターにトラフィックを送信することは、大陸間を横断することになり、レイテンシーが高くなるため合理的ではありません。その代わりに、Northern Virginia経由でのルーティングが望ましいでしょう。
良いことに、Local PreferenceをオーバーライドするためのBGP Communityを設定することができます。これにより、Direct Connect Gateway上のすべてのトラフィックがNorthern Virginia拠点を優先するようになります。しかし、まだ問題は解決していません。なぜなら、EU West 1から発信されるトラフィックもNorthern Virginiaに送られてしまうからです。私たちが望んでいたのは、EUのトラフィックがDublinを経由することでした。つまり、US Westは最寄りの拠点を優先し、障害時にはNorthern Virginiaを使用する一方で、EU West 1はDublinを優先するという構成が必要なのです。
Direct Connect Gatewayは単一のルーティングエンティティであるため、異なるルーティング設定を1つのGatewayで実現することはできません。この問題を解決するために、複数のDirect Connect Gatewayを作成します。各Direct Connect Gatewayは独自のルーティング動作を持つことができるためです。複数のDirect Connect Gatewayを作成することで、独自のルーティング動作を設定し、このカスタムルーティングロジックを適用したいCore Network Edgeにそれらを接続・関連付けることができます。私のシナリオでは、リージョンごとに1つのDirect Connect Gatewayを用意し、それぞれのリージョンのCore Network Edgeに関連付けて接続します。
Core Network EdgeはそのリージョンのルートのみをDirect Connect Gatewayにアドバタイズします。グローバルな接続を実現するために、Direct Connect拠点から全てのDirect Connect Gatewayへのバーチャルインターフェースを設定する必要があります。EUリージョンに関連付けられたDirect Connect Gateway 3に対して作成するバーチャルインターフェースでは、BGP Communityを使用して、Dublinデータセンターを第一優先、Virginiaを第二優先、Seattleを最終オプションとして設定します。同様に、US East 1に接続されているDirect Connect Gateway 2へのバーチャルインターフェースでは、Northern Virginiaを第一優先、Seattleを第二優先、Dublinを第三優先とします。Direct Connect Gateway 1のルーティング動作についても同様の設定を行います。
このネイティブ統合によって実現される素晴らしい機能がもう1つあります。それはエンドツーエンドのセグメンテーションです。ここでは、クラウド上にProductionとDevelopmentのセグメントがあり、オンプレミスにもProductionとDevelopmentのラックとスイッチがあります。オンプレミス環境では、DevelopmentとProductionのセグメントが異なる独立したVLANに分かれており、それぞれが分離されたVRFを持つルーターに接続されていることを想定しています。
オンプレミスからAWSへのセグメンテーションを拡張するために、 Production専用のDirect Connect Gatewayを作成し、オンプレミスのProduction VRFから、このDirect Connect Gatewayへ専用のVLANを使用したTransit Virtual Interfaceを設定します。このDirect Connect GatewayはProductionセグメントにのみ関連付けられます。 オンプレミスのProductionルートをアドバタイズし、AWS側からはProduction VPCのルートのみを学習します。
同じプロセスを繰り返して、開発用のDirect Connect Gatewayを作成し、ルーターから開発用VRFをVLANに設定し、このDirect Connect Gatewayを開発セグメントに関連付けます。 開発用のルートをアドバタイズし、開発セグメントのルートを学習します。 基本的に、オンプレミスのVLANからオンプレミスルーターのVRFへと拡張し、それがTransit Virtual Interface VLANを経由して固有のDirect Connect Gatewayまで拡張され、 クラウドセグメントに関連付けられ、ルートテーブルに接続されます。これで、オンプレミスからAWSまでのトラフィックのエンドツーエンドのセグメント分離が実現できました。では、セグメント化されたDirect Connectと一緒に動作別のDirect Connectを実装したい場合はどうでしょうか？
その場合は、複数のDirect Connect Gatewayを作成することになります。 ただし、注意すべき制限があります。Direct Connect接続ごとに作成できるTransit VIFは4つまでで、このシナリオではすでにその制限に達しています。このデザインを慎重な検討なしに実装することは避けてください。具体的な要件がある場合にのみ進めるべきです。このような高度なシナリオに取り組む際は、クォータに注意を払う必要があります - 増やせるものもありますが、ハードリミットのものもあります。
さて、 Transit Gatewayを取り除いてネイティブのDirect Connect接続を実装することのメリットがお分かりいただけたと思います。では、すでに設定済みの環境からの移行はどうすればよいでしょうか？ここでは、すでにDirect Connect GatewayがCloud WAN Transit Gatewayに接続されているセットアップがあります。このシナリオでは、オンプレミスルーターが受け取るルートは単一のASNを持ちます。これは、Direct Connect Gatewayが背後のすべてのASNを隠し、自身のASNで上書きするためです。Core Network Edgeがオンプレミスルーターから受け取るルートは3つのASNを持ちます - Direct Connect GatewayのASN、Transit GatewayのASN、そしてオンプレミスルーターのASNです。
移行を開始する際は、別のDirect Connect Gatewayを作成し、そこに新しいTransit VIFを作成します。このDirect Connect GatewayをCloud WANのハイブリッドセグメントに関連付けます。 これを行うと、新しいパスでDirect Connect Gatewayからルートの受信が始まりますが、このルートは2つのASNを持ちます - Cloud WANのASNとDirect Connect GatewayのASNです。これは長いパスとなるため、ルーターがBGPのルールに従っている場合、新しく作成したパスではなく、中断することなく古いパスを使い続けます。
ルートのアドバタイズを開始すると、 新しいパス経由でCloud WANが受け取るルートには2つのASNしかありません - Transit GatewayのASNは含まれません。そのため、Cloud WANは新しいパス経由でリターントラフィックのルーティングを開始します。これに注意する必要があるため、 テストルートから始めましょう。テストルート用のリターントラフィックが新しいパス経由で送信されるように、一部のテストルートのみをアドバタイズします。検証とテストを行い、 オンプレミス側でLocal Preferenceを使用して、短いパスよりもこのパスを優先するようにします。すべてが正常に動作することを確認したら、 メンテナンスウィンドウを取得して移行を実行します。すべてが正常に動作している場合、VIFをシャットダウンするか、Transit Gatewayからの関連付けを解除するだけです - 古いパスを中断する方法は複数あります。これを行うと、ルーティングが更新されます。
今お話しした内容についてさらに詳しく知りたい方は、ぜひブログのお知らせをご覧いただくことをお勧めします。さて、現在Cloud WANをお使いでない方は、Transit Gatewayから Cloud WANへの移行を検討されているのではないでしょうか。本日のセッションでは移行戦略については触れませんが、これについては昨年のセッションで詳しく説明しています。Transit GatewayをCloud WANに接続し、ネットワークを一つずつ移行する方法について説明したセッションがありますので、ぜひご確認ください。とてもシンプルで分かりやすい内容となっています。AWSでグローバルネットワークを構築される場合は、AWS Cloud WANの使用をお勧めしています。
VPNとAWS Verified Accessによるリモートアクセス
次は、AWS VPNと特殊なネットワーク接続要件についてお話ししますが、ここからはScottにバトンタッチしたいと思います。先ほどCloud WANとDirect Connectの統合についてお話ししましたが、このローンチは多くのお客様にとって物事をシンプルにしたという点で、私も非常に嬉しく思っています。ただ、Direct Connectの予測可能なパフォーマンスや高スループットが必要ない場合や、Direct Connectの利用が物理的に難しい場所にいる場合はどうすればよいでしょうか？AWS Site-to-Site VPNを使用すれば、セキュアなIPsecトンネルを介してインターネット経由でCloud WANに接続できます。各トンネルは、その地域のCore Network Edgeに直接接続されます。VPN接続は各リージョンで作成され、冗長性のために各リージョンでオンプレミス環境へのトンネルを設定します。ここでご覧いただけるように、それぞれのオンプレミス環境が複数のリージョンに接続されています。
このように構成することで、特定のリージョンで問題が発生した場合でも、別のリージョンにフェイルオーバーして接続を継続できます。これらのVPNトンネル内では、Direct Connectと同様にCloud WANセグメントとのBGPピアリングが確立され、ルート情報を交換することができます。
では、リモートクライアントについてはどうでしょうか？ネットワークにアクセスする必要のある開発者や、企業ネットワークにアクセスする必要のあるリモートワーカー、その他同様のユースケースについてはどうすればよいでしょうか？AWS Client VPNを使用すれば、VPCへのクライアントVPNを設定できます。Multi-Factor Authenticationを有効にし、VPCに接続した後は、Cloud WANを通じて他のVPCへ、VPC Peeringを通じて、Site-to-Site VPNやDirect Connectを使用してオンプレミスへ、そしてインターネットや他のAWSサービスへ接続することができます。
現代では、Client VPNやVPN接続が必ずしも必要というわけではありません。そのようなユースケースでは、AWS Verified Accessを使用できます。Verified Accessを使用すると、VPNなしでアプリケーションに接続できます。HTTPとHTTPSエンドポイントだけでなく、TCPエンドポイントの使用、ポリシーの作成、アクセスレコードの確認が可能で、さらにTrust Provider、Identity Provider、エンドポイントデバイス管理プロバイダーなどと接続することができます。
きめ細かな動的な認可識別を提供します。すべてのリクエストが認証されるため、権限に変更を加えた場合、次のリクエストからその変更に基づいて承認または拒否されます。可視性が向上し、パートナー企業が提供するような既存のセキュリティサービスを活用できます。 VPNへの接続が不要となり、ユーザーは複雑な設定に悩まされることがなくなります。VPNのレイヤー3アクセス制御では得られない、レイヤー7レベルでのきめ細かな制御が可能になります。AWS Verified Accessには、Jamf、CrowdStrike、JumpCloudなどのサードパーティプロバイダーが統合されており、すぐに利用することができます。
VPC LatticeとPrivateLinkによるサービス間連携の実現
AWSにおけるサービス間連携についてはどうでしょうか？私たちは、IPやポート、プロトコルに基づくレイヤー3やレイヤー4のアクセス制御の世界から、アプリケーションレベルのネットワーキングである、アイデンティティベースのアクセス制御レイヤー7へと進化してきました。そこで登場するのがVPC Latticeです。VPC Latticeを使用することで、 Zero Trustの接続性とアプリケーション制御を実現できます。ここでご覧のように、サービスチームAとサービスチームBがHTTPやTCPを使用して相互に接続する必要があります。
VPC Latticeのサービスネットワークを作成し、両方のVPCに接続します。これは完全マネージド型のデータプレーン と完全マネージド型のコントロールプレーンです。トラフィック制御やルーティング制御などを実行することができます。 ロードバランス制御や、どのサービスがどのサービスにアクセスできるかというアイデンティティベースのアクセス制御を実装できます。組織全体のサービスネットワークに対してネットワークベースのポリシーを作成したり、個々のサービスに対してサービスベースのポリシーを作成したりできます。これらの2つのポリシーを組み合わせることで、非常にきめ細かなアクセス制御を実現できます。
この詳細なアクセス制御がどのようなものか見てみましょう。VPC Latticeサービスネットワークへの接続があり、 Billingサービス、Parkingサービス、Inventoryサービスがあります。Latticeポリシーを作成し、Billing はInventoryと通信できないが、Parkingとは通信できるように設定しました。
シームレスに動作します。ポリシーを設定するだけで済むのです。VPC Latticeが処理してくれるため、IPアドレッシングやオーバーラップについて心配する必要はありません。DNSネームを使用してリンクローカルアドレスでサービスネットワークに接続するだけで、サービスネットワークへのすべてのリクエストを認証・承認します。
マルチリージョンのアーキテクチャについて、AWS Cloud WANを含めて考えてみましょう。VPC Latticeはこの場合どのように機能するのでしょうか？ここでは、Region 1にVPC 1とVPC 2があり、Region 2にも別のVPCがある構成を見ていきます。Region 1では、 サービスが直接サービスネットワークを通じて接続されており、非常にシンプルで設定も簡単です。そして、VPC 1はCloud WANに接続されており、Region 2のサービスネットワークに接続する必要があります。
今週、AWS PrivateLinkを活用したサービスネットワークエンドポイントを導入しました。Region 2のVPCにPrivateLinkエンドポイントを作成し、サービスネットワークへの接続を許可します。その後、Region 1からCloud WANを経由してRegion 2のサービスネットワークエンドポイントにリクエストを送信します。リクエストはサービスネットワークに入り、ローカルのサービスネットワークと同じように通信が行われます。これはオンプレミスからも同様に実行できます。
最近導入されたもう一つの機能は、AWS PrivateLinkに関連するものです。PrivateLinkでは、Region 1にNetwork Load Balancerの背後にサービスがあり、VPC 1でエンドポイントサービスとエンドポイントを作成します。 では、Region 2のNetwork Load Balancerの背後にあるサービスについてはどうでしょうか？Region 1のインスタンスからどのように接続すればよいのでしょうか？ そこで、クロスリージョンPrivateLinkを導入しました。これにより、Region 1のVPC 1にインターフェースエンドポイントを作成し、Region 2のエンドポイントサービスとNetwork Load Balancerを指定することで、クロスリージョン接続を簡素化できます。このユースケースではCloud WANは不要で、ネットワークを本当にシンプルにすることができます。
スケーラブルなグローバル接続を構築する際には、これらのコンポーネントがすべて組み合わさる必要があります。すべてがVPC Latticeで解決できるわけでもなく、すべてがCloud WANで解決できるわけでもなく、すべてがDirect Connectを経由する必要があるわけでもありません。重要なのはグローバルネットワークを構築することです。 グローバル接続を見てみると、Region 1、Region 2、Region 3があります。 これらのリージョン間にCloud WANセグメントが設定され、オンプレミスのDirect Connect GatewayがCloud WANにネイティブに構成されています。 Direct Connectが不要な場所や実現が難しい場所には、Site-to-Site VPNを使用して他のサイトに接続します。
リモートユーザーはClient VPNまたはVerified Accessを通じてVPCに接続し、必要に応じてそこからCloud WANを経由して通信します。サービスネットワークにはVPC Latticeを使用して、リージョン内のサービス間の接続を可能にします。 Region 3にもサービスネットワークがあり、 これらのどの場所からでもAWS PrivateLinkを利用したサービスネットワークエンドポイントに接続できます。これがAWS上で本当にスケールアウトした場合のグローバルネットワークの姿です。オンプレミスからAWSへの接続、AWS間の接続、クロスリージョン、同一リージョンなど、あらゆるネットワーキングのニーズに対応できます。すべてを監視し、 Cloud WAN、VPC Lattice、Verified Access、VPN、そしてDirect Connectのパワーを活用して、スケーラブルなグローバルネットワークを構築することができます。
本日はご参加いただき、ありがとうございました。ご質問がございましたら、会議室の外で私とSidをお待ちしております。また、展示会場のNetworkingとContent Delivery関連のブースでもお待ちしておりますので、お気軽にお立ち寄りください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion