A health SaaS has 400 standard clinics sharing tables and 10 hospital tenants requiring strict data isolation and per-tenant keys for compliance. A single pooled database without controls caused cross-tenant reads in testing. Which multi-tenant architecture with tenant isolation patterns meets both needs?

The hybrid design matches tiered requirements by giving the 10 hospitals silo isolation with per-tenant KMS keys to satisfy compliance-driven blast radius and encryption scope, while pooling the 400 low-risk clinics in shared tables governed by Cognito tenant context and database-enforced row-level security for economy and operational scale. Pooling all 410 tenants with row-level security alone is a standard cost-optimized SaaS pattern but violates the hospital constraint for strict physical isolation and dedicated key scope, leaving regulated workloads without required separation. Siloing all 410 tenants with dedicated keys and automation is a legitimate high-isolation pattern but contradicts the stated need to share tables for the 400 standard clinics, imposing unsustainable cost and management overhead where pooling was explicitly acceptable. Using siloed databases for hospitals with a single shared KMS key while correctly pooling clinics is a common simplification but fails the per-tenant key compliance requirement, since key sharing broadens decryption blast radius and audit scope. Exam caveat is to distinguish logical separation via row-level security from physical separation via silo plus key isolation, selecting silo only where compliance mandates it and pooling otherwise. Practical check is to verify tenant context propagation from token to RLS policy with cross-tenant query tests and to confirm per-hospital KMS key grants and inability to decrypt another silo with the wrong key.