Defense in depth: how many isolation layers do you actually need?

The question I get asked the most by enterprise architects looking at a multi-tenant platform is some variation of "how many layers of isolation should we have." It's usually phrased as a request for a list. Network. Namespace. Database. Row-level security. Tenant-id-in-every-query. Per-tenant encryption keys. Sometimes per-tenant KMS roots. Sometimes per-tenant VPCs. The list goes on, and the implicit assumption is that more is better, each new layer another firebreak between a bug and a breach.

I've built platforms with two layers. I've built them with five. I've audited a few that had eight. The eight-layer ones are not safer. They are slower, more expensive to reason about, and (this is the part that hurts) they routinely have undetected gaps that the two-layer ones don't, because nobody on the team can hold the whole picture in their head and the audit becomes a ritual instead of an exercise.

The honest answer is that there is a right number for your threat model and your audit obligations, and it is almost always smaller than instinct says. The discipline is figuring out what each layer actually protects against, where two layers overlap, and where the real seams live. Then you build to the threats, not to the catalog. The starting point of the series, the 2x cost shape of multi-tenant, is the backdrop. Every isolation layer is more of that 2x. Some earns its keep. Most doesn't.

What each layer actually protects against

The catalog only makes sense if you label what each entry is for. So before any sizing argument, the layers, with the threat each one actually addresses.

Network isolation, separate VPCs, subnets, security groups, mTLS between services. Protects against an attacker with network access to one tenant's traffic from reading another tenant's traffic. Mostly relevant when tenants share network paths and at least one is hostile or compromised. In a SaaS where everything runs inside one VPC behind the same load balancer, network isolation between tenants is usually theatre.

Namespace isolation. Kubernetes namespaces, separate object storage prefixes, per-tenant queues. Protects against application-layer bugs that would otherwise let one tenant's process touch another tenant's resources by name collision or default permissions. Useful when the runtime is shared and the code addresses resources by string identifiers.

Row-level security. Postgres RLS policies enforced by the database, with a session variable carrying the tenant. Protects against the application forgetting to add WHERE tenant_id = ?. The exact failure mode I covered in the migration piece, where the application check is primary and RLS is the safety net underneath.

Tenant-id-in-every-query, the application-layer convention where every query, cache lookup, and external call carries a tenant ID and refuses to proceed without one. Protects against the human failure mode, the PR that forgot the scope, the new endpoint that didn't inherit the middleware. First line of defense, not the last.

Per-tenant encryption keys, each tenant's data at rest is encrypted with a key distinct from every other tenant's. Protects an attacker who exfiltrates bulk storage from being able to decrypt more than one tenant's data without compromising more than one key. Also enables cryptographic deletion (burn the key, the data is unreadable) which is a real compliance feature when a tenant offboards.

That's the catalog. Five real layers, covering the design space ninety-five percent of platforms operate in.

Where the layers overlap

Now the part the catalog hides. These layers are not orthogonal. They overlap, sometimes substantially, and adding the second copy of a defense the first copy already provides costs you complexity without buying you safety.

The biggest overlap: tenant-id-in-every-query and row-level security protect against the same root failure (an under-scoped read), at different layers. RLS catches what the application layer missed. The application layer emits a much more useful error than RLS does. These two are a real pair, application primary, RLS safety net, catching the refactor that moves a query into a code path bypassing the middleware. Both earn their keep.

But adding a third on top, say, a query-rewriting proxy that injects tenant_id filters at parse time, is almost always a mistake. Three places where scope can be added, three places where a refactor can subtly bypass it, three places to audit when something goes wrong. Complexity grows multiplicatively. Safety grows by the slimmest margin.

The second overlap: network isolation and namespace isolation both address "what can one tenant's runtime touch belonging to another." If the runtime is hard-isolated by network, namespace isolation inside each VPC is belt and suspenders for a threat the network already eliminated. If everything runs in one shared cluster, namespace isolation is the actual defense and "network isolation" between namespaces is a sticker on a security questionnaire.

The third overlap, less obvious: per-tenant encryption keys and backup access policies protect against the same bulk-exfiltration scenario. If your backup system reads with a key that can decrypt every tenant's data, your per-tenant keys aren't doing what they look like they're doing. Lots of teams ship per-tenant keys and quietly route backups through a service account that holds them all.

The pattern: every additional layer is only valuable if it covers a threat the prior layers don't, and "doesn't cover" has to be true under realistic operational conditions, not in a perfect-world security architecture diagram.

Where the real seams are

The seams (the points where data actually crosses between tenants) are where isolation effort earns the most. They are also, in my experience, where teams under-invest, because the catalog-driven approach spreads budget evenly instead of concentrating it on the seams. The ones I've seen leak data, in rough order of frequency:

The shared cache. Redis, memcached, an in-process LRU. The application stores user:42:profile without a tenant prefix, and tenant A's user 42 evicts tenant B's user 42, or worse, reads it. Four-of-the-last-six tenant-isolation incidents I've watched were cache-key collisions. None of the five-layer catalogs from those teams listed "cache key namespacing" as a layer.

The shared search index. Elasticsearch, Meilisearch, a vector DB. One index, filter-by-tenant at query time, one wrong copy-paste from a leak that scrolls across everything. The fix, separate index per tenant, routing key per tenant, or a query gateway that enforces the filter, is real work, and sits below the catalog's notice.

The shared async worker. Jobs from all tenants through the same workers. The worker pulls a job and somewhere in processing it makes a database query without the tenant context because the worker forgot to set the session variable. RLS catches some; some gets through.

The observability backend. Logs, metrics, traces, co-mingled by default, with access controls usually weaker than the application's. The audit isolation cost from the opening piece in this series lives here.

The support tooling. The internal admin UI that lets a support engineer view tenant data. Often a thin wrapper over the same database with RLS bypassed because "it's internal." Sometimes the only place one human can see across tenants without an explicit cross-tenant decision being recorded.

If I have a finite isolation budget, I spend it on the seams. Tenant-prefix every cache key. Separate the search indexes or wrap the query gateway. Set the session variable on worker startup with a hard refusal to process a job without a tenant. Tenant-shard the log streams. Build support tooling as its own audited code path with the same enforcement primitives the application uses, the policy bundles included. That is where data moves between tenants. That is where the layers earn their cost.

Sizing to the threat model

The threat model question I ask before adding any layer: what attacker am I defending against, and what is their realistic capability inside the system?

A tenant with malware in their browser is a different threat than a tenant whose admin credentials were compromised. Both differ from a tenant with code execution on a shared application server. Different again from an insider on the platform team. Different again from a nation-state with persistent network access.

Most platforms I've audited claim to defend against all of those threats. None of them actually do. The five-layer architectures usually defend against the lowest-tier threat (a buggy application leaking between tenants) with five layers, while having no real answer for the higher-tier threats, an insider with database access, a compromised support engineer.

The disciplined version: pick the threat tier you actually need to defend against (driven by who your customers are, what their auditors ask, what your SLAs say) and build the layers that defend against that tier honestly, with the seams covered. Not a buffet. Targeted defense.

For most B2B SaaS with mid-market customers, the right threat tier is "buggy application code" plus "compromised tenant credentials." The right isolation set: application-layer tenant scoping with RLS underneath, namespace isolation in a shared cluster, tenant-prefixed caches and shard-routed indexes, audit-isolated logs, and a support tool with explicit cross-tenant decision records. Three real layers plus seam coverage. No per-tenant VPCs. No per-tenant KMS. No four flavors of redundant scoping middleware.

For platforms with regulated enterprise customers (banks, hospitals, anyone whose auditor asks the second-order question) add per-tenant encryption keys with a story about who can decrypt what, and the cryptographic-deletion guarantee that comes with it. Fourth layer, and it earns its cost in the contract negotiation alone.

For customers whose threat model includes a hostile co-tenant or a state-level adversary, you probably aren't running multi-tenant in the SaaS sense. Single-tenant per customer, separate deployment, separate cloud account. The "shared but isolated" catalog stops mapping to the threat. Stop trying to make it.

The honest framing

Defense in depth is a real principle. It has also been used to justify architectural sprawl, because nobody ever got fired for adding another layer, the cost shows up in latency and complexity, which spread out, while the benefit shows up in security review slides, which are concrete.

The disciplined question isn't "what layers can we add." It is "what threats are we defending against, what does each layer buy us against those threats, where do the layers overlap, where are the seams the catalog ignores, and what is the smallest set that covers the threat model honestly."

The disciplined answer is usually fewer layers than instinct says, and the layers you keep are sized, named, audited, and sitting on top of seam coverage the catalog-driven version usually skipped. Less surface to mis-configure. Less surface to audit. Less surface that decays in year three when the team that built it has rotated. The same shape as everywhere else in this series: pay deliberately, refuse to add layers because they sound prudent, put the budget where the data actually crosses.

, Sid