導入
マルチアカウントにすると、今度は「共通のネットワークやテンプレートを、アカウントの数だけ作り直すのか」という新しい非効率が生まれます。この最後のレッスンでは、アカウントをまたいでリソースやテンプレートを共有・標準化する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 |
具体例
10チームがそれぞれ自分のアカウントを持つ企業で、3つの「非効率」を3つの道具で解消します。
- 「各チームが同じVPCを作り直している」→ AWS RAM … ネットワークチームが1つの共有VPCを作り、そのサブネットをRAMで各チームのアカウントに共有。各チームはコピーせずそのVPCにEC2やLambdaを置くだけ。同じネットワークを10回作る無駄が消える。
- 「全アカウントに同じ監査用IAMロールとCloudTrail設定を入れたい」→ CloudFormation StackSets … 1つのテンプレートを、OUを対象に一括配布。新アカウントがOUに増えたら自動で展開される。
- 「開発者に、承認済み構成だけを自由に使わせたい」→ Service Catalog … 「標準EC2+セキュリティグループ+監視付き」を製品として登録し、開発者はカタログから選ぶだけ。AWSの詳細を知らなくても組織のガードレールに沿える。
混同しやすいですが軸は明確です。「リソースそのものを共用=RAM、テンプレートを配布=StackSets、選ばせて提供=Service Catalog」。要件の動詞(共用する/配布する/選ばせる)で見分けます。
読んでみよう
この章で学んだ Organizations・SCP・Control Tower・一括請求・ログ集約・RAM/StackSets/Service Catalog は、SAPドメイン1「組織の複雑さに対応する設計」の骨格そのものです。次章では視点を「組織の統治」から「組織をまたぐネットワーク設計」へ移し、複数のVPCやオンプレミスを安全につなぐ横断ネットワークを学びます。