Building Incident Response Pipeline in AWS Without a Single LLM Call — The Big Rollback #7

Spend enough time around security tooling right now and you'll notice a pattern: "automation" and "AI" have started getting used almost interchangeably. Every vendor pitch, every LinkedIn post about "the future of SOC" leads with an LLM. Autonomous agents triaging alerts. Chat interfaces summarizing findings. Copilots drafting incident reports.

Some of that is genuinely useful; I spend real time on LLM red-teaming and adversarial ML myself, it's not a dismissal of the field. But somewhere along the way, "automation" quietly stopped meaning "a system that acts without a human in the loop" and started meaning "a system with a model in it." Those are not the same claim, and conflating them has a cost: it makes people reach for an LLM to solve problems that a well-designed state machine already solves better, deterministically, auditably, and for a fraction of the latency and cost.

So I built a small, deliberately boring counter-example.

Architecture

GuardDuty detects a compromised EC2 instance. EventBridge filters for anything serious enough to matter. A Lambda function isolates the instance by swapping its security group. SNS tells the admin what happened. Every step is provisioned with Terraform, and the whole thing is triggered by a real finding, not a simulation — I confirmed it end-to-end by making a live instance query a domain AWS reserves specifically for testing this exact detection path, and watched the automation isolate it in about 1.2 seconds.

Demo

For this demo, I deployed a target EC2 instance with a deliberately broad attack surface: SSH open to 0.0.0.0/0. This configuration exists only to reproduce a realistic attack surface for testing. It must never be used in production.

To trigger a genuine finding rather than a synthetic one, I connected to the instance and queried a domain AWS reserves specifically for testing GuardDuty's threat intelligence detection:

dig guarddutyc2activityb.com any

dig guarddutyc2activityb.com any

Within a few minutes, GuardDuty flagged the query as a match against a known Command & Control domain. It was a real, high-severity finding tied to the actual instance, not a placeholder.

That finding is exactly what the EventBridge rule was watching for. It matched on severity and finding type, and fanned out to both targets in parallel: the containment Lambda and the SNS notification topic.

The Lambda took it from there. No human involved, no model involved. It read the instance ID out of the finding, swapped its security group to one with zero inbound or outbound rules, and tagged the instance with the finding ID and timestamp for the audit trail. Total time from finding to isolation: about 1.2 seconds.

Final Notes

The focus of this post relies on one idea: AI is genuinely useful, but knowing which situations actually call for it matters more than reaching for it by default.

Right now, the push toward AI is making some tooling decisions more about the vibe than the real need. A closed, deterministic decision like "isolate this instance if severity crosses this threshold" doesn't get better with a model in the loop. It gets slower, harder to audit, and exposed to a new class of attack surface for no real gain. The skill worth building isn't using AI everywhere. It's recognizing the difference before you build.

Link to the repo: https://github.com/zdr4k/aws-ir-automation