Blast Radius

Blast radius is how much is affected when one thing goes wrong — one component fails, one configuration is mistaken, one release is bad. It is a property of how a system is divided, which means it is decided long before the incident that reveals it.

The idea has a precise form in AWS’s Well-Architected guidance, which defines the thing that limits the radius: “fault isolated boundaries restrict the effect of a failure within a workload to a limited number of components. Components outside of the boundary are unaffected by the failure.” And the metaphor is older than computing — the pattern “comes from the concept of a bulkhead in a ship, where vertical partition walls subdivide the ship’s interior into self-contained, watertight compartments,” so that “bulkheads reduce the extent of seawater flooding in case of damage.”

The arithmetic is what makes it a design target rather than a sentiment. In a workload divided into independent cells, “if a workload uses 10 cells to service 100 requests, when a failure occurs in one cell, 90% of the overall requests would be unaffected by the failure.” Compare the undivided case, where “in the event of a failure, or a change in the application, 100% of customers would be impacted.” Same failure, two orders of outcome, and the difference was decided by an architecture decision.

What actually sets the radius

The radius is set by what is shared, because shared things have shared fate. Five categories cover most real systems, and the useful exercise is to answer each one for your own.

• Shared state. One database, one queue, one cache that everyone reads. Cells avoid this by construction: each one “is independent, does not share state with other cells, and handles a subset of the overall workload requests.”
• A shared control plane. Whatever schedules, routes or admits work for everyone. It is usually the least redundant part of a platform and the easiest to overlook, because it is not on the request path until it is.
• Objects that cannot be partitioned. Configuration that exists once for the whole system and applies to everybody.
• A shared kernel or host. Processes that share a machine share its failure modes and its resource ceiling.
• Shared identity and permissions. A credential or role that reaches everything makes any compromise of it a whole-system event, regardless of how the compute is divided.

The third category is the one people discover late, and Kubernetes makes a good concrete example. Namespaces partition most things, but namespace isolation “doesn’t apply to Kubernetes resources that can’t be namespaced, such as Custom Resource Definitions, Storage Classes, and Webhooks” — a list read in September 2026 and liable to grow. Read that as a risk register: a custom resource definition is a schema everyone shares, a storage class is a default that quietly decides whether disks survive, and an admission webhook is configured cluster-wide, so a single team can register one whose reach is far wider than its own namespace. How wide is a matter of configuration rather than of the object being cluster-scoped: a webhook intercepts only the operations, resource types and objects its rules and selectors match, and what happens when it is unreachable is decided by its failure policy. A narrowly matched webhook that fails open breaks little; one matching every resource with a policy of failing closed can stop every other team from deploying anything, and that combination is the thing worth finding in a review. The documentation’s own phrase for this class of problem is “uncontrollable blast radius of policy misconfigurations.”

Note also what a boundary does not cover. Giving each tenant its own control plane fixes the shared-object problems and nothing else: “per-tenant control planes do not solve isolation problems in the data plane, such as node-level noisy neighbors or security threats. These must still be addressed separately.” Two mechanisms that protect different planes are not redundancy.

Failure radius and change radius

Two different questions travel under the same phrase, and separating them prevents a lot of muddled planning.

	Triggered by	Bounded by
Failure radius	A component breaking, a dependency going away, a host dying	Fault isolation boundaries — what state, control plane and hardware are shared
Change radius	A deployment, a configuration edit, a platform upgrade	How gradually you can apply it, and whether you can reverse it

The same boundaries serve both, which is the quiet argument for building them. The AWS guidance points this out directly: when “provisioning a new customer or tenant, or applying a workload change, you can do this gradually, compartment by compartment, or in other words, isolation boundary by isolation boundary.” That is the logic behind a canary deployment and behind keeping a rollback that has actually been rehearsed. Notably, boundaries also contain the failures that are hardest to engineer around otherwise: “failure types that otherwise are hard to contain, such as unsuccessful code deployments or requests that are corrupted or invoke a specific failure mode” — a bad request that kills whatever processes it will kill one cell’s worth of capacity rather than all of it.

Dividing a workload requires a line to divide it along: “the overall workload is partitioned by a partition key. This key needs to align with the grain of the service, or the natural way that a service’s workload can be subdivided with minimal cross-cell interactions.” When no such key exists — when every request touches every tenant’s data — the cost of partitioning is a rewrite, not a deployment change, and that is worth knowing before promising a smaller radius.

It cannot be read off an incident

This is the part most often got wrong. An outage that stayed small because the failing component happened to be idle at three in the morning tells you nothing about your boundaries. An outage that was caught in four minutes by an alert tells you about your detection, not your radius. Blast radius is a property of the architecture, not an outcome of the last event — and describing a narrow escape as a small blast radius is how a known single point of failure survives a review.

The question that can be answered on a whiteboard, before anything fails, is: which shared component would have to fail for every user to notice? Write the list. If it is short and each item is understood, you have a design. If nobody can produce it, the radius is whatever it turns out to be.

And the honest cost, since isolation is not free. More boundaries means more units to provision, patch, monitor and pay for; interaction across boundaries becomes something you have to design rather than assume; and the routing layer that presents “a single endpoint to clients” is itself shared. The Kubernetes guidance frames the trade-off the same way when considering a cluster per tenant: “the benefit of stronger tenant isolation must be evaluated against the cost and complexity of managing multiple clusters.” The right radius is a decision, not a maximum to pursue.

Neighbouring terms

Term	What it describes
Blast radius	How far the effect of one failure or change reaches
Partial failure	That some parts of a system are failing while others work — the condition that makes a radius meaningful
Noisy neighbour	One specific mechanism by which a radius grows: contention over a shared resource
Workload isolation	The practice of separating workloads so their radii do not overlap

Partial failure is the normal condition of any distributed system; the only design question is how partial. For a worked example of computing the radius on a platform where tenants share a control plane, see There Is No Deny Rule, and for the cluster-wide mechanism that most often surprises people, multi-tenancy.

References, read September 2026: AWS Well-Architected: Reducing the Scope of Impact with Cell-Based Architecture; Kubernetes: Multi-tenancy; Kubernetes: Dynamic Admission Control (for what a webhook matches and what its failure policy does).