AWS Certificate Manager vs. cert-manager

Certificates as a Cloud Service or as Part of the Platform Architecture

TLS certificates are often considered a necessary security detail. However, in modern platform architectures, they are much more than that. Certificates define where trust ends, how services communicate, and whether security mechanisms are consistently automated or only applied sporadically.

AWS Certificate Manager (ACM) and cert-manager solve the same fundamental problem: issuing, renewing, and managing certificates. Architecturally, however, they pursue two fundamentally different approaches. One shifts certificate management to a cloud service, while the other integrates it directly into the platform.

AWS Certificate Manager: TLS as a Cloud Function

AWS Certificate Manager is AWS’s managed service for issuing and managing TLS certificates. It integrates seamlessly with AWS services like Elastic Load Balancer, CloudFront, and API Gateway. Certificates are automatically renewed, private key material remains within the AWS context, and operational effort is minimal.

For publicly accessible AWS endpoints, ACM is functionally solid and convenient. TLS becomes largely invisible—it just works, without teams having to deal with lifetimes, renewals, or key management.

However, this convenience is clearly delineated.

Platform Boundaries as Structural Limitation

ACM certificates can only be used with supported AWS services. Exporting private keys is not intended. Within Kubernetes clusters, ACM remains indirect: TLS is terminated at the load balancer, not at the application or the ingress controller itself.

Internal services, mTLS scenarios, ingresses outside of AWS, or hybrid setups require additional mechanisms or separate certificate chains. Certificate management becomes fragmented: one model for external endpoints, another for internal communication.

TLS remains an upstream cloud service—not part of the platform logic.

cert-manager: Certificates as Kubernetes Resources

cert-manager takes a different approach. As an open-source component in the Kubernetes ecosystem, it automates the issuance, renewal, and rotation of certificates directly within the cluster.

Certificates are treated as native Kubernetes resources. They are available where they are actually needed: at ingresses, services, or internal workloads. Supported are open protocols like ACME and different issuers—from Let’s Encrypt to internal PKIs to external certificate authorities.

Certificate management thus becomes part of the platform—not an external service.

Fundamental Architectural Difference

The architectural difference is fundamental. cert-manager completely decouples certificate management from individual cloud providers. The same configuration works on-premises, in European clouds, or in multiple environments simultaneously.

TLS becomes a declarative platform function. Certificate lifecycle, automation, and policies are described in Kubernetes manifests, versionable, and GitOps-capable. Certificates follow the same operational principles as applications and infrastructure.

ACM cannot achieve this because it is not designed for it.

Freedom Requires Responsibility

This degree of freedom comes with responsibility. cert-manager is not a managed service. Clean cluster architecture, monitoring, backup strategies, and clear processes for issuers and trust chains are necessary.

There is no hyperscaler that abstracts complexity. Instead, a unified certificate model is created across all environments—including internal services, mTLS scenarios, and fine-grained control over lifetimes and renewal strategies.

Complexity is not avoided here but made manageable.

Relevance for Kubernetes-Centric Platforms

In Kubernetes-centric platforms with multiple clusters or hybrid infrastructures, the difference quickly becomes apparent. AWS Certificate Manager simplifies TLS for AWS endpoints but remains bound to platform boundaries.

cert-manager integrates certificates directly into the application platform. TLS becomes portable, automatable, and consistent—regardless of where clusters are operated.

Certificates are not consumed but orchestrated.

Condensed Comparison

When Each Approach is Appropriate

AWS Certificate Manager is suitable for:

• publicly accessible AWS endpoints
• classic load balancer and CDN scenarios
• low requirements for internal TLS architectures
• focus on minimal operational effort

cert-manager is suitable for:

• Kubernetes-centric platform architectures
• multi-cluster or hybrid setups
• internal service-to-service encryption
• GitOps-based operational models
• long-term platform and security strategies

Conclusion

Certificates are not a marginal topic of security. They define how consistently, automatically, and future-proof trust is implemented.

AWS Certificate Manager subordinates TLS to the cloud. cert-manager integrates certificates into the platform itself.

The difference is not functional but structural. Those who consume certificates as a cloud service accept platform boundaries. Those who understand them as part of the platform architecture create a robust foundation for secure, portable, and long-term sustainable systems.