翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon VPC Transit Gateway の仕組み
AWS Transit Gateway は、仮想プライベートクラウド (VPC) とオンプレミスネットワークの間を流れるトラフィック用のリージョン仮想ルーターとして機能します。Transit Gateway は、ネットワークトラフィックの量に基づいて伸縮自在にスケーリングされます。Transit Gateway を介したルーティングは、レイヤー 3 で動作します。レイヤー 3 では、送信先 IP アドレスに基づいて、パケットが特定のネクストホップ接続に送信されます。
アーキテクチャ図の例
次の図は、3 つの VPC が添付された Transit Gateway を示しています。これらの VPC のそれぞれのルートテーブルには、ローカルルートと、他の 2 つの VPC を宛先とするトラフィックを Transit Gateway に送信するルートが含まれます。
以下は、前の図に示されているアタッチメントのデフォルト 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 つまたは複数の VPC。AWSTransit Gateway は、VPC サブネット内に Elastic Network Interface をデプロイします。これは、選択したサブネット間でトラフィックをルーティングするために Transit Gateway により使用されます。各アベイラビリティーゾーンには、少なくとも 1 つのサブネットが必要です。これにより、そのゾーンのすべてのサブネットのリソースにトラフィックが到達できるようになります。アタッチメントの作成時に、サブネットが同じゾーン内で有効になっている場合にだけ、特定のアベイラビリティーゾーン内のリソースが Transit Gateway に到達できます。サブネットルートテーブルに Transit Gateway へのルートがある場合、トラフィックが Transit Gateway に転送されるのは、Transit Gateway のアタッチメントが同じアベイラビリティーゾーンのサブネットにある場合のみです。
-
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 の有効化または無効化の詳細については、「Amazon VPC Transit Gateway の Transit Gateways」を参照してください。
-
AWS Transit Gateway Connect - AWS Transit Gateway Connect アタッチメントは、ECMP を自動的にサポートします。
-
AWS Direct Connect ゲートウェイ - ネットワークプレフィックス、プレフィックス長、AS_PATH がまったく同じである場合、AWS Direct Connect ゲートウェイアタッチメントは複数の Direct Connect ゲートウェイのアタッチメント間で ECMP を自動的にサポートします。
-
Transit Gateway ピアリング - Transit Gateway ピアリングは、ダイナミックルーティングをサポートしておらず、2 つの異なるターゲットに対して同じ静的ルートを設定することもできないため、ECMP をサポートしません。
注記
-
BGP マルチパスの AS-Path Relax はサポートされていないため、異なる AS 番号 (ASN) で ECMP を使用することはできません。
-
異なるアタッチメントタイプ間では ECMP はサポートされません。例えば、VPN と VPC アタッチメント間で ECMP を有効にすることはできません。代わりに、Transit Gateway ルートが評価され、トラフィックは評価されたルートに従ってルーティングされます。詳細については、「ルートの評価順序」を参照してください。
-
単一の Direct Connect ゲートウェイは、複数のトランジット仮想インターフェイス全体で ECMP をサポートします。このため、Direct Connect ゲートウェイは 1 つだけ設定して使用し、ECMP を利用するために複数のゲートウェイを設定して使用しないことをお勧めします。Direct Connect ゲートウェイとパブリック仮想インターフェイスの詳細については、「パブリック仮想インターフェイスから AWS へのアクティブ/アクティブまたはアクティブ/パッシブ Direct Connect 接続を設定するにはどうすればよいですか?
」を参照してください。
アベイラビリティーゾーン
VPC を Transit Gateway に接続するときは、VPC サブネット内のリソースにトラフィックをルーティングするために、1 つ以上のアベイラビリティーゾーンを Transit Gateway で使用できるようにする必要があります。各アベイラビリティーゾーンを有効にするには、サブネットを 1 つだけ指定します。Transit Gateway は、サブネットから 1 つの IP アドレスを使用して、そのサブネット内にネットワークインターフェイスを配置します。アベイラビリティーゾーンを有効にすると、指定したサブネットやアベイラビリティーゾーンだけでなく、その VPC 内のすべてのサブネットにトラフィックをルーティングできます。ただし、Transit Gateway アタッチメントが存在するアベイラビリティーゾーンにあるリソースのみ、Transit Gateway に到達できます。
トラフィックが、送信先アタッチメントが存在しないアベイラビリティーゾーンから送信される場合、AWS Transit Gateway は、そのトラフィックをアタッチメントが存在するランダムなアベイラビリティーゾーンに内部的にルーティングします。このタイプのクロスアベイラビリティーゾーントラフィックには、Transit Gateway の追加料金はかかりません。
高可用性を確保するために、複数のアベイラビリティーゾーンを有効にすることをお勧めします。
アプライアンスモードサポートの使用
VPC でステートフルネットワークアプライアンスを設定する予定の場合は、アプライアンスが配置されているその VPC アタッチメントに対してアプライアンスモードサポートを有効にできます。これにより、Transit Gateway は、送信元と送信先の間のトラフィックフローの存続期間中、その VPC アタッチメントに対して同じアベイラビリティーゾーンを使用します。また、そのアベイラビリティーゾーンにサブネットの関連付けがある限り、Transit Gateway は VPC 内の任意のアベイラビリティーゾーンにトラフィックを送信できるようにします。詳細については、「例: 共有サービス VPC のアプライアンス」を参照してください。
ルーティング
Transit Gateway は、Transit Gateway ルートテーブルを使ってアタッチメント間で IPv4 と IPv6 パケットをルーティングします。これらのルートテーブルを設定して、アタッチされている VPC、VPN 接続、Direct Connect ゲートウェイのルートテーブルからルートを伝播できます。静的ルートを Transit Gateway ルートテーブルに追加することもできます。パケットが 1 つのアタッチメントから送信されると、宛先 IP アドレスと一致するルートを使用して別のアタッチメントにルーティングされます。
Transit Gateway のピアリングアタッチメントでは、静的ルートだけがサポートされます。
ルートテーブル
Transit Gateway ではデフォルトのルートテーブルが自動的に使用されます。デフォルトでは、このルートテーブルはデフォルトの関連付けルートテーブルおよびデフォルトの伝達ルートテーブルです。または、ルート伝達とルートテーブルの関連付けを無効にした場合、AWS は Transit Gateway のデフォルトルートテーブルを作成しません。
Transit Gateway に対して追加のルートテーブルを作成できます。これにより、アタッチメントのサブネットを分離できます。アタッチメントごとに 1 つのルートテーブルに関連付けることができます。アタッチメントでそのルートを 1 つ以上のルートテーブルに伝播できます。
ルートに一致するトラフィックを破棄する Transit Gateway ルートテーブルでは、ブラックホールルートを作成できます。
VPC を Transit Gateway にアタッチするときは、トラフィックが Transit Gateway を通過してルーティングするために、サブネットルートテーブルにルートを追加する必要があります。詳細については、Amazon VPC ユーザーガイドの「Transit Gateway のルーティング」を参照してください。
ルートテーブルの関連付け
Transit Gateway アタッチメントを単一のルートテーブルに関連付けることができます。各ルートテーブルは、ゼロから多数のアタッチメントに関連付けられ、パケットを他のアタッチメントに転送できます。
ルート伝達
各アタッチメントには、1 つ以上の Transit Gateway ルートテーブルにインストールできるルートが付属しています。アタッチメントが Transit Gateway ルートテーブルに伝播されると、これらのルートはルートテーブルにインストールされます。アドバタイズされたルートをフィルタリングすることはできません。
VPC アタッチメントの場合、VPC の CIDR ブロックは Transit Gateway のルートテーブルに伝達されます。
VPN アタッチメントまたは Direct Connect ゲートウェイアタッチメントで動的ルーティングを使用する場合、BGP 経由でオンプレミスルーターから学習されたルートを Transit Gateway ルートテーブルに伝播できます。
動的ルーティングを VPN アタッチメントで使用する場合、VPN アタッチメントに関連付けられたルートテーブル内のルートが BGP を介してカスタマーゲートウェイにアドバタイズされます。
Connect アタッチメントの場合、Connect アタッチメントに関連付けられたルートテーブル内のルートは、BGP を介して VPC で実行されているサードパーティの仮想アプライアンス (SD-WAN アプライアンスなど) にアドバタイズされます。
Direct Connect ゲートウェイアタッチメントの場合、許可されたプレフィックスのインタラクションが AWS からカスタマーネットワークにアドバタイズするルートを制御します。
静的ルートと伝達ルートが同じ送信先を持つ場合、静的ルートの優先度が高くなるため、伝達されたルートはルートテーブルに含まれません。静的ルートを削除すると、重複する伝達ルートがルートテーブルに含まれます。
ピアリングアタッチメントのルート
2 つの Transit Gateway をピアリングし、それらの間でトラフィックをルーティングできます。これを行うには、Transit Gateway にピアリングアタッチメントを作成し、ピアリング接続を行うピア Transit Gateway を指定します。次に、Transit Gateway ルートテーブルに静的ルートを作成し、トラフィックを Transit Gateway ピアリングアタッチメントにルーティングします。ピア Transit Gateway にルーティングされるトラフィックは、ピア Transit Gateway の VPC および VPN アタッチメントにルーティングできます。
詳細については、「例: ピア接続 Transit Gateway 」を参照してください。
ルートの評価順序
Transit Gateway のルートは、次の順序で評価されます。
-
送信先アドレスの最も具体的なルート。
-
同じ CIDR を持つが、異なるアタッチメントタイプのルートの場合、ルートの優先度は次のとおりです。
-
静的ルート (例えば、Site-to-Site VPN 静的ルート)
-
プレフィックスリスト参照ルート
-
VPC が伝達したルート
-
Direct Connect ゲートウェイが伝播したルート
-
Transit Gateway Connect が伝播したルート
-
プライベート Direct Connect 伝播ルート経由の Site-to-Site VPN
-
Site-to-Site VPN 伝播ルート
-
伝播ルートをピアリングする Transit Gateway (クラウド WAN)
-
一部のアタッチメントは、BGP 経由でルートアドバタイズをサポートしています。同じ CIDR を持つルートと、同じアタッチメントタイプのルートの場合、ルートの優先度は BGP 属性によって制御されます。
-
AS パスの長さがより短い
-
MED 値がより低い
-
アタッチメントがサポートしている場合は、iBGP ルートよりも eBGP が推奨されます
重要
AWS は、上記の CIDR、アタッチメントタイプ、および BGP 属性が同じ BGP ルートの一貫したルート優先順位を保証できません。
AWS Transit Gateway には、優先ルートのみが表示されます。バックアップルートは、そのルートがアドバタイズされなくなった場合にのみ Transit Gateway ルートテーブルに表示されます。例えば、Direct Connect ゲートウェイと Site-to-Site VPN を介して同じルートをアドバタイズしている場合などです。AWSTransit 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 アタッチメントよりもAWS Direct Connectゲートウェイアタッチメントを好ましいと考える場合は、BGP VPN 接続を使用して Transit Gateway ルートテーブルにルートを伝達します。
送信先 | アタッチメント (ターゲット) | リソースタイプ | ルートタイプ | 優先度 |
---|---|---|---|---|
10.0.0.0/16 | tgw-attach-123 | vpc-1234 | VPC | 静的または伝播済み | 1 |
192.168.0.0/16 | tgw-attach-789 | vpn-5678 | VPN | 静的 | 2 |
172.31.0.0/16 | tgw-attach-456 | dxgw_id | AWS Direct Connect ゲートウェイ | 伝播済み | 3 |
172.31.0.0/16 | tgw-attach-789 | tgw-connect-peer-123 | 接続 | 伝播済み | 4 |
172.31.0.0/16 | tgw-attach-789 | vpn-5678 | VPN | 伝播済み | 5 |
トランジットゲートウェイシナリオの例
トランジットゲートウェイの一般的ユースケースは以下のとおりです。お客様のトランジットゲートウェイはこれらのユースケースに限定されません。
例
すべての VPC、AWS Direct Connect 、および Site-to-Site VPN 接続を接続する集中型ルーターとしてトランジットゲートウェイを設定することができます。このシナリオでは、アタッチメントはすべて、トランジットゲートウェイのデフォルトルートテーブルに関連付けられ、トランジットゲートウェイのデフォルトルートテーブルに伝播されます。そのため、アタッチメントはすべて、単純なレイヤー 3 IP ルーターとしてトランジットゲートウェイを提供しながら、パケットを相互にルーティングできます。
概要
次の図は、このシナリオの設定に重要なコンポーネントを示しています。このシナリオでは、トランジットゲートウェイへの 3 つの VPC のアタッチメントと 1 つの Site-to-Site VPN アタッチメントがあります。VPC A、VPC B、および VPC C のサブネットから、別の VPC のサブネットまたは VPN 接続を宛先とするパケットは、最初にトランジットゲートウェイを介してルーティングされます。
リソース
このシナリオでは、次のリソースを作成します。
-
3 つの VPC。VPC の作成の詳細については、Amazon VPC ユーザーガイドの「VPC を作成する」をご参照ください。
-
トランジットゲートウェイ。詳細については、「Amazon VPC Transit Gateway を使用して Transit Gateway を作成する」を参照してください。
-
トランジットゲートウェイ上の 3 つの VPC アタッチメント。詳細については、「Amazon VPC Transit Gateway を使用して VPC アタッチメントを作成する」を参照してください。
-
トランジットゲートウェイ上の Site-to-Site VPN のアタッチメント。各 VPC の CIDR ブロックがトランジットゲートウェイルートテーブルに伝播されます。VPN 接続が起動すると、BGP セッションが確立され、Site-to-Site VPN CIDR がトランジットゲートウェイルートテーブルに伝播され、VPC CIDR がカスタマーゲートウェイの BGP テーブルに追加されます。詳細については、「Amazon VPC Transit Gateway を使用して VPN への Transit Gateway アタッチメントを作成する」を参照してください。
Site-to-Site VPN AWS Site-to-Site VPNユーザーガイドで、カスタマーゲートウェイデバイスの要件を必ず確認してください。
ルーティング
各 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 |
|
伝播済み |
10.2.0.0/16 |
|
伝播済み |
10.3.0.0/16 |
|
伝播済み |
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
複数の独立したルーターとしてトランジットゲートウェイを設定することができます。これは複数のトランジットゲートウェイを使用するのと似ていますが、ルートとアタッチメントが変わる可能性がある場合に、より高い柔軟性を提供します。このシナリオでは、独立した各ルーターに単一のルートテーブルがあります。独立したルーターに関連付けられているすべてのアタッチメントは、伝播されてそのルートテーブルに関連付けられます。1 つの独立したルーターに関連付けられているアタッチメントは、相互にパケットをルーティングできますが、別の独立したルーターのアタッチメントにパケットをルーティングしたり、アタッチメントからパケットを受信したりすることはできません。
概要
次の図は、このシナリオの設定に重要なコンポーネントを示しています。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。VPC の作成の詳細については、Amazon VPC ユーザーガイドの「VPC を作成する」をご参照ください。
-
トランジットゲートウェイ。詳細については、「Amazon VPC Transit Gateway を使用して Transit Gateway を作成する」を参照してください。
-
3 つの VPC に使用するトランジットゲートウェイの 3 つのアタッチメント。詳細については、「Amazon VPC Transit Gateway を使用して VPC アタッチメントを作成する」を参照してください。
-
Transit Gateway 上の Site-to-Site VPN のアタッチメント。詳細については、「Amazon VPC Transit Gateway を使用して VPN への Transit Gateway アタッチメントを作成する」(VPN への Transit Gateway アタッチメントの作成) を参照してください。Site-to-Site VPN AWS Site-to-Site VPNユーザーガイドで、カスタマーゲートウェイデバイスの要件を必ず確認してください。
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 |
|
伝播済み |
10.2.0.0/16 |
|
伝播済み |
10.3.0.0/16 |
|
伝播済み |
トランジットゲートウェイルートテーブルでのルート伝播の詳細については、「Amazon VPC Transit Gateway を使用して Transit Gateway ルートテーブルへのルート伝播を有効にする」を参照してください。
カスタマーゲートウェイの BGP テーブル
カスタマーゲートウェイの BGP テーブルには、次の VPC CIDR が含まれています。
-
10.1.0.0/16
-
10.2.0.0/16
-
10.3.0.0/16
共有サービスを使用する複数の分離されたルーターとしてトランジットゲートウェイを設定できます。これは複数のトランジットゲートウェイを使用するのと似ていますが、ルートとアタッチメントが変わる可能性がある場合に、より高い柔軟性を提供します。このシナリオでは、独立した各ルーターに単一のルートテーブルがあります。独立したルーターに関連付けられているすべてのアタッチメントは、伝播されてそのルートテーブルに関連付けられます。1 つの独立したルーターに関連付けられているアタッチメントは、相互にパケットをルーティングできますが、別の独立したルーターのアタッチメントにパケットをルーティングしたり、アタッチメントからパケットを受信したりすることはできません。アタッチメントは、共有サービスとの間でパケットを送受信することができます。このシナリオは、分離する必要があるが、本番システムなどの共有サービスを使用する必要があるグループがある場合に使用できます。
概要
次の図は、このシナリオの設定に重要なコンポーネントを示しています。インターネットを送信先とする 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。VPC の作成の詳細については、Amazon VPC ユーザーガイドの「VPC を作成する」をご参照ください。
-
トランジットゲートウェイ。詳細については、「トランジットゲートウェイを作成する」を参照してください。
-
Transit Gateway 上の 4 つのアタッチメント (VPC ごとに 1 つ)。詳細については、「Amazon VPC Transit Gateway を使用して VPC アタッチメントを作成する」(VPC への Transit Gateway アタッチメントの作成) を参照してください。
-
Transit Gateway 上の Site-to-Site VPN のアタッチメント。詳細については、「Amazon VPC Transit Gateway を使用して VPN への Transit Gateway アタッチメントを作成する」(VPN への Transit Gateway アタッチメントの作成) を参照してください。
Site-to-Site VPN AWS Site-to-Site VPNユーザーガイドで、カスタマーゲートウェイデバイスの要件を必ず確認してください。
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 のアタッチメント |
伝播済み |
詳細については、「Amazon VPC Transit Gateway を使用して Transit Gateway ルートテーブルへのルート伝播を有効にする」(Transit Gateway ルートテーブルへのルートの伝達) を参照してください。
カスタマーゲートウェイの BGP テーブル
カスタマーゲートウェイの BGP テーブルには、4 つの VPC すべての CIDR が含まれています。
異なるリージョンで Transit Gateway 間に Transit Gateway ピアリング接続を作成できます。その後、各 Transit Gateway のアタッチメント間でトラフィックをルーティングできます。このシナリオでは、VPC および VPN アタッチメントは、Transit Gateway のデフォルトルートテーブルに関連付けられ、Transit Gateway のデフォルトルートテーブルに伝播されます。各 Transit Gateway のルートテーブルには、ゲートウェイのピアリングアタッチメントを指す静的ルートがあります。
概要
次の図は、このシナリオの設定に重要なコンポーネントを示しています。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 つの VPC。VPC の作成の詳細については、Amazon VPC ユーザーガイドの「VPC を作成する」をご参照ください。
-
2 つの Transit Gateway。同じリージョン内に存在することも、異なるリージョン内に存在することもできます。詳細については、「Amazon VPC Transit Gateway を使用して Transit Gateway を作成する」を参照してください。
-
最初のTransit Gateway の 2 つの VPC アタッチメント。詳細については、「Amazon VPC Transit Gateway を使用して VPC アタッチメントを作成する」を参照してください。
-
2 つ目の Transit Gateway 上の Site-to-Site VPN のアタッチメント。詳細については、「Amazon VPC Transit Gateway を使用して VPN への Transit Gateway アタッチメントを作成する」を参照してください。Site-to-Site VPN AWS Site-to-Site VPNユーザーガイドで、カスタマーゲートウェイデバイスの要件を必ず確認してください。
-
2 つのTransit Gateway 間のTransit Gateway ピアリングアタッチメント。詳細については、「Amazon VPC Transit Gateway の Transit Gateway ピアリングアタッチメント」を参照してください。
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 |
|
伝播済み |
10.2.0.0/16 |
|
伝播済み |
0.0.0.0/0 |
ピア接続のアタッチメント ID |
静的 |
次に、ルート伝播が有効になっているTransit Gateway 2 のデフォルトルートテーブルの例を示します。
送信先 | ターゲット | ルートタイプ |
---|---|---|
172.31.0.0/24 |
VPN 接続のアタッチメント ID |
伝播済み |
10.0.0.0/16 |
|
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 にルーティングするように、トランジットゲートウェイを設定できます。
概要
次の図は、このシナリオの設定に重要なコンポーネントを示しています。VPC A と VPC B にインターネットアクセス (アウトバウンドのみ) が必要なアプリケーションがあります。パブリック NAT ゲートウェイとインターネットゲートウェイ、VPC アタッチメント用のプライベートサブネットを使用して VPC C を設定します。すべての VPC をトランジットゲートウェイに接続します。VPC A と VPC B からのアウトバウンドインターネットトラフィックが VPC C へのトランジットゲートウェイを通過するようにルーティングを設定します。VPC C の NAT ゲートウェイは、トラフィックをインターネットゲートウェイにルーティングします。
リソース
このシナリオでは、次のリソースを作成します。
-
IP アドレス範囲が重複しない 3 つの VPC。詳細については、Amazon VPC ユーザーガイドの「VPC を作成する」を参照してください。
-
VPC A と VPC B には、それぞれ EC2 インスタンスを持つプライベートサブネットがあります。
-
VPC C には次のものがあります。
-
VPC にアタッチされたインターネットゲートウェイ。詳細については、Amazon VPC ユーザーガイドの「インターネットゲートウェイの作成とアタッチ」を参照してください。
-
NAT ゲートウェイを持つパブリックサブネット。詳細については、Amazon VPC ユーザーガイドの「NAT ゲートウェイの基本」を参照してください。
-
Transit Gateway アタッチメントのサブネット。プライベートサブネットは、パブリックサブネットと同じアベイラビリティーゾーンに設置する必要があります。
-
-
1 つのトランジットゲートウェイ。詳細については、「Amazon VPC Transit Gateway を使用して Transit Gateway を作成する」を参照してください。
-
トランジットゲートウェイ上の 3 つの VPC アタッチメント。各 VPC の CIDR ブロックがトランジットゲートウェイルートテーブルに伝播されます。詳細については、「Amazon VPC Transit Gateway を使用して VPC アタッチメントを作成する」を参照してください。VPC C には、プライベートサブネットを使用してアタッチメントを作成する必要があります。パブリックサブネットを使用してアタッチメントを作成すると、インスタンストラフィックはインターネットゲートウェイにルーティングされるものの、インターネットゲートウェイはそのトラフィックをドロップします。これは、インスタンスにパブリック IP アドレスがないためです プライベートサブネットにアタッチメントを配置することで、トラフィックが NAT ゲートウェイにルーティングされます。NAT ゲートウェイは、Elastic IP アドレスを送信元 IP アドレスとして使用して、トラフィックをインターネットゲートウェイに送信します
ルーティング
各 VPC には複数のルートテーブルがあり、トランジットゲートウェイには 1 つのルートテーブルがあります。
ルートテーブル
VPC A のルートテーブル
ルートテーブルの例を次に示します。最初のエントリにより、VPC 内のインスタンスが相互に通信できるようになります。2 番目のエントリは、他のすべての IPv4 サブネットトラフィックをトランジットゲートウェイにルーティングします。
送信先 | ターゲット |
---|---|
|
ローカル |
0.0.0.0/0 |
|
VPC B のルートテーブル
ルートテーブルの例を次に示します。最初のエントリにより、VPC 内のインスタンスが相互に通信できるようになります。2 番目のエントリは、他のすべての IPv4 サブネットトラフィックをトランジットゲートウェイにルーティングします。
送信先 | ターゲット |
---|---|
|
ローカル |
0.0.0.0/0 |
|
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 | Attachment | ルートタイプ |
---|---|---|
|
|
伝播済み |
|
|
伝播済み |
|
|
伝播済み |
0.0.0.0/0 |
|
static |
共有サービス VPC でアプライアンス (セキュリティアプライアンスなど) を設定できます。トランジットゲートウェイアタッチメント間でルーティングされるすべてのトラフィックは、まず、共有サービス VPC のアプライアンスによって検査されます。アプライアンスモードが有効な場合、トランジットゲートウェイは、フローハッシュアルゴリズムを使用して、アプライアンス VPC 内の 1 つのネットワークインターフェイスを選択し、フローの有効期間中トラフィックを送信します。トランジットゲートウェイは、リターントラフィックに同じネットワークインターフェイスを使用します。これにより、双方向トラフィックは対称的にルーティングされます。つまり、フローの有効期間中、VPC アタッチメント内の同じアベイラビリティーゾーンを経由してルーティングされます。アーキテクチャ内に複数のトランジットゲートウェイがある場合、各トランジットゲートウェイは独自のセッションアフィニティを維持し、各トランジットゲートウェイは異なるネットワークインターフェイスを選択できます。
フローの維持を保証するには、1 つのトランジットゲートウェイをアプライアンス VPC に接続する必要があります。複数のトランジットゲートウェイを 1 つのアプライアンス VPC に接続しても、これらのトランジットゲートウェイはフロー状態情報を相互に共有しないので、フローの維持は保証されません。
重要
-
アプライアンスモードのトラフィックは、送信元と送信先のトラフィックが同じ Transit Gateway アタッチメントから集中型 VPC (インスペクション VPC) に到達する限り、正しくルーティングされます。送信元と送信先が 2 つの異なる Transit Gateway アタッチメントにある場合、トラフィックが低下する可能性があります。中央 VPC がインターネットゲートウェイなどの別のゲートウェイからトラフィックを受信し、検査後にそのトラフィックを Transit Gateway アタッチメントに送信すると、トラフィックが低下する可能性があります。
-
既存のアタッチメントでアプライアンスモードを有効にすると、アタッチメントがアベイラビリティーゾーンを通過する可能性があるため、そのアタッチメントの現在のルートに影響する可能性があります。アプライアンスモードが有効になっていない場合、トラフィックは発信元のアベイラビリティーゾーンに保持されます。
概要
次の図は、このシナリオの設定に重要なコンポーネントを示しています。トランジットゲートウェイには、3 つの VPC アタッチメントがあります。VPC C は共有サービス VPC です。VPC A と VPC B 間のトラフィックはトランジットゲートウェイにルーティングされ、その後、最終的な宛先にルーティングされる前に、検査のために VPC C のセキュリティアプライアンスにルーティングされます。アプライアンスはステートフルアプライアンスであるため、リクエストトラフィックとレスポンストラフィックの両方が検査されます。高可用性を実現するために、VPC C の各アベイラビリティーゾーンにアプライアンスがあります。
このシナリオでは、次のリソースを作成します。
-
3 つの VPC。VPC の作成については、Amazon 仮想プライベートクラウド ユーザーガイドの「VPC を作成する」を参照してください。
-
トランジットゲートウェイ。詳細については、「Amazon VPC Transit Gateway を使用して Transit Gateway を作成する」を参照してください。
-
3 つの VPC アタッチメント、各 VPC に 1 つずつ。詳細については、「Amazon VPC Transit Gateway を使用して VPC アタッチメントを作成する」を参照してください。
VPC アタッチメントごとに、各アベイラビリティーゾーンでサブネットを指定します。共有サービス VPC の場合、これらは、トラフィックがトランジットゲートウェイから VPC にルーティングされるサブネットです。前の例では、サブネット A と C です。
VPC C の VPC アタッチメントの場合、アプライアンスモードのサポートを有効にして、レスポンストラフィックがソーストラフィックと同じ VPC C のアベイラビリティーゾーンにルーティングされるようにします。
Amazon VPC コンソールはアプライアンスモードをサポートしていません。Amazon VPC API、AWS SDK、または AWS CLI を使用して、アプライアンスモードまたは AWS CloudFormation を有効にできます。例えば、create-transit-gateway-vpc-attachment または modify-transit-gateway-vpc-attachment コマンドに
--options ApplianceModeSupport=enable
を追加します。
注記
アプライアンスモードでのフロー維持が保証されるのは、インスペクション VPC に対する送信元トラフィックと宛先トラフィックのみです。
ステートフルアプライアンスおよびアプライアンスモード
VPC アタッチメントが複数のアベイラビリティーゾーンにまたがっており、ステートフルな検査のために送信元ホストと送信先ホスト間のトラフィックを同じアプライアンスを介してルーティングする必要がある場合は、アプライアンスが配置されている VPC アタッチメントのアプライアンスモードサポートを有効にします。
詳細については、AWSブログの一元化された検査アーキテクチャ
アプライアンスモードが有効でない場合の動作
アプライアンスモードが有効になっていない場合、トランジットゲートウェイは、送信元のアベイラビリティーゾーン内の VPC アタッチメント間でルーティングされたトラフィックが送信先に到達するまで維持しようとします。トラフィックは、アベイラビリティーゾーンに障害が発生した場合、またはそのアベイラビリティーゾーン内で VPC アタッチメントに関連付けられたサブネットがない場合にのみ、アタッチメント間でアベイラビリティーゾーンを通過します。
次の図は、アプライアンスモードサポートが有効でない場合のトラフィックフローを示しています。VPC B のアベイラビリティーゾーン 2 から発信されるレスポンストラフィックは、トランジットゲートウェイによって VPC C 内の同じアベイラビリティーゾーンにルーティングされます。したがって、アベイラビリティーゾーン 2 のアプライアンスは VPC A の送信元からの元のリクエストを認識しないため、トラフィックはドロップされます。
ルーティング
各 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 アタッチメントは、次のルートテーブルに関連付けられています。トラフィックを VPC A および VPC B にルーティングします。
送信先 | ターゲット | ルートタイプ |
---|---|---|
10.0.0.0/16 |
|
伝播済み |
10.1.0.0/16 |
|
伝播済み |