re:Invent 2023: AWSが解説するAmazon VPC Latticeのアーキテクチャパターンとベストプラクティス
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2023 - Amazon VPC Lattice architecture patterns and best practices (NET326)
この動画では、Amazon VPC Latticeのアーキテクチャパターンとベストプラクティスについて、EC2 Networking部門のPrincipal Product ManagerであるJustin Daviesが解説します。VPC Latticeがどのようにアプリケーション層のネットワーキングを簡素化し、管理者と開発者の間のギャップを埋めるかを学べます。サービス、サービスネットワーク、認証ポリシーなどの主要コンポーネントの詳細や、IPv6移行、マルチリージョン接続などの実践的なユースケースも紹介されます。VPC Latticeの柔軟性と強力な機能を活用して、より効率的なネットワーク設計を実現する方法を知ることができます。 ※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
本編
Amazon VPC Latticeの紹介と聴衆の役割確認
みなさん、こんにちは。NET326へようこそ。 今回は「Amazon VPC Latticeのアーキテクチャパターンとベストプラクティス」についてお話しします。私はJustin Daviesと申します。AmazonのEC2 Networking部門で、アプリケーション層のネットワーキングに関するすべてを担当するPrincipal Product Managerをしています。
本題に入る前に、少し皆さんのことを知りたいと思います。これは毎回行っているのですが、これから説明していくように、役割や顧客のニーズに応えることが重要だからです。まず、手を挙げていただきたいのですが、この中で自分をどちらかというと管理者だと考えている方はどれくらいいらっしゃいますか？セキュリティ管理者、ネットワーク管理者、クラウド管理者などが該当します。なるほど、かなりの割合ですね。では、開発者はどうでしょうか？これは必ずしもコードを書く人だけでなく、サービスを所有したり、設定したりする人も含みます。おそらく半々くらいでしょうか。両方の役割を担っている方はどうですか？すべての帽子をかぶっている方は？そうですね、かなりの方がいらっしゃいますね。
VPC Latticeの開発背景と目的
これこそが、私たちがVPC Latticeを構築したかった理由です。小規模な企業や、時には大規模な企業でも、複数の役割を担う人がいるかもしれません。管理者と開発者の両方の役割を担っている人も多いでしょう。しかし、通常は、どちらかに分かれることが多く、時には相反する優先事項が障害になることがあります。私はこんな風に言うのが好きです。管理者は「開発者に力を与えたいが、安全にそれを行いたい」と言います。開発者が管理者のことを「楽しみを奪う警察」と呼ぶことがよくありますが、それは真実ではありません。管理者はニュースの見出しを飾りたくないのです。彼らの使命は、皆さんが迅速に運用し、前進できるようにすることですが、Hacker Newsに載るようなことは避けたいのです。
一方、開発者は、フルスタックエンジニアであっても、CCIEやネットワークの専門家ではないかもしれません。実際のところ、それは彼らが最も好まない仕事かもしれません。問題を特定してトラブルシューティングするために、tracerouteに集中したくはないでしょう。では、設定だけでなくトラブルシューティングも含めて、どうすればこれらの人々にとってより簡単にできるでしょうか？これが、顧客と話し、このペルソナの問題が存在することを見て、多くのこのようなアイデアが生まれた理由です。
今年の初め、実際には昨年プレビューとして発表しましたが、今年の初めにAmazon VPC Latticeという新製品をGAとしてリリースしました。それは3月のことでした。もしご存じなければ、これからその概要を少し説明しますが、その目的は、アプリケーション層のネットワーキングを簡素化し、管理者と開発者の間のギャップを埋めることです。どうすればこれをもう少し簡単にできるでしょうか？どうすれば彼らを再び友達にできるでしょうか？
VPC Latticeの主要機能と利点
VPC Latticeの使命は、開発者がアプリケーションをより速く構築できるようにし、ネットワーキングと接続性を簡素化して、基盤となるネットワーク接続の部分を気にしなくて済むようにすることでした。VPCを実質的に意識する必要がないようにしたかったのです。アプリケーションが、異なるアカウントや異なるVPCなど、適切な場所に存在できるようにし、開発者がこういったことを考える必要がないようにしたかったのです。セキュリティの観点からは、Zero Trustアーキテクチャパターンを採用し、ネットワーク層のセキュリティだけでなく、アプリケーション層のセキュリティを採用するよう強く推進しました。認証と認可を適用することで、可能な限り強力なセキュリティを簡単に実現できるようにしたかったのです。
可視性の観点からは、従来のネットワークレベルのログとメトリクスを提供するだけでなく、多くの新しいメトリクスとログも提供することを確実にしたいと考えました。これについては、すぐに例をお見せします。 管理者側から見ると、すべてはガードレールに関することです。開発者が超高速で進められるようにしながら、組織のセキュリティポスチャを監査し強制するためのツールと制御をどのように提供するか？それを邪魔にならないようにどうやって実現するか？これは同じ3つのタスク、つまり接続性、セキュリティ、可視性をカバーしていますが、少し異なる方法で行います。彼らにとって大きな焦点は、VPCとアカウント間のネットワーク接続という最も一般的な問題をどのように簡素化するかということです。さらに、これらのアカウントがすべて同じIPアドレスを持っていたらどうでしょうか？あるいは、一方がIPv6で他方がIPv4だったらどうでしょうか？こういったことをすべて一度に解決するにはどうすればいいでしょうか？
VPC Latticeは、ネットワーク管理者のためにこれらの問題を本当に解決しています。セキュリティの観点からは、セキュリティポスチャを強制するための集中的なインターフェースを提供しています。そして可視性の観点からは、そのセキュリティポスチャが実際に意図したとおりに機能しているかどうかを確認することができます。開発者が深夜2時に電話をかけてきて「ネットワークの問題だ」と言った場合、あなたは彼らと同じ可視性を持って、IPアドレスが実際に何を表しているのかを判断することができます。実際には、IPアドレスの背後にはおそらくサービスがあります。つまり、それを理解するための橋渡しをしてくれるのです。
本日のプレゼンテーションの概要
さて、今日は何について話すのでしょうか？まず、VPC Latticeの概要について、まだ馴染みのない方のために説明します。それが何であるか、そして主要な核となるコンポーネントについて話します。次に、GA以降にリリースした新機能や機能についても説明します。また、よくある質問とその回答についても取り上げます。3月にローンチして以来、お客様との対話が非常に興味深いものでした。共通の質問がいくつかあり、今日はそれらのいくつかに答えることで、おそらく同じような疑問を持っている方々の助けになればと思います。また、トップアーキテクチャパターンといくつかの人気のあるトピックについても話し、今日のお客様や自社のアプリケーションで直面している問題に対処するのに役立つヒントをお伝えします。最後に、始め方、貢献の仕方、そして私たちとの連絡を保つ方法についてお話しします。
VPC Latticeの主要コンポーネント：サービスとサービスネットワーク
VPC Latticeには、私たちが導入する4つの主要なコンポーネントがあります。これはVPCの機能で、サービス、サービスネットワーク、認証ポリシー、そしてサービスディレクトリです。これらは新しく導入された4つのものです。ただし、必ずしも使う必要はありません。使いたい場合に使えるものです。これから各コンポーネントについて詳しく見ていきましょう。
まず最も重要なのは、サービスとは何かを理解することです。というのも、人それぞれ異なる定義を持っているからです。Kubernetesのサービスもあれば、Lambdaのファンクション・アズ・ア・サービスもあります。では、VPC Latticeにおけるサービスとは何でしょうか？少し説明させてください。VPC Latticeでは、サービスは物理的なものではなく、論理的な抽象概念です。DNSエンドポイントのようなものだと考えるとよいでしょう。各サービスはDNSエンドポイントにマッピングされます。この例では、app1.example.comがサービスです。VPC Latticeのサービスは単なる論理的なフロントエンドで、リスナー、ルール、ターゲットグループで構成されています。
Amazonに馴染みのある方なら、これがElastic Load Balancingファミリーによく似ていることにお気づきでしょう。リスナーはプロトコルのようなものです。HTTPなのか、HTTPSなのか？プロトコルのバージョンは？gRPCなのか？HTTP1やHTTP2といったものです。ルールは非常にシンプルなものもあります。例えば、接続を検出したらデフォルトでターゲットグループに転送するといったものです。これは443ポートや80ポートのすべてをキャッチするものです。あるいは、もっと高度なものもあります。
このスライドに、いくつかの例を載せています。最初の例は、特定のAPIのpath1というパスを、インスタンスAuto Scalingグループで構成されたHTTP2 Auto Scalingグループのターゲットグループ1に送信するというものです。しかし、ユーザーエージェントがJustinというヘッダーを受け取った場合は、Kubernetesサービスがバックエンドにあるターゲットグループ2に送信します。GETリクエストを受け取った場合は、Fargateに送信します。そして、これらの条件に当てはまらないデフォルトのアクションとして、Lambda関数に送信するという具合です。
これは非常に強力です。なぜなら、これらの要素を自由に操作し、開発者が望むどのようなコンピューティングプラットフォームでも組み合わせることができるからです。よく遭遇するのは、開発者と話をすると「Lambdaを使いたいのですが、セキュリティチームがどのように適切に保護できるかまだ理解していないので、X、Y、Zをせざるを得ません」と言われることです。私は管理者の経験がありますから、「分かります」と言います。承認していないものは使ってほしくありません。しかし、この方法では少し多くの制御ができます。前面に抽象化層を置くことで、背後に何があっても同じセキュリティ制御を強制できるのです。
開発者が迅速に動き、適切なプラットフォームを選択できるようにすることは非常に強力です。これは、開発者に好きなプログラミング言語を使わせるのと同じ哲学です。もう一つの例を挙げましょう。ターゲットの重み付けもサポートしています。ターゲットグループはVPC間に存在でき、ターゲットに重みを付けることができます。例えば、/path1に対して、トラフィックの90%をターゲットグループ1に送り、10%をLambda関数にスライドさせることができます。
この図には示していませんが、ターゲットを異なるVPCに置くこともできます。これは非常にクールです。一部の顧客にとっては、これがKubernetesのアップグレードに役立ちます。なぜなら、VPCのライフサイクルを管理できるからです。古いVPCを稼働させたまま、新しいVPCをスピンアップし、新しいクラスターを立ち上げ、サービスを開始します。これはステージング環境のようなものです。10%のトラフィックをフェイルオーバーさせ、検証して問題ないと確信したら、古いVPCを削除できます。
これは何をもたらすのでしょうか？前面に抽象化層（つまりサービス）があるので、クライアントに何もする必要がありません。クライアントは、それが別のサービスであれユーザーであれ、何かが変更されたことさえ知りません。これは、この2つの要素を分離できる非常に強力な機能です。優れた抽象化層なのです。
認証ポリシーとサービスディレクトリの詳細
サービスネットワーク、はい。これは完全に作られた概念です。論理的な抽象化ですね。 Active Directoryや様々なIAMの概念をご存知の方なら、ユーザーとグループという概念があることをご存じでしょう。個々のユーザーに対して、権限を設定したりといった様々なことができます。しかし、大量のユーザーがいる場合、グループを作成してそれらのユーザー全員に影響する共通のポリシーを設定するのが理にかなっています。そして、本当に特定のポリシーを個々のユーザーに設定することができます。ここでも同じ考え方です。
つまり、サービスネットワークは実際にはグループ化のメカニズムに過ぎません。これによっていくつかのことができるようになり、後でその例をお見せします。でも、基本的にはグループ化のメカニズムだと考えてください。サービスをその中に配置し、そのサービスネットワークをVPCに関連付けることができます。これが接続性を可能にするものです。サービスがサービスネットワーク内にあるからといって、それらが互いに通信できるわけではありません。これはプロバイダーとコンシューマーのモデルです。つまり、サービスをその中に配置し、望むものすべてを作り上げ、そしてVPCに関連付けるのです。
認証ポリシー、これが先ほどのユーザーとグループの話に関連しています。 サービスネットワークとサービスに認証ポリシー、つまり基本的にはIAMリソースポリシーを設定できます。そしてここが重要なポイントです。IAMリソースポリシーはおそらみなさんご存じだと思いますが、バケットに設定することができ、リソースは通常AWSのものです。つまり、誰がこのリソースに対して何かを行うことができるかということです。ここでの違いは、そのリソースが今やあなたのサービス、つまりVPC Latticeサービスになり得るということです。
これはIAM認証を使用する非常に強力な方法です。シークレット管理の手間を省き、インスタンスプロファイルやタスクロールを添付する能力、自身のサービス間認証のための手間のかからない認証情報管理、そして何が何と通信できるかについて非常に文脈豊かな認可ルールを書くことができるといった利点があります。そして、これらはサービスネットワークまたはサービスに適用できます。では、2つの場所に適用できるとはどういうことでしょうか。 非常に混乱しますか？いいえ、これは基本的に最小権限モデルです。
サービスネットワークでトラフィックを許可するポリシーを書き、そしてサービス上で別のポリシーを書いた場合、 それが許可を意味するのはお分かりですね。しかし、少し違うことをして、サービスネットワークでトラフィックを許可し、サービス上では許可しない場合、 予想通り、許可されません。つまり、このような柔軟性を持って物事を本当にコントロールすることができるのです。これは基本的にサービスネットワークポリシーの例です。 サービスネットワークポリシーとサービスポリシーは全く同じものです。どちら側にも細かいポリシーや大まかなポリシーを設定できます。認証と認可を使用したくない場合は、サービスポリシーを有効にしないことも選択できます。ただし、私はそれをお勧めします。
通常、お客様にはこう言っています。サービスネットワークに複雑すぎるものを置かないでください。これは安全装置であり、多層防御の一部です。人間が読んで素早く理解できるものであるべきです。ここで私が示しているポリシーは、入ってきたリクエストが少なくとも自分の組織IDで認証されていることを示しています。つまり、少なくとも自分からのものだということです。これが基本的に言っていることです。これは最終目標ではありませんが、安全装置であり、ここでの防御となります。
サービス側では、サービスポリシーを設定するのは依然として管理者かもしれません。これは完全にあなたの組織次第です。開発者やサービス所有者に自分のサービスをより多く制御させる組織もあれば、その責務を分離する組織もあります。あなたにとって合理的なものを選んでください。しかし、このモデルでは、ここで細かい設定を行い、非常に細かく設定することができます。この例では、実際に個々のprincipalを呼び出すことを定義しています。これは典型的なIAMの機能をサポートしているので、principalタグを実際に使用できます。例えば、グループ化して「prodやPCIとタグ付けされたprincipalのみ」というようなことができます。
そして、黄色いテキストの部分では、基本的に私のサービス（つまりwidgetサービス）に対してのみ、リクエストのクエリ文字列パラメータがcolor blueで、GETリクエストの場合に限定しています。非常に文脈特有の豊かなポリシーについて話しています。これをサービスレベルで行う理由は、サービスネットワークでこれを行うと、人間が読めなくなってしまうからです。非常に難しくなってしまいます。だから、そこで分離が必要なのです。
さて、service directoryについてです。これは実際にとてもパワフルです。私たちが持つ最もシンプルな機能であるにもかかわらずです。これは単に、あなたのアカウントで作成したすべてのサービスのリストです。アカウントレベルで、あなたが作成したすべてのサービスと、あなたと共有されたすべてのサービスを表示します。管理者はこれが好きです。なぜなら、そのアカウントにログインして、技術的にアクセス可能なすべてのものを見ることができるからです。開発者もこれが好きです。なぜなら、アクセスしようとしているサービスのURLをコピーして、すぐに作業を始められるからです。非常にパワフルですが、最もシンプルで特別なものは何もありません。コンソールに行けば、そこにあるのは素晴らしいものです。
VPC Latticeの実装例：フルーツとベジタブルのサービスネットワーク
はい、これらが私の考える適切な役割です。必要に応じて変更し、異なるIAMアクセス権限を設定することもできます。ただ、通常お客様とお話しする中で見られるのは、管理者がサービスネットワークを作成し、認証ポリシーでアクセス制御を定義し、VPCの作成だけでなくサービスネットワークとVPCの関連付けも担当するというパターンです。一方、開発者は従来のApplication Load Balancerとその背後のセットアップを行うような立場です。サービスを作成し、トラフィック管理を定義します。これは単純に「デフォルトで私に転送して、あとは私が対応する」というものから、より高度なブルー/グリーンタイプのカナリアスタイルデプロイメントまで様々です。サービスをサービスネットワークに関連付けることもできますし、できないこともあります。一部の企業では「絶対に私だけがそれを行う」と言います。ですので、これは皆さん次第です。お客様の多くにとって、このような役割分担が理にかなっているようです。
では、私の野菜とフルーツサラダ会社を例に、サービスの作成、サービスネットワークの作成、そしてサービスネットワークとVPCの関連付けがどのように行われるかを見ていきましょう。これは主にアーキテクチャの説明になります。実際のデモなどは行いませんが、ご了承ください。後ほど廊下でお会いした際に、ご希望があればデモをお見せすることもできます。
ここには4つのVPCがあり、様々な場所にVPCが存在しています。これらの一部は共有サービスで、一部は自身のアプリケーション内でのみ通信可能なサービス、そして一部はクライアントのみです。クライアントのみというのは、お客様とお話しする中でよく聞くのですが、依存関係を持つアプリケーション、つまりサービスプロバイダーとして多くのアプリケーションから呼び出されるものがある一方で、誰からも呼び出されず、他のサービスを呼び出すだけのバッチジョブのようなアプリケーションもあるということです。これをクライアントと呼んでいます。一部のアプリケーションは両方の役割を果たすこともあります。
さて、それぞれの動作を見ていきましょう。サービスを作成すると、ブルーベリー、ケール、トマト、ニンジン、キュウリのサービスを作成したことがわかります。VPC3では特に何もしていません。なぜなら、ここは他のサービスを消費するだけで、誰もアクセスする必要がないからです。そのため、サービスを作成する必要もありません。Latticeに参加することはできますが、サービスを作成する必要はありません。そして、チェリー、アップル、パイナップルがあります。
まず、すべての果物が互いに通信できるネットワークを作成したいと思います。主にブルーベリー、チェリー、トマトを共有したいのです。サービスネットワークを作成し、fruitsと名付けます。そして、fruitsをVPC4と3に関連付けます。
この時点で、クレイジーな認証ポリシーで拒否されたり、セキュリティグループやネットワークACLでブロックされたりしていない限り、問題ありません。セキュリティグループやネットワークACLがブロックしていなければ、raspberry、banana、2つのバッチジョブ、cherry、apple、pineappleはすべて互いに通信でき、アクセスでき、自動的に発見し合い、接続できます。ここにはロードバランサーはありません。VPC Latticeがロードバランシングとネットワーク接続の機能を全て処理しており、それがうまく機能しているのです。以上が3つのステップです。では、vegetablesについてはどうすればいいでしょうか？
Vegetablesも、共有サービスのkaleのようなものに接続する必要があります。申し訳ありませんが、kaleはcarrotとcucumberがアクセスする必要のあるvegetablesの1つに過ぎません。でも、tomatoはどうすればいいでしょうか？人によってはtomatoはfruitだと言い、またある人はvegetableだと言うので、私にはわかりません。これが私の共有サービスですね。話す相手によって異なりますが、両方からアクセスされる必要があります。個人的にはfruitだと思います。しかし、このようにサービスを複数のサービスネットワークに配置できることを示しています。これにより、そのVPCの接続パターンを自由に定義でき、接続を自動的に設定してくれます。
サービスネットワークを複数のVPCにアタッチしたり、サービスを複数のサービスネットワークにアタッチしたりできます。これにより、必要に応じて階層的なアプローチで操作できます。これらの考え方の全体像です。デフォルトでは、サービスとサービスネットワーク、さらにVPCも全ての境界を切り離せば、セキュアになるように設計されています。サービスは自身のサービスネットワーク内のサービスにのみアクセスできます。これは非常に重要です。なぜなら、特定のセキュリティグループフィルタリング、ネットワークACLフィルタリング、ネットワークレベルの制御、またはアプリケーションレベルの認証認可について言及しなくても、ネットワークを正しくスコープするだけで非常に強力な保護が得られるからです。
VPCがそもそもアクセスできる範囲を適切にスコープするだけで、セキュリティの非常に重要な部分が確保されます。同じデザインで、暗号化を強制することもできます。HTTPSトラフィックのみを許可し、HTTPを許可しないように設定できます。これは、少なくともすべてがHTTPSで暗号化されていることを保証する、非常に強力で簡単な制御方法です。サービス間や、VPCから出入りするすべてのリクエストに対して、認証と認可を強制することもできます。そして再度強調したいのは、ネットワークを適切にスコープすることから始めるという、シンプルなポリシーの重要性です。fruitsとvegetablesの例のように、ポリシーを複雑にする代わりに、新しいサービスネットワークを作成しただけです。
VPC Latticeの主要機能と新機能の紹介
基本的な部分が整ったところで、これらが私たちが立ち上げた時の主要な機能です。これらがVPC Latticeがサポートする主要な特徴と機能です。サービスがVPCやアカウントをまたいでいても問題ありません。AWS Resource Access Managerと統合されているので、個々のサービスを共有することも、サービスネットワークを共有することもできます。これにより、1つか2つのものを共有して消費者に自分のサービスネットワークに配置させたり、サービスのコレクションを共有して単にVPCに関連付けさせたりする柔軟性が得られます。接続に関する他の部分として、これはネットワークアドレス変換を行っています。この例では、そしてこの後数分でパケットフローについて説明しますが、すべてのものがリンクローカルIPアドレス範囲と呼ばれるものでVPC Latticeと通信します。
パケットを受信すると、それは Lattice から来たもので、そこで行われる保護の種類です。また、このプロセスですべてのネットワークアドレス変換を処理します。文字通り、すべてが同じ IP アドレスであっても問題ありません。常に Lattice と通信しており、必要に応じて変換を行うからです。片側が IPv4 で、もう片側が IPv6 の場合や、両側が同時に対応できない移行期間中でも、全く問題ありません。サポートしているプロトコルバージョンは HTTP1、HTTP2、HTTPS、そして gRPC です。つまり、主に HTTP サービスが対象です。これはアプリケーション層のプロキシです。現在、TCP の場合は PrivateLink などと組み合わせて使用します。TCP 用の PrivateLink や Transit Gateway は引き続き機能しますが、これは今のところ本当にアプリケーション層のものに特化しています。
リクエストルーティングには、以前お話したような一般的な機能が含まれています。パス、ヘッダー、メソッド、重み付けされたターゲットグループなどです。これらはアプリケーション層プロキシに期待される機能です。セキュリティの観点から、VPC アソシエーションにセキュリティグループ参照を設定できます。これは非常に強力で、セキュリティグループ参照を使用して、VPC 内のどのインスタンスやリソースが VPC Lattice と通信できるかを選択できます。これは非常に強力なネットワーク層の制御です。
このネットワーク層の制御は IP アドレスに依存せず、セキュリティグループ参照を使用します。さらに、スタックを上に進むと、サービスとサービスネットワークに IAM 認証があります。これにより、完全な多層防御戦略が実現します。
現在サポートしているターゲットタイプは、Instances、Lambda Functions、ALB、IP アドレス、そして Kubernetes 統合です。Kubernetes 用のコントローラーがあり、これらすべてをプロビジョニングします。AWS Gateway API Controller と呼ばれ、オープンソースです。これは Lattice では IP ターゲットとして表示されます。Auto Scaling グループもサポートしています。ECS については、現在でも ECS タスクの前に ALB または NLB を配置する必要があります。
アイデンティティヘッダーの伝播とその重要性
さて、新しい機能は何でしょうか？昨年の re:Invent の講演に参加された方は、その後どうなったのか気になっているかもしれません。 いくつか迅速に進めようとしていることがあります。新しいリージョンをいくつか導入しました。来年はさらに多くのリージョンを計画しているので、お使いのリージョンがまだない場合は続報をお待ちください。AWS Resource Access Manager との統合は GA からありましたが、Customer Managed Permissions という新機能を追加しました。これについては後ほどスライドで詳しく説明するので、ここではあまり触れません。
Shared VPC サポートでは、サービスと共有サブネットを持つことができ、クライアントを共有サブネットに置くこともできます。特に変わったところはなく、うまく機能します。これは多くの顧客にとって非常に人気のある機能です。管理チームがVPCを所有し、消費者にサブネットを分配したい場合に特に役立ちます。VPCレベルのコンプライアンスも大きな特徴です。先ほど述べたように、私たちはVPC機能です。そのため、コンプライアンスのウェブページに記載されているVPCレベルのコンプライアンスはすべてVPC Latticeをカバーしています。ただし、注意点として、FedRAMPのような一部のコンプライアンス認証はLatticeではカバーされていません。これらは、機能ではなくAPIやSDKを個別に認証するサービスです。
Lambdaの新しいイベント構造とアイデンティティヘッダーの伝播は、基本的に同じ機能です。これについては後ほど詳しく説明します。一方はLambda用で、もう一方は他のすべてのプラットフォーム用です。両方をサポートしています。そして、AWS Gateway API Controllerが数週間前にGAになりました。
さて、アイデンティティヘッダーの伝播についてです。これは私が最も気に入っている機能の一つです。非常に強力で、この機能をリリースした時のLinkedInの投稿で、今までで最も多くの「いいね」をもらいました。これは実際、すべてのリクエストに対して、バックエンド、つまりターゲットに向けて大量のメタデータを含むヘッダーを追加します。呼び出し元が誰だったか、認証されていたか、認証されていた場合は何がプリンシパルだったかなどの情報が含まれます。ソースVPCやアカウントなどの情報も含まれます。この後のスライドで詳細を見ていただけますが、IAM Roles Anywhereとも連携します。
これがヘッダーの実際の様子です。HTTPサーバーからの実際のスナップショットで、ここに含まれる情報です。標準的なX-Amazon Anywhereアイデンティティにカバーされているものもあります。IAM Roles Anywhereを使用している場合、ここから非常に便利な情報を得ることができます。SPIFFEロールをポリシーで使用したいと要望するお客様がいました。つまり、IAMプリンシパルだけでなく、SPIFFE IDを使用して認可ポリシーを書けるようにしてほしいということです。これによってそれが可能になります。X-509 SANやname、URIなどの情報から、実際にそのコモンネームを識別できるのです。
Lambdaのイベント構造も、基本的に同じ機能です。ただし、これはLambdaにイベント構造として配信されます。つまり、この豊富な情報がすべて得られるわけです。非常に強力ですね。では、なぜこの機能が重要なのでしょうか？まず、開発者のHTTPログに、リクエストが来た環境やアイデンティティに関するすべての情報が直接含まれるようになります。深夜2時に、開発者がタイピングしながらログを見ている時、「これは自分のサービスなのか？」と思ったら、そこにリクエストが通ってきた全経路と全ての情報が見えるのです。他のツールを見なくても、HTTPログを見るだけでいいのです。トラブルシューティングに非常に役立ちます。さらに、バックエンドでの追加のカスタム認可にも使えます。また、パーソナライゼーションにも使えます。この情報に基づいて、リクエストが到着した時の扱いを変えることもできるでしょう。非常に強力な機能なので、初期リリース時に見逃した方は、ぜひ検討してみてください。
カスタマー管理の権限：リソース共有の新しい方法
カスタマー管理の権限は非常に強力な機能です。ここで詳しく説明しましょう。
サービスやサービスネットワークなどのリソースを共有する際、それらのリソースに対して人々が実行できるアクションがあります。例えば、サービスネットワークを共有した場合、共有相手は何ができるでしょうか？ サービスを配置できるでしょうか？VPCに関連付けることはできるでしょうか？それとも両方できるのでしょうか？これらは非常に重要な質問です。この機能を使用すると、共有先のIAM設定に触れることなく、共有時にポリシーを添付して「VPCへの関連付けのみ許可し、サービスの配置は許可しない」といった指定ができます。
つまり、こんな感じです。 相手側のIAM権限に触れることなく、その人が許可される操作を実際に記述できるのです。 これは非常に強力な機能で、多くのことを大幅に簡素化します。
VPC Latticeのトラフィックフローと料金体系
さて、ここからは質疑応答に移りましょう。これらは典型的な質問です。私が選んだ数個の質問を紹介します。私は毎日顧客と話をしていますが、多くの場合、共通の疑問が出てきます。皆さんが独自の問題だと思っていることも、隣の人も同じ問題を抱えていることが多いのです。では、「Amazon VPC Latticeでトラフィックはどのように流れるのか？」という素晴らしい質問から始めましょう。
VPC Latticeでは、大規模な移行作業なしで、できるだけ多くのシステムで使用できるよう、可能な限り汎用的なものを目指しました。特殊なカスタムサービスディスカバリーなどは行っていません。魔法のように見えるかもしれませんが、トラブルシューティングを容易にするため、できる限り基本的なアプローチを取るよう努めました。
VPC Latticeでサービスを作成する際、サービスネットワークとサービスがすでに設定されていると仮定すると、DNSネームが生成されます。リージョン、サービス名、長いハッシュ値、そして.on.awsという形式です。また、独自のカスタムドメイン名を定義することもできます。ほとんどの人はこちらを使用し、通常は私たちの長くて醜い名前は使用しません。そして、それにエイリアスを設定できます。
この例では、billing.myapp.comというエイリアスを設定しています。inventoryサービスがこれを呼び出しています。標準的なDNSリクエストがVPC Resolverに送られ、billing.myapp.comの場所を問い合わせます。 Route 53 resolverの設定に応じて、VPC resolverから返答があり、billing.myapp.comは実際にはVPC Latticeサービスへのエイリアスレコードで、実際のIPは169.254.171.25であると返されるかもしれません。ご覧の通り、これは実際の宛先サービスのIPではなく、クライアントと同じIPです。
しかし、これは実際にはリンクローカルアドレスであり、「了解、これについて知っています。これはVPC Latticeサービスで、あなたはprodサービスネットワークにいるのでVPC Latticeが有効になっています。トラフィックを直接私のENIに送信します。このサービスは私に直接接続されています」ということを意味します。つまり、トラフィックはENIを通じて外に出て、VPC LatticeがVPCサブストレートに組み込まれているため、VPCは今何をすべきか正確に把握しています。そして、そのパケットを更なる処理のためにプロキシに送ります。
このようにして、トラフィックは自動的に送信されます。注意点として、私たちは意図的にセキュリティグループを尊重しています。何かをバイパスしたくないからです。そのため、セキュリティグループがVPC Latticeのリンクローカル範囲をブロックしている場合、トラフィックは機能しません。何か問題が発生した場合、通常はまずここをチェックすべきです。セキュリティグループが許可しているかどうかを確認してください。この場合、セキュリティグループとネットワークACLが許可している限り、問題ありません。VPC LatticeのIPアドレスについて心配する必要はありません。これには管理されたプレフィックスリストが使用されます。
トラフィックがVPC Latticeプロキシに到達すると、トラフィックの検証、HTTPSトランザクションの実行、ヘッダーの識別を行います。認証が有効になっている場合、サービスとサービスネットワークの両方の認可ポリシーを通して実行します。これらは2つの異なるホップではなく、一度に行われます。これらを統合して一度に行うので、2回実行する必要がある大きな遅延は発生しません。
これは典型的なポリシーで、このような形になります。 まず、リクエストは認証されていますか？はい、リクエストは私の組織IDから認証されました。これは素晴らしいスタートポイントです。繰り返しになりますが、これが最善の方法です。認証をオンにする必要はありません。実際、クライアントに認証を要求する必要もありません。
ただし、クライアント認証がなくても、ネットワークレベルのコントロールと認証ポリシーを実施することは可能です。認証の使用をお勧めしますが、必須ではありません。
さて、サービスネットワークに到達し、パケットをそこにルーティングし、認証ポリシーを通過させました。 DNSリクエストを行い、パケットをVPC Latticeにルーティングし、認証ポリシーを通過させた後、承認され許可されました。これで、トラフィック管理を行うことができます。ここでSNERTルールを確認し、開発者やサービス所有者が定義したパケットの実際のルーティング方法に基づいてターゲットを決定します。この時点で、トラフィックはVPCやアカウントを越えて自動的に目的地にルーティングされます。
トラフィックは別の169.254アドレス（Latticeの範囲）から到着します。セキュリティグループでこのトラフィックを許可する必要があります。そうしないと、許可されません。これは管理されたプレフィックスリストの図です。 IPを直接使用せず、特定のIPを気にする必要はありません。管理されたプレフィックスリストを使用してください。IPv4用とIPv6用があります。両方を使用し、すべてに適用すれば問題ありません。
このスライドは読み上げませんし、皆さんにも読んでほしくありません。後で参照したい場合は、このスライドの写真を撮っておいてもいいですが、今は気にしないでください。カメラを下ろすのを確認するまで、ここで2秒ほど待ちます。
マネージドサービスとしてのVPC Latticeのメリット
では、料金体系についてお話しましょう。誰もが知りたがっていることですね。サービスとは何か？サービスの各インスタンスごとに料金を支払うのでしょうか？料金には3つの側面があります。通常、ほとんどのお客様は実際にはそのうちの2つしか見ていません。サービスごとの時間単位の料金、処理されるギガバイト数に基づくデータ処理料金、そして1時間あたりのリクエスト数に対する料金です。
1時間あたりのリクエスト数に対する料金は、通常お客様があまり気にしないものです。というのも、80%、90%、時には100%のサービスをカバーする無料枠があるからです。最初の30万リクエスト/時間は無料です。それを超えると、100万リクエストあたり10セントになります。超大規模なサービスをお持ちの場合はこの枠に該当するかもしれませんが、80パーセンタイルやロングテールではそこまで達しないでしょう。
サービスごとの時間単位の料金については、IEDでは1サービスあたり月額18ドル程度と考えることができます。これにはネットワークレベルの接続性やアプリケーションロードバランシング機能などが含まれていることを覚えておいてください。これはDNS名なので、特定のDNS名の背後に複数のパスがある場合でも、それは1つのサービスです。複数のサービスではありません。つまり、非常に柔軟な考え方ができるのです。
アタッチメントやエンドポイントのコストはありません。これは、消費者側に料金を請求する他のAWSサービスとは少し異なります。このサービスを消費する1万のVPCがあったとしても、消費するたびに料金を支払うわけではありません。サービスに対してのみ支払い、消費者側には関連料金はありません。VPCアソシエーションは無料です。繰り返しになりますが、1つのサービスは何千ものターゲットで構成される可能性がありますが、ターゲットごとに料金を支払うわけではありませんし、各ターゲットの隣でロードバランサーを実行するための料金を支払うわけでもありません。フロントエンド、つまりその論理的な抽象化に対してのみ料金が発生します。
データ処理に関しては、ここで触れておくべきことがあります。これは全てを包括しています。ロードバランサー、ネットワーク接続性、そしてデータ転送コストやその他全てをカバーしています。Availability Zone間でのやり取りに関するデータ転送コストはありません。全てがこのデータ処理料金に含まれているのです。
マネージドサービスのメリットについてお話ししましょう。これは重要な点です。なぜなら、多くの人が忘れがちですが、インフラ費用を予算項目として持つことが本当に大切なのです。自社のコストとインフラの効率化を図るには、まずその費用を把握する必要があります。そう考えると、少し変に聞こえるかもしれませんが、実際には非常に重要なのです。
多くの顧客が自前でインフラを運用している場合、我々はこのような問題を発見します。彼らは、実際のプロキシのコストなどではなく、EC2のコストとして計上されているかもしれない関連コストを考慮していないのです。インフラの真のコストを明確に把握し、それを予算項目として見ることが重要です。このような従量課金型のソリューションは、効率化を推進するのに非常に役立ちます。
スタッフの生産性という観点では、マネージドサービスの目的は、プラットフォームの運用に費やす時間を減らし、プラットフォームの利用に多くの時間を割くことです。ビジネスの成長に伴いアプリケーションの規模が拡大するにつれ、スピードとシンプルさが重要になります。マネージドサービスの背後で行われているイノベーションを活用しましょう。これはVPC Latticeに限った話ではなく、マネージドサービス全般のメリットについての一般的な情報です。
運用の回復力という観点では、AWSは大規模な運用の回復力と可用性を非常に重視しています。VPC Latticeは、単一のAZでのデプロイメントで99.9%のアップタイムSLAを提供しています。そして、アプリケーションを複数のAZにデプロイする場合は、99.99%のSLAを提供しています。フルマネージドサービスのメリットは、サイドカープロキシやゼロデイセキュリティイベントが発生した場合のダウンタイムを最小限に抑える心配をする必要がないという安心感です。これらは、ユーザーが何もしなくてもバックグラウンドで処理されます。
VPC Latticeは、シンプルに言えば、より速く進むことを可能にします。開発者が新しい顧客向け製品や機能を構築し、ネットワーキングの専門家になるのではなく、必要なものを提供することに集中できるようにします。つまり、差別化されていない重労働を取り除くことが目的です。もちろん、自社で保持して行いたい特定のタスクがあれば、それを続けることができます。しかし、実際のビジネスニーズに価値を提供していないと思われる特定のタスクがあれば、それを評価する価値があります。
VPC Latticeの柔軟性：マイクロサービスからサービスメッシュまで
VPCごとに複数のサービスネットワークを持つことはできるのでしょうか？これはよく聞かれる質問です。簡単に言えば、答えはノーですが、実際には必要ありません。サービスは好きなだけ多くのサービスネットワークに属することができます。もし特殊な接続要件を持つVPCがある場合は、新しいサービスネットワークを作成し、そこにそれらのサービスを配置すればいいのです。一部の顧客は、ほぼ1対1のマッピングを行い、そのVPC用のアプリケーション層ネットワークのようなものを定義しています。左下の「Top Secret」の例では、まさにそれを示しています。まだ必要なサービスがいくつかあります。そのVPC専用のサービスネットワークを構築し、接続することができます。
VPC Latticeはマイクロサービス専用なのでしょうか？これは良い質問です。結論から言うと、そうではありません。私たちは何であるかを気にしません。マイクロサービスだけでなく、モノリスでも、その両方の組み合わせでも構いません。これが要点です。バックエンドの複雑さを抽象化したいのです。フロントエンドの抽象化を持つ全ポイントがここにあります。VPC Latticeの背後にあるすべてはIPアドレスです。何も隠していませんし、複雑なことは何もしていません。ただ、これらのものの前に抽象化層を提供しているのです。
そこで、parking.comが移行プロセスを開始します。ゆっくりと物事を移行し、自分のペースで近代化を進めることができます。クライアントはまだparking.comを呼び出していますが、ratesサービスを移行したら、そのサービスにロードバランスをかけることができます。paymentサービスを移行したら、それも同様に行えます。そして、他のすべてのものは、デフォルトのフォワードルールを使ってモノリスに戻すことができます。永久にそのままにしておくこともできますし、それも移行することもできます。つまり、これはどのようなアプリケーションにも使用できるもので、マイクロサービスだけのものではありません。
VPC Latticeはサービスメッシュなのでしょうか？これも大きな質問です。そもそもサービスメッシュとは何でしょうか？通常、サービスメッシュはコントロールプレーンとデータプレーンで構成されています。コントロールプレーンは通常、Istio、LinkerD、App Meshなどで、データプレーン部分はEnvoy、LinkerD、Nginxなど、多数存在します。通常、コントロールプレーン部分は自分で管理するか、マネージドサービスを利用します。そして、すべてのワークロードの隣にサイドカープロキシ、つまりデータプレーンを配置します。そのワークロードのインスタンスが1,000個ある場合、1,000個のプロキシがすべてのワークロードの隣で動作することになります。
これには良い面も悪い面もあります。長所と短所があり、多くのクールなアプリケーション層のタスクを処理します。サービスディスカバリー、リクエストレベルのルーティング、暗号化、認証など、本当に便利な機能があります。通常はKubernetesでのみ動作します。他の方法もありますが、難しい場合があります。ここでもう一つ指摘したいのは、
ネットワーク接続は処理しません。システム内に存在するオーバーレイのようなものです。コスト面から見ると、支払う対象が明確な項目として存在しないことが多いです。通常、コントロールプレーンの実行に対して支払い、そしておそらくEC2上のワークロードの隣でデータプレーンにも支払うことになります。ワークロードが拡大するにつれて、プロキシも同様に拡大し、処理とメモリの使用量もワークロードと並行して増加します。そのため、課題となるのは、コンピューティングコストとして支払っているということです。
VPC Latticeは少し異なります。完全マネージド型のサービスで、コントロールプレーンもデータプレーンも管理されています。ユーザー空間には存在せず、VPCに直接組み込まれています。ワークロードとは完全に独立してスケールします。これはパフォーマンスの観点から非常に重要です。ワークロードが拡大しても、レイテンシーがワークロードと共に増加するのではなく、VPC Latticeは一定のラインを保ち、一貫性を維持します。これは、実際のワークロードが拡大してより多くのメモリリソースを必要とする際に、その隣に存在しないためです。同様の一般的なタスク、つまりサービスディスカバリー、リクエストレベルのルーティング、暗号化、認証を処理し、さらに認可も行い、ネットワークレベルの接続も処理します。これが大きな違いです。これらの機能と特徴の両方を備えています。そして、先ほど説明したように、支払いモデルも少し異なります。サイドカーを実行しているターゲットの数ではなく、サービスの使用量に応じて支払います。
つまり、要約すると、これはサービスメッシュではありませんが、一部の機能は同じで、実装方法が少し異なります。コンピューティング環境やユーザー空間ではなく、VPCに直接組み込まれており、サイドカーはオプションです。特定のタスクにサイドカーを使用し続けたい場合や、特定の機能を別に処理する必要がある場合は、引き続き使用できます。使用しないでくださいとは言っていません。ただ、必須ではないということです。基本的な要件を持つ多くの顧客にとっては、サイドカーを使用する必要はないはずです。そのため、なぜ余計な複雑さを加える必要があるでしょうか？ただし、必要な場合は確実に使用できます。完全マネージド型のコントロールプレーンとデータプレーンを備え、インスタンス、コンテナ、サーバーレスにわたって機能します。非常に柔軟性が高いですね。
VPC Latticeの主要アーキテクチャパターン
さて、主要なアーキテクチャパターンについて話しましょう。小規模から始めます。誰もが少なくともどこかの時点でここにいたはずです。これは新しいアプリケーションや新しい製品を始める大企業でも同じかもしれません。誰もがどこかでここから始まります。ここで強調したいのは、私たちがVPC Latticeについて話すとき、 通常はVPCやアカウント間の大規模な接続問題をすべて解決するものとして話しますが、実際には複雑さを軽減することで小規模ユーザーにも役立つということです。単なるロードバランサー、単なるプロキシだからです。そのため、単一のVPC内でも、アプリケーション間やサービス間の通信を大幅に簡素化できます。複数のVPCを持つ必要はありません。サブネットの相互作用などを必要とせずに、接続、アプリケーションレベルのロードバランシング、認証、認可などを最も迅速に実現する方法です。これは非常にクールなユースケースで、シンプルさを実現します。
もう一つの部分は、同じアプリケーションかもしれませんが、おそらくこの会社が別の会社を買収したような場合です。規模が拡大しています。 ここで複数VPCの話が出てきます。VPCやアカウントをまたいでアプリケーションを追加する場合、オペレーションやオンボーディングのプロセスは変わりません。まったく同じで、何か違うことを意識する必要はありません。インフラを変更せずに同じ利点を得られます。VPC間に新しい接続パターンを導入したり、サブネットのルーティングを正しく設定することを心配したりする必要はありません。すぐに使えるのです。
なぜVPC Latticeは優秀なセラピストなのでしょうか？それは、問題に対処するのが得意だからです。 「addressing」という言葉に注目してください。少なくとも一人が笑ってくれて嬉しいです。さて、先ほど話したように、 IPv6移行における重複アドレスの問題は、様々な理由から皆の頭を悩ませています。私たちはみんながIPv6を使うようになってほしいのですが、20年後も20年前と同じ会話をしているような気がします。そこでこれが役立つのです。サービス間通信、つまり東西通信について話すとき、まだIPアドレスのことを心配したり考えたりする必要はありません。これによってその必要性が完全に取り除かれ、抽象化することができます。
もし一部のサービスがIPv6に移行する必要があるなら、例えば公開サービスなどの場合、それは可能です。クライアント側に同時に移行させる必要はありません。5年間資金が投入されていないクライアントかもしれません。そんな役に立たない製品のためにすべての労力を費やしたいですか？各チームに自分たちの優先順位を決めさせましょう。IPv6に移行する意味があるなら、それでいいでしょう。残りはこれに任せてください。ただし、IPv4が正しい方法だと主張しているわけではありません。これは単に移行を容易にし、迅速に進めるための戦略として使えるということです。
この話題についてもっと聞きたい方は、Cables2Cloudsの人たちと素晴らしいポッドキャストを行いました。 このQRコードを読み取れるかどうかわかりませんが、読み取れない場合は後で教えてください。そのポッドキャストでこの話題を取り上げており、設定方法などを示す素晴らしいデモもあります。自分のペースで移行してください。
さて、これは killer です。 最初、みんなストレスを感じていました。VPC Latticeを使いたいけど、既存のインフラがある。どうすればいいの？あるいは、すでにサービスメッシュを実装しているけど、どうすればいいの？実は、とても簡単です。これらを並行して運用できることがわかりました。標準的なプロトコルを使用しているだけです。この例では、右側に旅行サービスがあります。皆さんにとっても右側だと思います。Application Load Balancerの背後にあります。そして、Transit Gatewayを通じて接続しています。 これは標準的なDNSリクエストで、travel.myapp.comは10.0.0.1というロードバランサーのIPアドレスで、ルートテーブルエントリとTransit Gatewayを経由してその宛先にルーティングされます。
ここで、何も変更せずにVPC Latticeサービスを有効にできます。VPC Latticeサービスを作成しても、何も変わりません。他のすべてのものは引き続き機能します。DNS 10.0.0.1への接続も可能です。ただ、新しいDNSアドレスが提供されるので、この新しいアドレスに接続したい場合は接続できます。では、それはどのように見えるでしょうか？サービスを作成し、このサービスネットワークに配置し、 そのVPCをサービスネットワークに関連付けました。この時点では、まだロードバランサーを使用しており、何も変更していません。
しかし、今はそれを変更したいと思います。ただし、1つのVPCに対してのみ変更したいのです。まだ全体に適用する準備ができていないからです。そこで、VPC2にプライベートホストゾーンを設置し、travel.myapp.comというDNSレコードをDNSサービスではなくVPC Latticeサービスにエイリアスするように指示します。これにより、大幅に簡素化されます。両方を好きなだけ長く、または短く稼働させることができます。すべてのVPCに適用したい場合は、プライベートホストゾーンを使用する必要はなく、パブリックホストゾーンを使用できます。これは非常に柔軟なオプションで、多くの選択肢を提供します。
まとめると、VPC Latticeは既存のアーキテクチャと連携します。サービスディスカバリは特別なものではなく、DNSです。しかし、その真の力は、DNSがローカルであることです。DNSをフェイルオーバーメカニズムのようなものとして使用しているわけではないので、TTLなどについてそれほど心配する必要はありません。IPは変更される可能性があるので、DNSを使用する必要はありますが、それほど頻繁ではありません。クライアントとサービスを個別に移行できます。これは単なる抽象化なので、自分のペースで行うことができます。一部のVPCに対して行ったり、サービスとクライアントを個別に移動したりと、あなたにとって適切な方法で実行できます。
VPC Latticeを活用した外部接続とIngressパターン
外部接続について。少しペースを上げていきます。Ingressは非常に人気のあるトピックです。多くのお客様に共通するパターンとして、多数のVPCがあり、それぞれのVPCに多くのアプリケーションがある場合、中央集中型のIngressをどのように実現するかという課題があります。なぜなら、すべてのVPCにインターネットゲートウェイを設置するのは悪夢のようなものだからです。これをどうすればいいでしょうか？そこで、お客様は中央集中型のVPCを持ち、そこでIngressを処理するモデルに移行しています。VPC Latticeでも同じことが可能です。唯一の違いは、VPC Latticeでは接続がVPC Latticeに対応したVPCから来る必要があるということです。
つまり、何かしらのものが必要で、それがここで示しているものです。Elastic Load Balancer（ALBやNLBなど、どちらも問題ありません）があり、そしてプロキシを実行するEC2などがあります。これはお好みのプロキシを選択できます。Auto Scaling groupを持つ静的プロキシでもよく、リクエストを転送するだけのものでも構いません。今のところ、何かしらのものが必要です。外部のクライアントがELBに接続し、プロキシに到達して接続を確立し、そこからすべてのネットワーク接続が解決されます。認証や認可を行い、実際のアプリケーションVPCへのすべてのIngress点を遮断することができます。
もう1つの非常に人気のある例として、ファイアウォールを前面に配置できるかという質問があります。もちろん可能です。これは典型的なVPCアーキテクチャです。AWS Network Firewallを使用することも、Gateway Load Balancerと組み合わせてお好みのファイアウォールベンダーを使用することもできます。すべてそのまま動作します。AWS ShieldとAWS Web Application Firewallも同様に機能します。Elastic Load Balancerの前に配置するだけで、Ingressにも適用できます。これは現在完全にサポートされています。
マルチリージョンについてはどうでしょうか？あるリージョンから別のリージョンへの接続をダイヤルしたい場合や、可用性やパフォーマンスの理由でそうしたい場合のイングレスについてはどうでしょうか？AWS Global Acceleratorを使えば同じことができます。Global AcceleratorはELBと統合されています。同じアーキテクチャを使って、複数のリージョンでサービスとサービスネットワークを複製し、必要に応じてGlobal Acceleratorを使ってトラフィックを移動させることができます。
このトピックに興味がある方は、私の同僚のAdam PalmerとPablo Sánchez Carmonaが書いたブログを是非チェックしてください。彼らはこのアーキテクチャパターンについて素晴らしい記事を書いています。Amazon ECS FargateとNetwork Load Balancerを使ってこれを実際に構築できるCloudFormationテンプレートも用意されています。ECS Fargateタスクは非常にシンプルで基本的なNginxプロキシを実行しているだけです。つまり、すぐにこれを始められるということです。このデザインはマルチリージョン接続でも人気があります。 つまり、あるリージョンのVPCから別のリージョンへの接続がある場合、必ずしもインターネット上のユーザーである必要はありません。ぜひチェックしてみてください。
もう一つのパターンはサーバーレスモデルです。これは実際にプレビュー中の顧客が、この問題を解決しようとしていたときのものです。彼らは私に何も言わずにこれを自分たちで行い、私が「どうやってそれをしたの？」と聞いたら、「ただAPI Gatewayを組み立てただけです。フロントにインターネットゲートウェイを持つVPCを置きたくなかったので、Lambdaプロキシを使いました」と答えました。そのLambdaプロキシは単なるLambda関数で、中央のVPCにENIを持つプライベートなLambda関数です。イングレスVPCにさえインターネットゲートウェイがありません。非常に強力です。
ここで素晴らしいのは、Lambdaプロキシが何でも好きなものにできることです。すぐ後でQRコードをお見せするブログに、いくつかの例があります。ここでヘッダー操作を行うこともできますし、何でもできます。このようなことができるのは非常に強力です。そして、完全にサーバーレスなイングレスです。 これがそれについて説明しているブログです。ぜひチェックしてみてください。比較的新しいものですが、多くの注目を集めているので、読む価値は十分にあります。
VPC Latticeの学習リソースとコミュニティ
最後に、フォローアップ項目をいくつか紹介したいと思います。私たちに連絡する方法、教育を続ける方法、始め方などをお示しして、まとめとしたいと思います。AWS Workshop Studioで多くのワークショップを開発しました。これは完全にガイド付きのワークショップです。ここに入って、ラボで遊ぶことができます。Amazon ECS用、Amazon EKS用、AWS Lambda用のものがあります。実際にどのように行うかを案内してくれる様々なワークショップがあると思います。
実際に手を動かして、自分で触れて確認することができます。このような体験は時に非常に有用です。Workshop Studioへのリンクは、そのQRコードに含まれています。現在は4つのワークショップがあり、今後さらに増やしていく予定です。
VPC Latticeに関するブログ記事は数多くあります。その中でも、今日お話しした内容に関連する、さらに詳しく掘り下げた記事をいくつか紹介しました。
これは300レベルの講演なので、一部の方には難しすぎるかもしれませんし、逆に物足りない方もいるかもしれません。ただ、今回触れなかったIPv6導入に関する記事は、移行方法を示しています。これはCables2Cloudポッドキャストと合わせて参考にするとよいでしょう。一番上の記事はサーバーレスVPC Lattice接続の構築方法を、そして一番下の記事はVPC LatticeとVMware環境の統合方法を紹介しています。後者は特定の目的に特化した興味深いソリューションで、VMwareワークロードを扱っている方にとっては、始めるのに最適な方法です。
また、オンラインで公開している人気の高い動画をいくつか紹介したいと思います。YouTubeのプレイリストを作成しました。これは右側に表示されているもので、今後も随時追加していく予定です。
Amazonだけでなく、他のポッドキャスターやVPC Latticeのデモを作成した方々の動画も含まれています。興味深いものを見つけたら、随時追加していきます。
左側に表示されているのは、TwitchのRouting Loopです。まだ見ていない方は、開発者の方でも是非ご覧ください。面白いモデレーターと充実したコンテンツがあります。特にこの動画は強力です。数日前にブログ記事を公開しましたが、QRコードはそのものではありません。タグを使用して人間の介入を減らし、サービスアソシエーションやサービスネットワークとVPCのアソシエーションを自動化する方法を紹介しています。この動画では、その方法のデモを見ることができます。また、最近公開されたブログ記事では、その実装コードも共有されています。
Gateway API コントローラーとKubernetes統合
そして最後になりますが、Gateway API コントローラーが一般提供されるようになりました。これは Kubernetes ワークロード向けのオープンソースコントローラーです。VPC Lattice について学ばなくても、このコントローラーを使用して VPC Lattice の全ての機能を自動的に利用できます。ネイティブの Kubernetes API を使用するだけで、全ての操作を行うことができます。ぜひコミュニティにご参加ください。皆さんが見つけた問題点をお聞かせいただければ幸いです。ここでいう問題点とは、新機能や新しい機能性についてのご要望などです。プルリクエストを作成していただければ、私たちが必ず確認いたします。
Gateway API コントローラーの概要に興味がある方は、API コントローラーと Kubernetes 統合に特化した2つのブログ記事がありますので、ぜひご覧ください。そして最後に、もし皆さんがまだ会場にいらっしゃるなら、特に熱心な方々は、ぜひ Alex と Matt のトークに参加してください。Wizard トークはいつも金曜日にブレイクアウトセッション形式で行われ、高度な VPC 設計と機能について扱います。Alex と Matt は過去数年間素晴らしい発表をしており、今回も素晴らしい内容になるでしょう。VPC Lattice も取り上げられますし、他の一般的な VPC ネットワーキングサービスについても触れられます。まだ会場にいらっしゃる方は、ぜひ NET306 セッションをチェックしてください。
セッションの締めくくり
ありがとうございました。そして、このセッションの感想をぜひお聞かせください。単に「こんにちは」と言うだけでも構いません。
※ こちらの記事は Amazon Bedrock を様々なタスクで利用することで全て自動で作成しています。
※ どこかの機会で記事作成の試行錯誤についても記事化する予定ですが、直近技術的な部分でご興味がある場合はTwitterの方にDMください。
Discussion