Blast Radius

Blast Radius describes the potential impact of a security incident. A compromised IAM user with "Action": "*", "Resource": "*" has an unlimited blast radius: the attacker can do anything in the account. A Lambda function with read-only access to one DynamoDB table has a tiny blast radius.

Reducing Blast Radius

• Least privilege: narrow permissions limit what a compromised identity can do
• Multi-account: separate accounts isolate workloads so a breach in one does not affect others
• Network segmentation: private subnets and security groups limit lateral movement
• Temporary credentials: short-lived credentials expire, limiting the attack window
• Permission boundaries: cap the maximum possible permissions

The useful mental exercise is to pick any single credential, role, or workload in your environment and ask: if this exact thing were fully compromised right now, what is everything the attacker could reach? The honest answer to that question, repeated across your estate, is your blast radius map. Most teams that do this exercise for the first time discover that a handful of identities, usually CI/CD roles, admin break-glass users, and old service accounts, can each reach nearly everything.

How It Goes Wrong in Practice

The canonical blast-radius disaster is a web application with a server-side request forgery (SSRF) flaw running on an EC2 instance whose role carries far more permission than the app needs. The SSRF lets the attacker reach the instance metadata service and steal the role's temporary credentials; from there, the damage is defined entirely by what that role can do. If the role follows least privilege, the attacker gets access to one application's data, which is bad but bounded. If someone attached a broad policy years ago "to make it work", the attacker inherits the account: they can read every S3 bucket, snapshot databases, create IAM users for persistence, and pivot into anything the account trusts. The application vulnerability was identical in both scenarios; the incident severity was decided months earlier by an IAM decision. The same amplification pattern shows up with flat single-account architectures, where development, staging, and production share one account and one compromise anywhere becomes a compromise everywhere, and with shared admin roles that dozens of humans and pipelines can assume. Defenses that shrink the radius are boring and cumulative: scope every role to its workload, require IMDSv2 on instances, split environments into separate accounts under Organizations with SCP guardrails, and give credentials the shortest practical lifetime.

Practical Check: Measure What a Principal Can Actually Do

You do not have to guess at a role's blast radius; simulate it. The IAM policy simulator evaluates a principal's full policy set against specific actions without executing anything:

aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:role/webapp-role --action-names iam:CreateUser s3:GetObject ec2:RunInstances kms:Decrypt

Each action comes back with an EvalDecision of allowed, explicitDeny, or implicitDeny. Feed it the dangerous actions you care about (IAM mutations, data reads, compute launches, KMS usage) for your most exposed roles, and you get a concrete, repeatable answer to "what happens if this role is stolen". Pair that with IAM Access Analyzer findings for resources shared outside the account, and review both whenever an incident tabletop exercise asks the blast-radius question.

Frequently Asked Questions

Is blast radius only about IAM permissions?
No. Permissions define the identity dimension, but network reachability, account boundaries, and data replication all contribute. A tightly scoped role in a flat network can still enable lateral movement; a broad role in an isolated account stops at the account edge. You reduce blast radius by layering these boundaries, which is the practical meaning of defense in depth.

Does a multi-account strategy really matter if IAM is done well?
Yes. An account is the strongest isolation boundary AWS offers: cross-account access exists only where a trust policy explicitly grants it, and SCPs can cap what entire accounts can ever do. IAM mistakes are inevitable at scale, and account boundaries are what keep a single mistake from being global.

What is the fastest blast-radius win for a small team?
Kill long-lived broad credentials. Replace access keys with roles, scope your CI/CD and application roles to their actual needs, and require IMDSv2. Those three changes convert the most common real-world attack paths from account takeover into contained incidents, at near-zero infrastructure cost.