Multi-tenancy in Cloud: Principles

Multi-tenancy is the foundation of SaaS. Instead of deploying a separate instance for each customer, you share infrastructure across tenants. Done right, it reduces cost per tenant by 10-50x compared to single-tenant deployments. Done wrong, one tenant's spike takes down everyone else.

This post covers the core principles of multi-tenant architecture, isolation models, data partitioning, and the noisy neighbor problem.

Isolation Models

Silo (Per-Tenant Resources)

Each tenant gets dedicated compute, database, and cache. Complete isolation. No noisy neighbor risk. But cost scales linearly with tenants — impractical for thousands of small tenants.

• When to use: enterprise customers with strict compliance (HIPAA, SOC2), custom SLAs, or data residency requirements
• AWS implementation: separate AWS accounts per tenant (via AWS Organizations), or separate VPCs/ECS clusters within one account

Pool (Shared Resources)

All tenants share the same compute, database, and cache. Isolation is enforced at the application level (tenant_id in every query). Lowest cost per tenant.

• When to use: free tier, standard tier, high volume of small tenants
• AWS implementation: shared ECS cluster, DynamoDB tables with tenant_id partition key, shared ElastiCache with key prefixes

Bridge (Hybrid)

Mix silo and pool per resource. For example: shared compute but separate databases per tenant. Or shared everything except the largest enterprise tenants who get their own stack.

Tenant-Aware Data Partitioning

DynamoDB: Partition Key Strategy

// DynamoDB: tenant_id as partition key prefix
{
  "pk": "TENANT#acme-corp#ORDER#12345",
  "sk": "ITEM#001",
  "tenantId": "acme-corp",
  "productName": "Widget Pro",
  "quantity": 5
}

// Query scoped to tenant (enforced at service layer)
QueryRequest query = QueryRequest.builder()
    .tableName("Orders")
    .keyConditionExpression("pk = :pk")
    .expressionAttributeValues(Map.of(
        ":pk", AttributeValue.builder()
            .s("TENANT#" + tenantContext.getTenantId() + "#ORDER#" + orderId)
            .build()
    ))
    .build();

PostgreSQL: Row-Level Security

-- PostgreSQL Row-Level Security for multi-tenancy
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
    USING (tenant_id = current_setting('app.current_tenant'));

-- Set tenant context per request
SET app.current_tenant = 'acme-corp';
SELECT * FROM orders; -- Only returns acme-corp's orders

The Noisy Neighbor Problem

When one tenant's workload degrades performance for others. A tenant running a massive export job consumes all database connections, and other tenants experience timeouts.

Mitigation strategies:

• Throttling — rate-limit API calls per tenant. Use API Gateway usage plans with per-tenant API keys.
• Resource quotas — limit DynamoDB RCU/WCU per tenant using application-level token buckets.
• Queue isolation — separate SQS queues per tenant tier (priority queues for premium tenants).
• Connection pooling — limit database connections per tenant to prevent one tenant from exhausting the pool.
• Tiered scaling — auto-scale based on per-tenant metrics, not just aggregate metrics.

Tenant Context Propagation

Every request must carry tenant context. The tenant ID flows through every layer: API Gateway → Lambda/ECS → Database → Cache → Event Bus.

• JWT claims — include tenant_id in the JWT token. Extract it in middleware.
• Request context — propagate tenant_id via thread-local or request-scoped beans (Spring) or Lambda context.
• Event metadata — include tenant_id in every event published to SNS/SQS/EventBridge.

Onboarding and Provisioning

When a new tenant signs up, what resources need to be created?

• Pool model: create a tenant record in the tenant table. No infrastructure provisioning needed.
• Silo model: provision a new database, ECS service, or even AWS account. Use CloudFormation StackSets or Terraform modules for automated provisioning.
• Hybrid: create tenant record + provision dedicated database. Use Step Functions to orchestrate the onboarding workflow.

Billing and Metering

Multi-tenant systems must track resource usage per tenant for billing. Key metrics to meter:

• API call count per tenant
• Storage consumed (S3, DynamoDB) per tenant
• Compute time (Lambda duration) per tenant
• Data transfer per tenant

Publish usage events to Kinesis or EventBridge, aggregate in a billing service, and expose via a usage API.

Multi-Tenancy Anti-Patterns

• No tenant context validation — if a bug lets Tenant A see Tenant B's data, it's a catastrophic security breach. Enforce tenant isolation at every layer.
• Tenant-specific code paths — if (tenant == "acme") { ... } doesn't scale. Use feature flags and configuration, not code branches.
• Shared credentials — each tenant's integration credentials must be separate. Never share API keys or database passwords across tenants.
• No per-tenant monitoring — aggregate metrics hide tenant-specific problems. Dashboard per tenant, or at least per tenant tier.

Multi-tenancy is a spectrum, not a binary choice. Start pooled for cost efficiency, and silo specific resources as tenant requirements (compliance, performance, customization) demand it.

Conclusion

Multi-tenancy is what makes SaaS economically viable. The key decisions are isolation model (silo vs pool vs hybrid), data partitioning strategy, and noisy neighbor prevention. Start with the pool model for most tenants, offer silo for enterprise, and always enforce tenant isolation at every layer of your stack.

At TechTrailCamp, multi-tenant SaaS architecture is covered in our Cloud Architecture and AWS tracks. You'll design and implement multi-tenant systems with DynamoDB and ECS through hands-on, 1:1 mentoring.