re:Invent 2023: AWSが語る最新VPC設計と新機能 - IPv6、Lattice、TRN2
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Advanced VPC designs and new capabilities (NET306)
この動画では、AWSのネットワーキングエキスパートが最新のVPCアーキテクチャや機能を詳しく解説します。IPv6対応、VPC Lattice、AWS Verified Accessなど、クラウドネイティブな接続性とセキュリティの進化を学べます。また、生成AIワークロード向けの驚異的な6,400Gbps/秒を実現するTRN2インスタンスや、ネットワークトラブルシューティングを支援するAmazon Qの活用法など、最先端の話題も満載です。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
re:Inventセッションの開始：AWSネットワーキングの基礎
みなさん、こんにちは！お元気ですか？まあまあですか？金曜日の午前10時です。この時間帯を意図的に選んだのは、本当にネットワーキングに熱心な方々だけが来てくれると分かっていたからです。ここは素晴らしいコミュニティで、その一員であることを嬉しく思います。私はMatt Lehwessで、EC2のシニアプリンシパルです。実はこれで10回目のre:Inventになります。Amazonに入社して10周年でもあります。この数週間前のことですね。このセッションを行うのは8年目だと思います。ここ数年はAlexも一緒です。Alexは戦略的アカウント向けのプリンシパルソリューションアーキテクトで、ネットワーキングのスペシャリスト、そして素晴らしいネットワーキングの魔術師でもあります。
今日はご参加いただき、ありがとうございます。この人数に光栄であり、身が引き締まる思いです。本当にありがとうございます。来年のことを考えると、何百時間もPowerPointに費やし、ステッカーをデザインするのですが、こうして皆さんに来ていただけると、すべてが報われます。さて、たくさんの内容がありますので、早速始めましょう。これはタイトルスライドです。それでは始めましょう。始める前に、これは300レベルのセッションです。200レベルでも400レベルでもありません。つまり、基礎と深い技術的な内容のバランスを取る必要があります。300は中間点のようなものです。VPCが何かわからない人もいるかもしれませんし、私たちよりも詳しい専門家もいるでしょうから、その中間を狙っています。
また、写真アイコンもいくつか入れています。写真を撮るのが好きな方もいますよね。このセッションは録画されています。YouTubeにアップロードされますので、後で確認することもできます。ぜひチェックしてください。いくつかの構成については、かなり速く進めていきますので、写真が撮れなくても落胆しないでください。YouTubeで見られますから。最後に、今年はAWS猫ネットワーキング魔術師が随所に登場します。皆さん、ステッカーをもらえましたか？もらっていない方は、後で声をかけてください。今年は、おまけでクールな猫IPv6ステッカーも用意しました。
Amazon VPCの概要とコンポーネント
このセッションの目的は、ネットワーキングに関する私たちのサービスと機能について話すことです。次に、新しい機能について話します。つまり、過去12ヶ月で何を行ったかということです。そして、高度なアーキテクチャに深く踏み込みます。つまり、いくつかの機能やサービスを組み合わせて1つにするような、皆さんが構築するかもしれないものです。さて、繰り返しになりますが、内容がたくさんあるので、かなり速く進めていきます。基礎について話しましょう。
さて、EC2-Classicは2006年頃、このような感じでした。そして、2010年頃だったと思いますが、Amazon VPCをリリースしました。これは、クラウド上の擬似データセンターまたは仮想データセンターのようなものとして設計されました。すべての顧客が1つ持つと考えていましたが、それは間違いでした。VPC内には、VPC内部のコンポーネントがあります。サブネットやアベイラビリティーゾーンなどです。VPCはリージョンレベルの構成要素です。サブネットはアベイラビリティーゾーンの構成要素です。EC2インスタンスもアベイラビリティーゾーンの構成要素です。これらはすべてリージョン自体の一部です。
VPCについて誰かに「それは何ですか？」と聞かれたら、「プライベートな空間のようなものです」と答えます。基本的にはVPC CIDRで、IPv4かIPv6のいずれかです。そして、CIDRやサブネット、つまりサブネットアドレスをサブネットに割り当てます。IPv4とIPv6のデュアルスタック、あるいはIPv6のみの構成も可能で、これは実際にかなり面白いです。また、インターネットゲートウェイというものもあります。これによってインターネットアクセスが可能になります。IPv6用のEgress-onlyインターネットゲートウェイもあります。VPC内には、ルートテーブルと呼ばれるものがあります。ルートテーブルは基本的にトラフィックの方向を制御します。非常にわかりやすいですね。
Elastic IPがあり、パブリックサービスやインターネットと通信できます。インターネットと通信しないプライベートサブネットを設定することもでき、ゲートウェイエンドポイントなどとプライベートに通信することができます。私たちはこういったゲートウェイ系のものが大好きなんです。これらをVPCに取り付けて、サービスを開発してきました。Network Firewallについては後ほど詳しく説明します。Gateway Load Balancerは、独自のファイアウォールを構築するためのメカニズムです。Egress Security VPC、Application Load Balancer、そしてインバウンドトラフィック用のNetwork Load Balancerもあります。
AWSネットワーキングサービスの進化：VPC Latticeから Cloud WANまで
VPC Latticeは、今年リリースした新しいサービスです。これは素晴らしいサービスで、サービスディレクトリにサービスを登録し、サービスネットワークと呼ばれるものを構築します。Alexがこれについて詳しく説明する予定です。とても興味深い内容になるでしょう。パブリックサービスや、自分で構築したプライベートサービスと通信するためのサービスエンドポイントもあります。さらに、Gateway Load Balancerエンドポイントもあります。VPCへの接続には、VPCピアリングがあります。リージョン間VPCピアリングもあります。2018年にリリースされたTransit Gatewayは素晴らしいサービスで、各リージョンで1つのTransit Gatewayに5,000のVPCを接続できます。
また、Transit Gatewayをリージョン間でピアリングすることもできます。あるいは、これらのTransit GatewayをCloud WANで置き換えたり、一緒に使用したりすることもできます。Cloud WANはグローバルに展開できます。VPN接続やDirect Connect、AWSへの物理的な光ファイバー接続も可能です。必要に応じて、Cloud WANをTransit Gatewayに接続することもできます。
Transit Gateway Connectは、お客様のSD-WAN展開をAWSにブリッジするために構築されました。もちろん、SD-WANのヘッドエンド用と同様に、Cloud WANをCloud WAN Connectに接続することもできます。そして、Cloud WAN用のDirect ConnectとVPNもあります。これで基礎の部分はほぼ終わりですので、皆さん同じレベルの理解ができたのではないでしょうか。
クライアントVPN接続も可能です。EC2 Instance Connectを使えば、AWSコンソールを通じて環境内のインスタンスに接続できます。そして最後に、AWS Verified Accessがあります。 これは、VPC内のアプリケーションへのゼロトラストフロントエンドです。さて、大きな疑問は、これらすべてを1枚のスライドに収められるかということです。答えは、もちろんイエスです。こちらがそのスライドです。 このスライドは本当に大変でした。皆さんに気に入っていただけて嬉しいです。では、次に進みましょう。Alexさん、IPアドレス管理について説明をお願いします。
Amazon VPC IPAMの新機能と無料枠の導入
はい、先ほどのスライドで示したものをすべて構築したいのですが、そのためには正しい方法で始める必要があります。そして、IPアドレス管理から始めなければなりません。Mattが展開の機能について話しましたが、当初は誰もが1つのVPCを持つと考えていました。しかし、それは間違いでした。 お客様は複数のVPC、時には多数のVPCを持っており、それは多くのIPアドレス管理を意味します。
では、なぜIPアドレス管理がそれほど重要なのでしょうか？それは、優れたIPアドレス管理の仕組みがいくつかの重要なことを可能にするからです。 まず、私たちは皆、パブリックIPv4の枯渇と戦っています。パブリックIPv4アドレスの使用状況を理解し、最適化する方法は、非常に優れたIP管理ツールによって実現されます。次に、プライベートIPv4の枯渇があります。非常に大規模な企業では、RFC 1918のアドレス空間が不足しつつあると言っています。多くの場合、これは不適切なIP管理が原因で起こります。コスト最適化も重要な要因です。IPv6のような技術をコスト最適化やスケールのために採用する方法、不適切なアドレス割り当て方式による支出を最小限に抑える方法も、IP管理に関連しています。そして最後に、グローバル展開があります。より多くのAWSリージョンにグローバルインフラストラクチャの展開を始めることを考えてみてください。それらはVPCから始まり、IP管理によって実現される接続から始める必要があります。
そのためのツールがあります。Amazon VPC IPAMと呼ばれるものです。 これにより、大規模なIPv4およびIPv6の管理が可能になります。IPアドレスの履歴情報を活用できます。IPアドレスの割り当て方法に独自のビジネスロジックを実装することができます。そしてもちろん、これはIPv4とIPv6の両方に対応しています。
昨年もIPAMについて少し話しましたが、今年は新しいリリースがいくつかあるので、それらを見ていきましょう。まず、IPAMを組織外のアカウントと統合できるようになりました。これは、合併や買収などの理由から、お客様から長年要望されていたものです。そして、IPアドレスの使用状況に関する詳細な洞察を得ることができるようになりました。IPAMのこのコンソールには、IPアドレスがどこで使用されているか、準拠しているVPCの数、重複するIP空間を持つVPCの数、管理されているVPCと管理されていないVPCの数が正確に表示されるので、非常に興奮しています。また、使用率の観点から見たトップのサブネットやトップのVPCについても、非常に詳細な洞察を提供します。とても素晴らしいダッシュボードですね。
IPAMからも素晴らしいニュースがあります。私たちは常に、お客様が必要なツールを最適なコストポイントで使用できるよう、適切な対応を心がけています。そこで、Amazon VPC IPAMが無料枠を開始しました。リージョンとアカウントごとに、IPAMのすべての機能にアクセスできるようになりました。 これにより、IPスペースの設定と管理が可能になります。また、リージョンとアカウントごとに独自のIPを持ち込むこともできます。さらに、AmazonからIPv6アドレスや連続したCIDRを取得することも可能です。これは、IPv6を採用するお客様にとって非常に重要な機能です。なぜなら、連続したアドレス指定が可能になり、より効率的なIPアドレス管理ができるからです。
パブリックIPv4アドレスの使用状況を把握することの重要性について、先ほど説明しました。IPAMとその無料枠の一部として、クロスリージョンとクロスアカウントをサポートするパブリックIPインサイトを提供しています。パブリックIPインサイトを使用すると、どのタイプのアドレスをどこで、なぜ使用しているかを確認できます。パブリックIPインサイトには包括的なコンソールも用意されています。 これらのアドレスをパブリックIPアドレスタイプ別に使用している状況を表示し、 それらのパブリックIPv4アドレスに関連するセキュリティグループやネットワークインターフェイスに関する詳細情報を提供します。これにより、最適化に必要な適切な情報を確実に得るためのツールが手に入ります。
IPv6アドレス指定に関して言及した重要な側面の1つが集約です。なぜそれが重要なのか疑問に思うかもしれません。IPv4では、 RFC 1918ルートを使用してプライベートIPv4スペースを簡単に集約できました。しかし、IPv6では状況が異なります。AWSでは、多くのVPCにわたってグローバルユニキャストアドレスが設定されており、それらが集約されていないと、ルートテーブルが非常に大きくなってしまいます。IPAMを使用すると、 リージョンごとにアカウントで連続したCIDRを取得し、そのリージョンにある全てのVPCをその連続したスペースでアドレス指定できます。 これにより、ルーティングが大幅に簡素化されます。
今年のもう一つの重要なIPv6関連の発表は、 VPC内でIPv6アドレスを階層化する機能です。以前は、VPCが/56、サブネットがデフォルトで/64でした。現在では、VPCのCIDRサイズとサブネットのCIDRサイズを選択できるようになりました。 後ほど詳しく説明しますが、非常に重要な機能の1つがインターフェイス上のプライマリIPv6アドレスです。 EC2インスタンスとそのElastic Network Interfaceを考えてみましょう。 最初に関連付けるIPv6アドレスを、プライマリとして設定できるようになりました。これで基礎が整いました。では、構築を始めましょう。
VPCネットワーキングの拡張と接続性：VPC sharingからIGWまで
VPCネットワーキングの側面について話しましょう。これは今日のセッションの第3章です。VPCとネットワーキングについて考える際、主に2つの方法があります。1つはVPCの境界を拡張すること、もう1つはVPC自体に接続することです。 これらが接続性に関する2つの主要なアプローチです。基本的に、ネットワーキングはアプリケーション同士を接続し、ルーティングすることに関するものです。
まず、VPC sharingについて説明しましょう。 VPC sharingの背景にある考え方は、ネットワーキングチームがVPCやサブネットを含む環境を制御・構築できるようにしながら、他のアカウントやプリンシパルがそのVPC内にインフラストラクチャやアプリケーションをデプロイできるようにすることでした。VPC sharingは現在多くの顧客が利用している機能で、Lambda、EC2、その他のサービスを他者のVPC内にデプロイすることができます。 VPCを共有する所有者として、Internet Gateway、ルートテーブル、エンドポイントなどの要素を制御し続けることができますが、そのVPCの参加者にはその制御権がありません。
重要な問題は、VPC sharingのような機能を使ってVPCを拡張するか、単一のVPCのサイズを大きくするか、それとも複数のVPCを作成するかということです。一部の顧客は多数のVPCを作成することを選択しています - 最近、デプロイメントに4,000以上のVPCを持つ顧客に遭遇しました。これは二者択一の状況ではないことに注意してください。両方の戦略を採用することができます。個別のVPCや単一のVPCを、私たちが「hyperscale VPC」と呼ぶものと比較すると、個別のVPCはVPCの分散ネットワークを作成し、共有VPCはhyperscale VPCまたは単一のVPCになる可能性があります。
VPC内には、Network Address Unit（NAU）と呼ばれる測定単位があります。これについては昨年簡単に説明しました。基本的に、1つのIPアドレスが1つのNAUを消費します。単一のVPC内で最大256,000の使用中IPを持つことができ、共有VPCでは512を持つことができます。
そのため、共有VPCのルートを選択する場合は、Network Address Unitの消費について考える必要があります。各アプリケーションに個別のVPCを使用し、多数のVPCを持つルートを選択する場合は、それらを相互に接続する必要があります。多数のVPCを持つことを考えると、影響の範囲を狭めることになります。 誰かがVPC内のルートテーブルを誤設定した場合、1つのアプリケーションが影響を受けます。共有VPCを持っていて誰かがルートテーブルを誤設定した場合、考慮すべきより大きな領域があります。
今年、私たちはマルチVPCの領域に直接関係する機能もリリースしました。これにより、マルチVPC接続が可能な elastic network interface を持つことができるようになりました。 つまり、elastic network interface が別のVPCに存在できるようになったのです。これは依然として同じAWSアカウント内、同じアベイラビリティーゾーン内にありますが、実際にはインスタンスを別のVPCにドロップできる素晴らしい機能で、peeringやtransit gatewayを管理する必要がありません。
さて、VPCへの接続方法についてですが、様々なメカニズムがあります。まず最初はインターネット接続です。このセクションの最後には興味深いアーキテクチャがあります。 基本的に、VPC内にはAvailability Zoneとパブリックサブネットのルーティングがあります。インターネットゲートウェイ、あるいはIPv6用のEgress-onlyインターネットゲートウェイと通信します。 プライベートサブネットでは、NATゲートウェイを使ってインターネットと通信することがあります。しかし結局のところ、すべてはサブネットごとのルーティングに帰結します。
ここで、NATゲートウェイについて具体的に話しましょう。今年、新機能がリリースされ、 NATゲートウェイに最大8つのIPアドレスを関連付けられるようになりました。実際にトラフィックをこれらのIPアドレス間でフローハッシュします。なぜこれが必要なのでしょうか？元々、NATゲートウェイは1つのアドレスしか持てず、1つのアドレスでNATゲートウェイを通じて55,000の同時接続が可能でした。今では8倍になりました。8つのIPで455,000の同時接続が可能になったと思います。これは、顧客がNATゲートウェイのデプロイメントをスケールアップしたいという要望に応えたものです。
また、Local ZoneでもNATゲートウェイが利用可能になりました。私はしばらくOutpostサービスチームで働いていましたが、非常にエキサイティングな時期でした。そのチームの信条の1つは、Local ZoneとOutpostsでリージョンと同じ体験を提供することでした。そのため、すべてのサービスをLocal Zoneに導入しようとしています。今回の場合、LAのLocal ZoneでNATゲートウェイが利用可能になりました。今後、さらに多くのサービスがLocal Zoneにデプロイされることを期待しています。
そして、先ほど言及した興味深いアーキテクチャがこちらです。IPv6を使用している顧客もいます。これは素晴らしいことです。彼らはTransit Gatewayやピアリングの代わりに、VPC間の相互接続メカニズムとしてIGWを使用しています。これはNATが不要なので問題ありません。 この場合、VPC内のホストがパブリックサービスと通信したり、IGWからIGWへ通信したりすることができます。あるいは、ホストからEgress IGWまたはEIGWを経由して外部へ一方向通信や内部発信通信を行うこともあります。または、IGWを介して別のVPCと通信することもあります。つまり、基本的にIGWをTransit Gatewayとして使用しているのです。 IPv6の場合、すべてがパブリックアドレスなので、これは非常に簡単に実現できます。
AWS PrivateLinkとVPC Latticeによるアプリケーションネットワーキング
次の接続メカニズムは、AWS PrivateLinkです。長い間、これは私のお気に入りのサービスの1つでした。なぜなら、リリース時には、サービスを他の人のVPCにドロップしたり、他の人のVPCからサービスを利用したりする機能がありました。しかし、最初のユースケースは、サービス接続用のインターフェースエンドポイントと呼ばれるもので、基本的にすべてのパブリックサービスへのプライベート接続をVPC内で可能にしました。最初は約30のサービスから始まりましたが、現在では150以上のサービスがVPC内のインターフェースエンドポイントを介してプライベートに通信できるようになっています。
PrivateLink についてもう少し詳しく説明しましょう。PrivateLink のインターフェースエンドポイントは、実際には VPC 内の 2 つの異なるサブネットに 2 つの Elastic Network Interface を持っています。これらは VPC 内の IP アドレスを実際に消費します。ここでは、別の VPC 内のサービスとも通信する PrivateLink のトポロジーを示しています。今年新たに導入したのは、これらのアドレスを定義する機能です。つまり、PrivateLink インターフェースエンドポイントに対して、VPC 内で使用する特定の IP を指定できるようになりました。繰り返しになりますが、これは VPC 内のプライベート範囲です。このような制御が強化されるのは良いことですね。
さて、他の VPC との接続性について、Alex に説明してもらいましょう。では、スケールアップについて考えてみましょう。まず 1 つの VPC から始めて、個別または共有の VPC をさらに作成していきます。
そして、それらの間の接続を確立する方法を考えます。いくつかのオプションを見てきましたが、ここでそれらについてもう少し詳しく掘り下げていきます。
最初のオプションは VPC ピアリングです。これは VPC の基本的な接続オプションです。2 つの VPC 間の 1 対 1 の接続で、リージョン内 VPC ピアリングとクロスリージョン VPC ピアリングの両方が可能です。VPC ピアリングで顧客に最も好評な機能の 1 つは、セキュリティグループの参照機能です。これは、VPC 内のリソースに関連付けられたセキュリティグループで、インバウンドまたはアウトバウンドトラフィックに対して、ピア VPC 内のセキュリティグループ ID への参照を実際に追加できるということです。
VPC ピアリングのユースケースと、VPC ピアリング以降に説明する内容が VPC ピアリングの使用を排除するものではないという点を覚えておくことが非常に重要です。VPC ピアリングは非推移的であり、1 対 1 の関係であることを考慮する必要があります。ルーティングの設定が必要で、セキュリティグループの参照によって細かなセキュリティアクセスが可能になります。しかし、これはどのようにスケールするのでしょうか？さらに掘り下げてスケールアップする場合、どのように対応すればよいのでしょうか？
ここで Transit Gateway の出番です。Transit Gateway は、リージョン内に集中化されたルーティングハブを提供し、 そこに数千の VPC を接続できます。しかも、VPC ピアリングを完全に諦める必要はありません。Transit Gateway は 2018 年にリリースされましたが、これは私にとって最も興奮した re:Invent の一つでした。今年で私の参加は 5 年目になります。
接続性の観点から見ると、 Transit Gateway はリージョン内で IPv4 と IPv6 の両方を大規模にルーティングすることができます。Transit Gateway の構成要素には、 ネットワークを分割できるアタッチメントとルートテーブルが含まれています。VPC から学習したルートを自動的にルートテーブルに伝播させることができます。また、必要に応じて静的ルートを設定することもできます。さらに、ネットワークセグメンテーションを作成する機能もあります。 つまり、Transit Gateway へのアタッチメントと、これらに関連付けられたルートテーブルを選択して、例えば本番環境と開発環境を分離することができるのです。
AWS Cloud WANとTransit Gatewayによるグローバルネットワーキング
先ほど、VPC ピアリングを諦める必要はないと言いましたが、VPC ピアリングと Transit Gateway を併用することができます。 そして、後ほど見ていきますが、ユースケースに応じたアーキテクチャでは Cloud WAN も使用できます。では、なぜ両方を使うのでしょうか？高スループット、低レイテンシーの通信、コスト最適化のためです。その通りです。VPC ピアリングは AZ 内のデータ転送コストが無料なので、賢く使いましょう。
スケーラビリティの面では、ハイブリッド接続、リージョン間接続、SD-WAN 接続のいずれかにアクセスする必要がある数千の VPC がある場合、Transit Gateway または Cloud WAN を使用します。そして、この 2 つを組み合わせることができるという事実を考えてみてください。Transit Gateway ルーティングの階層構造 と、VPC ピアリングがもたらす最適化された接続を活用できるのです。また、両者のスケーリング と、ユースケースに応じた両者の使い方を考慮に入れてください。
さて、ハイブリッド接続に話を進めると、Direct Connect があります。Direct Connect は AWS から提供される専用接続 です。お客様だけが使用する物理的な接続で、データセンターと AWS 間のルーティングと到達可能性を実現します。 昨年は、お客様により近づくことに注力しました。お客様のデータセンターがある場所により近づくために、Direct Connect の拠点を 130 か所以上に増やしました。
しかし、私たちはそこで止まりませんでした。Direct Connect では、複数のタイプの仮想インターフェースを利用できます。 最初のタイプは private virtual interface で、これが Direct Connect の最も基本的な導入方法です。次に Direct Connect gateway があり、これを使用すると複数のリージョンにまたがる VPC を同じ Direct Connect 仮想インターフェースに接続できます。
これらのインターフェースタイプに基づいて、今年はクォータを増やしました。 現在、AWS Direct Connect gateway あたりの virtual private gateway の数が、以前の10から最大20まで増加しています。また、public virtual interface を使用して AWS のパブリックサービスエンドポイントにアクセスすることもできます。ただし、これは基本的に AWS 上のすべての人にアクセスを提供するため、適切にセキュリティを確保してください。AWS の公開 IP アドレスが得られます。AWS Direct Connect と AWS Transit Gateway は、Direct Connect gateway と Transit VIF を通じてネイティブに統合されています。今年、Direct Connect 接続あたりの transit virtual interface の上限を4つまで、Direct Connect gateway あたりの transit gateway の上限を6つまで増やしました。 また、AWS からオンプレミスにアドバタイズされるルートの数も増やし、現在は IPv4 と IPv6 を合わせて200になりました。
さて、ここからが楽しみな部分です。 これらすべてを組み合わせて、AWS Cloud WAN でグローバルな接続性を次のレベルに引き上げます。 Cloud WAN については、リリース以来すべてのセッションで話してきました。Cloud WAN は、このグローバルな接続メカニズムを提供し、 AWS のグローバルバックボーンを活用することができます。インターネットを経由せずにプライベートな接続を提供します。また、接続性に関する意図を表現することができ、その意図が Cloud WAN ポリシーを通じてどのように表現されるかを見ていきます。さらに、ネットワークの可視性を一元的に管理できます。この分野では多くのエキサイティングな開発が進行中なので、注目してください。
Cloud WAN のコンポーネントを見て、Cloud WAN で何を構築できるかを振り返ってみましょう。最初のコンポーネントは core network policy です。 このポリシーを使用すると、JSON 形式でネットワーク接続の意図を表現できます。まず、 core network edge が使用する autonomous system number の範囲を指定します。次に、Cloud WAN を展開したい AWS リージョンを指定します。そして、attachment policy を指定します。 後ほど見ますが、Cloud WAN へのすべての attachment は、これらのポリシーに基づいて Cloud WAN セグメントに関連付けられ、伝播されます。ここでネットワーク構成を制御し、一元的な管理を実現します。
複数の attachment rule を設定できます。Cloud WAN は各リージョンで core network edge を使用し、これらの core network edge は自動的にピアリングされ、Border Gateway Protocol (BGP) を使用して動的にルートを交換します。これらの core network edge はそれぞれトランスポートを作成し、その上にネットワークセグメントを設定できます。これらのセグメントは本質的にグローバルルートテーブルです。 Cloud WAN で設定されたセグメントを、Cloud WAN で定義されたすべてのリージョンにまたがるグローバルなものにするか、リージョンローカルなセグメントにするかを選択できます。この機能は、データのローカリティを必要とし、通信がそのリージョン外に出ないようにする必要がある地域や国を扱う顧客にとって特に有用です。
さらに、各アタッチメントはアタッチメントタグに基づいて関連付けられ、伝播されます。これはVPCタグとは異なります。アタッチメントを作成する際、そのアタッチメントタグを指定するオプションがあります。Cloud WANでは、アタッチメントの扱い方を定義できます。Cloud WANが自動的にアタッチメントを受け入れるか、受け入れのためのパイプラインを設定するかを選択できます。興味深いことに、タグを変更すると、Cloud WANはそのアタッチメントの新しいタグを再分析し、適切なセグメントに再マッピングします。これにより、ネットワークの継続的インテグレーションと継続的デプロイメントのメカニズムが提供されます。
Direct ConnectとCloud WANの統合：ハイブリッド接続の進化
VPCアタッチメントは、Transit Gatewayアタッチメントの仕組みと非常によく似たネットワークインターフェースを使用します。繰り返しになりますが、AWS Cloud WANアタッチメントはTransit Gatewayアタッチメントと非常によく似た動作をします。
VPCにCloud WANアタッチメントのサブネットを指定する必要があります。これは、私たちが新しくリリースした機能にとても役立ちます。 VPCの観点からは、VPCルーティングを設定する必要があります。Cloud WANは、セグメント内で学習したルートをVPCルートテーブルに自動的に伝播しません。なぜなら、VPC境界はネットワーク境界として機能し、VPC内でルーティングしたいものを制御する権限をユーザーに与えるからです。
冒頭で触れたconnectアタッチメントは、お客様がSD-WANアプライアンスをVPCやグローバルネットワークにネイティブに統合できるようにするもので、connectアタッチメントと呼ばれる新しいタイプのアタッチメントを使用します。connectアタッチメントにはトランスポートアタッチメントを指定する必要があります。Cloud WANでは、そのトランスポートアタッチメントはVPCアタッチメントです。このトランスポートアタッチメントの上にconnectアタッチメントを作成し、さらにその上にconnectピアを作成します。connectピアのデフォルトのカプセル化はGRE（Generic Routing Encapsulation）です。
お客様からのフィードバックを受けて、私たちはトンネルレスconnectをリリースしました。 これは、GREトンネルのカプセル化オーバーヘッドなしで、クラウド対応のSD-WANをネイティブに実現します。VPC内のCloud WANインターフェースを直接使用して、Cloud WANとBGPピアリングを行うことができます。 では、その仕組みを見てみましょう。同じトランスポートアタッチメントがあり、同じconnectアタッチメントがあり、そしてトンネルレスconnectピアを作成します。
ここで非常に重要なのは、各 Connect ピアが冗長性のために2つの BGP セッションを持つことです。同じ Connect アタッチメントを介して、GRE トンネルとトンネルレスの両方の Connect ピアを持つことができます。Connect アタッチメントと Transport アタッチメントは、Cloud WAN 上で同じルートテーブルの一部である必要があります。この場合、それは Production です。SD-WAN アプライアンスがアタッチメントのサブネット外にデプロイされている場合、Cloud WAN が BGP を通じてアドバタイズするルートに対して VPC 内でルーティングを設定する必要があります。そのため、ルーティングをシームレスにするために、これらのアプライアンスを Cloud WAN アタッチメントのサブネット内にデプロイすることをお勧めします。
さて、お客様から非常に要望の多かった機能の1つが、アプライアンスモードです。 アプライアンスモードを使用すると、インスペクションを通じてルーティングする際に AZ の対称性を維持できます。Cloud WAN を使用したデプロイメントを見てみましょう。集中型インスペクションでは、インスペクションを行いたい各リージョンにインスペクションセグメントをデプロイします。インスペクション VPC があり、 その VPC 内に AWS Network Firewall または Gateway Load Balancer を利用したアプライアンスをデプロイします。ここで重要なのは、ウィザードからの注意点として、インスペクションセグメントはグローバルですが、リージョナルなアタッチメントのみを持つということです。
では、ルーティングはどのようになっているでしょうか？ Production、Development、その他のセグメントとインスペクションセグメントの間でセグメント共有が行われます。インバウンドトラフィックの場合、パケットフローは比較的単純です。インスペクションは Network Firewall または Gateway Load Balancer エンドポイントを通過します。リターントラフィックやインターネットから開始されたトラフィックも、インスペクションアプライアンスを経由して VPC に戻ります。 では、クロスセグメントの場合はどうでしょうか？ここでアプライアンスモード機能が非常に重要になります。
VPC インスペクションアタッチメントでアプライアンスモードが有効になっており、ルートテーブルが少し変更されていることがわかります。その理由は、 クロスリージョンの場合に対称性を維持する必要があるからです。リージョン内の VPC 間、クロスセグメントの通信は比較的単純です。これはリターントラフィックです。クロスリージョンの場合、その対称性が重要です。なぜなら、 ファイアウォールエンドポイントが一方向のトラフィックを見ていない場合、逆方向の同じトラフィックに対して何をすべきかわからないからです。ここで、両方のリージョンでトラフィックをインスペクションして両方のファイアウォールエンドポイントがトラフィックフローを確認できるようにするか、選択できます。
あるいは、1つのリージョンでのみトラフィックをインスペクションしたい場合は、AWS Cloud WAN を使用できます。Cloud WAN を Transit Gateway インフラストラクチャにネイティブに統合できます。 これは実際、非常に興味深い統合です。なぜなら、すべてのお客様が初日から Transit Gateway から Cloud WAN にすべての VPC を移行したいわけではないからです。 そのため、Cloud WAN を使用して接続性を統合できます。Transit Gateway から Cloud WAN へのルートテーブルアタッチメントがあり、すべてのルーティングは完全に動的です。 結果として、AWS Cloud WAN と Transit Gateway の両方を使用してセグメント化されたグローバルネットワークを作成することになります。
これはまた、Cloud WANとのDirect Connect統合も可能にします。Transit GatewayやCloud WANとダイナミックにルートを交換し、オンプレミスでそれらのルートをアドバタイズするためにDirect Connect gatewayを使用できます。ここでは、productionとdevelopmentという2つのセグメントがありますが、必要に応じて別のハイブリッドセグメントを使用してそのトラフィックを検査することもできます。これらのフローについて詳しく説明したブログがいくつかあります。
さて、昨年のre:Inventで、私たちは新しい用語を導入しました：application networkingです。 application networkingとは、2つの異なる領域に分かれています。1つ目はアプリケーションデリバリーを支えるElastic Load Balancingです。2つ目はAmazon VPC Latticeで、これは高可用性の接続メカニズムだけでなく、アプリケーション機能も提供します。
Elastic Load BalancingとVPC Latticeの新機能
Elastic Load Balancingについては、非常に重要な機能をリリースしました。これは実際、冒頭で話したインターフェース上のプライマリIPv6アドレスによって実現されています。この機能は、Application Load BalancerとNetwork Load Balancerに対してIPv6インスタンスタイプのターゲットを持つ能力です。 ご覧のように、これを行うには、ENI上にそのプライマリIPv6アドレスが必要です。
デプロイメントの観点から見ると、 皆さんはApplication Load Balancerのデプロイ方法にかなり馴染みがあるでしょう。ロードバランサーサブネットがあり、デュアルスタックをサポートしています。非常に重要なのは、数日前にApplication Load BalancerのmTLSサポートをリリースしたことです。 これは、トラストストアを設定し、そのトラストストアをALBリスナーにアタッチし、ALBリスナーでmTLSを有効にすることで機能します。これにより、クライアントトラフィックは Application Load Balancerによって認証され、必要に応じて追加のビジネスロジックを設定するために、Application Load Balancerはそのすべての情報をターゲットに送り返します。
さて、Network Load Balancerにも今年リリースされた新機能があります。それはセキュリティグループのサポートです。これは、Network Load Balancerに対する最も要望の多かった機能の1つだったと思います。これで、ロードバランサーのENIにセキュリティグループを関連付けることができるようになりました。 ここでいくつか考慮すべき点があります。それは、これらのセキュリティグループを作成時に関連付ける必要があるということです。また、冒頭で言及したセキュリティグループの参照を使用して、ターゲット上でロードバランサーのセキュリティグループを参照し、ロードバランサーからターゲットへのトラフィックのみを許可することができます。
さて、私の一番のお気に入りのトピックであるVPC Latticeに移りましょう。まだ「なぜVPC Latticeなのか？」と疑問に思っている方もいるかもしれませんね。この複雑な図を覚えていますか？これらのコンポーネントを全て構築し、連携させるには、多くのものをデプロイし、管理し、設定する必要があります。そこで、Amazon VPC Latticeが登場します。これはアプリケーションネットワーキング製品で、その複雑さの多くを取り除き、IPアドレスやネットワーキングを気にすることなく、AWSでゼロトラストのサービス間通信を設定できるようにします。ネットワークパスも作成します。アプリケーションネットワーキングとVPC Latticeのユースケースを見てみましょう。
これらのユースケースは、Amazon EKSやKubernetesのファン、そしてネットワークの専門家から高く評価されています。VPC Latticeは、セキュリティ機能やアプリケーションレベルの機能だけでなく、ネットワークレベルの機能も提供します。VPC Latticeで私が最も興奮しているのは、管理者も開発者も同じ設定を見て理解できることです。アプリケーションレベルの人々とネットワークインフラの人々の間の断絶がなくなるのです。
VPC Latticeには、これらのサービスを支える複数のコンポーネントがあります。サービスネットワークは新しい論理的な構造で、新しい論理的な境界です。定義するサービスは、Amazon EC2、AWS Lambda、Amazon ECS、Amazon EKSなど、すべての計算プラットフォームにまたがるデプロイメントモデルを持つことができます。サービスを作成する際、複数のターゲットグループを指定でき、これらのターゲットグループは異なる計算オプションを持つことができます。そして、サービスディレクトリがあります。サービスを作成すると、そのサービスがサービスディレクトリに表示され、AWS Resource Access Managerを使用してサービスを共有したり、サービスネットワークを使用して他のアカウントのサービスディレクトリにサービスを登録したりできます。認証と認可ポリシーは、VPC Latticeレベルでサービスネットワークやサービスに関連付けることができます。
では、VPC Latticeの動作を見てみましょう。これは私のお気に入りのユースケースで、おそらく毎日のように質問を受けるものです：重複するIPスペースを持つネットワーク接続を持つVPCをどのように設定するか？VPC Latticeは完全にネットワークアドレッシングを抽象化し、この問題を解決します。まず、サービスをサービスネットワークに関連付け、次にVPCをサービスネットワークに関連付けて、VPC内のクライアントがサービスを利用できるようにします。認証ポリシーを設定し、パケットの流れを確認します。セキュリティグループ、ネットワークACL、ルートテーブルなど、おなじみのVPCの構成要素はすべて引き続き適用されます。
パケットがVPC Latticeを通過するためには、これらすべてのセキュリティ構成要素によって許可される必要があります。クライアントからサービスネットワークへのパケットの発信から始まります。DNS解決が行われ、クライアントがVPC Latticeサービスのアドレス（IPv4では169.254、IPv6ではULAアドレス）を取得すると、そのパケットが生成されます。パケットは、送信元のセキュリティグループ、ネットワークACL、ルートテーブル、そしてVPC関連付けのセキュリティグループによって許可される必要があります。これはVPC Latticeの最も強力な機能の1つで、階層的なアプローチでセキュリティを使用できます。セキュリティグループ、ネットワークACL、ルートテーブルを諦める必要はなく、それらを相補的に使用できるのです。
トラフィックが許可されると、サービスネットワークに入ります。 サービスネットワークレベルでは、すべての認証ポリシー、セキュリティ設定、ルーティング設定が適用されます。最後に、 パケットは宛先VPCの目的地に到達します。ここでも、セキュリティグループ、ネットワークACL、ルーティングによって許可される必要があります。さて、私たちが興奮している新機能がいくつかあります。多くのお客様からリクエストのあった、共有VPCでのサービスターゲットのサポートが追加されました。 また、Amazon EKSとのネイティブ統合のためのAWS Gateway API controllerの一般提供リリースも行われました。これにより、EKSサービス、CRD、そこで利用可能なすべての構成要素との強力なネイティブ統合が可能になります。さらに、SIGv4aによるアイデンティティヘッダーの伝播も可能になり、その情報をネイティブに伝播させることで、リモートリージョンでの認証が可能になりました。
AWSのネットワークセキュリティ：EC2 Instance Connectの進化
接続性を構築したので、次はそれを安全にしましょう。
かなり素晴らしい機能ですね。AWSでネットワーキングを構築するための機能が多数ありますが、セキュリティは依然としてAWSで私たちが行うすべてのことの中心にあります。 まずは管理者の接続から始めましょう。ユーザーにとっては退屈に聞こえるかもしれませんが、管理者にとっては実際にとても重要です。
Amazon EC2 Instance Connectというものがあります。これは、EC2インスタンスにInstance Connectソフトウェアをインストールすることで、EC2コンソールからそのインスタンスに接続できるというものです。これは、Secure Shell（SSH）を使用してLinuxインスタンスに接続する簡単で安全な方法です。AWS Identity and Access Management（IAM）ポリシーとプリンシパルを使用してSSHアクセスを制御でき、SSHキーの共有と管理の必要性がなくなります。
仕組みはこうです。左側に管理者がいて、コンソールを通じて操作します。パブリックElastic IPを持つEC2インスタンスがあります。そして、コンソール自体からそのEC2インスタンスと通信できます。つまり、インスタンスを管理する必要のあるユーザーにSSHキーを配布するといったことを管理する必要がなくなるのです。
さて、このデザインには一つの欠点がありました。私たちは昨年、その修正に懸命に取り組みました。問題は、インスタンスにパブリックIPv4アドレスが必要だったことです。つまり、パブリックサブネットはInstance Connectを介してアクセス可能でした。 この問題に対処するため、最近Amazon EC2 Instance Connect endpointsをリリースしました。エンドポイント技術を使ってVPCへの接続を確立し、パブリックIPv4アドレスを持たないEC2インスタンスとも通信できるようになりました。
このケースではパブリックIPv4アドレスは不要です。素晴らしいですね。 ネットワークセキュリティに関しては、私はいつも検査のようなことを考えます。VPC内での検査について話しましょう。ここ数年、お客様との対話で繰り返し出てくるアーキテクチャの一つが、出口セキュリティVPCの構成です。お客様は「10個のVPCがあるんだけど、すべてのトラフィックをファイアウォールのようなものを通したい」と言います。
AWS Network FirewallとGateway Load Balancerによる高度なセキュリティ
2020年に、AWS Network Firewallをリリースしました。これにより、統合管理と監視が可能になりました。これは、高度にスケーラブルで柔軟な検査エンジンを内蔵した、クラウドネイティブなトラフィック検査メカニズムです。これはgateway load balancer技術によって支えられており、後ほどgateway load balancerについて話しますが、VPC内にファイアウォールエンドポイントを持つことができるようになりました。
アーキテクチャはこんな感じです。EC2インスタンスがあり、サブネット内のAWSネットワークエンドポイントを経由して、インスタンスへ、あるいはインターネットゲートウェイへとルーティングします。また、NAT gatewayのようなものも同様に配置できます。 つまり、Network Firewallを通過し、NAT gatewayを経由して、パブリックインターネットへ出ていくわけです。NAT gatewayとNetwork Firewallの両方の素晴らしい点は、マネージドサービスであることです。両方ともスケーラブルなので、より多くのインスタンスをNetwork Firewallに送信したり、この場合はNAT gatewayにも送信したりする際に、トラフィックを処理するためのインスタンスを増やす心配をする必要がありません。
実際、Network Firewallには他にもたくさんのデプロイメントオプションがあります。これは本当に一つの選択肢に過ぎません。最近、IPv6サポートもリリースしました。多くのサービスで、これがトレンドになっていることにお気づきでしょう。 v6サポートをリリースしたので、この場合、Network Firewallエンドポイントにv4サブネット、v6とv4のデュアルスタック、またはv6専用サブネットを持つことができます。v6専用は実際、お客様にとって非常に重要です。「VPC環境内でRFC 1918アドレッシングを使用しています。つまり、10や172などですね」と言うお客様がいます。しかし、「VPCの数が多すぎて、AWSの環境とオンプレミスの両方でRFC 1918アドレスが足りなくなってきています」とも言います。
IPv6アドレスのみを使用するサブネットにNetwork Firewallのようなサービスをデプロイする機能は、そういった人々にとって重要です。これにより、彼らが実際にはほとんど持っていないIPv4アドレスをさらに消費することがなくなります。 また、Network Firewallで受信TLS検査が可能になりました。 基本的に、AWS Certificate Managerと統合することで、TLSトラフィックを復号化したり、Network Firewall上でTLS検査を設定したりできます。 受信TLS検査にはいくつかの考慮事項があります。 さらに、Network Firewallで送信TLS検査も可能になりました。これらの機能をNetwork Firewallに組み込んでいるのです。
これらの種類の機能は、Network Firewall、Gateway Load Balancerにわたって構築されています。Network Firewallは内部的にGateway Load Balancerを基盤としているため、基本的に同じファミリーの一部と言えます。ちなみに、Gateway Load Balancerは、検査などのために、サードパーティ製アプライアンスをVPC内に実装する機能です。Network FirewallとGateway Load Balancerは2020年にリリースしました。
私たちは選択肢を提供したいと考えました。そのため、AWS Network Firewallを使用するか、既存のファイアウォールベンダーをVPC内で使用するかを選べるようにしました。ここでGateway Load Balancerが重要な役割を果たします。
Gateway Load Balancerは、VPC内にデプロイして管理する、耐障害性と高可用性を備えたインフラストラクチャです。VPC内にGateway Load BalancerとGateway Load Balancerエンドポイントが含まれます。それは次のようなイメージです。上部にGateway Load Balancerエンドポイントを持つVPCがあります。 トラフィックは1つのインスタンスから別のインスタンスに移動する可能性がありますが、この場合、Gateway Load Balancerエンドポイントを経由してルーティングしています。トラフィックを別のVPC内のGateway Load Balancerに送信し、そこからGENEVEを使用してフローハッシュを行い、下部の検査VPC内のアプライアンス全体にトラフィックを分散させています。
また、Gateway Load BalancerでIPv6もサポートしています。IPv6をあらゆる場所で使用できれば素晴らしいですね。ここで考慮すべき点が2つあります。Gateway Load Balancerでは、Gateway Load Balancerからアプライアンスへの通信にGENEVEトンネリングカプセル化を使用します。この場合、実際にはIPv6をIPv4 GENEVEトンネル内に格納して、アプライアンス自体に送信しています。これは、アプライアンスベンダーと協力して「ファイアウォールベンダーさん、VPC内でこれを使用したいのですが」と相談する必要があります。彼らのサービスをEC2インスタンスまたはソフトウェアとして使用し、Gateway Load Balancerは自分で管理することになります。
では、VPNを使わないアプリケーションアクセスについて話しましょう。私はVPCそのものを囲われた庭のように考えています。これが顧客に非常に好まれている理由です。彼らは「VPCがあり、それが私のペリメーターだ」と言います。VPCがセキュリティメカニズムだと私が言うのを聞くことはまずないでしょう。なぜなら、実際にはそうではないからです。セキュリティは他の要素によって提供されます。しかし、VPCは確かに制御メカニズムです。VPNやDirect Connectを使ってVPCに接続する場合、オンプレミスのアプリケーションにまでその囲われた庭を拡張していることになります。
AWS Verified Access：VPCへのゼロトラストアクセス
顧客が求めていたのは、VPCやその中のアプリケーションに対して、アプリケーションごとに接続する能力でした。つまり、VPC内のアプリケーションへのゼロトラストネットワークアクセスです。最近、AWS Verified AccessをVPC Latticeと共に一般提供しました。re:Inventで昨年発表しましたが、数ヶ月前にVerified Accessが一般提供になりました。ここでのアイデアは、VPCの前にVerified Accessサービスを置いてサービスに接続するというものです。
実際には、このようになります。アプリケーションロードバランサーを持つアプリケーションがあります。アプリケーションとアプリケーションロードバランサーは切っても切り離せません。 そして今、私たちはVerified Accessサービスでそれをフロントエンドすることができます。これはIDプロバイダーやAWS WAFと統合されています。ユーザーは、ブラウザ上のユーザーエージェントを通じて、Verified Accessを経由してアプリケーション自体に接続します。これにより、VPC全体へのアクセスを提供することなく、アプリケーションごとにVPCへのアクセスが可能になります。Direct ConnectやVPNでVPCに接続する場合のようなルーティングやセキュリティグループベースのアクセスとは異なります。
このダイアグラムの拡張に注目してください。これらのサービスにはHyperplaneも使用しています。Hyperplane ENIは、これらのサービスの一部として、そしてVPC内でのデプロイ方法として非常に一般的に見られるものです。Hyperplaneについてもっと知りたい方は、講演後にお話しください。それについて議論しているいくつかの講演をご紹介できます。
AWSインスタンスのネットワーク性能の進化
さて、2023年ですので、この講演に生成AIのセクションを含めないわけにはいきません。ネットワーキングと生成AIについて話しましょう。 2010年頃だったと思いますが、1秒あたり1ギガビットのC1インスタンスがありました。「すごい、1ギガのバーチャルマシンやEC2インスタンスが持てるんだ」と思ったのを覚えています。 その後しばらくして、クラスター計算用のCC1インスタンスをリリースしました。これは1秒あたり10ギガビットを処理できました。
2013年と2015年にC4インスタンスでこれを拡張し、Enhanced Networkingによって1秒あたりのパケット数を増やし、10Gbpsを提供しました。また、EBSストレージも最適化されるよう、EBS最適化をデフォルトで有効にしました。
そこからさらに進化を続けました。2015年頃にC5インスタンス、そして100Gbpsのネットワーク最適化インスタンスであるC5nを導入しました。想像してみてください。
以前、アジア太平洋地域のある国のインターネットバックボーンを管理していましたが、その国全体で80Gbpsでした。それが今では、2016年頃に導入されたと思われるC5nインスタンス1台で実現できるのです。私たちがどれほど進歩したかを考えると驚きます。そこからさらに改善を重ね、現在ではC7gnで200Gbpsを実現しています。
これらのスライドとボックスはおおよそ縮尺通りなので、これらのインスタンスファミリー間の帯域幅の違いがよくわかります。
生成AIを支えるAWSの高性能ネットワーキング技術
2020年には、クラウド初の400Gbps/インスタンスを実現したP4dをリリースしました。これが、私たちが「UltraCluster 1.0」と呼ぶものを構築した時期です。Steven Callahan（私たちはStev Calと呼んでいます）による素晴らしい講演がYouTubeで公開されています。ぜひチェックしてみてください。彼はUltraClusterアーキテクチャについて話しており、非常に興味深い内容です。基本的に、生成AIや大規模言語モデルのトレーニングのために、データセンターやキャンパス内にP4dインスタンスの専用クラウドネットワークを構築し始めました。
ここで、AI/MLワークロードが本格的に登場しました。
2022年には800Gbps/秒のTRN1が導入され、さらに印象的になりました。今年リリースされたTRN1nは1,600Gbps/秒を実現しています。数日前に発表されたP5は3,200Gbps/秒を提供します。
TRN2は信じられないほどの6,400Gbps/秒/インスタンスを実現しています。まだこれらを実際に起動して試す機会がありませんが。
ちなみに、他のインスタンスもまだこのスライドに含まれています。ただ、比較するとほんの小さな点になってしまうほどです。はるか下の方にあります。このように、ネットワーキングとそれをサポートできるインスタンスを通じて、生成AIを可能にしています。
UltraCluster 2.0アーキテクチャでは、 基本的に、データセンターでクラウドネットワークを構築するための全く新しいネットワーク設計を導入しました。
データセンターのネットワークを平坦化し、広帯域化することで、このような接続性を実現しました。データセンター全体で10倍の帯域幅と、ノンブロッキングの容量を確保しています。 また、独自のルーティングプロトコルも開発しました。SIDRと呼んでいますが、これはデータセンターでBGPやOSPFに代わるものです。従来のプロトコルが私たちのニーズを満たせなかったからです。 本当に素晴らしい技術です。
では、これがお客様にとってどういう意味を持つのでしょうか。私たちはSRD（Scalable Reliable Datagram）というプロトコルも開発しました。 これをENA Expressと呼んでいます。データセンターの一般的な経路を見ると、TCPフローハッシングによってホットスポットが発生する可能性があります。 SRDを使えば、データセンター内でフローレットのフローハッシングを行うことができます。これは非常に素晴らしい技術で、特別な設定は必要ありません。SRDまたはENA Expressをサポートするインスタンスを使うだけです。
今年、私たちはこの技術を58のインスタンスタイプに拡大しました。この種の技術を利用したいお客様にとって、これは大きな進歩です。 本当に印象的です。
Amazon Qを活用したネットワークトラブルシューティング
次に、Amazon Qを使ってお客様の視点からネットワークのトラブルシューティングがどのように行われるかを見てみましょう。これは本当にワクワクする話です。 ここに、ネットワークが機能していない壊れたアーキテクチャがあります。AZ1のインスタンスにSSH接続できず、 アプリケーションサーバー同士も通信できません。Amazon Qを使って調査してみましょう。これは現在プレビュー版なので、皆さんも試すことができます。コンソールの右側に小さなウィジェットがあり、そこで質問を入力できます。
この場合、「なぜAZ1のWebサーバーにSSH接続できないのか」と尋ねてみましょう。Amazon Qは、VPC Reachability Analyzerを使って、私たちが何を尋ねているかを理解します。 そして、必要なトラブルシューティングの手順を示してくれます。 何も設定されていないセキュリティグループを実際に表示してくれます。データベースアクセスについても、アプリケーションがデータベースと通信できない理由を示してくれます。
再度質問すると、数秒後に、ネットワークACLが適切に設定されていないと教えてくれました。このようにして、Amazon Qを使ってネットワークの問題を解決しました。このことについてのブログ記事を読んで、ぜひご感想をお聞かせください。
ネットワークの問題を解決しましたが、いくつか注意点があります。
これらの注意点もブログに記載されています。これはプレビュー機能なので、質問できる回数に制限があり、24時間ごとにリセットされます。
セッションの締めくくり
時間になりましたので、ご参加いただきありがとうございました。
アンケートへのご協力もお忘れなく。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion