AWS Direct Connect と Transit Gateway の運用ベストプラクティス～冗長化からIaC管理まで実践ガイド

はじめに

この記事では AWS Direct Connect (DX) と Transit Gateway (TGW) を組み合わせて利用する際の運用ベストプラクティスについて解説します。
対象は、業務経験1〜5年程度のインフラエンジニアやクラウドエンジニアを想定しています。

特に以下の課題を抱えている方に役立ちます。

• オンプレミスと AWS 間のネットワーク接続を安定運用したい
• マルチアカウント・マルチリージョン環境での接続設計に悩んでいる
• 実際に使える AWS CLI コマンドや Terraform サンプルを知りたい

※構成図などの図が全体的にかなり小さいです🥺すみません🥺

---

背景・前提知識

なぜ Direct Connect と Transit Gateway が重要か

• Direct Connect (DX): オンプレミスと AWS を専用線で接続し、低レイテンシかつ高帯域を実現するサービス。
• Transit Gateway (TGW): VPC 間やオンプレミスとの接続を集約するハブ的存在。

この2つを組み合わせることで、以下のメリットが得られます。

• マルチVPC・マルチアカウント環境でのシンプルな接続
• BGP（Border Gateway Protocol）による冗長化と経路制御
• 運用コスト削減（複雑なVPNの乱立を防げる）

---

本題：ベストプラクティスと実践例

1. Direct Connect Gatewayの初期設定（AWS CLI）

aws directconnect create-direct-connect-gateway \
  --direct-connect-gateway-name MyDXGW \
  --amazon-side-asn 64512

aws directconnect create-direct-connect-gateway-association \
  --direct-connect-gateway-id dxg-12345678 \
  --gateway-id tgw-87654321

---

2. Terraform による構成管理例

基本例

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_ec2_transit_gateway" "example" {
  description      = "Example Transit Gateway"
  amazon_side_asn  = 64520
}

resource "aws_dx_gateway" "example" {
  name            = "example-dxgw"
  amazon_side_asn = 64512
}

resource "aws_dx_gateway_association" "example" {
  dx_gateway_id         = aws_dx_gateway.example.id
  associated_gateway_id = aws_ec2_transit_gateway.example.id
}

---

3. Terraform モジュール化例（複数アカウント対応）

modules/tgw_dx/main.tf

variable "tgw_asn" { type = number }
variable "dxgw_asn" { type = number }
variable "tgw_id"   { type = string }
variable "dxgw_name" { type = string }

resource "aws_dx_gateway" "this" {
  name            = var.dxgw_name
  amazon_side_asn = var.dxgw_asn
}

resource "aws_dx_gateway_association" "this" {
  dx_gateway_id         = aws_dx_gateway.this.id
  associated_gateway_id = var.tgw_id
}

output "dxgw_id" {
  value = aws_dx_gateway.this.id
}

network-account/main.tf

provider "aws" {
  alias  = "network"
  region = "ap-northeast-1"
}

resource "aws_ec2_transit_gateway" "core" {
  provider        = aws.network
  amazon_side_asn = var.tgw_asn
  description     = "Core Transit Gateway"
}

module "tgw_dx" {
  source   = "../modules/tgw_dx"
  providers = { aws = aws.network }

  tgw_id    = aws_ec2_transit_gateway.core.id
  tgw_asn   = var.tgw_asn
  dxgw_asn  = var.dxgw_asn
  dxgw_name = "core-dxgw"
}

---

4. CI/CD による Terraform 自動デプロイ

GitHub Actions 例（.github/workflows/terraform.yml）

name: Terraform CI/CD

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  terraform:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.7.5

      - name: Terraform Init
        run: terraform init

      - name: Terraform Validate
        run: terraform validate

      - name: Terraform Plan
        run: terraform plan -out=tfplan

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main'
        run: terraform apply -auto-approve tfplan

---

5. マルチリージョン冗長化

Direct Connect は ロケーション障害 や リージョン障害 に備えて、
複数のリージョン・ロケーションにまたがって冗長化するのがベストプラクティスです。

設計パターン

1. マルチロケーション冗長化

   • 同一リージョン内で複数の DX ロケーションを利用
   • オンプレ側も冗長ルーターを配置して耐障害性を確保

2. マルチリージョン冗長化

   • 東京（ap-northeast-1）＋大阪（ap-northeast-3）に TGW を設置
   • DX Gateway を介して、オンプレからどちらの TGW にも接続可能にする
   • ルーティングは AS Path Prepending または BGP Local Preference で制御

5.1 高レベル構成図（DXGW + マルチリージョン TGW + 冗長 VIF）

ポイント

• CI/CD (GitHub Actions / CodePipeline)

  • Terraform や IaC を使った DX/TGW 設定を自動デプロイ
  • マルチリージョン対応も同一パイプラインで管理可能

• 監視 (CloudWatch / SNS / Alarms)

  • DX Virtual Interface や TGW の BGP 状態を監視
  • VPC 内サービスやルートテーブルも監視対象に

• 冗長化構成

  • Primary: Tokyo / Secondary: Osaka
  • フェイルオーバー時も監視・CI/CD で自動修復や通知

---

5.2 ルーティング切替の視点図（フェイルオーバー）

ポイント

• Keepalive/HoldTime を短め（例: 10s/30s）にすることで、障害検知を高速化。
• 復旧時は フェイルバック（プライマリへ戻す）挙動を BGP 属性で担保します。

---

5.3 役割ごとの責務分離（参考）

ポイント

• 経路制御はオンプレ側（AS Path/LocalPref）、集約は TGW、グローバル中継は DXGW と役割を分離。
• 監視・IaC（CI/CD）は横断機能として全体を支えます。

---

Terraform 例（マルチリージョン）

provider "aws" {
  alias  = "tokyo"
  region = "ap-northeast-1"
}

provider "aws" {
  alias  = "osaka"
  region = "ap-northeast-3"
}

resource "aws_ec2_transit_gateway" "tokyo_tgw" {
  provider        = aws.tokyo
  amazon_side_asn = 64520
  description     = "Tokyo Transit Gateway"
}

resource "aws_ec2_transit_gateway" "osaka_tgw" {
  provider        = aws.osaka
  amazon_side_asn = 64530
  description     = "Osaka Transit Gateway"
}

resource "aws_dx_gateway_association" "tokyo_dx_assoc" {
  dx_gateway_id         = var.dxgw_id
  associated_gateway_id = aws_ec2_transit_gateway.tokyo_tgw.id
}

resource "aws_dx_gateway_association" "osaka_dx_assoc" {
  dx_gateway_id         = var.dxgw_id
  associated_gateway_id = aws_ec2_transit_gateway.osaka_tgw.id
}

👉 ポイント

• DX Gateway はグローバルリソースなので、1つの DXGW に複数リージョンの TGW をアタッチ可能
• オンプレ側で プライマリ経路を東京、セカンダリ経路を大阪 と設定すれば、リージョン障害時に自動フェイルオーバー可能

フェイルオーバーテスト例

# 東京DX回線を遮断（オンプレミスルーターでの操作例）
shutdown interface GigabitEthernet0/1

# BGPセッション状態を確認（オンプレミスルーターでの操作例）
show bgp summary

# AWS 側ルート確認（大阪に切り替わっていることを確認）
aws ec2 describe-route-tables \
  --filters "Name=transit-gateway-id,Values=$(terraform output -raw osaka_tgw_id)"

---

6. モニタリングとアラート

resource "aws_cloudwatch_metric_alarm" "bgp_down" {
  alarm_name          = "DX-BGP-Down"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = 1
  metric_name         = "BGPState"
  namespace           = "AWS/DX"
  period              = 60
  statistic           = "Minimum"
  threshold           = 1
  alarm_actions       = [aws_sns_topic.netops.arn]

  dimensions = {
    VirtualInterfaceId = "dxvif-11223344"
  }
}

---

よくあるミスや注意点

1. 経路伝播の制御を忘れる
2. ASN の重複
3. 単一リージョン依存による障害リスク ←特にマルチリージョン構成で回避すべき

---

まとめ

• Direct Connect + Transit Gateway は大規模ネットワークの標準構成
• 冗長化・BGP 制御・モニタリングが安定運用の鍵
• Terraform をモジュール化 & CI/CD と連携することで、再現性・セキュリティ・運用効率が大幅に向上
• マルチリージョン冗長化を組み合わせることで、災害対策 (DR) にも対応可能

---

出典

• AWS Direct Connect ドキュメント (2024)
• AWS Transit Gateway ドキュメント (2024)
• AWS Well-Architected Framework: Networking (2023)