AWS best practices for incident response

AWS best practices for incident response are codified in the AWS Security Incident Response Guide and the AWS Well-Architected Framework Security pillar. The framework borrows the NIST SP 800-61 lifecycle and adapts each phase to cloud-native controls. The lifecycle has three operating bands: Prepare (build the runbooks, accounts, identities, and automation before anything fires), Operate (detect, analyze, contain, eradicate, recover during an active event), and Post-incident activity (lessons learned, control hardening, automation backfill). The exam expects you to map each phase to specific AWS services and to recognize when a candidate answer skips a phase that the framework treats as non-optional.

Preparation in AWS is account-shaped. The recommended pattern is a dedicated security tooling account inside AWS Organizations that holds delegated administration for GuardDuty, Security Hub, Inspector, IAM Access Analyzer, Macie, and AWS Config. A separate log archive account holds the organization CloudTrail, the Security Lake data lake, and immutable copies of S3 server access logs and VPC Flow Logs. A separate forensics account holds the analyst's workstations, the forensic AMIs, the quarantine VPC, and the IAM roles that responders assume to operate on subject accounts. Pre-deployed cross-account roles in every workload account give responders read access to evidence and a narrow set of write actions to invoke isolation and snapshot runbooks. This separation respects blast-radius control: even if the workload account is fully compromised, the evidence in the log archive account is out of reach because its bucket policy denies delete actions to every principal outside the archive account.

The Operate phase is where the exam tests sequencing knowledge. The canonical order is Detect, Analyze, Contain, Eradicate, Recover. Detection is event-driven through GuardDuty findings, Security Hub Security Standards findings, Config rule non-compliance, CloudWatch alarm state changes, and custom EventBridge rules over service logs. Analysis happens against immutable log copies, often inside the log archive account using Athena over the S3 raw logs or CloudWatch Logs Insights over CloudWatch Logs groups. Containment is network-first because it stops lateral movement without destroying evidence. Eradication removes the root cause, which may be a patched vulnerability, a rotated credential, an updated security group baseline, or a redeployed image. Recovery restores service from a known-good baseline, often by re-launching from a hardened AMI, restoring from AWS Backup, or rebuilding through CloudFormation. Skipping containment to jump straight to eradication is a common wrong-answer pattern: the attacker keeps a foothold while remediation is in flight.

Post-incident activity is the phase that turns a single event into a control-hardening initiative. The lessons-learned process produces three artifacts: a corrected runbook in Systems Manager Incident Manager, a new Config rule or Security Hub control that would have caught the precursor signal, and an updated GuardDuty suppression rule that removes any false positives that distracted responders during the live event. The artifact pattern matters on the exam because answers that say "the responder writes a post-mortem" without mapping the post-mortem to a control change are weaker than answers that close the loop in code.

Notification is the glue that wires the lifecycle together. The default AWS pattern is event-driven through Amazon EventBridge with Amazon SNS as the human-fanout layer.

Notification mechanisms for security events (Amazon SNS, Amazon EventBridge)

EventBridge is the central event bus for security events. Every detection service publishes events to the default event bus or to a custom security event bus. GuardDuty findings land on the bus under the source aws.guardduty and the detail type GuardDuty Finding. Security Hub aggregates findings and republishes them as Security Hub Findings - Imported (raw) and Security Hub Findings - Custom Action (analyst-invoked). AWS Config publishes compliance change events under aws.config and Config Rules Compliance Change. CloudWatch alarms publish state changes under aws.cloudwatch. IAM Access Analyzer publishes findings under aws.access-analyzer.

Rules on the bus filter events by source, account, severity, finding type, and resource tags. Targets include SNS topics for human notification, Lambda functions for enrichment or auto-remediation, Step Functions state machines for multi-step orchestration, Systems Manager Automation runbooks for direct remediation, and SQS queues for downstream pipelines. EventBridge Pipes and input transformers reshape the event payload before delivery, which is the official pattern for normalizing finding shape across providers.

SNS is the human-fanout layer. A standard pattern publishes high-severity findings to a topic subscribed by an email distribution list for the security on-call, a Slack channel through AWS Chatbot, and an Incident Manager response plan. SNS message attributes carry the severity, the finding type, and the workload tag so subscribers can filter at the subscription layer.

The following EventBridge rule routes GuardDuty findings of HIGH severity (7.0 and above on the GuardDuty 0-10 scale) into an SNS topic and an Incident Manager response plan, and any finding with detail type Backdoor into a Lambda isolation function:

{
 "source": ["aws.guardduty"],
 "detail-type": ["GuardDuty Finding"],
 "detail": {
 "severity": [{ "numeric": [">=", 7.0] }]
 }
}

The next snippet is the CLI that builds the rule, the SNS topic, the Lambda permission, and the Incident Manager target binding:

aws sns create-topic --name SecHigh-NotifyOncall

aws events put-rule \
 --name guardduty-high-severity \
 --event-pattern file://gd-high.json \
 --event-bus-name security-events

aws events put-targets \
 --rule guardduty-high-severity \
 --event-bus-name security-events \
 --targets "Id"="oncall","Arn"="arn:aws:sns:us-east-1:111111111111:SecHigh-NotifyOncall" \
 "Id"="im","Arn"="arn:aws:ssm-incidents::111111111111:response-plan/sev1-plan","RoleArn"="arn:aws:iam::111111111111:role/EventBridgeIncidentRole"

A second rule subscribes only to AWS Config compliance changes that flip a rule from COMPLIANT to NON_COMPLIANT for the security-tagged baseline and routes them to an SSM Automation runbook for remediation. The rule pattern is:

{
 "source": ["aws.config"],
 "detail-type": ["Config Rules Compliance Change"],
 "detail": {
 "messageType": ["ComplianceChangeNotification"],
 "newEvaluationResult": {
 "complianceType": ["NON_COMPLIANT"]
 },
 "configRuleName": [
 "s3-bucket-public-read-prohibited",
 "encrypted-volumes",
 "iam-user-mfa-enabled"
 ]
 }
}

💡 Exam Trap: EventBridge default event bus only receives events from the same account. Cross-account routing for an organization-wide bus requires a custom event bus with a resource-based policy allowing events:PutEvents from the org root, plus an EventBridge rule on each source account that forwards events to the central bus. The exam often poses a centralization scenario and lists answers that mention only the default bus.

📊 Limit: A single EventBridge rule can have at most 5 targets. Custom action invocations from Security Hub fan out through these targets, so for more than 5 downstream consumers you front them with an SNS topic or a Step Functions state machine that fans out internally.

⚠️ Anti-Pattern: Wiring CloudWatch alarms directly to SNS without an EventBridge intermediary loses the ability to filter, enrich, and route the event. The current AWS-recommended path is alarm state change to EventBridge to a router rule to the target, which keeps the alerting plane consistent across CloudWatch, GuardDuty, Security Hub, and Config.

🎯 Scenario: A retail platform sees a sudden spike in GuardDuty UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B findings tied to a service-account IAM user. The on-call wants an SMS, the SOC wants a Slack ping, and the runbook system needs a ticket. The AWS-native pattern wires the GuardDuty finding to an EventBridge rule, fans out through an SNS topic with email, SMS, and AWS Chatbot subscriptions, and uses a second target on the rule to start an Incident Manager response plan, which posts to ServiceNow through a built-in integration.

Decision Anchor. Choose EventBridge as the routing layer when the consumer set is heterogeneous, when filtering or enrichment is needed, or when targets are AWS-native (SNS, Lambda, Step Functions, SSM, Incident Manager). Choose SNS only as the human-fanout layer at the end of the pipeline. Choose CloudWatch alarms only when the source signal is a metric, not an event; convert the alarm state change to an EventBridge event for routing.

The preparation phase finishes by codifying the runbook. Incident Manager response plans bind the EventBridge rule to an escalation chain (contacts and engagement plans), an incident template (severity, title, summary), and a chat channel (Chime or Slack through Chatbot). The plan invokes SSM Automation runbooks as remediation actions, which keeps the human responders and the automation synchronized on the same incident record.

The Operate phase also depends on a credentialed responder identity. The recommended pattern is an IAM Identity Center permission set named SecurityIncidentResponder, assigned to the security on-call group, granting AWSSecurityIncidentResponseFullAccess plus account-specific assume-role permissions into pre-deployed SecurityBreakGlass roles in each workload account. Break-glass roles use STS session policies and require an MFA condition, and every assume-role call is monitored by a CloudTrail metric filter that triggers an alarm on use.

The Prepare phase output is verifiable through tabletop exercises run through AWS Fault Injection Service against a non-production account and through Resilience Hub assessments that test the response plan against a defined RTO. The exam expects you to know that test-the-plan is part of preparation, not an optional add-on.