Multi-Tenant SaaS Isolation for an EU Bank
A B2B SaaS provider runs a multi-tenant analytics platform on AWS. All tenants share an Amazon RDS for PostgreSQL cluster; isolation relies on a tenant_id column enforced by the ORM. The platform serves 1,200 tenants and 40,000 users. A new enterprise customer, an EU bank, requires contractual data residency in the EU, customer-managed keys, and network isolation from other tenants. The current stack is single-region us-east-1, with a 99.9% SLA and a 200 ms p95 API latency target. The engineering team is 18 people and cannot operate a separate stack per customer. The CTO asks for a target architecture that satisfies the bank without doubling operational overhead. Legal also flags that some analytics jobs copy tenant data into a shared S3 bucket for reporting.
1. Evaluate pool, bridge, and silo tenancy models for the bank and recommend one, explaining the trade-offs in blast radius, cost, and operational complexity.
Read the worked answer
Recommendation: bridge model with a dedicated EU data plane.
- Pool (current) fails the bank's requirements: a shared RDS cluster and shared S3 bucket place the bank's data in the same trust boundary as 1,199 other tenants, and one mis-scoped query or bucket policy exposes it. Customer-managed keys alone do not provide network isolation.
- Silo (full stack per tenant) gives the strongest blast-radius reduction but is operationally unrealistic for 18 engineers; cost per tenant and patch surface would grow linearly.
- Bridge keeps the shared application tier but gives the bank a dedicated RDS for PostgreSQL instance in eu-central-1, a dedicated KMS customer-managed key, a dedicated S3 bucket with bucket keys, and dedicated subnets/security groups reachable only via PrivateLink. Tenant routing stays in the application.
This reduces data-at-rest and network blast radius for the bank while keeping compute shared. Validate EU latency against the 200 ms p95 target, cross-region backup/restore, and key-policy separation. The analytics copy to the shared S3 bucket must be removed for this tenant or isolated into the dedicated bucket with its own key.
2. Identify the trust boundaries that change when analytics jobs copy tenant data to the shared S3 bucket, and propose controls to prevent cross-tenant data exposure.
Read the worked answer
Trust boundary shift: the analytics job crosses from the tenant-scoped production data plane into a shared reporting boundary where many tenants' objects share one bucket and one key policy. The bank's data becomes readable by any principal with s3:GetObject on that bucket, and by analytics roles scoped for the old model.
Controls:
- For the bank, write analytics output to a dedicated bucket or S3 Access Point encrypted with the bank's KMS key; deny the shared analytics role access to it.
- For all tenants, replace broad bucket policies with per-tenant prefixes and S3 Access Points, and require an object tag or access-point policy condition for tenant scoping.
- Run each analytics job with a job-specific IAM role limited to its tenant input and output prefix; no wildcard s3 actions.
- Enable S3 server access logs, CloudTrail data events, and alert on cross-prefix reads.
- Classify the reporting bucket as containing tenant data and include it in the data-residency review.
Residual risk: shared compute can still process multiple tenants' data in memory. Use per-tenant job queues and avoid co-locating the bank's job with other tenants if the contract requires it.
3. What should an architecture decision record capture for this change, and which assumptions would you validate before committing?
Read the worked answer
ADR should capture: context (EU bank, residency, customer-managed keys, network isolation), decision (bridge model with dedicated EU RDS/S3/KMS/subnets), alternatives (pool, silo, per-tenant schema), consequences (cost, latency, operational runbooks, key rotation, DR), security requirements (key policy, encryption context, access reviews), and open questions.
Assumptions to validate before committing:
- EU residency covers backups, logs, and analytics copies, not just the primary database.
- The KMS key policy can deny all non-production accounts and all human roles except break-glass.
- A dedicated RDS instance does not break the shared schema migration pipeline; migrations must be applied per instance.
- Latency from EU users to eu-central-1 stays within 200 ms p95, including PrivateLink hops.
- The 18-person team can operate one more RDS instance and key rotation without new headcount.
- Legal accepts the shared application tier if data is encrypted with the bank's key and network-isolated.
If any assumption fails, the fallback is a silo for this tenant only, not a return to pool.