Amazon VPC Lattice と VMware Cloud on AWS によるアプリケーションネットワークのシンプル化

モダンアプリケーションは、モジュール式かつ分散型のコンポーネントで構築されています。お客様は、特にハイブリッドクラウド環境において、サービスコンポーネント間のアプリケーションネットワーキングをシンプル化する柔軟な方法を求めています。
VMware Cloud on AWS を利用することで、お客様はオンプレミスの vSphere 環境からのワークロードとアプリケーションをシームレスなハイブリッドクラウド体験で Software Defined Data Center (SDDC) に簡単に移行できます。
ワークロードを VMware Cloud on AWS に移行するにつれ、SDDC 上で実行されている既存のアプリケーションと、ネイティブ AWS サービスを使用してデプロイされた新しいサービスとの接続要件に対処することが不可欠となってきます。
異なる AWS アカウントや Amazon Virtual Private Cloud (VPC) 間のサービス接続をサポートするには通常、VPC ピアリング、AWS Transit Gateway、AWS PrivateLink、サービスメッシュプロキシなど、追加のネットワーキングサービスとコンポーネントをプロビジョニングする必要があります。
さらに、複数の AWS アカウントと VPC を持つお客様は、重複する CIDR ブロックや環境分離の要件などの課題に直面することが多く、サービス間のアンダーレイとなる IP 接続性の構築をさらに複雑にします。
この記事では、Amazon VPC Lattice が SDDC やクラウドネイティブ環境全体のサービス間通信を、アンダーレイネットワークの複雑さを抽象化しながらシンプル化する方法を見ていきます。また、VPC Lattice を活用して、VMware Cloud on AWS からクラウドネイティブサービスへアプリケーションをシームレスに変換、移行できることも説明します。

Amazon VPC Lattice 概要

2023 年 3 月、AWS はアプリケーションネットワーキングサービス「Amazon VPC Lattice」の一般提供を発表しました。VPC Lattice は、サービス間通信のディスカバリと接続を容易にするものです。
VPC Lattice は、論理的なアプリケーションレイヤーネットワークであるサービスネットワークを作成します。これにより、異なる AWS アカウントや Amazon VPC 間でのサービスネットワーク全体のクライアント (コンシューマー) とサービス (プロバイダー) 間のアプリケーション通信を、アンダーレイネットワークの複雑さを抽象化してシンプル化します。
以下の図を元に Amazon VPC Lattice の主なコンポーネントを確認しましょう。

図1 – Amazon VPC Lattice の主なコンポーネント

サービス: VPC Lattice サービスは、特定のタスクや機能を提供するカスタマーアプリケーションを表します。サービスは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、サーバーレス関数など、さまざまなコンピュートオプションで実行できます。VPC Lattice サービスは、AWS Resource Access Manager (RAM) を使用して他の AWS アカウントと共有できます。VPC Lattice サービスには、次の要素が含まれます。
- ターゲットグループ – アプリケーションやサービスを提供するリソースの集まりです。ターゲットには、EC2 インスタンス、IP アドレス、AWS Lambda 関数、Application Load Balancer、Kubernetes Pod を指定できます。
- リスナー – 定義されたプロトコル (HTTP/HTTPS) とポート番号に基づいて、ターゲットグループ内のターゲットに接続リクエストをルーティングするプロセスです。
- ルール – 優先順位、条件、アクションが定義されたアプリケーションフローを制御するルーティングルールです。
サービスネットワーク: サービスの集合を論理的に区切る境界。VPC Lattice サービスと VPC をサービスネットワークに関連付けて、サービス接続を容易にすることができます。RAM を使用して、サービスネットワークを他のアカウントと共有することもできます。
サービスディレクトリ: 所有または RAM 経由で共有されているすべての VPC Lattice サービスの中央レジストリ。
認証ポリシー: サービスへのアクセスを制御するために、サービスネットワークまたはサービスに関連付けることができる AWS Identity and Access Management (IAM) ポリシー。

VPC がサービスネットワークと関連付けられると、VPC 内のクライアントは Domain Name System (DNS) を使用して、サービスネットワークに登録されたサービスを自動的に検出できるようになります。さらに、登録済みサービスのすべてのアプリケーション間トラフィックは VPC Lattice を通過するようになります。
VPC Lattice は、IAM ベースの認証ポリシーを使用したコンテキスト固有の認証によって、アプリケーション接続のセキュリティも強化します。これにより、顧客は細かいトラフィック制御とエンドツーエンドの可観測性が得られます。

VPC Lattice の詳細については、このブログ記事と Amazon VPC Lattice リファレンスアーキテクチャを参照してください。

VMware Cloud on AWS と VPC Lattice の統合

SDDC ENI を介した Application Load Balancer の活用

VMware Cloud on AWS 上で実行されているアプリケーションを Amazon VPC Lattice と統合するには、Application Load Balancer が必要です。これは、VPC Lattice が一意のリンクローカルアドレスレンジの 169.254.171.0/24 を使用しているためです。このアドレスレンジは VPC 内でのみローカルにアクセス可能で、SDDC 外部にルーティングできません。
そこで、Connected VPC 内に Application Load Balancer をデプロイすることで、 VPC Lattice からの着信リクエストを終端できます。これにより、広帯域かつ低レイテンシの SDDC Elastic Network Interface (ENI) を使用して、SDDC 上にホストされているワークロードにアプリケーションフローを IP ターゲットとしてルーティングできます。サンプルアーキテクチャは以下の通りです。

図2 – Application Load Balancer を介した SDDC ENI 統合

SDDC と Connected VPC 間のデータ転送は、SDDC とネイティブサービスが同じ AWS アベイラビリティーゾーン (AZ) 内にデプロイされている限り、いかなる egress 通信コストも発生しません。
以下のスクリーンショットに示すように、Connected VPC 内に内部 Application Load Balancer をプロビジョニングすると、ユーザーガイドに従って、SDDC 上で実行されているアプリケーション向けの Lattice ターゲットグループ (およびサービス) を作成できます。

図3 – VPC Lattice ターゲットグループとして Application Load Balancer を登録

VMware Transit Connect を介した Application Load Balancer の活用

Application Load Balancer を Lattice サービスとは分けた VPC に展開し、VMware Transit Connect を介してアプリケーショントラフィックを SDDC に渡すという選択肢もあります。以下の図のような構成です。

図4 – VMware Transit Connectを介した Application Load Balancer の統合

これは、Application Load Balancer がセキュリティ検査の要件のために Central Ingress VPC に展開されている場合に有効です。サービスネットワークは、別の AWS アカウントに存在し、AWS RAM を使用して ingress VPC と共有されることもあります。
VMware Transit Connect は、VMware が管理する AWS Transit Gateway ソリューションで、お客様のSDDC、クラウドネイティブサービス、オンプレミスリソース間の高速かつ回復性のある接続を提供します。SDDC と Amazon VPC を接続するために VMware Transit Connect をプロビジョニングする方法については、VMware のブログ記事を (日本語ブログはこちら) 参照してください。

お客様の環境で AWS Transit Gateway をすでに利用している場合は、ingress Application Load Balancer で着信サービスリクエストを終端し、アプリケーションフローをリージョン内ピアリングを使用した AWS Transit Gateway とVMware Transit Connect 経由で SDDC に配信することが可能です。以下の図は、このサンプルアーキテクチャを示しています。

図 5 – リージョン内ピアリングによる Application Load Balancer 統合

SDDCとネイティブサービス間のアプリケーション接続のシンプル化

VMware Cloud on AWS のお客様が、アプリケーションネットワーキングをシンプル化し、変革を加速する VPC Latticeの活用例を見ていきましょう。

最初の例では、お客様はオンプレミスのアプリケーション群を VMware Cloud on AWS に移行しました。新しくSoftware-as-a-Service (SaaS) 製品のローンチを計画しており、これには SDDC-01 上のバックエンド APIサービス (Service 1) を、ネイティブ AWS 環境で最近構築された 2 つのマイクロサービス (Service2, Service3) と統合する必要があります。これらのマイクロサービスは、下の図に示すように、異なる AWS アカウントと VPC にまたがる AWS Lambda と Amazon Elastic Kubernetes Service (Amazon EKS) 上にデプロイされています。

図 6 – SDDC アプリケーションと複雑性のある AWS 環境の統合

お客様は以下のサービス統合の要件と課題があります:

VPC-02 の CIDR と SDDC-01 の CIDR は一部重複しています。
VPC-03 は、外部のサービスプロバイダーが所有する別の AWS Organization の下にデプロイされているため、直接 IP 接続を確立することは許可されていません。
Service 2 と Service 3 は、Service 1 にアクセスする必要があります。
Service 2 と Service 3 は、双方向で通信する必要があります。

この場合、マルチアカウント環境における SDDC、コンテナ、サーバーレス関数全体で、セキュアかつプライベートなアプリケーション間接続を構築するために、VPC Lattice を活用できます。 VPC Lattice のユニークなリンクローカルアドレスレンジは、VPC や SDDC 間の潜在的なIPアドレスの競合問題も解消します。

まず、SDDC-01 にアタッチされた Connected VPC 内に、Service 1 の Application Load Balancer を作成する必要があります。これは、Lattice サービスはネイティブ VPC 内でのみアクセスできるため、Service 1 のすべての着信サービスリクエストを Connected VPC で終端するためです。
次に、VPC Lattice サービスネットワークを作成し、AWS RAM を介して 3 つのサービスアカウント (Account 1 ~3) と共有します。これにより、各アカウントで個別の VPC Lattice サービス (Service 1~3 向け) を作成し、サービスネットワークに関連付けることができます。
最後に、Service 2 と Service 3 が双方向通信を必要とするため、VPC-02 と VPC-03 をサービスネットワークに関連付ける必要があります。ただし、Service 3 はバックエンドサービスであるため、Connected VPC をサービスネットワークに関連付ける必要はありません。

以下にアーキテクチャ、ソリューションの概要を示しています。

図 7 – VPC Lattice によるアプリケーション間ネットワーキングのシンプル化

VPC Lattice を使用すると、マルチアカウントおよびマルチ VPC 環境における VMware Cloud on AWS アプリケーションとクラウドネイティブサービス間の相互接続を素早く構築できます。また、AWS Transit Gateway、AWS PrivateLink、Private NAT Gateway など、追加のネットワークインフラストラクチャサービスの構築による複雑さと管理オーバーヘッドを排除できます。
さらに、VPC Lattice には Lattice サービスごとに一意の DNS 名を自動的に割り当てる、組み込みの DNS ベースのサービスディスカバリーがあります。Amazon Route 53 プライベートホストゾーンを利用することで、サービスの CNAME、またはエイリアスレコードをカスタマイズすることもできます。

VPC Lattice によるアプリケーション変革の加速

次の例では、VPC Lattice が VMware Cloud on AWS のお客様がアプリケーションをシームレスにクラウドネイティブサービスに変換・移行するのにどのように役立つかを探っていきます。

お客様は SDDC 上で実行されているレガシーアプリケーションのリファクタリングを進めており、それを AWS Lambda のサーバーレス関数に再構築しました。SDDC 内のレガシーアプリケーションから Lambda 関数へのサービストラフィックの切り替え前に、アップストリームの他のサービスへの潜在的な影響を調査するための一連のカナリアテストを実施したいと考えています。
Amazon VPC Lattice は、このシナリオのようなブルー/グリーンやカナリアスタイルのロールアウトなど、一般的なデプロイメントパターンをサポートしています。VPC-02 の Lambda 関数を使用する 1 つのターゲットグループと、Connected VPC 内の Application Load Balancer を公開して SDDC-01 上のレガシーアプリケーションに向けたもう 1 つのターゲットグループで VPC Lattice サービスを設定できます。
その後、以下の図に示すように、リクエスト条件 (パス、メソッド、ヘッダー) に基づいて、 2 つのターゲットグループ間でトラフィックを分散する重み付けルーティングを利用できます。

図 8 – VPC Lattice による SDDC と AWS Lambda を横断したカナリアロールアウト

VPC Lattice は、サービス間の詳細なアクセスログを提供します。サポートされているログ配信ターゲットには、Amazon Simple Storage Service (Amazon S3) バケット、Amazon Kinesis Data Firehose、Amazon CloudWatch のロググループが含まれます。これにより、お客様は必要なログの詳細を迅速に取得し、特定のサービスまたはサービスネットワーク全体で発生し得る問題を特定および分析できます。
VPC Lattice は、アプリケーションの変革とモダナイゼーションを促進し、新しいアイデアを簡単に試すことができ、必要に応じて迅速にロールバックできるようにします。これにより、サービス移行時のリスクを軽減し、最終的にエンドユーザーの体験を向上させます。

追加の考慮事項

サービスネットワーク全体でのネットワークレベルの保護を実施するため、VPC Lattice の AWS マネージドプレフィックスリストをセキュリティグループで活用することをおすすめします。さらに、個々のサービスまたはサービスネットワーク全体のいずれかに、強力な認証とコンテキスト固有の認可を適用するために、サービスレベルの認証ポリシーを使用できます。詳細は、こちらの AWS ブログ記事を参照してください。

デフォルトでは、VPC Lattice のサービスはリンクローカルアドレスレンジがルーティング不可能なため、VPC 内からのみアクセスできます。 Lattice サービスへの外部接続性を提供するには、Elastic Load Balancing とプロキシのフリートを使用した ingress VPC が必要です。サンプルアーキテクチャと実装ガイドは、この AWS ブログ記事を参照してください。
AWS 責任共有モデルに従って、AWS インフラストラクチャ上にホストされるコンテンツの管理はお客様の責任となります。このユーザーガイドに従って Amazon VPC Lattice を設定し、セキュリティとコンプライアンス目標を満たしてください。また、VMware Cloud on AWS のネットワークとセキュリティの包括的なガイドも参照してください。 VMware Cloud on AWS 環境の強化に役立つリソースがあります。

価格については、Amazon VPC Lattice の料金ページをご確認ください。 AWS Transit Gateway や VMware Transit Connect の料金もご参照ください。

まとめ

この投稿では、Amazon VPC Lattice が VMware Cloud on AWS のお客様にどのようにアプリケーションネットワーキングをシンプル化し、変革を加速できるかについて説明しました。一般的な統合アーキテクチャと使用例の概要についてもご紹介しました。

より詳細については、以下のリンクをご参考ください。

本稿は、ソリューションアーキテクトの齋藤が翻訳を担当しました。原文はこちらです。

Amazon Web Services ブログ