Build automated incident response - GuardDuty detects threats, EventBridge routes findings, Lambda isolates compromised resources and alerts Slack.
Master core concepts and production patterns.
A security alert with no automation is just noise. When GuardDuty detects an EC2 instance communicating with a known cryptocurrency-mining command-and-control server at 3am, nobody is awake to respond. By the time someone at a company like Hotstar sees the alert in the morning, the instance may have been compromised for hours during peak streaming traffic. This project builds an automated security response system. **GuardDuty** detects the threat. **EventBridge** routes the finding to a Lambda function within seconds. Lambda isolates the compromised instance by replacing its security groups with a deny-all group, revokes any compromised IAM credentials, and sends a formatted Slack alert — all without a human needing to be awake or online. [ EC2 instance shows suspicious behavior ] | v [ GuardDuty detects it - CryptoMining, UnusualTraffic, etc. ] | v [ GuardDuty publishes finding to EventBridge ] | v [ EventBridge rule matches HIGH/CRITICAL severity ] | v [ EventBridge invokes Lambda with finding details ] | v [ Lambda isolates instance, revokes creds, tags, alerts Slack ] | v [ Security team receives Slack alert with full context ] > 💡 **Tip:** The entire response — detection to isolation to Slack notification — completes in under 60 seconds, automatically, at any hour of the day, in any AWS region including `ap-south-1` (Mumbai).
Manual incident response has a fundamental timing problem: the gap between "a threat occurs" and "a human notices and reacts" can be hours, especially overnight or on weekends. During that gap, a compromised instance can exfiltrate data, mine cryptocurrency on your bill, or pivot to attack other resources in the account — a real risk for any company running production workloads around the clock, like Zerodha during market hours. This project closes that gap by making the first response step fully automated. GuardDuty continuously analyzes CloudTrail API activity, VPC Flow Logs, and DNS logs using machine learning and threat intelligence feeds, without you configuring any of the underlying detection logic. EventBridge routes qualifying findings instantly. Lambda performs the actual isolation — and critically, isolation is not termination. The standard incident response pattern is to cut a compromised instance off from the network while preserving its disk and memory for forensic analysis, not to destroy the evidence by shutting it down. > ⚠️ **Security:** Automated remediation buys time and limits blast radius — it does not replace a human security review. Every automated action here also produces a Slack alert and a set of tags, so a person can pick up the investigation with full context. ---
Master core concepts and production patterns.
Enabling GuardDuty is a single API call — there's no agent to install and no infrastructure to manage. Once enabled, it immediately starts analyzing your account's CloudTrail, VPC Flow Log, and DNS data in the background.
```bash aws guardduty create-detector \ --enable \ --finding-publishing-frequency FIFTEEN_MINUTES \ --region ap-south-1 \ --query 'DetectorId' \ --output text ``` ```text abc123def456abc123def456abc12345 ``` Save the Detector ID — you'll need it to generate test findings later. ```bash aws guardduty list-detectors --region ap-south-1 ``` ```json { "DetectorIds": ["abc123def456abc123def456abc12345"] } ``` > 💡 **Tip:** `FIFTEEN_MINUTES` is the finding publishing frequency, not the detection frequency — GuardDuty detects threats continuously. This setting only controls how often *updates* to an existing finding get republished to EventBridge. ---
Master this concept and view production exercises.
A security alert with no automation is just noise. When GuardDuty detects an EC2 instance communicating with a known cry...
Manual incident response has a fundamental timing problem: the gap between "a threat occurs" and "a human notices and re...
Master this concept and view production exercises.
Enabling GuardDuty is a single API call — there's no agent to install and no infrastructure to manage. Once enabled, it ...
Save the Detector ID — you'll need it to generate test findings later. > 💡 Tip: FIFTEENMINUTES is the finding publishin...
Master this concept and view production exercises.
The isolation strategy for this project relies on one specific security group: a group with zero inbound rules and zero ...
Confirm there are no inbound rules: New security groups have a default "allow all" outbound rule — remove it explicitly:...
Master this concept and view production exercises.
This function does three things when invoked: it isolates the affected resource (EC2 instance or IAM user), it tags the ...
> 🔴 Common Mistake: Deleting compromised access keys instead of deactivating them. Deletion is irreversible and destroy...
Master this concept and view production exercises.
The Lambda needs just enough IAM permission to describe instances, modify their security groups, tag resources, and mana...
Attach the required permissions: > ⚠️ Security: These permissions use "Resource": "" for simplicity in this learning pro...
Master this concept and view production exercises.
IAM changes are eventually consistent — the role you just created may not be immediately visible to the Lambda service. ...
> 🔴 Common Mistake: Skipping the sleep 10 between creating the IAM role and creating the Lambda function often produces...
Master this concept and view production exercises.
The event pattern below is the actual filter deciding which findings reach your Lambda at all. Getting the severity comp...
> 🔴 Common Mistake: GuardDuty severity is a float from 0.1 to 10.0, not a string. {"numeric": [">=", 7.0]} correctly ca...
Master this concept and view production exercises.
Check your Slack channel — you should see the formatted security alert with finding details and the list of automated ac...
Mistake Why It Breaks Fix No sleep after IAM role creation "Role not found" error on Lambda create Add a short delay bef...
Aligns directly with DevOps, Site Reliability (SRE), and Platform Engineering job descriptions.