AWS Hybrid Connectivity Direct Connect VPN TGW 統合運用 Vol2

1. なぜHybrid Connectivityか — Network Vol1からの架橋 + AWS本番運用 Hybrid統合結節点

クラウド移行が進む現代でも、オンプレミスとAWSを繋ぐ「Hybrid Connectivity」は本番運用の根幹です。Vol1 (VPC設計基礎) で確立したTGW/Lattice/PrivateLinkの内部接続をベースに、本Vol2ではオンプレ↔AWS統合の全技術スタックを体系的に解説します。Direct Connect・Site-to-Site VPN・Transit Gateway × DX Gateway・Hybrid DNSの4本柱を設計判断の軸とともに体系化します。

1-1. Hybrid Connectivityが必要になる3つの場面

クラウド移行の過渡期

全システムを一括でクラウド移行することは現実的ではありません。レガシー基幹システム、ライセンス制約のあるソフトウェア、移行コストが高い大型データベースは、長期にわたってオンプレミスに残留します。この過渡期において、オンプレ↔AWS間の安定した接続は「移行の橋」であり、事業継続の前提条件です。

段階的な移行では「アプリ層はAWS・DBはオンプレ」という分離構成が一般的です。この状態でアプリとDBが毎秒通信するため、ネットワーク経路の安定性・レイテンシ・帯域は直接ビジネス影響を持ちます。

規制・コンプライアンス要件

金融機関、医療機関、官公庁では、データの保管場所やネットワーク経路に厳格な規制があります。「顧客データはオンプレに置きつつ、AI/分析処理はAWSで実施する」というハイブリッド構成が規制対応の現実解となるケースが多くあります。

通信の閉域性を担保するため、インターネット経由のVPNではなく物理専用線 (Direct Connect) が要件として明記されている場合も少なくありません。

低レイテンシ・高帯域が必要な業務

工場の生産システムと連携するIoTデータ収集、大容量映像データの転送、金融取引システムのリアルタイム処理など、専用線品質が求められる業務ではDirect Connect (DX) が必須です。DXは物理専用線のため、インターネットVPNと比較してレイテンシが安定し、帯域保証もあります。

1-2. Vol1からの架橋 — 内部設計からHybrid拡張へ

Vol1ではAWS内部のネットワーク設計を体系化しました。Vol2はその延長線上でオンプレ統合を扱います。

Vol1のTGWが「AWS内部のルーティングハブ」であったのに対し、Vol2のTGW × DX Gatewayは「オンプレ↔AWS全体のルーティングハブ」へと進化します。1つのDX Gatewayから複数のVPC・複数のAWSリージョンへ接続できる点が最大の強みです。

1-3. 本書で扱う4本柱

本Vol2はHybrid Connectivityを支える4つの主要技術を体系的に解説します。

Direct Connect (§2)
物理専用線によるオンプレ↔AWS低レイテンシ・高帯域接続。Dedicated/Hosted Connection、MACsec暗号化、Resiliency 3パターン (Maximum/High/Development)、LAG、BGP制御をTerraform例付きで詳説します。

Site-to-Site VPN (§3)
IPsecトンネルによるインターネット経由暗号化接続。Active/Active構成、BGP Route制御 (local-pref / AS_PATH prepend)、DPD、Accelerated VPNを解説します。DXと組み合わせたHAフェイルオーバー設計も扱います。

Transit Gateway × DX Gateway統合 (§4)
複数VPC/Regionにまたがる集約接続の中核。Transit VIF、Associations、Allowed Prefix、Inter-Region peeringをMulti-Account設計 (AWS RAM) とともに実践的に解説します。

Hybrid DNS (§5)
オンプレDNS ↔ Route 53 Resolver の名前解決ブリッジ。Inbound/Outbound Endpoint、Forwarding Rule、DNS Firewall、Resolver query loggingを体系化します。

1-4. AWS本番運用9軸でのHybrid Connectivityの位置付け

本シリーズが対象とするAWS本番運用の9軸において、Network Vol2 (Hybrid Connectivity) は以下の軸と強く連携します。

Hybrid Connectivityはオンプレ↔AWSの「物理インフラ接続層」であると同時に、9軸全体が依存するネットワーク基盤でもあります。以降の§では各技術を設計判断の視点で詳説します。

1-5. DX vs Site-to-Site VPN — 接続方式の設計判断マトリクス

Direct ConnectとSite-to-Site VPNはどちらもオンプレ↔AWS接続を実現しますが、特性が大きく異なります。本§では両者の比較と選定基準を整理します。詳細は§2 (DX) と§3 (VPN) で解説します。

選定の基準:

Direct Connectを選ぶ場合:
– 安定した高帯域が必要 (大容量データ転送・低レイテンシ業務)
– 閉域性が規制要件として求められる (金融・医療・官公庁)
– 長期的な大量データ転送で転送コストを最適化したい
– MACsec (L2暗号化) が必要

Site-to-Site VPNを選ぶ場合:
– 短期的な接続が必要 (PoC / 移行期間限定)
– DXの調達期間中のバックアップ接続として
– 低コストで複数拠点を繋ぎたい
– DXのフェイルオーバーパス (Primary DX + Backup VPN 構成)

本番運用の推奨パターン:
多くの本番環境では「Primary: Direct Connect (High Resiliency) + Backup: Site-to-Site VPN」のHA構成が最適解です。DX障害時にBGP切替でVPNに自動フェイルオーバーする設計を§6で詳説します。

2. Direct Connect 詳細 — Dedicated / Hosted / MACsec / Resiliency 3パターン / LAG / BGP

Direct Connect (DX) は、AWS Direct Connect ロケーション (POP) を経由してオンプレミスネットワークとAWSを物理専用線で接続するサービスです。インターネット経由のVPNとは異なり、専用帯域・一貫したレイテンシ・SLA保証が特徴です。接続タイプ・冗長パターン・BGP設計の3軸で設計判断を行います。

2-1. Dedicated Connection vs Hosted Connection

Direct Connectの物理接続には2つのタイプがあり、帯域要件・調達スピード・コストで使い分けます。

Dedicated Connection (占有接続)

AWSが提供する1Gbps、10Gbps、100Gbpsの物理ポートを顧客が専有します。

resource "aws_dx_connection" "dedicated" {
  name= "corp-dx-dedicated"
  bandwidth = "10Gbps"
  location  = "EqTY2"  # Direct Connect Location コード (東京: EqTY2 等)

  tags = {
 Environment = "production"
  }
}

Hosted Connection (ホスト接続)

AWSパートナー (Direct Connect Partner) が物理ポートを所有し、顧客は帯域をサブリースします。

選択基準:

2-2. MACsec — L2レベルの物理暗号化

MACsec (IEEE 802.1AE) は、Ethernetフレームレベルで暗号化を行うL2セキュリティプロトコルです。VPN (L3暗号化) とは異なり、物理回線上のすべてのフレームを暗号化します。金融機関や高セキュリティ要件の環境で有効です。

resource "aws_dx_connection" "macsec" {
  name= "corp-dx-macsec"
  bandwidth = "10Gbps"
  location  = "EqTY2"
  request_macsec  = true
  encryption_mode = "must_encrypt"  # must_encrypt (強制) / should_encrypt (任意)

  tags = {
 Environment = "production"
 Security = "macsec-enabled"
  }
}

resource "aws_dx_macsec_key_association" "main" {
  connection_id = aws_dx_connection.macsec.id
  ckn  = var.macsec_ckn # Connectivity Association Key Name (hex文字列)
  cak  = var.macsec_cak # Connectivity Association Key (hex文字列)
}

encryption_mode = "must_encrypt" を設定すると、MACsecが確立できない場合に通信が遮断されます。導入初期は should_encrypt でフォールバックを許可しつつ動作確認し、安定後に must_encrypt へ変更することを推奨します。

2-3. Resiliency 3パターン — SLAと冗長性の設計判断

AWSはDirect Connectの冗長構成として3つのパターンを定義しています。物理障害の許容範囲とコストのトレードオフで選択します。

Maximum Resiliency (SLA 99.99%)

[オンプレルータA] ─── [DX Location A / ポート1] ─── AWS
└─── [DX Location A / ポート2] ─── AWS

[オンプレルータB] ─── [DX Location B / ポート1] ─── AWS
└─── [DX Location B / ポート2] ─── AWS

最小でも2拠点のDX Locationを使用します。東京では EqTY2 (Equinix TY2) と AT Tokyo など異なる物理施設を選択することが重要です。同一施設の2ポートではLocation障害に対して冗長になりません。

High Resiliency (SLA 99.9%)

[オンプレルータA] ─── [DX Location A / ポート1] ─── AWS

[オンプレルータB] ─── [DX Location B / ポート1] ─── AWS

大半の本番環境ではHigh Resiliencyで十分です。コストと耐障害性のバランスが取れた構成です。

Development and Test (SLA 99%)

本番環境でのDevelopment and Test構成は避けてください。DX単体でHigh Resiliency未満の場合は、バックアップVPNを必ず追加してください (§6で詳説)。

2-4. LAG — Link Aggregation Group

LAG (Link Aggregation Group) は、複数の物理DX接続を1つの論理接続として束ねる機能です。帯域の線形拡張と物理ポート冗長を同時に実現します。

resource "aws_dx_lag" "main" {
  name= "corp-dx-lag"
  connections_bandwidth = "10Gbps"
  location  = "EqTY2"

  tags = {
 Environment = "production"
  }
}

resource "aws_dx_connection" "lag_member_1" {
  name= "corp-dx-lag-member-1"
  bandwidth = "10Gbps"
  location  = "EqTY2"
  lag_id = aws_dx_lag.main.id
}

resource "aws_dx_connection" "lag_member_2" {
  name= "corp-dx-lag-member-2"
  bandwidth = "10Gbps"
  location  = "EqTY2"
  lag_id = aws_dx_lag.main.id
}

LAGは同一DX Locationの複数ポートを束ねるため、Location障害には対応できません。帯域拡張が主目的の場合に有効です。Location冗長にはHigh Resiliency以上 (異なるLocation) を選択してください。

2-5. BGP設定 — ASN / Private ASN / BGP Community / MD5認証

Direct ConnectはBGP (Border Gateway Protocol) を使用してルーティング情報を交換します。適切なASN設計とセキュリティ設定が安定運用の鍵です。

ASN (Autonomous System Number) 設計

resource "aws_dx_gateway" "main" {
  name= "corp-dxgw"
  amazon_side_asn = "64512" # AWS側が使用するASN (DX Gateway単位で設定)
}

resource "aws_dx_private_virtual_interface" "main" {
  connection_id = aws_dx_connection.dedicated.id
  name = "corp-dx-private-vif"
  vlan = 4093# VLANタグ (1-4094、オンプレと一致必須)
  address_family= "ipv4"
  bgp_asn = 65000  # オンプレ側ASN
  bgp_auth_key  = var.bgp_md5_key # MD5認証キー (32文字以内)
  dx_gateway_id = aws_dx_gateway.main.id

  tags = {
 Environment = "production"
  }
}

BGP Community タグ

DX PrivateVIFでは以下のBGP Communityタグで経路広告範囲を制御できます。

MD5認証

BGPセッションの不正確立を防ぐため、MD5認証キーの設定を強く推奨します。bgp_auth_key に設定した値はオンプレルータ側の neighbor X.X.X.X password と一致させてください。キーはTerraform変数 (var) で管理し、ソースコードにハードコードしないことが重要です。

AWS Direct Connect 公式ドキュメント → 料金・接続タイプ・Resiliency詳細を確認する

3. Site-to-Site VPN (山場1) — Active/Active + BGP Route制御 + DPD + Accelerated VPN

AWS Site-to-Site VPN は IPsec プロトコルを使ってオンプレミス拠点と AWS VPC 間に暗号化トンネルを確立するマネージドサービスだ。各 VPN 接続には常に 2本のトンネル が自動作成される。この冗長設計はアベイラビリティゾーンをまたいだ AWS 側の可用性確保のためであり、1本のみ使う構成は推奨されない。

3-1 IPsec のフェーズ構成

IPsec トンネル確立は 2 つのフェーズに分かれる:

AWS は IKEv2 を推奨する。IKEv1 は後方互換のためにサポートされているが、新規設計では IKEv2 の採用が標準だ。認証方式は Pre-Shared Key (PSK) と Certificate-based (PKI) の 2 種類があり、大規模環境では PKI 認証が望ましい。

3-2 Customer Gateway と接続先の選択

Customer Gateway (CGW): オンプレミスの VPN デバイスを AWS 側で定義するリソース。BGP を使う場合は ASN を指定する。接続先は用途によって 2 択となる:

本番環境では TGW への VPN アタッチメント が標準的な選択になる。TGW は VPN/DX/VPC を一元的に接続するハブになり、VGW を VPC ごとに立てるスケーラビリティの限界を解消する。また Accelerated VPN や ECMP も TGW 必須機能であるため、新規設計では TGW 一択と考えてよい。

3-3 Active/Active 構成 — 2トンネル × 2 VPN 接続

VPN の高可用性設計における最重要の判断は Active/Active か Active/Standby かだ。

Active/Standby の問題点:
– 1本のトンネルがプライマリ、もう1本がスタンバイで待機
– フェイルオーバー時に BGP セッションが切断されるため接続断が発生
– 帯域が最大 50% しか有効活用されない

Active/Active 構成の全体像:

オンプレ CGW-A ──VPN接続1── TGW
├─ tunnel1 (AZ-a) ──▶ ECMP 分散
└─ tunnel2 (AZ-b) ──▶ ECMP 分散

オンプレ CGW-B ──VPN接続2── TGW
├─ tunnel1 (AZ-a) ──▶ ECMP 分散
└─ tunnel2 (AZ-b) ──▶ ECMP 分散

2台の CGW × 2本のトンネル = 合計 4本のトンネル で ECMP (Equal-Cost Multi-Path) 分散を実現する。TGW は ECMP をネイティブにサポートしており、BGP セッションが確立されている全トンネルに対してトラフィックを均等分散する。

ECMP の必要条件:
– BGP を使用 (Static routing では ECMP 不可)
– TGW で vpn_ecmp_support = "enable" を設定
– 全トンネルで同一の BGP prefix を広告
– オンプレ側ルーターが ECMP に対応

3-4 BGP Route 制御 — local-pref / AS_PATH prepend / MED

複数の経路が存在するハイブリッド環境でトラフィックの優先経路を制御する際、BGP 属性の理解は不可欠だ。Hybrid Connectivity では特に以下の 3 属性が重要になる。

① local-preference (local-pref)

local-pref は AS 内の経路優先度を設定する属性で、値が高いほど優先される。外部 AS には伝播しない内部属性であり、DX/VPN 間の優先切替に最もよく使われる。

• DX 優先設計: DX 経由 local-pref=200 / VPN 経由 local-pref=100
• 方向: オンプレ BGP ルーターが AWS からの受信経路に対して設定

# オンプレ BGP 設定例 (Cisco IOS-XE 概念)
route-map SET_PREF_DX permit 10
  set local-preference 200

route-map SET_PREF_VPN permit 10
  set local-preference 100

router bgp 65000
  neighbor <DX_BGP_PEER_IP>  route-map SET_PREF_DX  in
  neighbor <VPN_BGP_PEER_IP> route-map SET_PREF_VPN in

② AS_PATH prepend

AS_PATH prepend は経路の AS パスを人工的に長くして、他の AS からの経路選択を誘導する属性だ。BGP のベストパス選択ではより短い AS_PATH が優先されるため、prepend を付加した経路は優先度が下がる。

• 用途: AWS 側から VPN ではなく DX を使わせたい場合、VPN 側から広告する経路に prepend を付加
• 方向: オンプレ → AWS 方向 (外部 AS へ広告する際に付加)

# VPN 側は DX より優先度を下げる (AS_PATH を 3 回付加)
route-map VPN_PREPEND permit 10
  set as-path prepend 65000 65000 65000

router bgp 65000
  neighbor <VPN_AWS_BGP_PEER_IP> route-map VPN_PREPEND out

③ MED (Multi-Exit Discriminator)

MED は同一の隣接 AS への複数の出口経路に優先度のヒントを示す属性だ。ただし強制力は低く、相手 AS が MED を考慮しない場合もある。Hybrid Connectivity では local-pref と AS_PATH prepend で制御するのが主流で、MED は補助的に使う。

BGP 属性の優先順位 (高い順):

3-5 Dead Peer Detection (DPD) — トンネル死活監視

DPD は IKE セッションの死活監視プロトコルだ。ピアが応答しなくなった際にトンネルを検知して対処する仕組みで、Hybrid Connectivity の自動フェイルオーバー設計では必須の機能だ。

DPD のパラメータ:

タイムアウトアクションの選択指針:
– clear: ピア断後にトンネルを削除する。Active/Active 構成では BGP が他トンネルへ自動切替するため推奨
– restart: トンネル再確立を試みる。単一トンネル環境では restart が安全
– none: AWS 側から何もしない。レガシー互換のためのみ。新規設計では使用しない

DPD タイムアウト後、BGP セッションが切断され、残存トンネルまたは DX への BGP フェイルオーバーが起動する。DX 側の local-pref が高い設計になっていれば、DX 正常時は VPN BGP が失効しても問題なく DX 経由で通信が継続される。

3-6 Accelerated VPN — AWS Global Accelerator 経由の最適化

通常の Site-to-Site VPN は、パブリックインターネット経由で AWS リージョンエンドポイントに接続する。レイテンシはインターネット品質に依存するため、地理的に離れた拠点では不安定になりやすい。

Accelerated VPN は AWS Global Accelerator を活用し、VPN トラフィックをインターネットではなく AWS バックボーンネットワーク 経由で転送するオプションだ。

Accelerated VPN は TGW VPN アタッチメントにのみ対応している。VGW ベースの VPN では使用できないため、Accelerated VPN を採用する場合は TGW への移行が前提となる。

3-7 Terraform 実装例 — Active/Active + Accelerated VPN

# 1台目 Customer Gateway
resource "aws_customer_gateway" "primary" {
  bgp_asn = 65000# オンプレ側 ASN
  ip_address = "203.0.113.10"# 1台目 VPN デバイスのパブリック IP
  type = "ipsec.1"
  tags = { Name = "corp-cgw-primary" }
}

# 2台目 Customer Gateway (Active/Active 用)
resource "aws_customer_gateway" "secondary" {
  bgp_asn = 65000
  ip_address = "203.0.113.20"# 2台目 VPN デバイスのパブリック IP
  type = "ipsec.1"
  tags = { Name = "corp-cgw-secondary" }
}

# TGW (ECMP 有効化)
resource "aws_ec2_transit_gateway" "main" {
  amazon_side_asn  = 64512
  vpn_ecmp_support = "enable"
  default_route_table_association = "enable"
  default_route_table_propagation = "enable"
  tags = { Name = "main-tgw" }
}

# VPN 接続 1 (TGW 経由・BGP・Accelerated VPN)
resource "aws_vpn_connection" "primary" {
  customer_gateway_id = aws_customer_gateway.primary.id
  transit_gateway_id  = aws_ec2_transit_gateway.main.id
  type = "ipsec.1"
  static_routes_only  = false
  enable_acceleration = true
  tunnel1_ike_versions= ["ikev2"]
  tunnel2_ike_versions= ["ikev2"]
  tunnel1_dpd_timeout_seconds  = 30
  tunnel2_dpd_timeout_seconds  = 30
  tunnel1_dpd_timeout_action= "restart"
  tunnel2_dpd_timeout_action= "restart"
  tags = { Name = "corp-vpn-primary" }
}

# VPN 接続 2 (Active/Active の 2 本目)
resource "aws_vpn_connection" "secondary" {
  customer_gateway_id = aws_customer_gateway.secondary.id
  transit_gateway_id  = aws_ec2_transit_gateway.main.id
  type = "ipsec.1"
  static_routes_only  = false
  enable_acceleration = true
  tunnel1_ike_versions= ["ikev2"]
  tunnel2_ike_versions= ["ikev2"]
  tunnel1_dpd_timeout_seconds  = 30
  tunnel2_dpd_timeout_seconds  = 30
  tunnel1_dpd_timeout_action= "restart"
  tunnel2_dpd_timeout_action= "restart"
  tags = { Name = "corp-vpn-secondary" }
}

MTU 注意点: IPsec トンネルのオーバーヘッドにより有効 MTU が 1500 から 1436 バイト に縮小する。オンプレ側と AWS 側の双方で MSS Clamping (TCP MSS = 1379) を設定しないと、大きなパケットがサイレントにドロップする事象が発生する。Path MTU Discovery が正常に機能しない環境では特に注意が必要だ。

3-8 NAT-T — NATデバイス越しの VPN 接続

オンプレ VPN デバイスがプライベート IP アドレスを持ち、インターネット側に NAT デバイスを経由して接続している環境では、IPsec の ESP パケットが NAT によって破棄される問題が発生する。この問題を解消するのが NAT-T (NAT Traversal) だ。

• ESP パケットを UDP ポート 4500 でカプセル化し NAT を通過できるようにする
• IKE フェーズ 1 の中で双方が NAT の存在を検知すると自動的に NAT-T モードに切り替わる
• AWS の Site-to-Site VPN では NAT-T がデフォルトで有効

NAT 環境での確認事項:
– オンプレ VPN デバイスが NAT-T (UDP 4500) をサポートしていることを確認
– ファイアウォールで UDP 4500 (NAT-T) と UDP 500 (IKE) を双方向に許可
– NAT デバイスの PAT セッションタイムアウトが IKE keepalive より長いことを確認

3-9 VPN 監視 — CloudWatch Metrics による死活検知

Site-to-Site VPN の稼働状態は CloudWatch Metrics で継続監視できる。本番環境では以下のメトリクスを CloudWatch Alarms に設定しておくことを強く推奨する。

# VPN トンネル DOWN アラーム
resource "aws_cloudwatch_metric_alarm" "vpn_tunnel_down" {
  alarm_name = "vpn-primary-tunnel-down"
  comparison_operator = "LessThanOrEqualToThreshold"
  evaluation_periods  = 5
  metric_name= "TunnelState"
  namespace  = "AWS/VPN"
  period  = 60
  statistic  = "Average"
  threshold  = 0

  dimensions = {
 VpnId = aws_vpn_connection.primary.id
  }

  alarm_description = "VPN トンネルが 5 分間 DOWN 状態"
  alarm_actions  = [aws_sns_topic.alerts.arn]
}

Active/Active 構成では 4 本のトンネルそれぞれに TunnelState アラームを設定する。1本のトンネルが DOWN しても ECMP で他のトンネルが補うが、放置すると残りのトンネルに負荷が集中するリスクがある。早期検知と通知の仕組みが運用品質の鍵だ。

sequenceDiagram
 participant DX as Direct Connect
 participant VPN as Site-to-Site VPN
 participant TGW as Transit Gateway
 participant VPC as VPC

 Note over DX,TGW: Normal: DX Active (local-pref 200)
 DX->>TGW: BGP Route Advertisement
 TGW->>VPC: Traffic via DX

 Note over DX,TGW: DX Down → BFD/DPD Detect
 DX--xTGW: Link Down
 VPN->>TGW: BGP Failover (local-pref 100)
 TGW->>VPC: Traffic via VPN (failover)

4. Transit Gateway × DX Gateway 統合 (山場2) — Transit VIF / Associations / Allowed Prefix / Inter-Region peering

DX Gateway と Transit Gateway を組み合わせることで、単一の Direct Connect 回線から複数の AWS VPC やリージョンへのアクセスを一元化できる。この統合アーキテクチャは大規模なハイブリッド環境の設計基盤となる。

4-1 DX Gateway — リージョン横断の集約点

DX Gateway はグローバルリソースで、特定の AWS リージョンに縛られない。1 つの DX 物理回線 (または LAG) を複数のリージョンの VPC や TGW に接続する際の集約点として機能する。

DX Gateway の主要な特徴:
– グローバルリソース (リージョン非依存)
– 最大 10 の Virtual Gateway または Transit Gateway に関連付け可能
– 1 つの DX Gateway に最大 30 の Virtual Interface を関連付け可能
– 異なる AWS アカウントの VGW/TGW への接続をサポート

接続経路の全体像:

オンプレ拠点
 │
 ▼
Direct Connect 物理回線 (Dedicated/Hosted)
 │
 ▼
Direct Connect Location (POP)
 │
 ▼
[Transit VIF — VLAN/BGP/MTU]
 │
 ▼
DX Gateway (グローバルリソース)
 │
 ├──▶ TGW (ap-northeast-1) ──▶ VPC-A, VPC-B, VPC-C
 │
 └──▶ TGW (us-east-1) ──▶ VPC-D, VPC-E  ← Inter-Region 拡張

4-2 Transit VIF — DX から TGW への仮想インターフェース

VIF (Virtual Interface) は DX 物理回線上に作成する論理インターフェースで、3 種類ある:

TGW を活用するハイブリッド構成では Transit VIF を選択する。Transit VIF の設定パラメータ:

Jumbo Frame (MTU 8500) の活用: Transit VIF では MTU 8500 のジャンボフレームを有効化できる。VPN (MTU 1436) と比べてオーバーヘッドが小さく、大量データ転送で throughput が向上する。ただし VPC 側のネットワークも MTU 8500 に対応させる必要がある。

4-3 DX Gateway Association と Allowed Prefix 設計

DX Gateway と TGW を関連付けた後、Allowed Prefix の設計が最も重要なステップとなる。

Allowed Prefix とは: TGW から DX Gateway (さらにオンプレ) へ BGP 広告する CIDR のホワイトリストだ。ここに登録した CIDR だけがオンプレ側に広告される。

設計の原則:
1. 最小権限: オンプレに見せる CIDR は必要最小限にする (全 VPC CIDR を無制限に広告しない)
2. 集約表現: 個別 CIDR より集約 CIDR (/16 等) で広告してルートテーブルを小さく保つ
3. 衝突回避: オンプレ CIDR と AWS CIDR のオーバーラップを事前に確認

典型的な Allowed Prefix 設計:

TGW に接続された VPC 群:
  VPC-A: 10.1.0.0/16
  VPC-B: 10.2.0.0/16
  VPC-C: 10.3.0.0/16

DX Gateway Allowed Prefix (個別指定):
  10.1.0.0/16  ← VPC-A のみ広告
  10.2.0.0/16  ← VPC-B のみ広告
  10.3.0.0/16  ← VPC-C のみ広告

または集約指定 (VPC CIDR が 10.x.x.x に統一されている場合):
  10.0.0.0/8← 10.x.x.x 全体を広告 (オーバーラップに注意)

Allowed Prefix の落とし穴: 広すぎる CIDR (0.0.0.0/0 や /8 範囲) を設定すると、AWS が管理する内部 CIDR も誤ってオンプレに広告してしまう可能性がある。また TGW Route Table の衝突の原因になることも多い。

4-4 TGW Route Table — アタッチメント分離設計

TGW はデフォルトで全アタッチメントが同一のルートテーブルを共有する。しかし本番環境では 用途別にルートテーブルを分離 することが推奨される。

分離が必要なシナリオ:

TGW Route Table 構成の概念:

TGW Route Table (prod):
  関連付け: VPC-A (prod), VPC-B (prod), DX アタッチメント
  伝播:VPC-A → 10.1.0.0/16, VPC-B → 10.2.0.0/16, DX → 192.168.0.0/16

TGW Route Table (staging):
  関連付け: VPC-C (staging)
  伝播:VPC-C → 10.3.0.0/16  ← DX への伝播は無効化

4-5 Inter-Region TGW Peering

複数の AWS リージョンに TGW を展開している場合、Inter-Region TGW Peering で Region をまたいだ接続が可能になる。

Inter-Region TGW Peering の特徴:
– AWS バックボーンネットワーク経由 (インターネット不使用)
– リクエスト/承認モデル (片方が Peering Attachment を作成し、相手が承認)
– 異なるアカウントの TGW とも Peering 可能
– BGP ではなく静的ルートテーブルエントリで接続先を設定

BGP が使えない点の注意: TGW Peering Attachment は BGP をサポートしない。接続先の CIDR は TGW Route Table に静的に設定する必要があり、CIDR 変更時の運用負荷になる。

Cross-Region BGP の ASN 設計推奨:
– ap-northeast-1 TGW: Amazon side ASN = 64512
– us-east-1 TGW: Amazon side ASN = 64513
– リージョンごとに異なる ASN を設定することで、将来的な Direct Connect 統合時の経路制御を明確化する

4-6 Multi-Account 設計 — AWS RAM による DX Gateway 共有

大規模なマルチアカウント環境では、DX Gateway を 1 つのネットワーキングアカウントに集約し、AWS Resource Access Manager (RAM) を使って各 BU アカウントの TGW に共有するパターンが主流だ。

共有の仕組み:
1. ネットワーキングアカウントで DX Gateway を所有
2. RAM でターゲットアカウント (または OU) に DX Gateway を共有
3. 各アカウントで TGW Association を作成

この設計により、各 BU は自分の TGW を保持しつつ、オンプレとの DX 接続は一元管理できる。マルチアカウントシリーズで解説した Landing Zone 設計と組み合わせることで、スケーラブルなハイブリッド基盤が完成する。

4-7 Terraform 実装例

# DX Gateway
resource "aws_dx_gateway" "main" {
  name= "corp-dx-gateway"
  amazon_side_asn = "64512"
}

# DX 物理回線 (Dedicated Connection)
resource "aws_dx_connection" "main" {
  name= "corp-dx-connection"
  bandwidth = "1Gbps"
  location  = "EqTY2"# Direct Connect Location コード
  tags= { Name = "corp-dx-connection" }
}

# Transit VIF (DX 物理回線 → DX Gateway)
resource "aws_dx_transit_virtual_interface" "main" {
  connection_id = aws_dx_connection.main.id
  name = "corp-transit-vif"
  vlan = 200
  address_family= "ipv4"
  bgp_asn = 65000 # オンプレ側 BGP ASN
  amazon_address= "169.254.0.1/30"  # AWS 側 BGP ピア IP
  customer_address = "169.254.0.2/30"  # オンプレ側 BGP ピア IP
  bgp_auth_key  = var.bgp_auth_key  # MD5 パスワード (推奨)
  mtu  = 8500  # Jumbo Frame 有効化
  dx_gateway_id = aws_dx_gateway.main.id
}

# DX Gateway → TGW Association
resource "aws_dx_gateway_association" "main" {
  dx_gateway_id= aws_dx_gateway.main.id
  associated_gateway_id = aws_ec2_transit_gateway.main.id

  # TGW から DX Gateway 経由でオンプレへ広告する CIDR
  allowed_prefixes = [
 "10.1.0.0/16",  # VPC-A CIDR
 "10.2.0.0/16",  # VPC-B CIDR
 "10.3.0.0/16",  # VPC-C CIDR
  ]
}

# Inter-Region TGW Peering (ap-northeast-1 → us-east-1)
resource "aws_ec2_transit_gateway_peering_attachment" "cross_region" {
  provider = aws.us_east_1
  transit_gateway_id= aws_ec2_transit_gateway.us_east_1.id
  peer_transit_gateway_id = aws_ec2_transit_gateway.main.id
  peer_region = "ap-northeast-1"
  tags = { Name = "tgw-peering-apne1-use1" }
}

# Peering 承認 (ap-northeast-1 側)
resource "aws_ec2_transit_gateway_peering_attachment_accepter" "cross_region" {
  transit_gateway_attachment_id = aws_ec2_transit_gateway_peering_attachment.cross_region.id
  tags = { Name = "tgw-peering-accepted" }
}

# TGW Route Table にスタティックルートを追加 (Inter-Region 向け)
resource "aws_ec2_transit_gateway_route" "to_us_east_1" {
  transit_gateway_route_table_id = aws_ec2_transit_gateway.main.association_default_route_table_id
  destination_cidr_block= "10.100.0.0/16"  # us-east-1 VPC CIDR
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_peering_attachment.cross_region.id
}

4-8 BGP 広告の双方向制御 — TGW から DX Gateway への経路とオンプレからの受信経路

DX Gateway + TGW 統合では BGP 経路制御が双方向で発生する。設計時に両方向の経路を明確にしておかないと、意図しない経路でトラフィックが流れるリスクがある。

AWS → オンプレ 方向 (TGW から DX Gateway 経由):

TGW に関連付けられた VPC のルートは BGP Propagation で TGW Route Table に載り、DX Gateway Allowed Prefix に設定された CIDR がオンプレへ広告される。

VPC-A (10.1.0.0/16) の BGP 伝播経路:
  VPC-A → TGW Route Table (propagation ON)
→ DX Gateway (Allowed Prefix に 10.1.0.0/16 が含まれる場合のみ)
→ Transit VIF (BGP NLRI: 10.1.0.0/16)
→ オンプレ BGP ルーター

オンプレ → AWS 方向 (DX Gateway から TGW 経由):

オンプレ BGP ルーターが Transit VIF に対して広告したプレフィックスは DX Gateway を経由して TGW Route Table に伝播される。

オンプレ (192.168.0.0/16) の BGP 広告経路:
  オンプレ BGP ルーター → Transit VIF (BGP NLRI: 192.168.0.0/16)
→ DX Gateway
→ TGW Route Table (propagation ON で自動追加)
→ VPC-A, VPC-B の route table に 192.168.0.0/16 が伝播

双方向制御のチェックリスト:

5. Hybrid DNS — Route 53 Resolver Inbound/Outbound Endpoint / Forwarding Rule / DNS Firewall

5-1. Hybrid DNS が必要な理由

AWS VPC とオンプレミスが共存する環境では、DNS 名前解決が 2 つの世界に分断される。

問題: オンプレのアプリが rds01.aws.internal を引けない。AWS のアプリが ldap.corp.example.com を引けない。
解決: Route 53 Resolver の Inbound/Outbound Endpoint でブリッジを構築する。

• Inbound Endpoint: オンプレ → AWS の Private Hosted Zone 解決 (受口)
• Outbound Endpoint + Forwarding Rule: AWS → オンプレ DNS 転送 (出口)

5-2. Route 53 Resolver Inbound Endpoint

Inbound Endpoint はオンプレ DNS からの条件付きフォワードを受け付ける ENI 群。

動作フロー:
1. オンプレ DNS で条件付きフォワーダーを設定: *.aws.internal → Inbound Endpoint IP
2. オンプレクライアントが rds01.aws.internal をクエリ → オンプレ DNS → Inbound ENI へ転送
3. Route 53 Resolver が Private Hosted Zone / AWS 内部 DNS で解決
4. 結果をオンプレ DNS 経由でクライアントへ返す

Security Group 設計:
– Inbound: TCP/UDP 53 をオンプレ CIDR のみ許可
– Public Subnet 配置はアンチパターン — 必ず Private Subnet を使う

resource "aws_route53_resolver_endpoint" "inbound" {
  name= "hybrid-dns-inbound"
  direction = "INBOUND"
  security_group_ids = [aws_security_group.resolver_inbound.id]

  ip_address {
 subnet_id = aws_subnet.private_az1.id
  }
  ip_address {
 subnet_id = aws_subnet.private_az2.id
  }

  tags = {
 Name = "hybrid-dns-inbound"
  }
}

resource "aws_security_group" "resolver_inbound" {
  name= "resolver-inbound-sg"
  vpc_id = aws_vpc.main.id

  ingress {
 from_port= 53
 to_port  = 53
 protocol = "tcp"
 cidr_blocks = [var.on_premises_cidr]
  }
  ingress {
 from_port= 53
 to_port  = 53
 protocol = "udp"
 cidr_blocks = [var.on_premises_cidr]
  }
  egress {
 from_port= 0
 to_port  = 0
 protocol = "-1"
 cidr_blocks = ["0.0.0.0/0"]
  }
}

Terraform 適用後に割り当てられた ENI の IP アドレス (例: 10.1.1.10, 10.1.2.10) をオンプレ DNS の条件付きフォワーダーに登録する。

5-3. Route 53 Resolver Outbound Endpoint + Forwarding Rule

Outbound Endpoint は AWS VPC 内のアプリがオンプレ DNS ドメインを解決する際の出口。Forwarding Rule で転送先オンプレ DNS IP を紐付ける。

resource "aws_route53_resolver_endpoint" "outbound" {
  name= "hybrid-dns-outbound"
  direction = "OUTBOUND"
  security_group_ids = [aws_security_group.resolver_outbound.id]

  ip_address {
 subnet_id = aws_subnet.private_az1.id
  }
  ip_address {
 subnet_id = aws_subnet.private_az2.id
  }

  tags = {
 Name = "hybrid-dns-outbound"
  }
}

resource "aws_security_group" "resolver_outbound" {
  name= "resolver-outbound-sg"
  vpc_id = aws_vpc.main.id

  egress {
 from_port= 53
 to_port  = 53
 protocol = "tcp"
 cidr_blocks = [var.on_premises_cidr]
  }
  egress {
 from_port= 53
 to_port  = 53
 protocol = "udp"
 cidr_blocks = [var.on_premises_cidr]
  }
}

resource "aws_route53_resolver_rule" "forward_corp" {
  domain_name = "corp.example.com"
  name  = "forward-to-onprem"
  rule_type= "FORWARD"
  resolver_endpoint_id = aws_route53_resolver_endpoint.outbound.id

  target_ip {
 ip = var.on_premises_dns_ip_1
  }
  target_ip {
 ip = var.on_premises_dns_ip_2
  }

  tags = {
 Name = "forward-corp-to-onprem"
  }
}

resource "aws_route53_resolver_rule_association" "forward_corp" {
  resolver_rule_id = aws_route53_resolver_rule.forward_corp.id
  vpc_id  = aws_vpc.main.id
}

マルチVPC展開: RAM (Resource Access Manager) で Forwarding Rule を組織内全 VPC に共有できる。Transit Gateway 配下の全 VPC で同一オンプレ DNS 転送ルールを再利用する場合は RAM 共有が推奨。

resource "aws_ram_resource_share" "resolver_rule" {
  name = "resolver-rule-share"
  allow_external_principals = false
}

resource "aws_ram_resource_association" "resolver_rule" {
  resource_arn = aws_route53_resolver_rule.forward_corp.arn
  resource_share_arn = aws_ram_resource_share.resolver_rule.arn
}

resource "aws_ram_principal_association" "org" {
  principal = data.aws_organizations_organization.this.arn
  resource_share_arn = aws_ram_resource_share.resolver_rule.arn
}

5-4. DNS Firewall — ドメインベースのアウトバウンド制御

Route 53 Resolver DNS Firewall はアウトバウンドの DNS クエリをドメインリストでフィルタリングする。マルウェアの C2 (Command & Control) 通信を DNS 層でブロックする場合に有効。

resource "aws_route53_resolver_firewall_domain_list" "blocked" {
  name = "blocked-malware-domains"
  domains = ["malware-c2.example.com", "phishing-site.example.net"]
  tags = { Name = "dns-firewall-blocklist" }
}

resource "aws_route53_resolver_firewall_rule_group" "main" {
  name = "hybrid-dns-firewall-rules"
  tags = { Name = "hybrid-dns-firewall-rules" }
}

resource "aws_route53_resolver_firewall_rule" "block_malware" {
  name  = "block-malware-domains"
  action= "BLOCK"
  block_response = "NODATA"
  firewall_domain_list_id = aws_route53_resolver_firewall_domain_list.blocked.id
  firewall_rule_group_id  = aws_route53_resolver_firewall_rule_group.main.id
  priority = 100
}

resource "aws_route53_resolver_firewall_rule_group_association" "vpc" {
  name = "firewall-association"
  firewall_rule_group_id = aws_route53_resolver_firewall_rule_group.main.id
  vpc_id  = aws_vpc.main.id
  priority= 101
  mutation_protection = "DISABLED"
}

block_response の選択肢:
– NODATA: 空応答 (RCODE NOERROR だが答えなし) — アプリが無限再試行しない
– NXDOMAIN: ドメイン不存在 (RCODE NXDOMAIN)
– OVERRIDE: 代替 IP (サニタイズページ等) に転送

5-5. Resolver Query Logging

DNS クエリのログを記録し、セキュリティ分析・トラブルシューティングに活用する。

resource "aws_route53_resolver_query_log_config" "main" {
  name= "hybrid-dns-query-log"
  destination_arn = aws_cloudwatch_log_group.dns_queries.arn
}

resource "aws_cloudwatch_log_group" "dns_queries" {
  name  = "/aws/route53/resolver/query-logs"
  retention_in_days = 90
}

resource "aws_route53_resolver_query_log_config_association" "vpc" {
  resolver_query_log_config_id = aws_route53_resolver_query_log_config.main.id
  resource_id= aws_vpc.main.id
}

ログには query_name、rcode、answers、vpc_id、instance_id が含まれる。不審ドメインへのアクセスを CloudWatch Logs Insights で検出できる。

sequenceDiagram
 participant Client as AWS Client
 participant OE as Route53 Outbound Endpoint
 participant OnPrem as On-premises DNS
 participant IE as Route53 Inbound Endpoint
 participant R53 as Route53 Resolver

 Client->>R53: Query corp.example.com
 R53->>OE: Forwarding Rule match
 OE->>OnPrem: Forward to On-prem DNS
 OnPrem-->>OE: Response
 OE-->>Client: Answer

 Client->>OnPrem: Query aws.internal
 OnPrem->>IE: Forward to Inbound Endpoint
 IE->>R53: Resolve aws.internal
 R53-->>IE: Answer
 IE-->>OnPrem: Response
 OnPrem-->>Client: Answer

6. Failover/HA設計 — DX↔VPN フェイルオーバー + Terraform完全例

6-1. Failover 設計の基本方針

Hybrid 環境における Failover の核心は DX (Direct Connect) を Primary、VPN を Backup として BGP で制御すること。

Active/Passive 構成 (推奨):
– DX: BGP local-pref=200 (高優先) → 通常時はDX経由でトラフィック転送
– VPN: BGP local-pref=100 (低優先) → DX断時のみ自動切替
– 切替検知: BFD (Bidirectional Forwarding Detection) または BGP hold timer で数秒以内に検知

Active/Active 構成 (高スループット要件):
– DX + VPN 両方を常時使用 (ECMP)
– DX断時はVPNのみに自動切替
– スループット要件が高い場合に検討 (Accelerated VPN 併用)

6-2. BGP 制御 — AWS → オンプレ方向 (local-pref)

local-pref は 同一 AS 内 で使う属性。オンプレ BGP ルーターが AWS からの受信経路に設定し、DX と VPN どちらを優先するかを制御する。

# オンプレ BGP ルーター設定例 (Cisco IOS-XE 概念)
route-map SET_PREF_DX permit 10
  set local-preference 200

route-map SET_PREF_VPN permit 10
  set local-preference 100

router bgp 65000
  neighbor <DX_BGP_PEER_IP>  route-map SET_PREF_DX  in
  neighbor <VPN_BGP_PEER_IP> route-map SET_PREF_VPN in

DX 側で受け取った経路に local-pref=200 を付与することで、オンプレ → AWS 方向のトラフィックが DX 経由になる。DX BGP セッションが切断されると local-pref=200 の経路が消え、VPN 経由 (local-pref=100) に自動切替する。

6-3. BGP 制御 — オンプレ → AWS 方向 (AS_PATH prepend)

AS_PATH prepend は オンプレ → AWS 方向を制御する。VPN 経路の AS_PATH を長く見せることで DX を優先させる。

# VPN 側は DX より優先度を下げる (AS_PATH を 3 回付加)
route-map VPN_PREPEND permit 10
  set as-path prepend 65000 65000 65000

router bgp 65000
  neighbor <VPN_AWS_BGP_PEER_IP> route-map VPN_PREPEND out

AWS 側は DX 経路 (AS_PATH 短) を優先し、DX 断時に VPN 経路 (AS_PATH 長) へ自動切替する。

6-4. BFD と DPD — フェイルオーバー検知速度

BFD (Bidirectional Forwarding Detection):
– DX の BGP セッション上で使用
– 通常の BGP hold timer (90秒) より高速に障害を検知 (1秒以内)
– DX 物理障害 → BFD Down → BGP session Down → VPN への即時切替

DPD (Dead Peer Detection):
– IPsec VPN トンネルの死活検知
– dpd_timeout_action = "restart" でトンネルを自動再確立

6-5. Terraform 完全例 — DX + VPN + TGW Failover 3-Tier 構成

Tier 1: Primary DX

resource "aws_dx_connection" "primary" {
  name= "dx-primary-1gbps"
  bandwidth = "1Gbps"
  location  = "EqTY2"

  tags = {
 Name = "dx-primary"
 Role = "primary"
  }
}

resource "aws_dx_gateway" "main" {
  name= "hybrid-dx-gateway"
  amazon_side_asn = "64512"
}

resource "aws_dx_private_virtual_interface" "primary" {
  connection_id = aws_dx_connection.primary.id
  name = "dx-primary-vif"
  vlan = 100
  address_family= "ipv4"
  bgp_asn = 65000
  amazon_address= "169.254.0.1/30"
  customer_address = "169.254.0.2/30"
  dx_gateway_id = aws_dx_gateway.main.id

  tags = {
 Name = "dx-primary-vif"
  }
}

Tier 2: Backup VPN

resource "aws_customer_gateway" "main" {
  bgp_asn = 65000
  ip_address = var.on_premises_public_ip
  type = "ipsec.1"

  tags = {
 Name = "onprem-customer-gw"
  }
}

resource "aws_vpn_connection" "backup" {
  customer_gateway_id = aws_customer_gateway.main.id
  transit_gateway_id  = aws_ec2_transit_gateway.main.id
  type = "ipsec.1"
  static_routes_only  = false

  tunnel1_dpd_timeout_action  = "restart"
  tunnel1_dpd_timeout_seconds = 30
  tunnel2_dpd_timeout_action  = "restart"
  tunnel2_dpd_timeout_seconds = 30

  tags = {
 Name = "dx-backup-vpn"
 Role = "backup"
  }
}

Tier 3: TGW + DX Gateway Association

resource "aws_ec2_transit_gateway" "main" {
  description= "hybrid-tgw"
  amazon_side_asn  = 64512
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"
  vpn_ecmp_support = "enable"
  dns_support= "enable"

  tags = {
 Name = "hybrid-transit-gateway"
  }
}

resource "aws_ec2_transit_gateway_route_table" "hybrid" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  tags= { Name = "hybrid-route-table" }
}

resource "aws_dx_gateway_association" "tgw" {
  dx_gateway_id= aws_dx_gateway.main.id
  associated_gateway_id = aws_ec2_transit_gateway.main.id

  allowed_prefixes = [
 "10.0.0.0/8",
 "172.16.0.0/12",
  ]
}

resource "aws_ec2_transit_gateway_route_table_propagation" "dx" {
  transit_gateway_attachment_id  = aws_dx_gateway_association.tgw.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.hybrid.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "vpn" {
  transit_gateway_attachment_id  = aws_vpn_connection.backup.transit_gateway_attachment_id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.hybrid.id
}

6-6. フェイルオーバー検証と CloudWatch 監視

# DX Virtual Interface の BGP 状態確認
aws directconnect describe-virtual-interfaces \
  --query 'virtualInterfaces[].{Name:virtualInterfaceName,State:virtualInterfaceState,BGP:bgpPeers[].bgpStatus}'

# TGW route table のアクティブ経路確認
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-xxxxxxxx \
  --filters "Name=state,Values=active"

# VPN トンネル状態確認
aws ec2 describe-vpn-connections \
  --query 'VpnConnections[].VgwTelemetry[].{OutsideIP:OutsideIpAddress,Status:Status,LastChange:LastStatusChange}'

フェイルオーバー切替時間の目安:
– BFD 有効時: 1-3 秒 (DX BGP session Down 検知 + VPN 経路採用)
– BFD 無効時: BGP hold timer (デフォルト 90 秒) + VPN 切替で最大 2-3 分

resource "aws_cloudwatch_metric_alarm" "dx_bgp_down" {
  alarm_name = "dx-bgp-session-down"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = 1
  metric_name= "ConnectionBpsIngress"
  namespace  = "AWS/DX"
  period  = 60
  statistic  = "Sum"
  threshold  = 1000

  dimensions = {
 ConnectionId = aws_dx_connection.primary.id
  }

  alarm_description = "Direct Connect 接続異常 — VPN フェイルオーバー中"
  alarm_actions  = [aws_sns_topic.alerts.arn]
}

7. 詰まりポイント7選 + アンチパターン→正解変換演習 ≥5件

Direct Connect/VPN/TGW/Hybrid DNS を実際に構築・運用すると、ドキュメントには書かれていない「落とし穴」に何度もはまる。本節では頻出の7つの詰まりポイントを「なぜ詰まるか → どう解くか」2段構成で整理し、演習5問でアンチパターン→正解変換を体験する。

7-1. 詰まり① — DX 申込から開通まで4〜8週間かかる

なぜ詰まるか

Direct Connect の物理回線調達は、申込後に Cross-Connect 工事が必要なため通常4〜8週間のリードタイムが発生する。PoC をクラウド側だけで準備して「完成したら DX をつなごう」と計画すると、開通を待つ間ずっと Site-to-Site VPN を使い続けることになり設計変更が後追いになる。Hosted Connection を ISP 経由で発注する場合も、ISP の工程が別途入るため同様かそれ以上の期間を見込む必要がある。

どう解くか

PoC 初日から Site-to-Site VPN を構築し「DX 本番開通後に VPN は Failover/Backup 用として残す」設計を最初から決定する。TGW へのアタッチメントを DX/VPN 両方共通にしておけば、開通後は aws_dx_transit_virtual_interface を追加して BGP local-pref を調整するだけで切り替えられる。

# PoC 段階から TGW を中心にした構成にしておく
resource "aws_vpn_connection" "poc_vpn" {
  customer_gateway_id = aws_customer_gateway.onprem.id
  transit_gateway_id  = aws_ec2_transit_gateway.main.id  # 最初から TGW
  type = "ipsec.1"
  static_routes_only  = false  # BGP を有効化 (DX 移行後も再利用)
}

7-2. 詰まり② — BGP 経路が期待通りに流れない

なぜ詰まるか

BGP の経路選択は AS_PATH length / local-pref / MED / Community の優先順位が複雑で、「TGW に local-pref を設定したら全部 DX に寄った」「VPN も同じ local-pref で設定したら ECMP でランダムになった」という事例が多い。特にオンプレ側のルーター設定と AWS 側の BGP 属性が噛み合わず、戻りトラフィックが非対称経路になるケースが多発する。

どう解くか

AWS → オンプレ方向は TGW 側の BGP local-pref で制御する。DX 側: local-pref 200、VPN 側: local-pref 100 が標準構成。オンプレ → AWS 方向は AS_PATH prepend で制御し、VPN 経由の経路に prepend を付与して DX 経路を優先させる。Community 属性 (7224:7300 等) は local-pref と AS_PATH を固めてから導入する上級テクニック。

# オンプレルーター側 BGP 設定例 (Cisco IOS 概念)
# VPN 経由の経路に AS_PATH prepend を付けて DX を優先させる
router bgp 65001
 neighbor 169.254.10.1 route-map VPN_PREPEND out
route-map VPN_PREPEND permit 10
 set as-path prepend 65001 65001

7-3. 詰まり③ — TGW route table でブラックホールルート

なぜ詰まるか

TGW Route Table には BGP propagation (動的) と static route (静的) の2種類がある。static route を先に設定した後で propagation を有効にすると、static が優先されてブラックホールになることがある。Attachment が削除された後も static route が残存して「経路はあるのにパケットが届かない」状況が生まれる。Allowed Prefix を /8 や /16 の広いCIDRで設定すると、複数 VPC の経路と衝突するケースも多い。

どう解くか

原則として BGP propagation を主軸にし、static route は「propagation で賄えない例外ルーティング」にのみ使う。Attachment 削除時は関連 static route も同時に Terraform で削除し、terraform plan で経路差分を事前確認する習慣を付ける。

# BGP propagation を有効化 (DX Virtual Interface Attachment)
resource "aws_ec2_transit_gateway_route_table_propagation" "dx" {
  transit_gateway_attachment_id  = aws_dx_transit_virtual_interface.main.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.workload.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "vpn" {
  transit_gateway_attachment_id  = aws_vpn_connection.backup.transit_gateway_attachment_id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.workload.id
}

# static route は例外CIDRのみ (Attachment 削除時に必ず一緒に削除)
resource "aws_ec2_transit_gateway_route" "exception" {
  destination_cidr_block= "10.99.0.0/24"
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.exception.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.workload.id
}

7-4. 詰まり④ — Hybrid DNS 転送ループ

なぜ詰まるか

Route 53 Resolver の Outbound Endpoint に Forwarding Rule を設定する際、転送先のオンプレ DNS サーバー IP として「Outbound Endpoint 自身の IP」を誤って指定するループが発生する。また、オンプレ DNS の Conditional Forwarder で AWS 内部ドメインを Inbound Endpoint IP に向けるのを忘れると、オンプレ → AWS の名前解決が失敗し続ける。

どう解くか

Outbound Endpoint の転送先は必ずオンプレ DNS の実 IP (例: 192.168.1.53) を指定し、AWS Resolver の IP は指定しない。Inbound/Outbound Endpoint は別サブネット/AZ に分けて配置し、Security Group で UDP/TCP 53 のみ許可する。

resource "aws_route53_resolver_rule" "onprem_dns" {
  domain_name = "corp.example.internal"
  name  = "onprem-forward"
  rule_type= "FORWARD"
  resolver_endpoint_id = aws_route53_resolver_endpoint.outbound.id

  target_ip {
 ip= "192.168.1.53"  # オンプレ DNS の実 IP (Resolver IP は不可)
 port = 53
  }
}

# Forwarding Rule の転送先 IP を確認
aws route53resolver list-resolver-rules \
  --filters Name=Name,Values=onprem-forward \
  --query 'ResolverRules[].TargetIps'

7-5. 詰まり⑤ — DPD タイムアウトで VPN 断続

なぜ詰まるか

Dead Peer Detection (DPD) は VPN トンネルの死活監視プロトコルだが、DPD interval と retry 回数のデフォルト値がオンプレルーターと AWS の間でミスマッチになり、実際の障害がない状況でも DPD タイムアウトが頻発してトンネルが再ネゴシエーションを繰り返すことがある。AWS VPN トンネル内の最大パケットサイズは 1436 バイトになるため、BGP セッションを張るルーターの MTU を未調整のまま放置すると Path MTU Discovery 不全で断続的な通信障害が起きる。

どう解くか

AWS Site-to-Site VPN の DPD デフォルトは 30 秒間隔・3 リトライ。オンプレ側と一致させることが最優先。MTU は 1500 → 1436 に設定するか TCP MSS clamping を適用する。TunnelState CloudWatch メトリクスでアラームを設定して早期検知する。

resource "aws_cloudwatch_metric_alarm" "vpn_tunnel_down" {
  alarm_name = "vpn-tunnel-state-down"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = 2
  metric_name= "TunnelState"
  namespace  = "AWS/VPN"
  period  = 60
  statistic  = "Minimum"
  threshold  = 1
  alarm_description= "VPN トンネル断検知"

  dimensions = {
 VpnId = aws_vpn_connection.backup_vpn.id
  }
}

7-6. 詰まり⑥ — MACsec 対応ルーターの選定ミス

なぜ詰まるか

MACsec (IEEE 802.1AE) は物理イーサネット層の暗号化のため、対応ハードウェアが必須。AWS 側は 10Gbps / 100Gbps の Dedicated Connection のみ対応で Hosted Connection は非対応。オンプレ側も MACsec 対応 NIC / Router が必要で、XPN (Extended Packet Numbering: パケット番号 32bit → 64bit 拡張) 要件を見落として機器選定すると、暗号化ネゴシエーションが失敗する。

どう解くか

MACsec を採用する場合は、対応機器リスト (Cisco ASR/Nexus、Juniper MX/EX、Arista 7050X3 等) で機器を確認する。Hosted Connection では MACsec は使えない点に注意。request_macsec = true を設定する前に、接続先 Direct Connect Location での MACsec サポートを確認する。

resource "aws_dx_connection" "macsec_conn" {
  name  = "macsec-10g-connection"
  bandwidth= "10Gbps"
  location = "EqSY2"
  provider_name  = "Equinix"
  request_macsec = true  # Dedicated 10G/100G のみ有効
}

resource "aws_dx_macsec_key_association" "main" {
  connection_id = aws_dx_connection.macsec_conn.id
  ckn  = var.connectivity_association_key_name
  cak  = var.connectivity_association_key
}

7-7. 詰まり⑦ — DX + VPN Active/Active でトラフィックが片寄る

なぜ詰まるか

DX と VPN を Active/Active (ECMP) で運用する場合、BGP best-path selection が完全に同一コストになることはまれで、実際には DX 経由にほとんどのトラフィックが集中したり逆に VPN 経由に寄ったりする。DX (1Gbps/10Gbps) と VPN (最大 1.25Gbps) の帯域非対称が負荷偏在を引き起こし、VPN 側でパケットロスが発生するケースが多い。

どう解くか

帯域が非対称なら ECMP より Active/Passive (DX: local-pref 200、VPN: local-pref 100) を推奨する。真の Active/Active を狙う場合は local-pref / AS_PATH length / MED を完全同値にし、帯域も揃える必要がある。TunnelDataIn / TunnelDataOut と DX の ConnectionBpsIngress / ConnectionBpsEgress を CloudWatch で比較監視して偏りを検知する。

# DX と VPN の帯域を比較して偏りを確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/DX \
  --metric-name ConnectionBpsEgress \
  --dimensions Name=ConnectionId,Value=<dx-connection-id> \
  --start-time "$(date -u -v-1H '+%Y-%m-%dT%H:%M:%SZ')" \
  --end-time "$(date -u '+%Y-%m-%dT%H:%M:%SZ')" \
  --period 300 \
  --statistics Average \
  --output table

7-8. アンチパターン → 正解変換演習 5問

演習1: VGW 直付け → TGW Attachment へ移行

アンチパターン: オンプレ VPN を Virtual Private Gateway (VGW) に直接接続。1 VPC に VPN が閉じるため、新 VPC を追加するたびに VPN 設定が増殖する。

正解: Transit Gateway に VPN Attachment を作成し、TGW Route Table で複数 VPC への経路を一元管理する。

# Before: VGW 直付け (非推奨)
resource "aws_vpn_connection" "legacy" {
  customer_gateway_id = aws_customer_gateway.onprem.id
  vpn_gateway_id= aws_vpn_gateway.legacy.id
  type = "ipsec.1"
}

# After: TGW Attachment (推奨)
resource "aws_vpn_connection" "tgw_vpn" {
  customer_gateway_id = aws_customer_gateway.onprem.id
  transit_gateway_id  = aws_ec2_transit_gateway.main.id
  type = "ipsec.1"
}

演習2: 単一 DX Connection → LAG / Dual DX へ移行

アンチパターン: 1本の Dedicated Connection のみ。DX PoP の障害や物理回線断で全面切断。

正解: LAG (Link Aggregation Group) で複数回線を束ねるか、異なる DX Location から2本の Dedicated Connection を引いて Maximum Resiliency を確保する。

resource "aws_dx_lag" "ha_lag" {
  name= "ha-lag-10g"
  connections_bandwidth = "10Gbps"
  location  = "EqSY2"
  force_destroy= false
}

resource "aws_dx_connection" "member1" {
  name= "lag-member-1"
  bandwidth = "10Gbps"
  location  = "EqSY2"
  lag_id = aws_dx_lag.ha_lag.id
}

resource "aws_dx_connection" "member2" {
  name= "lag-member-2"
  bandwidth = "10Gbps"
  location  = "EqSY2"
  lag_id = aws_dx_lag.ha_lag.id
}

演習3: Default Resolver のみ → Inbound/Outbound Endpoint 分離

アンチパターン: VPC DNS (.2 Resolver) だけを使用。オンプレから AWS 内部ドメインを解決できず、AWS からオンプレドメインも解決できない。

正解: Inbound Endpoint でオンプレ → AWS 名前解決を、Outbound Endpoint で AWS → オンプレ転送を分離して設定する。

resource "aws_route53_resolver_endpoint" "inbound" {
  name= "hybrid-inbound"
  direction = "INBOUND"
  security_group_ids = [aws_security_group.resolver_sg.id]
  ip_address { subnet_id = aws_subnet.private_a.id }
  ip_address { subnet_id = aws_subnet.private_b.id }
}

resource "aws_route53_resolver_endpoint" "outbound" {
  name= "hybrid-outbound"
  direction = "OUTBOUND"
  security_group_ids = [aws_security_group.resolver_sg.id]
  ip_address { subnet_id = aws_subnet.private_c.id }
  ip_address { subnet_id = aws_subnet.private_d.id }
}

演習4: static route のみ → BGP propagation へ移行

アンチパターン: TGW Route Table に手動で static route を追加。DX Attachment 追加/削除のたびに手動でルート更新が必要で、見落としでブラックホールが発生。

正解: aws_ec2_transit_gateway_route_table_propagation で BGP propagation を有効化し、経路を自動更新する。

resource "aws_ec2_transit_gateway_route_table_propagation" "dx_propagation" {
  transit_gateway_attachment_id  = aws_dx_transit_virtual_interface.main.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.workload.id
}

resource "aws_ec2_transit_gateway_route_table_propagation" "vpn_propagation" {
  transit_gateway_attachment_id  = aws_vpn_connection.backup.transit_gateway_attachment_id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.workload.id
}

演習5: DX のみ Failover なし → DX + VPN Active/Passive

アンチパターン: DX 1本のみで Failover なし。DX 物理障害や BGP セッション断で即座にオンプレ通信が全断。

正解: VPN を Backup として追加し、BGP local-pref で DX 優先・VPN 待機の Active/Passive 構成にする。

# DX: Active (オンプレ側ルーターで local-pref 200 を設定)
resource "aws_dx_transit_virtual_interface" "primary" {
  connection_id= aws_dx_connection.dedicated.id
  name= "primary-transit-vif"
  vlan= 4094
  address_family  = "ipv4"
  bgp_asn= 65000
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  amazon_address  = "169.254.240.1/29"
  customer_address= "169.254.240.2/29"
}

# VPN: Passive Backup (オンプレ側で local-pref 100 + AS_PATH prepend を設定)
resource "aws_vpn_connection" "backup" {
  customer_gateway_id = aws_customer_gateway.onprem.id
  transit_gateway_id  = aws_ec2_transit_gateway.main.id
  type = "ipsec.1"
  static_routes_only  = false
}

# Failover テスト: BGP セッション断後の切替先アタッチメントを確認
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id <rt-id> \
  --filters Name=state,Values=active \
  --query 'Routes[*].{CIDR:DestinationCidrBlock,Via:TransitGatewayAttachments[0].ResourceType}'

8. まとめ + Vol3予告 + 落とし穴10選 + 9軸クロスリンク + Vol1↔Vol2 双方向リンク

8-1. Hybrid Connectivity で習得した5つの設計能力

本書 Vol2 では、AWS ↔ オンプレ接続の全体像を Direct Connect / Site-to-Site VPN / Transit Gateway × DX Gateway / Hybrid DNS の4本柱で体系化した。本書を通じて身に付く設計能力は次の5つ。

1. DX 設計判断能力 — Dedicated vs Hosted、Resiliency 3パターン、LAG、MACsec の選択基準と Terraform 完全実装
2. VPN BGP 制御能力 — Active/Active vs Active/Passive、local-pref/AS_PATH prepend の双方向経路制御と DPD チューニング
3. TGW 統合設計能力 — DX Gateway / Transit VIF / Allowed Prefix / Inter-Region Peering / Route Table 分離の組み合わせ設計
4. Hybrid DNS 設計能力 — Inbound/Outbound Endpoint 分離、Forwarding Rule、DNS Firewall の正しい配置パターン
5. HA/Failover 設計能力 — BGP local-pref + AS_PATH prepend 双方向制御による DX↔VPN フェイルオーバーの自動切替設計

8-2. 落とし穴10選チートシート

本書全体で触れた落とし穴を一覧化する。

8-3. Network Vol3 予告 — Network Firewall × Inspection VPC

Vol3 では、本書の Hybrid Connectivity を基盤として North-South / East-West トラフィックの検査基盤 を扱う予定。AWS Network Firewall による Inspection VPC 設計、Gateway Load Balancer (GWLB) を使ったサードパーティ NVA のインライン挿入、TGW Appliance Mode でのシンメトリックルーティングが主題となる。セキュリティ Vol2 (GuardDuty/Security Hub) とのシリーズ交差回にもなる。

8-4. 関連シリーズ — 9軸クロスリンク

本書は AWS 本番運用シリーズ全9軸の Network 軸 Vol2 として位置付けられる。以下の関連記事と組み合わせることで、AWS 本番設計の全体像が完成する。