Cloud Networking for SaaS: Multi-Tenant Architecture Guide

SaaS platforms face unique networking challenges: tenant isolation, noisy neighbor prevention, custom domains, and API management at scale. This guide covers networking patterns for building secure, scalable SaaS infrastructure.

SaaS Networking Requirements

Multi-tenant SaaS platforms must balance isolation with efficiency:

• Tenant isolation: Logical or physical separation between customers
• Noisy neighbor prevention: High-usage tenant shouldn't affect others
• Custom domains: customer.example.com for each tenant
• API management: Rate limiting, authentication, versioning
• Data residency: Regional deployment for compliance
• Private connectivity: VPN/PrivateLink for enterprise customers

Multi-Tenant Isolation Models

Pool (Shared Everything)

All Tenants → Shared ALB → Shared App Servers → Shared Database

Isolation: Application-level only (tenant_id in queries)
Cost: Lowest
Security: Moderate (logical isolation only)

• Single shared infrastructure for all tenants
• Isolation enforced at application layer
• Most cost-effective, but highest noisy neighbor risk

Silo (Dedicated Everything)

Tenant A → VPC A → App A → DB A
Tenant B → VPC B → App B → DB B
Tenant C → VPC C → App C → DB C

Isolation: Network-level (VPC)
Cost: Highest
Security: Maximum (full isolation)

• Separate VPC per tenant
• Complete network isolation
• Highest cost, but required for some enterprise/compliance

Bridge (Hybrid)

Standard Tenants → Shared VPC → Shared Resources
Enterprise Tenants → Dedicated VPC → Dedicated Resources

Balance of efficiency and isolation

• Shared infrastructure for standard tier
• Dedicated resources for enterprise/high-security tenants
• Common pattern for tiered SaaS pricing

API Gateway Architecture

Gateway Functions

• Authentication: Validate API keys, JWT, OAuth
• Rate limiting: Per-tenant and per-endpoint limits
• Routing: Direct to appropriate backend services
• Transformation: Request/response modification
• Analytics: Usage tracking for billing

Gateway Options

• AWS API Gateway: Managed, integrated with Lambda, usage plans
• Kong: Open source, extensible, self-managed or cloud
• Apigee: Enterprise features, analytics, monetization
• Custom (NGINX/Envoy): Maximum control, more operational burden

Rate Limiting Strategies

# Tiered rate limits by plan
Free:       100 requests/minute
Pro:       1000 requests/minute  
Enterprise: Custom SLA

# Per-endpoint limits
/api/v1/search:     60/minute (expensive)
/api/v1/users/{id}: 600/minute (lightweight)

Custom Domains and SSL

Wildcard vs. Per-Tenant Certificates

• *.app.example.com: Single wildcard cert for subdomain tenants
• tenant.com (vanity): Requires per-tenant certificate

Automated Certificate Provisioning

# Flow for custom domain setup:
1. Tenant adds custom domain in dashboard
2. Validate domain ownership (DNS TXT record)
3. Request certificate (ACM, Let's Encrypt)
4. Create/update ALB listener rule with certificate
5. Tenant updates DNS CNAME to your endpoint

Implementation Options

• Cloudflare for SaaS: Managed custom hostname SSL
• AWS ACM + ALB: Up to 25 certs per ALB (can increase)
• Let's Encrypt + certbot: Automated, free, self-managed

Enterprise Private Connectivity

Why Private Connectivity?

• Enterprise customers require traffic stay off public internet
• Compliance requirements (HIPAA, financial)
• Security team mandates for SaaS vendors

AWS PrivateLink

Your VPC                        Customer VPC
┌─────────────┐                 ┌─────────────┐
│ NLB + VPC   │◄───────────────►│ VPC Endpoint│
│ Endpoint    │  PrivateLink    │             │
│ Service     │                 │             │
└─────────────┘                 └─────────────┘

Traffic never leaves AWS network

VPN Options

• Site-to-Site VPN: Connect customer network to your VPC
• Client VPN: Individual user access
• SD-WAN integration: For customers with Zscaler, etc.

Global Deployment

Regional Strategy

• Data residency: EU data in EU region for GDPR
• Latency: Deploy near user concentrations
• Tenant assignment: Route tenant to appropriate region

DNS Routing

# Tenant-specific DNS resolution
tenant1.app.example.com → us-east-1
tenant2.app.example.com → eu-west-1
api.app.example.com → geolocation routing

Cross-Region Data

• Single-region primary: Simpler, tenant assigned to one region
• Multi-region: Active-active with distributed database
• Data sync: Only if tenant operates in multiple regions

Security Architecture

Network Segmentation

VPC: 10.0.0.0/16
├── Public Subnets (ALB, NAT GW)
│   └── Security Group: Allow 443 from 0.0.0.0/0
├── Private Subnets (App Tier)
│   └── Security Group: Allow from ALB SG only
├── Data Subnets (Database)
│   └── Security Group: Allow from App SG only
└── Management Subnet (Bastion, if needed)
    └── Security Group: Minimal access

Zero Trust Principles

• Services authenticate every request
• Network location doesn't imply trust
• Least privilege access for all components
• Encrypt everything (mutual TLS between services)

Tenant Data Protection

• Encryption at rest: Per-tenant KMS keys for highest isolation
• Encryption in transit: TLS 1.3 everywhere
• Access logging: Audit trail for all data access

Observability

Per-Tenant Metrics

• Request rate: Identify active/growing tenants
• Error rate: Tenant-specific issues
• Latency: P50/P95/P99 by tenant
• Usage: For billing and capacity planning

Tagging Strategy

# Every metric includes:
tenant_id: "tenant-123"
environment: "production"
region: "us-east-1"
service: "api-gateway"

Key Takeaways

• Choose isolation model based on security requirements and cost
• API gateway handles authentication, rate limiting, and routing
• Custom domains require automated certificate management
• Enterprise customers often require PrivateLink or VPN
• Instrument per-tenant metrics for observability and billing