Why I Built This

In real-world cloud environments, security is not about theory — it’s about proof.

During my learning and hands-on practice in AWS security, one thing became very clear:

If a compromised EC2 instance is not isolated immediately, it can lead to lateral movement, data leakage, or even full infrastructure compromise.

So instead of just understanding concepts, I built a production-style automated response system that:

• Detects suspicious activity

• Responds instantly

• Isolates the EC2 instance

• Preserves evidence

This blog is a breakdown of that system.

Problem Statement

Imagine this scenario:

• A developer unknowingly installs crypto-mining software

• The EC2 instance starts communicating with suspicious external IPs

• There is no immediate action

What happens next?

• Attack spreads

• Resources are abused

• No audit evidence

This is exactly what I wanted to solve.

What I Built

I designed an event-driven security automation system using:

• Amazon GuardDuty — Threat detection

• Amazon EventBridge — Event routing

• AWS Lambda — Automated response

• Quarantine Security Group — Isolation

• EBS Snapshots — Forensics

High-Level Workflow

• GuardDuty detects suspicious activity

• EventBridge captures the finding (severity ≥ 7)

• Lambda function is triggered

• EC2 instance is quarantined automatically

How the Detection Actually Works

One important thing I learned:

GuardDuty does NOT monitor installations — it monitors behavior.

So detection happens when:

• EC2 communicates with known crypto mining pools

• Suspicious DNS requests are observed

• Abnormal traffic patterns are detected

Once detected:

• Amazon GuardDuty generates a finding

• That finding is automatically sent to Amazon EventBridge

Automated Response (Core Logic)

Once the event reaches Lambda, the system performs:

1. Identify Compromised Instance Extract EC2 Instance ID from GuardDuty finding

2. Isolate the Instance Remove existing security groups Attach Quarantine Security Group (no inbound/outbound rules)

3. Preserve Evidence Create EBS snapshots

4. Block Further Access Attach Deny-All IAM policy

Quarantine Strategy

Instead of terminating the instance:

• I isolate it

Why?

• Keeps forensic data intact

• Allows investigation

• Prevents attacker movement

This is how real SOC teams operate.

Testing Approach

Since real attacks are not practical:

• Used GuardDuty sample findings

• Simulated events via test JSON

Then verified:

• EC2 lost all network access

• Snapshots were created

• IAM restrictions applied

What This Solves

• Instant containment of compromised EC2

• Prevents lateral movement

• Provides audit-ready evidence

• Removes manual intervention

• Demonstrates real DevSecOps capability

Production Notes

• This automation can be used in production

• Always test in non-prod first

• Clean up all resources after testing

• Disable GuardDuty if not required to avoid costs

Final Thoughts

This is not a demo project.

This is the same pattern used by cloud security and SOC teams in real production environments

My Resources

GitHub:
https://github.com/chandukh2006

LinkedIn:

https://www.linkedin.com/in/chandukh

Medium:

https://medium.com/@khchandu291