StackSetsの深淵：Service-managed vs Self-managedの「正解」と移行戦略
マルチアカウント環境において、AWS CloudFormation StackSetsは「インフラの民主化」を推し進める最強の武器だ。しかし、多くのエンジニアが「なんとなく」で権限モデルを選び、後の運用で技術的負債を抱えている。
今日は、StackSetsの二つの権限モデルを解剖し、なぜ今、組織が「Service-managed」に舵を切るべきなのか、その核心を突く。
—
1. 権限モデルの本質的対立
Self-managed permissions：古き良き「職人芸」
各ターゲットアカウントに対して、IAMロール（`AWSCloudFormationStackSetAdministrationRole`と`ExecutionRole`）を事前に手動（または別のIaC）でデプロイする必要がある。
- メリット: AWS Organizations外のアカウントや、複雑なクロスアカウント・クロスパーティション構成が可能。
- デメリット: アカウントが増えるたびに「ロールの配布」という儀式が必要。これが運用自動化の最大のボトルネックになる。
Service-managed permissions：現代の「自動化の極致」
AWS Organizationsと深く結合し、組織構造をStackSetsが直接参照する。
- メリット: 新規アカウント作成時、OU（組織単位）への紐付けだけでスタックが自動デプロイされる。「インフラの自動追従」が現実のものとなる。
- デメリット: Organizations環境が必須。
—
2. 現場が選ぶべき「勝者」は？
結論から言おう。新規構築なら100% Service-managed一択だ。
「Self-managedの柔軟性」は、ほとんどのケースで「管理コスト」という名の悪魔にすり替わる。新規アカウント作成時に自動で監視エージェントやセキュリティ設定が投入される体験を一度味わうと、二度と手動ロール管理には戻れない。
—
3. 開発スピードを最大化する「プロの実践テクニック」
VS Code神プラグイン
- CloudFormation Linter (cfn-lint): これがないなら今日からコードを書く資格がない。CI/CDパイプラインに組み込むのは当然だが、ローカルでリアルタイムに検証せよ。
- AWS Toolkit for VS Code: テンプレートのプレビューと、リソース定義への爆速ジャンプが必須。
隠れたキーボードショートカット (VS Code + CloudFormation)
- `Ctrl + Space` (補完): プロパティ名で迷うな。リソース型を打った瞬間にこれを叩き、全プロパティを呼び出せ。
- `Alt + Up/Down`: 複雑なネスト構造のブロックを一瞬で入れ替える。YAMLのインデント地獄から脱出せよ。
チーム開発の「神ルール」
- `!Sub`の多用を禁止せよ: 代わりに`Fn::Sub`の構文を使い、どこに何が注入されているか明示的にしろ。
- ParameterよりMappingを使え: 環境ごとの切り替えをParameterでやると、テンプレートが汚れる。`Mappings`でリージョンや環境変数（dev/stg/prod）を抽象化し、コードの重複を排除せよ。
—
4. Self-managedからService-managedへの「移行戦略」
既存のSelf-managedから乗り換える場合、以下の手順が最も安全だ。
1. スタックのインポート: 既存のスタックを削除せず、新しくService-managedでスタックをデプロイし、「リソースの所有権」を移行する。
2. ドリフト検出: `aws cloudformation detect-stack-drift` を実行し、既存リソースとの差分を徹底的に埋める。
3. 旧スタックのスタックセット解除: `RetainStacksOnAccountRemoval` を活用し、リソースを残したままStackSet管理のみを終了させる。
—
5. 実践的なベストプラクティス：YAML構成例
DRY（Don’t Repeat Yourself）を極めた、モジュール性の高いテンプレートの断片を公開する。
AWSTemplateFormatVersion: ‘2010-09-09’
Description: “Multi-Account Security Baseline”
環境ごとの差異をここに集約する（Mappingの活用）
Mappings:
ConfigMap:
prod:
InstanceType: “m5.large”
LogRetention: 365
dev:
InstanceType: “t3.micro”
LogRetention: 7
Resources:
# 冪等性を担保したリソース定義
SecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: “Base Security Group”
GroupName: !Sub “${AWS::StackName}-base-sg”
VpcId: !Ref VPCID # パラメータで注入
Outputs:
StackID:
Value: !Ref AWS::StackId
Export:
Name: !Sub “${AWS::StackName}-ID”
チームへの提言
StackSetsは単なるツールではない。「組織の権限構造をコードで定義する」という政治行為だ。
Service-managed permissionsに移行し、アカウントの増減というイベントを「IaCのトリガー」に昇華させろ。手動の作業を一つ減らすたびに、君たちのチームはより高次元のアーキテクチャ設計に時間を割けるようになる。
今の環境が「Self-managed」のままで苦しんでいるなら、それが君のチームが一段上に登るための最大の伸び代だ。今すぐリファクタリングの計画を立てろ。