AWS Certificate Manager vs. cert-manager

Zertifikate als Cloud-Service oder als Teil der Plattformarchitektur

TLS-Zertifikate gelten oft als notwendiges Sicherheitsdetail. In modernen Plattformarchitekturen sind sie jedoch weit mehr als das. Zertifikate definieren, wo Vertrauen endet, wie Services miteinander sprechen und ob Sicherheitsmechanismen konsistent automatisiert sind – oder nur punktuell greifen.

AWS Certificate Manager (ACM) und cert-manager lösen dasselbe Grundproblem: Zertifikate ausstellen, erneuern und verwalten. Architektonisch verfolgen sie jedoch zwei grundverschiedene Ansätze. Das eine verlagert Zertifikatsmanagement in einen Cloud-Service. Das andere integriert es direkt in die Plattform.

AWS Certificate Manager: TLS als Cloud-Funktion

AWS Certificate Manager ist der verwaltete Dienst von AWS zur Ausstellung und Verwaltung von TLS-Zertifikaten. Er integriert sich nahtlos in AWS-Services wie Elastic Load Balancer, CloudFront und API Gateway. Zertifikate werden automatisch erneuert, privates Schlüsselmaterial verbleibt im AWS-Kontext, der operative Aufwand ist minimal.

Für öffentlich erreichbare AWS-Endpunkte ist ACM funktional solide und bequem. TLS wird damit weitgehend unsichtbar – es funktioniert einfach, ohne dass sich Teams mit Laufzeiten, Erneuerungen oder Schlüsselverwaltung beschäftigen müssen.

Diese Bequemlichkeit ist jedoch klar abgegrenzt.

Plattformgrenzen als strukturelle Einschränkung

ACM-Zertifikate lassen sich ausschließlich mit unterstützten AWS-Services nutzen. Der Export privater Schlüssel ist nicht vorgesehen. Innerhalb von Kubernetes-Clustern bleibt ACM daher indirekt: TLS wird am Load Balancer terminiert, nicht an der Anwendung oder dem Ingress-Controller selbst.

Interne Services, mTLS-Szenarien, Ingresses außerhalb von AWS oder hybride Setups erfordern zusätzliche Mechanismen oder separate Zertifikatsketten. Zertifikatsmanagement wird fragmentiert: ein Modell für externe Endpunkte, ein anderes für interne Kommunikation.

TLS bleibt ein vorgelagerter Cloud-Service – nicht Teil der Plattformlogik.

cert-manager: Zertifikate als Kubernetes-Ressourcen

cert-manager verfolgt einen anderen Ansatz. Als Open-Source-Komponente im Kubernetes-Ökosystem automatisiert er die Ausstellung, Erneuerung und Rotation von Zertifikaten direkt im Cluster.

Zertifikate werden als native Kubernetes-Ressourcen behandelt. Sie stehen dort zur Verfügung, wo sie tatsächlich gebraucht werden: an Ingresses, Services oder internen Workloads. Unterstützt werden offene Protokolle wie ACME sowie unterschiedliche Issuer – von Let’s Encrypt über interne PKIs bis hin zu externen Certificate Authorities.

Zertifikatsmanagement wird damit Teil der Plattform – nicht ein externer Dienst.

Fundamentaler architektonischer Unterschied

Der architektonische Unterschied ist grundlegend. cert-manager entkoppelt Zertifikatsmanagement vollständig von einzelnen Cloud-Providern. Die gleiche Konfiguration funktioniert On-Premises, in europäischen Clouds oder in mehreren Umgebungen parallel.

TLS wird zur deklarativen Plattformfunktion. Zertifikats-Lifecycle, Automatisierung und Policies sind in Kubernetes-Manifesten beschrieben, versionierbar und GitOps-fähig. Zertifikate folgen denselben Betriebsprinzipien wie Anwendungen und Infrastruktur.

ACM kann das nicht leisten, weil es dafür nicht entworfen ist.

Freiheit erfordert Verantwortung

Dieser Freiheitsgrad bringt Verantwortung mit sich. cert-manager ist kein Managed Service. Saubere Cluster-Architektur, Monitoring, Backup-Strategien und klare Prozesse für Issuer und Trust-Ketten sind notwendig.

Es gibt keinen Hyperscaler, der Komplexität abstrahiert. Dafür entsteht ein einheitliches Zertifikatsmodell über alle Umgebungen hinweg – inklusive interner Services, mTLS-Szenarien und fein granularer Kontrolle über Laufzeiten und Erneuerungsstrategien.

Komplexität wird hier nicht vermieden, sondern beherrschbar gemacht.

Relevanz für Kubernetes-zentrierte Plattformen

In Kubernetes-zentrierten Plattformen mit mehreren Clustern oder hybriden Infrastrukturen wird der Unterschied schnell sichtbar. AWS Certificate Manager vereinfacht TLS für AWS-Endpunkte, bleibt aber an Plattformgrenzen gebunden.

cert-manager integriert Zertifikate direkt in die Anwendungsplattform. TLS wird portabel, automatisierbar und konsistent – unabhängig davon, wo Cluster betrieben werden.

Zertifikate werden nicht konsumiert, sondern orchestriert.

Verdichteter Vergleich

Wann welcher Ansatz sinnvoll ist

AWS Certificate Manager ist sinnvoll für:

• öffentlich erreichbare AWS-Endpunkte
• klassische Load-Balancer- und CDN-Szenarien
• geringe Anforderungen an interne TLS-Architekturen
• Fokus auf minimalen Betriebsaufwand

cert-manager ist sinnvoll für:

• Kubernetes-zentrierte Plattformarchitekturen
• Multi-Cluster- oder Hybrid-Setups
• interne Service-to-Service-Verschlüsselung
• GitOps-basierte Betriebsmodelle
• langfristige Plattform- und Security-Strategien

Fazit

Zertifikate sind kein Randthema der Security. Sie definieren, wie konsistent, automatisiert und zukunftsfähig Vertrauen umgesetzt wird.

AWS Certificate Manager ordnet TLS der Cloud unter. cert-manager integriert Zertifikate in die Plattform selbst.

Der Unterschied ist nicht funktional, sondern strukturell. Wer Zertifikate als Cloud-Service konsumiert, akzeptiert Plattformgrenzen. Wer sie als Teil der Plattformarchitektur begreift, schafft eine belastbare Grundlage für sichere, portable und langfristig tragfähige Systeme.