CDN for SaaS: Multi-Tenant Delivery Architecture

SaaS platforms face a CDN challenge that most websites never encounter: serving thousands of tenants, each with unique content, custom domains, and distinct performance expectations, through a single shared infrastructure. The architecture decisions you make at the CDN layer ripple through your entire delivery pipeline—from cache efficiency and SSL management to cost allocation and compliance posture. For a comprehensive overview, see our guide on CDN for E-Commerce: Speed That Converts — FlyFish NWA.

This guide walks through the patterns and tradeoffs of multi-tenant CDN architecture, drawing on real deployment experience from platforms serving 500 to 50,000 tenants. Whether you are launching your first regional expansion or migrating enterprise customers to custom domains, these strategies will help you build a delivery layer that scales with your customer base.

How Does Multi-Tenant Asset Delivery Work at the CDN Layer?

In a multi-tenant SaaS platform, every HTTP request carries an implicit question: which tenant does this belong to? The CDN must answer this before it can serve cached content, route to the correct origin, or apply tenant-specific rules.

Tenant identification methods. The three standard approaches are subdomain-based (acme.app.com), path-based (app.com/acme/), and custom domain-based (dashboard.acme.com). Each has distinct CDN implications:

Shared static assets. Framework JavaScript, CSS, and UI component assets are identical across tenants. Serve these from a shared path (e.g., /static/v2.4.1/) with content-hash filenames and a one-year Cache-Control max-age. Because the path and content are tenant-agnostic, every tenant benefits from the same cached copy, dramatically improving cache hit ratios.

Tenant-specific assets. Logos, custom themes, uploaded documents, and tenant data require isolated cache entries. Include the tenant identifier in the cache key—either naturally via the Host header (subdomain/custom domain models) or explicitly via a custom cache key rule that incorporates a tenant header or cookie.

How Do You Support Custom Domains for SaaS White-Labeling?

Enterprise SaaS customers expect to use their own domains: dashboard.acme.com instead of acme.yourapp.com. This is the most technically complex CDN requirement for SaaS, but modern providers have made it tractable.

Domain verification. When a customer adds a custom domain, your platform must verify ownership. The standard flow: generate a TXT record or CNAME value, instruct the customer to add it to their DNS, then poll for verification. Once verified, create the CDN configuration for that domain.

Automatic SSL provisioning. The CDN provisions a TLS certificate for each custom domain, typically via Let's Encrypt or a similar ACME provider. Cloudflare for SaaS, AWS CloudFront, and Fastly all support automatic certificate lifecycle management—issuance, renewal, and revocation—without manual intervention. Certificate provisioning typically completes in under 60 seconds.

Fallback certificate. During the provisioning window (or if provisioning fails), the CDN should fall back to your platform's wildcard certificate. This prevents certificate errors from blocking access during the brief setup period.

CNAME routing. The customer creates a CNAME record pointing their domain to your CDN endpoint (e.g., custom.yourcdn.com). The CDN receives the request, identifies the tenant by the Host header, and routes to the correct origin. An edge function can handle the tenant lookup by querying a KV store that maps custom domains to tenant configurations.

At scale (10,000+ custom domains), pre-warm your CDN's domain database and monitor certificate renewal failures. A single expired certificate can trigger support escalation from an enterprise customer.

What Are the Best Per-Tenant Caching Strategies?

Cache isolation between tenants is non-negotiable—serving Tenant A's data to Tenant B is a security incident. But overly aggressive isolation fragments the cache and destroys hit ratios.

Cache key design. The optimal cache key for SaaS is: Host + Path + Query (sorted) + Vary headers. Do not include session cookies, CSRF tokens, or user-specific headers in the cache key unless you are caching personalized content. See Cache Key Design for detailed patterns.

Tiered TTL strategy. Different content types within a tenant warrant different cache durations:

Stale-while-revalidate for dashboards. SaaS dashboards display data that is rarely real-time critical. Setting Cache-Control: max-age=30, stale-while-revalidate=300 means users see cached data instantly while the CDN fetches fresh data in the background. This dramatically reduces origin load during peak hours without noticeably degrading data freshness.

Cache warming for new tenants. When a new tenant provisions or a new region launches, the CDN cache is cold. Pre-warm critical paths (login page, main dashboard, key API endpoints) by sending synthetic requests from the target edge PoPs. This prevents the first real user from experiencing origin latency. See cache warming techniques for implementation patterns.

How Do Shared and Dedicated CDN Resources Compare for SaaS?

The shared-vs-dedicated decision affects performance isolation, cost structure, and compliance posture. Most SaaS platforms use a hybrid model.

The hybrid model. Self-serve and small business tenants share a CDN zone with SNI-based SSL, pooled bandwidth, and platform-managed cache rules. Enterprise tenants with contractual SLAs receive a dedicated CDN zone with isolated IP addresses, custom WAF rules, and separate log streams. The cost premium for dedicated resources (typically 2–5x per GB) is passed through in the enterprise pricing tier.

This hybrid approach lets you serve 95% of tenants at the lowest marginal cost while meeting the stringent requirements of the 5% that generate 40–60% of revenue. For the compliance dimension, refer to CDN Compliance for regulatory framework details.

What Does a Global Expansion Strategy Look Like for SaaS CDN?

When a SaaS platform expands from a single-region deployment to a global footprint, the CDN architecture must evolve to handle data residency, latency targets, and regional regulations.

Multi-origin architecture. Deploy separate application origins in each major region (US-East, EU-West, APAC-Singapore). The CDN uses geographic routing to direct each user to the nearest origin. This reduces API latency from 200–400 ms (cross-continent) to 20–50 ms (same-region). Static assets remain globally cached regardless of origin region.

Data residency enforcement. For EU tenants subject to GDPR data residency, configure the CDN to route requests only through EU PoPs and restrict cache storage to EU edge locations. Most enterprise CDN providers support geographic cache restrictions at the zone or rule level. Combine this with tenant-aware routing at the edge to enforce per-tenant data residency policies.

Regional performance baselines. Establish latency targets per region: under 100 ms TTFB for North America and Europe, under 150 ms for APAC, under 200 ms for emerging markets. Monitor against these baselines using Real User Monitoring segmented by tenant geography. When a region consistently misses its target, evaluate adding an origin or additional CDN PoPs.

Failover between regions. Configure the CDN with health checks against each origin. If US-East fails, route US traffic to US-West or EU-West. The CDN health check interval should be 10–30 seconds with a 2-of-3 failure threshold to avoid flapping. Document your failover architecture using the patterns described in CDN Architecture Patterns.

How Do You Accelerate SaaS APIs Through the CDN?

SaaS applications are API-heavy—a typical dashboard page triggers 5–15 API calls. CDN-based API acceleration reduces aggregate page load time by caching responses and optimizing the transport layer.

Cacheable API patterns. Read-heavy endpoints (dashboard widgets, report data, configuration) are prime candidates for edge caching. The key insight: even a 10-second TTL eliminates redundant origin hits when 100 users view the same dashboard simultaneously. That is 99 cache hits and 1 origin request instead of 100 origin requests.

Tenant-aware API caching. The cache key must include the tenant identifier and the authorization scope. Cache public tenant data aggressively (company profile, shared settings); cache user-specific data cautiously or not at all. Use the Vary header with a custom tenant header to maintain isolation.

Edge-level rate limiting. Protect your API from abuse and accidental DDoS by implementing per-tenant rate limits at the CDN edge. This stops abusive traffic before it reaches your origin, preserving capacity for legitimate requests. Most CDN providers support rule-based rate limiting with custom key fields (tenant ID, API key, IP).

How Do You Configure White-Label CDN for SaaS?

White-label CDN configuration goes beyond custom domains to encompass the entire delivery experience under the customer's brand.

Custom error pages. When the CDN serves a 404, 503, or rate-limit response, it should display the tenant's branded error page, not your platform's default. Store tenant-specific error pages at the edge (in a KV store or as cached assets) and inject them via edge functions.

Custom response headers. Enterprise tenants may require specific security headers (Content-Security-Policy, HSTS with custom max-age, custom X-headers). Implement these as per-tenant edge rules that the tenant configures through your platform's admin interface, which then pushes the configuration to the CDN via API. Consider infrastructure as code for managing these at scale.

Branded CDN subdomains. For tenants who want assets served from cdn.acme.com instead of your shared CDN hostname, provision a CNAME-based custom CDN domain with its own SSL certificate. The CDN treats this as another custom domain but routes to the tenant's asset storage bucket.

How Do You Allocate CDN Costs Per Tenant?

Accurate per-tenant cost allocation is essential for SaaS unit economics. CDN costs are typically 5–15% of infrastructure spend, and tenants who generate disproportionate traffic should bear their share.

Log-based metering. Stream CDN access logs to your data pipeline (via log analysis infrastructure). Each log entry contains the Host header (tenant identifier), bytes transferred, and request count. Aggregate these into daily per-tenant bandwidth and request counts.

Cost attribution formula. Total CDN cost is split into base platform cost (shared infrastructure overhead, distributed evenly) and variable cost (per-GB and per-request charges, attributed proportionally). A typical formula: tenant_cost = (base_cost / total_tenants) + (tenant_bandwidth / total_bandwidth * variable_cost).

Overage alerting. Set per-tenant bandwidth thresholds and alert both the tenant (approaching limit) and your operations team (unusual spike). CDN edge functions can enforce soft or hard bandwidth caps by returning a 429 response when a tenant exceeds their allocation, preventing a single tenant from inflating your shared CDN bill.

Understanding your overall CDN spend is the first step—see CDN Cost Optimization for strategies that reduce the total bill before you allocate it.