Eine ECR Lifecycle Policy ist die Regel, die eine Container-Registry davor bewahrt, jedes je gebaute Image für immer zu speichern; ohne sie wachsen ECR, Azure Container Registry und Artifact Registry mit jedem Commit, und jedes Image ohne Tag, jedes Image eines Branches von vor zwei Jahren und jede Zwischenschicht wird je GB und Monat berechnet, bei Azure über das im Tarif enthaltene Volumen hinaus. Die Einsparung entsteht aus einer Regel, die Images ohne Tag nach Tagen und Images je Repository über eine Anzahl hinaus löscht, zuerst in der Vorschau und dann automatisch. Die Behebung gehört dem Team, das die Build-Pipeline pflegt, weil die Pipeline die Images erzeugt und die Tags vergibt.

Symptom

Die Rechnung zeigt Registry-Speicher, der mit der Zahl der Builds wächst. Bei AWS ist das lineItem/UsageType EUC1-TimedStorage-ByteHrs unter AmazonECR, je Repository als lineItem/ResourceId, dazu DataTransfer-Out-Bytes für Pulls in andere Regionen und ins Internet. Bei Azure stehen MeterCategory Container Registry mit Basic-, Standard- oder Premium-Registry-Tagen und Storage-Metern für das Volumen über dem enthaltenen. In Google Cloud trägt Artifact Registry die SKUs Artifact Registry Storage je Region und Network Egress je GB. Was Container und Registries grundsätzlich kosten, steht in Containern und Kubernetes; diese Seite behandelt die Images, die niemand mehr zieht.

neinjaJeder Build pusht ein Image;das Tag wandert weiter, dasalte Image bleibtEine Regel,die es löscht?Die Speicherposition wächst mitden Builds, je GB und Monat:TimedStorage-ByteHrs, Storageüber dem enthaltenen Volumen,Artifact Registry StorageDie Speicherposition pendeltsich bei den Images ein, diedie Regel behältWachsender Speicher bei gleich-bleibenden Pulls: das Symptom;Pulls von anderswo sind dieEgress-Position daneben
Ohne Regel legt jeder Build auf eine Speicherposition, die je GB und Monat abgerechnet wird, während die Pulls daneben gleich bleiben

So erkennen Sie es

AWS

Die Repositories mit und ohne Lifecycle-Richtlinie, und die Images ohne Tag je Repository:

for r in $(aws ecr describe-repositories --query 'repositories[].repositoryName' --output text); do
  aws ecr get-lifecycle-policy --repository-name "$r" --query 'repositoryName' --output text 2>/dev/null || echo "$r: no policy"
done
aws ecr describe-images --repository-name <repository> --filter tagStatus=UNTAGGED \
  --query 'imageDetails[].[imageDigest,imagePushedAt,imageSizeInBytes,lastRecordedPullTime]' --output table

lastRecordedPullTime sagt, wann ein Image zuletzt gezogen wurde, und imageSizeInBytes die Größe seiner Schichten. Trusted Advisor meldet unter "Amazon ECR Repository without lifecycle policy configured" jedes private Repository ohne Richtlinie (gelesen am 2026-10-21). In den Abrechnungsdaten ist der Kandidat ein Repository mit wachsendem TimedStorage-ByteHrs bei gleichbleibenden Pulls (AWS Cost and Usage Report).

Azure

Die Registries mit Tarif und Nutzung, die Repositories, und die Manifeste ohne Tag je Repository:

az acr list --query "[].{name:name, rg:resourceGroup, sku:sku.name}" -o table
az acr show-usage --name <registry> -o table
az acr manifest list-metadata --registry <registry> --name <repository> --query "[?tags==null].{digest:digest, size:imageSize, created:createdTime, lastUpdate:lastUpdateTime}" -o table

az acr show-usage zeigt die gespeicherte Menge gegen das im Tarif enthaltene Volumen. Der Befehl acr purge läuft als ACR-Task im Container der Registry, mit --filter auf Repository und Tag, --ago als Altersgrenze, --untagged für Manifeste ohne Tag und --dry-run für die Vorschau; --untagged-only löscht nur Manifeste ohne Tag (Tags und Manifeste bereinigen). Azure Advisor hat zu Registries keine Empfehlung. Im Kostenexport ist der Kandidat eine Registry mit Storage-Metern über dem Tarifvolumen (Azure-Kostenexporte).

Google Cloud

Die Repositories mit Größe und Bereinigungsrichtlinien:

gcloud artifacts repositories list --format="table(name.basename(),location,format,sizeBytes,cleanupPolicies.list())"
gcloud artifacts docker images list <location>-docker.pkg.dev/<project-id>/<repository> --include-tags \
  --filter="-tags:*" --format="table(package,version,createTime,updateTime)"

Bereinigungsrichtlinien in Artifact Registry löschen nach tagState, olderThan, newerThan und Namenspräfixen, behalten mit einer Keep-Richtlinie oder einer Zahl jüngster Versionen, und laufen zuerst als Dry-Run, dessen Ergebnis in den Audit-Logs steht (Bereinigungsrichtlinien). Einen Recommender für Registries gibt es nicht. Im Abrechnungsexport ist der Kandidat ein Repository mit wachsender Artifact Registry Storage-Position (Google-Cloud-Abrechnungsexport).

So beheben Sie es

  1. Die Regel beschließen: Images ohne Tag nach sieben Tagen löschen, je Repository die letzten 30 getaggten Images behalten, Release-Tags nach Muster ausnehmen. Wer per Digest statt per Tag zieht, darf Manifeste ohne Tag nicht löschen; die Pipeline zeigt es.

  2. Die Regel setzen und zuerst prüfen. AWS, als JSON mit Vorschau (ECR-Lifecycle-Richtlinien):

    {
      "rules": [
        {"rulePriority": 1, "description": "untagged after 7 days",
         "selection": {"tagStatus": "untagged", "countType": "sinceImagePushed", "countUnit": "days", "countNumber": 7},
         "action": {"type": "expire"}},
        {"rulePriority": 2, "description": "keep 30 images",
         "selection": {"tagStatus": "any", "countType": "imageCountMoreThan", "countNumber": 30},
         "action": {"type": "expire"}}
      ]
    }
    

    aws ecr start-lifecycle-policy-preview --repository-name <repository> --lifecycle-policy-text file://policy.json zeigt, was die Regel träfe; aws ecr put-lifecycle-policy --repository-name <repository> --lifecycle-policy-text file://policy.json setzt sie, und Images laufen binnen 24 Stunden ab. Azure: az acr run --registry <registry> --cmd "acr purge --filter '<repository>:.*' --ago 30d --untagged --dry-run" /dev/null, dann ohne --dry-run, als geplanter Task mit az acr task create --schedule "0 1 * * Sun"; bei Premium-Registries daneben die Aufbewahrungsrichtlinie für Manifeste ohne Tag. Google Cloud: gcloud artifacts repositories set-cleanup-policies <repository> --location=<location> --policy=policy.json --dry-run, dann --no-dry-run.

  3. Die Egress-Seite prüfen: Pulls aus anderen Regionen und vom Internet zahlen Datentransfer; ein Replikat in der Region des Clusters und Pull-through-Caches für Basis-Images senken ihn (Datentransfer-Optimierung).

  4. Die Vorlage korrigieren: jedes neue Repository entsteht mit Richtlinie aus demselben Modul, und die Pipeline taggt Images mit eindeutigen Tags, damit Manifeste ohne Tag sicher zu löschen sind.

Gelöschte Images verschwinden aus der Speicherposition im nächsten Tagesexport, bei ECR binnen 24 Stunden nach Ablauf.

janeinDas Team der Build-Pipelinebeschließt die Regel: Imagesohne Tag nach Tagen,getaggte über eine Zahlhinaus, Release-Tags nachMuster ausgenommenZieht die Pipelineper Digest?Manifeste ohne Tag bleiben;die Regel zählt nurgetaggte ImagesManifeste ohne Tag gehenebenfalls nach TagenDie Regel setzen und zuerstprüfen; dann läuft sieautomatischDie Egress-Seite prüfen: einReplikat in der Region desClusters, Pull-through-Cachesfür Basis-ImagesDie Vorlage korrigieren:jedes neue Repository mitRichtlinie aus demselbenModul; eindeutige Tags ausder PipelineGelöschte Imagesverschwinden aus derSpeicherposition im nächstenTagesexport
Die Regel wird mit der Pipeline beschlossen, vor dem Lauf geprüft, und die Vorlage gibt jedem neuen Repository dieselbe Regel und eindeutige Tags

Risiken und Nebenwirkungen

  • Gelöschte Images sind unwiederbringlich; ein Deployment, das ein altes Image per Digest zieht, bricht, wenn das Manifest weg ist. Die Vorschau und der Dry-Run gehören vor jede Regel.
  • Eine Zahl je Repository, imageCountMoreThan, löscht auch ein altes Release-Image, das ein Rollback braucht; Release-Tags brauchen eine Keep-Regel mit höherer Priorität oder ein Tag-Muster, das die Löschregel ausnimmt.
  • Multi-Architektur-Images bestehen aus einer Manifestliste und Manifesten je Architektur, die ohne eigenen Tag aussehen; eine Regel nach untagged darf sie nicht treffen, und ECR schützt referenzierte Manifeste, Azure und Google Cloud nur über das Alter.
  • Ein Purge mit --ago 0d und --untagged ohne Filter leert eine Registry; acr purge warnt selbst davor.
  • Ein kleineres Repository senkt die Speicherposition, nicht die Egress-Position; ein Cluster, der sein Image stündlich aus einer anderen Region zieht, kostet weiter.

So weisen Sie die Einsparung nach

Vorher: je Registry oder Repository die gespeicherten GB-Monate und ihr Betrag im letzten vollen Monat, TimedStorage-ByteHrs, die Storage-Meter über dem Tarif, Artifact Registry Storage, und daneben die Zahl der Images ohne Tag. Nachher: dieselben Positionen im ersten vollen Monat nach der Regel; die gespeicherte Menge muss auf das Niveau der Regel fallen und danach mit der Zahl der aktiven Images wachsen, nicht mit der Zahl der Builds. Die Schätzung ist die Größe der Images, die die Vorschau trifft, mal Preis je GB-Monat; die Freigabe macht sie akzeptiert, die Regel umgesetzt, und die Rechnung des Folgemonats belegt sie nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert. Die Zahl der Repositories ohne Regel ist die Kennzahl, die danach null bleibt.

Quellen

Gelesen am 2026-10-21. Amazon ECR, Lifecycle-Richtlinien, Trusted Advisor, Kostenoptimierungsprüfungen, aws ecr, Azure Container Registry, Tags und Manifeste bereinigen, az acr, Artifact Registry, Bereinigungsrichtlinien, gcloud artifacts.