ECR: Container-Images speichern und abrufen

Amazon Elastic Container Registry (ECR) ist eine vollständig verwaltete, Docker-kompatible Container-Image-Registry. Sie speichert, verwaltet und stellt Container-Images sicher innerhalb von AWS bereit. ECR macht den Betrieb einer eigenen Registry-Infrastruktur überflüssig und lässt sich nativ in ECS, EKS, Lambda (Container-Images) und CodeBuild integrieren. In ECR gespeicherte Images werden zur Sicherstellung hoher Verfügbarkeit repliziert und können automatisch auf Sicherheitslücken geprüft werden.

ECR unterstützt zwei Repository-Typen: Private Repositorys in Amazon ECR erfordern eine AWS-Authentifizierung zum Abrufen von Images und eignen sich ideal für proprietäre Anwendungs-Images. Der Zugriff wird über IAM-Richtlinien und Ressourcenrichtlinien des Repositorys gesteuert. Öffentliche Repositorys in der ECR Public Gallery (public.ecr.aws) ermöglichen nicht authentifizierte Abrufe von überall im Internet und eignen sich ideal für Open-Source-Basis-Images, öffentliche Tools und von AWS bereitgestellte Images (Lambda-Basis-Images, für ECS optimierte AMI-Images). Öffentliche Repositorys bieten ein kostenloses Abrufkontingent mit Ratenbegrenzungen für nicht authentifizierte Anfragen.

Zum Pushen oder Abrufen privater ECR-Images muss sich Docker mit AWS-Anmeldeinformationen authentifizieren. Verwenden Sie aws ecr get-login-password, um ein temporäres Authentifizierungstoken abzurufen, und leiten Sie es an docker login weiter. Das Token ist 12 Stunden gültig. Aktualisieren Sie das Token in CI/CD-Pipelines vor jedem Push. ECS-Task-Agents, Lambda und EKS-Worker-Nodes authentifizieren sich über ihre IAM-Rolle automatisch bei ECR – für Laufzeit-Abrufe in AWS-Umgebungen ist keine manuelle Anmeldung erforderlich.

Der standardmäßige Ablauf zum Pushen eines Images in ECR: (1) Das Docker-Image lokal erstellen; (2) das Image mit der URI des ECR-Repositorys taggen (Format: account.dkr.ecr.region.amazonaws.com/repo-name:tag); (3) das getaggte Image pushen. ECR speichert jede Image-Schicht separat und dedupliziert gemeinsame Schichten über mehrere Images hinweg, wodurch die Speicherkosten sinken. Durch die Verwendung von unveränderlichen Tags wird das Überschreiben eines Tags verhindert, sodass bereitgestellte Image-Versionen stabil und revisionssicher bleiben.

IMMUTABLE-Tags verhindern, dass ein Tag mit einem anderen Image überschrieben wird. Wenn die Tag-Veränderlichkeit auf IMMUTABLE gesetzt ist, schlägt das Pushen eines neuen Images mit einem bereits vorhandenen Tag fehl – Sie müssen ein neues Tag verwenden. Dies ist eine bewährte Vorgehensweise für die Produktion: Sie stellt sicher, dass :v1.2.3 immer genau auf denselben Image-Digest verweist und ermöglicht zuverlässige Rollbacks und Prüfungen. Verwenden Sie MUTABLE-Tags nur für Entwicklungszweige oder das Komfort-Tag :latest in Nicht-Produktionsumgebungen.

Aktivieren Sie scan on push, um Images beim Pushen automatisch auf bekannte CVEs zu prüfen. ECR verwendet die Integration mit Amazon Inspector (Enhanced Scanning) oder das integrierte Basic Scanning auf Basis des Open-Source-Scanners Clair. Enhanced Scanning ermöglicht eine kontinuierliche Prüfung (nicht nur beim Pushen) und deckt Betriebssystem- sowie sprachspezifische Pakete (Node.js, Python, Java) ab. Prüfen Sie die Scan-Ergebnisse in der ECR-Konsole oder über EventBridge-Benachrichtigungen an Ihr Sicherheitsteam.

ECR berechnet Speichergebühren pro GB und Monat. Ohne Verwaltung sammeln sich alte Images unbegrenzt an und erhöhen die Kosten. Lifecycle Policies lassen Images automatisch anhand von Regeln ablaufen und löschen sie: Sie können beispielsweise nur die letzten 10 getaggten Releases behalten oder nicht getaggte Images löschen, die älter als 7 Tage sind. Lifecycle Policies werden täglich ausgeführt. Dies ist besonders wichtig in CI/CD-Pipelines, die bei jedem Commit neue Images pushen und dadurch Hunderte von Images pro Woche ansammeln können.

Damit Sie Images aus einem ECR-Repository in Konto A in ECS/EKS/Lambda in Konto B abrufen können, konfigurieren Sie im ECR-Repository in Konto A eine Repository-Richtlinie (ressourcenbasierte Richtlinie). Diese gewährt dem IAM-Prinzipal aus Konto B die Berechtigung, ecr:GetDownloadUrlForLayer, ecr:BatchGetImage und ecr:BatchCheckLayerAvailability aufzurufen. Dadurch müssen Images nicht zwischen Konten kopiert werden, und eine zentrale Imageverwaltung mit verteilter Nutzung wird ermöglicht.

Die ECR-Replikation kopiert Images automatisch aus Ihrer primären Registry in Registrys anderer AWS-Regionen (und optional in andere Konten). Wenn ECS-Tasks in einer anderen Region ein Image abrufen, beziehen sie es aus der lokalen regionalen Registry. Dadurch sinken Datenübertragungskosten und die Latenz beim Abrufen von Images. Konfigurieren Sie Replikationsregeln auf Registry-Ebene und legen Sie dabei fest, welche Repositorys in welche Zielregionen und Konten repliziert werden. Die Replikation erfolgt asynchron und nahezu in Echtzeit.

ECR verschlüsselt ruhende Images mithilfe der serverseitigen Verschlüsselung. Standardmäßig wird ein von AWS verwalteter Schlüssel (AWS_MANAGED_KEY) verwendet. Für zusätzliche Kontrolle und Überprüfbarkeit konfigurieren Sie einen kundenseitig verwalteten KMS-Schlüssel (CMK). Mit einem CMK kontrollieren Sie die Schlüsselrotation, können den Zugriff durch Deaktivieren des Schlüssels widerrufen und sämtliche Entschlüsselungsvorgänge in CloudTrail prüfen. Aktivieren Sie die KMS-Verschlüsselung, wenn gesetzliche oder regulatorische Anforderungen (PCI-DSS, HIPAA, FedRAMP) kundengesteuerte Verschlüsselungsschlüssel verlangen.

Eine vollständige CI/CD-Pipeline für ECS mit ECR: (1) Ein Entwickler pusht Code zu Git; (2) CodeBuild erstellt das Docker-Image und pusht es mit einem Commit-SHA-Tag in ECR; (3) CodePipeline aktualisiert die ECS-Task-Definition mit der neuen Image-URI; (4) ECS führt ein Rolling Update des Services durch und ruft das neue Image aus ECR ab. ECS-Tasks verwenden die Task Execution Role, um sich automatisch bei ECR zu authentifizieren – für Laufzeit-Abrufe müssen in der Pipeline keine Anmeldeinformationen verwaltet werden.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Private ECR-Repositorys speichern Container-Images mit IAM-gesteuertem Zugriff, unveränderlichen Tags für Produktionsstabilität und automatischer Sicherheitslückenprüfung mit Inspector. Lifecycle Policies lassen alte und nicht getaggte Images automatisch ablaufen und senken so die Speicherkosten in aktiven CI/CD-Umgebungen. Die ECR-Replikation kopiert Images für Bereitstellungen in mehreren Regionen in andere Regionen und Konten und reduziert dabei die Abruflatenz. Als Nächstes sehen wir uns die automatische ECS-Service-Skalierung und die Integration von Load Balancing an.