翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS Transit Gateway の仕組み
AWS Transit Gateway では、トランジットゲートウェイは、仮想プライベートクラウド (VPCs) とオンプレミスネットワーク間を流れるトラフィックのリージョン仮想ルーターとして機能します。Transit Gateway は、ネットワークトラフィックの量に基づいて伸縮自在にスケーリングされます。Transit Gateway を介したルーティングは、レイヤー 3 で動作します。レイヤー 3 では、送信先 IP アドレスに基づいて、パケットが特定のネクストホップ接続に送信されます。
**Topics**
+ [アーキテクチャ図の例](#architecture-diagram)
+ [リソースアタッチメント](#tgw-attachments-overview)
+ [等コストマルチパスルーティング](#tgw-ecmp)
+ [アベイラビリティーゾーン](#tgw-az-overview)
+ [ルーティング](#tgw-routing-overview)
+ [ネットワーク関数アタッチメント](#nf-attachment-overview)
+ [トランジットゲートウェイシナリオの例](#TGW_Scenarios)
## アーキテクチャ図の例
次の図は、3 つの VPC が添付された Transit Gateway を示しています。これらの VPC のそれぞれのルートテーブルには、ローカルルートと、他の 2 つの VPC を宛先とするトラフィックを Transit Gateway に送信するルートが含まれます。
![\[VPC 接続オプション\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/images/transit-gateway-overview.png)
以下は、前の図に示されているアタッチメントのデフォルト Transit Gateway のルートテーブルの例です。各 VPC の CIDR ブロックがルートテーブルに伝播されます。したがって、各アタッチメントは他の 2 つのアタッチメントにパケットをルーティングできます。
| ルーティング先 | ターゲット | ルートタイプ |
| --- | --- | --- |
| VPC A CIDR | VPC A のアタッチメント | 伝播済み |
| VPC B CIDR | VPC B のアタッチメント | 伝播済み |
| VPC C CIDR | VPC C のアタッチメント | 伝播済み |
## リソースアタッチメント
Transit Gateway アタッチメントは、パケットの送信元と送信先の両方です。次のリソースを Transit Gateway にアタッチできます。
+ 1 つ以上の VPCs AWS Transit Gateway は、VPC サブネット内に Elastic Network Interface をデプロイします。これは、選択したサブネットとの間でトラフィックをルーティングするために Transit Gateway によって使用されます。各アベイラビリティーゾーンには、少なくとも 1 つのサブネットが必要です。これにより、そのゾーンのすべてのサブネットのリソースにトラフィックが到達できるようになります。アタッチメントの作成時に、サブネットが同じゾーン内で有効になっている場合にだけ、特定のアベイラビリティーゾーン内のリソースが Transit Gateway に到達できます。サブネットルートテーブルに Transit Gateway へのルートがある場合、トラフィックが Transit Gateway に転送されるのは、Transit Gateway のアタッチメントが同じアベイラビリティーゾーンのサブネットにある場合のみです。
+ 1 つ以上の VPN 接続
+ 1 つ以上の VPN コンセントレータ
+ 1 つ以上の AWS Direct Connect ゲートウェイ
+ 1 つまたは複数の Transit Gateway Connect アタッチメント
+ 1 つ以上の Transit Gateway ピアリング接続
## 等コストマルチパスルーティング
AWS Transit Gateway は、ほとんどのアタッチメントで等コストマルチパス (ECMP) ルーティングをサポートしています。VPN アタッチメントの場合、Transit Gateway を作成または変更するときに、コンソールを使用して ECMP サポートを有効化または無効化できます。その他すべてのアタッチメントファイルについては、以下の ECMP 制限が適用されます。
+ VPC - CIDR ブロックを重複させることは可能ではないため、VPC は ECMP をサポートしません。例えば、CIDR が 10.1.0.0/16 の VPC と、同じ CIDR を使用する 2 つ目の VPC を Transit Gateway にアタッチしてから、それらの間のトラフィックを負荷分散するようにルーティングをセットアップすることはできません。
+ [**VPN ECMP サポート**] オプションが無効になっている場合、複数のパスで同等のプレフィックスが使用されていると、Transit Gateway は内部メトリクスを使用して優先パスを決定します。VPN アタッチメントに対する ECMP の有効化または無効化の詳細については、「[Transit Gateway の AWS Transit Gateway](tgw-transit-gateways.md)」を参照してください。
+ AWS Transit Gateway Connect - AWS Transit Gateway Connect アタッチメントは ECMP を自動的にサポートします。
+ AWS Direct Connect Gateway - AWS Direct Connect Gateway アタッチメントは、ネットワークプレフィックス、プレフィックスの長さ、AS\$1PATH がまったく同じである場合、複数の Direct Connect Gateway アタッチメント間で ECMP を自動的にサポートします。
+ Transit Gateway ピアリング - Transit Gateway ピアリングは、ダイナミックルーティングをサポートしておらず、2 つの異なるターゲットに対して同じ静的ルートを設定することもできないため、ECMP をサポートしません。
+ VPN コンセントレータ - VPN コンセントレータは ECMP をサポートしていません。
**注記**
BGP マルチパスの AS-Path Relax はサポートされていないため、異なる AS 番号 (ASN) で ECMP を使用することはできません。
異なるアタッチメントタイプ間では ECMP はサポートされません。例えば、VPN と VPC アタッチメント間で ECMP を有効にすることはできません。代わりに、Transit Gateway ルートが評価され、トラフィックは評価されたルートに従ってルーティングされます。詳細については、「[ルートの評価順序](#tgw-route-evaluation-overview)」を参照してください。
単一の Direct Connect ゲートウェイは、複数のトランジット仮想インターフェイス全体で ECMP をサポートします。このため、Direct Connect ゲートウェイは 1 つだけ設定して使用し、ECMP を利用するために複数のゲートウェイを設定して使用しないことをお勧めします。Direct Connect ゲートウェイとパブリック仮想インターフェイスの詳細については、パブリック[仮想インターフェイス AWS から へのアクティブ/アクティブまたはアクティブ/パッシブ Direct Connect 接続を設定する方法](https://repost.aws/knowledge-center/dx-create-dx-connection-from-public-vif)を参照してください。
## アベイラビリティーゾーン
VPC を Transit Gateway に接続するときは、VPC サブネット内のリソースにトラフィックをルーティングするために、1 つ以上のアベイラビリティーゾーンを Transit Gateway で使用できるようにする必要があります。各アベイラビリティーゾーンを有効にするには、サブネットを 1 つだけ指定します。Transit Gateway は、サブネットから 1 つの IP アドレスを使用して、そのサブネット内にネットワークインターフェイスを配置します。サブネットを指定してアベイラビリティーゾーンを有効にすると、指定したサブネットだけでなく、そのアベイラビリティーゾーン内のすべてのサブネットにトラフィックをルーティングできます。ただし、Transit Gateway アタッチメントが存在するアベイラビリティーゾーンにあるリソースのみ、Transit Gateway に到達できます。
送信先アタッチメントが存在しないアベイラビリティーゾーンからトラフィックが発信された場合、 AWS Transit Gateway はそのトラフィックをアタッチメントが存在するランダムなアベイラビリティーゾーンに内部的にルーティングします。このタイプのクロスアベイラビリティーゾーントラフィックには、Transit Gateway の追加料金はかかりません。
高可用性を確保するために、複数のアベイラビリティーゾーンを有効にすることをお勧めします。
**アプライアンスモードサポートの使用**
VPC でステートフルネットワークアプライアンスを設定する予定の場合は、アプライアンスが配置されているその VPC アタッチメントに対してアプライアンスモードサポートを有効にできます。これにより、Transit Gateway は、送信元と送信先の間のトラフィックフローの存続期間中、その VPC アタッチメントに対して同じアベイラビリティーゾーンを使用します。また、そのアベイラビリティーゾーンにサブネットの関連付けがある限り、Transit Gateway は VPC 内の任意のアベイラビリティーゾーンにトラフィックを送信できるようにします。詳細については、「[例: 共有サービス VPC のアプライアンス](#transit-gateway-appliance-scenario)」を参照してください。
## ルーティング
Transit Gateway は、Transit Gateway ルートテーブルを使ってアタッチメント間で IPv4 と IPv6 パケットをルーティングします。これらのルートテーブルを設定して、アタッチされている VPC、VPN 接続、Direct Connect ゲートウェイのルートテーブルからルートを伝播できます。静的ルートを Transit Gateway ルートテーブルに追加することもできます。パケットが 1 つのアタッチメントから送信されると、宛先 IP アドレスと一致するルートを使用して別のアタッチメントにルーティングされます。
Transit Gateway のピアリングアタッチメントでは、静的ルートだけがサポートされます。
**Topics**
+ [ルートテーブル](#tgw-route-tables-overview)
+ [ルートテーブルの関連付け](#tgw-route-table-association-overview)
+ [ルート伝達](#tgw-route-propagation-overview)
+ [ピアリングアタッチメントのルート](#tgw-route-table-peering)
+ [ルートの評価順序](#tgw-route-evaluation-overview)
### ルートテーブル
Transit Gateway ではデフォルトのルートテーブルが自動的に使用されます。デフォルトでは、このルートテーブルはデフォルトの関連付けルートテーブルおよびデフォルトの伝達ルートテーブルです。ルート伝達とルートテーブルの関連付けの両方を無効にすると、 AWS はトランジットゲートウェイのデフォルトルートテーブルを作成しません。ただし、ルート伝達またはルートテーブルの関連付けのいずれかが有効になっている場合、 AWS はデフォルトのルートテーブルを作成します。
Transit Gateway に対して追加のルートテーブルを作成できます。これにより、アタッチメントのサブネットを分離できます。アタッチメントごとに 1 つのルートテーブルに関連付けることができます。アタッチメントでそのルートを 1 つ以上のルートテーブルに伝播できます。
ルートに一致するトラフィックを破棄する Transit Gateway ルートテーブルでは、ブラックホールルートを作成できます。
VPC を Transit Gateway にアタッチするときは、トラフィックが Transit Gateway を通過してルーティングするために、サブネットルートテーブルにルートを追加する必要があります。詳細については、「Amazon VPC ユーザーガイド」の「[Transit Gateway のルーティング](https://docs.aws.amazon.com/vpc/latest/userguide/route-table-options.html#route-tables-tgw)」を参照してください。
### ルートテーブルの関連付け
Transit Gateway アタッチメントを単一のルートテーブルに関連付けることができます。各ルートテーブルは、ゼロから多数のアタッチメントに関連付けられ、パケットを他のアタッチメントに転送できます。
### ルート伝達
各アタッチメントには、1 つ以上の Transit Gateway ルートテーブルにインストールできるルートが付属しています。アタッチメントが Transit Gateway ルートテーブルに伝播されると、これらのルートはルートテーブルにインストールされます。アドバタイズされたルートをフィルタリングすることはできません。
VPC アタッチメントの場合、VPC の CIDR ブロックは Transit Gateway のルートテーブルに伝達されます。
動的ルーティングを VPN アタッチメント、VPN コンセントレータアタッチメント、または Direct Connect ゲートウェイアタッチメントで使用すると、オンプレミスルーターから学習したルートを BGP 経由でトランジットゲートウェイルートテーブルに伝達できます。
VPN アタッチメントまたは VPN コンセントレータアタッチメントで動的ルーティングを使用する場合、VPN アタッチメントまたは VPN コンセントレータアタッチメントに関連付けられたルートテーブル内のルートは、BGP を介してカスタマーゲートウェイにアドバタイズされます。
Connect アタッチメントの場合、Connect アタッチメントに関連付けられたルートテーブル内のルートは、BGP を介して VPC で実行されているサードパーティの仮想アプライアンス (SD-WAN アプライアンスなど) にアドバタイズされます。
Direct Connect ゲートウェイアタッチメントの場合、[許可されたプレフィックスインタラクション](https://docs.aws.amazon.com/directconnect/latest/UserGuide/allowed-to-prefixes.html)は、カスタマーネットワークにアドバタイズされるルートを制御します AWS。
静的ルートと伝達ルートが同じ送信先を持つ場合、静的ルートの優先度が高くなるため、伝達されたルートはルートテーブルに含まれません。静的ルートを削除すると、重複する伝達ルートがルートテーブルに含まれます。
### ピアリングアタッチメントのルート
2 つの Transit Gateway をピアリングし、それらの間でトラフィックをルーティングできます。これを行うには、Transit Gateway にピアリングアタッチメントを作成し、ピアリング接続を行うピア Transit Gateway を指定します。次に、Transit Gateway ルートテーブルに静的ルートを作成し、トラフィックを Transit Gateway ピアリングアタッチメントにルーティングします。ピア Transit Gateway にルーティングされるトラフィックは、ピア Transit Gateway の VPC および VPN アタッチメントにルーティングできます。
詳細については、「[例: ピア接続 Transit Gateway](#transit-gateway-peering-scenario)」を参照してください。
### ルートの評価順序
Transit Gateway のルートは、次の順序で評価されます。
+ 送信先アドレスの最も具体的なルート。
+ 同じ CIDR を持つが、異なるアタッチメントタイプのルートの場合、ルートの優先度は次のとおりです。
+ 静的ルート (例えば、Site-to-Site VPN 静的ルート)
+ プレフィックスリスト参照ルート
+ VPC が伝達したルート
+ Direct Connect ゲートウェイが伝播したルート
+ Transit Gateway Connect が伝播したルート
+ プライベート Direct Connect 伝播ルート経由の Site-to-Site VPN
+ Site-to-Site VPN 伝播ルート
+ Site-to-Site VPN-Concentrator 伝達ルート
+ 伝播ルートをピアリングする Transit Gateway (クラウド WAN)
一部のアタッチメントは、BGP 経由でルートアドバタイズをサポートしています。同じ CIDR を持つルートと、同じアタッチメントタイプのルートの場合、ルートの優先度は BGP 属性によって制御されます。
+ AS パスの長さがより短い
+ MED 値がより低い
+ アタッチメントがサポートしている場合は、iBGP ルートよりも eBGP が推奨されます
**重要**
AWS は、上記の同じ CIDR、アタッチメントタイプ、および BGP 属性を持つ BGP ルートの一貫したルート優先順位付け順序を保証できません。
MED を使用しない Transit Gateway にアドバタイズされたルートの場合、 AWS Transit Gateway は次のデフォルト値を割り当てます。
Direct Connect アタッチメントでアドバタイズされるインバウンドルートの場合は 0。
VPN および Connect アタッチメントでアドバタイズされるインバウンドルートの場合は 100。
AWS Transit Gateway には優先ルートのみが表示されます。バックアップルートは、以前にアクティブなルートがアドバタイズされなくなった場合にのみトランジットゲートウェイルートテーブルに表示されます。たとえば、Direct Connect ゲートウェイと Site-to-Site VPN を介して同じルートをアドバタイズする場合などです。 AWS Transit Gateway は、優先ルートである Direct Connect ゲートウェイルートから受信したルートのみを表示します。バックアップルートであるSite-to-Site VPN は、Direct Connect ゲートウェイがアドバタイズされなくなった場合にだけ表示されます。
#### VPC と Transit Gateway のルートテーブルの違い
ルートテーブルの評価は、VPC ルートテーブルと Transit Gateway ルートテーブルのどちらを使用しているかによって異なります。
VPC のルートテーブルの例を次に示します。VPC ローカルルートが最も優先順位が高く、その後に最も具体的なルートが続きます。静的ルートと伝達されたルートの送信先が同じ場合は、静的ルートの方が優先度が高くなります。
| 送信先 | ターゲット | 優先度 |
| --- | --- | --- |
| 10.0.0.0/16 | ローカル | 1 |
| 192.168.0.0/16 | pcx-12345 | 2 |
| 172.31.0.0/16 | vgw-12345 (静的) またはtgw-12345 (静的) | 2 |
| 172.31.0.0/16 | vgw-12345 (伝播済み) | 3 |
| 0.0.0.0/0 | igw-12345 | 4 |
Transit Gateway のルートテーブルの例を次に示します。VPN アタッチメントよりも Direct Connect ゲートウェイアタッチメントを好ましいと考える場合は、BGP VPN 接続を使用して Transit Gateway ルートテーブルにルートを伝達します。
| 送信先 | アタッチメント (ターゲット) | リソースタイプ | ルートタイプ | 優先度 |
| --- | --- | --- | --- | --- |
| 10.0.0.0/16 | tgw-attach-123 \$1 vpc-1234 | VPC | 静的または伝播済み | 1 |
| 192.168.0.0/16 | tgw-attach-789 \$1 vpn-5678 | VPN | 静的 | 2 |
| 172.31.0.0/16 | tgw-attach-456 \$1 dxgw\$1id | Direct Connect ゲートウェイ | 伝播済み | 3 |
| 172.31.0.0/16 | tgw-attach-789 \$1 tgw-connect-peer-123 | 接続 | 伝播済み | 4 |
| 172.31.0.0/16 | tgw-attach-789 \$1 vpn-5678 | VPN | 伝播済み | 5 |
## ネットワーク関数アタッチメント
ネットワーク関数アタッチメントは、 AWS Network Firewall アタッチメントなどのネットワークセキュリティ関数をトランジットゲートウェイに直接接続するリソースです。これにより、検査 VPC を手動で作成および管理する必要がなくなります。
ネットワーク関数アタッチメントの場合:
+ AWS は基盤となるインフラストラクチャを自動的に作成および管理します
+ Transit Gateway を通過するトラフィックを検査できます
+ セキュリティポリシーはネットワーク全体に一貫して適用されます
+ シンプルルーティングルールを使用して、ファイアウォール経由でトラフィックをルーティングできます
+ アタッチメントは複数のアベイラビリティーゾーンで動作し、高可用性を実現します
この統合により、複雑なルーティング設定を作成したり、別々の VPC を介して個別のエンドポイントを管理したりすることなく、ファイアウォールを Transit Gateway に直接接続できるようになり、ネットワークセキュリティが簡素化されます。
### AWS Network Firewall 統合
AWS Network Firewall 統合により、サービスマネージドバッファ VPC 内のアベイラビリティーゾーンごとに 1 つずつ、Gateway Load Balancer Endpoints のグループの形式でファイアウォールを接続できます。Network Firewall アタッチメントは、アプライアンスモードが自動的に有効化された状態で作成されます。これにより、検査 VPC を明示的に管理する必要がなくなります。
Network Firewall 統合を使用すると、Network Firewall デプロイの検査 VPC を作成および管理する必要がなくなります。ファイアウォールの作成時に VPC とサブネットを選択する代わりに、Transit Gateway を直接選択すると、 AWS は背後で必要なすべてのリソースを自動的にプロビジョニングおよび管理します。個々のファイアウォールエンドポイントではなく、新しい Transit Gateway ネットワーク関数アタッチメントが表示されます。
クロスアカウントシナリオの場合、Transit Gateway は Transit Gateway 所有者から Network Firewall 所有者アカウントに RAM 共有でき、どちらのアカウントでもファイアウォールアタッチメントを管理できます。ファイアウォールとアタッチメントの準備が整い次第、Transit Gateway ルートテーブルを変更して、検査のためにトラフィックをアタッチメントに送信できます。
**注記**
Transit Gateway は、Network Firewall アタッチメントの静的ルーティングのみをサポートします。
サードパーティーのファイアウォールはサポートされていません。
ファイアウォールとアタッチメントの詳細については、「[Transit Gateway ネットワーク関数のアタッチメント](tgw-nf-fw.md)」を参照してください。
## トランジットゲートウェイシナリオの例
トランジットゲートウェイの一般的ユースケースは以下のとおりです。お客様のトランジットゲートウェイはこれらのユースケースに限定されません。
**Topics**
### 例: 集中型ルーター
すべての VPC、 AWS Direct Connect、および Site-to-Site VPN 接続を接続する集中型ルーターとしてトランジットゲートウェイを設定することができます。このシナリオでは、アタッチメントはすべて、トランジットゲートウェイのデフォルトルートテーブルに関連付けられ、トランジットゲートウェイのデフォルトルートテーブルに伝播されます。そのため、アタッチメントはすべて、単純なレイヤー 3 IP ルーターとしてトランジットゲートウェイを提供しながら、パケットを相互にルーティングできます。
**Topics**
+ [概要:](#transit-gateway-centralized-router-overview)
+ [リソース](#transit-gateway-centralized-router-resources)
+ [ルーティング](#transit-gateway-centralized-router-routing)
#### 概要:
次の図は、このシナリオの設定に重要なコンポーネントを示しています。このシナリオでは、トランジットゲートウェイへの 3 つの VPC のアタッチメントと 1 つの Site-to-Site VPN アタッチメントがあります。VPC A、VPC B、および VPC C のサブネットから、別の VPC のサブネットまたは VPN 接続を宛先とするパケットは、最初にトランジットゲートウェイを介してルーティングされます。
![\[3 つの VPC アタッチメントと 1 つの VPN アタッチメントがあるトランジットゲートウェイ。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/images/transit-gateway-three-vpcs.png)
#### リソース
このシナリオでは、次のリソースを作成します。
+ 3 つの VPC。詳細については、「Amazon VPC ユーザーガイド」の「[VPC を作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)」を参照してください。
+ Transit Gateway。詳細については、「[Transit Gateway で AWS Transit Gateway を作成する](create-tgw.md)」を参照してください。
+ トランジットゲートウェイ上の 3 つの VPC アタッチメント。詳細については、「[AWS Transit Gateway で VPC アタッチメントの作成](create-vpc-attachment.md)」を参照してください。
+ トランジットゲートウェイ上の Site-to-Site VPN のアタッチメント。各 VPC の CIDR ブロックがトランジットゲートウェイルートテーブルに伝播されます。VPN 接続が起動すると、BGP セッションが確立され、Site-to-Site VPN CIDR がトランジットゲートウェイルートテーブルに伝播され、VPC CIDR がカスタマーゲートウェイの BGP テーブルに追加されます。詳細については、「[AWS Transit Gateway で VPN への Transit Gateway アタッチメントを作成する](create-vpn-attachment.md)」を参照してください。
「AWS Site-to-Site VPN ユーザーガイド」で、「[カスタマーゲートウェイデバイスの要件](https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html#CGRequirements)」を必ず確認してください。
#### ルーティング
各 VPC にはルートテーブルがあり、トランジットゲートウェイルートテーブルがあります。
##### VPC ルートテーブル
各 VPC には、2 つのエントリを持つルートテーブルがあります。最初のエントリは、VPC のローカル IPv4 ルーティングのデフォルトエントリです。このエントリによって、この VPC 内のインスタンスが相互に通信できるようになります。2 番目のエントリは、他のすべての IPv4 サブネットトラフィックをトランジットゲートウェイにルーティングします。次の表に VPC A のルートを示します。
| 送信先 | ターゲット |
| --- | --- |
| 10.1.0.0/16 | ローカル |
| 0.0.0.0/0 | *tgw-id* |
##### 転送ゲートウェイルートテーブル
以下は、前の図に示されているアタッチメントのデフォルトルートテーブルの例で、ルート伝播が有効になっています。
| 送信先 | ターゲット | ルートタイプ |
| --- | --- | --- |
| 10.1.0.0/16 | *VPC A のアタッチメント* | 伝播済み |
| 10.2.0.0/16 | *VPC B のアタッチメント* | 伝播済み |
| 10.3.0.0/16 | *VPC C のアタッチメント* | 伝播済み |
| 10.99.99.0/24 | VPN 接続のアタッチメント | 伝播済み |
##### カスタマーゲートウェイの BGP テーブル
カスタマーゲートウェイの BGP テーブルには、次の VPC CIDR が含まれています。
+ 10.1.0.0/16
+ 10.2.0.0/16
+ 10.3.0.0/16
### 例: 隔離された VPC
複数の独立したルーターとしてトランジットゲートウェイを設定することができます。これは複数のトランジットゲートウェイを使用するのと似ていますが、ルートとアタッチメントが変わる可能性がある場合に、より高い柔軟性を提供します。このシナリオでは、独立した各ルーターに単一のルートテーブルがあります。独立したルーターに関連付けられているすべてのアタッチメントは、伝播されてそのルートテーブルに関連付けられます。1 つの独立したルーターに関連付けられているアタッチメントは、相互にパケットをルーティングできますが、別の独立したルーターのアタッチメントにパケットをルーティングしたり、アタッチメントからパケットを受信したりすることはできません。
**Topics**
+ [概要:](#transit-gateway-isolated-overview)
+ [リソース](#transit-gateway-isolated-resources)
+ [ルーティング](#transit-gateway-isolated-routes)
#### 概要:
次の図は、このシナリオの設定に重要なコンポーネントを示しています。VPC A、VPC B、および VPC C からのパケットは、トランジットゲートウェイにルーティングされます。インターネットを送信先とする VPC A、VPC B、および VPC C のサブネットからのパケットは、最初にトランジットゲートウェイを介してルーティングされ、次に Site-to-Site VPN 接続にルーティングされます (送信先がそのネットワーク内にある場合)。送信先が別の VPC のサブネットである VPC からのパケット (たとえば 10.1.0.0 から 10.2.0.0) はトランジットゲートウェイを経由してルーティングされますが、トランジットゲートウェイルートテーブルにはそれらのルートがないためブロックされます。
![\[3 つの VPC アタッチメントと 1 つの VPN アタッチメントがあるトランジットゲートウェイ。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/images/transit-gateway-isolated.png)
#### リソース
このシナリオでは、次のリソースを作成します。
+ 3 つの VPC。詳細については、「Amazon VPC ユーザーガイド」の「[VPC を作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)」を参照してください。
+ Transit Gateway。詳細については、「[Transit Gateway で AWS Transit Gateway を作成する](create-tgw.md)」を参照してください。
+ 3 つの VPC に使用するトランジットゲートウェイの 3 つのアタッチメント。詳細については、「[AWS Transit Gateway で VPC アタッチメントの作成](create-vpc-attachment.md)」を参照してください。
+ Transit Gateway 上の Site-to-Site VPN のアタッチメント。詳細については、「[AWS Transit Gateway で VPN への Transit Gateway アタッチメントを作成する](create-vpn-attachment.md)」(VPN への Transit Gateway アタッチメントの作成) を参照してください。「AWS Site-to-Site VPN ユーザーガイド」で、「[カスタマーゲートウェイデバイスの要件](https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html#CGRequirements)」を必ず確認してください。
VPN 接続が起動すると、BGP セッションが確立され、VPN CIDR がトランジットゲートウェイルートテーブルに伝播され、VPC CIDR がカスタマーゲートウェイの BGP テーブルに追加されます。
#### ルーティング
各 VPC にはルートテーブルがあり、トランジットゲートウェイには VPC 用と VPN 接続用の 2 つのルートテーブルがあります。
##### VPC A、VPC B、および VPC C ルートテーブル
各 VPC には、2 つのエントリを持つルートテーブルがあります。最初のエントリは、VPC のローカル IPv4 ルーティングのデフォルトエントリです。このエントリにより、この VPC 内のインスタンスが相互に通信できるようになります。2 番目のエントリは、他のすべての IPv4 サブネットトラフィックをトランジットゲートウェイにルーティングします。次の表に VPC A のルートを示します。
| 送信先 | ターゲット |
| --- | --- |
| 10.1.0.0/16 | ローカル |
| 0.0.0.0/0 | *tgw-id* |
##### トランジットゲートウェイルートテーブル
このシナリオでは、VPC に 1 つのルートテーブルを使用し、VPN 接続に 1 つのルートテーブルを使用します。
VPC アタッチメントは次のルートテーブルに関連付けられます。このテーブルには、VPN アタッチメントの伝播されるルートがあります。
| 送信先 | ターゲット | ルートタイプ |
| --- | --- | --- |
| 10.99.99.0/24 | VPN 接続のアタッチメント | 伝播済み |
VPN アタッチメントは次のルートテーブルに関連付けられます。このテーブルには、各 VPC アタッチメントの伝播されるルートがあります。
| 送信先 | ターゲット | ルートタイプ |
| --- | --- | --- |
| 10.1.0.0/16 | *VPC A のアタッチメント* | 伝播済み |
| 10.2.0.0/16 | *VPC B のアタッチメント* | 伝播済み |
| 10.3.0.0/16 | *VPC C のアタッチメント* | 伝播済み |
トランジットゲートウェイルートテーブルでのルート伝播の詳細については、「[AWS Transit Gateway で Transit Gateway ルートテーブルへのルート伝達を有効にする](enable-tgw-route-propagation.md)」を参照してください。
##### カスタマーゲートウェイの BGP テーブル
カスタマーゲートウェイの BGP テーブルには、次の VPC CIDR が含まれています。
+ 10.1.0.0/16
+ 10.2.0.0/16
+ 10.3.0.0/16
### 例: 共有サービスによる分離された VPC
共有サービスを使用する複数の分離されたルーターとしてトランジットゲートウェイを設定できます。これは複数のトランジットゲートウェイを使用するのと似ていますが、ルートとアタッチメントが変わる可能性がある場合に、より高い柔軟性を提供します。このシナリオでは、独立した各ルーターに単一のルートテーブルがあります。独立したルーターに関連付けられているすべてのアタッチメントは、伝播されてそのルートテーブルに関連付けられます。1 つの独立したルーターに関連付けられているアタッチメントは、相互にパケットをルーティングできますが、別の独立したルーターのアタッチメントにパケットをルーティングしたり、アタッチメントからパケットを受信したりすることはできません。アタッチメントは、共有サービスとの間でパケットを送受信することができます。このシナリオは、分離する必要があるが、本番システムなどの共有サービスを使用する必要があるグループがある場合に使用できます。
**Topics**
+ [概要:](#Ttransit-gateway-isolated-shared-overview)
+ [リソース](#transit-gateway-isolated-shared-resources)
+ [ルーティング](#transit-gateway-isolated-shared-routes)
#### 概要:
次の図は、このシナリオの設定に重要なコンポーネントを示しています。インターネットを送信先とする VPC A、VPC B、VPC C のサブネットからのパケットは、最初に Transit Gateway を介してルーティングされ、次に Site-to-Site VPN のカスタマーゲートウェイにルーティングされます。VPC A、VPC B、または VPC C のサブネットを送信先とする VPC A、VPC B、または VPC C のサブネットからのパケットは、Transit Gateway を介してルーティングされますが、Transit Gateway ルートテーブルにはそれらのルートがないためブロックされます。トランジットゲートウェイを経由した VPC D への送信先ルートとして VPC D を持つ VPC A、VPC B、および VPC C からのパケット。
![\[4 つの VPC アタッチメントと 1 つの VPN アタッチメントがあるトランジットゲートウェイ。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/images/transit-gateway-isolated_shared.png)
#### リソース
このシナリオでは、次のリソースを作成します。
+ 4 つの VPC。詳細については、「Amazon VPC ユーザーガイド」の「[VPC を作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)」を参照してください。
+ トランジットゲートウェイ。詳細については、「[トランジットゲートウェイを作成する](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html)」を参照してください。
+ Transit Gateway 上の 4 つのアタッチメント (VPC ごとに 1 つ)。詳細については、「[AWS Transit Gateway で VPC アタッチメントの作成](create-vpc-attachment.md)」(VPC への Transit Gateway アタッチメントの作成) を参照してください。
+ Transit Gateway 上の Site-to-Site VPN のアタッチメント。詳細については、「[AWS Transit Gateway で VPN への Transit Gateway アタッチメントを作成する](create-vpn-attachment.md)」(VPN への Transit Gateway アタッチメントの作成) を参照してください。
「AWS Site-to-Site VPN ユーザーガイド」で、「[カスタマーゲートウェイデバイスの要件](https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html#CGRequirements)」を必ず確認してください。
VPN 接続が起動すると、BGP セッションが確立され、VPN CIDR がトランジットゲートウェイルートテーブルに伝播され、VPC CIDR がカスタマーゲートウェイの BGP テーブルに追加されます。
+ 隔離された各 VPC は、隔離されたルートテーブルに関連付けられ、共有ルートテーブルに伝達されます。
+ 共有された各 VPC は、共有されたルートテーブルに関連付けられ、両方のルートテーブルに伝達されます。
#### ルーティング
各 VPC にはルートテーブルがあり、トランジットゲートウェイには 2 つのルートテーブルがあります — 1 つは VPC 用、もう 1 つは VPN 接続および共有サービス VPC 用です。
##### VPC A、VPC B、VPC C、および VPC D ルートテーブル
各 VPC には、2 つのエントリを持つルートテーブルがあります。最初のエントリは、VPC のローカルルーティングのデフォルトエントリです。このエントリによって、この VPC 内のインスタンスが相互に通信できるようになります。2 番目のエントリは、他のすべての IPv4 サブネットトラフィックをTransit Gateway にルーティングします。
| 送信先 | ターゲット |
| --- | --- |
| 10.1.0.0/16 | ローカル |
| 0.0.0.0/0 | Transit Gateway ID |
##### トランジットゲートウェイルートテーブル
このシナリオでは、VPC に 1 つのルートテーブルを使用し、VPN 接続に 1 つのルートテーブルを使用します。
VPC A、B、および C のアタッチメントは次のルートテーブルに関連付けられます。このテーブルには、VPN アタッチメントの伝播されたルートと、VPC D のアタッチメントの伝播されたルートがあります。
| 送信先 | ターゲット | ルートタイプ |
| --- | --- | --- |
| 10.99.99.0/24 | VPN 接続のアタッチメント | 伝播済み |
| 10.4.0.0/16 | VPC D のアタッチメント | 伝播済み |
VPN アタッチメントおよび共有サービス VPC (VPC D) アタッチメントは、次のルートテーブルに関連付けられています。このテーブルには、各 VPC アタッチメントを指すエントリがあります。これにより、VPN 接続および共有サービス VPC から VPC への通信が可能になります。
| 送信先 | ターゲット | ルートタイプ |
| --- | --- | --- |
| 10.1.0.0/16 | VPC A のアタッチメント | 伝播済み |
| 10.2.0.0/16 | VPC B のアタッチメント | 伝播済み |
| 10.3.0.0/16 | VPC C のアタッチメント | 伝播済み |
詳細については、「[AWS Transit Gateway で Transit Gateway ルートテーブルへのルート伝達を有効にする](enable-tgw-route-propagation.md)」(Transit Gateway ルートテーブルへのルートの伝達) を参照してください。
##### カスタマーゲートウェイの BGP テーブル
カスタマーゲートウェイの BGP テーブルには、4 つの VPC すべての CIDR が含まれています。
### 例: ピア接続 Transit Gateway
異なるリージョンで Transit Gateway 間に Transit Gateway ピアリング接続を作成できます。その後、各 Transit Gateway のアタッチメント間でトラフィックをルーティングできます。このシナリオでは、VPC および VPN アタッチメントは、Transit Gateway のデフォルトルートテーブルに関連付けられ、Transit Gateway のデフォルトルートテーブルに伝播されます。各 Transit Gateway のルートテーブルには、ゲートウェイのピアリングアタッチメントを指す静的ルートがあります。
**Topics**
+ [概要:](#transit-gateway-peering-overview)
+ [リソース](#transit-gateway-peering-resources)
+ [ルーティング](#transit-gateway-peering-routing)
#### 概要:
次の図は、このシナリオの設定に重要なコンポーネントを示しています。Transit Gateway 1 には 2 つの VPC アタッチメントがあり、Transit Gateway 2 には 1 つの Site-to-Site VPN アタッチメントがあります。送信先としてインターネット接続を持つ VPC A および VPC B のサブネットからのパケットは、最初にTransit Gateway 1 を介してルーティングされ、次にTransit Gateway 2 を介して VPN 接続にルーティングされます。
![\[ピアリングされた 2 つのトランジットゲートウェイ。1 つには VPC アタッチメントを2 つ、もう 1 つには VPN アタッチメントを1 つ持ちます。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/images/transit-gateway-peering.png)
#### リソース
このシナリオでは、次のリソースを作成します。
+ 2 つの VPC。詳細については、「Amazon VPC ユーザーガイド」の「[VPC を作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)」を参照してください。
+ 2 つの Transit Gateway。同じリージョン内に存在することも、異なるリージョン内に存在することもできます。詳細については、「[Transit Gateway で AWS Transit Gateway を作成する](create-tgw.md)」を参照してください。
+ 最初のTransit Gateway の 2 つの VPC アタッチメント。詳細については、「[AWS Transit Gateway で VPC アタッチメントの作成](create-vpc-attachment.md)」を参照してください。
+ 2 つ目の Transit Gateway 上の Site-to-Site VPN のアタッチメント。詳細については、「[AWS Transit Gateway で VPN への Transit Gateway アタッチメントを作成する](create-vpn-attachment.md)」を参照してください。「AWS Site-to-Site VPN ユーザーガイド」で、「[カスタマーゲートウェイデバイスの要件](https://docs.aws.amazon.com/vpn/latest/s2svpn/your-cgw.html#CGRequirements)」を必ず確認してください。
+ 2 つのTransit Gateway 間のTransit Gateway ピアリングアタッチメント。詳細については、「[AWS Transit Gateway の Transit Gateway ピアリングアタッチメント](tgw-peering.md)」を参照してください。
VPC アタッチメントを作成すると、各 VPC の CIDR がTransit Gateway 1 のルートテーブルに伝播されます。VPN 接続がオンになると、次のアクションが発生します。
+ BGP セッションが確立される
+ Site-to-Site VPN CIDR がTransit Gateway 2 のルートテーブルに伝播される
+ VPC CIDR がカスタマーゲートウェイ BGP テーブルに追加される
#### ルーティング
各 VPC にはルートテーブルがあり、各Transit Gateway にルートテーブルがあります。
##### VPC A および VPC B ルートテーブル
各 VPC には、2 つのエントリを持つルートテーブルがあります。最初のエントリは、VPC のローカル IPv4 ルーティングのデフォルトエントリです。このデフォルトエントリにより、この VPC 内のリソースが相互に通信できるようになります。2 番目のエントリは、他のすべての IPv4 サブネットトラフィックをTransit Gateway にルーティングします。次の表に VPC A のルートを示します。
| 送信先 | ターゲット |
| --- | --- |
| 10.0.0.0/16 | ローカル |
| 0.0.0.0/0 | *tgw-1-id* |
##### Transit Gateway ルートテーブル
次に、ルート伝播が有効になっているTransit Gateway 1 のデフォルトルートテーブルの例を示します。
| 送信先 | ターゲット | ルートタイプ |
| --- | --- | --- |
| 10.0.0.0/16 | *VPC A のアタッチメント ID* | 伝播済み |
| 10.2.0.0/16 | *VPC B のアタッチメント ID* | 伝播済み |
| 0.0.0.0/0 | ピア接続のアタッチメント ID | 静的 |
次に、ルート伝播が有効になっているTransit Gateway 2 のデフォルトルートテーブルの例を示します。
| 送信先 | ターゲット | ルートタイプ |
| --- | --- | --- |
| 172.31.0.0/24 | VPN 接続のアタッチメント ID | 伝播済み |
| 10.0.0.0/16 | *ピア接続のアタッチメント ID * | static |
| 10.2.0.0/16 | ピア接続のアタッチメント ID | static |
##### カスタマーゲートウェイの BGP テーブル
カスタマーゲートウェイの BGP テーブルには、次の VPC CIDR が含まれています。
+ 10.0.0.0/16
+ 10.2.0.0/16
### 例: インターネットへの一元的な発信ルーティング
インターネットゲートウェイがない VPC からのアウトバウンドインターネットトラフィックを、NAT ゲートウェイとインターネットゲートウェイを含む VPC にルーティングするように、トランジットゲートウェイを設定できます。
**Topics**
+ [概要:](#transit-gateway-nat-igw-overview)
+ [リソース](#transit-gateway-nat-igw-resources)
+ [ルーティング](#transit-gateway-nat-igw-routing)
#### 概要:
次の図は、このシナリオの設定に重要なコンポーネントを示しています。VPC A と VPC B にインターネットアクセス (アウトバウンドのみ) が必要なアプリケーションがあります。パブリック NAT ゲートウェイとインターネットゲートウェイ、VPC アタッチメント用のプライベートサブネットを使用して VPC C を設定します。すべての VPC をトランジットゲートウェイに接続します。VPC A と VPC B からのアウトバウンドインターネットトラフィックが VPC C へのトランジットゲートウェイを通過するようにルーティングを設定します。VPC C の NAT ゲートウェイは、トラフィックをインターネットゲートウェイにルーティングします。
![\[3 つの VPC アタッチメントがを持つトランジットゲートウェイ。\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/images/tgw-centralized-nat-igw.png)
#### リソース
このシナリオでは、次のリソースを作成します。
+ 同一でもなく重複もしていない IP アドレス範囲を持つ 3 つの VPC。詳細については、*Amazon VPC ユーザーガイド*の「[VPC を作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)」を参照してください。
+ VPC A と VPC B には、それぞれ EC2 インスタンスを持つプライベートサブネットがあります。
+ VPC C には次のものがあります。
+ VPC にアタッチされたインターネットゲートウェイ。詳細については、「Amazon VPC ユーザーガイド」の「[インターネットゲートウェイの作成とアタッチ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway)」を参照してください。
+ NAT ゲートウェイを持つパブリックサブネット。詳細については、「Amazon VPC ユーザーガイド」の「[NAT ゲートウェイの基本](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-creating)」を参照してください。
+ Transit Gateway アタッチメントのサブネット。プライベートサブネットは、パブリックサブネットと同じアベイラビリティーゾーンに設置する必要があります。
+ 1 つのトランジットゲートウェイ。詳細については、「[Transit Gateway で AWS Transit Gateway を作成する](create-tgw.md)」を参照してください。
+ トランジットゲートウェイ上の 3 つの VPC アタッチメント。各 VPC の CIDR ブロックがトランジットゲートウェイルートテーブルに伝播されます。詳細については、「[AWS Transit Gateway で VPC アタッチメントの作成](create-vpc-attachment.md)」を参照してください。VPC C には、プライベートサブネットを使用してアタッチメントを作成する必要があります。パブリックサブネットを使用してアタッチメントを作成すると、インスタンストラフィックはインターネットゲートウェイにルーティングされるものの、インターネットゲートウェイはそのトラフィックをドロップします。これは、インスタンスにパブリック IP アドレスがないためです プライベートサブネットにアタッチメントを配置することで、トラフィックが NAT ゲートウェイにルーティングされます。NAT ゲートウェイは、Elastic IP アドレスを送信元 IP アドレスとして使用して、トラフィックをインターネットゲートウェイに送信します
#### ルーティング
各 VPC には複数のルートテーブルがあり、トランジットゲートウェイには 1 つのルートテーブルがあります。
**Topics**
+ [VPC A](#transit-gateway-nat-igw-vpc-a-route-table)
+ [VPC B](#transit-gateway-nat-igw-vpc-b-route-table)
+ [VPC C](#transit-gateway-nat-igw-nat-vpc-c-route-tables)
+ [トランジットゲートウェイ](#transit-gateway-nat-igw-tgw-route-table)
##### VPC A のルートテーブル
ルートテーブルの例を次に示します。最初のエントリにより、VPC 内のインスタンスが相互に通信できるようになります。2 番目のエントリは、他のすべての IPv4 サブネットトラフィックをトランジットゲートウェイにルーティングします。
| 送信先 | ターゲット |
| --- | --- |
| *VPC A CIDR* | ローカル |
| 0.0.0.0/0 | *transit-gateway-id* |
##### VPC B のルートテーブル
ルートテーブルの例を次に示します。最初のエントリにより、VPC 内のインスタンスが相互に通信できるようになります。2 番目のエントリは、他のすべての IPv4 サブネットトラフィックをトランジットゲートウェイにルーティングします。
| 送信先 | ターゲット |
| --- | --- |
| *VPC B CIDR* | ローカル |
| 0.0.0.0/0 | *transit-gateway-id* |
##### VPC C のルートテーブル
インターネットゲートウェイにルートを追加することにより、NAT ゲートウェイを使用して、サブネットをパブリックサブネットとして構成します。もう一方のサブネットはプライベートサブネットのままにします。
パブリックサブネットのルートテーブルの例を次に示します。最初のエントリにより、VPC 内のインスタンスが相互に通信できるようになります。2 番目と 3 番目のエントリは、VPC A と VPC B のトラフィックをトランジットゲートウェイにルーティングします。最後のエントリは、他のすべての IPv4 サブネットトラフィックをインターネットゲートウェイにルーティングします。
| 送信先 | ターゲット |
| --- | --- |
| VPC C CIDR | ローカル |
| VPC A CIDR | transit-gateway-id |
| VPC B CIDR | transit-gateway-id |
| 0.0.0.0/0 | internet-gateway-id |
プライベートサブネットのルートテーブルの例を次に示します。最初のエントリにより、VPC 内のインスタンスが相互に通信できるようになります。2 番目のエントリは、他のすべての IPv4 サブネットトラフィックを NAT ゲートウェイにルーティングします。
| 送信先 | ターゲット |
| --- | --- |
| VPC C CIDR | ローカル |
| 0.0.0.0/0 | nat-gateway-id |
##### 転送ゲートウェイルートテーブル
トランジットゲートウェイのルートテーブルの例を次に示します。各 VPC の CIDR ブロックがトランジットゲートウェイルートテーブルに伝播されます。静的ルートは、アウトバウンドインターネットトラフィックを VPC C に送信します。オプションとして、VPC CIDR ごとにブラックホールルートを追加することで、VPC 間の通信を防止することもできます。
| CIDR | 添付ファイル | ルートタイプ |
| --- | --- | --- |
| *VPC A CIDR* | *VPC A のアタッチメント* | 伝播済み |
| *VPC B CIDR* | *VPC B のアタッチメント* | 伝播済み |
| *VPC C CIDR* | *VPC C のアタッチメント* | 伝播済み |
| 0.0.0.0/0 | *VPC C のアタッチメント* | static |
### 例: 共有サービス VPC のアプライアンス
共有サービス VPC でアプライアンス (セキュリティアプライアンスなど) を設定できます。トランジットゲートウェイアタッチメント間でルーティングされるすべてのトラフィックは、まず、共有サービス VPC のアプライアンスによって検査されます。アプライアンスモードが有効な場合、トランジットゲートウェイは、フローハッシュアルゴリズムを使用して、アプライアンス VPC 内の 1 つのネットワークインターフェイスを選択し、フローの有効期間中トラフィックを送信します。トランジットゲートウェイは、リターントラフィックに同じネットワークインターフェイスを使用します。これにより、双方向トラフィックは対称的にルーティングされます。つまり、フローの有効期間中、VPC アタッチメント内の同じアベイラビリティーゾーンを経由してルーティングされます。アーキテクチャ内に複数のトランジットゲートウェイがある場合、各トランジットゲートウェイは独自のセッションアフィニティを維持し、各トランジットゲートウェイは異なるネットワークインターフェイスを選択できます。
フローの維持を保証するには、1 つのトランジットゲートウェイをアプライアンス VPC に接続する必要があります。複数のトランジットゲートウェイを 1 つのアプライアンス VPC に接続しても、これらのトランジットゲートウェイはフロー状態情報を相互に共有しないので、フローの維持は保証されません。
**重要**
アプライアンスモードのトラフィックは、送信元と送信先のトラフィックが同じ Transit Gateway アタッチメントから集中型 VPC (インスペクション VPC) に到達する限り、正しくルーティングされます。送信元と送信先が 2 つの異なる Transit Gateway アタッチメントにある場合、トラフィックが低下する可能性があります。中央 VPC がインターネットゲートウェイなどの別のゲートウェイからトラフィックを受信し、検査後にそのトラフィックを Transit Gateway アタッチメントに送信すると、トラフィックが低下する可能性があります。
既存のアタッチメントでアプライアンスモードを有効にすると、アタッチメントがアベイラビリティーゾーンを通過する可能性があるため、そのアタッチメントの現在のルートに影響する可能性があります。アプライアンスモードが有効になっていない場合、トラフィックは発信元のアベイラビリティーゾーンに保持されます。
**Topics**
+ [概要:](#transit-gateway-appliance-overview)
+ [ステートフルアプライアンスおよびアプライアンスモード](#transit-gateway-appliance-support)
+ [ルーティング](#transit-gateway-appliance-routing)
#### 概要:
次の図は、このシナリオの設定に重要なコンポーネントを示しています。トランジットゲートウェイには、3 つの VPC アタッチメントがあります。VPC C は共有サービス VPC です。VPC A と VPC B 間のトラフィックはトランジットゲートウェイにルーティングされ、その後、最終的な宛先にルーティングされる前に、検査のために VPC C のセキュリティアプライアンスにルーティングされます。アプライアンスはステートフルアプライアンスであるため、リクエストトラフィックとレスポンストラフィックの両方が検査されます。高可用性を実現するために、VPC C の各アベイラビリティーゾーンにアプライアンスがあります。
![\[共有サービス VPC のアプライアンス\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/images/transit-gateway-appliance.png)
このシナリオでは、次のリソースを作成します。
+ 3 つの VPC。詳細については、「Amazon VPC ユーザーガイド」の「[VPC を作成する](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html)」を参照してください。
+ Transit Gateway。詳細については、「[Transit Gateway で AWS Transit Gateway を作成する](create-tgw.md)」を参照してください。
+ 3 つの VPC アタッチメント、各 VPC に 1 つずつ。詳細については、「[AWS Transit Gateway で VPC アタッチメントの作成](create-vpc-attachment.md)」を参照してください。
VPC アタッチメントごとに、各アベイラビリティーゾーンでサブネットを指定します。共有サービス VPC の場合、これらは、トラフィックがトランジットゲートウェイから VPC にルーティングされるサブネットです。前の例では、サブネット A と C です。
VPC C の VPC アタッチメントの場合、アプライアンスモードのサポートを有効にして、レスポンストラフィックがソーストラフィックと同じ VPC C のアベイラビリティーゾーンにルーティングされるようにします。
Amazon VPC コンソールはアプライアンスモードをサポートしていません。Amazon VPC API、 AWS SDK、アプライアンスモードを有効にする AWS CLI 、または を使用することもできます CloudFormation。例えば、[create-transit-gateway-vpc-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-transit-gateway-vpc-attachment.html) または [modify-transit-gateway-vpc-attachment](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-transit-gateway-vpc-attachment.html) コマンドに `--options ApplianceModeSupport=enable` を追加します。
**注記**
アプライアンスモードでのフロー維持が保証されるのは、インスペクション VPC に対する送信元トラフィックと宛先トラフィックのみです。
#### ステートフルアプライアンスおよびアプライアンスモード
VPC アタッチメントが複数のアベイラビリティーゾーンにまたがっており、ステートフルな検査のために送信元ホストと送信先ホスト間のトラフィックを同じアプライアンスを介してルーティングする必要がある場合は、アプライアンスが配置されている VPC アタッチメントのアプライアンスモードサポートを有効にします。
詳細については、 AWS ブログの[「一元化された検査アーキテクチャ](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/)」を参照してください。
**アプライアンスモードが有効でない場合の動作**
アプライアンスモードが有効になっていない場合、トランジットゲートウェイは、送信元のアベイラビリティーゾーン内の VPC アタッチメント間でルーティングされたトラフィックが送信先に到達するまで維持しようとします。トラフィックは、アベイラビリティーゾーンに障害が発生した場合、またはそのアベイラビリティーゾーン内で VPC アタッチメントに関連付けられたサブネットがない場合にのみ、アタッチメント間でアベイラビリティーゾーンを通過します。
次の図は、アプライアンスモードサポートが有効でない場合のトラフィックフローを示しています。VPC B のアベイラビリティーゾーン 2 から発信されるレスポンストラフィックは、トランジットゲートウェイによって VPC C 内の同じアベイラビリティーゾーンにルーティングされます。したがって、アベイラビリティーゾーン 2 のアプライアンスは VPC A の送信元からの元のリクエストを認識しないため、トラフィックはドロップされます。
![\[アプライアンスへのレスポンストラフィックのドロップ\]](http://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/images/transit-gateway-appliance-dropped-traffic.png)
#### ルーティング
各 VPC には 1 つ以上のルートテーブルがあり、トランジットゲートウェイには 2 つのルートテーブルがあります。
##### VPC ルートテーブル
**VPC A と VPC B**
VPC A と B には、2 つのエントリを持つルートテーブルがあります。最初のエントリは、VPC のローカル IPv4 ルーティングのデフォルトエントリです。このデフォルトエントリにより、この VPC 内のリソースが相互に通信できるようになります。2 番目のエントリは、他のすべての IPv4 サブネットトラフィックをトランジットゲートウェイにルーティングします。以下は、VPC A のルートテーブルです。
| 送信先 | ターゲット |
| --- | --- |
| 10.0.0.0/16 | ローカル |
| 0.0.0.0/0 | *tgw-id* |
**VPC C**
共有サービス VPC (VPC C) には、サブネットごとに異なるルートテーブルがあります。サブネット A はトランジットゲートウェイによって使用されます (VPC アタッチメントの作成時にこのサブネットを指定します)。サブネット A のルートテーブルは、サブネット B のアプライアンスにすべてのトラフィックをルーティングします。
| 送信先 | ターゲット |
| --- | --- |
| 192.168.0.0/16 | ローカル |
| 0.0.0.0/0 | *appliance-eni-id* |
サブネット B (アプライアンスを含む) のルートテーブルは、トラフィックをトランジットゲートウェイにルーティングします。
| 送信先 | ターゲット |
| --- | --- |
| 192.168.0.0/16 | ローカル |
| 0.0.0.0/0 | *tgw-id* |
##### トランジットゲートウェイルートテーブル
このトランジットゲートウェイは、VPC A と VPC B に 1 つのルートテーブルを使用し、共有サービス VPC (VPC C) には 1 つのルートテーブルを使用します。
VPC A と VPC B のアタッチメントは、次のルートテーブルに関連付けられています。ルートテーブルは、すべてのトラフィックを VPC C にルーティングします。
| 送信先 | ターゲット | ルートタイプ |
| --- | --- | --- |
| 0.0.0.0/0 | *VPC C のアタッチメント ID* | 静的 |
VPC C アタッチメントは、次のルートテーブルに関連付けられています。トラフィックを VPC A および VPC B にルーティングします。
| 送信先 | ターゲット | ルートタイプ |
| --- | --- | --- |
| 10.0.0.0/16 | *VPC A のアタッチメント ID* | 伝播済み |
| 10.1.0.0/16 | *VPC B のアタッチメント ID* | 伝播済み |