Every major cloud provider offers managed SSL/TLS certificates — free, auto-renewing, and integrated with their load balancers and CDNs. But each platform has different limitations, pricing, and integration points. This guide compares AWS Certificate Manager, GCP Certificate Manager, and Azure Key Vault so you can make the right choice for your infrastructure.
Cloud-managed certificates solve three problems:
- No renewal burden: Certificates are automatically renewed before expiry — no cron jobs, no Certbot, no 3 AM pages
- Deep integration: Certificates are natively attached to load balancers, CDNs, and API gateways with a single click or API call
- Free: Public DV certificates are free on all three major platforms
The catch: cloud-managed certificates are usually not exportable. You can't download the private key and use it on your own server. They only work with the cloud provider's own services.
ACM issues free Domain Validation (DV) certificates for use with AWS services:
aws acm request-certificate \
--domain-name example.com \
--subject-alternative-names "*.example.com" \
--validation-method DNS
aws acm list-certificates
- DNS validation (recommended): Add a CNAME record to your domain's DNS. Works with Route 53 auto-validation.
- Email validation: AWS sends verification emails to domain contacts. Less reliable, harder to automate.
aws acm request-certificate \
--domain-name example.com \
--validation-method DNS \
--domain-validation-options DomainName=example.com,ValidationDomain=example.com
ACM automatically renews certificates that are:
- DNS-validated AND the CNAME validation record is still present
- In use by an AWS service (ALB, CloudFront, API Gateway)
Email-validated certificates require you to respond to renewal emails — a common failure point.
ACM certificates can only be attached to AWS services:
| Service | Region Requirement |
|---|
| Application Load Balancer (ALB) | Same region as certificate |
| Network Load Balancer (NLB) | Same region |
| CloudFront (CDN) | Certificate must be in us-east-1 |
| API Gateway | Same region (regional) or us-east-1 (edge) |
| Elastic Beanstalk | Via ALB |
| App Runner | Automatic |
Critical limitation: You cannot export the private key from ACM. If you need a certificate for an EC2 instance running Nginx, you can't use ACM — use Let's Encrypt instead (or put an ALB in front of your instance).
AWS Private CA (formerly ACM-PCA) lets you run your own CA for internal certificates:
aws acm-pca create-certificate-authority \
--certificate-authority-type ROOT \
--certificate-authority-configuration \
"KeyAlgorithm=EC_prime256v1,SigningAlgorithm=SHA256WITHECDSA,Subject={CommonName=My Internal CA}"
Pricing: $400/month per CA — steep for small teams. Consider HashiCorp Vault or step-ca as alternatives for internal PKI.
GCP automatically provisions and renews certificates for domains pointing to Google Cloud resources:
gcloud certificate-manager certificates create my-cert \
--domains="example.com,www.example.com"
gcloud certificate-manager maps create my-map
gcloud certificate-manager maps entries create my-entry \
--map=my-map \
--certificates=my-cert \
--hostname="example.com"
| Service | Certificate Type |
|---|
| External HTTPS Load Balancer | Google-managed or self-managed |
| GKE Ingress | Google-managed via annotation |
| Cloud Run (custom domain) | Automatic |
| App Engine | Automatic |
| Cloud CDN | Via load balancer |
Google-managed wildcard certificates require DNS authorization:
gcloud certificate-manager dns-authorizations create my-auth \
--domain="example.com"
gcloud certificate-manager dns-authorizations describe my-auth
gcloud certificate-manager certificates create wildcard-cert \
--domains="*.example.com,example.com" \
--dns-authorizations=my-auth
You can upload your own certificates (from Let's Encrypt or any CA):
gcloud certificate-manager certificates create imported-cert \
--certificate-file=fullchain.pem \
--private-key-file=privkey.pem
This is useful when migrating from another provider or when you need specific certificate properties that Google-managed certs don't support.
Azure's certificate management is split across multiple services, which can be confusing.
Azure App Service provides free managed certificates for custom domains:
az webapp config ssl create \
--resource-group mygroup \
--name myapp \
--hostname www.example.com
Limitations: No wildcard support for free managed certificates, and they only work with App Service (not Application Gateway or Front Door).
Azure Key Vault is the central store for certificates across Azure services:
az keyvault certificate import \
--vault-name myvault \
--name my-cert \
--file certificate.pfx \
--password "pfx-password"
az keyvault certificate create \
--vault-name myvault \
--name my-cert \
--policy @cert-policy.json
Azure supports auto-renewal in two scenarios:
- Partner CAs (DigiCert, GlobalSign): Key Vault automatically renews certificates through the CA partnership
- Self-signed: Key Vault can auto-renew self-signed certificates
For imported certificates (e.g., from Let's Encrypt), you must handle renewal externally and re-import. There is no built-in ACME support.
| Service | Certificate Source |
|---|
| App Service | Key Vault, managed, or upload |
| Application Gateway | Key Vault |
| Front Door | Key Vault or Front Door-managed |
| API Management | Key Vault or upload |
| Feature | AWS ACM | GCP Certificate Manager | Azure Key Vault |
|---|
| Free public certs | Yes (DV) | Yes (DV) | Yes (App Service only) |
| Wildcard support | Yes | Yes (DNS auth) | No (free tier) / Yes (paid) |
| Auto-renewal | Yes (DNS-validated) | Yes | Partner CAs only |
| Exportable private key | No | No (managed) / Yes (self-managed) | Yes (Key Vault) |
| Private CA | Yes ($400/mo) | Yes (CA Service) | Yes (Key Vault) |
| Multi-region | Per-region (except CloudFront) | Global (external LB) | Per-vault |
| ACME support | No | No | No |
| Validation | DNS or email | DNS or LB-based | DNS, email, or file |
| Max cert lifetime | 13 months | 90 days (managed) | Varies by CA |
- Your services run entirely on one cloud platform (ALB, CloudFront, GKE Ingress)
- You want zero certificate management overhead — no scripts, timers, or ACME clients
- You don't need the private key (SSL termination at the load balancer is fine)
- You run servers directly (EC2 with Nginx, bare metal, VPS)
- You need certificates across multiple clouds or on-premises
- You need exportable certificates (the private key must be on your server)
- You want consistency — the same renewal process everywhere
For more on Let's Encrypt automation, see Certificate Automation with ACME and Let's Encrypt.
Most production environments use both:
Public-facing (cloud-native):
CloudFront/ALB ──── ACM certificate (auto-renewed)
GKE Ingress ────── Google-managed cert
Backend servers (Let's Encrypt):
Nginx on EC2 ───── Certbot + systemd timer
On-prem proxy ──── Certbot + DNS-01 (Cloudflare)
Internal services (Private CA):
K8s pods ────────── cert-manager + internal CA
Database ────────── OpenSSL-generated certs
When you need to use a certificate from Let's Encrypt (or any external CA) with a cloud service, here's how to import it.
aws acm import-certificate \
--certificate fileb://cert.pem \
--private-key fileb://privkey.pem \
--certificate-chain fileb://chain.pem \
--region us-east-1
Note: Imported certificates are not auto-renewed by ACM. You must re-import when you renew. Automate this with a Certbot deploy hook:
#!/bin/bash
CERT_ARN="arn:aws:acm:us-east-1:123456789:certificate/abc-123"
DOMAIN="example.com"
aws acm import-certificate \
--certificate-arn "$CERT_ARN" \
--certificate "fileb:///etc/letsencrypt/live/$DOMAIN/cert.pem" \
--private-key "fileb:///etc/letsencrypt/live/$DOMAIN/privkey.pem" \
--certificate-chain "fileb:///etc/letsencrypt/live/$DOMAIN/chain.pem"
gcloud certificate-manager certificates create imported-cert \
--certificate-file=/etc/letsencrypt/live/example.com/fullchain.pem \
--private-key-file=/etc/letsencrypt/live/example.com/privkey.pem
Azure Key Vault expects PFX format. Convert PEM to PFX first:
openssl pkcs12 -export \
-out cert.pfx \
-inkey privkey.pem \
-in cert.pem \
-certfile chain.pem \
-password pass:mypassword
az keyvault certificate import \
--vault-name myvault \
--name my-cert \
--file cert.pfx \
--password mypassword
Tip: Use the SSL Certificate Decoder to verify your PEM files contain the correct chain before importing. The OpenSSL Command Builder can help generate the PFX conversion command.
If you operate across multiple clouds, standardize on these principles:
- Cloud-native for cloud services: Use ACM/GCP certs for load balancers and CDNs — free and zero-maintenance
- Let's Encrypt for servers: Consistent, exportable, works everywhere
- One private CA for internal services: Use cert-manager, Vault, or step-ca — don't run a separate PKI per cloud
- Centralized monitoring: Track all certificate expiry in one place, regardless of issuer
- Document everything: Maintain an inventory of which certificates cover which domains, where they're issued from, and how they renew
A certificate expiring in production doesn't care which cloud issued it. The important thing is that every certificate — cloud-managed or self-managed — is tracked, monitored, and renewed before it expires.
Cloud-managed certificates are the right choice for cloud-native services — they're free, auto-renewed, and tightly integrated. But they have limitations: non-exportable keys, cloud-specific services, and no ACME support for custom automation.
Key takeaways:
- AWS ACM is the simplest for AWS-only shops — but requires DNS validation for reliable auto-renewal
- GCP Certificate Manager handles wildcards via DNS authorization and works globally with external load balancers
- Azure Key Vault is the most flexible for imports but lacks native ACME — you'll manage renewal yourself for external certs
- Use a hybrid approach: cloud-native for load balancers, Let's Encrypt for servers, private CA for internal services
For hands-on practice: