エンジニアの皆さん、こんにちは。インフラの守護神、あるいは「破壊を未然に防ぐ最後の砦」としてのSREへようこそ。
AWS CloudFormation（CFn）は、コードでインフラを定義する（IaC）強力なツールですが、同時に「たった数行のミスで本番環境を全滅させる」という諸刃の剣でもあります。
今回は、そんな悲劇を未然に防ぐための、「スタックポリシー（Stack Policies）」という、現場のシニアが必ず仕込んでいる「守りの要」について解説します。
—
1. スタックポリシーとは何か？（初心者のための概念図）
CloudFormationにおいて、スタックポリシーは「特定のスタックに対する操作のガードレール」です。
通常、IAM権限があれば「更新（Update）」や「削除（Delete）」が可能ですが、人間はミスをする生き物です。誤ってコマンドを打ったり、テンプレートのパラメータを間違えたりした瞬間に、DBが消滅する……そんな事故を、ポリシーファイル一枚で防ぐのがこの機能の真髄です。
2. まずはセットアップ：Hello World的な「保護設定」
まずは、最も基本的な「意図しない変更をすべて拒否し、必要な時だけ許可する」ための設定ファイルを見てみましょう。これを`policy.json`として保存します。
{
“Statement”: [
{
“Effect”: “Deny”, // 拒否する
“Action”: “Update:”, // 全ての更新操作を
“Principal”: “”, // 全ユーザーに対して
“Resource”: “” // このスタック内の全リソースに適用
},
{
“Effect”: “Allow”, // ただし、これだけは許可する
“Action”: “Update:Modify”, // 属性の変更（例えばEC2のタグ追加など）
“Principal”: “”,
“Resource”: “”
}
]
}
どう動くのか？
- デフォルトの挙動: 「Deny」が効いているため、スタックの構成変更（Update）は全て弾かれます。
- 安全装置: もし「DBのインスタンスタイプを間違えて変更しようとした」としても、CFnは「ポリシーにより禁止されています」とエラーを返します。これで心臓が止まるような事故は激減します。
3. 【実務的ユースケース】RDSやS3を「絶対守る」設計
現場では、「データベースやS3バケットといったステートフルなリソース」は、絶対に削除や置換をさせたくありません。以下のポリシーは、本番環境の「鉄壁」として活用してください。
{
“Statement”: [
{
“Effect”: “Deny”,
“Action”: [“Update:Replace”, “Update:Delete”], // リソースの置換・削除をブロック
“Principal”: “”,
“Resource”: “LogicalResourceId/MyDatabaseInstance” // 論理IDで対象をピンポイント指定
}
]
}
- ポイント: `LogicalResourceId`を指定することで、ネットワークやIAMロールといった「変更しても安全なリソース」は更新を許可し、DBだけをピンポイントで保護できます。これが、SREが知っている「現場の知恵」です。
4. 適用と運用：どうやって現場に組み込むか
ポリシーを作成したら、以下のコマンドで適用します。
スタック作成時に適用する場合
aws cloudformation create-stack \
–stack-name production-db-stack \
–template-body file://template.yaml \
–stack-policy-body file://policy.json
もし後から適用したい場合は、`set-stack-policy`コマンドを使います。
aws cloudformation set-stack-policy \
–stack-name production-db-stack \
–stack-policy-body file://policy.json
5. 伝説のエンジニアからのアドバイス
初心者のうちは「ポリシーを設定すると、更新するたびに面倒くさいのでは？」と思うかもしれません。しかし、「面倒くさい」ことは「安全である」ことの裏返しです。
- 緊急時の運用: どうしても更新が必要な時は、`set-stack-policy`で一時的に「Allow」に書き換えてから作業し、終わったらすぐに「Deny」に戻す。この「オペレーションの儀式」こそが、ヒューマンエラーを物理的に排除する最善の方法です。
まとめ：明日からできること
1. 本番環境の全スタックに「Deny Update:」を適用する。
2. 特にRDSやS3には「Replace」禁止ポリシーを仕込む。
3. 「失敗できない」環境ほど、自分を縛るガードレールを先に作る。
これをマスターすれば、深夜のオンコールで「間違えて本番のDBを削除しました」という悪夢を見ることはなくなります。インフラエンジニアの真の仕事は、作るだけでなく「壊させない」ことにあります。ぜひ、次のデプロイから試してみてください。
応援しています。あなたのインフラが、明日も安定して稼働し続けることを願って。