2026年6月4日

2026年6月4日

AWS Transit Gateway の作成と情報取得の方法|VPCアタッチメントとルートテーブル設定まで

AWS Transit Gateway(TGW)は、複数の VPC やオンプレミス拠点を 1 つのハブにつなぐためのサービスです。この記事では、TGW を作成して 2 つの VPC を接続し、既存の TGW の ID や経路を AWS CLI で取得・確認するところまでを手順に沿って説明します。VPC ピアリングとの使い分けや、疎通しないときの確認順も扱います。

Transit Gateway を使う場面

VPC 同士をつなぐ方法としては VPC ピアリングもあります。ピアリングは 1 対 1 の接続で、経路は推移しません(A–B と B–C をつないでも A から C へは届きません)。VPC が 2〜3 個ならピアリングで足りますが、数が増えると接続の組み合わせが膨らみ、管理が難しくなります。

TGW はリージョン単位のルーターのように振る舞い、各 VPC は TGW に 1 本ずつ接続(アタッチメント)するだけで済みます。TGW のルートテーブルで「どこからどこへ通すか」を集中管理できるのが利点です。接続先としては、VPC のほか Site-to-Site VPN、Direct Connect ゲートウェイ、別の TGW とのピアリングなどを扱えます。

一方で、TGW はアタッチメントごとの時間課金とデータ処理量に応じた課金が発生します。料金体系は変わることがあるため、構築前に AWS の料金ページで確認してください。本記事の内容はコンソールや CLI の仕様に基づいています(2026年10月現在)。

WordPress の運用でいえば、Web サーバーのある VPC から、監視・バックアップ・踏み台などの共通基盤を置いた VPC や社内ネットワークへ到達させたい、という場面が典型的です。

構築前に決めること

CIDR が重ならないようにする

TGW で接続する VPC 同士の CIDR が重なっていると、宛先を区別できないため正しくルーティングできません。後から CIDR を変えるのは大がかりな作業になるので、最初に一覧を作って重複がないことを確認します。オンプレミスや VPN 先のアドレス帯も含めて確認しておくと、拠点を増やすときに困りません。

アタッチメント用のサブネットを用意する

VPC アタッチメントでは、AZ ごとに 1 つずつサブネットを指定します。TGW はそのサブネットに通信用のインターフェースを置きます。指定していない AZ のリソースからは TGW 経由の通信ができないため、ワークロードを置いている AZ はすべて含めてください。AWS のドキュメントでは、アタッチメント専用の小さなサブネットを AZ ごとに作る構成が推奨されています。こうしておくと、ネットワーク ACL やルートテーブルをアプリ用サブネットと分けて管理できます。

Transit Gateway を作成する

マネジメントコンソールでは VPC の画面から Transit Gateway を作成できます。画面の項目名は変わることがあるので、ここでは AWS CLI の例で、各オプションの意味とあわせて説明します。

aws ec2 create-transit-gateway \
  --description "shared-hub" \
  --options AmazonSideAsn=64512,AutoAcceptSharedAttachments=disable,DefaultRouteTableAssociation=enable,DefaultRouteTablePropagation=enable,DnsSupport=enable,VpnEcmpSupport=enable \
  --tag-specifications 'ResourceType=transit-gateway,Tags=[{Key=Name,Value=shared-hub}]'

主なオプションの意味は次のとおりです。

  • AmazonSideAsn: VPN や Direct Connect で BGP を使うときの AWS 側の AS 番号です。オンプレミス側と重ならない値を選びます。
  • DefaultRouteTableAssociation / DefaultRouteTablePropagation: 新しいアタッチメントを既定のルートテーブルに自動で関連付け、経路を自動で伝播させるかどうかです。すべての VPC を相互に通してよい小規模な構成なら有効のままが簡単です。本番と開発を分けたいなど通信を制限したい場合は無効にし、ルートテーブルを自分で設計します。
  • AutoAcceptSharedAttachments: AWS RAM で別アカウントに共有したときに、相手からのアタッチメントを自動承認するかどうかです。意図しない接続を防ぐため、無効にしておくのが一般的です。

作成直後の状態は pending で、数分ほどで available になります。

VPC をアタッチしてルートを追加する

TGW が available になったら、各 VPC をアタッチします。

aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-0123456789abcdef0 \
  --vpc-id vpc-0aaaaaaaaaaaaaaaa \
  --subnet-ids subnet-0aaaaaaaaaaaaaaa1 subnet-0aaaaaaaaaaaaaaa2

ここで多くの人がつまずくのが、VPC 側のルートテーブルです。TGW にアタッチしただけでは、VPC 内のサブネットは相手の CIDR 宛ての通信を TGW に送りません。各サブネットのルートテーブルに、相手 VPC の CIDR を宛先、TGW をターゲットとするルートを追加します。

aws ec2 create-route \
  --route-table-id rtb-0aaaaaaaaaaaaaaaa \
  --destination-cidr-block 10.20.0.0/16 \
  --transit-gateway-id tgw-0123456789abcdef0

相手 VPC 側にも、戻りのルートを同じように追加します。行きだけ設定して戻りを忘れると、片方向にしか通らず、タイムアウトになります。

既存の Transit Gateway の情報を取得する

運用中の環境では、TGW の ID やアタッチメントの状態、実際に有効な経路を調べたい場面がよくあります。次のコマンドで取得できます。

# TGW の一覧と状態
aws ec2 describe-transit-gateways \
  --query 'TransitGateways[].{ID:TransitGatewayId,State:State,ASN:Options.AmazonSideAsn}' \
  --output table

# アタッチメントの一覧(接続先の種類と状態)
aws ec2 describe-transit-gateway-attachments \
  --filters Name=transit-gateway-id,Values=tgw-0123456789abcdef0 \
  --output table

# TGW ルートテーブル内の経路を検索
aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-0123456789abcdef0 \
  --filters Name=state,Values=active

search-transit-gateway-routes では、経路が伝播(propagated)で入ったのか静的(static)に追加したのかも分かります。相手 VPC の CIDR がここに無ければ、関連付けか伝播の設定が漏れています。CLI は対象リージョンで実行する必要があるので、--region の指定や設定中のプロファイルにも注意してください。

疎通しないときの確認順

TGW 経由で通信できないときは、可能性の高い順に次を確認します。

  1. VPC のルートテーブル: 送信元と送信先の両方のサブネットに、相手 CIDR → TGW のルートがあるか。実務ではこれが最も多い原因です。
  2. TGW のルートテーブル: 各アタッチメントが正しいルートテーブルに関連付けられ、相手の経路が active で入っているか。
  3. セキュリティグループとネットワーク ACL: 送信先のセキュリティグループが、相手 VPC の CIDR からの通信を許可しているか。ネットワーク ACL は戻りの通信(エフェメラルポート)も許可が必要です。
  4. アタッチメントの AZ: 通信するインスタンスの AZ に、アタッチメントのサブネットがあるか。

切り分けには VPC Reachability Analyzer が便利です。送信元と送信先を指定すると、経路のどこで止まっているかを示してくれます。実際のパケットの状況は VPC フローログや TGW のフローログで確認できます。

運用で気をつけること

  • ルートテーブルやアタッチメントの変更は、既存の通信を止める可能性があります。変更前に現在の設定を describe 系のコマンドで保存し、検証用の環境で手順を試してから本番に適用してください。
  • Terraform などの IaC で管理している場合は、コンソールで手作業の変更をすると差分が生じます。変更はコード側で行います。
  • ファイアウォール機器を経由させるなど、行きと帰りで同じ経路を通す必要がある構成では、アタッチメントのアプライアンスモードを検討します。

まとめ

  • Transit Gateway は複数 VPC やオンプレミスを 1 つのハブで接続するサービスで、接続数が多い構成や経路を集中管理したい場合に向いています。
  • 構築前に CIDR の重複がないことを確認し、AZ ごとにアタッチメント用サブネットを用意します。
  • TGW の作成とアタッチだけでは通信できず、VPC 側のルートテーブルに相手 CIDR → TGW のルートを双方向で追加する必要があります。
  • 既存環境の情報は describe-transit-gateways、describe-transit-gateway-attachments、search-transit-gateway-routes で取得できます。
  • 疎通しないときは、VPC ルート、TGW ルート、セキュリティグループと ACL、AZ の順に確認し、Reachability Analyzer で切り分けます。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲