Introduction
Hi, I'm miruky.
An AWS CloudFormation template can say that S3 Versioning is enabled while the live bucket says something else. Drift detection compares the expected properties declared in the template with the resource's current properties, which makes that disagreement visible without changing the stack.
This Console-only run creates one empty S3 bucket in us-east-1, establishes an IN_SYNC baseline, and suspends versioning directly in Amazon S3. The observed sequence is stack drift (DRIFTED), one changed bucket (MODIFIED), and a versioning difference between the declared and live values. Re-enabling versioning returns the stack to IN_SYNC.
There is no additional CloudFormation charge for AWS resource providers in the AWS::* namespace. The procedure still makes S3 requests, and uploading the local template stores a small object in an S3 bucket in your account, so review the current CloudFormation pricing and Amazon S3 pricing pages before starting. The demonstration bucket remains empty throughout this exercise.
Use a sandbox identity with permission to create and inspect CloudFormation stacks and to read and change S3 bucket versioning. Do not use the root user.
1. Prepare the template
Save the following file locally as template.yaml. The bucket name must be globally unique. If the example name is already taken, replace it with a newly generated unique name before uploading the file.
AWSTemplateFormatVersion: '2010-09-09'
Description: Creates one empty S3 bucket for CloudFormation drift validation.
Resources:
ValidationBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: miruky-linijjzllplbihfg
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: AES256
OwnershipControls:
Rules:
- ObjectOwnership: BucketOwnerEnforced
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
# Declare the compared value instead of relying on an implicit default.
VersioningConfiguration:
Status: Enabled
This exercise changes the versioning configuration declared by the template. CloudFormation compares explicitly declared properties during drift detection, so the template value Enabled supplies an exact expected value. The template also enables server-side encryption, disables ACL ownership, and blocks all four forms of public access.
2. Create the stack
Start in CloudFormation in us-east-1 and use that Region for the complete procedure.
The header shows United States (N. Virginia) while the breadcrumb identifies CloudFormation's stack-creation flow. That Region corresponds to us-east-1.
The next page needs the local YAML file.
The local file field contains template.yaml. Continue after the file is accepted; CloudFormation copies a local upload to an S3 bucket in the account before proceeding.
Give the stack a unique name so you can identify it during the drift checks.
The Stack name field contains miruky-mligtoaradgmldqo. This template has no input parameters, so continue to the stack options page without adding IAM capabilities or changing the bucket configuration.
The review page is the last chance to confirm the Region, stack name, and one-resource template before provisioning begins. Read the displayed values rather than relying on a previous browser tab.
The review page shows Submit for the configured stack. Choose it once, then wait until the stack operation finishes before opening the resource list.
CloudFormation creates the bucket and records its logical and physical identifiers. The resource view is more useful than the success notification because it proves which AWS resource belongs to this stack.
The resource row shows status CREATE_COMPLETE, logical ID ValidationBucket, physical ID miruky-linijjzllplbihfg, and type AWS::S3::Bucket. These identifiers establish that the later S3 edit targets the bucket declared by this template.
3. Establish the baseline
Run a drift check before changing the bucket. A baseline distinguishes a newly introduced difference from a stack that was already out of sync.
The completed result reports IN_SYNC for both the stack and ValidationBucket. This fresh comparison differs from the initial NOT_CHECKED result and establishes that the live bucket matches the template.
4. Suspend S3 Versioning
Move to the bucket created by the stack in Amazon S3 and inspect its current versioning configuration before editing it.
The Bucket Versioning panel shows Enabled and exposes Edit. The operation changes only that setting; no object upload or bucket-policy change is needed for the drift example.
The edit view offers the two versioning states and requires a separate acknowledgment for suspension. The Console rejects the change if the acknowledgment is unchecked.
The form shows Suspend, I acknowledge the outcomes of suspending Bucket Versioning., and Save changes. For the failure check, select the suspension option, leave its acknowledgment unchecked, and submit the form.
The failed save does not change the bucket. Its message identifies the missing confirmation, so recovery only requires completing the existing form.
The message reads You must select the check box to suspend Bucket Versioning., while the acknowledgment remains unchecked. Select the required acknowledgment and submit the form again.
Return to the properties view after the successful save. The status panel, rather than the dismissed notification, proves the resulting bucket state.
Bucket Versioning now shows Suspended. The stack template still declares Enabled, so the live resource and expected configuration now disagree on one explicit property.
5. Inspect the drift
Return to the controlled CloudFormation stack and start a new drift operation. Reusing an earlier result would hide whether the S3 change was actually evaluated.
The Drifts page exposes Detect stack drift. Start a fresh detection and wait for the completed drift page before reading the result.
The resource list connects the overall stack result to the exact bucket that changed. It should contain only the generated name used by this exercise.
The Drift status is DRIFTED, and the ValidationBucket row shows MODIFIED, physical ID miruky-linijjzllplbihfg, and type AWS::S3::Bucket. The complete row rules out an unrelated resource as the source of the result.
Select the modified resource and open its detailed comparison. The property table is the evidence that narrows the result from a changed bucket to the exact setting.
The Differences table reports property VersioningConfiguration.Status, change NOT_EQUAL, expected value Enabled, and current value Suspended. CloudFormation has identified the direct Console edit at property level without modifying the bucket.
6. Restore the declared state
Return to the bucket's versioning editor and restore the value declared in the template. This changes the resource itself; it does not revise CloudFormation's expected state.
The selected recovery state is Enable. Submit the change. The S3 documentation notes that transitions from suspended to enabled can take time to propagate, so wait for the properties view to show the enabled state before running the final comparison.
Start one more drift operation after the restored state is visible. The last result must come from the new operation rather than the original baseline.
The new result reports IN_SYNC for the stack and ValidationBucket. The expected and current versioning states match again.
Wrap-up
The direct S3 change moved bucket versioning from Enabled to Suspended. CloudFormation exposed the difference as stack DRIFTED, resource MODIFIED, and property change NOT_EQUAL; restoring the declared state returned a fresh check to IN_SYNC.
Drift detection reports divergence but does not repair it. When an out-of-band change is intentional, decide whether the template should adopt it; when it is accidental, restore the declared configuration and run another check.
Thanks for reading this far.
See you in the next one.
Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.
Top comments (0)