CloudFront certificates live in us-east-1 for production

CloudFront certificates live in us-east-1

I've watched engineers spend hours debugging certificate errors across multiple AWS regions, only to realize their CloudFront distribution was never going to find the certificate they created in eu-west-1. This is one of those architecture details that feels arbitrary until you understand why it exists—and then it makes perfect sense. If you're distributing content globally with CloudFront, you need to know that certificates for CloudFront distributions must exist in us-east-1, period.

Request CloudFront certs in us-east-1

When you create a CloudFront distribution and want to attach an SSL/TLS certificate, AWS requires that certificate to live in the us-east-1 region. This isn't a preference or a recommendation—it's a hard requirement. The reason is architectural: CloudFront is a global service that doesn't belong to any single region, but its control plane is anchored in us-east-1. When you configure a distribution with a custom domain, CloudFront needs to retrieve the certificate from a known, consistent location.

Here's the practical flow. You navigate to ACM (AWS Certificate Manager) in the us-east-1 region specifically. You request a new certificate for your domain:

# You don't do this via CLI for the certificate request itself,
# but this is where the cert ends up
aws acm request-certificate \
  --domain-name example.com \
  --subject-alternative-names "*.example.com" \
  --validation-method DNS \
  --region us-east-1

Notice the --region us-east-1 flag. That's non-negotiable. I've seen teams request certificates in their "home region" and then spend time wondering why CloudFront can't find them when configuring distributions. The CloudFront console won't even show certificates from other regions in the dropdown.

Let me walk through a real example. You're running an e-commerce platform with your API in eu-central-1 and your database in us-east-1. Your frontend is distributed globally via CloudFront. You need a certificate for cdn.yourdomain.com. You go to ACM, but you make sure you're in the us-east-1 region first. You request the certificate for cdn.yourdomain.com with a subject alternative name for *.cdn.yourdomain.com if you need wildcards. Then you validate it (we'll cover that next). Only after it's issued and in us-east-1 can you attach it to your CloudFront distribution.

Load balancer certs in their own region

This is the part that trips people up. Application Load Balancers, Network Load Balancers, and Classic Load Balancers all live in specific regions, and their certificates can live in those same regions. In fact, they should live in the same region as the load balancer.

Here's where the confusion happens: you need certificates for both CloudFront and your regional load balancers. Many engineers think "I'll just request one certificate in us-east-1 and use it everywhere." That doesn't work. You actually need two separate certificates in many cases.

Let's look at an architecture. You have:

• A CloudFront distribution pointing to cdn.yourdomain.com
• An ALB in eu-west-1 serving your API on api.yourdomain.com

You need:

• A certificate for cdn.yourdomain.com in ACM us-east-1 (for CloudFront)
• A certificate for api.yourdomain.com in ACM eu-west-1 (for the ALB)

Request the ALB certificate in the region where the ALB lives:

aws acm request-certificate \
  --domain-name api.yourdomain.com \
  --validation-method DNS \
  --region eu-west-1

The ALB certificate doesn't need to be in us-east-1. It lives where your load balancer lives. This regional isolation is actually efficient—the certificate validation and renewal happen close to where the resource uses it.

I worked on a ride-hailing platform where we had regional API endpoints in three continents. We requested regional certificates for each ALB in their own regions and a separate CloudFront certificate in us-east-1. Each certificate was independently managed, validated, and renewed. It felt like duplication until I realized it's actually cleaner operationally.

Use DNS validation for auto-renewal

Now that you've requested your certificates in the correct regions, you need to validate them. You have two options: email validation and DNS validation. For CloudFront certificates and production workloads, DNS validation is the way to go because it enables automatic renewal.

When you choose DNS validation, ACM asks you to prove domain ownership by adding a CNAME record to your DNS provider. For a certificate request on example.com, you'll get a challenge like:

You add this CNAME to your DNS (usually in Route 53 if you're fully in AWS). ACM validates that you control the domain by checking for this record. Once validated, the certificate is issued. Here's the crucial part: if you keep that CNAME record in place, ACM automatically renews the certificate before expiry. No manual intervention needed.

In the AWS console, when you're requesting a certificate, select "DNS validation" and leave those records in place permanently. I've seen teams remove the validation records thinking they're cleanup—that breaks auto-renewal and your certificates will silently expire 90 days later.

For the CloudFront certificate in us-east-1, this is especially important because you can't afford a certificate expiry disrupting your global distribution. Set up DNS validation, add the CNAME to Route 53, and forget about it. ACM handles the rest.

Monitor expiry for imported certificates

Not every certificate comes from ACM. You might import a certificate you purchased elsewhere or generated with Let's Encrypt. If you do that, ACM can't auto-renew it. You own the renewal process.

If you're importing a certificate for CloudFront use, you must import it into us-east-1. Same rule applies. But here's the catch: ACM will send you email notifications when the certificate approaches expiry (60, 30, and 7 days before), but you need to actively renew it and reimport it.

The practical workflow looks like this:

1. Generate or purchase your certificate (e.g., from a provider like DigiCert or Let's Encrypt)
2. Import it into ACM in us-east-1 for CloudFront usage, or your target region for load balancers
3. Attach it to your CloudFront distribution or load balancer
4. Set up a calendar reminder or monitoring for when renewal is due (don't rely on email alone—set up CloudWatch alarms)
5. When renewal time comes, regenerate the certificate from your provider, import the new version into ACM with the same name or a versioned name
6. Update your resource to point to the new certificate

I've built automation for this using Lambda and SNS. When ACM sends a notification about certificate expiry, a Lambda function triggers a notification to our on-call team. We never rely on an individual remembering to renew. For imported certificates, this discipline is mandatory.

Common mistakes

Requesting CloudFront certificates outside us-east-1: You create a certificate in eu-central-1, then wonder why CloudFront can't find it. Always us-east-1 for CloudFront.

Using the same certificate for CloudFront and regional resources: A certificate in us-east-1 works for CloudFront, but you can't use it for an ALB in another region. Request region-specific certificates for regional resources.

Removing DNS validation records after validation completes: Those records aren't temporary. They enable auto-renewal. Keep them in place indefinitely.

Ignoring imported certificate expiry: ACM sends emails, but email is fragile. Set up monitoring and alerts. Track imported certificate expiry dates in a spreadsheet or tool.

Forgetting about wildcard certificate scope: A certificate for *.example.com works for api.example.com and cdn.example.com, but not example.com itself (you need to add the bare domain explicitly) and not api.staging.example.com (that requires a separate entry).

Key takeaways

• CloudFront certificates must be requested and validated in us-east-1, regardless of where your content originates or where your users are located.
• Load balancer certificates live in their own regions—request them where your ALB, NLB, or ELB resides.
• Always use DNS validation for production certificates so ACM can automatically renew them before expiry; keep the validation CNAME records in your DNS permanently.
• For imported certificates, you own the renewal process—set up monitoring, alerts, and calendar reminders so certificates don't expire silently.
• Plan for certificate management early in your architecture. Don't treat it as an afterthought that you debug when a certificate expires.