What Is Cloud Incident Response? A Defender's Guide

A leaked AWS access key gets committed to a public GitHub repo at 14:02. By 14:09 an automated scanner has it. By 14:20 the attacker has called sts:GetCallerIdentity, enumerated the account, spun up a dozen GPU instances for cryptomining in three regions, and created a second IAM user as a backdoor. The compromised EC2 host that ran the original workload has already been torn down and replaced by an auto-scaling group, taking its disk and memory with it. The on-prem playbook says pull the machine off the network and image the drive. There is no machine to pull and no drive to image. This is why cloud incident response is its own discipline.

Cloud incident response is the process a team follows when a security incident happens in a cloud environment. It runs the same lifecycle as any incident response (preparation, detection, containment, eradication, recovery, and a post-incident review), but the cloud changes what every one of those steps looks like. There is no console to walk up to, the infrastructure rewrites itself by the minute, identity is the perimeter, and the evidence lives in provider logs you have to enable before the incident, not after.

This guide covers what cloud incident response is, why it differs from traditional endpoint IR, the cloud log sources you investigate from, how to contain an active cloud threat when you cannot unplug anything, and how to prepare before the key leaks.

What is cloud incident response?

Cloud incident response (cloud IR) is the structured process for detecting, investigating, containing, and recovering from a security incident in a public cloud environment such as AWS, Azure, Google Cloud, or Oracle Cloud Infrastructure. The goal is the same as any incident response: limit the damage, evict the attacker, restore normal operations, and learn enough to prevent the next one.

The phases map cleanly onto the standard models. NIST SP 800-61 frames it as preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. The SANS PICERL model splits the same work into six steps: preparation, identification, containment, eradication, recovery, and lessons learned. Cloud IR does not replace those frameworks. It inherits them.

What changes is the terrain. In a data center you own the hardware, the hypervisor, the network taps, and the disks. In the cloud you own a slice of someone else's platform, defined by a shared responsibility model: the provider secures the infrastructure, and you secure your data, identities, configurations, and access. That line decides what you can investigate yourself and what you have to request from the provider. A responder who treats a cloud account like a remote data center makes wrong calls fast, because the assumptions that hold on-prem (a fixed host, a reachable console, a disk you can image) stop being true the moment the workload is ephemeral.

How cloud IR differs from traditional endpoint IR

The lifecycle is familiar. The execution is not. Five differences reshape every cloud investigation.

No physical access. You cannot connect a console, pull a disk, or attach a hardware capture tool to a cloud workload. Everything happens through the provider's API: you take a logical snapshot of a volume, you pull logs, you query the control plane. Forensics in the cloud is API-driven, which is why cloud forensics is a distinct skill set from disk and memory forensics on a physical box.

Accelerated lifecycles destroy evidence. Containers live for minutes. Serverless functions exist only while they run. Auto-scaling groups terminate and replace instances on a schedule. When a workload is discarded, its disk, its memory, and its local logs go with it, often before an analyst even sees the alert. In a data center the compromised host is still sitting there an hour later. In the cloud the artifact you needed may have been garbage-collected before you logged in.

Identity is the perimeter. There is no network cable to cut. An attacker in the cloud operates as a security principal: a leaked access key, an over-permissioned IAM role, a stolen session token, a compromised service account. Containment means disabling principals and revoking credentials, not isolating a subnet. A responder who reaches for network controls first will watch the attacker keep working through an identity the network never sees.

Rogue and unknown environments. A new cloud account can be created by any business unit with a credit card, outside the visibility of central security. The first the SOC hears of a "shadow" account is often the incident itself. Scope discovery in the cloud includes finding the parts of the estate nobody told you about, which never happens with a managed on-prem asset inventory.

The skills gap is worse. Cloud security IR specialists are harder to find and retain than general cloud engineers. The discipline combines deep platform knowledge (how AWS IAM evaluates a policy, how an Azure managed identity gets a token) with classic investigation instinct, and few people have both.

Cloud log sources: where the investigation happens

With no disk to image, logs are the investigation. The catch is that most cloud logging is opt-in or short-retention by default, so the preparation phase is where you decide whether the next incident is investigable at all. The core sources, by provider:

The control-plane audit log is the backbone of any cloud investigation. AWS CloudTrail records every API call: who (which principal), what (which action), when, from where (source IP), and to what (the resource). That record is how you reconstruct an attacker's path through an account, from the first GetCallerIdentity to the IAM user they created for persistence. Azure's Activity Log and Google's Cloud Audit Logs play the same role on their platforms.

Two failure modes wreck cloud investigations before they start. The first is logging that was never enabled: CloudTrail data events, VPC Flow Logs, and S3 access logs are off or partial by default, so the evidence simply does not exist. The second is retention: logs that exist but rolled off after 90 days, when the forensic timeline needs six months. Centralizing logs into a cloud SIEM or a dedicated logging account, with retention set deliberately, is a preparation task that pays off only when an incident actually lands. By then it is too late to turn it on.

Containing an active cloud threat

You cannot unplug the compromised machine. Cloud containment is about identity and configuration, executed through the API, and it has a specific order: cut the attacker's access without destroying the evidence you need to understand what they did.

1. Identify the compromised principals. Work the control-plane log to find every identity the attacker used: the leaked access key, any IAM users or roles they created, assumed-role chains, and stolen session tokens. The key you know about is rarely the only one. Map the full set before you start revoking, or you cut one head and leave another.
2. Revoke and disable access. Deactivate or delete the compromised access keys, disable the principals, and revoke active sessions (an attacker holding a valid session token keeps working even after you rotate the key behind it). Apply an explicit deny policy to lock a principal out instantly while you investigate.
3. Preserve evidence first. Before you terminate anything, snapshot the volumes and capture memory where the platform allows it, and copy the relevant logs to a location the attacker cannot reach. Ephemeral infrastructure means evidence is perishable; capture it before containment or recovery deletes it for good.
4. Hunt for persistence. Cloud attackers plant durable backdoors that survive a key rotation: a second IAM user, a new access key on an existing user, an over-permissioned Lambda or function, a modified trust policy, rogue VPC peering, or an altered security group that quietly allows inbound from the attacker's range. Eradication that only revokes the original key leaves these in place, and the attacker walks back in.
5. Isolate the affected resources. Quarantine compromised instances with a restrictive security group rather than terminating them (termination destroys evidence), tighten the security groups the attacker loosened, and remove the rogue network paths. This is the cloud equivalent of pulling a host off the network, done through configuration instead of a cable.

The thread through all five steps is that containment and forensics happen through the control plane, and the order matters: preserve before you eradicate. This is the same containment-then-eradication discipline that drives cloud detection and response, applied under pressure during a live incident.

Preparing for cloud incidents

Cloud IR is won or lost in the preparation phase, because half the things you need during an incident cannot be created during one. The work that has to happen first:

• Enable and centralize logging now. Turn on CloudTrail (including data events), VPC Flow Logs, and resource access logs across every account and region, ship them to a separate logging account or SIEM, and set retention to match your real investigation window, not the 90-day default.
• Pre-stage access and roles. Responders need a break-glass role with the permissions to investigate and contain in every account, ready before the incident. Negotiating IAM access mid-incident loses the hours that matter most.
• Build a cloud asset inventory. You cannot respond in accounts you do not know exist. Continuous discovery of accounts, workloads, and identities shrinks the rogue-environment problem from a surprise to a known list.
• Write cloud-specific playbooks. A leaked-key playbook, a compromised-IAM-role playbook, a public-bucket-exposure playbook. Generic IR plans assume a host to isolate; cloud playbooks assume a principal to disable.
• Know the shared responsibility line and the provider's IR process. Know what you can investigate yourself, what you must request from the provider, and how to open that request fast. The cloud provider is part of your response team for anything below the responsibility line.
• Rehearse with tabletops. Run a cloud-specific scenario (key leak, cryptomining, data exfiltration from a bucket) before the real one, so the team learns the API-driven response without the clock running.

The pattern is the same as on-prem IR, where preparation buys the speed that decides the cost of a breach. The cloud just front-loads more of it, because the evidence and the access have to exist before the incident starts.

Cloud IR versus traditional IR: a summary

Both run the same lifecycle and reward the same preparation. The difference is that cloud IR moves the fight from hardware and network to identity and API, and makes the provider a partner in the response. A team that internalizes that, and prepares the logging, access, and playbooks in advance, runs a controlled cloud incident instead of an improvised one.

Frequently Asked Questions

What is cloud incident response?

Cloud incident response is the process a team follows to detect, investigate, contain, and recover from a security incident in a public cloud environment such as AWS, Azure, or Google Cloud. It runs the standard incident response lifecycle (preparation, detection, containment, eradication, recovery, and a post-incident review) but executes each phase through provider APIs, logs, and identity controls rather than physical access to hardware.

How is cloud incident response different from traditional incident response?

The lifecycle is the same, but the execution differs in five ways: there is no physical access so forensics runs through provider APIs, infrastructure is ephemeral so evidence is destroyed quickly, identity (not the network) is the perimeter, environments can be spun up by anyone outside central visibility, and the required evidence lives in provider logs that must be enabled before the incident. Containment means disabling identities and revoking credentials rather than unplugging a machine.

What log sources are used in cloud incident response?

The control-plane audit log is the backbone: AWS CloudTrail, Azure Activity Log and Entra ID logs, and Google Cloud Audit Logs record every API call and who made it. Investigations also use network flow logs (VPC Flow Logs, NSG flow logs), resource and data-plane logs (S3 access logs, storage logs), and detection services like GuardDuty, Microsoft Defender for Cloud, or Security Command Center. Most of these are opt-in, so they must be enabled and retained before an incident.

How do you contain a threat in the cloud if you cannot unplug the machine?

You contain through identity and configuration. Identify every compromised principal (leaked keys, created IAM users, assumed roles, stolen session tokens), revoke and disable that access including active sessions, preserve evidence with snapshots before deleting anything, hunt for persistence such as backdoor users or modified trust policies, and isolate affected resources with restrictive security groups instead of terminating them. The order matters: preserve evidence before eradication destroys it.

Why is identity the perimeter in cloud incident response?

Because there is no network boundary to defend in the same way. A cloud attacker operates as a security principal using a leaked access key, an over-permissioned role, or a stolen token, and that identity works across regions and services regardless of network position. Containment therefore targets the identity (disabling principals and revoking credentials) rather than the network, which is why credential and access controls are the first lever in a cloud response.

How do you prepare for a cloud security incident?

Enable and centralize logging (CloudTrail, flow logs, access logs) with deliberate retention before any incident, pre-stage break-glass investigation roles in every account, maintain a continuous cloud asset inventory, write cloud-specific playbooks for scenarios like key leaks and bucket exposure, understand the shared responsibility line and the provider's IR request process, and rehearse with cloud tabletop exercises. Most of what you need during a cloud incident cannot be created once it has started.

The bottom line

Cloud incident response runs the same lifecycle as any incident response, but the cloud rewrites every step. There is no machine to unplug, the infrastructure tears itself down before you arrive, identity is the perimeter, and the evidence lives in provider logs you had to enable in advance. Containment is an API-driven sequence (find the compromised principals, revoke access, preserve evidence, hunt persistence, isolate resources) executed against the control plane rather than a network cable.

The deciding factor is preparation, and more of it has to happen before the incident than on-prem. Logging that was never enabled cannot be enabled retroactively, access that was not pre-staged costs the hours that matter most, and accounts nobody knew about cannot be defended. The teams that handle cloud incidents calmly are the ones that turned on the logs, staged the access, wrote the playbooks, and rehearsed the scenario while it was still quiet.