I'm building a multi-tenant events platform on AWS. Each tenant currently uses a platform subdomain such as tenant.stage.example.com. The React frontend is stored in S3 and served through CloudFront, while the application determines which event to render from the request hostname. API traffic goes through a separate fixed domain, so custom domains are only needed for the static frontend.
Customers now want to use domains such as portal.clientbrand.com. I need TLS certificates to be issued and renewed automatically without manual work for each customer. I'm considering automating CloudFront distributions and ACM certificates, using CloudFront SaaS Manager, running Caddy with on-demand TLS, or using a managed custom-domain provider.
The expected scale is a few hundred domains over time, possibly more later. Has anyone shipped CloudFront SaaS Manager or a similar setup in production? What provisioning, DNS validation, pricing, or apex-domain issues should I expect? Since the custom domain only serves static content and the API remains on a fixed hostname, would Caddy be unnecessary complexity? I'd also appreciate experiences with manually automating CloudFront and ACM, especially from anyone who later wished they had chosen another approach.
4 Answers
A managed edge platform with SaaS custom-hostname support is probably the lowest-risk option. We’ve used Cloudflare for SaaS in production for years across multiple businesses and it has worked well. It costs more than operating the pieces yourself, but certificate issuance, renewals, routing, and tenant onboarding are already solved.
CloudFront SaaS Manager seems like the natural fit if you want to stay entirely within AWS, but pay close attention to apex-domain support. If customers need to point the bare domain directly at you rather than using a subdomain, you may need an Anycast IP, which can add roughly $3,000 per month. Requiring customers to use an ALIAS, ANAME, or provider-specific flattening record—or redirecting their apex domain to www—can avoid that cost, depending on their DNS provider.
The fact that your custom hostname only serves static S3 content makes this much easier and cheaper than a setup where the origin routes API requests by the Host header. S3 does not care about the incoming host in the same way an API gateway or application router might. Keep the API on its fixed domain, and you can focus custom-domain automation on certificate provisioning, hostname mapping, tenant lookup, and CDN caching. For a few hundred domains, CloudFront automation may be perfectly reasonable; SaaS Manager or a managed provider becomes more attractive if reducing operational work matters more than minimizing cost.
Caddy can handle this surprisingly well, even at much larger scale. One setup serving around 2,000 actual sites runs comfortably on a small instance. Use on-demand TLS with an allowlist or an ask endpoint so arbitrary hostnames cannot consume your certificate rate limits. It also helps to have the proxy serve only the HTML shell and keep static assets on a separate CDN hostname. Organizing the S3 content by domain makes onboarding straightforward without constantly rewriting the proxy configuration.
We generally require an ALIAS-style record, although different DNS providers call it ALIAS, ANAME, or CNAME flattening. That avoids needing a dedicated Anycast IP in many cases.