You are adding cdn.example.com to a CloudFront distribution as an alternate domain name, but the ACM certificate you issued in eu-west-1 does not appear in the certificate list. Why, and what do you do about it?
answer
- ACM is Regional, CloudFront is not
- certificates cannot be copied between Regions
- one Region owns every CloudFront viewer cert
- N. Virginia
- wildcard must actually cover the name
basics
~10 sACM certificates are Regional, and CloudFront reads viewer certificates only from us-east-1 (N. Virginia). Request or import the certificate again in us-east-1, covering cdn.example.com, then select it on the distribution.
solid answer
~40 sCloudFront is a global service configured through the us-east-1 endpoint, and it will only attach a viewer certificate that lives in ACM in **us-east-1**. Certificates cannot be copied between Regions, so the fix is to request a new public certificate in us-east-1 for `cdn.example.com` (or import the same certificate there if it came from an external CA), validate it — DNS validation via a CNAME is the usual route — and then select it under the distribution's alternate domain names. The certificate must actually cover the name, either exactly or through a wildcard such as `*.example.com`. Note this rule is specific to CloudFront's viewer side: a certificate on an Application Load Balancer must be in that load balancer's own Region, which is why teams that copy the ALB pattern get caught here.
go deeper
Remember the single rule: a certificate for a CloudFront alternate domain name must be requested or imported in us-east-1, and certificates cannot be moved between Regions. Say it plainly rather than guessing.
Explain why — ACM is Regional while CloudFront's configuration is anchored in us-east-1 — and cover the surrounding checks: DNS validation for automatic renewal, wildcard coverage rules, and SNI as the free default versus dedicated IP.
Show that you track certificate lifecycle as an availability risk: imported certificates do not auto-renew, validation records must stay in the zone, and a distribution fronting an ALB needs certificates on both hops. Be ready to say how you monitor expiry.
Own certificate strategy across the estate: who issues, whether names are wildcard or per-service, how renewal is proven rather than assumed, and how the minimum TLS security policy is set and audited across all distributions.
## Why the certificate is missing AWS Certificate Manager is a Regional service: a certificate issued in `eu-west-1` exists only in `eu-west-1` and can be attached only to resources in that Region. CloudFront is global, but its control plane is anchored in `us-east-1`, and it reads viewer certificates from ACM in that Region alone. So the picker is not broken; it is showing you the full set of certificates that CloudFront can see, and yours is not among them. ## The fix Request a new public certificate in `us-east-1` for `cdn.example.com`. ACM public certificates are free, and DNS validation — adding the CNAME record ACM gives you to the hosted zone for `example.com` — is preferred because it renews automatically for as long as the record stays in place. If the certificate came from an external CA, import it into `us-east-1` instead; imported certificates do not auto-renew, so they become a calendar item. Then attach it to the distribution alongside the alternate domain name. Two related checks are worth doing at the same time. First, the certificate must cover the exact name you are adding — `*.example.com` covers `cdn.example.com` but not `example.com` itself, and not `a.b.example.com`. Second, an alternate domain name can generally be claimed by only one distribution at a time, so a leftover distribution holding the same CNAME will block you. ## SNI versus dedicated IP When you attach a custom certificate, CloudFront asks how it should be presented. **SNI custom SSL** is the default and carries no extra charge: the viewer's TLS handshake announces the hostname it wants, and CloudFront selects the matching certificate on shared edge addresses. Essentially every client in use today sends SNI. The alternative, **dedicated IP custom SSL**, allocates addresses per edge location for your distribution and carries a substantial monthly fee; it exists for very old clients that omit SNI, and choosing it without that specific requirement is simply an expensive mistake. The distribution also carries a security policy that sets the minimum TLS version and cipher suite CloudFront will negotiate with viewers. That is a separate setting from the certificate itself, and it is the knob you change when a compliance requirement says older protocol versions must be refused. ## The mental model to carry away "Where does this certificate have to live?" is answered by *what terminates TLS*. An ALB terminates in its own Region and wants a certificate there. CloudFront terminates at the edge under a global configuration and wants the certificate in `us-east-1`. When a distribution fronts an ALB you often need both: one certificate in `us-east-1` for the viewer connection, and one in the ALB's Region for the CloudFront-to-origin connection.
- Your CloudFront distribution fronts an ALB over HTTPS. How many certificates are involved and where do they live?Two. The viewer-facing certificate for the alternate domain name must be in ACM in us-east-1. The ALB needs its own certificate in the Region where the load balancer runs, presented on the CloudFront-to-origin connection. They can be issued for the same or different names, but neither can substitute for the other.
- Why is DNS validation usually preferred over email validation for an ACM certificate used by CloudFront?The validation CNAME stays in the hosted zone, so ACM can revalidate and renew the certificate automatically before expiry with no human in the loop. Email validation requires someone to click a link on each renewal, which is exactly the kind of task that gets missed and takes a distribution down at 2am.
- When would dedicated IP custom SSL be the right choice over SNI?Almost never today. It is for clients so old they do not send the SNI extension in the TLS handshake, so CloudFront cannot tell which certificate to present on a shared address. It costs a significant fixed monthly fee per distribution. Unless you have evidence of such clients in your traffic, SNI is the correct default.
saying these in an interview costs you the question
- Thinks ACM certificates are global like the distribution
- Tries to copy or move a certificate between Regions
- Assumes the origin's Region governs the viewer certificate
- Believes a wildcard covers the apex domain too
- Picks dedicated IP SSL without any legacy-client requirement