導入
マルチアカウントにすると、今度は「共通のネットワークやテンプレートを、アカウントの数だけ作り直すのか」という新しい非効率が生まれます。この最後のレッスンでは、アカウントをまたいでリソースやテンプレートを共有・標準化する3つの道具を学びます。
説明
| 道具 | 何を共有・標準化するか |
|---|---|
| AWS RAM（Resource Access Manager） | 個々のリソースそのもの（VPCのサブネット、Transit Gatewayなど）を、他アカウントと直接共有する |
| CloudFormation StackSets | 同じテンプレートのスタックを、複数アカウント・複数リージョンへ一括デプロイ・一括更新する |
| Service Catalog | 承認済みの**製品（テンプレート集）**を、利用者がセルフサービスで選んで使えるカタログとして提供する |
AWS RAM を使うと、あるアカウントで作った Transit Gateway や共有VPCのサブネットを、コピーせずにそのまま他のアカウントから使わせることができます。同じネットワークをアカウントごとに作り直す必要がなくなり、コストと管理の手間を大きく減らせます。特に「共有VPC（Shared VPC）」構成では、ネットワークチームが管理するVPCのサブネットを、各アプリケーションチームのアカウントに共有し、各チームはそこにEC2やLambdaを置くだけにする、という役割分担が定番です。
CloudFormation StackSets は、「同じセキュリティ設定・同じIAMロール・同じCloudTrail設定を、全アカウント・全リージョンに配りたい」というときに使います。OUを対象にすれば、新しくアカウントが増えたときも自動でスタックが展開されるため、Control Tower のガードレール配布の裏側でも使われている仕組みです。
Service Catalog は、開発者が「承認済みの構成（例: 標準EC2＋セキュリティグループ＋監視付きのAMI）」だけをセルフサービスで起動できるようにする仕組みです。開発者はAWSの詳細な知識がなくても、カタログから選ぶだけで組織のガードレールに沿ったリソースを作れます。Control Tower の Account Factory も、内部的には Service Catalog の製品としてアカウント発行を提供しています。
flowchart TD
RAM["AWS RAM"] --> R1["リソースそのものを共有<br/>（VPCサブネット・TGWなど）"]
SS["CloudFormation StackSets"] --> R2["同じテンプレートを<br/>複数アカウント/リージョンへ一括展開"]
SC["Service Catalog"] --> R3["承認済みテンプレートを<br/>セルフサービスで選んで使わせる"]
R1 --> GOAL["組織全体の標準化・運用負荷削減"]
R2 --> GOAL
R3 --> GOAL
3つを混同しやすいので、判断の軸を整理しておきます。
| 問いたいこと | 選ぶべき道具 |
|---|---|
| 「同じリソースを複数アカウントで共用したい」 | AWS RAM |
| 「同じ設定/テンプレートを複数アカウントへ配布したい」 | CloudFormation StackSets |
| 「開発者に選ばせる形で標準構成を提供したい」 | Service Catalog |
読んでみよう
この章で学んだ Organizations・SCP・Control Tower・一括請求・ログ集約・RAM/StackSets/Service Catalog は、SAPドメイン1「組織の複雑さに対応する設計」の骨格そのものです。次章では視点を「組織の統治」から「組織をまたぐネットワーク設計」へ移し、複数のVPCやオンプレミスを安全につなぐ横断ネットワークを学びます。