EventBridge, Step Functions & Lambda Security Orchestration
A security orchestration pipeline that detects unauthorized EC2 security group modifications via EventBridge, orchestrates response with Step Functions, isolates instances with Lambda, captures EBS forensic evidence, and publishes reports to SNS.
Manually responding to suspicious security group changes is slow and inconsistent, leaving compromised instances reachable while analysts investigate.
Turns detection into an automated, repeatable runbook: isolate first, preserve evidence, then notify — shrinking the window between signal and containment.
Catches unauthorized EC2 security group modifications as they happen.
Runs isolation, forensics, and reporting as one ordered workflow.
Cuts off compromised instances while snapshotting disks for forensics.
Event-driven response chain: a detection event fans out into isolation, evidence capture, and notification, all tracked as a single state machine execution.
EC2 SG Change ──> EventBridge Rule ──> Step Functions
│
┌─────────────────────────┼─────────────────────────┐
▼ ▼ ▼
Lambda (Isolate) EBS Snapshot SNS Incident Reportsoar-pipeline/
├── template.yaml # EventBridge rule + functions
├── src/
│ ├── isolate.py # Instance isolation
│ ├── snapshot.py # Forensic capture
│ └── notify.py # Report formatting
└── tests/
└── simulate_event.json # Simulated security eventRun active operations audits utilizing the custom sandbox telemetry receiver widget below.
Isolation, forensics, and notification must run in order with retries and a full audit trail.
Step Functions state machine
Accepted per-execution orchestration overhead in exchange for reliability and a complete audit trail.
Add approval gates before destructive isolation actions in production accounts.
Response functions need powerful actions (isolation, snapshots) that must not become a privilege escalation path.
Snapshots taken after an incident must be trustworthy for later analysis.
Validating the pipeline without a real attack to respond to.
Root Cause:Detection and response logic only runs when matching security events occur.
Crafted simulated security group modification events and traced them through execution history.
Built a repeatable simulation event plus checks on execution history, metrics, and isolation effectiveness.
Simulations approximate but never fully reproduce attacker behavior.
Security automation needs a test harness from day one, not just production events.
Orchestration beats chaining: explicit state machines make incident flows reviewable.
Decouple detection from response so either side can evolve independently.
Automated evidence capture turns incidents from anecdotes into auditable records.
I would add a human approval step before isolation for production use.
Audit raw repository script configurations directly inside the active terminal workspace.
Keep exploring
An event-driven cloud security analytics pipeline that ingests AWS CloudTrail records, applies normalization and risk scoring heuristics, and fires alert integrations under 45 seconds to secure distributed multi-tenant AWS accounts.
ArchitectureCloudTrail → S3 → Lambda → EventBridge → SNS
A production-style distributed queue processing system: a Lambda worker drains DynamoDB orders from SQS with structured correlation logging, multi-dimensional CloudWatch monitoring, SNS alert routing, injected failure drills, and runbook-driven recovery measured against SLOs.
ArchitectureSQS → Lambda Worker → DynamoDB → CloudWatch → SNS Alert Queue
A saga-based order processing system on Step Functions implementing idempotent operations, bounded retries, compensating actions, manual repair procedures, failure testing, and a transactional outbox over DynamoDB Streams to close the write/publish gap.
ArchitectureAPI → Step Functions Saga → Services → Compensations → DynamoDB Streams Outbox