AWS Certificate Manager
Service 39

AWS Certificate Manager

SecurityTLSManaged

AWS Certificate Manager (ACM) issues and manages TLS certificates for AWS services. Public certificates used with integrated AWS services are free, valid for 198 days (reduced from 395 days in February 2026 to meet the CA/Browser Forum limit), and renewed automatically before they expire — removing both the cost and the manual expiry-tracking that used to cause outages. You request a certificate, prove domain ownership, and AWS services use it directly; you never see the private key.

Private certificates for internal CAs are a separate paid feature (ACM Private CA).

Public vs Private and Where They Attach

Public certificates are trusted by every browser — ACM's root is in the standard trust stores — and are free. Private certificates come from a private CA you manage and are trusted only by clients you configure; the private CA is paid.

By default, certificates attach only to AWS services that terminate TLS — ELB, CloudFront, API Gateway, App Runner, Elastic Beanstalk, and Amplify — and the private key never leaves AWS, so a standard certificate cannot be installed on an EC2 instance you manage. Since 2025, ACM also issues exportable public certificates (a paid option) whose key you can download and install anywhere, including EC2 and on-premises hosts. CloudFront certificates must live in us-east-1.

Validation and Renewal

DNS validation is recommended: ACM gives you a CNAME to add, and renewal stays automatic as long as the record remains. Email validation is slower, breaks more easily, and is hard to automate. For Route 53, ACM can add the validation CNAME with one click.

Public certificates renew automatically about 45 days before expiry as long as validation is still in place — the replacement is transparent, and resources pick up the new certificate without restart. This auto-renewal is the feature that justifies most of ACM's existence.

ACM vs a third-party CA

ACM public certificate — free, auto-renewing TLS for AWS-attached services (ELB, CloudFront, API Gateway) — the default on AWS.

ACM Private CA — internal services needing a private CA, where you do not want names in public CA logs (paid).

Third-party CA / Let's Encrypt — TLS on EC2 you manage yourself or on workloads outside AWS — a free alternative to ACM's paid exportable certificates.

Common Mistakes
  • Trying to install a standard (non-exportable) ACM certificate on an EC2 instance — its key never leaves AWS; use ACM's paid exportable certificates or another CA there.
  • Requesting a CloudFront certificate outside us-east-1, where it will not attach.
  • Using email validation, which breaks renewal more easily, instead of DNS validation.
  • Removing the validation CNAME after issuance, which silently breaks the next automatic renewal.
  • Requesting only example.com without the www subject alternative name (or vice versa), so one host fails TLS.
  • Trying to export a private key from ACM by hand instead of using ACM Private CA's export feature where required.
Best Practices
  • Use DNS validation so renewal stays automatic, and keep the validation CNAME in place.
  • Put validation CNAMEs in Route 53 with the one-click integration when your DNS is there.
  • Request both the apex and www names as subject alternative names.
  • Request CloudFront certificates in us-east-1.
  • For EC2-hosted or non-AWS workloads, use ACM's exportable certificates or a public CA like Let's Encrypt.
Comparable services GCP Certificate Manager, Certificate Authority ServiceAzure App Service Certificates, Key Vault

Knowledge Check

Why can't a standard (non-exportable) ACM certificate be installed on an EC2 instance you manage?

  • Its private key never leaves AWS, so it cannot be installed onto an operating system that you manage yourself
  • EC2 simply lacks the underlying TLS stack needed to terminate inbound HTTPS connections directly on the host operating system
  • ACM certificates only ever work in us-east-1, so they cannot reach instances running in any other Region
  • EC2 requires a per-instance email validation step that ACM simply has no mechanism to perform on your behalf at launch time

Which validation method keeps ACM certificate renewal automatic?

  • DNS validation — as long as the CNAME record stays in place, renewal needs no action at all
  • Email validation — the approval link never expires once it is clicked
  • Manual upload of a freshly issued certificate every single year before it lapses
  • No validation at all is needed once the certificate is first issued

Where must a certificate for a CloudFront distribution be requested?

  • In us-east-1, regardless of where the rest of the infrastructure lives
  • In whichever Region the origin bucket or origin load balancer happens to live
  • In every single Region where the distribution serves traffic from its edge locations
  • Region does not matter, since CloudFront replicates the certificate to every edge

What is the headline benefit of ACM public certificates used with integrated AWS services?

  • They are free and renew automatically, removing manual expiry tracking that causes outages
  • They include a built-in web application firewall that filters out malicious HTTP request patterns
  • They provide DDoS protection by absorbing volumetric traffic floods before they reach the origin
  • They stay valid for a full ten years, so neither renewal nor revalidation is ever needed again

You got correct