re:Invent 2024: AWSアプリケーションネットワーキングの最新アップデート
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - AWS application networking: Build simple, secure, and reliable apps (NET317)
この動画では、AWSのアプリケーションネットワーキングサービスの最新アップデートについて、Elastic Load BalancingとAPI GatewayのプロダクトリーダーであるSathya RamaseshanとYousef Ourabiが解説しています。Elastic Load Balancing、Amazon API Gateway、AWS PrivateLink、Amazon VPC Latticeの4つの主要サービスについて、それぞれの特徴や使い分けを詳しく説明し、新機能としてPrivateLinkでのUDPサポート、クロスリージョンPrivateLink、VPC LatticeのネイティブECSサポート、Cross VPC Resource Endpointsなどの発表を行っています。特にPrivateLinkは198以上のAWSサービスをサポートし、MongoDBやTeradataなど多くのサードパーティプロバイダーとの連携も実現しており、エンタープライズでの活用が進んでいることが分かります。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
アプリケーションネットワーキングの概要と本セッションの目的
みなさん、こんにちは。私はElastic Load BalancingとAPI Gatewayのプロダクトリーダーを務めるSathya Ramaseshanです。本日は、API Gateway、AWS PrivateLink、そしてAmazon VPC LatticeのエンジニアリングリーダーであるYousef Ourabiと一緒に、私たちが担当するサービスについての最新情報を皆様と共有できることを大変嬉しく思います。
これは300レベルのクラスです。まず私から、アプリケーションネットワーキングという用語の定義と、ポートフォリオに含まれる全サービスの概要について説明させていただきます。このセクションの目的は、各サービスの相対的な位置づけを理解していただき、アーキテクチャに基づいて適切なサービスを選択できるようにすることです。その後、詳細なセクションに移り、私がElastic Load Balancingについて説明し、その後Yousefが残りの部分をカバーします。ネットワークがアプリケーション開発をどのように簡素化できるかに興味をお持ちのアプリケーション開発者、ネットワークエンジニア、またはIT専門家の方々にとって有益な内容となることを願っています。
ネットワーク管理者と開発者のニーズに応えるAWSサービス
AWSでは常にお客様を起点に考えており、今回は特にネットワーク管理者と開発者という2つのペルソナに焦点を当てています。私たちの考えでは、ネットワーク管理者は制御を失うことなく開発者に権限を与えたいと考えています。そのために、アプリケーションを接続し、セキュリティを確保するための一元化されたツールセットが必要です。例えば、ネットワーク管理者はネットワーク内の2つのIP間の接続方法や通信のセキュリティを重視しますが、それらのIPの背後にある内容については必ずしも気にしません。一方、開発者はネットワークではなくアプリケーションを重視します。彼らはできるだけ効率的にアプリケーションを構築したいと考えています。つまり、ビジネスロジックをできるだけ効率的に構築したいのです。先ほどの例を拡張すると、開発者はアプリケーションの機能とパフォーマンスを重視し、それが解決するIPやそれが配置されているサブネットについては気にしません。
そこで、アプリケーションネットワーキングは、これら2つのペルソナが協力して、フルマネージド型のAWSサービスを使用して、高度にスケーラブルで信頼性が高く、パフォーマンスが優れ、セキュアなアプリケーションを構築するための接着剤となります。 現在、このトピックをカバーするAWSポートフォリオの主要サービスは、Elastic Load Balancing、Amazon API Gateway、AWS PrivateLink、そしてAmazon VPC Latticeです。これら4つのサービスを結びつける共通点は、その必要な機能にあります。可用性とスケールは、AWSのすべてのフルマネージド型サービスの基本的な機能です。私たちのサービスでは、それぞれが受け取るトラフィックに基づいて自動的にスケールし、リージョン内のすべてのAZにデプロイすることができます。可用性とスケールに加えて、これらのサービスはそれぞれアプリケーションの接続、セキュリティ確保、監視が可能です。これらの機能はサービスごとに異なるレベルで提供されており、このトークを通じて継続的に探っていきます。
メンタルモデルを構築するために、皆さんがご存知かもしれないOSIモデルのシンプルバージョンであるTCP/IPモデルについて説明させていただきます。このモデルは、2つのシステム間の通信を可能にするためにネットワーク層がどのように相互作用するかを説明しています。最下層のネットワークアクセス層から始まる4つの層があります。これは物理層であり、実際には今日のトークではカバーしない層です。その上にネットワーク層があり、ここで各パケットにIPが追加されます。この層にはIP認識があり、ルートテーブルを使用して宛先にパケットが転送されます。その上にトランスポート層があり、TCPまたはUDPプロトコルに基づいて送信者と受信者の間でパケットが送信されます。この層では、接続、フロー、ポートの認識があります。最上位にアプリケーション層があり、これはリクエスト-レスポンス層です。
具体例を見ていきましょう。クライアントがサーバーからリソースを取得するリクエストを作成する場合を考えてみます。まず、アプリケーション層からトランスポート層に移動し、そこでプロトコルに基づいてパケットに分割され、ポートが追加されます。次にネットワーク層で各パケットにIPが付与され、物理層を通じて目的地までパケットがルーティングされます。目的地では、受信側がまずIPを取り除き、トランスポート層に送って選択したプロトコルに従ってパケットが正しい順序で受信されたことを確認し、ポートを取り除いて、最後にアプリケーション層に送ります。そこでパケットがサーバーが応答できるリクエストの形に組み立てられます。アプリケーションネットワーキングのサービスのほとんどは、トランスポート層かアプリケーション層のいずれかに分類されます。
トランスポート層のサービス：NLB、PrivateLink、GWLBの特徴
トランスポート層のサービスについて説明しましょう。 最初に紹介したいのは、Network Load Balancer（NLB）です。これは接続レベルのロードバランサーで、インスタンスやコンテナをターゲットとして、TCPコネクションとUDPフローの両方のロードバランシングが可能です。
Network Load Balancerは、VPC内のサービスをインターネットに公開したり、VPC内でクライアントとターゲット間の接続を提供する内部ロードバランサーを構築したりする際に、非常によく使用されています。NLBは通常、大規模なスケーリングが必要なアプリケーションに使用されます。セキュリティの観点から、NLBは TLSで通信を暗号化できます。さらに、Security Groupsを使用したIPベースのアクセス制御も提供しており、これは管理者がIPベースのセキュリティに広く活用している、シンプルで直感的な機能です。
PrivateLinkは、これもトランスポート層のサービスで、 クライアントVPC内のインターフェースエンドポイントとNetwork Load Balancerの背後にあるサービスとの間に一方向の接続を提供することで、VPC接続を実現します。この接続はAWSのバックボーンを使用して確立され、高性能で安全です。PrivateLinkはプロバイダーとコンシューマーという概念を導入しています。プロバイダーはサービスの所有者で、CloudWatchのようなAWSサービス、顧客所有のサービス、またはISVなどのサードパーティが提供するサービスが該当します。コンシューマーはそのサービスを利用する主体で、コンシューマーとプロバイダーは別々のVPCや別のアカウントに存在することができます。セキュリティの観点から、PrivateLinkはNLBと同様に、インターフェースエンドポイントとNetwork Load Balancer間のSecurity GroupsとTLS暗号化を提供します。
Gateway Load Balancerは、 ネットワーク層とトランスポート層の両方の特性を持つユニークなサービスです。Gateway Load Balancerはプロトコルに依存しない「bump in the wire」として機能し、レイヤー3のゲートウェイとレイヤー4のロードバランサーの両方の役割を果たします。このプロトコルに依存しない特性により、アプリケーションターゲットへの接続のロードバランシングを行うものの、どちらかというとネットワークサービスの性質が強くなっています。Gateway Load Balancerは「bump-on-the-wire」の実装にGeneve（Generic Network Virtualization Encapsulation）を使用しています。GWLBは主にセキュリティの分野で使用され、顧客は自社開発またはサードパーティプロバイダーが提供する高可用性ファイアウォールを展開して、検査や侵入検知・防止に活用しています。トラフィックの流れとしては、インターネットや他のVPCからVPC外部からトラフィックが到着すると、まずGateway Load Balancerエンドポイント（これはインターフェースエンドポイントです）を通過します。 そこから、目的地に進む前に検査のためにアプライアンスターゲットに転送されます。
アプリケーション層のサービス：ALB、API Gateway、VPC Latticeの機能
アプリケーション層のサービスについて、さらに上のレイヤーに進んでいきましょう。まずはApplication Load Balancer（ALB）から説明します。 ALBは、コンテナ、インスタンス、そしてサーバーレスアプリケーションに対して、リクエストレベルのルーティングとロードバランシングを提供します。これは、VPC内のサービスをインターネットに公開する際に、AWS内で最も広く使用されているロードバランサーです。NLBと同様に、VPC内部の接続用にInternal ALBを使用することもできます。ALBが広く普及している理由は、WebサイトやAPIサーバーのホスティングなど、メディア、ストリーミング、ゲーム、フィンテック、エンタープライズなど、様々な業界のワークロードに対応できる汎用性の高さにあります。
セキュリティの観点から見ると、ALBはこのレイヤーで強化された機能を提供します。 TLSやセキュリティグループなど、NLBの機能を含んでいることに加えて、ロードバランサーでクライアントの証明書ベースのアイデンティティを認証するための相互TLSもサポートしています。Amazon CognitoやOIDC準拠のサードパーティIDプロバイダーを通じて、ユーザー認証を実装することができます。認証以外にも、AWS WAFと統合してデータパスのセキュリティ態勢を強化することができます。
API Gatewayは、開発者があらゆる規模でAPIを作成、公開、維持、監視、保護するために使用する、より高度な抽象化レイヤーです。ALBとAPI Gatewayを比較すると、ALBはよりシンプルなAPIサーバーに適している一方、API Gatewayは機能が豊富で、より高度なユースケースに適しています。API GatewayはLambda、Amazon DynamoDB、Amazon S3、あるいはVPC内の独自のサービスなど、様々なAWSサービスを使用して構築されたAPIに対してパブリックエンドポイントを提供できます。リージョナルエンドポイントまたはエッジ最適化エンドポイントを選択できます。エッジ最適化エンドポイントでは、AWSが管理するCloudFrontディストリビューションがAPI Gatewayの前面に配置されます。
API Gatewayの重要な特徴の1つは、VPCの外部に存在することです。これにより、API Gatewayリソースをユーザーのプライベートなネットワーク内に配置する必要がないため、ユーザーエクスペリエンスが簡素化されます。
APIをAWS環境内部でのみ公開し、パブリックインターネットからのアクセスを制限したい場合は、プライベートAPIを使用できます。API GatewayはAWS PrivateLinkとの統合を通じてプライベートAPIをサポートしています。アプリケーションの認識という観点から見ると、 API Gatewayは、私たちのポートフォリオの中で、リクエストとレスポンスのボディを認識できる唯一のサービスです。この機能を使用することで、興味深いことができます。例えば、 First NameとLast Nameなど、リクエストボディに特定のフィールドを必須としたい場合、API Gatewayはそれらが見つからない場合に400エラーを返してリクエストを拒否することができます。
正常系のケースでは、目的のものが見つかった際に、API Gatewayを使用してリクエストを変換することができます。ここでは、ファーストネームとラストネームを連結して単一のname項目にし、それを送信先に送る例を示しています。同様の機能はレスポンスでも利用可能です。API Gatewayのもう一つの便利な機能として、Usage Planがあります。これを使用すると、クライアントやメソッド、あるいはその組み合わせに基づいてAPIのスロットリングや追跡を行うことができ、APIを保護したい場合に非常に役立ちます。セキュリティの観点から、API GatewayはApplication Load Balancerよりもさらに多くの機能を提供します。TLS、相互TLS、Amazon Cognitoによるユーザー認証があり、AWSプリンシパルを認証する場合にはIAMベースの認証も利用できます。カスタム認証ロジックを実行したい場合は、Lambda authorizerを使用することができます。
VPC Latticeの特徴とアプリケーションネットワーキングサービスの比較
トランスポート層とアプリケーション層の両方を組み合わせると、VPC Latticeのようになります。Latticeは、管理者と開発者それぞれに直感的な機能を提供することで、ネットワーキングを簡素化するユニークな高レベルの抽象化サービスです。例えば、Latticeは大規模なVPC間接続を提供します。複数のVPCに分散された多くのサービスは、Service Networkと呼ばれる単一のLatticeインスタンスで接続できます。これはネットワーク管理者にとって非常に便利です。なぜなら、多くのVPCにまたがるすべてのサービスを大規模に接続できるだけでなく、IPアドレスの重複の問題を心配する必要がないからです。
API Gatewayと同様に、LatticeもVPCの外部に存在するため、VPC内にLatticeリソースを配置する必要がなく、ユーザーエクスペリエンスが簡素化されます。Latticeのもう一つの重要な機能は、Service Directoryです。これは、Service Network内のすべてのサービスのインベントリです。これは発見のために非常に役立ち、特にService Network内に多数のサービスがある場合に適しています。アプリケーションの認識の観点から、LatticeはApplication Load Balancerと非常によく似たリクエストルーティングとロードバランシングを行うことができます。
セキュリティの観点から、LatticeはSecurity Groupsやサービス間のTLS暗号化など、Application Load Balancerと同様の特性を持っています。LatticeはIAMベースの認証を2つのレベルでサポートしています：ネットワーク管理者が粗粒度の認証ポリシーを持つことができるService Networkレベルと、開発者が細粒度の認証ポリシーを持つことができるサービスレベルです。また、Latticeは送信先に到達する前にSigV4リクエストを認証します。VPC間接続、レイヤーの認識、認証機能の充実度を組み合わせることで、Latticeはゼロトラストアーキテクチャに理想的な適合性を持っています。
多くの内容を扱ってきましたので、簡単に振り返ってみましょう。重要なポイントは、アプリケーションネットワーキングサービスと他のAWSサービスとの統合を活用することで、アプリケーションの高可用性と強力なセキュリティポスチャを実現できるということです。Elastic Load BalancingとAPI Gatewayを比較すると、Elastic Load Balancingはロードバランシングのユースケースや、シンプルなAPIサーバーに最適です。一方、API Gatewayは高度なAPIサーバーのユースケースや、大規模なAPIホスティングに適しています。PrivateLinkとLatticeを比較すると、PrivateLinkはElastic Load Balancingとの統合があり、ポイントツーポイントの接続用に設計されています。
一方、VPC Latticeは多対多またはメッシュスタイルの接続に最適化されています。また、Latticeはゼロトラストの領域でも重要な役割を果たしています。これで概要の説明は終わりですので、Elastic Load Balancingから詳細な説明に入っていきましょう。
Elastic Load Balancingの最新機能と改善点
ロードバランサーには4種類あります：Application Load Balancer（ALB）、Network Load Balancer（NLB）、そしてGateway Load Balancer（GWLB）です。Classic Load Balancer（CLB）は最初に導入したロードバランサーで、レイヤー4とレイヤー7の両方のロードバランシングが可能であり、現在も維持・提供を続けているオプションです。このセクションでは、過去12ヶ月間のELBの主要な機能リリースについてお話しします。
セキュリティは常に最優先事項であり、その分野で機能強化を行ってきました。ここでは2つの機能についてお話ししたいと思います。ALBとNLBの共有セキュリティグループと、相互TLS機能の強化です。共有セキュリティグループは実際には今年初めにリリースされたVPCの機能で、ALBとNLBの両方でサポートされています。ユースケースは2つあります：1つ目は、複数のアカウントにまたがる単一のVPCがあり、そのVPC内に配置できるセキュリティグループを参加しているすべてのアカウントで機能させることができます。2つ目は、単一のアカウントに複数のVPCがある場合で、そのアカウント内のVPC間でセキュリティグループを共有できます。
相互TLSは昨年リリースした機能です。当初は、CAバンドルと失効リストを含むトラストストアは、ALBと同じアカウントに置く必要がありました。今年初めに、AWS Resource Access Managerを使用して、中央アカウントから他の様々なアプリケーションアカウントに特定のトラストストアを共有できるトラストストア共有機能をリリースしました。これにより、ネットワーク管理者は単一のトラストストアを生成し、すべてのアプリケーションアカウントがそのトラストストアを使用するようにすることで、セキュリティ管理者は正確性を維持しながら容易にスケールできるようになりました。また、CAバンドルのサブジェクト名を通知する機能もリリースしました。これは、クライアントが複数のクライアント証明書を持っていて、相互TLS接続に使用する適切な証明書を選択する必要がある場合に特に役立ちます。これらの機能は、相互TLSのリリース後に受けたフィードバックに基づいてリリースされました。
可用性はElastic Load Balancingの最優先事項です。可用性を考慮したアーキテクチャの優れた方法は、ロードバランサーを3つのゾーンに分散させることです。これは、1つのAvailability Zoneに障害が発生しても、追加の可用性があるため有用です。数年前、AWS Application Recovery Controllerチームは、クロスゾーンが無効化されたロードバランサー向けにゾーナルシフト機能をリリースしました。今回、クロスゾーンが有効化されたロードバランサーでもゾーナルシフトを可能にしました。障害のあるAvailability Zoneを検出してそこから退避することを選択すると、ロードバランシングノードだけでなく、その背後にあるターゲットも退避します。障害のあるAvailability Zone内のターゲットは、正常なAvailability Zone内にあるロードバランサーのノードからのトラフィックを受信しなくなり、影響範囲を減らし、可用性の姿勢を改善します。
最近、ALBとNLBの両方で利用可能なLoad Balancer Capacity Unit予約機能をリリースしました。この機能により、スポーツイベントのストリーミングやEコマースプラットフォームのフラッシュセールなど、トラフィックの急増に対応するためのLoad Balancerの最小容量を設定できます。Load Balancer Capacity Units（LCU）で最小値を指定すると、その最小容量が常時保証されます。 Load Balancerは受信トラフィックに基づいて引き続き自動的にスケーリングを行うため、設定した最小容量を基準とし、それ以上の容量が必要な場合は自然なスケーリングが行われます。
Load Balancerのルーティング機能は非常に便利です。というのも、アプリケーションからそのロジックを切り離すことで、アプリケーションをシンプルにできるからです。この分野で、私たちはいくつかの重要な機能をリリースしました。NLBとGWLBでは、最も要望の多かった機能の一つであるTCP設定可能アイドルタイムアウトをリリースしました。このリリース以前は、TCP設定可能タイムアウトは350秒に固定されていました。現在は60秒から6000秒の間で任意の値を選択できます。これにより、Load Balancerのタイムアウトをクライアントやターゲットに合わせて設定でき、再試行を減らすことができます。
この設定により、再試行エラーと全体的な遅延を潜在的に削減でき、アプリケーションのパフォーマンスが向上します。ALB Header Modificationも、最も要望の多かった機能の一つです。 リクエスト側では、AWS生成のTLSヘッダーの名前を変更する具体的な機能をリリースしました。TLSヘッダーは、組織がコンプライアンスのために最小暗号バージョンを強制したり、相互TLSでカスタムロジックを構築したりする際によく使用されるため、アプリケーション開発者にとって特別な意味を持つということを、お客様から学びました。
そのロジックを構築するために、各チームでAWS生成のヘッダーを解析するのが難しいという声をお客様からいただいていました。これを簡素化するため、これらのヘッダーの名前を変更できるようにしました。この例では、 X-Amazon-TLS-Versionを単にTLS-Versionに変更しており、これによりアプリケーションが宛先に到達する前により適切な形になります。なお、このリリースではヘッダーの名前のみを変更でき、値は変更できないことにご注意ください。レスポンス側では、HSTSとCross-Origin Resource Sharing（CORS）ヘッダーを挿入する機能を提供しています。
この機能をリリースした理由は、個々のアプリケーション開発チームに依頼する必要があり、エラーが発生しやすかったこれらのヘッダーを、管理者が組織全体で一元的に強制できるようにするためです。この例では、 HSTSヘッダーにmax-ageの値を900に設定していますが、アプリケーションに適した設定に変更することができます。 利用可能なすべてのCORSヘッダーについても同様の設定が可能です。
API Gatewayの進化とプライベートカスタムドメインの導入
AWS Load Balancer ControllerはKubernetesのAWSデプロイメントにおいて、ALBとNLBの両方が非常によく使用されています。ここでは、過去12ヶ月間に実施したAWS Load Balancer Controllerの改善点についてご説明します。まず基本的な部分から見ていきましょう。Load Balancer Controllerは、KubernetesクラスターのElastic Load Balancerを管理するのに役立ちます。Kubernetesでは、ユーザーはKubernetes独自のAPIを使用してリソースを操作することを好みます。Load Balancer Controllerは、KubernetesのAPIとELBコントロールプレーンの間の変換層として機能するクラスター内のデプロイメントです。
このControllerは、サービスを構成するKubernetesクラスター内のPodを、ロードバランサーのターゲットとして登録・登録解除する役割を担っています。これは特にKubernetesにとって重要です。なぜならPodは非常に一時的な性質を持つためです。Controllerは2つ以上のPodで実行され、そのうちの1つが常にリーダーとして選出されます。ここでロードバランサーと言う場合、それは私たちにとってはLayer 4、つまりNLBを意味し、Ingressと言う場合は、Layer 7、つまりALBを意味します。この12ヶ月間、私たちはControllerのパフォーマンスと使いやすさの改善に注力してきました。
パフォーマンス改善の最初の焦点は、Reconciliationでした。まず、Reconciliationとは何かを説明しましょう。注目すべき3つのコンポーネントがあります：まずController、次にKubernetes APIサーバー、そしてELBコントロールプレーンです。Load Balancer Controllerの役割は、これら2つを同期させ続けることです。緑色のボックスは、これら2つが同期している状態を示しており、このAPIサーバーとELBコントロールプレーンを同期させ続けるプロセスをReconciliationと呼んでいます。
Reconciliationが非常に遅くなることがあります。例えば、多数のサービス、リソース、ロードバランサーが接続された大規模なクラスターがある場合、多くのルックアップが必要となり、Reconciliationが遅くなる可能性があります。また、リーダーPodが再起動された場合、新しいレプリカのスピンアップ、新しいリーダーの選出、そしてReconciliationの実行が必要となり、これらすべてに時間がかかることがあります。キャッシングと遅延キューを使用することで、ルックアップの回数を削減し、Reconciliation時間を90%短縮できたことをお知らせできて嬉しく思います。ご覧の通り、このスライドでは緑色のボックスが非常に速く表示されています。さらに、Load Balancer Controller Podで実行されるSDKをAWS SDK Go v2にアップグレードしました。
Load Balancer Controller SDKはELBコントロールプレーンのクライアントとして機能し、Podが継続的にスピンアップとダウンを繰り返す一時的な性質により、数多くのAPI呼び出しを行うことを覚えておくと良いでしょう。このアップグレードにより、CPU使用率を50%削減し、メモリ使用量を32%削減することができました。この軽量化されたSDKはデータ処理が非常に速く、改良された再試行メカニズムを備えており、API呼び出しを極めて効率的に行い、Controllerのパフォーマンスを向上させています。
アプリケーションの回復性を高めるため、複数のクラスターをプロビジョニングしてトラフィックを処理したいというお客様からのフィードバックを多数いただいています。2つの独立したクラスターがある場合、それぞれに独自のLoad Balancer Controllerのインスタンスが存在し、これらは互いに独立して動作します。当初、これらのクラスター間でTarget Groupを立ち上げる際、各コントローラーは衝突を避けるためにTarget Groupを上書きしていました。この方法は衝突防止には効果的でしたが、複数のクラスターにまたがるTarget Groupのサポートができませんでした。
今回、コントローラーをアップグレードし、複数のクラスターからのターゲットを競合なく同時にオンボードできるようになったことをお知らせできることを嬉しく思います。この改善により、複数のクラスターにまたがるTarget Groupを安全にサポートできるようになり、使い勝手が大幅に向上しました。ここでは、同一VPC内の2つのクラスターにまたがるTarget Groupの例をご紹介しています。また、異なるVPC間のクラスターにまたがるTarget Groupもサポートしており、その場合はAWS Transit Gatewayなどのサービスを使用してVPC間の接続を確保するだけで済みます。
これで私のパートは終了です。ここからYousefに引き継ぎたいと思います。ありがとうございます、Satya。素晴らしい導入でこれから説明する内容への良い布石となりました。私のセクションでは、まずAmazon API Gateway、そしてAWS PrivateLinkとAmazon VPC Latticeについてお話しします。まずはAPI Gatewayから始めましょう。Amazon API Gatewayは、誰でも本番環境レベルのAPIを任意のスケールで公開できるようにするサービスです。以前は、APIのセットアップには大きな運用負荷がかかり、開発者はDNSレコード、TLS証明書、ロードバランサー、Webサーバーなどを構成する必要がありました。お客様からよりシンプルなソリューションへの要望があり、2015年にAPI Gatewayが誕生しました。当初はAWS Lambdaとの深い統合に焦点を当てていましたが、時間とともにAPI Gatewayはさらに多くのユースケースをサポートするように進化しました。
API Gatewayの主要な機能を見ていきましょう。基本となるのは、リクエスト・レスポンスパターンに従うHTTP RESTful APIです。インターネットに公開するパブリックAPIと、企業内部向けのプライベートAPIの両方をサポートしています。その後、ストリーミングや非同期ワークロードを必要とするアプリケーション向けにWebSocketのサポートも導入しました。API Gatewayのターゲットとして100以上のAWSサービスと統合しています。さらに、API Gatewayは認証、認可、スロットリング、Usage Keyなど、お客様がAPIを効果的に管理するための機能も提供しています。
API Gatewayは長年にわたり大きく進化してきました。2023年には、1,000億件を超えるAPIリクエストを処理したことを発表し、この数字は急速に成長を続けています。スケールが拡大するにつれて、可用性とセキュリティに関するお客様の高い基準を満たすため、継続的な投資の必要性を認識しています。数千のノードを迅速にスケールできるパフォーマンス向上など、障害イベントをより適切に管理するための数々の改善を実施してきました。また、個々のAPIストリームを分離し、お客様のデプロイメント中の500エラーの急増などの異常を検出する社内ツールも開発しました。
また、開発者向けにさまざまなユーザビリティの改善も導入しました。API Gatewayでは、セルフサービスのクォータ管理を含む、複数の使いやすさの改善を実施しました。2024年初めにコンソールを刷新し、複数のサードパーティとの連携によってDeveloper Portalの機能を提供できるようになりました。まずはレジリエンスの改善について説明し、その後でレジリエンスに関するデータプレーンのアーキテクチャについて、より詳細なスライドで説明していきます。先ほど触れましたが、グレイ障害の検出と軽減機能を構築しました。これにより、API Gatewayはネットワークレベルの障害を検出し、お客様が何も操作することなく、自動的に軽減・管理することが可能になりました。
一連のサービス保護対策を構築し、AWS WAFと統合しました。インターネットに公開されているAPIを大規模に運用している我々のスケールでは、DDoS攻撃を受けることは珍しくありません。私たちのチームは24時間365日体制で対応し、このような事象に対する管理と軽減を行います。また、APIプラットフォーム用の大量のコンピューティングインスタンスのプロビジョニングにかかる時間を短縮する機能も構築しました。最後に、データプレーンを再構築し、セルラーアーキテクチャに分割しました。これについて、これから詳しく説明していきます。
まず、APIリクエストの経路について、高レベルの概要を見ていく必要があります。通常、リクエストはリクエスト・レスポンスパターンに従います。リクエストはAPIシステムに到達し、そこで認可、認証、リクエストの検証、レスポンスの検証、変換などが実行されます。その後、リクエストは他のサービス、Webサーバー、Lambda関数、EC2インスタンスなどに転送されます。APIを呼び出すと、最初のステップとして、リクエストはAPI Gatewayのフロントドアに到達します。そのリクエストは内部的に最初のサービスにルーティングされ、そこでセキュリティの第一層が実行されます。ここで認証、認可、レート制限などが行われます。
その後、特定のAPIに応じて、セルまたはパーティションの1つにマッピングされます。Shuffle Shardingを含む複数のスキームを使用しています。最初のAPIにリクエストが到着すると、認証後に、そのAPIを所有する特定のパーティションに渡されます。そのパーティションは、独立したLoad Balancer（数千のLoad Balancerがあります）を持つ完全にスタンドアロンなインフラストラクチャを持っており、それらのLoad Balancerには、バックエンドでAPIの呼び出しを実際に処理する一連のコンピューティングインスタンスが設定されています。これらは互いに分離されており、個々のパーティションの影響範囲を制御しながら、より良いスケーリングと個別の管理を可能にしています。
API Gatewayについて、2024年に提供した可用性の改善について説明してきましたが、API Gatewayが立ち上げた主要なセキュリティ機能についても言及することが重要です。今年初めに、すべてのAPIに対して、追加の設定なしでTLS 1.3のサポートを開始しました。これはAPI Gatewayのお客様への約束の一部です。また、AWS WAFとの統合も改善し、WAFとAPI Gatewayを統合しているお客様向けに、最大64キロバイトまでの大きなペイロードの検査をサポートできるようになりました。Custom Authorizerを使用しているAPI Gatewayユーザーに対しては、VPC Endpointポリシーのサポートを改善しました。
また、ユーザビリティに関するフィードバックも寄せられました。API Gatewayが最初にローンチされた時は、パブリックまたはインターネット向けのAPIに重点を置いていました。時間の経過とともにプライベートAPIのパターンが出現し、これに関してお客様からユーザビリティの改善を求める声が寄せられていました。API Gatewayのエンドポイントには多くの情報が含まれています - API ID、VPC ID、リージョン名、APIステージ名などです。お客様が求めているのは、 myexample.comのような、シンプルで覚えやすいものです。お客様は、これを自社の顧客と共有し、素早く簡単に発見できるようにしたいと考えています。プライベートAPIのパターンがAPI Gatewayでより一般的になるにつれ、これが最も要望の多い機能となり、本日、私たちはその要望に応えて、API Gatewayのプライベートカスタムドメインの提供を開始することを発表できることを嬉しく思います。
この発表により、 API Gatewayの新しい章が開かれます。まず第一に、これによってプライベートAPIエンドポイントのカスタマイズと発見可能性に関するより良いコントロールが可能になります。さらに、大規模なAPIの管理を容易にする機能の追加も始めています。今回のリリースでは、プライベートドメインという概念を導入し、そのプライベートドメインに1つまたは複数のAPIをマッピングできるようにしました。開発者はドメインレベルでポリシーを適用でき、そのポリシーはそのドメインに関連付けられたすべてのAPIに自動的に適用されるため、プライベートドメインのポリシーとセキュリティ管理が容易になります。
AWS PrivateLinkとResource Access Manager (RAM)との深い統合により、エンタープライズ内での異なるアカウント間やVPC間での共有がシームレスに可能になりました。ご存知の通り、AWS Well-Architectedでは、セキュリティとブラストラディウスをより適切に制御するために、マルチアカウント・マルチVPCのセットアップでの運用を強く推奨しています。API Gatewayのプライベートカスタムドメインにより、複雑な作業を行うことなく、VPC間やアカウント間のクライアントを持つアプリケーションを簡単にサポートできるようになりました。さらに、ローンチ時からIPv6との統合も行っており、プライベートカスタムドメインはIPv6をサポートしており、今後のAPI Gatewayの全ての機能リリースでもIPv6をサポートしていきます。
プライベートカスタムドメインの使用開始は比較的簡単です。 いくつかの前提条件があり、こちらの画面はぜひ写真に撮っておいてください。アプリケーションの所有者として、SSLまたはTLS証明書とRoute 53のプライベートホストゾーンが必要です。通常、これらの証明書はAPI GatewayでACMによって管理されます。カスタムドメインを作成し、そのドメインのベースマッピングを作成します。次に、そのドメインをResource Access Managerで共有し、アカウント間で共有できるようにします。そのドメインをVPCエンドポイントに関連付け、最後にお客様と協力してRoute 53マッピングまたはエイリアスをそのカスタムドメインに作成します。
ここでは詳しく説明しませんが、より詳しく知りたい方は、木曜日に「API GatewayによるプライベートAPIワークロードのスケーリング」というセッションがあります。そこでは、パブリックパターン、プライベートAPIパターンについて詳しく説明し、API Gatewayを広範に使用している大手顧客のItau Unibanco（ブラジルの大手銀行）からの事例も紹介します。より詳しく知りたい方は、木曜日のこのセッションをぜひチェックしてください。
AWS PrivateLinkとVPC Latticeの新機能：UDPサポートとResource Endpoints
では次に、AWS PrivateLinkとVPC Latticeについて見ていきましょう。両者はプライベートVPC接続をサポートしていますが、その方法と目的が少し異なります。 PrivateLinkは、コンシューマーからプロバイダーへの一方向のアクセスをサポートしています。これはクライアント主導型で、クライアントがリモートVPCのプロバイダーに接続するためのアクションを起こす必要があります。オプションとして、プロバイダーは接続を受け入れるか拒否するかのハンドシェイクプロトコルを実装することができます。トラフィックは確実にAWSネットワーク内でプライベートに保たれ、PrivateLinkはオンプレミスネットワーク接続もサポートしています。オンプレミスネットワークがあり、Direct Connectを介してAWS VPCに接続している場合、そのVPCを経由してPrivateLink上のサービスにアクセスすることができます。
お客様がPrivateLinkを好んで使用する理由は様々です。最も重要な理由は、クライアント主導型であることです。これは、組織内の信頼境界を越える際に非常に強力な機能となります。一般的なユースケースとして、例えばMongoDBのようなサードパーティのデータベース（PrivateLinkソリューションを提供）へのアクセスが挙げられます。コンシューマーとして、相手のVPC内のマネージドMongoDBインスタンスにアクセスしたいが、相手側にはネットワークへのアクセスを許可したくない場合、クライアント主導型の一方向アクセスが活きてきます。さらに、エンドポイントポリシーとセキュリティグループを使用することで、誰がどのエンドポイントに接続できるかを制御する強力なデータペリメーターを構築でき、強固なセキュリティとコンプライアンスの保証を得ることができます。前述の通り、PrivateLinkはプロバイダー側でのオンプレミス接続もサポートしています。また、PrivateLinkは多くのメトリクスを発行し、最近ではContributor Insightsという機能をリリースし、プロバイダーがAPIの主要なコンシューマーやトップトーカーを把握し、接続を管理するのに役立つ情報を提供しています。
PrivateLinkエンドポイントが接続するサービスには、TCPサービスとアプライアンスの2種類があります。今日はサービスに重点を置いて説明しますが、アプライアンスについても簡単に触れておく価値があります。アプライアンスは、Gateway Load Balancerとの統合を実現するPrivateLinkの機能です。Gateway Load Balancerは、通常ネットワークの下位レイヤーで高度な機能を提供し、PrivateLinkによって実現されるGateway Load Balancerエンドポイントを通じてネットワークに統合する機能を提供します。
歴史的に、PrivateLink上のサービスはTCPのみで、3つのカテゴリーに分類されます。1つ目はAWSサービスで、現在多くのお客様がPrivateLink経由でAWSサービスに接続しています。PrivateLinkは198以上のサービスをサポートしており、その数は常に増え続けています。2つ目のカテゴリーは、お客様が開発し所有するサービスです。これは、VPCやアカウントの境界を越えてデータを公開し、自社のエンタープライズ顧客にアクセスを提供したい場合のプライベートエンタープライズパターンに関連します。3つ目はサードパーティプロバイダーです。サードパーティプロバイダーには、MongoDB、Teradata、Snowflakeなどのサービスがあります。PrivateLinkはAWS Marketplaceと統合されていますが、サードパーティプロバイダーがPrivateLink経由でサービスを提供できる独自のISVエコシステムも持っています。
これまでの制限として、これらのサービスはTCPプロトコルをベースとしている必要がありました。お客様からは接続性の拡張、特にUDP接続のサポートを求める声がありました。 本日、PrivateLinkでのUDPサポートのリリースを発表できることを嬉しく思います。これは全リージョンで一般提供され、重要なポイントとして、ローンチ時点でUDPv4とv6の両方をサポートしています。この拡張性、構成可能性、相互運用性については、これから説明するスライドの中で大きなテーマとなっていきます。
このリリースでは、Network Load BalancerにUDP v4およびv6リスナーを追加できるようになりました。このダイアグラムもぜひスクリーンショットを撮っておいてください。これにより、v6プロバイダーサービスへのシームレスな移行や段階的な移行が可能になります。大規模なアーキテクチャの再設計は必要ありません。PrivateLink サービスを提供するNetwork Load Balancerがデュアルスタックである限り、その場で使用でき、リスナーを段階的に追加できます。これはPrivateLinkの接続性と使いやすさを大きく向上させる改善です。
しかし、お客様からはさらなる要望をいただいています。お客様から伺っているのは、リージョンを越えてPrivateLinkに接続する機能が欲しいということです。同じダイアグラムを拡張すると、US-EAST-1のコンシューマーやカスタマーがUS-WEST-2のデータやプロバイダーサービスにアクセスしたいというニーズがあります。これは特定のリージョンにデータを置きたい場合や、社内の災害復旧フェイルオーバーシナリオのために必要とされることがあります。嬉しいことに、私たちは新しい機能を提供することができました。本日、クロスリージョンPrivateLinkを発表します。現在、7つのリージョンで一般提供を開始しており、2025年1月までにすべてのリージョンで利用可能になる予定です。さらに、 リージョンを越えたUDPとTCPサービス、そしてv4とv6の接続性にも対応しており、私たちが期待する多くのユースケースを実現できるようになります。
主要パートナーからは、すでに非常に力強いフィードバックをいただいています。Salesforceによれば、この機能強化により、セキュリティ、パフォーマンス、スケーラビリティを損なうことなく、社内外のサービスのリージョン間通信を効率化できるとのことです。Datadogからは、クロスリージョンPrivateLinkにより、お客様は複数のリージョンでネットワークリソースを作成することなく、わずか数クリックでObservabilityデータをDatadogに送信できるようになったと聞いています。
PrivateLinkには多くのサードパーティISVパートナーがいることを先ほど申し上げました。すべてを紹介することはできませんが、主要なパートナーをいくつかご紹介させていただきたいと思います。
私たちは常にこのネットワークを拡大するよう努めています。PrivateLinkパートナーになることにご興味がありましたら、ぜひご連絡ください。また、先ほど申し上げたように、Gateway Load Balancerにも同様のプロバイダーシステムがあります。Palo Alto Networks、Fortinet、Check Point Software Technologiesなどの主要パートナーがいます。パートナーになることにご興味がある場合は、お気軽にご連絡ください。
ここまでPrivateLinkについて説明してきましたが、ここからはLatticeについて話を移していきましょう。先ほど、PrivateLinkは組織間、つまり自社から他社への信頼境界を越えるのに適していると述べました。一方、Latticeは通常、組織内で使用されます。もちろん、強力なデータ境界とセキュリティ制御も備えており、これについては後のスライドで説明しますが、信頼境界内での利用に自然にフィットするソリューションです。
Latticeには4つの基本的な概念があります。比較的わかりやすい概念ですが、これから発表する新機能の理解に重要なので、少し詳しく説明させていただきます。まず1つ目がLattice Serviceで、これはアプリケーションのエンドポイントと考えてください。Service Networkは1つまたは複数のサービスの集まりで、このグループ化の仕組みによって、アプリケーションの共有と管理を非常にエレガントに行うことができます。また、Service NetworkやService個別に対して、Auth PolicyやIAM Policyを適用することができます。最後に、Service Directoryがあり、これはService Network内のサービスを発見するための検出ツールです。Service Network内に多くのサービスが存在する場合に特に重要になります。
お客様がLatticeを気に入っている理由は多岐にわたりますが、その中でも抽象化の仕組みが挙げられます。PrivateLinkを振り返ると、これはポイントツーポイントのクライアント主導の接続です。これは非常にシンプルで始めるには最適ですが、数千のPrivateLink ServiceやConnectionを管理するとなると、スケールした際に課題となる可能性があります。Latticeが提供する抽象化により、開発者はそのようなシナリオを管理し、エレガントにスケールすることができます。ServiceやService Networkに適用できるポリシーにより、きめ細かな制御を簡単に実現できます。
最後に、私が最も興奮しているのは、これから詳しく説明するApplication Awarenessです。これにより、開発者はスロットリングなどの運用作業や重要な処理を実行できます。重要なポイントとして、Latticeはコンピュートに依存しないという特徴があります。つまり、Lambda関数、EC2インスタンス、Kubernetesクラスターなど、どのバックエンドでもLattice Serviceを定義できるということです。既存のEC2インスタンスがあれば、それをLattice Serviceのバックエンドとして使用できます。開発者がこのワークロードにKubernetesが適していると判断した場合、アーキテクチャの他の部分を変更することなく、Kubernetesをバックエンドとする新しいLattice Serviceを作成するだけで対応できます。
エキサイティングな発表の前に、ServiceとService Networkについてもう少し詳しく見ていきましょう。Lattice Serviceには4つのコンポーネントがあります。1つ目はURL、2つ目はListenerで、ここではポートプロトコルやクライアントの接続方法を定義します。3つ目はRulesで、これはLattice Serviceへの呼び出しをどこにルーティングするかを定義する実質的なルーティングルールです。そして最後がTarget Groupsです。これが先ほど言及したもので、現在、私たちは様々なコンピュートオプションをサポートしています。EC2インスタンス、Lambda関数、EKSクラスター、あるいは別のロードバランサーなどです。既存のロードバランサーを使用したサービスがある場合、その上にLatticeの抽象化レイヤーを作成し、メッシュに組み込むことができます。
Service Networkはグループ化とアソシエーションのメカニズムであり、サービスを整理する手助けとなります。Service Networkは1つまたは複数のVPCに接続することができ、これについては後のスライドで詳しく説明します。実は、Latticeという新しいプリミティブを導入する重要な発表があります。Latticeを使い始めるのは比較的簡単です。まず、Lattice Target GroupまたはTarget（リクエストを処理するアプリケーション）を作成します。次に、Lattice Serviceを作成し、それらのTargetと関連付けます。その後、Lattice Service Networkを作成し、1つまたは複数のVPCと関連付けます。最後に、ServiceをService Networkに関連付けることができます。
このスライドに戻ってご覧いただけるように、Service Networkを定義すると、数千のVPCを簡単に関連付けることができ、エレガントにスケールします。開発者としては、セキュリティ境界をより適切に分割するために、複数の小規模なアカウントや小規模なVPCを作成できますが、同じサービスインフラストラクチャと関連付けて共有することができます。そのため、これを何度も繰り返す必要がありません。この抽象化により、セキュアで細かい制御が可能な高度なトポロジーを比較的簡単に作成することができます。
これが私が本当に興奮している部分です。先ほど申し上げたように、VPC Latticeはコンピュートに依存しません。ここでは、一般的なLattice Serviceのロゴを、EC2、Kubernetes、Lambdaに置き換えています。Lambdaは私たちのエコシステムの重要な部分ですが、お客様からはECSのサポートでこの統合ポートフォリオを完成させてほしいという要望がありました。これは以前から、お客様独自のワークアラウンドで可能でした。ここで示しているのが、その場合の構成です。概念的に分かりやすくするためにボックスにラベルを付けています。通常はALBなどのロードバランサーをTargetとするLattice Serviceを定義し、そのALBがECSクラスターにイベントをプロキシするという仕組みでした。これは機能しましたが、ワークアラウンドであり、複雑さとコストが増加していました。
お客様からより良い方法を求められ、私たちはLatticeのネイティブECSサポートを導入できたことを嬉しく思います。これにより、VPC LatticeのService統合におけるコンピュートオプションが完成し、開発者が新しいサービスを構築する際に使用できるコンピュートエンジンがさらに1つ追加されました。これが新しい構成で、先ほどのグラフを単純化すると、中間のロードバランサーを単純に削除し、ECSタスクに直接呼び出しを行えるようになったことが分かります。
一歩下がって見てみると、これが私を本当に興奮させる理由です。VPC Latticeがアプリケーションを認識し、コンピュートに依存しないという事実は、非常に強力なツールを生み出します。パスに基づいて異なるリスナーを定義し、異なるルールを持つことができます。異なるコンピュートエンジンにルーティングすることができます。例えば、サービスから始めて、そのワークロードをALBバックのサービスに移行する必要があると判断した場合、Latticeを使用すれば、トポロジー、セキュリティポリシー、データペリメーター、接続メッシュを変更することなく、シームレスに移行できます。私たちの目標は、AWSで最も選ばれるメッシュになることです。
お客様から PrivateLink や Lattice についてどのように考えているのかと質問されることがありますが、これは非常に興味深い質問だと思います。 今回のリリースでは、Lattice と Service Networks によって導入される基本的な機能に立ち返って考えてみましょう。PrivateLink と Lattice について考える際に重要なのは、お客様が接続性の拡張を求めていたという点です。UDP ベースのサービスへの接続を望んでいました。 ECS ベースのクラスターへの接続も求められましたが、ロードバランサーを使用しないサービスへの接続についても要望がありました。これには EC2 インスタンスやデータベース、キャッシュなどが含まれます。通常、これらはロードバランサーの背後にはありません。キャッシュやデータベースクラスターの前にロードバランサーを配置することは一般的ではありません。
このユースケースでは、コンシューマー側とプロデューサー側の両方に当てはまる2つの異なるシナリオを見ていきます。お客様は通常、 リモート VPC 内の特定のリソースにアクセスしたいと考えています。個々の EC2 インスタンスの場合、これは可能ですが、中間の NLB を作成し、PrivateLink サービスを作成し、その PrivateLink 接続をサポートするための追加のオーバーヘッドが必要になります。プロバイダー側では、 特定の制御されたリソースにアクセスする必要がある場合があります。一般的なユースケースとしては、データ収集サービスを構築している企業で、顧客のデータが単一の EC2 インスタンスにある場合です。顧客に PrivateLink サービスを立ち上げてもらう必要はありませんが、制御、セキュリティ、データの境界、そして VPC 境界を越えて特定のリソースのみを共有するというセキュリティ保証が必要です。
これは現在でも行われていますが、回避策は同様です。 CDK や Terraform による自動化を提供し、顧客に PrivateLink サービスを通じて設定してもらい、そこにコールバックする形になります。
本日、私たちは Lattice for VPC の新しい構成要素として Resources を発表します。これは先ほど述べた EC2 インスタンス、RDS データベース、キャッシュクラスターなどのリソースをモデル化したものです。これらのリソースはスケールを考慮して設計されており、1対多または多対多の通信を可能にし、RAM や IAM ポリシーとの強力な統合も備えています。
本日、Cross VPC Resource Endpoints の提供開始を発表できることを嬉しく思います。 これにより、お客様は追加のロードバランサーサービスを必要とせずに、単一の EC2 インスタンスに接続できるようになります。Resource Endpoints の使用開始は簡単です。リソース所有者として Lattice API を使用する場合、まずリソースを定義して作成します。この概念は Lattice 内に存在します。 次に、そのリソースに必要なポリシーとリソース設定を作成します。クロスアカウント共有のために RAM を通じて共有することができます。
コンシューマー側については、先ほど言及した相互運用性に関連しますが、PrivateLinkやLatticeを通じてそのリソースに接続することができます。既存のPrivateLink接続を使用してリソースに直接接続するか、そのリソースをService Networkに追加してVPCに関連付けることができます。先ほどお見せした図に戻りますが、今回のリリースでは、 PrivateLinkからLattice Service Networkへの直接接続機能も発表しています。ユースケースとしては、既存のPrivateLink環境があり、開発者に好評なLatticeサービスの作成を始めた場合、アーキテクチャを変更する必要はありません。私たちがブリッジを構築しているので、VPC環境からLattice Service Networkへ簡単に接続できます。
Cross VPCリソースには多くのメリットがあります。プライベートでスケーラブル、1対多または多対多の通信が可能で、RAMやIAMとの統合により、シームレスな共有を実現します。すでに主要パートナーから、Resource Endpointsの使用に関して力強いフィードバックを得ています。Palo Alto Networksは、Resource EndpointsとCloud NGFWの統合がクラウド運用の簡素化において大きな前進だと述べています。ClickHouseは、AWSでホストされている運用システムからデータを移行する人にとって、Resource Endpointsは魅力的な機能だと言っています。ClickHouseは数兆行のデータを管理するのに使用されており、Resource Endpointsによって非常に細かいレベルでの安全な通信を提供することができます。
ローンチに際して、パートナー各社に感謝申し上げます。Resource Endpointsには多くのパートナーがいます。 その一部は先ほどのスライドで紹介しました。すべてを詳しく説明する時間はありませんが、Resource Endpointsとの統合に関わってくださったパートナー各社に感謝申し上げます。これによって顧客のイノベーションが促進されることを楽しみにしています。
アプリケーションネットワーキングに関する追加セッションの案内
アプリケーションネットワーキングについてさらに学びたい方には、いくつかのセッションをお勧めします。このトークの直後に、Advanced VPC DesignについてのNET301があります。明日火曜日には、AWS PrivateLinkとVPC Latticeを使用したクロスVPCリソースアクセスの簡素化に関する詳細なセッションNET218があります。そして木曜日には、Amazon API Gatewayを使用したプライベートワークロードのスケーリングとセキュリティ確保について、大規模な顧客からAPI Gatewayのパターンについて話を聞くディープダイブセッションがあります。ご清聴ありがとうございました。これらの発表が皆様にとって興味深いものであることを願っています。皆様が何を構築されるのか楽しみにしています。ご質問がありましたらお気軽にご連絡ください。最後に、アンケートへのご協力をお願いいたします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion