ANS-1.5オンプレミスネットワークと AWS クラウド間のルーティング戦略と接続アーキテクチャを設計する。

ヒントボタン

シンガポールやロンドンから us-east-1 へ伸びるインターネット区間で生じる 220ms/40ms のばらつきを抑えるには、Transit Gateway の外側で AWS Global Accelerator のエッジネットワークを経由させる Accelerated Site-to-Site VPN を用い、近接 PoP までだけを公網に流して残りを Amazon Backbone で運ぶ経路最適化が遅延とジッタを劇的に改善する鍵になります。
IPsec で 1.5Gbps を安定維持するにはトンネル 1 本あたり約 1.25Gbps の上限を踏まえ、Accelerated Site-to-Site VPN を 2 本張って BGP による ECMP でアクティブ／アクティブ運用すれば帯域と冗長性を同時に確保でき、Transit Gateway ルートテーブルが複数パスを自動分散するため追加の運用負荷もほとんど増えません。
予算の制約で Direct Connect がまだ使えず現場に新機材を置かずにすぐ効果を出したい状況では、遅延・ジッタ・スループット・月間 99.95% 可用性という四つの要件を同時に満たしつつ Transit Gateway を活かし Amazon Backbone に乗れるマネージドサービスかどうかを俯瞰して選択することが総合的判断のポイントとなります。

ヒントボタン

低レイテンシ要件と今後のリージョン追加を考えると、1 本の専用線にプライベート VIF を作成して Direct Connect Gateway をハブとして使い、東京とオレゴンの Virtual Private Gateway をぶら下げる設計が有効です。DXGW は最大 200 の VGW を地域横断で収容できるため、物理回線やオンプレ側ルータ設定を増やさず新しい VPC を容易に追加できます。インターネットを経由しないため IPsec の暗号処理やベストエフォート回線の遅延変動がなく、1 Gbps の帯域を安定して活用できます。

オンプレとサンドボックス VPC を確実に分離するには、その VPC を Direct Connect Gateway に関連付けない方法がもっともシンプルかつ安全です。さらに DXGW の Allowed Prefixes で 10.0.0.0/16 と 172.16.0.0/16 だけを広告すれば 10.1.0.0/16 はクラウド側から一切流れず、オンプレ側 ACL や静的ルートより人的ミスの余地を減らせます。Transit Gateway でブラックホールを設定する案もありますが、アタッチを作らない設計は設定数が少なく意図しない経路露出を根本から排除できます。

費用と運用負荷に目を向けると、Transit Gateway への Direct Connect アタッチメントやプライベート VIF を複数本用意する方式は月額とデータ処理料が積み上がり、VPN トンネルを使う構成では装置冗長や監視コストも増えます。プライベート VIF 1 本＋DXGW＋必要な VGW だけなら追加時間課金がなく部品も少ないため障害点が減り、Allowed Prefixes で経路制御を一元化できます。低レイテンシ・拡張性・隔離・コストの四要件を総合的に俯瞰すると、この組み合わせが現時点で最も合理的な選択肢だと整理できます。

ヒントボタン

可用性99.99%かつ帯域2Gbpsを満たすには、AWS Direct Connect高可用性ガイドの要件通り、東京と大阪など物理的に分離された2つのDXロケーションに1Gbpsずつ専用線を敷設し、同一Direct Connect Gateway配下でLink Aggregation Groupを組み、各線にBGPセッションを張って障害検知を行えば、建屋断絶にも耐えつつ30秒以内に経路が収束する設計になります。
平常時に2本の専用線へ均等分散し障害時のみVPNへ迂回させるには、Transit GatewayでECMPを有効化して両プライベートVIFを同コストにしつつ、バックアップ用Site-to-Site VPNのBGP広告にAS-Pathを三回程度プリペンドして長い経路にし、DX側BGPが落ちた場合のみVPN経路が最短として選ばれるよう優先度を制御する手法が有効です。
複数VPCを束ねる場合はDirect Connect GatewayとTransit Gatewayを連携させることで経路配布を集約でき、各VIFの帯域をフル活用しながらオンプレとクラウド間を一元管理できます; 暗号化が必要な金融ワークロードではSite-to-Site VPNを併設し、Direct Connect断時の自動フェイルオーバーをBGPで実現する構成が、帯域・可用性・経路制御の全要件を総合的に満たすアプローチとなります。

ヒントボタン

要件①の10 Gbps双方向と経路可用性99.99%を実現するには、東京と大阪の両データセンターからAWS Direct Connectを2本ずつ引き、Link Aggregation Groupで束ねるのが現実的です。1回線あたり99.9%のSLAを複数本で冗長化すれば目標可用性に近づき、専用線の物理障害やポート故障を透過的に吸収できます。1 Gbpsや単一回線では帯域もSLAも不足する点、さらにロケーションを分散して地域災害に備える重要性を思い出してください。

Direct Connectにはオンプレミスから広告できるプレフィックスが100件以内という制限があります。/24が350個ならBGPで/16などに経路集約して数を減らすことが必須です。Direct Connect GatewayとTransit Gatewayを組み合わせ、7224:9100や7224:92xxといったBGPコミュニティを付与すれば東京をプライマリ、ソウルをセカンダリにでき、個別VGWを多数運用する場合と比べて経路数も運用負荷も大幅に削減できます。

専用線が切れた際に30秒以内でVPNへ自動切り替えを行うには、同じTransit GatewayにSite-to-Site VPNを張り、BGPのAS_PATHを長くして優先度を下げるだけでシンプルに実装できます。Direct Connect Gatewayを一つに統合し設定を集約すれば管理が一本化され、帯域・可用性・経路広告上限・リージョン優先・切替時間という複数要件を俯瞰して最も整合性の高い設計かどうかを判断しやすくなります。

ヒントボタン

Direct Connect からオンプレミスへの経路選択では、AWS ネットワーク内で最初に Local Preference が比較されるため、BGP コミュニティ 7224:9100 のような Very High 値を東京側に、7224:7100 のような Low 値を大阪側に設定しておくと、同一 /22 プレフィックスを広告していても東京経路が常時プライマリとして選ばれ、障害時のみ大阪へスムーズにフェイルオーバーする挙動を自然に実現できます。
オンプレミスから AWS へのトラフィックを 60:40 程度で分散したい場合は、Direct Connect のプライベート VIF で受信する二つの経路に AS_PATH プリペンドを使って長さ差を付けるのが定石であり、東京側を 0 回・大阪側を複数回プリペンドすると AWS の経路選択順序（Local Pref → AS_PATH）でほぼ狙った比率へ落ち着きます。プリペンドの回数は 2〜3 回を目安に実測しながら微調整すると効果的です。
ベストプラクティスでは、Direct Connect LAG と単回線を組み合わせる冗長設計において、AWS→オンプレは BGP コミュニティで Local Preference を明示し、オンプレ→AWS は AS_PATH で帯域配分を行い、MED や Weight といった AWS が評価しにくい属性に頼らないことが推奨されるため、これら二方向の制御方法を組み合わせた案が総合的に最も要件を満たしやすい判断となります。

ヒントボタン

Direct Connect の 99.99% SLA を達成するには、AWS ドキュメントにある通り「物理ロケーション冗長＋回線冗長」が必須です。つまり 2 つ別々の DX ロケーションに接続し、各ロケーションで 2 本以上の専用線を用意する構成が推奨となります。ロケーションが 1 か所のみ、あるいは VPN との組み合わせだけでは SLA は 99.9% に留まる点を思い出してください。さらに BGP を冗長化しておけば切替は自動で行われ、手動フェイルオーバの運用負荷も回避できます。

帯域は合計 5 Gbps 以上が条件ですが、10 Gbps 専用線を 2 本ずつ LAG にまとめれば最初から 20 Gbps を確保でき、Link Aggregation Group へ新規回線を追加するだけで将来のスループット拡張も容易です。Direct Connect Gateway から Transit Gateway へ ECMP でぶら下げれば、複数 VPC へ均等経路分散され、オンプレ 2 拠点両方ともにシンプルなルーティングで大容量を利用できます。帯域と運用性の両立を意識しましょう。

可用性を最重視する場合、単一ロケーション集中や 100 Gbps 1 本の太回線は拠点障害で一発停止となり要件を外します。また 1 Gbps 回線や VPN バックアップだけでは帯域不足や手動切替が懸念です。2 ロケーション × 2 回線 LAG と DX Gateway＋Transit Gateway＋ECMP の組み合わせなら 99.99%・20 Gbps 以上・自動スケールが揃い、可用性・性能・運用の複数要件を総合的に満たす選択となるでしょう。

ヒントボタン

Direct Connect では BGP ルートに予約コミュニティ 7224:xxxx を付与すると AWS 側の Local Preference が自動設定されます。同一リージョン回線の優先度 High は 100、Low は 98 が割り当てられ、クロスリージョンは 8 番台を使用します。ap-northeast-1 の回線をプライマリにするなら最も高い Local Preference を与える値が必要で、具体的には 7224:7100 が High、7224:7300 が Low である点を番号と効果のセットで覚えておくと混乱しません。

オンプレミス側で AS_PATH や MED を変更できない場合でも、Direct Connect Gateway と Transit Gateway 間のルートはコミュニティによる Local Preference だけで選択が決まります。東京と大阪を同じ Gateway に関連付けても、東京回線に Local Preference 100 を与え大阪回線に 98 を与えれば、通常時は東京へ集約し、障害時のみ大阪へ自動フェイルオーバーするシンプルな冗長構成が組めます。

今回のシナリオは 1 Gbps の専用回線が東京と大阪に一本ずつあり、Direct Connect Gateway を介して共通の Transit Gateway に接続する典型的二重化パターンです。AWS が公開する 7224 シリーズのコミュニティを使い、同一リージョン最優先値を東京側に、大阪側に低優先値を付与すれば要件達成となるため、変更不可の BGP 属性があってもコミュニティと Local Preference だけで経路制御を完結させるという総合判断が鍵になります。

ヒントボタン

Transit Gateway が評価する順序はローカルプリファレンス→AS_PATH→その他です。全リンクのローカルプリファレンスを既定値100で統一し、Direct Connect 東京側プライベート VIF はプリペンド無し、大阪側は自 AS を2回、Site-to-Site VPN は4回と長さを段階付けすれば、AS_PATH が最短の東京経路が常用となり、障害発生時は30秒以内に大阪→VPN へ自動で切り替わります。

オンプレミスのルータでも BGP は AS_PATH をトランジティブ属性として評価するため、クラウド側と同じ判定軸に揃えておくと戻りトラフィックも同経路を通り左右対称ルーティングが成立します。ローカルプリファレンスは自 AS 内でのみ有効で外部へは伝搬しないので、Direct Connect Gateway や Site-to-Site VPN との経路共有では意図通りに作用しない点を押さえておきましょう。

Direct Connect Gateway に静的な優先度設定は存在しないため、BGP 属性で経路選定を制御する設計が鍵です。同一プレフィックスを3リンクから広告し AS_PATH を0→2→4と調整しておけば、東京 DX→大阪 DX→VPN の順で自律的にフェイルオーバーし、30 秒以内の自動性・経路の対称性・運用の簡潔さという複数要件を同時に満たせます。

ヒントボタン

1. リンク層でFIPS 140-3準拠を実現したいときは、AWS Direct Connect の専有接続で有効化できる MACsec がほぼ唯一の手段です。Hosted Connection や Site-to-Site VPN は IPsec によるレイヤ 3 暗号化、TLS はアプリケーション層の暗号化となり要件とずれます。まずは「専有回線＋MACsec」で検討を始めると選択肢が絞れます。

2. 常時 50 Gbps をオンプレミスから送るなら、100 Gbps の専有回線を 2 本用意し LAG（Link Aggregation Group）で束ねる設計が典型です。Direct Connect の LAG はポート障害時に自動でフェイルオーバーしつつ合計 200 Gbps まで伸ばせるため、帯域確保と単一点障害排除を両立できます。Transit Gateway と組み合わせれば BGP マルチパスによる経路冗長も容易です。

3. 複数リージョンの VPC へ設定を増やさず広げたい場合、Transit VIF と Direct Connect Gateway で経路を一括広告し、各リージョンの Transit Gateway をアタッチする方法が効果的です。MACsec で暗号化、LAG で冗長化、Transit VIF でルート集約という三つの視点を同時に満たす構成を俯瞰すれば、最も合理的な設計が自ずと見えてくるはずです。

ヒントボタン

Direct Connect Gateway で集約したプレフィックスをそのまま活かしたい場合、プライベート VIF を Transit VIF に張り替えたり Transit Gateway へ乗り換えたりするとルート広告の再設計が発生します。既存のプライベート VIF を DXGW に紐付けたまま SiteLink をオンにすればルートテーブルは一切変わらず、VPC 向けのルート集約も維持したまま拠点間メッシュを後付けでき、追加設定は VIF 単位で完結します。

トラフィックを任意のリージョンや VPC に迂回させずヘアピン遅延を抑えたいときは、経路が DX バックボーン内部で閉じるかどうかが鍵です。SiteLink はプライベート VIF から直接 DXGW に入り、同一 DXGW 配下の別ロケーションへトランジットするため、ap-northeast-1 の AZ や Transit Gateway を経由しません。パケットはリージョンレイヤを抜けずにオンプレ同士で折り返すので、10 ms 級の遅延目標を専用線品質で保ちやすい構造です。

追加のオンプレ機器を置かないという制約下では、Site-to-Site VPN や Global Accelerator を組み合わせる案はハードウェア増設やインターネット経路依存で要件を外れ、Layer2 拡張は Direct Connect が L3 サービスである点と整合しません。Direct Connect SiteLink を既存 VIF に適用する方法が唯一、DX サービスだけで三つの要件を同時に充たす総合的にバランスの取れた選択となります。

ヒントボタン

レイテンシ3 ms以内という厳しい条件をAWSリージョンを経由せず満たすためには、Direct Connect拠点間を専用ネットワークで直結できるSiteLinkの活用が鍵です。SiteLinkを有効にすると、東京とシンガポールのロケーション間トラフィックはインターネットやTransit Gatewayを通らず専用線品質で流れ、VPN暗号化やリージョン経由ルーティングのオーバーヘッドを避けられるため遅延を最小化できます。

複数アカウントにある3つのVPCへプライベートIPでシンプルに接続するには、Private VIFをDirect Connect Gatewayに関連付ける方法が適しています。Direct Connect Gatewayは最大10個のVPCを一括で共有でき、マルチアカウントでも経路集約が容易です。TGWアタッチメントを使う構成は拡張性こそ高いものの、アタッチメント数・コスト・運用が増えるため今回の規模では冗長になる点を意識してください。

帯域拡張やVLAN追加時の運用負荷を抑えるには、単一のPrivate VIFを維持したままLink Aggregation Groupで回線を束ねる設計が効果的です。VPCごとに個別VLANを切ったりTransit VIFを増やす案は、BGPセッションやVLAN設定の追加変更が都度発生しますが、DX Gateway＋SiteLink＋Private VIFの組み合わせならVLAN数は固定でBGP再設定も不要なままスケールできます。

つまり、SiteLinkで低遅延オンプレ相互接続を実現し、Direct Connect Gatewayと単一Private VIFでマルチアカウントVPCの経路を集約し、LAGで拡張性を確保する構成が三つの要件をバランス良く満たす総合的な判断となります。

ヒントボタン

オンプレミスから Amazon S3 へインターネットを通さずに送信する場合、AWS Direct Connect の Public VIF で S3 のパブリックプレフィックスを受信し、BGP で S3 のみを許可するのが王道です。Private VIF や VPC 内の Gateway Endpoint はオンプレミスからは利用できないため、専用線経路を確保するには Public VIF が必須となります。1 Gbps 回線でも 5 TB/日の転送が可能で、DX 自体の 99.9% SLA によって可用性要件も満たせます。

12 か月で 50 VPC を追加する計画では、Virtual Private Gateway を個別に配置すると BGP セッションが VPC の数だけ増え運用負荷が跳ね上がります。Transit VIF から Direct Connect Gateway と Transit Gateway を経由してハブ＆スポーク化すると、オンプレミス側の BGP ピアは 1 本のまま、各 VPC は Transit Gateway にアタッチするだけでよく、ルート伝播も自動化されます。将来的な VPC 追加時の作業が最小限になる点が大きなメリットです。

コストを抑えつつ SLA 99.9% を満たすなら、1 本の DX 回線に Transit VIF と Public VIF をそれぞれ 1 つ作り、Transit VIF は DX Gateway 経由で中央の Transit Gateway へ、Public VIF は S3 のみを許可する構成がシンプルです。LAG や冗長ロケーションを追加しないため費用を削減でき、BGP セッション数も最小化できます。転送経路、拡張性、運用コストを総合的に見渡して最もバランスの取れた案を選びましょう。

ヒントボタン

国内二拠点から東京リージョンと大阪リージョンのVPCへ高スループット通信を維持しつつ、将来さらに十以上のVPCを増設しても構築作業を最小限に抑えるには、AWS Direct Connect Gateway をハブに据え、2本のプライベートVIFをぶら下げて複数リージョンのVPCをアタッチ操作だけで追加できる一元管理型のトポロジーが運用負荷を大幅に軽減します。

二本の10 Gbps回線をアクティブ／アクティブで70対30に荷重分散させたい場合、AWS側で評価される主要BGP属性はAS_PATHであるためオンプレミスルータでASパスプリペンドを行うと比率調整が容易です。Link Aggregation Groupにまとめると経路が論理的に一本化されプリペンドが効かず、Transit VIFではMEDが無視される点も押さえておきましょう。

両方のDirect Connectが同時断となってもRTO5分以内で業務を再開するには、Site-to-Site VPNをTransit Gatewayに集約しBGPフェイルオーバーで自動切替える設計が有効で、TGWを挟むことで新規VPC追加時もVPN設定が増えずルーティング伝播を一元化できるため、高可用性・経路制御・拡張性・運用簡素化という複数要件を俯瞰した総合判断として最もバランスの取れた冗長構成となります。

ヒントボタン

99.99% の可用性を目指す場合は、各オンプレ DC から別々の Direct Connect ロケーションへ 10 Gbps 専用線を敷設してプライベート VIF を張り、PoP レベルまで物理冗長化したうえで BGP に BFD を併用し HoldTimer を短縮することにより 1 秒以内の障害検知と 5 秒以内の経路収束を実現し、RTO30秒という要件を大きく上回る速さで復旧できる設計が AWS Well-Architected ネットワークの推奨です。
平均 5 Gbps・ピーク 8 Gbps をデュアルスタックでアクティブアクティブに均等配分するには片系停止時でも全量を受け止められる 10 Gbps ポートを 2 本確保することが前提となり、Site-to-Site VPN の 1 トンネル 1 Gbps 目安や Transit Gateway の ECMP では帯域が不足するため、Direct Connect の Link Aggregation Group で無停止にポートを追加できる構成にしておけば将来トラフィックが 2 倍へ伸びても回線断なく拡張でき運用負荷も最小化されます。
IPv4 と IPv6 を同一プライベート VIF に載せ AS-PATH をそろえることで Direct Connect 2 経路間の ECMP が自動的に 50:50 の負荷分散を行いますが、スタティックルートや Route 53 ヘルスチェック＋Lambda は検知が秒単位で遅れ、パブリック VIF やインターネット VPN も SLA や閉域要件を満たしにくいため、複数要件を俯瞰すると異なる DX ロケーション × 10 Gbps 専用線 × LAG × BGP/BFD の組み合わせが帯域・可用性・拡張性・運用性を同時に充足する総合的に最適な判断となります。

ヒントボタン

要件は平均 20 Gbps と障害時 10 Gbps を確保しつつ 99.99% の可用性を得ることです。AWS Direct Connect の SLA では「異なるロケーションに 2 本以上ずつ」の冗長構成が必須と記載されています。同一施設で LAG を組んだり単一 100 Gbps 回線に集約したりしても、施設障害時は一度に断となり目標に届きません。複数リージョン VPC を集約している場合は Direct Connect Gateway を介して Transit Gateway に接続すると、各ロケーションのプライベート VIF をシンプルに集約でき運用負荷も下がります。

インターネット経由の Site-to-Site VPN は手軽ですが 1 本あたりおよそ 1.25 Gbps のベストエフォートでレイテンシも高く、平均 20 Gbps を流し続ける要件と合いません。Direct Connect が切れた際に 10 Gbps を保証できず SLA 99.99% に届かないため、専用線での帯域冗長が不可欠です。さらに VPN と Direct Connect を BGP で優先度制御すると経路監視や再調整の運用負荷が増す点も踏まえて考えてみてください。

東京と大阪という物理的に離れた Direct Connect ロケーションでそれぞれ 10 Gbps ×2 の LAG を組み 20 Gbps を平滑化し、Direct Connect Gateway を通じて Transit Gateway にアタッチし BGP をアクティブ／アクティブで広告する構成なら、回線やロケーションを 1 つ失っても残り 2 本で 10 Gbps を維持できます。AWS のベストプラクティスどおりに組めば運用はシンプルで、帯域・可用性・作業量の複数要件を俯瞰しても最もバランスが整った選択となるはずです。

ヒントボタン

Direct Connect は暗号化を提供しないので、金融で必須の IPsec をどう掛け合わせるかが鍵です。Public VIF 上に Site-to-Site VPN を重ねれば追加回線なしで 1 Gbps 回線でも利用可能ですが、MACsec は 10 Gbps 専用線と高価なトランシーバが前提となり「コスト最小」「1 Gbps」という条件と噛み合わないことを思い出してください。また手動切替のみの設計では RTO 五分以内を確実に守るのが難しい点にも注意が必要です。

年 99.99% 可用性と RTO 五分以内を両立させる典型解は、各拠点の 2 本ずつを Link Aggregation Group に束ね BGP で経路制御し、優先経路を Direct Connect、代替経路をインターネット VPN にして自動フェイルオーバーさせる形です。Transit Gateway や Direct Connect Gateway を併用しておけば、回線を増やさず複数 VPC・マルチリージョンへ容易に拡張できるため、可用性と運用効率を同時に高められます。

東京と us-east-1 間のアプリ通信をオンプレミス経由にせず AWS バックボーンで完結し、暗号化・冗長性・低コストの全要件を満たすには、Direct Connect Gateway を中心に両リージョンの Transit Gateway をアタッチし、同一 LAG に Private／Public VIF を共存させて Site-to-Site VPN を張り BGP で経路を切り替えるアプローチが、可用性・セキュリティ・費用対効果を俯瞰して最もバランスが取れていると判断できます。

ヒントボタン

ヒント①
NAT を介さず IPv6 をそのまま流すには経路上の装置がすべてデュアルスタック対応であることが必須です。Transit Gateway と Site-to-Site VPN は /126 の IPv6 トンネルアドレスと BGP デュアルスタックを公式にサポートし、IPsec による暗号化も同時に実現できます。Direct Connect で IPv6 を追加しても暗号は自動付与されず、NAT64 構成は変換が入るため要件とずれる点を思い出してください。

ヒント②
合計 2 Gbps をアクティブ／アクティブで確保するうえでは帯域のスケール方法を比較するのが鍵です。Site-to-Site VPN トンネルは 1 本あたり理論 1.25 Gbps、Transit Gateway で ECMP を有効にすれば複数トンネルを束ねてスループットを高められます。VPN アタッチメントを 2 つ作れば 4 トンネルで約 5 Gbps が視野に入るため冗長性と性能を同時に満たせます。ソフトウェア VPN や単一の Direct Connect は暗号処理や回線数がボトルネックになりやすい点を比較しましょう。

ヒント③
新しい VPC を追加しても経路を手動で触りたくないなら、AWS Transit Gateway のルート自動伝播機能とオンプレミス側 BGP を組み合わせる方式が最も運用を省力化します。VPC を TGW にアタッチするだけでプレフィックスが広告され、VGW やスタティックルートの追加作業は不要です。DX Gateway を経由する案やオーケストレーションでルート配布する案は変更時の手間が残ります。デュアルスタック対応、暗号化、帯域拡張、自動経路反映のすべてを一括で満たせる構成かを俯瞰して選択してください。

ヒントボタン

オンプレミス側ルーターと Transit Gateway Connect の BGP 経路選定では、まず LOCAL_PREF が比較されるのは同一 AS 内だけで、異なる AS 間では AS_PATH の長短が優先されます。VPC でもオンプレミスでも対称ルーティングを保ちたいなら、両方向で共通して評価される AS_PATH を意識してプレペンド回数を調整する設計が鍵になります。
MED や 7224:7100 などの AWS 推奨コミュニティは、Transit Gateway が受信する側で作用しても、オンプレミス装置が同じ基準で見てくれるとは限りません。特に MED は送信 AS が同一のピア間でしか比較されないため、AS 64512 のアプライアンス同士が複数存在する今回のようなクロス AS では優先度付けに利用しづらい点に注意してください。
BGP のデフォルト Keepalive 10 秒・Hold 30 秒に任せれば、Transit Gateway Connect 上の GRE トンネルが切れても約30秒以内に短い AS_PATH の経路に自動収束し、追加料金が発生する機能や手動切替も不要です。複数要件を俯瞰すると、共通属性で制御できるシンプルな AS_PATH ベースの冗長化が最も効率的と判断できます。

ヒントボタン

ヒント1
帯域を単一トンネルで 5 Gbps まで伸ばし、かつ IPsec を使わないという条件は Site-to-Site VPN や通常の Direct Connect プライベート VIF だけでは難しいです。Transit Gateway Connect は GRE トンネルを 1 本だけで最大 5 Gbps まで処理でき、オンプレ SD-WAN 装置がすでに GRE と BGP を話せる場合にそのまま噛み合わせやすい点が強みになります。

ヒント2
約 100 経路を動的にやり取りし手動設定を減らしたいなら BGP が不可欠です。VPC ピアリングではルートは自動伝播されず静的ルートを個別に書く必要がありますが、Transit Gateway は BGP ルート伝播を受け取りルートテーブルで片方向だけ流すよう細かく制御できます。オンプレ→クラウド経路のみ広告し、他拠点へ広がらない設計にしやすい点を確認してみてください。

ヒント3
全トラフィックを一度ハブに集めて左右非対称を防ぐにはハブ＆スポーク構成が適しています。Transit Gateway を中心に VPC アタッチメントを張れば経路は一元管理でき、Connect アタッチメントで SD-WAN と直接 GRE/BGP を組むことで帯域・動的経路・フィルタリングの全要件を満たせます。総合的に判断するとハブ側で GRE を終端できるサービスの採用が最も要件に合致します。

ヒントボタン

Site-to-Site VPN 接続は 2 本の IPsec トンネルで構成され、片方が障害しても BFD や BGP Keep-Alive で自動切替わりますが帯域は 1 接続あたり理論値 1.25 Gbps 程度です。5 Gbps を平常時に確保するには同一 Transit Gateway へ複数 VPN を並列で張り、同一プレフィックスを同コストで広告し ECMP で 4 トンネルへ均等分散する設計が王道です。オンプレにルータが 2 台あるなら各ルータに 2 接続ずつ用意して 1.25×4=5 Gbps を見込み、トンネル追加もダウンタイムなく行える点が拡張のしやすさに直結します。

3 アカウント 15 VPC の環境で Virtual Private Gateway を個別に置くと、VPN 作成やルートテーブル更新が 15 か所、PSK 管理も 15 セットに増え、構成変更のたびに運用工数が膨らみます。Transit Gateway に集約すれば VPC 追加・削除はアタッチ操作のみで済み、BGP による動的伝播でルートが自動生成されます。Network Firewall や VPC エンドポイントの共通化も容易になり、将来の帯域増強時も TGW への VPN 追加だけで済むためスケールと運用負荷の両面で大きなメリットがあります。

インターネット回線前提で 5 Gbps のアクティブ-アクティブ分散、BGP 自動フェイルオーバー、Direct Connect 追加費用なし、簡単な帯域拡張という複数要件を俯瞰すると、Transit Gateway と複数 Site-to-Site VPN を組み合わせ、ECMP でトラフィックを均等化する構成がスループット・冗長性・運用効率を最もバランス良く満たす総合的な解となります。

ヒントボタン

Transit Gateway のルートテーブルはアタッチメント単位で関連付けを変えられるため、Site-to-Site VPN に伝搬させるテーブルに本番 VPC だけを関連付け、開発 VPC は別テーブルか未関連付けにすることで 10.4.0.0/16 の CIDR 自体が BGP でオンプレミスへ広告されず、経路の不可視化をシンプルに実現できます。この方式ならブラックホール静的ルートや Community タグの煩雑な設定が不要で、今後 CIDR を増やしても関連付けを変えない限りオンプレに漏れる心配がありません。

BGP を有効にした 2 本の IPsec VPN トンネルを同じ Transit Gateway ルートテーブルに載せると、ECMP と自動フェイルオーバが働き、障害発生後も数分以内に経路が収束します。静的ルートを Lambda や Route 53 Health Check で書き換える運用に比べ、動的伝搬を活用する設計はヒューマンエラーを減らし、RTO 5 分以内という条件と運用負荷最小化の両方を自然に満たせます。さらにオンプレ側で ASN 65000/65001 を使い分ければ、追加トンネル時もほぼ無停止で冗長性を拡張できます。

まとめると、Transit Gateway のルートテーブルを二層構造にし、VPN 用テーブルには本番 4 VPC と 2 本の Site-to-Site VPN を関連付け、VPC 間通信用テーブルには 5 つの VPC 全てを添付する設計が、不要な経路広告抑止、BGP 冗長化による可用性、静的設定削減という複数要件をバランス良く満たします。ルートテーブル間で伝搬を無効化すれば経路汚染も防げ、将来 Direct Connect や追加 VPC を接続する際も関連付け操作だけでポリシーを保てるため、長期的な拡張性という俯瞰的観点でも有効です。

ヒントボタン

Direct Connect を使えない状況で 5 Gbps を確保するには、VPN を複数本束ねて ECMP で並列転送する仕組みが欠かせません。Transit Gateway の VPN アタッチメントは最大 4 本の IPsec トンネルを張れ、BGP と ECMP がデフォルト有効です。4 本を 1.25 Gbps ずつ担わせれば合計 5 Gbps 相当のスループットを低コストで実現でき、オンプレ側ルータも同一 AS 内で自動的にロードシェアリングしてくれます。

フェイルオーバ時間 10 秒以内という制約は、BGP keep-alive／hold-timer を短縮する方法が現実的です。TGW VPN で BGP を使えば経路収束を数秒まで切り詰めやすい一方、スタティック VPN や VGW 直収ではトンネルヘルスチェック頼みになり検知が遅れがちです。BGP のダイナミックルーティングを活用してこそ素早い障害切替が叶う点に注目してください。

オンプレ側で個々の VPC プレフィックスを登録したくない場合、TGW でルート伝播を有効にしておくと接続された 3 つの VPC CIDR が自動広告されます。つまりオンプレ側が保有すべき経路は「TGW への集約プレフィックス」のみで済むため運用が簡素化されます。要件に並ぶ「VPNのみ・4本でECMP・10秒切替・静的登録不要」を俯瞰すると、集約ルート伝播と 4 トンネル ECMP を同時に提供できる TGW VPN が最も条件整合的であると判断できます。

ヒントボタン

50 Gbpsものアグリゲート帯域と1 秒以内のRTOを本番で安定させるには、4本の10 Gbps Direct ConnectをLAGで論理1本に束ねつつ、SD-WANアプライアンスが確立するGREトンネルをTransit Gateway Connectが終端し、BGPのマルチパス機能でECMP分散を有効化して回線障害時も即座に切替わるハブ構成が鍵になります。さらに他の選択肢で見られるVPNや個別VIFではトラフィックあたりの上限帯域や経路収束時間が制約となり、この高スループット・低RTOの要求水準を満たしきれないことに注意してください。

オンプレ両拠点が同じ10.0.0.0/16を広告しても互いに見えずVPCとは通信させたい場合、Transit GatewayのルートテーブルをDCごとに分離し、それぞれにDirect Connect Gatewayとのアソシエーションと対象VPCだけを伝播させれば、重複CIDRはテーブル間で干渉せず、動的ルーティングだけで意図した通信経路が保たれるため運用が大幅に簡素化します。スタティックルートやNAT変換での回避はポリシー変更の都度手作業が発生し、将来的なVPC追加時に設定漏れのリスクが高まります。

帯域・RTO・重複CIDR隔離・運用簡素化という四つの要件を照らし合わせると、Direct Connect Gateway＋Transit Gateway Connect＋専用ルートテーブル＋BGP ECMPという組み合わせが最新ベストプラクティスに沿い、自動経路収束で障害に強く、VPCの増減にもハブ側設定だけで追随できる点で総合的に最適と言えます。プレフィクスリスト主体の静的制御やVPCピアリングフルメッシュは拡張性に欠けるため、長期運用視点でもこの設計が推奨されます。

ヒントボタン

常時 20 Gbps 以上を余裕でさばき低遅延も確保するには、Direct Connect 10 Gbps 回線を 4 本束ねて Link Aggregation Group にするのが効果的です。LAG は論理 40 Gbps を提供し、ポート障害時も残存ポートへ自動分散できるので可用性が高く、オンプレ機器側も LACP 設定不要でシンプルに帯域とレイテンシ 50 ms 未満の要件を満たせます。

三つの VPC を個別にピアリングするとルートテーブルが分散して運用が複雑になるため、東京リージョンでは Transit Gateway をハブにして一元的に接続し、オンプレ経路は Direct Connect Gateway から同じ Transit Gateway へアタッチすると管理負荷を大幅に削減できます。DXGW と TGW の組み合わせはリージョン内利用も正式サポートされ、集中ルーティングで経路の可視性と制御性を高められます。

オンプレ側では BGP を使い AS_PATH Prepend で Direct Connect を最短経路に設定し、同一 Transit Gateway に Site-to-Site VPN アタッチメントを追加すれば、物理回線断時でも 1 分以内に暗号化トンネルへ自動フェイルオーバー可能です。LAG による帯域確保、TGW+DXGW による集中ハブ、BGP による動的優先制御という三つの観点を俯瞰し、全要件をバランス良く同時に満たせる構成かどうかを総合判断してみてください。

ヒントボタン

医療データの経路上暗号化が必須という条件では、Direct Connect 単体では暗号化されない点に注意が必要です。Transit Gateway や VGW に対し Site-to-Site VPN over Direct Connect を二重化する方法や Cloud WAN で IPsec トンネルを複数張る方法など、専用線の 10 Gbps 帯域を活かしながら IPsec を重ねる設計が候補になります。常時 5 Gbps 以上のスループットを狙うなら既存 LOA-CFA を最大限に利用できる構成に目を向けてください。

可用性 99.99% と RTO 1 分を同時に満たすには、Direct Connect の LAG で物理回線を冗長化し、Transit Gateway に対して BGP 付き VPN トンネルを少なくとも 2 本張って論理経路も二重化するのが定番です。経路属性として MED などで優先度を下げたインターネット VPN を待機させておけば、DX 障害時に 60 秒以内で自動フェイルオーバが狙えます。ECMP 分散は経路切替の判定が複雑化するため、要件の簡潔さとのバランスも検討ポイントです。

3 アカウント 6 VPC のルーティングを一元管理するには Hub-and-Spoke 方式の Transit Gateway がもっともシンプルで、単一のルートテーブルから動的に経路を配布できます。Direct Connect Gateway と個別 VGW を多数束ねる案は運用が煩雑になりやすく、Cloud WAN や SD-WAN アプライアンス主体の案は帯域や遅延 3 ms 未満の達成が難しい場面があります。性能、暗号化、可用性、運用負荷の四要件を総合的に満たす構成を俯瞰して選択しましょう。

ヒントボタン

Direct Connect を優先にして Site-to-Site VPN をバックアップにするには、Transit Gateway へ両回線で BGP セッションを張り、バックアップ側だけ AS-Path を複数回プレペンドして経路を長くするのが定石です。さらに TGW で ECMP を無効化すれば負荷分散が起きず、プライマリ／セカンダリが明確に固定されます。BGP の Keepalive 10 秒・Hold 30 秒という標準タイマーはフェイルオーバーを約 1 分以内に収束させるため、RTO 要件とも整合します。

VPC からの IPv6 を完全にアウトバウンド専用にしたい場合は Egress-Only Internet Gateway を各 VPC に配置し、ルートテーブルで ::/0 をそちらへ向ける方法が最もシンプルです。Internet Gateway では戻り方向も開放されるため NACL や Security Group だけで外部からの着信を確実に遮断するのは煩雑になります。Egress-Only IGW と Transit Gateway の組み合わせにより、IPv6 の外向き通信とオンプレミス宛てプライベートプレフィクスの両立が容易に実現できます。

オンプレミスからはプライベートアドレスだけを到達させ、かつデュアルスタックで動的経路広告したいので、Direct Connect プライベート VIF＋Transit Gateway を使い、Public VIF や NAT64 を経由させない構成が不可欠です。AS-Path による優先度制御、TGW での ECMP 抑制、Egress-Only IGW での IPv6 片方向化という要素を組み合わせる案が、冗長性・セキュリティ・運用性の三要件を最もバランス良く満たすと総合的に判断できます。

ヒントボタン

1. 50 万 pps を処理しながら OS パッチやコネ追跡の同期を気にしない構成にしたい場合、EC2 ベースの NAT インスタンスやオンプレミスのファイアウォールより、マネージドで最大 1M pps・45 Gbps 以上をさばく NAT Gateway がはるかに運用負荷とスループットの両面で有利です。NAT Gateway は自動スケールと高可用性がサービスに含まれ、パッチ適用やメンテナンスを考慮しなくてもよいため「OS 運用を最小化」という要件に直結します。

2. ホワイトリストを単一アドレス 203.0.113.10 に集約するには Elastic IP を 1 つだけ使い続ける必要があります。EIP は同時に複数リソースへ割り当てられないため、複数 NAT Gateway を並列に置くと送信元が分散します。CloudWatch で StatusUnavailable を監視し、Lambda が当該 EIP を保持したまま NAT Gateway を再作成して Transit Gateway ルートを更新する自動化を組めば、障害発生から数分以内に待機 AZ へ引き継げるため RTO 5 分の目標を達成しやすくなります。

3. Transit Gateway のデフォルトルートを単一点の NAT Gateway に向けておけば、Direct Connect 経由のオンプレ DC と VPC からのインターネット通信を同じ送信元 IP に統合できます。DX 障害時に全通信が停止する経路設計や、SaaS 側へ /32 を複数登録させる設計は要件との整合が難しいため、マネージド NAT Gateway＋EIP 固定＋CloudWatch/Lambda フェイルオーバーを組み合わせる案が性能・可用性・運用性を総合的に満たす最適解と俯瞰的に判断できます。

ヒントボタン

3 Gbps／90 万 pps を機械的にさばき、同じ AZ 内でセルフヒーリングさせるには、EC2 ベースの NATインスタンスでは水平スケールやルート切替の運用が煩雑になりがちです。Public NAT Gateway も単一 AZ 障害で停止します。各 AZ に配置でき 45 Gbps まで伸びる Private NAT Gateway なら可用性と性能の両面で余裕があり、要件 1 を満たしやすいと考えてみてください。

転送コストを抑えるには、トラフィックを別 AZ へ横断させないことが重要です。VPC のルートテーブルで B 社向けプレフィックスだけを同じ AZ の Private NAT Gateway に静的ルーティングすれば、Transit Gateway を経由しないため AZ 間データ転送料を防げますし、送信と返却が同経路になるので左右非対称ルートも回避できます。

一度 100.64.1.0/24 を Transit Gateway のルートテーブルにスタティック登録しておけば、その経路は Direct Connect へ自動伝播され、以後のルートメンテナンスは最小限で済みます。性能・可用性・コスト・運用負荷の四つの要件を俯瞰すると、各 AZ に Private NAT Gateway を置き TGW で経路を広告する構成が最もバランスの取れた選択肢と言えるでしょう。

ヒントボタン

要件①の「クラウドとオンプレ通信は常時暗号化」を満たすには AWS Direct Connect のプライベート VIF 上に Site-to-Site VPN over Direct Connect を載せると、同一リンクを流れるトラフィックが常時 IPsec で包まれ、専用の MACsec 機材や追加回線を買わず Virtual Private Gateway だけで済み、暗号化と優先経路が一致するので運用の複雑さも抑えられます。
要件②の「DX 断後30秒以内の自動フェイルオーバー」は BGP と BFD を併用した二本の Site-to-Site VPN トンネルが鍵で、Direct Connect が切れても同一トンネルが即座にインターネットへ再ダイヤルし VGW が動的ルートを広告し続けるため、オンプレ側はタイマー値調整だけでスタティック変更なく RTO をクリアできます。
左右対称ルーティングとコスト最小化を両立させるには Direct Connect Gateway と Virtual Private Gateway を一対一で関連付けて単一 ASN で BGP を流し、プライベート VIF 上の IPsec トンネルだけで経路を集約すれば Transit Gateway やパブリック VIF を増やさず済み、DX 優先・VPN バックアップの三要件を俯瞰した総合判断として最も合理的です。

ヒントボタン

可用性99.95%とRTO30秒以内という数字は、Site-to-Site VPNで推奨される2トンネル×2系統＝計4トンネル構成を示唆します。静的ルートだけでは切替検知が遅れますが、Virtual Private GatewayとBGPを併用すればDead Peer DetectionやHold Timerで数十秒以内に再収束し、Customer Gatewayの片系障害も吸収できるため単一点障害を排除できます。

オンプレ→AWS方向をDC-A常用、DC-B待機としつつAWS→オンプレ方向は常に最短経路にしたい場合、BGP属性のLOCAL_PREFとAS_PATHプリペンドが鍵です。拠点ごとに独立したCustomer Gatewayを用意するとルータ設定を分離でき、2本ずつ張ったVPNトンネルをアップ状態のままでも、Virtual Private GatewayはAS_PATHの短い経路を選びロードシェアを抑止できます。

インターネット回線1本だけの前提でTransit GatewayやDirect Connectを追加するとコストと運用工数が増え「運用負荷は極小」という要件に反します。Virtual Private Gatewayの自動フェイルオーバーとBGP属性制御だけで①高可用性②速いRTO③プライマリ／スタンバイ④片方向経路固定⑤低運用負荷を同時に満たす構成が総合的に最も理にかなっています。

ヒントボタン

オンプレ拠点からAWSへ低遅延で暗号化トンネルを張りたい場合、Virtual Private Gateway を使う従来のIPsec VPNはインターネット経路のばらつきによりRTTが伸びがちです。一方、Accelerated Site-to-Site VPN は AWS Global Accelerator の PoP を介して最適経路へルーティングされるため、40 ms以内のレイテンシを狙いやすく、さらに BGP による動的経路交換で最大1,000ルートを自動学習でき、スタティック設定の手間を大幅に削減できます。

複数 VPC に個別接続を作ると運用が煩雑になり、障害時も通信が遠回りしがちです。Transit Gateway をハブに据えると 2 つの VPC を一か所でアタッチでき、Centralized routing が可能になります。ここに各データセンターから BGP セッションを 2 本ずつ張り、Transit Gateway で ECMP を有効化すれば 4 本すべてが同時にアクティブとなり、BFD と組み合わせたヘルスチェックで 1 分未満のフォールオーバーと 99.9% 以上の可用性を実現しやすくなります。

Direct Connect はコスト上不可、暗号化必須、40 ms以下の遅延、99.9% 以上の可用性、1,000 ルートの動的学習、自動フェイルオーバー、運用簡素化という制約を並べて総合的に評価すると、Accelerated Site-to-Site VPN を東京・大阪から二重化し Transit Gateway で集中ルーティングと ECMP を行う構成のみがすべての要件を同時に満たすことが読み取れます。

ヒントボタン

4 Gbps を均等利用したい場合、2 × 1 Gbps 回線を LAG 化して Direct Connect Gateway に Transit VIF を集約し、複数 Transit Gateway と関連付ければ ECMP が自動で働きます。プライベート VIF やリージョン間 VIF を個別に張る方式では帯域が分散しにくく、将来リージョンが増えるたびに配線と BGP セッションを追加する手間が発生する点を踏まえて考えてみてください。

障害時 1 分以内の切替は Transit Gateway に Site-to-Site VPN を同コストで並列し、BGP の AS_PATH や MED で Direct Connect 優先にしておくと実現できます。VGW の Dead Peer Detection や SD-WAN オーバーレイだけに頼ると 90 秒以上かかるケースもあり要件に届きません。暗号化トンネルが同時に確保できフェイルバックも自動化されるため、運用監視の負担を減らせる構成を意識しましょう。

広告経路 8,000 本とアカウント単位フィルタリングは Direct Connect Gateway の prefix filter と上限 10,000 が適合し、Transit VIF がリージョン非依存であるため将来 TGW を追加しても VIF や BGP の再構築は不要です。帯域集約、迅速フェイルオーバー、経路スケール、拡張性の四要件を横断的に評価し、最も構成要素が少なく運用が単純な案を選びましょう。

ヒントボタン

Transit Gateway(TGW) に接続した Site-to-Site VPN は ECMP を有効化すると 8 本までをハッシュで並列転送できますが、デフォルトでは BGP が 1 経路のみを選ぶため帯域が細くなります。追加コストなくリンクアグリゲーションを実現する第一歩は TGW ルートテーブルで ECMP サポートをオンにし、複数トンネルを同価値として認識させることです。

ECMP を機能させるには BGP が各経路を完全に同一コストと判断できるよう属性を揃える必要があります。同一プレフィックス、AS-PATH、MED、Community などを 4 トンネルすべてで一致させれば Transit Gateway は Equal-Cost と判断し均等に分散します。オンプレミスルータで Local-Pref や Weight を変えず統一した広告を行うことが帯域合算と冗長化の鍵です。

30 秒以内のフェイルオーバーは Site-to-Site VPN の BGP keepalive／hold-timer が標準で満たしており、経路撤回後は自動で残りのリンクへ切り替わります。新たに Direct Connect を追加したりスタティックルートへ依存する方法は費用や収束時間が増える傾向があるため、まず既存 4 トンネルで ECMP 条件を揃えるだけで帯域・可用性・コストを同時に最適化できるかを全要件を俯瞰して判断すると良いでしょう。

ヒントボタン

要件の8 Gbps超という帯域をインターネット経由で安定確保するには、Accelerated Site-to-Site VPNの1トンネル最大約1.25 Gbpsを2トンネル束ねて2.5 Gbpsとし、これを関東DCと関西DCへ2接続ずつ張ってBGP ECMPでアクティブ-アクティブ利用すると理論値10 Gbpsになり十分余裕を持てます。Direct Connect 1 Gbps×2はバックアップに回せば既存コストを活かしつつ初期投資を抑制でき、VPN課金の従量性とも相性が良いです。

平常時30 ms未満の遅延と障害発生から30 秒以内の自動フェイルオーバーを両立する鍵はGlobal Accelerator経由のAccelerated VPNとBGPのKeepalive/HoldTimerです。Transit Gateway上でECMPを有効にしておくと経路喪失を素早く検知し残りのトンネルへ即時切替えが可能です。オンプレ各ASNに対しDirect Connect経路へMEDやAS-PATHで低優先度を設定しておけば、4本のVPNが全断した場合のみDXに自動昇格しRTO 5 分を十分に満たせます。

年内に5 VPCを無停止で拡張するには東京リージョンのTransit Gatewayをハブとし、既存3 VPCと新規5 VPCを順次アタッチするだけでルーティングが自動伝搬します。各VPCにVGWやSD-WANアプライアンスを個別配置する方式と比べ設定が一元化され運用負荷も低下します。DX Gatewayを介して既設Direct Connectを待機接続としてぶら下げれば、帯域・レイテンシ・可用性・コスト・拡張性という複数要件を総合的に見ても最もバランスの取れた構成になります。

ヒントボタン

要件はインターネットゲートウェイを一切経由せずにオンプレミスから Amazon S3 に 200 MB/s で夜間同期することです。VPC 内にプライベート IP の ENI を複数 AZ で置き、その /32 を Virtual Private Gateway から BGP 広告すればオンプレミスは VPN 内で直接 HTTPS を張れます。このように外部ネットワークへ引き込めるプライベート終端を提供できるのは AWS PrivateLink ベースの S3 インターフェイス型 VPC エンドポイントだけである点を思い出してください。

ゲートウェイエンドポイントはサブネットのルートテーブル内でのみ機能し VGW やオンプレミスに経路を配れず、NAT Gateway は必ず IGW を経由するため閉域要件を外れます。Transit Gateway は集約に便利ですが時間課金とデータ処理課金が高く、既に 2 本の Site-to-Site VPN がある小規模構成では「追加コスト最小化」の観点で見合わないケースが多いことを頭に入れておくと選択肢を絞りやすくなります。

したがって「プライベート通信を徹底する」「既存 BGP VPN の冗長性を活かす」「追加料金を抑える」という三つの要件を総合的に満たす最もシンプルな設計は、VPC に S3 インターフェイス型 VPC エンドポイントを AZ ごとに配置し、その ENI のプライベート IP を /32 で広告してオンプレミスから閉域接続する構成であると整理できます。

ヒントボタン

重複した10.0.0.0/16のオンプレ環境に安全に到達するには、VPC側の172.16.0.0/16をそのままBGPで広告するとCIDRが衝突します。Transit GatewayとDirect Connect Gateway間のルート表で、Private NAT Gatewayにより100.64.0.0/16などのCarrier-Grade NAT帯へ一意変換した後のプレフィックスだけを広告すれば、オンプレには変換後アドレスしか見えず競合を回避できます。Private NATはアウトバウンド発端の通信のみを許可し逆方向の新規セッションを破棄するため、片方向通信というセキュリティ要件にも合致します。

5,000接続/秒かつ40 Gbps超を処理するトラフィックでは、m5n.largeなどのNATインスタンスはENI上限やCPU負荷で性能が頭打ちになり、手動スケールや障害対応も運用負荷が高くなります。マネージド型のNAT Gatewayは1台で最大45 Gbps、AZ単位で配置すれば可用性と帯域を自動で確保できます。PrivateタイプならInternet Gatewayを伴わず、Direct Connectだけに経路を閉じられるため、インターネット経路を混在させたくない金融SaaSのガバナンス要件にも適合します。

①VPC発のみに限定するフロー制御、②40 Gbps超を支えるマルチAZ冗長の高性能NAT、③オンプレに広告するプレフィックスを変換後アドレスだけに絞るBGPルート制御――これら三つの要件を俯瞰すると、Private NAT Gatewayを各AZに配置しTransit Gatewayで広告フィルタを行う設計が全項目を同時に満たします。Public NATやNATインスタンス、単一AZ構成では帯域・片方向性・CIDR競合・可用性のいずれかで不足が残る点を比較して判断してみてください。