Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Entwurf für AWS Fargate in Amazon ECS
AWS Fargate ist eine Technologie, mit der Sie in Amazon ECS [Container](https://aws.amazon.com/containers/) ausführen können, ohne hierfür Server oder Amazon-EC2-Instance-Cluster verwalten zu müssen. Mit AWS Fargate müssen Sie keine Cluster virtueller Maschinen mehr bereitstellen, konfigurieren oder skalieren, um Container auszuführen. Auf diese Weise müssen keine Servertypen mehr ausgewählt werden, es muss nicht entschieden werden, wann die Cluster skaliert werden oder das Cluster-Packing optimiert werden.
Wenn Sie Ihre Aufgaben und Services mit Fargate ausführen, packen Sie Ihre Anwendung in Container, legen die CPU- und Arbeitsspeicheranforderungen fest, definieren Netzwerk- und IAM-Richtlinien und starten die Anwendung. Jede Fargate-Aufgabe hat ihre eigene Isolationsgrenze und teilt den zugrunde liegenden Kernel, die CPU-Ressourcen, die Arbeitsspeicherressourcen oder die Elastic-Network-Schnittstelle nicht mit einer anderen Aufgabe. Sie konfigurieren Ihre Aufgabendefinitionen für Fargate, indem Sie den `requiresCompatibilities`-Aufgabendefinitionsparameter auf `FARGATE` setzen. Weitere Informationen finden Sie unter [Capacity (Kapazität)](task_definition_parameters.md#requires_compatibilities).
Fargate bietet Plattformversionen für Amazon Linux 2 (Plattformversion 1.3.0), das Bottlerocket-Betriebssystem (Plattformversion 1.4.0) und die Full- und Core-Versionen von Microsoft Windows 2019 Server an. Sofern nicht anders angegeben, gelten die Informationen für alle Fargate-Plattformen.
Weitere Informationen über Regionen, die Linux-Container auf Fargate unterstützen, finden Sie unter [Linux-Container auf AWS Fargate](AWS_Fargate-Regions.md#linux-regions).
Weitere Informationen zu den Regionen, die Windows-Container auf Fargate unterstützen, finden Sie unter [Windows-Container auf AWS Fargate](AWS_Fargate-Regions.md#windows-regions).
## Anleitungen
Weitere Informationen zu den ersten Schritten mit der Konsole finden Sie unter:
+ [Erfahren Sie, wie Sie eine Amazon-ECS-Linux-Aufgabe für Fargate erstellen.](getting-started-fargate.md)
+ [Erfahren Sie, wie Sie eine Amazon-ECS-Windows-Aufgabe für Fargate erstellen.](Windows_fargate-getting_started.md)
Informationen zu den ersten Schritten mit dem AWS CLI finden Sie unter:
+ [Erstellen einer Amazon ECS-Linux-Aufgabe für den Fargate mit dem AWS CLI](ECS_AWSCLI_Fargate.md)
+ [Erstellen einer Amazon ECS-Windows-Aufgabe für den Fargate mit dem AWS CLI](ECS_AWSCLI_Fargate_windows.md)
## Kapazitätsanbieter
Die folgenden Kapazitätsanbieter sind verfügbar:
+ Fargate
+ Fargate Spot – Führen Sie unterbrechungstolerante Amazon-ECS-Aufgaben mit einer reduzierten Gebühr im Vergleich zum AWS Fargate-Preis aus. Fargate Spot führt Aufgaben über freie Rechenkapazität aus. Wenn die Kapazität wieder AWS benötigt wird, werden Ihre Aufgaben mit einer zweiminütigen Warnung unterbrochen. Weitere Informationen finden Sie unter [Amazon-ECS-Cluster für Fargate](fargate-capacity-providers.md).
## Aufgabendefinitionen
Fargate-Aufgaben unterstützen nicht alle verfügbaren Amazon-ECS-Aufgabendefinitionsparameter. Einige Parameter werden generell nicht unterstützt, bei anderen weicht deren Verhalten für Fargate-Aufgaben ab. Weitere Informationen finden Sie unter [CPU und Arbeitsspeicher der Aufgabe](fargate-tasks-services.md#fargate-tasks-size).
## Plattformversionen
AWS Fargate-Plattformversionen werden verwendet, um auf eine bestimmte Laufzeitumgebung für die Fargate-Task-Infrastruktur zu verweisen. Es handelt sich um eine Kombination aus der Kernel-Version und den Container-Laufzeitversionen. Sie wählen eine Plattformversion aus, wenn Sie eine Aufgabe ausführen oder wenn Sie einen Service erstellen, um eine Reihe identischer Aufgaben zu verwalten.
Neue Revisionen von Plattformversionen werden bei Änderungen der Laufzeitumgebung veröffentlicht, z. B. wenn es Kernel- oder Betriebssystem-Updates, neue Features, Fehlerbehebungen oder Sicherheits-Updates gibt. Eine Fargate-Plattformversion wird aktualisiert, indem eine neue Plattformversionsrevision erstellt wird. Jede Aufgabe wird während ihres Lebenszyklus auf einer Plattformversionsrevision ausgeführt. Wenn Sie die neueste Version der Plattformversionsrevision verwenden möchten, müssen Sie eine neue Aufgabe starten. Eine neue Aufgabe, die auf Fargate ausgeführt wird, läuft immer auf der neuesten Revision einer Plattformversion, wodurch sichergestellt wird, dass Aufgaben immer auf einer sicheren und gepatchten Infrastruktur gestartet werden.
Wenn ein Sicherheitsproblem gefunden wird, das sich auf eine bestehende Plattformversion auswirkt, wird eine neue gepatchte Version der Plattformversion AWS erstellt und Aufgaben, die auf der anfälligen Version ausgeführt werden, zurückgezogen. Möglicherweise erhalten Sie eine Benachrichtigung, dass die Ausmusterung Ihrer Fargate-Aufgaben geplant wurde. Weitere Informationen finden Sie unter [Außerbetriebnahme und Wartung von Aufgaben für AWS Fargate auf Amazon ECS](task-maintenance.md).
Weitere Informationen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
## Service-Load Balancing
Ihr Amazon-ECS-Service auf AWS Fargate kann optional zur Verwendung von Elastic Load Balancing konfiguriert werden, um Datenverkehr gleichmäßig auf die Aufgaben in Ihrem Service zu verteilen.
Amazon-ECS-Services in AWS Fargate unterstützen die Load-Balancer-Typen Application Load Balancer, Network Load Balancer und Gateway Load Balancer. Application Load Balancer werden zum Routing HTTP/HTTPS (oder Layer 7) des Datenverkehrs verwendet. Network Load Balancer werden zum Weiterleiten von TCP- oder UDP-Datenverkehr (oder Layer 4) verwendet. Weitere Informationen finden Sie unter [Verwenden von Load Balancing für die Verteilung des Service-Datenverkehrs in Amazon ECS](service-load-balancing.md).
Wenn Sie eine Zielgruppe für diese Services erstellen, müssen Sie zudem `ip` als Zieltyp auswählen, und nicht `instance`. Das liegt daran, dass Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, mit einer Elastic-Network-Schnittstelle verknüpft sind, und nicht mit einer Amazon-EC2-Instance. Weitere Informationen finden Sie unter [Verwenden von Load Balancing für die Verteilung des Service-Datenverkehrs in Amazon ECS](service-load-balancing.md).
Die Verwendung eines Network Load Balancers zur Weiterleitung von UDP-Verkehr an Ihre Amazon ECS on AWS Fargate-Aufgaben wird nur bei Verwendung der Plattformversion 1.4 oder höher unterstützt.
## Nutzungsmetriken
Sie können CloudWatch Nutzungsmetriken verwenden, um einen Überblick über die Ressourcennutzung Ihres Kontos zu erhalten. Verwenden Sie diese Kennzahlen, um Ihre aktuelle Servicenutzung in CloudWatch Diagrammen und Dashboards zu visualisieren.
AWS Fargate Die Nutzungsmetriken entsprechen den AWS Servicekontingenten. Sie können Alarme konfigurieren, mit denen Sie benachrichtigt werden, wenn sich Ihre Nutzung einem Servicekontingent nähert. Weitere Informationen zu AWS Fargate Service Quotas finden Sie unter [Amazon-ECS-Endpunkte und -Kontingente](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html) in der *Allgemeine Amazon Web Services-Referenz*.
Weitere Informationen zu AWS Fargate Nutzungsmetriken finden Sie unter [AWS FargateNutzungsmetriken](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-fargate-usage.html).
# Amazon-ECS-Sicherheitsüberlegungen für die Verwendung von Fargate
Wir empfehlen Kunden, die für ihre Aufgaben eine starke Isolierung suchen, Fargate zu verwenden. Fargate führt jede Aufgabe in einer Hardware-Virtualisierungsumgebung aus. Workloads, die auf Fargate ausgeführt werden, teilen sich keine Netzwerkschnittstellen, flüchtigen Fargate-Speicher, CPU oder Arbeitsspeicher mit anderen Aufgaben. Weitere Informationen finden Sie unter [Sicherheitsüberblick von AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf).
# Bewährte Sicherheitsmethoden für Fargate in Amazon ECS
Wir empfehlen, dass Sie die folgenden bewährten Methoden berücksichtigen, wenn Sie AWS Fargate verwenden. Weitere Hinweise finden Sie unter [Sicherheitsüberblick von AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf).
## Wird verwendet AWS KMS , um kurzlebigen Speicher für Fargate zu verschlüsseln
Sie sollten Ihren kurzlebigen Speicher entweder AWS KMS mit Ihren eigenen, vom Kunden verwalteten Schlüsseln verschlüsseln lassen. Für Aufgaben, die in Fargate mit Plattformversion `1.4.0` oder höher gehostet werden, erhält jede Aufgabe 20 GiB flüchtigen Speicher. Weitere Informationen finden Sie unter [kundenseitig verwalteter Schlüssel (CMK)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html). Sie können die Gesamtmenge des flüchtigen Speichers bis zu einem Maximum von 200 GiB erhöhen, indem Sie den `ephemeralStorage`-Parameter in Ihrer Aufgabendefinition angeben. Für solche Aufgaben, die am 28. Mai 2020 oder später gestartet wurden, wird der flüchtige Speicher mit einem AES-256-Verschlüsselungsalgorithmus unter Verwendung eines von Fargate verwalteten Schlüssels verschlüsselt.
Weitere Informationen finden Sie unter [Speicheroptionen für Amazon-ECS-Aufgaben](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html).
**Beispiel: Starten einer Aufgabe in Fargate Plattformversion 1.4.0 mit Verschlüsselung des flüchtigen Speichers**
Mit dem folgenden Befehl wird eine Aufgabe in Fargate Plattformversion 1.4 gestartet. Da diese Aufgabe als Teil des Clusters gestartet wird, verwendet sie den flüchtigen Speicher von 20 GiB, der automatisch verschlüsselt wird.
```
aws ecs run-task --cluster clustername \
--task-definition taskdefinition:version \
--count 1
--launch-type "FARGATE" \
--platform-version 1.4.0 \
--network-configuration "awsvpcConfiguration={subnets=[subnetid],securityGroups=[securitygroupid]}" \
--region region
```
## SYS\$1PTRACE-Funktion für die Ablaufverfolgung von syscall im Kernel
Die Standardkonfiguration der Linux-Funktionen, die Ihrem Container hinzugefügt oder entfernt werden, wird von Docker bereitgestellt.
Aufgaben, die auf Fargate gestartet werden, unterstützen lediglich das Hinzufügen der `SYS_PTRACE`-Kernelfunktion.
Das folgende Video zeigt, wie Sie dieses Feature über das Sysdig-[Falco](https://github.com/falcosecurity/falco)-Projekt verwenden können.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/OYGKjmFeLqI)
[Den im vorherigen Video besprochenen Code finden Sie hier. GitHub ](https://github.com/paavan98pm/ecs-fargate-pv1.4-falco)
## Verwenden Sie Amazon GuardDuty mit Fargate Runtime Monitoring
Amazon GuardDuty ist ein Service zur Bedrohungserkennung, der Ihnen hilft, Ihre Konten, Container, Workloads und die Daten in Ihrer AWS Umgebung zu schützen. Mithilfe von Modellen für maschinelles Lernen (ML) und Funktionen zur Erkennung von Anomalien und Bedrohungen werden GuardDuty kontinuierlich verschiedene Protokollquellen und Laufzeitaktivitäten überwacht, um potenzielle Sicherheitsrisiken und böswillige Aktivitäten in Ihrer Umgebung zu identifizieren und zu priorisieren.
Runtime Monitoring in GuardDuty schützt Workloads, die auf Fargate ausgeführt werden, indem es die AWS Protokoll- und Netzwerkaktivitäten kontinuierlich überwacht, um bösartiges oder nicht autorisiertes Verhalten zu identifizieren. Runtime Monitoring verwendet einen schlanken, vollständig verwalteten GuardDuty Security Agent, der das Verhalten auf dem Host analysiert, z. B. den Dateizugriff, die Prozessausführung und Netzwerkverbindungen. Dazu gehören Berechtigungseskalationen, die Verwendung kompromittierter Anmeldeinformationen, die Kommunikation mit schädlichen IP-Adressen oder Domains und das Vorhandensein von Malware auf Amazon-EC2-Instances und in Container-Workloads. Weitere Informationen finden Sie im *GuardDuty Benutzerhandbuch* unter [GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html).
# Fargate-Sicherheitsüberlegungen für Amazon ECS
Jede Aufgabe hat eine eigene Infrastrukturkapazität, da Fargate jeden Workload in einer isolierten virtuellen Umgebung ausführt. Workloads, die auf Fargate ausgeführt werden, teilen sich keine Netzwerkschnittstellen, flüchtigen Speicher, CPU oder Arbeitsspeicher mit anderen Aufgaben. Sie können mehrere Container innerhalb einer Aufgabe ausführen, darunter Anwendungs-Container und Beiwagen-Container oder einfach Beiwagen. Ein *Beiwagen* ist ein Container, der zusammen mit einem Anwendungs-Container in einer Amazon-ECS-Aufgabe ausgeführt wird. Während der Anwendungs-Container den Kernanwendungscode ausführt, können Prozesse, die in Beiwagen ausgeführt werden, die Anwendung erweitern. Mithilfe von Beiwagen können Sie Anwendungsfunktionen in spezielle Container unterteilen, sodass Sie Teile Ihrer Anwendung einfacher aktualisieren können.
Container, die Teil derselben Aufgabe sind, teilen sich Ressourcen für den Fargate-Starttyp, da diese Container immer auf demselben Host laufen und Rechenressourcen gemeinsam nutzen. Diese Container teilen sich auch den von Fargate bereitgestellten flüchtigen Speicher. Linux-Container in einer Aufgabe teilen sich Netzwerk-Namespaces, einschließlich der IP-Adresse und der Netzwerkports. Innerhalb einer Aufgabe können Container, die zur Aufgabe gehören, über localhost miteinander kommunizieren.
Die Laufzeitumgebung in Fargate verhindert, dass Sie bestimmte Controller-Features verwenden, die auf EC2-Instances unterstützt werden. Berücksichtigen Sie Folgendes, wenn Sie Workloads erstellen, die auf Fargate ausgeführt werden:
+ Keine privilegierten Container oder privilegierter Zugriff – Features wie privilegierte Container oder privilegierter Zugriff sind derzeit auf Fargate nicht verfügbar. Dies wird sich auf Anwendungsfälle wie die Ausführung von Docker in Docker auswirken.
+ Eingeschränkter Zugriff auf Linux-Funktionen – Die Umgebung, in der Container auf Fargate laufen, ist gesperrt. Zusätzliche Linux-Funktionen, wie CAP\$1SYS\$1ADMIN und CAP\$1NET\$1ADMIN, sind eingeschränkt, um eine Rechteerweiterung zu verhindern. Fargate unterstützt das Hinzufügen der Linux-Funktion [CAP\$1SYS\$1PTRACE](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#other_task_definition_params) zu Aufgaben, um innerhalb der Aufgabe bereitgestellte Beobachtbarkeits- und Sicherheitstools zur Überwachung der containerisierten Anwendung zu ermöglichen.
+ Kein Zugriff auf den zugrunde liegenden Host — Weder Kunden noch AWS Betreiber können eine Verbindung zu einem Host herstellen, auf dem Kunden-Workloads ausgeführt werden. Sie können ECS Exec verwenden, um Befehle in einem auf Fargate laufenden Container auszuführen oder eine Shell für diesen zu erhalten. Sie können ECS Exec verwenden, um Diagnoseinformationen für das Debuggen zu sammeln. Fargate verhindert auch, dass Container auf die Ressourcen des zugrunde liegenden Hosts zugreifen, z. B. auf das Dateisystem, die Geräte, das Netzwerk und die Container-Laufzeit.
+ Netzwerke — Sie können Sicherheitsgruppen und Netzwerke verwenden, ACLs um den ein- und ausgehenden Datenverkehr zu kontrollieren. Fargate-Aufgaben erhalten eine IP-Adresse aus dem konfigurierten Subnetz in Ihrer VPC.
# Fargate-Plattformversionen für Amazon ECS
AWS Fargate-Plattformversionen werden verwendet, um auf eine bestimmte Laufzeitumgebung für die Fargate-Task-Infrastruktur zu verweisen. Es handelt sich um eine Kombination aus der Kernel-Version und den Container-Laufzeitversionen. Sie wählen eine Plattformversion aus, wenn Sie eine Aufgabe ausführen oder wenn Sie einen Service erstellen, um eine Reihe identischer Aufgaben zu verwalten.
Neue Revisionen von Plattformversionen werden bei Änderungen der Laufzeitumgebung veröffentlicht, z. B. wenn es Kernel- oder Betriebssystem-Updates, neue Features, Fehlerbehebungen oder Sicherheits-Updates gibt. Eine Fargate-Plattformversion wird aktualisiert, indem eine neue Plattformversionsrevision erstellt wird. Jede Aufgabe wird während ihres Lebenszyklus auf einer Plattformversionsrevision ausgeführt. Wenn Sie die neueste Version der Plattformversionsrevision verwenden möchten, müssen Sie eine neue Aufgabe starten. Eine neue Aufgabe, die auf Fargate ausgeführt wird, läuft immer auf der neuesten Revision einer Plattformversion, wodurch sichergestellt wird, dass Aufgaben immer auf einer sicheren und gepatchten Infrastruktur gestartet werden.
Wenn ein Sicherheitsproblem gefunden wird, das sich auf eine bestehende Plattformversion auswirkt, wird eine neue gepatchte Version der Plattformversion AWS erstellt und Aufgaben, die auf der anfälligen Version ausgeführt werden, zurückgezogen. Möglicherweise erhalten Sie eine Benachrichtigung, dass die Ausmusterung Ihrer Fargate-Aufgaben geplant wurde. Weitere Informationen finden Sie unter [Außerbetriebnahme und Wartung von Aufgaben für AWS Fargate auf Amazon ECS](task-maintenance.md).
Sie geben die Plattformversion an, wenn Sie eine Aufgabe ausführen oder einen Service bereitstellen.
Bei der Angabe einer Plattformversion sollte Folgendes berücksichtigt werden:
+ Sie können eine bestimmte Versionsnummer angeben, z. B. `1.4.0` oder `LATEST`.
Die **NEUESTE** Linux-Plattformversion ist `1.4.0`.
Die **NEUESTE** Windows-Plattformversion ist `1.0.0`.
+ Wenn Sie die Plattformversion für einen Service aktualisieren möchten, erstellen Sie eine Bereitstellung. Angenommen, Sie haben einen Service, der Aufgaben auf der Linux-Plattformversion `1.3.0` ausführt. Um den Service so zu ändern, dass Aufgaben auf der Linux-Plattformversion `1.4.0` ausgeführt werden, können Sie Ihren Service aktualisieren und eine neue Plattformversion angeben. Ihre Aufgaben werden mit der neuesten Plattformversion und der neuesten Plattformversionsrevision erneut bereitgestellt. Weitere Informationen über Bereitstellungen finden Sie unter [Amazon-ECS-Dienstleistungen](ecs_services.md).
+ Wenn Ihr Service skaliert wird, ohne dass die Plattformversion aktualisiert wird, erhalten diese Aufgaben die Plattformversion, die in der aktuellen Bereitstellung des Service angegeben wurde. Angenommen, Sie haben einen Service, der Aufgaben auf der Linux-Plattformversion `1.3.0` ausführt. Wenn Sie die gewünschte Anzahl des Service erhöhen, startet der Service-Scheduler die neuen Aufgaben unter Verwendung der neuesten Plattformversionsrevision von Plattformversion `1.3.0`.
+ Neue Aufgaben werden immer auf der neuesten Version einer Plattformversion ausgeführt. Dadurch wird sichergestellt, dass sich die Aufgaben immer auf einer gesicherten und gepatchten Infrastruktur befinden.
+ Die Plattformversionsnummern für Linux-Container und Windows-Container auf Fargate sind unabhängig voneinander. Beispielsweise sind das Verhalten, die Features und die Software, die in der Plattformversion `1.0.0` für Windows-Container auf Fargate verwendet werden, nicht mit denen der Plattformversion `1.0.0` für Linux-Container auf Fargate vergleichbar.
+ Das Folgende gilt für Fargate-Windows-Plattformversionen.
Microsoft-Windows-Server-Container-Images müssen von einer bestimmten Version von Windows Server erstellt werden. Sie müssen dieselbe Version von Windows Server in der `platformFamily` auswählen, wenn Sie eine Aufgabe ausführen oder einen Service erstellen, der dem Windows-Server-Container-Image entspricht. Außerdem können Sie in der Aufgabendefinition eine passende `operatingSystemFamily` angeben, um zu verhindern, dass Aufgaben auf der falschen Windows-Version ausgeführt werden. Weitere Informationen finden Sie unter [Abgleichen der Container-Host-Version mit Container-Image-Versionen](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility#matching-container-host-version-with-container-image-versions) auf der Microsoft-Learn-Website.
# Migration zu Linux Plattformversion 1.4.0 in Amazon ECS
Folgendes sollte berücksichtigt werden, wenn Sie Ihre Amazon-ECS-Aufgaben auf Fargate von Plattformversion `1.0.0`, `1.1.0`, `1.2.0` oder `1.3.0` zur Plattformversion `1.4.0` migrieren: Es ist eine bewährte Methode, sicherzustellen, dass eine Aufgabe auf der Plattformversion `1.4.0` ordnungsgemäß funktioniert, bevor Sie die Aufgaben migrieren.
+ Das Verhalten des zu Aufgaben hinführenden und von Aufgaben wegführenden Netzwerkdatenverkehrs wurde aktualisiert. Ab Plattformversion 1.4.0 erhalten alle Amazon-ECS-Aufgaben in Fargate eine einzige Elastic-Network-Schnittstelle (als Aufgaben-ENI bezeichnet) und der gesamte Netzwerkdatenverkehr fließt innerhalb Ihrer VPC durch diese ENI. Der Netzwerkdatenverkehr ist in den VPC-Flow-Protokollen für Sie sichtbar. Weitere Informationen finden Sie unter [Netzwerkoptionen für Amazon-ECS-Aufgaben für Fargate](fargate-task-networking.md).
+ Wenn Sie Schnittstellen-VPC-Endpunkte verwenden, sollten Sie Folgendes beachten:
+ Für Container-Images, die mit Amazon ECR gehostet werden, benötigen Sie die folgenden Endpunkte. Weitere Informationen finden Sie unter [Amazon ECR-Schnittstellen VPC-Endpunkte (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) im *Amazon Elastic Container-Registry-Benutzerhandbuch*.
+ **com.amazonaws. *region*.ecr.dkr Amazon ECR VPC-Endpunkt**
+ **com.amazonaws. *region*.ecr.api Amazon ECR VPC-Endpunkt**
+ Amazon-S3-Gateway-Endpunkt
+ Wenn die Aufgabendefinition auf Secrets-Manager-Geheimnisse verweist, um sensible Daten für Ihre Container abzurufen, müssen Sie die Schnittstellen-VPC-Endpunkte für Secrets Manager erstellen. Weitere Informationen finden Sie unter [Verwenden von Secrets Manager mit VPC-Endpunkten](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html) im *AWS Secrets Manager -Benutzerhandbuch*.
+ Wenn die Aufgabendefinition auf Parameter von Systems Manager Parameter Store verweist, um sensible Daten für Ihre Container abzurufen, müssen Sie die Schnittstellen-VPC-Endpunkte für Systems Manager erstellen. Weitere Informationen finden Sie unter [Verbessern der Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten für Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html) im *Benutzerhandbuch für AWS Systems Manager *.
+ Die Sicherheitsgruppe in der Elastic-Network-Schnittstelle (ENI), die Ihrer Aufgabe zugeordnet ist, benötigt die Sicherheitsgruppenregeln, die den Datenverkehr zwischen der Aufgabe und den VPC-Endpunkten erlaubt.
# Änderungsprotokoll für Fargate-Linux-Plattformversionen
Die folgenden sind verfügbare Linux-Plattformversionen. Weitere Informationen zu Plattform-Veraltung finden Sie unter [AWS Veraltete Version der Fargate-Linux-Plattform](platform-versions-retired.md).
## 1.4.0
Im Folgenden finden Sie das Änderungsprotokoll für die Plattformversion `1.4.0`.
+ Ab dem 5. November 2020 wird jede neue Amazon-ECS-Aufgabe auf Fargate mithilfe der Plattformversion `1.4.0` gestartet und kann die folgenden Features verwenden:
+ Wenn Sie Secrets Manager zum Speichern von sensiblen Daten verwenden, können Sie einen bestimmten JSON-Schlüssel oder eine bestimmte Version eines Secrets als Umgebungsvariable oder in eine Protokollkonfiguration einfügen. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
+ Geben Sie Umgebungsvariablen im Massenformat an, indem Sie `environmentFiles`-Containerdefinition-Parameter nutzen. Weitere Informationen finden Sie unter [Eine einzelne Umgebungsvariable an einen Amazon-ECS-Container übergeben](taskdef-envfiles.md).
+ Aufgaben, die in einer VPC und einem Subnetz ausgeführt werden, für IPv6 das aktiviert ist, erhalten sowohl eine private IPv4 Adresse als auch eine IPv6 Adresse. Weitere Informationen finden Sie unter [Netzwerkoptionen für Amazon-ECS-Aufgaben für Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html).
+ Der Endpunkt der Aufgabenmetadaten Version 4 stellt zusätzliche Metadaten zu Ihrer Aufgabe und Ihrem Container bereit, einschließlich des Task-Starttyps, des Amazon-Ressourcennamens (ARN) des Containers sowie der verwendeten Protokolltreiber- und Protokolltreiberoptionen. Beim Abfragen des `/stats`-Endpunktes erhalten Sie auch Statistiken zur Netzwerkrate für Ihre Container. Weitere Informationen finden Sie unter [Version 4 des Aufgaben-Metadaten-Endpunkts](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4-fargate.html).
+ Ab dem 30. Juli 2020 wird jede neue Amazon-ECS-Aufgabe, die auf Fargate mithilfe der Plattformversion `1.4.0` gestartet wird, UDP-Datenverkehr mit einem Network Load Balancer an ihre Amazon ECS on Fargate Aufgaben weiterleiten können. Weitere Informationen finden Sie unter [Verwenden von Load Balancing für die Verteilung des Service-Datenverkehrs in Amazon ECS](service-load-balancing.md).
+ Ab dem 28. Mai 2020 wird bei jeder neuen Amazon ECS-Aufgabe, die mithilfe der Plattformversion auf Fargate gestartet `1.4.0` wird, der kurzlebige Speicher mit einem AES-256-Verschlüsselungsalgorithmus unter Verwendung eines eigenen Verschlüsselungsschlüssels verschlüsselt. AWS Weitere Informationen erhalten Sie unter [Flüchtiger Speicher für Fargate-Aufgaben für Amazon ECS.](fargate-task-storage.md) und [Speicheroptionen für Amazon-ECS-Aufgaben](using_data_volumes.md).
+ Unterstützung für die Verwendung von Amazon EFS Dateisystem-Volumes für die persistente Aufgabenspeicherung hinzugefügt. Weitere Informationen finden Sie unter [Amazon-EFS-Volumes mit Amazon ECS verwenden](efs-volumes.md).
+ Der flüchtige Aufgabenspeicher wurde für jede Aufgabe auf mindestens 20 GB erhöht. Weitere Informationen finden Sie unter [Flüchtiger Speicher für Fargate-Aufgaben für Amazon ECS.](fargate-task-storage.md).
+ Das Verhalten des zu Aufgaben hinführenden und von Aufgaben wegführenden Netzwerkdatenverkehrs wurde aktualisiert. Ab Plattformversion 1.4.0 erhalten alle Fargate-Aufgaben eine einzige Elastic-Network-Schnittstelle (als Aufgaben-ENI bezeichnet) und der gesamte Netzwerkverkehr fließt innerhalb Ihrer VPC durch diese ENI und wird durch Ihre VPC-Flow-Protokolle für Sie sichtbar. Weitere Informationen über Netzwerke für den Amazon-EC2-Starttyp finden Sie unter [Netzwerkoptionen für Amazon-ECS-Aufgaben für EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html). Weitere Informationen über Netzwerke für Fargate finden Sie unter [Netzwerkoptionen für Amazon-ECS-Aufgaben für Fargate](fargate-task-networking.md).
+ Aufgabe ENIs fügt Unterstützung für Jumbo-Frames hinzu. Netzwerkschnittstellen sind mit einer Maximum Transmission Unit (MTU) konfiguriert, die der Größe der größten Nutzlast entspricht, die in einen einzelnen Frame passt. Je größer die MTU ist, desto mehr Anwendungsnutzlast passt in ein einzelnes Frame, was den Overhead pro Frame reduziert und die Effizienz erhöht. Die Unterstützung von Jumbo-Frames reduziert den Overhead, wenn der Netzwerkpfad zwischen Ihrer Aufgabe und dem Ziel Jumbo-Frames unterstützt, wie z. B. den gesamten Datenverkehr, der in Ihrer VPC verbleibt.
+ CloudWatch Container Insights wird Netzwerkleistungskennzahlen für Fargate-Aufgaben enthalten. Weitere Informationen finden Sie unter [Amazon-ECS-Container mithilfe von Container Insights mit verbesserter Beobachtbarkeit überwachen](cloudwatch-container-insights.md).
+ Unterstützung für den Aufgabenmetadaten-Endpunkt Version 4 hinzugefügt, der zusätzliche Informationen für Ihre Fargate-Aufgaben enthält, einschließlich Netzwerkstatistiken und in welcher Availability Zone die Aufgabe ausgeführt wird. Weitere Informationen erhalten Sie unter [Amazon-ECS-Aufgabenmetadaten-Endpunkt Version 4](task-metadata-endpoint-v4.md) und [Amazon-ECS-Aufgabenmetaden-Endpunkt Version 4 für Aufgaben in Fargate](task-metadata-endpoint-v4-fargate.md).
+ Unterstützung für den Linux-Parameter`SYS_PTRACE` in Containerdefinitionen hinzugefügt. Weitere Informationen finden Sie unter [Linux-Parameter](task_definition_parameters.md#container_definition_linuxparameters).
+ Der Fargate Container-Agent ersetzt die Verwendung des Amazon-ECS-Container-Agents für alle Fargate-Aufgaben. Diese Änderung hat normalerweise keine Auswirkungen auf die Ausführung Ihrer Aufgaben.
+ Die Containerlaufzeit verwendet nun Containerd anstelle von Docker. Diese Änderung hat wahrscheinlich keine Auswirkungen auf die Ausführung Ihrer Aufgaben. Sie werden feststellen, dass einige Fehlermeldungen, die in der Containerlaufzeit entstehen, jetzt nicht mehr Docker, sondern allgemeinere Fehlern erwähnen. Weitere Informationen finden Sie unter [Aufgabe-Beendet-Fehlermeldungen in Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/stopped-task-error-codes.html).
+ Basierend auf Amazon Linux 2.
# AWS Veraltete Version der Fargate-Linux-Plattform
**Wichtig**
Wir beenden den Support für PV 1.3.0 in Fargate am 30. Juni 2026. Ab dem 15. Juni 2026 werden wir die Plattformversion 1.3.0 auf „Ausgelaufen“ setzen. Zu diesem Zeitpunkt können Sie keine neuen Aufgaben starten oder neue Services erstellen, die mit der Plattformversion 1.3.0 konfiguriert sind. Ihre vorhandenen Aufgaben werden jedoch weiterhin ausgeführt. Am 30. Juni 2026 werden wir alle verbleibenden laufenden Aufgaben beenden, die mit der Plattformversion 1.3.0 konfiguriert sind.
Informationen darüber, wie Sie zur Plattformversion 1.4 migrieren, finden Sie unter [Migration zu Linux Plattformversion 1.4.0 in Amazon ECS](platform-version-migration.md).
In der folgenden Tabelle sind Linux-Plattformversionen aufgeführt, die AWS Fargate als veraltet markiert hat oder deren Verfall geplant ist. Diese Plattformversionen bleiben bis zum veröffentlichten Veraltungs-Datum verfügbar.
Ein *erzwungenes Aktualisierungsdatum* wird für jede Plattformversion bereitgestellt, für die eine Veraltung vorgesehen ist. Am erzwungenen Aktualisierungsdatum wird jeder Dienst, der die `LATEST`-Plattformversion, die auf eine Plattformversion verweist, die für eine Veraltung vorgesehen ist, nutzt, mit der Option „neue Bereitstellung erzwingen“ aktualisiert. Wenn der Service mit der Option „Neue Bereitstellung erzwingen“ aktualisiert wird, werden alle Tasks, die auf einer Plattformversion ausgeführt werden, die für die Veraltung vorgesehen ist, angehalten und neue Tasks werden mit der Plattformversion gestartet, auf die das `LATEST`-Tag zu diesem Zeitpunkt verweist. Eigenständige Aufgaben oder Dienste mit einer expliziten Plattformversion sind vom erzwungenen Aktualisierungsdatum nicht betroffen.
Informationen darüber, wie Sie zur neuesten Plattformversion migrieren, finden Sie unter [Migration zu Linux Plattformversion 1.4.0 in Amazon ECS](platform-version-migration.md).
Sobald eine Plattformversion das *Datum der Außerbetriebnahme* erreicht, ist die Plattformversion für neue Aufgaben oder Services nicht mehr verfügbar. Alle eigenständigen Aufgaben oder Dienste, die explizit eine veraltete Plattformversion verwenden, verwenden diese Plattformversion weiter, bis die Aufgaben beendet sind. Nach dem Veraltungsdatum erhält eine veraltete Plattformversion keine Sicherheitsupdates oder Fehlerbehebungen mehr.
| Plattformversion | Datum der Aktualisierung erzwingen | Datum der Veraltung |
| --- | --- | --- |
| 1.0.0 | 26. Oktober 2020 | 14. Dezember 2020 |
| 1.1.0 | 26. Oktober 2020 | 14. Dezember 2020 |
| 1.2.0 | 26. Oktober 2020 | 14. Dezember 2020 |
| 1.3.0 | | 15. Juni 2026 |
Weitere Informationen zu aktuellen Plattformversionen finden Sie unter [Fargate-Plattformversionen für Amazon ECS](platform-fargate.md).
## Änderungsprotokoll für veraltete Fargate-Linux-Versionen
### 1.3.0
Im Folgenden finden Sie das Änderungsprotokoll für die Plattformversion `1.3.0`.
+ Ab dem 30. September 2019 unterstützt jede neue Fargate-Aufgabe, die gestartet wird, den Protokolltreiber `awsfirelens`. Konfigurieren Sie, dass Amazon ECS die FireLens Aufgabendefinitionsparameter verwendet, um Protokolle zur Protokollspeicherung und Analyse an ein AWS Service- oder AWS Partnernetzwerkziel (APN) weiterzuleiten. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle an einen AWS Service senden oder AWS Partner](using_firelens.md).
+ Aufgabenrecycling für Fargate-Aufgaben hinzugefügt. Dies ist der Prozess der Aktualisierung von Aufgaben, die Teil eines Amazon-ECS-Service sind. Weitere Informationen finden Sie unter [Einstellung und Wartung von Aufgaben für AWS Fargate auf Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-maintenance.html).
+ Ab dem 27. März 2019 bietet jede neue gestartete Fargate-Aufgabe zusätzliche Aufgabendefinitions-Parameter, mit denen Sie eine Proxy-Konfiguration, Abhängigkeiten für das Startup und Herunterfahren von Containern sowie einen Zeitbeschränkungs-Wert für das Starten und Stoppen pro Container definieren können. Weitere Informationen finden Sie unter [Proxykonfiguration](task_definition_parameters.md#proxyConfiguration), [Container-Abhängigkeit](task_definition_parameters.md#container_definition_dependson) und [Container-Timeouts](task_definition_parameters.md#container_definition_timeout).
+ Ab dem 2. April 2019 unterstützt jede neue Fargate-Aufgabe, die gestartet wird, das Einfügen sensibler Daten in Ihre Container, indem Ihre sensiblen Daten entweder in AWS Secrets Manager Secrets- oder AWS Systems Manager Parameter Store-Parametern gespeichert und dann in Ihrer Container-Definition referenziert werden. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
+ Ab dem 1. Mai 2019 unterstützt jede neue Fargate-Aufgabe, die gestartet wird, das Verweisen auf sensible Daten in der Protokollkonfiguration eines Containers mithilfe der `secretOptions`-Containerdefinitionsparameter. Weitere Informationen finden Sie unter [Sensible Daten an einen Amazon-ECS-Container übergeben](specifying-sensitive-data.md).
+ Ab dem 1. Mai 2019 unterstützt jede neue Fargate-Aufgabe, die gestartet wird, den`splunk` -Protokolltreiber zusätzlich zum `awslogs`-Protokolltreiber. Weitere Informationen finden Sie unter [Speicher und Protokollierung](task_definition_parameters.md#container_definition_storage).
+ Ab dem 9. Juli 2019 unterstützen alle neuen Fargate-Aufgaben, die gestartet werden, CloudWatch Container Insights. Weitere Informationen finden Sie unter [Amazon-ECS-Container mithilfe von Container Insights mit verbesserter Beobachtbarkeit überwachen](cloudwatch-container-insights.md).
+ Ab dem 3. Dezember 2019 wird der Spot-Kapazitätsanbieter Fargate Spot unterstützt. Weitere Informationen finden Sie unter [Amazon-ECS-Cluster für Fargate](fargate-capacity-providers.md).
+ Basierend auf Amazon Linux 2.
### 1.2.0
Im Folgenden finden Sie das Änderungsprotokoll für die Plattformversion `1.2.0`.
**Anmerkung**
Die Plattformversion `1.2.0` steht nicht mehr zur Verfügung. Weitere Informationen zu Plattform-Veraltung finden Sie unter [AWS Veraltete Version der Fargate-Linux-Plattform](#platform-versions-retired).
+ Unterstützung für die Authentifizierung mit AWS Secrets Manager privaten Registern wurde hinzugefügt. Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
### 1.1.0
Im Folgenden finden Sie das Änderungsprotokoll für die Plattformversion `1.1.0`.
**Anmerkung**
Die Plattformversion `1.1.0` steht nicht mehr zur Verfügung. Weitere Informationen zu Plattform-Veraltung finden Sie unter [AWS Veraltete Version der Fargate-Linux-Plattform](#platform-versions-retired).
+ Zusätzliche Unterstützung für den Metadatenendpunkt der Amazon-ECS-Aufgaben. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabenmetadaten für Aufgaben in Fargate verfügbar](fargate-metadata.md).
+ Unterstützung von Docker-Zustandsprüfungen in Container-Definitionen hinzugefügt. Weitere Informationen finden Sie unter [Gesundheitscheck](task_definition_parameters.md#container_definition_healthcheck).
+ Zusätzliche Unterstützung für Amazon-ECS-Serviceerkennung. Weitere Informationen finden Sie unter [Die Serviceerkennung verwenden, um Amazon-ECS-Services mithilfe von DNS-Namen zu verbinden](service-discovery.md).
### 1.0.0
Im Folgenden finden Sie das Änderungsprotokoll für die Plattformversion `1.0.0`.
**Anmerkung**
Die Plattformversion `1.0.0` steht nicht mehr zur Verfügung. Weitere Informationen zu Plattform-Veraltung finden Sie unter [AWS Veraltete Version der Fargate-Linux-Plattform](#platform-versions-retired).
+ Basierend auf Amazon Linux 2017.09.
+ Erstversion.
# Änderungsprotokoll für Fargate-Windows-Plattformversionen
Die folgenden sind verfügbare Plattformversionen für Windows-Container.
## 1.0.0
Im Folgenden finden Sie das Änderungsprotokoll für die Plattformversion `1.0.0`.
+ Erstveröffentlichung zur Support auf den folgenden Microsoft-Windows-Server-Betriebssystemen:
+ Windows Server 2019 Voll
+ Windows Server 2019 Kern
+ Windows Server 2022 Voll
+ Windows Server 2022 Kern
# Überlegungen zu Windows-Container in Fargate für Amazon ECS
Im Folgenden sind die Unterschiede und Überlegungen aufgeführt, die Sie beachten sollten, wenn Sie Windows-Container auf AWS Fargate ausführen.
Wenn Sie Aufgaben in Linux- und Windows-Containern ausführen müssen, müssen Sie separate Aufgabendefinitionen für jedes Betriebssystem erstellen.
AWS übernimmt die Verwaltung der Betriebssystem-Lizenzen, sodass Sie keine zusätzlichen Microsoft Windows Server-Lizenzen benötigen.
Windows Containers on AWS Fargate unterstützt die folgenden Betriebssysteme:
+ Windows Server 2019 Voll
+ Windows Server 2019 Kern
+ Windows Server 2022 Voll
+ Windows Server 2022 Kern
Windows-Container auf AWS Fargate unterstützen den awslogs-Treiber. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle senden an CloudWatch](using_awslogs.md).
Die folgenden Features werden auf Windows-Containern auf Fargate nicht unterstützt:
+ Amazon FSx
+ ENI-Trunking
+ g MSAs für Windows-Container
+ App-Mesh-Service und Proxy-Integration für Aufgaben
+ Firelens-Protokollrouter-Integration für Aufgaben
+ EFS-Volumes
+ EBS-Datenträger
+ Die folgenden Aufgabendefinitionsparameter:
+ `maxSwap`
+ `swappiness`
+ `environmentFiles`
+ Der Fargate-Spot-Kapazitätsanbieter
+ Image-Volumes
Die Dockerfile-Option `volume` wird ignoriert. Nutzen Sie stattdessen eine Bind-Mounts in Ihrer Aufgabendefinition. Weitere Informationen finden Sie unter [Bind-Mounts mit Amazon ECS verwenden](bind-mounts.md).
+ CPU- und Arbeitsspeicherparameter auf Aufgabenebene werden für Windows-Container ignoriert. Es wird empfohlen, für Windows-Container Ressourcen auf Container-Ebene festzulegen.
+ Speicher für Aufgabe
+ mermoryReservation in Containern
+ Richtlinien in Container neu starten
+ Sie können die platformFamily eines Services nicht ändern.
# Das Verhalten beim Abrufen von Container-Images aus Linux-Containern in Fargate für Amazon ECS
Jede Fargate-Aufgabe wird auf einer eigenen Instance mit je einem einzelnen Benutzer und Mandanten ausgeführt. Wenn Sie Linux-Container in Fargate ausführen, werden Container-Images oder Container-Image-Ebenen nicht auf der Instance zwischengespeichert. Daher muss für jedes in der Aufgabe definierte Container-Image für jede Fargate-Aufgabe das gesamte Container-Image aus der Container-Image-Registry abgerufen werden. Die Zeit, die zum Abrufen der Images benötigt wird, steht in direktem Zusammenhang mit der Zeit, die zum Starten einer Fargate-Aufgabe benötigt wird.
Berücksichtigen Sie Folgendes, um die Abrufzeit von Images zu optimieren.
**Nähe zu Container-Images**
Um die Zeit zu reduzieren, die für das Herunterladen von Container-Images benötigt wird, sollten Sie die Daten so nah wie möglich am Computer platzieren. Das Abrufen eines Container-Images über das Internet oder über das Internet AWS-Regionen kann sich auf die Download-Zeit auswirken. Es wird empfohlen, das Container-Image in derselben Region zu speichern, in der die Aufgabe ausgeführt wird. Wenn Sie das Container-Image in Amazon ECR speichern, verwenden Sie einen VPC-Schnittstellenendpunkt, um die Abrufzeit des Images weiter zu reduzieren. Weitere Informationen finden Sie unter [Schnittstellen-VPC-Endpunkte in Amazon ECR (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html) im *Amazon-ECR-Benutzerhandbuch*.
**Reduzierung der Größe des Container-Images**
Die Größe eines Container-Images wirkt sich direkt auf die Download-Zeit aus. Durch die Reduzierung der Größe des Container-Images oder der Anzahl der Container-Image-Ebenen kann die Zeit reduziert werden, die für das Herunterladen eines Images benötigt wird. Schlanke Basis-Images (wie das minimale Container-Image von Amazon Linux 2023) können erheblich kleiner sein als solche, die auf herkömmlichen, Betriebssystem-Basis-Images basieren. Weitere Informationen zum Minimal-Image finden Sie unter [AL2023 Minimal Container Image](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html) im *Amazon Linux 2023 User Guide*.
**Alternative Komprimierungsalgorithmen**
Container-Image-Ebenen werden häufig komprimiert, wenn sie in eine Container-Image-Registry übertragen werden. Durch die Komprimierung der Container-Image-Ebene wird die Datenmenge reduziert, die über das Netzwerk übertragen und in der Container-Image-Registry gespeichert werden muss. Nachdem eine Container-Image-Ebene von der Container-Laufzeit auf eine Instance heruntergeladen wurde, wird diese Ebene dekomprimiert. Der verwendete Komprimierungsalgorithmus und die Menge an v, die für die Laufzeit CPUs verfügbar ist, wirken sich auf die Zeit aus, die zum Dekomprimieren des Container-Images benötigt wird. In Fargate können Sie die Größe der Aufgabe erhöhen oder den leistungsfähigeren zstd-Komprimierungsalgorithmus nutzen, um die für die Dekomprimierung benötigte Zeit zu reduzieren. Weitere Informationen finden Sie unter [zstd on](https://github.com/facebook/zstd). GitHub Informationen zur Implementierung der Images für Fargate finden Sie unter [Reducing AWS Fargate Startup Times with zstd Compressed Container](https://aws.amazon.com/blogs/containers/reducing-aws-fargate-startup-times-with-zstd-compressed-container-images/) Images.
**Lazy-Loading-Container-Images**
Bei großen Container-Images (> 250 MB) kann es optimal sein, ein Container-Image verzögert zu laden, anstatt das gesamte Container-Image herunterzuladen. In Fargate können Sie Seekable OCI (SOCI) verwenden, um ein Container-Image verzögert aus einer Container-Image-Registry zu laden. Weitere Informationen finden Sie unter [soci-snapshotter](https://github.com/awslabs/soci-snapshotter) on GitHub und [Lazy loading container images using](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html#fargate-tasks-soci-images) Seekable OCI (SOCI).
# Das Verhalten beim Abrufen von Container-Images aus Windows-Containern in Fargate für Amazon ECS
Fargate Windows speichert das von Microsoft bereitgestellte Servercore-Basis-Image des letzten Monats und des Vormonats im Cache. Diese Bilder entsprechen der Anzahl der Patches, die an jedem Patch-Dienstag aktualisiert werden KB/Build . Am 9. April 2024 veröffentlichte Microsoft beispielsweise KB5036896 (17763.5696) für Windows Server 2019. Der vorherige Monat KB am 12. März 2024 war KB5035849 (17763.5576). Für die Plattformen `WINDOWS_SERVER_2019_CORE` und `WINDOWS_SERVER_2019_FULL` wurden also die folgenden Container-Images zwischengespeichert:
+ `mcr.microsoft.com/windows/servercore:ltsc2019`
+ ` mcr.microsoft.com/windows/servercore:10.0.17763.5696`
+ `mcr.microsoft.com/windows/servercore:10.0.17763.5576`
Darüber hinaus veröffentlichte Microsoft am 9. April 2024 KB5036909 (20348.2402) für Windows Server 2022. Der vorherige Monat KB am 12. März 2024 war KB5035857 (20348.2340). Für die Plattformen `WINDOWS_SERVER_2022_CORE` und `WINDOWS_SERVER_2022_FULL` wurden also die folgenden Container-Images zwischengespeichert:
+ `mcr.microsoft.com/windows/servercore:ltsc2022`
+ `mcr.microsoft.com/windows/servercore:10.0.20348.2402`
+ `mcr.microsoft.com/windows/servercore:10.0.20348.2340`
# Flüchtiger Speicher für Fargate-Aufgaben für Amazon ECS.
Bei der Bereitstellung AWS Fargate erhält jede Amazon ECS-Aufgabe, die auf Linux-Containern gehostet wird, den folgenden kurzlebigen Speicher für Bind-Mounts. Diese können aufgespielt und mit den Parametern `volumes`, `mountPoints` und `volumesFrom` in der Aufgabendefinition von allen Containern verwendet werden. Dies wird bei aktivierten Windows-Containern nicht unterstützt. AWS Fargate
## Plattformversionen für Fargate-Linux-Container
### Version 1.4.0 oder höher
Standardmäßig erhalten Amazon-ECS-Aufgaben, die auf Fargate mit Plattformversion `1.4.0` oder höher gehostet werden mindestens 20 GiB flüchtigen Speicher. Die Gesamtmenge des flüchtigen Speichers kann bis zu einem Maximum von 200 GiB erhöht werden. Dazu können Sie den `ephemeralStorage`-Parameter in Ihrer Aufgabendefinition festlegen.
Das gezogene, komprimierte und das unkomprimierte Container-Image für die Aufgabe wird im flüchtigen Speicher gespeichert. Um die Gesamtmenge des flüchtigen Speichers zu ermitteln, die Ihre Aufgabe verwenden muss, müssen Sie die Speichermenge, die Ihr Containerimage verwendet, von der Gesamtmenge des flüchtigen Speichers abziehen, der Ihrer Aufgabe zugewiesen ist.
Bei Aufgaben mit Plattformversion `1.4.0` oder höher, die am 28. Mai 2020 oder später gestartet wurden, wird der flüchtige Speicher mit einem AES-256-Verschlüsselungsalgorithmus verschlüsselt. Dieser Algorithmus verwendet einen AWS eigenen Verschlüsselungsschlüssel, oder Sie können Ihren eigenen, vom Kunden verwalteten Schlüssel erstellen. Weitere Informationen finden Sie unter Vom [Kunden verwaltete Schlüssel für AWS Fargate kurzlebigen Speicher](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-storage-encryption.html).
Für Aufgaben, die Plattformversion `1.4.0` oder höher verwenden und die am 18. November 2022 oder später gestartet wurden, wird die flüchtige Speichernutzung über den Aufgabenmetadaten-Endpunkt gemeldet. Ihre Anwendungen in Ihren Aufgaben können den Aufgabenmetadaten-Endpunkt-Version 4 abfragen, um deren reservierte Größe für flüchtigen Speicher und die verwendete Menge abzurufen.
Darüber hinaus werden die Größe des reservierten flüchtigen Speichers und die verwendete Menge an Container Insights gesendet, wenn Sie Amazon CloudWatch Container Insights aktivieren.
**Anmerkung**
Fargate reserviert Speicherplatz auf der Festplatte. Er wird nur von Fargate verwendet. Ihnen entstehen dafür keine Kosten. Es wird in diesen Metriken nicht angezeigt. Sie können diesen zusätzlichen Speicherplatz jedoch in anderen Tools sehen, wie z. B. `df`.
### Version 1.3.0 oder früher
Für Amazon-ECS-Aufgaben in Fargate, die Plattformversion `1.3.0` oder früher verwenden, erhält jede Aufgabe den folgenden flüchtigen Speicher.
+ 10 GB Speicher auf Docker-Ebene
**Anmerkung**
Dieser Betrag umfasst sowohl komprimierte als auch unkomprimierte Container-Image-Artifakte.
+ Zusätzliche 4 GB für Volume-Mounts. Diese können aufgespielt und mit den Parametern `volumes`, `mountPoints` und `volumesFrom` in der Aufgabendefinition von allen Containern verwendet werden.
## Plattformversionen für Fargate-Windows-Container
### Version 1.0.0 oder höher
Standardmäßig erhalten Amazon-ECS-Aufgaben, die auf Fargate mit Plattformversion `1.0.0` oder höher gehostet werden mindestens 20 GiB flüchtigen Speicher. Die Gesamtmenge des flüchtigen Speichers kann bis zu einem Maximum von 200 GiB erhöht werden. Dazu können Sie den `ephemeralStorage`-Parameter in Ihrer Aufgabendefinition festlegen.
Das gezogene, komprimierte und das unkomprimierte Container-Image für die Aufgabe wird im flüchtigen Speicher gespeichert. Um die Gesamtmenge des flüchtigen Speichers zu ermitteln, die Ihre Aufgabe verwenden muss, müssen Sie die Speichermenge, die Ihr Containerimage verwendet, von der Gesamtmenge des flüchtigen Speichers abziehen, der Ihrer Aufgabe zugewiesen ist.
Weitere Informationen finden Sie unter [Bind-Mounts mit Amazon ECS verwenden](bind-mounts.md).
# Vom Kunden verwaltete Schlüssel für AWS Fargate kurzlebigen Speicher für Amazon ECS
AWS Fargate unterstützt vom Kunden verwaltete Schlüssel zur Verschlüsselung von Daten für Amazon ECS-Aufgaben, die in kurzlebigen Speichern gespeichert sind, um Kunden, die Vorschriften beachten, bei der Einhaltung ihrer internen Sicherheitsrichtlinien zu unterstützen. Kunden profitieren weiterhin von den Serverless-Vorteilen von Fargate und bieten Compliance-Prüfern gleichzeitig mehr Einblick in die selbstverwaltete Speicherverschlüsselung. Fargate verfügt zwar standardmäßig über eine von Fargate verwaltete Verschlüsselung für den flüchtigen Speicher, Kunden können jedoch beim Verschlüsseln sensibler Daten auch eigene selbstverwaltete Schlüssel verwenden.
Sie können Ihre eigenen Schlüssel importieren AWS KMS oder die Schlüssel in erstellen. AWS KMS Diese selbstverwalteten Schlüssel werden in AWS KMS standardmäßigen AWS KMS Lebenszyklusaktionen wie Rotation, Deaktivierung und Löschen gespeichert und führen diese aus. Sie können den Zugriff auf und die Verwendung von Schlüsseln in CloudTrail Protokollen überprüfen.
Standardmäßig unterstützt der KMS-Schlüssel 50 000 Zuweisungen pro Schlüssel. Fargate verwendet einen einzigen AWS KMS Zuschuss pro vom Kunden verwalteter Schlüsselaufgabe und unterstützt somit bis zu 50.000 gleichzeitige Aufgaben für einen Schlüssel. Wenn Sie diese Anzahl erhöhen möchten, können Sie eine Erhöhung des Limits beantragen, die auf einer case-by-case bestimmten Grundlage genehmigt wird.
Fargate berechnet keine zusätzlichen Gebühren für die Verwendung von kundenverwalteten Schlüsseln. Ihnen wird nur der Standardpreis für die Verwendung von AWS KMS Schlüsseln für Speicher- und API-Anfragen berechnet.
**Topics**
+ [Einen Verschlüsselungsschlüssel für flüchtigen Fargate-Speicher für Amazon ECS erstellen](fargate-create-storage-key.md)
+ [Verwaltung von AWS KMS Schlüsseln für Fargate Ephemeral Storage für Amazon ECS](fargate-managing-kms-key.md)
# Einen Verschlüsselungsschlüssel für flüchtigen Fargate-Speicher für Amazon ECS erstellen
Erstellen Sie einen kundenverwalteten Schlüssel zum Verschlüsseln von Daten, die im flüchtigen Fargate-Speicher gespeichert sind.
**Anmerkung**
Die Verschlüsselung von flüchtigem Fargate-Speicher mit kundenverwalteten Schlüsseln ist für Windows-Aufgaben-Cluster nicht verfügbar.
Die Verschlüsselung von flüchtigem Fargate-Speicher mit kundenverwalteten Schlüsseln ist für `platformVersions`früher als `1.4.0` nicht verfügbar.
Fargate reserviert Speicherplatz auf einem flüchtigen Speicher, der nur von Fargate genutzt wird, und Ihnen wird der Speicherplatz nicht in Rechnung gestellt. Die Zuteilung kann sich von Schlüsselaufgaben unterscheiden, die nicht vom Kunden verwaltet werden, aber der Gesamtspeicherplatz bleibt gleich. Sie können sich diese Änderung in Tools wie `df` anzeigen.
Multiregionale Schlüssel werden für flüchtigen Fargate-Speicher nicht unterstützt.
KMS-Schlüsselaliase werden für flüchtigen Fargate-Speicher nicht unterstützt.
Gehen Sie wie folgt vor, um einen vom Kunden verwalteten Schlüssel (CMK) zur Verschlüsselung von kurzlebigem Speicher für Fargate in AWS KMS zu erstellen.
1. [Navigieren Sie zu /kms. https://console.aws.amazon.com](https://console.aws.amazon.com/kms)
1. Folgen Sie den Anweisungen zum [Erstellen von Schlüsseln](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) im [Entwicklerhandbuch für AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
1. Achten Sie bei der Erstellung Ihres AWS KMS Schlüssels darauf, dass Sie in den wichtigsten Richtlinien die für den Fargate-Dienst relevanten AWS KMS Betriebsberechtigungen angeben. Um Ihren kundenverwalteten Schlüssel mit Ihren Amazon-ECS-Cluster-Ressourcen zu verwenden, müssen die folgenden API-Vorgänge in der Richtlinie zugelassen sein:
+ `kms:GenerateDataKeyWithoutPlainText`‐ Rufen Sie an`GenerateDataKeyWithoutPlainText`, um aus dem bereitgestellten Schlüssel einen verschlüsselten AWS KMS Datenschlüssel zu generieren.
+ `kms:CreateGrant` – Fügt einem kundenverwalteten Schlüssel eine Zuweisung hinzu. Gewährt Kontrollzugriff auf einen bestimmten AWS KMS Schlüssel, der den Zugriff auf Grant-Operationen ermöglicht, die Amazon ECS Fargate benötigt. Weitere Informationen zum [Verwenden von Zuweisungen](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) finden Sie im [Entwicklerhandbuch für AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). Das erlaubt es Amazon ECS Fargate, Folgendes zu tun:
+ Rufen Sie an`Decrypt`, AWS KMS um den Verschlüsselungsschlüssel zum Entschlüsseln der kurzlebigen Speicherdaten zu erhalten.
+ Einen Prinzipal für die Außerbetriebnahme einrichten, damit der Service in den Status `RetireGrant` wechseln kann.
+ `kms:DescribeKey` – Stellt die Details des kundenverwalteten Schlüssels bereit, damit Amazon ECS den Schlüssel validieren kann, falls dieser symmetrisch ist und aktiviert wurde.
Das folgende Beispiel zeigt eine AWS KMS Schlüsselrichtlinie, die Sie auf den Zielschlüssel für die Verschlüsselung anwenden würden. Wenn Sie diese Beispiels-Richtlinienanweisungen verwenden möchten, ersetzen Sie die *user input placeholders* durch Ihre eigenen Informationen. Konfigurieren Sie wie immer nur die Berechtigungen, die Sie benötigen, aber Sie müssen mindestens einem Benutzer Berechtigungen gewähren AWS KMS , um Fehler zu vermeiden.
```
{
"Sid": "Allow generate data key access for Fargate tasks.",
"Effect": "Allow",
"Principal": { "Service":"fargate.amazonaws.com" },
"Action": [
"kms:GenerateDataKeyWithoutPlaintext"
],
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:ecs:clusterAccount": [
"customerAccountId"
],
"kms:EncryptionContext:aws:ecs:clusterName": [
"clusterName"
]
}
},
"Resource": "*"
},
{
"Sid": "Allow grant creation permission for Fargate tasks.",
"Effect": "Allow",
"Principal": { "Service":"fargate.amazonaws.com" },
"Action": [
"kms:CreateGrant"
],
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:ecs:clusterAccount": [
"customerAccountId"
],
"kms:EncryptionContext:aws:ecs:clusterName": [
"clusterName"
]
},
"ForAllValues:StringEquals": {
"kms:GrantOperations": [
"Decrypt"
]
}
},
"Resource": "*"
},
{
"Sid": "Allow describe key permission for cluster operator - CreateCluster and UpdateCluster.",
"Effect": "Allow",
"Principal": { "AWS":"arn:aws:iam::customerAccountId:role/customer-chosen-role" },
"Action": [
"kms:DescribeKey"
],
"Resource": "*"
}
```
Fargate-Aufgaben verwenden die Verschlüsselungskontext-Schlüssel `aws:ecs:clusterAccount` und `aws:ecs:clusterName` für kryptografische Vorgänge mit dem Schlüssel. Kunden sollten diese Berechtigungen hinzufügen, um den Zugriff auf einen bestimmten and/or Kontocluster einzuschränken. Verwenden Sie den Cluster-Namen und nicht den ARN, wenn Sie den Cluster angeben.
Weitere Informationen finden Sie unter [Verschlüsselungskontext](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) im [AWS KMS -Entwicklerhandbuch](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
Wenn Sie einen Cluster erstellen oder aktualisieren, haben Sie die Option, den Bedingungsschlüssel `fargateEphemeralStorageKmsKeyId` zu verwenden. Dieser Bedingungsschlüssel ermöglicht Kunden eine genauere Kontrolle über die IAM-Richtlinien. Aktualisierungen der `fargateEphemeralStorageKmsKeyId`-Konfiguration werden nur bei neuen Servicebereitstellungen wirksam.
Im Folgenden finden Sie ein Beispiel dafür, wie Kunden nur einem bestimmten Satz genehmigter AWS KMS Schlüssel Berechtigungen gewähren können.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:CreateCluster",
"ecs:UpdateCluster"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ecs:fargate-ephemeral-storage-kms-key": "arn:aws:kms:us-west-2:111122223333:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
}
}
]
}
```
------
Als Nächstes folgt ein Beispiel für die Ablehnung von Versuchen, AWS KMS Schlüssel zu entfernen, die bereits einem Cluster zugeordnet sind.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": [
"ecs:CreateCluster",
"ecs:UpdateCluster"
],
"Resource": "*",
"Condition": {
"Null": {
"ecs:fargate-ephemeral-storage-kms-key": "true"
}
}
}
}
```
------
Kunden können mithilfe der Befehle, oder sehen, ob ihre nicht verwalteten Aufgaben oder Serviceaufgaben mithilfe des AWS CLI `describe-tasks` Schlüssels verschlüsselt sind. `describe-cluster` `describe-services`
Weitere Informationen finden Sie unter [Bedingungsschlüssel für AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html) im [Entwicklerhandbuch für AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
------
#### [ AWS-Managementkonsole ]
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version 2.](https://console.aws.amazon.com/ecs/v2)
1. Wählen Sie im linken Navigationsbereich **Cluster** und oben rechts entweder **Cluster erstellen** oder wählen Sie einen vorhandenen Cluster aus. Wählen Sie für einen vorhandenen Cluster oben rechts die Option **Cluster aktualisieren** aus.
1. Im Abschnitt **Verschlüsselung** des Workflows haben Sie die Möglichkeit, Ihren AWS KMS Schlüssel unter **Managed Storage und **Fargate Ephemeral** Storage** auszuwählen. Sie können von hier aus auch wählen, ob Sie **einen AWS KMS Schlüssel erstellen** möchten.
1. Wählen Sie **Erstellen**, wenn Sie mit der Erstellung Ihres neuen Clusters fertig sind, oder **Aktualisieren**, wenn Sie einen vorhandenen aktualisieren wollten.
------
#### [ AWS CLI ]
Im Folgenden finden Sie ein Beispiel für die Erstellung eines Clusters und die Konfiguration Ihres kurzlebigen Fargate-Speichers mithilfe von AWS CLI (ersetzen Sie die *red* Werte durch Ihre eigenen):
```
aws ecs create-cluster --cluster clusterName \
--configuration '{"managedStorageConfiguration":{"fargateEphemeralStorageKmsKeyId":"arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"}}'
{
"cluster": {
"clusterArn": "arn:aws:ecs:us-west-2:012345678901:cluster/clusterName",
"clusterName": "clusterName",
"configuration": {
"managedStorageConfiguration": {
"fargateEphemeralStorageKmsKeyId": "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
},
"status": "ACTIVE",
"registeredContainerInstancesCount": 0,
"runningTasksCount": 0,
"pendingTasksCount": 0,
"activeServicesCount": 0,
"statistics": [],
"tags": [],
"settings": [],
"capacityProviders": [],
"defaultCapacityProviderStrategy": []
},
"clusterCount": 5
}
```
------
#### [ CloudFormation ]
Im Folgenden finden Sie eine Beispielvorlage für die Erstellung eines Clusters und die Konfiguration Ihres kurzlebigen Fargate-Speichers mithilfe von CloudFormation (ersetzen Sie die *red* Werte durch Ihre eigenen):
```
AWSTemplateFormatVersion: 2010-09-09
Resources:
MyCluster:
Type: AWS::ECS::Cluster
Properties:
ClusterName: "clusterName"
Configuration:
ManagedStorageConfiguration:
FargateEphemeralStorageKmsKeyId: "arn:aws:kms:us-west-2:012345678901:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
------
# Verwaltung von AWS KMS Schlüsseln für Fargate Ephemeral Storage für Amazon ECS
Nachdem Sie Ihren AWS KMS Schlüssel zur Verschlüsselung Ihres kurzlebigen Fargate-Speichers erstellt oder importiert haben, verwalten Sie ihn genauso wie jeden anderen Schlüssel. AWS KMS
**Automatische Rotation der Schlüssel AWS KMS**
Sie können die automatische Schlüsselrotation aktivieren oder sie manuell rotieren. Bei der automatischen Schlüsselrotation wird der Schlüssel jährlich für Sie rotiert, indem neues kryptografisches Material für den Schlüssel generiert wird. AWS KMS speichert auch alle früheren Versionen des kryptografischen Materials, sodass Sie alle Daten entschlüsseln können, für die die früheren Schlüsselversionen verwendet wurden. Jegliches rotiertes Material wird AWS KMS erst gelöscht, wenn Sie den Schlüssel löschen.
Die automatische Schlüsselrotation ist optional und kann jederzeit aktiviert oder deaktiviert werden.
**Schlüssel deaktivieren oder entziehen AWS KMS**
Wenn Sie einen vom Kunden verwalteten Schlüssel deaktivieren AWS KMS, hat dies keine Auswirkungen auf die Ausführung von Aufgaben, und sie funktionieren während ihres gesamten Lebenszyklus weiter. Wenn eine neue Aufgabe den deaktivierten oder widerrufenen Schlüssel verwendet, schlägt die Aufgabe fehl, da sie nicht auf den Schlüssel zugreifen kann. Sie sollten einen CloudWatch Alarm oder etwas Ähnliches einstellen, um sicherzustellen, dass kein deaktivierter Schlüssel zum Entschlüsseln bereits verschlüsselter Daten benötigt wird.
**Schlüssel löschen AWS KMS**
Das Löschen von Schlüsseln sollte immer der letzte Ausweg sein und sollte nur durchgeführt werden, wenn Sie sicher sind, dass der gelöschte Schlüssel nie wieder benötigt wird. Neue Aufgaben, die versuchen, den gelöschten Schlüssel zu verwenden, schlagen fehl, da sie nicht darauf zugreifen können. AWS KMS empfiehlt, einen Schlüssel zu deaktivieren, anstatt ihn zu löschen. Wenn Sie der Meinung sind, dass es notwendig ist, einen Schlüssel zu löschen, empfehlen wir, ihn zuerst zu deaktivieren und einen CloudWatch Alarm einzustellen, um sicherzustellen, dass er nicht benötigt wird. Wenn Sie einen Schlüssel löschen, haben Sie AWS KMS mindestens sieben Tage Zeit, Ihre Meinung zu ändern.
**Überprüfung des AWS KMS Schlüsselzugriffs**
Sie können CloudTrail Protokolle verwenden, um den Zugriff auf Ihren AWS KMS Schlüssel zu überprüfen. Sie können die AWS KMS Operationen`CreateGrant`,`GenerateDataKeyWithoutPlaintext`, und überprüfen`Decrypt`. Bei diesen Vorgängen wird auch das `aws:ecs:clusterAccount` und `aws:ecs:clusterName` als Teil der `EncryptionContext` angemeldeten Daten angezeigt CloudTrail.
Im Folgenden finden Sie CloudTrail Beispielereignisse für `GenerateDataKeyWithoutPlaintext``GenerateDataKeyWithoutPlaintext (DryRun)`,`CreateGrant`,`CreateGrant (DryRun)`, und `RetireGrant` (ersetzen Sie die *red* Werte durch Ihre eigenen).
------
#### [ GenerateDataKeyWithoutPlaintext ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "ec2-frontend-api.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:13Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKeyWithoutPlaintext",
"awsRegion": "us-west-2",
"sourceIPAddress": "ec2-frontend-api.amazonaws.com",
"userAgent": "ec2-frontend-api.amazonaws.com",
"requestParameters": {
"numberOfBytes": 64,
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws:ecs:clusterAccount": "account-id",
"aws:ebs:id": "vol-xxxxxxx",
"aws:ecs:clusterName": "cluster-name"
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ GenerateDataKeyWithoutPlaintext (DryRun) ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "fargate.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:11Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKeyWithoutPlaintext",
"awsRegion": "us-west-2",
"sourceIPAddress": "fargate.amazonaws.com",
"userAgent": "fargate.amazonaws.com",
"errorCode": "DryRunOperationException",
"errorMessage": "The request would have succeeded, but the DryRun option is set.",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"dryRun": true,
"numberOfBytes": 64,
"encryptionContext": {
"aws:ecs:clusterAccount": "account-id",
"aws:ecs:clusterName": "cluster-name"
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ CreateGrant ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "ec2-frontend-api.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:13Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "ec2-frontend-api.amazonaws.com",
"userAgent": "ec2-frontend-api.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"granteePrincipal": "fargate.us-west-2.amazonaws.com",
"operations": [
"Decrypt"
],
"constraints": {
"encryptionContextSubset": {
"aws:ecs:clusterAccount": "account-id",
"aws:ebs:id": "vol-xxxx",
"aws:ecs:clusterName": "cluster-name"
}
},
"retiringPrincipal": "ec2.us-west-2.amazonaws.com"
},
"responseElements": {
"grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ CreateGrant (DryRun) ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "fargate.amazonaws.com"
},
"eventTime": "2024-04-23T18:08:11Z",
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "fargate.amazonaws.com",
"userAgent": "fargate.amazonaws.com",
"errorCode": "DryRunOperationException",
"errorMessage": "The request would have succeeded, but the DryRun option is set.",
"requestParameters": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"granteePrincipal": "fargate.us-west-2.amazonaws.com",
"dryRun": true,
"operations": [
"Decrypt"
],
"constraints": {
"encryptionContextSubset": {
"aws:ecs:clusterAccount": "account-id",
"aws:ecs:clusterName": "cluster-name"
}
}
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
#### [ RetireGrant ]
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AWSService",
"invokedBy": "AWS Internal"
},
"eventTime": "2024-04-20T18:37:38Z",
"eventSource": "kms.amazonaws.com",
"eventName": "RetireGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "AWS Internal",
"userAgent": "AWS Internal",
"requestParameters": null,
"responseElements": {
"keyId": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"additionalEventData": {
"grantId": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-west-2:account-id:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "account-id",
"sharedEventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventCategory": "Management"
}
```
------
# Außerbetriebnahme und Wartung von Aufgaben für AWS Fargate auf Amazon ECS
AWS ist für die Wartung der zugrunde liegenden Infrastruktur für AWS Fargate verantwortlich. AWS bestimmt, wann eine Revision einer Plattformversion durch eine neue Version für die Infrastruktur ersetzt werden muss. Dies wird als Ausmusterung von Aufgaben bezeichnet. AWS sendet eine Benachrichtigung über die Außerbetriebnahme einer Aufgabe, wenn die Revision einer Plattformversion zurückgezogen wird. Wir aktualisieren regelmäßig unsere unterstützten Plattformversionen, um eine neue Revision einzuführen, die Aktualisierungen für die Fargate-Laufzeit-Software und die zugrunde liegenden Abhängigkeiten wie das Betriebssystem und die Container-Laufzeit enthält. Sobald eine neuere Revision verfügbar ist, nehmen wir die ältere Revision außer Betrieb, um sicherzustellen, dass alle Kunden-Workloads auf der aktuellsten Version der Fargate-Plattformversion ausgeführt werden. Wenn eine Version außer Betrieb genommen wird, werden alle Aufgaben, die für diese Version ausgeführt werden, gestoppt.
Amazon-ECS-Aufgaben können entweder als Serviceaufgaben oder als eigenständige Aufgaben kategorisiert werden. Serviceaufgaben werden im Rahmen eines Services bereitgestellt werden und vom Amazon ECS Scheduler kontrolliert. Weitere Informationen finden Sie unter [Amazon-ECS-Dienstleistungen](ecs_services.md). Eigenständige Aufgaben sind Aufgaben, die von der Amazon `RunTask` ECS-API entweder direkt oder von einem externen Scheduler gestartet werden, z. B. geplante Aufgaben (die von Amazon gestartet werden EventBridge) AWS Batch, oder AWS Step Functions. Als Reaktion auf die Außerbetriebnahme Ihrer Serviceaufgaben müssen Sie keine Maßnahmen ergreifen, da der Amazon ECS Scheduler die Aufgaben automatisch ersetzt.
Bei eigenständigen Aufgaben müssen Sie als Reaktion auf die Außerbetriebnahme der Aufgabe möglicherweise zusätzliche Bearbeitungsschritte vornehmen. Weitere Informationen finden Sie unter [Kann Amazon ECS eigenständige Aufgaben automatisch bearbeiten?](#task-retirement-standalone-tasks).
Bei Serviceaufgaben müssen Sie keine Maßnahmen ergreifen, um Aufgaben außer Betrieb zu nehmen, es sei denn, Sie möchten diese Aufgaben vorher AWS ersetzen. Wenn der Amazon ECS Scheduler die Aufgaben anhält, nutzt er den `maximumPercent` und startet eine neue Aufgabe, um die gewünschte Anzahl für den Service beizubehalten. Halten Sie sich an bewährte Methoden, um die Auswirkungen der Außerbetriebnahme von Aufgaben so gering wie möglich zu halten. Der `maximumPercent`-Standardwert für einen Service mit REPLICA Service Scheduler beträgt 200 %. Daher plant Amazon ECS, wenn es AWS Fargate anfängt, Aufgaben außer Dienst zu stellen, zunächst eine neue Aufgabe und wartet dann, bis sie ausgeführt wird, bevor eine alte Aufgabe außer Kraft gesetzt wird. Wenn Sie den `maximumPercent`-Wert auf 100 % setzen, stoppt Amazon ECS die Aufgabe zuerst und ersetzt sie dann.
Bei der Außerbetriebnahme einer eigenständigen Aufgabe wird die Aufgabe am oder nach dem Datum der Außerbetriebnahme der Aufgabe AWS beendet. Amazon ECS startet keine Ersatzaufgabe, wenn eine Aufgabe angehalten wird. Wenn Sie möchten, dass diese Aufgaben weiter ausgeführt werden, müssen Sie die laufenden Aufgaben anhalten und vor dem in der Benachrichtigung angegebenen Zeitpunkt eine Ersatzaufgabe starten. Daher empfehlen wir unseren Kunden, den Status der eigenständigen Aufgaben zu überwachen und bei Bedarf Logik zu implementieren, um die gestoppten Aufgaben zu ersetzen.
Wenn eine Aufgabe in einem der Szenarien gestoppt wird, können Sie `describe-tasks` ausführen. Der `stoppedReason` in der Antwort ist `ECS is performing maintenance on the underlying infrastructure hosting the task`.
Die Wartung der Aufgaben fällt an, wenn eine Revision der Plattformversion mit einer neuen Revision ersetzt werden muss. Wenn es ein Problem mit einem zugrunde liegenden Fargate-Host gibt, ersetzt Amazon ECS den Host ohne Benachrichtigung über die Außerbetriebnahme der Aufgabe.
## Übersicht der Benachrichtigungen über die Außerbetriebnahme von Aufgaben
Wenn eine Version einer Plattformversion als zurückgezogen werden muss AWS kennzeichnet, identifizieren wir alle Aufgaben, die auf dieser Plattformversionsrevision in allen Regionen ausgeführt werden.
Die folgende Abbildung zeigt den Lebenszyklus einer Revision der Fargate-Plattformversion von der Einführung einer neuen Revision bis zur Außerbetriebnahme der Plattformrevision.
![\[Diagramm, das den Lebenszyklus der Außerbetriebnahme von Fargate-Aufgaben zeigt.\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/images/fargate-task-retirement.png)
Die folgenden Informationen enthalten Einzelheiten.
+ Nachdem eine neue Revision der Plattformversion veröffentlicht wurde, werden alle neuen Aufgaben für diese Revision geplant.
+ Bestehende Aufgaben, die geplant wurden und ausgeführt werden, behalten für die Dauer der Aufgabe die Revision bei, der sie ursprünglich zugewiesen wurden, und werden nicht auf die neue Revision migriert.
+ Neue Aufgaben, beispielsweise im Rahmen eines Updates für einen Service oder der Außerbetriebnahme von Fargate-Aufgaben, werden auf die neueste Revision der Plattformversion übertragen, die zum Zeitpunkt des Starts verfügbar ist.
Benachrichtigungen über die Einstellung einer Aufgabe werden sowohl über das AWS Health Dashboard als auch per E-Mail an die registrierte E-Mail-Adresse gesendet und enthalten die folgenden Informationen:
+ Das Datum der Außerbetriebnahme der Aufgabe – Die Aufgabe wird an oder nach diesem Datum beendet.
+ Bei eigenständigen Aufgaben die IDs der Aufgaben.
+ Bei Dienstaufgaben die ID des Clusters, auf dem der Dienst ausgeführt wird, und die ID IDs des Dienstes.
+ Die nächsten Schritte, die Sie unternehmen müssen.
In der Regel senden wir jeweils eine Benachrichtigung pro Service und eigenständige Aufgabe in jeder AWS-Region. In bestimmten Fällen erhalten Sie jedoch möglicherweise mehr als ein Ereignis für jeden Aufgabentyp, z. B. wenn zu viele Aufgaben außer Betrieb genommen werden müssen, wodurch die Grenzen unserer Benachrichtigungsmechanismen überschritten werden.
Es gibt folgende Möglichkeiten, Aufgaben zu identifizieren, die für die Außerbetriebnahme vorgesehen sind:
+ Die Health Dashboard
AWS Health Benachrichtigungen können über Amazon EventBridge an Archivspeicher wie Amazon Simple Storage Service gesendet werden, automatisierte Aktionen wie das Ausführen einer AWS Lambda Funktion oder andere Benachrichtigungssysteme wie Amazon Simple Notification Service ausführen. Weitere Informationen finden Sie unter [AWS Health Ereignisse mit Amazon überwachen EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html). Eine Beispielkonfiguration zum Senden von Benachrichtigungen an Amazon Chime, Slack oder Microsoft Teams finden Sie im [AWS Health Aware-Repository](https://github.com/aws-samples/aws-health-aware) unter. GitHub
Das Folgende ist ein EventBridge Beispielereignis.
```
{
"version": "0",
"id": "3c268027-f43c-0171-7425-1d799EXAMPLE",
"detail-type": "AWS Health Event",
"source": "aws.health",
"account": "123456789012",
"time": "2023-08-16T23:18:51Z",
"region": "us-east-1",
"resources": [
"cluster|service",
"cluster|service"
],
"detail": {
"eventArn": "arn:aws:health:us-east-1::event/ECS/AWS_ECS_TASK_PATCHING_RETIREMENT/AWS_ECS_TASK_PATCHING_RETIREMENT_test1",
"service": "ECS",
"eventScopeCode": "ACCOUNT_SPECIFIC",
"communicationId": "7988399e2e6fb0b905ddc88e0e2de1fd17e4c9fa60349577446d95a18EXAMPLE",
"lastUpdatedTime": "Wed, 16 Aug 2023 23:18:52 GMT",
"eventRegion": "us-east-1",
"eventTypeCode": "AWS_ECS_TASK_PATCHING_RETIREMENT",
"eventTypeCategory": "scheduledChange",
"startTime": "Wed, 16 Aug 2023 23:18:51 GMT",
"endTime": "Fri, 18 Aug 2023 23:18:51 GMT",
"eventDescription": [
{
"language": "en_US",
"latestDescription": "\\nA software update has been deployed to Fargate which includes CVE patches or other critical patches. No action is required on your part. All new tasks launched automatically uses the latest software version. For existing tasks, your tasks need to be restarted in order for these updates to apply. Your tasks running as part of the following ECS Services will be automatically updated beginning Wed, 16 Aug 2023 23:18:51 GMT.\\n\\nAfter Wed, 16 Aug 2023 23:18:51 GMT, the ECS scheduler will gradually replace these tasks, respecting the deployment settings for your service. Typically, services should see little to no interruption during the update and no action is required. When AWS stops tasks, AWS uses the minimum healthy percent (1) and launches a new task in an attempt to maintain the desired count for the service. By default, the minimum healthy percent of a service is 100 percent, so a new task is started first before a task is stopped. Service tasks are routinely replaced in the same way when you scale the service or deploy configuration changes or deploy task definition revisions. If you would like to control the timing of this restart you can update the service before Wed, 16 Aug 2023 23:18:51 GMT, by running the update-service command from the ECS command-line interface specifying force-new-deployment for services using Rolling update deployment type. For example:\\n\\n$ aws ecs update-service -service service_name \\\n--cluster cluster_name -force-new-deployment\\n\\nFor services using Blue/Green deployment type with AWS CodeDeploy:\\nPlease refer to create-deployment document (2) and create new deployment using same task definition revision.\\n\\nFor further details on ECS deployment types, please refer to ECS Deployment Developer Guide (1).\\nFor further details on Fargate's update process, please refer to the AWS Fargate User Guide (3).\\nIf you have any questions or concerns, please contact AWS Support (4).\\n\\n(1) https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html\\n(2) https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html\\n(3) https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-maintenance.html\\n(4) https://aws.amazon.com/support\\n\\nA list of your affected resources(s) can be found in the 'Affected resources' tab in the 'Cluster/ Service' format in the AWS Health Dashboard. \\n\\n"
}
],
"affectedEntities": [
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c23333"
},
{
"entityValue": "arn:aws:ecs:eu-west-1:111222333444:task/examplecluster/00805ce1d81940b5a37398e5a2c25555"
}
}
]
}
}
```
+ Email
Eine E-Mail wird an die registrierte E-Mail-Adresse für die AWS-Konto ID gesendet.
Informationen darüber, wie Sie sich auf die Außerbetriebnahme von Aufgaben vorbereiten, finden Sie unter [Bereiten Sie sich auf die AWS Fargate Fargate-Aufgaben auf Amazon ECS vor](prepare-task-retirement.md).
## Kann ich die Außerbetriebnahme von Aufgaben deaktivieren?
Nein. AWS Ist im Rahmen des Modells der AWS gemeinsamen Verantwortung für die Verwaltung und Wartung der zugrunde liegenden Infrastruktur für verantwortlich AWS Fargate. Dazu gehört die Durchführung regelmäßiger Plattformupdates, um Sicherheit und Stabilität zu gewährleisten. Diese Updates werden automatisch von installiert AWS und können von den Kunden nicht abbestellt werden. Dies ist ein entscheidender Vorteil der Verwendung von a AWS Fargate im Vergleich zur Ausführung Ihrer Workloads auf EC2-Instances. Die Verantwortung für die Wartung der zugrunde liegenden Plattform liegt bei Ihnen. AWS Dieses Modell erlaubt es Ihnen, sich auf Ihre Anwendungen anstatt auf die Wartung der Infrastruktur zu konzentrieren. Durch die automatische Anwendung dieser Plattform-Updates AWS ist es möglich, die Fargate-Umgebung up-to-date sicher zu halten, ohne dass Sie als Kunde etwas unternehmen müssen. Dies trägt dazu bei, eine zuverlässige und sichere containerisierte Umgebung für die Ausführung Ihrer Workloads in Fargate bereitzustellen.
## Kann ich über andere AWS Dienste Benachrichtigungen über die Einstellung von Aufgaben erhalten?
AWS sendet eine Benachrichtigung über die Einstellung einer Aufgabe an den Health Dashboard und an den primären E-Mail-Kontakt auf der AWS-Konto. Das Health Dashboard bietet eine Reihe von Integrationen in andere AWS Dienste, darunter EventBridge. Sie können EventBridge damit die Sichtbarkeit der Hinweise automatisieren (z. B. die Nachricht an ein ChatOps Tool weiterleiten). Weitere Informationen finden Sie unter [Lösungsübersicht: Erfassung von Benachrichtigungen über die Außerbetriebnahme von Aufgaben](https://aws.amazon.com/blogs/containers/improving-operational-visibility-with-aws-fargate-task-retirement-notifications/).
## Kann ich die Außerbetriebnahme einer Aufgabe ändern, nachdem sie geplant wurde?
Nein. Der Zeitplan basiert auf der Wartezeit für die Außerbetriebnahme von Aufgaben, die standardmäßig auf 7 Tage eingestellt ist. Wenn Sie mehr Zeit benötigen, können Sie die Wartezeit auf 14 Tage konfigurieren. Weitere Informationen finden Sie unter [Schritt 2: Erfassen Sie Benachrichtigungen über die Außerbetriebnahme von Aufgaben, um Teams zu benachrichtigen und Maßnahmen zu ergreifen](prepare-task-retirement.md#prepare-task-retirement-capture-task-events).
Ab dem 18.12.2025 können Sie mit Amazon ECS Amazon [EC2 EC2-Ereignisfenster](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) für Ihre Fargate-Aufgaben konfigurieren. Wenn Sie genaue Kontrolle über den genauen Zeitpunkt der Außerbetriebnahme von Aufgaben benötigen, z. B. indem Sie sie an Wochenenden planen, um Unterbrechungen während der Geschäftszeiten zu vermeiden, können Sie Amazon EC2 EC2-Ereignisfenster für Ihre Aufgaben, Services oder Cluster konfigurieren, siehe. [Schritt 1: Legen Sie die Wartezeit für Aufgaben fest oder verwenden Sie Amazon EC2 EC2-Ereignisfenster](prepare-task-retirement.md#prepare-task-retirement-set-time) Beachten Sie, dass die Änderung dieser Konfiguration für Stilllegungen gilt, die in der future geplant sind. Derzeit geplante Außerbetriebnahmen sind davon nicht betroffen. Wenn Sie ein Amazon EC2 EC2-Ereignisfenster für Ihre Fargate-Aufgaben konfigurieren, hat dieses außerdem Vorrang vor der Konfiguration Ihrer Wartezeit für die Außerbetriebnahme von Aufgaben. Wenn Sie weitere Bedenken haben, wenden Sie sich an. Support
## Wie geht Amazon ECS mit Aufgaben um, die Teil eines Service sind?
Bei Serviceaufgaben müssen Sie auf die Außerbetriebnahme einer Aufgabe keine Maßnahmen ergreifen, es sei denn, Sie möchten diese Aufgaben vorher AWS ersetzen. Wenn der Amazon ECS Scheduler die Aufgaben anhält, nutzt er den minimalen fehlerfreien Prozentsatz und startet eine neue Aufgabe, um die gewünschte Anzahl für den Service beizubehalten. Um die Auswirkungen der Außerbetriebnahme von Fargate-Aufgaben so gering wie möglich zu halten, sollten Workloads gemäß den bewährten Methoden von Amazon ECS bereitgestellt werden. Wenn Kunden beispielsweise eine statuslose Anwendung als Amazon ECS-Service bereitstellen, z. B. als Web- oder API-Server, sollten sie mehrere Task-Replikate bereitstellen und diese minimumHealthyPercent auf 100% setzen. Der Standardwert für den minimalen fehlerfreien Prozentsatz ist 100 Prozent. Daher plant Amazon ECS, wenn Fargate anfängt, Aufgaben außer Betrieb zu nehmen, zunächst eine neue Aufgabe und wartet dann, bis sie ausgeführt wird, bevor eine alte Aufgabe außer Betrieb genommen wird. Serviceaufgaben werden bei der Außerbetriebnahme von Aufgaben routinemäßig auf die gleiche Weise ersetzt, wenn Sie den Service skalieren, Konfigurationsänderungen bereitstellen oder Revisionen der Aufgabendefinition bereitstellen. Informationen zum Vorbereiten auf die Außerbetriebnahme von Aufgaben finden Sie unter [Bereiten Sie sich auf die AWS Fargate Fargate-Aufgaben auf Amazon ECS vor](prepare-task-retirement.md).
## Kann Amazon ECS eigenständige Aufgaben automatisch bearbeiten?
Nein. AWS kann keine Ersatzaufgabe für eigenständige Aufgaben erstellen`RunTask`, die von geplanten Aufgaben (z. B. über EventBridge Scheduler) AWS Batch, oder AWS Step Functions gestartet werden. Amazon ECS verwaltet nur Aufgaben, die Teil eines Service sind.
## Fehlerbehebung bei der Verfügbarkeit von Services während der Außerbetriebnahme von Aufgaben
Wenn Amazon ECS während der Außerbetriebnahme einer Aufgabe keine Ersatzaufgabe starten kann, kann sich dies auf Ihre Serviceverfügbarkeit auswirken. Dies kann auf eine falsche Kundenkonfiguration zurückzuführen sein, z. B.:
+ Fehlende oder fehlerhaft konfigurierte IAM-Rollen
+ Unzureichende Kapazität in den Ziel-Subnetzen
+ Sicherheitsgruppen falsch konfiguriert
+ Fehler in Aufgabendefinitionen
Wenn Amazon ECS keine Ersatzaufgaben starten kann, werden die außer Betrieb genommenen Aufgaben ersatzlos gestoppt, was die verfügbare Kapazität Ihres Services reduziert und möglicherweise zu Serviceunterbrechungen führen kann. Überwachen Sie die Anzahl der Aufgaben Ihres Services und die CloudWatch Amazon-Metriken, um sicherzustellen, dass Ersatzaufgaben während der Außerbetriebnahme erfolgreich gestartet werden.
# Bereiten Sie sich auf die AWS Fargate Fargate-Aufgaben auf Amazon ECS vor
Gehen Sie wie folgt vor, um sich auf die Außerbetriebnahme von Aufgaben vorzubereiten:
1. Legen Sie die Wartezeit für die Außerbetriebnahme von Aufgaben fest oder verwenden Sie Amazon EC2 EC2-Ereignisfenster.
1. Erfassen Sie Benachrichtigungen zur Außerbetriebnahme von Aufgaben, um Teammitglieder zu benachrichtigen.
1. Sie können sicherstellen, dass alle Aufgaben Ihrer Services auf der neuesten Plattformversion ausgeführt werden, indem Sie den Service mit der Option zur erzwungenen Bereitstellung aktualisieren. Dieser Schritt ist optional.
## Schritt 1: Legen Sie die Wartezeit für Aufgaben fest oder verwenden Sie Amazon EC2 EC2-Ereignisfenster
Sie haben zwei Kontoeinstellungsoptionen, um den Zeitpunkt zu konfigurieren, zu dem Fargate die Stilllegung von Aufgaben startet: und. `fargateTaskRetirementWaitPeriod` `fargateEventWindows`
**Verwenden Sie die Kontoeinstellungen fargateTaskRetirement WaitPeriod **
Sie können den Zeitpunkt konfigurieren, zu dem Fargate mit der Außerbetriebnahme der Aufgabe beginnt. Die Standard-Wartezeit beträgt 7 Tage. Wählen Sie für Workloads, die eine sofortige Anwendung der Updates erfordern, die Einstellung „Sofort“ (`0`). Wenn Sie mehr Zeit benötigen, konfigurieren Sie die `7` Option oder `14` Tag.
Wir empfehlen Ihnen, eine kürzere Wartezeit zu wählen, damit Sie neuere Versionen der Plattformversionen früher erwerben können.
Konfigurieren Sie die Wartezeit, indem Sie `put-account-setting-default` oder `put-account-setting` als Root-Benutzer oder Administrator ausführen. Verwenden Sie die Option `fargateTaskRetirementWaitPeriod` für `name` und die Option `value`, die auf einen der folgenden Werte eingestellt ist:
+ `0`- AWS sendet die Benachrichtigung und beginnt sofort, die betroffenen Aufgaben zurückzuziehen.
+ `7`- AWS sendet die Benachrichtigung und wartet 7 Kalendertage, bevor mit der Außerbetriebnahme der betroffenen Aufgaben begonnen wird. Dies ist die Standardeinstellung.
+ `14` – AWS sendet die Benachrichtigung und wartet 14 Kalendertage, bevor mit der Außerbetriebnahme der betroffenen Aufgaben begonnen wird.
Weitere Informationen finden Sie unter [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)und [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)in der *Amazon Elastic Container Service API-Referenz*.
**Verwenden Sie die fargateEventWindows Kontoeinstellungen**
Ab dem 18.12.2025 können Sie mit Amazon ECS Amazon [EC2 EC2-Ereignisfenster](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html) für Ihre Fargate-Aufgaben konfigurieren. Wenn Sie genaue Kontrolle über den genauen Zeitpunkt der Außerbetriebnahme von Aufgaben benötigen, z. B. indem Sie sie an Wochenenden planen, um Unterbrechungen während der Geschäftszeiten zu vermeiden, können Sie Amazon EC2 EC2-Ereignisfenster für Ihre Aufgaben, Services oder Cluster konfigurieren.
Wenn Sie Ereignisfenster verwenden, stellt Fargate sicher, dass Ihre Aufgaben mindestens 3 Tage lang ausgeführt werden, bevor sie innerhalb des nächsten verfügbaren Zeitfensters zurückgezogen werden, sofern sie nicht durch benutzerinitiierte Aktionen oder kritische Integritätsereignisse wie eine Verschlechterung der zugrunde liegenden Hardware gestoppt werden.
Stellen Sie die Kontoeinstellung `fargateEventWindows` auf `enabled` ein. Sie können eine der folgenden Optionen verwenden APIs: `put-account-setting-default` oder `put-account-setting` als Root-Benutzer oder Administratorbenutzer.
Jedes Amazon EC2 EC2-Ereignisfenster muss mindestens 4 Stunden pro Woche geöffnet sein, und jeder Zeitraum muss mindestens 2 Stunden lang sein. Für große Cluster und Services empfehlen wir, Ereignisfenster mit langer Dauer (8 Stunden oder mehr) oder häufigeren Zeiträumen zu konfigurieren, die mindestens einmal alle 3 Tage auftreten. Weitere Überlegungen zu Amazon EC2 EC2-Ereignisfenstern finden Sie im [Benutzerhandbuch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/event-windows.html#event-windows-considerations). Es AWS Fargate stellt sicher, dass Ihre Aufgaben mindestens 3 Tage lang ausgeführt werden, bevor sie eingestellt werden, sofern sie nicht durch vom Benutzer initiierte Aktionen oder kritische Integritätsereignisse wie eine Verschlechterung der zugrunde liegenden Hardware gestoppt werden.
**Wichtig**
Es empfiehlt sich, Aufgaben innerhalb des Ereignisfensters zu ersetzen. Wenn Sie feststellen, dass Aufgaben außerhalb Ihres Veranstaltungsfensters zurückgezogen werden, sollten Sie erwägen, die Dauer zu verlängern (8 Stunden oder mehr) oder die Häufigkeit zu erhöhen (mindestens einmal alle 3 Tage).
So wenden Sie Amazon EC2 EC2-Ereignisfenster auf Ihre Abmeldungen von Fargate-Aufgaben an:
+ Stellen Sie die Kontoeinstellung `fargateEventWindows` auf `enabled` ein. Sie können eine der folgenden Optionen verwenden APIs: `put-account-setting-default` oder `put-account-setting` als Root-Benutzer oder als Administratorbenutzer. Beachten Sie, dass dies eine einmalige Aktivierung für die Nutzung der Amazon EC2 EC2-Event-Fenster-Funktion für Ihre Fargate-Aufgaben ist.
+ Erstellen Sie über die AWS-Konsole oder die AWS-CLI ein Amazon EC2 EC2-Ereignisfenster. Verwenden Sie die `create-instance-event-window` EC2-API mit Zeitbereichen oder Cron-Ausdrücken, um ein Ereignisfenster mit CLI zu erstellen. Notieren Sie sich das `InstanceEventWindowId` aus der Antwort.
```
aws ec2 create-instance-event-window \
--time-range StartWeekDay=monday,StartHour=2,EndWeekDay=wednesday,EndHour=8 \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
Alternativ können Sie Cron-Ausdrücke verwenden, wenn Sie EC2-Ereignisfenster erstellen.
```
aws ec2 create-instance-event-window \
--cron-expression "* 21-23 * * 2,3" \
--tag-specifications "ResourceType=instance-event-window,Tags=[{Key=K1,Value=V1" \
--name myEventWindowName
```
+ Anschließend können Sie das Ereignisfenster mithilfe der `associate-instance-event-window` EC2-API bestimmten Diensten, Clustern oder allen Aufgaben in Ihrem Konto zuordnen.
+ Für ECS-Serviceaufgaben
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:serviceArn,Value=your-service-arn}]"
```
+ Für ECS-Cluster
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:clusterArn,Value=your-cluster-arn}]"
```
+ Um allen Aufgaben im Konto ein Ereignisfenster zuzuordnen
```
aws ec2 associate-instance-event-window \
--instance-event-window-id iew-0abcdef1234567890 \
--association-target "InstanceTags=[{Key=aws:ecs:fargateTask,Value=true}]"
```
Sie können mehr als ein Schlüssel-Wert-Paar verwenden, um ein Ereignisfenster mehreren Diensten oder Clustern zuzuordnen.
Fargate wählt das Ereignisfenster für jede Aufgabe in der folgenden Reihenfolge aus:
+ Wenn dem Dienst der Aufgabe ein Ereignisfenster zugeordnet ist, wird dieses verwendet. Dies gilt nicht für eigenständige oder nicht verwaltete Aufgaben.
+ Wenn dem Cluster der Aufgabe ein Ereignisfenster zugeordnet ist, wird dieses verwendet.
+ Wenn für alle Fargate-Aufgaben ein Ereignisfenster festgelegt ist, wird dieses verwendet.
+ Die `fargateTaskRetirementWaitPeriod` Einstellung wird verwendet, wenn keines der Ereignisfenster mit der Aufgabe übereinstimmt.
**Konfiguration von Ereignisfenstern für die Fargate-Aufgabenwartung**
Stellen Sie sich einen Fall vor, in dem Sie mehrere ECS-Services auf Fargate mit unterschiedlichen Verfügbarkeitsanforderungen ausführen. Sie möchten eine präzise Kontrolle über die Stilllegung von Aufgaben haben. Sie können mehrere Ereignisfenster wie folgt konfigurieren:
+ **Standardwartung für alle Fargate-Aufgaben**: Erstellen Sie ein Ereignisfenster für routinemäßige Wartungsarbeiten außerhalb der Spitzenzeiten (täglich von 12 bis 4 Uhr) und ordnen Sie es mithilfe des Tags allen Fargate-Aufgaben zu. ` aws:ecs:fargateTask`
+ **Wartung nur am Wochenende für Entwicklungscluster**: Erstellen Sie für einen Entwicklungscluster mit Diensten, die Unterbrechungen am Wochenende tolerieren können, ein 24-Stunden-Wochenendfenster (Samstag und Sonntag, den ganzen Tag) und ordnen Sie es dem Cluster zu, indem Sie das `aws:ecs:clusterArn` Tag mit Ihrem Cluster-ARN verwenden.
+ **Eingeschränktes Zeitfenster für geschäftskritische Dienste**: Bei einem geschäftskritischen Zahlungsabwicklungsservice, der an Wochentagen eine hohe Verfügbarkeit erfordert, beschränken Sie die Wartung auf die frühen Morgenstunden am Wochenende (Samstag und Sonntag, 12:00 bis 04:00 Uhr) und ordnen Sie sie dem jeweiligen Dienst zu, indem Sie das Tag mit Ihrem Service-ARN verwenden. `aws:ecs:serviceArn`
Bei dieser Konfiguration verwendet der Zahlungsdienst sein spezielles Wochenendfenster, die Dienste und Aufgaben des Entwicklungsclusters verwenden das 24-Stunden-Fenster am Wochenende und alle anderen Fargate-Aufgaben verwenden das standardmäßige tägliche Wartungsfenster.
Weitere Informationen finden Sie unter [put-account-setting-default](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting-default.html)und [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html)in der *Amazon Elastic Container Service API-Referenz*.
## Schritt 2: Erfassen Sie Benachrichtigungen über die Außerbetriebnahme von Aufgaben, um Teams zu benachrichtigen und Maßnahmen zu ergreifen
Wenn eine Aufgabe bevorsteht, AWS sendet eine Benachrichtigung über die Außerbetriebnahme einer Aufgabe an das AWS Health Dashboard und an den primären E-Mail-Kontakt auf der AWS-Konto. Das AWS Health Dashboard bietet eine Reihe von Integrationen in andere AWS Dienste, darunter Amazon EventBridge. Sie können EventBridge es verwenden, um anhand einer Benachrichtigung über die Einstellung einer Aufgabe Automatisierungen zu erstellen, z. B. um die Sichtbarkeit der bevorstehenden Außerbetriebnahme zu erhöhen, indem Sie die Nachricht an ein ChatOps Tool weiterleiten. AWS Health Aware ist eine Ressource, die zeigt, wie leistungsfähig das AWS Health Dashboard ist und wie Benachrichtigungen im gesamten Unternehmen verteilt werden können. Sie können eine Benachrichtigung über die Außerbetriebnahme einer Aufgabe an eine Chat-Anwendung wie Slack weiterleiten.
In der folgenden Abbildung ist die Lösungsübersicht dargestellt.
![\[Diagramm, das die Fargate-Lösung zur Erfassung von Benachrichtigungen über die Außerbetriebnahme von Fargate-Aufgaben zeigt.\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/images/fargate-task-retirement-solution.png)
Die folgenden Informationen enthalten Einzelheiten.
+ Fargate sendet die Benachrichtigung über die Außerbetriebnahme der Aufgabe an das AWS Health -Dashboard.
+ Das AWS Health Dashboard sendet E-Mails an den primären E-Mail-Kontakt auf der AWS-Konto, und benachrichtigt EventBridge.
+ EventBridge hat eine Regel, die die Benachrichtigung über den Ruhestand erfasst.
Die Regel sucht nach Ereignissen mit dem Ereignisdetails-Typ: `"AWS Health Event" and the Event Detail Type Code: "AWS_ECS_TASK_PATCHING_RETIREMENT"`
+ Die Regel löst eine Lambda-Funktion aus, die die Informationen mithilfe eines eingehenden Slack-Webhooks an Slack weiterleitet. Weitere Informationen finden Sie unter [Eingehende Webhooks](https://slack.com/marketplace/A0F7XDUAZ-incoming-webhooks).
Ein Codebeispiel finden Sie unter [Capturing AWS Fargate Task Retirement Notifications](https://github.com/aws-samples/capturing-aws-fargate-task-retirement-notifications/tree/main) auf Github.
## Schritt 3: Den Ersatz von Aufgaben steuern
Sie können den genauen Zeitpunkt der Außerbetriebnahme einer Aufgabe nicht kontrollieren, Sie können jedoch eine Wartezeit definieren. Wenn Sie die Kontrolle darüber haben möchten, ob Aufgaben nach Ihrem eigenen Zeitplan ersetzt werden, können Sie die Benachrichtigung über die Außerbetriebnahme einer Aufgabe erfassen, um zunächst das Datum der Außerbetriebnahme der Aufgabe zu ermitteln. Anschließend können Sie Ihren Service erneut bereitstellen, um Ersatzaufgaben zu starten und auch alle eigenständigen Aufgaben zu ersetzen. Bei Services, die eine fortlaufende Bereitstellung verwenden, aktualisieren Sie den Service mit `update-service` und der Option `force-deployment` vor Beginn der Außerbetriebnahme.
Im folgenden `update-service`-Beispiel wird die Option `force-deployment` verwendet.
```
aws ecs update-service —-service service_name \
--cluster cluster_name \
--force-new-deployment
```
Für Dienste, die das blue/green Deployment verwenden, müssen Sie in ein neues Deployment erstellen AWS CodeDeploy. Informationen zum Erstellen der Bereitstellung finden Sie unter [Bereitstellung erstellen](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html) in der *Referenz für AWS Command Line Interface *.
# Unterstützte Regionen für Amazon ECS auf AWS Fargate
Sie können die folgenden Tabellen verwenden, um die Regionsunterstützung für Linux-Container auf AWS Fargate und Windows-Container auf AWS Fargate zu überprüfen.
## Linux-Container auf AWS Fargate
Amazon ECS Linux-Container auf AWS Fargate werden im Folgenden unterstützt AWS-Regionen. Die unterstützten Availability Zones IDs sind gegebenenfalls angegeben.
| Name der Region | Region |
| --- | --- |
| USA Ost (Ohio) | us-east-2 |
| USA Ost (Nord-Virginia) | us-east-1 |
| USA West (Nordkalifornien) | us-west-1 (nur `usw1-az1` und `usw1-az3`) |
| USA West (Oregon) | us-west-2 |
| Kanada (Zentral) | ca-central-1 |
| Kanada West (Calgary) | ca-west-1 |
| Mexiko (Zentral) | mx-central-1 |
| Afrika (Kapstadt) | af-south-1 |
| Asien-Pazifik (Hongkong) | ap-east-1 |
| Asien-Pazifik (Mumbai) | ap-south-1 |
| Asien-Pazifik (Tokio) | ap-northeast-1 (nur `apne1-az1`, `apne1-az2` und `apne1-az4`) |
| Asien-Pazifik (Seoul) | ap-northeast-2 |
| Asia Pacific (Osaka) | ap-northeast-3 |
| Asien-Pazifik (Hyderabad) | ap-south-2 |
| Asien-Pazifik (Singapur) | ap-southeast-1 |
| Asien-Pazifik (Sydney) | ap-southeast-2 |
| Asien-Pazifik (Thailand) | ap-southeast-7 |
| Asien-Pazifik (Jakarta) | ap-southeast-3 |
| Asien-Pazifik (Melbourne) | ap-southeast-4 |
| Asien-Pazifik (Malaysia) | ap-southeast-5 |
| Kanada (Zentral) | ca-central-1 |
| Kanada West (Calgary) | ca-west-1 |
| China (Peking) | cn-north-1 (nur `cnn1-az1` und `cnn1-az2`) |
| China (Ningxia) | cn-northwest-1 |
| Europe (Frankfurt) | eu-central-1 |
| Europa (Zürich) | eu-central-2 |
| Europa (Irland) | eu-west-1 |
| Europa (London) | eu-west-2 |
| Europa (Paris) | eu-west-3 |
| Europa (Milan) | eu-south-1 |
| Europa (Spain) | eu-south-2 |
| Europa (Stockholm) | eu-north-1 |
| Südamerika (São Paulo) | sa-east-1 |
| Israel (Tel Aviv) | il-central-1 |
| Naher Osten (Bahrain) | me-south-1 |
| Naher Osten (VAE) | me-central-1 |
| AWS GovCloud (US-Ost) | us-gov-east-1 |
| AWS GovCloud (US-West) | us-gov-west-1 |
## Windows-Container auf AWS Fargate
Amazon ECS Windows-Container auf AWS Fargate werden im Folgenden unterstützt AWS-Regionen. Die unterstützten Availability Zones IDs sind gegebenenfalls angegeben.
| Name der Region | Region |
| --- | --- |
| USA Ost (Ohio) | us-east-2 |
| USA Ost (Nord-Virginia) | us-east-1 (nur `use1-az1`, `use1-az2`, `use1-az4`, `use1-az5` und `use1-az6`) |
| USA West (Nordkalifornien) | us-west-1 (nur `usw1-az1` und `usw1-az3`) |
| USA West (Oregon) | us-west-2 |
| Afrika (Kapstadt) | af-south-1 |
| Asien-Pazifik (Hongkong) | ap-east-1 |
| Asien-Pazifik (Mumbai) | ap-south-1 |
| Asien-Pazifik (Hyderabad) | ap-south-2 |
| Asia Pacific (Osaka) | ap-northeast-3 |
| Asien-Pazifik (Seoul) | ap-northeast-2 |
| Asien-Pazifik (Singapur) | ap-southeast-1 |
| Asien-Pazifik (Sydney) | ap-southeast-2 |
| Asien-Pazifik (Melbourne) | ap-southeast-4 |
| Asien-Pazifik (Malaysia) | ap-southeast-5 |
| Asien-Pazifik (Tokio) | ap-northeast-1 (nur `apne1-az1`, `apne1-az2` und `apne1-az4`) |
| Kanada (Zentral) | ca-central-1 (nur `cac1-az1` und `cac1-az2`) |
| Kanada West (Calgary) | ca-west-1 |
| China (Peking) | cn-north-1 (nur `cnn1-az1` und `cnn1-az2`) |
| China (Ningxia) | cn-northwest-1 |
| Europe (Frankfurt) | eu-central-1 |
| Europa (Zürich) | eu-central-2 |
| Europa (Irland) | eu-west-1 |
| Europa (London) | eu-west-2 |
| Europa (Paris) | eu-west-3 |
| Europa (Milan) | eu-south-1 |
| Europa (Spain) | eu-south-2 |
| Europa (Stockholm) | eu-north-1 |
| Südamerika (São Paulo) | sa-east-1 |
| Israel (Tel Aviv) | il-central-1 |
| Naher Osten (VAE) | me-central-1 |
| Naher Osten (Bahrain) | me-south-1 |