Amazon VPC Transit Gateway の仕組み - Amazon VPC

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

Amazon VPC Transit Gateway の仕組み

AWS Transit Gateway では、トランジットゲートウェイは、仮想プライベートクラウド (VPCs) とオンプレミスネットワーク間を流れるトラフィックのリージョン仮想ルーターとして機能します。Transit Gateway は、ネットワークトラフィックの量に基づいて伸縮自在にスケーリングされます。Transit Gateway を介したルーティングは、レイヤー 3 で動作します。レイヤー 3 では、送信先 IP アドレスに基づいて、パケットが特定のネクストホップ接続に送信されます。

アーキテクチャ図の例

次の図は、3 つのVPCアタッチメントを持つトランジットゲートウェイを示しています。これらそれぞれのルートテーブルVPCsには、ローカルルートと、他の 2 つ宛てのトラフィックをVPCsトランジットゲートウェイに送信するルートが含まれます。

VPC 接続オプション

以下は、前の図に示されているアタッチメントのデフォルト Transit Gateway のルートテーブルの例です。各 のCIDRブロックVPCはルートテーブルに伝播されます。したがって、各アタッチメントは他の 2 つのアタッチメントにパケットをルーティングできます。

デスティネーション ターゲット ルートタイプ
VPC A CIDR Attachment for VPC A 伝播済み
VPC B CIDR Attachment for VPC B 伝播済み
VPC C CIDR Attachment for 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 つ以上の AWS Direct Connect ゲートウェイ

  • 1 つまたは複数の Transit Gateway Connect アタッチメント

  • 1 つ以上の Transit Gateway ピアリング接続

  • Transit Gateway アタッチメントは、パケットの送信元と送信先の両方です。

等コストマルチパスルーティング

AWS Transit Gateway は、ほとんどのアタッチメントで等コストマルチパス (ECMP) ルーティングをサポートしています。VPN アタッチメントの場合、トランジットゲートウェイを作成または変更するときに、コンソールを使用してECMPサポートを有効または無効にできます。他のすべてのアタッチメントタイプには、次のECMP制限が適用されます。

  • VPC - CIDRブロックVPCは重複できないECMPため、 は をサポートしていません。例えば、10.1.0.0/16 VPC CIDR の と 1 秒の を同じ VPCを使用してトランジットゲートウェイCIDRにアタッチし、それらの間のトラフィックを負荷分散するようにルーティングを設定することはできません。

  • VPN - VPN ECMP サポートオプションが無効になっている場合、トランジットゲートウェイは内部メトリクスを使用して、複数のパスでプレフィックスが等しい場合に優先パスを決定します。VPN アタッチメントの有効化または無効化の詳細については、ECMP「」を参照してくださいAmazon Transit Gateway のVPCトランジットゲートウェイ

  • AWS Transit Gateway Connect - AWS Transit Gateway Connect アタッチメントは、 を自動的にサポートしますECMP。

  • AWS Direct Connect Gateway - AWS Direct Connect Gateway アタッチメントは、ネットワークプレフィックス、プレフィックスの長さ、および AS_PATH がまったく同じ場合、複数の Direct Connect Gateway アタッチメントECMP間で自動的にサポートされます。

  • トランジットゲートウェイピアリング - トランジットゲートウェイピアリングは、動的ルーティングをサポートしておらず、2 つの異なるターゲットに対して同じ静的ルートを設定できないECMPため、 をサポートしていません。

注記
  • BGP マルチパス AS-Path relax はサポートされていないため、異なる自律システム番号 () ECMPで を使用することはできませんASNs。

  • ECMP は、異なるアタッチメントタイプ間ではサポートされていません。例えば、 VPNとVPC添付ファイルECMPの間で を有効にすることはできません。代わりに、Transit Gateway ルートが評価され、トラフィックは評価されたルートに従ってルーティングされます。詳細については、「ルートの評価順序」を参照してください。

  • 単一の Direct Connect ゲートウェイは、複数のトランジット仮想インターフェイスECMPで をサポートします。したがって、 を利用するために複数のゲートウェイをセットアップして使用しないように、1 つの Direct Connect ゲートウェイのみをセットアップして使用することをお勧めしますECMP。Direct Connect ゲートウェイとパブリック仮想インターフェイスの詳細については、「パブリック仮想インターフェイスAWS から へのアクティブ/アクティブまたはアクティブ/パッシブ Direct Connect 接続を設定する方法」を参照してください。

アベイラビリティーゾーン

VPC をトランジットゲートウェイにアタッチするときは、トランジットゲートウェイがVPCサブネット内のリソースにトラフィックをルーティングするために使用する 1 つ以上のアベイラビリティーゾーンを有効にする必要があります。各アベイラビリティーゾーンを有効にするには、サブネットを 1 つだけ指定します。Transit Gateway は、サブネットから 1 つの IP アドレスを使用して、そのサブネット内にネットワークインターフェイスを配置します。アベイラビリティーゾーンを有効にすると、指定したサブネットやアベイラビリティーゾーンだけでなくVPC、 内のすべてのサブネットにトラフィックをルーティングできます。ただし、Transit Gateway アタッチメントが存在するアベイラビリティーゾーンにあるリソースのみ、Transit Gateway に到達できます。

送信先アタッチメントが存在しないアベイラビリティーゾーンからトラフィックが発信された場合、 AWS Transit Gateway はそのトラフィックをアタッチメントが存在するランダムなアベイラビリティーゾーンに内部的にルーティングします。このタイプのクロスアベイラビリティーゾーントラフィックには、Transit Gateway の追加料金はかかりません。

高可用性を確保するために、複数のアベイラビリティーゾーンを有効にすることをお勧めします。

アプライアンスモードサポートの使用

でステートフルネットワークアプライアンスを設定する場合はVPC、アプライアンスが配置されているVPCアタッチメントのアプライアンスモードサポートを有効にできます。これにより、送信元と送信先間のトラフィックフローの存続期間中、トランジットゲートウェイはそのVPCアタッチメントに同じアベイラビリティーゾーンを使用します。また、そのゾーンにサブネットの関連付けがある限りVPC、トランジットゲートウェイは 内の任意のアベイラビリティーゾーンにトラフィックを送信できます。詳細については、「例: 共有サービスのアプライアンス VPC」を参照してください。

ルーティング

トランジットゲートウェイはIPv4、トランジットゲートウェイルートテーブルを使用してアタッチメント間で とIPv6パケットをルーティングします。これらのルートテーブルを設定して、アタッチされた VPCs、VPN接続、および Direct Connect ゲートウェイのルートテーブルからルートを伝達できます。静的ルートを Transit Gateway ルートテーブルに追加することもできます。パケットが 1 つのアタッチメントから送信されると、宛先 IP アドレスと一致するルートを使用して別のアタッチメントにルーティングされます。

Transit Gateway のピアリングアタッチメントでは、静的ルートだけがサポートされます。

ルートテーブル

Transit Gateway ではデフォルトのルートテーブルが自動的に使用されます。デフォルトでは、このルートテーブルはデフォルトの関連付けルートテーブルおよびデフォルトの伝達ルートテーブルです。または、ルート伝達とルートテーブルの関連付けを無効にした場合、 AWS は Transit Gateway のデフォルトルートテーブルを作成しません。

Transit Gateway に対して追加のルートテーブルを作成できます。これにより、アタッチメントのサブネットを分離できます。アタッチメントごとに 1 つのルートテーブルに関連付けることができます。アタッチメントでそのルートを 1 つ以上のルートテーブルに伝播できます。

ルートに一致するトラフィックを破棄する Transit Gateway ルートテーブルでは、ブラックホールルートを作成できます。

をトランジットゲートウェイVPCにアタッチするときは、トラフィックがトランジットゲートウェイを経由するように、サブネットルートテーブルにルートを追加する必要があります。詳細については、「Amazon ユーザーガイド」の「トランジットゲートウェイのルーティング」を参照してください。 VPC

ルートテーブルの関連付け

Transit Gateway アタッチメントを単一のルートテーブルに関連付けることができます。各ルートテーブルは、ゼロから多数のアタッチメントに関連付けられ、パケットを他のアタッチメントに転送できます。

ルート伝達

各アタッチメントには、1 つ以上の Transit Gateway ルートテーブルにインストールできるルートが付属しています。アタッチメントが Transit Gateway ルートテーブルに伝播されると、これらのルートはルートテーブルにインストールされます。アドバタイズされたルートをフィルタリングすることはできません。

VPC アタッチメントの場合、 のCIDRブロックVPCは Transit Gateway ルートテーブルに伝達されます。

アタッチメントまたは Direct Connect ゲートウェイVPNアタッチメントで動的ルーティングを使用する場合、オンプレミスルーターから学習したルートを 経由で任意のトランジットゲートウェイルートテーブルBGPに伝達できます。

動的ルーティングがVPNアタッチメントとともに使用されると、VPNアタッチメントに関連付けられたルートテーブル内のルートは、 を介してカスタマーゲートウェイにアドバタイズされますBGP。

Connect アタッチメントの場合、Connect アタッチメントに関連付けられたルートテーブル内のルートは、 VPC から で実行される SD WANアプライアンスなどのサードパーティーの仮想アプライアンスにアドバタイズされますBGP。

Direct Connect ゲートウェイアタッチメントの場合、許可されたプレフィックスインタラクションは、 からカスタマーネットワークにアドバタイズされるルートを制御します AWS。

静的ルートと伝達ルートが同じ送信先を持つ場合、静的ルートの優先度が高くなるため、伝達されたルートはルートテーブルに含まれません。静的ルートを削除すると、重複する伝達ルートがルートテーブルに含まれます。

ピアリングアタッチメントのルート

2 つの 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 で伝播されたルートVPNを介した Site-to-Site

    • Site-toVPN-Site で伝播されたルート

    • 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。 AWS Transit Gateway は、優先ルートである Direct Connect ゲートウェイルートから受信したルートのみを表示します。バックアップルートVPNである Site-to-Site は、Direct Connect ゲートウェイがアドバタイズされなくなった場合にのみ表示されます。

VPC とトランジットゲートウェイのルートテーブルの違い

ルートテーブルの評価は、VPCルートテーブルとトランジットゲートウェイルートテーブルのどちらを使用しているかによって異なります。

次の例は、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

次の例は、トランジットゲートウェイルートテーブルを示しています。ゲートウェイアタッチメントを AWS Direct Connect VPNアタッチメントにする場合は、BGPVPN接続を使用してトランジットゲートウェイルートテーブルにルートを伝播します。

デスティネーション アタッチメント (ターゲット) リソースタイプ ルートタイプ 優先度
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

トランジットゲートウェイシナリオの例

トランジットゲートウェイの一般的ユースケースは以下のとおりです。お客様のトランジットゲートウェイはこれらのユースケースに限定されません。

    トランジットゲートウェイは、、VPCs、 AWS Direct Connectおよび Site-to-Site のすべてのVPN接続を接続する集中型ルーターとして設定できます。このシナリオでは、アタッチメントはすべて、トランジットゲートウェイのデフォルトルートテーブルに関連付けられ、トランジットゲートウェイのデフォルトルートテーブルに伝播されます。そのため、アタッチメントはすべて、単純なレイヤー 3 IP ルーターとしてトランジットゲートウェイを提供しながら、パケットを相互にルーティングできます。

    概要

    次の図は、このシナリオの設定に重要なコンポーネントを示しています。このシナリオでは、トランジットゲートウェイに 3 つのVPCアタッチメントと 1 つの Site-to-Site VPNアタッチメントがあります。VPC A、VPCB、C VPC のサブネットからのパケットで、別の のサブネットVPCまたはVPN接続の宛先が最初にトランジットゲートウェイを経由します。

    3 つのVPCアタッチメントと 1 つのVPNアタッチメントを備えたトランジットゲートウェイ。

    リソース

    このシナリオでは、次のリソースを作成します。

    ルーティング

    各 VPCにはルートテーブルがあり、トランジットゲートウェイのルートテーブルがあります。

    VPC ルートテーブル

    各 には 2 つのエントリを持つルートテーブルVPCがあります。最初のエントリは、 のローカルIPv4ルーティングのデフォルトエントリVPCです。このエントリにより、この中のインスタンスは相互に通信VPCできるようになります。2 番目のエントリは、他のすべてのIPv4サブネットトラフィックをトランジットゲートウェイにルーティングします。次の表は、VPCA ルートを示しています。

    デスティネーション ターゲット

    10.1.0.0/16

    ローカル

    0.0.0.0/0

    tgw-id

    転送ゲートウェイルートテーブル

    以下は、前の図に示されているアタッチメントのデフォルトルートテーブルの例で、ルート伝播が有効になっています。

    送信先 ターゲット ルートタイプ

    10.1.0.0/16

    Attachment for VPC A

    伝播済み

    10.2.0.0/16

    Attachment for VPC B

    伝播済み

    10.3.0.0/16

    Attachment for VPC C

    伝播済み

    10.99.99.0/24

    Attachment for VPN connection

    伝播済み

    カスタマーゲートウェイBGPテーブル

    カスタマーゲートウェイBGPテーブルには、次の VPC が含まれますCIDRs。

    • 10.1.0.0/16

    • 10.2.0.0/16

    • 10.3.0.0/16

    複数の独立したルーターとしてトランジットゲートウェイを設定することができます。これは複数のトランジットゲートウェイを使用するのと似ていますが、ルートとアタッチメントが変わる可能性がある場合に、より高い柔軟性を提供します。このシナリオでは、独立した各ルーターに単一のルートテーブルがあります。独立したルーターに関連付けられているすべてのアタッチメントは、伝播されてそのルートテーブルに関連付けられます。1 つの独立したルーターに関連付けられているアタッチメントは、相互にパケットをルーティングできますが、別の独立したルーターのアタッチメントにパケットをルーティングしたり、アタッチメントからパケットを受信したりすることはできません。

    概要

    次の図は、このシナリオの設定に重要なコンポーネントを示しています。VPC A、VPCB、C VPC からのパケットはトランジットゲートウェイにルーティングされます。インターネットを送信先とする VPC A、VPCB、C VPC のサブネットからのパケットは、まず Transit Gateway を経由し、次に Site-to-Site VPN接続にルーティングします (送信先がそのネットワーク内にある場合)。例えば、10.1.0.0 から 10.2.0.0 までVPCなど、別の のサブネットの送信先VPCを持つパケットは、トランジットゲートウェイを経由します。トランジットゲートウェイルートテーブルにサブネットのルートがないため、パケットはブロックされます。

    3 つのVPCアタッチメントと 1 つのVPNアタッチメントを備えたトランジットゲートウェイ。

    リソース

    このシナリオでは、次のリソースを作成します。

    VPN 接続が起動すると、BGPセッションが確立され、 VPN CIDR がトランジットゲートウェイルートテーブルに伝達され、 VPCCIDRsがカスタマーゲートウェイBGPテーブルに追加されます。

    ルーティング

    各 VPCにはルートテーブルがあり、トランジットゲートウェイには 2 つのルートテーブルがあります。1 つは 用VPCs、もう 1 つはVPN接続用です。

    VPC A、VPCB、C VPC ルートテーブル

    各 VPCには 2 つのエントリを持つルートテーブルがあります。最初のエントリは、 のローカルIPv4ルーティングのデフォルトエントリですVPC。このエントリにより、この中のインスタンスは相互に通信VPCできるようになります。2 番目のエントリは、他のすべてのIPv4サブネットトラフィックをトランジットゲートウェイにルーティングします。次の表は、VPCA ルートを示しています。

    デスティネーション ターゲット

    10.1.0.0/16

    ローカル

    0.0.0.0/0

    tgw-id

    トランジットゲートウェイルートテーブル

    このシナリオでは、 に 1 つのルートテーブルVPCsを使用し、VPN接続に 1 つのルートテーブルを使用します。

    VPC アタッチメントは、VPNアタッチメントの伝播されたルートを持つ次のルートテーブルに関連付けられています。

    デスティネーション ターゲット ルートタイプ
    10.99.99.0/24 Attachment for VPN connection

    伝播済み

    VPN アタッチメントは、各VPCアタッチメントに伝播されたルートを持つ次のルートテーブルに関連付けられています。

    デスティネーション ターゲット ルートタイプ

    10.1.0.0/16

    Attachment for VPC A

    伝播済み

    10.2.0.0/16

    Attachment for VPC B

    伝播済み

    10.3.0.0/16

    Attachment for VPC C

    伝播済み

    トランジットゲートウェイルートテーブルでのルート伝播の詳細については、「Amazon VPC Transit Gateway を使用してトランジットゲートウェイルートテーブルへのルート伝達を有効にする」を参照してください。

    カスタマーゲートウェイBGPテーブル

    カスタマーゲートウェイBGPテーブルには、次の VPC が含まれますCIDRs。

    • 10.1.0.0/16

    • 10.2.0.0/16

    • 10.3.0.0/16

    共有サービスを使用する複数の分離されたルーターとしてトランジットゲートウェイを設定できます。これは複数のトランジットゲートウェイを使用するのと似ていますが、ルートとアタッチメントが変わる可能性がある場合に、より高い柔軟性を提供します。このシナリオでは、独立した各ルーターに単一のルートテーブルがあります。独立したルーターに関連付けられているすべてのアタッチメントは、伝播されてそのルートテーブルに関連付けられます。1 つの独立したルーターに関連付けられているアタッチメントは、相互にパケットをルーティングできますが、別の独立したルーターのアタッチメントにパケットをルーティングしたり、アタッチメントからパケットを受信したりすることはできません。アタッチメントは、共有サービスとの間でパケットを送受信することができます。このシナリオは、分離する必要があるが、本番システムなどの共有サービスを使用する必要があるグループがある場合に使用できます。

    概要

    次の図は、このシナリオの設定に重要なコンポーネントを示しています。インターネットを送信先とする VPC A、VPCB、C VPC のサブネットからのパケットは、まずトランジットゲートウェイを経由し、次に Site-to-Site のカスタマーゲートウェイにルーティングしますVPN。A、VPCB、または VPC VPCC のサブネットから送信先が A、VPCB、または VPC VPCC のサブネットのパケットは、トランジットゲートウェイを経由します。トランジットゲートウェイルートテーブルにルートがないため、パケットはブロックされます。D を宛先ルートとする VPC A、VPCB、VPCC VPC からのパケットは、トランジットゲートウェイを経由し、その後 D VPC にルーティングされます。

    4 つのVPCアタッチメントと 1 つのVPNアタッチメントを備えたトランジットゲートウェイ。

    リソース

    このシナリオでは、次のリソースを作成します。

    VPN 接続が起動すると、BGPセッションが確立され、 VPN CIDR がトランジットゲートウェイルートテーブルに伝達され、 VPCCIDRsがカスタマーゲートウェイBGPテーブルに追加されます。

    • 分離された各 VPCは、分離されたルートテーブルに関連付けられ、共有ルートテーブルに伝播されます。

    • 各共有VPCサービスは共有ルートテーブルに関連付けられ、両方のルートテーブルに伝播されます。

    ルーティング

    各 VPCにはルートテーブルがあり、トランジットゲートウェイには 2 つのルートテーブルがあります。1 つは 用VPCs、もう 1 つはVPN接続と共有サービス用ですVPC。

    VPC A、VPCB、VPCC、D VPC ルートテーブル

    各 VPCには、2 つのエントリを持つルートテーブルがあります。最初のエントリは、 のローカルルーティングのデフォルトエントリVPCです。このエントリにより、この中のインスタンスは相互に通信VPCできるようになります。2 番目のエントリは、他のすべてのIPv4サブネットトラフィックをトランジットゲートウェイにルーティングします。

    デスティネーション ターゲット
    10.1.0.0/16 ローカル
    0.0.0.0/0 transit gateway ID

    Transit Gateway ルートテーブル

    このシナリオでは、 に 1 つのルートテーブルVPCsを使用し、VPN接続に 1 つのルートテーブルを使用します。

    VPC A、B、および C アタッチメントは、次のルートテーブルに関連付けられています。このルートテーブルには、VPNアタッチメントの伝播されたルートとVPC、D のアタッチメントの伝播されたルートがあります。

    デスティネーション ターゲット ルートタイプ
    10.99.99.0/24 Attachment for VPN connection 伝播済み
    10.4.0.0/16 Attachment for VPC D 伝播済み

    VPN アタッチメントと共有サービス VPC (VPC D) アタッチメントは、次のルートテーブルに関連付けられます。ルートテーブルには、各VPCアタッチメントを指すエントリがあります。これにより、VPN接続 と共有サービス VPCsから への通信が可能になりますVPC。

    デスティネーション ターゲット ルートタイプ
    10.1.0.0/16 Attachment for VPC A 伝播済み
    10.2.0.0/16 Attachment for VPC B 伝播済み
    10.3.0.0/16 Attachment for VPC C 伝播済み

    詳細については、「Amazon VPC Transit Gateway を使用してトランジットゲートウェイルートテーブルへのルート伝達を有効にする」を参照してください。

    カスタマーゲートウェイBGPテーブル

    カスタマーゲートウェイBGPテーブルには、4 つすべての CIDRsの が含まれていますVPCs。

    異なるリージョンで Transit Gateway 間に Transit Gateway ピアリング接続を作成できます。その後、各 Transit Gateway のアタッチメント間でトラフィックをルーティングできます。このシナリオでは、 VPCおよび VPNアタッチメントはトランジットゲートウェイのデフォルトルートテーブルに関連付けられ、トランジットゲートウェイのデフォルトルートテーブルに伝播されます。各 Transit Gateway のルートテーブルには、ゲートウェイのピアリングアタッチメントを指す静的ルートがあります。

    概要

    次の図は、このシナリオの設定に重要なコンポーネントを示しています。トランジットゲートウェイ 1 には 2 つのVPCアタッチメントがあり、トランジットゲートウェイ 2 には 1 つの Site-to-Site VPNアタッチメントがあります。インターネットを送信先とする VPC A と VPC B のサブネットからのパケットは、まずトランジットゲートウェイ 1 を経由し、次にトランジットゲートウェイ 2 を経由し、次にVPN接続にルーティングします。

    2 つのピアリングされたトランジットゲートウェイ。1 つは 2 つのVPCアタッチメント、もう 1 つはVPNアタッチメントです。

    リソース

    このシナリオでは、次のリソースを作成します。

    VPC アタッチメントを作成すると、各 CIDRsの がトランジットゲートウェイ VPC 1 のルートテーブルに伝播されます。VPN 接続が起動すると、次のアクションが発生します。

    • BGP セッションが確立された

    • Site-to-Site はトランジットゲートウェイ VPN CIDR 2 のルートテーブルに伝播されます。

    • VPC CIDRs がカスタマーゲートウェイBGPテーブルに追加されます。

    ルーティング

    各 VPCにはルートテーブルがあり、各トランジットゲートウェイにはルートテーブルがあります。

    VPC A および VPC B ルートテーブル

    各 VPCには 2 つのエントリを持つルートテーブルがあります。最初のエントリは、 のローカルIPv4ルーティングのデフォルトエントリですVPC。このデフォルトエントリにより、この中のリソースは相互に通信VPCできるようになります。2 番目のエントリは、他のすべてのIPv4サブネットトラフィックをトランジットゲートウェイにルーティングします。次の表は、VPCA ルートを示しています。

    デスティネーション ターゲット

    10.0.0.0/16

    ローカル

    0.0.0.0/0

    tgw-1-id

    Transit Gateway ルートテーブル

    次に、ルート伝播が有効になっているTransit Gateway 1 のデフォルトルートテーブルの例を示します。

    送信先 ターゲット ルートタイプ

    10.0.0.0/16

    Attachment ID for VPC A

    伝播済み

    10.2.0.0/16

    Attachment ID for VPC B

    伝播済み

    0.0.0.0/0

    Attachment ID for peering connection

    静的

    次に、ルート伝播が有効になっているTransit Gateway 2 のデフォルトルートテーブルの例を示します。

    送信先 ターゲット ルートタイプ

    172.31.0.0/24

    Attachment ID for VPN connection

    伝播済み

    10.0.0.0/16

    Attachment ID for peering connection

    static

    10.2.0.0/16

    Attachment ID for peering connection static

    カスタマーゲートウェイBGPテーブル

    カスタマーゲートウェイBGPテーブルには、次の VPC が含まれますCIDRs。

    • 10.0.0.0/16

    • 10.2.0.0/16

    インターネットゲートウェイVPCのない から、ゲートウェイNATとインターネットゲートウェイを含む にアウトバウンドインターネットトラフィックをルーティングVPCするようにトランジットゲートウェイを設定できます。

    概要

    次の図は、このシナリオの設定に重要なコンポーネントを示しています。A と VPC B VPC には、アウトバウンドのみのインターネットアクセスを必要とするアプリケーションがあります。VPC C は、パブリックNATゲートウェイとインターネットゲートウェイ、およびVPCアタッチメントのプライベートサブネットを使用して設定します。すべてをVPCsトランジットゲートウェイに接続します。A と VPC B VPC からのアウトバウンドインターネットトラフィックがトランジットゲートウェイを C VPC に通過するようにルーティングを設定します。C VPC のNATゲートウェイはトラフィックをインターネットゲートウェイにルーティングします。

    3 つのVPCアタッチメントを持つトランジットゲートウェイ。

    リソース

    このシナリオでは、次のリソースを作成します。

    • 重複しない IP アドレス範囲VPCsを持つ 3 つの 。詳細については、「Amazon ユーザーガイド」のVPC「 の作成」を参照してください。 VPC

    • VPC A と VPC B には、それぞれEC2インスタンスを持つプライベートサブネットがあります。

    • VPC C には次のものがあります。

    • 1 つのトランジットゲートウェイ。詳細については、「Amazon VPC Transit Gateway を使用してトランジットゲートウェイを作成する」を参照してください。

    • トランジットゲートウェイ上の 3 つのVPCアタッチメント。各 のCIDRブロックはVPC、トランジットゲートウェイルートテーブルに伝播されます。詳細については、「Amazon VPC Transit Gateway を使用してVPCアタッチメントを作成する」を参照してください。VPC C の場合、プライベートサブネットを使用してアタッチメントを作成する必要があります。パブリックサブネットを使用してアタッチメントを作成すると、インスタンストラフィックはインターネットゲートウェイにルーティングされるものの、インターネットゲートウェイはそのトラフィックをドロップします。これは、インスタンスにパブリック IP アドレスがないためです アタッチメントをプライベートサブネットに配置すると、トラフィックはNATゲートウェイにルーティングされ、NATゲートウェイは Elastic IP アドレスをソース IP アドレスとして使用してトラフィックをインターネットゲートウェイに送信します。

    ルーティング

    各 のルートテーブルVPCとトランジットゲートウェイのルートテーブルがあります。

    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

    C VPC のルートテーブル

    インターネットNATゲートウェイにルートを追加して、ゲートウェイをパブリックサブネットとしてサブネットを設定します。もう一方のサブネットはプライベートサブネットのままにします。

    パブリックサブネットのルートテーブルの例を次に示します。最初のエントリにより、 内のインスタンスが相互に通信VPCできるようになります。2 番目と 3 番目のエントリは、VPCA と 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

    トランジットゲートウェイルートテーブル

    トランジットゲートウェイのルートテーブルの例を次に示します。各 のCIDRブロックはVPC、トランジットゲートウェイルートテーブルに伝播されます。静的ルートはアウトバウンドインターネットトラフィックを C VPC に送信します。オプションで、各 にブラックホールルートを追加することで、通信VPC間を防ぐことができますVPCCIDR。

    CIDR Attachment ルートタイプ

    VPC A CIDR

    Attachment for VPC A

    伝播済み

    VPC B CIDR

    Attachment for VPC B

    伝播済み

    VPC C CIDR

    Attachment for VPC C

    伝播済み

    0.0.0.0/0

    Attachment for VPC C

    static

    アプライアンス (セキュリティアプライアンスなど) は、共有サービス で設定できますVPC。Transit Gateway アタッチメント間でルーティングされるすべてのトラフィックは、まず共有サービス のアプライアンスによって検査されますVPC。アプライアンスモードを有効にすると、トランジットゲートウェイは、フローハッシュアルゴリズムVPCを使用してアプライアンス 内の単一のネットワークインターフェイスを選択し、フローの存続期間中、トラフィックを に送信します。トランジットゲートウェイは、リターントラフィックに同じネットワークインターフェイスを使用します。これにより、双方向トラフィックは対称的にルーティングされ、フローの存続期間中、VPCアタッチメント内の同じアベイラビリティーゾーンを介してルーティングされます。アーキテクチャ内に複数のトランジットゲートウェイがある場合、各トランジットゲートウェイは独自のセッションアフィニティを維持し、各トランジットゲートウェイは異なるネットワークインターフェイスを選択できます。

    フローの維持を保証するVPCには、1 つのトランジットゲートウェイのみをアプライアンスに接続する必要があります。複数のトランジットゲートウェイを単一のアプライアンスに接続しても、トランジットゲートウェイVPCはフロー状態情報を相互に共有しないため、フローの維持は保証されません。

    重要
    • アプライアンスモードのトラフィックは、送信元トラフィックと送信先トラフィックが同じ Transit Gateway アタッチメントから一元管理された VPC (検査 VPC) に到達する限り、正しくルーティングされます。送信元と送信先が 2 つの異なる Transit Gateway アタッチメントにある場合、トラフィックがドロップされる可能性があります。一元化された がインターネットゲートウェイなどの別のゲートウェイからトラフィックVPCを受信し、検査後にそのトラフィックをトランジットゲートウェイアタッチメントに送信すると、トラフィックがドロップされる可能性があります。

    • 既存のアタッチメントでアプライアンスモードを有効にすると、アタッチメントがアベイラビリティーゾーンを流れる可能性があるため、そのアタッチメントの現在のルートに影響する可能性があります。アプライアンスモードが有効になっていない場合、トラフィックは発信元のアベイラビリティーゾーンに保持されます。

    概要

    次の図は、このシナリオの設定に重要なコンポーネントを示しています。トランジットゲートウェイには 3 つのVPCアタッチメントがあります。VPC C は共有サービス ですVPC。A と VPC B VPC の間のトラフィックはトランジットゲートウェイにルーティングされ、検査のために C VPC のセキュリティアプライアンスにルーティングされてから、最終送信先にルーティングされます。アプライアンスはステートフルアプライアンスであるため、リクエストトラフィックとレスポンストラフィックの両方が検査されます。高可用性のために、VPCC の各アベイラビリティーゾーンにアプライアンスがあります。

    共有サービスのアプライアンス VPC

    このシナリオでは、次のリソースを作成します。

    • 3 つの VPCs。の作成の詳細についてはVPC、Amazon Virtual Private Cloud ユーザーガイドVPC」の「 の作成」を参照してください。

    • Transit Gateway。詳細については、「Amazon VPC Transit Gateway を使用してトランジットゲートウェイを作成する」を参照してください。

    • 3 つのVPCアタッチメント - 各 に 1 つずつVPCs。詳細については、「Amazon VPC Transit Gateway を使用してVPCアタッチメントを作成する」を参照してください。

      VPC アタッチメントごとに、各アベイラビリティーゾーンにサブネットを指定します。共有サービス の場合VPC、これらはトラフィックがトランジットゲートウェイVPCから にルーティングされるサブネットです。前の例では、サブネット A と C です。

      VPC C のVPCアタッチメントでは、アプライアンスモードのサポートを有効にして、レスポンストラフィックがソーストラフィックと同じ C VPC のアベイラビリティーゾーンにルーティングされるようにします。

      Amazon VPCコンソールはアプライアンスモードをサポートしています。Amazon API、、 VPC を使用してアプライアンスモード AWS SDK AWS CLI を有効にすることもできます AWS CloudFormation。例えば、 --options ApplianceModeSupport=enablecreate-transit-gateway-vpc-attachment コマンドまたは modify-transit-gateway-vpc-attachment コマンドに追加します。

    注記

    アプライアンスモードでのフローの維持は、検査 に向かう送信元トラフィックと送信先トラフィックに対してのみ保証されますVPC。

    ステートフルアプライアンスおよびアプライアンスモード

    VPC アタッチメントが複数のアベイラビリティーゾーンにまたがり、ステートフル検査のために送信元ホストと送信先ホスト間のトラフィックを同じアプライアンス経由でルーティングする必要がある場合は、アプライアンスが配置されているVPCアタッチメントのアプライアンスモードサポートを有効にします。

    詳細については、 AWS ブログの「一元化された検査アーキテクチャ」を参照してください。

    アプライアンスモードが有効でない場合の動作

    アプライアンスモードが有効になっていない場合、トランジットゲートウェイは、送信先に到達するまで、送信元のアベイラビリティーゾーン内のVPCアタッチメント間でルーティングされたトラフィックを保持しようとします。トラフィックは、アベイラビリティーゾーンに障害が発生した場合、またはそのアベイラビリティーゾーンにアタッチメントに関連付けられたサブネットがない場合にのみ、VPCアタッチメント間でアベイラビリティーゾーンを通過します。

    次の図は、アプライアンスモードサポートが有効でない場合のトラフィックフローを示しています。VPC B のアベイラビリティーゾーン 2 から発信されるレスポンストラフィックは、トランジットゲートウェイによって VPC C の同じアベイラビリティーゾーンにルーティングされます。したがって、アベイラビリティーゾーン 2 のアプライアンスは VPC A のソースからの元のリクエストを認識しないため、トラフィックはドロップされます。

    アプライアンスへのレスポンストラフィックのドロップ

    ルーティング

    各 VPCには 1 つ以上のルートテーブルがあり、トランジットゲートウェイには 2 つのルートテーブルがあります。

    VPC ルートテーブル

    VPC A と VPC B

    VPCs A と B には、2 つのエントリを持つルートテーブルがあります。最初のエントリは、 のローカルIPv4ルーティングのデフォルトエントリですVPC。このデフォルトエントリにより、この中のリソースは相互に通信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

    トランジットゲートウェイルートテーブル

    このトランジットゲートウェイは、A と VPC B に 1 VPC つのルートテーブルを使用し、共有サービス VPC (VPC C) に 1 つのルートテーブルを使用します。

    VPC A および VPC B アタッチメントは、次のルートテーブルに関連付けられています。ルートテーブルは、すべてのトラフィックを C VPC にルーティングします。

    デスティネーション ターゲット ルートタイプ

    0.0.0.0/0

    Attachment ID for VPC C

    static

    C VPC アタッチメントは、次のルートテーブルに関連付けられています。トラフィックを VPC A と VPC B にルーティングします。

    デスティネーション ターゲット ルートタイプ

    10.0.0.0/16

    Attachment ID for VPC A

    伝播済み

    10.1.0.0/16

    Attachment ID for VPC B

    伝播済み