Architecture

Tenant Isolation

The set of architectural strategies for ensuring that multiple tenants (customers, business units, or environments) sharing an S3-based lakehouse cannot access each other's data, metadata, or compute resources.

9 connections 3 resources

Summary

What it is

Where it fits

Tenant isolation is a cross-cutting concern in multi-tenant lakehouse designs. Strategies range from separate S3 buckets per tenant (strongest isolation, highest overhead) to shared tables with row-level security (weakest isolation, lowest overhead), with prefix-based IAM policies as a middle ground.

Misconceptions / Traps

S3 prefix-based IAM policies provide namespace isolation but not performance isolation. One tenant's heavy LIST or GET workload can cause throttling that affects co-tenants on the same prefix partition.
Row-level security for tenant isolation depends entirely on the query engine enforcing the filter. Any bypass (direct S3 access, misconfigured engine) breaks tenant boundaries.
Shared Iceberg catalogs across tenants mean that catalog metadata operations (commit, list tables) are shared. Catalog contention from one tenant can affect all tenants.

Key Connections

scoped_to Lakehouse, S3 — multi-tenancy in S3-based architectures
depends_on Row / Column Security — row-level filtering for shared-table tenancy
depends_on Encryption / KMS — per-tenant encryption keys for bucket-level isolation
constrains Request Amplification — per-tenant bucket designs multiply request volume

Definition

What it is

Architectural patterns for separating data belonging to different tenants in a shared S3-based lakehouse, ranging from separate buckets (hard isolation) to shared tables with row-level filtering (soft isolation).

Why it exists

Multi-tenant SaaS platforms store all tenant data on S3 but must guarantee that no tenant can access another's data. The isolation strategy affects cost, operational complexity, and the blast radius of misconfigurations.

Primary use cases

SaaS data platforms on S3, multi-tenant analytics lakehouses, data marketplace architectures.

Recent developments

Latest signals

Three canonical isolation patterns: dedicated-bucket / shared-bucket-prefix / S3 Access Points. AWS publishes three design patterns: dedicated S3 bucket per tenant (strongest isolation, scales to fewer tenants), shared bucket with prefix-based isolation (scales to thousands of tenants, weaker isolation), and S3 Access Points (per-tenant network endpoints attached to one bucket). Per AWS Storage Blog — Multi-Tenant Access Control on S3.
Token Vending Machine (TVM) pattern for SaaS tenant isolation. AWS prescriptive guidance: Lambda-based TVM generates short-lived STS credentials scoped to a single SaaS tenant's data — analogous to the credential-vending pattern used by Iceberg REST catalogs. Per AWS Prescriptive Guidance — TVM for S3 SaaS isolation.
ABAC + IAM is the structural answer for thousands-of-tenants scale. Attribute-Based Access Control (ABAC) combined with IAM lets a single policy structure scale to any practical number of tenants — the policy resolves to different effective permissions based on session tags, not per-tenant policy proliferation. Per AWS Security Blog — SaaS Tenant Isolation with ABAC + IAM.
SaaS Factory open-source reference implementation. AWS Samples published a full SaaS hands-on repo documenting partitioning approaches to store multi-tenant data on Amazon S3 — operational reference for teams designing tenant-isolation from scratch. Per GitHub — aws-saas-factory-s3-multitenancy.
Multi-tenant AI infrastructure complete design guide. Scality published a 2026 design guide specifically for multi-tenant AI infrastructure — addressing the case where tenant-isolation patterns must coexist with GPU-shared training workloads. Per Scality — Multi-Tenant AI Infrastructure Design Guide.