When a cloud security incident starts, the first few minutes matter more than most teams expect. In AWS, it is easy to lose key evidence, break a production workload by mistake, or miss signs that the issue is broader than it first looked. That is why a runbook matters. A good incident response runbook gives responders a clear sequence: how to size the incident, what to contain first, what evidence to preserve, who to notify, and what to improve after the event. For teams preparing for the AWS Certified Security – Specialty SCS-C03 exam, this topic also shows up in a practical way. You need to know not just the AWS services, but how to use them under pressure. This guide walks through cloud triage steps, a solid evidence checklist, containment playbooks, communication templates, and post-incident follow-up in a way that mirrors real work.
Why an AWS incident response runbook needs cloud-specific steps
Traditional incident response methods still apply in AWS, but the environment changes how you collect evidence and contain damage. In a data center, you might isolate a physical server and image the disk. In AWS, the system may be spread across multiple accounts, Regions, Auto Scaling groups, containers, serverless functions, managed databases, and IAM roles. Resources can be short-lived. Logs may live in different services. An attacker may never log into an EC2 instance at all. They may use stolen API keys and move through IAM, S3, KMS, Lambda, or Secrets Manager instead.
That is why a cloud runbook should answer four questions quickly:
- What happened? Identify the event type, affected assets, and likely blast radius.
- How bad is it? Assign severity based on business impact, data exposure, and attacker access.
- What must we preserve? Collect logs, snapshots, memory-related clues where possible, and account activity before they change.
- What must we stop now? Contain access or malicious activity without destroying evidence.
A simple runbook reduces guesswork. It also makes actions more consistent across shifts and teams.
Severity triage steps for AWS incidents
Triage is the process of deciding how serious the incident is and what needs immediate attention. If severity is wrong, the response is wrong. Teams either overreact and disrupt services, or underreact and allow the incident to spread.
Use a severity model with clear triggers. A practical model is Sev 1 through Sev 4.
- Sev 1: Confirmed compromise with high business impact. Examples: active ransomware behavior, root account misuse, confirmed customer data exfiltration, organization-wide IAM abuse, production outage caused by malicious changes.
- Sev 2: Serious suspicious activity with possible data or privilege risk. Examples: GuardDuty findings showing credential exfiltration, unusual AssumeRole patterns across accounts, public S3 exposure involving sensitive buckets, unauthorized security group changes on production assets.
- Sev 3: Limited suspicious activity or policy violation with no confirmed impact yet. Examples: failed login spikes, malware detection on a noncritical workload, drift from security baselines, unauthorized but low-impact configuration changes.
- Sev 4: Low-risk alerts or events that need review but do not currently show compromise. Examples: noisy scans against public endpoints, non-sensitive test account misconfiguration, isolated detection with no follow-up indicators.
To assign severity, ask these questions in order:
- Is the incident active right now? If harmful actions are still happening, severity rises.
- What is the access level? Root, administrator role, production database access, or KMS key access usually pushes severity higher.
- What data or systems are involved? Customer data, regulated data, payment systems, and identity systems increase impact.
- What is the blast radius? One instance is different from one account, and one account is different from AWS Organizations-wide access.
- Can the attacker persist? New IAM users, backdoor Lambda functions, altered trust policies, and cross-account roles suggest ongoing risk.
Document the severity and the reason. This matters because severity often changes as you learn more.
Cloud triage steps: what to do in the first hour
The first hour should focus on preserving facts, understanding scope, and stopping further damage. Do not jump straight into deleting resources or rotating everything at once. In AWS, rushed action can erase the trail you need.
- Open the incident record. Start a case ID, timestamp the start, note who is responding, and record every action taken.
- Confirm the signal source. Was the alert from GuardDuty, Security Hub, CloudTrail, AWS Config, Detective, IAM Access Analyzer, an EDR tool, billing alerts, or a user report? Knowing the source tells you how reliable the signal is.
- Identify the affected scope. Capture account ID, Region, service, resource IDs, IAM principals, tags, environment type, and owner.
- Preserve log availability. Verify CloudTrail, VPC Flow Logs, Route 53 Resolver logs, ELB logs, S3 access logs if used, CloudWatch logs, and application logs are retained and not overwritten.
- Check for obvious spread. Review AWS Organizations activity, cross-account role assumptions, recent IAM changes, suspicious API calls, and simultaneous activity in multiple Regions.
- Decide containment strategy. Choose the least destructive action that stops the threat. For example, remove public exposure before terminating a system.
- Notify the right team. Security, cloud platform, workload owner, legal or privacy if needed, and leadership based on severity.
A common mistake is to treat every EC2 alert as a host-only issue. In AWS, the host may be a symptom. The real problem may be an IAM credential leak that also touches S3 and Lambda. Always check identity activity early.
Containment playbooks by incident type
Containment should stop the attacker while preserving evidence and avoiding unnecessary downtime. The right action depends on the incident type.
1. Compromised IAM user or access key
- Disable or rotate the exposed access keys.
- Revoke active sessions where possible and review recent API calls in CloudTrail.
- Check for created users, roles, inline policies, access keys, trust policy changes, and unusual AssumeRole actions.
- Review Secrets Manager, Parameter Store, and CodeBuild or CI pipelines for credential leakage paths.
- Contain with targeted policy denies if broad lockout would break production.
Why: Stolen AWS credentials often lead to fast privilege escalation. If you only rotate the original key but miss a newly created role or backdoor user, the attacker may keep access.
2. Root account misuse
- Immediately secure the root account with password reset and MFA validation.
- Review all root activity in CloudTrail across Regions.
- Check billing changes, support plan changes, alternate contacts, account settings, and security settings.
- Inspect IAM, SCPs, CloudTrail settings, and KMS key policies for malicious modifications.
Why: Root is rare in normal operations. Any unexpected root use is high risk because it can bypass many normal controls.
3. EC2 compromise or malware
- Do not terminate the instance immediately unless damage is ongoing and severe.
- Isolate using security groups, network ACLs if needed, or a quarantine VPC pattern.
- Capture EBS snapshots of attached volumes.
- Collect instance metadata, running processes if accessible, system logs, and recent user data or launch template changes.
- Check the instance profile role for misuse in CloudTrail.
Why: Termination destroys volatile clues and can hide how access happened. Quarantine first when possible.
4. S3 data exposure
- Block public access if exposure is unintended.
- Review bucket policy, ACLs, access points, and recent policy changes.
- Check object-level access logs if enabled, CloudTrail data events, and replication behavior.
- Identify whether sensitive objects were accessed, copied, or deleted.
Why: Public access is not the whole story. A bucket can also be exposed by cross-account policy or by a compromised role.
5. RDS or data store compromise
- Restrict network access and credentials with minimal disruption.
- Snapshot the database before major changes if business risk allows.
- Review parameter group changes, security groups, IAM database authentication activity, and application logs.
- Check whether the issue came from the database, the app layer, or stolen secrets.
6. Lambda or serverless abuse
- Disable or restrict the affected function trigger if malicious execution is active.
- Preserve function code, environment variables, versions, aliases, and CloudWatch logs.
- Review execution role permissions and outbound access patterns.
- Check CI/CD pipelines and deployment roles for tampering.
Evidence collection checklist for AWS incidents
Evidence should support three goals: understand what happened, prove scope and impact, and enable recovery. Collect evidence before changing too much.
Core account and control plane evidence
- CloudTrail logs for all Regions, including management and data events where enabled
- AWS Config timeline and resource configuration history
- GuardDuty findings and affected resource details
- Security Hub findings and workflow status
- AWS Detective investigation details if used
- IAM credential report
- IAM users, roles, policies, trust relationships, permission boundaries
- Organizations account activity and service control policy changes
- KMS key usage and key policy changes
- CloudFormation stack events, Terraform or pipeline logs if infrastructure changed through automation
Network evidence
- VPC Flow Logs
- Load balancer access logs
- Route 53 Resolver query logs and DNS records
- WAF logs if present
- Security group and network ACL configurations before and after the event
Compute and workload evidence
- EC2 instance IDs, AMI, launch template, instance profile, tags
- EBS snapshots of attached volumes
- Console output and system logs
- Running process, connection, and scheduled task details if you can access the host safely
- ECS task definitions, EKS audit logs, Kubernetes events if containers are involved
- Lambda code package, versions, aliases, environment variables, and execution logs
Storage and data evidence
- S3 bucket policy, ACLs, Block Public Access settings, object versioning status
- S3 server access logs or CloudTrail data events if enabled
- RDS snapshots, audit logs, parameter groups, and access history
- DynamoDB table policies and CloudTrail data events where available
Identity and secrets evidence
- Access key last used details
- Recent AssumeRole activity
- Secrets Manager secret access history
- SSM Parameter Store access patterns
- MFA device changes and account contact changes
For each item, record who collected it, when, from where, and the hash or integrity details if your process requires it. This is basic chain-of-custody discipline. Even if you are not going to court, it helps the team trust the evidence later.
If your team needs a starting point, keep an internal asset such as an IR runbook template with fields for timestamps, affected resources, evidence locations, approvals, and containment decisions.
Communication templates that work during incidents
Good communication reduces confusion. During an incident, people usually want too much detail too early or too little detail too late. Use short, structured updates.
Initial security team alert
Incident ID: IR-2026-001
Severity: Sev 2
Summary: Suspicious IAM activity detected in production account. Unusual AssumeRole calls from an unknown source. No confirmed data access yet.
Affected scope: Account 123456789012, us-east-1, IAM roles AppDeployRole and ReadOnlyAuditRole
Actions in progress: CloudTrail review, temporary deny policy on affected role, GuardDuty and Config validation
Requested support: Platform team to confirm expected deployment activity in last 2 hours
Leadership update
What happened: We detected suspicious AWS account activity affecting one production account.
Current impact: No confirmed customer-facing outage. No confirmed data loss at this time.
What we are doing: We have restricted the suspected access path, preserved logs, and are validating whether any systems or data were touched.
Next update: In 30 minutes or sooner if impact changes.
Workload owner request
We need: Confirmation whether these API calls and role assumptions were expected. Please provide deployment records, on-call engineer names, and any recent infrastructure changes between 10:00 and 12:00 UTC.
These templates work because they separate facts from assumptions. They also avoid emotional language. That helps people act on the message instead of reacting to it.
Post-incident improvements: what should change after recovery
The incident is not done when access is removed. A strong team turns every incident into a control improvement. The goal is not blame. The goal is to reduce the chance of repeat failure.
Focus the review on these areas:
- Detection gaps: Did CloudTrail data events, GuardDuty, Config rules, or Security Hub controls miss something important?
- Logging gaps: Were critical logs disabled, retained too briefly, or stored in too many places to use quickly?
- Identity hardening: Did the attacker exploit overbroad roles, missing MFA, weak trust policies, or long-lived keys?
- Network exposure: Were security groups, public subnets, or load balancer rules too open?
- Data protection: Was encryption configured correctly, and were key policies too permissive?
- Operational readiness: Did responders know where the runbook was, who had approval authority, and how to quarantine workloads?
Then create concrete actions. Good examples include:
- Enable organization-wide CloudTrail with centralized log protection
- Turn on GuardDuty and Security Hub in all accounts and Regions
- Reduce use of long-lived IAM user keys and move workloads to roles
- Add SCPs to block risky actions such as disabling logging
- Use S3 Block Public Access by default and stricter bucket policy review
- Deploy quarantine security groups and automation through Systems Manager
- Run incident response tabletop exercises every quarter
This kind of follow-up is also useful for exam preparation. The SCS-C03 exam often tests whether you know the preventive and detective controls that should exist before an incident happens. If you want more exam-focused preparation, you can review this AWS Certified Security Specialty SCS-C03 practice test as part of your study plan.
How to keep the runbook practical and usable
A runbook fails when it is too long, too vague, or too tied to one engineer’s memory. Keep it operational. That means:
- Use checklists, not essays
- Separate triage, containment, evidence, and communication into distinct sections
- List exact AWS services and log sources to check
- Include approval points for disruptive actions
- Test the runbook against real scenarios, not only theory
- Version it and review it after every incident
A good AWS incident response runbook is not just an exam topic. It is a safety tool. In the cloud, attackers move through APIs, roles, and managed services quickly. Responders need a process that matches that speed. If your triage steps are clear, your containment actions are measured, and your evidence checklist is complete, your team will make better decisions when the pressure is highest.
