⭐ Why I Built This Project

(Project 4 of 6 — Drift Detection with AWS Config)

Instead of studying cloud security concepts in isolation, I’m using real job descriptions as a roadmap and building hands-on projects that map directly to cloud security, cloud operations, and security engineering.

This 6-part series focuses on practical, resume-ready cloud security skills, including:

• Identity hardening and MFA enforcement
• IAM governance and access reviews
• Continuous monitoring of cloud resources
• Misconfiguration detection & drift analysis
• Log analysis, audit readiness, and evidence gathering
• Guard rails at scale using AWS Organizations + Service Control Policies (SCPs)
• Threat detection, anomaly monitoring, and incident triage

Each project is designed to reflect real-world responsibilities, not just theoretical learning.

📌 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 approach protection 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.

Drift detection is critical because:

• 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 is a fun, friendly, technical guide designed for absolute beginners including troubleshooting from a real-world lab run.

📘 Table of Contents

1. Introduction
2. What Is Drift Detection?
3. Architecture Overview
4. Prerequisites & Cost Notes
5. Step 1 — Create a Config Logs Bucket
6. Step 2 — Enable AWS Config (S3-Only Setup)
7. Step 3 — Create the Drift-Test S3 Bucket
8. Step 4 — Add the AWS Config Rule
9. Step 5 — Create SNS Topic for Alerts
10. Step 6 — Create EventBridge Rule
11. Step 7 — Introduce Drift
12. Step 8 — Verify Detection & Alerts
13. Troubleshooting & Gotchas
14. Cleanup
15. 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:

• You want your S3 bucket private
• Someone makes it public
• Drift detected! 🔔

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

🏗️ Architecture Overview

High-level flow:

1. You create a private S3 bucket
2. AWS Config evaluates it using a managed rule
3. You introduce drift (make it public)
4. Config marks it 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 this project low cost:

• Use one region
• Track only S3 resources
• Use a single rule
• Delete everything at the end (cleanup section included)

🪣 Step 1 — Create a Config Logs Bucket

1. Go to S3 → Create Bucket
2. Name it something like:

config-logs-lab-<yourinitials>-123

1. Enable Block Public Access
2. Leave default encryption on
3. 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
  1. Set the delivery S3 bucket to the one you created
  2. Skip SNS notifications (we’ll create our own later)

🪣 Step 3 — Create the Drift-Test S3 Bucket

Name example:

drift-demo-bucket-<yourinitials>-123

1. Create the bucket
2. Keep Block Public Access = ON
3. Add tag:

Key: Project
Value: ConfigDriftLab

This tag lets us scope the Config rule later.

🧩 Step 4 — Add the AWS Config 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.

Set Scope to:

• 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. Create
4. Add a subscription:
   • Protocol: Email
   • Endpoint: your email address
5. Confirm the email in your inbox

🔔 Step 6 — Create EventBridge Rule

This rule listens for AWS Config compliance changes.

Use this event pattern:

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

Set the Target = 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)

To simulate drift:

1. Disable Block Public Access
2. Add a public bucket policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicRead",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::drift-demo-bucket-<yourinitials>-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

SNS Email →

Check inbox and spam folder (real story from this lab 😅)

🧰 Troubleshooting & Gotchas (Real Lab Issues)

This section includes both a narrative + clean reference list, based on actual problems encountered while building this project.

🧵 Narrative: What Actually Broke & How I Fixed It

1. SNS Never Delivered the Alert

Turns out the SNS topic had the default policy, which does NOT allow EventBridge to publish messages.

Fix:

I added this 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:<account-id>:drift-alerts-test-topic",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:events:us-east-1:<account-id>:rule/aws-config-drift-to-sns"
    }
  }
}

2. The First Alert Went to Spam

SNS emails come from:

no-reply@sns.amazonaws.com

I marked it as Not Spam so future alerts land correctly.

3. Config Rule Name Mismatch

AWS updated the naming of S3 Config rules.

The correct one is:

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

📋 Clean Troubleshooting Checklist

🧹 Cleanup (Avoid Costs!)

Delete in this order:

1. Drift S3 bucket
2. AWS Config rule
3. Stop Configuration Recorder
4. Delete delivery channel
5. Delete Config logs bucket
6. Delete EventBridge rule
7. Delete SNS topic & subscription
8. Delete IAM roles used for remediation (if any)

This ensures AWS Config stops billing you.

🎉 Final Thoughts

You just built:

• Drift detection
• Automated alerting
• AWS Config recording pipeline
• Real debugging scenarios

This is a perfect beginner‑friendly cloud security project to show on a resume or portfolio.🚀

🤝 Connect

If you enjoyed this article or you’re also learning DevOps, Linux, Security, or Cloud automation, I’d love to connect, share ideas, and learn.

💬 Feel free to reach out or follow my journey on 👉 LinkedIn