Upgrade to Pro — share decks privately, control downloads, hide ads and more …

200アカウント規模を見据えた開発・検証・本番の​環境分離を成立させる、AWS Transit...

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

Presentation from JAWS-UG Fukuoka #26

Avatar for Ryosuke Tsuruda

Ryosuke Tsuruda

June 22, 2026

More Decks by Ryosuke Tsuruda

Other Decks in Technology

Transcript

  1. ©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
  2. ©Fusic Co., Ltd. 4 CONTENTS 目次 1. 背景と設計要件 2. 構築したアーキテクチャ

    3. 環境ごとの通信分離 4. リソース共有によるコスト最適化 5. まとめ
  3. ©Fusic Co., Ltd. 6 背景 ✓ 社内システムを動かしている既存のAWS環境がある(社内イントラ) ✓ 社内イントラに接続するマルチアカウント基盤を作成 ✓

    なぜマルチアカウントだったのか ⚫ AWSが推奨している方式を採用(セキュリティ、請求などの観点) ⚫ 組織ポリシー(サービス/チームごとにアカウントを分ける)に則る 必要があった https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/sec_securely_operate_multi_accounts.html
  4. ©Fusic Co., Ltd. 8 主な設計要件 ✓ 社内イントラにある基幹システムと接続する ⚫ 本番の安定性が最優先 ✓

    開発・検証・本番の3つの環境を用意する ⚫ 検証・本番環境は社内イントラと接続する ⚫ 開発環境は社内イントラと接続しない ✓ AWSアカウントは開発/検証で1つ、本番で1つ(VPCで環境を分割) ✓ 社内イントラ環境とCIDRが重複できない ✓ 最終的に200アカウント規模を見据える ⚫ 社内イントラのサービスを新しい基盤へ移行していく
  5. ©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
  6. ©Fusic Co., Ltd. 19 Transit Gatewayによる分離戦略 ルートテーブルを分割する 1つのTransit Gatewayに環 境ごとのルートテーブル

    を作成する Transit Gatewayを分割する 環境ごとにTransit Gatewayを作成する 環境間の通信を分離するパターンは2つ考えられる
  7. ©Fusic Co., Ltd. 21 Transit Gatewayによる分離戦略 今回の判断:環境ごとにTransit Gatewayを分離 ✓ 本番用Transit

    Gatewayを分けた理由 ⚫ 本番環境はDirect Connect経由で既存環境の基幹システムと接続して いる ⚫ 検証/開発環境の設定変更や障害が本番環境のTransit Gatewayに影響 することを原理的に排除する ✓ 開発用と検証用を分けた理由 ⚫ 理論的には開発/検証は1つのTGW + ルートテーブル分離で成立する ⚫ 環境ごとにTGWを分けるという一貫したルールにすることで、運用 判断をシンプルにし統一性を確保した
  8. ©Fusic Co., Ltd. 22 例外を許容する記述もある AWSのホワイトペーパーには、以下の場合に複数のTransit Gatewayを作成 する場合があると明記 ✓ コントロールプレーンの操作を分離する

    ✓ 管理の容易性を高める https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure /transit-gateway.html
  9. ©Fusic Co., Ltd. 26 対応策:ルートテーブルにBlackhole routeを設定 ✓ 各Transit Gatewayのルートテーブルに、他環境のCIDRを Blackhole

    routeとして設定 ✓ Blackhole routeとは、「そのルートに一致する通信の転送を拒否 する」ルール • 検証環境のCIDR • 本番環境のCIDR 開発環境 ・開発環境のCIDR ・本番環境のCIDR 検証環境 ・開発環境のCIDR ・検証環境のCIDR 本番環境
  10. ©Fusic Co., Ltd. 27 Blackhole routeを設定しない場合 Route Table ②Transit Gatewayの

    ルートテーブルを見に行く 10.1.100.0 10.1.250.0 ③共有リソースのVPCへ のルーティングがある (デフォルトルート) ④検証環境へのルーティ ングがある ①開発環境のリソースから検証環境の IP帯にアクセスしようとする
  11. ©Fusic Co., Ltd. 28 Blackhole routeを設定すると.. ①開発環境のリソースから検証環境の IP帯にアクセスしようとする Route Table

    ②Transit Gatewayの ルートテーブルを見に行く ③検証環境のIP帯は Blackholeなので この時点でDropする 10.1.250.0 10.1.100.0
  12. ©Fusic Co., Ltd. 30 カスタムプレフィックスリストによる登録 ✓ プレフィックスリスト=「1 つ以上の CIDR ブロックのセット」

    ✓ プレフィックスリストは大きく2種類ある ⚫ AWSマネージドプレフィックスリスト ⚫ カスタマーマネージドプレフィックスリスト
  13. ©Fusic Co., Ltd. 33 カスタムマネージドプレフィックスリスト ✓ 各環境で使うCIDRを環境ごとのカスタムマネージドプレフィッ クスリストに登録 ✓ プレフィックスリストをTransit

    Gatewayのルートテーブルに関 連付ける ✓ プレフィックスリストにCIDRを登録すると自動的にBlackhole ルートを設定できる
  14. ©Fusic Co., Ltd. 34 ここまでのまとめ Transit Gatewayのベストプラクティスは1リージョンに1Transit Gatewayだ が、設計による例外もあり得る Point

    01 Transit Gatewayを分離しても、環境間通信を分離できないケースがある Point 02 プレフィックスリストを活用したBlackhole routeの設定でカバー Point 03
  15. ©Fusic Co., Ltd. 36 アカウントごとにリソースを作成したときの問題点 ✓ 200アカウント個別にリソースを作成すると、コストが膨大にな る ✓ 例えばNAT

    Gatewayの場合、1日297.6USDかかる 0.062(USD/時間)×200(アカウント)×24(時間/日)=297.6 USD ✓ コストを最適化するために、共有できるリソースは可能な限り共 有したい
  16. ©Fusic Co., Ltd. 37 リソース集約のメリットとリスク メリット • コスト削減 • リソース管理の一元化

    リスク • 集約箇所が単一障害点 となる • ルーティングの複雑化
  17. ©Fusic Co., Ltd. 38 集約したリソース ✓ VPC EndpointとRoute 53 Inbound/Outbound

    Resolverを集約 ✓ 検証&開発用で共有することでさらにコスト最適化
  18. ©Fusic Co., Ltd. 39 本番環境のみ共有リソースを分離した理由 なぜ本番用VPCを検証/開発と分離したか ✓ 本番用VPC EndpointsやRoute 53

    Resolverを検証/開発と共用す る案もあった ✓ 分離した理由:本番環境への影響>リソースのコスト ⚫ 本番環境の障害影響の局所化 ⚫ VPC Endpointのスループット/セキュリティポリシーの独立性 ✓ トレードオフ ⚫ VPC Endpoint・Resolverが二重構成になりコスト増 ⚫ 運用対象も増える
  19. ©Fusic Co., Ltd. 40 具体的実装 具体的な実装方法は2通り ① Private Hosted Zone共有方式

    メリット:コストが比較的少ない デメリット:アカウント数が増えると運用負荷が増える ② Resolver Rule+RAM方式 メリット:大規模アカウントでも運用負荷が比較的少ない デメリット:Resolverのコストがかかる
  20. ©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
  21. ©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を指定
  22. ©Fusic Co., Ltd. 43 どちらを選ぶかの判断軸 どちらを選ぶべきか ✓ 小規模なら①、アカウント数が増え続けるなら② ✓ 運用負荷とコストのどちらが先に効いてくるかが分岐点

    今回は①を選択した 理由 ✓ 設定がシンプルで分かりやすい ✓ 運用負荷を軽減できるソリューションを使った(AFT)
  23. ©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
  24. ©Fusic Co., Ltd. 46 まとめ 異なる環境が混在するマルチアカウント基盤を構築した Point 01 Transit Gatweay自体を分離して、CIDR設計とBlackhole

    routeで環境間通信 を遮断 Point 02 共有リソースを集約しつつ、本番環境への影響を最小限にする コスト最適化 Point 03