マルチアカウント運用の最適解：CloudFormation StackSetsの「権限モデル」を完全攻略する
こんにちは。インフラの自動化を極める中で、必ずぶつかる壁が「マルチアカウント環境の管理」です。
「5つ以上のアカウントを個別に手動管理している」という状況は、エンジニアにとっての時限爆弾です。AWS CloudFormation StackSetsを使えば、一つのテンプレートから全アカウントへ一斉にリソースを展開できます。
しかし、ここで多くの人が迷うのが「Service-managed」と「Self-managed」のどちらを選ぶべきかという点です。今回は、この選択がなぜ重要なのか、そして現場で失敗しないための移行戦略を、伝説のSREの視点から解説します。
—
1. 権限モデルの真実：なぜ二種類あるのか？
StackSetsにおける権限モデルの違いは、一言で言えば「誰が権限管理の責任を負うか」です。
Self-managed permissions（旧来の方式）
- 仕組み: ターゲットとなる各アカウントに、管理用のIAMロール（`AWSCloudFormationStackSetAdministrationRole`）を事前に手動で作成しておく必要があります。
- 向いているケース: AWS Organizationsに参加していないアカウントや、ガバナンスが分断されている特殊な環境。
- デメリット: アカウントが増えるたびに、信頼関係や権限のセットアップを手動で行う必要があり、運用負荷が高い。
Service-managed permissions（次世代の推奨方式）
- 仕組み: AWS Organizationsと深く統合。管理アカウント（委任管理者）が、組織内のメンバーアカウントに対して「勝手に」リソースを展開できます。
- 向いているケース: AWS Organizationsを導入している、現代的なクラウド環境すべて。
- メリット: 「アカウントが組織に追加されたら自動的に設定を適用する」という、真の自動化が可能になります。
—
2. Hello World: Service-managed での自動デプロイ
まずは、組織内で「全アカウントに共通のIAMロールを配る」というタスクを想定した、最も強力なセットアップを体験しましょう。
手順1: 管理アカウントでの準備
AWS Organizationsの管理アカウント（または委任管理者）で、以下の機能を有効化します。
信頼されたアクセスを有効にする（最初の一回のみ）
aws cloudformation enable-aws-organizations-service-access
手順2: テンプレートの作成 (template.yaml)
シンプルに「全アカウントに特定のIAMロールを作成する」コードです。
AWSTemplateFormatVersion: ‘2010-09-09’
Description: “組織内アカウントに一律で配布される監査用IAMロール”
Resources:
AuditRole:
Type: ‘AWS::IAM::Role’
Properties:
RoleName: “CrossAccountAuditRole”
AssumeRolePolicyDocument:
Version: ‘2012-10-17’
Statement:
- Effect: Allow
Principal: {AWS: “arn:aws:iam::管理アカウントID:root”}
Action: ‘sts:AssumeRole’
手順3: StackSetの作成
これをCLIで実行する瞬間が、自動化の快感です。
aws cloudformation create-stack-set \
–stack-set-name “GlobalAuditRole” \
–template-body file://template.yaml \
–permission-model SERVICE_MANAGED \
–auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false
これで、今日から新しいアカウントが増えても、自動的にこのIAMロールが展開されます。これが「インフラの冪等性」の威力です。
—
3. 現場で震えるほど役立つ「移行戦略」
既にSelf-managedで運用している環境をService-managedへ移行したい場合、いきなり切り替えるのは危険です。以下のステップで安全に移行してください。
1. タグ付けによる切り分け: 既存のStackSetはそのままにし、新しいStackSetをService-managedで作成します。
2. インポートの検討: AWS CLIの `import-stacks-to-stack-set` を利用し、既存のリソースを新しいService-managedのスタックセットに紐付けます。
3. クリーンアップ: 移行が確認でき次第、古いSelf-managed用のIAMロールを削除し、依存関係を整理します。
—
先輩エンジニアからのアドバイス
「ツールは使うものではなく、自分の武器にするもの」です。
Self-managedは、過去の互換性のための遺産です。今から新規で構築するならば、迷わずService-managedを選択してください。 権限の管理をAWS Organizationsに委譲することで、あなたは「個々の設定」から解放され、「インフラ全体の設計」というより高次元な仕事に集中できるようになります。
この仕組みをマスターすれば、10アカウントあろうが100アカウントあろうが、あなたの管理コストは変わりません。さあ、手作業の時代を終わらせましょう。
何かわからないことがあれば、いつでも聞いてください。次は、このStackSetsをTerraformで抽象化する方法について語り合いましょうか。