CONCEPT Cited by 1 source
Architectural Isolation¶
Definition¶
Architectural isolation is the multi-tenant security posture where tenants do not share the plane on which unencrypted data and credentials live — dedicated compute (own servers / VMs), dedicated networking (own VPC), and no shared unencrypted-data process or shared admin plane. Shared utilities (metrics, billing, orchestration) remain — but with explicit firebreaks such that a compromise at the shared layer does not flow to any tenant's data plane.
MongoDB's framing against the shared-walls alternative:
"In most cloud database service offerings, you're sharing walls with strangers. Shared walls hurt performance, they leak failures, and sometimes they leak secrets. We minimize shared walls, and where utilities must be shared, we build firebreaks."
"With a MongoDB Atlas dedicated cluster, you get the whole building. Your cluster runs on its own provisioned servers, in its own private network (VPC). Your unencrypted data is never available in a shared VM or process. There are no 'noisy neighbors' because you have no neighbors. The attack surface shrinks dramatically, and resource contention disappears. The blast radius of a problem elsewhere stops at your door."
(Source: sources/2025-09-25-mongodb-carrying-complexity-delivering-agility)
Three load-bearing claims¶
MongoDB's dedicated-cluster framing attaches three distinct wins to architectural isolation, all cashed against the shared-wall baseline:
- Blast-radius containment. A VM escape, a memory-safety bug in a co-tenant's process, or a misconfigured shared orchestrator is bounded to one tenant's box. The boundary is structural (hardware / network), not application-level.
- Noisy-neighbor elimination. Co-tenant workloads can't contend for CPU, memory, network, or IO with your workload because there are no co-tenants. The performance isolation is therefore structural — not a QoS promise the scheduler has to enforce under contention.
- Secret-leak containment. Unencrypted data and credentials live on a process / VM no other tenant's code can reach; a shared hypervisor or side-channel attack against a co-tenant has no co-tenant to attack from.
The post's "anti-Vegas principle" captures all three: "what happens outside your cluster will stay outside."
Placement on the isolation spectrum¶
Isolation is a range, not binary. Typical mainstream offerings sit at different points:
| Level | Example | Sharing surface |
|---|---|---|
| Shared process | Many SaaS trials; multi-tenant Redis tiers | OS, memory, process — every request touches shared state |
| Shared VM / container host | Most "serverless DB" free tiers | OS kernel, hypervisor, network — ring-fenced by accounts |
| Dedicated VM, shared hypervisor / fabric | AWS dedicated instance on shared tenancy | Hardware + some network fabric |
| Dedicated cluster with own VPC (MongoDB Atlas dedicated) | — | Only admin / metrics control plane via firebreaks |
| Account-per-tenant | ProGlove's 6,000-account AWS model | Partition-root only; each tenant's entire AWS footprint is its own account |
| Partition / sovereign | AWS GovCloud / China partitions | Nothing; even the IAM tenant root is partition-scoped |
Architectural isolation in the MongoDB sense is the "dedicated cluster with own VPC" rung — a deliberately named step above "dedicated VM shared fabric."
Firebreaks for shared utilities¶
The post acknowledges some sharing is unavoidable — metrics collection, billing, orchestrator control plane. Firebreak design primitives in the wider wiki:
- Data isolation at the shared layer. A shared metrics-ingestion path tags every sample with a tenant ID and enforces server-side filtering; no operator can aggregate across tenants without a distinct break-glass path (concepts/observability).
- Different identity root for admin plane. Tenant application credentials must never grant anything in the admin plane; the admin plane uses a separate IDP / RBAC scope (see patterns/self-service-block-approval).
- Separate audit log, separate retention. The audit plane is a sibling firebreak to the data plane — concepts/detection-in-depth.
Failure modes¶
- Dedicated cluster, shared fabric. A "dedicated" tier that still terminates traffic on a shared load balancer or stores backups in a shared pool moves the isolation boundary elsewhere — and the attacker with it. Verify the blast radius claim end-to-end, not at the VM boundary only.
- Firebreak drift. Over time, convenience features punch holes ("let's stream tenant events to a shared analytics cluster"); each hole is a shared wall the original claim didn't price. See sources/2026-01-15-github-when-protections-outlive-their-purpose for the sibling framing (controls outliving their purpose).
- Per-tenant cost vs isolation trade. Dedicated-cluster pricing is higher than shared tiers; small customers may get pushed to shared tiers by cost, which means the architectural-isolation claim applies to part of the fleet only. Document the tier boundary.
Seen in¶
- sources/2025-09-25-mongodb-carrying-complexity-delivering-agility — canonical wiki source; the "you get the whole building" framing of MongoDB Atlas dedicated clusters + the shared-walls critique + the anti-Vegas principle.