AWS ECR vs. Harbor

Container-Registry als Cloud-Service oder als kontrollierbarer Plattformbaustein

Container-Registries wirken auf den ersten Blick wie ein technisches Detail. Images werden gebaut, abgelegt, gezogen – fertig. In der Praxis sind Registries jedoch ein zentraler Bestandteil moderner Plattformarchitekturen. Sie entscheiden darüber, wie Images verteilt, abgesichert, versioniert und zwischen Umgebungen bewegt werden können.

AWS Elastic Container Registry (ECR) und Harbor lösen dasselbe Grundproblem: Container-Images speichern und bereitstellen. Architektonisch stehen sie jedoch für zwei grundverschiedene Modelle. Das eine ordnet die Registry der Cloud unter. Das andere macht sie zu einem kontrollierbaren Bestandteil der eigenen Plattform.

AWS ECR: Container-Registry als Cloud-Funktion

AWS Elastic Container Registry ist der verwaltete Container-Registry -Dienst von AWS. Docker- und OCI-Images lassen sich einfach speichern und abrufen. Die Integration in IAM, ECS, EKS und CodePipeline ist tief, Lifecycle-Policies und grundlegende Image-Scans sind verfügbar. Betrieb, Skalierung und Verfügbarkeit übernimmt AWS vollständig.

Für Workloads, die konsequent in AWS laufen, ist ECR schnell eingerichtet und funktional ausreichend. Entwickler müssen sich nicht mit Storage, Replikation oder Hochverfügbarkeit beschäftigen. Die Registry ist da, funktioniert und verschwindet weitgehend im Hintergrund.

Diese Bequemlichkeit ist jedoch kein neutraler Vorteil.

Integration als strukturelle Grenze

ECR ist vollständig an AWS gebunden – infrastrukturell, organisatorisch und kostenlogisch. Zugriffskontrolle folgt dem IAM-Modell, Replikation orientiert sich an AWS-Regionen, Abrechnung skaliert mit Storage und Datenverkehr innerhalb und außerhalb von AWS.

In Kubernetes -Umgebungen außerhalb von AWS oder in hybriden Szenarien wird ECR damit zu einem externen Abhängigkeitspunkt. Die Registry ist zwar erreichbar, aber nicht Teil der eigentlichen Plattformarchitektur. Sie ist ein angebundener Cloud-Service, dessen Logik nicht mit der Cluster- oder Plattformlogik identisch ist.

Container-Images werden hier implizit an ein Ökosystem gebunden, nicht bewusst als plattformübergreifendes Artefakt behandelt.

Harbor: Registry als Plattformkomponente

Harbor verfolgt einen grundlegend anderen Ansatz. Als Open-Source-Container-Registry ist Harbor explizit für Kubernetes- und Plattformumgebungen konzipiert. Es unterstützt OCI-Images, Helm-Charts und weitere Artefakte und bringt Funktionen mit, die über reine Image-Ablage hinausgehen.

Rollenbasierte Zugriffskontrolle, Mandantenfähigkeit, Replikation zwischen Standorten, Image-Signing, Vulnerability-Scans und Policy-gesteuerte Freigaben sind integraler Bestandteil des Systems. Harbor lässt sich selbst betreiben – On-Premises, in europäischen Clouds oder in verteilten Setups – und integriert sich direkt in Kubernetes-Cluster.

Die Registry ist hier kein externer Service, sondern Teil der Plattform.

Die Rolle der Registry entscheidet

Der zentrale Unterschied liegt nicht im Feature-Vergleich, sondern in der Rolle der Registry. AWS ECR ist eine Cloud-Funktion. Harbor ist ein Plattformbaustein.

Mit Harbor werden Projekte, Repositories und Policies bewusst strukturiert. Mandantenfähigkeit ist vorgesehen, nicht nachgerüstet. Image-Promotion – etwa von Development nach Production – lässt sich explizit steuern. Replikation zwischen Standorten erfolgt unabhängig vom Cloud-Provider. Freigaben und Signaturen werden Teil der Governance, nicht ein optionales Add-on.

Die Registry wird damit Teil der Sicherheits- und Governance-Schicht – nicht nur ein technischer Speicher.

Architektonische Konsequenzen: Portabilität und Konsistenz

Diese Offenheit hat unmittelbare architektonische Auswirkungen. Container-Images bleiben portabel. Build-, Scan- und Deployment-Prozesse funktionieren identisch über mehrere Cluster und Umgebungen hinweg. Kubernetes greift auf eine Registry zu, die unter eigener Kontrolle steht und nicht an ein einzelnes Ökosystem gekoppelt ist.

Gerade in Plattformen mit GitOps-Ansatz, mehreren Clustern oder hybriden Umgebungen wird die Registry so zu einem stabilen Kernbaustein. Sie folgt der Plattformarchitektur – nicht umgekehrt.

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

Betrieb als bewusste Entscheidung

Der operative Aufwand ist bei Harbor bewusst Teil des Modells. Betrieb, Updates, Monitoring und Backups müssen geplant und umgesetzt werden. Das erhöht die Verantwortung, schafft aber Transparenz.

Kosten sind planbar, Datenhaltung nachvollziehbar, Replikationswege sichtbar. Integrationen erfolgen über offene Standards, nicht über Cloud-spezifische APIs. Optimierung bedeutet bessere Plattformarchitektur – nicht höhere Servicekosten.

ECR nimmt diesen Aufwand ab, erkauft das jedoch mit Abhängigkeit und eingeschränkter Gestaltungsfreiheit.

Verdichteter Vergleich

Wann welcher Ansatz sinnvoll ist

AWS ECR ist sinnvoll für:

• klar AWS-zentrierte Workloads
• einfache Container-Setups
• geringe Anforderungen an Portabilität
• Fokus auf minimalen Betriebsaufwand

Harbor ist sinnvoll für:

• Kubernetes- und Plattform-zentrierte Architekturen
• Multi-Cluster- oder Hybrid-Szenarien
• GitOps-basierte Deployments
• Organisationen mit Governance- und Compliance -Anforderungen
• langfristige Infrastrukturstrategien

Fazit

Container-Registries sind kein austauschbares Detail. Sie entscheiden darüber, wie Images verteilt, abgesichert und kontrolliert werden.

AWS ECR ordnet die Registry der Cloud unter. Harbor macht sie zur eigenständigen, offenen Plattformkomponente.

Der Unterschied ist nicht funktional, sondern strategisch. Wer Container-Artefakte an einen Anbieter bindet, bindet einen zentralen Teil der Lieferkette. Wer die Registry als Plattformbaustein versteht, behält Kontrolle – auch dann, wenn sich Infrastruktur, Cloud oder Organisationsstruktur ändern.