re:Invent 2023: AWSとSonosが語る成長と柔軟性を備えたネットワーク設計
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Ready for what’s next? Designing networks for growth and flexibility (NET310)
この動画では、AWSのPrincipal Solutions ArchitectであるSidhartha ChauhanとSonosのPrincipal Network EngineerであるBen Robinsonが、成長とスケーラビリティのためのネットワーク構築のベストプラクティスを紹介します。AWS Cloud WANやTransit Gatewayなどの最新技術を活用したグローバルネットワークの設計方法や、VPCの適切な分割戦略、IPアドレス管理のコツなど、大規模環境での実践的なノウハウを学べます。さらに、SonosがCloud WANを導入した経緯や得られたメリットについての貴重な事例も共有されています。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
AWS ネットワーキングセッションの紹介と成長の課題
みなさん、こんにちは。成長と柔軟性のためのネットワーク構築のベストプラクティスを探る NET310 セッションへようこそ。私は Sidhartha Chauhan と申しますが、Sid と呼んでいただいて構いません。AWS の Principal Solutions Architect を務めています。今日は Ben Robinson さんも一緒です。Ben は Sonos の Principal Network Engineer で、このプレゼンテーションの終わりの方で登壇し、Sonos が AWS 上で成長とスケールのためのネットワークをどのように構築したかについて、その journey を共有してくれます。
すべての組織がクラウド導入の journey の途上にあります。アプリケーションをクラウドに移行しているか、新しいアプリケーションを構築しているか、できれば今は generative AI を使って。一つ確かなのは、アプリケーションの数は増え続けるということです。そのため、私たちネットワークエンジニアやネットワークアーキテクトは、あらゆる種類のアプリケーションや要件に対応してスケールできるネットワークを構築する必要があります。それがこのセッションのテーマであり、その方法について説明します。
ネットワーキングとスケールの多面的な課題
ネットワーキングとスケールは多面的なので、いくつか例を見てみましょう。 例えば、非常に高いスループット要件を持つアプリケーションがあるとします。そのためには、「EC2 インスタンスは適切なタイプか？ネットワーク要件を満たせるか？ロードバランシングはどうか？どのようにして異なるロードバランサーやインスタンス間でトラフィックを分散させるか？」といったことを考える必要があります。
次の課題は、異なるネットワーク要件を持つ多数のアプリケーション（内部向けと外部向けの両方）を扱うことです。 これらのアプリケーションをどのように互いに分離するか、あるいは必要に応じて接続するかを考えます。セキュリティをどのように強制するか？ さらに、多数のビジネスユニットがあり、これらのビジネスユニットを独自のルーティング境界に分離したいかもしれません。Layer 7 の検査を行いたいかもしれません。
最後に、私たちが生きているグローバルな環境を考えると、私たちは皆グローバルネットワークを構築しています。ここでは、最適なグローバルルーティングの設定、統一されたセキュリティオペレーション、そしてそのすべてを管理する単一の管理画面が必要になります。今日のセッションでは、主にネットワーク接続のスケールに関連する下の3つの課題に焦点を当てます。
クラウド時代のネットワーク設計とAWS Well-Architected Framework
これまでにそのようなスケールの課題を見たことがない方も、ご心配なく。今日の時点からきっと学び、進化していけるはずです。データセンターの管理と運用だけが私たちの仕事だった黎明期に戻ってみましょう。データセンターを歩き回り、スイッチやケーブルに実際に触れることができた - 楽しい時代でしたね。そして、CloudとAWSの時代が到来しました。
当初、Cloudはバックアップや災害復旧ワークロードをデプロイする手段と考えられていましたが、それはすぐに変化し、本番アプリケーションや重要なアプリケーションをデプロイするようになりました。リモートオフィスやブランチオフィス、オンプレミスのインフラをクラウドインフラに直接接続して、低レイテンシーと高スループットを実現する必要がありました。そしてすぐに、私が「メッシュの混沌」と呼ぶような状況になってしまいました。
より良いアプローチは、AWSを中心に置いて頭脳のように機能させ、AWS Global Backboneを活用し、その上にAWSのソフトウェア定義サービスを載せて、クラウドインフラであれオンプレミスであれ、すべてのインフラ間のルーティングを管理することです。このプレゼンテーションでは、このアプローチについて話し合います。これはシンプルさとスケーラビリティの両方を促進します。
そのデザインを実現するための異なるオプションを比較検討する際、AWS Well-Architected Frameworkを使用します。このフレームワークには、パフォーマンス効率、セキュリティ、信頼性、運用上の優秀性、コスト最適化、持続可能性などの原則が含まれています。では、成長、スケール、柔軟性のためにどのようにアーキテクチャを設計すればよいでしょうか？答えは、私のお気に入りの「それは状況次第」です。アプリケーションのネットワーク要件によって異なります。
VPC設計の重要性とNAUの概念
まずはアプリケーションのトラフィックパスから始めましょう。アプリケーションとそのすべての依存関係がVPC内に限定されているのか、それとも複数のVPCにまたがっているのでしょうか？一歩下がって考えてみましょう。すべてのインフラを単一のVPCに入れるべきか、それともVPC間で分割すべきか？非常に基本的な質問ですが：いくつのVPCを持つべきでしょうか？
スケールと成長のためには、これを正しく理解する必要があります。多くの顧客がこれを間違えて、後でスケールに関する多くの課題に直面するのを見てきました。 私はVPCを理想的なネットワーク分離境界、つまり影響の範囲を制限するものとして捉えています。 よく見かけるのは、VPCをアプリケーションのネットワーク境界として扱う戦略です。つまり、異なるアプリケーションを異なるVPCにデプロイしたり、本番環境、非本番環境、開発・テスト環境をそれぞれ別のVPCにするといったアプローチです。
アプリケーションの各マイクロサービスごとにVPCを設けるという細かいアプローチもあれば、事業部門の異なるアプリケーションをひとつのVPCにまとめるというマクロなアプローチもあります。どのアプローチが正しいのかと聞かれれば、それは状況次第です。考慮すべき要因は多々ありますが、よく見落とされがちなのが人とプロセスの側面です。もし、あなたの組織が分散型で、セキュリティからネットワーキングまでアプリケーション全体を所有・管理する2ピザチームがいるなら、アプリケーションごと、あるいはアプリケーションの規模によってはマイクロサービスごとに異なるVPCやアカウントを持つ、より分散したアプローチが理にかなっています。ひとつ確かなのは、極端な方向に走らないことです。1つのVPCだけを作るのも、10,000のVPCを作るのも避けましょう。その間のどこかで、あなたに合ったアプローチを見つけてください。
もうひとつの重要な質問は、VPCはどれくらい大きくできるのかということです。これは「状況次第」という答えではなく、事実に基づく答えがあります。VPCの大きさはNAU（Network Address Usage）というメトリクスで測ることができます。名前が示すように、これはVPCで使用するアドレスの数ですが、そう単純ではありません。例を見てみましょう。
NAUは、ENIに割り当てられたIPアドレスごとに1です。また、ENIに割り当てられたプレフィックスごとにも1です。例えば、ENIにスラッシュ28を割り当てることができます。しかし、hyperplaneによってバックアップされるAWS管理のENIの場合は6になります。つまり、VPC endpoints、Lambda functions、NAT Gateway、またはそのようなサービスを使用する場合、クォータはVPCあたり256,000、または他のVPCとピアリングされているVPCの場合は512,000です。Amazon CloudWatchを使用して、VPCのNAUをモニタリングしてください。
VPC共有とVPC接続オプションの選択
さて、AWSでネットワークを構築する戦略の1つで、非常に大規模なVPCを作成することにつながるのがVPC共有です。VPC共有の考え方は、個々のアカウントを異なるアプリケーションコンポーネントに割り当てますが、ネットワークの観点からは、すべてが単一のVPC内にデプロイされるというものです。つまり、1つのVPCを複数のアカウントで共有するのです。これを行う理由は、アプリケーションの異なるコンポーネントをできるだけ近接して配置したいからです。これにより、レイテンシーとデータ転送料金が削減されます。また、中央チームがVPCを管理し、アプリケーション所有者はそれを気にする必要がないという職務の分離も促進されます。
ただし、非常に大規模なVPCを構築する際は注意が必要です。NAU制限が適用されますし、セキュリティグループやネットワークACLの管理も必要です。そしてもちろん、影響の範囲も広くなります。共有VPCを作成する方法について、参考になるアーキテクチャを1つ紹介できます。それは、異なる事業部門をVPCにまとめる戦略です。例えば、マーケティングアプリ用の共有VPCを作成し、その事業部門内の異なるアプリケーション所有者と個々のサブネットを共有します。もう1つのアプローチは、多数のマイクロサービスを持つ非常に大規模なプラットフォーム用のVPCを持ち、それらのVPCをそのマイクロサービスを所有する個々のアカウント所有者と共有するというものです。
どの戦略を選択しても、1つ確実なのは、複数のVPCを持つことになり、それらを接続する必要が出てくるということです。では、VPCをスケールで接続するにはどうすればよいでしょうか？現在、Transit GatewayとCloud WANがありますが、どちらのオプションを選ぶべきでしょうか？決定を下す前に、アプリケーションの要件に立ち返る必要があります。クロスリージョンアクセスが必要ですか？オンプレミス接続が必要ですか？セキュリティ要件は何ですか？セグメンテーションが必要ですか？ディープパケットインスペクション、ゼロトラストは？帯域幅とレイテンシーの要件は何ですか？そしてコストも重要なので、アプリケーションコンポーネント間でどれだけのデータ転送が発生するかを理解することが大切です。
Transit Gatewayの特徴とスケーラビリティ
最初のオプションであるTransit Gatewayを見てみましょう。Transit Gatewayは、ハブアンドスポークデザインを構築することでスケールを促進します。Transit Gatewayは最大5,000のネットワークアタッチメントに接続できます。グローバル接続もサポートしており、各リージョンにTransit Gatewayをデプロイし、Transit Gatewayクロスリージョンピアリングを通じて相互に接続またはピアリングすることができます。ただし、Transit Gatewayはリージョナルサービスなので、各リージョンでTransit Gatewayを設定する必要があり、リージョン単位の運用となります。
また、ハイブリッドスケールも促進します。次に見ていただく内容について、最近クォータを更新しました。Direct Connect GatewayをTransit Gatewayに最大6つ接続でき、Direct Connectごとに4つのTransit VIFを作成できます。つまり、簡単な計算をすると、1つのDirect Connect上で最大24のTransit Gatewayに接続できるということです。また、Transit Gatewayからオンプレミスルーターに200のプレフィックスをアドバタイズできます。ただし、そのためには静的ルートを書く必要があることに注意してください。スクリーンショットを見ると、「Allowed Prefixes」というセクションがあります。そこにそれらのプレフィックスを入力することになります。また、クロスリージョンTransit Gatewayピアリングを設定する際も静的ルートを書く必要があり、その例を下のスクリーンショットで見ることができます。
さて、セキュリティの観点から、ルートテーブルを使用して地域ごとのセグメンテーションを作成できます。ここでは、本番環境、開発環境、およびピアリング用のルートテーブルがあり、これらのルートテーブルにアタッチメントを関連付けることができます。
100以上のルートテーブルを持つことができますが、よく聞かれる質問として「いくつのルートテーブルを持つべきか」というものがあります。予想通り、答えは「状況次第」です。しかし、アプローチの仕方としては、ルートテーブルの設計はVPC設計のスーパーセットであるべきです。つまり、複数の本番環境VPCがある場合、ここで示したように本番環境セグメントを作成できます。また、VPCをビジネスラインごとにセグメント化している場合は、それに応じたルートテーブルを作成することもできます。このように、VPC設計のサブセットとなります。だからこそ、VPC設計を適切に行うことが非常に重要なのです。
セグメントはグローバルに拡張されないことに注意してください。つまり、「本番環境VPCは本番環境と通信し、開発環境VPCは開発環境と通信する」というようなリージョンをまたいだ設定はできません。また、レイヤー7のセキュリティを設定することもできます。AWS Network FirewallやGateway Load Balancerを使用して検査用VPCを追加し、「本番環境と開発環境の境界を越えるトラフィックは検査用VPCを経由すべき」というようなルーティングロジックを記述できます。パフォーマンスの観点からは、Availability Zoneごとのアタッチメントごとに最大100Gbpsを達成できます。コストの観点からは、データ処理料金と時間単位の料金がかかります。
AWS Cloud WANの概要とTunnel-less Connect機能
これらのWell-Architectedの柱を見ると、運用の観点からは静的ルートを記述する必要があり、リージョン単位の運用となります。また、セグメントはグローバルに拡張されません。このように、グローバルネットワークを構築する際にはいくつかの制限があることがわかります。そこで次のオプションとして、AWS Cloud WANが登場します。このサービスを使用してグローバルネットワークを構築します。このアーキテクチャでは、オンプレミス環境があり、AWSリージョンを導入し、ワークロードの移行を開始し、メッシュネットワークを構築します。私たちはこの複雑さを解決したいのです。
AWSのバックボーンを使用して、グローバルで回復力のあるルーティングレイヤーを構築します。その上にCloud WANが構築されます。Cloud WANでは、Core Network Edge（CNE）をプロビジョニングします。これらはAWSによって完全に管理されるリージョナルエンドポイントです。すべてのCNEは完全にメッシュ化されており、それらの間には動的ルーティングがあります。ネットワークを最寄りのCNEに接続し、後ほど詳しく説明しますが、SD-WAN接続を介してリモートオフィスを接続することもできます。これらをすべて行うと、CNEはグローバルにルートを交換します。静的ルートを記述する必要はなく、すべて動的ルーティングです。デフォルトのクォータである5,000まで、数千のネットワークを接続できます。
ハブアンドスポークデザイン、ダイナミックルーティング、そしてグローバルな一元管理が可能になります。AWS Network Managerダッシュボードを使用すると、 ネットワークの豊富な可視化が得られます。ネットワークトポロジーを詳しく調べることができ、さまざまなトポロジーマップや、ネットワーク内のすべてのイベントの可視性が得られます。例えば、SD-WAN接続のBGPが上がったり下がったりした場合、それらすべてを一箇所で確認できます。
こちらは少し異なる視覚的表現ですが、同じコンセプトを示しています。中央にCloud WANコアネットワークがあり、下にはオンプレミスインフラ、上には3つのAWSリージョンにまたがるVPCがあります。VPCを最寄りのCNEに接続するアタッチメントを作成します。 オンプレミスからは、IPsecサイト間VPN接続を作成できます。SD-WAN接続の場合、VPCにSD-WANアプライアンスをプロビジョニングし、 そのVPCをVPCアタッチメントを使用してCNEに接続します。その上に、Connectアタッチメントと呼ばれるものを作成します。Connectアタッチメントを通じて、Cloud WANコアネットワークエッジとSD-WANアプライアンスの間にGREトンネルを作成し、その上でBGPを実行してルートとトラフィックを交換できます。
これが数週間前までの方法でしたが、最近Tunnel-less Connectをリリースしました。 Tunnel-less Connectについて詳しく見ていきましょう。全体的な目標は変わりません。SD-WANアプライアンスを高可用性の方法で Cloud WANコアネットワークエッジに接続したいのです。まず、VPCアタッチメントを作成し、これによりCloud WAN ENIがトランスポートVPCにデプロイされます。 次に、Tunnel-less Connectを作成します。これにより、BGPピアリング用の2つのIPv4アドレスがプロビジョニングされます。これらのIPアドレスは、VPCにデプロイされるCloud WAN ENIを通じてアクセス可能になります。そして、 これらのIPとSD-WANアプライアンスの間でBGPピアリング関係を設定します。これで完了です。GREトンネルは必要ありません。
Tunnel-less Connectの詳細と実装上の注意点
現在、多くのパートナーがすでにTunnel-less接続をサポートしています。では、これによって何が変わるのでしょうか？ GREを使用するトンネルベースのConnectでは、 GREトンネルごとに5ギガビット/秒しか得られませんでした。しかし、Tunnel-less Connectでは、アベイラビリティーゾーンごとに100ギガビット/秒が得られます。これは大きな違いです。考慮すべきアーキテクチャ上の注意点がいくつかあります。VPCごとに1つのTunnel-less Connectアタッチメントしか持てません。
トランスポートVPCアタッチメントとConnectアタッチメントは、同じセグメントに関連付ける必要があります。これらの意味がわからなくても心配しないでください。プレゼンテーションの後半で、これらの考慮事項を使用したアーキテクチャについて説明します。また、ベストプラクティスとして、SD-WANアプライアンスをトランスポートVPCアタッチメントと同じサブネットで実行することをお勧めします。この図に示されているのがまさにそのとおりです。
なぜそうすべきかと疑問に思われるかもしれません。その理由は、そうしないと多くの静的ルートを書かなければならなくなり、それは避けたいからです。このQRコードのブログでは、その方法の詳細や、ベストプラクティス、考慮事項などについて詳しく説明しています。
さて、続けましょう。オンプレミスのインフラストラクチャをAWS Cloud WANに接続する場合、Transit Gatewayを経由する必要があります。現在、Cloud WANはネイティブのDirect Connect接続をサポートしていません。オンプレミスからTransit Gateway、そしてCloud WANへ広告するルートはすべて動的に学習されますが、Transit GatewayからDirect Connectへの静的ルートは依然として書く必要があります。
次は、Cloud WANの私が特に気に入っている機能についてです：ネットワークポリシーです。JSONネットワークポリシーを通じて、Cloud WANの設定全体を定義できます。こちらがポリシーの例です。グローバルネットワークをデプロイしたいエッジロケーションを指定します。ここではUS East 1、US West 2です。セグメントを定義し、セグメントアクションを定義します。これは基本的に特定のセグメント間でルートを共有することを意味します。ここで静的ルートを書くこともできます。最後に、アタッチメントポリシーを書くことができ、これによってアタッチメントが特定のセグメントに関連付けられる方法を自動化します。ここではタグに基づいて行われています。
Cloud WANのネットワークポリシーとNetDevOpsパイプライン
ポリシーのバージョン管理も可能で、異なるポリシーをデプロイすると、バージョン管理されます。また、以前のポリシーにロールバックするオプションもあります。ポリシーを作成する際、Cloud WANでは変更セットを作成することでポリシーを検証できます。ポリシーの変更点を正確に確認できます。それを検証し、実行します。実行すると、Cloud WANネットワークにグローバルに変更が適用されます。もはやリージョナルコンソールに行って変更を加える必要はなく、すべてがグローバルな操作となります。
この検証ステップ、つまり変更セットの検証をNetDevOpsパイプラインに統合したいと思うでしょう。NetDevOpsパイプラインについてご存じない方のために説明しますと、これはDevOpsの原則をネットワーク設定の変更に適用する実践です。ネットワーキングの観点から成長し、スケールアップしたい場合は、これも採用すべき実践の一つです。Cloud WANのJSONポリシードキュメントと同様に、ネットワーク設定をコードとして扱います。バージョン管理システムに保存し、CI/CDを使用してネットワークの変更を実装およびテストします。
それでは、エンドツーエンドでの具体的な例をご紹介します。このシナリオでは、Cloud WANを含むネットワーキングアカウントがあり、新しいVPCのプロビジョニングを自動化し、そのVPCをCloud WANネットワークにアタッチしたいと考えています。 セルフサービスポータルを通じて、アプリケーションチームが必要なものを定義できるようにします。これはService CatalogやカスタムUIを通じて行うことができます。具体的な方法は問いません。彼らは「VPCが必要で、それは開発用VPCで、/24のサブネットが必要」などと入力します。これに基づいて、AWS CloudFormationテンプレートやCDKスクリプト、あるいはTerraformなどが生成されます。そしてこれがCI/CDパイプラインをトリガーします。
ここで重要なステップは、自動化されたネットワーク構成チェックです。多くの項目をチェックできます。例えば、アプリケーションチームが開発用VPCとインターネットゲートウェイを要求したけれども、ポリシーでそれが許可されていない場合、パイプラインを失敗させることができます。このように、さまざまなガードレールを設定できます。すべてが検証され、問題がないことが確認されたら、VPCの作成、アタッチメントの作成、そしてタグ付けが行われます。
ここから、人による承認ステップを追加できます。誰かがAWS Cloud WANコンソールに入り、「誰かが開発セグメントへのアタッチメント接続を要求していますが、許可しますか？」というメッセージを確認します。承認すると、Cloud WANの自動化が開始されます。アタッチメントを適切なセグメントにマッピングし、すべてのルートを学習し、すべてのルートを伝播させます。すべてが動的に行われます。最後に、VPC内の接続をテストします。すべてが問題なければ、パイプラインは終了します。
Cloud WANのセグメンテーションとルーティング戦略
さて、Cloud WANに話を戻しましょう。セキュリティの観点から、Transit Gatewayと非常によく似たグローバルセグメントを作成できますが、これらはグローバルセグメントなので、AWSリージョン全体で一貫性があります。アタッチメントを適切なセグメントに関連付けます。Transit GatewayをCloud WANセグメントに関連付ける場合は、少し複雑になります。その仕組みを見てみましょう。
Transit Gateway内には、ルートテーブルがあります。これをCloud WANに関連付けたい場合、実際には個々のルートテーブルをCloud WANセグメントに関連付けることができます。例えば、Transit Gatewayのハイブリッドルートテーブルを取り、Cloud WANのハイブリッドセグメントに関連付けることができます。
また、集中型の検査を使用してレイヤー7のセキュリティを構築することもできます。これは Transit Gateway の動作と非常によく似ていますが、ここでもグローバルなセグメントになります。各リージョンに集中型の VPC をデプロイし、そこに NAT Gateway、ネットワークファイアウォール、そしてあらゆる種類の共有リソースを配置します。
ネットワーク検査の設定方法 やルーティングの方法についてより深く掘り下げたい場合（静的ルートの作成や、実施内容に応じて追加のセグメントを作成する必要があるかもしれません）、参考になるブログ記事があります。ただし今日は、トラフィックの検査は慎重に行うべきだという点に焦点を当てたいと思います。リージョン間やセグメント間でトラフィックを検査するたびに、4つの追加のホップが発生します。データを2回余分に処理することになるので、すべてのトラフィックに対して行うべきではありません。
では、どのようにアプローチすればよいでしょうか？検査戦略として、セグメント間、セグメント内、リージョン内、リージョン間、オンプレミス、左右、東西など、あらゆる場所ですべてを検査するという方法があります。そのようにする場合、レイテンシーやデータ処理料金が過剰にならないようにするには、VPC の設計が鍵となります。通常、VPC 内ではなく VPC 間で検査を行うため、低レイテンシーのアクセスが必要で、データ転送コストを抑えたい場合は、アプリケーションコンポーネントを VPC 間に分散させないようにする必要があります。
私が好んで勧めるのは、セキュリティゾーンと境界の間で検査を行うことです。通常、Cloud WAN のセグメントを セキュリティ境界にマッピングし、セグメント間で検査を行います。つまり、開発環境と本番環境の間でトラフィックが流れる場合は検査を行いますが、本番セグメント内や開発セグメント内のトラフィックは検査しません。
目的特化型VPC接続オプションの比較
パフォーマンスの観点から、AWS Cloud WAN は Availability Zone ごとにアタッチメントあたり最大 200 Gbps をサポートしており、これは Transit Gateway と非常に似ています。コスト面でも、データ処理料金とアタッチメントごとの料金があり、これも Transit Gateway と非常に似ています。なぜすべてが Transit Gateway と似ているのかと疑問に思われるかもしれませんが、それは Cloud WAN が Transit Gateway と同様の技術を基盤に使用しているからです。ただし、Cloud WAN は豊富な自動化と動的ルーティングを提供します。
では、目的に特化したVPC接続オプションについてお話ししたいと思います。まず最初はVPCピアリングです。VPCピアリングは私たちが最初にリリースした接続モデルですが、現在では目的特化型モデルの役割を担っています。VPCピアリングはどんな時に使うのでしょうか？スケーラビリティが高くなく、運用の観点からも優れているとは言えません。セキュリティもレイヤー4のみで、レイヤー7はありません。では、なぜ使うのでしょうか？それは、パフォーマンスのためです。2つのVPCをピアリングする場合、その間にゲートウェイはありません。2つのVPCをピアリングし、それらのVPC内のEC2インスタンスが同じAvailability Zoneに属している場合、データ転送料金はかかりません。
つまり、VPC間で接続したいアプリケーションがあり、それらが頻繁にやり取りを行い、ギガバイトやペタバイト単位のデータを転送する場合、データ転送料金に注意を払いたいのであれば、VPCピアリングを使用することをお勧めします。次の目的特化型オプションはPrivateLinkです。これは、サービスプロバイダーとして、サービスを複数の消費者と共有したいが、VPC全体やネットワーク全体を公開したくない場合に使用します。特定のサービスのみを公開したい場合に適しています。
このモデルでは、サービスプロバイダーがエンドポイントサービスを作成し、それを消費者アカウントと共有します。消費者アカウントは、そのエンドポイントサービスに対してインターフェースエンドポイントを作成します。裏側では、PrivateLink接続が作成されます。VPCピアリングもTransit Gatewayも Cloud WANも使用しません。これは異なるデータプレーンです。スケーラビリティの観点から見ると、サービスプロバイダーは無制限のスケーラビリティを得られ、サービス消費者はVPCごとに100のエンドポイントを持つことができます。
PrivateLinkは完全マネージド型です。セキュリティの観点からは、一方向の接続のみで、サービスプロバイダーが消費者に対して接続を開始することはできません。セキュリティグループを使用することができ、PrivateLinkをAWSサービスへのアクセスに使用する場合（これはサポートされているモデルです）、より細かい粒度のポリシーであるエンドポイントポリシーを書くこともできます。パフォーマンスの観点からは、自動的に毎秒100Gbpsまでスケールアップします。また、従量制の時間単位の料金とデータ転送料金がかかります。
次の目的特化型サービスはVPC Latticeです。VPC Latticeは、完全マネージド型ネットワーキングサービスの究極の形と言えるでしょう。
アプリケーションのオーナーとして、サイドカーやエージェントなしで、認証、モニタリング、トラフィックシェーピング、サービスディスカバリー、ヘルスチェックが組み込まれた、完全マネージド型のサービスが欲しいと思うでしょう。これらの機能はすべて、Amazon VPC Latticeサービスを通じてVPCのデータプレーンに組み込まれ、完全に管理されています。 サービスネットワークを作成し、異なるアカウントや異なるVPCにある可能性のあるマイクロサービスを、サービスネットワークの一部としてサービスとして登録します。そうすることで、これらのサービスはVPC Latticeのデータプレーンを通じて、すべての機能を備えて相互に通信できるようになります。
VPC Latticeの特徴と接続モデルの選択
この機能は均質に動作します。あるVPCにEC2インスタンスがあり、別のVPCにLambda関数があるか、EKSやALBがあっても、それらすべてを接続できます。IAMを使用してすべてのパケットが認証・承認されるため、ゼロトラストを実現できます。パフォーマンスは、AZごとにサービスあたり100ギガビットです。コストの観点からは3つのメトリクスがあり、非常に従量制の料金モデルとなっています。
では、どのオプションを使用すべきでしょうか？デフォルトの接続モデルを選択し、ユースケースに基づいて目的に特化した接続を追加構築することをお勧めします。グローバルなプレゼンスがある場合は、AWS Cloud WANの使用をお勧めします。ここでグループ演習をしてみましょう。 これらの接続モデルをすべて組み合わせる方法を見てみましょう。2つのサブネットを持つ2つのVPCに6つのEC2インスタンスといくつかのコンテナがあります。まず、デフォルトの接続モデルとしてCloud WANを選択します。これらのVPCは同じリージョンにあるため、コアネットワークエッジを通じて接続します。
次に、アプリケーションチームが要件を持ってきました。 EC2インスタンス3と4が、インスタンス1と2への非常に高スループットの接続を必要としています。これらは同じAZにあり、データ転送コストを最小限に抑えたいとのことです。これは、ネットワーク認定試験の問題のようですね。ここではどの接続モデルを選択しますか？Cloud WANのようなコアネットワークエッジを使い続けますか、それとも別の接続モデルを導入しますか？誰でも答えてください。VPCピアリングですね、素晴らしい。 VPCピアリングを作成し、VPCピアリングを介してトラフィックをルーティングする方法は、VPCのルートテーブルにより具体的なルートを作成することです。
次に、アプリケーションチームが来て言います。「2つのVPCにEKSクラスターがあります。」彼らはゼロトラストIAMポリシー認証で通信したいと考えており、さらにサービスディスカバリーも必要としています。何を使えばいいでしょうか？VPC Latticeですね、素晴らしい。 これはどのように機能するのでしょうか？サービスがサービスディスカバリーを行うと、URLが得られ、そのURLはリンクローカルIPに変換されます。トラフィックはこのリンクローカルIPを通じてハイパーバイザーに取り込まれ、VPCのデータプレーンに入ります。Cloud WANには決して行きません。
最後の要件です。アプリチームが第三者のSaaSプロダクトを購入し、プライベートな一方向の接続が必要になりました。どうすればいいでしょうか？PrivateLinkです。ここでPrivateLinkをプロビジョニングします。DNSがPrivateLink endpoint serviceのDNSをVPC内のインターフェースエンドポイントに変換します。 つまり、Cloud WANには一切行きません。他のすべてにはCloud WANを使います。デフォルトルートは私のcore networkを指しています。
スケーラブルなネットワーク構築のベストプラクティスと考慮事項
では、他のスケールに関する考慮事項を見てみましょう。IPアドレッシングは、正しく設定する必要がある基本的な要素の1つです。重複するCIDRアドレスを持っていたり、IPアドレスが不足したりしている顧客に多く出会いましたが、それは決して良い状況ではありません。階層的な観点からIPレンジを要約できるIPアドレッシング設計を選択することが重要です。階層は自由に選べます。 通常は、異なるリージョンにレンジを割り当て、そのリージョン内で異なる環境、ビジネスライン、またはアプリケーショングループにレンジを割り当てます。選択は自由ですが、要約が鍵となります。これにより、静的ルートの作成が容易になり、ファイアウォールのエントリも簡単になります。
クラウドでIPアドレス管理を支援するVPC IP Address Manager (IPAM)というサービスがあります。まだ使用していない場合は、お勧めします。 最近、IPv4パブリックIPの価格設定方法を変更したので、IPAMのパブリックIPインサイトを使用して、パブリックの観点からIPv4アドレスの使用状況を把握できます。最後に、IPv6をまだ検討していない場合は、特に大規模な環境では検討すべきです。 数千のVPCを構築し、大規模なコンテナワークロードや生成AIアプリケーションが導入されるにつれて、IPv6の重要性が増していきます。
IPアドレスが不足する時が来るでしょう。そのとき、IPv6が唯一の選択肢となります。だから早めに考えておくべきです。次の考慮事項は、集中型アーキテクチャと分散型アーキテクチャについてです。ここでは、ファイアウォールやNATゲートウェイなど、特定のサービスを集中化して、集中型のインターネットエグレスを実現します。どちらを選ぶべきでしょうか？どちらでも構いませんが、アプローチを標準化することが重要です。
多くの顧客が集中型アプローチを標準化していますが、例外に対しては反復可能なガードレールパターンを適用しています。例を挙げましょう。アプリケーションチームが「顧客向けのパブリックなアプリケーションをデプロイします」と言ってきたとします。インターネットイングレスを集中化するのは非常に難しいです。インターネットエグレスの集中化の方がはるかに簡単です。そのため、分散型のインターネットエグレスモデルの方が理にかなっています。しかし、アプリチームに「VPCにインターネットゲートウェイをデプロイしてトラフィックを受け入れてもいいよ」とは言いたくありません。NetDevOpsを使用して、DevOpsパイプラインで反復可能にしたいのです。
ここでの例としては、ALBの上にWAFをデプロイし、AWS Firewall Managerを使用して組織内の異なるアカウントにある何百ものALBにわたってWAFルールを管理することが挙げられます。これは分散モデルですが、中央集中型の制御も維持できます。そして、NetDevOpsパイプラインで定義したベストプラクティスとガードレールに基づいてデプロイされていることを確認できます。
さて、さらにいくつかのベストプラクティスを見ていきましょう。ここでは、サンプルアーキテクチャといくつかの高度なシナリオを見ていきます。複数のリージョンにわたって何百ものVPCがあり、オンプレミス接続もありますが、Transit Gatewayを使用しています。さらなるスケールを実現するためにCloud WANに移行したいと思います。ここに、2つのリージョンにまたがる3つのルートテーブルを持つ2つのTransit Gatewayがある私のアーキテクチャがあります。また、Direct Connectを介してオンプレミス接続もあります。
AWS Cloud WANをプロビジョニングします。まず、Transit GatewayのルートテーブルデザインをCloud WANのセグメントに模倣することから始めます。次に、Transit GatewayとCloud WANの間でセグメントを関連付けます。これにより、Transit GatewayとCloud WANの間でダイナミックルーティングが設定されます。本質的に、Transit Gateway間でダイナミックルーティングを有効にしたことになります。なぜなら、Cloud WANの2つのCNEがTransit Gatewayからルートを学習し、リージョン間で広告するからです。
基本的に、リージョンをまたいで2つのTransit Gatewayのprodとprod、devとdev、hybridとhybridをピアリングしたことになります。VPCピアリングではこれはできませんでしたが、Cloud WANを間に置くことで可能になります。これは、Cloud WANを初めて使用する場合の良い出発点です。これを設定したら、次にテストまたは開発VPCをCloud WANにアタッチできます。開発VPCのルートテーブルでは、変更を加える必要があります。Transit Gatewayではなく、コアネットワークを指すように変更します。
ネットワーク接続を確認し、すべてが正常に動作していることを確認してから、開発VPCをTransit Gatewayからデタッチします。これで完了です。あとは、すべてのVPCに対してこれを1000回繰り返すだけですが、NetDevOpsパイプラインを使用して行う必要があります。そうすれば、組み込みの検証とテストを伴って自動的に行われます。さて、Cloud WANへの移行に成功しました。ここに2つのリージョンがあります。prodセグメントのルートテーブルを見てみましょう。ここでグローバルルートテーブルを見ています。すべてのprod VPCがルートテーブルにあることがわかります。つまり、prod VPC同士が通信できるということです。
また、Transit Gateway AとTransit Gateway Bを通じてOn-Premisesネットワークへのルートも持っています。リージョン1でトラフィックが発生した場合、Transit Gateway Aを経由して流れ、リージョン2で発生した場合はTransit Gateway Bを経由して流れます。なぜこうなるのでしょうか？それは、それぞれのリージョンにあるCNEがローカルでルーティングの決定を行っているからです。このルーティングの決定は、Cloud WANのルート優先順位に基づいて行われます。これはドキュメントのスクリーンショットです。2番目のポイントを見ると、同じ宛先IPアドレスで異なるネクストホップを持つルートの場合、スタティックルートが優先され、VPC伝播ルートが優先されます。そして3番目が動的ルーティングです。
この場合、AS pathの長さを考慮する必要があります。リージョン1からTransit Gateway Aを経由するトラフィックの場合、Transit Gateway、Direct Connect Gateway、On-Premルーターの3つのホップ、つまり3つのASNがあります。しかし、リージョンBから行く場合は4ホップになります。そのため、常にリージョンローカルのルートを選択し、それが失敗した場合、つまりTransit Gateway Aが失敗した場合は、Transit Gateway Bを経由するルートを選択します。では、障害を発生させてみましょう。Direct Connectの接続が両方ともダウンしたとします。
さて、トラフィックがこのようにルーティングされると思う人は手を挙げてください。はい、少数ですね。その通りです。なぜなら、実際にはトラフィックはTransit Gatewayに送られるからです。Transit Gateway Aはまだ稼働しているからです。Direct Connect Gatewayはグローバルに分散された高可用性のルーターです。Direct Connect接続がダウンしても、Direct Connect Gatewayはダウンしません。
これは重要なポイントです。なぜなら、ハイブリッドトラフィックにはDirect Connect Gatewayのデータプレーンを活用したいからです。ハイブリッドトラフィックに対する地域依存性を排除したいのです。つまり、できるだけ早くトラフィックをリージョンから出し、Direct Connectインフラストラクチャに引き渡し、Direct Connect Gatewayに最寄りのDirect Connect locationへのグローバルルーティングを処理させたいのです。このアーキテクチャはデフォルトでそうなっていますが、すべてのアーキテクチャがそうなっているわけではありません。
例を挙げましょう。新しいAWSリージョンを立ち上げたとします。Direct Connect接続のないVPCをプロビジョニングします。トラフィックが発生します。リージョン3のCore Network Edge（CNE）は、先ほど言ったように完全メッシュなので、リージョン1と2のCNEから等距離にあります。そのため、トラフィックはTransit Gateway AまたはBに送られます。リージョン1がUS、リージョンBがヨーロッパ、リージョン3がインドのムンバイだとしましょう。トラフィックをUSのデータセンター経由で出したくないですよね？では、どうすればいいでしょうか？
さて、非常にシンプルです。まず、リージョン内にローカルでTransit Gatewayを作成します。 これで、ローカルの出口ポイントができました。トラフィックをMumbaiリージョン内のDirect Connect Gatewayにローカルで引き渡し、そこから最寄りのDirect Connect locationにルーティングします。次に、集中型インターネットエグレスのためのエグレスセグメントがある別のシナリオを見てみましょう。 米国とヨーロッパにエグレスVPCがありますが、Mumbaiにはありません。この場合どうなるでしょうか？トラフィックはそれらのリージョンのいずれかに送られ、ご想像の通り、米国に送られることになるでしょう。
これは望ましくありません。では、どうすればいいでしょうか？ローカルリージョンにエグレスVPCを作成します。クロスリージョンの依存関係を避けるため、常にリージョナルな出口ポイントを持つようにしましょう。ただし、MumbaiリージョンにエグレスVPCを作成できない場合で、意図的にクロスリージョンの依存関係を課したい場合は、方法があります。ここではその詳細には触れません。なぜなら、静的ルートを書いたり、 複数のセグメントを作成したりと、かなり複雑になるからです。このブログを必ずチェックすることをお勧めします。
さて、次の要件はリモートロケーションへのSD-WAN接続を作成することです。 VPC内にSD-WANアプライアンスを作成し、Connect attachmentsをセットアップし、 それらのアタッチメントをセグメントに関連付けます。そして、オンプレミスからこれらのSD-WANアプライアンスへ、インターネット経由でSD-WANトンネルを作成できます。もちろん、高可用性のために複数のSD-WANアプライアンスを用意します。非常に分かりやすいですね。
さらに複雑な要件を追加してみましょう。セグメントをオンプレミスに拡張したいとします。その場合、まずSD-WANでどのように行うかを見てみましょう。2つのConnect attachmentsを作成します。 ここではGRE Connect attachmentsを見ています。これらを異なるセグメントに関連付けます。ここではprodとnon-prodのセグメントがあります。そこでprodとnon-prodのConnect attachmentsを作成し、この場合、同じSD-WANアプライアンス上で終端させます。
SD-WANアプライアンスがVRFのような機能を持っていると仮定すると、 SD-WANアプライアンスを論理的に2つの独立したセグメントに分割できます。1つのトンネルは1つのVRFで終端し、 もう1つのトンネルは別のVRFで終端します。そしてこれをオンプレミスに拡張できます。ここでも、高可用性のために異なるAvailability Zoneに複数のアプライアンスを使用する必要があることを示すスターマークが下部にあることがわかります。
SD-WANアプライアンスがVRF的なセットアップをサポートしていない場合はどうすればいいでしょうか？その場合は、複数のSD-WANアプライアンスを作成またはデプロイし、個々のSD-WANアプライアンスをConnectアタッチメントにマッピングし、それらを個々のセグメントにマッピングすることができます。では、スケーラビリティについて見てみましょう。Connectアタッチメントを使用しているため、すでにConnectアタッチメントにはサポートする帯域幅に制限があることを確認しました。GREトンネルあたり5ギガビットです。トンネルをスケールアップしたり、より多くのアタッチメントを作成したりすることはできますが、水平方向にスケールすればするほど、運用上の課題が増えてしまいます。
ここで、お察しの通り、トンネルレスConnectの出番です。トンネルレスConnectでは、2つのトンネルレスConnectアタッチメントを作成し、それらのアタッチメントを異なるセグメントに関連付けます。ただし、ここに違いがあります。アーキテクチャの推奨事項や考慮事項を振り返ってみましょう。
VPCごとに1つのトンネルレスConnectアタッチメントしか持てず、VPCアタッチメントとトンネルレスConnectアタッチメントは同じCloud WANセグメントに関連付けられている必要があります。つまり、異なるセグメントは異なるVPCの異なるEC2インスタンスで終端する必要があるということです。そのようにセットアップする必要があります。多数のセグメントがある場合は、複数のVPCを作成する必要があります。例えば、オンプレミスに拡張したい10個のセグメントがある場合、10個のVPCを作成する必要があります。高可用性を確保するには、20個のSD-WANアプライアンスを作成することになり、スケーラブルではないかもしれません。そのため、バランスを取る必要があります。多数のセグメントがあり、SD-WANアプライアンスがVRFをサポートしている場合は、GREベースのConnectオプションを選択する方が、コストとパフォーマンスの観点からスケールしやすいかもしれません。
また、Direct Connect経由でセグメントをオンプレミスに拡張することもできます。そのために2つのオプションがあります。1つはTransit Gateway上で、Connectアタッチメントを作成し、それらをTransit Gatewayルートテーブルに関連付けます。1つはprodテーブル用、もう1つはnon-prodテーブル用です。prodとnon-prodのTransit Gatewayルートテーブルは、prodやnon-prodなどの適切なCloud WANセグメントに関連付けられます。そして、それをオンプレミスに拡張できます。オンプレミスでは、ほとんどのルーターがVRF設定をサポートしているので、異なるVRFで終端する複数のトンネルが存在することになります。複数のGREトンネルを作成することでスケールアップできます。もう1つのオプションは、トンネルレスConnectを作成することです。これは先ほど見たものと非常によく似ていますが、オンプレミスからSD-WANへの接続が、インターネット経由ではなく、Direct Connect経由のプライベートIPを使用することになります。
最後の要件は、AWS Cloud WANとオンプレミスネットワーク間でDirect Connect経由の動的ルーティングを設定することです。これらのGREトンネルを作成し、SD-WAN接続をセットアップすることで、すでにこれを達成しています。Connect BGPピアとSD-WAN間のBGPピアリングが自動的に設定されています。オンプレミスのルーターやSD-WAN終端ポイントは、SD-WANアプライアンスと動的にルートを交換します。そして、SD-WANアプライアンスはそれらのルートをCloud WANと動的に交換します。このようなアーキテクチャを作成すれば、エンドツーエンドのBGPが実現します。このセットアップにより、Transit Gateway上での静的ルート設定を心配する必要がなくなります。
さて、みなさんがSonosスピーカーの話を聞きたがっているのはよくわかります。言葉遊びのつもりですが。でもその前に、いくつかの重要なポイントについて話しましょう。覚えておくべき10のことがあります。 第一に、アプリケーションのネットワーク要件によって異なります。アプリケーションのニーズに焦点を当て、そこから逆算して考える必要があります。 AWS Well-Architected Frameworkを活用しましょう。スケーラブルなネットワークを構築するということは、必ずしも最高のスループットを持つことを意味しません。レジリエンス、セキュリティ、コスト最適化も同様に重要です。デフォルトの接続モデルを選択し、必要に応じて他のオプションを追加しましょう。先ほど述べたように、グローバルな接続が必要な場合は、 AWS Cloud WANをお勧めしますが、グローバルなプレゼンスがない場合は、AWS Transit Gatewayを使用することもできます。これが主な2つの選択肢です。その上でVPC Lattice、AWS PrivateLink、VPCピアリングなどの他のオプションを導入します。これらが提供する機能を理解し、デフォルトの接続モデルの上に重ねていきます。
集中化されたリソースを持つハブアンドスポークデザインを構築すべきです。これには集中化されたNAT Gatewayやセキュリティアプライアンスが含まれます。また、分散型インターネットイングレスのような例外的なケースの扱い方についても話しました。 NetDevOpsは非常に重要です。多くの方々がすでにAWS CloudFormation、AWS CDK、またはTerraformを使用してネットワーク自動化を行っていると思います。ネットワークの多くを自動的にテストできる純粋なNetDevOpsパイプラインを目指しましょう。VPC Reachability AnalyzerやIAM Access Analyzerなど、CI/CDパイプラインに組み込めるツールがたくさんあります。今では生成AIもありますので、テストの一部に生成AIを使用することもできるかもしれません。 アーキテクチャの観点からは、特にVPCデザインとIPアドレッシングなど、基本をしっかりと押さえることが重要です。これらを正しく設定していれば、スケールの課題は解決できたのに、今ではlanding zone 2.2、landing zone 3.2などを構築している顧客がどれほど多いか、言い表せないほどです。
共有VPCを使用できますが、非常に大規模なVPCを構築したくないことに注意してください。制限を把握しておきましょう。AWS Direct ConnectのデータプレーンがCloud WANとどのように異なるか、そしてハイブリッドトラフィックをグローバルに送信するためにDirect Connect Gatewayをどのように使用するか、また地域依存性を避ける方法について話しました。また、SD-WAN接続に推奨されるアプローチとなった新機能のtunnel-less connectも見ました。最後に、AWS Cloud WANでルートプライオリティがどのように機能するかを確認しました。非常に大規模でスケーラブルなネットワークを構築する際には、最適でないルーティングが発生するシナリオに遭遇するでしょう。そのような場合、このルートプライオリティの設計に立ち返り、最適なルーティングを実現できるように再設計する必要があります。
SonosのCloud WAN導入事例と利点
ありがとう、Sid。みなさん、こんにちは。20年以上のビジネス経験と数千の特許を持つSonosは、カテゴリーをリードするサウンド体験の提供を目指しています。Cloud WANを使用した私たちのネットワークの旅について少しお話ししたいと思います。私がここにいるのは、Sidが先ほど言及したこれらの製品をすべての人が使うべきだと信じているからです。より多くの容量を提供し、コスト効率が良く、多くのセキュリティ上の利点があるからです。しかし、Sonosの旅のほとんどはオンプレミスで、クラウドはありませんでした。最初は少しのハイブリッド環境、いくつかのVPC、いくつかのアカウント、サイト間VPN接続から始まりました。しかし、VPCやアカウントを増やしていくにつれて、うまくスケールしませんでした。そこで、より高度なソリューションが必要になりました。それがTransit VPCでした。
Transit VPCを導入し、数年後にTransit Gatewayが登場しました。Transit VPCのダイナミックルーティング機能が気に入っていたので、すぐには移行しませんでした。AWSのアカウントチームと協力してフィードバックを提供し、最終的にはCloud WANに移行しました。Transit VPCが素晴らしかったのは、グローバルだったからです。Transit VPCのハブアンドスポークにある顧客管理のコンストラクトで、アプリケーションが存在するスポークVPCがありました。もちろんスケールの問題はありましたが、容量の問題を回避し、VPCピアリング接続を追加することで、さらに長く使用することができました。複数のリージョンにTransit VPCインフラストラクチャをデプロイするためのカスタム自動化パイプラインを構築しました。リージョンを追加したい場合は、それを複製する必要がありました。また、ライセンスとサポートモデルの管理も必要でした。
2022年、AWS Cloud WANが利用可能になったことを嬉しく思いました。 これは私たちにとって、あらゆるものを接続し、さらにそれ以上のことができる素晴らしいソリューションです。私たちには、何百ものVPCを接続し、リージョン内の容量制限やリージョン間の帯域幅制限を超えることなく、グローバルなネットワークソリューションが必要でした。もちろん、コスト効率も良好です。リソース共有の部分は本当に素晴らしく、AWS Resource Access Managerを使用してCloud WANのコアネットワークを他のアカウントと共有できます。これは組織レベルでもアカウントレベルでも可能です。
これにより、それらのアカウントを担当するDevOpsチームは、ネットワークチームの介入なしに、必要に応じて任意のVPCを接続できます。Cloud WANを使用した自動化に関しては、AWSに責任を移行することで大きな恩恵を受けました。先ほど見たJSONドキュメントのコアネットワークポリシーは、私たちの大量の自動化を置き換えました。Cloud WANに移行することで、その多くを簡単に移行できました。
個人的に気に入っているのは、DevOpsチームがアタッチメントに様々なタグを設定できるアタッチメントポリシーです。アタッチメントは、そのネットワークポリシーに埋め込まれたアタッチメントポリシールールに基づいて、適切なセグメントに配置されます。相互運用性に関しては、以前のソリューションではリンクステートルーティングプロトコルと内部BGPを使用していましたが、現在はCloud WANでEBGPとECMPを使用しています。SD-WANインフラストラクチャをこれに接続し、他のクラウドも接続しています。
この移行の利点の1つは、AWSが顧客のフィードバックに耳を傾け、私たちが必要とするものを提供してくれることです。これらの製品を作り、裏で懸命に働いている人々に本当に感謝しています。まるで自分専用のMPLSネットワークを持っているようで、しかもAWSがそれを維持し、パッチを当て、さらに改善してくれるのです。最初に使い始めたときは、アタッチメントあたり50 Gbpsでしたが、何も言わなくても、いつの間にかアタッチメントあたり100 Gbpsに増加していました。
容量が増えることで、柔軟性も高まります。私たちにとって、それは集中型NATエグレスのようなものを意味します。グローバルにネットワークを構築し、使用した分だけ支払うことができます。また、VPC分離やVPCアタッチメント分離、セグメントやマクロセグメンテーション機能、さらにこのソリューションに付随する検査アーキテクチャなど、セキュリティ面でのメリットもあります。
では、私たちの次のステップは何でしょうか？Cloud WANに移行して満足した後も、私たちは拡大を続けています。きっと近いうちに耳にするであろう新しいサービス統合は、現在のCloud WANと同じくらい使いやすいものになるでしょう。また、GREトンネルの一部を取り除き、これらのトンネルレスのConnect peerに置き換えていく予定です。詳細については、 コードを入手できる私たちのケーススタディをご覧ください。これがお役に立てば幸いです。
セッションのまとめと今後の学習リソース
Sid、とても参考になりました。ありがとうございます。ここに来てあなたの話を共有してくれてありがとうございます。 また、AWS Networking Coreのデジタルバッジと学習パスもご用意しています。Cloud WANやその他多くのネットワーキングサービスについて学ぶための無料リソースを利用したい方は、こちらから認証済みのデジタルバッジも取得できます。本当にありがとうございました。アンケートにぜひご協力ください。 同僚のBenは5つ星評価をいただけると嬉しいそうです。予定より早く終わりましたので、質問を受け付けることができそうです。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion