Das Rätsel der ECS-Tag-Propagation gelöst

Vor Kurzem stand einer unserer Kunden vor folgendem Problem: Die Resource Tags, die er seinem Amazon Elastic Container Service (ECS) zugewiesen hatte, wurden nicht an die ECS-Tasks weitergereicht. Diese Tags waren für den Kunden entscheidend, denn er nutzte sie, um die Kosten eines bestimmten Projekts zu überwachen und zu steuern.

In AWS sind Cost Allocation Tags der Schlüssel zur Kostenverfolgung. Es gibt zwei Arten: AWS-generierte Tags, die automatisch auf Ressourcen angewendet werden, und benutzerdefinierte Tags, die Sie selbst erstellen und vergeben. Letztere bieten Flexibilität bei der Organisation Ihrer Ressourcen.

In diesem Artikel gehe ich der Ursache auf den Grund und erkläre, warum sich benutzerdefinierte Tags anders verhalten als ECS-Managed Tags. Außerdem zeige ich Ihnen, wie Sie diese Hürde meistern und Ihre Cost-Allocation-Strategie wirksam halten.

Darüber hinaus erläutere ich, wie wir das Cost-Tracking unseres Kunden mit den leistungsstarken FinOps-Tools von DoiT zusätzlich verbessert haben.

Das Problem — ECS Resource Tagging

Für ein besseres Management Ihrer Amazon-ECS-Ressourcen können Sie jeder Ressource eigene Metadaten in Form von Tags hinzufügen. Jeder Tag besteht aus einem Key und einem optionalen Value.

Unser Kunde hatte einen ECS-Cluster erstellt und einem Service zugeordnet. Der Service war mit dem benutzerdefinierten Tag WebProject:CostTracking konfiguriert.

Benutzerdefinierter Tag am ECS-Service

Uns fiel jedoch ein Problem auf: Der Service-Tag wurde nicht an die vom Service gestarteten Tasks weitergereicht. In der ECS-Konsole zeigte sich, dass die vom Service gestarteten Tasks lediglich die ECS-Managed Tags erhielten, nicht aber die benutzerdefinierten Tags des Service.

Wenn Sie ECS-Managed Tags verwenden, taggt ECS alle neu gestarteten Tasks automatisch mit den Cluster-Informationen.

ECS-Task ohne benutzerdefinierten Tag

Mit dem AWS-CLI-Befehl describe-services haben wir bestätigt, dass die Tags des Service nicht propagiert wurden.

$ aws ecs describe-services — services nginx-service — cluster web-cluster — region us-east-1 — query ‘services[*].propagateTags’ — output text

Ein Blick in die CloudTrail-Logs zum Event CreateService zeigte, dass der Parameter zur Tag-Propagation vom Service zu den Tasks nicht gesetzt war.

CloudTrail-Log: Service-Tag wird nicht propagiert

Beim Aufruf der CreateService-API geben Sie Parameter wie die Task-Definition, die gewünschte Anzahl an Tasks, den Service-Namen sowie optional Details zu Load Balancing, Service Discovery und mehr an.

Der Parameter --propagate-tags bestimmt, ob die Tags der Task-Definition oder des Service an die Tasks weitergegeben werden. Wird kein Wert angegeben, werden die Tags nicht propagiert. Standardwert ist NONE. Tags lassen sich nur während der Task-Erstellung propagieren.

Im CloudTrail-Log ist zu erkennen, dass beim Anlegen des ECS-Service der Standardwert nicht geändert wurde. Folglich wurden die Tags nicht an die vom Service erzeugten Tasks weitergereicht.

Standardmäßig ist beim Erstellen eines ECS-Service über die Konsole die Tag-Propagation an die Tasks deaktiviert.

Standardverhalten: ECS-Service propagiert keine Tags

Wenn die Tags des Service auch auf die Tasks angewendet werden sollen, müssen Sie diese Option beim Einrichten des Service im Drop-down-Menü explizit auswählen — konkret die Option zur Tag-Propagation vom Service.

Tagging-Option beim Erstellen des Service

So beheben Sie das Problem

Damit die benutzerdefinierten Tags des Service an die Tasks propagiert werden, ist ein neues Deployment nötig. Diese Aktion muss jedoch über die AWS CLI erfolgen, nicht über die AWS-Konsole.

Der Grund: Der CLI-Befehl UpdateService erlaubt die Angabe des Parameters --propagate-tags. Dieser Parameter steht in der AWS-Konsole nicht zur Verfügung — daher führt kein Weg an der CLI vorbei.

Mit dem folgenden Befehl haben wir den Service aktualisiert und ein neues Deployment erzwungen, sodass die Tags vom Service an die Tasks propagiert werden.

$ aws ecs update-service — cluster <CLUSTER_NAME> — service <SERVICE_NAME> — force-new-deployment — propagate-tags SERVICE

Im CloudTrail-Log zum Event UpdateService war anschließend zu sehen, dass der Parameter propagateTags nun auf SERVICE gesetzt war.

CloudTrail-Log: Service-Update propagiert Tags an die Tasks

Zusätzlich lässt sich das mit dem CLI-Befehl describe-services für den Service prüfen.

Beim neu deployten Task ist erkennbar, dass sowohl der ECS-Managed Tag als auch der benutzerdefinierte Tag an den Task propagiert wurden.

ECS-Tasks mit ECS-Managed und benutzerdefinierten Tags.