翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# VPC から VPC への接続
お客様は、2 つの異なる VPC 接続パターンを使用してマルチ VPC 環境をセットアップできます。*多対多*、または*ハブアンドスポーク*です。many-to-manyアプローチでは、各 VPC 間のトラフィックは各 VPC 間で個別に管理されます。hub-and-spokeモデルでは、すべての VPC 間トラフィックは中央リソースを経由し、確立されたルールに基づいてトラフィックをルーティングします。
# VPC ピアリング
2 つの VPCs を接続する最初の方法は、VPC ピアリングを使用することです。この設定では、接続により VPCs 間の完全な双方向接続が可能になります。このピアリング接続はVPCs。VPCs は、ピアリング接続することもできます。アベイラビリティーゾーン内に留まる VPC ピアリング接続を介したデータ転送はすべて無料です。アベイラビリティーゾーンをまたぐ VPC ピアリング接続を介したすべてのデータ転送には、標準のリージョン内データ転送料金が課金されます。VPCs がリージョン間でピアリング接続されている場合、リージョン間の標準データ転送料金が適用されます。
VPC ピアリングはpoint-to-point接続であり、[推移的なルーティング](https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html#transitive-peering)をサポートしていません。例えば、VPC A と VPC B の間、および VPC A と VPC C の間に VPC [ピアリング](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html)接続がある場合、VPC B のインスタンスは VPC A を経由して VPC C に到達することはできません。VPC B と VPC C の間でパケットをルーティングするには、直接 VPC ピアリング接続を作成する必要があります。
大規模な場合、数十または数百の VPCs がある場合、それらをピアリングと相互接続すると、数百または数千のピアリング接続のメッシュが発生する可能性があります。多数の接続は、管理とスケーリングが困難な場合があります。例えば、VPC が 100 個あり VPCs 、それらの間でフルメッシュピアリングを設定する場合、4,950 個のピアリング接続 [`n(n-1)/2`] が必要です。ここで、 `n` は VPCs。VPC あたり 125 のアクティブなピアリング接続[の最大数](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html)があります。
![\[VPC ピアリングを使用したネットワーク設定を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/network-setup-vpc-peering.png)
VPC ピアリングを使用している場合は、各 VPC にオンプレミス接続 (VPN または Direct Connect) を作成する必要があります。上の図に示すように、VPC 内のリソースは、ピア接続された VPC のハイブリッド接続を使用してオンプレミスに到達することはできません。
VPC ピアリングは、ある VPC 内のリソースが別の VPC 内のリソースと通信する必要があり、両方の VPCs の環境が制御および保護され、接続する VPCs の数が 10 未満である場合に最適です (各接続の個別の管理を可能にするため）。VPC ピアリングは、VPC 間接続の他のオプションと比較して、全体的なコストと総パフォーマンスが最も低くなります。
# AWS Transit Gateway
[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) は、サードパーティーVPCs仮想アプライアンスをプロビジョニングすることなく、VPC とオンプレミスネットワークをフルマネージドサービスとして接続するためのハブアンドスポーク設計を提供します。VPN オーバーレイは不要で、高可用性とスケーラビリティ AWS を管理します。
Transit Gateway を使用すると、数千の VPCs。すべてのハイブリッド接続 (VPN および Direct Connect 接続) を単一のゲートウェイにアタッチし、組織の AWS ルーティング設定全体を 1 か所に統合して制御できます (次の図を参照）。Transit Gateway は、ルートテーブルを使用して、接続されているすべてのスポークネットワーク間でトラフィックをルーティングする方法を制御します。このhub-and-spokeモデルは、VPCs が Transit Gateway インスタンスにのみ接続して接続されたネットワークにアクセスするため、管理を簡素化し、運用コストを削減します。
![\[を使用したハブアンドスポーク設計を示す図 AWS Transit Gateway\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/hub-and-spoke-design.png)
Transit Gateway はリージョンリソースであり、同じ 内の数千の VPCs を接続できます AWS リージョン。ハイブリッド接続のために、1 つの Direct Connect 接続を介して複数のゲートウェイに接続できます。通常、特定のリージョン内のすべての VPC インスタンスを接続する Transit Gateway インスタンスを 1 つだけ使用し、必要に応じて Transit Gateway ルーティングテーブルを使用してそれらを分離できます。Transit Gateway は設計上高可用性であるため、高可用性のために追加の Transit Gateway は必要ありません。冗長性のために、各リージョンで 1 つのゲートウェイを使用します。ただし、複数のゲートウェイを作成して、設定ミスによる影響範囲を制限したり、コントロールプレーンオペレーションを分離したり、管理のease-of-useしたりすることは有効なケースです。
Transit Gateway ピアリングを使用すると、お客様は同じリージョンまたは複数のリージョン内で Transit Gateway インスタンスをピアリングし、それらの間でトラフィックをルーティングできます。VPC ピアリングと同じ基盤となるインフラストラクチャを使用するため、暗号化されます。詳細については、[AWS Transit Gateway リージョン間ピアリングを使用したグローバルネットワークの構築](https://aws.amazon.com/blogs/networking-and-content-delivery/building-a-global-network-using-aws-transit-gateway-inter-region-peering/)」と[AWS Transit Gateway がリージョン内ピアリングをサポートするようになりました](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-transit-gateway-now-supports-intra-region-peering/)」を参照してください。
組織の Transit Gateway インスタンスを Network Services アカウントに配置します。これにより、ネットワークサービスアカウントを管理するネットワークエンジニアによる一元管理が可能になります。Resource Access Manager (RAM) AWS を使用して Transit Gateway インスタンスを共有し、同じリージョン内の AWS Organization 内の複数のアカウント間で VPCs を接続します。AWS RAM を使用すると AWS アカウント、 AWS リソースを AWS Organization 内または との間で簡単かつ安全に共有できます。詳細については、[中央アカウントのブログ記事の「Transit Gateway への AWS Transit Gateway アタッチメントの自動化](https://aws.amazon.com/blogs/networking-and-content-delivery/automating-aws-transit-gateway-attachments-to-a-transit-gateway-in-a-central-account/)」を参照してください。
Transit Gateway では、Transit Gateway Connect を使用して SD-WAN インフラストラクチャと AWS 間の接続を確立することもできます。動的ルーティングにはボーダーゲートウェイプロトコル (BGP) で Transit Gateway Connect アタッチメントを使用し、高パフォーマンスには汎用ルーティングカプセル化 (GRE) トンネルプロトコルを使用して、Connect アタッチメントごとに最大 20 Gbps の合計帯域幅を提供します (Connect アタッチメントごとに最大 4 つの Transit Gateway Connect ピア）。Transit Gateway Connect を使用すると、基盤となるトランスポートレイヤーとして VPC アタッチメントまたは アタッチメントを介して、オンプレミスの SD-WAN インフラストラクチャまたは Direct Connect クラウドで実行されている SD-WAN アプライアンスの両方を統合できます。リファレンスアーキテクチャと詳細な設定については、「Connect [との SD-WAN AWS Transit Gateway 接続の簡素化](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-sd-wan-connectivity-with-aws-transit-gateway-connect/)」を参照してください。
# トランジット VPC ソリューション
[トランジット VPCs](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) はVPCs 間接続用のハブアンドスポーク設計を導入することで、VPC ピアリングとは異なる方法で VPC 間の接続を作成できます。トランジット VPC ネットワークでは、1 つの中央 VPC (ハブ VPC) は、通常は [IPsec](https://en.wikipedia.org/wiki/IPsec) 経由で BGP を利用する VPN 接続を介して他のすべての VPC (スポーク VPC) に接続します。中央 VPC には[、VPN オーバーレイを使用して受信トラフィックを送信先にルーティングするソフトウェアアプライアンスを実行する Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2) インスタンスが含まれています。トランジット VPC ピアリングには次の利点があります。
+ 推移的ルーティングはオーバーレイ VPN ネットワークを使用して有効になり、ハブアンドスポーク設計が可能になります。
+ ハブトランジット VPC の EC2 インスタンスでサードパーティーベンダーソフトウェアを使用する場合、高度なセキュリティ (レイヤー 7 ファイアウォール/侵入防止システム (IPS)/侵入検知システム (IDS) ) に関するベンダー機能を使用できます。オンプレミスで同じソフトウェアを使用している場合は、統一された運用/モニタリングエクスペリエンスからメリットを得られます。
+ Transit VPC アーキテクチャは、一部のユースケースで必要な接続を可能にします。例えば、AWS GovCloud インスタンスと商用リージョン VPC または Transit Gateway インスタンスを Transit VPC に接続し、2 つのリージョン間の VPC 間接続を有効にすることができます。このオプションを検討するときは、セキュリティとコンプライアンスの要件を評価します。セキュリティを強化するために、このホワイトペーパーで後述する設計パターンを使用して一元的な検査モデルをデプロイできます。
![\[仮想アプライアンスを備えたトランジット VPC を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/transit-vpc-virtual-appliances.png)
トランジット VPC には、インスタンスサイズ/ファミリーに基づいて EC2 でサードパーティーベンダーの仮想アプライアンスを実行する場合のコストの増加、VPN 接続あたりのスループットの制限 (VPN トンネルあたり最大 1.25 Gbps)、追加の設定、管理、および障害耐性のオーバーヘッド (お客様は、サードパーティーベンダーの仮想アプライアンスを実行している EC2 インスタンスの HA と冗長性を管理する責任があります) など、独自の課題があります。
## VPC ピアリングと Transit VPC と Transit Gateway
*表 1 — 接続の比較*
| 条件 | VPC ピアリング | トランジット VPC | Transit Gateway | PrivateLink | Cloud WAN | VPC Lattice |
| --- | --- | --- | --- | --- | --- | --- |
| スコープ | リージョン/グローバル | リージョン別 | リージョン別 | リージョン別 | グローバル | リージョン別 |
| アーキテクチャ | フルメッシュ | VPN hub-and-spoke | アタッチメントベースのhub-and-spoke | プロバイダーまたはコンシューマーモデル | 添付ファイルベース、マルチリージョン | アプリ間の接続 |
| スケール | 125 のアクティブなピア/VPC | 仮想ルーター/EC2 によって異なります | リージョンあたり 5,000 個の添付ファイル | 制限なし | コアネットワークあたり 5000 個のアタッチメント | サービスあたり 500 VPC の関連付け |
| セグメンテーション | セキュリティグループ | カスタマーマネージド | Transit Gateway ルートテーブル | セグメンテーションなし | セグメント | サービスおよびサービスネットワークポリシー |
| レイテンシー | 低 | VPN 暗号化のオーバーヘッドによる追加 | 追加の Transit Gateway ホップ | トラフィックは AWS バックボーンにとどまるため、お客様はテストする必要があります | Transit Gateway と同じデータプレーンを使用します | トラフィックは AWS バックボーンにとどまるため、お客様はテストする必要があります |
| 帯域幅制限 | インスタンスあたりの制限、集計制限なし | サイズ/ファミリーに基づく EC2 インスタンスの帯域幅制限の対象 | 最大 100 Gbps (バースト)/アタッチメント | アベイラビリティーゾーンあたり 10 Gbps、自動的に 100 Gbps までスケールアップ | 最大 100 Gbps (バースト)/アタッチメント | アベイラビリティーゾーンあたり 10 Gbps |
| [可視性] | VPC フローログ | VPC フローログと CloudWatch メトリクス | Transit Gateway Network Manager、VPC フローログ、CloudWatch メトリクス | CloudWatch メトリクス | Network Manager、VPC フローログ、CloudWatch メトリクス | CloudWatch アクセスログ |
| セキュリティグループ 相互参照 | サポート | サポートされません | サポートされません | サポートされません | サポートされません | 該当しない |
| IPv6 サポート | サポート | 仮想アプライアンスによって異なります | サポート | サポート対象 | サポート対象 | サポート |
# AWS PrivateLink
[AWS PrivateLink](https://aws.amazon.com/privatelink/) は、トラフィックをパブリックインターネットに公開することなく、VPCs、AWS サービス、オンプレミスネットワーク間のプライベート接続を提供します。を利用したインターフェイス VPC エンドポイントを使用すると AWS PrivateLink、さまざまなアカウント AWS や VPCs 間で や他の サービスに簡単に接続できるため、ネットワークアーキテクチャが大幅に簡素化されます。これにより、コンシューマー VPC のみがサービスプロバイダー VPC への接続を開始する AWS リージョン 方法で、ある VPCs (サービスプロバイダー) に存在するサービス/アプリケーションを 内の他の VPCs (コンシューマー) にプライベートに公開することができます。例としては、プライベートアプリケーションがサービスプロバイダー APIs。
を使用するには AWS PrivateLink、VPC でアプリケーションの Network Load Balancer を作成し、そのロードバランサーを指す VPC エンドポイントサービス設定を作成します。次に、サービスコンシューマーはサービスへのインターフェイスエンドポイントを作成します。これにより、コンシューマーサブネットに Elastic Network Interface (ENI) が作成され、サービス宛てのトラフィックのエントリポイントとして機能するプライベート IP アドレスが割り当てられます。コンシューマーとサービスは、同じ VPC に存在する必要はありません。VPC が異なる場合、コンシューマーとサービスプロバイダーVPCs は重複する IP アドレス範囲を持つことができます。次の図に示すように、インターフェイス VPC エンドポイントを作成して他の VPCs のサービスにアクセスすることに加えて、インターフェイス VPC エンドポイントを作成して AWS PrivateLink、 を介して[サポートされている AWS のサービス](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)にプライベートにアクセスできます。
Application Load Balancer (ALB) を NLB のターゲットとして、ALB の高度なルーティング機能を と組み合わせることができるようになりました AWS PrivateLink。リファレンスアーキテクチャと詳細な設定については、[Network Application Load Balancer の Application Load Balancer タイプのターゲットグループ](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/)を参照してください。
![\[他の VPCs および AWS サービスへの接続 AWS PrivateLink を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/aws-privatelink.png)
Transit Gateway、VPC ピアリング、 のいずれかの選択 AWS PrivateLink は、接続によって異なります。
+ **AWS PrivateLink** — 1 つ以上のコンシューマー VPCs に、サービスプロバイダー VPC または特定の AWS サービス内の特定のサービスまたはインスタンスセットへの単方向アクセスを許可する AWS PrivateLink クライアント/サーバーが設定されている場合に使用します。コンシューマー VPC でアクセス権を持つクライアントのみが、サービスプロバイダー VPC またはサービス内の AWS サービスへの接続を開始できます。これは、2 つの VPCsを持つ場合にも適しています。 は、 がサービスプロバイダーとの IP 競合がないことを保証する方法でクライアント VPC 内の ENIs AWS PrivateLink を使用するためです。VPC ピアリング、VPN、Transit Gateway、Cloud WAN、および を介して AWS PrivateLink エンドポイントにアクセスできます AWS Direct Connect。
+ **VPC ピアリングと Transit Gateway** — VPC 間のレイヤー 3 IP 接続を有効にする場合はVPCs。
アーキテクチャには、さまざまなユースケースに対応するために、これらのテクノロジーが混在しています。これらのサービスはすべて、相互に組み合わせて運用できます。例えば、API スタイルのクライアント/サーバー接続 AWS PrivateLink の処理、 リージョン内でプレイスメントグループがまだ望ましい直接接続要件を処理するための VPC ピアリング、大規模な VPCs の接続を簡素化するための Transit Gateway、ハイブリッド接続のエッジ統合などです。
# VPC 共有
VPCsは、チーム間のネットワーク分離を VPC 所有者が厳密に管理する必要はなく、アカウントレベルのユーザーとアクセス許可が である必要がある場合に役立ちます。[共有 VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) では、複数の AWS アカウントが、共有され一元管理された Amazon VPCs にアプリケーションリソース (Amazon EC2 インスタンスなど) を作成します。このモデルでは、VPC を所有するアカウント (所有者) は、他のアカウント (参加者) と 1 つ以上のサブネットを共有します。サブネットが共有されると、参加者は共有しているサブネット内にある自分のアプリケーションリソースを表示、作成、変更、および削除できます。参加者は、他の参加者または VPC 所有者に属するリソースを表示、変更、または削除することはできません。共有 VPCs内のリソース間のセキュリティは、セキュリティグループ、ネットワークアクセスコントロールリスト (NACLs)、またはサブネット間のファイアウォールを使用して管理されます。
VPC 共有の利点：
+ 設計の簡素化 — VPC 間の接続を複雑にしない
+ 管理対象 VPCsの削減
+ ネットワークチームとアプリケーション所有者間の職務の分離
+ IPv4 アドレス使用率の向上
+ コストの削減 — 同じアベイラビリティーゾーン内の異なるアカウントに属するインスタンス間でのデータ転送料金は発生しません
**注記**
サブネットを複数のアカウントと共有する場合、参加者は IP スペースとネットワークリソースを共有しているため、ある程度の協力が必要です。必要に応じて、参加者アカウントごとに異なるサブネットを共有できます。参加者ごとに 1 つのサブネットにより、ネットワーク ACL はセキュリティグループに加えてネットワーク分離を提供できます。
ほとんどのカスタマーアーキテクチャには複数の VPCsが含まれ、その多くは 2 つ以上のアカウントと共有されます。Transit Gateway と VPC ピアリングを使用して、共有 VPCsを接続できます。例えば、10 個のアプリケーションがあるとします。各アプリケーションには、独自の AWS アカウントが必要です。アプリケーションは 2 つのアプリケーションポートフォリオに分類できます (同じポートフォリオ内のアプリケーションには、「マーケティング」のアプリケーション 1～5 と「セールス」のアプリケーション 6～10 という同様のネットワーク要件があります）。
アプリケーションポートフォリオごとに 1 つの VPC (合計 2 つの VPCs) を持つことができ、VPC はそのポートフォリオ内の異なるアプリケーション所有者アカウントと共有されます。アプリ所有者は、それぞれの共有 VPC にアプリをデプロイします (この場合は、NACLs を使用したネットワークルートのセグメント化と分離のための異なるサブネット）。2 つの共有 VPCs は Transit Gateway を介して接続されます。この設定では、次の図に示すように、10 個の VPCs を 2 つの VPC に接続する必要がなくなります。
![\[共有 VPC の設定例を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-shared-vpc.png)
**注記**
VPC 共有参加者は、共有サブネットにすべての AWS リソースを作成することはできません。詳細については、VPC 共有ドキュメントの[「制限](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations)」セクションを参照してください。
VPC 共有の主な考慮事項とベストプラクティスの詳細については、ブログ記事[「VPC 共有: 重要な考慮事項とベストプラクティス](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-key-considerations-and-best-practices/)」を参照してください。
# プライベート NAT ゲートウェイ
チームは多くの場合、独立して作業し、プロジェクト用に新しい VPC を作成することがあります。この VPC には、クラスレスドメイン間ルーティング (CIDR) ブロックが重複している可能性があります。統合のために、重複する CIDRs、VPC ピアリングや Transit Gateway などの機能では実現できません。プライベート NAT ゲートウェイはこのユースケースに役立ちます。プライベート NAT ゲートウェイは、一意のプライベート IP アドレスを使用して、重複する送信元 IP アドレスの送信元 NAT を実行し、ELB は重複する送信先 IP アドレスの送信先 NAT を実行します。Transit Gateway または仮想プライベートゲートウェイを使用して、プライベート NAT ゲートウェイから他の VPCs またはオンプレミスネットワークにトラフィックをルーティングできます。
![\[プライベート NAT ゲートウェイのセットアップ例を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-private-nat-gateway.png)
上の図は、VPC A と B の 2 つのルーティング不可能な (重複CIDRs、`100.64.0.0/16`) サブネットを示しています。それらの間の接続を確立するには、VPC A `10.0.1.0/24`と B にそれぞれ、重複しない/ルーティング可能なセカンダリ CIDRs (ルーティング可能なサブネット、`10.0.2.0/24`) を追加できます。ルーティング可能な CIDRs は、IP 割り当てを担当するネットワーク管理チームによって割り当てられる必要があります。プライベート NAT ゲートウェイは、IP アドレスが の VPC A のルーティング可能なサブネットに追加されます`10.0.1.125`。プライベート NAT ゲートウェイは、VPC A (`100.64.0.10`) のルーティング不可能なサブネットのインスタンスからのリクエストに対して`10.0.1.125`、プライベート NAT ゲートウェイの ENI である としてソースネットワークアドレス変換を実行します。これで、トラフィックは、 のターゲットを持つ VPC B () の Application Load Balancer (ALB`10.0.2.10`) に割り当てられたルーティング可能な IP アドレスを指すことができます`100.64.0.10`。トラフィックは Transit Gateway を介してルーティングされます。リターントラフィックは、プライベート NAT ゲートウェイによって元の Amazon EC2 インスタンスに接続をリクエストして処理されます。
プライベート NAT ゲートウェイは、オンプレミスネットワークが承認された IPs へのアクセスを制限するときにも使用できます。少数のお客様のオンプレミスネットワークは、お客様が所有する承認された IPs の限られた連続したブロックを介してのみ、プライベートネットワーク (IGW なし) とのみ通信することをコンプライアンスで要求されます。各インスタンスに ブロックから個別の IP を割り当てる代わりに、プライベート NAT ゲートウェイを使用して、許可リストに登録された各 IP の背後にある AWS VPCs で大規模なワークロードを実行できます。詳細については、[「プライベート NAT ソリューションによるプライベート IP の枯渇を解決する方法](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/)」ブログ記事を参照してください。
![\[プライベート NAT ゲートウェイを使用してオンプレミスネットワークに承認された IPs を提供する方法を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/how-to-use-nat.png)
# AWS クラウド WAN
AWS Cloud WAN は、以前はトランジットゲートウェイ、VPC ピアリング、IPSEC VPN トンネルでできたネットワークを接続する新しい方法です。以前は、1 つ以上の VPCs を設定し、前の方法のいずれかと併せて接続し、IPSEC VPN Direct Connect または を使用してオンプレミスネットワークに接続していました。ネットワークとセキュリティ体制のコンストラクトは 1 つの場所で定義し、ネットワークは別の場所で定義します。クラウド WAN を使用すると、これらのコンストラクトをすべて 1 か所に一元化できます。ポリシーにより、ネットワークをセグメント化して誰が誰と話せるかを判断し、これらのセグメントを介して本稼働トラフィックを開発ワークロードやテストワークロード、またはオンプレミスネットワークから分離できます。
![\[AWS Cloud WAN 接続を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/cloud-wan-diagram.png)
Network Manager のユーザーインターフェイスと APIs を使用してグローバル AWS ネットワークを管理します。グローバルネットワークは、すべてのネットワークオブジェクトのルートレベルのコンテナです。コアネットワークは、AWS によって管理されるグローバルネットワークの一部です。コアネットワークポリシー (CNP) は、コアネットワークのあらゆる側面を定義する単一のバージョニングポリシードキュメントです。アタッチメントは、コアネットワークに追加する接続またはリソースです。コアネットワークエッジ (CNE) は、 ポリシーに準拠するアタッチメントのローカル接続ポイントです。ネットワークセグメントはルーティングドメインであり、デフォルトではセグメント内での通信のみを許可します。
CloudWAN を使用するには：
1. AWS Network Manager で、グローバルネットワークと関連するコアネットワークを作成します。
1. セグメントにアタッチするセグメント、ASN 範囲、 AWS リージョン タグを定義する CNP を作成します。
1. ネットワークポリシーを適用します。
1. リソースアクセスマネージャーを使用して、コアネットワークをユーザー、アカウント、または組織と共有します。
1. 添付ファイルを作成してタグ付けします。
1. アタッチされた VPCsのルートを更新して、コアネットワークを含めます。
クラウド WAN は、AWS インフラストラクチャをグローバルに接続するプロセスを簡素化するように設計されています。これにより、一元的なアクセス許可ポリシーでトラフィックをセグメント化し、会社の場所で既存のインフラストラクチャを使用できます。Cloud WAN は、VPCs、SD-WANs、クライアント VPNs、ファイアウォール、VPNs、データセンターリソースも接続して Cloud WAN に接続します。詳細については、[AWS Cloud WAN ブログ記事](https://aws.amazon.com/blogs/networking-and-content-delivery/category/networking-content-delivery/aws-cloud-wan/)を参照してください。
AWS Cloud WAN は、クラウド環境とオンプレミス環境を接続する統合ネットワークを可能にします。組織は、次世代ファイアウォール (NGFWsと侵入防止システム (IPSs) をセキュリティに使用します。[AWS Cloud WAN と Transit Gateway の移行と相互運用性のパターン](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-cloud-wan-and-aws-transit-gateway-migration-and-interoperability-patterns/)に関するブログ記事では、単一リージョンネットワークとマルチリージョンネットワークを含む Cloud WAN ネットワーク内のアウトバウンドネットワークトラフィックを一元的に管理および検査するためのアーキテクチャパターンについて説明し、ルートテーブルを設定します。これらのアーキテクチャにより、安全なクラウド環境を維持しながら、データとアプリケーションを安全に維持できます。
Cloud WAN の詳細については、[AWS Cloud WAN ブログ記事の「集中型アウトバウンド検査アーキテクチャ](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-outbound-inspection-architecture-in-aws-cloud-wan/)」を参照してください。
# Amazon VPC Lattice
Amazon VPC Lattice は、フルマネージド型のアプリケーションネットワークサービスであり、さまざまなアカウントや仮想プライベートクラウドで サービスを接続、モニタリング、保護するために使用されます。VPC Lattice は、サービスを論理的な境界内で相互接続するのに役立つため、サービスを効率的に管理および検出できます。
VPC Lattice コンポーネントは以下で構成されます。
+ **サービス** - インスタンス、コンテナ、または Lambda 関数で実行されるアプリケーションの単位であり、リスナー、ルール、ターゲットグループで構成されます。
+ **サービスネットワーク** - これは、サービスの検出と接続を自動的に実装し、サービスのコレクションに共通のアクセスポリシーとオブザーバビリティポリシーを適用するために使用される論理的な境界です。
+ **認証ポリシー** - リクエストレベルの認証とコンテキスト固有の認可をサポートするために、サービスネットワークまたは個々のサービスに関連付けることができる IAM リソースポリシー。
+ **サービスディレクトリ** - 所有しているサービス、または AWS Resource Access Manager を通じて共有されているサービスを一元的に表示します。
VPC Lattice の使用手順：
1. サービスネットワークを作成します。サービスネットワークは通常、ネットワーク管理者がフルアクセスを持つネットワークアカウントにあります。サービスネットワークは、組織内の複数のアカウント間で共有できます。共有は、個々のサービスまたはサービスアカウント全体で実行できます。
1. VPCs をサービスネットワークにアタッチして、各 VPC のアプリケーションネットワークを有効にし、異なるサービスがネットワークに登録されている他のサービスの消費を開始できるようにします。セキュリティグループは、トラフィックを制御するために適用されます。
1. デベロッパーは、サービスディレクトリに入力され、サービスネットワークに登録されるサービスを定義します。VPC Lattice には、設定されたすべてのサービスのアドレス帳が含まれています。デベロッパーは、ブルー/グリーンデプロイを使用するようにルーティングポリシーを定義することもできます。セキュリティは、認証および認可ポリシーが定義されているサービスネットワークレベルと、IAM によるアクセスポリシーが実装されているサービスレベルで管理されます。
![\[VPC Lattice 通信フローを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/vpc-lattice.png)
詳細については、VPC [Lattice ユーザーガイド](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html )を参照してください。