AWS Incident Response Architecture — Overview
Incident Response accounts for 14% of the SCS-C03 exam (Domain 2). Questions focus on forensic isolation of compromised instances, automated remediation pipelines, and the specific AWS services used at each phase. This post covers the complete IR lifecycle: Preparation → Detection → Containment → Eradication → Recovery → Lessons Learned.
Security Hub Alert
CloudWatch Alarm
Config Rule Violation
Severity Classification
Route to Playbook
Revoke IAM credentials
Block network path
Snapshot for forensics
Rotate credentials
Patch vulnerability
Update WAF rules
Athena log queries
Memory forensics
Timeline analysis
IR Phases — AWS Services Mapping
| Phase | Actions | AWS Services |
|---|---|---|
| Preparation | Pre-deploy tools, access, runbooks | CloudTrail (org trail), GuardDuty, Security Hub, pre-provisioned forensic account with cross-account roles, SSM Automation documents |
| Detection | Identify security event | GuardDuty findings, Security Hub aggregation, CloudWatch alarms, Config rule violations, Inspector findings |
| Containment | Stop spread, preserve evidence | Security Group isolation, IAM policy denial, NACL blocking, EBS snapshot, memory dump, VPC Network Access Analyzer |
| Eradication | Remove threat | Terminate compromised instance, rotate keys (KMS, IAM), delete unauthorized resources, SSM Patch Manager |
| Recovery | Restore normal operations | Launch from clean AMI, restore from backup (AWS Backup), validate with Inspector scan, CloudFormation redeploy |
| Post-Incident | Root cause analysis, improve | Amazon Detective (graph analysis), Athena (log queries), update runbooks, apply preventive controls |
EC2 Forensic Isolation — The Key Exam Pattern
When an EC2 instance is compromised, the standard forensic procedure is:
- Tag the instance:
Status=Compromised,Incident=IR-2026-001(for tracking) - Isolate the network: Replace the security group with a “forensic isolation” SG that allows NO inbound/outbound traffic (or only outbound to forensic tools)
- Preserve evidence:
- Create EBS snapshots (disk forensics)
- Capture memory dump (if instance is running — use SSM to run memory capture tool)
- Capture instance metadata (instance type, security groups, IAM role, network interfaces)
- Disable auto-termination: Set
DisableApiTermination=true(prevent ASG from terminating) - Detach from ASG/ELB: Remove from load balancer target group (stops new traffic)
- Analyze in forensic account: Share EBS snapshots to dedicated forensic account → mount and analyze offline
Critical exam point: Do NOT terminate the instance immediately. You need evidence for root cause analysis. Isolate first, preserve, THEN terminate after analysis.
IAM Credential Compromise Response
- Identify compromised credentials: CloudTrail shows unauthorized API calls from unexpected IPs/regions
- Disable the credential:
- Access key: Deactivate (don’t delete yet — need for audit trail)
- IAM role: Add inline Deny policy with condition
aws:TokenIssueTime < [current time](revokes all existing sessions) - Console password: Delete login profile
- Review CloudTrail: What did the attacker do? What resources were accessed/modified?
- Rotate all related credentials: Any secrets the compromised role could access (Secrets Manager, Parameter Store)
- Review resource policies: Check if attacker created backdoor access (new IAM users, role trust policies, S3 bucket policies)
Automated Remediation Patterns
| Trigger | Automated Response | Implementation |
|---|---|---|
| GuardDuty: UnauthorizedAccess:EC2 | Isolate instance (swap SG), snapshot, notify | EventBridge → Step Functions (parallel: isolate + snapshot + SNS) |
| GuardDuty: CryptoCurrency:EC2 | Isolate instance, terminate after snapshot | EventBridge → Lambda (isolate + snapshot + terminate) |
| Config: non-compliant SG (0.0.0.0/0 SSH) | Auto-remediate by removing the rule | Config rule → SSM Automation → revoke-security-group-ingress |
| IAM: Root login detected | Alert + disable root access keys if any exist | CloudTrail → EventBridge (ConsoleLogin where userIdentity.type=Root) → Lambda |
| S3: Public bucket detected | Block public access immediately | Config rule (s3-bucket-public-read-prohibited) → SSM Automation → PutPublicAccessBlock |
Amazon Detective — Investigation
- What: Automatically builds a security behavior graph from CloudTrail, VPC Flow Logs, GuardDuty, Security Lake
- How: Visualizes relationships — which IAM entity accessed which resource, from which IP, at what time
- Use case: Determine blast radius of a compromise. “What else did this attacker do? What other resources were accessed?”
- Exam note: Detective is for investigation (post-detection). GuardDuty is for detection. Don’t confuse them.
Exam Tips
| Exam | Key Points |
|---|---|
| SCS-C03 | “Compromised EC2” → Isolate (SG), Snapshot, DON’T terminate yet. “Revoke IAM role sessions” → inline Deny with TokenIssueTime condition. “Automated remediation for GuardDuty” → EventBridge + Lambda/Step Functions. “Root cause analysis” → Amazon Detective. “Forensic analysis of disk” → EBS snapshot → share to forensic account → mount. “Auto-fix non-compliant resources” → Config rule + SSM Automation. |
AWS Certification Exam Practice Questions
Question 1:
GuardDuty detects that an EC2 instance is communicating with a known command-and-control server. The security team needs to immediately contain the threat while preserving forensic evidence. Which sequence of actions is correct?
- Terminate the instance immediately to stop the C2 communication
- Replace the instance’s security group with an isolation SG (no inbound/outbound), create EBS snapshots, then investigate
- Add a NACL rule blocking the C2 IP, leave the instance running normally
- Detach the instance’s IAM role and wait for the connection to timeout
Show Answer
Answer: B — Standard forensic procedure: (1) Network isolation via security group swap stops ALL communication (not just the known C2 IP — there may be other C2 channels). (2) EBS snapshots preserve disk evidence for analysis. (3) Instance remains running for potential memory forensics. Terminating (A) destroys evidence. NACL (C) only blocks one IP. Removing IAM role (D) doesn’t stop network communication.
Question 2:
An IAM access key has been exposed on GitHub. CloudTrail shows the key was used to create new IAM users and launch EC2 instances in multiple regions. What is the FIRST action to take?
- Delete the IAM user who owned the exposed key
- Deactivate the exposed access key and attach a Deny-all inline policy to the user
- Rotate the access key (create new, delete old)
- Change the console password for the user
Show Answer
Answer: B — First priority: stop the bleeding. Deactivate the key immediately (prevents new API calls). Attach Deny-all inline policy (catches any other credentials the user might have). Don’t delete the user (A) — you need the audit trail. Don’t just rotate (C) — the attacker’s existing sessions might still work. After containment: review what attacker did, remove unauthorized resources, investigate backdoors created.
Question 3:
A security engineer needs to revoke all active sessions for an IAM role that has been compromised. The role is assumed by multiple Lambda functions and EC2 instances. How can ALL existing role sessions be invalidated immediately?
- Delete the IAM role and recreate it
- Attach an inline policy to the role with Deny on all actions, conditioned on aws:TokenIssueTime being before the current timestamp
- Change the role’s trust policy to deny all principals
- Remove all managed policies from the role
Show Answer
Answer: B — The inline Deny policy with condition "Condition": {"DateLessThan": {"aws:TokenIssueTime": "2026-07-09T12:00:00Z"}} immediately denies all actions for sessions issued before that time. New legitimate sessions (after the timestamp) still work. Deleting the role (A) breaks all dependent services. Changing trust policy (C) prevents new assumptions but doesn’t affect existing sessions. Removing policies (D) takes time to propagate.
Question 4:
A company wants to automatically isolate any EC2 instance when GuardDuty detects cryptocurrency mining activity. The solution must also capture a memory dump before isolation and notify the security team. Which architecture achieves this?
- GuardDuty → SNS → Security team email (manual response)
- GuardDuty → EventBridge → Step Functions (parallel: SSM RunCommand for memory dump + Lambda for SG swap + SNS notification)
- GuardDuty → Lambda (sequential: memory dump, then isolate, then notify)
- GuardDuty → Config rule → auto-remediation
Show Answer
Answer: B — Step Functions orchestrates parallel actions: (1) SSM RunCommand executes memory capture tool on the instance (must happen BEFORE isolation cuts network). (2) Lambda swaps the security group to isolate after memory capture completes. (3) SNS notifies the team. Step Functions provides visual workflow, error handling, and audit trail. Single Lambda (C) can work but Step Functions is better for multi-step parallel operations with ordering dependencies.
Question 5:
After a security incident, the investigation team needs to analyze the compromised EC2 instance’s disk contents. The instance is in Account A (production). Forensic analysis must happen in Account B (forensic account) to avoid contaminating the production environment. How should the EBS data be transferred?
- Create AMI of the instance and share with Account B
- Create EBS snapshots, modify snapshot permissions to share with Account B, Account B creates volumes from shared snapshots in the forensic account
- Use DataSync to copy the EBS volume to Account B
- Attach the EBS volume to an instance in Account B
Show Answer
Answer: B — Standard cross-account forensic procedure: snapshot the EBS volumes → modify snapshot sharing permissions to allow Account B → Account B creates new volumes from the shared snapshots → attach to a forensic analysis instance. AMI sharing (A) works but includes all volumes plus metadata. DataSync (C) is for file-level copies. You cannot directly attach a volume cross-account (D). If the snapshot is encrypted, the KMS key policy must also allow Account B access.
Related Posts
- Security Services Architecture – GuardDuty & Security Hub
- Centralized Logging Architecture
- IAM Security Architecture
- Data Encryption Architecture
References
- AWS Security Incident Response Guide
- Automate EC2 Incident Response — AWS Security Blog
- Amazon Detective User Guide
- Step Functions for Security IR — AWS Blog
Frequently Asked Questions
Why not just terminate a compromised instance immediately?
Terminating destroys volatile evidence (memory, running processes, network connections). You lose the ability to determine: what the attacker did, what data was exfiltrated, how they got in, and whether they established persistence elsewhere. Always isolate first (SG swap), preserve evidence (snapshots + memory), investigate, THEN terminate. The isolation stops the threat while preserving evidence.
How do I revoke temporary credentials from an assumed IAM role?
Attach an inline Deny policy to the role with condition: aws:TokenIssueTime less than current time. This immediately invalidates ALL sessions issued before that timestamp. New sessions (assumed after the timestamp) still work normally. This is the official AWS-recommended approach — you cannot individually revoke STS tokens.
What is the difference between GuardDuty and Detective?
GuardDuty is for detection — it identifies threats (finding: “EC2 is talking to a C2 server”). Detective is for investigation — after you know something happened, Detective helps you understand the full scope (“what else did the attacker do, what was the timeline, which other resources were affected”). GuardDuty triggers the alert; Detective helps you investigate it.