🏢 建築設計図と実際の建物で例えると超わかりやすい!
CloudFormation = 建物の設計図📐
設計図通りに建物（AWSリソース）を建てたはずなのに...
時間が経つと誰かが勝手に改装して
設計図と違う状態
に！😱
これが
「ドリフト（Drift）= 乖離」
です。
AWS Config
は定期的に建物を点検する
検査員👷
Systems Manager Automation
は設計図通りに直す
工事業者🔧
検査員が問題を見つけたら → 工事業者が自動で修復！
これが今日学ぶ最強の組み合わせです✨
🏗️ 建築プロジェクトに例えると...
設計図（CloudFormation）
建築家が作った完璧な設計図。
「3階建て、各階に10部屋、エレベーター2基」
📋 設計図の内容（テンプレート）：
• EC2インスタンス: t3.medium
• セキュリティグループ: ポート80, 443のみ
• RDS: db.t3.small, 暗号化ON
• S3バケット: バージョニング有効
✅ 設計図通りに建設したはず...
実際の建物（現在の状態）
誰かが勝手に改装してしまった！
「3階建て、でも部屋数が変わってる、エレベーター1基に」
🚨 実際の状態（勝手な変更）：
• EC2インスタンス: t3.large に変更された！
• セキュリティグループ: ポート22を誰かが追加！
• RDS: 暗号化を誰かがOFFに！
• S3バケット: バージョニングが無効化！
❌ これが「ドリフト（乖離）」です！
よくある状況：
• 「急いでるから」とマネジメントコンソールから直接変更
• トラブルシューティング中に設定を変更してそのまま
• 新人エンジニアが知らずにAWS CLIで変更
• セキュリティチームが緊急対応で設定変更
• テスト目的で変更してリセット忘れ
💡 結果：CloudFormationテンプレートと実際のリソースが不一致に！
📊 ドリフトの種類と実例
プロパティの変更
実際： t3.large
📝 例：
• EC2インスタンスタイプ変更
• RDSストレージサイズ拡張
• Lambda関数のメモリサイズ
• EBSボリュームサイズ
検出難易度: ★★☆☆☆
リソースの追加
実際： ポート80, 443, 22
📝 例：
• SGに新しいルール追加
• IAMポリシーに権限追加
• S3バケットにタグ追加
• VPCにサブネット追加
検出難易度: ★★☆☆☆
リソースの削除
実際： エレベーター1基
📝 例：
• SGルールを誰かが削除
• タグが消えている
• アラームが削除された
• ログ設定が無効化
検出難易度: ★★★☆☆
セキュリティ設定の変更
実際： 暗号化OFF
📝 例：
• RDS暗号化を無効化
• S3バケットポリシー変更
• パブリックアクセス許可
• バックアップ設定OFF
検出難易度: ★★★★☆
1. セキュリティリスク：
• 意図しないポート開放でハッキングリスク
• 暗号化が無効化されてデータ漏洩
• パブリックアクセスで機密情報流出
2. コンプライアンス違反：
• 監査で承認されていない設定が発覚
• 規制要件を満たせない
• 認証更新が不可能に
3. 予期しない障害：
• CloudFormationスタック更新時に失敗
• 災害復旧時に正しく復元できない
• Infrastructure as Codeが機能しない
4. コスト超過：
• インスタンスサイズが勝手に大きくなって高額請求
• 不要なリソースが放置
• バックアップが過剰に取られる
🔄 検出から自動修復までの完全フロー
ルール名：
cloudformation-stack-drift-detection-check
📋 チェック内容：
• CloudFormationスタックに対してドリフト検出を実行
• テンプレートと実際のリソース設定を比較
• 24時間ごと、または設定変更検出時に実行
• ドリフトがあれば「NON_COMPLIANT」判定
🎯 検出対象：
• すべてのCloudFormationスタック
• または特定のタグ/名前パターンのスタック
AWS Configが自動的に以下を実行：
1. CloudFormationスタックを特定
2.
DetectStackDrift
APIを呼び出し
3. スタック内の各リソースをチェック
4. テンプレートとの差分を検出
📊 検出結果：
• IN_SYNC : 一致（問題なし）
• DRIFTED : 乖離あり（修復必要）
• MODIFIED : 一部変更
• DELETED : リソース削除済み
判定条件：
• ドリフト状態が
DRIFTED
→ ❌ 非準拠
• ドリフト状態が
IN_SYNC
→ ✅ 準拠
記録される情報：
• どのスタックでドリフトが発生したか
• どのリソースが変更されたか
• 具体的な変更内容（差分）
• 検出日時とタイムスタンプ
💡 この情報を使って自動修復をトリガー！
イベントパターン：
「Configルールが非準拠を検出したら」
→ EventBridgeが自動的にキャッチ
{
"source": ["aws.config"],
"detail-type": ["Config Rules Compliance Change"],
"detail": {
"configRuleName": [
"cloudformation-stack-drift-detection-check"
],
"newEvaluationResult": {
"complianceType": ["NON_COMPLIANT"]
}
}
}
Systems Manager Automation Runbook を起動
Runbook名：
AWS-UpdateCloudFormationStack
実行内容：
1. 問題のスタックを特定
2. 元のテンプレートを取得
3. スタック更新（Update Stack）を実行
4. CloudFormationが設計図通りに修復
5. 完了後に通知
🎯 結果：
• すべての変更が元に戻る
• 設計図通りの状態に復元
• 手動作業ゼロ！
通知内容：
• SNSトピック経由でメール/Slack通知
• 「スタック○○のドリフトを自動修復しました」
• 修復内容の詳細レポート
• 次回チェック予定日時
📊 監査ログ：
• CloudTrailに全操作を記録
• Config Timelineで履歴確認
• 誰が変更して、いつ修復されたかすべて追跡可能
🎉 自動運用サイクルの完成！
🤖 AWS-UpdateCloudFormationStack の仕組み
🔧 Runbookの動作ステップ
Step 1: 入力パラメータ取得
• StackName: 修復対象のスタック名
• TemplateBody/TemplateURL: 元のテンプレート
• Parameters: スタックパラメータ
• Capabilities: 必要な権限（IAM作成など）
Step 2: 現在の状態確認
• スタックの存在確認
• 現在のスタックステータスチェック
• 更新可能な状態か検証
• （UPDATE_IN_PROGRESS なら待機）
Step 3: スタック更新実行
•
UpdateStack
API呼び出し
• 元のテンプレートを使用
• 変更セット（Change Set）を作成
• CloudFormationが差分を自動検出して修正
Step 4: 完了待機
• スタック更新完了を監視
• ステータスが
UPDATE_COMPLETE
になるまで待機
• タイムアウト: 通常30-60分
• エラー発生時はロールバック
Step 5: 結果レポート
• 修復成功/失敗をレポート
• 変更されたリソース一覧
• 実行ログの出力
• CloudWatch Logsに詳細記録
1. 元のテンプレート通りに復元
→ 手動変更をすべて上書き
2. 安全な更新
→ Change Setで事前確認
→ 失敗時は自動ロールバック
3. 完全自動化
→ 人間の介入不要
→ 深夜でも修復可能
🎯 これで設計図通りの状態が常に維持されます！
🛠️ 完全な実装例
1️⃣ AWS Configルールの設定
Resources: DriftDetectionConfigRule: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: cloudformation-stack-drift-detection Description: CloudFormationスタックのドリフトを検出 Source: Owner: AWS SourceIdentifier: CLOUDFORMATION_STACK_DRIFT_DETECTION_CHECK Scope: ComplianceResourceTypes: - AWS::CloudFormation::Stack MaximumExecutionFrequency: TwentyFour_Hours # 24時間ごと
2️⃣ EventBridgeルールの設定
DriftDetectionEventRule: Type: AWS::Events::Rule Properties: Name: cfn-drift-auto-remediation Description: ドリフト検出時に自動修復 EventPattern: source: - aws.config detail-type: - Config Rules Compliance Change detail: configRuleName: - cloudformation-stack-drift-detection newEvaluationResult: complianceType: - NON_COMPLIANT State: ENABLED Targets: - Arn: !Sub 'arn:aws:ssm:${AWS::Region}:${AWS::AccountId}:automation-definition/AWS-UpdateCloudFormationStack:$DEFAULT' RoleArn: !GetAtt AutomationRole.Arn Id: UpdateStackTarget InputTransformer: InputPathsMap: stackName: $.detail.resourceId InputTemplate: | { "StackName": ["<stackName>"], "UsePreviousTemplate": ["true"], "AutomationAssumeRole": ["!GetAtt AutomationRole.Arn"] }
3️⃣ IAMロールの設定
AutomationRole: Type: AWS::IAM::Role Properties: RoleName: CFN-Drift-Auto-Remediation-Role AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - ssm.amazonaws.com - events.amazonaws.com Action: sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AmazonSSMAutomationRole Policies: - PolicyName: CloudFormationUpdatePolicy PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - cloudformation:UpdateStack - cloudformation:DescribeStacks - cloudformation:DescribeStackEvents - cloudformation:GetTemplate Resource: '*' - Effect: Allow Action: - iam:PassRole Resource: '*' Condition: StringEquals: iam:PassedToService: cloudformation.amazonaws.com
4️⃣ SNS通知の設定（オプション）
DriftNotificationTopic: Type: AWS::SNS::Topic Properties: TopicName: cfn-drift-notifications DisplayName: CloudFormation Drift Notifications Subscription: - Endpoint: your-email@example.com Protocol: email DriftNotificationRule: Type: AWS::Events::Rule Properties: Name: cfn-drift-notification EventPattern: source: - aws.ssm detail-type: - EC2 Automation Execution Status-change Notification detail: DocumentName: - AWS-UpdateCloudFormationStack Targets: - Arn: !Ref DriftNotificationTopic Id: SNSTarget
💼 実際のユースケースと活用例
エンタープライズ本番環境
複数チームが同じインフラを触る環境で、誰かが勝手に設定変更してしまう
解決策：
• ドリフト検出を有効化
• 手動変更を即座に元に戻す
• Slackに通知して犯人を特定
• 教育材料として活用
結果：
• 設定変更は必ずコード経由に
• Infrastructure as Codeが徹底
• セキュリティ事故ゼロ
効果: ★★★★★
セキュリティコンプライアンス
監査で「承認されていない変更」が発覚し、コンプライアンス違反のリスク
解決策：
• 暗号化設定などの重要設定を監視
• 変更を即座に検出・修復
• 監査証跡を自動記録
• 変更履歴を可視化
結果：
• ISO27001/SOC2適合
• 監査対応が超楽に
• 規制要件クリア
効果: ★★★★★
コスト最適化
誰かがインスタンスサイズを大きくして、気づいたら請求額が爆増
解決策：
• インスタンスタイプ変更を検出
• 承認されたサイズに自動復元
• コスト超過を未然に防ぐ
• 変更理由を記録して分析
結果：
• 月額30%コスト削減
• 予算超過ゼロ
• コスト管理の自動化
効果: ★★★★☆
災害復旧（DR）対策
災害復旧テストで、CloudFormationが失敗。実際の設定とテンプレートが違っていた
解決策：
• 常に設計図通りの状態を維持
• DR時のスタック再作成を保証
• 定期的なドリフトチェック
• 復旧手順の自動化
結果：
• DR成功率100%
• RPO/RTO達成
• 災害時の安心感
効果: ★★★★★
• 重要度の高いスタックから優先的に
• 本番環境は必須、開発環境は任意
• タグで管理対象を明確に
2. 自動修復は段階的に導入
• 最初は通知のみ（自動修復OFF）
• ドリフトのパターンを分析
• 意図的な変更と誤操作を区別
• 安定してから自動修復ON
3. 重要度別に対応を変える
• 【高】セキュリティ設定 → 即座に自動修復
• 【中】リソースサイズ → 通知して確認後に修復
• 【低】タグの変更 → 定期的にまとめて修復
4. チームへの教育
• 「手動変更は禁止」を周知
• すべての変更はコード経由
• ドリフトアラートの意味を理解
• インシデント分析を共有
5. 例外管理の仕組み
• 緊急時の手動変更フロー定義
• 一時的にルールを無効化する手順
• 変更後にテンプレート更新
• ドキュメント化と承認プロセス
6. 定期的なレビュー
• 週次でドリフト発生状況を確認
• よくある変更パターンを分析
• テンプレートの改善点を発見
• チーム全体で振り返り
7. 監査ログの活用
• CloudTrailでドリフト原因を追跡
• 誰がいつ変更したか記録
• Config Timelineで変更履歴可視化
• コンプライアンスレポート作成
8. コスト監視との連携
• ドリフトでコスト増加を検出
• 予算アラートと組み合わせ
• Cost Explorerで影響分析
• 無駄なリソースを即座に削減
1. 削除されたリソース
• スタック外で手動削除されたリソースは復元不可
• CloudFormationは既存リソースの更新のみ可能
• 完全な復元にはスタック再作成が必要
2. 変更不可能なプロパティ
• RDSのインスタンスIDなど一部プロパティは変更不可
• この場合、リソースの置き換え（Replacement）が発生
• データ損失のリスクあり
3. 依存関係エラー
• 他のリソースに依存する変更は失敗する可能性
• 複雑なスタックでは修復に時間がかかる
• 手動介入が必要なケースも
4. 権限不足
• AutomationRoleに必要な権限がないと失敗
• IAM権限、KMS暗号化キーなど確認
• エラーログを確認して権限追加
💡 推奨事項：
• 最初は通知のみで運用開始
• ドリフトパターンを把握してから自動修復を有効化
• 重要なリソースは手動確認後に修復
• 定期的にテスト環境で動作確認
❓ よくある質問（FAQ）
• 1時間、3時間、6時間、12時間、24時間から選択
• または設定変更時にトリガー
• 頻度を上げるとコストも増加
• 通常は24時間で十分
💰 コスト例（東京リージョン）：
• 24時間ごと: 月額$3-5程度
• 1時間ごと: 月額$50-70程度
✅ 安全なケース：
• 設定変更のみ（タグ、SG、IAMポリシーなど）
• CloudFormationが既存リソースを更新
• データは保持される
⚠️ 注意が必要なケース：
• リソースの置き換え（Replacement）が発生
• 例：RDSインスタンスIDの変更
• この場合は新規作成→古いものを削除
💡 対策：
• DeletionPolicyを「Retain」に設定
• 重要データは必ずバックアップ
• Change Setで事前確認
正しいフロー：
1. CloudFormationテンプレートを更新
2. スタック更新を実行
3. これで変更が「正式」になる
4. ドリフトは発生しない
間違ったフロー：
1. マネジメントコンソールで直接変更
2. ドリフトとして検出される
3. 自動修復で元に戻される
4. 変更が失われる
💡 Infrastructure as Codeを徹底しましょう！
方法1: 各アカウントで個別設定
• シンプルで分かりやすい
• アカウントごとに調整可能
• StackSetsで一括デプロイ
方法2: 組織全体で一元管理
• AWS Organizations統合
• 管理アカウントで集中管理
• Aggregatorで全体を可視化
💡 大規模環境では方法2がおすすめ
🎓 まとめ
🏗️ 建物は設計図通りに保つべき
CloudFormation = 建物の設計図📐
ドリフト = 設計図と実際の建物の違い🏢
検査員（Config）
が問題を見つけて、
工事業者（SSM Automation）
が自動で直す！
これが最強の組み合わせです✨
AWS Config
24時間監視で
ドリフトを検出
EventBridge
問題発生を
即座に伝達
SSM Automation
設計図通りに
自動修復
🎯 導入のステップ：
1️⃣
Configルール
cloudformation-stack-drift-detection-check を有効化
2️⃣
EventBridge
で非準拠イベントをキャッチ
3️⃣
SSM Automation
AWS-UpdateCloudFormationStack を起動
4️⃣
IAMロール
に必要な権限を付与
5️⃣
SNS通知
でチームに共有
これで完全自動化の完成！🎉
💡 覚えておくべき最重要ポイント：
「
すべての変更はコード経由で
」
Infrastructure as Code を徹底すれば、
ドリフトは発生しません！
手動変更は
必ず検出・修復
されて、
設計図通りの安全な状態が維持されます🔒
自動化で、安心して眠れる夜を！😴✨