cert-manager vs Cloud Certs: how to choose
cert-manager issues certificates into Kubernetes Secrets, where any workload can mount them. Cloud certificate services — ACM, Azure Key Vault certificates, Google Certificate Manager — issue certificates into the cloud's own load balancers and often will not let you export the private key at all.
That export restriction is the deciding constraint far more often than any feature. If TLS terminates at a cloud load balancer, the cloud service is simpler and free of renewal risk: the provider handles issuance and rotation and nothing in your cluster needs the key. If TLS must terminate inside the cluster — an ingress controller, a service mesh, mutual TLS between pods — you need the key in a Secret, and cert-manager is the tool that puts it there.
Many clusters end up with both, and that is fine as long as the boundary is explicit: the cloud service for public edge certificates on the load balancer, cert-manager for everything terminating inside the cluster.
Decision matrix: which one fits your situation
| Your situation | Use | Why |
|---|---|---|
| TLS terminates at a cloud load balancer | Cloud service | Managed issuance and renewal, no key in your cluster, usually no charge for public certs. |
| TLS terminates at an in-cluster ingress controller | cert-manager | The controller needs the key, which most cloud services will not export. |
| Mutual TLS between services | cert-manager | Internal PKI with short-lived certificates is what it is built for. |
| Internal certificates from a private CA | cert-manager | Vault, a private CA, or self-signed issuers are all first-class. |
| Multi-cloud, want one process | cert-manager | The same controller and resources work everywhere; cloud services do not. |
| Wildcard for a domain you control via cloud DNS | Either | cert-manager's DNS-01 solver works well; the cloud service is less to run. |
Renewal is where this goes wrong
Cloud services renew automatically and are effectively unfailable, which is their main practical advantage. cert-manager also renews automatically, and its failures are quiet: a DNS-01 solver whose credentials expired, a rate limit hit after a reconcile loop, or an Ingress annotation that stopped matching. Nothing breaks until the certificate does, typically weeks later.
If you run cert-manager, alert on certificate expiry independently of it — from a blackbox probe against the live endpoint, not from cert-manager's own metrics. A monitor that depends on the component it is monitoring will not tell you when that component has quietly stopped working.
Frequently asked questions
Can I export a certificate from ACM to use in my cluster?
Not for public certificates — AWS does not release the private key, which is a deliberate security property rather than an omission. Certificates issued from AWS Private CA can be exported. If you need a public certificate's key inside the cluster, use cert-manager with Let's Encrypt or another ACME issuer.
Is Let's Encrypt suitable for production?
Yes, and it secures an enormous share of the public web. Design for its rate limits — use the staging environment while testing, avoid reconcile loops that request repeatedly, and remember limits are per registered domain. Most cert-manager incidents are self-inflicted rate limiting during a misconfiguration, not a problem with the CA.
What about wildcard certificates?
Both handle them. cert-manager requires the DNS-01 challenge for wildcards, which means giving it credentials to write DNS records — scope those tightly to the specific zone. Cloud services issue wildcards without you managing that credential, which is one fewer secret to protect.
Do I need cert-manager if I use a service mesh?
Often not for mesh-internal traffic — Istio and Linkerd both issue and rotate workload certificates themselves. You may still want cert-manager for the mesh's own root or intermediate CA, and for ingress certificates at the edge. Check what your mesh manages before adding overlapping certificate machinery.
