Before we can talk about AWS Certificate Manager, we need to understand what an SSL/TLS certificate actually is and what problem it solves.

What Is an SSL/TLS Certificate?

An SSL/TLS certificate is a small digital file that does two jobs at once: it proves a website’s identity, and it enables encryption of the data traveling between a visitor’s browser and that website. “SSL” (Secure Sockets Layer) is the older name for this technology, and “TLS” (Transport Layer Security) is its modern successor, though people still commonly say “SSL certificate” out of habit. Without a valid certificate, a browser will show visitors a scary warning page instead of your website, because it has no way to confirm the site is genuine or that the connection is private.

What Is AWS Certificate Manager (ACM)?

AWS Certificate Manager is a fully managed AWS service that lets you easily provision, manage, and deploy public and private SSL/TLS certificates for use with AWS services. “Fully managed” here specifically means AWS automatically renews certificates before they expire, as long as they remain properly connected to a supported AWS resource, eliminating the classic and surprisingly common failure of a website going down because a human forgot to renew a certificate manually. E-commerce companies like Shopify-hosted stores rely on this kind of automatic renewal so a forgotten expiration date never becomes the reason customers suddenly can’t complete a purchase.

Public vs. Private Certificates

ACM supports two distinct categories of certificates, each solving a different trust problem:

AWS Certificate Manager is built from a small number of pieces, but understanding how they connect explains why the “automatic” part actually works.

The Building Blocks

• Certificate — the actual digital file containing the domain name it covers, its validity dates, and cryptographic keys.
• Domain Validation — the proof-of-ownership step required before a Certificate Authority will issue a certificate for your domain.
• Certificate Authority (CA) — the trusted entity that verifies domain ownership and issues the certificate; for public certificates this is Amazon Trust Services.
• Integrated AWS Service — the resource the certificate is attached to, such as an Application Load Balancer, Amazon CloudFront distribution, or Amazon API Gateway.
• AWS Private CA — an optional, separate service for organizations that need to issue their own private certificates internally.

flowchart TB
    User["Website Owner"] -->|"Requests certificate"| ACM["AWS Certificate Manager"]
    ACM -->|"Validates domain ownership"| DNS["Route 53 / DNS Validation"]
    DNS -->|"Ownership confirmed"| ACM
    ACM -->|"Issues certificate"| CERT["Signed Certificate"]
    CERT --> ALB["Application Load Balancer"]
    CERT --> CF["Amazon CloudFront"]
    CERT --> APIGW["Amazon API Gateway"]
    ACM -.->|"Auto-renews before expiry"| CERT
        

Where ACM Fits Inside AWS

AWS Certificate Manager sits at the intersection of security and networking, most commonly attached to an Application Load Balancer or Amazon CloudFront distribution to enable HTTPS for a website, or to Amazon API Gateway to secure a custom API domain. A typical pattern connects an ACM certificate to an Application Load Balancer, which then terminates HTTPS traffic at the load balancer itself, decrypting incoming requests before passing them to backend EC2 instances over a simpler, unencrypted internal connection within the VPC.

What actually happens between requesting a certificate and a visitor’s browser showing that trusted padlock icon?

Step by Step: Issuing a Certificate

Why DNS Validation Is Preferred

ACM supports both DNS validation and email validation, but DNS validation is strongly preferred because, once the required DNS record is in place, ACM can automatically re-verify ownership at renewal time without you lifting a finger. Email validation, by contrast, requires someone to click a confirmation link in an email each time, which is exactly the kind of manual step that gets missed and causes certificates to expire unexpectedly.

A certificate isn’t a one-time purchase — it has a defined lifespan and an ongoing renewal cycle that ACM manages behind the scenes.

The Life of a Certificate

An ACM public certificate is valid for up to 13 months from issuance. Long before it expires, typically around 60 days ahead, ACM automatically attempts to renew it, silently repeating the same domain validation check it performed originally. As long as the required DNS validation record remains in place, this renewal happens with zero manual intervention, and the new certificate is automatically put into use without any downtime or visible change for website visitors.

sequenceDiagram
    participant Owner as Domain Owner
    participant ACM as AWS Certificate Manager
    participant DNS as DNS Provider
    participant Resource as ALB / CloudFront

    Owner->>ACM: Request certificate
    ACM->>DNS: Ask for validation record
    Owner->>DNS: Add CNAME validation record
    DNS-->>ACM: Confirm record exists
    ACM->>Resource: Attach issued certificate
    Note over ACM: ~60 days before expiry
    ACM->>DNS: Re-check validation record
    ACM->>Resource: Deploy renewed certificate automatically
        

What Happens If Renewal Fails?

If the DNS validation record has been removed, or the domain’s DNS settings have changed, automatic renewal can fail. ACM sends notifications well in advance in this situation, giving the domain owner time to fix the underlying DNS configuration before the certificate actually expires and causes a real outage.

Certificate Revocation

Occasionally a certificate needs to be invalidated before its natural expiration date, for example if a private key were ever suspected of being compromised. This is called revocation, and it works like a store publicly announcing that a specific gift card number has been cancelled and should no longer be honored, even though the physical card itself still exists. ACM-managed certificates handle key security internally in a way that makes this scenario rare, but understanding revocation helps explain why Certificate Authorities maintain public revocation lists that browsers can check.

ACM removes a huge amount of manual certificate work, but it does come with some real boundaries worth understanding.

The Core Trade-off: Convenience vs. Portability

A traditional, manually purchased certificate can be installed on literally any server, cloud provider, or piece of hardware you own — but that portability comes with the full weight of manual renewal and installation. ACM trades that universal portability for near-total convenience: certificates work seamlessly across integrated AWS services and renew themselves, but they’re tied specifically to the AWS ecosystem rather than being freely movable elsewhere.

This trade-off rarely matters for teams that run entirely on AWS, since every service that needs a certificate can get one directly from ACM anyway. It becomes relevant mainly for organizations running a genuinely hybrid setup, with some servers outside AWS entirely, where a manually managed certificate purchased from a traditional Certificate Authority may still be the more practical choice for those specific non-AWS systems.

Certificates themselves aren’t typically a performance bottleneck, but how you manage many of them at scale absolutely matters.

Managing Certificates Across Many Domains

A single ACM certificate can cover multiple domain names and subdomains at once through Subject Alternative Names (SANs), meaning a company running dozens of related subdomains doesn’t necessarily need dozens of separate certificates. This is similar to a single master key that opens multiple doors in a building, rather than needing a unique key cut for every single door.

Scaling Across Regions and Accounts

Because ACM certificates are regional resources, a company running Application Load Balancers in multiple AWS Regions needs a certificate requested separately in each region where it’s used. A notable exception is Amazon CloudFront, a global service, which specifically requires its certificates to be requested in the us-east-1 (N. Virginia) region regardless of where the actual content is served from around the world.

For organizations operating across multiple AWS accounts, such as a separate account per environment or per business unit, ACM certificates can be shared across accounts using AWS Resource Access Manager, avoiding the need to re-issue and separately validate an identical certificate in every single account that happens to need it. This is particularly useful for a shared corporate domain used by several teams, each running their own applications in their own dedicated AWS account.

A certificate silently expiring is one of the most common and entirely preventable causes of a website outage — ACM is built specifically to avoid that failure mode.

Automatic Renewal as a Reliability Feature

Before services like ACM existed, certificate expiration was a genuinely common cause of production outages, often catching teams by surprise months after whoever originally set up the certificate had moved to a different project or left the company entirely. ACM’s automatic renewal, tied directly to a persistent DNS validation record rather than a person’s memory or calendar reminder, removes human forgetfulness from the equation entirely.

Durability vs. Availability

For a certificate, availability means it remains valid and correctly attached to the resources that need it, while durability is less about data loss and more about the certificate’s validity persisting reliably over time. ACM achieves this reliability through automated renewal cycles that don’t depend on any single person remembering to act.

Certificates exist entirely for security purposes, so understanding exactly what protections ACM provides — and what it doesn’t — really matters.

• Private key protection — ACM generates and stores private keys securely within AWS, and they’re never exposed for you to accidentally mishandle or leak.
• Domain validation — ensures certificates are only issued to parties who can actually prove ownership of the domain in question.
• Integration with AWS Certificate Transparency logging — public certificates are logged publicly, letting domain owners monitor for unauthorized certificates issued in their name.
• IAM permissions — control exactly who within your organization is allowed to request, view, or delete certificates.
• AWS Private CA — provides an isolated root of trust for organizations needing certificates that should never be trusted outside their own systems.

Even with automatic renewal, keeping an eye on certificate health prevents surprises rather than reacting to them after the fact.

AWS Certificate Manager integrates with AWS Config and Amazon EventBridge, allowing you to track certificate status changes and set up notifications for events like renewal failures or upcoming expirations. Think of this like a smoke detector for your certificates — you’d rather be alerted the moment something looks wrong than discover the problem only after visitors start seeing browser security warnings. Teams commonly configure EventBridge rules that trigger a notification to a messaging channel whenever ACM reports a certificate approaching expiration without a successful renewal.

ACM’s real value shows up in how effortlessly it plugs into the AWS services that actually serve traffic to users.

A typical deployment attaches an ACM certificate directly to an Application Load Balancer’s HTTPS listener, enabling secure connections for a web application without ever touching a certificate file manually. Another extremely common pattern attaches an ACM certificate to an Amazon CloudFront distribution, securing a global content delivery setup so that visitors anywhere in the world connect over HTTPS regardless of which edge location happens to serve their request.

Cost Considerations During Deployment

Public ACM certificates used with supported, integrated AWS services are provided at no additional charge, which is genuinely unusual compared to the historical cost of purchasing certificates from third-party Certificate Authorities. The main cost consideration to watch for is AWS Private CA, which does carry its own separate monthly and per-certificate charges, so organizations should weigh whether truly private, internal-only certificates are necessary before adopting that additional service.

Automating Issuance at Scale

Larger organizations rarely request certificates one at a time through a console click. Instead, they typically use infrastructure-as-code tools to request ACM certificates as part of the same automated deployment that creates a new load balancer or CloudFront distribution, so a new environment or customer subdomain comes online already fully secured, with validation records created programmatically at the same moment the DNS entries themselves are set up. This kind of end-to-end automation is what allows a SaaS company to onboard hundreds of customer subdomains a day without a human ever manually touching a certificate request.

How a team manages certificates across a growing set of domains is itself a design decision, and a shortsighted early choice can create real maintenance debt.

Good Patterns to Follow

• Use DNS validation instead of email validation whenever possible, since it enables true set-it-and-forget-it renewal.
• Consolidate related subdomains under a single multi-domain certificate rather than issuing dozens of separate ones.
• Set up EventBridge or AWS Config alerts for certificate renewal failures, even though renewal is automatic.

Most ACM problems in the real world trace back to a small number of avoidable configuration mistakes.

Seeing how real organizations actually use ACM makes the abstract concepts click into place.

Across every one of these industries, the common thread is the same: encryption and identity verification stopped being a manual chore that someone had to remember, and became a background service that simply keeps working, year after year, without drawing attention to itself.

Public certificates are provided at no additional cost when used with supported, integrated AWS services like Application Load Balancer, CloudFront, and API Gateway. Only AWS Private CA, used for issuing private internal certificates, carries its own separate charges.

Generally, no. ACM public certificates are designed to be used specifically with integrated AWS services, and their private keys are not exportable, which is part of how AWS keeps the private key secure without requiring you to manage it yourself.

A certificate is eligible for automatic renewal if it’s actively associated with a supported AWS resource and its DNS validation record remains correctly in place; ACM will attempt renewal roughly 60 days before expiration and will notify you if that renewal encounters any problems.

Amazon CloudFront’s certificate management specifically requires certificates to be requested in the us-east-1 (N. Virginia) region, regardless of where your content is actually delivered from, because that’s where CloudFront’s certificate distribution control plane is centralized.

A public certificate is trusted automatically by browsers and operating systems everywhere because it’s issued by a widely trusted Certificate Authority, while a private certificate is only trusted within your own organization because it’s issued by your own private Certificate Authority through AWS Private CA.

Yes, using Subject Alternative Names (SANs), a single ACM certificate can cover a primary domain along with additional related domain names or subdomains, reducing the number of separate certificates a team needs to request, validate, and keep track of.