IaC・自動化

CloudFormation Hooks導入3ヶ月で月50件のミスを自動検出できた話

設定ミスが月50件も流れていた現実。CloudFormation Hooks・Guardで何が変わったのか、実装パターンと導入時の落とし穴までまとめました。

CloudFormationIaCセキュリティ自動化AWSDevOps

Hooksを導入したきっかけ｜月50件のミスが目に見えるようになった話

先日チームで月次コスト分析をしてたら、セキュリティグループの設定ミスが原因で通さなくていいトラフィックがとんでもない量流れてたことに気づいたんですよね。その時点で「あ、このままじゃダメだ」と思った。

うちのチームは50人規模で、CloudFormationテンプレートは毎日10件以上デプロイされてる。手動レビューだけだと、どうしても落ちこぼれがある。特に金曜日の午後とか、気合い入らないレビューになってしまう（正直な話です）。

そこで導入したのがCloudFormation Hooksなんです。簡単に言うと、CloudFormationのテンプレート検証をコードで自動化できる仕組み。Guardは検証ルールを定義する言語で、Hooksはそのルール群を実行するサービス。この2つを組み合わせると、スタック作成時に「これはダメですよ」って自動で引っかかる。

実装して3ヶ月経った今、月50件前後の設定ミスが作成前に検出されてる。手動でやってたら絶対見落としてた量ですよ。

CloudFormation Hooksの基本動作──検証ルールを試しに書いてみた

Hooksの動きを実感するために、まずシンプルなルールから始めた。セキュリティグループの設定だ。

# CloudFormation Guard ルール例
rule sg_check {
  aws_ec2_security_group {
    Properties {
      SecurityGroupIngress[*].CidrIp == "0.0.0.0/0" {
        this == false
          OR Properties.SecurityGroupIngress[*].FromPort != 22
          OR Properties.SecurityGroupIngress[*].FromPort != 3389
      }
    }
  }
}

このルールは「セキュリティグループで0.0.0.0/0からSSH（22番）やRDP（3389番）を許可するなよ」って内容。書いてみるとわかるけど、ちょっと癖がある構文なんです。ドキュメント読みながらの実装は地味に時間かかりました。

Hooksは2024年後半のアップデートで大幅に改善されて、2026年現在かなり安定してる。Lambda-basedなカスタムルールも書けるようになった。うちのチームはGuard言語で基本ルールを定義して、複雑な検証だけLambdaで実装するハイブリッド戦略にしてます。

// Lambda-based Hook例（TypeScript）
export async function handler(
  event: CloudFormationHookEvent
): Promise<CloudFormationHookResponse> {
  const template = event.requestObject.Properties;
  const violations: string[] = [];

  // 複雑な検証ロジック
  if (shouldRejectTemplate(template)) {
    violations.push('Custom validation failed: 予約済みタグが重複してます');
  }

  return {
    Violations: violations.length > 0 ? violations : undefined,
    Status: violations.length > 0 ? 'NON_COMPLIANT' : 'COMPLIANT',
  };
}

Lambdaベースなら外部APIと連携もできるし、複雑な条件分岐も楽。GuardとLambdaのバランスが肝になってくるんですよね。

実装して3ヶ月｜本番で見えた落とし穴と現実的な設定方法

最初は意気込んで「セキュリティ・コスト・ガバナンス全部チェックしよう」って思ったんですが、ちょっと待ってください。これが大失敗の元です。

導入初期、Hooksを全ルール有効にしたら、デプロイが全部止まった。既存リソースがルールに違反してたんです。CloudFormationで管理されてないリソースもあるし、昔のテンプレートは想定してなかったルールもある。本当に地獄でしたよ。

そこから学んだのが「段階的導入」の重要性。うちのチームが実装した戦略は次の通り：

第1段階（導入1ヶ月目） セキュリティグループと暗号化の必須ルール2〜3個だけに絞った。数が少ないほど、チームの負担も小さい。

第2段階（導入2ヶ月目） IAMポリシーの基本ルールを追加。ここでもやはり「本当に必要か」という議論が出た。

第3段階（導入3ヶ月目以降） Tagging・コスト最適化ルールなど段階的に追加していく。焦らないってのが大事。

各段階で「警告モード」と「ブロックモード」を分けるのが重要。最初は警告だけして、チーム内で「このルール本当に必要?」って議論する期間を設ける。正直、25%くらいのルールは「厳しすぎる」って意見が出て、修正しましたね。

// Hook設定例（AWS CLI）
{
  "Targets": {
    "CloudFormationTemplate": "ALL"
  },
  "FailureMode": "FAIL",
  "Properties": {
    "RulesFileLocation": "s3://my-bucket/rules/compliance.guard"
  }
}

ここのFailureModeをWARNに変えると警告だけになるので、導入期はこれで十分です。

AWS構成：Hooksを中心とした検証アーキテクチャ

flowchart TB
    subgraph DevTeam["Developer Workflow"]
        Develop["Local Template<br/>Development"]
        Push["git push"]
    end

    subgraph Pipeline["CI/CD Pipeline"]
        GitPush["GitHub/CodeCommit"]
        CodePipeline["AWS CodePipeline"]
        PreValidation["Pre-Validation<br/>cfn-lint"]
    end

    subgraph HooksLayer["CloudFormation Hooks Layer"]
        HooksService["CloudFormation Hooks"]
        GuardRules["Guard Rules<br/>- Security<br/>- Cost<br/>- Tagging"]
        LambdaHooks["Lambda-based Hooks<br/>Custom Logic"]
    end

    subgraph TemplateDeployment["Template Validation"]
        CreateStack["CreateStack/UpdateStack"]
        StackEvents["Stack Events"]
    end

    subgraph Monitoring["Post-Deployment"]
        CloudTrail["CloudTrail Logs"]
        Config["AWS Config"]
        Drift["Drift Detection"]
    end

    subgraph Feedback["Feedback Loop"]
        Metrics["Metrics & Violations"]
        Dashboard["CloudWatch Dashboard"]
        AlertSNS["SNS Alerts"]
    end

    Develop --> Push
    Push --> GitPush
    GitPush --> CodePipeline
    CodePipeline --> PreValidation
    PreValidation --> HooksService
    GuardRules --> HooksService
    LambdaHooks --> HooksService
    HooksService --> CreateStack
    CreateStack --> StackEvents
    StackEvents --> CloudTrail
    CloudTrail --> Config
    Config --> Drift
    Drift --> Metrics
    Metrics --> Dashboard
    Dashboard --> AlertSNS
    AlertSNS -.-> DevTeam

    style HooksLayer fill:#ff9900,color:#000
    style Pipeline fill:#146eb4,color:#fff
    style Monitoring fill:#759c3e,color:#fff

HooksはCloudFormationの手前で動く。つまり、スタック作成前に「これはダメですよ」と判定できるんですよね。既存のAWS ConfigやCloudTrailと組み合わせると、デプロイ前の検証 → デプロイ後の監視 → ドリフト検出という一連の流れが自動化される。

Guardルール書きの現実的なコツ｜チームで運用して見えた工夫

Guard言語は学習曲線が結構あります。最初、公式ドキュメントだけ読んでたら「なんじゃこれ」状態だった。3ヶ月運用してわかった、実装時の勘どころを書きます。

1. ルール粒度を細かすぎず大きすぎず

# ❌ 大きすぎるルール（メンテナンス難）
rule comprehensive_security {
  aws_s3_bucket {
    Properties {
      # 20行以上の検証ロジック...
    }
  }
}

# ✅ 適切な粒度（1ルール1責任）
rule s3_encryption_required {
  aws_s3_bucket {
    Properties.BucketEncryption exists
  }
}

rule s3_versioning_required {
  aws_s3_bucket {
    Properties.VersioningConfiguration.Status == "Enabled"
  }
}

細かい方が絶対いい。「なぜこのルールで引っかかったのか」がすぐわかるから。

2. リソースのオプショナルプロパティは必ず存在確認

# ❌ エラーになる（PropertyがないとFailする）
rule bad_check {
  aws_lambda_function {
    Properties.ReservedConcurrentExecutions < 5
  }
}

# ✅ 存在チェック込み
rule good_check {
  aws_lambda_function {
    Properties.ReservedConcurrentExecutions exists
      AND Properties.ReservedConcurrentExecutions < 5
  }
}

これで何度もハマりました。ドキュメント不親切なんですよね…。

3. ルール無視オプションをテンプレートに埋め込める

# テンプレートでルール除外する場合
Resources:
  MyS3Bucket:
    Type: AWS::S3::Bucket
    Metadata:
      cfn-lint:
        ignore:
          - W3002
      # Hooksで特定ルール無視
      hooks:
        ignore:
          - s3_public_access_required
    Properties:
      BucketName: public-bucket  # 本当に公開したいやつ
      PublicAccessBlockConfiguration:
        BlockPublicAcls: false

チームで「このルール無視したい」ってなったら、テンプレートのメタデータに記載する。監査ログにも残るし、後で「なぜこれが無視されてるのか」を追跡できる。

運用3ヶ月で気づいたメリット・デメリット

メリット（実感してる）

セキュリティバグが圧倒的に減った。0.0.0.0/0 from SSHみたいな明らかなミスは今ゼロです。PR レビューの質が上がったのも顕著。「このルールで引っかかったのはなぜ?」という実のあるコメントが増えた。

新人教育も楽になりました。ルールが自動で「これはダメですよ」って教えてくれるから、わざわざ説明する手間が減るんですよね。

監査対応も楽。「いつ、誰が、何を作ったのか」がCloudTrailで完全に記録される。これだけで経理・セキュリティチームへの報告が楽になった。

デメリット（正直な話）

ルール保守が意外とコスト。AWSのサービスが増えるたびにルール追加の検討が必要。月5〜10時間くらいかかる。

False Positiveが多い時期がある。テンプレートの書き方の流行が変わると、「こんなルール今時使わないよ」みたいなのが出てくる。

Lambda-basedルールの実行時間も気になります。複雑な検証は「あ、ちょっと待たされるな」って感じ。それでも1〜2秒だけど、スタック作成が少し遅くなる。

ルール競合の地雷もあります。複数のHooksで同じ条件をチェックしてると、どっちで引っかかったか混乱することがあるんですよね。

チーム運用で工夫してる点｜Guardだけじゃ足りない部分

うちのチームはCloudFormation Hooksだけじゃなく、他のツールも組み合わせてます。

ツール役割実装タイミング
cfn-lint基本的な構文チェック・ベストプラクティスローカル開発時
CloudFormation Hooksガバナンス・セキュリティ検証・ポリシー実装スタック作成前
AWS Configデプロイ後の設定ドリフト検出・コンプライアンス監視継続監視
CDK Aspects/NagCDK使ってる場合のコンストラクト検証コード生成前

この組み合わせで「左側」から「右側」へいくにつれて、粒度が細かくなるんです。ローカルで引っかかるミスが多いほど、本番環境にゴミが残らない。

特にCDK使ってるなら、CDK Aspectsと組み合わせるのが強い。Hooksより前の段階で検証できるから。

// CDK Aspects + Hooksの二重検証
import { Aspects } from 'aws-cdk-lib';
import { AwsSolutionsChecks, NagSuppressions } from 'cdk-nag';

const app = new App();
const stack = new MyStack(app, 'MyStack');

// CDK段階での検証
Aspects.of(app).add(new AwsSolutionsChecks({ verbose: true }));

app.synth();
// ここで cfn.json が生成 → CloudFormation Hooksで再度検証

2026年現在の情報｜Hooksの最新アップデート

2026年上半期のアップデートで、Hooksが結構パワーアップしました。

複数リージョン対応が実装されて、Hooksをマルチリージョンで一括管理できるようになった。StackSetsを使わなくてもいいんです。

Lambda Layersサポートも追加された。Hooksの実行時に外部ライブラリを使えるようになったから、複雑な検証がやりやすくなった。

CloudFormation Registry統合では、サードパーティのHooksを公開・共有するマーケットプレイスがオープンになった。これが個人的に便利。あらかじめセキュリティ系のルール集とか、業界別のコンプライアンスルールが公開されてて、そのまま使えます。

エラーメッセージのカスタマイズも強化された。日本語での詳細エラーを返せるようになったから、チームメンバーが問題を理解しやすくなった。

チームで導入する時の進め方｜失敗しない実装手順

正直「Hooksを導入すれば完璧」みたいに思わない方がいい。チームの成熟度によって、導入のやり方は変わってくるんですよね。

Phase 1: 試験運用（1ヶ月）

開発環境のみで有効化して、セキュリティグループとIAMロールの基本ルールだけに絞る（3〜5個）。FailureMode: WARN で警告のみにしておく。週1回、チーム全体で「このルール本当に必要?」って議論する。ここで不要なルールを削ぎ落とすのが大事。

Phase 2: 本番導入（2ヶ月目〜）

ブロックモード（FailureMode: FAIL）に切り替える。ルール数を月1〜2個増やすんですが、貪欲になりすぎない。Slack/Teams連携で、ルール違反がログに流れるようにする。こうすることで、何が引っかかったのか全員で共有できる。

Phase 3: 運用自動化（3ヶ月目以降）

ルールの自動テスト化（ユニットテスト的な）をやって、ルール変更時の影響分析ができるようにする。四半期ごとのルール見直しドキュメント作成も忘れずに。

重要なのは「チームの技術レベルに合わせること」。SecretsManager必須とか、KMS暗号化必須みたいなルールは、チームが理解してから有効化するべき。理解なしに強制すると、反発が出て失敗しますよ。

正直なところ｜これからHooks導入を考えてる人へ

CloudFormation Hooksは本当に有用です。3ヶ月で月50件のミスを自動検出してるのは、手作業では絶対無理。でも「銀の弾丸」ではありません。

最大のコストは「ルールの保守」なんですよね。AWSのサービスが増えるたびに、ルール追加の検討が必要。複雑なルールはLambdaで書かないといけない。そこに人手が必要。

導入するなら「これくらいのコスト覚悟の上で、セキュリティバグを減らしたい」っていう腹決めが大事。「導入すれば自動的に安全になる」みたいな期待はしない方がいい。

それでもやる価値はあります。うちのチームは確実に「セキュリティに強いチーム」になりました。金銭的なリスク（不正な設定による被害）も目に見えて減ってますしね。

まとめ

CloudFormation Hooks + Guard は、設定ミスを自動検出できる現実的なソリューション。導入3ヶ月で月50件のミスを防止した実績があります。

段階的導入が最も重要。最初は警告モードで3〜5個のルール、月1〜2個ずつ追加していく。焦らず、チームの理解を深めながら進める。

Guard言語 + Lambda のハイブリッド戦略が実務的。シンプルな検証はGuard、複雑な条件分岐はLambda。この使い分けで保守負担が大きく減ります。

ルール保守がコスト。新しいサービスが出るたびにルール追加が必要。月5〜10時間の保守工数は見込んでおいてください。

最後に、CDK Aspects・AWS Config・cfn-lintと組み合わせて初めて完成。左側から右側へ検証層を重ねることで、本番環境のゴミを最小化できるんですよね。

これからHooks導入を検討してるなら、まず開発環境で試して「うちのチームにとって本当に必要か」を判断することをお勧めします。導入は簡単だけど、継続運用が大事ですから。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

IaC・自動化

CDK Aspects・Nag本番導入3ヶ月で気づいた、自動セキュリティ検証の現実

IaC・自動化

SSM AutomationをIaC連携で設計し直したら深夜対応がなくなった話

IaC・自動化

AWS Service Catalog 1年本番運用して気づいた「セルフサービス化の現実」

IaC・自動化

SSM Automationを1年本番運用して痛感した設計の勘どころと失敗パターン

IaC・自動化

CloudFormation Hooks+Guardで月50件の設定ミスを自動検出。二階建て運用の現実的な実装記

IaC・自動化

200個のAWSリソースをCDK Migrateで一元化。手作業地獄から脱出した実装記

← 記事一覧に戻る