Dora NodaOn July 6, 2026, AWS announced that Certificate Manager now speaks ACME — the same open protocol Let's Encrypt has used for a decade to automate certificate issuance. You can now point any ACMEv2 client at a managed AWS endpoint and get 45-day public certificates from Amazon Trust Services, with IAM-bound accounts, endpoint-level domain scopes, and per-domain metering. Read that twice: the cloud provider's answer to the era of short-lived certificates is to become another certificate authority with an ACME server behind its own billing and identity systems.
If you run a self-hosted platform, this launch changes nothing about what you should do — and that is the point. Your cert-manager already speaks ACME directly to Let's Encrypt, for free, with no IAM policy surface and no per-domain invoice. AWS didn't invent a better automation protocol; it wrapped the existing one in enterprise controls and a price list. The only thing the 47-day future actually demands of you is renewal margin: shorter lifetimes halve your retry window, and this post ends with the concrete checklist that hardens it.
What AWS actually shipped
The July 6 announcement is precise about the shape of the product: you provision a dedicated ACME endpoint inside ACM, and any ACMEv2-compatible client — Certbot, cert-manager for Kubernetes, acme.sh — can request 45-day public certificates from Amazon Trust Services through it. Availability covers all commercial AWS Regions today, with GovCloud, China, and the EU Sovereign Cloud partitions promised later, according to the AWS News Blog walkthrough.
The enterprise packaging is the real product. A PKI administrator validates domains once at the endpoint level, holding the DNS credentials centrally; application teams then register with External Account Binding credentials and request certificates within the scopes the endpoint allows, never touching DNS themselves. IAM roles bind to ACME accounts for per-client access control, endpoint-level domain scopes and wildcard policies constrain what each account may request, CloudTrail logs every certificate request for audit, CloudWatch tracks operational metrics, and ACM sends expiry notifications as certificates approach renewal. Pricing is per domain included in each certificate at issuance, with different prices for fully qualified names versus wildcards and volume tiers computed across monthly issuance.
None of that is a protocol innovation. It is centralized PKI governance grafted onto an open protocol — valuable for a specific buyer, irrelevant overhead for everyone else. The comparison below makes the split concrete.
The two paths, side by side
This is the core of the post: the same ACME client, cert-manager, pointed at two different servers. Everything downstream of the protocol — renewal scheduling, secret storage, failure modes — is identical. Only the server side differs.
| Dimension | cert-manager → ACM endpoint | cert-manager → Let's Encrypt direct |
|---|---|---|
| Protocol | ACMEv2, unchanged | ACMEv2, unchanged |
| Client changes | Point server at the ACM directory URL, add externalAccountBinding | Default ClusterIssuer, no EAB needed |
| Certificate lifetime | 45 days, Amazon Trust Services | 90 days today, moving to 45 days (opt-in profile since May 2026, default by Feb 2028) |
| Cost | Per domain per issuance, FQDN and wildcard priced separately | Free |
| Access control | IAM roles + EAB + endpoint domain scopes | Kubernetes RBAC on Certificate/Issuer objects |
| Audit trail | CloudTrail per-request logs, CloudWatch metrics | Kubernetes events, cert-manager metrics, your own Prometheus |
| DNS-credential blast radius | Contained: admin validates once, teams get EAB creds | Depends on your solver setup; scoped screens exist but you build them |
| CA lock-in | Amazon Trust Services; endpoint config is AWS API surface | None; any ACME CA is one server URL away |
| Renewal mechanics | Identical — the client schedules renewals, not the server | Identical |
Read the last row twice. ACME servers do not renew anything. The client decides when to re-request, the client holds the retry logic, and the client owns the alerting gap. Moving the server from Let's Encrypt to AWS changes who signs the certificate and who bills you for it; it does not buy a single extra day of renewal margin. That margin is set by certificate lifetime and your client's renewal policy, full stop.
What ACM's ACME endpoint is actually good for
Steelmanning this product matters, because it is genuinely well-designed for its buyer: the enterprise with a central PKI team and dozens of application teams that should never hold DNS credentials.
The validate-once-distribute-issuance model solves a real organizational problem. Before this endpoint, giving every team automated issuance meant either distributing DNS provider credentials widely (so each team's ACME client could answer DNS-01 challenges) or funneling every certificate request through a ticket queue. ACM's endpoint splits those roles cleanly: the PKI admin proves domain control once, and each team gets an EAB credential scoped to exactly the names it may request. Compromise of a team's credential yields certificates for its own domains only, not the organization's DNS keys.
The audit story is equally enterprise-shaped. Every issuance lands in CloudTrail next to every other API call the organization makes, expiry notifications flow through ACM's existing channels, and a single console searches certificates regardless of whether they were issued through the console, the API, or ACME. For a regulated company that must demonstrate who requested which certificate and when, that centralized ledger is worth paying per-domain fees for. It is also the only row in the table above where ACM wins on substance rather than packaging.
If that describes your organization — a PKI team, compliance auditors, teams you don't fully trust with DNS — the endpoint is a reasonable buy. If it doesn't, keep reading.
Why a self-hosted PaaS gains nothing by adding it
A git-push platform on owned machines has none of the enterprise PKI team's problems and would inherit all of the endpoint's costs.
Start with the client: cert-manager already speaks plain ACME and accepts any directory URL in its issuer spec, with externalAccountBinding support for CAs that require it. Pointing it at Let's Encrypt is the default path, documented in every tutorial, exercised by most of the Kubernetes world. Repointing it at ACM adds an EAB credential to manage, an IAM trust surface to misconfigure, and an AWS API dependency in the issuance path of every tenant certificate — in exchange for the same protocol and shorter history of operational battle-testing at ACME scale.
Then the invoice. Let's Encrypt is free; ACM meters every domain on every issuance. Tenant subdomains multiply domains fast — a platform minting one certificate per tenant subdomain issues hundreds of domain-occurrences per renewal cycle, and renewal cycles are about to double in frequency as lifetimes halve. That meter runs whether or not you needed a single enterprise feature on the tin. And the CA moves from the neutral, ubiquitous Let's Encrypt to Amazon Trust Services, with endpoint configuration living behind AWS APIs — a dependency your disaster recovery story must now include for zero protocol gain.
The honest summary: ACM's ACME endpoint sells governance and auditability to organizations whose problem is internal trust boundaries. A self-hosted PaaS's problem is renewal reliability under shrinking lifetimes, and that problem lives entirely in the client. Same client, same math, either server — so pick the free, lock-in-free server and spend the savings on the checklist below.
The part that actually matters: your renewal margin
Certificate lifetimes are on a published shrink schedule, and this is the forcing function behind this post. The CA/Browser Forum's Ballot SC-081v3 caps public certificates at 200 days since March 2026, 100 days from March 2027, and 47 days from March 2029. Let's Encrypt moves faster: an opt-in 45-day profile since May 2026, 64-day defaults from February 2027, and full 45-day defaults with a 7-hour authorization-reuse window from February 2028, per its 90-to-45 timeline. We covered the full schedule and what it breaks in The 47-Day Certificate Era; this section is the operational checklist distilled to numbers.
Know your retry window, because it just halved. cert-manager renews at two-thirds of a certificate's lifetime by default: day 60 of a 90-day certificate, leaving a 30-day window in which a failing renewal can be noticed and fixed before expiry. At 45 days that becomes renewal around day 30 with roughly a 15-day window. Let's Encrypt's own guidance is to renew approximately two-thirds through lifetime. The failure mode that kills you is not the schedule — it is a renewal that starts failing quietly inside a window half as forgiving as the one you tuned your paging for.
Set renewBefore deliberately instead of inheriting it. The default two-thirds rule is sane, but an explicit renewBefore documents the window your alerting assumes and protects you if defaults ever shift. More importantly, audit every renewBefore you set years ago against 45-day lifetimes: a value tuned for 90-day certs can silently become a same-week renewal loop — or worse, a window your on-call rotation can't cover over a holiday.
Alert on renewal failure, not on expiry. The recurring pattern in public expiry postmortems is a cluster that had cert-manager installed and renewing on schedule — until something changed: an issuer misconfiguration, rotated DNS credentials, a moved secret. Nothing paged on the failing CertificateRequest, and the 30-day window quietly burned down to zero. Expiry alerts are a last-ditch tripwire; the signal you need is "a renewal has been failing for N hours," with N much smaller than your 15-day window.
Kill hardcoded renewal intervals. Any cron job, script, or runbook that assumes "certs last 90 days, renew monthly" breaks under 45-day defaults — Let's Encrypt has called this out explicitly, since a 60-day cron fires after a 45-day cert already expired. Renewal scheduling must derive from the certificate's actual lifetime, which is what configured ACME clients already do. The hardcoded intervals hide in shell scripts and wiki pages, not in cert-manager manifests; go find them.
Turn on ARI and count your onboarding headroom. Renewals coordinated through ACME Renewal Information are exempt from all of Let's Encrypt's rate limits, while new issuance still counts against 50 certificates per registered domain per week. We worked the full tenant-scale math in the ARI post: steady-state renewals for thousands of tenants can cost zero limit budget, but onboarding bursts and fleet-wide reissues hit walls. Shorter lifetimes don't change the limits — they double how often you lean on the exemptions, which is exactly when you want ARI already enabled.
Run that checklist and the 47-day era is a non-event for your platform. Skip it and add an AWS dependency instead, and you will have the best-audited expired certificate in the industry.
Running TLS for tenants on machines you own? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service with automated certificates on infrastructure you control. Star the repo on GitHub or deploy your first app today.
