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 経由で通信できないときは、可能性の高い順に次を確認します。
- VPC のルートテーブル: 送信元と送信先の両方のサブネットに、相手 CIDR → TGW のルートがあるか。実務ではこれが最も多い原因です。
- TGW のルートテーブル: 各アタッチメントが正しいルートテーブルに関連付けられ、相手の経路が
activeで入っているか。 - セキュリティグループとネットワーク ACL: 送信先のセキュリティグループが、相手 VPC の CIDR からの通信を許可しているか。ネットワーク ACL は戻りの通信(エフェメラルポート)も許可が必要です。
- アタッチメントの 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 で切り分けます。