🏢 たとえ話:「共有バスターミナル」

🚌 街のバスターミナルに例えてみよう

Transit Gatewayのクロスアカウント共有は、「A社が建設したバスターミナルを、B社にも使わせてあげる」仕組みとそっくりです。

🚌 バスターミナルのたとえ話 💼 A社(ターミナル所有者) 🚌 A社バス路線 (VPC-A) 🏢 バスターミナル = Transit Gateway A社が建設し、A社が管理 運行ダイヤ変更 = ルートテーブル管理 📋 利用許可契約書 = AWS RAM 👥 B社(利用者) 🚌 B社バス路線 (VPC-B) B社ができること ✔ バスの乗り入れ(アタッチ) ✔ 乗降客数の確認(監視) ✘ ダイヤ変更(ルート管理) ✘ ターミナル取壊(TGW削除) A社ができること(全権限) ✔ ターミナルの建設・取壊 ✔ 運行ダイヤの作成・変更 ✔ 乗り入れ許可の管理 乗り入れ 乗り入れ 共有許可 🕑 ダイヤ管理(ルートテーブル) A社のみが作成・変更・削除可能 🔎 モニタリング参照 参照のみ。設定変更は不可
🚌 バスターミナルの世界☁️ AWSの世界ポイント
🏢 バスターミナルTransit Gateway (TGW)ネットワークの中央ハブ
💼 ターミナル所有者(A社)TGW所有者アカウント全権限を持つ管理者
👥 乗り入れ許可された会社(B社)共有先アカウント限定的な利用権限のみ
📋 利用許可契約書AWS RAM共有の仲介サービス
🚌 バスの乗り入れVPCアタッチメント作成共有先が実行できる操作
🕑 運行ダイヤ(時刻表)ルートテーブル所有者のみが管理可能
🔎 乗降客数モニターモニタリング・ログ共有先は参照のみ
🚫 ターミナルの取り壊しTGWの削除所有者のみが実行可能

🛠 アーキテクチャ構成図

Transit Gateway クロスアカウント共有 アーキテクチャ 👑 アカウントA(TGW所有者) AWS RAM リソース共有 👥 アカウントB(共有先) VPC-A 10.1.0.0/16 ☁ TGW-A Transit Gateway 所有者: アカウントA ルートテーブル 🔒 所有者のみ管理 ワークロードA 🟢 既存稼働中 VPC-B 10.2.0.0/16 🔗 VPCアタッチメント アカウントBが作成可能 📈 モニタリング・ログ 👁 参照のみ可能 ワークロードB 🔵 移行対象 Attach TGW登録 共有 クロスアカウント接続 凡例: 同一アカウント クロスアカウント RAM共有フロー

🔎 共有範囲と仕組み

共有先アカウントの権限マップ ✔ 共有先が利用可能 🔗 VPCアタッチメント作成 自VPCをTGWに接続 📈 モニタリング参照 接続状態・トラフィック確認 📊 使用統計アクセス データ転送量・接続数 📑 ルートテーブル参照 内容の閲覧のみ可能 ✘ 共有先では不可 🚫 TGWの削除 所有者アカウントのみ 📝 ルートテーブル管理 作成・変更・削除すべて不可 🔒 RAM共有設定の変更 共有対象の追加・削除不可 👥 他アカウントの操作 他者のアタッチメント操作不可

🛡 権限モデル比較:所有者 vs 共有先

権限モデル比較表 👑 所有者(アカウントA) 👥 共有先(アカウントB) Transit Gateway 管理 Transit Gateway 管理 TGW作成・削除 TGW作成・削除 → 不可 ルートテーブル作成・変更・削除 ルートテーブル操作 → 全て不可 ルートの追加・変更・削除 ルート操作 → 全て不可 VPCアタッチメント作成・管理 自VPCアタッチメント作成のみ ✔ AWS RAM共有設定の管理 RAM共有設定変更 → 不可 全モニタリング・統計の参照 モニタリング参照のみ(設定変更不可)

セットアップ手順

セットアップ 5ステップ 1 TGW作成 アカウントAで TGWを作成 アカウントA 2 RAM共有 AWS RAMで アカウントBに共有 アカウントA 3 招待承認 アカウントBで 共有を承認 アカウントB 4 VPCアタッチ アカウントBが VPCをアタッチ アカウントB 5 ルート設定 アカウントAで ルートを追加 アカウントA 💡 Organizations内ではステップ3が自動スキップ!

🔬 判断フローチャート:どの接続方式を選ぶ?

マルチアカウント接続方式 判断フローチャート マルチアカウントVPC接続が必要 接続するVPCは 3つ以上? No VPCピアリング 1対1接続で十分 Yes 既存の稼働中 TGWがある? No 新規TGW作成 ゼロから構築 Yes ⭐ TGW共有 AWS RAM でクロスアカウント 運用オーバーヘッド最小! ✔ 既存運用手順・知識を活用 ✔ コスト最小 / ルーティング一元管理 ✔ 段階的移行でリスク軽減

🚀 運用オーバーヘッドを最小化する5つの原則

運用オーバーヘッド最小化 5つの原則 運用 最適化 1 既存リソース 活用 2 移行範囲 最適化 3. 管理効率性 4 運用 継続性 5 リスク 管理
1
既存リソースの活用度
TGW-Aが既に稼働しており、チームAのワークロードで実績がある場合、この既存リソースを活用することで大きなメリットが得られます。
📋 既存の運用手順・ドキュメント継続利用
🔧 既知の性能特性とトラブル対応知識の活用
🔔 既存モニタリング設定・アラームの継続利用
📚 ネットワークチームの学習コスト最小化
2
移行範囲の最適化
アカウントBのVPCのみをTGW-Aに移行する戦略をとることで、変更の影響範囲を最小限に抑えます。
🛡 チームAの環境への影響を完全に回避
🎯 移行対象の明確な範囲設定
🔄 段階的な移行とロールバック計画の単純化
🔍 テストと検証の対象を限定
3
クロスアカウント管理の効率性
AWS RAMを使用することで、所有権を明確に保ちながら必要な機能のみを共有できます。
👑 TGW-Aの所有権はアカウントAに維持
🔒 アカウントBは最小権限のみ取得
💰 課金の複雑化を回避
🛡 セキュリティポリシーの一貫性を保持
4
運用継続性の確保
既存のTGW-Aを基盤とすることで、チームの既存知識やツールチェーンをそのまま活用できます。
🛠 既存知識とツールを継続利用
🔄 自動化スクリプト・ワークフローの再利用
🔬 障害対応手順の変更を最小化
👥 チームAの運用プロセスへの影響回避
5
リスク管理
最小限の変更により、新規インフラ導入に伴う各種リスクを軽減します。
💥 未知の問題リスクを軽減
🚧 障害範囲の拡大を防止
👨 人為的ミスの可能性を削減
⏰ 長期間の移行による運用負荷を回避

🔄 Before / After 比較

❌ Before:個別TGW構成 アカウントA VPC-A + TGW-A アカウントB VPC-B + TGW-B TGWピアリング 問題点 🔴 TGWを2つ管理(コスト2倍) 🔴 ルートテーブルが分散(一貫性なし) 🔴 ピアリング設定の追加管理負荷 🔴 モニタリングが2系統(運用複雑化) 🔴 障害対応手順が2倍 ✔ After:TGW共有構成 アカウントA 👑 VPC-A + TGW-A(所有) TGW-A アカウントB VPC-B(アタッチのみ) RAM共有 メリット 🟢 TGW 1台で管理(コスト半減) 🟢 ルートテーブルを一元管理(一貫性確保) 🟢 ピアリング不要(管理負荷削減) 🟢 モニタリング1系統(運用シンプル化) 🟢 既存の運用手順をそのまま利用

💻 コード例

# Step 1: TGW所有者(アカウントA)でRAMリソース共有を作成
aws ram create-resource-share \
  --name "TGW-CrossAccount-Share" \
  --resource-arns "arn:aws:ec2:ap-northeast-1:111111111111:transit-gateway/tgw-0abc123" \
  --principals "222222222222" \
  --tags key=Environment,value=Production

# Step 2: 共有先(アカウントB)で招待を承認
aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn "arn:aws:ram:ap-northeast-1:111111111111:resource-share-invitation/xxx"

# Step 3: 共有先(アカウントB)でVPCアタッチメントを作成
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id "tgw-0abc123" \
  --vpc-id "vpc-0bbb222" \
  --subnet-ids "subnet-0aaa111" "subnet-0bbb222"

# Step 4: 所有者(アカウントA)でルートを追加
aws ec2 create-transit-gateway-route \
  --destination-cidr-block "10.2.0.0/16" \
  --transit-gateway-route-table-id "tgw-rtb-0abc123" \
  --transit-gateway-attachment-id "tgw-attach-0bbb222"
# アカウントA側: RAM共有リソース定義
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  TGWResourceShare:
    Type: AWS::RAM::ResourceShare
    Properties:
      Name: "TGW-CrossAccount-Share"
      ResourceArns:
        - !Sub "arn:aws:ec2:${AWS::Region}:${AWS::AccountId}:transit-gateway/${TGWId}"
      Principals:
        - "222222222222"
      AllowExternalPrincipals: true

# アカウントB側: VPCアタッチメント
  VPCAttachment:
    Type: AWS::EC2::TransitGatewayVpcAttachment
    Properties:
      TransitGatewayId: "tgw-0abc123"
      VpcId: !Ref VpcB
      SubnetIds:
        - !Ref PrivateSubnet1
        - !Ref PrivateSubnet2
# アカウントA側: RAM共有リソース
resource "aws_ram_resource_share" "tgw_share" {
  name                      = "TGW-CrossAccount-Share"
  allow_external_principals = true
}
resource "aws_ram_resource_association" "tgw" {
  resource_arn       = aws_ec2_transit_gateway.main.arn
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}
resource "aws_ram_principal_association" "account_b" {
  principal          = "222222222222"
  resource_share_arn = aws_ram_resource_share.tgw_share.arn
}

# アカウントB側: 共有承認 + VPCアタッチメント
resource "aws_ram_resource_share_accepter" "accept" {
  share_arn = "arn:aws:ram:ap-northeast-1:111111111111:resource-share/xxx"
}
resource "aws_ec2_transit_gateway_vpc_attachment" "vpc_b" {
  transit_gateway_id = "tgw-0abc123"
  vpc_id             = aws_vpc.vpc_b.id
  subnet_ids         = [aws_subnet.priv1.id, aws_subnet.priv2.id]
  depends_on = [aws_ram_resource_share_accepter.accept]
}

ベストプラクティス vs アンチパターン

✅ ベストプラクティス
🟢 既存の稼働実績あるTGWを共有し、新規作成を避ける
🟢 AWS Organizations連携で招待承認を自動化する
🟢 ルートテーブルは所有者が一元管理し、一貫性を保つ
🟢 移行対象VPCのみ限定し段階的にアタッチする
🟢 CloudWatch+Flow Logsでクロスアカウント通信を監視
🟢 タグ付けポリシー統一でコスト配分を明確化
❌ アンチパターン
🔴 アカウントごとに個別TGWを作成してピアリング接続
🔴 共有先にルートテーブル管理を委任しようとする
🔴 全VPCを同時に移行して障害影響範囲を拡大
🔴 RAM共有範囲を確認せず不要なリソースまで公開
🔴 モニタリングなしでクロスアカウント接続を本番投入
🔴 TGWの所有者変更が必要な設計にしてしまう

🔧 トラブルシューティング

トラブル切り分けフロー ⚠ TGWが表示されない RAM招待未承認 or リージョン不一致 ✅ get-resource-share-invitations確認 ⚠ 権限エラー発生 IAMポリシーに EC2系権限が不足 ✅ CreateTGWVpcAttachment権限付与 ⚠ VPC間通信不可 ルートテーブル未設定 or SG/NACL不備 ✅ TGW・VPC双方のルートを確認 ⚠ pendingAcceptance 自動承認が無効 所有者側で手動承認が必要 ✅ AutoAcceptSharedAttachments確認 💡 全パターン共通:VPC Flow Logs + CloudWatch で原因を特定してから対処する

📚 試験対策ポイント

試験キーワード ➡ 正解パターン 「マルチアカウントでTGW共有」 AWS RAM 「運用オーバーヘッド最小化」 既存TGW共有 「ルートテーブル管理は誰?」 所有者のみ 💡 試験のコツ ⭐ 「新規TGW作成」よりも「既存TGW共有」が常に優先 ⭐ Organizations内 = 招待承認の自動スキップ ⭐ VPCピアリング vs TGW共有の使い分け出題あり ⭐ AutoAcceptSharedAttachments の設定値を確認
ANS-C01
TGWクロスアカウント共有 = AWS RAM
「マルチアカウントでTGWを共有」と出たら、AWS RAMが正解。VPCピアリングではなくTGW共有を選ぶ理由も理解しておく。
SAP-C02
運用オーバーヘッド最小化の判断基準
「運用オーバーヘッドを最小化」がキーワードの場合、既存TGWの共有>新規TGW作成。既存リソース活用が常に優先。
ANS-C01
権限分離モデルの理解
「共有先にルートテーブル管理権限はあるか?」→ No。ルートテーブル操作は所有者のみ。VPCピアリングとの大きな違い。
SAP-C02
移行戦略とリスク管理
既存TGW-Aに新アカウントBのVPCだけ移行する方が全体再構築よりリスク低い。「最小変更」「段階的移行」がキーワード。

よくある質問(FAQ)

TGW時間課金はTGW所有者(アカウントA)に請求されます。データ転送料金はアタッチメントを作成したアカウント(アカウントB)にそれぞれ請求されます。インフラ費用は所有者、通信費用は利用者の負担です。
TGWにはアタッチメント数の上限(デフォルト5,000)があります。性能面ではTGW自体は50 Gbps以上の高帯域幅のため、通常は問題になりません。大量接続時はService Quotasでの上限緩和を検討してください。
VPC数が3つ以上でフルメッシュ接続が必要なら、TGW共有を推奨します。VPCピアリングはN*(N-1)/2の管理が必要ですが、TGWならハブ&スポーク型で一元管理可能です。2つのVPC間で帯域・レイテンシ最優先なら、VPCピアリングが適切な場合もあります。
RAM経由のTGW共有は同一リージョン内に限定されます。リージョン間は各リージョンにTGWを作成し、Inter-Region Peeringで接続します。各TGWをRAMで個別に共有する構成となります。
TGW削除前に全アタッチメント(共有先含む)の削除が必要です。突然接続が切れることはなく、事前調整が必須となります。

📋 チートシート

📋 クイックリファレンスカード 共有サービス AWS RAM(Resource Access Manager) 共有可能な範囲 同一リージョン内のみ Organizations内の特典 招待の自動承認 所有者の権限 TGW全操作(作成・削除・ルート管理) 共有先の権限 VPCアタッチ + モニタリング参照のみ 料金負担 TGW時間→所有者 / 転送→利用者 ⭐ 試験キーワード ➡ 「運用オーバーヘッド最小化」 ➡ 「既存TGW活用」 ➡ 「AWS RAM」 ➡ 「最小権限の原則」 ➡ 「段階的移行」

📖 用語集

Transit Gateway (TGW)
VPC、VPN、Direct Connectを集約するネットワークハブ
AWS RAM
AWSリソースを他アカウント・Organizationsと共有するサービス
VPCアタッチメント
VPCをTGWに接続する論理的な紐付け
ルートテーブル
TGW内のトラフィック経路を制御する設定
アソシエーション
アタッチメントとルートテーブルの紐付け
プロパゲーション
アタッチメントからルートテーブルへのルート自動伝播

Created by SSuzuki1063

AWS SAP Learning Resources