Triggering Lambda for Auto-Remediation

AWS Lambda runs your code without managing servers, charging only for execution time. In security automation, it is the most flexible remediation target.

When EventBridge matches a finding, it invokes a Lambda function that performs the fix — isolating an instance, revoking a key, or closing a bucket — in seconds.

The pattern is consistent: a detector emits a finding, an EventBridge rule matches it, and the rule invokes a Lambda function passing the event as input.

The function reads the event detail, identifies the affected resource, and calls AWS APIs to remediate. Detection becomes correction with no human in the loop.

EventBridge delivers the full event JSON to the function. The code extracts what it needs — the instance ID, the bucket name, the offending key — from the detail object.

Robust functions validate this input, because acting on a malformed or unexpected event could remediate the wrong resource.

Common Lambda remediations include:

• Swapping in a quarantine security group on a compromised instance.
• Disabling a leaked IAM access key.
• Enabling Block Public Access on an exposed bucket.
• Removing an over-permissive security group rule.

Each is a few API calls the function makes automatically.

A Lambda function runs with an execution role. Grant it only the permissions its remediation requires — nothing more.

An auto-remediation function is powerful by design, so its role is a prime target. Scoping it tightly limits the damage if the function or its event input is ever abused.

EventBridge can occasionally deliver an event more than once, and a finding may recur. Make remediation idempotent — safe to run repeatedly.

Applying a quarantine security group that is already attached should simply succeed without side effects, so duplicate invocations never cause harm or errors.

Automated actions can be disruptive, so add safety checks. The function might verify the resource has a specific tag, skip protected production systems, or require a severity threshold already filtered by the pattern.

Some teams gate destructive actions behind an approval step to prevent runaway automation.

Every remediation must leave a trail. Have the function write to CloudWatch Logs and optionally notify via SNS what it did and to which resource.

Combined with CloudTrail recording the API calls, this gives a complete record of automated responses for audit and post-incident review.

Remediation can fail — a permission gap, a throttled API, a deleted resource. Configure retries and a dead-letter queue so failed invocations are not lost.

The function should also alert a human when it cannot complete, so a failed auto-remediation escalates rather than silently leaving a threat unaddressed.

For EventBridge to call your function, the rule needs permission to invoke it — granted by a resource-based policy on the Lambda that trusts the EventBridge service.

The function's own execution role governs what it can do once running, while this invoke permission governs who is allowed to trigger it. Both must be in place for the pipeline to work.

Test remediation functions against sample events in a non-production account before trusting them with real incidents.

Verify they act on the right resource, respect their guardrails, and log correctly. Automation that fires wrongly can cause an outage as surely as an attacker, so validation is essential.

Why idempotency?

AWS Lambda is the flexible target that performs auto-remediation when an EventBridge rule matches a finding. The function reads the event detail, identifies the resource, and calls APIs to fix it — quarantining instances, disabling keys, or closing buckets. Give it a least-privilege execution role, make actions idempotent, add guardrails and logging, handle failures with a DLQ and alerts, and test thoroughly before trusting it in production.