SSL certificates issued through AWS Certificate Manager come with a reputation for being maintenance-free – provision one, attach it to a load balancer or CloudFront distribution, and forget about it. That reputation is only half true, and the gap between what ACM actually guarantees and what teams assume it guarantees is where a surprising number of production outages come from.
What AWS Certificate Manager Actually Handles For You
ACM issues public and private TLS certificates and, critically, will attempt to renew them automatically before expiration – but only for certificates that are actively in use by an integrated AWS service such as Elastic Load Balancing, CloudFront, API Gateway, or Elastic Beanstalk. The renewal process re-validates domain ownership using the same method chosen at issuance, either DNS validation via a CNAME record or email validation sent to WHOIS-listed contacts.
DNS validation is the far more reliable option and the one AWS recommends. Once the validation CNAME is created in your hosted zone, ACM can revalidate silently every renewal cycle without any human involvement. Email validation, by contrast, depends on inboxes that get ignored, forwarded incorrectly, or simply stop being monitored after the person who set them up leaves the company.
Where Automatic Renewal Quietly Breaks
The myth worth busting here is the idea that “ACM manages certificates automatically” means zero ongoing responsibility. In practice, renewal fails silently in several common situations:
The validation CNAME record gets deleted during a DNS cleanup or a migration to a new hosted zone. Someone tidying up Route 53 records sees a cryptic underscore-prefixed CNAME pointing to acm-validations.aws and assumes it’s leftover cruft from a decommissioned service, then deletes it. Nine to eleven months later, when renewal is due, ACM can’t revalidate and the certificate quietly expires.
A certificate stops being attached to any AWS resource. ACM only auto-renews certificates that are in use. If a certificate was issued for a domain that later got moved to a different load balancer or removed entirely, ACM may consider it unused and skip renewal, even if the certificate is still referenced somewhere in a stale configuration.
Cross-account or cross-region complications. Certificates for CloudFront must exist in us-east-1 regardless of where the rest of the infrastructure lives, and this single fact trips up more deployments than any other ACM quirk. Teams issue a certificate in their working region, attach it to an Application Load Balancer successfully, then wonder why CloudFront can’t find it.
Building a Verification Habit, Not Just Trust in Automation
The practical lesson from watching ACM failures play out is simple: automatic renewal reduces the workload, it doesn’t remove the need for monitoring. Treat ACM the same way you’d treat any other certificate authority in your certificate lifecycle process – track issuance, expected renewal windows, and validation status independently of whatever AWS’s console tells you at a glance.
A few habits reduce the risk meaningfully:
Tag every ACM certificate with its purpose and the service that consumes it. When someone reviews Route 53 records six months later, a certificate tagged “prod-checkout-alb, do not remove validation CNAME” survives cleanup passes that untagged records don’t.
Set up AWS Config or CloudWatch Events rules that alert when a certificate’s status changes to “Pending Validation” or “Expired” – these are the two states that indicate renewal has stalled.
Check the “in use” status periodically. ACM’s console shows which resources reference each certificate. A certificate with zero associated resources is either genuinely obsolete or an orphaned reference that needs reattaching – either way it needs a decision, not silence.
Handling Certificates ACM Doesn’t Fully Own
Not every certificate in an AWS environment goes through ACM. Certificates on EC2 instances running your own Nginx or Apache configuration, certificates used by third-party SaaS integrations pointing at your domain, and certificates issued through internal or private CAs for service-to-service traffic all sit outside ACM’s automatic renewal scope. These need the same tracking discipline as any self-managed certificate, and in multi-cloud or hybrid environments this is usually where visibility gaps actually form – not inside ACM itself, but at the boundary where ACM’s coverage ends and everything else begins.
This matters even more when CloudFront sits in front of an origin with its own certificate. CloudFront validates the certificate at the origin separately from the ACM-issued edge certificate, and a misconfigured origin certificate can produce connection errors that have nothing to do with the ACM certificate everyone assumes is the problem. Diagnosing which layer actually failed – edge or origin – is a common source of wasted troubleshooting time during incidents.
A Realistic Renewal Timeline
For a DNS-validated ACM certificate, AWS begins attempting renewal roughly 60 days before expiration and retries periodically. If validation succeeds, the new certificate is deployed without any visible change to end users – no downtime, no reissuance request needed. If validation fails at day 60, ACM keeps retrying until close to expiration, at which point the certificate simply expires and dependent services start serving errors or, in stricter configurations, refuse connections entirely.
That final window – the last two to three weeks before an unrenewed certificate expires – is exactly why independent expiry tracking with staged alerts (30, 14, 7, and 1 day out) matters even for ACM-managed certificates. Relying solely on AWS’s own renewal attempts means the first sign of trouble might be a customer reporting a browser warning, rather than an internal alert giving the team time to fix the underlying DNS issue before anyone notices.
Frequently Asked Questions
Does ACM automatically renew certificates issued through email validation?
Yes, but reliability depends entirely on someone actively monitoring the validation email addresses. Because these inboxes are frequently unmonitored or tied to former employees, DNS validation is the safer choice for any certificate expected to auto-renew without manual intervention.
Can you export an ACM certificate for use outside AWS?
Public ACM certificates cannot be exported for use on non-AWS infrastructure – they’re tied to the AWS services they’re attached to. If a certificate needs to run on a self-managed server outside AWS, it needs to come from a different CA or from ACM Private CA, which does support export in specific configurations.
Why did an ACM certificate expire even though it showed as valid in the console days earlier?
This usually traces back to a broken validation record or a certificate that fell out of active use between renewal checks. Reviewing the certificate’s associated resources and confirming the validation CNAME still resolves correctly are the first two troubleshooting steps.
ACM removes a meaningful amount of manual certificate work, but “automatic” isn’t the same as “unattended.” The teams that avoid ACM-related outages are the ones who keep independent visibility into validation status and renewal timing, rather than assuming the console’s green checkmark tells the whole story.