翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 非ワークロードサブネット用のマルチアカウント VPC 設計でルーティング可能な IP スペースを節約
<a name="preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets"></a>

*Amazon Web Services、Adam Spicer*

## 概要
<a name="preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets-summary"></a>

Amazon Web Services(AWS)は、[トランジットゲートウェイアタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html)と[ロードバランサーエンドポイント](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html) ([AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-high-level-steps.html) またはサードパーティアプライアンスをサポートするため) の両方に仮想プライベートクラウド(VPC)の専用サブネットを使用することを推奨するベストプラクティスを公開しています。これらのサブネットは、これらのサービスのエラスティックネットワークインターフェイスを格納するために使用されます。AWS Transit Gateway とゲートウェイロードバランサーの両方を使用する場合、VPC の各アベイラビリティーゾーンに 2 つのサブネットが作成されます。VPC の設計方法により、このような余分なサブネットは [/28 マスクより小さくすることはできず](https://docs---aws.amazon.com.rproxy.govskope.usvpc/latest/userguide/configure-subnets.html#subnet-sizing)、ルーティング可能なワークロードに使用できたはずの貴重なルーティング可能な IP スペースを消費する可能性があります。このパターンは、ルーティング不可能なClassless Inter-Domain Routing (CIDR) 範囲をこれらの専用サブネットに使用して、ルーティング可能な IP スペースを節約する方法を示しています。

## 前提条件と制限事項
<a name="preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets-prereqs"></a>

**前提条件**
+ ルーティング可能な IP [スペースのマルチ VPC 戦略](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html)
+ 使用しているサービス ([トランジットゲートウェイアタッチメント](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html)、[ゲートウェイロードバランサー](https://aws.amazon.com/blogs/apn/centralized-traffic-inspection-with-gateway-load-balancer-on-aws/) または [Network Firewall エンドポイント](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)) のルーティング不可能なCIDR範囲

## アーキテクチャ
<a name="preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets-architecture"></a>

**ターゲット アーキテクチャ**

このパターンには 2 つのリファレンスアーキテクチャが含まれます。1 つのアーキテクチャにはトランジットゲートウェイ (TGW) アタッチメント用のサブネットと ゲートウェイ ロードバランサーエンドポイント (GWLBE) 用のサブネットがあり、もう 1 つのアーキテクチャには TGW アタッチメント専用のサブネットがあります。

**アーキテクチャ 1 ‒ アプライアンスへの入力ルーティングを備えた TGW 接続 VPC**

次の図は、2 つのアベイラビリティーゾーンにまたがる VPC のリファレンスアーキテクチャを示しています。インレスでは、VPC は [イングレスルーティングパターン](https://aws.amazon.com/blogs/aws/new-vpc-ingress-routing-simplifying-integration-of-third-party-appliances/) を使用して、パブリックサブネット宛のトラフィックを [Bump-in-the-Wire](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/) アプライアンスに転送し、ファイアウォールインスペクションを行います。TGW アタッチメントは、プライベートサブネットから別の VPC への出力をサポートします。

このパターンでは、TGW アタッチメントサブネットと GwLBe サブネットにルーティング不可能な CIDR 範囲を使用します。TGW ルートテーブルでは、このルーティング不能な CIDR は、より具体的なルートのセットを使用してブラックホール (静的) ルートに設定されています。ルートが TGW ルートテーブルに伝達される場合、これらのより具体的なブラックホールルートが適用されます。

この例では、/23 ルーティング可能な CIDR が分割され、ルーティング可能なサブネットに完全に割り当てられます。

![\[アプライアンスへの入力ルーティングを備えた TGW 接続 VPC。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/0171d91d-ab1e-41ca-a425-1e6e610080e1/images/adad1c83-cdc2-4c5e-aa35-f47fc31af384.png)


**アーキテクチャ 2 — TGW 接続 VPC**

次の図は、2 つのアベイラビリティーゾーンにまたがる VPC のリファレンスアーキテクチャを示しています。TGW アタッチメントは、プライベートサブネットから別の VPC へのアウトバウンドトラフィック (下り) をサポートします。TGW アタッチメントサブネットにのみルーティング不可能な CIDR 範囲を使用します。TGW ルートテーブルでは、このルーティング不能な CIDR は、より具体的なルートのセットを使用してブラックホール (静的) ルートに設定されています。ルートが TGW ルートテーブルに伝達される場合、これらのより具体的なブラックホールルートが適用されます。

この例では、/23 ルーティング可能な CIDR が分割され、ルーティング可能なサブネットに完全に割り当てられます。

![\[プライベートサブネットから別の VPC に出力するための TGW アタッチメントを備えた、2 つのアベイラビリティーゾーンにまたがる VPC。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/0171d91d-ab1e-41ca-a425-1e6e610080e1/images/31a2a241-5be6-425e-93e9-5ff7ffeca3a9.png)


## ツール
<a name="preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets-tools"></a>

**AWS のサービスと設定されているリソース**
+ [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) を使用すると、定義した仮想ネットワーク内で AWS リソースを起動できます。この仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。このパターンでは、VPC セカンダリ CIDR を使用して、ワークロード CIDR 内のルーティング可能な IP スペースを確保します。
+ [インターネットゲートウェイのイングレスルーティング](https://aws.amazon.com/blogs/aws/new-vpc-ingress-routing-simplifying-integration-of-third-party-appliances/) (エッジアソシエーション) は、専用の非ルーティングサブネットの ゲートウェイロードバランサーエンドポイントとともに使用できます。
+ [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) は VPC とオンプレミスネットワークを接続する一元的ハブです。このパターンでは、VPC はトランジットゲートウェイに集中的に接続され、Transit Gateway アタッチメントはルーティングできない専用のサブネットに配置されます。
+ [ゲートウェイロードバランサ―](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html)を使用すると、ファイアウォール、侵入検知および防止システム、ディープパケットインスペクションシステムなどの仮想アプライアンスをデプロイ、スケール、管理できます。ゲートウェイは、すべてのトラフィックの単一の入口と出口の役割を果たします。このパターンでは、ゲートウェイロードバランサーのエンドポイントは、ルーティングできない専用のサブネットで使用できます。
+ [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) は、ステートフルでマネージド型のネットワークファイアウォールならびに侵入検知および防止サービスです。このパターンでは、ゲートウェイロードバランサーのエンドポイントは、ルーティングできない専用のサブネットで使用できます。

**コードリポジトリ**

このパターンのランブックと AWS CloudFormation テンプレートは、GitHub の[ルーティング不可能なセカンダリ](https://github.com/aws-samples/non-routable-secondary-vpc-cidr-patterns/) CIDR パターンリポジトリにあります。サンプルファイルを使用して、環境内に作業ラボをセットアップできます。

## ベストプラクティス
<a name="preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets-best-practices"></a>

**AWS Transit Gateway**
+ 各 Transit Gateway VPC アタッチメントに個別のサブネットを使用します。
+ ルーティング不可能なセカンダリ CIDR 範囲から /28 サブネットを Transit Gateway アタッチメントサブネットに割り当てます。
+ 各トランジットゲートウェイのルートテーブルに、ルーティングできない CIDR 範囲の静的でより具体的なルートをブラックホールとして追加します。

**ゲートウェイロードバランサーとイングレス・ルーティング**
+ イングレスルーティングを使用して、インターネットからのトラフィックをゲートウェイロードバランサーエンドポイントに転送します。
+ 各ゲートウェイロードバランサーエンドポイントに個別のサブネットを使用します。
+ ゲートウェイロードバランサーエンドポイントサブネットに、ルーティング不可能なセカンダリ CIDR 範囲から /28 サブネットを割り当てます。

## エピック
<a name="preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets-epics"></a>

### VPCの作成
<a name="create-vpcs"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| ルーティング不可能な CIDR 範囲を決定します。 | Transit Gateway アタッチメントサブネットと (オプションで) ゲートウェイLoad Balancer または Network Firewall エンドポイントサブネットに使用される、ルーティング不可能なCIDR範囲を決定します。この CIDR 範囲は VPC のセカンダリ CIDR として使用されます。VPC のプライマリ CIDR 範囲またはより大きなネットワークから**ルーティング可能であってはなりません**。 | クラウドアーキテクト | 
| VPC のルーティング可能な CIDR 範囲を決定します。 | VPC に使用されるルーティング可能な CIDR 範囲のセットを決定します。この CIDR 範囲は VPC のプライマリ CIDR として使用されます。 | クラウドアーキテクト | 
| VPCの作成 | VPC を作成し、トランジットゲートウェイにアタッチします。各 VPC には、前の 2 つのステップで決定した範囲に基づいて、ルーティング可能なプライマリ CIDR 範囲とルーティング不可能なセカンダリ CIDR 範囲が必要です。 | クラウドアーキテクト | 

### Transit ゲートウェイ のブラックホールルートの設定
<a name="configure-transit-gateway-blackhole-routes"></a>


| タスク | 説明 | 必要なスキル | 
| --- | --- | --- | 
| より具体的なルーティング不能な CIDR をブラックホールとして作成する。 | 各トランジットゲートウェイのルートテーブルには、ルーティング不可能なCIDR用に作成されたブラックホールルートのセットが必要です。これらは、セカンダリ VPC CIDR からのトラフィックがルーティング不可能なままになり、大規模なネットワークに漏れることがないように設定されています。これらのルートは、VPC のセカンダリ CIDR として設定されているルーティング不可能な CIDR よりも具体的でなければなりません。たとえば、ルーティング不可能なセカンダリ CIDR が 100.64.0.0/26 の場合、トランジットゲートウェイのルートテーブル内のブラックホールルートは 100.64.0.0/27 と 100.64.0.32/27 である必要があります。 | クラウドアーキテクト | 

## 関連リソース
<a name="preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets-resources"></a>
+ [ゲートウェイロードバランサーをデプロイするためのベストプラクティス](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/)
+ [ゲートウェイロードバランサーを使用した分散型検査アーキテクチャ](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/distributed-inspection-architectures-gwlb-ra.pdf?did=wp_card&trk=wp_card)
+ [ネットワーキングイマージョンデー](https://catalog.workshops.aws/networking/en-US/gwlb/lab2-internettovpc) ‒ [インターネットから VPC ファイアウォールラボ](https://catalog.workshops.aws/networking/en-US/gwlb/lab2-internettovpc)
+ [Transit Gateway 設計のベストプラクティス](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html)

## 追加情報
<a name="preserve-routable-ip-space-in-multi-account-vpc-designs-for-non-workload-subnets-additional"></a>

ルーティング不可能なセカンダリ CIDR 範囲は、大量の IP アドレスを必要とする大規模なコンテナデプロイメントを扱う場合にも役立ちます。このパターンをプライベート NAT ゲートウェイで使用すると、ルーティング不可能なサブネットを使用してコンテナデプロイメントをホストできます。詳細については、ブログ記事 [プライベート NAT ソリューションでプライベート IP の枯渇を解決する方法](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/) を参照してください。