CloudFormation Hooksを活用したプロアクティブなガバナンス統制：デプロイ前の自動ポリシー検証基盤の構築
こんにちは。大規模クラウドインフラの設計・運用を統括するテックリードの皆さん、日々のAWS環境のガバナンスに頭を悩ませていませんか？
「CI/CDパイプラインを回して、いざCloudFormationのスタックをデプロイしたら、セキュリティグループが全開放（`0.0.0.0/0`）されていた」「暗号化されていないS3バケットが作成されてしまい、コンプライアンス監査で指摘を受けた」——こんなインシデントは、モダンなSREチームであれば絶対に避けなければならない悪夢です。
これまで、こうしたポリシー違反の検知は「デプロイ後（AWS Config）」や「静的解析（cfn-lintやCheckovなど）」に頼りがちでした。しかし、静的解析はローカルの実行忘れをすり抜けることがあり、AWS Configは「事後検知」であるため、インフラが一時的に脆弱な状態で露出するリスクを完全にゼロにすることはできませんでした。
そこで登場するのが、AWS CloudFormation Hooksです。
これは、CloudFormationのプロビジョニングエンジン自体にフックし、リソースが作成・変更される「まさにその瞬間（デプロイ前）」に自動でポリシー検証を行い、違反があれば即座にデプロイをブロックするという、極限まで攻めたガバナンス基盤を実現する機能です。
今回は、このCloudFormation Hooksの内部メカニズムから、Lambda（AWS CloudFormation Handler）を用いたカスタムHookの完全実装、そしてチーム開発を加速させる実践的なプラットフォーム構築の手法まで、プロの知見を余すところなく伝授します。
—
1. CloudFormation Hooksのアーキテクチャと動作原理
CloudFormation Hooksは、AWS CloudFormation Registryに登録される拡張機能（エクステンション）の一種です。プロビジョニングのライフサイクルにおいて、以下のポイントで割り込み処理を行います。
[Developer (git push)]
↓
[CI/CD / AWS Console]
↓
[CloudFormation Stack Operation]
↓
==== ★ CloudFormation Hooks 起動 ★ ====
- PRE_CREATE / PRE_UPDATE / PRE_DELETE
- リソースのJSON/YAMLペイロードを検査
=======================================
├─ [PASS] → プロビジョニング実行へ進む
└─ [FAIL] → デプロイを即座に中断（ABORT） + エラー返却
Hookの3つのライフサイクルイベント
1. PRE_CREATE: リソースが作成される直前
2. PRE_UPDATE: リソースが更新される直前
3. PRE_DELETE: リソースが削除される直前（主にリソース保護用）
判定結果（Status）は以下の3つを返却します。
- `SUCCESS`: 検証OK。処理を継続。
- `FAILED`: ポリシー違反。デプロイを即座にアボート（ロールバック）。
- `NON_COMPLIANT`: 警告のみ（モードによって挙動が変わるが、通常はブロック推奨）。
—
2. 開発環境の極限効率化：VS Code設定と必須プラグイン
カスタムHookの開発は、AWS CloudFormation Command Line Interface (CloudFormation CLI) を用いてJava, Python, あるいはGoでハンドラーを実装します。ここでは最も柔軟性の高い Python をベースに進めます。
チーム共通のVS Code推奨プラグイン (`.vscode/extensions.json`)
開発メンバー間で設定を強制するため、リポジトリに以下の設定を配置してください。
{
“recommendations”: [
ms-python.python,
ms-python.vscode-pylance,
redhat.vscode-yaml,
amazonwebservices.aws-toolkit-vscode
]
}
デプロイ・テストスピードを極限まで高める隠しコマンド
CloudFormation CLI (`cfn`) を使ったローカルテストのループを高速化するため、以下のMakefileをプロジェクトルートに配置し、ビルドからテストまでの手数を極限まで削ります。
.PHONY: init test submit
開発環境の初期セットアップ
init:
pip install cfn-cli cloudformation-cli-python-plugin
単体テストの実行
test:
pytest –cov=src
ローカルでのHookシミュレーション
invoke:
cfn invoke PRE_CREATE test/payload.json
Registryへのパッケージングと登録
submit:
cfn submit –verbose
—
3. 実践：カスタムHook（Lambdaベース）の完全実装
今回は、「全てのS3バケットはデフォルト暗号化（SSE-S3またはSSE-KMS）が有効でなければならない」という社内規約を強制するカスタムHookを実装します。
Step 1: プロジェクトの初期化
cfn init –region ap-northeast-1 –namespace Acme –service S3 –name BucketEncryptionHook –language python
これにより、自動生成されたボイラープレートコード（`src/handlers.py`など）が作成されます。
Step 2: フックロジックの実装 (`src/handlers.py`)
CloudFormationから渡されるイベントペイロードをパースし、S3バケットのリソースプロパティに暗号化設定が含まれているかを検証する極限まで堅牢なコードを記述します。
import logging
from typing import Any, MutableMapping, Optional
from cloudformation_cli_python_lib import (
Action,
HandlerErrorCode,
OperationStatus,
ProgressEvent,
Resource,
SessionProxy,
exceptions,
)
ロガーの設定（CloudWatch Logsに出力される）
LOG = logging.getLogger(__name__)
LOG.setLevel(logging.INFO)
resource = Resource(“Acme::S3::BucketEncryptionHook”)
test_entrypoint = resource.test_entrypoint
@resource.handler(Action.CREATE)
def pre_create_handler(
session: Optional[SessionProxy],
request: MutableMapping[str, Any],
callback_context: MutableMapping[str, Any],
) -> ProgressEvent:
“””
PRE_CREATE イベントハンドラー
新規作成されるS3バケットのプロパティを検査し、暗号化が強制されているか検証する
“””
model = request.get(“clientRequestToken”, {}) # 簡易的な参照
target_model = request.get(“resourceProperties”, {})
LOG.info(f”Invoking S3 Encryption Hook. Properties: {target_model}”)
try:
# AWS::S3::Bucket の BucketEncryption プロパティをチェック
bucket_encryption = target_model.get(“BucketEncryption”)
if not bucket_encryption:
LOG.error(“Compliance Violation: S3 Bucket is missing BucketEncryption property.”)
return ProgressEvent(
status=OperationStatus.FAILED,
errorCode=exceptions.InvalidRequest.error_code,
message=”[SECURITY POLICY] すべてのS3バケットには BucketEncryption（サーバー側暗号化）の設定が必須です。”
)
LOG.info(“Compliance Check Passed: S3 Bucket has encryption enabled.”)
return ProgressEvent(
status=OperationStatus.SUCCESS
)
except Exception as e:
LOG.exception(f”Unexpected error occurred in Hook: {str(e)}”)
return ProgressEvent(
status=OperationStatus.FAILED,
errorCode=HandlerErrorCode.InternalFailure,
message=str(e),
)
@resource.handler(Action.UPDATE)
def pre_update_handler(
session: Optional[SessionProxy],
request: MutableMapping[str, Any],
callback_context: MutableMapping[str, Any],
) -> ProgressEvent:
# UPDATE時もCREATEと同等のロジックを適用
return pre_create_handler(session, request, callback_context)
@resource.handler(Action.DELETE)
def pre_delete_handler(
session: Optional[SessionProxy],
request: MutableMapping[str, Any],
callback_context: MutableMapping[str, Any],
) -> ProgressEvent:
# 削除時は特に制限をかけないため成功を返す
return ProgressEvent(status=OperationStatus.SUCCESS)
Step 3: スキーマ定義の修正 (`acme-s3-bucketencryptionhook.json`)
CloudFormation Registryに認識させるためのスキーマファイルを定義します。
{
“typeName”: “Acme::S3::BucketEncryptionHook”,
“description”: “Enforces default encryption on all S3 buckets prior to deployment.”,
“sourceUrl”: “https://github.com/your-org/infra-governance-hooks”,
“definitions”: {},
“properties”: {},
“handlers”: {
“preCreate”: {
“permissions”: []
},
“preUpdate”: {
“permissions”: []
},
“preDelete”: {
“permissions”: []
}
},
“targets”: {
“AWS::S3::Bucket”: {
“options”: {
“invocation”: “PYTHON”
}
}
}
}
> 💡 プロの知見: `targets` セクションで `”AWS::S3::Bucket”` を指定している点が極めて重要です。これにより、このHookは組織内のS3バケット作成・更新時にのみピンポイントで発火し、不要なオーバヘッドを完全に排除します。
—
4. 組織全体へのスケール：AWS CloudFormation Registryへの登録とHookの有効化
開発したHookは、AWSアカウント（またはOrganizationsの全アカウント）のCloudFormation Registryにプライベートエクステンションとして登録し、「Invocation（有効化）」する必要があります。
1. レジストリへの登録 (`cfn submit`)
cfn submit –verbose –region ap-northeast-1
これで、AWSアカウント内に `Acme::S3::BucketEncryptionHook` がプライベートExtensionとして登録されます。
2. Hookの有効化（CloudFormationコンソールまたはAWS CLI）
登録しただけでは動きません。アカウント全体、あるいは特定のスタックターゲットに対してHookを「有効（ENABLED）」にする必要があります。
aws cloudformation set-type-configuration \
–type HOOK \
–type-name “Acme::S3::BucketEncryptionHook” \
–configuration-alias “default” \
–configuration ‘{“CloudFormationConfiguration”: {“HookConfiguration”: {“TargetStacks”: “ALL”, “FailureMode”: “FAIL”}}}’ \
–region ap-northeast-1
- `FailureMode: FAIL`: ポリシー違反時にスタックのデプロイを強制停止させます（ガバナンス統制の要）。
- `TargetStacks: ALL`: アカウント内のすべてのCloudFormationスタックのデプロイに対してこのHookを適用します。
—
5. 動作検証：デプロイが華麗に弾かれる瞬間
それでは、暗号化設定を意図的に抜いた不良テンプレートを用意し、デプロイ時にどう挙動するか確認しましょう。
不正なCloudFormationテンプレート (`malformed-stack.yaml`)
AWSTemplateFormatVersion: ‘2010-09-09’
Resources:
InsecureBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: my-super-insecure-bucket-12345
# あえて BucketEncryption を記述しない
デプロイコマンドの実行
aws cloudformation create-stack \
–stack-name insecure-test-stack \
–template-body file://malformed-stack.yaml \
–region ap-northeast-1
期待される結果（CloudFormationの応答）
CloudFormationはスタック作成の初期段階でHookを呼び出し、Lambdaが違反を検知して即座に処理をアボートします。コンソールやCLIには以下のエラーが返却されます。
An error occurred (ValidationError) when calling the CreateStack operation:
Resource handler returned message: “[SECURITY POLICY] すべてのS3バケットには BucketEncryption（サーバー側暗号化）の設定が必須です。” (RequestToken: …, HandlerErrorCode: InvalidRequest)
見事にデプロイがブロックされました！
開発者はAWS環境を汚すことなく、ローカルまたはCI/CDパイプラインのファーストステップで規約違反に気づくことができます。
—
6. テックリードが実践すべき運用上のベストプラクティス
1. FailureModeは原則 `FAIL`、移行期のみ `WARN`
新規導入時は既存スタックの更新で思わぬブロックが発生するリスクがあります。最初は `FailureMode: WARN` でCloudWatch Logsの検知数を確認し、安全性を担保した上で `FAIL` に切り替えるのが定石です。
2. 組織展開にはAWS CloudFormation Registryのパブリッシュ機能を活用
AWS Organizations環境であれば、Delegated Administratorを設定することで、マスターアカウントから配下の子アカウント群へ一括でカスタムHookを自動配信・有効化できます。個別に `cfn submit` を叩く運用は今すぐやめましょう。
3. ユニットテストの徹底
LambdaベースのHookコードは `pytest` を用いて、モックペイロードに対するパス/フェイルのテストケースを必ずCI（GitHub Actions等）に組み込んでください。Hook自体のバグがインフラ全体のデプロイ停止を引き起こす「デッドロック」を防ぐためです。
—
終わりに
CloudFormation Hooksは、従来の「静的解析による水際対策」や「Configによる事後お掃除」というインフラ運用のパラダイムシフトを起こす強力な武器です。
「ガードレール」をクラウドのプロビジョニング層の深部に組み込むことで、開発チームのスピード感を損なうことなく、極めて高いセキュリティとコンプライアンスを両立させることが可能になります。
明日の朝、まずはS3やIAMの重要リソースに対して、組織で最低限守るべきポリシーを1つ、このCustom Hookとして実装してみてはいかがでしょうか。あなたのクラウドインフラストラクチャは、より強靭で美しいものへと進化するはずです。