翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# で運用されている SaaS コンシューマー AWS
このセクションでは、お客様とコンシューマーの両方が で運用されている場合の接続オプションについて説明します AWS クラウド。このシナリオは、多くの が AWS のサービス ネイティブに統合され、両方の当事者が AWS のサービス ポートフォリオ全体にアクセスできるため、最大の柔軟性を提供します。
**Topics**
+ [との統合 AWS PrivateLink](#options-aws-privatelink)
+ [Amazon VPC Lattice サービスの共有](#options-amazon-vpc-lattice)
+ [VPC ピアリング接続の作成](#options-aws-vpc-peering)
+ [を使用した VPCs の接続 AWS Transit Gateway](#options-aws-transit-gateway)
次のネットワーク値マップは、各評価メトリクスの各オプションスコアをまとめたものです。評価メトリクスの詳細については、このガイドの[「評価メトリクス](evaluating.md#evaluating-metrics)」を参照してください。マップでは、5 は最低 TCO、最適なネットワーク分離、修復時間など、最適なスコアを表します。このレーダーチャートの読み方の詳細については、このガイド[ネットワーク値マップ](evaluating.md#evaluating-map)の「」を参照してください。
レーダーチャートには、次の値が表示されます。
| 評価メトリクス | AWS PrivateLink | Amazon VPC Lattice | VPC ピアリング | AWS Transit Gateway |
| --- | --- | --- | --- | --- |
| 統合のしやすさ | 5 | 5 | 4 | 3 |
| TCO | 5 | 5 | 3 | 4 |
| スケーラビリティ | 5 | 4 | 1 | 4 |
| 適応性 | 4 | 5 | 2 | 3 |
| ネットワーク分離 | 5 | 5 | 2 | 3 |
| 可観測性 | 4 | 5 | 4 | 4 |
| 修復にかかる時間 | 5 | 5 | 5 | 4 |
## との統合 AWS PrivateLink
[AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) は、SaaS サービスを統合する最もクラウドネイティブな方法です。SaaS プロバイダーは、[Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) の背後でアプリケーションをホストできます。Network Load Balancer は、[Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html)、[Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)、[Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)、[Auto Scaling グループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)と直接統合されます。Network Load Balancer からのトラフィックを SaaS プロバイダーアカウントのインターフェイス VPC エンドポイントにルーティングすることもできます。これにより、API を使用して、[Amazon API Gateway](https://repost.aws/knowledge-center/invoke-private-api-gateway) や などのアプリケーションにアクセスできます[AWS AppSync](https://docs.aws.amazon.com/appsync/latest/devguide/what-is-appsync.html)。アプリケーションが、データベースなど、ロードバランシングされていない顧客環境内のリソースにアクセスする必要がある場合は、[リソース VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/use-resource-endpoint.html)を使用できます。
AWS PrivateLink は、アベイラビリティーゾーンあたり最大 100 Gbps の帯域幅をサポートします。次の図は、いくつかの統合が可能な基本設定を示しています。2 つのコンシューマーアカウントを SaaS プロバイダーアカウントに接続します AWS PrivateLink。コンシューマーアカウントにサービスエンドポイントがあり、SaaS プロバイダーアカウントに Network Load Balancer があります。
この方法による利点は以下の通りです。
+ 統合の容易さ: ルートテーブルの変更は必要ありません
+ 統合の容易さ: [を通じてエンドポイントサービスを提供 AWS Marketplace](https://docs.aws.amazon.com/marketplace/latest/userguide/privatelink.html)できます。
+ 統合の容易さ: VPC エンドポイントが[フレンドリ DNS 名](https://docs.aws.amazon.com/vpc/latest/privatelink/manage-dns-names.html)をサポート
+ スケーラビリティ: 数千の SaaS コンシューマーにスケールできます
+ 適応性: CIDR 範囲の重複のサポート
+ 適応性: IPv6 のサポート
+ 適応性: クロスリージョンサポート
+ TCO: AWS PrivateLink はフルマネージド型サービスであるため、運用作業が少なくて済みます
+ ネットワーク分離: SaaS プロバイダーからトラフィックを開始できないため、SaaS コンシューマーのセキュリティ上の利点
+ ネットワーク分離: サブネットまたは VPC 全体が公開されていないため、SaaS プロバイダーのセキュリティ上の利点
このアプローチの欠点は次のとおりです。
+ 適応性: SaaS プロバイダーはコンシューマーと同じアベイラビリティーゾーンを使用する必要があります
+ 適応性: クライアントが開始する接続のみをサポートし、サービスが開始する通信にはリソース VPC エンドポイントが必要です
+ 適応性: Network Load Balancer は、 AWS PrivateLink
## Amazon VPC Lattice サービスの共有
SaaS アプリケーションの接続オプションとして [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) を使用するには、まず SaaS アプリケーションコンポーネントを表す 1 つ以上の VPC Lattice サービスを作成します。Amazon EC2 インスタンス、コンテナ、 AWS Lambda 関数などのバックエンドターゲットにトラフィックを送信するようにリスナーとルーティングルールを設定します。詳細については、[「VPC Lattice サービスネットワーク内の Saas サービス](https://aws.amazon.com/blogs/networking-and-content-delivery/connecting-saas-services-within-a-vpc-lattice-service-network/)の接続」(AWS ブログ記事) を参照してください。概念的には、これは Application Load Balancer の設定とほぼ同じです。次に、 [AWS Resource Access Manager (AWS RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) を使用して顧客 AWS アカウント または組織と SaaS サービスを安全に共有し、アクセス許可を指定します。お客様がリソース共有を受け入れると、SaaS サービスを既存または新しく作成された VPC Lattice サービスネットワークに関連付けることで、service-to-service通信が可能になります。
各 VPC Lattice サービスは、アベイラビリティーゾーンごとに 1 秒あたり最大 10 Gbps および 10,000 リクエストをサポートできます。認証ポリシーを実装することで、顧客は SaaS アプリケーションにアクセスできるサービスとリソースをきめ細かく制御できます。[リソースゲートウェイ](https://docs.aws.amazon.com/vpc-lattice/latest/ug/resource-gateway.html)を使用して、TCP 接続を必要とするリソースにアクセスできます。たとえば、管理している Amazon EKS クラスターや、アプリケーションがアクセスする必要があるカスタマー管理のリソースなどです。SaaS サービスにリソースゲートウェイを使用する方法の詳細については、[「VPC リソース AWS PrivateLink のサポート AWS アカウント を使用して 全体で SaaS 機能を拡張する](https://aws.amazon.com/blogs/networking-and-content-delivery/extend-saas-capabilities-across-aws-accounts-using-aws-privatelink-support-for-vpc-resources/)」(AWS ブログ記事) を参照してください。
次の図は、いくつかの統合例を含む高レベルの VPC Lattice 設定を示しています。カスタマーマネージドサービスネットワークを使用して SaaS アプリケーションにアクセスします。
この方法による利点は以下の通りです。
+ 統合の容易さ: ルートテーブルの変更は必要ありません
+ 統合の容易さ: すぐに使えるサービス検出
+ スケーラビリティ: 数千の SaaS コンシューマーにスケールできます
+ 適応性: CIDR 範囲の重複のサポート
+ 適応性: IPv6 のサポート
+ 適応性: VPC Lattice サービスとして任意の AWS コンピューティングサービスと統合
+ TCO: VPC Lattice はフルマネージドサービスであるため、運用作業が少なくて済みます
+ TCO: 高度なトラフィックルーティングによる組み込みロードバランシング
+ ネットワーク分離: 認証ポリシーによるきめ細かな認可
+ ネットワーク分離: SaaS プロバイダーからトラフィックを開始できないため、SaaS コンシューマーのセキュリティ上の利点
+ ネットワーク分離: サブネットまたは VPC 全体を公開していないため、SaaS プロバイダーのセキュリティ上の利点
このアプローチの欠点は次のとおりです。
+ 適応性: クライアントが開始した接続のみをサポートし、サービスが開始した通信にはリソースゲートウェイが必要です
+ 適応性: クロスリージョンサポートなし
## VPC ピアリング接続の作成
[VPC ピアリング](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)を使用して SaaS プロバイダーの VPC をコンシューマーの VPC に接続すると、両者は接続を開始できます。これには、両方のアカウントでセキュリティグループ、ファイアウォール、ネットワークアクセスコントロールリスト (NACLs) を適切に設定する必要があります。そうしないと、不要なトラフィックがピアリング接続を介してネットワークに入る可能性があります。セキュリティグループを使用して、ピア接続された VPCs からセキュリティグループを参照できます。これは、許可リストのセキュリティグループが許可リストの IP アドレスと比較してより明示的で詳細なアクセスコントロールを提供するため、アプリケーションへのアクセスを制御するのに役立ちます。
VPC ピアリングを使用すると、VPC にデプロイされたサービスまたはリソースを通じて SaaS サービスにアクセスできます。ほとんどの SaaS アプリケーションは Application Load Balancer または Network Load Balancer の背後にあります。 [AWS AppSync プライベート APIs](https://docs.aws.amazon.com/appsync/latest/devguide/using-private-apis.html)または [Amazon API Gateway プライベート APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html) は、インターフェイス VPC エンドポイントを介したピアリング接続のターゲットになる可能性があるため、SaaS アプリケーションへの他の一般的なエントリポイントです。
ピアリング接続を確立したら、両方のアカウントの VPCs のルートテーブルを更新して、ピアリング接続をそれぞれの CIDR 範囲のネクストホップとして定義する必要があります。このソリューションは、複数のピアリング接続の管理がすぐに複雑になるため、コンシューマーが少ない SaaS プロバイダーにのみ推奨されます。
次の図は、いくつかの統合が可能な基本設定を示しています。2 つのコンシューマーアカウントの VPCs には、SaaS プロバイダーアカウントの VPC とのピアリング接続があります。
この方法による利点は以下の通りです。
+ 修復までの時間: 通信の単一障害点がない
+ スケーラビリティ: VPC ピアリングに対する帯域幅の制限なし
+ TCO: ピアリング接続または同じアベイラビリティーゾーン内のピアリング接続経由のトラフィックにはコストがかかりません
+ TCO: 管理するインフラストラクチャがない
+ 適応性: IPv6 のサポート
+ 適応性: リージョン間ピアリングをサポート
このアプローチの欠点は次のとおりです。
+ 適応性: 推移的ルーティングはサポートされていません
+ 適応性: CIDR 範囲の重複はサポートされていません
+ スケーラビリティ: スケーラビリティの制限 (VPC あたり最大 125 個のピアリング接続)
+ TCO: ピアリング接続を追加するたびに複雑さが指数関数的に増加
+ TCO: ルートテーブルの管理、ピアリング接続自体、セキュリティグループルール、トラフィック検査のオーバーヘッド
+ ネットワーク分離: 両当事者の VPCs全体が公開されるため、厳格なセキュリティコントロールが必要
## を使用した VPCs の接続 AWS Transit Gateway
を介して VPCs を接続すると[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)、VPC アタッチメントが作成され、VPC との間でトラフィックをルーティングする各アベイラビリティーゾーンのサブネットにネットワークインターフェイスがデプロイされます。VPC アタッチメントのすべてのアベイラビリティーゾーンに専用`/28`サブネットを配置することをお勧めします。詳細については、[「Amazon VPC Transit Gateways 設計のベストプラクティス](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html)」を参照してください。VPCs は、デプロイされたネットワークインターフェイスを介してトラフィックを送信するために更新されたルートテーブルを必要とし、それに応じて Transit Gateway ルートテーブルを更新する必要があります。マルチテナント設定では、SaaS プロバイダーの VPC にすべてのコンシューマーの VPCs。コンシューマーの VPCs には、SaaS プロバイダーの VPC へのルートのみが必要です。
Transit Gateway は、設計上高可用性です。[VPC フローログ](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-vpc-flow-logs-for-aws-transit-gateway/)によるモニタリングをサポートし、Transit Gateway アタッチメントの最大帯域幅はアベイラビリティーゾーンあたり 100 Gbps です。VPC ピアリングと同様に、このアプローチによりクロス VPC セキュリティグループ参照が可能になり、環境間のアクセスコントロールが簡素化されます。
Transit Gateway を使用して SaaS サービスにコンシューマーを接続するには、主に 2 つのオプションがあります。
**オプション 1: RAM の使用**
最初のオプションでは、サービスプロバイダー[は () を使用して Transit Gateway ](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-share.html)をコンシューマーと共有します。 [AWS Resource Access ManagerAWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)これにより、コンシューマーは自分のアカウントに VPC アタッチメントをデプロイできます。次の図は、このオプションを大まかに示しています。
**オプション 2: ピア接続トランジットゲートウェイ**
2 番目のオプションは、トランジットゲートウェイをコンシューマーのアカウントのトランジットゲートウェイとピアリングすることです。これにより、トランジットゲートウェイ内のルートテーブルを完全に制御できるため、コンシューマーはより柔軟になります。例えば、サービスとワークロードの間に一元的な検査を設定できます。このオプションの欠点は、トランジットゲートウェイ間の静的ルーティングのみがサポートされていることです。次の図は、このオプションを大まかに示しています。
この方法による利点は以下の通りです。
+ スケーラビリティ: 最大 5,000 個のアタッチメントをサポート
+ スケーラビリティ: 接続されたすべての VPCsを 1 か所で管理およびモニタリング
+ 適応性: Transit Gateway は VPNs、 Direct Connect ゲートウェイ、およびサードパーティー SD-WAN アプライアンスにアタッチすることもできます
+ 適応性: [検査 VPC の追加](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)などの柔軟なアーキテクチャ
+ 適応性: 推移的ルーティングのサポート
+ 適応性: リージョン内およびリージョン間のトランジットゲートウェイをピアリングできます
+ 適応性: IPv6 のサポート
+ TCO: AWS Transit Gateway はフルマネージド型サービスであるため、運用作業が少なくて済みます
+ TCO: 追加の Transit Gateway アタッチメントごとに TCO が直線的に増加
このアプローチの欠点は次のとおりです。
+ 統合のしやすさ: ルーティング設定には高度なネットワーク知識が必要です
+ 適応性: CIDR 範囲の重複はサポートされていません
+ TCO: ルートテーブルエントリ、セキュリティグループルール、トラフィック検査の管理によるオーバーヘッド
+ セキュリティ: 両当事者の VPCs全体が公開されるため、厳しいセキュリティコントロールが必要