/SERVICES

The Classic Approach: One Distribution per Tenant or for all Tenants

The naive way to give every tenant their own domain and certificate is to create a separate CloudFront distribution per customer. It works at small scale, but:

• Every new customer means creating and managing a new distribution
• AWS has a soft limit of 200 distributions per account by default
• 300 tenants means 300 distributions to monitor, update, and keep in sync
• A change to cache behaviour, WAF configuration, or origin settings has to be applied to every distribution individually

The next step most teams take is a single distribution with wildcard certificates and CNAME aliases. One distribution, *.yoursaas.com, all tenants pointing to the same distribution. Cleaner, but with real tradeoffs.

The Problem with Wildcards and Aliases

Wildcard certificates are blunt instruments

A wildcard gives no per-tenant certificate isolation. Enterprise customers increasingly require their own certificate, not a shared wildcard.

With CloudFront SaaS, every tenant gets a dedicated ACM certificate for their subdomain. The certificate is scoped to that one (or multiple) domain(s). If a tenant leaves, their certificate goes with them. Nothing is shared at the TLS level.

Adding aliases to an existing distribution is operationally fragile

In the standard model, every new tenant means calling the CloudFront API to add an alias to the existing distribution, then waiting for a global deploy to propagate. That deploy takes time, touches the entire distribution, and means a configuration change every time a tenant onboards or offboards.

With CloudFront SaaS, a new tenant is a new resource, a aws_cloudfront_distribution_tenant in Terraform. Creating a tenant doesn't modify the parent distribution. It doesn't trigger a global propagation. The parent distribution stays unchanged; you're simply adding a lightweight tenant object that inherits its configuration. Onboarding is additive, not mutative. This concept really matters when you seperate your customers IaC state from the shared state.

resource "aws_cloudfront_distribution_tenant" "acme" {
  distribution_id = aws_cloudfront_multi_tenant_distribution.main.id
  domain          = "acme.yoursaas.com"
  # certificate, WAF override, origin path — all optional per-tenant customizations
}

Shared Configuration, Per-Tenant Overrides

The core model is: one multi-tenant distribution as a blueprint, N distribution tenants that inherit it.

The parent distribution defines everything that's shared: cache behaviours, origin routing, security headers, TLS policy. Distribution tenants inherit all of that automatically. But each tenant can selectively override:

• WAF Web ACL: swap in a different WAF configuration for tenants that need it
• TLS certificate: use a tenant-provided certificate instead of the default
• Geographic restrictions: restrict a tenant to specific countries if required
• Origin path: route a tenant to a different path on the same origin

This is what makes it genuinely useful for real SaaS platforms. Some tenants are on a basic plan and get the standard WAF ruleset. Enterprise tenants on a premium plan get a stricter WAF with additional managed rule groups, rate limiting tuned to their traffic patterns, and bot control. Both share the same parent distribution, the WAF difference is a single override on the distribution tenant resource.

Infrastructure That Scales with Your Tenant Count

In a standard distribution with aliases, your Terraform state and your CloudFront configuration grow coupled together: every tenant is an alias on the same resource. 300 tenants means one resource with 300 aliases, and every plan/apply touches that resource.

With distribution tenants, each tenant is its own isolated Terraform resource. You can:

• Onboard a tenant in isolation without touching any other tenant's configuration
• Offboard a tenant by destroying a single resource
• Manage tenants in separate state files or workspaces
• Automate onboarding via Step Functions or similar, with each step creating one resource

The operational model scales horizontally instead of growing a single resource.

Connection Groups: Isolation Without Separate Distributions

One underappreciated feature is connection groups, the routing layer that sits between distribution tenants and CloudFront's edge network.

By default, all distribution tenants share one connection group. But you can create custom connection groups and assign specific tenants to them. This is useful when:

• A tenant is under a DDoS attack and you want to isolate their routing
• An enterprise customer needs dedicated Anycast IPs
• You want to segment tenants by geography or traffic class

Isolation without the cost of a separate distribution.

When to Use Standard CloudFront

CloudFront SaaS is not the right tool for every situation. AWS explicitly recommends standard distributions for single websites or applications. If you're running one product with one domain, a standard distribution is simpler and has no downsides.

CloudFront SaaS starts making sense when:

• You're running multiple tenants with individual domains
• Tenants have different security or compliance requirements
• You need automated onboarding that doesn't touch shared resources
• Your tenant count is growing and you want operational overhead to stay flat

Conclusion

The decision to use CloudFront SaaS over standard distributions is ultimately about operational leverage. With a standard distribution, your operational complexity grows with your tenant count. With CloudFront SaaS, the parent distribution is configured once and the per-tenant overhead is a single lightweight resource.

Dedicated certificates per tenant, per-tenant WAF overrides, additive onboarding that never touches existing tenants, and a clean Terraform resource model, these aren't just nice-to-haves. For platforms serving hundreds of customers with varying requirements, they're what makes sustainable operations possible.

Building a multi-tenant platform on AWS and thinking through the edge architecture? [Get in touch.]

/INSIGHTS

Your trusted partner for Cloud Neutral Platform Managed Services