What Is AWS Certificate Manager? Free Certificates, the 198-Day Rule, and the One Big Catch

AWS Certificate Manager (ACM) is the AWS service that issues, stores, renews and deploys the SSL/TLS certificates that put the padlock on your site. For anything that lives inside AWS, a load balancer, CloudFront, API Gateway, the public certificate costs nothing, renews itself, and you never see the private key. That last part is the catch. The free certificate cannot leave AWS. If you want to install it on your own Nginx, an EC2 instance, a Kubernetes cluster or another cloud, you need either an exportable certificate, $7 per name and $79 per wildcard each time it is issued, or ACM's new ACME endpoint, which hands your own server a 45-day certificate for $1 a name. And since February 18, 2026, every public certificate ACM issues lasts 198 days instead of 395, which is fine for the integrated services and a real change for anyone who exports.

Jake's phone repair shop runs its booking page on AWS, and the first time Ethan put HTTPS on it he did the thing most people do: requested a free ACM certificate, attached it to the load balancer, and forgot about it. It renewed itself twice without either of them noticing. Then Jake bought a second-hand mini server for the back office, wanted the same padlock on it, and asked Ethan for "the certificate file". There was no file. There has never been a file. This page is the whole picture Ethan drew for him that afternoon: what ACM actually is, when it is free and when it is not, how validation works and why a certificate sits in Pending validation for three days, what changed in 2026, and the three honest ways to get a certificate onto a machine AWS does not manage.

What ACM actually is, and what it is not

A TLS certificate is a signed statement that the server answering for booking.example.com really is allowed to. Browsers trust a short list of certificate authorities to sign those statements, and ACM's public certificates come from Amazon Trust Services, Amazon's own authority, whose roots are trusted by Chrome, Edge, Firefox, Safari and Java. The certificates are domain-validated: they say you control the name, nothing about who you are.

Without ACM, the certificate lifecycle is a chore you repeat every year: generate a key, prove the domain, download the files, install them on every server, watch the expiry date, renew, reinstall. ACM collapses that to three steps for anything inside AWS: request, validate, attach. It keeps the private key inside AWS, hands the certificate to the load balancer or distribution, and renews it on its own as long as the certificate is in use and your validation record is still in DNS.

That is also what ACM is not. It is not a certificate file you download. It is not a way to put a certificate on an EC2 instance by itself; AWS's own page says plainly that attaching an ACM-managed certificate directly to an instance needs a Nitro Enclave, and for everything else it now points you to ACME or an exportable certificate. And it is not free for everything; it is free for the integrated services, which turns out to be the only sentence most people remember.

Jake: "So where is the certificate? I want to copy it to the back-office box."

Ethan: "There is no file. AWS holds the key and hands the certificate to the load balancer directly. That is the whole reason it is free and the whole reason you cannot copy it."

Is ACM free? Yes, no, and the 2026 price list

ACM's pricing page has one row that says "No cost" and a few that do not. Here is the whole of it, in the order people ask.

Read the exportable row twice, because the word "again" is where the real cost hides. The $7 is charged when the certificate is issued and charged again every time ACM renews it. With 198-day certificates renewing 45 days early, a new one is issued roughly every 153 days, which is about 2.4 issuances a year: call it $17 a year per name and $188 a year per wildcard. That is still cheap next to a commercial certificate, and it is not zero. AWS lowered these prices from $15 and $149 on the same day it shortened the validity, so the yearly cost stayed roughly where it was.

Free never meant free architecture, either. The certificate on Jake's load balancer costs nothing; the load balancer, the containers behind it, CloudFront, API Gateway and the data transfer all bill as usual. ACM removed one line from the invoice, not the invoice.

Jake: "Seven dollars I can live with. Why was it free before and not now?"

Ethan: "It is still free on the load balancer. You are paying for the one thing that was never free: taking the key with you."

The one big catch, in detail

The standard ACM certificate works because AWS generates and keeps the private key. You never download it, so you never leak it, email it, bake it into a deployment script, or copy it between servers at midnight. That is a genuine security win and the reason the integrated services can renew without you. It is also why there is nothing to install on the back-office box.

Until June 2025 that was the end of the story: ACM public certificates were for AWS-managed endpoints, full stop. Now there are three doors out, and choosing between them is most of this page.

One sentence from the exportable-certificate launch deserves its own line: public certificates created before June 17, 2025 cannot be exported, and the export setting is chosen when you request the certificate and cannot be changed afterwards. If you have an older certificate and now need its key, you request a new one with export enabled. That is the whole trick, and nobody tells you until you have spent an hour looking for the download button.

198 days: what changed on February 18, 2026

For years ACM public certificates were valid for 13 months, 395 days. On February 18, 2026, AWS cut that to 198 days for every new public certificate, ahead of the CA/Browser Forum rule that caps public certificates at 200 days from March 15, 2026. Nothing was asked of you: certificates already issued at 395 days stay valid until they renew, and when they renew they come back at 198. ACM moved its renewal window with it, from 60 days before expiry to 45, and the older 395-day certificates renew at 60 days and then join the new cycle.

If your certificate lives on a load balancer or CloudFront, this is a footnote. ACM renews it, the service picks the new one up, and you may never notice that it now happens twice a year. If you export, it is a change in your routine: the renewed certificate has to be fetched and installed roughly every five months instead of once a year, which is exactly the reason AWS built the ACME endpoint. The industry's own schedule keeps going; AWS's launch note for ACME says the maximum drops to 100 days from March 2027 and to 47 days by 2029, so a renewal process that needs a human is on borrowed time.

The sizes and algorithms did not change. ACM requests certificates with 2048-bit RSA, or 256- or 384-bit ECDSA keys; larger RSA and 521-bit ECDSA are for imported certificates only. A certificate holds up to 10 names by default, up to 100 by quota increase, and the first name you list becomes the subject with all of them in the Subject Alternative Name extension.

DNS, email or HTTP: proving you own the name

Before Amazon's authority will sign anything, ACM has to see that you control every name in the request. There are three ways, and only one of them you should want.

Email validation has two quiet limits. ACM no longer looks up WHOIS contacts for new certificates or renewals, so the five standard mailboxes are the only ones that get the link. And a certificate requested with email validation can never be switched to DNS; you delete it and request again. Pick DNS the first time.

Validation only applies to public certificates. ACM does not validate imported certificates or private ones, and it cannot validate anything in a Route 53 private hosted zone, a VPN-only DNS server or any other domain the public internet cannot resolve. For those, the answer is AWS Private CA, which is a different product with a monthly fee.

How DNS validation works, one CNAME at a time

When you request example.com and www.example.com with DNS validation, ACM hands you two CNAME records. Each has a name that starts with an underscore and a long random string, and a value that ends in acm-validations.aws. You add them to whichever DNS provider is authoritative for the domain, ACM sees them, and the certificate moves from Pending validation to Issued.

Name:   _a79865eb4cd1a6ab990a45779b4e0b96.example.com.
Type:   CNAME
Value:  _424c7224e9b0146f9a8808af955727d0.acm-validations.aws.

Three things about that record save a lot of grief. The record for *.example.com and the record for example.com are identical, so a wildcard plus apex request needs one CNAME, not two; www.example.com gets its own. The record is the renewal: ACM re-checks it every time, so it stays in DNS for the life of the domain, and deleting it is how you stop automatic renewal. And the CNAME works in every Region and for every future certificate on that name, which means you can request the same certificate again in us-east-1 for CloudFront, or replace a deleted one, without validating again.

If Route 53 hosts the zone, the console shows a Create records in Route 53 button and does it for you. The button is missing when Route 53 is not the provider, when ACM and Route 53 are in different accounts, when you lack permission to write to the zone, when the name was already validated, or when the domain is not publicly addressable. Expect the certificate to sit in Pending validation for up to 30 minutes after the records exist, and know the deadline: if ACM cannot see the record within 72 hours of generating it, the certificate flips to Validation timed out and you request a new one.

1. In the ACM console, pick the Region the certificate will be used in, then Request, public certificate, DNS validation, and list every name: example.com and *.example.com if you want both.
2. Open the new certificate. Each name shows a CNAME name and value; Export to CSV if you have several.
3. Add each record at the authoritative DNS provider. If the provider appends your domain automatically, enter only the part before .example.com.
4. Check from outside: dig _a79865eb4cd1a6ab990a45779b4e0b96.example.com CNAME +short should print the acm-validations.aws value.
5. Wait. aws acm wait certificate-validated --certificate-arn ARN returns when the status changes, or watch the console.
6. Attach the issued certificate to the listener or distribution, and leave the CNAME where it is.

Jake: "Can I delete that odd underscore record once it says Issued? It looks like junk."

Ethan: "That odd record is the reason you never think about renewals. Delete it and in about five months ACM will start sending you emails you did not want."

Stuck in Pending validation: every cause and its test

A certificate that will not leave Pending validation is almost always a DNS problem, and the problem is almost never ACM. Work down the table; the first column is what to run.

The GoDaddy case is common enough that AWS documents it by name: the registrar appends your domain to the name field, so you enter _ho9hv39800vb3examplew3vnewoib3u alone, without .example.com, or you end up with the domain twice and a record that validates nothing. Namecheap and several others behave the same way. The CAA case is the sneaky one, because DNS looks perfect and the certificate still sits there; ACM checks CAA after validation, and a record that lists only another authority blocks issuance silently.

Two commands tell you what ACM is waiting for and whether the world can see your record.

aws acm describe-certificate --certificate-arn ARN --region us-east-1 \
  --query 'Certificate.DomainValidationOptions[].{name:DomainName,status:ValidationStatus,record:ResourceRecord}'

dig _a79865eb4cd1a6ab990a45779b4e0b96.example.com CNAME +short
nslookup -type=CNAME _a79865eb4cd1a6ab990a45779b4e0b96.example.com

If the record resolves from the public internet and CAA is clear, you are done; ACM checks on its own schedule and you cannot hurry it. Jake's first certificate sat for a day because the booking domain's nameservers still pointed at the registrar while Ethan had carefully added the record to a Route 53 zone that nobody on the internet was asking. The NS check takes five seconds and would have saved the day.

Renewal: when ACM does it alone and when it needs you

ACM renews the certificates it issued, under conditions that are worth knowing precisely. A public certificate is eligible when it is in use by an AWS service, or when it has been exported since it was issued or last renewed. Imported certificates are never renewed by ACM. Expired certificates are not renewed. And ACME certificates are renewed by your ACME client, not by ACM.

With DNS validation, 45 days before expiry ACM checks that the certificate is in use and that every CNAME is still resolvable, then issues the renewal under the same ARN, and the load balancer or distribution picks it up without you. With email validation, 45 days before expiry ACM starts emailing the five admin addresses, and a human has to click. If a renewal cannot complete, for a CAA record that now blocks Amazon, a deleted CNAME, or a certificate nobody is using, ACM raises an EventBridge event called ACM Certificate Renewal Action Required at 30 days before expiry for public certificates, and tries again at 15, 3 and 1 days.

The events are the part most people never set up and then wish they had. Starting 30 days before a public certificate expires, and 45 days for private and imported ones, ACM emits a daily ACM Certificate Approaching Expiration event, and you can change that lead time with PutAccountConfiguration. One EventBridge rule on aws.acm that posts to a chat channel is the difference between an imported certificate quietly expiring on a Saturday and you knowing a month ahead. There is also an ACM Certificate Available event on every issuance and renewal, with an Exported flag, which is the hook for automating the re-export of exportable certificates.

1. In EventBridge, create a rule on the default bus with source aws.acm and detail-type ACM Certificate Approaching Expiration.
2. Target an SNS topic, a chat webhook through Lambda, or a ticketing integration.
3. Add a second rule for ACM Certificate Renewal Action Required, because that one means ACM already tried and failed.
4. For imported certificates, make the rule your reminder to re-issue and re-import before the date.

Renewed certificates keep their ARN, which is why the services attached to them need no change. Certificates are regional, so the same name in two Regions is two certificates that renew separately. And there is one dangerous feature of email validation worth saying out loud: the renewal link goes to the five mailboxes, and if none of them is read, the certificate expires with a month of warnings nobody saw.

The Region rule that catches almost everyone

An ACM certificate lives in one Region and cannot be copied to another. To use the same name on load balancers in two Regions, you request a certificate in each, and because the DNS CNAME is valid everywhere, the second request validates instantly. The exception is CloudFront: it reads certificates only from US East (N. Virginia), us-east-1, and distributes them to every edge location from there.

Jake's application runs in Mumbai and his CloudFront certificate lives in Virginia. That is not a mistake; it is the rule. The mistake is the one Ethan made the first time, requesting the certificate in Mumbai, attaching the distribution, and finding the certificate missing from CloudFront's dropdown.

Wildcards: what *.example.com does and does not cover

A wildcard certificate for *.example.com covers www.example.com, api.example.com and any other single label in front of the domain, an unlimited number of them. It does not cover example.com itself, and it does not cover dev.api.example.com, because the asterisk stands for exactly one level. The usual request is therefore two names on one certificate, example.com and *.example.com, and as you saw above they share a single validation CNAME.

Two wildcard rules from AWS's own pages: HTTP validation does not support wildcards, so a CloudFront wildcard needs DNS or email validation; and a CAA issuewild record that omits Amazon blocks wildcard issuance even when an issue record allows it, while an issue record alone is enough when there is no issuewild at all.

Exportable certificates: the key leaves AWS, on your terms

Since June 2025 you can ask ACM for a public certificate you are allowed to export. In the console the request page has an Allow export choice; in the API it is a request option, and once a certificate is issued the choice is fixed. You validate it the same way, then export the certificate, its chain, and the private key encrypted with a passphrase you supply, and install them wherever TLS terminates: EC2, containers, EKS pods, an on-premises server, another cloud.

aws acm export-certificate --certificate-arn ARN --passphrase fileb://passphrase.txt \
  --query '{cert:Certificate,chain:CertificateChain,key:PrivateKey}' --output json

Then the part exporting changes: renewal. ACM still renews the certificate 45 days before its 198 days are up, keeps the ARN, and raises the ACM Certificate Available event with Exported set. It does not install anything for you. Your job is to export the renewed certificate and deploy it, by hand or through automation keyed on that event, Systems Manager documents, or the ACK controller on EKS, which writes the renewed certificate into a Kubernetes Secret. AWS also offers a Workload Credentials Provider for automating exportable certificates where ACME is not an option.

Treat the exported key the way you would treat a password file: restricted permissions, no copies in chat, and revoke the certificate in ACM if you ever suspect the key leaked. That is the trade. You get a publicly trusted certificate on any machine for $7 a name, and you take back the one job AWS was doing for you.

ACME: the July 2026 answer for servers you manage yourself

On July 6, 2026, ACM added an ACME endpoint, which changes the answer to "how do I get a certificate onto EC2" for most people. ACME is the protocol Let's Encrypt made famous: a client on your server asks a certificate authority for a certificate, proves the domain, and renews on a timer, with the private key generated on your server and never seen by anyone else. ACM now runs a managed ACME server, works with any ACMEv2 client including Certbot, cert-manager for Kubernetes and acme.sh, and issues publicly trusted certificates from Amazon Trust Services with a 45-day validity in every commercial Region.

AWS's version has one twist that makes it fit a company. A PKI administrator creates the ACME endpoint, validates the domains once with the familiar CNAME, and hands application teams external account binding credentials, a key ID and a MAC key. The clients then request certificates for the pre-approved domains without ever touching DNS, and the administrator can limit which domains each client may use and whether wildcards are allowed. Issuance shows up in the ACM console, CloudTrail and CloudWatch like everything else.

certbot certonly --standalone --non-interactive --agree-tos --email you@example.com \
  --server https://acm-acme-enroll.REGION.api.aws/ENDPOINT-ID/directory \
  --eab-kid EXAMPLE_KEY_ID --eab-hmac-key EXAMPLE_MAC_KEY \
  --issuance-timeout 120 --domain www.example.com

Issuance can take up to two minutes, so set the client's timeout to at least 120 seconds; many default to 30 or 90 and give up early. Certbot then keeps the certificate under /etc/letsencrypt/live/ and its normal certbot renew timer handles the rest. Three things to know before you choose it: ACME certificates cannot be attached to a load balancer, CloudFront or API Gateway, because AWS never holds the key; ACM does not renew them, your client does; and they are revoked through the ACME endpoint, not the ACM console. They also do not count against the 2,500-certificate quota, and they get a stable ARN across renewals when the same client renews the same names.

For Jake's back-office box, ACME won. One Certbot command, a renewal timer, a dollar a month, and no key ever sitting in a chat window. Exportable certificates make more sense when the same name has to live on a load balancer and a server, or when a platform like EKS with the ACK controller can do the deploying for you.

Jake: "So the mini server gets a certificate that lasts 45 days? That sounds worse."

Ethan: "It sounds worse and it is better, because you never touch it. The client renews it every few weeks on its own. The 45 days is the whole industry's direction; AWS just got there first."

Importing a certificate you already have

If you already bought a certificate elsewhere, import it: the certificate body, the private key and the chain, all in PEM form. Imported certificates work with the same integrated services, and ACM does not renew them, because it cannot; the issuer is somewhere else. You re-issue with the issuer, re-import under the same ARN, and the attached services pick it up. The expiry events above are the safety net; set them up the day you import, not the week it expires. Imported certificates have their own quota of 2,500, and they can use the larger RSA and 521-bit ECDSA keys that ACM itself does not request.

AWS Private CA in one paragraph

For names the public internet should never trust, internal services, test environments, device identities, ACM can issue certificates from AWS Private CA, which is its own service with its own bill: $400 a month per CA in general-purpose mode, or $50 a month in short-lived certificate mode, plus $0.75 per certificate for the first 1,000 each month, $0.35 for the next 9,000, and $0.001 after that, or $0.058 each in short-lived mode. The first private CA in each Region has no CA charge for 30 days, and certificates still bill. Private certificates requested through ACM and then exported or attached to a service are eligible for ACM renewal; ones issued straight through the Private CA IssueCertificate API are not. If you only need one internal certificate, $400 a month is a very expensive padlock, and a self-managed CA or ACME against an internal authority may be the honest answer.

Quotas and the CloudFormation trap

Each Region of each account gets 2,500 ACM certificates and may request up to 5,000 in a year. Expired and revoked certificates still count until you delete them, so a busy CI pipeline that requests a certificate per branch and never cleans up walks into the limit. Certificates from Private CA and from ACME do not count. Each certificate holds 10 names by default and up to 100 on request; ACME certificates get 100, fixed. RequestCertificate is throttled at five calls a second, which matters only to automation, and ImportCertificate at one.

The CloudFormation trap is worth its own warning. A stack that creates an ACM certificate stays in CREATE_IN_PROGRESS until the certificate validates, and with email validation that means until a human clicks. Use DNS validation with Route 53 so the stack can create the records itself, and in Terraform pair aws_acm_certificate with an aws_route53_record for each domain_validation_options entry and an aws_acm_certificate_validation that waits on them; without the validation resource, Terraform happily attaches a certificate that has not been issued yet.

Eight mistakes, and the sentence that fixes each

1. The CloudFront certificate is in the wrong Region. Request it again in us-east-1; the CNAME you already have validates it instantly.
2. The validation CNAME was deleted after issuance. Put it back; it is the renewal.
3. The wildcard was expected to cover the apex. Add example.com as a second name.
4. The registrar appended the domain twice. Enter only the host part of the record name.
5. The record went into a zone nobody is asking. dig NS tells you where to put it.
6. The old certificate was expected to become exportable. Only certificates requested with export enabled, after June 17, 2025, can be exported.
7. A CAA record blocks Amazon. Add an issue entry for amazon.com, and issuewild if you need wildcards.
8. A certificate was expected to follow the app to another Region. Certificates are regional; request one per Region.

And the HTTPS-is-down checklist, in the order that finds the fault fastest: is the certificate Issued; does it contain the exact hostname users type; is it in the right Region; is it attached to the right listener or distribution; does DNS point at that load balancer or distribution; does the listener accept 443; do the security groups allow it; for CloudFront, is it in us-east-1; and for a certificate still pending, does its CNAME resolve from the public internet.

Questions people type about ACM

If you came here for the padlock, the honest summary is this: inside AWS the certificate is free and self-renewing, and the only work is one DNS record you never delete. Outside AWS you choose between paying $7 to take the key with you and paying $1 to let your server fetch its own. Jake's booking page still runs on the free certificate Ethan attached in the spring, and the back-office box renews its own every few weeks through ACME; neither of them has looked at a certificate file since, which is exactly the point.

Revision note. Written October 8, 2026, with the 198-day validity, the lower exportable prices and the July ACME endpoint all in place. If a certificate of yours has been sitting in Pending validation all afternoon, the NS lookup in the table above is the five-second check that usually ends it.