CloudFormationの新機能「ドリフト認識変更セット」を利用したドリフト修復を試してみた

CloudFormationの変更セット新機能「REVERT_DRIFT」モードを検証。ドリフト認識変更セット(Drift-aware change sets)を作成し、テンプレートを修正することなくS3のドリフト状態を「あるべき姿」に復元できた手順を紹介します。

suzuki.ryo

2025.11.24

2025年11月18日の AWS CloudFormation アップデートにより、ドリフト状態の修復に利用できる「ドリフト認識変更セット」がサポートされました。
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/configuration-drift-enhanced-cloudformation-sets/
従来、CloudFormation でドリフト状態を修復するには、一度ダミーの変更を実施してから元に戻すといった操作が必要でした。
今回は、S3バケットのバージョニング設定を意図的に「ドリフト」させ、新機能の「ドリフト認識変更セット (Drift-aware change sets)」を利用して復元できるか検証してみましたので紹介します。
 ドリフト認識変更セットとは？変更セット（Change Set）作成時に、新しいパラメータ --deployment-mode REVERT_DRIFT を指定することで、ドリフト認識変更セットが作成できるようになりました。
標準変更セット(従来)は、新しいテンプレートを既存のテンプレートとの比較のみ実施しますが、

ドリフト認識変更セットでは、テンプレートの比較に加え、実機、デプロイ済みリソースを含めた確認を実施し、ドリフトを解消して元に戻す変更セットを作成可能になりました。
 検証シナリオ以下の流れで検証します。
初期構築: バージョニング「有効 (Enabled)」なS3バケットを作成。
ドリフト発生: AWS CLIで直接「停止 (Suspended)」に変更。
通常デプロイ（比較用）: そのまま変更セットを作成し、どうなるか確認。
新機能デプロイ: REVERT_DRIFT モードで変更セットを作成し、自動修正されるか確認。
 検証用テンプレートバージョニングを有効としたS3バケットを用意しました。
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  TestBucket:
    Type: AWS::S3::Bucket
    Properties:
      VersioningConfiguration:
        Status: Enabled
 検証実施 1. ドリフトの発生まず、スタックを作成し、その後、CLIで設定を変更してドリフト状態を作ります。
# 1. スタック作成（Enabled）
aws cloudformation deploy --template-file drift-aware-test.yaml ...

# 2. 手動で設定変更（Enabled -> Suspended）
aws s3api put-bucket-versioning --bucket $BUCKET_NAME --versioning-configuration Status=Suspended
現在の状態：
テンプレート: Enabled
実機: Suspended
 2. 通常の変更セットを作成してみるまずは従来通りの方法で、変更セットを作成してみました。テンプレートファイル自体は変更していません。
aws cloudformation create-change-set \
  --stack-name drift-aware-test-stack \
  --change-set-name standard-changeset \
  --template-body file://drift-aware-test.yaml
結果:
"Changes": []
予想通り、「変更なし」 と判定されました。これでは、ExecuteChangeSet しても何も起きず、ドリフトしたままです。
 3. 新機能「Drift-aware」で作成してみる次に、今回の新機能パラメータ --deployment-mode REVERT_DRIFT を付けて実行しました。
aws cloudformation create-change-set \
  --stack-name drift-aware-test-stack \
  --change-set-name drift-aware-changeset \
  --template-body file://drift-aware-test.yaml \
  --deployment-mode REVERT_DRIFT
結果:
"Changes": [
    {
        "Type": "Resource",
        "ResourceChange": {
            "Action": "Modify",
            "LogicalResourceId": "TestBucket",
            "ResourceDriftStatus": "MODIFIED",
            "Details": [
                {
                    "Target": {
                        "Name": "VersioningConfiguration",
                        "BeforeValue": "Suspended", 
                        "AfterValue": "Enabled"
                    },
                    "Drift": {
                        "ActualValue": "Suspended",
                        "PreviousValue": "Enabled"
                    }
                }
            ]
        }
    }
]
テンプレートの変更は実施していませんが、「実機の設定が Suspended になっているので、Enabled に戻します」 という変更セットが生成されました。

ResourceDriftStatus: MODIFIED と認識されているのが分かります。
 4. 実行して修正確認この変更セットを実行 (execute-change-set) した後、S3バケットの状態を確認しました。
aws s3api get-bucket-versioning --bucket $BUCKET_NAME
# Result:
{
    "Status": "Enabled"
}
無事、バージョニング設定が有効に戻り、あるべき姿に戻った事が確認できました。
 マネージドコンソールWebコンソールでも同様に、変更セットの作成を試してみました。
ドリフト認識変更セットを指定
レビュー画面でドリフト認識変更セットである事を確認して、変更セットを作成
作成されたドリフト認識変更セットで、修復対象が確認できる事
変更セットを実施して、ドリフト修復ができる事を確認できました。
 まとめ今回のアップデート、ドリフト認識変更セットにより、IaC管理外で行われた変更（ドリフト）への対応が劇的に楽になりました。
CI/CD パイプラインの「定期実行ジョブ」などでこのオプションを使用すれば、「常に正しい設定を維持する（Configuration Healing）」 仕組みも簡単に構築できそうです。
AWS Config Rules による自動修復（Remediation）を実装する場合、別途 Lambda や SSM ドキュメントの準備が必要でしたが、本機能なら「既存のテンプレート」があれば即座に復旧可能です。運用コストを抑えたドリフト対策の手段として、ぜひお試しください。