【AWS CloudFormation】スタックポリシーの深淵：本番インフラの「うっかり削除」を物理的に封殺するプロの実践知見
こんにちは。大規模クラウドインフラの設計・運用を統括するテックリードだ。
日々のインフラ運用において、最も恐ろしい瞬間は何だろうか？
深夜の障害？ 複雑なネットワークルーティングのデバッグ？ いや、違う。最も背筋が凍る瞬間とは、「開発環境のつもりで叩いたAWS CLIのコマンドが、実は本番環境のECSクラスターやRDSサブネットをターゲットにしており、数秒後に返ってきた `UPDATE_COMPLETE` という無慈悲な文字列を見た時」ではないだろうか。
人間の記憶や「指の確認」などという脆弱なレイヤーに信頼を置いてはならない。インフラストラクチャー・アイズ・コード（IaC）の現場において、事故を防ぐ唯一の防衛策は「システム的・物理的なガードレール」の構築だ。
今回は、AWS CloudFormationの機能でありながら、多くの現場で見落とされがちなしこり――「スタックポリシー（Stack Policies）」を取り上げる。単なるJSONの書き方解説ではない。チーム開発の速度を落とさずに、本番リソースの破滅的な誤操作を完全に無力化する実務運用の極意を伝授しよう。
—
1. なぜ「削除保護（Termination Protection）」だけでは不十分なのか？
多くのエンジニアは、誤操作対策としてスタックの「削除保護（Termination Protection）」を有効にしていることだろう。
確かにこれで `aws cloudformation delete-stack` からの本番環境消滅を防ぐことはできる。しかし、これで十分だと考えているなら、君のインフラはまだ危険にさらされている。
CloudFormationの脅威は「削除」だけではない。「意図しないアップデート（Update）」による置換（Replacement）こそが真の恐怖なのだ。
- 設定変更に伴うRDSインスタンスの強制再作成（データ消失）
- セキュリティグループのインバウンドルールのリセットによる一時的なサービス断
- S3バケットの暗号化設定変更に伴う予期せぬアクセス拒否
これらは `UpdateStack` APIによって引き起こされ、削除保護では1ミリも防げない。ここで登場するのが、リソースの更新そのものを粒度高く制御する「スタックポリシー」である。
—
2. スタックポリシーの基礎と「実戦で使える」JSON設計
スタックポリシーは、スタック更新時にどのリソースに対してどのような操作（`Update:Modify`, `Update:Replace`, `Update:Delete`）を許可または拒否するかを定義するJSONドキュメントだ。
まずは、本番環境において「絶対に死守すべきリソース」を保護するための、実用的なスタックポリシーのベストプラクティス構成を見てほしい。
実用的なスタックポリシー（`production-stack-policy.json`）
{
“Statement” : [
{
“Sid” : “AllowAllUpdatesByDefault”,
“Effect” : “Allow”,
“Principal” : “”,
“Action” : “Update:”,
“Resource” : “”
},
{
“Sid” : “ProtectCriticalDatabaseAndStorage”,
“Effect” : “Deny”,
“Principal” : “”,
“Action” : [
“Update:Replace”,
“Update:Delete”
],
“Resource” : [
“LogicalResourceId/ProductionDatabase”,
“LogicalResourceId/CustomerDataBucket”,
“LogicalResourceId/CoreVPC”
]
}
]
}
このポリシーの設計思想
1. デフォルト許可（Allow All）の原則: 最初のエントリで、基本的にはすべてのリソースのすべての更新を許可している。これがないと、通常のアプリケーションデプロイやマイナーな設定変更すらすべてブロックされてしまい、開発スピードが完全に死ぬ。
2. クリティカルリソースの限定防御（Deny Specific）: 2つ目のエントリで、DB、S3、VPCといった「置き換わったらビジネスが終了する」リソースに絞り、`Update:Replace` と `Update:Delete` を明示的に拒否（Deny）している。
3. 論理リソースID（LogicalResourceId）の指定: `Resource` 句には物理名（ARN）ではなく、CloudFormationテンプレート内の論理IDを指定する。これにより、スタック作成前であっても確実に対象を特定してロックできる。
—
3. 開発スピードを落とさない！実務運用における神テクニック
「でも、スタックポリシーを入れると、いざインフラを改修したい時にデプロイが弾かれて面倒くさくなるのでは？」
そう思った君は鋭い。厳格すぎるセキュリティは開発速度を殺し、結果としてエンジニアがポリシーをバイパスする裏技（手動でのポリシー上書きなど）を探し始めるという悪夢を生む。
ここからが、テックリードとしての腕の見せ所だ。開発スピードを殺さずに安全性を担保するプロの実践テクニックを公開しよう。
テクニック①：一時的ポリシー上書きによる「安全な脱獄」フロー
どうしても保護されたリソースを更新（例えばRDSのインスタンスタイプ変更など）する必要が生じた場合、管理者権限を持つCI/CDパイプラインやオペレータは、スタック更新時に一時的なポリシー（Explicit Policy）を渡すことで、ロックを一時的に解除できる。
aws cloudformation update-stack \
–stack-name production-core-infra \
–template-body file://updated-template.yaml \
–stack-policy-during-update-body file://temporary-allow-policy.json \
–capabilities CAPABILITY_IAM
この `temporary-allow-policy.json` には、一時的に当該リソースの変更を許可する記述を入れておく。これにより、「普段はガチガチに守られ、変更時は厳格な監査ログ（CloudTrail）を残しながら意図的にガードを下げる」という理想的なガバナンスが成立する。
テクニック②：IDE（VS Code）でのミスを防ぐプラグインとスニペット
開発者のローカル環境でのミスを極限まで減らすため、VS Codeを使用しているチームであれば、以下の拡張機能の導入を強制せよ。
- AWS Toolkit for Visual Studio Code: テンプレートの構文チェックや、リソースの可視化に必須。
- YAML / JSON Support (Red Hat): JSONのスキーマバリデーションを効かせ、スタックポリシーの記述ミスをコンパイル前に検知する。
さらに、チーム共有のsnippets（`.vscode/cloudformation.code-snippets`）にスタックポリシーの骨組みを登録しておき、新規スタック作成時には数キーの入力で必ずポリシーのスケルトンが生成されるようにルール化せよ。
—
4. チーム開発におけるガバナンスルール：共有化の極意
属人性を排し、チーム全体でこの仕組みを機能させるためには、GitリポジトリとCI/CDのパイプラインに以下のルールを組み込む必要がある。
1. テンプレートとポリシーの同居（Co-location）
インフラストラクチャのコードを管理するGitリポジトリでは、CloudFormationのテンプレート（`template.yaml`）の直下に、必ず対応するスタックポリシー（`stack-policy.json`）を同じディレクトリに配置する。
infra/
├── production/
│ ├── template.yaml
│ └── stack-policy.json # 常にセットでPRレビューの対象にする
2. GitHub Actions / GitLab CIでの自動適用
スタックの作成・更新を行うパイプライン（CD）のスクリプトには、必ず `–stack-policy-body` を含める。手動オペレーションを排除し、CIが自動的に最新のポリシーを適用・維持するように強制するのだ。
GitHub Actions のワークフロー例
- name: Deploy CloudFormation Stack
run: |
aws cloudformation deploy \
–template-file infra/production/template.yaml \
–stack-name production-cluster \
–stack-policy-file infra/production/stack-policy.json \
–capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM
—
5. おわりに：インフラエンジニアのプライドをコードに宿せ
「うっかり本番DBを消してしまいました」
――このセリフをビジネスの現場で発した瞬間、エンジニアとしての信頼は地に落ちる。そしてそれは、個人の不注意を責めるべき問題ではなく、「ミスを防げないシステム構造を放置した設計者の怠慢」なのだ。
CloudFormationのスタックポリシーは、コードを書く私たち自身を、そしてビジネスの継続性を未来永劫守るための「盾」である。
面倒くさがらずに今日のデプロイメントパイプラインに組み込め。君が眠っている間も、その強固なポリシーが本番インフラの平和を静かに守り抜いてくれるはずだ。