200アカウント規模を見据えた開発・検証・本番の 環境分離を成立させる、AWS Transit Gateway によるネットワーク設計と実践

Presentation from JAWS DAYS 2026
https://jawsdays2026.jaws-ug.jp/

Transcript

1. JAWS DAYS 2026 Mashup for the Future 200アカウント規模を見据えた開発・検証・本番の 環境分離を成立させる、AWS Transit Gateway によるネットワーク設計と実践 株式会社 Fusic 鶴田 諒輔(@pensuke628)
2. #jawsug #jawsdays2026 #jawsdays2026_b 自己紹介 鶴 田 諒 輔 R Y O S U K E T S U R U D A 株 式 会 社 F u s i c 事 業 本 部 ク ラ ウ ド エ ン ジ ニ ア リ ン グ 部 門 エ ン ジ ニ ア J AW S D AY S 初 参 加 & 初 登 壇 ！
3. #jawsug #jawsdays2026 #jawsdays2026_b 1. アーキテクチャと設計ポイント 1. 環境間の通信分離 2. 環境ごとのインターネット経路 3. 共有リソースのコスト最適化 2. ネットワーク要件の標準化と自動化 3. まとめ アジェンダ
4. アーキテクチャと 設計ポイント
5. #jawsug #jawsdays2026 #jawsdays2026_b アーキテクチャの全体像 本番環境 検証環境 開発環境
6. #jawsug #jawsdays2026 #jawsdays2026_b Hubアカウントの構成
7. #jawsug #jawsdays2026 #jawsdays2026_b • Direct Connect Gateway → Transit Gatewayで本番/検証環境を既 存環境と接続 Hubアカウントと外部環境の接続 検証環境 本番環境
8. #jawsug #jawsdays2026 #jawsdays2026_b Spokeアカウントの構成
9. #jawsug #jawsdays2026 #jawsdays2026_b マルチアカウントのネットワーク設計ポイント マルチアカウントのネットワーク設計ポイント 1. 環境間の通信分離 マルチアカウントに複数環境が混在する 場合、環境間の通信は許可するか遮断す るか 01 インターネットや外部APIへの接続箇所が 環境ごとに異なる場合の制御をどのよう に実現するか 2. 外部通信への経路 02 3. 共有リソースの コスト最適化 03 コストをできる限り削減しつつ、可用性 とのバランスをどのように取るか
10. #jawsug #jawsdays2026 #jawsdays2026_b マルチアカウントに複数の環境を含む可能性がある 異なる環境間で通信を許可するか、遮断するかを明確にする必要が ある 1. 環境間の通信分離 本番 検証 マルチアカウント テスト 開発
11. #jawsug #jawsdays2026 #jawsdays2026_b Transit Gatewayを使った環境間の通信制御のパターン Transit Gatewayの分離戦略 ルートテーブルを分割する 1つのTransit Gatewayに 環境ごとのルートテーブ ルを作成するパターン Transit Gatewayを分割する 環境ごとにTransit Gatewayを作成するパ ターン
12. #jawsug #jawsdays2026 #jawsdays2026_b 今回の判断：環境ごとにTransit Gatewayを分離 • 本番用Transit Gatewayを分けた理由 本番環境はDirect Connect経由で既存環境の基幹システムと接続して いる。検証/開発環境の設定変更や障害が本番環境のTransit Gatewayに影響することを原理的に排除する • 開発用Transit Gatewayと検証用Transit Gatewayを分けた理由 理論的には開発/検証は1つのTGW + ルートテーブル分離で成立する。 しかし、環境ごとにTGWを分けるという一貫したルールにすること で、運用判断をシンプルにし統一性を確保した Transit Gatewayの分離戦略
13. #jawsug #jawsdays2026 #jawsdays2026_b Transit Gatewayを環境ごとに分離しているが、それだけでは環境間 通信を完全には遮断できないケースがある Transit Gateway分離で排除できないリスク ①Stg/Dev共有VPCを中継した通信 ②Direct Connect経由 で既存環境を中継した 通信
14. #jawsug #jawsdays2026 #jawsdays2026_b • これらを排除するため、各Transit Gatewayのルートテーブルに他環 境のCIDRへのブラックホールルートを設定 • 各環境で使用するCIDRを登録したカスタマーマネージドプレフィッ クスリストを用意 Black hole routeの設定 • 検証環境のCIDRを登録したプ レフィックスリスト 開発環境 ・開発環境のCIDRを登録したプ レフィックスリスト ・本番環境向けに割り当てられ たCIDR（10.A.0.0/16） 検証環境 ・開発/検証環境向けに割り当て られたCIDR（10.B.0.0/16） 本番環境
15. #jawsug #jawsdays2026 #jawsdays2026_b • 検証/本番環境はDirect Connect経由で既存環境と双方向通信する ため、既存環境側のルーティングで宛先を判別できるようCIDRの 重複は許されない • 既存環境から割り当てられたIP帯が10.A.0.0/16と10.B.0.0/16の2つ • 本番: 10.A.X.0/24（X=1〜100、X=0はHubアカウント） • 検証: 10.B.X.0/24（X=1〜100、X=0はHubアカウント） • 開発: 10.B.X.0/24（X=101〜200） ※既存環境と未接続だが、CIDRの重複を回避 CIDR帯域の設計
16. #jawsug #jawsdays2026 #jawsdays2026_b 環境間の通信分離のまとめ Transit Gatewayの設計ポイントは本番環境への影響度と運用負荷 Point 01 Transit Gatewayを分離しても、環境間通信を分離できないケースがある Point 02 Black hole routeの設定と適切なCIDR設計でEdgeケースもカバー Point 03
17. #jawsug #jawsdays2026 #jawsdays2026_b 外部APIとの連携やパッケージ取得等でインターネット接続が必要 本番/検証環境 • 既存環境側に存在するNAT Gatewayを利用 開発環境 • 既存環境とは接続しないため、別途インターネット接続を準備する 必要がある 本番/検証と開発でインターネット経路が異なる 2. 環境ごとのインターネット経路
18. #jawsug #jawsdays2026 #jawsdays2026_b • 本番/検証環境は既存環境側のNAT経由 • 開発環境はHubアカウントのVPC内のNAT Gateway経由でインターネッ トに接続 インターネット接続戦略
19. #jawsug #jawsdays2026 #jawsdays2026_b • Transit Gatewayルートテーブルのデフォルトルートの向き先で実 現 • 開発: デフォルトルート → HubアカウントのVPC • 本番/検証: デフォルトルート → Direct Connectアタッチメント インターネットへの経路がデフォルトルートで分岐する シンプルな設計 インターネット接続戦略
20. #jawsug #jawsdays2026 #jawsdays2026_b • 200アカウント個別にリソースを作成すると、コストが膨大になる • コストを最適化するために、共有できるリソースは可能な限り共有 したい 3. 共有リソースのコスト最適化 メリット • コスト削減 • リソース管理の一元化 リスク • 集約箇所が単一障害点 となる • ルーティングの複雑化
21. #jawsug #jawsdays2026 #jawsdays2026_b • コスト最適化のため、VPC EndpointとRoute 53 Inbound/Outbound ResolverをHubアカウントに集約 • SpokeアカウントにはVPC Endpointなどを作成しない 共有VPC Endpoint + Route 53 Resolver
22. #jawsug #jawsdays2026 #jawsdays2026_b なぜ本番用VPCを検証/開発と分離したか • 本番用VPC Endpoints・Route 53 Resolverを検証/開発と共用する 案もあった • 分離した理由 • 本番環境の障害影響の局所化 • VPC Endpointのスループット/セキュリティポリシーの独立性 • トレードオフ • VPC Endpoint・Resolverが二重構成になりコスト増 • 運用対象も増える 共有VPC Endpoint + Route 53 Resolver 本番環境への影響＞リソースのコスト
23. #jawsug #jawsdays2026 #jawsdays2026_b 実装方法(2通り) ①Private Hosted Zone共有方式 メリット：コストが比較的少ない デメリット：アカウント数が増えると運用負荷が増える ②Resolver Rule＋RAM方式 メリット：大規模アカウントでも運用負荷が比較的少ない デメリット：Resolverのコストがかかる 共有VPC Endpoint + Route 53 Resolver
24. ネットワーク要件の標準化と 自動化
25. #jawsug #jawsdays2026 #jawsdays2026_b • アカウント作成のたびに手動でTransit Gatewayアタッチメント・ ルート設定を行うのは200アカウント規模では破綻する • 設定ミスや漏れが環境分離の穴になるリスク • 環境ごとにTransit Gatewayが異なり、ルーティング設定やブラッ クホールルートも環境に応じて変わるため、手動運用ではミスの可 能性が高い 設計が正しくても、払い出し時に反映されなければ意味がない 3. ネットワーク要件の標準化と自動化
26. #jawsug #jawsdays2026 #jawsdays2026_b Acoount Factory for Terrafom(AFT)で実現した自動化フロー • Control Tower配下でアカウント発行から必要なterraformによるリ ソース作成まで自動実行 • 今回は以下のリソースを自動作成 • VPC作成（環境種別に応じたCIDR割り当て） • 環境に対応するTransit GatewayへのAttachment作成 • Transit GatewayルートテーブルへのAssociation / Propagation設定 • 各環境のprefixリストへのIPアドレスの追加（他環境CIDRの遮断） • VPCルートテーブルのデフォルトルート設定 ネットワーク要件の標準化と自動化
27. #jawsug #jawsdays2026 #jawsdays2026_b Account Factory for Terraformの実装例 module ”service_name" { source = "./modules/aft-account- request" control_tower_parameters = { AccountName = “アカウント名" ManagedOrganizationalUnit = ”OUのid" } account_customizations_name = ”prod" custom_fields = { vpc_cidr = "10.A.0.0/24" } } data "aws_ssm_parameter" "vpc_cidr" { name = "/aft/account-request/custom- fields/prod_vpc_cidr" } locals { vpc_cidr = data.aws_ssm_parameter.vpc_cidr.value } resource "aws_vpc" ”xxx" { cidr_block = local.prod_vpc_cidr } アカウント発行側 リソース管理側
28. #jawsug #jawsdays2026 #jawsdays2026_b まとめ Transit Gatweay自体を分離して、CIDR設計とBlack role roteで環境間通信 を遮断 Point 01 共有リソースを集約しつつ、本番環境への影響を最小限にする コスト最適化 Point 02 AFTによる「ネットワーク要件を満たしたアカウント」の継続的な払い出 し Point 03