Blast Radius
Blast radius is how much damage a single failure or compromise can cause, measured in tenants, data, credentials, regions, or services affected.
Definition
Blast radius is the scope of impact from one failure, misconfiguration, or compromised component, expressed as the number of users, tenants, systems, or credentials affected before the damage is contained.
Context and scope
Use it when designing failure domains, reviewing privilege boundaries, and deciding whether shared infrastructure is worth the containment risk.
Common misconceptions
- Blast radius is only about availability; a credential leak can affect data without any outage
- Redundancy reduces blast radius; replicas can propagate a bad change faster
- Microservices automatically shrink blast radius; shared databases and identities often keep it large
Anti-patterns
- One shared administrator credential for every service and environment
- Pushing configuration to all regions at once with no staged rollout
- Co-locating every tenant in one cluster with one database role
Related concepts
Authoritative source
https://learn.microsoft.com/en-us/azure/architecture/patterns/deployment-stamp
Damage scope, not probability
Risk combines likelihood and impact. Blast radius isolates the impact side: if this component fails or is compromised, what breaks with it? A shared database credential, a global config push, or a single-tenant cluster all answer that question differently, even when their failure probabilities look similar.
How it works
Boundaries create blast radius. Separate AWS accounts or projects per environment limit credential reach. Cells partition tenants into independent stacks so one bad deploy affects one cell. Bulkheads isolate thread pools, connection pools, and queues so saturation stays local. Short-lived, narrowly scoped credentials mean a leaked token expires before it can be reused elsewhere.
Containment also needs operational design: staged rollouts, feature flags, and the ability to disable a region or tenant without redeploying everything. Static stability, where each region can serve independently, prevents a local failure from cascading through shared dependencies.
When to use it
Apply it whenever adding shared infrastructure, broadening a credential, or designing a multi-tenant deployment. It is also a useful review question for incident response: what is the worst thing an attacker with this access can reach?
Trade-offs
Smaller blast radius multiplies operational units: more accounts, clusters, keys, and dashboards. Isolation raises cost and complexity, and too much of it makes consistency hard. Sharing is not inherently wrong; the decision should be explicit, with compensating controls such as per-tenant encryption and strong audit.
Example and misconceptions
A SQL injection in one service uses a shared database role with access to every tenant’s schema. The blast radius is the entire platform. Scoping the role per service and enabling row-level security reduces the same bug to a single tenant’s data.
The common misconception is that redundancy equals containment. Replicating a compromised artifact or credential to every region increases the blast radius rather than reducing it.
Related concepts: Bulkhead Isolation, Tenant Isolation, and Attack Surface.