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:
- AWS partition — sovereignty / jurisdictional boundary; concepts/aws-partition.
- AWS Region — availability / geographic boundary.
- AWS Availability Zone — DC-fault boundary.
- AWS account — security + quota + billing + IAM boundary. (concepts/account-per-tenant-isolation)
- Kubernetes cluster / EC2 fleet / service deployment — operational-unit boundary. (concepts/active-multi-cluster-blast-radius, patterns/multi-cluster-active-active-redundancy)
- Tenant — authorization boundary inside a shared environment. (concepts/tenant-isolation)
- Request — the unit a single fault might affect.
Related framings in the wiki¶
- concepts/active-multi-cluster-blast-radius — same concept at the service/cluster level: running services across multiple active clusters so that any single cluster failure doesn't take the whole service down.
- concepts/performance-isolation — performance-domain cousin; "how large a perf regression can one tenant cause for another?"
- patterns/cross-partition-failover — blast-radius response at the largest possible scope (partition-level human-disaster containment).
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_idcheck 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¶
- sources/2026-02-25-aws-6000-accounts-three-people-one-platform — ProGlove's primary framing for the account-per-tenant architectural choice; blast-radius containment is one of five named benefits.
- sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty — partition-level blast radius (human-disaster / geopolitical containment) addressed by patterns/cross-partition-failover.
- sources/2025-09-25-mongodb-carrying-complexity-delivering-agility — MongoDB's dedicated-cluster framing of architectural isolation is explicitly a blast-radius containment claim: "with a MongoDB Atlas dedicated cluster… the blast radius of a problem elsewhere stops at your door." The anti-shared-wall stance is a boundary-per-tenant-at-VM-and-VPC rung on the blast-radius ladder, one step below account-per-tenant.
- concepts/active-multi-cluster-blast-radius — related cluster-level shape.