はじめに

こんにちは、ほうき星 @H0ukiStar です。

皆さんは昨年(2025年)の11月に CloudFormation がアップデートされ、ドリフト状態の修正に利用可能なドリフト認識変更セットが追加されたことをご存じでしょうか？

本機能の登場以前は、ドリフト修正を行うためには一度ダミーの変更を加えてスタック更新を実施し、その後元に戻す必要がありました。
しかし現在は、変更セット作成時に --deployment-mode REVERT_DRIFT を指定することで、IaC と実際のインフラストラクチャとの差分を認識し、ドリフト修復用の変更セットを作成できるようになりました。

本記事では CloudFormation スタックのドリフトをチェックし、このドリフト認識変更セットを用いて自動的にドリフトの修正を行う Configuration Healing の仕組みを Durable Functions で実装してみましたのでご紹介します。

ドリフト認識変更セットを試してみる

サンプルスタックの展開

まずはドリフト認識変更セットがどのように動作するのかを確認します。
以下の CloudFormation テンプレートをスタック名：test としてデプロイしました。

AWSTemplateFormatVersion: 2010-09-09
Description: Stack for testing drift-aware change sets

Resources:
 TestParameter:
 Type: AWS::SSM::Parameter
 Properties:
 Name: /drift-test/sample
 Type: String
 Value: initial-value
 Description: Parameter for drift testing

スタック展開直後は以下の通りドリフトは発生していません。

👁 スタック展開直後のドリフトステータス

ドリフトの発生

以下のコマンドで SSM パラメータの値を変更し、ドリフトを発生させます。

aws ssm put-parameter \
 --name /drift-test/sample \
 --value updated-value \
 --overwrite

CloudFormation のドリフト画面からもドリフトが発生していることを確認できます。

👁 SSM パラメータ変更後のドリフトステータス

ドリフト認識変更セットで修復してみる

CloudFormation のドリフト画面上にドリフト認識変更セットを使用して修正できる旨の案内が表示されているので「変更セットを作成」から実施します。

👁 変更セットの作成

変更セットのタイプがドリフト認識変更セットになっていることを確認し、画面の案内に従って変更セットを作成します。

👁 ドリフト認識変更セットの作成

作成された変更セットのリソースの変更内容を確認すると、ドリフトになっている部分を認識したうえでその修正が行われる内容になっています。

👁 変更セットの内容確認

変更セットの適用後、ドリフトが解消されていることが確認できます。

👁 変更セット適用後のドリフトステータス

Durable Functions を用いた Configuration Healing

CloudFormation のドリフト検出や変更セット作成は非同期処理であるため、完了までポーリングによる待機が必要になります。

これを通常の Lambda 関数だけで実装すると、待機制御やリトライ、状態管理が複雑になりがちです。

今回は Durable Functions を利用することで、これらの待機処理や状態遷移をシンプルに実装しました。

また、Durable Functions は長時間実行されるワークフローを前提としているため、CloudFormation のような非同期 API を扱うユースケースと非常に相性が良いです。
特に今回のような「開始 → 完了待機 → 状態確認 → 次処理」というオーケストレーションを伴う処理では、実装を見通し良く記述することができます。

フロー

実装にあたっては、以下の流れで CloudFormation スタックのドリフト検出から修復までを行います。

Durable Functions を利用することで、ドリフト検出や変更セット作成完了までの待機をシンプルに実装できます。

また Lambda 関数に与えるイベント中で CreateChangeSetOnly:true とすることで、変更セットの作成までに留めるようにしています。

Durable Functions での実装サンプル

Durable Functions は前述のフローに則って実装しています。

SAM テンプレートを含む全ソースは以下のリポジトリに置いています。合わせて参考にしてください。

動作確認

実際に test スタックで作成した SSM Parameter の値を変更してドリフトを発生させ、展開した Lambda 関数を実行してみます。

aws lambda invoke \
 --function-name arn:aws:lambda:<region>:<account-id>:function:cfn-drift-healing:Alias \
 --invocation-type Event \
 --cli-binary-format raw-in-base64-out \
 --payload '{"StackName": "test"}' \
 response.json

ログ等を確認すると、以下の流れで自動修復が実施されていることが分かります。

1. ドリフト検出開始
2. ドリフト状態を検知
3. ドリフト認識変更セットを作成
4. 変更セットを実行
5. ドリフト解消

👁 Lambda 関数実行ログ

👁 永続実行の実行結果

修復完了を SNS 通知によっても確認できます。

👁 SNS 通知内容

また、以下のように Durable Functions 実行時にイベントで CreateChangeSetOnly: true を渡すことで、変更セットの作成までに留め変更セットの実行は人に委ねることも可能です。

aws lambda invoke \
 --function-name arn:aws:lambda:<region>:<account-id>:function:cfn-drift-healing:Alias \
 --invocation-type Event \
 --cli-binary-format raw-in-base64-out \
 --payload '{"StackName": "test", "CreateChangeSetOnly": true}' \
 response.json

👁 変更セット作成までにとどめた場合の Lambda 関数実行ログ

👁 変更セット作成までにとどめた場合の SNS 通知内容

さいごに

CloudFormation の ドリフト認識変更セット により、これまで手間だったドリフト修復を安全かつ容易に実施できるようになりました。

本記事ではこのドリフト認識変更セットを用いて、自動的にドリフトの修正を行う Configuration Healing の仕組みを Durable Functions で実装しました。
IaC を利用していても、長期間運用される環境では意図しない変更によるドリフトは避けられません。
EventBridge Scheduler 等と組み合わせて定期的に実行することで、こういった意図しない変更や、「後で直そう」と思ったまま放置されていた変更に起因するドリフトを機械的に修正でき、IaC による構成管理を継続的に維持しやすくなります。

なお、本番環境等において強制的に自動修復を行うことに抵抗がある場合は、記事中でも触れたように変更セットの作成までに留め、人によるレビューを挟む運用にすると良いでしょう。

本記事の内容が、CloudFormation を利用した Configuration Healing の実装例として参考になれば幸いです。