CloudFormation Drift Detection：構成管理の「聖域」を侵すノイズを排除する自動化の深淵
IaC（Infrastructure as Code）を導入した組織において、最も醜悪な敵は「手動変更」である。
「少しだけ設定を変えてテストしたい」「緊急対応でコンソールからタグをいじった」。その場しのぎの善意が、コードと実環境の乖離――すなわちドリフト（Drift）を生む。ドリフトはシステムを非決定論的なブラックボックスへと変貌させ、次回のデプロイ時に予期せぬ破壊を引き起こすトリガーとなる。
本稿では、CloudFormationのドリフト検出機能を単なる「確認作業」から「自律的な守護システム」へと昇華させるための、現場で血を流してきた者だけが知るアーキテクチャを解説する。
—
1. ドリフトの本質と「コスト」の正体
ドリフト検出は、API `DetectStackDrift` を呼び出し、現在のリソース状態とテンプレートを比較する。だが、これを手動で行うのはエンジニアの怠慢だ。
大規模環境において、数千のスタックに対して全量検出を行うと、APIレート制限（Throttling）に抵触し、さらにCloudTrailのログがノイズで溢れかえる。「検知すること」自体がインフラの負荷になるというジレンマを、我々は設計で解決しなければならない。
—
2. アーキテクチャ：EventBridgeをトリガーとした「自律的監視ループ」
単に定期実行するのではなく、変更イベントに追従するイベント駆動型アーキテクチャを構築する。
構成要素
1. EventBridge Rule: `aws.cloudformation` イベントを監視し、`UpdateStack` や `CreateStack` 完了後にドリフト検出をキックする。
2. Step Functions: 検出処理の非同期実行と、結果のパース、および「自動修復が必要な差分か」の判定ロジックを担う。
3. Lambda: テンプレートと実環境の差分（`StackResourceDrift`）を分析し、Slack/ChatOpsへの通知、または自動ロールバックを決定する。
—
3. 実装の核心：自動化スクリプトによる「強制同期」
以下は、ドリフトを検知した際に、特定のプロパティを除外して報告するPython（Boto3）のロジックの断片である。
import boto3
cfn = boto3.client(‘cloudformation’)
def detect_and_report(stack_name):
# ドリフト検出の開始
detection = cfn.detect_stack_drift(StackName=stack_name)
drift_id = detection[‘StackDriftDetectionId’]
# 完了を待機（ポーリングの最適化：指数バックオフの実装を推奨）
waiter = cfn.get_waiter(‘stack_drift_detection_complete’)
waiter.wait(StackDriftDetectionId=drift_id)
# 結果の取得
drifts = cfn.describe_stack_resource_drifts(StackDriftDetectionId=drift_id)
for drift in drifts[‘StackResourceDrifts’]:
if drift[‘StackResourceDriftStatus’] == ‘DRIFTED’:
# ここで「無視リスト（IgnoreList）」を照合し、
# 意図的なドリフトか、悪意ある変更かを判別する
if is_malicious(drift):
trigger_auto_remediation(stack_name)
def trigger_auto_remediation(stack_name):
# 最終奥義：ドリフト発生スタックの強制アップデート
# 実際には変更セットを作成し、変更内容をプレビューしてから適用する
print(f”Alert: Drift detected in {stack_name}. Initiating auto-remediation…”)
—
4. 現場で震えるための「最適化ハック」
① 「無視リスト」によるノイズキャンセリング
AWS Auto Scalingによる動的プロパティ変更や、タグの自動付与など、システム上不可避なドリフトは存在する。これらをドリフトとして検知し続けると、SREはアラート疲れで麻痺する。Lambda側で `PropertyDifferences` を正規表現でフィルタリングし、実質的な「意図しない変更」のみを抽出するゲートウェイを必ず実装せよ。
② メモリ消費とAPI実行コストの抑制
大規模なNested Stack環境で `detect_stack_drift` を叩くと、メモリ消費が急増し、Lambdaのタイムアウトが頻発する。
- 解決策: スタックを階層化し、ルートスタックから再帰的に呼び出すのではなく、変更のあったスタックセット単位で細分化して並列処理せよ。`boto3` の `paginate` を活用し、メモリ空間を汚染しないストリーミング処理を徹底すること。
③ CloudFormation DriftとAWS Configの使い分け
- CloudFormation Drift: 「テンプレートとの不一致」を確認するのに特化。
- AWS Config: 「コンプライアンス（例：S3は暗号化されているか）」を確認するのに特化。
両者を統合せよ。 Configのルール違反を検知した際、直ちにCloudFormationのドリフトチェックを走らせることで、「何が設定違反を生んだのか（手動変更か、テンプレートの不備か）」という根本原因を数秒で特定できる。
—
5. 伝説のアーキテクトからの助言
ドリフト検出を導入する目的は「完璧な環境を維持すること」ではない。「環境が壊れたときに、即座にそれを認識し、コードを正とする状態へ戻すための信頼」を醸成することにある。
もし君がこの自動化を導入するなら、最初は「検知のみ」から始めろ。次に「Slack通知」。最後に、信頼できるパイプラインが構築できた段階で初めて「自動修復（`UpdateStack`の自動再実行）」を解放せよ。
インフラをコードで記述するということは、単にYAMLを書くことではない。「いかなる状況下でも、コードが真実（Single Source of Truth）である」という規律を、システム全体に強制することなのだ。
さあ、コンソールにログインして手動で設定を変更する時代は終わった。自動化された正義を、君のインフラに実装せよ。