翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# インターネットへの一元的なエグレス
マルチアカウント環境にアプリケーションをデプロイする場合、多くのアプリではアウトバウンドのみのインターネットアクセス (ライブラリ、パッチ、OS 更新のダウンロードなど) が必要になります。これは、IPv4 トラフィックと IPv6 トラフィックの両方で実現できます。IPv4 の場合、これは、NAT ゲートウェイ (推奨) の形式のネットワークアドレス変換 (NAT)、またはすべての出力インターネットアクセスの手段として Amazon EC2 インスタンスで実行されているセルフマネージド NAT インスタンスを通じて実現できます。内部アプリケーションはプライベートサブネットにあり、NAT ゲートウェイと Amazon EC2 NAT インスタンスはパブリックサブネットにあります。
AWS では、NAT ゲートウェイの使用を推奨しています。NAT ゲートウェイは、可用性と帯域幅が向上し、管理にかかる労力が少なくて済むためです。詳細については、[「NAT ゲートウェイと NAT インスタンスの比較](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html)」を参照してください。
IPv6 トラフィックの場合、Egress トラフィックは、分散された方法で Egress Only インターネットゲートウェイを介して各 VPC を離れるように設定することも、NAT インスタンスまたはプロキシインスタンスを使用して一元化された VPC に送信するように設定することもできます。IPv6 パターンについては、「」を参照してください[IPv6 の一元化された出力](centralized-egress-for-ipv6.md)。
**Topics**
+ [集中 IPv4 出力に NAT ゲートウェイを使用する](using-nat-gateway-for-centralized-egress.md)
+ [で NAT ゲートウェイを使用して IPv4 を AWS Network Firewall 一元的に出力する](using-nat-gateway-with-firewall.md)
+ [Amazon EC2 インスタンスでの NAT ゲートウェイと Gateway Load Balancer を使用した一元的な IPv4 出力](using-nat-gateway-and-gwlb-with-ec2.md)
+ [IPv6 の一元化された出力](centralized-egress-for-ipv6.md)
# 集中 IPv4 出力に NAT ゲートウェイを使用する
NAT ゲートウェイは、マネージドネットワークアドレス変換サービスです。すべてのスポーク VPC に NAT ゲートウェイをデプロイすると、デプロイするすべての NAT ゲートウェイに対して時間単位の料金が発生するため ([Amazon VPC の料金](https://aws.amazon.com/vpc/pricing/)を参照）、コストがかかる可能性があります。NAT ゲートウェイを一元化することは、コストを削減するための実行可能なオプションです。一元化するには、次の図に示すように、ネットワークサービスアカウントに個別の Egress VPC を作成し、Egress VPC に NAT ゲートウェイをデプロイし、スポーク VPCs からのすべての Egress トラフィックを Transit Gateway または CloudWAN を使用して Egress VPC に存在する NAT ゲートウェイにルーティングします。
**注記**
Transit Gateway を使用して NAT ゲートウェイを一元化する場合、すべての VPC で NAT ゲートウェイを実行する分散アプローチと比較して、追加の Transit Gateway データ処理料金が発生します。エッジケースによっては、VPC から NAT ゲートウェイを介して大量のデータを送信する場合、Transit Gateway データ処理料金を回避するために、VPC で NAT をローカルにしておく方がコスト効率の高いオプションになる場合があります。
![\[分散型高可用性 NAT ゲートウェイアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/decentralized-ha-nat-gateway.png)
![\[Transit Gateway を使用した集中型 NAT ゲートウェイを示す図 (概要)\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-nat-gateway-tg.png)
![\[Transit Gateway を使用した集中型 NAT ゲートウェイを示す図 (ルートテーブル設計)\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/nat-gateway-tg-rt.png)
この設定では、スポーク VPC アタッチメントはルートテーブル 1 (RT1) に関連付けられ、ルートテーブル 2 (RT2) に伝達されます。2 つの VPCs 間の通信を禁止する[ブラックホール](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html)ルートがあります。VPC 間通信を許可する場合は、RT1 から`10.0.0.0/8 -> Blackhole`ルートエントリを削除できます。これにより、トランジットゲートウェイ経由で通信できるようになります。スポーク VPC アタッチメントを RT1 に伝達することもできます (または、1 つのルートテーブルを使用してすべてを関連付け/伝達することもできます）。これにより、Transit Gateway を使用して VPCs 間の直接トラフィックフローが可能になります。
RT1 にすべてのトラフィックを Egress VPC にポイントする静的ルートを追加します。この静的ルートのため、Transit Gateway は、送信 VPC の ENIs を介してすべてのインターネットトラフィックを送信します。エグレス VPC に入ると、トラフィックはこれらの Transit Gateway ENIs が存在するサブネットルートテーブルで定義されたルートに従います。サブネットルートテーブルに、同じアベイラビリティーゾーン内のそれぞれの NAT ゲートウェイを指すルートを追加して、クロスアベイラビリティーゾーン (AZ) トラフィックを最小限に抑えます。NAT ゲートウェイサブネットルートテーブルには、ネクストホップとしてインターネットゲートウェイ (IGW) があります。リターントラフィックをフローバックするには、すべてのスポーク VPC バインドトラフィックをネクストホップとして Transit Gateway にポイントする静的ルートテーブルエントリを NAT ゲートウェイサブネットルートテーブルに追加する必要があります。
## 高可用性
高可用性を実現するには、複数の NAT ゲートウェイ (各アベイラビリティーゾーンに 1 つずつ) を使用する必要があります。NAT ゲートウェイが使用できない場合、影響を受けた NAT ゲートウェイを通過するそのアベイラビリティーゾーンでトラフィックがドロップされる可能性があります。1 つのアベイラビリティーゾーンが使用できない場合、そのアベイラビリティーゾーンの Transit Gateway エンドポイントと NAT ゲートウェイは失敗し、すべてのトラフィックは他のアベイラビリティーゾーンの Transit Gateway エンドポイントと NAT ゲートウェイエンドポイントを経由して流れます。
## セキュリティ
セキュリティグループは、ソースインスタンス、Transit Gateway ルートテーブルのブラックホールルート、および NAT ゲートウェイが配置されているサブネットのネットワーク ACL に依存します。たとえば、お客様は NAT Gateway パブリックサブネット (複数可) の ACLs を使用して、送信元または送信先の IP アドレスを許可またはブロックできます。または、NAT Gateway を と共に使用 AWS Network Firewall して、次のセクションで説明する一元的な出力を行い、この要件を満たすこともできます。
## スケーラビリティ
単一の NAT ゲートウェイは、割り当てられた IP アドレスごとに一意の送信先ごとに最大 55,000 の同時接続をサポートできます。クォータ調整をリクエストして、最大 8 つの割り当てられた IP アドレスを許可し、1 つの送信先 IP とポートへの同時接続を 440,000 回許可できます。NAT ゲートウェイは 5 Gbps の帯域幅を提供し、自動的に 100 Gbps にスケールします。トランジットゲートウェイは通常、ロードバランサーとして機能しず、複数のアベイラビリティーゾーンの NAT ゲートウェイ間でトラフィックを均等に分散しません。トランジットゲートウェイ全体のトラフィックは、可能であればアベイラビリティーゾーン内に留まります。トラフィックを開始する Amazon EC2 インスタンスがアベイラビリティーゾーン 1 にある場合、トラフィックはエグレス VPC の同じアベイラビリティーゾーン 1 の Transit Gateway Elastic Network Interface から流れ出し、Elastic Network Interface が存在するサブネットルートテーブルに基づいてネクストホップに流れます。ルールの完全なリストについては、Amazon Virtual Private Cloud ドキュメント[の NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を参照してください。
詳細については、[AWS Transit Gateway を使用して複数の VPCs から単一のインターネット出口ポイントを作成する](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-a-single-internet-exit-point-from-multiple-vpcs-using-aws-transit-gateway/)ブログ記事を参照してください。
# で NAT ゲートウェイを使用して IPv4 を AWS Network Firewall 一元的に出力する
アウトバウンドトラフィックを検査およびフィルタリングする場合は、一元化された Egress アーキテクチャに AWS Network Firewall と NAT ゲートウェイを組み込むことができます。 AWS Network Firewall は、すべての VPCs。VPC 全体の Layer 3-7 ネットワークトラフィックを制御および可視化します。URL/ドメイン名、IP アドレス、コンテンツベースのアウトバウンドトラフィックフィルタリングを実行して、データ損失の可能性を防ぎ、コンプライアンス要件を満たし、既知のマルウェア通信をブロックできます。 は、既知の不正な IP アドレスまたは不正なドメイン名を宛先とするネットワークトラフィックを除外できる数千のルール AWS Network Firewall をサポートしています。また、オープンソースのルールセットをインポートするか、Suricata ルール構文を使用して独自の侵入防止システム (IPS) ルールを作成することで、 AWS Network Firewall サービスの一部として Suricata IPS ルールを使用することもできます。 では、AWS パートナーから取得した互換性のあるルールをインポート AWS Network Firewall することもできます。
検査を使用した一元化された Egress アーキテクチャでは、 AWS Network Firewall エンドポイントは、Egress VPC の Transit Gateway アタッチメントサブネットルートテーブルのデフォルトのルートテーブルターゲットです。スポーク VPCsとインターネット間のトラフィックは、次の図 AWS Network Firewall に示すように を使用して検査されます。
![\[AWS Network Firewall と NAT ゲートウェイを使用した一元的な出力を示す図 (ルートテーブル設計)\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-rt.png)
Transit Gateway を使用した一元化されたデプロイモデルの場合、AWS では複数のアベイラビリティーゾーンにエンドポイントをデプロイ AWS Network Firewall することをお勧めします。前の図に示すように、お客様がワークロードを実行しているアベイラビリティーゾーンごとにファイアウォールエンドポイントが 1 つある必要があります。ベストプラクティスとして、 はファイアウォールサブネット内の送信元または送信先からのトラフィックを検査 AWS Network Firewall できないため、ファイアウォールサブネットには他のトラフィックを含めないでください。
前のセットアップと同様に、スポーク VPC アタッチメントはルートテーブル 1 (RT1) に関連付けられ、ルートテーブル 2 (RT2) に伝達されます。ブラックホールルートが明示的に追加され、2 つの VPCs 間の通信が禁止されます。
RT1 では、すべてのトラフィックを Egress VPC にポイントするデフォルトルートを引き続き使用します。Transit Gateway は、すべてのトラフィックフローを Egress VPC の 2 つのアベイラビリティーゾーンのいずれかに転送します。トラフィックが Egress VPC 内の Transit Gateway ENIs の 1 つに到達すると、トラフィックをそれぞれのアベイラビリティーゾーンの AWS Network Firewall エンドポイントの 1 つに転送するデフォルトルートに到達します。 AWS Network Firewall は、デフォルトルートを使用してトラフィックを NAT ゲートウェイに転送する前に設定したルールに基づいてトラフィックを検査します。
この場合、アタッチメント間でトラフィックを送信しないため、Transit Gateway アプライアンスモードは必要ありません。
**注記**
AWS Network Firewall はネットワークアドレス変換を実行しません。この関数は、 を介したトラフィック検査後に NAT ゲートウェイによって処理されます AWS Network Firewall。この場合、リターントラフィックはデフォルトで NATGW IPs に転送されるため、受信ルーティングは必要ありません。
Transit Gateway を使用しているため、ここでは NAT ゲートウェイの前にファイアウォールを配置できます。このモデルでは、ファイアウォールは Transit Gateway の背後にあるソース IP を確認できます。
これを単一の VPC で実行している場合、同じ VPC 内のサブネット間のトラフィックを検査できる VPC ルーティングの機能強化を使用できます。詳細については、「[VPC ルーティング機能強化 AWS Network Firewall による のデプロイモデル](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall-with-vpc-routing-enhancements/)」ブログ記事を参照してください。
## スケーラビリティ
AWS Network Firewall は、トラフィック負荷に基づいてファイアウォール容量を自動的にスケールアップまたはスケールダウンして、安定した予測可能なパフォーマンスを維持し、コストを最小限に抑えることができます。 AWS Network Firewall は、何万ものファイアウォールルールをサポートするように設計されており、アベイラビリティーゾーンあたり最大 100 Gbps のスループットまでスケールできます。
## 主な考慮事項
+ 各ファイアウォールエンドポイントは、約 100 Gbps のトラフィックを処理できます。より高いバーストまたは持続的なスループットが必要な場合は、[AWS サポート](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html)にお問い合わせください。
+ Network Firewall とともに AWS アカウントに NAT ゲートウェイを作成する場合、標準の NAT ゲートウェイ処理と 1 時間あたりの使用[料金は](https://aws.amazon.com/network-firewall/pricing/)、GB あたりの処理とファイアウォールの使用時間に基づいて one-to-one で免除されます。
+ Transit Gateway AWS Firewall Manager を使用せずに、 を介して分散ファイアウォールエンドポイントを検討することもできます。
+ ネットワークアクセスコントロールリストと同様に、ファイアウォールルールを本番環境に移行する前に、順序が重要かどうかをテストします。
+ 詳細な検査には、高度な Suricata ルールが必要です。ネットワークファイアウォールは、イングレストラフィックとエグレストラフィックの暗号化されたトラフィック検査をサポートしています。
+ `HOME_NET` ルールグループ変数は、ステートフルエンジンでの処理の対象となるソース IP 範囲を定義しました。一元化されたアプローチを使用して、Transit Gateway にアタッチされたすべての VPC CIDRs を追加して、処理の対象にする必要があります。`HOME_NET` ルールグループ変数の詳細については、[Network Firewall のドキュメント](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-domain-names.html)を参照してください。
+ Transit Gateway と Egress VPC を別の Network Services アカウントにデプロイして、職務の委任に基づいてアクセスを分離することを検討してください。たとえば、ネットワーク管理者のみが Network Services アカウントにアクセスできます。
+ このモデル AWS Network Firewall での のデプロイと管理を簡素化するために、 AWS Firewall Manager を使用できます。Firewall Manager では、一元化された場所で作成した保護を複数のアカウントに自動的に適用することで、さまざまなファイアウォールを一元管理できます。Firewall Manager は、Network Firewall の分散デプロイモデルと集中デプロイモデルの両方をサポートします。詳細については、ブログ記事[「 AWS Network Firewall を使用してデプロイする方法 AWS Firewall Manager](https://aws.amazon.com/blogs/security/how-to-deploy-aws-network-firewall-by-using-aws-firewall-manager/)」を参照してください。
# Amazon EC2 インスタンスでの NAT ゲートウェイと Gateway Load Balancer を使用した一元的な IPv4 出力
AWS Marketplace と からのソフトウェアベースの仮想アプライアンス (Amazon EC2 上) を出口ポイント AWS Partner Network として使用する方法は、NAT ゲートウェイのセットアップと似ています。このオプションは、さまざまなベンダーが提供する高度なレイヤー 7 ファイアウォール/侵入防止/検出システム (IPS/IDS) およびディープパケットインスペクション機能を使用する場合に使用できます。
次の図では、NAT ゲートウェイに加えて、Gateway Load Balancer (GWLB) の背後にある EC2 インスタンスを使用して仮想アプライアンスをデプロイします。この設定では、GWLB、Gateway Load Balancer Endpoint (GWLBE)、仮想アプライアンス、NAT ゲートウェイが、VPC アタッチメントを使用して Transit Gateway に接続されている一元化された VPC にデプロイされます。スポーク VPCsは、VPC アタッチメントを使用して Transit Gateway にも接続されます。GWLBEs はルーティング可能なターゲットであるため、Transit Gateway との間で送受信されるトラフィックを、GWLB の背後にあるターゲットとして設定された仮想アプライアンスのフリートにルーティングできます。GWLB bump-in-the-wireとして機能し、すべての Layer 3 トラフィックをサードパーティーの仮想アプライアンスに透過的に渡すため、トラフィックの送信元と送信先には表示されません。したがって、このアーキテクチャにより、Transit Gateway を通過するすべての出力トラフィックを一元的に検査できます。
VPCs[「AWS Gateway Load Balancer を使用した一元化された検査アーキテクチャ AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/)」および「」を参照してください。
Transit Gateway でアプライアンスモードを有効にして、仮想アプライアンスを介してフロー対称性を維持できます。つまり、双方向トラフィックは、フローの存続期間中、同じアプライアンスとアベイラビリティーゾーンを介してルーティングされます。この設定は、ディープパケットインスペクションを実行するステートフルファイアウォールにとって特に重要です。アプライアンスモードを有効にすると、ソースネットワークアドレス変換 (SNAT) などの複雑な回避策が不要になり、トラフィックを適切なアプライアンスに強制的に戻して対称性を維持します。詳細については、「[Gateway Load Balancer をデプロイするためのベストプラクティス](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/)」を参照してください。
Transit Gateway を使用せずに GWLB エンドポイントを分散的にデプロイして、出力検査を有効にすることもできます。このアーキテクチャパターンの詳細については、ブログ記事[「AWS Gateway Load Balancer の紹介: サポートされているアーキテクチャパターン](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/)」を参照してください。
![\[Gateway Load Balancer と EC2 インスタンスによる集中出力を示す図 (ルートテーブル設計)\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-gwlb-and-ec2.png)
## 高可用性
AWS では、可用性を高めるために、Gateway Load Balancer と仮想アプライアンスを複数のアベイラビリティーゾーンにデプロイすることをお勧めします。
Gateway Load Balancer は、ヘルスチェックを実行して仮想アプライアンスの障害を検出できます。アプライアンスに異常がある場合、GWLB は新しいフローを正常なアプライアンスに再ルーティングします。既存のフローは、ターゲットのヘルスステータスに関係なく、常に同じターゲットに送信されます。これにより、接続ドレインが可能になり、アプライアンスの CPU スパイクによるヘルスチェックの失敗に対応できます。詳細については、ブログ記事[「Gateway Load Balancer をデプロイするためのベストプラクティス](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/)」の「セクション 4: アプライアンスとアベイラビリティーゾーンの障害シナリオを理解する」を参照してください。Gateway Load Balancer は、Auto Scaling グループをターゲットとして使用できます。この利点により、アプライアンスフリートの可用性とスケーラビリティの管理に手間がかかります。
## 利点
Gateway Load Balancer と Gateway Load Balancer エンドポイントは を利用しているため AWS PrivateLink、パブリックインターネットを経由することなく、VPC 境界間でトラフィックを安全に交換できます。
Gateway Load Balancer は、仮想セキュリティアプライアンスの管理、デプロイ、スケーリングの差別化されていない負担を軽減し、重要なことに集中できるようにするマネージドサービスです。Gateway Load Balancer は、お客様が を使用してサブスクライブできるように、ファイアウォールのスタックをエンドポイントサービスとして公開できます[AWS Marketplace](https://aws.amazon.com/marketplace)。これは Firewall as a Service (FWaaS) と呼ばれます。シンプルなデプロイを導入し、BGP と ECMP に依存して複数の Amazon EC2 インスタンスにトラフィックを分散する必要がなくなります。
## 主な考慮事項
+ アプライアンスは、GWLB と統合するために [Geneve](https://datatracker.ietf.org/doc/html/rfc8926) カプセル化プロトコルをサポートする必要があります。
+ 一部のサードパーティーアプライアンスは SNAT およびオーバーレイルーティング ([2 アームモード](https://networkgeekstuff.com/networking/basic-load-balancer-scenarios-explained/)) をサポートできるため、コストを削減するために NAT ゲートウェイを作成する必要がなくなります。ただし、このモードを使用する前に、任意の AWS パートナーに相談してください。これはベンダーのサポートと実装に依存します。
+ [GWLB アイドルタイムアウト](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/gateway-load-balancers.html#idle-timeout)を書き留めます。これにより、クライアントで接続がタイムアウトする可能性があります。クライアント、サーバー、ファイアウォール、OS レベルでタイムアウトを調整して、これを回避できます。詳細については、[「Gateway Load Balancer をデプロイするためのベストプラクティス](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/)」ブログ記事の*「セクション 1: TCP キープアライブ値またはタイムアウト値をチューニングして、存続期間の長い TCP フローをサポートする*」を参照してください。
+ GWLBE は を利用しているため AWS PrivateLink、 AWS PrivateLink 料金が適用されます。詳細については、 の[AWS PrivateLink 料金表ページ](https://aws.amazon.com/privatelink/pricing/)を参照してください。Transit Gateway で一元化されたモデルを使用している場合は、TGW データ処理料金が適用されます。
+ Transit Gateway と Egress VPC を別の Network Services アカウントにデプロイして、ネットワーク管理者のみが Network Services アカウントにアクセスできるなど、職務の委任に基づいてアクセスを分離することを検討してください。
# IPv6 の一元化された出力
一元化された IPv4 出力を持つデュアルスタックデプロイで IPv6 出力をサポートするには、次の 2 つのパターンのいずれかを選択する必要があります。 IPv4
+ 分散 IPv4 出力を使用した集中 IPv6 出力
+ 一元化された IPv4 出力と一元化された IPv6 出力
次の図に示す最初のパターンでは、エグレス専用インターネットゲートウェイが各スポーク VPC にデプロイされます。Egress-Only インターネットゲートウェイは、VPC 内のインスタンスからの IPv6 経由のアウトバウンド通信を可能にする、水平スケーリング、冗長化、高可用性のゲートウェイです。これにより、インターネットがインスタンスとの IPv6 接続を開始できなくなります。Egress-Only インターネットゲートウェイには料金はかかりません。このデプロイモデルでは、IPv6 トラフィックは各 VPC の Egress-Only インターネットゲートウェイから流れ出し、IPv4 トラフィックはデプロイされた一元化された NAT ゲートウェイを経由して流れます。
![\[一元化された IPV4 出力と分散されたアウトバウンドのみの IPv6 出力を示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-egress-and-decentralized-outbound-ipv6.png)
次の図に示す 2 番目のパターンでは、インスタンスからの出力 IPv6 トラフィックが集中型 VPC に送信されます。これは、NAT66 インスタンスと NAT ゲートウェイで IPv6-to-IPv6 Network Prefix Translation (NPTv6) を使用するか、プロキシインスタンスと Network Load Balancer を使用することで実現できます。 NAT66 このパターンは、アウトバウンドトラフィックの集中型トラフィック検査が必要であり、各スポーク VPC で実行できない場合に適用されます。
![\[NAT ゲートウェイと NATIPv6NAT66 出力を示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv6-egress-using-nat-gateways.png)
![\[プロキシインスタンスと Network Load Balancer を使用した集中 IPv4 および IPv6 出力を示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-and-ipv6-egress.png)
[AWS での IPv6 ホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/advanced-dual-stack-and-ipv6-only-network-designs.html)では、一元化された IPv6 出力パターンについて説明します。IPv6 出力パターンについては、ブログ記事[「デュアルスタック IPv4 および IPv6 VPCs](https://aws.amazon.com/blogs/networking-and-content-delivery/centralizing-outbound-internet-traffic-for-dual-stack-ipv4-and-ipv6-vpcs/)」で、特別な考慮事項、サンプルソリューション、図表とともに詳しく説明されています。