🛡️ AWS Config Drift Detection Lab - Beginner-Friendly Guide

Source: Dev.to

📌 Project Sequence

• 👉 Part 1: AWS IAM Hardening — strengthening identity boundaries and improving authentication hygiene
• 👉 Part 2: Cloud Security Posture Management (CSPM) using Security Hub + AWS Config
• 👉 Part 3: CASB‑like monitoring with GuardDuty + CloudTrail, focusing on anomalies, delegated admin, and safe threat simulation
• 👉 Part 4: (this project) — Drift Detection with AWS Config, using managed Config rules, scoped evaluations, EventBridge routing, SNS notifications, and optional auto‑remediation to detect when cloud resources deviate from approved security baselines

🔐 Why This Progression Matters

Modern cloud‑security teams protect workloads in layers:

Identity first → Posture second → Threat detection → Drift governance

After establishing IAM hygiene (Project 1), posture baselines (Project 2), and threat‑intel/anomaly detection (Project 3), the next natural step is detecting when cloud resources drift away from their intended configuration.

Why drift detection is critical

• Many breaches originate from accidental misconfigurations
• Public S3 buckets remain a top cloud‑security incident
• Compliance frameworks require continuous configuration monitoring
• Security teams rely on automated alerts, not manual checks

This project simulates a realistic workflow used by cloud‑security analysts, compliance engineers, and platform‑security teams by combining:

• AWS Config managed rules
• Scoped evaluations (tags, resource types)
• EventBridge event‑pattern filtering
• SNS notification routing
• Optional SSM auto‑remediation actions
• Cost‑safe cleanup practices

You’ll intentionally make an S3 bucket public, watch AWS detect the drift, trigger an automated alert, and optionally repair the issue automatically… a true end‑to‑end cloud‑security workflow.

A hands‑on walkthrough using AWS Config, EventBridge, and SNS to detect when an S3 bucket becomes public (a classic example of security drift). This guide is friendly for absolute beginners and includes troubleshooting from a real‑world lab run.

📘 Table of Contents

• Introduction
• What Is Drift Detection?
• Architecture Overview
• Prerequisites & Cost Notes
• Step 1 — Create a Config Logs Bucket
• Step 2 — Enable AWS Config (S3‑Only Setup)
• Step 3 — Create the Drift‑Test S3 Bucket
• Step 4 — Add the AWS Config Rule
• Step 5 — Create SNS Topic for Alerts
• Step 6 — Create EventBridge Rule
• Step 7 — Introduce Drift
• Step 8 — Verify Detection & Alerts
• Troubleshooting & Gotchas
• Cleanup
• Final Thoughts

🔰 Introduction

Cloud environments change fast—sometimes too fast, and not always intentionally.

This lab shows you how to detect unwanted changes (drift) using:

• AWS Config → Detects drift
• Amazon EventBridge → Routes drift events
• Amazon SNS → Sends email alerts

You’ll break an S3 bucket on purpose and watch AWS alert you. You’ll also see real‑world troubleshooting issues I hit along the way and how to fix them.

🌪️ What Is Drift Detection?

Security drift happens when a resource moves away from your intended configuration.

Example

This lab focuses on detecting when an S3 bucket becomes publicly accessible.

🏗️ Architecture Overview

High‑level flow

1. Create a private S3 bucket.
2. AWS Config evaluates it using a managed rule.
3. Introduce drift (make the bucket public).
4. Config marks the resource NON_COMPLIANT.
5. EventBridge catches the change.
6. SNS sends you an email alert.

🛠️ Prerequisites & Cost Notes

You Need

• An AWS account

• Basic IAM permissions:

  AWSConfigFullAccess
  S3FullAccess
  EventBridgeFullAccess
  SNSFullAccess

Cost Notes

• AWS Config is not fully free‑tier.

• To keep costs low:

  • Use one region only.
  • Track only S3 resources.
  • Deploy a single rule.

• Delete everything at the end (see the Cleanup section).

🪣 Step 1 — Create a Config Logs Bucket

1. Open S3 → Create bucket.

2. Name it something like:

   config-logs-lab--123

3. Enable Block Public Access.

4. Leave default encryption on.

5. Click Create bucket.

📝 Step 2 — Enable AWS Config (S3‑Only)

1. Open AWS Config → Set up.

2. Choose Record specific resource types.

3. Select:

   • AWS::S3::Bucket
   • (Optional but recommended) AWS::S3::AccountPublicAccessBlock

4. Set the delivery S3 bucket to the one you created in Step 1.

5. Skip SNS notifications for now (we’ll create our own later).

🪣 Step 3 — Create the Drift‑Test S3 Bucket

1. Name example:

   drift-demo-bucket--123

2. Create the bucket with Block Public Access = ON.

3. Add a tag to scope the Config rule later:

   Key:   Project
   Value: ConfigDriftLab

🧩 Step 4 — Add the AWS Config Rule

1. In the AWS Config console, go to Rules → Add rule.

2. Choose the managed rule s3-bucket-public-read-prohibited (or a similar rule that checks bucket ACLs).

3. Set Scope of changes to Resources with specific tags and enter:

   Key:   Project
   Value: ConfigDriftLab

4. Save the rule. AWS Config will now evaluate any bucket with that tag.

📢 Step 5 — Create SNS Topic for Alerts

1. Open Amazon SNS → Topics → Create topic.

2. Choose Standard and name it, e.g., config-drift-alerts.

3. After creation, click Create subscription:

   • Protocol: Email
   • Endpoint: your email address

4. Confirm the subscription from the email you receive.

🔔 Step 6 — Create EventBridge Rule

1. Open Amazon EventBridge → Rules → Create rule.

2. Name the rule, e.g., ConfigDriftToSNS.

3. Define the event pattern to capture Config compliance‑change events for the specific rule:

   {
     "source": ["aws.config"],
     "detail-type": ["Config Rules Compliance Change"],
     "detail": {
       "configRuleName": ["s3-bucket-public-read-prohibited"],
       "newEvaluationResult": {
         "complianceType": ["NON_COMPLIANT"]
       }
     }
   }

4. Set the target to the SNS topic created in Step 5.

5. Save the rule.

🚀 Step 7 — Introduce Drift

1. Navigate to the drift‑test bucket created in Step 3.
2. Disable Block Public Access (or add a public read ACL).
3. Verify the bucket is now publicly readable (e.g., via the bucket URL).

AWS Config will evaluate the bucket, mark it NON_COMPLIANT, EventBridge will fire, and SNS will send you an email.

✅ Step 8 — Verify Detection & Alerts

• Check AWS Config → Compliance tab for the rule; the bucket should show NON_COMPLIANT.
• Check EventBridge → Metrics to see the rule triggered.
• Check your email for the SNS alert.

If you enabled optional SSM remediation, you could also have the bucket automatically re‑locked.

🐞 Troubleshooting & Gotchas

🧹 Cleanup

1. Delete the public bucket (or re‑apply Block Public Access).
2. Delete the Config logs bucket.
3. Remove the AWS Config rule.
4. Delete the EventBridge rule.
5. Delete the SNS topic and its subscription.
6. (Optional) Disable the AWS Config recorder if you no longer need it.

Cleaning up ensures you won’t incur ongoing charges.

🏁 Final Thoughts

Drift detection bridges the gap between static compliance and dynamic security. By automating the detection of unintended changes, you reduce manual audit effort, speed up incident response, and stay aligned with compliance frameworks.

Feel free to extend this lab:

• Add SSM Automation for auto‑remediation.
• Scope additional resources (e.g., IAM roles, RDS instances).
• Integrate with AWS Security Hub for centralized findings.

Happy hunting! 🚀

Rule

Search for the managed rule:

• ✅ s3-bucket-level-public-access-prohibited – This is the new bucket‑level drift rule that detects whether bucket policies or ACLs make the bucket public.

Scope → Resources with specific tags

• Key: Project
• Value: ConfigDriftLab

📣 Step 5 — Create SNS Topic for Alerts

1. Go to SNS → Topics → Create Topic.
2. Name: drift-alerts-test-topic
3. Click Create.

Add a subscription

• Protocol: Email
• Endpoint: your email address

Confirm the subscription from the email you receive.

🔔 Step 6 — Create EventBridge Rule

This rule listens for AWS Config compliance changes.

Event pattern

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["s3-bucket-level-public-access-prohibited"],
    "newEvaluationResult": {
      "complianceType": ["NON_COMPLIANT"]
    }
  }
}

• Target: the SNS topic you just created.
• If needed, re‑add the target so EventBridge automatically updates the SNS policy.

💥 Step 7 — Introduce Drift (Make the Bucket Public)

1. Disable Block Public Access on the bucket.
2. Add a public bucket policy (replace “ with your own letters):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicRead",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::drift-demo-bucket--123/*"
    }
  ]
}

AWS Config will soon detect this change.

📨 Step 8 — Verify Drift Detection & Alerts

You should see:

• AWS Config → Rule Status: NON_COMPLIANT 🔴
• EventBridge → Monitoring: Invocations > 0 (or more, once triggered)
• SNS Email: Check your inbox and spam folder (real story from this lab 😅)

🧰 Troubleshooting & Gotchas (Real Lab Issues)

🧵 Narrative: What Actually Broke & How I Fixed It

1. SNS never delivered the alert
   The default SNS policy does not allow EventBridge to publish.
   Fix: Add the following statement to the SNS access policy:

   {
     "Sid": "Allow_EventBridge_Publish",
     "Effect": "Allow",
     "Principal": {
       "Service": "events.amazonaws.com"
     },
     "Action": "SNS:Publish",
     "Resource": "arn:aws:sns:us-east-1::drift-alerts-test-topic",
     "Condition": {
       "ArnEquals": {
         "aws:SourceArn": "arn:aws:events:us-east-1::rule/aws-config-drift-to-sns"
       }
     }
   }

2. The first alert went to spam
   SNS emails come from no-reply@sns.amazonaws.com. Mark the message as Not Spam so future alerts land in the inbox.

3. Config rule name mismatch
   AWS renamed the S3 Config rule. The correct name is:

   ✔ s3-bucket-level-public-access-prohibited

📋 Clean Troubleshooting Checklist

🧹 Cleanup (Avoid Costs)

1. Delete the drift‑test bucket or re‑apply Block Public Access.
2. Delete the Config logs bucket.
3. Remove the AWS Config rule (s3-bucket-level-public-access-prohibited).
4. Delete the EventBridge rule (ConfigDriftToSNS).
5. Delete the SNS topic and its subscription.
6. Disable the AWS Config recorder if no longer needed.