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

Presentation from JAWS-UG Fukuoka #26

Transcript

1. ©Fusic Co., Ltd. 0 200アカウント規模を見据えた開発・検証・本番の 環境分離を成立させる、AWS Transit Gatewayに よるネットワーク設計と実践 2026.06.20 株式会社Fusic 鶴田 諒輔 (@pensuke628) JAWS-UG福岡 #26 JAWS DAYS 2026 re:Cap!!
2. ©Fusic Co., Ltd. 1 自己紹介 株 式 会 社 F u s i c エ ン ジ ニ ア 鶴田 諒輔 R y o s u ke Tsu r u d a 受 賞 ➢ 2 0 2 5 J a p a n A l l A W S C e r t i f i c a t i o n s E n g i n e e r s 好 き な A W S サ ー ビ ス A W S S y s t e m s M a n a g e r
3. ©Fusic Co., Ltd. 2 JAWS DAYS 2026登壇しました！ 資 料 は こ ち ら
4. ©Fusic Co., Ltd. 3 今日話すこと 今日はより細かい部分を少し深掘り ✓ 環境分離 ✓ 共有リソースの集約
5. ©Fusic Co., Ltd. 4 CONTENTS 目次 1. 背景と設計要件 2. 構築したアーキテクチャ 3. 環境ごとの通信分離 4. リソース共有によるコスト最適化 5. まとめ
6. ©Fusic Co., Ltd. 5 背景と設計要件 1
7. ©Fusic Co., Ltd. 6 背景 ✓ 社内システムを動かしている既存のAWS環境がある（社内イントラ） ✓ 社内イントラに接続するマルチアカウント基盤を作成 ✓ なぜマルチアカウントだったのか ⚫ AWSが推奨している方式を採用（セキュリティ、請求などの観点） ⚫ 組織ポリシー（サービス/チームごとにアカウントを分ける）に則る 必要があった https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_securely_operate_multi_accounts.html
8. ©Fusic Co., Ltd. 7 社内イントラのイメージ 社内イントラの特徴 ✓ 拠点の端末とAWS環境が接続された環境 ✓ 1000近い社内システムが動作している ✓ 本番環境と検証環境が存在している
9. ©Fusic Co., Ltd. 8 主な設計要件 ✓ 社内イントラにある基幹システムと接続する ⚫ 本番の安定性が最優先 ✓ 開発・検証・本番の3つの環境を用意する ⚫ 検証・本番環境は社内イントラと接続する ⚫ 開発環境は社内イントラと接続しない ✓ AWSアカウントは開発/検証で1つ、本番で1つ（VPCで環境を分割） ✓ 社内イントラ環境とCIDRが重複できない ✓ 最終的に200アカウント規模を見据える ⚫ 社内イントラのサービスを新しい基盤へ移行していく
10. ©Fusic Co., Ltd. 9 構築したアーキテクチャ 2
11. ©Fusic Co., Ltd. 10 AWS Transit Gateway ✓ VPCとオンプレミスネットワークを接続す るサービス ✓ 大規模ネットワーク構築で使われることが 多い ✓ マネージドで高可用性を提供 AWS Transit Gateway https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/what-is-transit-gateway.html
12. ©Fusic Co., Ltd. 11 アーキテクチャの全体像 開発環境 検証環境 本番環境 今回構築した範囲
13. ©Fusic Co., Ltd. 12 Hubアカウント 開発環境 検証環境 本番環境
14. ©Fusic Co., Ltd. 13 Spokeアカウント
15. ©Fusic Co., Ltd. 14 社内イントラとの接続
16. ©Fusic Co., Ltd. 15 環境ごとの通信分離 3
17. ©Fusic Co., Ltd. 16 アーキテクチャの全体像（再掲） 開発環境 検証環境 本番環境 3環境が混在した マルチアカウント基盤
18. ©Fusic Co., Ltd. 17 環境間の通信要件 異なる環境間の通信を「許可する・遮断する」か明確にする必要がある 本番 検証 マルチアカウント 開発
19. ©Fusic Co., Ltd. 18 環境間の通信は分離させたい 今回の方針：環境間通信は遮断する ✓ データの混在を防止 ✓ 検証・開発の事故を本番に波及させない 本番 検証 マルチアカウント 開発
20. ©Fusic Co., Ltd. 19 Transit Gatewayによる分離戦略 ルートテーブルを分割する 1つのTransit Gatewayに環 境ごとのルートテーブル を作成する Transit Gatewayを分割する 環境ごとにTransit Gatewayを作成する 環境間の通信を分離するパターンは2つ考えられる
21. ©Fusic Co., Ltd. 20 AWSのベストプラクティス 1リージョンに1つのTransit Gateway、ルートテーブルで分割が推奨 https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-best-design-practices.html
22. ©Fusic Co., Ltd. 21 Transit Gatewayによる分離戦略 今回の判断：環境ごとにTransit Gatewayを分離 ✓ 本番用Transit Gatewayを分けた理由 ⚫ 本番環境はDirect Connect経由で既存環境の基幹システムと接続して いる ⚫ 検証/開発環境の設定変更や障害が本番環境のTransit Gatewayに影響 することを原理的に排除する ✓ 開発用と検証用を分けた理由 ⚫ 理論的には開発/検証は1つのTGW + ルートテーブル分離で成立する ⚫ 環境ごとにTGWを分けるという一貫したルールにすることで、運用 判断をシンプルにし統一性を確保した
23. ©Fusic Co., Ltd. 22 例外を許容する記述もある AWSのホワイトペーパーには、以下の場合に複数のTransit Gatewayを作成 する場合があると明記 ✓ コントロールプレーンの操作を分離する ✓ 管理の容易性を高める https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure /transit-gateway.html
24. ©Fusic Co., Ltd. 23 Transit Gateway分離でも排除できないリスク Transit Gatewayを環境ごとに分割したが、環境間が繋がってしまうケースがある
25. ©Fusic Co., Ltd. 24 Transit Gateway分離でも排除できないリスク ①検証/開発環境の共有VPCを中継した通信
26. ©Fusic Co., Ltd. 25 Transit Gateway分離でも排除できないリスク ②Direct Connect経由で既存環境を中継した通信
27. ©Fusic Co., Ltd. 26 対応策：ルートテーブルにBlackhole routeを設定 ✓ 各Transit Gatewayのルートテーブルに、他環境のCIDRを Blackhole routeとして設定 ✓ Blackhole routeとは、「そのルートに一致する通信の転送を拒否 する」ルール • 検証環境のCIDR • 本番環境のCIDR 開発環境 ・開発環境のCIDR ・本番環境のCIDR 検証環境 ・開発環境のCIDR ・検証環境のCIDR 本番環境
28. ©Fusic Co., Ltd. 27 Blackhole routeを設定しない場合 Route Table ②Transit Gatewayの ルートテーブルを見に行く 10.1.100.0 10.1.250.0 ③共有リソースのVPCへ のルーティングがある (デフォルトルート) ④検証環境へのルーティ ングがある ①開発環境のリソースから検証環境の IP帯にアクセスしようとする
29. ©Fusic Co., Ltd. 28 Blackhole routeを設定すると.. ①開発環境のリソースから検証環境の IP帯にアクセスしようとする Route Table ②Transit Gatewayの ルートテーブルを見に行く ③検証環境のIP帯は Blackholeなので この時点でDropする 10.1.250.0 10.1.100.0
30. ©Fusic Co., Ltd. 29 ルートテーブルの例 開発環境 CIDR 検証環境 CIDR Blackholeルートを毎回登録するのはかなりの手間
31. ©Fusic Co., Ltd. 30 カスタムプレフィックスリストによる登録 ✓ プレフィックスリスト＝「1 つ以上の CIDR ブロックのセット」 ✓ プレフィックスリストは大きく2種類ある ⚫ AWSマネージドプレフィックスリスト ⚫ カスタマーマネージドプレフィックスリスト
32. ©Fusic Co., Ltd. 31 AWSマネージドプレフィックスリスト ✓ AWSが管理するプレフィックスリスト ✓ CloudFrontなどのAWSサービスで使用されるIPアドレスを一括 で参照できる
33. ©Fusic Co., Ltd. 32 カスタムマネージドプレフィックスリスト ✓ ユーザーが自由に作成できるプレフィックスリスト ✓ 作成したプレフィックスリストは、RAMを使って他のAWSアカ ウントに共有できる AWS account AWS account AWS Resource Access Manager
34. ©Fusic Co., Ltd. 33 カスタムマネージドプレフィックスリスト ✓ 各環境で使うCIDRを環境ごとのカスタムマネージドプレフィッ クスリストに登録 ✓ プレフィックスリストをTransit Gatewayのルートテーブルに関 連付ける ✓ プレフィックスリストにCIDRを登録すると自動的にBlackhole ルートを設定できる
35. ©Fusic Co., Ltd. 34 ここまでのまとめ Transit Gatewayのベストプラクティスは1リージョンに1Transit Gatewayだ が、設計による例外もあり得る Point 01 Transit Gatewayを分離しても、環境間通信を分離できないケースがある Point 02 プレフィックスリストを活用したBlackhole routeの設定でカバー Point 03
36. ©Fusic Co., Ltd. 35 リソース共有によるコスト最適化 4
37. ©Fusic Co., Ltd. 36 アカウントごとにリソースを作成したときの問題点 ✓ 200アカウント個別にリソースを作成すると、コストが膨大にな る ✓ 例えばNAT Gatewayの場合、1日297.6USDかかる 0.062(USD/時間)×200(アカウント)×24(時間/日）=297.6 USD ✓ コストを最適化するために、共有できるリソースは可能な限り共 有したい
38. ©Fusic Co., Ltd. 37 リソース集約のメリットとリスク メリット • コスト削減 • リソース管理の一元化 リスク • 集約箇所が単一障害点 となる • ルーティングの複雑化
39. ©Fusic Co., Ltd. 38 集約したリソース ✓ VPC EndpointとRoute 53 Inbound/Outbound Resolverを集約 ✓ 検証&開発用で共有することでさらにコスト最適化
40. ©Fusic Co., Ltd. 39 本番環境のみ共有リソースを分離した理由 なぜ本番用VPCを検証/開発と分離したか ✓ 本番用VPC EndpointsやRoute 53 Resolverを検証/開発と共用す る案もあった ✓ 分離した理由：本番環境への影響＞リソースのコスト ⚫ 本番環境の障害影響の局所化 ⚫ VPC Endpointのスループット/セキュリティポリシーの独立性 ✓ トレードオフ ⚫ VPC Endpoint・Resolverが二重構成になりコスト増 ⚫ 運用対象も増える
41. ©Fusic Co., Ltd. 40 具体的実装 具体的な実装方法は2通り ① Private Hosted Zone共有方式 メリット：コストが比較的少ない デメリット：アカウント数が増えると運用負荷が増える ② Resolver Rule＋RAM方式 メリット：大規模アカウントでも運用負荷が比較的少ない デメリット：Resolverのコストがかかる
42. ©Fusic Co., Ltd. 41 Private Hosted Zone共有方式 AWS account AWS account AWS account VPC VPC VPC Private Hosted zone ① VPC Endpointを 集約したいアカウントに 作成する ②Private Hosted Zoneを作成し、 VPC Endopointへのエイリアスレコードを作成 ③各アカウントへの関連を作成する https://docs.aws.amazon.com/ja_jp/whitepapers/latest/building-scalable-secure- multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html
43. ©Fusic Co., Ltd. 42 Resolver Rule＋RAM方式 AWS account AWS account AWS account VPC VPC VPC Inbound resolver Resolver Rule ②RAMでルールを共有 ③共有されたルールを VPCに関連づける ① VPC Endpointの ホスト名の転送先に VPC Resolverを指定
44. ©Fusic Co., Ltd. 43 どちらを選ぶかの判断軸 どちらを選ぶべきか ✓ 小規模なら①、アカウント数が増え続けるなら② ✓ 運用負荷とコストのどちらが先に効いてくるかが分岐点 今回は①を選択した 理由 ✓ 設定がシンプルで分かりやすい ✓ 運用負荷を軽減できるソリューションを使った（AFT）
45. ©Fusic Co., Ltd. 44 （補足）AFTとは ✓ AWS Control Tower Account Factory for Terraformの略称 ✓ Control Tower配下で、アカウント発行から必要なリソース作成 まで、Terraformで自動実行するソリューション ✓ AWS以外のリソース作成も自動化できる https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/aft-overview.html
46. ©Fusic Co., Ltd. 45 まとめ 5
47. ©Fusic Co., Ltd. 46 まとめ 異なる環境が混在するマルチアカウント基盤を構築した Point 01 Transit Gatweay自体を分離して、CIDR設計とBlackhole routeで環境間通信 を遮断 Point 02 共有リソースを集約しつつ、本番環境への影響を最小限にする コスト最適化 Point 03
48. ©Fusic Co., Ltd. OSEKKAI × TECHNOLOGY ご清聴いただきありがとうございました Thank You ココロと技術で、ぴったりも、びっくりも。 47