インフラストラクチャドリフト

インフラストラクチャドリフトとは

インフラストラクチャドリフト (Infrastructure Drift) は、IaC (CloudFormation, Terraform) で定義した状態と、実際のインフラの状態が乖離する問題である。手動変更 (コンソール操作) が主な原因である。

なぜ発生するか

なぜ発生するかを図で示す。

1. CloudFormation でセキュリティグループを作成 (ポート 443 のみ許可)
2. 障害対応で手動でポート 22 を追加 (コンソールから)
3. CloudFormation のテンプレートにはポート 22 がない
→ テンプレートと実態が乖離 (ドリフト)

原因	例
手動変更	コンソールから設定を変更
緊急対応	障害時に手動でリソースを変更
別ツールでの変更	Terraform と CloudFormation の併用
外部サービスの変更	AWS が自動的に設定を変更

ドリフトの検出

CloudFormation

検出の起動と結果の取得が分かれており、2 段構えで呼び出す。

# 検出を開始 (StackDriftDetectionId が返る)
aws cloudformation detect-stack-drift --stack-name my-stack

# 進行状況と全体の判定を確認
aws cloudformation describe-stack-drift-detection-status \
  --stack-drift-detection-id <StackDriftDetectionId>

# リソース単位の差分を見る
aws cloudformation describe-stack-resource-drifts --stack-name my-stack

検出範囲には制約があり、ここを知らないと「IN_SYNC だから大丈夫」を誤読する。ドリフト検出に対応していないリソース種別は判定されず NOT_CHECKED になり、対応リソースを 1 つも含まないスタックは中身を見ないまま IN_SYNC と表示される。判定対象もテンプレートやパラメータで明示的に指定したプロパティに限られ、既定値に任せたプロパティは追跡されない。既定値と同じ値でもあえてテンプレートに書くのは、この検出漏れを避けるためだ。親スタックに対する検出は入れ子スタックの中を見ないので、入れ子側は個別に起動する。

Terraform

# 現在の状態と定義の差分を表示
terraform plan
# → 手動変更があれば差分として表示される

# 状態を実物へ合わせる目的だけの計画を作る
terraform plan -refresh-only

plan は既定で状態ファイルを実物と同期させるため、外部で変更されたオブジェクトは差分として現れる。-refresh-only を付けた場合は構成へ寄せる変更を提案せず、状態と出力値を実物に合わせることだけを目的とした計画になる。障害対応で意図的に手を入れた後、記録を追いつかせたいときがこの用途だ。逆に -refresh=false を指定すると既定の同期が止まり、ドリフトは見えなくなる。

ドリフトの修正

手動変更をテンプレートに反映してデプロイする方法、手動作成したリソースを IaC にインポートする方法、テンプレートの状態に戻して手動変更を元に戻す方法がある。

ドリフトの予防

IAM で手動変更を制限してコンソール操作を禁止し、CI/CD でのみデプロイする。EventBridge + Lambda で定期的にドリフトを自動検出し、AWS Config でリソースの設定変更を監視する。

イミュータブルインフラとの関係

イミュータブルインフラストラクチャでは稼働中のサーバーに手を入れず、新しいイメージから作り直して差し替える。そのため OS 設定やインストール済みパッケージのように「サーバーの中身」が少しずつずれていく型のドリフトは起きない。消えるのはこの型だけで、ロードバランサーの設定やセキュリティグループの規則といったリソース定義側の手動変更は、イミュータブルな構成でも同じように乖離する。

サーバーレス構成も同じ整理になる。Lambda + DynamoDB にはログインして設定を書き換えるサーバーが無いが、関数のメモリ量・タイムアウト・環境変数・同時実行数や DynamoDB のキャパシティ設定はコンソールから変更できる。障害対応でメモリを上げたまま戻し忘れる類のドリフトは普通に起きるため、検出と予防はサーバーレスでも必要だ。

基礎から学ぶなら関連書籍が手がかりになる。