Build Automated Security Incident Response with GuardDuty, EventBridge, and Lambda

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.

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.

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.

Save the Detector ID — you'll need it to generate test findings later.

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.

The isolation strategy for this project relies on one specific security group: a group with zero inbound rules and zero outbound rules. Attaching this to a compromised instance instantly blocks all network traffic in both directions, without touching the instance's disk or memory.

Confirm there are no inbound rules:

New security groups have a default "allow all" outbound rule — remove it explicitly:

Common Mistake

Forgetting to revoke the default outbound rule. A brand-new security group blocks all inbound traffic by default, but still allows all outbound traffic — a compromised instance could still exfiltrate data even after you think you've isolated it, unless you explicitly close the egress side too.

This function does three things when invoked: it isolates the affected resource (EC2 instance or IAM user), it tags the resource with what happened and why, and it sends a Slack alert. Note that IAM Access Key findings get access keys deactivated, not deleted — deactivation is reversible and preserves the audit trail, which matters if the finding turns out to be a false positive.

Common Mistake

Deleting compromised access keys instead of deactivating them. Deletion is irreversible and destroys evidence — if a finding turns out to be a false positive, or you need to trace exactly what the credential accessed, a deactivated key is far more useful than a deleted one.

The Lambda needs just enough IAM permission to describe instances, modify their security groups, tag resources, and manage IAM access keys — nothing more. This is the principle of least privilege applied to the responder itself, since the responder is now a high-value target in your account too.

Attach the required permissions:

Security

These permissions use "Resource": "*" for simplicity in this learning project. In a real environment, scope EC2 and IAM actions down to specific resource ARNs or tag-based conditions wherever the API supports it — a Lambda with unrestricted iam:UpdateAccessKey is itself a high-value target if compromised.

IAM changes are eventually consistent — the role you just created may not be immediately visible to the Lambda service. This is a common source of confusing, intermittent errors for anyone new to scripting AWS resource creation, so we account for it explicitly below.

Common Mistake

Skipping the sleep 10 between creating the IAM role and creating the Lambda function often produces a "role not found" error, since IAM changes are eventually consistent and the role may not be visible to the Lambda service the instant after create-role returns.

The event pattern below is the actual filter deciding which findings reach your Lambda at all. Getting the severity comparison right matters — GuardDuty severity is a number (0.1 to 10.0), not a category string, so the pattern has to use a numeric comparison operator, not a string match.

Common Mistake

GuardDuty severity is a float from 0.1 to 10.0, not a string. {"numeric": [">=", 7.0]} correctly catches both HIGH and CRITICAL findings; writing {"severity": ["HIGH"]} will never match anything, since severity is never sent as that literal string value.

Check your Slack channel — you should see the formatted security alert with finding details and the list of automated actions taken.

Tip

GuardDuty's sample findings use synthetic instance IDs that don't exist in your account, so the EC2 isolation step will log an error for those specific test runs — that's expected. To fully validate the isolation logic, launch a real disposable test EC2 instance and manually invoke the Lambda with a finding payload referencing that instance's ID.