翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon VPC Lattice リファレンスアーキテクチャ 公開日: **2023 年 10 月 16 日 ([図の履歴](#diagram-history))** Amazon VPC Lattice は、サービス間の通信を一貫して接続、モニタリング、保護するアプリケーションレイヤーサービスです。このシリーズでは、マルチAWS アカウント 環境のさまざまな接続パターンを示します。 ## コンポーネント図 VPC Lattice を使用すると、 AWS コンピューティングサービス (インスタンス、コンテナ、サーバーレス関数) 間で、サービス間の通信を一貫した方法で接続、保護、モニタリングできます。この図は、VPC Lattice のさまざまなコンポーネントと、それらが相互にどのように相互作用するかを示しています。 ![VPC Lattice のさまざまなコンポーネントと、それらが相互にどのように相互作用するかを示す図。](https://docs.aws.amazon.com/ja_jp/reference-architecture-diagrams/latest/amazon-vpc-lattice-use-cases/images/1-components.png) 1. *サービスネットワーク*は、サービスの集合の論理境界です。ネットワークに関連付けらたサービスは、検出、接続、アクセシビリティ、オブザーバビリティの認証を受けることができます。ネットワーク内のサービスにリクエストを行うには、クライアントがサービスネットワークに関連付けられている VPC 内にある必要があります。 1. *サービスは*、特定のタスクまたは関数を配信するソフトウェアの独立したデプロイ可能なユニットを表します。各サービスには、ルールを使用して 1 つ以上のターゲットグループをターゲットにするリスナーがあります。ターゲットは、**Amazon Elastic Compute Cloud** (Amazon EC2) インスタンス、IP アドレス、**AWS Lambda**関数、Application Load Balancer、または Kubernetes Pod です。 1. サービスがサービスネットワークに関連付けられている場合、クライアントはこのサービスにリクエストを行うことができますが、クライアントが配置されている VPC もサービスネットワークに関連付けられ、ポリシーで許可されている場合に限ります。 1. サービスネットワークと *VPC の関連付け*を行うと、その VPC 内のすべてのターゲットがクライアントになり、サービスネットワーク内の他のサービスと通信できるようになります。セキュリティグループをこの関連付けにアタッチして VPC からのネットワークアクセスを制御し、サービスネットワークまたはサービスポリシーを使用してきめ細かなアクセスコントロールを適用できます。 1. *認証ポリシー*は、サービスネットワークまたはサービスの両方で使用して、アクセスコントロールを設定できます。 ## トラフィックフロー図 VPC Lattice は、その中のすべてのサービスを簡単かつ効果的に検出、保護、接続、モニタリングできるように設計されています。Amazon Route 53 VPC Resolver は、コンシューマー VPC 内で VPC Lattice サービスのドメイン名を解決し、リンクローカルアドレスに解決してトラフィックをサービスネットワークにローカルに送信します。 ![その中のすべてのサービスを簡単かつ効果的に検出、保護、接続、モニタリングする方法を示す図。](https://docs.aws.amazon.com/ja_jp/reference-architecture-diagrams/latest/amazon-vpc-lattice-use-cases/images/2-traffic-flow.png) 1. **Amazon Elastic Compute Cloud** (Amazon EC2) インスタンスに配置されたコンシューマーアプリケーションは、**Amazon Route 53** VPC Resolver にクエリを実行して*、service1* のドメイン名解決を取得します。 1. DNS 解決により、トラフィックをサービスネットワーク (リンクローカルアドレス) に送信する必要があると判断されます。最初のトラフィックコントロールメジャーは、VPC 関連付けにアタッチされたセキュリティグループです (複数のセキュリティグループをアタッチできます）。 1. リクエストされた **VPC Lattice **サービスがコンシューマー VPC に関連付けられているサービスネットワークに関連付けられていて、サービスネットワークポリシーで通信が許可されている場合、トラフィックは特定のターゲットに転送されます。 1. この例では、*service1* には Application Load Balancer (ALB) であるターゲットグループが 1 つだけ (デフォルトでルーティングされます) あります。この ALB は、トラフィックを対応する **Amazon EC2** インスタンスに転送します。 ## VPC Lattice サービス図のカスタムドメイン名 VPC Lattice サービスを作成するときに、ユーザーにより直感的な URL を提供するようにカスタムドメイン名を設定できます。クライアントがカスタムドメイン名を使用してリクエストを行うと、DNS サーバーはそれを VPC Lattice が生成したドメイン名 (service-name-service\_id.partition\_id.vpc-lattice-svcs.region.on.aws) に解決します。ただし、カスタムドメイン名を VPC Lattice 生成ドメイン名 (CNAME レコード) にマッピングする場合にのみ発生します。 ![カスタムドメイン名を VPC Lattice 生成ドメイン名にマッピングする方法を示す図。](https://docs.aws.amazon.com/ja_jp/reference-architecture-diagrams/latest/amazon-vpc-lattice-use-cases/images/3-custom-domain-name.png) 1. カスタムドメイン名と **VPC Lattice** 生成ドメイン名間のマッピングを許可するには、コンシューマー VPC に関連付けられたプライベートホストゾーンを作成します。このホストゾーンには、このマッピングを実行する ALIAS レコードが含まれます。 1. 必要に応じて、HTTPS リクエストを処理するには、カスタムドメイン名を設定するときに **AWS Certificate Manager** (ACM) で独自の SSL/TLS 証明書を準備する必要があります。 1. **Amazon EC2** インスタンスに配置されたコンシューマーアプリケーションは、VPC リゾルバーにクエリを実行して、*service1.example.com* のドメイン名解決を取得します。**Route 53 Resolver** はエイリアスレコードを解決し、適切な **VPC Lattice **エンドポイント IP アドレスを直接返して、VPC リゾルバーの追加の DNS ルックアップを排除します。 1. アプリケーションは、トラフィックを **VPC Lattice **サービスネットワークの VPC 関連付けに転送します。 1. リクエストされた **VPC Lattice **サービスはコンシューマー VPC に関連付けられたサービスネットワークに関連付けられているため、サービスネットワークのポリシーでは通信が許可されるため、トラフィックは特定のターゲットに転送されます。 1. この例では、*service1* には、自動スケーリンググループであるターゲットグループが 1 つだけ (デフォルトでルーティングされます) あります。トラフィックは、グループ内の **Amazon EC2** インスタンスの 1 つに転送されます。 ## マルチアカウント集中型単一サービスネットワーク図 中央アカウントは、サービスネットワークの所有権を持つことができます。これは、同じまたは異なる 内の他の AWS アカウントと共有されます ( AWS Resource Access Manager を使用) AWS Organizations。さらに、プロバイダーアカウントは AWS Resource Access Manager を使用してサービスを共有することもできます。 ![中央アカウントが同じまたは異なる 内の他の AWS アカウントと共有 ( AWS Resource Access Manager を使用) されるサービスネットワークの所有権を持つ方法を示す図 AWS Organizations。](https://docs.aws.amazon.com/ja_jp/reference-architecture-diagrams/latest/amazon-vpc-lattice-use-cases/images/4-multi-account-centralized-single-service-network.png) 1. **Amazon EC2** インスタンスに配置されたコンシューマーアプリケーションは、VPC リゾルバーにクエリを実行して*、service2* のドメイン名解決を取得します。 1. DNS 解決により、トラフィックをサービスネットワークに送信する必要があると判断されます。 1. この例では、サービスネットワークとサービスレベルの両方のポリシーで、コンシューマーからのターゲット (Auto Scaling グループ) へのトラフィックが許可されるため、**Amazon EC2** インスタンスのアプリケーションは *service2* を消費できます。 1. コンシューマーアプリケーションは、*service1* のドメイン名解決を取得します。 1. VPC リゾルバーは、サービスネットワークをネクストホップとして解決します。ただし、この例では、サービスネットワークまたはサービスレベルのポリシーのいずれかでは、コンシューマーが service1 (**Lambda** 関数) を消費できないため、トラフィックはドロップされます。 ## マルチアカウント集中型マルチサービスネットワーク図 中央アカウントは、複数のサービスネットワークの所有権を持つことができます。これは、同じまたは異なる (サービスと同じ) 内で AWS アカウント、他の と共有 AWS Organizations ( AWS Resource Access Manager を使用) されます。複数のサービスネットワークを使用すると、サービスのセグメント化が可能になり、ポリシーを使用して達成または補完することもできます。 ![中央アカウントが同じまたは異なる (サービスと同じ) 内で他の と共有されている AWS Organizations ( AWS Resource Access Manager を使用) AWS アカウント複数のサービスネットワークの所有権を持つ方法を示す図。](https://docs.aws.amazon.com/ja_jp/reference-architecture-diagrams/latest/amazon-vpc-lattice-use-cases/images/5-multi-account-centralized-multiple-service-networks.png) 1. VPC に配置された**AWS Lambda**関数は、VPC が関連付けられた後にサービスネットワークにアクセスできます。この場合、**Lambda** 関数にあるコンシューマーサービスは、VPC リゾルバーにクエリを実行して *service1* のドメイン名を解決します。 1. DNS 解決により、トラフィックをサービスネットワーク 2 に送信する必要があると判断されます。 1. サービスネットワークとサービスレベルのポリシーの両方で、コンシューマーからのターゲット (Auto Scaling グループ) へのトラフィックが許可されるため、コンシューマーアプリケーションはサービスを消費できます。 1. **Amazon EC2** インスタンスに配置されたコンシューマーアプリケーションは、VPC リゾルバーにクエリを実行して *service2* のドメイン名を解決します。これは、トラフィックをサービスネットワークに送信する **VPC Lattice** リンクローカルアドレスで解決されます。 1. *service2* はサービスネットワーク 1 に関連付けられていないため、トラフィックはドロップされます。 ## マルチアカウント分散サービスネットワーク図 各プロバイダーは独自のサービス AWS アカウント を所有し、同じまたは異なる 内で AWS アカウント他の と共有します AWS Organizations。VPC は 1 つのサービスネットワークにのみ関連付けることができるため、コンシューマーは独自のサービスネットワークを所有し、使用するサービスを選択できます。 ![各プロバイダーが独自のサービス AWS アカウント を所有し AWS アカウント、同じ 内または異なる 内で他の と共有する方法を示す図 AWS Organizations。](https://docs.aws.amazon.com/ja_jp/reference-architecture-diagrams/latest/amazon-vpc-lattice-use-cases/images/6-multi-account-distributed-service-networks.png) 1. **Amazon EC2** インスタンスに配置されたコンシューマーアプリケーションは、VPC リゾルバーに *service1* の DNS 解決をクエリします。 1. DNS 解決により、トラフィックをサービスネットワーク 1 に送信する必要があると判断されます。 1. サービスネットワークとサービスレベルのポリシーの両方で、コンシューマーからのターゲット (**Lambda** 関数) へのトラフィックが許可されるため、コンシューマーアプリケーションは service1 を消費できます。 1. VPC に配置された **Lambda** 関数は、VPC が関連付けられた後にサービスネットワークにアクセスできます。この場合、**Lambda** 関数にあるコンシューマーサービスは、VPC リゾルバーに *service2* の DNS 解決をクエリします。 1. DNS 解決により、トラフィックをサービスネットワーク 2 に送信する必要があると判断されます。 1. サービスネットワークとサービスレベルの両方のポリシーは、コンシューマーからのターゲット (Auto Scaling グループ) へのトラフィックを許可するため、コンシューマーアプリケーションは *service2* を消費できます。 ## 詳細情報 詳細については、「」を参照してください。 + [AWS アーキテクチャアイコン](https://aws.amazon.com/architecture/icons) + [AWS アーキテクチャセンター](https://aws.amazon.com/architecture) + [AWS Well-Architected](https://aws.amazon.com/architecture/well-architected) ## 寄稿者 このリファレンスアーキテクチャ図の寄与要因は次のとおりです。 + Amazon Web Services、スペシャリストソリューションアーキテクト、Pablo Sánchez Carmona + Amazon Web Services、シニアスペシャリストソリューションアーキテクト、Adam Palmer ## 図の履歴 このリファレンスアーキテクチャ図の更新について通知を受け取るには、RSS フィードをサブスクライブします。 | 変更 | 説明 | 日付 | | --- |--- |--- | | [図が更新されました](#diagram-history) | 図を更新し、新しいユースケースを追加しました。 | 2023 年 10 月 16 日 | | [初版発行](#diagram-history) | リファレンスアーキテクチャ図が最初に公開されました。 | 2023 年 4 月 17 日 | **注記** RSS 更新をサブスクライブするには、使用しているブラウザで RSS プラグインが有効になっている必要があります。