Skip to content

CONCEPT Cited by 3 sources

Blast radius

What it is

Blast radius is the scope of damage that a single fault — bug, misconfiguration, vulnerability, runaway workload, compromised credential — can reach before isolation mechanisms contain it. System design choices trade off blast-radius size against operational complexity and cost:

  • Smaller blast radius ⇒ safer failure modes, but more boundaries to provision/maintain/monitor.
  • Larger blast radius ⇒ simpler ops, cheaper substrate, but a single fault can affect many customers / regions / products.

The term is the concrete unit architects use when discussing isolation trade-offs: "what's the blast radius of this change?" is the design-review heuristic for rolling out anything risky.

Load-bearing in account-per-tenant isolation

One of the five benefits ProGlove cites for account-per-tenant:

"An accidental misconfiguration or vulnerability could expose multiple tenants."

…is a blast-radius framing. The AWS account boundary bounds the blast radius of any per-tenant fault to exactly one tenant's data + compute + IAM + network. In contrast, the shared-account shape makes the blast radius the whole tenant fleet. (Source: sources/2026-02-25-aws-6000-accounts-three-people-one-platform)

Named blast-radius boundaries in the wiki

Roughly ordered by decreasing size:

  1. AWS partition — sovereignty / jurisdictional boundary; concepts/aws-partition.
  2. AWS Region — availability / geographic boundary.
  3. AWS Availability Zone — DC-fault boundary.
  4. AWS account — security + quota + billing + IAM boundary. (concepts/account-per-tenant-isolation)
  5. Kubernetes cluster / EC2 fleet / service deployment — operational-unit boundary. (concepts/active-multi-cluster-blast-radius, patterns/multi-cluster-active-active-redundancy)
  6. Tenant — authorization boundary inside a shared environment. (concepts/tenant-isolation)
  7. Request — the unit a single fault might affect.

Caveats

  • Blast radius ≠ 0 is not always the goal. Making the radius smaller costs more (more accounts, more clusters, more separate fleets). The right size is set by regulatory requirements, customer commitments, and economic feasibility, not a universal "smaller is better."
  • Structural boundaries vs application-level boundaries. An account boundary is load-bearing whether or not the application is multi-tenant-aware; a per-request tenant_id check is only load-bearing if the code path actually enforces it. Structural boundaries are the ones that survive bugs.
  • Cross-boundary primitives re-introduce risk. Anything that works "across" a blast-radius boundary — cross-account IAM roles, multi-region replication, shared admin tooling — lives outside the boundary and must be hardened separately. ProGlove's explicit call-out: "Observability tooling should be centralized, but without reintroducing the very risks that accounts are meant to isolate."

Seen in

Last updated · 178 distilled / 1,178 read