What is AWS incident response?

AWS incident response is the practice of detecting, investigating, containing, and recovering from a security incident in an Amazon Web Services environment. It is its own discipline because the attack surface, the control plane, and the evidence layer are all the AWS API: damage spreads at API speed, identity rather than the network is the perimeter, and ephemeral resources destroy evidence unless logging and forensics were engineered in advance.

How is cloud incident response different from on-prem IR?

In the cloud, a single set of credentials calling the AWS API can enumerate, create, and destroy resources across every region in minutes, with no traditional lateral movement. The perimeter is IAM, not the network; instances, containers, and functions terminate and take their evidence with them; and the blast radius can span every account in your organisation. We rebuild the on-prem playbook around those realities rather than transplanting it unchanged.

What does cloud forensics on AWS involve?

Cloud forensics on AWS centres on evidence you can only capture if it was prepared for: control-plane and data-event logs in CloudTrail, network and DNS telemetry, and disk evidence taken as EBS snapshots copied read-only into an isolated forensic account. Volatile memory is captured from inside the guest while the instance is still running. Immutable, WORM-protected logs preserve the chain of custody.

Can you contain an AWS incident without taking down production?

Yes, and that is the point. Containment in the cloud can cause its own outage: isolating an instance in an auto-scaling group invites a replacement, and denying a role can sever the workload it was running. We use reversible, evidence-preserving containment, denying compromised sessions, quarantining with security groups, and detaching with termination protection, so you stop the attacker without stopping the business.

Which AWS services do you use for detection and response?

We work with the native AWS toolchain at the mechanism level: CloudTrail with data events as the system of record, GuardDuty and Security Hub for detection, Amazon Detective and Athena for investigation, Config for resource history, and EventBridge with Systems Manager for scoped, guardrailed response automation. We design to AWS's own incident response guidance and the NIST SP 800-61 lifecycle, then go beyond it.

AlvorAdvisory

AWS Incident Response · NIST SP 800-61

AWS incident response, re-architected from the ground up.

Alvor is a specialist AWS incident response and cloud forensics practice. An AWS incident is not a server you can unplug and image at your leisure: a leaked access key can stand up resources in every region before the first alert is read, the instance holding your evidence can terminate itself, and the blast radius runs along IAM trust rather than the network wire. We respond the way the cloud actually fails: identity first, evidence preserved before anything is torn down, and containment scoped so you stop the attacker without stopping the business.

Book a consultation How an engagement runs

NIST SP 800-61 lifecycleCloudTrail · GuardDuty · DetectiveContained without the outage

The tension

An AWS account is not a data centre.

Incident response grew up in the data centre: a network you defend at the edge, servers that sit still long enough to image, an attacker who moves at human pace, and logs that wait on the box until you collect them. None of that holds in AWS. The estate is defined in IAM and built from API calls, the machines are disposable, and an action taken with a stolen key lands across regions in seconds. Cloud incident response is not on-prem incident response in someone else’s data centre. It is a re-architected discipline, and the on-prem playbook has to be rebuilt around how the cloud actually fails.

What on-prem IR assumes

A network edge you defend and inspect
Servers that persist, ready to be imaged
An attacker moving at human speed
Logs waiting on the host until you collect them
A console and cables you physically control

What an AWS incident actually is

Identity as the perimeter, IAM trust as the path
Instances, containers, and functions that vanish
Damage spreading at the speed of an API call
Evidence that exists only if you logged it first
A blast radius that can span every account you have

Why the on-prem playbook fails here

Five ways a data-centre playbook breaks in the cloud.

None of this is an argument against having an incident response plan. It is an argument for one built on how AWS actually works. Each of these is a real way a sound on-prem instinct, applied unchanged to the cloud, costs you the response when it matters most.

API speed

By the time a human reads the alert, the key has been everywhere it can reach.

A leaked long-term access key needs no malware and no lateral movement in the traditional sense. It calls the AWS control plane directly. Enumeration, resource creation in regions you do not even use, and data access can all happen in minutes, automated, by a bot that found the key in a public repository before you did. The number that decides the outcome is dwell time, the gap between exposure and detection, and in the cloud that gap is measured against an adversary working at machine speed. A response cadence tuned to human-paced intrusions is already behind.

Identity, not network

The breach runs along IAM trust, not the network wire.

Most AWS incidents are credential incidents, not network ones: a long-term key committed to a public repository, a role assumed through an over-permissive trust policy, or instance credentials lifted from the metadata service through a server-side request forgery. The 2019 Capital One breach is the canonical case of that last path, more than a hundred million records reached through an over-permissioned role; IMDSv2, with its session-oriented requests and a default single network hop, is the mechanism that closes it where it is enforced. Defending the network tells you little once the attacker is authenticated. The questions that matter are which principal, which permissions, and what it can assume next.

Ephemeral evidence

The box that holds the evidence can terminate before you reach it.

An auto-scaling group replaces an unhealthy instance, a container exits, a function returns, and the volatile evidence goes with them. In the data centre the disk waits for you. In AWS it does not. Cloud forensics is therefore decided before the incident, not during it: management and data-event logging turned on across accounts, flow and DNS logs retained, and a snapshot-first reflex so the volume is copied read-only to a forensic account before anything is rebuilt. If the logging was not designed in advance, the evidence is simply gone.

Containment risk

Pull the wrong credential and you take production down yourself.

Containment that takes down production is just a second incident. Isolating an instance inside an auto-scaling group invites its own replacement. Denying a role to stop an attacker can sever the workload that role was running. Deleting compromised infrastructure can destroy the evidence and the service in one move. Mature cloud containment is precise rather than blunt: deny the sessions issued before a cutoff, quarantine with a restrictive security group, detach with termination protection, and isolate the resource without tearing down the business around it. Speed matters, and so does the blast radius to your own operations.

Org-wide radius

One assumed role can carry the incident across every account you have.

A single AWS account was never the boundary. Cross-account role assumption, an Organizations management account, shared services, and a centralised pipeline identity all mean an attacker who lands in one place can often reach the others. In AWS, your IAM policy is your blast radius, and containment that stops at the account where the alert fired misses the lateral path the cloud makes easy. The response has to reason about the whole organisation: the trust between accounts, the privileged identities that span them, and the guardrails that should have bounded the radius before the incident began.

Prepared by design

The work that decides an incident happens before it.

By the time an alert fires, the outcome is already mostly set: by whether the logs you need exist, whether the access to investigate is ready, and whether the team has run the play before. Incident response is not a document you write and file. It is a capability you build and rehearse. We baseline what you can actually see and do under pressure, close the gaps that only surface in a real incident, and prove the response works on a tabletop before it has to work for real. Attacks move at API speed, so the response has to be pre-staged, not improvised.

1We rehearse before the incident: codified runbooks, game-day exercises, and break-glass access tested rather than assumed.
2Containment is scoped to the blast radius, not the blunt instrument: deny the compromised sessions and constrain the principal without taking the workload down with them.
3Evidence is preserved before anything is eradicated: snapshots copied read-only to an isolated forensic account, with immutable logs that hold up after the fact.

How the work runs

Before the incident, or in the middle of one.

AWS incident response is the same four delivery tracks as the rest of the practice, pointed at readiness and response. Engage us to get ready, to stand the capability up, or on the worst day to run the response with you. Each stage ends on a decision that stays yours.

01Assess

Find out what you could actually see and do.

We test the response against a real scenario: can you detect it, can you scope it from the logs, can you contain it without an outage. You get an incident-response readiness assessment, a tabletop run with your team, and a ranked list of the gaps that would hurt on the day.

IR readiness assessmentTabletop exercisePrioritised gap register

Explore Assess

02Architect

Design the response before you need it.

We design the readiness: the logging and forensics architecture, the runbooks for the scenarios that fit your estate, the break-glass and forensic-account patterns, and the containment automation built with the guardrails to fire safely rather than break production.

Logging & forensics designScenario runbooksBreak-glass & forensic account

Explore Architect

03Build

Stand the capability up, then prove it.

We implement alongside your team: detection tuned, the forensic account stood up, response automation deployed and tested, and evidence retention made immutable. Nothing is marked ready until it has survived a rehearsal, not just a closed ticket.

Detection tunedForensic account builtAutomation rehearsed

Explore Build

04Operate

Be there on the day, and after.

A standing incident-response retainer: agreed response times, a team that already knows your environment, and the investigation, containment, and reporting support when an incident hits. Between incidents we keep the readiness current and fold every lesson back in.

IR retainerInvestigation & containmentContinuous readiness

Explore Operate

The AWS incident response lifecycle

Four phases, each with its own tooling and its own decisions.

We work to the four-phase incident response lifecycle that NIST SP 800-61 established and its 2025 revision now aligns to the Cybersecurity Framework, mapped onto the AWS services that make each phase real. The phases are not bureaucracy. They are the difference between a response that compounds and one that improvises, and they keep the work on the customer side of the shared-responsibility line where it belongs.

Preparation

Before the day

The phase that decides the other three. Logging turned on and retained across accounts, a forensic account stood up, runbooks written, roles and out-of-band comms agreed, and break-glass access tested. Detective guardrails in place so the incident is seen, and response automation built with the guardrails to not misfire.

CloudTrail org trailConfig · Security HubForensic accountRunbooks · game days

Detection & analysis

Seeing it

Turning signal into an understood incident. GuardDuty and Security Hub findings triaged, the behaviour reconstructed in Detective, and the full story queried from the logs with Athena and CloudWatch. The output is scope: which identities, which resources, which accounts, and how far it has reached.

GuardDutyAmazon DetectiveAthena over CloudTrailVPC Flow · DNS logs

Containment & recovery

Stopping it

Stopping the spread without stopping the business, then removing the foothold and restoring trust. Sessions denied and keys rotated, principals constrained, resources quarantined, then the attacker's artefacts eradicated and the environment rebuilt from known-good. Evidence is captured before anything is torn down.

Session deny · key rotationSecurity-group quarantineSystems ManagerRebuild from known-good

Post-incident activity

Learning from it

The phase most teams skip and the one that pays back. A blameless review of what happened and why, the detection and guardrail gaps closed so the same path cannot reopen, and the reporting obligations met on their clocks. Each incident is made to leave the next one smaller.

Blameless reviewDetection gaps closedGuardrail hardeningReporting met

The reporting clock

The moment you detect, a second clock starts running.

A serious incident is not only a technical event. It triggers obligations with deadlines, and the deadlines run from when you became aware, not from when the dust settles. The evidence those reports need, who acted, what was accessed, and when, is the same evidence the investigation produces, provided the logging was there to capture it. We build the response so the regulatory account is a by-product of the investigation rather than a second scramble. The reach depends on where you operate and what data you hold, and we map the obligations that bind you to the response in advance.

Every engagement maps to the methods the field already trusts: the NIST SP 800-61 lifecycle, the SANS PICERL model, and MITRE ATT&CK for the cloud, so the response is structured and the evidence defensible.

SEC cyber disclosureMaterial cybersecurity incidents disclosed by US-listed companies within four business days of judging the incident material.
GDPR · UK GDPRPersonal-data breaches notified to the supervisory authority without undue delay, and within 72 hours of becoming aware where feasible.
NIS2 · DORAEU operational-resilience regimes with staged incident-reporting clocks, the first notification measured in hours, not days.
HIPAA Breach NotificationBreaches of protected health information notified to individuals and regulators within the statutory deadlines, up to 60 days.
State laws · PCI · contractualState breach statutes, card-brand rules, and the cyber-insurance and customer commitments that frequently set the tightest clock of all.

Common questions

What teams ask about AWS incident response.

The questions a security lead brings to a first conversation about cloud incident response and forensics on AWS.

What is AWS incident response?: AWS incident response is the practice of detecting, investigating, containing, and recovering from a security incident in an Amazon Web Services environment. It is its own discipline because the attack surface, the control plane, and the evidence layer are all the AWS API: damage spreads at API speed, identity rather than the network is the perimeter, and ephemeral resources destroy evidence unless logging and forensics were engineered in advance.
How is cloud incident response different from on-prem IR?: In the cloud, a single set of credentials calling the AWS API can enumerate, create, and destroy resources across every region in minutes, with no traditional lateral movement. The perimeter is IAM, not the network; instances, containers, and functions terminate and take their evidence with them; and the blast radius can span every account in your organisation. We rebuild the on-prem playbook around those realities rather than transplanting it unchanged.
Do you offer an AWS incident response retainer?: Yes. Our Operate track is a standing AWS incident response retainer with response times agreed in writing, a team that already knows your environment, and investigation, containment, and reporting support when an incident hits. Between incidents we keep your readiness current. You can also engage us purely for a readiness review, or on the day of an active incident.
What does cloud forensics on AWS involve?: Cloud forensics on AWS centres on evidence you can only capture if it was prepared for: control-plane and data-event logs in CloudTrail, network and DNS telemetry, and disk evidence taken as EBS snapshots copied read-only into an isolated forensic account. Volatile memory is captured from inside the guest while the instance is still running. Immutable, WORM-protected logs preserve the chain of custody.
Can you contain an AWS incident without taking down production?: Yes, and that is the point. Containment in the cloud can cause its own outage: isolating an instance in an auto-scaling group invites a replacement, and denying a role can sever the workload it was running. We use reversible, evidence-preserving containment, denying compromised sessions, quarantining with security groups, and detaching with termination protection, so you stop the attacker without stopping the business.
Which AWS services do you use for detection and response?: We work with the native AWS toolchain at the mechanism level: CloudTrail with data events as the system of record, GuardDuty and Security Hub for detection, Amazon Detective and Athena for investigation, Config for resource history, and EventBridge with Systems Manager for scoped, guardrailed response automation. We design to AWS's own incident response guidance and the NIST SP 800-61 lifecycle, then go beyond it.

AlvorAdvisory

Bring us your worst day.

A live intrusion, a leaked key, or the wish to be ready before either: tell us the state of your AWS estate and what it has to protect. We scope the work in writing, a readiness review or an AWS incident response retainer, before the next alert fires.

Book a consultation See the four tracks

AWS incident response, re-architected from the ground up.

An AWS account is not a data centre.

The work that decides an incident happens before it.

Four phases, each with its own tooling and its own decisions.

The moment you detect, a second clock starts running.