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.
# Amazon-ECS-Cluster
Ein Amazon-ECS-Cluster ist eine logische Gruppierung von Aufgaben oder Services, der die Infrastrukturkapazität für Ihre containerisierten Anwendungen bereitstellt. Bei der Erstellung eines Clusters wählen Sie aus den drei primären Infrastrukturtypen, die jeweils für unterschiedliche Anwendungsfälle und betriebliche Anforderungen optimiert sind.
## Den richtigen Cluster-Typ auswählen
Amazon ECS bietet drei Infrastrukturtypen für Ihre Cluster. Wählen Sie den Typ, der Ihren Workload-Anforderungen, betrieblichen Präferenzen und Zielen zur Kostenoptimierung am besten entspricht:
Amazon ECS Managed Instances (empfohlen)
**Optimal für die meisten Workloads** — ermöglicht die AWS vollständige Verwaltung der zugrunde liegenden Amazon EC2 EC2-Instances, einschließlich Bereitstellung, Patching und Skalierung. Diese Option bietet das optimale Gleichgewicht zwischen Leistung, Kosteneffektivität und einfacher Bedienung.
**Verwendungszwecke:**
+ Sie möchten das Infrastrukturmanagement übernehmen AWS
+ Sie benötigen kostengünstige Rechenleistung mit automatischer Optimierung
+ Sie möchten sich eher auf Ihre Anwendungen als auf die Infrastruktur konzentrieren
+ Sie benötigen vorhersehbare Leistung mit flexibler Skalierung
Fargate
**Serverless-Datenverarbeitung** – Zahlen Sie nur für die Ressourcen, die Ihre Aufgaben verbrauchen, ohne die Infrastruktur verwalten zu müssen. Ideal für variable Workloads und für einen schnellen Einstieg.
**Verwendungszwecke:**
+ Sie möchten ausschließlich einen Serverless-Betrieb
+ Sie haben unberechenbare oder variable Workloads
+ Sie möchten die Betriebskosten minimieren
+ Sie benötigen eine schnelle Bereitstellung und Skalierung
Amazon EC2-Instances
**Vollständige Kontrolle** – Sie verwalten die zugrunde liegenden Amazon-EC2-Instances direkt, einschließlich Instance-Auswahl, Konfiguration und Wartung.
**Verwendungszwecke:**
+ Sie benötigen bestimmte Instance-Typen oder Konfigurationen
+ Sie verfügen über eine bestehende Amazon-EC2-Infrastruktur, die Sie nutzen können
+ Sie benötigen kundenspezifische AMIs oder spezialisierte Software
+ Sie benötigen maximale Kontrolle über die zugrunde liegende Infrastruktur
**Anmerkung**
Amazon ECS Managed Instances ist die empfohlene Wahl für die meisten neuen Workloads, da es die beste Kombination aus Leistung, Kostenoptimierung und einfachem Betrieb bietet und gleichzeitig die AWS Bewältigung von Infrastrukturverwaltungsaufgaben ermöglicht.
## Cluster-Komponenten
Zusätzlich zur Infrastrukturkapazität besteht ein Cluster aus den folgenden Ressourcen:
+ Das Netzwerk (VPC und Subnetz), in dem Ihre Aufgaben und Services ausgeführt werden
Wenn Sie Amazon ECS Managed Instances oder Amazon-EC2-Instances für die Kapazität verwenden, kann sich das Subnetz in Availability Zones, Local Zones, Wavelength Zones oder AWS Outposts befinden.
+ Ein optionaler Namespace
Ein Namespace wird für die service-to-service Kommunikation mit Service Connect verwendet.
+ Eine Überwachungsoptionen
CloudWatch Container Insights ist mit zusätzlichen Kosten verbunden und ist ein vollständig verwalteter Service. Sammelt, aggregiert und fasst Amazon-ECS-Metriken und -Protokolle automatisch zusammen.
## Cluster-Konzepte
Im Folgenden werden allgemeine Konzepte zu Amazon-ECS-Clustern vorgestellt.
+ Sie erstellen Cluster, um Ihre Ressourcen zu trennen.
+ Cluster sind AWS-Region spezifisch.
+ Cluster können einen der folgenden Zustände aufweisen.
ACTIVE
Der Cluster ist bereit, Aufgaben zu akzeptieren, und Sie können gegebenenfalls Container-Instances beim Cluster registrieren.
PROVISIONING
Dem Cluster sind Kapazitätsanbieter zugeordnet, und die Ressourcen, die für den Kapazitätsanbieter benötigt werden, werden erstellt.
DEPROVISIONING
Dem Cluster sind Kapazitätsanbieter zugeordnet, und die Ressourcen, die für den Kapazitätsanbieter benötigt werden, werden gelöscht.
FEHLGESCHLAGEN
Dem Cluster sind Kapazitätsanbieter zugeordnet, und die Ressourcen, die für den Kapazitätsanbieter benötigt werden, konnten nicht erstellt werden.
INACTIVE
Der Cluster wurde gelöscht. Cluster mit dem Status `INACTIVE` Status können für einen bestimmten Zeitraum im Konto erkennbar bleiben. Dieses Verhalten kann sich jedoch in Zukunft ändern. Stellen Sie deshalb sicher, dass Sie sich nicht darauf verlassen, dass bestehende `INACTIVE`-Cluster erhalten bleiben.
+ Ein Cluster kann eine Mischung aus Aufgaben enthalten, die in Amazon ECS Managed Instances, AWS Fargate, Amazon-EC2-Instances oder externen Instances gehostet werden. Aufgaben können in der Infrastruktur von Amazon ECS Managed Instances, Fargate oder EC2 als Starttyp oder als Kapazitätsanbieter-Strategie ausgeführt werden. Wenn Sie EC2-Kapazitätsanbieter verwenden, verfolgt und skaliert Amazon ECS die Kapazität von Amazon-EC2-Auto-Scaling-Gruppen nicht.
+ Ein Cluster kann eine Mischung aus Kapazitätsanbieter von Amazon ECS Managed Instances, Auto-Scaling-Gruppen oder Fargate enthalten. Eine Kapazitätsanbieter-Strategie kann nur Kapazitätsanbieter von Amazon ECS Managed Instances, Auto Scaling Gruppen oder Fargate enthalten.
+ Sie können verschiedene Instance-Typen für Amazon ECS Managed Instances und EC2 oder Auto-Scaling-Gruppen-Kapazitätsanbieter verwenden. Eine Instance kann jedoch nur in einem Cluster gleichzeitig registriert werden.
+ Sie können den Zugriff auf Cluster einschränken, indem Sie benutzerdefinierte IAM-Richtlinien erstellen. Weitere Informationen finden Sie im Abschnitt [Beispiele für Amazon-ECS-Cluster](security_iam_id-based-policy-examples.md#IAM_cluster_policies) in [Beispiele für identitätsbasierte Richtlinien für Amazon Elastic Container Service](security_iam_id-based-policy-examples.md).
+ Sie können Service-Auto-Scaling verwenden, um Fargate-Aufgaben zu skalieren. Weitere Informationen finden Sie unter [Automatisches Skalieren Ihres Amazon-ECS-Service](service-auto-scaling.md).
+ Sie können einen standardmäßigen Service-Connect-Namespace für einen Cluster konfigurieren. Nachdem Sie einen standardmäßigen Service-Connect-Namespace festgelegt haben, können alle neuen Services, die im Cluster erstellt wurden, als Client-Services im Namespace hinzugefügt werden, indem Sie Service Connect aktivieren. Es ist keine zusätzliche Konfiguration erforderlich. Weitere Informationen finden Sie unter [Verwenden von Service Connect, um Amazon-ECS-Services mit Kurznamen zu verbinden](service-connect.md).
## Kapazitätsanbieter
Amazon-ECS-Kapazitätsanbieter verwalten die Skalierung der Infrastruktur für Aufgaben in Ihren Clustern. Jeder Cluster kann über einen oder mehrere Kapazitätsanbieter und eine optionale Kapazitätsanbieter-Standardstrategie verfügen. Sie können dem Cluster eine Standardstrategie für Kapazitätsanbieter zuweisen. Die Kapazitätsanbieter-Strategie legt fest, wie die Aufgaben über die Kapazitätsanbieter eines Clusters verteilt werden. Wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen, können Sie entweder die Kapazitätsanbieter-Standardstrategie des Clusters verwenden oder eine Strategie für Kapazitätsanbieter angeben, die die Standardstrategie überschreibt. Die standardmäßige Kapazitätsanbieter-Strategie des Clusters gilt nur, wenn Sie keinen Starttyp oder keine Kapazitätsanbieter-Strategie für Ihre Aufgabe oder Ihren Service angeben. Wenn Sie einen dieser Parameter angeben, wird die Standardstrategie nicht verwendet.
Amazon ECS bietet drei Arten von Kapazitätsanbietern für Ihre Cluster:
Kapazitätsanbieter von Amazon ECS Managed Instances
AWS verwaltet die zugrunde liegenden Amazon EC2 EC2-Instances vollständig, einschließlich Bereitstellung, Patching, Skalierung und Lebenszyklusmanagement. Dies bietet das optimale Gleichgewicht zwischen Leistung, Kosteneffektivität und einfacher Bedienung. Die Kapazitätsanbieter von Amazon ECS Managed Instances optimieren automatisch die Instance-Auswahl und Skalierung auf der Grundlage Ihrer Workload-Anforderungen.
Mit Amazon ECS Managed Instances profitieren Sie von:
+ Automatische Instance-Bereitstellung und Skalierung
+ Verwaltete Patches und Sicherheitsupdates
+ Kostenoptimierung durch intelligente Instance-Auswahl
+ Reduzierte Betriebskosten
Fargate-Kapazitätsanbieter
Serverless-Datenverarbeitung, bei der Sie nur für die Ressourcen zahlen, die Ihre Aufgaben verbrauchen, ohne die Infrastruktur verwalten zu müssen. Sie müssen nur die vordefinierten Kapazitätsanbieter (Fargate und Fargate Spot) dem Cluster zuordnen.
Auto-Scaling-Gruppenkapazitätsanbieter
Wenn Sie Amazon-EC2-Instances für Ihre Kapazität verwenden, verwenden Sie die Auto-Scaling-Gruppe, um die Amazon-EC2-Instances zu verwalten. Auto Scaling hilft Ihnen dabei, sicherzustellen, dass Sie die richtige Anzahl von Amazon-EC2-Instances zur Verfügung haben, um die Auslastung Ihrer Anwendung zu bewältigen. Sie haben volle Kontrolle über die zugrunde liegende Infrastruktur.
Ein Cluster kann eine Mischung aus Aufgaben enthalten, die in Amazon ECS Managed Instances, AWS Fargate, Amazon-EC2-Instances oder externen Instances gehostet werden. Aufgaben können in der Infrastruktur von Amazon ECS Managed Instances, Fargate oder EC2 als Starttyp oder als Kapazitätsanbieter-Strategie ausgeführt werden. Wenn Sie EC2 als Starttyp verwenden, verfolgt und skaliert Amazon ECS die Kapazität von Gruppen von Amazon EC2 Auto Scaling nicht.
Ein Cluster kann eine Mischung aus Kapazitätsanbieter von Amazon ECS Managed Instances, Auto-Scaling-Gruppen oder Fargate enthalten. Eine Kapazitätsanbieter-Strategie kann nur Kapazitätsanbieter von Amazon ECS Managed Instances, Auto Scaling Gruppen oder Fargate enthalten.
# Cluster für Amazon ECS Managed Instances
Amazon-ECS-Kapazitätsanbieter verwalten die Skalierung der Infrastruktur für Aufgaben in Ihren Clustern. Nachdem Sie den Cluster erstellt haben, erstellen Sie einen oder mehrere Kapazitätsanbieter und eine optionale Kapazitätsanbieter-Strategie für den Cluster. Die Kapazitätsanbieter-Strategie legt fest, wie die Aufgaben über die Kapazitätsanbieter eines Clusters verteilt werden. Wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen, können Sie entweder die Kapazitätsanbieter-Standardstrategie des Clusters verwenden oder eine Strategie für Kapazitätsanbieter angeben, die die Standardstrategie überschreibt.
Amazon ECS Managed Instances hat die folgenden Kapazitätsanbieter.
| Typ | Kriterien zur Auswahl der Instances |
| --- | --- |
| Standard | Die kostengünstigsten Instances, die die folgenden Anforderungen der Aufgabendefinition und Serviceparameter erfüllen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/managed-instance-clusters.html) |
| Benutzerdefiniert | Die Instances, die die Attribut- und Typanforderungen erfüllen, die Sie bei der Erstellung des Clusters angeben. Informationen zu den Attributen finden Sie unter [Attribute von Amazon-ECS-Container-Instances](task-placement-constraints.md#attributes). Informationen über Instance-Typen finden Sie unter [Spezifikationen für Instance-Typen von Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html) in Instance-Typen von Amazon EC2. |
Amazon ECS startet die Instances und ordnet sie dem Kapazitätsanbieter von Amazon ECS Managed Instances zu. Für den benutzerdefinierten Kapazitätsanbieter erstellt Amazon ECS auch den Kapazitätsanbieter.
# Erstellen eines Clusters für Amazon ECS Managed Instances
Sie erstellen einen Cluster, um die Infrastruktur zu definieren, auf der Ihre Aufgaben und Services ausgeführt werden.
Wenn Sie einen Cluster für Amazon ECS Managed Instances erstellen, erstellt Amazon ECS automatisch einen Kapazitätsanbieter für verwaltete Instances mit Standardkonfigurationen. Dieser Kapazitätsanbieter wählt die kostengünstigsten Instance-Typen für Ihre Workloads aus. Sie können auch benutzerdefinierte Kapazitätsanbieter erstellen, wenn Sie bestimmte Instance-Attribute oder -Typen benötigen.
Um die Cluster-Erstellung so einfach wie möglich zu gestalten, verfügt die Konsole über Standardselektionen für viele Auswahlmöglichkeiten.
+ Erstellt einen Standard-Namespace AWS Cloud Map , der denselben Namen wie der Cluster hat. Ein Namespace ermöglicht es Services, die Sie im Cluster erstellen, ohne zusätzliche Konfiguration eine Verbindung zu den anderen Services im Namespace herzustellen.
Weitere Informationen finden Sie unter [Amazon-ECS-Services verbinden](interconnecting-services.md).
Sie können die folgenden Optionen ändern:
+ Ändern Sie den Standard-Namespace, der dem Cluster zugeordnet ist.
Ein Namespace ermöglicht es Services, die Sie im Cluster erstellen, ohne zusätzliche Konfiguration eine Verbindung zu den anderen Services im Namespace herzustellen. Der Standard-Namespace ist mit dem Cluster-Namen identisch. Weitere Informationen finden Sie unter [Amazon-ECS-Services verbinden](interconnecting-services.md).
+ Weisen Sie einen AWS KMS Schlüssel für Ihren verwalteten Speicher zu. Weitere Informationen zur Erstellung eines Schlüssels finden Sie unter [Einen KMS-Schlüssel erstellen](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) im *Benutzerhandbuch für AWS Key Management Service *.
+ Fügen Sie Tags hinzu, die Ihnen helfen, Ihren Cluster zu identifizieren.
## Voraussetzungen
Bevor Sie beginnen, vergewissern Sie sich, dass Sie die Schritte in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) ausgeführt haben, und weisen Sie die entsprechende IAM-Berechtigung zu. Weitere Informationen finden Sie unter [Beispiele für Amazon-ECS-Cluster](security_iam_id-based-policy-examples.md#IAM_cluster_policies).
Der Benutzer, der den Cluster erstellt, muss über eine zusätzliche Berechtigung verfügen: `iam:CreateServiceLinkedRole`.
Wenn Sie nichts angeben`instanceRequirements`, wählt Amazon ECS automatisch die kostengünstigsten Instance-Typen auf der Grundlage Ihrer Aufgabendefinitionsanforderungen aus. Um bestimmte Instance-Attribute oder -Typen zu verwenden, erstellen Sie einen Kapazitätsanbieter mit`instanceRequirements`.
Erfahren Sie, wie Sie Ihre Instances auswählen. Weitere Informationen finden Sie unter [Bewährte Methoden zur Instance-Auswahl für Amazon ECS Managed Instances](managed-instances-instance-selection-best-practices.md).
Sie haben die erforderlichen IAM-Rollen für Amazon ECS Managed Instances. Dies umfasst:
+ **Rolle „Infrastruktur**“ — Ermöglicht Amazon ECS, in Ihrem Namen AWS Dienste zur Verwaltung der Infrastruktur von Amazon ECS Managed Instances zu kontaktieren.
Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Infrastruktur](infrastructure_IAM_role.md).
+ **Instance-Profil** – Stellt Berechtigungen für den Amazon-ECS-Container-Agent und den Docker-Daemon bereit, die auf verwalteten Instances ausgeführt werden.
Weitere Informationen finden Sie unter [Instance-Profil von Amazon ECS Managed Instances](managed-instances-instance-profile.md).
## Konsolenverfahren
**So erstellen Sie einen neuen Cluster (Amazon ECS-Konsole)**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie die zu verwendende Region in der Navigationsleiste aus.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der Seite **Clusters** die Option **Create cluster** (Cluster erstellen) aus.
1. Konfigurieren Sie unter **Clusterkonfiguration** Folgendes:
+ Geben Sie für **Cluster-Name** einen eindeutigen Namen ein.
Der Name kann bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern und Bindestriche enthalten.
+ (Optional) Wenn der für Service Connect verwendete Namespace nicht mit dem Clusternamen identisch sein soll, geben Sie unter **Namespace** einen eindeutigen Namen ein.
1. Gehen Sie für **Benutzerdefinierter Kapazitätsanbieter** wie folgt vor:
+ Wählen Sie für **Wählen Sie eine Methode zum Abrufen von EC2-Kapazität** die Option **Amazon ECS Managed Instances** aus.
+ Wählen Sie für Instance-Profil die Rolle des Instance-Profils aus.
+ Wählen Sie für Infrastrukturrolle die Infrastrukturrolle aus.
+ Um einen benutzerdefinierten Kapazitätsanbieter zu verwenden, wählen Sie unter **Instance-Auswahl** die Option **Benutzerdefiniert verwenden** aus. Geben Sie dann für jedes Attribut den **Attributwert** ein.
1. (Optional) Verwenden Sie Container Insights, erweitern Sie **Überwachung** und wählen Sie dann eine der folgenden Optionen:
+ Um das empfohlene Container Insights mit verbesserter Beobachtbarkeit zu verwenden, wählen Sie **Container Insights mit verbesserter Beobachtbarkeit**.
+ Um Container Insights zu verwenden, wählen Sie **Container Insights**.
1. (Optional) Verschlüsseln Sie die Daten im verwalteten Speicher. Geben Sie unter **Verschlüsselung** für **verwalteten Speicher** den ARN des AWS KMS Schlüssels ein, den Sie zum Verschlüsseln der verwalteten Speicherdaten verwenden möchten.
1. (Optional) Um Ihren Cluster leichter identifizieren zu können, erweitern Sie den Bereich **Tags**, und konfigurieren Sie dann Ihre Tags.
[Markierung hinzufügen] Wählen Sie **Add tag (Markierung hinzufügen)**, und führen Sie die folgenden Schritte aus:
+ Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein.
+ Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein.
1. Wählen Sie **Erstellen** aus.
## AWS CLI Verfahren
Sie können mit der AWS CLI einen Cluster für Amazon ECS Managed Instances erstellen. Verwenden Sie die neuesten Version der AWS CLI. Weitere Informationen zur Aktualisierung auf die neueste Version finden Sie unter [Installieren oder Aktualisieren auf die neueste Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Anmerkung**
Sie können Dual-Stack-Service-Endpunkte verwenden, um mit Amazon ECS über die AWS AWS CLI SDKs, und die Amazon ECS-API sowohl über als auch IPv4 zu interagieren. IPv6 Weitere Informationen finden Sie unter [Verwenden von Dual-Stack-Endpunkten in Amazon ECS](dual-stack-endpoint.md).
**So erstellen Sie einen neuen Cluster (AWS CLI)**
1. Erstellen Sie mit dem folgenden Befehl den Cluster mit einem eindeutigen Namen:
```
aws ecs create-cluster --cluster-name managed-instances-cluster
```
Ausgabe:
```
{
"cluster": {
"status": "ACTIVE",
"defaultCapacityProviderStrategy": [],
"statistics": [],
"capacityProviders": [],
"tags": [],
"clusterName": "managed-instances-cluster",
"settings": [
{
"name": "containerInsights",
"value": "disabled"
}
],
"registeredContainerInstancesCount": 0,
"pendingTasksCount": 0,
"runningTasksCount": 0,
"activeServicesCount": 0,
"clusterArn": "arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster"
}
}
```
1. (Optional) Verwenden Sie den folgenden Befehl, um Container Insights mit verbesserter Beobachtbarkeit für Ihren Cluster zu aktivieren:
```
aws ecs put-account-setting --name containerInsights --value enhanced
```
1. (Optional) Verwenden Sie den folgenden Befehl, um Tags zu Ihrem Cluster hinzuzufügen:
```
aws ecs tag-resource --resource-arn arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster --tags key=Environment,value=Production
```
## Nächste Schritte
Erstellen Sie eine Aufgabendefinition für Amazon ECS Managed Instances. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
Führen Sie Ihre Anwendungen als eigenständige Aufgaben oder als Teil eines Services aus. Weitere Informationen finden Sie hier:
+ [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md)
+ [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md)
# Aktualisierung eines Clusters zur Verwendung von Amazon ECS Managed Instances
Sie können einen vorhandenen Cluster aktualisieren, um Amazon ECS Managed Instances zu verwenden.
Wenn Sie Amazon ECS Managed Instances zu Ihrem Cluster hinzufügen, erstellt Amazon ECS automatisch einen Kapazitätsanbieter für verwaltete Instances mit Standardkonfigurationen. Dieser Kapazitätsanbieter wählt die kostenoptimiertesten Allzweck-Instance-Typen für Ihre Workloads aus. Sie können auch benutzerdefinierte Kapazitätsanbieter erstellen, wenn Sie bestimmte Instance-Attribute oder -Typen benötigen.
## Voraussetzungen
Wenn Sie nichts angeben`instanceRequirements`, wählt Amazon ECS automatisch die kostengünstigsten Instance-Typen auf der Grundlage Ihrer Aufgabendefinitionsanforderungen aus. Um bestimmte Instance-Attribute oder -Typen zu verwenden, erstellen Sie einen Kapazitätsanbieter mit`instanceRequirements`.
Sie haben die erforderlichen IAM-Rollen für Amazon ECS Managed Instances. Dies umfasst:
+ **Rolle „Infrastruktur**“ — Ermöglicht Amazon ECS, in Ihrem Namen AWS Dienste zur Verwaltung der Infrastruktur von Amazon ECS Managed Instances zu kontaktieren.
Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Infrastruktur](infrastructure_IAM_role.md).
+ **Instance-Profil** – Stellt Berechtigungen für den Amazon-ECS-Container-Agent und den Docker-Daemon bereit, die auf verwalteten Instances ausgeführt werden.
Weitere Informationen finden Sie unter [Instance-Profil von Amazon ECS Managed Instances](managed-instances-instance-profile.md).
## Überlegungen zu Aktualisierungen
Wenn Sie einen Cluster für Amazon ECS Managed Instances aktualisieren, beachten Sie Folgendes:
+ Laufende Aufgaben – Die Aktualisierung der Cluster-Einstellungen hat keine Auswirkungen auf aktuell ausgeführte Aufgaben. Die Änderungen gelten für neue Aufgaben, die nach der Aktualisierung gestartet werden.
+ Änderungen des Kapazitätsanbieters – Wenn Sie die Einstellungen des Kapazitätsanbieters ändern, werden bestehende verwaltete Instances weiterhin ausgeführt, aber neue Instances verwenden die aktualisierte Konfiguration.
+ Änderungen überwachen – Die Aktivierung oder Deaktivierung von Container Insights wirkt sich auf die Erfassung von Metriken für den gesamten Cluster aus.
## Konsolenverfahren
**So aktualisieren Sie einen Cluster (Amazon-ECS-Konsole)**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie die zu verwendende Region in der Navigationsleiste aus.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Clusters**-Seite den Cluster aus, den Sie aktualisieren möchten.
1. Wählen Sie **Cluster aktualisieren**.
1. (Optional) Um die Einstellungen des Kapazitätsanbieters zu ändern, aktualisieren Sie unter **Benutzerdefinierter Kapazitätsanbieter** Folgendes nach Bedarf:
+ Wählen Sie für das **Instance-Profil** bei Bedarf eine andere Instance-Profil-Rolle aus.
+ Wählen Sie für die **Infrastrukturrolle** bei Bedarf eine andere Infrastrukturrolle aus.
+ Um einen benutzerdefinierten Kapazitätsanbieter zu verwenden, aktualisieren Sie unter **Instance-Auswahl** die Einstellungen für den **Attributwert**.
1. Wählen Sie **Aktualisieren** aus.
## AWS CLI Verfahren
Sie können einen Cluster für Amazon ECS Managed Instances mit der AWS CLI aktualisieren. Verwenden Sie die neuesten Version der AWS CLI. Weitere Informationen zur Aktualisierung auf die neueste Version finden Sie unter [Installieren oder Aktualisieren auf die neueste Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Anmerkung**
Sie können Dual-Stack-Service-Endpunkte verwenden, um mit Amazon ECS über die AWS AWS CLI SDKs, und die Amazon ECS-API sowohl über als auch IPv4 zu interagieren. IPv6 Weitere Informationen finden Sie unter [Verwenden von Dual-Stack-Endpunkten in Amazon ECS](dual-stack-endpoint.md).
**So aktualisieren Sie einen Cluster (AWS CLI)**
1. Erstellen eines Kapazitätsanbieters für Führen Sie den folgenden Befehl aus:
Ersetzen Sie die *user-input* durch Ihre Werte.
```
aws ecs create-capacity-provider \
--name my-managed-instances-provider \
--managed-instances-provider \
--instance-profile arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile \
--infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRole \
--instance-requirements '{
"vCpuCount": {"min": 2, "max": 8},
"memoryMiB": {"min": 4096, "max": 16384}
}
```
1. Verwenden Sie den folgenden Befehl, um den Kapazitätsanbieter dem Cluster hinzuzufügen:
Ersetze die *user-input* durch deine Werte.
```
aws ecs put-cluster-capacity-providers --cluster managed-instances-cluster --capacity-providers my-managed-instances-provider --default-capacity-provider-strategy capacityProvider=my-managed-instances-provider,weight=1
```
# Kapazitätsanbieter von Amazon ECS Managed Instances
Die Kapazitätsanbieter von Amazon ECS Managed Instances bieten ein Container-Rechenmodell, das Ihnen Zugriff auf alle AWS Funktionen und Amazon EC2 EC2-Angebote bietet und gleichzeitig die Betriebs- und Sicherheitsaufgaben AWS verwaltet. AWS kümmert sich um Software- und Betriebssystem-Patching, Instanzskalierung und Wartung und bietet Ihnen so die betrieblichen Vorteile von Fargate, während Sie gleichzeitig Zugriff auf alle AWS Funktionen und Integrationen haben.
Amazon ECS erstellt Startvorlagen für Amazon ECS Managed Instances. Dies definiert, wie Amazon ECS Managed Instances von Amazon ECS gestartet wird, einschließlich des Instance-Profils für Ihre Aufgaben, der Netzwerk- und Speicherkonfiguration, der Kapazitätsoptionen und der Instance-Anforderungen für eine flexible Auswahl des Instance-Typs.
## Wann Sie benutzerdefinierte Kapazitätsanbieter verwenden sollen
Ziehen Sie benutzerdefinierte Kapazitätsanbieter in Betracht, wenn Ihre Workloads Folgendes erfordern:
+ Spezifische Rechenanforderungen: Anwendungen, die beschleunigte Datenverarbeitung, spezifische CPU-Befehlssätze, hohe Netzwerkleistung oder große Speicherkonfigurationen erfordern, die mit den Fargate-Standardoptionen nicht verfügbar sind.
+ GPU-Workloads: Inferenz für maschinelles Lernen, Bildrendern in Echtzeit, Videokodierung oder andere GPU-beschleunigte Anwendungen, die Zugriff auf NVIDIA oder AMD benötigen. GPUs
+ Kapazitätsreservierungen: Geschäftskritische Workloads, die eine vorhersehbare Kapazitätsverfügbarkeit erfordern.
+ Erweiterte Beobachtbarkeit: Sicherheits- und Überwachungstools, die einen privilegierten Zugriff auf das zugrunde liegende Betriebssystem erfordern, z. B. EBPF-basierte Überwachungslösungen oder Netzwerkanalysetools.
+ Kostenoptimierung: Workloads, die von der Platzierung mehrerer Aufgaben profitieren können, gemeinsam genutzte Infrastrukturkomponenten nutzen können oder die die Nutzung größerer Instance-Typen maximieren müssen.
## Überwachungsoptionen
Amazon ECS Managed Instances bieten umfassende Überwachungsfunktionen, mit denen Sie die Leistung, den Zustand und die Ressourcennutzung Ihrer containerisierten Workloads verfolgen können. Sie können je nach Ihren betrieblichen Anforderungen zwischen verschiedenen Überwachungsebenen wählen.
+ **Grundlegende Überwachung** – Stellt wichtige Messwerte für die meisten Kennzahlen in 5-Minuten-Intervallen und für Statussüberprüfungen in 1-Minuten-Intervallen bereit. Diese Option ist standardmäßig aktiviert und es fallen keine zusätzlichen Gebühren an.
+ **Detaillierte Überwachung** – Bietet mehr Transparenz, da alle Kennzahlen in Intervallen von 1 Minute verfügbar sind, sodass betriebliche Probleme schneller erkannt und behoben werden können. Weitere Informationen finden Sie unter [Detaillierte Überwachung für Amazon ECS Managed Instances](monitoring-managed-instances.md#detailed-monitoring-managed-instances).
Beide Überwachungsoptionen lassen sich nahtlos CloudWatch integrieren und bieten Dashboards, Alarme und automatisierte Reaktionen, um eine optimale Anwendungsleistung und Verfügbarkeit aufrechtzuerhalten.
## Überlegungen zu Kapazitätsanbietern
Ein Cluster kann eine Mischung aus Kapazitätsanbieter von Amazon ECS Managed Instances, Auto-Scaling-Gruppen oder Fargate enthalten. Eine Kapazitätsanbieter-Strategie kann nur Kapazitätsanbieter von Amazon ECS Managed Instances, Auto Scaling Gruppen oder Fargate enthalten.
## Verbreitung von Tags
Kapazitätsanbieter für Amazon ECS Managed Instances unterstützen die Tag-Weitergabe. Bei der Tag-Propagierung werden alle vom Kapazitätsanbieter verwalteten Ressourcen – die verwaltete Instance, die Amazon-ECS-Container-Instance, die Startvorlage, Volumes, Elastic-Network-Schnittstellen – mit denselben Tags versehen, die auf der Ebene des Kapazitätsanbieters angegeben sind. Sie können Tags bei der Erstellung des Kapazitätsanbieters angeben und die Tag-Weitergabe aktivieren, indem Sie den `propagateTags`-Parameter als `CAPACITY_PROVIDER` angeben.
Weitere Informationen über das Markieren in Amazon ECS Managed Instances finden Sie unter [Tags für Amazon ECS Managed Instances](instance-details-tags-managed-instances.md).
# Bewährte Methoden für die Aktualisierung von Kapazitätsanbietern für Amazon ECS Managed Instances
Für ein Höchstmaß an Sicherheit und Rollback-Support empfehlen wir, Kapazitätsanbieter als unveränderliche Ressourcen zu behandeln. Wenn Sie die Konfiguration eines Kapazitätsanbieters aktualisieren müssen, folgen Sie diesem empfohlenen Arbeitsablauf:
1. **Erstellen Sie einen neuen Kapazitätsanbieter** mit Ihrer aktualisierten Konfiguration, anstatt die bestehende zu ändern.
1. **Aktualisieren Sie jeden Service** so, dass er den neuen Kapazitätsanbieter verwendet, damit die Bereitstellungen abgeschlossen werden können.
1. **Löschen Sie den alten Kapazitätsanbieter**, nachdem Sie sich vergewissert haben, dass die neue Konfiguration erwartungsgemäß funktioniert.
Dieser Ansatz bietet mehrere Vorteile:
+ **Kontrollierter Rollout** – Sie können die Services einzeln aktualisieren und die Auswirkungen überwachen.
+ **Einfaches Rollback** – Wenn Probleme auftreten, können Sie die Services schnell auf den vorherigen Kapazitätsanbieter zurücksetzen.
+ **Reduzierter Explosionsradius** – Probleme mit der neuen Konfiguration wirken sich nicht sofort auf alle Workloads aus.
**Anmerkung**
Wenn Sie das System verwenden CloudFormation, sollten Sie erwägen, den alten Kapazitätsanbieter bis zu einer späteren Bereitstellung beizubehalten, um die Möglichkeit zu haben, Ihre Stack-Änderungen rückgängig zu machen.
Sie können die vorhandenen Kapazitätsanbieter zwar aktualisieren, aber dieser Ansatz führt zu einem größeren unkontrollierten Explosionsradius. Direkte Updates wenden neue Einstellungen auf alle künftig bereitgestellten Kapazitäten an, lösen jedoch keine Servicebereitstellungen aus. Das bedeutet, dass Sie Konfigurationsprobleme möglicherweise erst viel später entdecken, wenn Ihre Services skaliert werden müssen.
# Erstellen eines Kapazitätsanbieters für Amazon ECS Managed Instances
Amazon ECS Managed Instances verwendet Kapazitätsanbieter, um die Rechenkapazität für Ihre Workloads zu verwalten. Wenn Sie einen Kapazitätsanbieter ohne Angabe erstellen`instanceRequirements`, wählt Amazon ECS automatisch die kostenoptimiertesten Allzweck-Instance-Typen aus. Sie können Kapazitätsanbieter erstellen`instanceRequirements`, um Instance-Attribute wie Instance-Typen, CPU-Hersteller, Beschleunigertypen und andere Anforderungen zu spezifizieren.
Benutzerdefinierte Kapazitätsanbieter verwenden eine attributbasierte Auswahl des Instance-Typs, mit der Sie Instance-Anforderungen als eine Reihe von Attributen ausdrücken können. Diese Anforderungen werden automatisch in alle passenden Instance-Typen von Amazon EC2 übersetzt, was die Erstellung und Wartung von Instance-Typ-Konfigurationen vereinfacht. Weitere Informationen zu den Instance-Anforderungen und der attributbasierten Auswahl finden Sie unter [Attributebasierte Auswahl des Instance-Typs für Amazon EC2 Fleet](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) im *Amazon-EC2-Benutzerhandbuch*.
## Voraussetzungen
Überprüfen Sie zu Beginn, ob Sie die folgenden Schritte ausgeführt haben:
+ Ermitteln Sie, welche Art von Überwachung verwendet werden soll. Weitere Informationen finden Sie unter [Detaillierte Überwachung für Amazon ECS Managed Instances](monitoring-managed-instances.md#detailed-monitoring-managed-instances).
+ Verwenden Sie einen vorhandenen Cluster oder planen Sie, einen zu erstellen. Weitere Informationen finden Sie unter [Erstellen eines Clusters für Amazon ECS Managed Instances](create-cluster-managed-instances.md).
+ Sie haben die erforderlichen IAM-Rollen für Amazon ECS Managed Instances. Dies umfasst:
+ **Rolle „Infrastruktur**“ — Ermöglicht Amazon ECS, in Ihrem Namen AWS Dienste zur Verwaltung der Infrastruktur von Amazon ECS Managed Instances zu kontaktieren.
Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Infrastruktur](infrastructure_IAM_role.md).
+ **Instance-Profil** – Stellt Berechtigungen für den Amazon-ECS-Container-Agent und den Docker-Daemon bereit, die auf verwalteten Instances ausgeführt werden.
Weitere Informationen finden Sie unter [Instance-Profil von Amazon ECS Managed Instances](managed-instances-instance-profile.md).
Erfahren Sie, wie Sie Ihre Instances auswählen. Weitere Informationen finden Sie unter [Bewährte Methoden zur Instance-Auswahl für Amazon ECS Managed Instances](managed-instances-instance-selection-best-practices.md).
## Konsolenverfahren
**So erstellen Sie einen Kapazitätsanbieter für Amazon ECS Managed Instances (Amazon-ECS-Konsole)**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie die zu verwendende Region in der Navigationsleiste aus.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Clusters**-Seite den Cluster-Namen aus.
1. Wählen Sie auf der Cluster-Seite die Registerkarte **Infrastruktur**.
1. Wählen Sie im Abschnitt **Kapazitätsanbieter** die Option **Kapazitätsanbieter erstellen** aus.
1. Konfigurieren Sie unter **Konfiguration des Kapazitätsanbieters** Folgendes:
+ Geben Sie unter **Name des Kapazitätsanbieters**, einen eindeutigen Namen für den Kapazitätsanbieter ein.
+ Wählen Sie für **Kapazitätsanbietertyp** **Amazon ECS Managed Instances** aus.
1. Konfigurieren Sie unter **Instance-Konfiguration** Folgendes:
+ Wählen Sie für **Instance-Profil** die Instance-Profilrolle aus, die für Amazon ECS Managed Instances erstellt wurde.
+ Wählen Sie für **Infrastrukturrolle** die Infrastrukturrolle aus, die für Amazon ECS Managed Instances erstellt wurde.
1. Geben Sie unter **Instance-Anforderungen** die Attribute für Ihre Instances an. Sie können eine beliebige Kombination der folgenden Elemente konfigurieren:
+ **vCPU-Anzahl** — Geben Sie die Anzahl von v an CPUs (z. B. `4` oder `8-16` für einen Bereich).
+ **Arbeitsspeicher (MiB)** – Geben Sie die Menge an Arbeitsspeicher in MiB an (z. B. `8192` oder `16384-32768` für einen Bereich).
+ **Instance-Typen** – Geben Sie bestimmte Instance-Typen an (z. B. `m5.large,m5.xlarge,c5.large`).
+ **CPU-Hersteller** – Wählen Sie aus `intel`, `amd` oder `amazon-web-services`.
+ **Accelerator-Typen** – Geben Sie Accelerator-Typen wie `gpu`, `fpga` oder `inference` an.
+ **Anzahl der Accelerators** – Geben Sie die Anzahl der Accelerators an (z. B. `1` oder `2-4` für einen Bereich).
1. Wählen Sie unter **Erweiterte Konfiguration** eine der folgenden Überwachungsoptionen aus:
+ **Um Metriken zur Statusüberprüfung CloudWatch senden zu lassen, wählen Sie Basic.**
+ **Um alle Metriken CloudWatch gesendet zu haben, wählen Sie Detailliert.**
1. (Optional) Um Ihren Kapazitätsanbieter leichter identifizieren zu können, erweitern Sie **Tags** und konfigurieren Sie dann Ihre Tags.
Um die Tag-Weitergabe vom Kapazitätsanbieter an verwaltete Ressourcen wie Instances zu aktivieren, die vom Kapazitätsanbieter gestartet wurden, wählen Sie unter **Tags weitergeben von** die Option **Kapazitätsanbieter** aus.
[Markierung hinzufügen] Wählen Sie **Add tag (Markierung hinzufügen)**, und führen Sie die folgenden Schritte aus:
+ Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein.
+ Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein.
1. Wählen Sie **Erstellen** aus.
## AWS CLI Verfahren
Sie können einen Kapazitätsanbieter für Amazon ECS Managed Instances mit der AWS CLI erstellen. Verwenden Sie die neuesten Version der AWS CLI. Weitere Informationen zur Aktualisierung auf die neueste Version finden Sie unter [Installieren oder Aktualisieren auf die neueste Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**So erstellen Sie einen Kapazitätsanbieter für Amazon ECS Managed Instances (AWS CLI)**
1. Führen Sie den folgenden Befehl aus:
```
aws ecs create-capacity-provider --cli-input-json file://capacity-provider-definition.json
```
Das folgendes `capacity-provider-definition.json` kann verwendet werden, um grundlegende Instance-Anforderungen und die Instance-Speichergröße festzulegen, und die Tag-Propagierung zu aktivieren:
```
{
"name": "my-managed-instances-provider",
"cluster": "my-cluster",
"tags": [
{
"key": "version",
"value": "test"
}
],
"managedInstancesProvider": {
"infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole",
"instanceLaunchTemplate": {
"ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
"instanceRequirements": {
"vCpuCount": {
"min": 4,
"max": 8
},
"memoryMiB": {
"min": 8192,
"max": 16384
}
},
"networkConfiguration": {
"subnets": [
"subnet-abcdef01234567",
"subnet-bcdefa98765432"
],
"securityGroups": [
"sg-0123456789abcdef"
]
},
"storageConfiguration": {
"storageSizeGiB": 100
},
"monitoring": "basic"
},
"propagateTags": "CAPACITY_PROVIDER"
}
}
```
1. Stellen Sie sicher, dass Ihr Kapazitätsanbieter erfolgreich erstellt wurde:
```
aws ecs describe-capacity-providers \
--capacity-providers my-managed-instances-provider
```
## Nächste Schritte
Nachdem Sie Ihren Kapazitätsanbieter erstellt haben, können Sie ihn verwenden, um Services zu erstellen oder Aufgaben auszuführen:
+ Informationen zur Verwendung des Kapazitätsanbieters mit einem Service finden Sie unter [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md).
+ Informationen zur Verwendung des Kapazitätsanbieters für eigenständige Aufgaben finden Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md).
# Aktualisierung der Überwachung von Amazon ECS Managed Instances
Sie können die Überwachungsoption für Ihren Kapazitätsanbieter von Amazon ECS Managed Instances ändern, um zwischen grundlegender und detaillierter Überwachung zu wechseln. Auf diese Weise können Sie den Umfang der erfassten Überwachungsdaten anpassen, ohne den Kapazitätsanbieter neu erstellen zu müssen.
Weitere Informationen zu den Überwachungsoptionen finden Sie unter [Überwachung von Amazon ECS Managed Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-managed-instances.html).
## Konsolenverfahren
**So aktualisieren Sie die Überwachung für Amazon ECS Managed Instances (Amazon-ECS-Konsole)**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie die zu verwendende Region in der Navigationsleiste aus.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Clusters**-Seite den Cluster-Namen aus.
1. Wählen Sie auf der Cluster-Seite die Registerkarte **Infrastruktur**.
1. Wählen Sie unter **Erweiterte Konfiguration** eine der folgenden Überwachungsoptionen aus:
+ **Um Metriken zur Statusüberprüfung CloudWatch senden zu lassen, wählen Sie Basic.**
+ **Um alle Metriken CloudWatch gesendet zu haben, wählen Sie Detailliert.**
1. Wählen Sie **Aktualisieren** aus.
Gehen Sie wie folgt vor, um Tags zu aktualisieren, die einem vorhandenen Kapazitätsanbieter für Amazon ECS Managed Instances zugeordnet sind:
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der Clusters-Seite die Option **Infrastruktur** aus.
1. Wählen Sie auf der Infrastrukturseite den Kapazitätsanbieter aus, den Sie erstellt haben.
1. Wählen Sie auf der Seite mit dem Kapazitätsanbieter die Option **Tags** aus.
1. Wählen Sie unter **Tags** die Option **Manage tags (Tags verwalten)** aus.
1. Geben Sie zum Hinzufügen eines Tags den Schlüssel und den Wert des Tags an, das Sie hinzufügen möchten, und wählen Sie dann **Speichern** aus. Fügen Sie mehrere Tags gleichzeitig hinzu, indem Sie für jedes Tag, das Sie hinzufügen möchten **Tag hinzufügen** auswählen. Sie können maximal 50 Tags hinzufügen.
Klicken Sie zum Entfernen eines Tags auf **Remove (Entfernen)**.
**Anmerkung**
Wenn die Tag-Weitergabe aktiviert ist, gelten Tags, die nach der Erstellung des Kapazitätsanbieters hinzugefügt oder entfernt wurden, nicht für Ressourcen, die zuvor vom Kapazitätsanbieter erstellt wurden.
## AWS CLI Verfahren
Sie können einen Kapazitätsanbieter für Amazon ECS Managed Instances mit der AWS CLI aktualisieren. Verwenden Sie die neuesten Version der AWS CLI. Weitere Informationen zur Aktualisierung auf die neueste Version finden Sie unter [Installieren oder Aktualisieren auf die neueste Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**So aktualisieren Sie die Überwachung für Amazon ECS Managed Instances (AWS CLI)**
1. Verwenden Sie den folgenden Befehl, um die detaillierte Überwachung zu aktivieren:
```
aws ecs update-capacity-provider \
--name my-managed-instances-provider \
--managed-instances-provider '{
"instanceLaunchTemplateUpdate": {
"monitoring": "DETAILED"
}
}'
```
1. Verwenden Sie den folgenden Befehl, um die grundlegende Überwachung zu aktivieren:
```
aws ecs update-capacity-provider \
--name my-managed-instances-provider \
--managed-instances-provider '{
"instanceLaunchTemplateUpdate": {
"monitoring": "BASIC"
}
}'
```
# Löschen eines Kapazitätsanbieters für Amazon ECS Managed Instances
Wenn Sie mit einem Kapazitätsanbieter von Amazon ECS Managed Instances fertig sind, können Sie ihn löschen. Nachdem die Gruppe gelöscht wurde, wechselt der Kapazitätsanbieter von Amazon ECS Managed Instances in den `INACTIVE`-Status. Kapazitätsanbieter mit dem Status `INACTIVE` können für einen bestimmten Zeitraum im Konto erkennbar bleiben. Dieses Verhalten kann sich jedoch in Zukunft ändern und Sie sollten sich nicht darauf verlassen, dass `INACTIVE`-Kapazitätsanbieter bestehen bleiben. Bevor der Kapazitätsanbieter von Amazon ECS Managed Instances gelöscht wird, muss der Kapazitätsanbieter aus der Kapazitätsanbieter-Strategie aller Services entfernt werden. Sie können die `UpdateService`-API oder den Update-Service-Workflow in der Amazon-ECS-Konsole verwenden, um einen Kapazitätsanbieter aus der Kapazitätsanbieter-Strategie eines Service zu entfernen. Verwenden Sie die Option **Neue Bereitstellung erzwingen**, um sicherzustellen, dass alle Aufgaben, die die vom Kapazitätsanbieter bereitgestellte Kapazität in Amazon ECS Managed Instances verwenden, auf die Kapazität der übrigen Kapazitätsanbieter umgestellt werden.
**So löschen Sie einen Kapazitätsanbieter für den Cluster (Amazon-ECS-Konsole)**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie auf der *name* Seite **Cluster:** **Infrastructure**, den Kapazitätsanbieter für Amazon ECS Managed Instances, und wählen Sie dann **Löschen** aus.
1. Geben Sie im Bestätigungsfeld **Löschen** ein *Amazon ECS Managed Instances capacity provider name*
1. Wählen Sie **Löschen** aus.
# Amazon-ECS-Workloads, die in Amazon ECS Managed Instances ausgeführt werden, sicher anhalten
Mit Amazon ECS Task Scale-in Protection können Sie verhindern, dass Aufgaben durch Abskalierungsereignisse von der Service-Skalierung oder von Bereitstellungen beendet werden.
Bestimmte Anwendungen erfordern einen Mechanismus zum Schutz unternehmenskritischer Aufgaben vor der Beendigung durch Abskalierungsereignisse in Zeiten geringer Auslastung oder während Service-Bereitstellungen. Beispiel:
+ Sie verfügen über eine asynchrone Anwendung mit Warteschlangenverarbeitung, z. B. einen Video-Transkodierungsauftrag, bei dem einige Aufgaben stundenlang ausgeführt werden müssen, selbst wenn die kumulierte Service-Auslastung gering ist.
+ Sie haben eine Spieleanwendung, die Spieleserver als Aufgaben ausführt, die auch dann weiterlaufen müssen, wenn sich alle Benutzer abgemeldet haben, um die Startlatenz eines Serverneustarts zu verringern.
+ Wenn Sie eine neue Codeversion bereitstellen, müssen Aufgaben weiterhin ausgeführt werden, da eine erneute Verarbeitung kostenintesiv wäre.
Um zu verhindern, dass Aufgaben, die zu Ihrem Service gehören, bei einem Abskalierungs-Ereignis beendet werden, setzen Sie das `ProtectionEnabled`-Attribut auf `true`. Wenn Sie `ProtectionEnabled` auf „true“ setzen, sind Aufgaben standardmäßig für 2 Stunden geschützt. Sie können dann den Schutzzeitraum mithilfe des `ExpiresInMinutes`-Attributs anpassen. Sie können Ihre Aufgaben für mindestens 1 Minute und bis zu maximal 2 880 Minuten (48 Stunden) schützen. Wenn Sie die verwenden AWS CLI, können Sie die `--protection-enabled` Option angeben.
Nachdem eine Aufgabe ihre erforderliche Arbeit beendet hat, können Sie das `ProtectionEnabled`-Attribut auf `false` setzen, sodass die Aufgabe durch nachfolgende Abskalierungsereignisse beendet werden kann. Wenn Sie die verwenden AWS CLI, können Sie die `--no-protection-enabled` Option angeben.
## Mechanismen von Task Scale-in Protection
Task Scale-in Protection können Sie entweder über den Endpunkt des Amazon-ECS-Container-Agenten oder die Amazon-ECS-API einrichten und abrufen.
+ **Amazon-ECS-Container-Agent-Endpunkt**
Wir empfehlen die Verwendung des Amazon-ECS-Container-Agent-Endpunkts für Aufgaben, die den Schutzbedarf selbst bestimmen können. Verwenden Sie diesen Ansatz für warteschlangenbasierte oder Auftragsverarbeitungs-Workloads.
Wenn ein Container mit der Verarbeitung von Aufgaben beginnt, z. B. durch Konsumieren einer SQS-Nachricht, können Sie das `ProtectionEnabled`-Attribut über den Pfad des Endpunkts von Task Scale-in Protection `$ECS_AGENT_URI/task-protection/v1/state` innerhalb des Containers festlegen. Amazon ECS beendet diese Aufgabe bei Abskalierungsereignissen nicht. Nachdem die Aufgabe ihre Arbeit beendet hat, können Sie das `ProtectionEnabled`-Attribut mithilfe desselben Endpunkts zurücksetzen, so dass die Aufgabe bei nachfolgenden Abskalierungsereignissen beendet werden kann.
Weitere Informationen zur Verwendung des Agent-Endpunkts des Amazon-ECS-Containers finden Sie unter [Endpunkt von Amazon ECS Task Scale-in Protection](managed-instance-task-scale-in-protection-endpoint.md).
+ **Amazon-ECS-API**
Über die Amazon-ECS-API können Sie Task Scale-in Protection festlegen und abrufen, wenn Ihre Anwendung über eine Komponente verfügt, die den Status aktiver Aufgaben verfolgt. Verwenden Sie `UpdateTaskProtection`, um eine oder mehrere Aufgaben als geschützt zu markieren. Verwenden Sie `GetTaskProtection`, um den Schutzstatus abzurufen.
Ein Beispiel für diesen Ansatz wäre, wenn Ihre Anwendung Spielserver-Sitzungen als Amazon-ECS-Aufgaben hostet. Wenn sich ein Benutzer bei einer Sitzung auf dem Server (Aufgabe) anmeldet, können Sie die Aufgabe als geschützt markieren. Nachdem sich der Benutzer abgemeldet hat, können Sie entweder den Schutz speziell für diese Aufgabe aufheben oder den Schutz für ähnliche Aufgaben, die keine aktiven Sitzungen mehr haben, regelmäßig aufheben, je nachdem, ob Sie Server im Leerlauf halten möchten.
Weitere Informationen finden Sie unter [UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html)und [GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html)in der *Amazon Elastic Container Service API-Referenz*.
Sie können beide Ansätze kombinieren. Verwenden Sie beispielsweise den Amazon-ECS-Agent-Endpunkt, um den Aufgabenschutz innerhalb eines Containers einzurichten, und verwenden Sie die Amazon-ECS-API, um den Aufgabenschutz für Ihren externen Controller-Service zu entfernen.
## Überlegungen
Berücksichtigen Sie die folgenden Punkte, bevor Sie Task Scale-in Protection verwenden:
+ Task Scale-in Protection wird nur für Aufgaben unterstützt, die über einen Service bereitgestellt werden.
+ Task Scale-in Protection wird für Aufgaben unterstützt, die über einen Service bereitgestellt werden, der in Amazon ECS Managed Instances ausgeführt wird.
+ Wir empfehlen die Verwendung des Amazon-ECS-Container-Agent-Endpunkts, da der Amazon-ECS-Agent über integrierte Wiederholungsmechanismen und eine einfachere Schnittstelle verfügt.
+ Sie können den Ablaufzeitraum für Task Scale-in Protection zurücksetzen, indem Sie `UpdateTaskProtection` für eine Aufgabe aufrufen, für die der Schutz bereits aktiviert ist.
+ Bestimmen Sie, wie lange eine Aufgabe benötigen würde, um ihre erforderliche Arbeit abzuschließen, und legen Sie die `expiresInMinutes`-Eigenschaft entsprechend fest. Wenn Sie den Ablauf des Schutzes länger als nötig festlegen, entstehen Ihnen Kosten und Verzögerungen bei der Bereitstellung neuer Aufgaben.
+ Überlegungen zur Bereitstellung:
+ Wenn der Service eine fortlaufende Aktualisierung verwendet, werden neue Aufgaben erstellt, aber Aufgaben mit älteren Versionen werden nicht beendet, bis `protectionEnabled` gelöscht wird oder abläuft. Sie können den `maximumPercentage`-Parameter in der Bereitstellungskonfiguration auf einen Wert anpassen, der es ermöglicht, neue Aufgaben zu erstellen, wenn alte Aufgaben geschützt sind.
+ Wenn Sie dies verwenden CloudFormation, hat der Update-Stack ein Timeout von 3 Stunden. Wenn Sie also Ihren Task-Schutz auf mehr als 3 Stunden einstellen, kann Ihre CloudFormation Implementierung zu einem Ausfall und Rollback führen.
Während der Zeit, in der Ihre alten Aufgaben geschützt sind, wird der CloudFormation Stack angezeigt`UPDATE_IN_PROGRESS`. Wenn Task Scale-in Protection entfernt wird oder innerhalb des 3-Stunden-Fensters abläuft, wird Ihre Bereitstellung erfolgreich sein und in den Status `UPDATE_COMPLETE` wechseln. Wenn die Bereitstellung länger als 3 Stunden in `UPDATE_IN_PROGRESS` verharrt, schlägt sie fehl, zeigt den `UPDATE_FAILED`-Status an und wird dann auf den alten Aufgabensatz zurückgesetzt.
+ Amazon ECS sendet Service-Ereignisse, wenn geschützte Aufgaben eine Bereitstellung (fortlaufend oder blau/grün) davon abhalten, den stabilen Zustand zu erreichen, so dass Sie Abhilfemaßnahmen ergreifen können. Wenn Sie beim Versuch, den Schutzstatus einer Aufgabe zu aktualisieren, eine `DEPLOYMENT_BLOCKED`-Fehlermeldung erhalten, bedeutet dies, dass der Service über mehr geschützte Aufgaben verfügt als die gewünschte Anzahl von Aufgaben für den Service. Führen Sie einen der folgenden Schritte aus, um diesen Fehler zu beheben:
+ Warten Sie, bis der aktuelle Aufgabenschutz abgelaufen ist. Stellen Sie dann den Aufgabenschutz ein.
+ Stellen Sie fest, welche Aufgaben angehalten werden können. Dann verwenden Sie `UpdateTaskProtection` mit der auf `false` festgelegten `protectionEnabled`-Option für diese Aufgaben.
+ Erhöhen Sie die Anzahl der gewünschten Aufgaben des Services auf mehr als die Anzahl der geschützten Aufgaben.
## Für Task Scale-in Protection erforderliche IAM-Berechtigungen
Die Aufgabe muss über die Amazon-ECS-Aufgabenrolle mit den folgenden Berechtigungen verfügen:
+ `ecs:GetTaskProtection`: Erlaubt dem Amazon-ECS-Container-Agenten `GetTaskProtection` aufzurufen.
+ `ecs:UpdateTaskProtection`: Erlaubt dem Amazon-ECS-Container-Agenten `UpdateTaskProtection` aufzurufen.
# Endpunkt von Amazon ECS Task Scale-in Protection
Der Amazon-ECS-Container-Agent fügt die `ECS_AGENT_URI`-Umgebungsvariable automatisch in die Amazon-ECS-Aufgabencontainer ein, um eine Methode für die Interaktion mit dem Container-Agent-API-Endpunkt bereitzustellen.
Wir empfehlen die Verwendung des Amazon-ECS-Container-Agent-Endpunkts für Aufgaben, die den Schutzbedarf selbst bestimmen können.
Wenn ein Container mit der Verarbeitung von Aufgaben beginnt, können Sie das `protectionEnabled`-Attribut über den Pfad des Endpunkts von Task Scale-in Protection `$ECS_AGENT_URI/task-protection/v1/state` innerhalb des Containers festlegen.
Eine PUT-Anfrage an diesen URI innerhalb eines Containers legt Task Scale-in Protection fest. Eine GET-Anfrage an diese URI ruft den aktuellen Schutzstatus einer Aufgabe ab.
## Anfrageparameter von Task Scale-in Protection
Task Scale-in Protection können Sie mithilfe des `${ECS_AGENT_URI}/task-protection/v1/state`-Endpunkts mit den folgenden Anfrageparametern einrichten.
`ProtectionEnabled`
Geben Sie `true` an, um eine Aufgabe als geschützt zu markieren. Geben Sie `false` an, um den Schutz aufzuheben und die Aufgabe für die Beendigung zu berechtigen.
Typ: Boolescher Wert
Erforderlich: Ja
`ExpiresInMinutes`
Die Anzahl der Minuten, für die Aufgabe geschützt ist. Sie können mindestens 1 Minute bis zu 2 880 Minuten (48 Stunden) angeben. Während dieses Zeitraums wird Ihre Aufgabe nicht durch Abskalierungsereignisse des Services Auto Scaling oder durch Bereitstellungen beendet. Nach Ablauf dieses Zeitraums wird der `protectionEnabled`-Parameter auf `false` gesetzt.
Wenn Sie keinen Zeitraum angeben, wird die Aufgabe automatisch für 120 Minuten (2 Stunden) geschützt.
Typ: Ganzzahl
Erforderlich: Nein
Die folgenden Beispiele zeigen, wie Sie den Aufgabenschutz mit unterschiedlichen Laufzeiten festlegen können.
**Beispiel für den Schutz einer Aufgabe mit der Standardzeitspanne**
Dieses Beispiel zeigt, wie eine Aufgabe mit dem Standardzeitraum von 2 Stunden geschützt wird.
```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}'
```
**Beispiel dafür, wie eine Aufgabe 60 Minuten lang geschützt wird**
Dieses Beispiel zeigt, wie eine Aufgabe mit dem `expiresInMinutes`-Parameter 60 Minuten lang geschützt wird.
```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}'
```
**Beispiel dafür, wie eine Aufgabe 24 Stunden lang geschützt wird**
Dieses Beispiel zeigt, wie eine Aufgabe mit dem `expiresInMinutes`-Parameter 24 Stunden lang geschützt wird.
```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}'
```
Die PUT-Anfrage gibt die folgende Antwort zurück.
```
{
"protection": {
"ExpirationDate": "2023-12-20T21:57:44.837Z",
"ProtectionEnabled": true,
"TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
}
}
```
## Antwortparameter von Task Scale-in Protection
Die folgenden Informationen werden in der JSON-Antwort des Endpunkts `${ECS_AGENT_URI}/task-protection/v1/state` von Task Scale-in Protection zurückgegeben.
`ExpirationDate`
Die Epochenzeit, zu der der Schutz für die Aufgabe abläuft. Wenn die Aufgabe nicht geschützt ist, ist dieser Wert Null.
`ProtectionEnabled`
Der Schutzstatus der Aufgabe. Wenn der Abskalierungsschutz für eine Aufgabe aktiviert ist, ist der Wert `true`. Andernfalls ist es `false`.
`TaskArn`
Der vollständige Amazon Resource Name (ARN) der Aufgabe, zu der der Container gehört.
Das folgende Beispiel zeigt die für eine geschützte Aufgabe zurückgegebenen Details.
```
curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
```
```
{
"protection":{
"ExpirationDate":"2023-12-20T21:57:44Z",
"ProtectionEnabled":true,
"TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
}
}
```
Die folgenden Informationen werden zurückgegeben, wenn ein Fehler auftritt.
`Arn`
Der vollständige Amazon-Ressourcenname (ARN) der Aufgabe.
`Detail`
Die auf den Fehler bezogenen Details.
`Reason`
Der Grund für den Fehlschlag.
Das folgende Beispiel zeigt die für eine nicht geschützte Aufgabe zurückgegebenen Details.
```
{
"failure":{
"Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0",
"Detail":null,
"Reason":"TASK_NOT_VALID"
}
}
```
Die folgenden Informationen werden zurückgegeben, wenn eine Ausnahme auftritt.
`requestID`
Die AWS Anforderungs-ID für den Amazon ECS-API-Aufruf, der zu einer Ausnahme führt.
`Arn`
Der vollständige Amazon-Ressourcenname (ARN) der Aufgabe oder des Services.
`Code`
Der Fehlercode.
`Message`
Die Fehlermeldung.
Wenn ein `RequestError`- oder `RequestTimeout`-Fehler auftritt, ist es wahrscheinlich, dass es sich um ein Netzwerkproblem handelt. Versuchen Sie, VPC-Endpunkte für Amazon ECS zu verwenden.
Das folgende Beispiel zeigt die Details, die zurückgegeben werden, wenn ein Fehler auftritt.
```
{
"requestID":"12345-abc-6789-0123-abc",
"error":{
"Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
"Code":"AccessDeniedException",
"Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action"
}
}
```
Der folgende Fehler wird angezeigt, wenn der Amazon-ECS-Agent aus Gründen wie Netzwerkproblemen oder einem Ausfall der Amazon-ECS-Steuerebene keine Antwort vom Amazon-ECS-Endpunkt erhalten kann.
```
{
"error": {
"Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
"Code": "RequestCanceled",
"Message": "Timed out calling Amazon ECS Task Protection API"
}
}
```
Der folgende Fehler wird angezeigt, wenn der Amazon-ECS-Agent eine Drosselungsausnahme von Amazon ECS erhält.
```
{
"requestID": "12345-abc-6789-0123-abc",
"error": {
"Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
"Code": "ThrottlingException",
"Message": "Rate exceeded"
}
}
```
# Amazon-ECS-Cluster für Fargate
Mit Amazon ECS on AWS Fargate Capacity Providers können Sie sowohl Fargate- als auch Fargate Spot-Kapazitäten für Ihre Amazon ECS-Aufgaben nutzen.
Mit Fargate Spot können Sie unterbrechungstolerante Amazon-ECS-Aufgaben zu einer im Vergleich zum Fargate-Preis ermäßigten Gebühr ausführen. 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.
Wenn Aufgaben, die die Kapazitätsanbieter Fargate und Fargate Spot verwenden, gestoppt werden, wird das Ereignis zur Änderung des Aufgabenstatus an Amazon gesendet. EventBridge Der Grund für das Anhalten gibt eine Beschreibung der Ursache an. Weitere Informationen finden Sie unter [Statussänderungs-Ereignisse für Amazon-ECS-Aufgaben](ecs_task_events.md).
Ein Cluster kann eine Mischung aus Fargate- und Auto-Scaling-Gruppen-Kapazitätsanbietern enthalten. Eine Kapazitätsanbieter-Strategie kann jedoch nur entweder Fargate- oder Auto-Scaling-Gruppen-Kapazitätsanbieter enthalten, aber nicht beide. Weitere Informationen finden Sie unter [Kapazitätsanbieter für Auto-Scaling-Gruppen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html#asg-capacity-providers).
Berücksichtigen Sie bei der Verwendung von Kapazitätsanbietern die folgenden Punkte:
+ Sie müssen den Kapazitätsanbieter zunächst einem Cluster zuordnen, bevor Sie ihn der Kapazitätsanbieter-Strategie zuordnen können.
+ Sie können maximal 20 Kapazitätsanbieter für eine Kapazitätsanbieter-Strategie angeben.
+ Sie können einen Service, der einen Kapazitätsanbieter einer Auto-Scaling-Gruppe verwendet, nicht aktualisieren, um einen Fargate-Kapazitätsanbieter zu verwenden. Das Gegenteil ist der Fall.
+ Wenn in einer Kapazitätsanbieter-Strategie kein `weight`-Wert für einen Kapazitätsanbieter in der Konsole angegeben ist, wird der Standardwert von `1` verwendet. Wenn Sie die API oder verwenden AWS CLI, `0` wird der Standardwert von verwendet.
+ Wenn in einer Kapazitätsanbieter-Strategie mehrere Kapazitätsanbieter angegeben sind, muss mindestens einer der Kapazitätsanbieter eine Gewichtung haben, die größer ist als Null. Kapazitätsanbieter mit einer Gewichtung von Null werden nicht für die Aufgabenplatzierung verwendet. Wenn Sie in einer Strategie mehrere Kapazitätsanbieter mit derselben Gewichtung von Null angeben, schlagen alle `RunTask`- oder `CreateService`-Aktionen, die die Kapazitätsanbieter-Strategie verwenden, fehl.
+ In einer Kapazitätsanbieter-Strategie kann nur für einen Kapazitätsanbieter ein *Basis*-Wert festgelegt werden. Wenn kein Basiswert angegeben wird, wird der Standardwert Null verwendet.
+ Ein Cluster kann eine Mischung aus Kapazitätsanbietern für Auto-Scaling-Gruppen und Fargate-Kapazitätsanbietern enthalten. Eine Kapazitätsanbieter-Strategie kann jedoch nur Kapazitätsanbieter der Auto-Scaling-Gruppe oder Fargate enthalten, aber nicht beides.
+ Ein Cluster kann eine Mischung aus Services und eigenständigen Aufgaben enthalten, die beide Kapazitätsanbieter verwenden. Ein Service kann aktualisiert werden, um anstelle eines Starttyps eine Kapazitätsanbieter-Strategie zu verwenden. Allerdings müssen Sie dabei eine neue Bereitstellung erzwingen.
## Fargate-Spot-Beendigungsnachrichten
In Zeiten extrem hoher Nachfrage sind die Kapazitäten von Fargate Spot möglicherweise nicht verfügbar. Dies kann dazu führen, dass Fargate-Spot-Aufgaben verzögert werden. In diesen Fällen versuchen die Amazon-ECS-Services erneut, Aufgaben zu starten, bis die erforderliche Kapazität verfügbar ist. Fargate ersetzt Spot-Kapazität nicht durch On-Demand-Kapazität.
Wenn Aufgaben, die Fargate Spot-Kapazität verwenden, aufgrund einer Spot-Unterbrechung angehalten werden, wird zwei Minuten, bevor eine Aufgabe angehalten wird, eine Warnung gesendet. Die Warnung wird als Ereignis zur Änderung des Aufgabenstatus an Amazon EventBridge und als SIGTERM-Signal an die laufende Aufgabe gesendet. Wenn Sie Fargate Spot als Teil eines Service verwenden, empfängt der Service-Planer in diesem Szenario das Unterbrechungssignal und versucht, zusätzliche Aufgaben auf Fargate Spot zu starten, wenn Kapazität verfügbar ist. Ein Service mit nur einer Aufgabe wird unterbrochen, bis Kapazität verfügbar ist. Weitere Informationen zu einem korrekten Herunterfahren finden Sie unter [Korrektes Herunterfahren mit ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/).
Um sicherzustellen, dass Ihre Container korrekt beendet werden, bevor die Aufgabe endet, können Sie Folgendes konfigurieren:
+ In der Containerdefinition, die die Aufgabe verwendet, kann ein `stopTimeout`-Wert von `120` Sekunden oder weniger angegeben werden. Der `stopTimeout`-Standardwert liegt bei 30 Sekunden. Sie können einen längeren `stopTimeout`-Wert angeben, um mehr Zeit zwischen dem Eingang des Ereignisses zur Änderung des Aufgabenstatus und dem Zeitpunkt, an dem der Container zwangsweise angehalten wird, zu gewinnen. Weitere Informationen finden Sie unter [Container-Timeouts](task_definition_parameters.md#container_definition_timeout).
+ Das SIGTERM-Signal muss innerhalb des Containers empfangen werden, um alle Bereinigungsaktionen ausführen zu können. Wird dieses Signal nicht verarbeitet, erhält die Aufgabe nach dem konfigurierten `stopTimeout` ein SIGKILL-Signal, was zu Datenverlust oder -beschädigung führen kann.
Das Folgende ist ein Ausschnitt eines Ereignisses zur Änderung des Aufgabenstatus. Dieser Codeausschnitt zeigt den Anhaltegrund und den Anhaltecode für eine Fargate-Spot-Unterbrechung an.
```
{
"version": "0",
"id": "9bcdac79-b31f-4d3d-9410-fbd727c29fab",
"detail-type": "ECS Task State Change",
"source": "aws.ecs",
"account": "111122223333",
"resources": [
"arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6f1cebef"
],
"detail": {
"clusterArn": "arn:aws:ecs:us-east-1:111122223333:cluster/default",
"createdAt": "2016-12-06T16:41:05.702Z",
"desiredStatus": "STOPPED",
"lastStatus": "RUNNING",
"stoppedReason": "Your Spot Task was interrupted.",
"stopCode": "SpotInterruption",
"taskArn": "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6fEXAMPLE",
...
}
}
```
Das Folgende ist ein Ereignismuster, das verwendet wird, um eine EventBridge Regel für Ereignisse zur Änderung des Amazon ECS-Aufgabenstatus zu erstellen. Optional können Sie einen Cluster im `detail`-Feld angeben. Das bedeutet, dass Sie Ereignisse zur Statusänderung von Aufgaben für diesen Cluster erhalten. Weitere Informationen zum Erstellen einer EventBridge Regel finden Sie unter [Erste Schritte mit Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) im * EventBridge Amazon-Benutzerhandbuch*.
```
{
"source": [
"aws.ecs"
],
"detail-type": [
"ECS Task State Change"
],
"detail": {
"clusterArn": [
"arn:aws:ecs:us-west-2:111122223333:cluster/default"
]
}
}
```
# Erstellen eines Amazon-ECS-Clusters für Fargate-Workloads
Sie erstellen einen Cluster, um die Infrastruktur zu definieren, auf der Ihre Aufgaben und Services ausgeführt werden.
Bevor Sie beginnen, vergewissern Sie sich, dass Sie die Schritte in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) ausgeführt haben, und weisen Sie die entsprechende IAM-Berechtigung zu. Weitere Informationen finden Sie unter [Beispiele für Amazon-ECS-Cluster](security_iam_id-based-policy-examples.md#IAM_cluster_policies). Die Amazon ECS-Konsole erstellt die Ressourcen, die von einem Amazon ECS-Cluster benötigt werden, indem sie einen CloudFormation Stack erstellt.
Die Konsole ordnet die Fargate- und Fargate-Spot-Kapazitätsanbieter dem Cluster automatisch zu.
Sie können die folgenden Optionen ändern:
+ Fügen Sie dem Cluster einen Namespace hinzu.
Über einen Namespace können Services, die Sie im Cluster erstellen, ohne zusätzliche Konfiguration eine Verbindung zu den anderen Services im Namespace herstellen. Weitere Informationen finden Sie unter [Amazon-ECS-Services verbinden](interconnecting-services.md).
+ Aktivieren Sie Aufgabenereignisse, um EventBridge Benachrichtigungen über Änderungen des Aufgabenstatus zu erhalten.
+ Fügen Sie Tags hinzu, die Ihnen helfen, Ihren Cluster zu identifizieren.
+ Weisen Sie Ihrem verwalteten Speicher einen AWS KMS Schlüssel zu. Weitere Informationen zur Erstellung eines Schlüssels finden Sie unter [Einen KMS-Schlüssel erstellen](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) im *Benutzerhandbuch für AWS Key Management Service *.
+ Weisen Sie einen AWS KMS Schlüssel für Ihren kurzlebigen Fargate-Speicher zu. Weitere Informationen zur Erstellung eines Schlüssels finden Sie unter [Einen KMS-Schlüssel erstellen](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) im *Benutzerhandbuch für AWS Key Management Service *.
+ Konfigurieren Sie den AWS KMS Schlüssel und die Protokollierung für ECS Exec.
## Verfahren
**So erstellen Sie einen neuen Cluster (Amazon ECS-Konsole)**
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 die zu verwendende Region in der Navigationsleiste aus.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der Seite **Clusters** die Option **Create cluster** (Cluster erstellen) aus.
1. Konfigurieren Sie unter **Clusterkonfiguration** Folgendes:
+ Geben Sie für **Cluster-Name** einen eindeutigen Namen ein.
Der Name kann bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern und Bindestriche enthalten.
+ (Optional) Wenn der für Service Connect verwendete Namespace nicht mit dem Cluster-Namen identisch sein soll, geben Sie unter **Service-Connect-Standardeinstellungen** für **Standard-Namespace** einen eindeutigen Namen ein. Um einen gemeinsam genutzten Namespace zu verwenden, wählen Sie einen Namespace-ARN aus oder geben Sie ihn ein. Weitere Informationen zur Verwendung von geteilten Namespaces finden Sie unter [Amazon ECS Service Connect mit gemeinsam genutzten AWS Cloud Map Namespaces](service-connect-shared-namespaces.md).
1. (Optional) Verwenden Sie Container Insights, erweitern Sie **Überwachung** und wählen Sie dann eine der folgenden Optionen:
+ Um das empfohlene Container Insights mit verbesserter Beobachtbarkeit zu verwenden, wählen Sie **Container Insights mit verbesserter Beobachtbarkeit**.
+ Um Container Insights zu verwenden, wählen Sie **Container Insights**.
1. (Optional) Um Aufgabenereignisse zu aktivieren, erweitern Sie **Aufgabenereignisse** und aktivieren Sie dann **Aufgabenereignisse aktivieren**.
Wenn Sie Aufgabenereignisse aktivieren, sendet Amazon ECS Ereignisse zur Änderung des Aufgabenstatus an EventBridge. Auf diese Weise können Sie Änderungen im Aufgabenlebenszyklus automatisch überwachen und darauf reagieren.
1. (Optional) Um ECS Exec zum Debuggen von Aufgaben im Cluster zu verwenden, erweitern Sie **Konfiguration zur Fehlerbehebung** und konfigurieren Sie dann Folgendes:
+ (Optional) Geben Sie unter **AWS KMS Schlüssel für ECS Exec** den ARN des AWS KMS Schlüssels ein, den Sie zur Verschlüsselung der ECS Exec-Sitzungsdaten verwenden möchten.
+ (Optional) Wählen Sie für die **ECS-Exec-Protokollierung** das Protokollziel aus:
+ Um Logs an CloudWatch Logs zu senden, wählen Sie **Amazon CloudWatch**.
+ Um Protokolle an Amazon S3 zu senden, wählen Sie **Amazon S3**.
+ Um die Protokollierung zu deaktivieren, wählen Sie **Keine**.
1. (Optional) Unter **Verschlüsselung** können Sie Folgendes konfigurieren:
+ Verschlüsseln Sie Ihre Daten auf dem flüchtigen Speicher von Fargate. Geben Sie unter **Verschlüsselung** für **Fargate Ephemeral Storage** den ARN des AWS KMS Schlüssels ein, den Sie zur Verschlüsselung der Fargate-Ephemeral Storage-Daten verwenden möchten.
+ Verschlüsseln Sie die Daten im verwalteten Speicher. Geben Sie unter **Verschlüsselung** für **verwalteten Speicher** den ARN des AWS KMS Schlüssels ein, den Sie zum Verschlüsseln der verwalteten Speicherdaten verwenden möchten.
1. (Optional) Um Ihren Cluster leichter identifizieren zu können, erweitern Sie den Bereich **Tags**, und konfigurieren Sie dann Ihre Tags.
[Markierung hinzufügen] Wählen Sie **Add tag (Markierung hinzufügen)**, und führen Sie die folgenden Schritte aus:
+ Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein.
+ Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein.
[Markierung entfernen] Wählen Sie **Remove (Entfernen)** rechts neben dem Schlüssel und dem Wert der Markierung.
1. Wählen Sie **Erstellen** aus.
## Nächste Schritte
Nachdem Sie den Cluster erstellt haben, können Sie Aufgabendefinitionen für Ihre Anwendungen erstellen und diese dann als eigenständige Aufgaben oder als Teil eines Services ausführen. Weitere Informationen finden Sie hier:
+ [Amazon-ECS-Aufgabendefinitionen](task_definitions.md)
+ [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md)
+ [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md)
# Amazon-ECS-Kapazitätsanbieter für EC2-Workloads
Wenn Sie Amazon-EC2-Instances für Ihre Kapazität nutzen, verwenden Sie Auto-Scaling-Gruppen, um die Amazon-EC2-Instances zu verwalten, die in ihren Clustern registriert sind. Auto Scaling hilft Ihnen dabei, sicherzustellen, dass Sie die richtige Anzahl von Amazon-EC2-Instances zur Verfügung haben, um die Auslastung Ihrer Anwendung zu bewältigen.
Sie können das Feature zur verwalteten Skalierung verwenden, damit Amazon ECS die Auf- und Abskalierungsaktionen der Auto-Scaling-Gruppe verwaltet. Alternativ können Sie die Skalierungsaktionen selbst verwalten. Weitere Informationen finden Sie unter [Automatische Verwaltung der Amazon-ECS-Kapazität mit Cluster-Auto-Scaling](cluster-auto-scaling.md).
Wir empfehlen, dass Sie eine neue leere Auto-Scaling-Gruppe erstellen. Bei Verwendung einer vorhandenen Auto-Scaling-Gruppe kann es vorkommen, dass Amazon-EC2-Instances, die der Gruppe zugeordnet sind und die bereits ausgeführt und bei einem Amazon-ECS-Cluster registriert waren, bevor die Auto-Scaling-Gruppe zur Erstellung eines Kapazitätsanbieters verwendet wurde, nicht ordnungsgemäß bei dem Kapazitätsanbieter registriert werden. Dies kann Probleme verursachen, wenn der Kapazitätsanbieter in einer Kapazitätsanbieter-Strategie verwendet wird. Verwenden Sie `DescribeContainerInstances`, um zu bestätigen, ob eine Container-Instance einem Kapazitätsanbieter zugeordnet ist oder nicht.
**Anmerkung**
Um eine leere Auto-Scaling-Gruppe zu erstellen, setzen Sie die gewünschte Anzahl auf Null. Nachdem Sie den Kapazitätsanbieter erstellt und einem Cluster zugeordnet haben, können Sie ihn aufskalieren.
Wenn Sie die Amazon ECS-Konsole verwenden, erstellt Amazon ECS in Ihrem Namen eine Amazon EC2 EC2-Startvorlage und eine Auto Scaling Scaling-Gruppe als Teil des CloudFormation Stacks. Ihnen wird das Präfix `EC2ContainerService-` vorangestellt. Sie können die Auto-Scaling-Gruppe als Kapazitätsanbieter für diesen Cluster verwenden.
Wir empfehlen Ihnen, Managed Instance Draining zu verwenden, um Amazon-EC2-Instances ordnungsgemäß zu beenden, ohne Ihre Workloads zu stören. Dieses Feature ist standardmäßig aktiviert. Weitere Informationen finden Sie unter [Amazon-ECS-Workloads, die auf EC2-Instances ausgeführt werden, sicher anhalten](managed-instance-draining.md).
Beachten Sie Folgendes, wenn Sie die Kapazitätsanbieter der Auto-Scaling-Gruppe in der Konsole verwenden:
+ Eine Auto-Scaling-Gruppe muss eine `MaxSize` größer als Null haben, um eine Aufskalierung zu ermöglichen.
+ Die Auto-Scaling-Gruppe kann keine Einstellungen für die Instance-Gewichtung haben.
+ Wenn die Auto-Scaling-Gruppe nicht aufskaliert werden kann, um die Anzahl der ausgeführten Aufgaben aufzunehmen, können die Aufgaben nicht über den `PROVISIONING`-Status hinausgehen.
+ Ändern Sie nicht die Ressource der Skalierungsrichtlinie, die Ihren Auto-Scaling-Gruppen zugeordnet ist, die von Kapazitätsanbietern verwaltet werden.
+ Wenn die verwaltete Skalierung beim Erstellen eines Kapazitätsanbieters aktiviert ist, kann die gewünschte Anzahl der Auto-Scaling-Gruppe auf `0` festgelegt werden. Wenn die verwaltete Skalierung aktiviert ist, verwaltet Amazon ECS die Auf- und Abskalierungsaktionen der Auto-Scaling-Gruppe.
+ Sie müssen den Kapazitätsanbieter zunächst einem Cluster zuordnen, bevor Sie ihn der Kapazitätsanbieter-Strategie zuordnen können.
+ Sie können maximal 20 Kapazitätsanbieter für eine Kapazitätsanbieter-Strategie angeben.
+ Sie können einen Service, der einen Kapazitätsanbieter einer Auto-Scaling-Gruppe verwendet, nicht aktualisieren, um einen Fargate-Kapazitätsanbieter zu verwenden. Das Gegenteil ist der Fall.
+ Wenn in einer Kapazitätsanbieter-Strategie kein `weight`-Wert für einen Kapazitätsanbieter in der Konsole angegeben ist, wird der Standardwert von `1` verwendet. Wenn Sie die API oder verwenden AWS CLI, `0` wird der Standardwert von verwendet.
+ Wenn in einer Kapazitätsanbieter-Strategie mehrere Kapazitätsanbieter angegeben sind, muss mindestens einer der Kapazitätsanbieter eine Gewichtung haben, die größer ist als Null. Kapazitätsanbieter mit einer Gewichtung von Null werden nicht für die Aufgabenplatzierung verwendet. Wenn Sie in einer Strategie mehrere Kapazitätsanbieter mit derselben Gewichtung von Null angeben, schlagen alle `RunTask`- oder `CreateService`-Aktionen, die die Kapazitätsanbieter-Strategie verwenden, fehl.
+ In einer Kapazitätsanbieter-Strategie kann nur für einen Kapazitätsanbieter ein *Basis*-Wert festgelegt werden. Wenn kein Basiswert angegeben wird, wird der Standardwert Null verwendet.
+ Ein Cluster kann eine Mischung aus Kapazitätsanbietern für Auto-Scaling-Gruppen und Fargate-Kapazitätsanbietern enthalten. Eine Kapazitätsanbieter-Strategie kann jedoch nur Kapazitätsanbieter der Auto-Scaling-Gruppe oder Fargate enthalten, aber nicht beides.
+ Ein Cluster kann eine Mischung aus Services und eigenständigen Aufgaben enthalten, die sowohl Kapazitätsanbieter als auch Starttypen verwenden. Ein Service kann aktualisiert werden, um anstelle eines Starttyps eine Kapazitätsanbieter-Strategie zu verwenden. Allerdings müssen Sie dabei eine neue Bereitstellung erzwingen.
+ Amazon ECS unterstützt Warm-Pools für Amazon EC2 Auto Scaling. Ein Warm-Pool ist eine Gruppe von vorinitialisierten Amazon-EC2-Instances, die bereit sind, in Betrieb genommen zu werden. Wann immer Ihre Anwendung aufskaliert werden muss, verwendet Amazon EC2 Auto Scaling die vor-initialisierten Instances aus dem warmen Pool, anstatt kalte Instances zu starten. Dadurch kann ggf. ein letzter Initialisierungsprozess ausgeführt werden, bevor die Instance in Betrieb genommen wird. Weitere Informationen finden Sie unter [Konfiguration vorinitialisierter Instances für Ihre Auto-Scaling-Gruppe in Amazon ECS](using-warm-pool.md).
Weitere Informationen zum Erstellen einer Startvorlage für Amazon EC2 Auto Scaling finden Sie unter [Auto-Scaling-Startvorlagen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html) im *Benutzerhandbuch für Amazon EC2 Auto Scaling*. Weitere Informationen zum Erstellen einer Gruppe für Amazon EC2 Auto Scaling finden Sie unter [Auto-Scaling-Gruppen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) im *Benutzerhandbuch zu Amazon EC2 Auto Scaling*.
# Sicherheitsüberlegungen zu Amazon-EC2-Container-Instances für Amazon ECS
Sie sollten eine einzelne Container-Instance und ihren Zugriff innerhalb Ihres Bedrohungsmodells berücksichtigen. Beispielsweise könnte eine einzelne betroffene Aufgabe in der Lage sein, die IAM-Berechtigungen einer nicht infizierten Aufgabe auf derselben Instance zu nutzen.
Wir empfehlen Ihnen Folgendes, um dies zu verhindern:
+ Verwenden Sie bei der Ausführung Ihrer Aufgaben keine Administratorrechte.
+ Weisen Sie Ihren Aufgaben eine Aufgabenrolle mit der geringsten Berechtigung zu.
Der Container-Agent erstellt automatisch ein Token mit einer eindeutigen Anmeldeinformations-ID, das für den Zugriff auf Amazon-ECS-Ressourcen verwendet wird.
+ Um zu verhindern, dass Container, die von Aufgaben ausgeführt werden, die den `awsvpc`-Netzwerkmodus verwenden, auf die Anmeldeinformationen zugreifen, die dem Amazon-EC2-Instance-Profil zugewiesen wurden, während die Berechtigungen, die von der Aufgabenrolle bereitgestellt werden, weiterhin zulässig sind, setzen Sie die `ECS_AWSVPC_BLOCK_IMDS`-Agentenkonfigurationsvariable in der Agentenkonfigurationsdatei auf wahr und starten Sie den Agenten neu.
+ Verwenden Sie Amazon GuardDuty Runtime Monitoring, um Bedrohungen für Cluster und Container in Ihrer AWS Umgebung zu erkennen. Runtime Monitoring verwendet einen GuardDuty Sicherheitsagenten, der die Laufzeit einzelner Amazon ECS-Workloads transparent macht, z. B. Dateizugriff, Prozessausführung und Netzwerkverbindungen. Weitere Informationen finden Sie unter [GuardDutyRuntime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) im *GuardDuty Benutzerhandbuch*.
# Erstellen eines Amazon-ECS-Clusters für Amazon-EC2-Workloads
Sie erstellen einen Cluster, um die Infrastruktur zu definieren, auf der Ihre Aufgaben und Services ausgeführt werden.
Bevor Sie beginnen, vergewissern Sie sich, dass Sie die Schritte in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) ausgeführt haben, und weisen Sie die entsprechende IAM-Berechtigung zu. Weitere Informationen finden Sie unter [Beispiele für Amazon-ECS-Cluster](security_iam_id-based-policy-examples.md#IAM_cluster_policies). Die Amazon ECS-Konsole bietet eine einfache Möglichkeit, die Ressourcen zu erstellen, die von einem Amazon ECS-Cluster benötigt werden, indem ein CloudFormation Stack erstellt wird.
Um den Prozess der Clustererstellung so einfach wie möglich zu gestalten, verfügt die Konsole über Standardauswahlen für viele Auswahlmöglichkeiten, die wir unten beschreiben. Es gibt auch Hilfe-Panels für die meisten Abschnitte in der Konsole, die weiteren Kontext bieten.
Sie können Amazon-EC2-Instances registrieren, wenn Sie den Cluster erstellen, oder zusätzliche Instances mit dem Cluster registrieren, nachdem er erstellt wurde.
Sie können die folgenden Standardoptionen ändern:
+ Ändern Sie die Subnetze, in denen Ihre Instances gestartet werden
+ Ändern Sie die Sicherheitsgruppen, die zur Steuerung des Datenverkehrs zu den Container-Instances verwendet werden
+ Fügen Sie dem Cluster einen Namespace hinzu.
Über einen Namespace können Services, die Sie im Cluster erstellen, ohne zusätzliche Konfiguration eine Verbindung zu den anderen Services im Namespace herstellen. Weitere Informationen finden Sie unter [Amazon-ECS-Services verbinden](interconnecting-services.md).
+ Aktivieren Sie Aufgabenereignisse, um EventBridge Benachrichtigungen über Änderungen des Aufgabenstatus zu erhalten.
+ Weisen Sie Ihrem verwalteten Speicher einen AWS KMS Schlüssel zu. Weitere Informationen zur Erstellung eines Schlüssels finden Sie unter [Einen KMS-Schlüssel erstellen](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) im *Benutzerhandbuch für AWS Key Management Service *.
+ Weisen Sie einen AWS KMS Schlüssel für Ihren kurzlebigen Fargate-Speicher zu. Weitere Informationen zur Erstellung eines Schlüssels finden Sie unter [Einen KMS-Schlüssel erstellen](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) im *Benutzerhandbuch für AWS Key Management Service *.
+ Konfigurieren Sie den AWS KMS Schlüssel und die Protokollierung für ECS Exec.
+ Fügen Sie Tags hinzu, die Ihnen helfen, Ihren Cluster zu identifizieren.
## Optionen für Auto-Scaling-Gruppen
Wenn Sie Amazon-EC2-Instances verwenden, müssen Sie eine Auto-Scaling-Gruppe angeben, um die Infrastruktur zu verwalten, auf der Ihre Aufgaben und Services ausgeführt werden.
Wenn Sie eine neue Auto-Scaling-Gruppe erstellen möchten, wird diese automatisch für das folgende Verhalten konfiguriert:
+ Die Aktionen der Auto-Scaling-Gruppe zum Ab- oder Aufskalieren werden von Amazon ECS verwaltet.
+ Amazon ECS verhindert nicht, dass Amazon-EC2-Instances, die Aufgaben enthalten und sich in einer Auto-Scaling-Gruppe befinden, während einer Abskalierungs-Aktion beendet werden. Weitere Informationen finden Sie unter [Instance-Skalierungsschutz](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection) im *AWS Auto Scaling -Benutzerhandbuch*.
Sie konfigurieren die folgenden Eigenschaften für Auto-Scaling-Gruppen. Diese bestimmen den Typ und die Anzahl der Instances, die für die Gruppe gelauncht werden sollen:
+ Das Amazon-ECS-optimierte AMI.
+ Der Instance-Typ.
+ Das SSH-Schlüsselpaar, das Ihre Identität beweist, wenn Sie eine Verbindung mit der Instance herstellen. Weitere Informationen zum Erstellen von SSH-Schlüssel finden Sie unter [Amazon-EC2-Schlüsselpaare und Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im *Benutzerhandbuch für Amazon EC2*.
+ Die minimale Anzahl von Instances, die für die Auto-Scaling-Gruppe gelauncht werden sollen.
+ Die maximale Anzahl von Instances, die für die Auto-Scaling-Gruppe gestartet werden.
Damit die Gruppe aufskaliert werden kann, muss das Maximum größer als 0 sein.
Amazon ECS erstellt als Teil des CloudFormation -Stacks in Ihrem Namen eine Launchvorlage von Amazon EC2 Auto Scaling und eine Auto-Scaling-Gruppe. Die Werte, die Sie für das AMI, die Instance-Typen und das SSH-Schlüsselpaar angegeben haben, befinden sich in der Startvorlage. Die Vorlagen sind mit dem Präfix `EC2ContainerService-` versehen, wodurch sie leicht erkennbar sind. Die Auto-Scaling-Gruppen haben das Präfix `-ECS-Infra-ECSAutoScalingGroup`.
Instances, die für die Auto-Scaling-Gruppe geluncht wurden, verwenden die Launchvorlage.
## Netzwerkoptionen
Standardmäßig werden Instances in den Standard-Subnetzen für die Region gestartet. Es werden die Sicherheitsgruppen verwendet, die den Datenverkehr zu Ihren Container-Instances steuern, die derzeit den Subnetzen zugeordnet sind. Sie können die Subnetze und Sicherheitsgruppen für die Instances ändern.
Sie können ein vorhandenes Subnetz auswählen. Sie können entweder eine bestehende Sicherheitsgruppe auswählen oder eine neue erstellen. Verwenden Sie Subnetze, die IPv6 nur einen CIDR-Block enthalten, um Aufgaben in einer IPv6 Nur-Konfiguration zu erstellen.
Wenn Sie eine neue Sicherheitsgruppe erstellen, müssen Sie mindestens eine Regel für eingehenden Datenverkehr angeben.
Die Regeln für eingehenden Datenverkehr legen fest, welcher Datenverkehr Ihre Container-Instances erreichen kann, und beinhalten die folgenden Eigenschaften:
+ Das zulässige Protokoll
+ Der zulässige Bereich an Ports
+ Der eingehende Datenverkehr (Quelle)
Um eingehenden Verkehr von einer bestimmten Adresse oder einem bestimmten CIDR-Block zuzulassen, verwenden Sie **Benutzerdefiniert** als **Quelle** mit dem zulässigen CIDR.
Um eingehenden Datenverkehr von allen Zielen zuzulassen, verwenden Sie **Überall** als **Quelle**. Dadurch werden automatisch der CIDR-Block 0.0.0.0/0 und der IPv4 CIDR-Block: :/0 hinzugefügt. IPv6
Um eingehenden Datenverkehr von Ihrem lokalen Computer zuzulassen, verwenden Sie **Quellengruppe** als **Quelle**. Dadurch wird automatisch die aktuelle IP-Adresse Ihres lokalen Computers als zulässige Quelle hinzugefügt.
**So erstellen Sie einen neuen Cluster (Amazon ECS-Konsole)**
Bevor Sie beginnen, weisen Sie die entsprechende IAM-Berechtigung zu. Weitere Informationen finden Sie unter [Beispiele für Amazon-ECS-Cluster](security_iam_id-based-policy-examples.md#IAM_cluster_policies).
1. Öffnen [https://console.aws.amazon.com/ecs/Sie die](https://console.aws.amazon.com/ecs/v2) Konsole auf Version 2.
1. Wählen Sie die zu verwendende Region in der Navigationsleiste aus.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der Seite **Clusters** die Option **Create cluster** (Cluster erstellen) aus.
1. Konfigurieren Sie unter **Clusterkonfiguration** Folgendes:
+ Geben Sie für **Cluster-Name** einen eindeutigen Namen ein.
Der Name kann bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern und Bindestriche enthalten.
+ (Optional) Wenn der für Service Connect verwendete Namespace nicht mit dem Cluster-Namen identisch sein soll, geben Sie unter **Service-Connect-Standardeinstellungen** für **Standard-Namespace** einen eindeutigen Namen ein. Um einen gemeinsam genutzten Namespace zu verwenden, wählen Sie einen Namespace-ARN aus oder geben Sie ihn ein. Weitere Informationen zur Verwendung von geteilten Namespaces finden Sie unter [Amazon ECS Service Connect mit gemeinsam genutzten AWS Cloud Map Namespaces](service-connect-shared-namespaces.md).
1. Fügen Sie Ihrem Cluster Amazon-EC2-Instances hinzu, erweitern Sie **Infrastruktur** und wählen Sie dann **Fargate- und selbstverwaltete Instances** aus.
Konfigurieren Sie als Nächstes die Auto-Scaling-Gruppe, die als Kapazitätsanbieter fungiert:
1. Um eine vorhandene Auto-Scaling-Gruppe zu verwenden, wählen Sie die Gruppe aus der **Auto-Scaling-Gruppe (ASG)** aus.
1. Um eine Auto-Scaling-Gruppe zu erstellen, wählen Sie in der **Auto-Scaling-Gruppe (ASG)** **Create new group** (Neue Gruppe erstellen) und geben Sie dann die folgenden Details zur Gruppe an:
+ Wählen Sie für **Bereitstellungsmodell**, ob **On-Demand**-Instances oder **Spot** Instances verwendet werden sollen.
+ Wenn Sie Spot Instances verwenden möchten, wählen Sie für **Zuweisungsstrategie** aus, welche Spot-Kapazitätspools (Instance-Typen und Availability Zones) für die Instances verwendet werden.
Für die meisten Workloads können Sie **Preis und Kapazität optimiert** wählen.
Weitere Informationen finden Sie unter [Zuweisungsstrategien für Spot-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html) im *Amazon-EC2-Benutzerhandbuch*.
+ Wählen Sie für **Amazon Machine Image (AMI) der Container-Instance** das Amazon-ECS-optimierte AMI für die Instances der Auto-Scaling-Gruppe aus.
+ Wählen Sie für **EC2 instance type** (EC2-Instance-Typ) den Instance-Typ für Ihre Workloads aus.
Die verwaltete Skalierung funktioniert am besten, wenn Ihre Auto-Scaling-Gruppe dieselben oder ähnliche Instance-Typen verwendet.
+ Wählen Sie für **EC2-Instance-Rolle** eine vorhandene Container-Instance-Rolle aus, oder erstellen Sie eine neue.
Weitere Informationen finden Sie unter [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md).
+ Geben Sie für **Capacity** (Kapazität) die minimale Anzahl und die maximale Anzahl von Instances ein, die in der Auto-Scaling-Gruppe gelauncht werden sollen.
+ Wählen Sie für **SSH key pair** (SSH-Schlüsselpaar) das Paar aus, das Ihre Identität nachweist, wenn Sie eine Verbindung zur Instance herstellen.
+ Um ein größeres Image und mehr Speicherplatz zu ermöglichen, geben Sie für **Größe des Root-EBS-Volumes** den Wert in GiB ein.
1. (Optional) Um die VPC und Subnetze zu ändern, führen Sie unter **Netzwerke für Amazon-EC2-Instances** einen der folgenden Vorgänge aus:
+ Um ein Subnetz zu entfernen, wählen Sie unter **Subnets** (Subnetze) **X** für jedes Subnetz, das Sie entfernen möchten.
+ Um zu einer anderen VPC als der **Standard**-VPC zu wechseln, wählen Sie unter **VPC** eine vorhandene **VPC** und dann unter **Subnetze** die Subnetze aus. Wählen Sie für eine IPv6 Nur-Konfiguration eine VPC mit einem IPv6 CIDR-Block und Subnetzen, die nur über einen CIDR-Block verfügen. IPv6
+ Wählen Sie die Sicherheitsgruppen aus. Wählen Sie unter **Sicherheitsgruppe** eine der folgenden Optionen aus:
+ Um eine vorhandene Sicherheitsgruppe zu verwenden, wählen Sie **Vorhandene Sicherheitsgruppe verwenden** und dann die Sicherheitsgruppe.
+ Um eine Sicherheitsgruppe zu erstellen, wählen Sie **Neue Sicherheitsgruppe erstellen** aus. Wählen Sie dann **Regel hinzufügen** für jede eingehende Regel.
Informationen zu Eingangsregeln finden Sie unter [Netzwerkoptionen](#networking-options).
+ Um Ihren Amazon-EC2-Container-Instances automatisch öffentliche IP-Adressen zuzuweisen, wählen Sie für **Automatische Zuweisung öffentlicher IP-Adressen** eine der folgenden Optionen:
+ **Subnetzeinstellung verwenden** – Weisen Sie den Instances eine öffentliche IP-Adresse zu, wenn es sich bei dem Subnetz, in dem die Instances gestartet werden, um ein öffentliches Subnetz handelt.
+ **Einschalten** – Weisen Sie den Instances eine öffentliche IP-Adresse zu.
1. (Optional) Verwenden Sie Container Insights, erweitern Sie **Überwachung** und wählen Sie dann eine der folgenden Optionen:
+ Um das empfohlene Container Insights mit verbesserter Beobachtbarkeit zu verwenden, wählen Sie **Container Insights mit verbesserter Beobachtbarkeit**.
+ Um Container Insights zu verwenden, wählen Sie **Container Insights**.
1. **(Optional) Um Aufgabenereignisse zu aktivieren, erweitern Sie **Aufgabenereignisse und aktivieren Sie dann Aufgabenereignisse** aktivieren.**
Wenn Sie Aufgabenereignisse aktivieren, sendet Amazon ECS Ereignisse zur Änderung des Aufgabenstatus an EventBridge. Auf diese Weise können Sie Änderungen im Aufgabenlebenszyklus automatisch überwachen und darauf reagieren.
1. (Optional) Um ECS Exec zum Debuggen von Aufgaben im Cluster zu verwenden, erweitern Sie **Konfiguration zur Fehlerbehebung** und konfigurieren Sie dann Folgendes:
+ (Optional) Geben Sie unter **AWS KMS Schlüssel für ECS Exec** den ARN des AWS KMS Schlüssels ein, den Sie zur Verschlüsselung der ECS Exec-Sitzungsdaten verwenden möchten.
+ (Optional) Wählen Sie für die **ECS-Exec-Protokollierung** das Protokollziel aus:
+ Um Logs an CloudWatch Logs zu senden, wählen Sie **Amazon CloudWatch**.
+ Um Protokolle an Amazon S3 zu senden, wählen Sie **Amazon S3**.
+ Um die Protokollierung zu deaktivieren, wählen Sie **Keine**.
1. (Optional)
Wenn Sie Runtime Monitoring mit der manuellen Option verwenden und möchten, dass dieser Cluster von überwacht wird GuardDuty, wählen Sie **Tag hinzufügen** und gehen Sie wie folgt vor:
+ Geben Sie für **Schlüssel** **guardDutyRuntimeMonitoringManaged** ein.
+ Geben Sie für **Wert** **true** ein.
1. (Optional) Verschlüsseln Sie die Daten im verwalteten Speicher. Geben Sie unter **Verschlüsselung** für **verwalteten Speicher** den ARN des AWS KMS Schlüssels ein, den Sie zum Verschlüsseln der verwalteten Speicherdaten verwenden möchten.
1. (Optional) Um die Cluster-Tags zu verwalten, erweitern Sie **Tags** und führen Sie dann eine der folgenden Vorgänge aus:
[Markierung hinzufügen] Wählen Sie **Add tag (Markierung hinzufügen)**, und führen Sie die folgenden Schritte aus:
+ Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein.
+ Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein.
[Markierung entfernen] Wählen Sie **Remove (Entfernen)** rechts neben dem Schlüssel und dem Wert der Markierung.
1. Wählen Sie **Erstellen** aus.
## Nächste Schritte
Nachdem Sie den Cluster erstellt haben, können Sie Aufgabendefinitionen für Ihre Anwendungen erstellen und diese dann als eigenständige Aufgaben oder als Teil eines Services ausführen. Weitere Informationen finden Sie hier:
+ [Amazon-ECS-Aufgabendefinitionen](task_definitions.md)
+ [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md)
+ [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md)
# Automatische Verwaltung der Amazon-ECS-Kapazität mit Cluster-Auto-Scaling
Amazon ECS kann die Skalierung von Amazon-EC2-Instances verwalten, die in Ihrem Cluster registriert sind. Dies wird als *Auto Scaling für Amazon-ECS-Cluster* bezeichnet. Sie aktivieren die verwaltete Skalierung, wenn Sie den Kapazitätsanbieter für Amazon-ECS-Auto-Scaling-Gruppen erstellen. Dann legen Sie einen Zielprozentsatz (die `targetCapacity`) für die Instance-Auslastung in dieser Auto-Scaling-Gruppe fest. Amazon ECS erstellt zwei benutzerdefinierte CloudWatch Metriken und eine Skalierungsrichtlinie für die Zielverfolgung für Ihre Auto Scaling Scaling-Gruppe. Anschließend verwaltet Amazon ECS die Aktionen zum Auf- und Abskalieren je nach der Ressourcenauslastung, die Ihre Aufgaben verursachen.
Für jeden Kapazitätsanbieter der Auto-Scaling-Gruppe, der einem Cluster zugeordnet ist, erstellt und verwaltet Amazon ECS die folgenden Ressourcen:
+ Ein CloudWatch Alarm bei niedrigem metrischen Wert
+ Ein CloudWatch Alarm bei hohem metrischen Wert
+ Eine Skalierungsrichtlinie für die Ziel-Nachverfolgung.
**Anmerkung**
Amazon ECS erstellt die Skalierungsrichtlinie für die Ziel-Nachverfolgung und fügt sie an die Auto-Scaling-Gruppe an. Um die Skalierungsrichtlinie für die Ziel-Nachverfolgung zu aktualisieren, aktualisieren Sie die vom Kapazitätsanbieter verwalteten Skalierungseinstellungen, statt die Skalierungsrichtlinie direkt zu aktualisieren.
Wenn Sie die verwaltete Skalierung deaktivieren oder den Kapazitätsanbieter von einem Cluster trennen, entfernt Amazon ECS sowohl die CloudWatch Metriken als auch die Ressourcen der Ziel-Tracking-Skalierungsrichtlinie.
Amazon ECS verwendet die folgenden Metriken, um zu bestimmen, welche Aktionen ausgeführt werden sollen:
`CapacityProviderReservation`
Der Prozentsatz der Container-Instances, die für einen bestimmten Kapazitätsanbieter verwendet werden. Amazon ECS generiert diese Metrik.
Amazon ECS legt den Wert `CapacityProviderReservation` auf eine Zahl zwischen 0–100 fest. Amazon ECS verwendet die folgende Formel, um das Verhältnis der verbleibenden Kapazität in der Auto-Scaling-Gruppe darzustellen. Anschließend veröffentlicht Amazon ECS die Metrik für CloudWatch. Weitere Informationen darüber, wie die Metrik berechnet wird, finden Sie unter [Deep Dive zu Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)
```
CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
```
`DesiredCapacity`
Die Kapazitätsmenge für die Auto-Scaling-Gruppe. Diese Metrik wird nicht veröffentlicht für CloudWatch.
Amazon ECS veröffentlicht die `CapacityProviderReservation` Metrik CloudWatch im `AWS/ECS/ManagedScaling` Namespace. Die `CapacityProviderReservation`-Metrik führt zu einer der folgenden Aktionen:
**Der Wert `CapacityProviderReservation` entspricht `targetCapacity`**
Die Auto-Scaling-Gruppe muss weder ab- noch aufskaliert werden. Der angestrebte Nutzungsprozentsatz wurde erreicht.
**Der Wert `CapacityProviderReservation` ist größer als `targetCapacity`**
Es gibt mehr Aufgaben, die einen höheren Prozentsatz der Kapazität beanspruchen als Ihr `targetCapacity`-Prozentsatz. Der erhöhte Wert der `CapacityProviderReservation` Metrik führt dazu, dass der zugehörige CloudWatch Alarm ausgelöst wird. Dieser Alarm aktualisiert den `DesiredCapacity`-Wert für die Auto-Scaling-Gruppe. Die Auto-Scaling-Gruppe verwendet diesen Wert, um EC2-Instances zu launchen und sie dann beim Cluster anzumelden.
Wenn die `targetCapacity` der Standardwert 100 % ist, befinden sich die neuen Aufgaben im Status `PENDING` während der Skalierung, da auf den Instances keine Kapazität zur Ausführung der Aufgaben verfügbar ist. Nachdem sich die neuen Instances bei ECS registriert haben, werden diese Aufgaben auf den neuen Instances gestartet.
**Der Wert `CapacityProviderReservation` ist kleiner als `targetCapacity`**
Es gibt weniger Aufgaben, die einen niedrigeren Prozentsatz der Kapazität beanspruchen als Ihr `targetCapacity`-Prozentsatz, und es gibt mindestens eine Instance, die beendet werden kann. Der verringerte Wert der `CapacityProviderReservation` Metrik bewirkt, dass der zugehörige CloudWatch Alarm ausgelöst wird. Dieser Alarm aktualisiert den `DesiredCapacity`-Wert für die Auto-Scaling-Gruppe. Die Auto-Scaling-Gruppe verwendet diesen Wert, um EC2-Container-Instances zu beenden und sie dann vom Cluster abzumelden.
Die Auto-Scaling-Gruppe folgt der Beendigungsrichtlinie der Gruppe, um zu bestimmen, welche Instances sie bei Abskalieren-Ereignissen zuerst beendet. Außerdem werden Instances vermieden, für die der Instance-Abskalierungsschutz aktiviert ist. Cluster-Auto-Scaling kann verwalten, für welche Instances die Einstellung für den Instance-Abskalierungsschutz gilt, wenn Sie den verwalteten Beendigungsschutz aktivieren. Weitere Informationen zum verwalteten Beendigungsschutz finden Sie unter [Die Instances steuern, die Amazon ECS beendet](managed-termination-protection.md). Weitere Informationen darüber, wie Auto-Scaling-Gruppen Instances beenden, finden Sie unter [Steuern, welche Auto-Scaling-Instances während der Abskalierung beendet werden](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) im *Benutzerhandbuch für Amazon EC2 Auto Scaling*.
Bei Verwendung von Cluster-Auto-Scaling sollte Folgendes berücksichtigt werden:
+ Ändern oder verwalten Sie nicht die gewünschte Kapazität für die Auto-Scaling-Gruppe, die einem Kapazitätsanbieter zugeordnet ist, der über andere Skalierungsrichtlinien verfügt als die, die Amazon ECS verwaltet.
+ Wenn Amazon ECS ab 0 Instances aufskaliert, werden automatisch 2 Instances gestartet.
+ Amazon ECS verwendet die `AWSServiceRoleForECS` serviceverknüpfte IAM-Rolle für die Berechtigungen, die erforderlich sind, um in Ihrem Namen AWS Auto Scaling aufzurufen. Weitere Informationen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon ECS](using-service-linked-roles.md).
+ Bei der Verwendung von Kapazitätsanbietern mit Auto-Scaling-Gruppen benötigt der Benutzer, die Gruppe oder die Rolle, der bzw. die die Kapazitätsanbieter erstellt, die `autoscaling:CreateOrUpdateTags`-Berechtigung. Dies liegt daran, dass Amazon ECS an die Auto-Scaling-Gruppe ein Tag hinzufügt, wenn sie es dem Kapazitätsanbieter zuordnet.
**Wichtig**
Stellen Sie sicher, dass die von Ihnen verwendeten Tools das `AmazonECSManaged`-Tag nicht aus der Auto-Scaling-Gruppe entfernen. Wenn dieses Tag entfernt wird, kann Amazon ECS das Skalieren nicht verwalten.
+ Die auto Clusterskalierung ändert das **MinimumCapacity**oder **MaximumCapacity**für die Gruppe nicht. Damit die Gruppe horizontal skaliert werden kann, **MaximumCapacity**muss der Wert für größer als Null sein.
+ Wenn Auto Scaling (verwaltete Skalierung) aktiviert ist, kann ein Kapazitätsanbieter nur mit einem Cluster gleichzeitig verbunden sein. Wenn Ihr Kapazitätsanbieter die verwaltete Skalierung deaktiviert hat, können Sie ihn mehreren Clustern zuordnen.
+ Wenn die verwaltete Skalierung deaktiviert ist, führt der Kapazitätsanbieter keine Auf- oder Abskalierung durch. Sie können eine Kapazitätsanbieter-Strategie verwenden, um Ihre Aufgaben zwischen Kapazitätsanbietern auszugleichen.
+ Die `binpack`-Strategie ist in Bezug auf die Kapazität die effizienteste Strategie.
+ Wenn die Zielkapazität im Rahmen der Platzierungsstrategie unter 100 % liegt, muss die `binpack`-Strategie eine höhere Ordnung als die `spread`-Strategie haben. Dadurch wird verhindert, dass der Kapazitätsanbieter aufskaliert, bis jede Aufgabe über eine Dedicated Instance verfügt oder das Limit erreicht ist.
## Auto Scaling von Clustern aktivieren
Verwenden Sie die Konsole oder die AWS CLI, um das Cluster Auto Scaling zu aktivieren.
Wenn Sie mithilfe der Konsole einen Cluster erstellen, der EC2-Kapazitätsanbieter verwendet, erstellt Amazon ECS in Ihrem Namen eine Auto-Scaling-Gruppe und legt die Zielkapazität fest. Weitere Informationen finden Sie unter [Erstellen eines Amazon-ECS-Clusters für Amazon-EC2-Workloads](create-ec2-cluster-console-v2.md).
Sie können auch eine Auto-Scaling-Gruppe erstellen und sie dann einem Cluster zuweisen. Weitere Informationen finden Sie unter [Aktualisieren eines Amazon-ECS-Kapazitätsanbieters](update-capacity-provider-console-v2.md).
Wenn Sie den verwenden AWS CLI, nachdem Sie den Cluster erstellt haben
1. Vor dem Erstellen des Kapazitätsanbieters müssen Sie eine Auto-Scaling-Gruppe erstellen. Weitere Informationen zu [Auto-Scaling-Gruppen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) finden Sie im *Benutzerhandbuch für Amazon EC2 Auto Scaling*.
1. Verwenden Sie `put-cluster-capacity-providers`, um den Cluster-Kapazitätsanbieter zu ändern. Weitere Informationen finden Sie unter [Amazon ECS Cluster Auto Scaling aktivieren](turn-on-cluster-auto-scaling.md).
# Optimieren Sie die auto Skalierung von Amazon ECS-Clustern
Kunden, die Amazon ECS in Amazon EC2 ausführen, können die Vorteile von Cluster Auto Scaling nutzen, um die Skalierung von Amazon-EC2-Auto-Scaling-Gruppen zu verwalten. Mit Cluster Auto Scaling können Sie Amazon ECS so konfigurieren, dass Ihre Auto-Scaling-Gruppe automatisch skaliert wird, sodass Sie sich ganz auf die Ausführung Ihrer Aufgaben konzentrieren können. Amazon ECS stellt sicher, dass die Auto-Scaling-Gruppe nach Bedarf auf- und abskaliert wird, ohne dass weitere Eingriffe erforderlich sind. Amazon-ECS-Kapazitätsanbieter werden verwendet, um die Infrastruktur in Ihrem Cluster zu verwalten, indem sichergestellt wird, dass genügend Container-Instances vorhanden sind, um die Anforderungen Ihrer Anwendung zu erfüllen. Informationen darüber, wie Cluster Auto Scaling unter der Haube funktioniert, finden Sie unter [Deep Dive zu Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).
Cluster-Auto Scaling basiert auf einer CloudWatch basierten Integration mit der Auto Scaling-Gruppe zur Anpassung der Clusterkapazität. Daher ist eine inhärente Latenz verbunden mit
+ Veröffentlichung der CloudWatch Metriken,
+ Die Zeit, die die Metrik benötigt hat`CapacityProviderReservation`, um CloudWatch Alarme zu umgehen (sowohl bei hohen als auch bei niedrigen Alarmen)
+ Die Zeit, die eine neu gestartete Amazon-EC2-Instance zum Aufwärmen benötigt. Sie können folgende Aktionen durchführen, um Cluster Auto Scaling für schnellere Bereitstellungen reaktionsschneller zu gestalten:
## Größen der schrittweisen Skalierung von Kapazitätsanbietern
Amazon ECS-Kapazitätsanbieter stellen grow/shrink die Container-Instances so her, dass sie die Anforderungen Ihrer Anwendung erfüllen. Die Mindestanzahl von Instances, die Amazon ECS startet, ist standardmäßig auf 1 festgelegt. Dies kann Ihre Bereitstellungen verlängern, wenn mehrere Instances für die Ausführung Ihrer ausstehenden Aufgaben erforderlich sind. Sie können die [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) über die Amazon-ECS-API erhöhen, um die Mindestanzahl von Instances zu erhöhen, die Amazon ECS gleichzeitig auf- oder abskaliert. Wenn [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) zu niedrig ist, kann dies einschränken, wie viele Container-Instances gleichzeitig auf- oder abskaliert werden, was Ihre Bereitstellungen verlangsamen kann.
**Anmerkung**
Diese Konfiguration ist derzeit nur über die Option [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)oder verfügbar [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs.
## Instance-Aufwärmphase
Die Instance-Aufwärmphase ist der Zeitraum, nach dem eine neu gestartete Amazon EC2 EC2-Instance zu den CloudWatch Metriken für die Auto Scaling Scaling-Gruppe beitragen kann. Nach Ablauf der angegebenen Aufwärmphase wird die Instance auf die aggregierten Metriken der Auto-Scaling-Gruppe angerechnet, und Cluster Auto Scaling fährt mit der nächsten Berechnungsiteration fort, um die Anzahl der benötigten Instances zu schätzen.
Der Standardwert für [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod)ist 300 Sekunden, den Sie [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) APIs für eine reaktionsschnellere Skalierung auf einen niedrigeren Wert über [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html)oder konfigurieren können. Es empfiehlt sich, den Wert auf mehr als 60 Sekunden festzulegen, um eine Überbereitstellung zu vermeiden.
## Freie Kapazität
Wenn Ihr Kapazitätsanbieter keine Container-Instances für die Aufgabenplatzierung zur Verfügung hat, muss er die Cluster-Kapazität erhöhen (aufskalieren), indem er Amazon-EC2-Instances im laufenden Betrieb startet und wartet, bis sie hochgefahren sind, bevor er Container auf ihnen starten kann. Dies kann die Startrate von Aufgaben erheblich senken. Sie haben hier zwei Optionen.
In diesem Fall erhöht sich die effektive Startrate von Aufgaben, wenn Amazon-EC2-Kapazitäten bereits gestartet und bereit sind, Aufgaben auszuführen. Sie können die `Target Capacity`-Konfiguration verwenden, um anzugeben, dass Sie freie Kapazitäten in Ihren Clustern beibehalten möchten. Wenn Sie beispielsweise für `Target Capacity` einen Wert von 80 % festlegen, geben Sie an, dass Ihr Cluster jederzeit 20 % freie Kapazität benötigt. Dank dieser freien Kapazität können alle eigenständigen Aufgaben sofort gestartet werden, wodurch sichergestellt wird, dass das Starten von Aufgaben nicht gedrosselt wird. Der Nachteil dieses Ansatzes sind potenziell höhere Kosten für die Beibehaltung von freier Cluster-Kapazität.
Ein alternativer Ansatz, den Sie in Betracht ziehen können, besteht darin, Ihrem Service mehr Spielraum zu verleihen, nicht dem Kapazitätsanbieter. Das bedeutet, dass Sie, anstatt die `Target Capacity`-Konfiguration zu reduzieren, um freie Kapazitäten bereitzustellen, die Anzahl der Replikate in Ihrem Service erhöhen können, indem Sie die Skalierungsmetrik der Ziel-Nachverfolgung oder die Schwellenwerte für die schrittweise Skalierung des Service-Auto-Scaling ändern. Beachten Sie, dass dieser Ansatz nur bei stark beanspruchten Workloads hilfreich ist, aber keine Auswirkungen hat, wenn Sie neue Services bereitstellen und zum ersten Mal von 0 auf N Aufgaben wechseln. Weitere Informationen zu den zugehörigen Skalierungsrichtlinien finden Sie unter [Skalierungsrichtlinien der Ziel-Nachverfolgung](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) oder [schrittweise Skalierungsrichtlinien](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html) im *Entwicklerhandbuch für Amazon Elastic Container Service*.
# Von Amazon ECS verwaltetes Skalierungsverhalten
Wenn Sie Kapazitätsanbieter für Auto-Scaling-Gruppen haben, die verwaltete Skalierung verwenden, schätzt Amazon ECS die optimale Anzahl von Instances, die Ihrem Cluster hinzugefügt werden sollen, und verwendet diesen Wert, um zu bestimmen, wie viele Instances angefordert oder veröffentlicht werden müssen.
## Verhalten für die verwaltete Skalierung nach oben
Amazon ECS wählt einen Kapazitätsanbieter für jede Aufgabe aus, indem es der Kapazitätsanbieter-Strategie des Service, der eigenständigen Aufgabe oder der Cluster-Standardeinstellung folgt. Amazon ECS folgt den restlichen Schritten für einen einzelnen Kapazitätsanbieter.
Aufgaben ohne Kapazitätsanbieter-Strategie werden von Kapazitätsanbietern ignoriert. Eine ausstehende Aufgabe, für die es keine Kapazitätsanbieter-Strategie gibt, führt bei keinem Kapazitätsanbieter zum Aufskalieren. Aufgaben oder Services können keine Strategie für einen Kapazitätsanbieter festlegen, wenn diese Aufgabe oder dieser Service einen Starttyp festlegt.
Im Folgenden wird das Scale-Out-Verhalten detaillierter beschrieben.
+ Gruppieren Sie alle Bereitstellungsaufgaben für diesen Kapazitätsanbieter so, dass jede Gruppe genau die gleichen Ressourcenanforderungen hat.
+ Wenn Sie mehrere Instance-Typen in einer Auto-Scaling-Gruppe verwenden, werden die Instance-Typen in der Auto-Scaling-Gruppe nach ihren Parametern sortiert. Zu diesen Parametern gehören vCPU, Speicher, elastische Netzwerkschnittstellen (ENIs), Ports und GPUs. Die kleinsten und größten Instance-Typen für jeden Parameter werden ausgewählt. Weitere Informationen zur Auswahl eines Instance-Typs finden Sie unter [Amazon-EC2-Container-Instances für Amazon ECS](create-capacity.md).
**Wichtig**
Wenn eine Gruppe von Aufgaben einen Ressourcenbedarf hat, der größer ist als der kleinste Instance-Typ in der Auto-Scaling-Gruppe, dann kann diese Gruppe von Aufgaben nicht mit diesem Kapazitätsanbieter ausgeführt werden. Der Kapazitätsanbieter skaliert die Auto-Scaling-Gruppe nicht. Die Aufgaben verbleiben im Status `PROVISIONING`.
Um zu verhindern, dass Aufgaben im Status `PROVISIONING` verbleiben, empfehlen wir Ihnen, separate Auto-Scaling-Gruppen und Kapazitätsanbieter für unterschiedliche Mindestressourcenanforderungen zu erstellen. Wenn Sie Aufgaben ausführen oder Services erstellen, fügen Sie nur Kapazitätsanbieter zur Kapazitätsanbieter-Strategie hinzu, die die Aufgabe auf dem kleinsten Instance-Typ in der Auto-Scaling-Gruppe ausführen können. Für andere Parameter können Sie Platzierungsbeschränkungen verwenden
+ Für jede Aufgabengruppe berechnet Amazon ECS die Anzahl der Instances, die zum Ausführen der nicht platzierten Aufgaben erforderlich sind. Diese Berechnung verwendet eine `binpack`-Strategie. Diese Strategie berücksichtigt die Anforderungen der Aufgaben an vCPU, Arbeitsspeicher, Elastic-Network-Schnittstellen (ENI), Ports und GPUs. Es berücksichtigt auch die Ressourcenverfügbarkeit der Amazon-EC2-Instances. Die Werte für die größten Instance-Typen werden als maximale berechnete Instance-Anzahl behandelt. Die Werte für den kleinsten Instance-Typ werden als Schutz verwendet. Wenn der kleinste Instance-Typ nicht mindestens eine Instance der Aufgabe ausführen kann, betrachtet die Berechnung die Aufgabe als nicht kompatibel. Daher wird die Aufgabe von der Aufskalierungsberechnung ausgeschlossen. Wenn alle Aufgaben nicht mit dem kleinsten Instance-Typ kompatibel sind, stoppt das Auto Scaling des Clusters und der Wert `CapacityProviderReservation` bleibt auf dem Wert `targetCapacity`.
+ Amazon ECS veröffentlicht die `CapacityProviderReservation` Metrik in CloudWatch Bezug darauf, `minimumScalingStepSize` ob einer der folgenden Punkte zutrifft.
+ Die maximale berechnete Instance-Anzahl ist geringer als die minimale Skalierungsschrittgröße.
+ Der niedrigere Wert von entweder `maximumScalingStepSize` oder der maximal berechneten Instance-Anzahl.
+ CloudWatch Alarme verwenden die `CapacityProviderReservation` Metrik für Kapazitätsanbieter. Wenn die `CapacityProviderReservation`-Metrik größer als der `targetCapacity`-Wert ist, erhöhen Alarme auch die `DesiredCapacity` der Auto-Scaling-Gruppe. Der `targetCapacity` Wert ist eine Einstellung des Kapazitätsanbieters, die während der Aktivierungsphase für die auto Skalierung des Clusters an den CloudWatch Alarm gesendet wird.
Der Standardwert für `targetCapacity` ist 100 %.
+ Die Auto-Scaling-Gruppe launcht zusätzliche EC2-Instances. Um eine übermäßige Bereitstellung zu verhindern, stellt Auto Scaling sicher, dass die kürzlich gestartete EC2-Instance-Kapazität stabilisiert wird, bevor neue Instances gestartet werden. Auto Scaling prüft, ob alle vorhandenen Instances die `instanceWarmupPeriod` (jetzt abzüglich der Startzeit der Instance) überschritten haben. Die Aufskalierung ist für Instances, die sich innerhalb der `instanceWarmupPeriod` befinden, gesperrt.
Die Standardanzahl von Sekunden für das Aufwärmen einer neu gelaunchten Instance beträgt 300.
Weitere Informationen finden Sie unter [Detaillierte Informationen zum Auto Scaling von Amazon-ECS-Clustern](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).
### Überlegungen zum Aufskalieren
Berücksichtigen Sie Folgendes für den Aufskalierungs-Prozess:
+ Obwohl es mehrere Platzierungs-Einschränkungen gibt, empfehlen wir, dass Sie nur die `distinctInstance`-Einschränkung für die Aufgabenplatzierung nutzen. Dies verhindert, dass der Aufskalierungs-Prozess angehalten wird, da Sie eine Platzierungs-Einschränkung verwenden, die nicht mit den Stichproben-Instances kompatibel ist.
+ Die verwaltete Skalierung funktioniert am besten, wenn Ihre Auto-Scaling-Gruppe dieselben oder ähnliche Instance-Typen verwendet.
+ Wenn ein Aufskalierungsprozess erforderlich ist und derzeit keine Container-Instances laufen, skaliert Amazon ECS zunächst immer auf zwei Instances und führt dann weitere Aufskalierungs- oder Abskalierungsprozesse durch. Bei jedem weiteren Aufskalieren wird auf die Aufwärmphase der Instance gewartet. Bei Aufskalierungsprozessen wartet Amazon ECS nach einem Aufskalierungsprozess immer 15 Minuten, bevor Abskalierungsprozesse gestartet werden.
+ Der zweite Aufskalierungs-Schritt muss warten, bis das `instanceWarmupPeriod` abläuft, was sich auf die Gesamtskalierungsgrenze auswirken kann. Wenn Sie diese Zeit verkürzen müssen, stellen Sie sicher, dass die `instanceWarmupPeriod` für den Start der EC2-Instance und den Start des Amazon-ECS-Agenten ausreicht (was eine Überbereitstellung verhindert).
+ Cluster-Auto-Scaling unterstützt Startkonfiguration, Startvorlagen und mehrere Instance-Typen in der Auto-Scaling-Gruppe des Kapazitätsanbieters. Sie können auch die attributbasierte Instance-Typauswahl ohne mehrfache Instance-Typen verwenden.
+ Wenn Sie eine Auto-Scaling-Gruppe mit On-Demand-Instances und mehreren Instance-Typen oder Spot-Instances verwenden, platzieren Sie die größeren Instance-Typen höher in der Prioritätsliste und geben Sie keine Gewichtung an. Die Angabe einer Gewichtung wird derzeit nicht unterstützt. Weitere Informationen finden Sie unter [Auto-Scaling-Gruppen mit mehreren Instance-Typen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) im *AWS Auto Scaling -Benutzerhandbuch*.
+ Amazon ECS startet dann entweder `minimumScalingStepSize`, wenn die maximal berechnete Instance-Anzahl kleiner als die minimale Skalierungsschrittgröße ist, oder den niedrigeren Wert von `maximumScalingStepSize` oder der maximal berechneten Instance-Anzahl.
+ Wenn ein Amazon-ECS-Service oder `run-task` eine Aufgabe startet und die Container-Instances des Kapazitätsanbieters nicht über genügend Ressourcen verfügen, um die Aufgabe zu starten, dann begrenzt Amazon ECS die Anzahl der Aufgaben mit diesem Status für jeden Cluster und verhindert, dass Aufgaben dieses Limit überschreiten. Weitere Informationen finden Sie unter [Amazon-ECS-Service-Kontingente](service-quotas.md).
## Verwaltetes Abskalierungs-Verhalten
Amazon ECS überwacht Container-Instances für jeden Kapazitätsanbieter in einem Cluster. Wenn eine Container-Instance keine Aufgaben ausführt, gilt die Container-Instance als leer und Amazon ECS startet den Abskalierungsprozess.
CloudWatch Scale-In-Alarme benötigen 15 Datenpunkte (15 Minuten), bevor der Scale-In-Prozess für die Auto Scaling Scaling-Gruppe beginnt. Nachdem der Abskalierungs-Prozess gestartet wurde, bis Amazon ECS die Anzahl der angemeldeten Container-Instances reduzieren muss, legt die Auto-Scaling-Gruppe fest, dass der `DesireCapacity`-Wert größer als eine Instance und weniger als 50 % pro Minute sein soll.
Wenn Amazon ECS eine Aufskalierung anfordert (wenn `CapacityProviderReservation` größer als 100 ist), während ein Abskalierungs-Prozess durchgeführt wird, wird der Abskalierungs-Prozess angehalten und bei Bedarf von Neuem gestartet.
Im Folgenden wird das Abskalierungsverhalten im Detail beschrieben:
1. Amazon ECS berechnet die Anzahl der leeren Container-Instances. Eine Container-Instance gilt als leer, auch wenn keine Daemon-Aufgaben ausgeführt werden.
1. Amazon ECS setzt den Wert `CapacityProviderReservation` auf eine Zahl zwischen 0–100, die anhand der folgenden Formel das Verhältnis zwischen der erforderlichen Größe der Auto-Scaling-Gruppe und der tatsächlichen Größe darstellt, ausgedrückt in Prozent. Anschließend veröffentlicht Amazon ECS die Metrik für CloudWatch. Weitere Informationen darüber, wie die Metrik berechnet wird, finden Sie unter [Deep Dive im Cluster-Auto-Scaling von Amazon-ECS](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/)
```
CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
```
1. Die `CapacityProviderReservation` Metrik generiert einen CloudWatch Alarm. Dieser Alarm aktualisiert den `DesiredCapacity`-Wert für die Auto-Scaling-Gruppe. Anschließend wird eine der folgenden Aktionen ausgeführt:
+ Wenn Sie keine vom Kapazitätsanbieter verwaltete Beendigung verwenden, wählt die Auto-Scaling-Gruppe EC2-Instances mithilfe der Auto-Scaling-Gruppen-Beendigungsrichtlinie aus und beendet die Instances, bis die Anzahl der EC2-Instances die `DesiredCapacity` erreicht. Die Container-Instances werden dann vom Cluster abgemeldet.
+ Wenn alle Container-Instances einen verwalteten Beendigungsschutz verwenden, entfernt Amazon ECS den Abskalierungsschutz für leere Container-Instances. Die Auto-Scaling-Gruppe kann dann die EC2-Instances beenden. Die Container-Instances werden dann vom Cluster abgemeldet.
# Die Instances steuern, die Amazon ECS beendet
**Wichtig**
Sie müssen den *Abskalierungsschutz für Instances* von Auto Scaling in der Auto-Scaling-Gruppe aktivieren, um das Feature des verwalteten Beendigungsschutzes der automatischen Cluster-Skalierung zu nutzen.
Mit dem verwalteten Beendigungsschutz kann das Cluster-Auto-Scaling steuern, welche Instances beendet werden. Wenn Sie den verwalteten Beendigungsschutz verwenden, beendet Amazon ECS nur EC2-Instances, auf denen keine Amazon-ECS-Aufgaben ausgeführt werden. Aufgaben, die von einem Service ausgeführt werden, der die `DAEMON`-Planungsstrategie verwendet, werden ignoriert und eine Instance kann durch das Auto Scaling des Clusters beendet werden, auch wenn die Instance diese Aufgaben ausführt. Das liegt daran, dass alle Instances im Cluster diese Aufgaben ausführen.
Amazon ECS aktiviert zunächst die Option zum *Instance-Abskalierungsschutz* für die EC2-Instances in der Auto- Scaling-Gruppe. Anschließend platziert Amazon ECS die Aufgaben auf den Instances. Wenn alle Nicht-Daemon-Aufgaben auf einer Instance angehalten werden, initiiert Amazon ECS den Abskalierungs-Prozess und deaktiviert den Abskalierungs-Schutz für die EC2-Instance. Die Auto-Scaling-Gruppe kann dann die Instance beenden.
Der Auto-Scaling-*Instance-Abskalierungsschutz* steuert, welche EC2-Instances von Auto Scaling beendet werden können. Instances mit aktiviertem Abskalierungs-Feature können während des Abskalierungs-Prozess nicht beendet werden. Weitere Informationen über den Abskalierungsschutz von Auto-Scaling-Instances finden Sie unter [Verwenden des Abskalierungsschutzes von Instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) im *Benutzerhandbuch zu Amazon EC2 Auto Scaling*.
Sie können den `targetCapacity`-Prozentsatz so festlegen, dass Sie über freie Kapazitäten verfügen. Auf diese Weise können zukünftige Aufgaben schneller gestartet werden, da die Auto-Scaling-Gruppe keine weitere Instances starten muss. Amazon ECS verwendet den Zielkapazitätswert, um die CloudWatch Metrik zu verwalten, die der Service erstellt. Amazon ECS verwaltet die CloudWatch Metrik. Die Auto-Scaling-Gruppe wird als stabiler Status behandelt, sodass keine Skalierungsaktion erforderlich ist. Die Werte können zwischen 0 und 100 % liegen. Um Amazon ECS beispielsweise so zu konfigurieren, dass 10 % freie Kapazität zusätzlich zu der von Amazon-ECS-Aufgaben verwendeten Kapazität beibehalten werden, legen Sie den Zielkapazitätswert auf 90 % fest. Berücksichtigen Sie Folgendes, wenn Sie den `targetCapacity`-Wert für einen Kapazitätsanbieter festlegen.
+ Ein `targetCapacity`-Wert von weniger als 100 % entspricht der Höhe der freien Kapazität (Amazon-EC2-Instaces), die im Cluster vorhanden sein muss. Freie Kapazität bedeutet, dass es keine laufenden Aufgaben gibt.
+ Platzierungseinschränkungen wie Availability Zones ohne zusätzliches `binpack` zwingen Amazon ECS dazu, eine Aufgabe für jede Instance auszuführen, was möglicherweise nicht das gewünschte Verhalten ist.
Sie müssen den Auto-Scaling-Instance-Abskalierungsschutz in der Auto-Scaling-Gruppe aktivieren, um den verwalteten Beendigungsschutz zu nutzen. Wenn Sie den Abskalierungsschutz nicht aktivieren, kann die Aktivierung des verwalteten Beendigungsschutzes zu unerwünschtem Verhalten führen. Möglicherweise haben Sie z. B. Instances, die im Ausgleichsstatus feststecken. Weitere Informationen finden Sie unter [Instance-Skalierungsschutz verwenden](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) im *Benutzerhandbuch zum Amazon EC2 Auto Scaling*.
Wenn Sie den Beendigungsschutz mit einem Kapazitätsanbieter verwenden, führen Sie keine manuellen Aktionen, wie z. B. das Trennen der Instance, an der Auto-Scaling-Gruppe durch, die dem Kapazitätsanbieter zugeordnet ist. Manuelle Aktionen können den Abskalierungs-Vorgang des Kapazitätsanbieters unterbrechen. Wenn Sie eine Instance von der Auto-Scaling-Gruppe trennen, müssen Sie [die getrennte Instance auch aus dem Amazon-ECS-Cluster abmelden](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deregister_container_instance.html).
# Aktualisierung des verwalteten Beendigungsschutzes für Amazon-ECS-Kapazitätsanbieter
Wenn Sie den verwalteten Beendigungsschutz verwenden, müssen Sie die Einstellungen für die vorhandenen Kapazitätsanbieter aktualisieren.
## Konsole
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie auf der Cluster-Seite die Registerkarte **Infrastruktur**.
1. Wählen Sie den Kapazitätsanbieter.
1. Wählen Sie **Aktualisieren**, um die Einstellungen des Kapazitätsanbieters zu ändern.
1. Schalten Sie unter **Einstellungen für Auto-Scaling-Gruppen** die Option **Verwalteter Beendigungsschutz** ein, um das Feature zu aktivieren oder zu deaktivieren.
1. Wählen Sie **Aktualisieren** aus.
## AWS CLI
Sie können die Einstellung für den verwalteten Beendigungsschutz eines Kapazitätsanbieters mit dem `update-capacity-provider`-Befehl aktualisieren:
So aktivieren Sie den verwalteten Beendigungsschutz:
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=ENABLED"
```
So deaktivieren Sie den verwalteten Beendigungsschutz:
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=DISABLED"
```
**Anmerkung**
Es kann einige Minuten dauern, bis die Änderungen in Ihrem gesamten Cluster wirksam werden. Wenn Sie den verwalteten Beendigungsschutz aktivieren, werden Instances, auf denen bereits Aufgaben ausgeführt werden, vor Abskalierungsereignissen geschützt. Wenn der verwaltete Beendigungsschutz deaktiviert wird, wird das Schutz-Flag während des nächsten Verwaltungszyklus des ECS-Kapazitätsanbieters von den Instances entfernt.
## Konsole für ausgeführte Aufgaben
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie auf der Cluster-Seite die Registerkarte **Aufgaben**.
1. Wählen Sie die Aufgabe
1. Schalten Sie unter **Konfiguration** die Option **Verwalteter Beendigungsschutz** ein, um das Feature zu aktivieren oder zu deaktivieren.
1. Wählen Sie **Task Scale-in Protection konfigurieren**.
Das Dialogfeld **Task Scale-in Protection konfigurieren** wird angezeigt.
1. Aktivieren Sie unter **Task Scale-in Protection** die Option **Einschalten**.
1. Geben Sie für **Ablauf in Minuten** die Anzahl an Minuten vor Ablauf von Task Scale-in Protection an.
1. Wählen Sie **Update (Aktualisieren)** aus.
# Amazon ECS Cluster Auto Scaling aktivieren
Sie können Cluster Auto Scaling aktivieren, damit Amazon ECS die Skalierung von Amazon-EC2-Instances verwalten kann, die in Ihrem Cluster registriert sind.
Wenn Sie die Konsole verwenden möchten, um die Cluster Auto Scaling zu aktivieren, finden Sie weitere Informationen unter [Erstellen eines Kapazitätsanbieters für Amazon ECS](create-capacity-provider-console-v2.md).
Erstellen Sie vor Beginn eine Auto-Scaling-Gruppe und einen Kapazitätsanbieter. Weitere Informationen finden Sie unter [Amazon-ECS-Kapazitätsanbieter für EC2-Workloads](asg-capacity-providers.md).
Um Cluster Auto Scaling zu aktivieren, ordnen Sie den Kapazitätsanbieter dem Cluster zu. Anschließend aktivieren Sie Cluster Auto Scaling.
1. Führen Sie den Befehl `put-cluster-capacity-providers` aus, um dem Cluster einen oder mehrere Kapazitätsanbieter zuzuordnen.
Um die AWS Fargate Kapazitätsanbieter hinzuzufügen, schließen Sie die `FARGATE` und die `FARGATE_SPOT` Kapazitätsanbieter in die Anfrage ein. Weitere Informationen finden Sie unter `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` in der Referenz zum *AWS CLI -Befehl*.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers CapacityProviderName FARGATE FARGATE_SPOT \
--default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
```
Um eine Auto-Scaling-Gruppe für EC2 hinzuzufügen, fügen Sie den Namen der Auto-Scaling-Gruppe in die Anfrage ein. Weitere Informationen finden Sie unter `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` in der Referenz zum *AWS CLI -Befehl*.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers CapacityProviderName \
--default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
```
1. Führen Sie den Befehl `describe-clusters` aus, um zu überprüfen, ob die Zuordnung erfolgreich war. Weitere Informationen finden Sie unter `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` in der Referenz zum *AWS CLI -Befehl*.
```
aws ecs describe-clusters \
--cluster ClusterName \
--include ATTACHMENTS
```
1. Führen Sie den Befehl `update-capacity-provider` aus, um das verwaltete Auto Scaling für den Kapazitätsanbieter zu aktivieren. Weitere Informationen finden Sie unter `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` in der Referenz zum *AWS CLI -Befehl*.
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=ENABLED}"
```
# Amazon ECS Cluster Auto Scaling deaktivieren
Sie deaktivieren Cluster Auto Scaling, wenn Sie eine detailliertere Steuerung der EC2-Instances benötigen, die in Ihrem Cluster registriert sind.
Um das Cluster Auto Scaling für einen Cluster zu deaktivieren, können Sie entweder den Kapazitätsanbieter mit aktivierter verwalteter Skalierung vom Cluster trennen oder den Kapazitätsanbieter aktualisieren, um die verwaltete Skalierung zu deaktivieren.
## Den Kapazitätsanbieter trennen
Führen Sie die folgenden Schritte aus, um den Kapazitätsanbieter von einem Cluster zu trennen.
1. Verwenden Sie den Befehl `put-cluster-capacity-providers`, um den Kapazitätsanbieter für Auto-Scaling-Gruppen vom Cluster zu trennen. Der Cluster kann die Verbindung zu den AWS Fargate Kapazitätsanbietern beibehalten. Weitere Informationen finden Sie unter `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` in der Referenz zum *AWS CLI -Befehl*.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers FARGATE FARGATE_SPOT \
--default-capacity-provider-strategy '[]'
```
Verwenden Sie den Befehl `put-cluster-capacity-providers`, um den Kapazitätsanbieter für Auto-Scaling-Gruppen vom Cluster zu trennen. Weitere Informationen finden Sie unter `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` in der Referenz zum *AWS CLI -Befehl*.
```
aws ecs put-cluster-capacity-providers \
--cluster ClusterName \
--capacity-providers [] \
--default-capacity-provider-strategy '[]'
```
1. Führen Sie den Befehl `describe-clusters` aus, um zu überprüfen, ob die Trennung erfolgreich war. Weitere Informationen finden Sie unter `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` in der Referenz zum *AWS CLI -Befehl*.
```
aws ecs describe-clusters \
--cluster ClusterName \
--include ATTACHMENTS
```
## Deaktivieren Sie die verwaltete Skalierung für den Kapazitätsanbieter
Führen Sie die folgenden Schritte aus, um die verwaltete Skalierung für den Kapazitätsanbieter zu deaktivieren.
+ Führen Sie den Befehl `update-capacity-provider` aus, um das verwaltete Auto Scaling für den Kapazitätsanbieter zu deaktivieren. Weitere Informationen finden Sie unter `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` in der Referenz zum *AWS CLI -Befehl*.
```
aws ecs update-capacity-provider \
--name CapacityProviderName \
--auto-scaling-group-provider "managedScaling={status=DISABLED}"
```
# Erstellen eines Kapazitätsanbieters für Amazon ECS
Nach Abschluss der Cluster-Erstellung können Sie einen neuen Kapazitätsanbieter (Auto-Scaling-Gruppe) für EC2 erstellen. Kapazitätsanbieter helfen Ihnen bei der Verwaltung und Skalierung der Infrastruktur für Ihre Anwendungen.
Vor dem Erstellen des Kapazitätsanbieters müssen Sie eine Auto-Scaling-Gruppe erstellen. Weitere Informationen zu [Auto-Scaling-Gruppen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) finden Sie im *Benutzerhandbuch für Amazon EC2 Auto Scaling*.
**So erstellen Sie einen Kapazitätsanbieter für den Cluster (Amazon-ECS-Konsole)**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie auf der *name* Seite **Cluster:** die Option **Infrastruktur** und dann **Create** aus.
1. Konfigurieren Sie auf der Seite **Create capacity providers** (Kapazitätsanbieter erstellen) die folgenden Optionen.
1. Geben Sie unter **Basic details** (Allgemeine Details) für **Capacity provider name** (Name des Kapazitätsanbieters), einen eindeutigen Namen des Kapazitätsanbieters ein.
1. Wählen Sie unter **Auto Scaling group** (Auto-Scaling-Gruppe) für **Use an existing Auto Scaling group** (Vorhandene Auto-Scaling-Gruppe verwenden) die Auto-Scaling-Gruppe aus.
1. (Optional) Um eine Skalierungsrichtlinie zu konfigurieren, konfigurieren Sie unter **Scaling policies** (Skalierungsrichtlinien) die folgenden Optionen.
+ Damit Amazon ECS die Ab- und Aufskalierungsaktionen verwaltet, wählen Sie **Turn on managed scaling** (Verwaltete Skalierung aktivieren) aus.
+ Um zu verhindern, dass eine EC2-Instance mit ausgeführten Amazon-ECS-Aufgaben beendet wird, wählen Sie **Turn on scaling protection** (Skalierungsschutz aktivieren) aus.
+ Geben Sie **unter Zielkapazität festlegen** den Zielwert für die CloudWatch Metrik ein, die in der von Amazon ECS verwalteten Skalierungsrichtlinie für die Zielverfolgung verwendet wird.
1. Wählen Sie **Erstellen** aus.
# Aktualisieren eines Amazon-ECS-Kapazitätsanbieters
Wenn Sie eine Auto-Scaling-Gruppe als Kapazitätsanbieter verwenden, können Sie die Skalierungsrichtlinie der Gruppe ändern.
**So aktualisieren Sie einen Kapazitätsanbieter für den Cluster (Amazon-ECS-Konsole)**
1. [Öffnen Sie die Konsole auf Version 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie auf der *name* Seite **Cluster:** die Option **Infrastruktur** und dann **Update** aus.
1. Konfigurieren Sie auf der Seite **Create capacity providers** (Kapazitätsanbieter erstellen) die folgenden Optionen.
1. Konfigurieren Sie in der **Auto-Scaling-Gruppe** unter **Scaling-Richtlinien** die folgenden Optionen.
+ Damit Amazon ECS die Ab- und Aufskalierungsaktionen verwaltet, wählen Sie **Turn on managed scaling** (Verwaltete Skalierung aktivieren) aus.
+ Um zu verhindern, dass EC2-Instances mit ausgeführten Amazon-ECS-Aufgaben beendet werden, wählen Sie **Skalierungsschutz aktivieren** aus.
+ Geben Sie **unter Zielkapazität festlegen** den Zielwert für die CloudWatch Metrik ein, die in der von Amazon ECS verwalteten Skalierungsrichtlinie für die Zielverfolgung verwendet wird.
1. Wählen Sie **Aktualisieren** aus.
# Löschen eines Amazon–ECS-Kapazitätsanbieters
Wenn Sie mit einem Auto-Scaling-Gruppenkapazitätsanbieter fertig sind, können Sie ihn löschen. Nachdem die Gruppe gelöscht wurde, wechselt der Kapazitätsanbieter der Auto-Scaling-Gruppe in den `INACTIVE`-Status. Kapazitätsanbieter mit dem Status `INACTIVE` können für einen bestimmten Zeitraum im Konto erkennbar bleiben. Dieses Verhalten kann sich jedoch in Zukunft ändern und Sie sollten sich nicht darauf verlassen, dass `INACTIVE`-Kapazitätsanbieter bestehen bleiben. Bevor der Kapazitätsanbieter der Auto-Scaling-Gruppe gelöscht wird, muss der Kapazitätsanbieter aus der Kapazitätsanbieter-Strategie aller Services entfernt werden. Sie können die `UpdateService`-API oder den Update-Service-Workflow in der Amazon-ECS-Konsole verwenden, um einen Kapazitätsanbieter aus der Kapazitätsanbieter-Strategie eines Service zu entfernen. Verwenden Sie die Option **Neue Bereitstellung erzwingen**, um sicherzustellen, dass alle Aufgaben, die die vom Kapazitätsanbieter bereitgestellte Kapazität der Amazon-EC2-Instance verwenden, auf die Kapazität der übrigen Kapazitätsanbieter umgestellt werden.
**So löschen Sie einen Kapazitätsanbieter für den Cluster (Amazon-ECS-Konsole)**
1. [Öffnen Sie die Konsole auf Version 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie auf der *name* Seite **Cluster:** **Infrastruktur**, die Auto Scaling Scaling-Gruppe und dann **Löschen** aus.
1. Geben Sie im Bestätigungsfeld **Löschen** ein *Auto Scaling group name*
1. Wählen Sie **Löschen** aus.
# Amazon-ECS-Workloads, die auf EC2-Instances ausgeführt werden, sicher anhalten
Managed Instance Draining ermöglicht die ordnungsgemäße Beeindigung von Amazon-EC2-Instances. Auf diese Weise können Ihre Workloads sicher angehalten und auf Instances ohne Beendigung verschoben werden. Wartung und Aktualisierung der Infrastruktur werden durchgeführt, ohne dass Sie sich Gedanken über Unterbrechungen der Workloads machen müssen. Durch die Verwendung von Managed Instance Draining vereinfachen Sie Ihre Workflows zur Infrastrukturverwaltung, die den Austausch von Amazon-EC2-Instances erfordern, und sorgen gleichzeitig für Stabilität und Verfügbarkeit Ihrer Anwendungen.
Amazon ECS Managed Instance Draining funktioniert mit dem Ersatz von Auto-Scaling-Gruppen-Instances. Auf der Grundlage der Instance-Aktualisierung und der maximalen Instance-Lebensdauer können Kunden sicherstellen, dass sie die neuesten Betriebssystem- und Sicherheitsvorschriften für ihre Kapazität einhalten.
Managed Instance Draining kann nur mit Amazon-ECS-Kapazitätsanbietern verwendet werden. Sie können Managed Instance Draining aktivieren, wenn Sie Ihre Auto Scaling Scaling-Gruppenkapazitätsanbieter mithilfe der Amazon ECS-Konsole oder des SDK erstellen oder aktualisieren. AWS CLI
Die folgenden Ereignisse werden durch Amazon ECS Managed Instance Draining abgedeckt.
+ [Instance-Aktualisierung für Auto-Scaling-Gruppen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html) – Verwenden Sie die Instance-Aktualisierung, um die Amazon-EC2-Instances in Ihrer Auto-Scaling-Gruppe fortlaufend zu ersetzen, anstatt dies manuell stapelweise durchzuführen. Diese Methode ist besonders nützlich, wenn Sie eine große Anzahl von Instances ersetzen müssen. Eine Instance-Aktualisierung wird über die Amazon-EC2-Konsole oder die `StartInstanceRefresh`-API eingeleitet. Wenn Sie den verwalteten Beendigungsschutz verwenden, stellen Sie sicher, dass `Replace` für den Abskalierungsschutz auswählen, wenn Sie `StartInstanceRefresh` aufrufen.
+ [Maximale Instance-Lebensdauer](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-max-instance-lifetime.html) – Sie können eine maximale Lebensdauer definieren, wenn es darum geht, die Instances von Auto-Scaling-Gruppen zu ersetzen. Dies ist hilfreich für die Planung von Ersatz-Instances auf der Grundlage interner Sicherheitsrichtlinien oder der Compliance.
+ Abskalieren von Auto-Scaling-Gruppen – Basierend auf Skalierungsrichtlinien und geplanten Skalierungsaktionen unterstützt die Auto-Scaling-Gruppe die automatische Skalierung von Instances. Durch die Verwendung einer Auto-Scaling-Gruppe als Amazon-ECS-Kapazitätsanbieter können Sie Instances von Auto-Scaling-Gruppen abskalieren, wenn auf ihnen keine Aufgaben ausgeführt werden.
+ [Zustandsprüfungen für Auto-Scaling-Gruppen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html) – Auto-Scaling-Gruppen unterstützen viele Zustandsprüfungen, um die Beendigung fehlerhafter Instances zu verwalten.
+ [CloudFormation Stack-Updates](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-direct.html) — Sie können Ihrem CloudFormation Stack ein `UpdatePolicy` Attribut hinzufügen, um fortlaufende Aktualisierungen durchzuführen, wenn sich die Gruppe ändert.
+ [Neuausgleich der Spot-Kapazität](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) – Die Auto-Scaling-Gruppe versucht, Spot-Instances, bei denen ein höheres Ausfallrisiko besteht, proaktiv zu ersetzen, basierend auf der Amazon-EC2-Mitteilung zum Neuausgleich der Kapazität. Die Auto-Scaling-Gruppe beendet die alte Instance, wenn die Ersatz-Instance gestartet und fehlerfrei ist. Mit Amazon ECS Managed Instance Draining wird die Spot-Instance genauso ausgeglichen wie eine Nicht-Spot-Instance.
+ [Spot-Unterbrechung](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html) – Spot Instances werden mit einer Frist von zwei Minuten beendet. Amazon ECS Managed Instance Draining versetzt die Instance daraufhin in den Ausgleichsstatus.
**Lebenszyklus-Hooks für Amazon EC2 Auto Scaling mit Managed Instance Draining.**
Auto-Scaling-Gruppen-Lebenszyklus-Hooks ermöglichen es Kunden, Lösungen zu erstellen, die durch bestimmte Ereignisse im Instance-Lebenszyklus ausgelöst werden, und eine benutzerdefinierte Aktion auszuführen, wenn dieses bestimmte Ereignis eintritt. Eine Auto-Scaling-Gruppe erlaubt bis zu 50 Hooks. Es können mehrere Beendigungs-Hooks existieren, die parallel ausgeführt werden, und die Auto-Scaling-Gruppe wartet, bis alle Hooks abgeschlossen sind, bevor sie eine Instance beenden.
Neben der von Amazon ECS managed Hook-Beendigung können Sie auch Ihre eigenen Lebenszyklus-Beendigungs-Hooks konfigurieren. Lebenszyklus-Hooks haben eine `default action`, und wir empfehlen, `continue` als Standard festzulegen, um sicherzustellen, dass andere Hooks, wie der von Amazon ECS Managed Hook, nicht von Fehlern durch benutzerdefinierte Hooks beeinträchtigt werden.
Wenn Sie bereits einen Lebenszyklus-Hook zur Beendigung von Auto-Scaling-Gruppen konfiguriert und auch Amazon ECS Managed Instance Draining aktiviert haben, werden beide Lebenszyklus-Hooks ausgeführt. Die jeweiligen Zeitpunkte können jedoch nicht garantiert werden. Lebenszyklus-Hooks haben eine `default action`-Einstellung, mit der festgelegt wird, welche Aktion ausgeführt werden soll, wenn das Timeout abgelaufen ist. Im Falle von Fehlern empfehlen wir, `continue` als Standardergebnis in Ihrem benutzerdefinierten Hook zu verwenden. Dadurch wird sichergestellt, dass andere Hooks, insbesondere die von Amazon ECS Managed Hooks, nicht durch Fehler in Ihrem benutzerdefinierten Lebenszyklus-Hook beeinträchtigt werden. Das alternative Ergebnis von `abandon` führt dazu, dass alle anderen Hooks übersprungen werden und vermieden werden sollten. Weitere Informationen über Lebenszyklus-Hooks von Auto-Scaling-Gruppen finden Sie unter [Lebenszyklus-Hooks in Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) im *Benutzerhandbuch für Amazon EC2 Auto Scaling*.
**Entlastung von Aufgaben und verwalteten Instances**
Amazon ECS Managed Instance Draining verwendet das vorhandene Entlastungs-Feature, das in Container-Instances zu finden ist. Das Feature zur [Entlastung von Container-Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-draining.html) führt den Austausch durch und stoppt bei Replikataufgaben, die zu einem Amazon-ECS-Service gehören. Eine eigenständige Aufgabe, z. B. eine von `RunTask` aufgerufene, die sich im Status `PENDING` oder `RUNNING` befindet, bleibt davon unberührt. Sie müssen entweder warten, bis diese abgeschlossen sind, oder sie manuell anhalten. Die Container-Instance bleibt so lange im `DRAINING`-Status, bis entweder alle Aufgaben gestoppt wurden oder 48 Stunden vergangen sind. Daemon-Aufgaben werden als letzte beendet, nachdem alle Replikataufgaben gestoppt wurden.
**Managed Instance Draining und verwalteter Beendigungsschutz**
Managed Instance Draining funktioniert auch dann, wenn die verwaltete Beendigung deaktiviert ist. Weitere Informationen zum verwalteten Beendigungsschutz finden Sie unter [Die Instances steuern, die Amazon ECS beendet](managed-termination-protection.md).
In der folgenden Tabelle ist das Verhalten der verschiedenen Kombinationen aus verwalteter Beendigung und verwalteter Entlastung zusammengefasst.
| Verwaltete Beendigung | Verwaltete Entlastung | Ergebnis |
| --- | --- | --- |
| Aktiviert | Aktiviert | Amazon ECS schützt Amazon-EC2-Instances, auf denen Aufgaben ausgeführt werden, davor, durch Abskalierungsereignisse beendet zu werden. Alle Instances, die beendet werden, z. B. solche, für die kein Beendigungsschutz aktiviert ist, bei denen Spot-Unterbrechungen aufgetreten sind oder die durch eine Instance-Aktualisierung erzwungen wurden, werden ordnungsgemäß ausgeglichen. |
| Disabled | Aktiviert | Amazon ECS schützt Amazon-EC2-Instances, auf denen Aufgaben ausgeführt werden, nicht vor dem Abskalieren. Alle Instances, die beendet werden, werden jedoch ordnungsgemäß ausgeglichen. |
| Enabled | Disabled | Amazon ECS schützt Amazon-EC2-Instances, auf denen Aufgaben ausgeführt werden, davor, durch Abskalierungsereignisse beendet zu werden. Instances können jedoch immer noch durch Spot-Unterbrechungen oder erzwungene Instance-Aktualisierungen beendet werden oder wenn sie keine Aufgaben ausführen. Amazon ECS führt für diese Instances keine ordnungsgemäße Entlastung durch und startet Ersatz-Service-Aufgaben, nachdem sie beendet wurden. |
| Disabled | Disabled | Amazon-EC2-Instances können jederzeit abskaliert oder beendet werden, auch wenn sie Amazon-ECS-Aufgaben ausführen. Amazon ECS startet Ersatz-Service-Aufgaben, nachdem sie beendet wurden. |
**Entlastung verwalteter Instances und Entlastung von Spot Instances**
Mit Spot Instance Draining können Sie eine Umgebungsvariable `ECS_ENABLE_SPOT_INSTANCE_DRAINING` auf dem Amazon-ECS-Agenten einrichten, die es Amazon ECS ermöglicht, eine Instance als Reaktion auf die zweiminütige Spot-Unterbrechung in den Entlastungsstatus zu versetzen. Amazon ECS Managed Instance Draining ermöglicht das reibungslose Herunterfahren von Amazon-EC2-Instances, die aus vielen Gründen beendet werden, nicht nur wegen Spot-Unterbrechungen. Sie können beispielsweise den Kapazitäts-Neuausgleich von Amazon EC2 Auto Scaling verwenden, um Spot-Instances mit erhöhtem Unterbrechungsrisiko proaktiv zu ersetzen, und die verwaltete Instance-Entlastung sorgt dafür, dass die zu ersetzende Spot-Instance ordnungsgemäß heruntergefahren wird. Wenn Sie Managed Instance Draining verwenden, müssen Sie Spot Instance Draining nicht separat aktivieren, sodass `ECS_ENABLE_SPOT_INSTANCE_DRAINING` in den Benutzerdaten von Auto-Scaling-Gruppen redundant ist. Weitere Informationen zur Entlastung von Spot Instances finden Sie unter [Spot Instances](create-capacity.md#container-instance-spot).
## So funktioniert Managed Instance Draining mit EventBridge
Von Amazon ECS verwaltete Instance-Draining-Ereignisse werden auf Amazon veröffentlicht EventBridge, und Amazon ECS erstellt eine EventBridge verwaltete Regel im Standardbus Ihres Kontos, um das Managed Instance Draining zu unterstützen. Sie können diese Ereignisse zur Überwachung und Fehlerbehebung nach anderen AWS Diensten wie Lambda, Amazon SNS und Amazon SQS filtern.
+ Amazon EC2 Auto Scaling sendet ein Ereignis, EventBridge wenn ein Lifecycle-Hook aufgerufen wird.
+ Hinweise zu punktuellen Unterbrechungen werden unter veröffentlicht. EventBridge
+ Amazon ECS generiert Fehlermeldungen, die Sie über die Amazon ECS-Konsole und abrufen können APIs.
+ EventBridge verfügt über integrierte Wiederholungsmechanismen, um vorübergehende Ausfälle zu vermeiden.
# Konfiguration von Amazon-ECS-Kapazitätsanbietern zum sicheren Herunterfahren von Instances
Sie können Managed Instance Draining aktivieren, wenn Sie die Kapazitätsanbieter für Ihre Auto-Scaling-Gruppen mithilfe der Amazon-ECS-Konsole und der AWS CLI erstellen oder aktualisieren.
**Anmerkung**
Managed Instance Draining ist standardmäßig aktiviert, wenn Sie einen Kapazitätsanbieter erstellen.
Im Folgenden finden Sie Beispiele AWS CLI für die Verwendung von zum Erstellen eines Kapazitätsanbieters mit aktiviertem Managed Instance Draining und zum Aktivieren des Managed Instance Draining für den vorhandenen Kapazitätsanbieter eines Clusters.
**Einen Kapazitätsanbieters mit aktiviertem Managed Instance Draining erstellen**
Verwenden Sie den `create-capacity-provider`-Befehl, um einen Kapazitätsanbieter mit aktiviertem Managed Instance Draining zu erstellen. Stellen Sie den Parameter `managedDraining` auf `ENABLED` ein.
```
aws ecs create-capacity-provider \
--name capacity-provider \
--auto-scaling-group-provider '{
"autoScalingGroupArn": "asg-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1
},
"managedDraining": "ENABLED",
"managedTerminationProtection": "ENABLED",
}'
```
Antwort:
```
{
"capacityProvider": {
"capacityProviderArn": "capacity-provider-arn",
"name": "capacity-provider",
"status": "ACTIVE",
"autoScalingGroupProvider": {
"autoScalingGroupArn": "asg-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1
},
"managedTerminationProtection": "ENABLED"
"managedDraining": "ENABLED"
}
}
}
```
**Managed Instance Draining für den vorhandenen Kapazitätsanbieter eines Clusters aktivieren**
Sie können mit dem `update-capacity-provider`-Befehl Managed Instance Draining für den vorhandenen Kapazitätsanbieter eines Clusters aktivieren. Sie sehen, dass das `managedDraining` derzeit `DISABLED` sagt und `updateStatus` sagt `UPDATE_IN_PROGRESS`.
```
aws ecs update-capacity-provider \
--name cp-draining \
--auto-scaling-group-provider '{
"managedDraining": "ENABLED"
}
```
Antwort:
```
{
"capacityProvider": {
"capacityProviderArn": "cp-draining-arn",
"name": "cp-draining",
"status": "ACTIVE",
"autoScalingGroupProvider": {
"autoScalingGroupArn": "asg-draining-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1,
"instanceWarmupPeriod": 300
},
"managedTerminationProtection": "DISABLED",
"managedDraining": "DISABLED" // before update
},
"updateStatus": "UPDATE_IN_PROGRESS", // in progress and need describe again to find out the result
"tags": [
]
}
}
```
Verwenden Sie den `describe-clusters`-Befehl und schließen Sie `ATTACHMENTS` ein. Der `status` des Anhangs für Managed Instance Draining ist `PRECREATED`, und der gesamte `attachmentsStatus` ist `UPDATING`.
```
aws ecs describe-clusters --clusters cluster-name --include ATTACHMENTS
```
Antwort:
```
{
"clusters": [
{
...
"capacityProviders": [
"cp-draining"
],
"defaultCapacityProviderStrategy": [],
"attachments": [
# new precreated managed draining attachment
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"type": "managed_draining",
"status": "PRECREATED",
"details": [
{
"name": "capacityProviderName",
"value": "cp-draining"
},
{
"name": "autoScalingLifecycleHookName",
"value": "ecs-managed-draining-termination-hook"
}
]
},
...
],
"attachmentsStatus": "UPDATING"
}
],
"failures": []
}
```
Wenn die Aktualisierung abgeschlossen ist, verwenden Sie `describe-capacity-providers` und Sie sehen `managedDraining` ist jetzt `ENABLED`.
```
aws ecs describe-capacity-providers --capacity-providers cp-draining
```
Antwort:
```
{
"capacityProviders": [
{
"capacityProviderArn": "cp-draining-arn",
"name": "cp-draining",
"status": "ACTIVE",
"autoScalingGroupProvider": {
"autoScalingGroupArn": "asg-draning-arn",
"managedScaling": {
"status": "ENABLED",
"targetCapacity": 100,
"minimumScalingStepSize": 1,
"maximumScalingStepSize": 1,
"instanceWarmupPeriod": 300
},
"managedTerminationProtection": "DISABLED",
"managedDraining": "ENABLED" // successfully update
},
"updateStatus": "UPDATE_COMPLETE",
"tags": []
}
]
}
```
## Fehlerbehebung bei Amazon ECS Managed Instance Draining
Möglicherweise müssen Sie Probleme mit Managed Instance Draining beheben. Im Folgenden finden Sie ein Beispiel für die Lösung eines Problems, auf das Sie bei der Verwendung stoßen können.
**Bei Verwendung von Auto Scaling werden Instances nicht beendet, wenn sie die maximale Instance-Lebensdauer überschritten haben.**
Wenn Sie eine Auto-Scaling-Gruppe verwenden und Instances nicht beendet werden, auch nachdem sie die maximalen Instance-Lebensdauer erreicht bzw. überschritten haben, kann das daran liegen, dass sie vor Abskalierung geschützt sind. Sie können die verwaltete Beendigung deaktivieren und die verwaltete Entlastung erlauben, das Instance-Recycling zu übernehmen.
## Entlastungsverhalten für Amazon ECS Managed Instances
Die Kündigung von Amazon ECS Managed Instances gewährleistet reibungslose Arbeitslastübergänge bei gleichzeitiger Kostenoptimierung und Aufrechterhaltung der Systemintegrität. Das Beendigungssystem bietet drei unterschiedliche Entscheidungspfade für die Beendigung von Instances, die jeweils unterschiedliche zeitliche Merkmale und Kundenauswirkungsprofile aufweisen.
### Entscheidungspfade zur Beendigung
Vom Kunden initiierte Beendigung
Bietet direkte Kontrolle über das Entfernen von Instances, wenn Sie Container-Instances sofort außer Betrieb nehmen müssen. Sie rufen die DeregisterContainerInstance API auf, wobei das Force-Flag auf true gesetzt ist, was darauf hinweist, dass trotz laufender Workloads eine sofortige Kündigung erforderlich ist.
Vom System initiierte Beendigung im Leerlauf
Amazon ECS Managed Instances überwacht und optimiert die Kosten kontinuierlich und proaktiv, indem inaktive Amazon ECS-Container-Instances beendet werden, auf denen keine Aufgaben ausgeführt werden. ECS verwendet eine heuristische Verzögerung, um Container-Instances die Möglichkeit zu geben, neu gestartete Aufgaben zu übernehmen, bevor sie beendet werden. Dies kann mit dem Konfigurationsparameter des Kapazitätsanbieters `scaleInAfter` Amazon ECS Managed Instances angepasst werden.
Beendigung der Aktualisierung der Infrastruktur
Amazon ECS Managed Instances verwaltet und aktualisiert automatisch Software auf verwalteten Container-Instances, um Sicherheit und Compliance zu gewährleisten und gleichzeitig die Workload-Verfügbarkeit aufrechtzuerhalten. Weitere Informationen finden Sie unter [Patchen in Amazon ECS Managed Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html).
### Ordnungsgemäße Entlastung und Workload-Migration
Das ordnungsgemäße Entlastungssystem sorgt für eine ausgeklügelte Abstimmung mit dem Amazon-ECS-Servicemanagement, um sicherzustellen, dass serviceverwaltete Aufgaben ordnungsgemäß von den Instances entfernt werden, für die eine Beendigung geplant ist.
**Koordination der Entlastung von Serviceaufgaben**
Wenn eine Instance in den Status DRAINING übergeht, stoppt der Amazon ECS Scheduler automatisch das Platzieren neuer Aufgaben auf der Instance und implementiert gleichzeitig Verfahren zum ordnungsgemäßen Herunterfahren vorhandener Serviceaufgaben. Die Entlastung der Serviceaufgaben umfasst die Koordination mit den Strategien zur Servicebereitstellung, den Anforderungen an die Zustandsprüfungen und Ihren Präferenzen für den Ausgleich, um einen optimalen Zeitpunkt und optimale Erfolgsquoten für die Migration zu gewährleisten.
**Eigenständige Bearbeitung von Aufgaben**
Eigenständige Aufgaben müssen unterschiedlich bearbeitet werden, da sie nicht vom automatischen Servicemanagement profitieren. Das System bewertet Merkmale eigenständiger Aufgaben, einschließlich Schätzungen der Aufgabendauer, Analysen der Abschlusswahrscheinlichkeit und Bewertung der Auswirkungen auf den Kunden. Die Strategie des ordnungsgemäßen Abschlusses ermöglicht die automatische Ausführung eigenständiger Aufgaben innerhalb eines längeren Übergangszeitraums. Gleichzeitig stellt die erzwungene Beendigung sicher, dass die Infrastruktur innerhalb akzeptabler Zeiträume aktualisiert wird, wenn Aufgaben nicht automatisch abgeschlossen wurden.
### Zweiphasige Abschlussstrategie
Das Beendingungssystem verfolgt einen zweiphasigen Ansatz, bei dem die Workload-Kontinuität mit den Anforderungen an die Infrastrukturverwaltung in Einklang gebracht wird.
**Phase 1: Ordnungsgemäße Abschlusszeit**
Während dieser Phase implementiert das System Strategien zur ordnungsgemäßen Entlastung, bei denen die Kontinuität der Workload an erster Stelle steht. Serviceaufgaben werden durch normale Amazon-ECS-Planungsprozesse problemlos gelöscht, eigenständige Aufgaben werden weiterhin ausgeführt und können auf natürliche Weise abgeschlossen werden, und das System überwacht, ob alle Aufgaben durch natürliche Abschlussprozesse den Status „Angehalten“ erreichen.
**Phase 2: Strenge Durchsetzung von Fristen**
Wenn durch einen ordnungsgemäßen Abschluss die Beendigungsziele nicht innerhalb eines akzeptablen Zeitrahmens erreicht werden, führt das System eine strikte Durchsetzung der Fristen durch. Die feste Frist wird in der Regel auf die Entlastungs-Initiierungszeit plus sieben Tage festgelegt, sodass ausreichend Zeit für einen ordnungsgemäßen Abschluss unter Wahrung der betrieblichen Anforderungen zur Verfügung steht. Die Durchsetzung umfasst den automatischen Aufruf von Verfahren zur erzwungenen Abmeldung und die sofortige Beendigung aller verbleibenden Aufgaben, unabhängig vom Abschluss-Status.
# Erstellen von Ressourcen für Amazon ECS-Cluster Auto Scaling mit dem AWS-Managementkonsole
Erfahren Sie, wie Sie die Ressourcen für Cluster Auto Scaling mit der AWS-Managementkonsole erstellen. Wenn Ressourcen einen Namen benötigen, verwenden wir das Präfix `ConsoleTutorial`, um sicherzustellen, dass alle Ressourcen eindeutige Namen haben und leicht zu finden sind.
**Topics**
+ [
## Voraussetzungen
](#console-tutorial-prereqs)
+ [
## Schritt 1: Erstellen eines Amazon-ECS-Clusters
](#console-tutorial-cluster)
+ [
## Schritt 2: Registrieren einer Aufgabendefinition
](#console-tutorial-register-task-definition)
+ [
## Schritt 3: Ausführen einer Aufgabe
](#console-tutorial-run-task)
+ [
## Schritt 4: Überprüfen
](#console-tutorial-verify)
+ [
## Schritt 5: Bereinigen
](#console-tutorial-cleanup)
## Voraussetzungen
In diesem Tutorial wird davon ausgegangen, dass die folgenden Voraussetzungen erfüllt wurden:
+ Die Schritte in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) wurden ausgeführt.
+ Ihr IAM-Benutzer besitzt die im [AmazonECS\$1 FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess)-IAM-Richtlinienbeispiel angegebenen Berechtigungen.
+ Die Amazon-ECS-Container-Instance IAM-Rolle wird erstellt. Weitere Informationen finden Sie unter [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md).
+ Die Amazon-ECS-serviceverknüpfte IAM-Rolle wird erstellt. Weitere Informationen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon ECS](using-service-linked-roles.md).
+ Die serviceverknüpften IAM-Rolle für Auto Scaling wird erstellt. Weitere Informationen finden Sie unter [Servicebezogene Rollen für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html) im *Benutzerhandbuch zum Amazon EC2 Auto Scaling*.
+ Sie haben eine VPC und die zu verwendende Sicherheitsgruppe erstellt. Weitere Informationen finden Sie unter [Erstellen einer Virtual Private Cloud](get-set-up-for-amazon-ecs.md#create-a-vpc).
## Schritt 1: Erstellen eines Amazon-ECS-Clusters
Führen Sie die folgenden Schritte aus, um einen Amazon-ECS-Cluster zu erstellen.
Amazon ECS erstellt in Ihrem Namen eine Amazon EC2 Auto Scaling Scaling-Startvorlage und eine Auto Scaling-Gruppe als Teil des CloudFormation Stacks.
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 Navigationsbereich **Cluster** und dann **Cluster erstellen**.
1. Geben Sie unter **Cluster-Konfiguration** für **Cluster-Name** `ConsoleTutorial-cluster` ein.
1. Löschen Sie unter **Infrastruktur** die Option AWS Fargate (serverlos) und wählen Sie dann **Amazon EC2 EC2-Instances** aus. Konfigurieren Sie als Nächstes die Auto-Scaling-Gruppe, die als Kapazitätsanbieter fungiert.
1. Unter der **Auto-Scaling-Gruppe (ASG)**. Wählen Sie **Neue ASG erstellen** aus, und geben Sie dann die folgenden Details zur Gruppe ein:
+ Wählen Sie für **Betriebssystem/Architektur** die Option **Amazon Linux 2** aus.
+ Wählen Sie unter **EC2-Instance-Typ** **t3.nano**.
+ Geben Sie für **Capacity** (Kapazität) die minimale Anzahl und die maximale Anzahl von Instances ein, die in der Auto-Scaling-Gruppe gelauncht werden sollen.
1. (Optional) Um die Cluster-Tags zu verwalten, erweitern Sie **Tags** und führen Sie dann eine der folgenden Vorgänge aus:
[Markierung hinzufügen] Wählen Sie **Add tag (Markierung hinzufügen)**, und führen Sie die folgenden Schritte aus:
+ Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein.
+ Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein.
[Markierung entfernen] Wählen Sie **Remove (Entfernen)** rechts neben dem Schlüssel und dem Wert der Markierung.
1. Wählen Sie **Erstellen** aus.
## Schritt 2: Registrieren einer Aufgabendefinition
Bevor Sie auf Ihrem Cluster eine Aufgabe ausführen können, müssen Sie eine Aufgabendefinition registrieren. Aufgabendefinitionen sind Listen zusammengefasster Container. Im folgenden Beispiel sehen Sie eine einfache Aufgabendefinition, die ein `amazonlinux`-Image aus dem Docker-Hub verwendet und sich einfach im Ruhezustand befindet. Weitere Informationen zu den verfügbaren Parametern für die Aufgabendefinition finden Sie im Abschnitt [Amazon-ECS-Aufgabendefinitionen](task_definitions.md).
1. [Öffnen Sie die Konsole auf Version 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)
1. Wählen Sie im Navigationsbereich **Task definitions** (Aufgabendefinitionen) aus.
1. Wählen Sie **Create new task definition** (Neue Aufgabendefinition erstellen), **Create new task definition with JSON** (Neue Aufgabendefinition mit JSON) erstellen.
1. Fügen Sie im Textfeld **JSON-Editor** den folgenden Inhalt ein.
```
{
"family": "ConsoleTutorial-taskdef",
"containerDefinitions": [
{
"name": "sleep",
"image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
"memory": 20,
"essential": true,
"command": [
"sh",
"-c",
"sleep infinity"
]
}
],
"requiresCompatibilities": [
"EC2"
]
}
```
1. Wählen Sie **Erstellen** aus.
## Schritt 3: Ausführen einer Aufgabe
Nachdem Sie eine Aufgabendefinition für Ihr Konto registriert haben, können Sie eine Aufgabe im Cluster ausführen. Für dieses Tutorial führen Sie fünf Instances der `ConsoleTutorial-taskdef`-Aufgabendefinition in Ihrem `ConsoleTutorial-cluster`-Cluster aus.
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Wählen Sie auf der **Cluster-Seite ConsoleTutorial** **-cluster** aus.
1. Wählen Sie unter **Aufgaben** die Option **Neue Aufgabe ausführen**.
1. Wählen Sie im Abschnitt **Umgebung** unter **Rechenoptionen** die Option **Kapazitätsanbieter-Strategie** aus.
1. Wählen Sie unter **Bereitstellungskonfiguration** für **Anwendungstyp** die Option **Aufgabe** aus.
1. **Wählen Sie **ConsoleTutorial-taskdef aus der Dropdownliste** Family aus.**
1. Geben Sie unter **Gewünschte Aufgaben** den Wert 5 ein.
1. Wählen Sie **Erstellen** aus.
## Schritt 4: Überprüfen
Zu diesem Zeitpunkt im Tutorial sollten Sie einen Cluster mit fünf aktiven Aufgaben und eine Auto-Scaling-Gruppe mit einem Kapazitätsanbieter haben. Für den Kapazitätsanbieter ist die Amazon-ECS-verwaltete Skalierung aktiviert.
Wir können überprüfen, ob alles ordnungsgemäß funktioniert, indem wir uns die CloudWatch Metriken, die Auto Scaling Scaling-Gruppeneinstellungen und schließlich die Anzahl der Amazon ECS-Cluster-Aufgaben ansehen.
**Um die CloudWatch Metriken für Ihren Cluster anzuzeigen**
1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie auf der Navigationsleiste oben auf dem Bildschirm die Region aus.
1. Wählen Sie im Navigationsbereich unter **Metriken** **Alle Metriken** aus.
1. Wählen Sie auf der Seite **Alle Metriken** unter der Registerkarte **Durchsuchen** die Option `AWS/ECS/ManagedScaling`.
1. Wähle **CapacityProviderName, ClusterName**.
1. Aktivieren Sie das Kontrollkästchen, das dem entspricht `ConsoleTutorial-cluster` ** ClusterName**.
1. Ändern Sie auf der Registerkarte **Grafisch dargestellte Metriken** den **Zeitraum** auf **30 Sekunden** und **Statistik** auf **Maximum**.
Der im Diagramm angezeigte Wert stellt den Zielkapazitätswert für den Kapazitätsanbieter dar. Er sollte bei `100` beginnen, was der zuvor festgelegte Zielkapazitätsprozentsatz ist. Sie sollten eine Skalierung nach oben bis `200` sehen, wodurch ein Alarm für die Zielverfolgungsskalierungsrichtlinie ausgelöst wird. Der Alarm löst dann eine Skalierung der Auto-Scaling-Gruppe nach oben aus.
Gehen Sie wie folgt vor, um Ihre Auto-Scaling-Gruppendetails anzuzeigen, um zu bestätigen, dass die Aktion zur Skalierung nach oben eingetreten ist.
**So überprüfen Sie die Skalierung der Auto-Scaling-Gruppe**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie auf der Navigationsleiste oben auf dem Bildschirm die Region aus.
1. Wählen Sie im Navigationsbereich unter **Auto Scaling** **Auto Scaling Groups (Auto Scaling-Gruppe)** aus.
1. Wählen Sie die in diesem Tutorial erstellte `ConsoleTutorial-cluster`-Auto-Scaling-Gruppe aus. Sehen Sie sich den Wert unter **Gewünschte Kapazität** und die Instances auf der Registerkarte **Instance-Verwaltung** an, um zu bestätigen, dass Ihre Gruppe auf zwei Instances skaliert wurde.
Führen Sie die folgenden Schritte aus, um Ihren Amazon-ECS-Cluster anzuzeigen und um so zu bestätigen, dass die Amazon-EC2-Instances beim Cluster registriert wurden und Ihre Aufgaben in einen `RUNNING`-Status übergehen.
**So überprüfen Sie die Instances in der Auto-Scaling-Gruppe**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster**-Seite den `ConsoleTutorial-cluster`-Cluster aus.
1. Bestätigen Sie auf der Registerkarte **Aufgaben**, dass fünf Aufgaben im Status `RUNNING` angezeigt werden.
## Schritt 5: Bereinigen
Wenn Sie dieses Tutorial abgeschlossen haben, sollten Sie die damit verknüpften Ressourcen bereinigen, um zu vermeiden, dass für nicht verwendete Ressourcen Kosten entstehen. Das Löschen von Kapazitätsanbietern und Aufgabendefinitionen wird nicht unterstützt, aber mit diesen Ressourcen sind keine Kosten verbunden.
**So bereinigen Sie die Tutorial-Ressourcen**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster-Seite ConsoleTutorial** **-cluster** aus.
1. **Wählen Sie auf der Seite **ConsoleTutorial-cluster** die Registerkarte **Tasks** und dann **Stop, Stop All** aus.**
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der Seite **Clusters** die Option **ConsoleTutorial-cluster** aus.
1. Wählen Sie oben rechts auf der Seite **Cluster löschen** aus.
1. **Geben Sie im Bestätigungsfeld **delete **ConsoleTutorial-cluster** ein und wählen Sie Löschen** aus.**
1. Löschen Sie die Auto-Scaling-Gruppen, indem Sie folgende Schritte ausführen.
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie auf der Navigationsleiste oben auf dem Bildschirm die Region aus.
1. Wählen Sie im Navigationsbereich unter **Auto Scaling** **Auto Scaling Groups (Auto Scaling-Gruppe)** aus.
1. Wählen Sie die `ConsoleTutorial-cluster`-Auto-Scaling-Gruppe und dann **Aktionen** aus.
1. Wählen Sie im Menü **Actions (Aktionen)** die Option **Delete (Löschen)** aus. Geben Sie im Bestätigungsfeld **Löschen** ein und wählen Sie dann **Löschen**.
# Amazon-EC2-Container-Instances für Amazon ECS
Eine Amazon-ECS-Container-Instance ist eine Amazon-EC2-Instance, die den Amazon-ECS-Container-Agent ausführt und in einem Cluster registriert wurde. Wenn Sie Aufgaben mit Amazon ECS unter Verwendung des Kapazitätsanbieters, des externen Kapazitätsanbieters oder eines Kapazitätsanbieters der Auto-Scaling-Gruppe ausführen, werden Aufgaben auf den aktiven Container-Instances platziert. Sie sind für die Verwaltung und Wartung von Container-Instances verantwortlich.
Sie können zwar Ihr eigenes Amazon EC2 EC2-Instance-AMI erstellen, das die grundlegenden Spezifikationen erfüllt, die für die Ausführung Ihrer containerisierten Workloads auf Amazon ECS erforderlich sind, aber die Amazon ECS-optimierten AMIs sind vorkonfiguriert und wurden von Technikern auf Amazon ECS getestet. AWS Dies ist die einfachste Methode für den Einstieg, mit dem Ihre Container in AWS schnell einsatzbereit werden.
Wenn Sie mit der Konsole einen Cluster erstellen, erstellt Amazon ECS eine Startvorlage für Ihre Instances mit dem neuesten AMI, das dem ausgewählten Betriebssystem zugeordnet ist.
Wenn Sie CloudFormation einen Cluster erstellen, ist der SSM-Parameter Teil der Amazon EC2 EC2-Startvorlage für die Auto Scaling Scaling-Gruppeninstanzen. Sie können die Vorlage so konfigurieren, dass ein dynamischer Systems-Manager-Parameter verwendet wird, um zu bestimmen, welches Amazon-ECS-optimierte AMI bereitgestellt werden soll. Dieser Parameter stellt sicher, dass der Stack bei jeder Bereitstellung überprüft, ob eine Aktualisierung verfügbar ist, die auf die EC2-Instances angewendet werden muss. Ein Beispiel für die Verwendung des Systems-Manager-Parameters finden Sie unter [Erstellen eines Amazon-ECS-Clusters mit dem Amazon-ECS-optimierten-AMI für Amazon Linux 2023](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) im *Benutzerhandbuch für AWS CloudFormation *.
+ [Abrufen der Amazon-ECS-optimierten Linux-AMI-Metadaten](retrieve-ecs-optimized_AMI.md)
+ [Abrufen der Metadaten des Amazon-ECS-optimierten Bottlerocket-AMI](ecs-bottlerocket-retrieve-ami.md)
+ [Abrufen der Amazon-ECS-optimierten Windows-AMI-Metadaten](retrieve-ecs-optimized_windows_AMI.md)
Sie können aus den Instance-Typen wählen, die mit Ihrer Anwendung kompatibel sind. Bei größeren Instances können Sie mehr Aufgaben gleichzeitig starten. Bei kleineren Instances können Sie differenzierter aufskalieren, um Kosten zu sparen. Sie müssen sich nicht für einen einzigen Amazon-EC2-Instance-Typ entscheiden, der für alle Anwendungen in Ihrem Cluster geeignet ist. Stattdessen können Sie mehrere Auto-Scaling-Gruppen erstellen, wobei jede Gruppe einen anderen Instance-Typen hat. Anschließend können Sie für jede dieser Gruppen einen Amazon-EC2-Kapazitätsanbieter erstellen.
Bestimmen Sie anhand der folgenden Richtlinien die Instance-Familientypen und den Instance-Typen, die verwendet werden sollen:
+ Eliminieren Sie die Instance-Typen oder Instance-Familien, die den spezifischen Anforderungen Ihrer Anwendung nicht entsprechen. Wenn Ihre Anwendung beispielsweise eine GPU benötigt, können Sie alle Instance-Typen ausschließen, die keine GPU haben.
+ Berücksichtigen Sie Anforderungen wie Netzwerkdurchsatz und Speicher.
+ Berücksichtigen Sie den CPU und den Arbeitsspeicher. Als allgemeine Regel gilt, dass die CPU und der Arbeitsspeicher groß genug sein müssen, um mindestens ein Replikat der Aufgabe aufzunehmen, die Sie ausführen möchten.
## Spot Instances
Spot-Kapazität kann im Vergleich zu On-Demand-Instances zu erheblichen Kosteneinsparungen führen. Spot-Kapazität ist überschüssige Kapazität, deren Preis deutlich unter dem Preis für On-Demand-Kapazität oder reservierter Kapazität liegt. Spot-Kapazität eignet sich für Batch-Verarbeitungs- und Machine-Learning-Workloads sowie für Entwicklungs- und Staging-Umgebungen. Generell ist sie für alle Workloads geeignet, die vorübergehende Ausfallzeiten tolerieren.
Seien Sie sich über die folgenden Konsequenzen im Klaren, denn die Spot-Kapazität ist möglicherweise nicht immer verfügbar.
+ In Zeiten extrem hoher Nachfrage ist die Spot-Kapazität möglicherweise nicht verfügbar. Dies kann dazu führen, dass der Start von Amazon-EC2-Spot-Instances verzögert wird. In diesen Fällen versuchen Amazon-ECS-Services erneut, Aufgaben zu starten, und Gruppen von Amazon-EC2-Auto-Scaling versuchen ebenfalls erneut, Instances zu starten, bis die erforderliche Kapazität verfügbar ist. Amazon EC2 ersetzt Spot-Kapazität nicht durch On-Demand-Kapazität.
+ Wenn der Gesamtbedarf an Kapazität steigt, werden Spot Instances und Aufgaben möglicherweise mit einer Warnung von nur zwei Minuten beendet. Nach dem Senden der Warnung sollten die Aufgaben gegebenenfalls korrekt heruntergefahren werden, bevor die Instance vollständig beendet wird. Dies trägt dazu bei, die Wahrscheinlichkeit von Fehlern zu minimieren. Weitere Informationen zu einem korrekten Herunterfahren finden Sie unter [Korrektes Herunterfahren mit ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/).
Beachten Sie die folgenden Empfehlungen, um Kapazitätsengpässe vor Ort zu minimieren:
+ Verwenden Sie mehrere Regionen und Availability Zones – Die Spot-Kapazität variiert je nach Region und Availability Zone. Sie können die Spot-Verfügbarkeit verbessern, indem Sie Ihre Workloads in mehreren Regionen und Availability Zones ausführen. Geben Sie nach Möglichkeit Subnetze in allen Availability Zones in den Regionen an, in denen Sie Ihre Tasks und Instances ausführen.
+ Verwenden von mehreren Amazon-EC2-Instance-Typen – Wenn Sie Mixed Instance Policies mit Amazon EC2 Auto Scaling verwenden, werden mehrere Instance-Typen in Ihrer Auto-Scaling-Gruppe gestartet. Dadurch wird sichergestellt, dass eine Anfrage nach Spot-Kapazität bei Bedarf erfüllt werden kann. Um die Zuverlässigkeit zu maximieren und die Komplexität zu minimieren, sollten Sie in Ihrer Mixed Instances Policy Instance-Typen mit ungefähr der gleichen Menge an CPU und Arbeitsspeicher verwenden. Diese Instances können aus einer anderen Generation oder aus Varianten desselben Basis-Instance-Typs stammen. Beachten Sie, dass sie möglicherweise zusätzliche Features enthalten, die Sie möglicherweise nicht benötigen. Ein Beispiel für eine solche Liste könnte m4.large, m5.large, m5a.large, m5d.large, m5n.large, m5dn.large und m5ad.large enthalten. Weitere Informationen finden Sie unter [Auto-Scaling-Gruppen mit mehreren Instance-Typen und Kaufoptionen](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) im *Benutzerhandbuch für Amazon EC2 Auto Scaling*.
+ Verwenden Sie die kapazitätsoptimierte Spot-Zuweisungsstrategie – Mit Amazon EC2 Spot können Sie zwischen kapazitäts- und kostenoptimierten Zuweisungsstrategien wählen. Wenn Sie beim Start einer neuen Instance die kapazitätsoptimierte Strategie wählen, wählt Amazon EC2 Spot den Instance-Typ mit der größten Verfügbarkeit in der ausgewählten Availability Zone aus. Dies trägt dazu bei, die Wahrscheinlichkeit zu verringern, dass die Instance kurz nach ihrem Start beendet wird.
Informationen darüber, wie Sie Spot-Beendigungsnachrichten auf Ihren Container-Instances konfigurieren, finden Sie unter:
+ [Konfiguration von Linux-Container-Instances von Amazon ECS für den Empfang von Spot-Instance-Benachrichtigungen](spot-instance-draining-linux-container.md)
+ [Konfiguration von Windows-Container-Instances von Amazon ECS für den Empfang von Spot-Instance-Benachrichtigungen](windows-spot-instance-draining-container.md)
# Amazon ECS-optimiertes Linux AMIs
**Wichtig**
[Das Amazon ECS-optimierte Amazon Linux 2-AMI wird end-of-life am 30. Juni 2026 erreicht und entspricht damit demselben EOL-Datum wie das Upstream-Betriebssystem Amazon Linux 2 (weitere Informationen finden Sie unter Amazon Linux 2). FAQs](https://aws.amazon.com/amazon-linux-2/faqs/) Wir empfehlen unseren Kunden, ihre Anwendungen auf Amazon Linux 2023 aufzurüsten, was langfristigen Support bis 2028 beinhaltet. Informationen zur Migration von Amazon Linux 2 zu Amazon Linux 2023 finden Sie unter [Migration vom Amazon-ECS-optimierten AMI für Amazon Linux 2 zum Amazon-ECS-optimierten AMI für Amazon Linux 2023](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html).
Standardmäßig ist das Verfallsdatum aller Amazon ECS-optimierten AMIs auf zwei Jahre nach dem Erstellungsdatum des AMI festgelegt. Sie können die Amazon EC2 `DescribeImages` EC2-API verwenden, um den Verfallsstatus und das Datum eines AMI zu überprüfen. Weitere Informationen finden Sie [DescribeImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html)in der *Amazon Elastic Compute Cloud API-Referenz*.
Amazon ECS stellt die Amazon-ECS-optimierten AMIs bereit, die mit den notwendigen Anforderungen und Empfehlungen vorkonfiguriert sind, um Ihre Container-Workloads auszuführen. Wir empfehlen die Verwendung des Amazon-ECS-optimierten-AMI für Amazon Linux 2023 für Ihre Amazon-EC2-Instances. Wenn Sie Ihre Container-Instances von dem neuesten für Amazon ECS optimierten AMI starten, ist sichergestellt, dass Sie die aktuellen Sicherheitsupdates und die Version des Container-Agenten erhalten. Weitere Informationen, wie eine Instance gestartet wird, finden Sie unter [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
Wenn Sie mit der Konsole einen Cluster erstellen, erstellt Amazon ECS eine Startvorlage für Ihre Instances mit dem neuesten AMI, das dem ausgewählten Betriebssystem zugeordnet ist.
Wenn Sie CloudFormation einen Cluster erstellen, ist der SSM-Parameter Teil der Amazon EC2 EC2-Startvorlage für die Auto Scaling Scaling-Gruppeninstanzen. Sie können die Vorlage so konfigurieren, dass ein dynamischer Systems-Manager-Parameter verwendet wird, um zu bestimmen, welches Amazon-ECS-optimierte AMI bereitgestellt werden soll. Dieser Parameter stellt sicher, dass der Stack bei jeder Bereitstellung überprüft, ob eine Aktualisierung verfügbar ist, die auf die EC2-Instances angewendet werden muss. Ein Beispiel für die Verwendung des Systems-Manager-Parameters finden Sie unter [Erstellen eines Amazon-ECS-Clusters mit dem Amazon-ECS-optimierten-AMI für Amazon Linux 2023](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) im *Benutzerhandbuch für AWS CloudFormation *.
Wenn Sie das Amazon ECS-optimierte AMI anpassen müssen, finden Sie weitere Informationen unter [Amazon ECS Optimized AMI Build Recipes](https://github.com/aws/amazon-ecs-ami) auf. GitHub
Die folgenden Varianten des Amazon-ECS-optimierten AMI sind für Ihre Amazon-EC2-Instances mit dem Betriebssystem von Amazon Linux 2023 verfügbar.
| Betriebssystem | AMI | Description | Speicherkonfiguration |
| --- | --- | --- | --- |
| Amazon Linux 2023 | Amazon-ECS-optimiertes AMI für Amazon Linux 2023 | Amazon Linux 2023 ist die nächste Generation von Amazon Linux von AWS. In den meisten Fällen empfohlen, um Ihre Amazon-EC2-Instances für Ihre Amazon-ECS-Workloads zu launchen. Weitere Informationen finden Sie unter [Was ist Amazon Linux 2023?](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html) im *Benutzerhandbuch für Amazon Linux 2023*. | Standardmäßig wird das Amazon-ECS-optimierte AMI für Amazon Linux 2023 mit einem einzelnen 30-GiB-Root-Volume ausgeliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte AMI für Amazon Linux 2023 ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
| Amazon Linux 2023 (arm64) | Amazon-ECS-optimiertes AMI für Amazon Linux 2023 (arm64) | Dieses AMI basiert auf Amazon Linux 2023 und wird für den Start Ihrer Amazon EC2 EC2-Instances, die auf ARM-basierten AWS Graviton/Graviton 2/Graviton 3/Graviton 4-Prozessoren basieren, für Ihre Amazon ECS-Workloads empfohlen. Weitere Informationen finden Sie unter [Spezifikationen für Allzweck-Instances in Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html) im *Leitfaden zu Instance-Typen von Amazon EC2*. | Standardmäßig wird das Amazon-ECS-optimierte AMI für Amazon Linux 2023 mit einem einzelnen 30-GiB-Root-Volume ausgeliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte AMI für Amazon Linux 2023 ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
| Amazon Linux 2023 (Neuron) | Amazon-ECS-optimiertes AMI für Amazon Linux 2023 | Basierend auf Amazon Linux 2023 ist dieses AMI für Inf1-, Trn1- oder Inf2-Instances von Amazon EC2 bestimmt. Es ist mit den Treibern AWS Inferentia und AWS Trainium sowie der AWS Neuron-Runtime für Docker vorkonfiguriert, wodurch die Ausführung von Inferenz-Workloads für maschinelles Lernen auf Amazon ECS vereinfacht wird. Weitere Informationen finden Sie unter [Amazon ECS-Aufgabendefinitionen für AWS Neuron-Workloads für maschinelles Lernen](ecs-inference.md). Das Amazon-ECS-optimierte AMI für Amazon Linux 2023 (Neuron) hat die AWS CLI nicht vorinstalliert. | Standardmäßig wird das Amazon-ECS-optimierte AMI für Amazon Linux 2023 mit einem einzelnen 30-GiB-Root-Volume ausgeliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte AMI für Amazon Linux 2023 ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
| Amazon Linux 2.023 GPU | Amazon-ECS-optimiertes AMI für Amazon Linux 2023 GPU | Dieses AMI basiert auf Amazon Linux 2023 und wird für den Start Ihrer Amazon EC2 EC2-GPU-basierten Instances für Ihre Amazon ECS-Workloads empfohlen. Es ist mit NVIDIA-Kerneltreibern und einer Docker-GPU-Laufzeit vorkonfiguriert, sodass Workloads ausgeführt werden können, die die Vorteile von GPUs Amazon ECS nutzen. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabendefinitionen für GPU-Workloads](ecs-gpu.md). | Standardmäßig wird das Amazon-ECS-optimierte AMI für Amazon Linux 2023 mit einem einzelnen 30-GiB-Root-Volume ausgeliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte AMI für Amazon Linux 2023 ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
Die folgenden Varianten des Amazon-ECS-optimierten AMI sind für Ihre Amazon-EC2-Instances mit dem Betriebssystem von Amazon Linux 2 verfügbar.
| Betriebssystem | AMI | Description | Speicherkonfiguration |
| --- | --- | --- | --- |
| **Amazon Linux 2** | Amazon-ECS-optimiertes Amazon-Linux-2-AMI mit Kernel 5.10 | Dieses AMI basiert auf Amazon Linux 2 und ist für den Start Ihrer Amazon-EC2-Instances bestimmt, bei denen Sie Linux-Kernel 5.10 anstelle von Kernel 4.14 für Ihre Amazon-ECS-Workloads verwenden sollten. Das Amazon-ECS-optimierte Amazon-Linux-2-AMI Kernel 5.10 ist nicht mit dem AWS CLI vorinstalliert. | Standardmäßig wird das auf Amazon Linux 2 basierende Amazon ECS-optimierte AMIs (Amazon ECS-optimiertes Amazon Linux 2 AMI, Amazon ECS-optimiertes Amazon Linux 2 (arm64) AMI und Amazon ECS GPU-optimiertes AMI) mit einem einzigen 30-GiB-Root-Volume geliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte Amazon Linux 2-AMI ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
| **Amazon Linux 2** | Amazon-ECS-optimiertes Amazon-Linux-2-AMI | Dies ist für Ihre Amazon-ECS-Workloads. Das Amazon-ECS-optimierte Amazon Linux 2-AMI ist nicht mit dem AWS CLI vorinstalliert. | Standardmäßig wird das auf Amazon Linux 2 basierende Amazon ECS-optimierte AMIs (Amazon ECS-optimiertes Amazon Linux 2 AMI, Amazon ECS-optimiertes Amazon Linux 2 (arm64) AMI und Amazon ECS GPU-optimiertes AMI) mit einem einzigen 30-GiB-Root-Volume geliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte Amazon Linux 2-AMI ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
| **Amazon Linux 2 (arm64)** | Amazon-ECS-optimiertes Amazon Linux 2 (arm64) AMI mit Kernel 5.10 | Dieses AMI basiert auf Amazon Linux 2 und ist für Ihre Amazon EC2 EC2-Instances vorgesehen, die von ARM-basierten AWS Graviton/Graviton 2/Graviton 3/Graviton 4-Prozessoren angetrieben werden, und Sie möchten Linux-Kernel 5.10 anstelle von Linux-Kernel 4.14 für Ihre Amazon ECS-Workloads verwenden. Weitere Informationen finden Sie unter [Spezifikationen für Allzweck-Instances von Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html) im *Leitfaden zu Instance-Typen von Amazon EC2*. Das Amazon ECS-optimierte Amazon Linux 2 (arm64) AMI ist nicht vorinstalliert. AWS CLI | Standardmäßig wird das auf Amazon Linux 2 basierende Amazon ECS-optimierte AMIs (Amazon ECS-optimiertes Amazon Linux 2 AMI, Amazon ECS-optimiertes Amazon Linux 2 (arm64) AMI und Amazon ECS GPU-optimiertes AMI) mit einem einzigen 30-GiB-Root-Volume geliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte Amazon Linux 2-AMI ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
| Amazon Linux 2 (arm64) | Amazon-ECS-optimiertes Amazon Linux 2 (arm64) AMI | Dieses AMI basiert auf Amazon Linux 2 und wird verwendet, wenn Sie Ihre Amazon EC2 EC2-Instances, die von ARM-basierten AWS Graviton/Graviton 2/Graviton 3/Graviton 4-Prozessoren angetrieben werden, für Ihre Amazon ECS-Workloads starten. Das Amazon ECS-optimierte Amazon Linux 2 (arm64) AMI ist nicht vorinstalliert. AWS CLI | Standardmäßig wird das auf Amazon Linux 2 basierende Amazon ECS-optimierte AMIs (Amazon ECS-optimiertes Amazon Linux 2 AMI, Amazon ECS-optimiertes Amazon Linux 2 (arm64) AMI und Amazon ECS GPU-optimiertes AMI) mit einem einzigen 30-GiB-Root-Volume geliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte Amazon Linux 2-AMI ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
| **Amazon Linux 2 (GPU)** | GPU-optimiertes Kernel 5.10 AMI von Amazon ECS | Basierend auf Amazon Linux 2 wird dieses AMI zum Starten Ihrer GPU-basierten Amazon-EC2-Instances mit Linux Kernel 5.10 für Ihre Amazon-ECS-Workloads empfohlen. Es ist mit NVIDIA-Kerneltreibern und einer Docker-GPU-Laufzeit vorkonfiguriert, sodass Workloads ausgeführt werden können, die die Vorteile von GPUs Amazon ECS nutzen. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabendefinitionen für GPU-Workloads](ecs-gpu.md). | Standardmäßig wird das auf Amazon Linux 2 basierende Amazon ECS-optimierte AMIs (Amazon ECS-optimiertes Amazon Linux 2 AMI, Amazon ECS-optimiertes Amazon Linux 2 (arm64) AMI und Amazon ECS GPU-optimiertes AMI) mit einem einzigen 30-GiB-Root-Volume geliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte Amazon Linux 2-AMI ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
| Amazon Linux 2 (GPU) | Amazon-ECS-GPU-optimiertes AMI | Basierend auf Amazon Linux 2 wird dieses AMI zum Starten Ihrer GPU-basierten Amazon-EC2-Instances mit Linux Kernel 4.14 für Ihre Amazon-ECS-Workloads empfohlen. Es ist mit NVIDIA-Kerneltreibern und einer Docker-GPU-Laufzeit vorkonfiguriert, sodass Workloads ausgeführt werden können, die die Vorteile von GPUs Amazon ECS nutzen. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabendefinitionen für GPU-Workloads](ecs-gpu.md). | Standardmäßig wird das auf Amazon Linux 2 basierende Amazon ECS-optimierte AMIs (Amazon ECS-optimiertes Amazon Linux 2 AMI, Amazon ECS-optimiertes Amazon Linux 2 (arm64) AMI und Amazon ECS GPU-optimiertes AMI) mit einem einzigen 30-GiB-Root-Volume geliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte Amazon Linux 2-AMI ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
| Amazon Linux 2 (Neuron) | Amazon-ECS-optimiertes Amazon Linux 2 (Neuron) Kernel 5,10 AMI | Basierend auf Amazon Linux 2 ist dieses AMI für Amazon-EC2-Inf1-, Trn1- oder Inf2-Instances bestimmt. Es ist mit AWS Inferentia mit Linux-Kernel 5.10- und AWS Trainium-Treibern sowie der AWS Neuron-Runtime für Docker vorkonfiguriert, wodurch die Ausführung von Inferenz-Workloads für maschinelles Lernen auf Amazon ECS vereinfacht wird. Weitere Informationen finden Sie unter [Amazon ECS-Aufgabendefinitionen für AWS Neuron-Workloads für maschinelles Lernen](ecs-inference.md). Das für Amazon ECS optimierte Amazon Linux 2 (Neuron) AMI ist nicht AWS CLI vorinstalliert. | Standardmäßig wird das auf Amazon Linux 2 basierende Amazon ECS-optimierte AMIs (Amazon ECS-optimiertes Amazon Linux 2 AMI, Amazon ECS-optimiertes Amazon Linux 2 (arm64) AMI und Amazon ECS GPU-optimiertes AMI) mit einem einzigen 30-GiB-Root-Volume geliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte Amazon Linux 2-AMI ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
| Amazon Linux 2 (Neuron) | Amazon-ECS-optimiertes AMI für Amazon Linux 2 (Neuron) | Basierend auf Amazon Linux 2 ist dieses AMI für Amazon-EC2-Inf1-, Trn1- oder Inf2-Instances bestimmt. Es ist mit den Treibern AWS Inferentia und AWS Trainium sowie der AWS Neuron-Runtime für Docker vorkonfiguriert, wodurch die Ausführung von Inferenz-Workloads für maschinelles Lernen auf Amazon ECS vereinfacht wird. Weitere Informationen finden Sie unter [Amazon ECS-Aufgabendefinitionen für AWS Neuron-Workloads für maschinelles Lernen](ecs-inference.md). Das für Amazon ECS optimierte Amazon Linux 2 (Neuron) AMI ist nicht AWS CLI vorinstalliert. | Standardmäßig wird das auf Amazon Linux 2 basierende Amazon ECS-optimierte AMIs (Amazon ECS-optimiertes Amazon Linux 2 AMI, Amazon ECS-optimiertes Amazon Linux 2 (arm64) AMI und Amazon ECS GPU-optimiertes AMI) mit einem einzigen 30-GiB-Root-Volume geliefert. Sie können die Größe des 30-GiB-Root-Volumes zum Startzeitpunkt ändern, um den verfügbaren Speicherplatz auf Ihrer Container-Instance zu erhöhen. Dieser Speicher wird für das Betriebssystem sowie für Docker-Images und Metadaten verwendet. Das Standard-Dateisystem für das Amazon-ECS-optimierte Amazon Linux 2-AMI ist `xfs` und Docker verwendet den `overlay2`-Speichertreiber. Weitere Informationen finden Sie unter [Verwenden des OverlayFS-Speichertreibers](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) in der Docker-Dokumentation. |
Amazon ECS stellt ein Changelog für die Linux-Variante des Amazon ECS-optimierten AMI on bereit. GitHub Weitere Informationen finden Sie unter [Änderungsprotokoll](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md).
Die Linux-Varianten des für Amazon ECS optimierten AMI verwenden das Amazon Linux 2 AMI oder Amazon Linux 2023 AMI als Basis. Sie können den AMI-Namen für jede Variante kann durch Abfragen der API von Systems Manager Parameter Store abrufen. Weitere Informationen finden Sie unter [Abrufen der Amazon-ECS-optimierten Linux-AMI-Metadaten](retrieve-ecs-optimized_AMI.md). Die AMI-Versionshinweise von Amazon Linux 2 sind ebenfalls verfügbar. Weitere Informationen finden Sie in den [Versionshinweisen zu Amazon Linux 2](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html). Die Versionshinweise von Amazon Linux 2023 sind ebenfalls verfügbar. Weitere Informationen finden Sie in den [Versionshinweisen zu Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes.html).
Auf den folgenden Seiten finden Sie weitere Informationen zu den Änderungen:
+ [Quelle: AMI-Versionshinweise](https://github.com/aws/amazon-ecs-ami/releases) zu GitHub
+ [Versionshinweise für die Docker-Engine](https://docs.docker.com/engine/release-notes/) in der Docker-Dokumentation
+ [NVIDIA-Treiberdokumentation](https://docs.nvidia.com/datacenter/tesla/index.html) in der NVIDIA-Dokumentation
+ [Amazon ECS-Agent-Änderungsprotokoll aktiviert](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md) GitHub
Der Quellcode für die `ecs-init`-Anwendung sowie die Skripts und die Konfiguration für das Paketieren des Agenten sind jetzt Teil des Agent-Repositorys. Ältere Versionen von `ecs-init` und deren Verpackung finden Sie im [Amazon ecs-init](https://github.com/aws/amazon-ecs-init/blob/master/CHANGELOG.md) Changelog unter GitHub
## Anwenden von Sicherheitsupdates auf das Amazon-ECS-optimierte AMI
Die auf Amazon Linux AMIs basierenden Amazon ECS-optimierten Produkte enthalten eine angepasste Version von. cloud-init Cloud-initist ein Paket, das zum Bootstrapping von Linux-Images in einer Cloud-Computing-Umgebung und zum Ausführen der gewünschten Aktionen beim Starten einer Instance verwendet wird. Standardmäßig werden bei allen Amazon ECS-optimierten, auf Amazon Linux AMIs basierenden, vor dem 12. Juni 2024 veröffentlichten Sicherheitsupdates beim Start der Instance alle Sicherheitsupdates „Kritisch“ und „Wichtig“ angewendet.
Ab den auf Amazon Linux 2 AMIs basierenden Versionen von Amazon ECS-Optimized vom 12. Juni 2024 umfasst das Standardverhalten nicht mehr das Aktualisieren von Paketen beim Start. Stattdessen empfehlen wir Ihnen, auf ein neues Amazon-ECS-optimiertes AMI zu aktualisieren, sobald Versionen verfügbar sind. Die für Amazon ECS optimierten AMIs Versionen werden veröffentlicht, sobald Sicherheitsupdates oder grundlegende AMI-Änderungen verfügbar sind. Dadurch wird sichergestellt, dass Sie die neuesten Paketversionen und Sicherheitsupdates erhalten und dass die Paketversionen bei Instance-Starts unveränderlich sind. Weitere Informationen zum Abrufen der neuesten Amazon-ECS-optimierten AMIs finden Sie unter [Abrufen der Amazon-ECS-optimierten Linux-AMI-Metadaten](retrieve-ecs-optimized_AMI.md).
Wir empfehlen, Ihre Umgebung so zu automatisieren, dass sie auf ein neues AMI aktualisiert wird, sobald diese verfügbar sind. Informationen zu den verfügbaren Optionen finden Sie unter [Amazon ECS ermöglicht eine einfachere EC2-Kapazitätsverwaltung mit Managed Instance Draining](https://aws.amazon.com/blogs/containers/amazon-ecs-enables-easier-ec2-capacity-management-with-managed-instance-draining/).
Um weiterhin „Kritische“ und „Wichtige“ Sicherheitsupdates manuell auf eine AMI-Version anzuwenden, können Sie den folgenden Befehl auf der Amazon-EC2-Instance ausführen.
```
yum update --security
```
**Warnung**
Durch die Aktualisierung von Docker- containerd Containerd-Paketen werden alle laufenden Container auf dem Host gestoppt, was bedeutet, dass alle laufenden Amazon ECS-Aufgaben gestoppt werden. Planen Sie entsprechend, um Serviceunterbrechungen zu minimieren.
Wenn Sie Sicherheitsupdates beim Start wieder aktivieren möchten, können Sie beim Starten Ihrer Amazon-EC2-Instance die folgende Zeile zum `#cloud-config`-Abschnitt der cloud-init-Benutzerdaten hinzufügen. Weitere Informationen finden Sie unter [Verwendung von cloud-init in Amazon Linux 2](https://docs.aws.amazon.com/linux/al2/ug/amazon-linux-cloud-init.html) im *Benutzerhandbuch für Amazon Linux*.
```
#cloud-config
repo_upgrade: security
```
## Versionsgesperrte Pakete in einer Amazon ECS-optimierten GPU AL2023 AMIs
Bestimmte Pakete sind entscheidend für das korrekte, leistungsstarke Verhalten der GPU-Funktionalität in Amazon AL2023 ECS-optimierten GPUs. AMIs Dazu zählen:
+ NVIDIA-Treiber () `nvidia*`
+ Kernel-Module (`kmod*`)
+ NVIDIA-Bibliotheken (`libnvidia*`)
+ Kernel-Pakete (`kernel*`)
**Anmerkung**
Dies ist keine vollständige Liste. Die vollständige Liste der gesperrten Pakete ist verfügbar mit `dnf versionlock list`
Diese Pakete sind versionsgesperrt, um Stabilität zu gewährleisten und unbeabsichtigte Änderungen zu verhindern, die die GPU-Workloads stören könnten. Daher sollten diese Pakete im Allgemeinen im Rahmen eines verwalteten Prozesses geändert werden, der potenzielle Probleme ordnungsgemäß behandelt und die GPU-Funktionalität beibehält.
Um unbeabsichtigte Änderungen zu verhindern, wird das `dnf versionlock` Plugin für diese Pakete verwendet.
Wenn Sie ein gesperrtes Paket ändern möchten, können Sie:
```
# unlock a single package
sudo dnf versionlock delete $PACKAGE_NAME
# unlock all packages
sudo dnf versionlock clear
```
**Wichtig**
Wenn Updates für diese Pakete erforderlich sind, sollten Kunden erwägen, die neueste AMI-Version zu verwenden, die die erforderlichen Updates enthält. Wenn die Aktualisierung vorhandener Instances erforderlich ist, sollte ein sorgfältiger Ansatz zum Entsperren, Aktualisieren und erneuten Sperren von Paketen angewendet werden, wobei stets sicherzustellen ist, dass die GPU-Funktionalität während des gesamten Prozesses erhalten bleibt.
# Abrufen der Amazon-ECS-optimierten Linux-AMI-Metadaten
Sie können die Amazon-ECS-optimierten AMI-Metadaten programmgesteuert abrufen. Die Metadaten umfassen den AMI-Namen, die Version des Amazon-ECS-Container-Agent und die Amazon-ECS-Laufzeitversion, die die Docker-Version enthält.
Wenn Sie mit der Konsole einen Cluster erstellen, erstellt Amazon ECS eine Startvorlage für Ihre Instances mit dem neuesten AMI, das dem ausgewählten Betriebssystem zugeordnet ist.
Wenn Sie CloudFormation einen Cluster erstellen, ist der SSM-Parameter Teil der Amazon EC2 EC2-Startvorlage für die Auto Scaling Scaling-Gruppeninstanzen. Sie können die Vorlage so konfigurieren, dass ein dynamischer Systems-Manager-Parameter verwendet wird, um zu bestimmen, welches Amazon-ECS-optimierte AMI bereitgestellt werden soll. Dieser Parameter stellt sicher, dass der Stack bei jeder Bereitstellung überprüft, ob eine Aktualisierung verfügbar ist, die auf die EC2-Instances angewendet werden muss. Ein Beispiel für die Verwendung des Systems-Manager-Parameters finden Sie unter [Erstellen eines Amazon-ECS-Clusters mit dem Amazon-ECS-optimierten-AMI für Amazon Linux 2023](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) im *Benutzerhandbuch für AWS CloudFormation *.
Die AMI-ID, der Image-Name, das Betriebssystem, die Container-Agent-Version, der Quell-Image-Name und die Laufzeitversion für jede Variante des Amazon ECS-Optimized AMIs können programmgesteuert abgerufen werden, indem die Systems Manager Parameter Store-API abgefragt wird. Weitere Informationen zur Systems Manager Parameter Store-API finden Sie unter [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html)und [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html).
**Anmerkung**
Ihr administrativer Benutzer muss über die folgenden IAM-Berechtigungen verfügen, um die Amazon-ECS-optimierten AMI-Metadaten abzurufen. Diese Berechtigungen wurden der `AmazonECS_FullAccess`-IAM-Richtlinie hinzugefügt.
ssm: GetParameters
ssm: GetParameter
ssm: GetParametersByPath
## Systems Manager Parameterspeicher-Parameterformat
Im Folgenden ist das Format des Parameternamens für jede Amazon-ECS-optimierte AMI-Variante aufgeführt.
**Linux Amazon ECS-optimiert AMIs**
+ AMI-Metadaten für Amazon Linux 2023:
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/
```
+ AMI-Metadaten für Amazon Linux 2023 (arm64):
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/
```
+ AMI-Metadaten für Amazon Linux 2023 (Neuron):
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/
```
+ AMI-Metadaten für Amazon Linux 2023 (GPU):
```
/aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/
```
Amazon Linux 2-AMI Metadaten:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/
```
+ Amazon Linux 2 AMI-Metadaten mit Kernel 5.10:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/
```
+ Amazon Linux 2 (arm64) AMI-Metadaten:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/arm64/
```
+ Amazon Linux 2 (arm64) AMI-Metadaten mit Kernel 5.10:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/
```
+ Amazon-ECS-GPU-optimiertes Kernel 5.10 AMI – Metadaten:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/
```
+ Amazon Linux 2 (GPU) AMI-Metadaten:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/gpu/
```
+ Amazon-ECS-optimiertes Amazon Linux 2 (Neuron) Kernel 5,10 AMI – Metadaten:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/
```
+ AMI-Metadaten für Amazon Linux 2 (Neuron):
```
/aws/service/ecs/optimized-ami/amazon-linux-2/inf/
```
Das folgende Parameternamensformat ruft die Image-ID des neuesten empfohlenen Amazon-ECS-optimierten AMI für Amazon Linux 2 mit dem Sub-Parameter `image_id` ab.
```
/aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id
```
Das folgende Parameternamen-Format ruft die Metadaten einer bestimmten Amazon-ECS-optimierten AMI-Version ab, indem der AMI-Name angegeben wird.
+ Amazon-ECS-optimierte Amazon Linux 2-AMI Metadaten:
```
/aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20181112-x86_64-ebs
```
**Anmerkung**
Alle Versionen des Amazon-ECS-optimierten Amazon Linux 2-AMI stehen zum Abrufen bereit. Nur Amazon-ECS-optimierte AMI-Versionen `amzn-ami-2017.09.l-amazon-ecs-optimized` (Linux) und höher können abgerufen werden.
## Beispiele
Die folgenden Beispiele zeigen, wie Sie die Metadaten für jede Amazon-ECS-optimierte AMI-Variante abrufen können.
### Abrufen der Metadaten des neuesten empfohlenen Amazon-ECS-optimierten AMI
Sie können das neueste empfohlene Amazon ECS-optimierte AMI AWS CLI mit den folgenden AWS CLI Befehlen abrufen.
**Linux Amazon ECS-optimiert AMIs**
+ **Für das Amazon ECS-optimierte Amazon Linux 2023: AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended --region us-east-1
```
+ **Für das Amazon ECS-optimierte Amazon Linux 2023 (arm64): AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/recommended --region us-east-1
```
+ **Für das Amazon ECS-optimierte Amazon Linux 2023 (Neuron): AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended --region us-east-1
```
+ **Für die Amazon ECS-optimierte Amazon Linux 2023-GPU: AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/recommended --region us-east-1
```
+ **Für den Amazon ECS-optimierten Amazon Linux 2-Kernel 5.10: AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended --region us-east-1
```
+ **Für das Amazon ECS-optimierte Amazon Linux 2: AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended --region us-east-1
```
+ **Für den Amazon ECS-optimierten Amazon Linux 2-Kernel 5.10 (arm64): AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/recommended --region us-east-1
```
+ **Für das Amazon ECS-optimierte Amazon Linux 2 (arm64): AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/recommended --region us-east-1
```
+ **Für den GPU-optimierten Amazon ECS-Kernel 5.10: AMIs**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/recommended --region us-east-1
```
+ **Für das AMIs GPU-optimierte Amazon ECS:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
```
+ **Für den Amazon ECS-optimierten Amazon Linux 2 (Neuron) -Kernel AMIs 5.10:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/recommended --region us-east-1
```
+ **Für das Amazon ECS-optimierte Amazon Linux 2 (Neuron) AMIs:**
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/inf/recommended --region us-east-1
```
### Abrufen der Image-ID des neuesten empfohlenen Amazon-ECS-optimierten AMIs für Amazon Linux 2023
Sie können die Image-ID der aktuellen empfohlenen Amazon-ECS-optimierten AMI-ID für Amazon Linux 2023 mit dem Sub-Parameter `image_id` abrufen.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1
```
Um nur den `image_id`-Wert abzurufen, können Sie den spezifischen Parameterwert abzufragen, z. B.:
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```
### Abrufen der Metadaten einer bestimmten Amazon-ECS-optimierten Amazon Linux 2-AMI-Version
Rufen Sie mit dem folgenden AWS CLI Befehl die Metadaten einer bestimmten Amazon ECS-optimierten Amazon Linux AWS CLI AMI-Version ab. Ersetzen Sie den AMI-Namen durch den Namen des abzurufenden Amazon-ECS-optimierten Amazon Linux AMI.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20200928-x86_64-ebs --region us-east-1
```
### Abrufen der Amazon ECS-optimierten Amazon Linux 2-Kernel-5.10-AMI-Metadaten mithilfe der Systems Manager Manager-API GetParametersByPath
Rufen Sie die Amazon ECS-optimierten Amazon Linux 2-AMI-Metadaten mit der Systems Manager GetParametersByPath Manager-API ab, indem Sie den AWS CLI folgenden Befehl verwenden.
```
aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/ --region us-east-1
```
### Abrufen der Image-ID des neuesten empfohlenen Amazon-ECS-optimierten AMI für Amazon Linux 2 Kernel 5.10
Sie können die Image-ID des neuesten empfohlenen Amazon-ECS-optimierten AMI für Amazon Linux 2 Kernel 5.10 mit dem Sub-Parameter `image_id` abrufen.
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id --region us-east-1
```
Um nur den `image_id`-Wert abzurufen, können Sie den spezifischen Parameterwert abzufragen, z. B.:
```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```
### Verwenden des neuesten empfohlenen Amazon ECS-optimierten AMI in einer Vorlage CloudFormation
Sie können auf das neueste empfohlene Amazon-ECS-optimierte AMI in einer CloudFormation -Vorlage verweisen, indem Sie auf den Systems Manager Parameterspeichernamen verweisen.
**Linux-Beispiel**
```
Parameters:kernel-5.10
LatestECSOptimizedAMI:
Description: AMI ID
Type: AWS::SSM::Parameter::Value
Default: /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id
```
# Migration von einem Amazon-ECS-optimierten AMI für Amazon Linux 2 zu Amazon Linux 2023
Nach [Amazon Linux](https://aws.amazon.com/amazon-linux-2/faqs) beendet Amazon ECS die Standardunterstützung für Amazon Linux 2 Amazon ECS-Optimized mit AMIs Wirkung zum 30. Juni 2026. Nach diesem Datum wird die Amazon ECS-Agentenversion gepinnt und neue Amazon Linux 2 Amazon ECS-optimierte Versionen AMIs werden erst veröffentlicht, wenn das Amazon Linux 2-Quell-AMI aktualisiert wird. Complete End of Life (EOL) tritt am 30. Juni 2026 ein. Danach AMIs werden keine Amazon ECS-optimierten Amazon Linux 2 mehr veröffentlicht, auch wenn das Quell-AMI aktualisiert wird.
Amazon Linux 2023 bietet einen secure-by-default Ansatz mit vorkonfigurierten Sicherheitsrichtlinien SELinux im permissiven Modus, standardmäßig aktiviertem IMDSv2 Nur-Modus, optimierten Startzeiten und verbesserter Paketverwaltung für mehr Sicherheit und Leistung.
Es besteht ein hohes Maß an Kompatibilität zwischen Amazon Linux 2 und Amazon Linux 2023, die für Amazon ECS optimiert sind AMIs, und die meisten Kunden werden minimal-to-zero Änderungen ihrer Workloads zwischen den beiden Betriebssystemen feststellen.
Weitere Informationen finden Sie unter [Vergleich von Amazon Linux 2 und *Amazon Linux 2023*](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) im *Amazon Linux 2023 Benutzerhandbuch* und in [AL2023 FAQs](https://aws.amazon.com/linux/amazon-linux-2023/faqs).
## Erwägungen zur Kompatibilität
### Paketverwaltung und Betriebssystem-Updates
Im Gegensatz zu früheren Versionen von Amazon Linux ist Amazon ECS-optimiertes Amazon Linux 2023 AMIs an eine bestimmte Version des Amazon Linux-Repositorys gebunden. Dies schützt Benutzer vor dem versehentlichen Aktualisieren von Paketen, das zu unerwünschten oder schwerwiegenden Änderungen führen könnten. Weitere Informationen finden Sie unter [Verwaltung von Repositorys und Betriebssystem-Updates in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) im *Benutzerhandbuch für Amazon Linux 2023*.
### Linux-Kernel-Versionen
Amazon Linux 2 AMIs basiert auf den Linux-Kerneln 4.14 und 5.10, während Amazon Linux 2023 die Linux-Kernel 6.1 und 6.12 verwendet. Weitere Informationen finden Sie unter [Vergleich von Amazon Linux 2 und Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2-kernel.html) im *Benutzerhandbuch für Amazon Linux 2023*.
### Änderungen der Paketverfügbarkeit
Im Folgenden finden Sie wichtige Paketänderungen in Amazon Linux 2023:
+ Einige Quell-Binärpakete in Amazon Linux 2 sind in Amazon Linux 2023 nicht mehr verfügbar Weitere Informationen finden Sie unter [Aus Amazon Linux 2023 entfernte Pakete](https://docs.aws.amazon.com/linux/al2023/release-notes/removed.html) in den *Versionshinweisen zu Amazon Linux 2023*.
+ Änderungen in der Art und Weise, wie Amazon Linux verschiedene Versionen von Paketen unterstützt. Das in Amazon Linux 2 verwendete `amazon-linux-extras`-System ist in Amazon Linux 2023 nicht vorhanden. Alle Pakete sind einfach im „Core“-Repository verfügbar.
+ Extra-Pakete für Enterprise Linux (EPEL) werden in Amazon Linux 2023 nicht unterstützt Weitere Informationen finden Sie unter [EPEL-Kompatibilität in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/epel.html) im *Benutzerhandbuch für Amazon Linux 2023*.
+ 32-bit-Anwendungen werden in Amazon Linux 2023 nicht unterstützt Weitere Informationen finden Sie unter [Veraltete Features von Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2.html#deprecated-32bit-rpms) im *Benutzerhandbuch für Amazon Linux 2023*.
### Änderungen an Kontrollgruppen (cgroups)
Eine Kontrollgruppe (cgroup) ist ein Linux-Kernel-Feature zur hierarchischen Organisation von Prozessen und zur Verteilung von entsprechenden Systemressourcen. Kontrollgruppen werden häufig zur Implementierung einer Container-Laufzeit und von `systemd` verwendet.
Der Amazon-ECS-Agent, Docker und containerd unterstützen alle sowohl cgroupv1 als auch cgroupv2. Der Amazon-ECS-Agent und die Container-Laufzeit verwalten cgroups für Sie, sodass Amazon-ECS-Kunden keine Änderungen für diese zugrunde liegende Aufrüstung auf cgroup vornehmen müssen.
Weitere Informationen zu cgroupv2 finden Sie unter [Control Groups v2 in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/cgroupv2.html) im *Benutzerhandbuch für Amazon Linux 2023*.
### Änderungen in Instance Metadata Service (IMDS)
Amazon Linux 2023 erfordert standardmäßig Instance Metadata Service Version 2 (IMDSv2). IMDSv2 bietet mehrere Vorteile, die zur Verbesserung der Sicherheitslage beitragen. Das Programm verwendet eine sitzungsorientierte Authentifizierungsmethode, die die Erstellung eines geheimen Tokens in einer einfachen HTTP-PUT-Anfrage zum Starten der Sitzung erfordert. Die Gültigkeitsdauer eines Sitzungs-Tokens kann zwischen 1 Sekunde und 6 Stunden variieren.
Weitere Informationen zum Übergang von IMDSv1 zu IMDSv2 finden Sie unter Umstellung auf die [Verwendung von Instance Metadata Service Version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
Wenn Sie dies verwenden möchten, können Sie dies dennoch tun IMDSv1, indem Sie die Einstellungen mithilfe der Starteigenschaften der Instance-Metadatenoption manuell überschreiben.
### Änderungen der Speicherauslagerung
Speicherauslagerungen pro Container werden unter Amazon Linux 2023 und cgroups v2 nicht unterstützt. Weitere Informationen finden Sie unter [Verwaltung des Container-Auslagerungsspeicherplatzes in Amazon ECS](container-swap.md).
### FIPS-Validierungsänderungen
Amazon Linux 2 ist nach FIPS 140-2 zertifiziert und Amazon Linux 2023 ist nach FIPS 140-3 zertifiziert.
Um den FIPS-Modus in Amazon Linux 2023 zu aktivieren, installieren Sie die erforderlichen Pakete auf Ihrer Amazon-EC2-Instance und befolgen Sie die Konfigurationsschritte anhand der Anweisungen unter [Aktivieren des FIPS-Modus in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html) im *Benutzerhandbuch für Amazon Linux 2023*.
### Beschleunigte Instance-Unterstützung
Das für Amazon ECS optimierte Amazon Linux 2023 AMIs unterstützt sowohl Neuron- als auch GPU-beschleunigte Instance-Typen. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md).
## Benutzerdefiniert erstellen AMIs
Wir empfehlen zwar, zu offiziell unterstütztem und veröffentlichtem Amazon ECS-Optimized AMIs for Amazon Linux 2023 zu wechseln, aber Sie können weiterhin benutzerdefinierte Amazon Linux 2 Amazon ECS-Optimized AMIs mit den Open-Source-Build-Skripten erstellen, die zur Erstellung der Linux-Varianten des Amazon ECS-optimierten AMI verwendet werden. Weitere Informationen finden Sie unter [Amazon-ECS-optimiertes Linux-AMI-Entwicklungsskript](ecs-ami-build-scripts.md).
## Migrationsstrategien
Wir empfehlen, einen Migrationsplan zu erstellen und umzusetzen, der gründliche Anwendungstests beinhaltet. In den folgenden Abschnitten werden verschiedene Migrationsstrategien beschrieben, entsprechend der Art, wie Sie Ihre Amazon-ECS-Infrastruktur verwalten.
### Migration mit Amazon-ECS-Kapazitätsanbietern
1. Erstellen Sie einen neuen Kapazitätsanbieter mit einer neuen Startvorlage. Dies sollte auf eine Auto-Scaling-Gruppe mit einer Startvorlage verweisen, die Ihrer vorhandenen ähnelt, aber anstelle des Amazon-ECS-optimierten AMI für Amazon Linux 2 sollte es eine der Varianten für Amazon Linux 2023 angeben. Fügen Sie diesen neuen Kapazitätsanbieter zu Ihrem bestehenden Amazon-ECS-Cluster hinzu.
1. Aktualisieren Sie die standardmäßige Kapazitätsanbieter-Strategie Ihres Clusters, sodass sie sowohl den bestehenden Kapazitätsanbieter von Amazon Linux 2 als auch den neuen Kapazitätsanbieter von Amazon Linux 2023 einbezieht. Beginnen Sie mit einer höheren Gewichtung für den Kapazitätsanbieter von Amazon Linux 2 und einer geringeren Gewichtung beim Kapazitätsanbieter von Amazon Linux 2023 (z. B. Amazon Linux 2: Gewicht 80, Amazon Linux 2023: Gewicht 20). Dies veranlasst Amazon ECS, mit der Bereitstellung von Amazon-Linux-2023-Instances zu beginnen, sobald neue Aufgaben geplant sind. Stellen Sie sicher, dass die Instances korrekt registriert wurden und dass die Aufgaben auf den neuen Instances erfolgreich ausgeführt werden können.
1. Passen Sie die Gewichtung der Kapazitätsanbieter in der Standardstrategie Ihres Clusters schrittweise an, indem Sie die Gewichtung für den Anbieter von Amazon Linux 2023 erhöhen und gleichzeitig die Gewichtung des Anbieters für Amazon Linux 2 schrittweise verringern (z. B. 60/40, dann 40/60, dann 20/80). Sie können auch die Strategien einzelner Service-Kapazitätsanbieter aktualisieren, um Amazon-Linux-2023-Instances zu priorisieren. Überwachen Sie die Aufgabenverteilung, um sicherzustellen, dass sie erfolgreich auf Amazon-Linux-2023-Instances ausgeführt werden.
1. Sie können optional Container-Instances von Amazon Linux 2 ausgleichen, um die Aufgabenmigration zu beschleunigen. Wenn Sie über ausreichend Ersatzkapazität für Amazon Linux 2023 verfügen, können Sie Ihre Amazon Linux 2-Container-Instances manuell über die Amazon ECS-Konsole entladen oder AWS CLI um den Übergang Ihrer Aufgaben von Amazon Linux 2 zu Amazon Linux 2023 zu beschleunigen. Nachdem die Migration abgeschlossen ist, entfernen Sie den Kapazitätsanbieter von Amazon Linux 2 aus Ihrem Cluster und löschen Sie die zugehörige Auto-Scaling-Gruppe.
### Migrieren mit einer Amazon-EC2-Auto-Scaling-Gruppe
1. Erstellen Sie eine neue Amazon-EC2-Auto-Scaling-Gruppe mit einer neuen Startvorlage. Diese sollte Ihrer vorhandenen Startvorlage ähneln, sollte jedoch anstelle des Amazon-ECS-optimierten AMI für Amazon Linux 2 eine der Varianten für Amazon Linux 2023 angeben. Diese neue Auto-Scaling-Gruppe kann Instances in Ihrem vorhandenen Cluster starten.
1. Skalieren Sie die Auto Scaling-Gruppe hoch, sodass Amazon-Linux-2023-Instances damit beginnen, sich in Ihrem Cluster zu registrieren. Stellen Sie sicher, dass die Instances korrekt registriert wurden und dass die Aufgaben auf den neuen Instances erfolgreich ausgeführt werden können.
1. Nachdem bestätigt wurde, dass Ihre Aufgaben unter Amazon Linux 2023 funktionieren, skalieren Sie die Auto-Scaling-Gruppe von Amazon Linux 2023 hoch und skalieren Sie gleichzeitig die Auto-Scaling-Gruppe von Amazon Linux 2 schrittweise herunter, bis Sie alle Instances von Amazon Linux 2 vollständig ersetzt haben.
1. Wenn Sie über ausreichend Ersatzkapazität für Amazon Linux 2023 verfügen, sollten Sie die Container-Instances möglicherweise explizit ausgleichen, um den Übergang Ihrer Aufgaben von Amazon Linux 2 zu Amazon Linux 2023 zu beschleunigen. Weitere Informationen finden Sie unter [Entlastung von Amazon-ECS-Container-Instances](container-instance-draining.md).
### Migration mit manuell verwalteten Instances
1. Starten Sie manuell (oder passen Sie die Startskripts an) neue Amazon-EC2-Instances mit dem Amazon-ECS-optimierten AMI für Amazon Linux 2023 anstelle von Amazon Linux 2. Stellen Sie sicher, dass diese Instances dieselben Sicherheitsgruppen, Subnetze, IAM-Rollen und Cluster-Konfigurationen verwenden wie Ihre bestehenden Amazon-Linux-2-Instances. Die Instances sollten sich beim Start automatisch in Ihrem vorhandenen Amazon-ECS-Cluster registrieren.
1. Stellen Sie sicher, dass die neuen Amazon-Linux-2023-Instances erfolgreich in Ihrem Amazon-ECS-Cluster registriert wurden und sich in einem `ACTIVE`-Status befinden. Testen Sie, ob Aufgaben auf diesen neuen Instances ordnungsgemäß geplant und ausgeführt werden können, indem Sie entweder auf die natürliche Aufgabenverteilung warten oder stopping/starting einige Aufgaben manuell ausführen, um eine Neuplanung auszulösen.
1. Ersetzen Sie Ihre Amazon-Linux-2-Instances schrittweise, indem Sie nach Bedarf weitere Amazon-Linux-2023-Instances starten und dann die Amazon-Linux-2-Instances nacheinander manuell entlasten und beenden. Sie können Instances über die Amazon-ECS-Konsole ausgleichen, indem Sie die Instance auf den `DRAINING`-Status setzen. Dadurch werden der Instance keine neuen Aufgaben mehr zugewiesen und bestehende Aufgaben können abgeschlossen oder an anderer Stelle verschoben werden.
# Amazon-ECS-optimiertes Linux-AMI-Entwicklungsskript
Amazon ECS hat die Entwicklungsskripts, die zum Erstellen der Linux-Varianten des Amazon-ECS-optimierten AMI verwendet werden, als Open Source bereitgestellt. Diese Build-Skripts sind jetzt auf GitHub verfügbar. Weitere Informationen finden Sie [amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami)unter GitHub.
Wenn Sie das Amazon ECS-optimierte AMI anpassen müssen, finden Sie weitere Informationen unter [Amazon ECS Optimized AMI Build Recipies](https://github.com/aws/amazon-ecs-ami) auf. GitHub
Das Build-Skripts-Repository enthält eine [HashiCorpPacker-Vorlage](https://developer.hashicorp.com/packer/docs) und Build-Skripte zur Generierung der einzelnen Linux-Varianten des Amazon ECS-optimierten AMI. Diese Skripts sind die Informationsquelle für Amazon ECS-optimierte AMI-Builds, sodass Sie dem GitHub Repository folgen können, um Änderungen an unseren zu überwachen. AMIs Beispielsweise möchten Sie vielleicht, dass Ihr eigenes AMI dieselbe Version von Docker nutzt, die das Amazon-ECS-Team für das offizielle AMI verwendet.
Weitere Informationen finden Sie im Amazon ECS AMI-Repository unter [aws/on amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami). GitHub
**So erstellen Sie ein Amazon-ECS-optimiertes Linux-AMI**
1. Klonen Sie das Repo `aws/amazon-ecs-ami` GitHub .
```
git clone https://github.com/aws/amazon-ecs-ami.git
```
1. Fügen Sie eine Umgebungsvariable für die AWS Region hinzu, die bei der Erstellung des AMI verwendet werden soll. Ersetzen Sie den `us-west-2`-Wert durch die zu verwendende Region.
```
export REGION=us-west-2
```
1. Zur Entwicklung des AMIs wird ein Makefile bereitgestellt. Verwenden Sie aus dem Stammverzeichnis des geklonten Repositorys einen der folgenden Befehle, der der Linux-Variante des Amazon-ECS-optimierten AMI entspricht, das Sie erstellen möchten.
+ Amazon-ECS-optimiertes Amazon Linux 2-AMI
```
make al2
```
+ Amazon-ECS-optimiertes Amazon Linux 2 (arm64) AMI
```
make al2arm
```
+ Amazon-ECS-GPU-optimiertes AMI
```
make al2gpu
```
+ Amazon-ECS-optimiertes AMI für Amazon Linux 2 (Neuron)
```
make al2inf
```
+ Amazon-ECS-optimiertes AMI für Amazon Linux 2023
```
make al2023
```
+ Amazon-ECS-optimiertes AMI für Amazon Linux 2023 (arm64)
```
make al2023arm
```
+ Amazon ECS-optimiertes Amazon Linux 2023 GPU-AMI
```
make al2023gpu
```
+ Amazon-ECS-optimiertes AMI für Amazon Linux 2023 (Neuron)
```
make al2023neu
```
# Amazon ECS-optimiert Bottlerocket AMIs
Bottlerocketist ein Linux Open-Source-Betriebssystem, das speziell AWS für den Betrieb von Containern auf virtuellen Maschinen oder Bare-Metal-Hosts entwickelt wurde. Das Amazon-ECS-optimierte Bottlerocket-AMI ist sicher und enthält nur die Mindestanzahl an Paketen, die zum Ausführen von Containern erforderlich ist. Dies verbessert die Ressourcennutzung, reduziert die Angriffsfläche für Sicherheitsangriffe und trägt zur Senkung des Verwaltungsaufwands bei. Das Bottlerocket-AMI ist auch in Amazon ECS integriert, um den betrieblichen Aufwand zu reduzieren, der mit der Aktualisierung von Container-Instances in einem Cluster verbunden ist.
Bottlerocket unterscheidet sich auf folgende Weise von Amazon Linux:
+ Bottlerocket enthält keinen Paketmanager und die zugehörige Software kann nur als Container ausgeführt werden. Aktualisierungen von Bottlerocket werden in einem einzigen Schritt durchgeführt und können wieder rückgängig gemacht werden, wodurch die Wahrscheinlichkeit von Aktualisierungsfehlern verringert wird.
+ Der primäre Mechanismus zur Verwaltung von Bottlerocket-Hosts ist ein Container-Scheduler. Im Gegensatz zu Amazon Linux ist die Anmeldung bei einzelnen Bottlerocket-Instances nur selten und nur für erweiterte Debugging- und Fehlerbehebungszwecke vorgesehen.
Weitere Informationen zu Bottlerocket finden Sie in der [Dokumentation](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) und den [Releases](https://github.com/bottlerocket-os/bottlerocket/releases) auf GitHub.
Es gibt Varianten des Amazon-ECS-optimierten Bottlerocket-AMI für Kernel 6.1 und Kernel 5.10.
Die folgenden Varianten verwenden Kernel 6.1:
+ `aws-ecs-2`
+ `aws-ecs-2-nvidia`
Die folgenden Varianten verwenden Kernel 5.10:
+ `aws-ecs-1`
+ `aws-ecs-1-nvidia`
Weitere Informationen über die `aws-ecs-1-nvidia`-Variante finden Sie unter [Ankündigung der NVIDIA-GPU-Unterstützung für Bottlerocket auf Amazon ECS](https://aws.amazon.com/blogs/containers/announcing-nvidia-gpu-support-for-bottlerocket-on-amazon-ecs/).
## Überlegungen
Beachten Sie Folgendes, wenn Sie ein Bottlerocket-AMI mit Amazon ECS verwenden.
+ Bottlerocket unterstützt Amazon-EC2-Instances mit `x86_64`- und `arm64`-Prozessoren. Die Bottlerocket-AMI wird nicht für die Verwendung mit Amazon-EC2-Instances mit einem Inferentia-Chip empfohlen.
+ Bottlerocket-Images enthalten keine SSH-Server oder Shell. Sie können jedoch out-of-band Verwaltungstools verwenden, um SSH-Administratorzugriff zu erhalten und Bootstrapping durchzuführen.
Weitere Informationen finden Sie in diesen Abschnitten im [bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket) auf GitHub:
+ [Exploration](https://github.com/bottlerocket-os/bottlerocket#exploration) (Erkundung)
+ [Administrator-Container](https://github.com/bottlerocket-os/bottlerocket#admin-container)
+ Standardmäßig hat Bottlerocket einen [Steuerungs-Container](https://github.com/bottlerocket-os/bottlerocket-control-container), der aktiviert ist. Dieser Container führt den [AWS Systems Manager -Agenten](https://github.com/aws/amazon-ssm-agent) aus, den Sie verwenden können, um Befehle auszuführen oder Shell-Sitzungen auf Amazon-EC2-Bottlerocket-Instances zu starten. Weitere Informationen finden Sie unter [Session Manager einrichten](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) im *AWS Systems Manager -Benutzerhandbuch*.
+ Bottlerocket ist für Container-Workloads optimiert und konzentriert sich auf Sicherheit. Bottlerocket enthält keinen Paketmanager und ist unveränderlich.
Informationen zu den Sicherheitsfunktionen und Anleitungen finden Sie unter [Sicherheitsfunktionen](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_FEATURES.md) und [Sicherheitsrichtlinien](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_GUIDANCE.md) von. GitHub
+ Der `awsvpc`-Netzwerkmodus wird für Bottlerocket AMI Version `1.1.0` oder höher unterstützt.
+ App Mesh in einer Aufgabendefinition wird für die Bottlerocket-AMI-Version `1.15.0` oder höher unterstützt.
+ Der Aufgabendefinitionsparameter `initProcessEnabled` wird für das Bottlerocket-AMI Version `1.19.0` oder höher unterstützt.
+ Sie unterstützen Bottlerocket AMIs auch nicht die folgenden Dienste und Funktionen:
+ ECS Anywhere
+ Service Connect
+ Amazon EFS im verschlüsselten Modus
+ Amazon EFS im `awsvpc` Netzwerkmodus
+ Amazon-EBS-Volumes können nicht bereitgestellt werden
+ Elastic-Inference-Beschleuniger
# Abrufen der Metadaten des Amazon-ECS-optimierten Bottlerocket-AMI
Sie können die Amazon Machine Image (AMI) -ID für Amazon ECS-Optimized abrufen, AMIs indem Sie die AWS Systems Manager Parameter Store-API abfragen. Mit diesem Parameter müssen Sie Amazon ECS-optimiertes AMI nicht manuell suchen. IDs Weitere Informationen zur Systems Manager Parameter Store-API finden Sie unter [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). Der von Ihnen verwendete Benutzer muss über die `ssm:GetParameter`-IAM-Berechtigung zum Abrufen der Amazon-EKS-optimierten AMI-Metadaten verfügen.
## `aws-ecs-2` Bottlerocket AMI-Variante
Sie können die neueste stabile `aws-ecs-2` Bottlerocket-AMI-Variante nach AWS-Region und Architektur mit dem oder dem AWS CLI abrufen. AWS-Managementkonsole
+ **AWS CLI**— Sie können die Image-ID des neuesten empfohlenen Amazon ECS-optimierten Bottlerocket AMIs mit dem folgenden AWS CLI Befehl abrufen, indem Sie den Unterparameter verwenden. `image_id` Ersetzen Sie den `region` durch den Regionalcode, für den Sie die AMI-ID benötigen.
Informationen zu den unterstützten [finden Sie AWS-Regionen unter Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) on GitHub. Um eine andere Version als die neueste abzurufen, ersetzen Sie`latest` mit der Versionsnummer.
+ Für die 64-Bit-(`x86_64`)-Architektur:
```
aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ Für die 64 Bit Arm (`arm64`)-Architektur:
```
aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS-Managementkonsole** – Sie können die empfohlene Amazon-ECS-optimierte AMI-ID mithilfe einer URL in der AWS-Managementkonsole abfragen. Die URL öffnet die Amazon-EC2-Systems-Manager-Konsole mit dem Wert der ID für den Parameter. Ersetzen Sie in der folgenden URL `region` durch den Regionalcode, für den Sie die AMI-ID benötigen.
Informationen zu den unterstützten [finden Sie AWS-Regionen unter Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) on GitHub.
+ Für die 64-Bit-(`x86_64`)-Architektur:
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id/description?region=region#
```
+ Für die 64 Bit Arm (`arm64`)-Architektur:
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id/description?region=region#
```
## `aws-ecs-2-nvidia` Bottlerocket AMI-Variante
Sie können die neueste stabile `aws-ecs-2-nvdia` Bottlerocket-AMI-Variante nach Region und Architektur mit dem oder dem AWS CLI abrufen. AWS-Managementkonsole
+ **AWS CLI**— Sie können die Image-ID des neuesten empfohlenen Amazon ECS-optimierten Bottlerocket AMIs mit dem folgenden AWS CLI Befehl abrufen, indem Sie den Unterparameter verwenden. `image_id` Ersetzen Sie den `region` durch den Regionalcode, für den Sie die AMI-ID benötigen.
Informationen zu den unterstützten [finden Sie AWS-Regionen unter Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) on GitHub. Um eine andere Version als die neueste abzurufen, ersetzen Sie`latest` mit der Versionsnummer.
+ Für die 64-Bit-(`x86_64`)-Architektur:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ Für die 64 Bit Arm (`arm64`)-Architektur:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS-Managementkonsole** – Sie können die empfohlene Amazon-ECS-optimierte AMI-ID mithilfe einer URL in der AWS-Managementkonsole abfragen. Die URL öffnet die Amazon-EC2-Systems-Manager-Konsole mit dem Wert der ID für den Parameter. Ersetzen Sie in der folgenden URL `region` durch den Regionalcode, für den Sie die AMI-ID benötigen.
Informationen zu den unterstützten [finden Sie AWS-Regionen unter Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) on GitHub.
+ Für die 64 Bit (`x86_64`)-Architektur:
```
https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id/description?region=region#
```
+ Für die 64 Bit Arm (`arm64`)-Architektur:
```
https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id/description?region=region#
```
## `aws-ecs-1` Bottlerocket AMI-Variante
Sie können die neueste stabile `aws-ecs-1` Bottlerocket-AMI-Variante nach AWS-Region und Architektur mit dem oder dem AWS CLI abrufen. AWS-Managementkonsole
+ **AWS CLI**— Sie können die Image-ID des neuesten empfohlenen Amazon ECS-optimierten Bottlerocket AMIs mit dem folgenden AWS CLI Befehl abrufen, indem Sie den Unterparameter verwenden. `image_id` Ersetzen Sie den `region` durch den Regionalcode, für den Sie die AMI-ID benötigen.
Informationen zu den unterstützten [finden Sie AWS-Regionen unter Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) on GitHub. Um eine andere Version als die neueste abzurufen, ersetzen Sie`latest` mit der Versionsnummer.
+ Für die 64-Bit-(`x86_64`)-Architektur:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ Für die 64 Bit Arm (`arm64`)-Architektur:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS-Managementkonsole** – Sie können die empfohlene Amazon-ECS-optimierte AMI-ID mithilfe einer URL in der AWS-Managementkonsole abfragen. Die URL öffnet die Amazon-EC2-Systems-Manager-Konsole mit dem Wert der ID für den Parameter. Ersetzen Sie in der folgenden URL `region` durch den Regionalcode, für den Sie die AMI-ID benötigen.
Informationen zu den unterstützten [finden Sie AWS-Regionen unter Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) on GitHub.
+ Für die 64-Bit-(`x86_64`)-Architektur:
```
https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id/description
```
+ Für die 64 Bit Arm (`arm64`)-Architektur:
```
https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id/description
```
## `aws-ecs-1-nvidia` Bottlerocket AMI-Variante
Sie können die neueste stabile `aws-ecs-1-nvdia` Bottlerocket-AMI-Variante nach Region und Architektur mit dem oder dem AWS CLI abrufen. AWS-Managementkonsole
+ **AWS CLI**— Sie können die Image-ID des neuesten empfohlenen Amazon ECS-optimierten Bottlerocket AMIs mit dem folgenden AWS CLI Befehl abrufen, indem Sie den Unterparameter verwenden. `image_id` Ersetzen Sie den `region` durch den Regionalcode, für den Sie die AMI-ID benötigen.
Informationen zu den unterstützten [finden Sie AWS-Regionen unter Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) on GitHub.
+ Für die 64-Bit-(`x86_64`)-Architektur:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
```
+ Für die 64 Bit Arm (`arm64`)-Architektur:
```
aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
```
+ **AWS-Managementkonsole** – Sie können die empfohlene Amazon-ECS-optimierte AMI-ID mithilfe einer URL in der AWS-Managementkonsole abfragen. Die URL öffnet die Amazon-EC2-Systems-Manager-Konsole mit dem Wert der ID für den Parameter. Ersetzen Sie in der folgenden URL `region` durch den Regionalcode, für den Sie die AMI-ID benötigen.
Informationen zu den unterstützten [finden Sie AWS-Regionen unter Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) on GitHub.
+ Für die 64 Bit (`x86_64`)-Architektur:
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id/description?region=region#
```
+ Für die 64 Bit Arm (`arm64`)-Architektur:
```
https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id/description?region=region#
```
## Nächste Schritte
Ein ausführliches Tutorial zu den ersten Schritten mit dem Bottlerocket Betriebssystem auf Amazon ECS finden Sie unter [Using a Bottlerocket AMI with Amazon ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) on GitHub und [Getting started with Bottlerocket and Amazon ECS](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/) auf der AWS Blogseite.
Informationen zum Starten einer Bottlerocket-Instance finden Sie unter [Starten einer Bottlerocket-Instance für Amazon ECS](bottlerocket-launch.md).
# Starten einer Bottlerocket-Instance für Amazon ECS
Sie können eine Bottlerocket-Instance starten, damit Sie Ihre Container-Workloads ausführen können.
Sie können den verwenden AWS CLI , um die Bottlerocket Instance zu starten.
1. Erstellen Sie eine Datei mit dem Namen `userdata.toml`. Diese Datei wird für Instance-Benutzerdaten verwendet. Ersetzen Sie *cluster-name* mit dem Namen Ihres Clusters.
```
[settings.ecs]
cluster = "cluster-name"
```
1. Verwenden Sie einen der Befehle, die in [Abrufen der Metadaten des Amazon-ECS-optimierten Bottlerocket-AMI](ecs-bottlerocket-retrieve-ami.md) enthalten sind, um die Bottlerocket-AMI-ID abzurufen. Sie verwenden dies im folgenden Schritt.
1. Führen Sie den folgenden Befehl aus, um die Bottlerocket-Instance zu starten. Denken Sie daran, die folgenden Parameter zu ersetzen:
+ *subnet*Ersetzen Sie es durch die ID des privaten oder öffentlichen Subnetzes, in dem Ihre Instance gestartet wird.
+ *bottlerocket\$1ami*Ersetzen Sie durch die AMI-ID aus dem vorherigen Schritt.
+ *t3.large*Ersetzen Sie durch den Instance-Typ, den Sie verwenden möchten.
+ *region*Ersetzen Sie durch den Regionalcode.
```
aws ec2 run-instances --key-name ecs-bottlerocket-example \
--subnet-id subnet \
--image-id bottlerocket_ami \
--instance-type t3.large \
--region region \
--tag-specifications 'ResourceType=instance,Tags=[{Key=bottlerocket,Value=example}]' \
--user-data file://userdata.toml \
--iam-instance-profile Name=ecsInstanceRole
```
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Container-Instance im Cluster registriert ist. Denken Sie beim Ausführen dieses Befehls daran, die folgenden Parameter zu ersetzen:
+ Ersetzen Sie *cluster* mit Ihrem Clusternamen.
+ *region*Ersetzen Sie es durch Ihren Regionalcode.
```
aws ecs list-container-instances --cluster cluster-name --region region
```
Eine ausführliche Anleitung zu den ersten Schritten mit dem Bottlerocket Betriebssystem auf Amazon ECS finden Sie unter [Using a Bottlerocket AMI with Amazon ECS on and Getting started with Amazon ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) on GitHub und Getting started with [Bottlerocketand Amazon ECS auf der Blogseite](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/). AWS
# Verwaltung von Linux-Container-Instances in Amazon ECS
Wenn Sie EC2-Instances für Ihre Amazon-ECS-Workloads verwenden, sind Sie für die Wartung der Instances verantwortlich.
**Topics**
+ [Starten einer Container-Instance](launch_container_instance.md)
+ [Bootstrapping von Linux-Container-Instances](bootstrap_container_instance.md)
+ [Konfiguration von Container-Instances für den Empfang von Spot-Instance-Benachrichtigungen](spot-instance-draining-linux-container.md)
+ [Ausführen eines Skripts beim Starten einer Container-Instance](start_task_at_launch.md)
+ [
# Erhöhung der Netzwerkschnittstellen für Linux-Container-Instances von Amazon ECS
](container-instance-eni.md)
+ [Arbeitsspeicher für Container-Instances reservieren](memory-management.md)
+ [Remote-Verwaltung von Container-Instances](ec2-run-command.md)
+ [Verwenden eines HTTP-Proxys für Linux-Container-Instances](http_proxy_config.md)
+ [Konfiguration vorinitialisierter Instances für Ihre Auto-Scaling-Gruppe](using-warm-pool.md)
+ [
# Überprüfen des Amazon-ECS-Container-Agenten
](ecs-agent-update.md)
Jede Amazon-ECS-Container-Agenten-Version unterstützt unterschiedliche Features und bietet Fehlerbehebungen aus früheren Versionen. Wir empfehlen grundsätzlich, die neueste Version des Amazon-ECS-Container-Agenten zu verwenden, wenn dies möglich ist. Die neueste Version für Ihren Container-Agenten finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
[Informationen darüber, welche Funktionen und Verbesserungen in den einzelnen Agent-Versionen enthalten sind, finden Sie unter /releases. https://github.com/aws/ amazon-ecs-agent](https://github.com/aws/amazon-ecs-agent/releases)
**Wichtig**
Die Mindestversion von Docker für zuverlässige Metriken ist die Docker-Version `v20.10.13` und neuer, die in Amazon-ECS-optimiertem AMI `20220607` und neuer enthalten ist.
Die Amazon-ECS-Agent-Versionen `1.20.0` und neuer haben die Unterstützung für Docker-Versionen älter als `18.01.0` eingestellt.
# Starten einer Amazon ECS Linux-Container-Instance
Sie können Amazon-ECS-Container-Instances mit der Amazon-EC2-Konsole erstellen.
Sie können eine Instance mit verschiedenen Methoden starten, einschließlich der Amazon EC2 EC2-Konsole und dem SDK. AWS CLI Informationen zu den weiteren Methoden für das Starten einer Instance finden Sie unter [Starten einer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html) im *Amazon-EC2-Benutzerhandbuch*.
Weitere Informationen zum Startassistenten finden Sie unter [Starten einer Instance mit dem neuen Launch Instance Wizard](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) im *Amazon-EC2-Benutzerhandbuch*.
Bevor Sie beginnen, führen Sie die Schritte in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) aus.
Sie können den neuen Amazon-EC2-Assistenten verwenden, um eine Instance zu starten. Der Launch Instance Wizard gibt alle Startparameter an, die zum Starten einer Instance erforderlich sind.
**Topics**
+ [
## Verfahren
](#linux-liw-initiate-instance-launch)
+ [
## Name und Tags
](#linux-liw-name-and-tags)
+ [
## Anwendungs- und Betriebssystem-Images (Amazon Machine Image)
](#linux-liw-ami)
+ [
## Instance-Typ
](#linux-liw-instance-type)
+ [
## Schlüsselpaar (Anmeldung)
](#linux-liw-key-pair)
+ [
## Netzwerkeinstellungen
](#linux-liw-network-settings)
+ [
## Speicher konfigurieren
](#linux-liw-storage)
+ [
## Erweiterte Details
](#linux-liw-advanced-details)
## Verfahren
Bevor Sie beginnen, führen Sie die Schritte in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) aus.
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. In der Navigationsleiste oben auf dem Bildschirm wird die aktuelle AWS Region angezeigt (z. B. USA Ost (Ohio)). Wählen Sie eine Region aus, in der die Instance gestartet werden soll.
1. Wählen Sie im Dashboard der Amazon EC2-Konsole die Option **Instance starten** aus.
## Name und Tags
Der Instance-Name ist ein Tag, wobei der Schlüssel **Name** ist und es sich bei dem Wert um den von Ihnen angegebenen Namen handelt. Sie können Instance, Volumes und elastische Grafiken markieren. Bei Spot-Instances können Sie nur die Spot-Instance-Anforderung mit Tags (Markierungen) versehen.
Die Angabe eines Instance-Namens und zusätzlicher Tags ist optional.
+ Geben Sie unter **Name** einen beschreibenden Namen für die Instance ein. Wenn Sie keinen Namen angeben, kann die Instance anhand der ID identifiziert werden, die beim Starten der Instance automatisch generiert wird.
+ Wenn Sie zusätzliche Tags hinzufügen möchten, wählen Sie **Add additional tags** (Zusätzliche Tags hinzufügen) aus. Klicken Sie auf **Tag hinzufügen**, geben Sie dann einen Schlüssel und einen Wert ein und wählen Sie den Ressourcentyp aus, den Sie markieren möchten. Wählen Sie für jedes weitere Tag **Add another Tag** (Weiteres Tag hinzufügen) aus.
## Anwendungs- und Betriebssystem-Images (Amazon Machine Image)
Ein Amazon Machine Image (AMI) enthält die Informationen, die zum Starten einer Instance erforderlich sind. Ein AMI könnte beispielsweise die für die Funktion als Webserver erforderliche Software (z. B. Apache) und Ihre Website enthalten.
Verwenden Sie die **Suchleiste**, um ein geeignetes Amazon ECS-optimiertes AMI zu finden, das von veröffentlicht wurde. AWS
1. Geben Sie einen der folgenden Begriffe in die **Suchleiste** ein.
+ **ami-ecs**
+ Der **Wert** eines Amazon-ECS-optimierten AMI.
Die neuesten Amazon ECS-optimierten Versionen AMIs und ihre Werte finden Sie unter [Linux Amazon ECS-Optimized](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux) AMI.
1. Drücken Sie die **Eingabetaste**.
1. Wählen Sie auf der Seite **Wählen Sie ein Amazon Machine Image (AMI)** die AMIs Registerkarte **AWS Marketplace** aus.
1. Wählen Sie im Bereich **Ergebnisse verfeinern** auf der linken Seite **Amazon Web Services** als **Publisher** aus.
1. Wählen in der Zeile des AMI, das Sie verwenden wollen, **Auswählen** aus.
Wählen Sie andernfalls **Abbrechen** (oben rechts), um zum Launch Instance Wizard zurückzukehren, ohne ein AMI zu wählen. Ein Standard-AMI ist ausgewählt. Stellen Sie sicher, dass das AMI die in [Amazon ECS-optimiertem](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) Linux beschriebenen Anforderungen erfüllt. AMIs
## Instance-Typ
Der Instance-Typ definiert die Hardware-Konfiguration und Größe der Instance. Größere Instance-Typen haben mehr CPU und Arbeitsspeicher. Weitere Informationen finden Sie unter [Instance-Typen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) im *Amazon EC2-Benutzerhandbuch*. Wenn Sie IPv6 nur einen Workload ausführen möchten, unterstützen bestimmte Instance-Typen keine Adressen. IPv6 Weitere Informationen finden Sie unter [IPv6Adressen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing) im *Amazon EC2 EC2-Benutzerhandbuch*.
+ Wählen Sie unter **Instance-Typ** den Instance-Typ für die Instance aus.
Von dem von Ihnen ausgewählten Instance-Typ ist abhängig, welche Ressourcen zur Ausführung Ihrer Aufgaben verfügbar sind.
## Schlüsselpaar (Anmeldung)
Wählen Sie für **Schlüsselpaarname** ein vorhandenes Schlüsselpaar aus oder wählen Sie **Neues Schlüsselpaar erstellen**, um ein neues zu erstellen.
**Wichtig**
Wenn Sie die Option **Proceed without key pair (Not recommended)** (Ohne Schlüsselpaar fortfahren (Nicht empfohlen)) auswählen, können Sie keine Verbindung zur Instance herstellen, es sei denn, Sie wählen ein AMI aus, das entsprechend konfiguriert ist, um Benutzern eine andere Anmeldemöglichkeit zu erlauben.
## Netzwerkeinstellungen
Konfigurieren Sie die Netzwerkeinstellungen nach Bedarf, nachdem Sie **Bearbeiten** im Abschnitt **Netzwerkeinstellungen** ausgewählt haben.
+ Wählen Sie für **VPC** die VPC aus, in der Sie die Instance starten möchten. Um einen IPv6 reinen Workload auszuführen, wählen Sie eine Dual-Stack-VPC, die IPv4 sowohl einen als auch einen IPv6 CIDR-Block enthält.
+ Wählen Sie für **Subnetz** das Subnetz aus, in dem die Instance gestartet werden soll. Sie können eine Instance in einem Subnetz starten, das einer Availability Zone, Local Zone, Wavelength-Zone oder einem Outpost zugeordnet ist.
Um die Instance in einer Availability Zone zu starten, wählen Sie das Subnetz aus, in dem die Instance gestartet werden soll. Um ein neues Subnetz zu erstellen, wählen Sie **Create new subnet** aus, um die Amazon VPC-Konsole aufzurufen. Wenn Sie fertig sind, kehren Sie zum Launch Instance Wizard zurück und wählen Sie das Symbol zum Aktualisieren, um Ihr Subnetz in die Liste zu laden.
Um die Instance in einer Local Zone zu starten, wählen Sie ein Subnetz aus, das Sie in der Local Zone erstellt haben.
Um eine Instance in einem Outpost zu starten, wählen Sie ein Subnetz in einer VPC aus, die Sie dem Outpost zugeordnet haben.
Um einen reinen Workload auszuführen, wählen Sie ein Subnetz aus, das IPv6 nur einen CIDR-Block enthält. IPv6
+ **Auto-assign Public IP** (Öffentliche IP automatisch zuweisen): Wenn Ihre Instance über das öffentliche Internet zugänglich sein soll, muss das Feld **Auto-assign Public IP** (Öffentliche IP automatisch zuweisen) auf **Enable** (Aktivieren) festgelegt sein. Falls nicht, setzen Sie dieses Feld auf **Disable** (Deaktivieren).
**Anmerkung**
Container-Instances benötigen Zugriff, um mit dem Amazon-ECS-Service-Endpunkt zu kommunizieren. Dies kann über einen Schnittstellen-VPC-Endpunkt oder über Ihre Container-Instances mit öffentlichen IP-Adressen erfolgen.
Weitere Informationen zu Schnittstellen-VPC-Endpunkten finden Sie unter [Amazon ECS und Schnittstellen-VPC-Endpunkte (AWS PrivateLink)](vpc-endpoints.md).
Wenn Sie keinen Schnittstellen-VPC-Endpunkt konfiguriert haben und Ihre Container-Instances keine öffentlichen IP-Adressen haben, müssen Sie Netzwerkadressübersetzung (Network Address Translation, NAT) verwenden, um diesen Zugriff zur Verfügung zu stellen. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im *Amazon-VPC-Benutzerhandbuch* und unter [Verwenden eines HTTP-Proxys für Amazon-ECS-Linux-Container-Instances](http_proxy_config.md) in dieser Anleitung.
+ **Wenn Sie eine Dual-Stack-VPC und ein IPv6 Nur-Only-Subnetz wählen, wählen Sie für **Auto-Assign IPv6 IP** die Option Enable aus.**
+ **Firewall (security groups)** (Firewall (Sicherheitsgruppen)): Verwenden Sie eine Sicherheitsgruppe, um Firewallregeln für Ihre Container-Instance zu definieren. Diese Regeln legen fest, welcher eingehende Netzwerkverkehr an Ihre Container-Instance weitergeleitet wird. Der gesamte übrige Datenverkehr wird ignoriert.
+ Um eine vorhandene Sicherheitsgruppe auszuwählen, wählen Sie **Select existing security group** (Vorhandene Sicherheitsgruppe auswählen) und wählen Sie die Sicherheitsgruppe aus, die Sie in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) erstellt haben.
+ **Wenn Sie die Instance IPv6 nur für einen Workload starten, wählen Sie **Erweiterte Netzwerkkonfiguration** und dann für **Assign Primary IPv6 ** IP die Option Yes aus.**
**Anmerkung**
Ohne eine primäre IPv6 Adresse können Aufgaben, die auf der Container-Instance im Host- oder Bridge-Netzwerkmodus ausgeführt werden, nicht bei Load Balancers oder bei registriert werden. AWS Cloud Map
## Speicher konfigurieren
Die von Ihnen ausgewählte AMI beinhaltet ein oder mehrere Speicher-Volumes, einschließlich eines Root-Volumes. Sie können zusätzliche Volumes angeben, die an die Instance angehängt werden sollen.
Sie können die Ansicht **Simple** (Einfach) verwenden.
+ **Storage type** (Speichertyp): Konfigurieren Sie den Speicher für Ihre Container-Instance.
Wenn Sie das Amazon-ECS-optimierte Amazon Linux 2-AMI verwenden, ist für Ihre Instance ein einzelnes 30 GiB-Volume konfiguriert, das zwischen dem Betriebssystem und Docker geteilt wird.
Wenn Sie das Amazon-ECS-optimierte AMI verwenden, erhält Ihre Instance zwei Volumes konfiguriert. Das **Root**-Volume ist für die Nutzung durch das Betriebssystem und das zweite Amazon EBS-Volume (zugeordnet zu `/dev/xvdcz`) ist für die Nutzung durch Docker vorgesehen.
Sie haben auch die Möglichkeit, die Volume-Größen für Ihre Instance entsprechend den Anforderungen Ihrer Anwendung zu erhöhen oder zu verringern.
## Erweiterte Details
Erweitern Sie für **Advanced details (Erweiterte Details)** den Bereich zur Ansicht der Felder und geben Sie zusätzliche Parameter für die Instance an.
+ **Purchasing option** (Kaufoption): Wählen Sie **Request Spot instances (Spot-Instances anfordern)** aus, um Spot-Instances anzufordern. Außerdem müssen Sie in den anderen Felder im Zusammenhang mit Spot-Instances Werte festlegen. Weitere Informationen finden Sie unter [Spot-Instance-Anforderungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html).
**Anmerkung**
Wenn Sie Spot-Instances verwenden und die Meldung `Not available` angezeigt wird, muss möglicherweise ein anderer Instance-Typ angegeben werden.
+ **IAM instance profile** (IAM-Instance-Profil): Wählen Sie die IAM-Rolle Ihrer Container-Instance aus. Diese heißt normalerweise `ecsInstanceRole`.
**Wichtig**
Wenn Sie Ihre Container-Instance nicht mit den richtigen IAM-Berechtigungen starten, kann Ihr Amazon-ECS-Agent keine Verbindung mir Ihrem Cluster herstellen. Weitere Informationen finden Sie unter [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md).
+ **Benutzerdaten**: Konfigurieren Sie Ihre Amazon-ECS-Container-Instance mit Benutzerdaten, wie z. B. den Agenten-Umgebungsvariablen aus [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md). Amazon EC2-Benutzerdaten-Skripts werden nur einmal ausgeführt, wenn die Instance erstmals gestartet wird. Im Folgenden finden Sie einige gängige Beispiele dafür, wofür Benutzerdaten verwendet werden:
+ Standardmäßig startet Ihre Container-Instance in Ihrem Standard-Cluster. Für einen Start in einem nicht standardmäßigen Cluster wählen Sie die Liste **Advanced Details**. Fügen Sie dann das folgende Skript in das Feld **Benutzerdaten** ein und *your\$1cluster\$1name* ersetzen Sie es durch den Namen Ihres Clusters.
```
#!/bin/bash
echo ECS_CLUSTER=your_cluster_name >> /etc/ecs/ecs.config
```
+ Wenn sich eine `ecs.config`-Datei in Amazon S3 befindet und für Amazon S3 schreibgeschützter Zugriff auf Ihre Container-Instance-Rolle aktiviert ist, wählen Sie die Liste **Advanced Details (Erweiterte Details)**. Fügen Sie dann das folgende Skript in das Feld **Benutzerdaten** ein und *your\$1bucket\$1name* ersetzen Sie es durch den Namen Ihres Buckets, um die Konfigurationsdatei zu installieren AWS CLI und beim Start zu schreiben.
**Anmerkung**
Weitere Informationen zu dieser Konfiguration finden Sie unter [Speichern der Konfiguration von Amazon-ECS-Container-Instances in Amazon S3](ecs-config-s3.md).
```
#!/bin/bash
yum install -y aws-cli
aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
```
+ Geben Sie Tags für Ihre Container-Instance mit dem Konfigurationsparameter `ECS_CONTAINER_INSTANCE_TAGS` an. Dadurch werden Tags erstellt, die nur mit Amazon ECS verknüpft sind, sie können nicht über die Amazon EC2-API aufgelistet werden.
**Wichtig**
Wenn Sie Ihre Container-Instances mit einer Amazon EC2 Auto Scaling-Gruppe starten, sollten Sie den Agent-Konfigurationsparameter ECS\$1CONTAINER\$1INSTANCE\$1TAGS verwenden, um Tags hinzuzufügen. Dies liegt an der Art und Weise, in der Amazon-EC2-Instances Tags hinzugefügt werden, die mit Auto-Scaling-Gruppen gestartet werden.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=your_cluster_name
ECS_CONTAINER_INSTANCE_TAGS={"tag_key": "tag_value"}
EOF
```
+ Geben Sie Tags für Ihre Container-Instance an und verwenden Sie dann den Konfigurationsparameter `ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM`, um sie von Amazon EC2 nach Amazon ECS zu übertragen
Nachfolgend finden Sie ein Beispiel für ein Benutzerdaten-Skript, das die mit einer Container-Instance verknüpften Tags propagiert und die Container-Instance mit einem Cluster namens `your_cluster_name` registriert:
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=your_cluster_name
ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM=ec2_instance
EOF
```
+ Standardmäßig versucht der Amazon ECS-Container-Agent, die Kompatibilität der Container-Instance für eine IPv6 Nur-Konfiguration zu ermitteln, indem er sich den Standard IPv4 und die IPv6 Routen der Instance ansieht. Um dieses Verhalten zu überschreiben, können Sie den ` ECS_INSTANCE_IP_COMPATIBILITY`-Parameter auf `ipv4` oder `ipv6` in der `/etc/ecs/ecs.config`-Datei der Instance setzen.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=your_cluster_name
ECS_INSTANCE_IP_COMPATIBILITY=ipv6
EOF
```
Weitere Informationen finden Sie unter [Bootstrapping von Amazon-ECS-Linux-Container-Instances zur Weitergabe von Daten](bootstrap_container_instance.md).
# Bootstrapping von Amazon-ECS-Linux-Container-Instances zur Weitergabe von Daten
Beim Starten einer Amazon-EC2-Instance haben Sie die Möglichkeit, Benutzerdaten an die EC2-Instance zu übergeben. Die Daten können für allgemeine automatisierte Konfigurationsaufgaben und sogar zur Ausführung von Skripts beim Start der Instance verwendet werden. In Amazon ECS werden Benutzerdaten hauptsächlich zur Übergabe von Konfigurationsinformationen an den Docker-Daemon und den Amazon-ECS-Container-Agenten verwendet.
Sie können mehrere Arten von Benutzerdaten an Amazon EC2 übergeben, darunter auch Cloud-Boothooks, Shell-Skripts und `cloud-init`-Anweisungen. Weitere Informationen zu diesen und anderen Formattypen finden Sie in der [Cloud-Init-Dokumentation](https://cloudinit.readthedocs.io/en/latest/explanation/format.html).
Informationen zur Übergabe dieser Benutzerdaten, wenn Sie den Amazon EC2 Launch Wizard verwenden, finden Sie unter [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
Sie können die Container-Instance so konfigurieren, dass sie Daten in der Container-Agent-Konfiguration oder in der Docker-Daemon-Konfiguration weitergibt.
## Amazon-ECS-Container-Agent
Die Linux-Varianten des Amazon-ECS-optimierten AMI suchen beim Start des Containeragenten nach Agenten-Konfigurationsdaten in der Datei `/etc/ecs/ecs.config`. Sie können diese Konfigurationsdaten beim Start mit Amazon EC2-Benutzerdaten angeben. Weitere Informationen zu den verfügbaren Konfigurationsvariablen für den Amazon-ECS-Container-Agenten finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
Wenn Sie nur eine einzelne Agent-Konfigurationsvariable wie z. B. den Clusternamen festlegen möchten, kopieren Sie die Variable mit dem Befehl **echo** in die Konfigurationsdatei:
```
#!/bin/bash
echo "ECS_CLUSTER=MyCluster" >> /etc/ecs/ecs.config
```
Wenn Sie mehrere Variablen in `/etc/ecs/ecs.config` schreiben müssen, verwenden Sie hierfür das folgende `heredoc`-Format. Bei Verwendung dieses Formats wird alles zwischen den Zeilen **cat** und `EOF` in die Konfigurationsdatei geschrieben.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
ECS_LOGLEVEL=debug
ECS_WARM_POOLS_CHECK=true
EOF
```
Um benutzerdefinierte Instance-Attribute festzulegen, legen Sie die `ECS_INSTANCE_ATTRIBUTES`-Umgebungsvariable fest.
```
#!/bin/bash
cat <<'EOF' >> ecs.config
ECS_INSTANCE_ATTRIBUTES={"envtype":"prod"}
EOF
```
## Docker-Daemon
Sie können Docker Daemon-Konfigurationsinformationen mit Amazon EC2-Benutzerdaten angeben. Weitere Informationen zu Konfigurationsoptionen finden Sie in der [Docker-Daemon-Dokumentation](https://docs.docker.com/reference/cli/dockerd/).
**Anmerkung**
AWS unterstützt keine benutzerdefinierten Docker-Konfigurationen, da sie manchmal ohne Vorwarnung mit future Änderungen oder Funktionen von Amazon ECS in Konflikt geraten können.
Im folgenden Beispiel werden die benutzerdefinierten Optionen zur Konfigurationsdatei des Docker-Daemons, `/etc/docker/daemon.json`, hinzugefügt, die dann in den Benutzerdaten angegeben wird, wenn die Instance gestartet wird.
```
#!/bin/bash
cat </etc/docker/daemon.json
{"debug": true}
EOF
systemctl restart docker --no-block
```
Im folgenden Beispiel werden die benutzerdefinierten Optionen zur Konfigurationsdatei des Docker-Daemons, `/etc/docker/daemon.json`, hinzugefügt, die dann in den Benutzerdaten angegeben wird, wenn die Instance gestartet wird. Dieses Beispiel zeigt, wie der Docker-Proxy in der Docker-Daemon-Konfigurationsdatei deaktiviert wird.
```
#!/bin/bash
cat </etc/docker/daemon.json
{"userland-proxy": false}
EOF
systemctl restart docker --no-block
```
# Konfiguration von Linux-Container-Instances von Amazon ECS für den Empfang von Spot-Instance-Benachrichtigungen
Amazon EC2 hält Ihre Spot-Instance an, beendet sie oder versetzt sie in den Ruhezustand, wenn der Spot-Preis den Höchstpreis für Ihre Anforderung überschreitet oder keine Kapazität mehr verfügbar ist. Amazon EC2 stellt eine zweiminütige Spot-Instance-Unterbrechungsmeldung für Beenden- und Anhalten-Aktionen bereit. Es wird nicht die zweiminütige Benachrichtigung für die Ruhezustand bereitgestellt. Wenn die Entlastung für Amazon-ECS-Spot-Instances auf der Instance aktiviert ist, erhält Amazon ECS die Benachrichtigung über die Unterbrechung der Spot-Instance und versetzt die Instance in den Status `DRAINING`.
**Wichtig**
Amazon ECS erhält keine Benachrichtigung von Amazon EC2, wenn Instances durch den Kapazitäts-Neuausgleich des Auto Scalings entfernt werden. Weitere Informationen finden Sie unter [Kapazitäts-Neuausgleich von Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html).
Wenn eine Container-Instance auf `DRAINING` festgelegt wird, lässt es Amazon ECS nicht zu, dass die Platzierung neuer Aufgaben in der Container-Instance geplant wird. Serviceaufgaben auf der betroffenen Container-Instance mit dem Status `PENDING` werden umgehend gestoppt. Wenn Container-Instances im Cluster verfügbar sind, werden Ersatzserviceaufgaben darauf gestartet.
Spot Instance Draining ist standardmäßig deaktiviert.
Sie können Spot Instance Draining aktivieren, wenn Sie eine Instance starten. Fügen Sie das folgende Skript in das Feld **Benutzerdaten** ein. *MyCluster*Ersetzen Sie durch den Namen des Clusters, für den die Container-Instance registriert werden soll.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
EOF
```
Weitere Informationen finden Sie unter [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
**So aktivieren Sie den Spot-Instance-Ausgleich für eine vorhandene Container-Instance**
1. Stellen Sie über SSH eine Verbindung mit der Spot-Instance her.
1. Bearbeiten Sie die Datei `/etc/ecs/ecs.config` und fügen Sie folgende Zeile hinzu:
```
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
```
1. Den Service `ecs` neu starten.
+ Für das Amazon-ECS-optimierte Amazon Linux 2-AMI:
```
sudo systemctl restart ecs
```
1. (Optional) Durch Abfragen der Agenten-Introspektions-API-Operation können Sie überprüfen, ob der Agent ausgeführt wird und Sie können Informationen über Ihre neue Container-Instance einholen. Weitere Informationen finden Sie unter [Amazon-ECS-Container-Introspektion](ecs-agent-introspection.md).
```
curl http://localhost:51678/v1/metadata
```
# Ausführen eines Skripts beim Starten einer Linux-Container-Instance von Amazon ECS
Sie müssen unter Umständen einen bestimmten Container auf jeder Container-Instance ausführen, um Vorgänge oder Sicherheitsbelange zu behandeln (z. B. Überwachung, Sicherheit, Metriken, Serviceerkennung oder Protokollierung).
Zu diesem Zweck können Sie Ihre Container-Instances so konfigurieren, dass der Befehl **docker run** mit dem Benutzerdatenskript beim Start oder in manchen Init-Systemen wie Upstart oder **systemd** aufgerufen wird. Diese Methode funktioniert zwar, hat aber einige Nachteile, da Amazon ECS nichts über den Container weiß und CPU, Arbeitsspeicher, Ports oder sonstige verwendete Ressourcen nicht überwachen kann. Damit Amazon ECS alle Aufgabenressourcen ordnungsgemäß berücksichtigen kann, sollten Sie eine Aufgabendefinition für den Container erstellen, der auf Ihren Container-Instances ausgeführt werden soll. Verwenden Sie anschließend Amazon ECS, um die Aufgabe beim Start mit Amazon EC2-Benutzerdaten zu platzieren.
Bei dem Amazon EC2-Benutzerdatenskript im folgenden Verfahren wird die Amazon-ECS-Introspektions-API zur Ermittlung der Container-Instance verwendet. Anschließend verwendet es den Befehl AWS CLI und den **start-task** Befehl, um beim Start eine angegebene Aufgabe für sich selbst auszuführen.
**So starten Sie eine Aufgabe beim Start einer Container-Instance**
1. Ändern Sie Ihre `ecsInstanceRole`-IAM-Rolle, um Berechtigungen für die API-Operation `StartTask` hinzuzufügen. Weitere Informationen finden Sie unter [Berechtigungen für eine Rolle aktualisieren](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_update-role-permissions.html) im *Benutzerhandbuch für AWS Identity and Access Management *.
1. Starten Sie eine oder mehrere Container-Instances mit dem Amazon-ECS-optimierten AMI für Amazon Linux 2. Starten Sie neue Container-Instances und verwenden Sie das folgende Beispielskript in den EC2-Benutzerdaten. *your\$1cluster\$1name*Ersetzen Sie durch den Cluster, in dem sich die Container-Instance registrieren soll, und *my\$1task\$1def* durch die Aufgabendefinition, die beim Start auf der Instance ausgeführt werden soll.
Weitere Informationen finden Sie unter [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
**Anmerkung**
Der mehrteilige MIME-Inhalt unten verwendet zum Einstellen von Konfigurationswerten und Installieren von Paketen ein Shell-Skript. Außerdem verwendet er einen systemd-Auftrag zum Starten der Aufgabe, wenn der **ecs**-Service ausgeführt wird und die Introspektions-API verfügbar ist.
```
Content-Type: multipart/mixed; boundary="==BOUNDARY=="
MIME-Version: 1.0
--==BOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"
#!/bin/bash
# Specify the cluster that the container instance should register into
cluster=your_cluster_name
# Write the cluster configuration variable to the ecs.config file
# (add any other configuration variables here also)
echo ECS_CLUSTER=$cluster >> /etc/ecs/ecs.config
START_TASK_SCRIPT_FILE="/etc/ecs/ecs-start-task.sh"
cat <<- 'EOF' > ${START_TASK_SCRIPT_FILE}
exec 2>>/var/log/ecs/ecs-start-task.log
set -x
# Install prerequisite tools
yum install -y jq aws-cli
# Wait for the ECS service to be responsive
until curl -s http://localhost:51678/v1/metadata
do
sleep 1
done
# Grab the container instance ARN and AWS Region from instance metadata
instance_arn=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F/ '{print $NF}' )
cluster=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .Cluster' | awk -F/ '{print $NF}' )
region=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F: '{print $4}')
# Specify the task definition to run at launch
task_definition=my_task_def
# Run the AWS CLI start-task command to start your task on this container instance
aws ecs start-task --cluster $cluster --task-definition $task_definition --container-instances $instance_arn --started-by $instance_arn --region $region
EOF
# Write systemd unit file
UNIT="ecs-start-task.service"
cat <<- EOF > /etc/systemd/system/${UNIT}
[Unit]
Description=ECS Start Task
Requires=ecs.service
After=ecs.service
[Service]
Restart=on-failure
RestartSec=30
ExecStart=/usr/bin/bash ${START_TASK_SCRIPT_FILE}
[Install]
WantedBy=default.target
EOF
# Enable our ecs.service dependent service with `--no-block` to prevent systemd deadlock
# See https://github.com/aws/amazon-ecs-agent/issues/1707
systemctl enable --now --no-block "${UNIT}"
--==BOUNDARY==--
```
1. Überprüfen Sie, ob Ihre Container-Instances im richtigen Cluster gestartet werden und ob Ihre Aufgaben gestartet wurden.
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie auf der Navigationsleiste die Region aus, in der sich der Cluster befindet.
1. Wählen Sie im Navigationsbereich **Clusters** und dann den Cluster aus, der Ihre Container-Instances hostet.
1. Wählen Sie auf der Seite **Cluster** **Aufgaben** und dann Ihre Aufgaben aus.
Auf jeder Container-Instance, die Sie gestartet haben, sollte Ihre Aufgabe ausgeführt werden.
Wenn Ihre Aufgaben nicht angezeigt werden, können Sie sich mit SSH bei Ihren Container-Instances anmelden und die Datei `/var/log/ecs/ecs-start-task.log` auf Debugging-Informationen überprüfen.
# Erhöhung der Netzwerkschnittstellen für Linux-Container-Instances von Amazon ECS
**Anmerkung**
Dieses Feature ist nicht auf Fargate verfügbar.
Jede Aufgabe, die den `awsvpc`-Netzwerkmodus verwendet, erhält eine eigene Elastic-Network-Schnittstelle (ENI), die an die Container-Instance angehängt wird, die sie hostet. Es gibt eine Standardbegrenzung bei der Anzahl der Netzwerkschnittstellen, die an eine Amazon-EC2-Instance angehängt werden können. Dabei zählt die primäre Netzwerkschnittstelle als eine Einheit. Beispielsweise können einer `c5.large` Instance standardmäßig bis zu drei ENIs angehängt sein. Die primäre Netzwerkschnittstelle für die Instance zählt als eine, sodass Sie der Instance zwei ENIs weitere hinzufügen können. Da jede Aufgabe, die den Netzwerkmodus `awsvpc` verwendet, eine ENI benötigt, können Sie nur zwei solcher Aufgaben auf diesem Instance-Typ ausführen.
Amazon ECS unterstützt das Starten von Container-Instances mit erhöhter ENI-Dichte mit unterstützten Instance-Typen von Amazon EC2. Wenn Sie diese Instance-Typen verwenden und die `awsvpcTrunking` Kontoeinstellungen aktivieren, ENIs sind weitere für neu gestartete Container-Instances verfügbar. Diese Konfiguration gibt Ihnen die Möglichkeit, mehrere Aufgaben auf den einzelnen Container-Instances zu platzieren. Informationen zum Aktivieren des Features mithilfe der Konsole finden Sie unter [Ändern der Amazon-ECS-Kontoeinstellungen](ecs-modifying-longer-id-settings.md). Informationen zur AWS CLI Aktivierung der Funktion finden Sie unter[Verwaltung der Amazon ECS-Kontoeinstellungen mit dem AWS CLI](account-setting-management-cli.md).
Beispielsweise hat eine `c5.large`-Instance mit `awsvpcTrunking` ein erhöhtes ENI-Limit von zwölf. Die Container-Instance verfügt über die primäre Netzwerkschnittstelle und Amazon ECS erstellt und fügt eine "Stamm"-Netzwerkschnittstelle an die Container-Instance an. Mit dieser Konfiguration können Sie also zehn Aufgaben anstelle der aktuellen zwei Aufgaben auf der Container-Instance starten.
Die Stamm-Netzwerkschnittstelle wird vollständig von Amazon ECS verwaltet. Sie wird gelöscht, wenn Sie Ihre Container-Instance beenden oder die Registrierung auf dem Cluster aufheben. Weitere Informationen finden Sie unter [Netzwerkoptionen für Amazon-ECS-Aufgaben für EC2](task-networking.md).
## Überlegungen
Beachten Sie Folgendes, wenn Sie das ENI-Trunking-Feature verwenden.
+ Nur Linux-Varianten des Amazon-ECS-optimierten AMI oder andere Amazon-Linux-Varianten mit Version `1.28.1` oder höher des Container-Agenten und Version `1.28.1-2` oder höher des ecs-init-Pakets unterstützen die erhöhten ENI-Limits. Wenn Sie die neueste Linux-Variante des Amazon-ECS-optimierten AMI verwenden, sind diese Anforderungen erfüllt. Windows-Container werden derzeit nicht unterstützt.
+ Nur neue Amazon-EC2-Instances, die nach der Aktivierung von `awsvpcTrunking` gestartet werden, erhalten die erhöhten ENI-Limits und die Trunk-Netzwerkschnittstelle. Zuvor gestarteten Instances erhalten keine dieser Features, unabhängig von den durchgeführten Aktionen.
+ Amazon EC2 EC2-Instances müssen ressourcenbasierte IPv4 DNS-Anfragen deaktiviert sein. Um diese Option zu deaktivieren, deaktivieren Sie die Option **Ressourcenbasierte DNS-Anfragen IPV4 (A-Eintrag) aktivieren**, wenn Sie eine neue Instance in der Amazon EC2 EC2-Konsole erstellen. Verwenden Sie den folgenden Befehl AWS CLI, um diese Option mit dem zu deaktivieren.
```
aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
```
+ Amazon-EC2-Instances in freigegebenen Subnetzen werden nicht unterstützt. Sie können sich nicht bei einem Cluster registrieren, wenn sie verwendet werden.
+ Ihre Aufgaben müssen den Netzwerkmodus `awsvpc` und EC2 verwenden. Aufgaben, die Fargate verwenden, erhalten immer eine dedizierte ENI, unabhängig davon, wie viele gestartet werden. Somit ist dieses Feature nicht erforderlich.
+ Ihre Aufgaben müssen in derselben Amazon VPC wie Ihre Container-Instance gestartet werden. Beim Starten Ihrer Aufgaben kommt es zu einem Attributfehler, wenn sich die Aufgaben nicht in derselben VPC befinden.
+ Beim Starten einer neuen Container-Instance wechselt die Instance in den Status `REGISTERING` und die Stamm-ENI wird für die Instance bereitgestellt. Wenn die Registrierung fehlschlägt, wechselt die Instance in den Status `REGISTRATION_FAILED`. Sie können Probleme bei einer fehlgeschlagenen Registrierung beheben, indem Sie die Container-Instance beschreiben, um das Feld `statusReason` einzusehen, welches den Grund für den Fehler beschreibt. Die Container-Instance kann dann manuell abgemeldet oder beendet werden. Sobald die Container-Instance erfolgreich abgemeldet oder beendet wurde, löscht Amazon ECS den Trunk-ENI.
**Anmerkung**
Amazon ECS sendet Statusänderungsereignisse für Container-Instances aus, die Sie für Instances überwachen können, die zu einem `REGISTRATION_FAILED`-Zustand übergehen. Weitere Informationen finden Sie unter [Statussänderungs-Ereignisse für Amazon-ECS-Container-Instances](ecs_container_instance_events.md).
+ Sobald die Container-Instance beendet wird, wechselt die Instance in den Status `DEREGISTERING` und die Bereitstellung der Stamm-ENI wird aufgehoben. Die Instance wechselt dann in einen `INACTIVE`-Status.
+ Wenn eine Container-Instance in einem öffentlichen Subnetz mit den erhöhten ENI-Limits angehalten und dann neu gestartet wird, verliert die Instance ihre öffentliche IP-Adresse und der Container-Agent verliert die Verbindung.
+ Wenn Sie `awsvpcTrunking` aktivieren, erhalten Container-Instances eine zusätzliche ENI, die die Standard-Sicherheitsgruppe der VPC verwendet und von Amazon ECS verwaltet wird.
Eine Standard-VPC umfasst ein öffentliches Subnetz in jeder Availability Zone, ein Internet-Gateway und Einstellungen zum Aktivieren der DNS-Auflösung. Das Subnetz ist ein öffentliches Subnetz, da die Haupt-Routing-Tabelle den Datenverkehr des Subnetzes in das Internet über das Internet-Gateway sendet. Sie können ein Standardsubnetz zu einem privaten Subnetz machen, indem Sie die Route vom Ziel 0.0.0.0/0 zum Internet-Gateway verschieben. Wenn Sie so vorgehen, können Container-Instances diesem Subnetz jedoch nicht mehr auf das Internet zugreifen. Sie können Sicherheitsgruppenregeln hinzufügen oder löschen, um den Datenverkehr in und aus Ihren Subnetzen zu kontrollieren. Weitere Informationen finden Sie unter [Sicherheitsgruppenregeln](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) im *Benutzerhandbuch für Amazon Virtual Private Cloud*.
## Voraussetzungen
Bevor Sie eine Container-Instance mit den erhöhten ENI-Limits starten, müssen die folgenden Voraussetzungen erfüllt sein.
+ Die serviceverknüpfte Rolle für Amazon ECS muss erstellt werden. Die serviceverknüpfte Amazon ECS-Rolle gibt Amazon ECS die Erlaubnis, in Ihrem Namen Anrufe an andere AWS Services zu tätigen. Diese Rolle wird automatisch für Sie erstellt, wenn Sie einen Cluster erstellen oder wenn Sie einen Service in der AWS-Managementkonsole erstellen oder aktualisieren. Weitere Informationen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon ECS](using-service-linked-roles.md). Sie können die serviceverknüpfte Rolle auch mit dem folgenden AWS CLI Befehl erstellen.
```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com
```
+ Die IAM-Rolle Ihres Kontos oder Ihrer Container-Instance muss die `awsvpcTrunking`-Kontoeinstellung aktivieren. Wir empfehlen, dass Sie zwei Container-Instance-Rollen (`ecsInstanceRole`) erstellen. Sie können dann die `awsvpcTrunking`-Kontoeinstellung für eine Rolle aktivieren und diese Rolle für Aufgaben verwenden, die ENI-Trunking erfordern. Weitere Informationen über die Container-Instance-Rolle finden Sie unter [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md).
Nachdem die Voraussetzungen erfüllt sind, können Sie eine neue Container-Instance mit einem der unterstützten Instance-Typen von Amazon EC2 starten. Für die Instance gelten dann die erhöhten ENI-Limits. Eine Liste mit unterstützten Instance-Typen finden Sie unter [Unterstützte Instances für mehr Amazon-ECS-Container-Netzwerkschnittstellen](eni-trunking-supported-instance-types.md). Die Container-Instance muss Version `1.28.1` oder höher des Container-Agenten haben sowie Version `1.28.1-2` oder höher des ecs-Init-Pakets. Wenn Sie die neueste Linux-Variante des Amazon-ECS-optimierten AMI verwenden, sind diese Anforderungen erfüllt. Weitere Informationen finden Sie unter [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
**Wichtig**
Amazon EC2 EC2-Instances müssen ressourcenbasierte IPv4 DNS-Anfragen deaktiviert sein. Um diese Option zu deaktivieren, stellen Sie sicher, dass die Option **Ressourcenbasierte DNS-Anfragen aktivieren IPV4 (A-Datensatz)** deaktiviert ist, wenn Sie eine neue Instance mit der Amazon EC2 EC2-Konsole erstellen. Verwenden Sie den folgenden Befehl AWS CLI, um diese Option mit dem zu deaktivieren.
```
aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
```
**Um Ihre Container-Instances mit erhöhten ENI Limits anzuzeigen, verwenden Sie den AWS CLI**
Jede Container-Instance verfügt über eine standardmäßige Netzwerkschnittstelle, die als Stamm-Netzwerkschnittstelle bezeichnet wird. Verwenden Sie den folgenden Befehl, um Ihre Container-Instances mit erhöhten ENI-Limits aufzulisten, indem das Attribut `ecs.awsvpc-trunk-id` abgefragt wird. Dieses Attribut gibt an, dass eine Trunk-Netzerkschnittstelle vorhanden ist.
+ [list-attributes](https://docs.aws.amazon.com/cli/latest/reference/ecs/list-attributes.html) (AWS CLI)
```
aws ecs list-attributes \
--target-type container-instance \
--attribute-name ecs.awsvpc-trunk-id \
--cluster cluster_name \
--region us-east-1
```
+ [Get- ECSAttribute Liste](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ECSAttributeList.html) (AWS Tools for Windows PowerShell)
```
Get-ECSAttributeList -TargetType container-instance -AttributeName ecs.awsvpc-trunk-id -Region us-east-1
```
# Unterstützte Instances für mehr Amazon-ECS-Container-Netzwerkschnittstellen
Nachfolgend finden Sie die unterstützten Amazon-EC2-Instance-Typen und die Anzahl der Aufgaben, die auf dem Instance-Typ mit dem Netzwerkmodus `awsvpc` gestartet werden können und zwar vor und nach dem Aktivieren der `awsvpcTrunking`-Kontoeinstellung.
**Wichtig**
Obwohl andere Instance-Typen in derselben Instance-Familie unterstützt werden, werden die Instance-Typen `a1.metal`, `c5.metal`, `c5a.8xlarge`, `c5ad.8xlarge`, `c5d.metal`, `m5.metal`, `p3dn.24xlarge`, `r5.metal`, `r5.8xlarge` und `r5d.metal` nicht unterstützt.
Die Instance-Familien `c5n`, `d3`, `d3en`, `g3`, `g3s`, `g4dn`, `i3`, `i3en`, `inf1`, `m5dn`, `m5n`, `m5zn`, `mac1`, `r5b`, `r5n`, `r5dn`, `u-12tb1`, `u-6tb1`, `u-9tb1` und `z1d` werden nicht unterstützt.
**Topics**
+ [
## Allgemeine Zwecke
](#eni-branch-gp)
+ [
## Für Datenverarbeitung optimiert
](#eni-branch-co)
+ [
## Arbeitsspeicher optimiert
](#eni-branch-mo)
+ [
## Speicheroptimiert
](#eni-branch-so)
+ [
## Beschleunigtes Computing
](#eni-branch-ac)
+ [
## High Performance Computing
](#eni-branch-hpc)
## Allgemeine Zwecke
| Instance-Typ | Aufgabenlimit ohne ENI-Trunking | Aufgabenlimit mit ENI-Trunking |
| --- | --- | --- |
| a1.medium | 1 | 10 |
| a1.large | 2 | 10 |
| a1.xlarge | 3 | 20 |
| a1.2xlarge | 3 | 40 |
| a1.4xlarge | 7 | 60 |
| m5.large | 2 | 10 |
| m5.xlarge | 3 | 20 |
| m5.2xlarge | 3 | 40 |
| m5.4xlarge | 7 | 60 |
| m5.8xlarge | 7 | 60 |
| m5.12xlarge | 7 | 60 |
| m5.16xlarge | 14 | 120 |
| m5.24xlarge | 14 | 120 |
| m5a.large | 2 | 10 |
| m5a.xlarge | 3 | 20 |
| m5a.2xlarge | 3 | 40 |
| m5a.4xlarge | 7 | 60 |
| m5a.8xlarge | 7 | 60 |
| m5a.12xlarge | 7 | 60 |
| m5a.16xlarge | 14 | 120 |
| m5a.24xlarge | 14 | 120 |
| m5ad.large | 2 | 10 |
| m5ad.xlarge | 3 | 20 |
| m5ad.2xlarge | 3 | 40 |
| m5ad.4xlarge | 7 | 60 |
| m5ad.8xlarge | 7 | 60 |
| m5ad.12xlarge | 7 | 60 |
| m5ad.16xlarge | 14 | 120 |
| m5ad.24xlarge | 14 | 120 |
| m5d.large | 2 | 10 |
| m5d.xlarge | 3 | 20 |
| m5d.2xlarge | 3 | 40 |
| m5d.4xlarge | 7 | 60 |
| m5d.8xlarge | 7 | 60 |
| m5d.12xlarge | 7 | 60 |
| m5d.16xlarge | 14 | 120 |
| m5d.24xlarge | 14 | 120 |
| m5d.metal | 14 | 120 |
| m6a.large | 2 | 10 |
| m6a.xlarge | 3 | 20 |
| m6a.2xlarge | 3 | 40 |
| m6a.4xlarge | 7 | 60 |
| m6a.8xlarge | 7 | 90 |
| m6a.12xlarge | 7 | 120 |
| m6a.16xlarge | 14 | 120 |
| m6a.24xlarge | 14 | 120 |
| m6a.32xlarge | 14 | 120 |
| m6a.48xlarge | 14 | 120 |
| m6a.metal | 14 | 120 |
| m6g.medium | 1 | 4 |
| m6g.large | 2 | 10 |
| m6g.xlarge | 3 | 20 |
| m6g.2xlarge | 3 | 40 |
| m6g.4xlarge | 7 | 60 |
| m6g.8xlarge | 7 | 60 |
| m6g.12xlarge | 7 | 60 |
| m6g.16xlarge | 14 | 120 |
| m6g.metal | 14 | 120 |
| m6gd.medium | 1 | 4 |
| m6gd.large | 2 | 10 |
| m6gd.xlarge | 3 | 20 |
| m6gd.2xlarge | 3 | 40 |
| m6gd.4xlarge | 7 | 60 |
| m6gd.8xlarge | 7 | 60 |
| m6gd.12xlarge | 7 | 60 |
| m6gd.16xlarge | 14 | 120 |
| m6gd.metal | 14 | 120 |
| m6i.large | 2 | 10 |
| m6i.xlarge | 3 | 20 |
| m6i.2xlarge | 3 | 40 |
| m6i.4xlarge | 7 | 60 |
| m6i.8xlarge | 7 | 90 |
| m6i.12xlarge | 7 | 120 |
| m6i.16xlarge | 14 | 120 |
| m6i.24xlarge | 14 | 120 |
| m6i.32xlarge | 14 | 120 |
| m6i.metal | 14 | 120 |
| m6id.large | 2 | 10 |
| m6id.x groß | 3 | 20 |
| m6id.2xlarge | 3 | 40 |
| m6id.4xlarge | 7 | 60 |
| m6id.8xlarge | 7 | 90 |
| m6id.12xlarge | 7 | 120 |
| m6id.16xlarge | 14 | 120 |
| m6id.24xlarge | 14 | 120 |
| m6id.32xlarge | 14 | 120 |
| m6id.metal | 14 | 120 |
| m6idn.large | 2 | 10 |
| m6idn.xlarge | 3 | 20 |
| m6id.2xlarge | 3 | 40 |
| m6idn.4xlarge | 7 | 60 |
| m6idn.8xlarge | 7 | 90 |
| m6idn.12xlarge | 7 | 120 |
| m6idn.16xlarge | 14 | 120 |
| m6idn.24xlarge | 14 | 120 |
| m6idn.32xlarge | 15 | 120 |
| m6idn.metal | 15 | 120 |
| m6in.large | 2 | 10 |
| m6in.xlarge | 3 | 20 |
| m6in.2xlarge | 3 | 40 |
| m6in.4xlarge | 7 | 60 |
| m6n.8xlarge | 7 | 90 |
| m6in.12xlarge | 7 | 120 |
| m6in.16xlarge | 14 | 120 |
| m6in.24xlarge | 14 | 120 |
| m6in.32xlarge | 15 | 120 |
| m6in.metal | 15 | 120 |
| m7a.medium | 1 | 4 |
| m7a.large | 2 | 10 |
| m7a.xlarge | 3 | 20 |
| m7a.2xlarge | 3 | 40 |
| m7a.4xlarge | 7 | 60 |
| m7a.8xlarge | 7 | 90 |
| m7a.12xlarge | 7 | 120 |
| m7a.16xlarge | 14 | 120 |
| m7a.24xlarge | 14 | 120 |
| m7a.32xlarge | 14 | 120 |
| m7a.48xlarge | 14 | 120 |
| m7a.metal-48xl | 14 | 120 |
| m7g.medium | 1 | 4 |
| m7g.large | 2 | 10 |
| m7g.xlarge | 3 | 20 |
| m7g.2xlarge | 3 | 40 |
| m7g.4xlarge | 7 | 60 |
| m7g.8xlarge | 7 | 60 |
| m7g.12xlarge | 7 | 60 |
| m7g.16xlarge | 14 | 120 |
| m7g.metal | 14 | 120 |
| m7gd.medium | 1 | 4 |
| m7gd.large | 2 | 10 |
| m7gd.xlarge | 3 | 20 |
| m7gd.2xlarge | 3 | 40 |
| m7gd.4xlarge | 7 | 60 |
| m7gd.8xlarge | 7 | 60 |
| m7gd.12xlarge | 7 | 60 |
| m7gd.16xlarge | 14 | 120 |
| m7gd.metal | 14 | 120 |
| m7i.large | 2 | 10 |
| m7i.xlarge | 3 | 20 |
| m7i.2xlarge | 3 | 40 |
| m7i.4xlarge | 7 | 60 |
| m7i.8xlarge | 7 | 90 |
| m7i.12xlarge | 7 | 120 |
| m7i.16xlarge | 14 | 120 |
| m7i.24xlarge | 14 | 120 |
| m7i.48xlarge | 14 | 120 |
| m7i.metal-24xl | 14 | 120 |
| m7i.metal-48xl | 14 | 120 |
| m7i-flex.large | 2 | 4 |
| m7i-flex.xlarge | 3 | 10 |
| m7i-flex.2xlarge | 3 | 20 |
| m7i-flex.4xlarge | 7 | 40 |
| m7i-flex.8xlarge | 7 | 60 |
| m7i-flex.12xlarge | 7 | 120 |
| m7i-flex.16x groß | 14 | 120 |
| m8a.medium | 1 | 4 |
| m8a.large | 2 | 10 |
| m8a.xlarge | 3 | 20 |
| m8a.2 x groß | 3 | 40 |
| m8a.4x groß | 7 | 60 |
| m8a.8xgroß | 9 | 90 |
| m8a.12x groß | 11 | 120 |
| m8a.16x groß | 15 | 120 |
| m8a.24x groß | 15 | 120 |
| m8a.48x groß | 23 | 120 |
| m8a.metal-24xl | 15 | 120 |
| M8 A, Metall, 48 XL | 23 | 120 |
| m8azn. mittel | 2 | 4 |
| m8azn. groß | 3 | 10 |
| m8azn.x groß | 3 | 20 |
| m8azn.3 x groß | 7 | 40 |
| m8azn.6 x groß | 7 | 60 |
| m8azn.12x groß | 15 | 120 |
| m8azn.24x groß | 15 | 120 |
| m8azn.metall-12xl | 15 | 120 |
| m8azn.metall-24xl | 15 | 120 |
| m8g.medium | 1 | 4 |
| m8g.large | 2 | 10 |
| m8g.xlarge | 3 | 20 |
| m8g.2xlarge | 3 | 40 |
| 8 g, 4 x groß | 7 | 60 |
| 8 g, 8 x groß | 7 | 60 |
| 8 g, 12 x groß | 7 | 60 |
| 8 g, 16 x groß | 14 | 120 |
| m8g.24xlarge | 14 | 120 |
| m8g.48xlarge | 14 | 120 |
| m8g.metal-24xl | 14 | 120 |
| m8g.metal-48xl | 14 | 120 |
| m 8 GB. Mittel | 1 | 4 |
| m 8 GB. Groß | 2 | 10 |
| m8 gb.xlarge | 3 | 20 |
| m8 gb. 2 x groß | 3 | 40 |
| m8 gb.4x groß | 7 | 60 |
| m 8 GB. 8 x groß | 9 | 60 |
| m8 gb.12x groß | 11 | 60 |
| m8 gb.16x groß | 15 | 120 |
| m8 gb.24x groß | 23 | 120 |
| 8 GB. 48 x groß | 23 | 120 |
| m 8 GB, Metall, 24 XL | 23 | 120 |
| m8 gb.metal-48xl | 23 | 120 |
| m8gd.medium | 1 | 4 |
| m8gd.large | 2 | 10 |
| m8gd.xlarge | 3 | 20 |
| m8 gd.2 x groß | 3 | 40 |
| m8 gd.4 x groß | 7 | 60 |
| m 8 g d 8 x groß | 7 | 60 |
| m 8 g d, 12 x groß | 7 | 60 |
| m 8 g d, 16 x groß | 14 | 120 |
| m8gd.24xlarge | 14 | 120 |
| m8gd.48xlarge | 14 | 120 |
| m8gd.metal-24xl | 14 | 120 |
| m8gd.metal-48xl | 14 | 120 |
| M8 Gn. Mittel | 1 | 4 |
| m8 gn. groß | 2 | 10 |
| m8gn.xlarge | 3 | 20 |
| m8g n.2 x groß | 3 | 40 |
| M8 Gn. 4 x groß | 7 | 60 |
| M8 Gn. 8 x groß | 9 | 60 |
| M8 Gn. 12 x groß | 11 | 60 |
| M8 Gn. 16 x groß | 15 | 120 |
| M8 Gn. 24 x groß | 23 | 120 |
| M8 Gn. 48 x groß | 23 | 120 |
| M8 Gn. Metall, 24 XL | 23 | 120 |
| M8 Gn. Metall-48 XL | 23 | 120 |
| m8i.large | 2 | 10 |
| m8i.xlarge | 3 | 20 |
| m8i.2 x groß | 3 | 40 |
| m8i.4x groß | 7 | 60 |
| m8i.8 x groß | 9 | 90 |
| m8i.12x groß | 11 | 120 |
| m8i.16x groß | 15 | 120 |
| m8i.24x groß | 15 | 120 |
| m8i.32x groß | 23 | 120 |
| m8i.48x groß | 23 | 120 |
| m8i.96xlarge | 23 | 120 |
| m8i.metal-48xl | 23 | 120 |
| m8i.metal-96xl | 23 | 120 |
| m8id. groß | 2 | 10 |
| m8id.xlarge | 3 | 20 |
| m8id.2 x groß | 3 | 40 |
| m8 id. 4 x groß | 7 | 60 |
| m8 id. 8 x groß | 9 | 90 |
| m8id. 12x groß | 11 | 120 |
| m8id.16x groß | 15 | 120 |
| m8id. 24x groß | 15 | 120 |
| m8id.32x groß | 23 | 120 |
| m8id.48x groß | 23 | 120 |
| m8id. 96x groß | 23 | 120 |
| m8 id. Metall, 48 XL | 23 | 120 |
| m8id.metall-96xl | 23 | 120 |
| m8i-flex. Groß | 2 | 4 |
| m8i-flex.xgroß | 3 | 10 |
| m8i-flex.2 x groß | 3 | 20 |
| m8i-flex.4 x groß | 7 | 40 |
| m8i-flex.8 x groß | 9 | 60 |
| m8i-flex.12x groß | 11 | 120 |
| m8i-flex.16x groß | 15 | 120 |
| mac2.metal | 7 | 12 |
| mac2-m1ultra.metal | 7 | 12 |
| mac2-m2.metal | 7 | 12 |
| mac2-m2pro.metal | 7 | 12 |
| mac-m4.metal | 7 | 12 |
| mac-m4pro.metal | 7 | 12 |
| Mac-M4 Max. Metall | 7 | 12 |
## Für Datenverarbeitung optimiert
| Instance-Typ | Aufgabenlimit ohne ENI-Trunking | Aufgabenlimit mit ENI-Trunking |
| --- | --- | --- |
| c5.large | 2 | 10 |
| c5.xlarge | 3 | 20 |
| c5.2xlarge | 3 | 40 |
| c5.4xlarge | 7 | 60 |
| c5.9xlarge | 7 | 60 |
| c5.12xlarge | 7 | 60 |
| c5.18xlarge | 14 | 120 |
| c5.24xlarge | 14 | 120 |
| c5a.large | 2 | 10 |
| c5a.xlarge | 3 | 20 |
| c5a.2xlarge | 3 | 40 |
| c5a.4xlarge | 7 | 60 |
| c5a.12xlarge | 7 | 60 |
| c5a.16xlarge | 14 | 120 |
| c5a.24xlarge | 14 | 120 |
| c5ad.large | 2 | 10 |
| c5ad.xlarge | 3 | 20 |
| c5ad.2xlarge | 3 | 40 |
| c5ad.4xlarge | 7 | 60 |
| c5ad.12xlarge | 7 | 60 |
| c5ad.16xlarge | 14 | 120 |
| c5ad.24xlarge | 14 | 120 |
| c5d.large | 2 | 10 |
| c5d.xlarge | 3 | 20 |
| c5d.2xlarge | 3 | 40 |
| c5d.4xlarge | 7 | 60 |
| c5d.9xlarge | 7 | 60 |
| c5d.12xlarge | 7 | 60 |
| c5d.18xlarge | 14 | 120 |
| c5d.24xlarge | 14 | 120 |
| c6a.large | 2 | 10 |
| c6a.xlarge | 3 | 20 |
| c6a.2xlarge | 3 | 40 |
| c6a.4xlarge | 7 | 60 |
| c6a.8xlarge | 7 | 90 |
| c6a.12xlarge | 7 | 120 |
| c6a.16xlarge | 14 | 120 |
| c6a.24xlarge | 14 | 120 |
| c6a.32xlarge | 14 | 120 |
| c6a.48xlarge | 14 | 120 |
| c6a.metal | 14 | 120 |
| c6g.medium | 1 | 4 |
| c6g.large | 2 | 10 |
| c6g.xlarge | 3 | 20 |
| c6g.2xlarge | 3 | 40 |
| c6g.4xlarge | 7 | 60 |
| c6g.8xlarge | 7 | 60 |
| c6g.12xlarge | 7 | 60 |
| c6g.16xlarge | 14 | 120 |
| c6g.metal | 14 | 120 |
| c6gd.medium | 1 | 4 |
| c6gd.large | 2 | 10 |
| c6gd.xlarge | 3 | 20 |
| c6gd.2xlarge | 3 | 40 |
| c6gd.4xlarge | 7 | 60 |
| c6gd.8xlarge | 7 | 60 |
| c6gd.12xlarge | 7 | 60 |
| c6gd.16xlarge | 14 | 120 |
| c6gd.metal | 14 | 120 |
| c6gn.medium | 1 | 4 |
| c6gn.large | 2 | 10 |
| c6gn.xlarge | 3 | 20 |
| c6gn.2xlarge | 3 | 40 |
| c6gn.4xlarge | 7 | 60 |
| c6gn.8xlarge | 7 | 60 |
| c6gn.12xlarge | 7 | 60 |
| c6gn.16xlarge | 14 | 120 |
| c6i.large | 2 | 10 |
| c6i.xlarge | 3 | 20 |
| c6i.2xlarge | 3 | 40 |
| c6i.4xlarge | 7 | 60 |
| c6i.8xlarge | 7 | 90 |
| c6i.12xlarge | 7 | 120 |
| c6i.16xlarge | 14 | 120 |
| c6i.24xlarge | 14 | 120 |
| c6i.32xlarge | 14 | 120 |
| c6i.metal | 14 | 120 |
| c6id.large | 2 | 10 |
| c6id.xlarge | 3 | 20 |
| c6id.2xlarge | 3 | 40 |
| c6id.4xlarge | 7 | 60 |
| c6id.8xlarge | 7 | 90 |
| c6id.12xlarge | 7 | 120 |
| c6id.16xlarge | 14 | 120 |
| c6id.24xlarge | 14 | 120 |
| c6id.32xlarge | 14 | 120 |
| c6id.metal | 14 | 120 |
| c6in.large | 2 | 10 |
| c6in.xlarge | 3 | 20 |
| c6in.2xlarge | 3 | 40 |
| c6in.4xlarge | 7 | 60 |
| c6in.8xlarge | 7 | 90 |
| c6in.12xlarge | 7 | 120 |
| c6in.16xlarge | 14 | 120 |
| c6in.24xlarge | 14 | 120 |
| c6in.32xlarge | 15 | 120 |
| c6in.metal | 15 | 120 |
| c7a.medium | 1 | 4 |
| c7a.large | 2 | 10 |
| c7a.xlarge | 3 | 20 |
| c7a.2xlarge | 3 | 40 |
| c7a.4xlarge | 7 | 60 |
| c7a.8xlarge | 7 | 90 |
| c7a.12xlarge | 7 | 120 |
| c7a.16xlarge | 14 | 120 |
| c7a.24xlarge | 14 | 120 |
| c7a.32xlarge | 14 | 120 |
| c7a.48xlarge | 14 | 120 |
| c7a.metal-48xl | 14 | 120 |
| c7g.medium | 1 | 4 |
| c7g.large | 2 | 10 |
| c7g.xlarge | 3 | 20 |
| c7g.2xlarge | 3 | 40 |
| c7g.4xlarge | 7 | 60 |
| c7g.8xlarge | 7 | 60 |
| c7g.12xlarge | 7 | 60 |
| c7g.16xlarge | 14 | 120 |
| c7g.metal | 14 | 120 |
| c7gd.medium | 1 | 4 |
| c7gd.large | 2 | 10 |
| c7gd.xlarge | 3 | 20 |
| c7gd.2xlarge | 3 | 40 |
| c7gd.4xlarge | 7 | 60 |
| c7gd.8xlarge | 7 | 60 |
| c7gd.12xlarge | 7 | 60 |
| c7gd.16xlarge | 14 | 120 |
| c7gd.metal | 14 | 120 |
| c7gn.medium | 1 | 4 |
| c7gn.large | 2 | 10 |
| c7gn.xlarge | 3 | 20 |
| c7gn.2xlarge | 3 | 40 |
| c7gn.4xlarge | 7 | 60 |
| c7gn.8xlarge | 7 | 60 |
| c7gn.12xlarge | 7 | 60 |
| c7gn.16xlarge | 14 | 120 |
| c7gn.metal | 14 | 120 |
| c7i. groß | 2 | 10 |
| c7i.x groß | 3 | 20 |
| c7i.2xlarge | 3 | 40 |
| c7i.4xlarge | 7 | 60 |
| c7i.8xlarge | 7 | 90 |
| c7i.12xlarge | 7 | 120 |
| c7i.16xlarge | 14 | 120 |
| c7i.24xlarge | 14 | 120 |
| c7i.48xlarge | 14 | 120 |
| c7i.metal-24xl | 14 | 120 |
| c7i.metal-48xl | 14 | 120 |
| c7i-flex.large | 2 | 4 |
| c7i-flex.xlarge | 3 | 10 |
| c7i-flex.2xlarge | 3 | 20 |
| c7i-flex.4xlarge | 7 | 40 |
| c7i-flex.8xlarge | 7 | 60 |
| c7i-flex.12xlarge | 7 | 120 |
| c7i-flex.16xlarge | 14 | 120 |
| c8a. mittel | 1 | 4 |
| c8a. groß | 2 | 10 |
| c8a.x groß | 3 | 20 |
| c8a.2 x groß | 3 | 40 |
| c8a.4x groß | 7 | 60 |
| c8a.8 x groß | 9 | 90 |
| c8a.12x groß | 11 | 120 |
| c8a.16x groß | 15 | 120 |
| c8a.24x groß | 15 | 120 |
| c8a.48x groß | 23 | 120 |
| C8A, Metall, 24 XL | 15 | 120 |
| c8a.metall-48xl | 23 | 120 |
| c8g.medium | 1 | 4 |
| c8g.large | 2 | 10 |
| c8g.xlarge | 3 | 20 |
| c8g.2xlarge | 3 | 40 |
| c8g.4 x groß | 7 | 60 |
| c8g.8xgroß | 7 | 60 |
| c8g.12x groß | 7 | 60 |
| c8g.16x groß | 14 | 120 |
| c8g.24xlarge | 14 | 120 |
| c8g.48xlarge | 14 | 120 |
| c8g.metal-24xl | 14 | 120 |
| c8g.metal-48xl | 14 | 120 |
| c 8 GB. Mittel | 1 | 4 |
| c 8 GB. Groß | 2 | 10 |
| c8gb.xlarge | 3 | 20 |
| c 8 gb. 2 x groß | 3 | 40 |
| c 8 gb. 4 x groß | 7 | 60 |
| c 8 GB. 8 x groß | 9 | 60 |
| c 8 gb. 12 x groß | 11 | 60 |
| c 8 gb. 16 x groß | 15 | 120 |
| c 8 gb. 24 x groß | 23 | 120 |
| c 8 gb. 48 x groß | 23 | 120 |
| C 8 GB, Metall, 24 XL | 23 | 120 |
| C8 GB.Metall-48 XL | 23 | 120 |
| c8gd.medium | 1 | 4 |
| c8gd.large | 2 | 10 |
| c8gd.xlarge | 3 | 20 |
| c8gd.2 x groß | 3 | 40 |
| c8gd.4x groß | 7 | 60 |
| c8gd.8xgroß | 7 | 60 |
| c8gd.12x groß | 7 | 60 |
| c8gd.16x groß | 14 | 120 |
| c8gd.24xlarge | 14 | 120 |
| c8gd.48xlarge | 14 | 120 |
| c8gd.metal-24xl | 14 | 120 |
| c8gd.metal-48xl | 14 | 120 |
| c8gn.medium | 1 | 4 |
| c8gn.large | 2 | 10 |
| c8gn.xlarge | 3 | 20 |
| C8 Gn. 2 x groß | 3 | 40 |
| C8 Gn. 4 x groß | 7 | 60 |
| C8 Gn. 8 x groß | 9 | 60 |
| c8gn.12x groß | 11 | 60 |
| c8gn.16x groß | 15 | 120 |
| c8gn.24xlarge | 23 | 120 |
| c8gn.48xlarge | 23 | 120 |
| c8gn.metal-24xl | 23 | 120 |
| c8gn.metal-48xl | 23 | 120 |
| c8i.large | 2 | 10 |
| c8i.xlarge | 3 | 20 |
| c8i.2 x groß | 3 | 40 |
| c8i.4x groß | 7 | 60 |
| c8i.8 x groß | 9 | 90 |
| c8i.12x groß | 11 | 120 |
| c8i.16x groß | 15 | 120 |
| c8i.24x groß | 15 | 120 |
| c8i.32x groß | 23 | 120 |
| c8i.48x groß | 23 | 120 |
| c8i.96xlarge | 23 | 120 |
| c8i.metall-48xl | 23 | 120 |
| c8i.metal-96xl | 23 | 120 |
| c8id. groß | 2 | 10 |
| c8id.xlarge | 3 | 20 |
| c8id.2 x groß | 3 | 40 |
| c8id.4x groß | 7 | 60 |
| c8id.8xgroß | 9 | 90 |
| c8id.12x groß | 11 | 120 |
| c8id.16x groß | 15 | 120 |
| c8id.24x groß | 15 | 120 |
| c8id.32x groß | 23 | 120 |
| c8id.48x groß | 23 | 120 |
| c8id.96x groß | 23 | 120 |
| C8 ID, Metall, 48 XL | 23 | 120 |
| c8id.metall-96xl | 23 | 120 |
| c8i-flex. groß | 2 | 4 |
| c8i-flex.xgroß | 3 | 10 |
| c8i-flex.2 x groß | 3 | 20 |
| c8i-flex.4x groß | 7 | 40 |
| c8i-flex.8 x groß | 9 | 60 |
| c8i-flex.12x groß | 11 | 120 |
| c8i-flex.16x groß | 15 | 120 |
## Arbeitsspeicher optimiert
| Instance-Typ | Aufgabenlimit ohne ENI-Trunking | Aufgabenlimit mit ENI-Trunking |
| --- | --- | --- |
| r5.large | 2 | 10 |
| r5.xlarge | 3 | 20 |
| r5.2xlarge | 3 | 40 |
| r5.4xlarge | 7 | 60 |
| r5.12xlarge | 7 | 60 |
| r5.16xlarge | 14 | 120 |
| r5.24xlarge | 14 | 120 |
| r5a.large | 2 | 10 |
| r5a.xlarge | 3 | 20 |
| r5a.2xlarge | 3 | 40 |
| r5a.4xlarge | 7 | 60 |
| r5a.8xlarge | 7 | 60 |
| r5a.12xlarge | 7 | 60 |
| r5a.16xlarge | 14 | 120 |
| r5a.24xlarge | 14 | 120 |
| r5ad.large | 2 | 10 |
| r5ad.xlarge | 3 | 20 |
| r5ad.2xlarge | 3 | 40 |
| r5ad.4xlarge | 7 | 60 |
| r5ad.8xlarge | 7 | 60 |
| r5ad.12xlarge | 7 | 60 |
| r5ad.16xlarge | 14 | 120 |
| r5ad.24xlarge | 14 | 120 |
| r5b.16xlarge | 14 | 120 |
| r5d.large | 2 | 10 |
| r5d.xlarge | 3 | 20 |
| r5d.2xlarge | 3 | 40 |
| r5d.4xlarge | 7 | 60 |
| r5d.8xlarge | 7 | 60 |
| r5d.12xlarge | 7 | 60 |
| r5d.16xlarge | 14 | 120 |
| r5d.24xlarge | 14 | 120 |
| r5dn.16xlarge | 14 | 120 |
| r6a.large | 2 | 10 |
| r6a.xlarge | 3 | 20 |
| r6a.2xlarge | 3 | 40 |
| r6a.4xlarge | 7 | 60 |
| r6a.8xlarge | 7 | 90 |
| r6a.12xlarge | 7 | 120 |
| r6a.16xlarge | 14 | 120 |
| r6a.24xlarge | 14 | 120 |
| r6a.32xlarge | 14 | 120 |
| r6a.48xlarge | 14 | 120 |
| r6a.metal | 14 | 120 |
| r6g.medium | 1 | 4 |
| r6g.groß | 2 | 10 |
| r6g.xlarge | 3 | 20 |
| r6g.2xlarge | 3 | 40 |
| r6g.4xlarge | 7 | 60 |
| r6g.8xlarge | 7 | 60 |
| r6g.12xlarge | 7 | 60 |
| r6g.16xlarge | 14 | 120 |
| r6g.metal | 14 | 120 |
| r6gd.medium | 1 | 4 |
| r6gd.large | 2 | 10 |
| r6gd.xlarge | 3 | 20 |
| r6gd.2xlarge | 3 | 40 |
| r6gd.4xlarge | 7 | 60 |
| r6gd.8xlarge | 7 | 60 |
| r6gd.12xlarge | 7 | 60 |
| r6gd.16xlarge | 14 | 120 |
| r6gd.metal | 14 | 120 |
| r6i.large | 2 | 10 |
| r6i.xlarge | 3 | 20 |
| r6i.2xlarge | 3 | 40 |
| r6i.4xlarge | 7 | 60 |
| r6i.8xlarge | 7 | 90 |
| r6i.12xlarge | 7 | 120 |
| r6i.16xlarge | 14 | 120 |
| r6i.24xlarge | 14 | 120 |
| r6i.32xlarge | 14 | 120 |
| r6i.metal | 14 | 120 |
| r6id.large | 2 | 10 |
| r6id.xlarge | 3 | 20 |
| r6id.2xlarge | 3 | 40 |
| r6id.4xlarge | 7 | 60 |
| r6id.8xlarge | 7 | 90 |
| r6id.12xlarge | 7 | 120 |
| r6id.16xlarge | 14 | 120 |
| r6id.24xlarge | 14 | 120 |
| r6id.32xlarge | 14 | 120 |
| r6id.metal | 14 | 120 |
| r6idn.large | 2 | 10 |
| r6idn.xlarge | 3 | 20 |
| r6idn.2xlarge | 3 | 40 |
| r6idn.4xlarge | 7 | 60 |
| r6idn.8xlarge | 7 | 90 |
| r6idn.12xlarge | 7 | 120 |
| r6idn.16xlarge | 14 | 120 |
| r6idn.24xlarge | 14 | 120 |
| r6idn.32xlarge | 15 | 120 |
| r6idn.metal | 15 | 120 |
| r6in.large | 2 | 10 |
| r6in.xlarge | 3 | 20 |
| r6in.2xlarge | 3 | 40 |
| r6in.4xlarge | 7 | 60 |
| r6in.8xlarge | 7 | 90 |
| r6in.12xlarge | 7 | 120 |
| r6in.16xlarge | 14 | 120 |
| r6in.24xlarge | 14 | 120 |
| r6in.32xlarge | 15 | 120 |
| r6in.metal | 15 | 120 |
| r7a.medium | 1 | 4 |
| r7a.large | 2 | 10 |
| r7a.x groß | 3 | 20 |
| r7a.2xlarge | 3 | 40 |
| r7a.4xlarge | 7 | 60 |
| r7a.8xlarge | 7 | 90 |
| r7a.12xlarge | 7 | 120 |
| r7a.16xlarge | 14 | 120 |
| r7a.24xlarge | 14 | 120 |
| r7a.32xlarge | 14 | 120 |
| r7a.48xlarge | 14 | 120 |
| r7a.metal-48xl | 14 | 120 |
| r7g.medium | 1 | 4 |
| r7g.large | 2 | 10 |
| r7g.xlarge | 3 | 20 |
| r7g.2xlarge | 3 | 40 |
| r7g.4xlarge | 7 | 60 |
| r7g.8xlarge | 7 | 60 |
| r7g.12xlarge | 7 | 60 |
| r7g.16xlarge | 14 | 120 |
| r7g.metal | 14 | 120 |
| r7gd.medium | 1 | 4 |
| r7gd.large | 2 | 10 |
| r7gd.xlarge | 3 | 20 |
| r7gd.2xlarge | 3 | 40 |
| r7gd.4xlarge | 7 | 60 |
| r7gd.8xlarge | 7 | 60 |
| r7gd.12xlarge | 7 | 60 |
| r7gd.16xlarge | 14 | 120 |
| r7gd.metal | 14 | 120 |
| r7i.large | 2 | 10 |
| r7i.xlarge | 3 | 20 |
| r7i.2xlarge | 3 | 40 |
| r7i.4xlarge | 7 | 60 |
| r7i.8xlarge | 7 | 90 |
| r7i.12xlarge | 7 | 120 |
| r7i.16xlarge | 14 | 120 |
| r7i.24xlarge | 14 | 120 |
| r7i.48xlarge | 14 | 120 |
| r7i.metal-24xl | 14 | 120 |
| r7i.metal-48xl | 14 | 120 |
| r7iz.large | 2 | 10 |
| r7iz.xlarge | 3 | 20 |
| r7iz.2xlarge | 3 | 40 |
| r7iz.4xlarge | 7 | 60 |
| r7iz.8xlarge | 7 | 90 |
| r7iz.12xlarge | 7 | 120 |
| r7iz.16xlarge | 14 | 120 |
| r7iz.32xlarge | 14 | 120 |
| r7iz.metal-16xl | 14 | 120 |
| r7iz.metal-32xl | 14 | 120 |
| r8a.medium | 1 | 4 |
| r8a.large | 2 | 10 |
| r8a.xlarge | 3 | 20 |
| r8a.2 x groß | 3 | 40 |
| r8a.4x groß | 7 | 60 |
| r8a.8 x groß | 9 | 90 |
| r8a.12x groß | 11 | 120 |
| r8a.16x groß | 15 | 120 |
| r8a.24x groß | 15 | 120 |
| r8a.48x groß | 23 | 120 |
| r8a.metal-24xl | 15 | 120 |
| r8a.metal-48xl | 23 | 120 |
| r8g.medium | 1 | 4 |
| r8g.large | 2 | 10 |
| r8g.xlarge | 3 | 20 |
| r8g.2 x groß | 3 | 40 |
| r8g.4x groß | 7 | 60 |
| r8g.8xgroß | 7 | 60 |
| r8g.12x groß | 7 | 60 |
| r8g.16x groß | 14 | 120 |
| r8g.24xlarge | 14 | 120 |
| r8g.48xlarge | 14 | 120 |
| r8g.metal-24xl | 14 | 120 |
| r8g.metal-48xl | 14 | 120 |
| r8gb.medium | 1 | 4 |
| r8gb.large | 2 | 10 |
| r8gb.xlarge | 3 | 20 |
| r8gb.2xlarge | 3 | 40 |
| r8gb.4xlarge | 7 | 60 |
| r8gb.8xlarge | 9 | 60 |
| r8gb.12xlarge | 11 | 60 |
| r8gb.16xlarge | 15 | 120 |
| r8gb.24xlarge | 23 | 120 |
| r8gb. 48x groß | 23 | 120 |
| r8gb.metal-24xl | 23 | 120 |
| R 8 GB, Metall, 48 XL | 23 | 120 |
| r8gd.medium | 1 | 4 |
| r8gd.large | 2 | 10 |
| r8gd.xlarge | 3 | 20 |
| r8gd.2xlarge | 3 | 40 |
| r8gd.4x groß | 7 | 60 |
| r8gd.8xgroß | 7 | 60 |
| r8gd.12x groß | 7 | 60 |
| r8gd.16x groß | 14 | 120 |
| r8gd.24xlarge | 14 | 120 |
| r8gd.48xlarge | 14 | 120 |
| r8gd.metal-24xl | 14 | 120 |
| r8gd.metal-48xl | 14 | 120 |
| r8gn.medium | 1 | 4 |
| r8gn.large | 2 | 10 |
| r8gn.xlarge | 3 | 20 |
| r8gn.2xlarge | 3 | 40 |
| r8gn.4xlarge | 7 | 60 |
| r8gn.8xlarge | 9 | 60 |
| r8gn.12xlarge | 11 | 60 |
| r8gn.16xlarge | 15 | 120 |
| r8gn.24xlarge | 23 | 120 |
| r8gn.48xlarge | 23 | 120 |
| r8gn.metal-24xl | 23 | 120 |
| r8gn.metal-48xl | 23 | 120 |
| r8i.large | 2 | 10 |
| r8i.xlarge | 3 | 20 |
| r8i.2 x groß | 3 | 40 |
| r8i.4x groß | 7 | 60 |
| r8i.8 x groß | 9 | 90 |
| r8i.12x groß | 11 | 120 |
| r8i.16x groß | 15 | 120 |
| r8i.24x groß | 15 | 120 |
| r8i.32x groß | 23 | 120 |
| r8i.48x groß | 23 | 120 |
| r8i.96xlarge | 23 | 120 |
| r8i.metall-48xl | 23 | 120 |
| r8i.metal-96xl | 23 | 120 |
| r8id. groß | 2 | 10 |
| r8id.xlarge | 3 | 20 |
| r8id.2 x groß | 3 | 40 |
| r8id.4x groß | 7 | 60 |
| r8id.8xgroß | 9 | 90 |
| r8id.12x groß | 11 | 120 |
| r8id.16x groß | 15 | 120 |
| r8id.24x groß | 15 | 120 |
| r8id.32x groß | 23 | 120 |
| r8id.48x groß | 23 | 120 |
| r8id.96x groß | 23 | 120 |
| r8 id. Metall, 48 XL | 23 | 120 |
| r8id.metal-96xl | 23 | 120 |
| r8i-flex.large | 2 | 4 |
| r8i-flex.xlarge | 3 | 10 |
| r8i-flex.2xlarge | 3 | 20 |
| r8i-flex.4xlarge | 7 | 40 |
| r8i-flex.8xlarge | 9 | 60 |
| r8i-flex.12xlarge | 11 | 120 |
| r8i-flex.16xlarge | 15 | 120 |
| u-3tb1.56xlarge | 7 | 12 |
| u-6tb1.56xlarge | 14 | 12 |
| u-18tb1.112xlarge | 14 | 12 |
| u-18tb1.metal | 14 | 12 |
| u-24tb1.112xlarge | 14 | 12 |
| u-24tb1.metal | 14 | 12 |
| u7i-6tb.112xlarge | 14 | 120 |
| u7i-8tb.112xlarge | 14 | 120 |
| u7i-12tb.224xlarge | 14 | 120 |
| u7in-16tb.224xlarge | 15 | 120 |
| u7in-24tb.224xlarge | 15 | 120 |
| u7in-32tb.224xlarge | 15 | 120 |
| u7inh-32tb.480xlarge | 15 | 120 |
| x2gd.medium | 1 | 10 |
| x2gd.large | 2 | 10 |
| x2gd.xlarge | 3 | 20 |
| x2gd.2xlarge | 3 | 40 |
| x2gd.4xlarge | 7 | 60 |
| x2gd.8xlarge | 7 | 60 |
| x2gd.12xlarge | 7 | 60 |
| x2gd.16xlarge | 14 | 120 |
| x2gd.metal | 14 | 120 |
| x2idn.16xlarge | 14 | 120 |
| x2idn.24xlarge | 14 | 120 |
| x2idn.32xlarge | 14 | 120 |
| x2idn.metal | 14 | 120 |
| x2iedn.xlarge | 3 | 13 |
| x2iedn.2xlarge | 3 | 29 |
| x2iedn.4xlarge | 7 | 60 |
| x2iedn.8xlarge | 7 | 120 |
| x2iedn.16xlarge | 14 | 120 |
| x2iedn.24xlarge | 14 | 120 |
| x2iedn.32xlarge | 14 | 120 |
| x2iedn.metal | 14 | 120 |
| x2iezn.2xlarge | 3 | 64 |
| x2iezn.4xlarge | 7 | 120 |
| x2iezn.6xlarge | 7 | 120 |
| x2iezn.8xlarge | 7 | 120 |
| x2iezn.12xlarge | 14 | 120 |
| x2iezn.metal | 14 | 120 |
| x8g.medium | 1 | 4 |
| x8g.large | 2 | 10 |
| x8g.xlarge | 3 | 20 |
| x8g.2xlarge | 3 | 40 |
| x8g.4xlarge | 7 | 60 |
| x8g.8xlarge | 7 | 60 |
| x8g.12xlarge | 7 | 60 |
| x8g.16xlarge | 14 | 120 |
| x8g.24xlarge | 14 | 120 |
| x8g.48xlarge | 14 | 120 |
| x8g.metal-24xl | 14 | 120 |
| x8g.metal-48xl | 14 | 120 |
| x8aedz. groß | 3 | 10 |
| x8aedz.x groß | 3 | 20 |
| x8aedz.3 x groß | 7 | 40 |
| x8aedz.6xgroß | 7 | 60 |
| x8aedz.12x groß | 15 | 120 |
| x8aedz.24x groß | 15 | 120 |
| x8aedz.metall-12xl | 15 | 120 |
| x8aedz.metall-24xl | 15 | 120 |
| x8i. groß | 2 | 10 |
| x8i.x groß | 3 | 20 |
| x8i.2 x groß | 3 | 40 |
| x8i.4x groß | 7 | 60 |
| x8i.8 x groß | 9 | 90 |
| x8i.12x groß | 11 | 120 |
| x8i.16x groß | 15 | 120 |
| x8i.24x groß | 15 | 120 |
| x8i.32x groß | 23 | 120 |
| x8i.48x groß | 23 | 120 |
| x8i.64x groß | 23 | 120 |
| x8i.96x groß | 23 | 120 |
| x8i.Metall-48xl | 23 | 120 |
| x8i.Metall-96xl | 23 | 120 |
## Speicheroptimiert
| Instance-Typ | Aufgabenlimit ohne ENI-Trunking | Aufgabenlimit mit ENI-Trunking |
| --- | --- | --- |
| i4g.large | 2 | 10 |
| i4g.xlarge | 3 | 20 |
| i4g.2xlarge | 3 | 40 |
| i4g.4xlarge | 7 | 60 |
| i4g.8xlarge | 7 | 60 |
| i4g.16xlarge | 14 | 120 |
| i4i.xlarge | 3 | 8 |
| i4i.2xlarge | 3 | 28 |
| i4i.4xlarge | 7 | 58 |
| i4i.8xlarge | 7 | 118 |
| i4i.12xlarge | 7 | 118 |
| i4i.16xlarge | 14 | 248 |
| i4i.24xlarge | 14 | 118 |
| i4i.32xlarge | 14 | 498 |
| i4i.metal | 14 | 498 |
| i7i.large | 2 | 10 |
| i7i.xlarge | 3 | 20 |
| i7i.2xlarge | 3 | 40 |
| i7i.4xlarge | 7 | 60 |
| i7i.8xlarge | 7 | 90 |
| i7i.12x groß | 7 | 90 |
| i7i.16x groß | 14 | 120 |
| i7i.24x groß | 14 | 120 |
| i7i.48xlarge | 14 | 120 |
| i7i.metal-24xl | 14 | 120 |
| i7i.metal-48xl | 14 | 120 |
| i7ie.large | 2 | 20 |
| i7ie.xlarge | 3 | 29 |
| i7ie.2xlarge | 3 | 29 |
| i7ie.3xlarge | 3 | 29 |
| i7ie.6xlarge | 7 | 60 |
| i7ie.12xlarge | 7 | 60 |
| i7ie.18xlarge | 14 | 120 |
| i7ie.24xlarge | 14 | 120 |
| i7ie.48xlarge | 14 | 120 |
| i7ie.metal-24xl | 14 | 120 |
| i7ie.metal-48xl | 14 | 120 |
| i8g.large | 2 | 10 |
| i8g.xlarge | 3 | 20 |
| i 8 g, 2 x groß | 3 | 40 |
| i8g.4x groß | 7 | 60 |
| i8g.8xgroß | 7 | 60 |
| i8g.12xlarge | 7 | 60 |
| i8g.16x groß | 14 | 120 |
| i8g.24xlarge | 14 | 120 |
| i8g.48xlarge | 14 | 120 |
| i8g.metal-24xl | 14 | 120 |
| i8g.metall-48xl | 14 | 120 |
| i8ge.large | 2 | 20 |
| i8ge.xlarge | 3 | 29 |
| i8ge.2xlarge | 3 | 29 |
| i8ge.3xlarge | 5 | 29 |
| i8ge.6xlarge | 9 | 60 |
| i8ge.12xlarge | 11 | 60 |
| i8ge.18xlarge | 15 | 120 |
| i8ge.24xlarge | 15 | 120 |
| i8ge.48xlarge | 23 | 120 |
| i8ge.metal-24xl | 15 | 120 |
| i8ge.metal-48xl | 23 | 120 |
| im4gn.large | 2 | 10 |
| im4gn.xlarge | 3 | 20 |
| im4gn.2xlarge | 3 | 40 |
| im4gn.4xlarge | 7 | 60 |
| im4gn.8xlarge | 7 | 60 |
| im4gn.16xlarge | 14 | 120 |
| is4gen.medium | 1 | 4 |
| is4gen.large | 2 | 10 |
| is4gen.xlarge | 3 | 20 |
| is4gen.2xlarge | 3 | 40 |
| is4gen.4xlarge | 7 | 60 |
| is4gen.8xlarge | 7 | 60 |
## Beschleunigtes Computing
| Instance-Typ | Aufgabenlimit ohne ENI-Trunking | Aufgabenlimit mit ENI-Trunking |
| --- | --- | --- |
| dl1.24xlarge | 59 | 120 |
| dl2q.24xlarge | 14 | 120 |
| f2.6xlarge | 7 | 90 |
| f2.12xlarge | 7 | 120 |
| f2.48xlarge | 14 | 120 |
| g4ad.xlarge | 1 | 12 |
| g4ad.2xlarge | 1 | 12 |
| g4ad.4xlarge | 2 | 12 |
| g4ad.8xlarge | 3 | 12 |
| g4ad.16xlarge | 7 | 12 |
| g5.xgroß | 3 | 6 |
| g5.2xgroß | 3 | 19 |
| g5.4xlarge | 7 | 40 |
| g5.8xlarge | 7 | 90 |
| g5.12xlarge | 14 | 120 |
| g5.16xlarge | 7 | 120 |
| g5.24xlarge | 14 | 120 |
| g5.48xlarge | 6 | 120 |
| g5g.xlarge | 3 | 20 |
| g5g.2xlarge | 3 | 40 |
| g5g.4xlarge | 7 | 60 |
| g5g.8xlarge | 7 | 60 |
| g5g.16xlarge | 14 | 120 |
| g5g.metal | 14 | 120 |
| g6.xlarge | 3 | 20 |
| g6.2xlarge | 3 | 40 |
| g6.4xlarge | 7 | 60 |
| g6.8xlarge | 7 | 90 |
| g6.12xlarge | 7 | 120 |
| g6.16xlarge | 14 | 120 |
| g6.24xlarge | 14 | 120 |
| g6.48xlarge | 14 | 120 |
| g6e.xlarge | 3 | 20 |
| g6e.2xlarge | 3 | 40 |
| g6e.4xlarge | 7 | 60 |
| g6e.8xlarge | 7 | 90 |
| g6e.12xlarge | 9 | 120 |
| g6e.16xlarge | 14 | 120 |
| g6e.24xlarge | 19 | 120 |
| g6e.48xlarge | 39 | 120 |
| g6f.large | 1 | 10 |
| g6f.xlarge | 3 | 20 |
| g6f.2xlarge | 3 | 40 |
| g6f.4xlarge | 7 | 60 |
| gr6.4xlarge | 7 | 60 |
| gr6.8xlarge | 7 | 90 |
| gr6f.4xlarge | 7 | 60 |
| G7E 2 x groß | 3 | 242 |
| g7e.4 x groß | 7 | 242 |
| g7e.8 x groß | 7 | 242 |
| g7e.12x groß | 9 | 242 |
| g 7 e 24 x groß | 19 | 242 |
| g 7 e 48 x groß | 39 | 242 |
| inf2.xlarge | 3 | 20 |
| inf2.8xlarge | 7 | 90 |
| inf2.24xlarge | 14 | 120 |
| inf2.48xlarge | 14 | 120 |
| p4d.24xgroß | 59 | 120 |
| p4de.24xlarge | 59 | 120 |
| p5.4xlarge | 3 | 60 |
| p5.48xlarge | 63 | 242 |
| p5e.48xlarge | 63 | 242 |
| p5en.48xlarge | 63 | 242 |
| p6-b200.48xlarge | 31 | 242 |
| p6-b 300.48x groß | 67 | 242 |
| p6e-gb200.36xlarge | 38 | 120 |
| trn1.2xlarge | 3 | 19 |
| trn1.32xlarge | 39 | 120 |
| trn1n.32xlarge | 79 | 242 |
| Trn 2,3 x groß | 1 | 14 |
| trn2.48xlarge | 31 | 242 |
| trn2u.48xlarge | 31 | 242 |
| vt1.3xlarge | 3 | 40 |
| vt1.6xlarge | 7 | 60 |
| vt1.24xlarge | 14 | 120 |
## High Performance Computing
| Instance-Typ | Aufgabenlimit ohne ENI-Trunking | Aufgabenlimit mit ENI-Trunking |
| --- | --- | --- |
| hpc6a.48xlarge | 1 | 120 |
| hpc6id.32xlarge | 1 | 120 |
| hpc7g.4xlarge | 3 | 120 |
| hpc7g.8xlarge | 3 | 120 |
| hpc7g.16xlarge | 3 | 120 |
| hpc8a.96x groß | 3 | -2 |
# Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren
Wenn der Amazon-ECS-Container-Agent eine Container-Instance in einem Cluster registriert, muss der Agent bestimmen, wie viel Arbeitsspeicher die Container-Instance zur Verfügung hat und für Ihre Aufgaben reservieren kann. Aufgrund des Speicher-Overheads der Plattform und des vom System-Kernel belegten Arbeitsspeichers weicht dieser Wert vom Wert des installierten Arbeitsspeichers ab, der für Amazon-EC2-Instances angegeben wird. Eine `m4.large`-Instance beispielsweise besitzt 8 GiB installierten Speicher. Dies bedeutet jedoch nicht immer, dass genau 8 192 MiB Arbeitsspeicher für Aufgaben zur Verfügung stehen, wenn die Container-Instance registriert wird.
## Bestimmung der Speicherressourcen für ECS Managed Instances
Amazon ECS Managed Instances verwendet einen hierarchischen Ansatz, um die Speicherressourcenanforderungen für Aufgaben zu ermitteln. Im Gegensatz zu ECS auf EC2, das auf der Speicher-Introspektion von Docker basiert, berechnet ECS Managed Instances den Speicherbedarf bei Planungsentscheidungen direkt aus der Task-Payload.
Wenn der ECS Managed Instances Agent eine Aufgabe empfängt, berechnet er den Speicherbedarf anhand der folgenden Prioritätsreihenfolge:
1. **Speicher auf Taskebene (höchste Priorität)** — Wenn in der Aufgabendefinition Speicher auf Taskebene angegeben ist, verwendet der Agent diesen Wert direkt. Dieser Wert hat Vorrang vor allen Speichereinstellungen auf Containerebene.
1. **Speichersumme auf Containerebene (Fallback)** — Wenn kein Speicher auf Taskebene angegeben ist (oder 0 ist), summiert der Agent die Speicheranforderungen aller Container in der Aufgabe. Für jeden Container verwendet er:
1. *Speicherreservierung (Soft-Limit)* — Wenn ein Container `memoryReservation` in seiner Konfiguration einen Wert angibt, verwendet der Agent diesen Wert.
1. *Container-Speicher (festes Limit)* — Wenn `memoryReservation` nicht angegeben, verwendet der Agent das `memory` Feld des Containers.
**Example Speicher auf Taskebene angegeben**
Wenn Speicher auf Aufgabenebene angegeben ist, hat dieser Vorrang vor Einstellungen auf Containerebene:
```
{
"family": "my-task",
"memory": "2048",
"containerDefinitions": [
{
"name": "container1",
"memory": 1024,
"memoryReservation": 512
}
]
}
```
Der Agent reserviert 2048 MiB (Speicher auf Taskebene hat Vorrang).
**Example Speicher auf Containerebene mit Reservierungen**
Wenn kein Speicher auf Taskebene angegeben ist, summiert der Agent die Speicheranforderungen des Containers:
```
{
"family": "my-task",
"containerDefinitions": [
{
"name": "container1",
"memory": 1024,
"memoryReservation": 512
},
{
"name": "container2",
"memory": 512
}
]
}
```
Der Agent reserviert 512 MiB (Container1-Reservierung) \$1 512 MiB (Container2-Speicher) = 1024 MiB insgesamt.
Der ECS Managed Instances Agent führt die Speicherberechnung in drei Phasen durch:
1. **Empfang von Aufgaben** — Wenn eine Task-Payload von der ECS-Steuerebene eingeht, berechnet der Agent sofort den benötigten Arbeitsspeicher.
1. **Ressourcenspeicher** — Der berechnete Speicherbedarf wird im Aufgabenmodell gespeichert, sodass er später bei der Ressourcenabrechnung verwendet werden kann.
1. **Entscheidung zur Terminplanung** — Bevor der Agent eine Aufgabe annimmt, prüft er, ob ausreichend Speicherplatz verfügbar ist. Wenn nicht genügend Speicher verfügbar ist, wird die Aufgabe zurückgewiesen und verbleibt in der ECS-Servicewarteschlange, bis Ressourcen verfügbar sind.
**Anmerkung**
Im Gegensatz zu ECS auf EC2 verwenden ECS Managed Instances die `ECS_RESERVED_MEMORY` Konfigurationsvariable nicht. Die Speicherreservierung für Systemprozesse erfolgt über das Ressourcenmanagement der zugrunde liegenden Plattform, und der Agent führt eine genaue Ressourcenabrechnung auf der Grundlage von Aufgabendefinitionen durch.
Für ECS auf EC2 stellt der Amazon ECS-Container-Agent eine Konfigurationsvariable namens bereit`ECS_RESERVED_MEMORY`, mit der Sie eine bestimmte Anzahl von MiB Speicher aus dem Pool entfernen können, der Ihren Aufgaben zugewiesen ist. Damit wird dieser Arbeitsspeicher für wichtige Systemprozesse reserviert.
Wenn Sie den gesamten Arbeitsspeicher auf einer Container-Instance mit Ihren Aufgaben belegen, kann es sein, dass Ihre Aufgabe mit wichtigen Systemprozessen um Arbeitsspeicher konkurrieren und möglicherweise einen Systemfehler auslösen.
Wenn Sie beispielsweise `ECS_RESERVED_MEMORY=256` in der Konfigurationsdatei Ihres Container-Agenten angeben, registriert der Agent den gesamten Arbeitsspeicher bis auf 256 MiB für diese Instance, und 256 MiB Arbeitsspeicher können nicht für ECS-Aufgaben zugeordnet werden. Weitere Informationen über die Konfigurationsvariablen des Agenten und ihre Einstellung finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md) und [Bootstrapping von Amazon-ECS-Linux-Container-Instances zur Weitergabe von Daten](bootstrap_container_instance.md).
Wenn Sie 8 192 MiB für die Aufgabe angeben und keine Ihrer Container-Instances 8 192 MiB oder mehr Arbeitsspeicher zur Verfügung haben, um diese Anforderung zu erfüllen, kann die Aufgabe nicht in Ihrem Cluster platziert werden. Wenn Sie eine verwaltete Rechenumgebung verwenden, AWS Batch müssen Sie einen größeren Instance-Typ starten, um der Anfrage gerecht zu werden.
Der Amazon-ECS-Container-Agent verwendet die Docker-Funktion `ReadMemInfo()` für die Abfrage des gesamten für das Betriebssystem verfügbaren Arbeitsspeichers. Sowohl Linux als auch Windows bieten bietet Befehlszeilen-Hilfsprogramme, um die Gesamtmenge an Arbeitsspeicher zu bestimmen.
**Example – Bestimmung des Gesamtspeichers für Linux**
Der Befehl **free** gibt Informationen darüber zurück, wie viel Speicher insgesamt vom Betriebssystem erkannt wird.
```
$ free -b
```
Beispielausgabe für eine `m4.large`-Instance, die das Amazon-ECS-optimierte Amazon Linux-AMI ausführt.
```
total used free shared buffers cached
Mem: 8373026816 348180480 8024846336 90112 25534464 205418496
-/+ buffers/cache: 117227520 8255799296
```
Diese Instance verfügt über 8373026816 Bytes Gesamtspeicher, und es stehen 7985 MiB für Aufgaben zur Verfügung.
**Example – Bestimmung des Gesamtspeichers für Windows**
Der Befehl **wmic** gibt Informationen darüber zurück, wie viel Speicher insgesamt vom Betriebssystem erkannt wird.
```
C:\> wmic ComputerSystem get TotalPhysicalMemory
```
Beispielausgabe für eine `m4.large`-Instance, die das Amazon-ECS-optimierte AMI für Windows Server ausführt.
```
TotalPhysicalMemory
8589524992
```
Diese Instance verfügt über 8589524992 Bytes Gesamtspeicher, und es stehen 8191 MiB für Aufgaben zur Verfügung.
## Arbeitsspeicher für Container-Instances anzeigen
Sie können in der Amazon ECS-Konsole (oder bei der [DescribeContainerInstances](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeContainerInstances.html)API-Operation) sehen, mit wie viel Speicher sich eine Container-Instance registriert. Wenn Sie versuchen, Ihre Ressourcennutzung zu maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ bereitstellen, können Sie den für diese Container-Instance verfügbaren Arbeitsspeicher beobachten und dann Ihren Aufgaben soviel Arbeitsspeicher zuordnen.
**So können Sie den Arbeitsspeicher für Container-Instances anzeigen**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie im Navigationsbereich **Cluster** und dann den Cluster aus, der Ihre Container-Instance hostet.
1. Wählen Sie **Infrastruktur** und dann unter Container-Instances eine Container-Instance aus.
1. Der Abschnitt **Ressourcen** zeigt den registrierten und verfügbaren Arbeitsspeicher für die Container-Instance an.
Der **Registrierte** Speicherwert gibt den Wert der Container-Instance an, die beim ersten Start bei Amazon ECS registriert wurde, und der **Verfügbare** Speicherwert gibt an, was noch nicht den Aufgaben zugeordnet wurde.
# Fernverwaltung von Amazon ECS-Container-Instances mithilfe von AWS Systems Manager
Sie können die Funktion Run Command in AWS Systems Manager (Systems Manager) verwenden, um die Konfiguration Ihrer Amazon ECS-Container-Instances sicher und remote zu verwalten. Run Command bietet eine einfache Möglichkeit, allgemeine Verwaltungsaufgaben ohne lokale Anmeldung bei der Instance auszuführen. Sie können Konfigurationsänderungen für all Ihre Cluster verwalten, indem Sie Befehle für mehrere Container-Instances gleichzeitig ausführen. Run Command erstellt Berichte über den Status und die Ergebnisse jedes Befehls.
Hier finden Sie einige Beispiele der Arten von Aufgaben, die Sie mit Run Command ausführen können:
+ Installieren oder deinstallieren von Paketen.
+ Ausführen von Sicherheitsupdates.
+ Bereinigen von Docker-Images.
+ Beenden oder Starten von Services.
+ Anzeigen von Systemressourcen.
+ Anzeigen von Protokolldateien.
+ Durchführen von Dateioperationen.
Weitere Informationen zu Run Command finden Sie unter [AWS Systems Manager -Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) im *AWS Systems Manager -Benutzerhandbuch*.
Im Folgenden sind die Voraussetzungen für die Verwendung von Systems Manager mit Amazon ECS aufgeführt.
1. Sie müssen der Container-Instance die Rechte role (**ecsInstanceRole**) für den Zugriff auf den Systems Manager gewähren APIs. Sie können dies tun, indem Sie der `ecsInstanceRole` Rolle **Amazon SSMManaged InstanceCore** zuweisen. Informationen zum Anhängen einer Richtlinie an eine Rolle finden Sie unter [Aktualisieren der Berechtigungen für eine Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) im *Benutzerhandbuch für AWS Identity and Access Management *.
1. Stellen Sie sicher, dass SSM Agent auf Ihrer Container-Instance installiert ist. Weitere Informationen finden Sie unter [Manuelles Installieren und Deinstallieren eines SSM-Agent auf EC2-Instances für Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html).
Nachdem Sie Ihre von Systems Manager verwalteten Richtlinien hinzugefügt haben `ecsInstanceRole` und sich vergewissert haben, dass AWS Systems Manager Agent (SSM Agent) auf Ihren Container-Instances installiert ist, können Sie mit Run Command Befehle an Ihre Container-Instances senden. Weitere Informationen zum Ausführen von Befehlen und Shell-Scripts auf Ihren Instances sowie zum Anzeigen der Ausgabe finden Sie unter [Ausführen von Befehlen mit Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) und [Run Command Walkthroughs](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command-walkthroughs.html) im *AWS Systems Manager -Benutzerhandbuch.*
Ein häufiger Anwendungsfall ist die Aktualisierung der Container-Instance-Software mit Run Command. Sie können die Verfahren im AWS Systems Manager Benutzerhandbuch mit den folgenden Parametern verfolgen.
| Parameter | Wert |
| --- | --- |
| **Befehlsdokument** | AWS-RunShellScript |
| Befehl | $ yum update -y
|
| Ziel-Instances | Ihre Container-Instances |
# Verwenden eines HTTP-Proxys für Amazon-ECS-Linux-Container-Instances
Sie können Ihre Amazon-ECS-Container-Instances für die Verwendung eines HTTP-Proxys sowohl für den Amazon-ECS-Container-Agenten als auch für den Docker-Daemon konfigurieren. Das ist praktisch, wenn Ihre Container-Instances keinen externen Netzwerkzugriff über ein Amazon VPC-Internet-Gateway, NAT-Gateway oder eine Instance haben.
Um Ihre Amazon-ECS-Linux-Container-Instance für die Verwendung eines HTTP-Proxys zu konfigurieren, bestimmen Sie beim Starten die folgenden Variablen in den relevanten Dateien (mit Amazon EC2-Benutzerdaten). Sie können die Konfigurationsdatei auch manuell bearbeiten und den Agenten anschließend neu starten.
`/etc/ecs/ecs.config`(Amazon Linux 2und AmazonLinux AMI)
`HTTP_PROXY=10.0.0.131:3128`
Legen Sie diesen Wert auf den Host-Namen (oder die IP-Adresse) und die Portnummer eines HTTP-Proxys fest, den der Amazon ECS-Agent verwenden soll, um eine Verbindung zum Internet herzustellen. Beispielsweise haben Ihre Container-Instances vielleicht keinen externen Netzwerkzugriff über ein Amazon VPC-Internet-Gateway, NAT-Gateway oder eine Instance.
`NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`
Setzen Sie diesen Wert auf `169.254.169.254,169.254.170.2,/var/run/docker.sock`, um die Amazon-EC2-Instance-Metadaten, IAM-Rollen für Aufgaben und Docker-Daemon-Datenverkehr aus dem Proxy zu filtern.
`/etc/systemd/system/ecs.service.d/http-proxy.conf` (nur Amazon Linux 2)
`Environment="HTTP_PROXY=10.0.0.131:3128/"`
Setzen Sie diesen Wert auf den Hostname (oder die IP-Adresse) und die Portnummer eines HTTP-Proxys, sodass mit `ecs-init` eine Internetverbindung aufgebaut werden kann. Beispielsweise haben Ihre Container-Instances vielleicht keinen externen Netzwerkzugriff über ein Amazon VPC-Internet-Gateway, NAT-Gateway oder eine Instance.
`Environment="NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock"`
Setzen Sie diesen Wert auf `169.254.169.254,169.254.170.2,/var/run/docker.sock`, um die Amazon-EC2-Instance-Metadaten, IAM-Rollen für Aufgaben und Docker-Daemon-Datenverkehr aus dem Proxy zu filtern.
`/etc/init/ecs.override` (nur Amazon-Linux-AMI)
`env HTTP_PROXY=10.0.0.131:3128`
Setzen Sie diesen Wert auf den Hostname (oder die IP-Adresse) und die Portnummer eines HTTP-Proxys, sodass mit `ecs-init` eine Internetverbindung aufgebaut werden kann. Beispielsweise haben Ihre Container-Instances vielleicht keinen externen Netzwerkzugriff über ein Amazon VPC-Internet-Gateway, NAT-Gateway oder eine Instance.
`env NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`
Setzen Sie diesen Wert auf `169.254.169.254,169.254.170.2,/var/run/docker.sock`, um die Amazon-EC2-Instance-Metadaten, IAM-Rollen für Aufgaben und Docker-Daemon-Datenverkehr aus dem Proxy zu filtern.
`/etc/systemd/system/docker.service.d/http-proxy.conf` (nur Amazon Linux 2)
`Environment="HTTP_PROXY=http://10.0.0.131:3128"`
Setzen Sie diesen Wert auf den Hostname (oder die IP-Adresse) und die Portnummer eines HTTP-Proxys, sodass der Docker-Daemon damit eine Internetverbindung aufbauen kann. Beispielsweise haben Ihre Container-Instances vielleicht keinen externen Netzwerkzugriff über ein Amazon VPC-Internet-Gateway, NAT-Gateway oder eine Instance.
`Environment="NO_PROXY=169.254.169.254,169.254.170.2"`
Setzen Sie diesen Wert auf `169.254.169.254,169.254.170.2`, um EC2 Instance-Metadaten aus dem Proxy zu filtern.
`/etc/sysconfig/docker` (Amazon Linux AMI und nur Amazon Linux 2)
`export HTTP_PROXY=http://10.0.0.131:3128`
Setzen Sie diesen Wert auf den Hostname (oder die IP-Adresse) und die Portnummer eines HTTP-Proxys, sodass der Docker-Daemon damit eine Internetverbindung aufbauen kann. Beispielsweise haben Ihre Container-Instances vielleicht keinen externen Netzwerkzugriff über ein Amazon VPC-Internet-Gateway, NAT-Gateway oder eine Instance.
`export NO_PROXY=169.254.169.254,169.254.170.2`
Setzen Sie diesen Wert auf `169.254.169.254,169.254.170.2`, um EC2 Instance-Metadaten aus dem Proxy zu filtern.
Die Festlegung dieser Umgebungsvariablen in den oben genannten Dateien wirkt sich nur auf den Amazon ECS Container-Agenten, `ecs-init` und den Docker-Daemon aus. Sie konfigurieren keine anderen Services (z. B. **yum**) für die Nutzung des Proxy.
Informationen zur Konfiguration des Proxys finden Sie unter [Wie richte ich einen HTTP-Proxy für Docker und den Amazon ECS-Container-Agenten in Amazon Linux ein 2](https://repost.aws/knowledge-center/ecs-http-proxy-docker-linux2) oder. AL2023
# Konfiguration vorinitialisierter Instances für Ihre Auto-Scaling-Gruppe in Amazon ECS
Amazon ECS unterstützt Warm-Pools für Amazon EC2 Auto Scaling. Ein Warm-Pool ist eine Gruppe von vorinitialisierten Amazon-EC2-Instances, die bereit sind, in Betrieb genommen zu werden. Wann immer Ihre Anwendung aufskaliert werden muss, verwendet Amazon EC2 Auto Scaling die vorinitialisierten Instances aus dem Warm-Pool, anstatt kalte Instances zu launchen, erlaubt die Ausführung eines endgültigen Initialisierungsprozesses und stellt die Instance dann in Betrieb.
Weitere Informationen zu Warm-Pools und zum Hinzufügen eines Warm-Pools zu Ihrer Auto-Scaling-Gruppe finden Sie unter [Warm-Pools für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html) *im Benutzerhandbuch zu Amazon EC2 Auto Scaling*.
Wenn Sie einen Warm-Pool für eine Auto-Scaling-Gruppe für Amazon ECS erstellen oder aktualisieren, können Sie die Option nicht festlegen, mit der Instances an den Warm-Pool beim Abskalieren zurückgegeben werden (`ReuseOnScaleIn`). Weitere Informationen finden Sie unter [put-warm-pool](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-warm-pool.html) in der *AWS Command Line Interface -Referenz*.
Um Warm-Pools mit Ihrem Amazon-ECS-Cluster zu verwenden, setzen Sie die Agent-Konfigurationsvariable `ECS_WARM_POOLS_CHECK` im Feld **User data** (Benutzerdaten) der Launchvorlage Ihrer Amazon-EC2-Auto-Scaling-Gruppe auf `true`.
Das folgende Beispiel zeigt, wie die Agent-Konfigurationsvariable im Feld **User data** (Benutzerdaten) einer Amazon-EC2-Launchvorlage angegeben werden kann. Ersetzen Sie es *MyCluster* durch den Namen Ihres Clusters.
```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_WARM_POOLS_CHECK=true
EOF
```
Diese Variable `ECS_WARM_POOLS_CHECK` wird nur von den Agenten-Versionen `1.59.0` oder höher unterstützt. Weitere Informationen zu der Variablen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
# Überprüfen des Amazon-ECS-Container-Agenten
Sie müssen den Amazon-ECS-Container-Agent möglicherweise gelegentlich aktualisieren, um Fehlerbehebungen und neue Features darin aufzunehmen. Durch die Aktualisierung des Amazon-ECS-Container-Agenten werden laufende Aufgaben oder Services auf der Container-Instance nicht unterbrochen. Der Aktualisierungsprozess hängt davon ab, ob Ihre Container-Instance mit dem Amazon-ECS-optimierten AMI oder mit einem anderen Betriebssystem gestartet wurde.
**Anmerkung**
Agent-Updates gelten nicht für Windows-Container-Instances. Wir empfehlen, dass Sie die neuen Container-Instances starten, um die Agent-Version in Ihren Windows-Clustern zu aktualisieren.
## Überprüfen der Amazon-ECS-Container-Agent-Version
Sie können die Version des Container-Agenten, der auf Ihren Container-Instances ausgeführt wird prüfen, um festzustellen, ob eine Aktualisierung erforderlich ist. Sie finden die Agenten-Version in der Container-Instance-Ansicht der Amazon-ECS-Konsole. Gehen Sie zum Prüfen Ihrer Agenten-Version wie folgt vor:
------
#### [ Amazon ECS console ]
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Wählen Sie auf der Navigationsleiste die Region aus, in der Ihre externe Instance registriert ist.
1. Wählen Sie im Navigationsbereich **Clusters** und danach den Cluster aus, der Ihre externe Instance hostet.
1. Wählen Sie auf der *name* Seite **Cluster:** die Registerkarte **Infrastruktur** aus.
1. Beachten Sie unter **Container instances** (Container-Instances) die Spalte **Agent version** (Agent-Version) für Ihre Container-Instances. Wenn die Container-Instance nicht die neueste Container-Agent-Version enthält, erhalten Sie von der Konsole eine Nachricht, die Sie auf die veraltete Version des Agenten hinweist.
Wenn die Agentenversion veraltet ist, können Sie den Container-Agenten wie folgt aktualisieren:
+ Wenn Ihre Container-Instance das Amazon-ECS-optimierte AMI ausführt, gehen Sie zu [Aktualisieren des Amazon-ECS-Container-Agenten auf einem Amazon-ECS-optimierten AMI](agent-update-ecs-ami.md).
+ Wenn Ihre Container-Instance das Amazon-ECS-optimierte AMI nicht ausführt, gehen Sie zu [Manuelles Aktualisieren des Amazon ECS-Container-Agenten (für nicht für Amazon AMIs ECS optimierte Systeme)](manually_update_agent.md).
**Wichtig**
Für die Aktualisierung der Amazon-ECS-Agenten-Version mit Versionen vor 1.0.0 auf Ihrem Amazon-ECS-optimierten AMI empfehlen wir Ihnen, zunächst die aktuelle Container-Instance zu beenden und dann eine Instance mit dem aktuellen AMI zu starten. Alle Container-Instances, die eine Vorversion verwenden, sollten durch die aktuelle AMI-Version ersetzt werden. Weitere Informationen finden Sie unter [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
------
#### [ Amazon ECS container agent introspection API ]
Sie können auch den Agenten verwenden, um die Version der Introspektions-API des Amazon-ECS-Container-Agenten in der Container-Instance selbst abzurufen. Weitere Informationen finden Sie unter [Amazon-ECS-Container-Introspektion](ecs-agent-introspection.md).
**So prüfen Sie, ob Ihr Amazon-ECS-Container-Agent die neueste Version in der Introspektions-API verwendet**
1. Melden Sie sich bei Ihrer Container-Instance über SSH an.
1. Fragen Sie die Introspektions-API ab.
```
[ec2-user ~]$ curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
```
**Anmerkung**
Die Introspektions-API hat `Version`-Informationen zur Version 1.0.0 des Amazon-ECS-Container-Agenten hinzugefügt. Wenn `Version` beim Abfragen der Introspektions-API nicht, bzw. die Introspektions-API überhaupt nicht in Ihrem Agenten vorhanden ist, dann bedeutet das, dass die von Ihnen verwendete Version v.0.03 oder älter ist. Sie sollten Ihre Version aktualisieren.
------
# Aktualisieren des Amazon-ECS-Container-Agenten auf einem Amazon-ECS-optimierten AMI
Wenn Sie das Amazon-ECS-optimierte AMI verwenden, stehen Ihnen die folgenden Optionen für die Aktualisierung des Amazon-ECS-Container-Agenten zur Verfügung (Auflistung nach Empfehlungsreihenfolge):
+ Beenden Sie Ihre aktuellen Container-Instances und starten Sie die aktuelle Version des Amazon-ECS-optimierten Amazon Linux 2-AMI (entweder manuell oder durch Aktualisierung Ihrer Auto Scaling-Startkonfiguration mit dem neuesten AMI). So erhalten Sie eine neue Container-Instance mit den aktuellen getesteten und validierten Versionen von Amazon Linux, Docker, `ecs-init` und Amazon-ECS-Container-Agent. Weitere Informationen finden Sie unter [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md).
+ Verbinden Sie sich über SSH mit der Instance und aktualisieren Sie das `ecs-init`-Paket (sowie seine Abhängigkeiten) auf die neueste Version. Dieser Vorgang liefert die aktuellsten getesteten und validierten Versionen von Docker und `ecs-init`, die in den Amazon Linux-Repositories verfügbar sind, sowie die neueste Version des Amazon-ECS-Container-Agenten. Weitere Informationen finden Sie unter [So aktualisieren Sie das `ecs-init`-Paket auf dem Amazon-ECS-optimierten AMI](#procedure_update_ecs-init).
+ Aktualisieren Sie den Container-Agenten mit dem `UpdateContainerAgent` API-Vorgang, entweder über die Konsole oder mit dem AWS CLI oder AWS SDKs. Weitere Informationen finden Sie unter [Aktualisieren des Amazon-ECS-Container-Agenten mit der `UpdateContainerAgent`-API-Operation](#agent-update-api).
**Anmerkung**
Agent-Updates gelten nicht für Windows-Container-Instances. Wir empfehlen, dass Sie die neuen Container-Instances starten, um die Agent-Version in Ihren Windows-Clustern zu aktualisieren.
**So aktualisieren Sie das `ecs-init`-Paket auf dem Amazon-ECS-optimierten AMI**
1. Melden Sie sich bei Ihrer Container-Instance über SSH an.
1. Aktualisieren Sie das `ecs-init`-Paket mit dem folgenden Befehl.
```
sudo yum update -y ecs-init
```
**Anmerkung**
Das `ecs-init`-Paket und der Amazon-ECS-Container-Agent werden sofort aktualisiert. Neuere Versionen von Docker werden jedoch nicht geladen, bis der Docker-Daemon neu gestartet wird. Machen Sie einen Neustart, indem Sie entweder die Instance neu starten oder die folgenden Befehle auf Ihrer Instance ausführen:
Amazon-ECS-optimiertes Amazon Linux 2-AMI:
```
sudo systemctl restart docker
```
Amazon-ECS-optimiertes Amazon Linux AMI:
```
sudo service docker restart && sudo start ecs
```
## Aktualisieren des Amazon-ECS-Container-Agenten mit der `UpdateContainerAgent`-API-Operation
**Wichtig**
Die `UpdateContainerAgent`-API wird nur auf Linux-Varianten des Amazon-ECS-optimierten AMI unterstützt, mit Ausnahme des Amazon-ECS-optimierten Amazon Linux 2 (arm64) AMI. Für Container-Instances, die das Amazon-ECS-optimierte Amazon Linux 2 (arm64) -AAMI verwenden, aktualisieren Sie das `ecs-init`-Paket, um den Agenten zu aktualisieren. Informationen zu Container-Instances, die auf anderen Betriebssystemen laufen, finden Sie unter [Manuelles Aktualisieren des Amazon ECS-Container-Agenten (für nicht für Amazon AMIs ECS optimierte Systeme)](manually_update_agent.md). Sollten Sie Windows-Container-Instances nutzen, empfehlen wir, dass Sie die neuen Container-Instances starten, um die Agent-Version in Ihren Windows-Clustern zu aktualisieren.
Der `UpdateContainerAgent` API-Prozess beginnt, wenn Sie ein Agent-Update anfordern, entweder über die Konsole oder mit dem AWS CLI oder AWS SDKs. Amazon ECS prüft, ob Ihre derzeitige Agent-Version der neuesten verfügbaren Agent-Version entspricht und ob eine Aktualisierung verfügbar ist. Wenn keine Aktualisierung verfügbar ist, beispielsweise, wenn der Agent bereits mit der neuesten Version läuft, wird eine `NoUpdateAvailableException` zurückgegeben.
Der oben genannte Aktualisierungsprozess umfasst folgende Schritte:
`PENDING`
Ein Agent-Aktualisierung ist verfügbar und der Aktualisierungsprozess wurde gestartet.
`STAGING`
Der Agent hat mit dem Herunterladen der Agent-Aktualisierung begonnen. Wenn der Agent die Aktualisierung nicht herunterladen kann oder wenn der Inhalt der Aktualisierung falsch oder korrupt ist, sendet der Agent eine Benachrichtigung des Fehlers und die Aktualisierung geht in den `FAILED`-Status über.
`STAGED`
Das Herunterladen des Agent ist abgeschlossen und die Agent-Inhalte wurden bestätigt.
`UPDATING`
Der `ecs-init`-Service wird mit der neuen Agenten-Version neu gestartet. Wenn der Agent nicht neu starten kann, geht die Aktualisierung in den `FAILED`-Status über. Andernfalls zeigt der Agent Amazon ECS an, dass die Aktualisierung nicht abgeschlossen wurde.
**Anmerkung**
Agent-Updates gelten nicht für Windows-Container-Instances. Wir empfehlen, dass Sie die neuen Container-Instances starten, um die Agent-Version in Ihren Windows-Clustern zu aktualisieren.
**So aktualisieren Sie im Amazon-ECS-optimierten AMI in der Konsole den Amazon-ECS-Container-Agenten**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie auf der Navigationsleiste die Region aus, in der Ihre externe Instance registriert ist.
1. Wählen Sie im Navigationsbereich **Clusters** und dann den Cluster aus.
1. Wählen Sie auf der *name* Seite **Cluster:** die Registerkarte **Infrastruktur** aus.
1. Wählen Sie unter **Container-Instances** die zu aktualisierenden Instances aus, und wählen Sie dann **Aktionen**, **Agent aktualisieren**.
# Manuelles Aktualisieren des Amazon ECS-Container-Agenten (für nicht für Amazon AMIs ECS optimierte Systeme)
Sie müssen den Amazon-ECS-Container-Agent möglicherweise gelegentlich aktualisieren, um Fehlerbehebungen und neue Features darin aufzunehmen. Durch die Aktualisierung des Amazon-ECS-Container-Agenten werden laufende Aufgaben oder Services auf der Container-Instance nicht unterbrochen.
**Anmerkung**
Agent-Updates gelten nicht für Windows-Container-Instances. Wir empfehlen, dass Sie die neuen Container-Instances starten, um die Agent-Version in Ihren Windows-Clustern zu aktualisieren.
1. Melden Sie sich bei Ihrer Container-Instance über SSH an.
1. Überprüfen Sie, ob ihr Agent die Umgebungsvariable `ECS_DATADIR` nutzt, um seinen Status zu speichern.
```
ubuntu:~$ docker inspect ecs-agent | grep ECS_DATADIR
```
Ausgabe:
```
"ECS_DATADIR=/data",
```
**Wichtig**
Wenn der vorherige Befehl die Umgebungsvariable `ECS_DATADIR` nicht zurücksendet, müssen Sie sämtliche Aufgaben, die auf dieser Container-Instance ausgeführt werden, abbrechen, bevor Sie Ihren Agenten aktualisieren. Neuere Agenten mit der Umgebungsvariable `ECS_DATADIR` speichern ihren Status und Sie können sie aktualisieren, während Aufgaben problemlos ausgeführt werden.
1. Halten Sie den Amazon-ECS-Container-Agent an.
```
ubuntu:~$ docker stop ecs-agent
```
1. Löschen Sie den Agent-Container.
```
ubuntu:~$ docker rm ecs-agent
```
1. Stellen Sie sicher, dass das `/etc/ecs`-Verzeichnis und die Konfigurationsdatei für den Amazon-ECS-Container-Agenten unter `/etc/ecs/ecs.config` vorhanden sind.
```
ubuntu:~$ sudo mkdir -p /etc/ecs && sudo touch /etc/ecs/ecs.config
```
1. Bearbeiten Sie die Datei `/etc/ecs/ecs.config` und stellen Sie sicher, dass sie mindestens die folgenden Variablendeklarationen enthält. Wenn Sie nicht möchten, dass Ihre Container-Instance im Default-Cluster registriert wird, legen Sie Ihren Cluster-Namen als einen Wert für `ECS_CLUSTER` fest.
```
ECS_DATADIR=/data
ECS_ENABLE_TASK_IAM_ROLE=true
ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true
ECS_LOGFILE=/log/ecs-agent.log
ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
ECS_LOGLEVEL=info
ECS_CLUSTER=default
```
Weitere Informationen zu diesen und anderen Agenten-Laufzeitoptionen erhalten Sie unter[Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
**Anmerkung**
Sie können Ihre Agenten-Umgebungsvariablen optional in Amazon S3 speichern (diese können in Ihren Container-Instances zum Startzeitpunkt mithilfe von Amazon EC2-Benutzerdaten heruntergeladen werden). Dies empfiehlt sich für sensible Daten, wie beispielsweise Authentifizierungs-Anmeldeinformationen für private Repositorys. Weitere Informationen erhalten Sie unter [Speichern der Konfiguration von Amazon-ECS-Container-Instances in Amazon S3](ecs-config-s3.md) und [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
1. Rufen Sie das neueste Image für den Amazon-ECS-Container-Agent von Amazon-Elastic-Container-Registry-Public ab.
```
ubuntu:~$ docker pull public.ecr.aws/ecs/amazon-ecs-agent:latest
```
Ausgabe:
```
Pulling repository amazon/amazon-ecs-agent
a5a56a5e13dc: Download complete
511136ea3c5a: Download complete
9950b5d678a1: Download complete
c48ddcf21b63: Download complete
Status: Image is up to date for amazon/amazon-ecs-agent:latest
```
1. Führen Sie den neuesten Amazon-ECS-Container-Agenten in Ihrer Container-Instance aus.
**Anmerkung**
Verwenden Sie Docker-Neustartrichtlinien oder einen Prozessmanager (wie **upstart** oder **systemd**), um den Container-Agenten als Service oder Daemon zu behandeln und sicherzustellen, dass dieser nach dem Beenden wieder gestartet wird. Das Amazon ECS-optimierte AMI verwendet das `ecs-init` RPM für diesen Zweck, und Sie können den [Quellcode für dieses RPM](https://github.com/aws/amazon-ecs-init) unter einsehen. GitHub
Das folgende Beispiel des Agenten-Ausführungsbefehls ist auf mehrere Zeilen verteilt, um die Optionen deutlicher darzustellen. Weitere Informationen zu diesen und anderen Agenten-Laufzeitoptionen erhalten Sie unter[Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
**Wichtig**
Für Betriebssysteme mit SELinux aktivierter Option ist die `--privileged` Option in Ihrem **docker run** Befehl erforderlich. Darüber hinaus empfehlen wir für Container-Instances mit SELinux aktivierter Option, die `:Z` Option zu den Volume Mounts `/log` und den `/data` Volume Mounts hinzuzufügen. Die Host-Mounts für diese Volumes müssen jedoch vorhanden sein, bevor Sie den Befehl ausführen. Andernfalls erhalten Sie die Fehlermeldung `no such file or directory`. Gehen Sie wie folgt vor, wenn Sie Schwierigkeiten haben, den Amazon ECS-Agenten auf einer SELinux -fähigen Container-Instance auszuführen:
Erstellen Sie auf Ihrer Container-Instance Mounting-Punkte für Hoste-Volume.
```
ubuntu:~$ sudo mkdir -p /var/log/ecs /var/lib/ecs/data
```
Fügen Sie die Option `--privileged` zum unteren Befehl **docker run** hinzu.
Fügen Sie die Option `:Z` zu den Container-Volume-Mounts `/log` und `/data` (z. B. `--volume=/var/log/ecs/:/log:Z`) zum unteren Befehl **docker run** hinzu.
```
ubuntu:~$ sudo docker run --name ecs-agent \
--detach=true \
--restart=on-failure:10 \
--volume=/var/run:/var/run \
--volume=/var/log/ecs/:/log \
--volume=/var/lib/ecs/data:/data \
--volume=/etc/ecs:/etc/ecs \
--volume=/etc/ecs:/etc/ecs/pki \
--net=host \
--env-file=/etc/ecs/ecs.config \
amazon/amazon-ecs-agent:latest
```
**Anmerkung**
Wenn Sie die Meldung `Error response from daemon: Cannot start container` erhalten, können Sie den fehlerhaften Container mit dem Befehl **sudo docker rm ecs-agent** löschen und den Agenten neu starten.
# Amazon ECS-optimiertes Windows AMIs
Die Amazon ECS-optimierten AMIs sind mit den erforderlichen Komponenten vorkonfiguriert, die Sie für die Ausführung von Amazon ECS-Workloads benötigen. Sie können zwar Ihr eigenes Container-Instance-AMI erstellen, das die grundlegenden Spezifikationen erfüllt, die für die Ausführung Ihrer containerisierten Workloads auf Amazon ECS erforderlich sind, aber die Amazon ECS-optimierten AMIs sind vorkonfiguriert und wurden von Technikern auf Amazon ECS getestet. AWS Dies ist die einfachste Methode für den Einstieg, mit dem Ihre Container in AWS schnell einsatzbereit werden.
Die Amazon-ECS-optimierten AMI-Metadaten, einschließlich des AMI-Namens, der Version des Amazon-ECS-Container-Agents und der Amazon-ECS-Laufzeitversion, die die Docker-Version enthält, können für jede Variante programmgesteuert abgerufen werden. Weitere Informationen finden Sie unter [Abrufen der Amazon-ECS-optimierten Windows-AMI-Metadaten](retrieve-ecs-optimized_windows_AMI.md).
**Wichtig**
Alle ECS-optimierten AMI-Varianten, die nach August 2022 produziert wurden, werden von Docker EE (Mirantis) auf Docker CE (Moby-Projekt) migriert.
Um sicherzustellen, dass Kunden standardmäßig über die neuesten Sicherheitsupdates verfügen, verwaltet Amazon ECS mindestens die letzten drei für Amazon AMIs ECS optimierten Windows-Versionen. Nach der Veröffentlichung des neuen Amazon ECS-optimierten AMIs Windows macht Amazon ECS die für Amazon ECS optimierten Windows, die älter sind AMIs , privat. Wenn es ein privates AMI gibt, auf das Sie zugreifen müssen, lassen Sie es uns wissen, indem Sie ein Ticket beim Cloud Support einreichen.
## Amazon-ECS-optimierte AMI-Varianten
Die folgenden Windows Server-Varianten des Amazon-ECS-optimierten AMI sind für Ihre Amazon-EC2-Instances verfügbar.
**Wichtig**
Alle ECS-optimierten AMI-Varianten, die nach August produziert wurden, werden von Docker EE (Mirantis) auf Docker CE (Moby-Projekt) migriert.
+ **Vollständiges AMI für Amazon ECS für Windows Server 2025**
+ **Amazon ECS-optimiertes Windows Server 2025 Core-AMI**
+ **Amazon-ECS-optimierter Windows Server 2022 Full AMI**
+ **Amazon-ECS-optimierter Windows Server 2022 Core AMI**
+ **Amazon-ECS-optimierter Windows Server 2019 Full AMI**
+ **Amazon-ECS-optimierter Windows Server 2019 Core AMI**
+ **Amazon-ECS-optimierter Windows Server 2016 Full AMI**
**Wichtig**
Windows Server 2016 unterstützt nicht die neueste Docker-Version, zum Beispiel 25.x.x. Daher erhält Windows Server 2016 Full AMIs keine Sicherheits- oder Bug-Patches für die Docker-Laufzeit. Es wird empfohlen, dass Sie auf eine der folgenden Windows-Plattformen wechseln:
Windows Server 2022 Voll
Windows Server 2022 Kern
Windows Server 2019 Voll
Windows Server 2019 Kern
Am 9. August 2022 erreichte das Amazon-ECS-optimierte Windows Server 20H2 Core AMI das Enddatum des Supports. Es werden keine neuen Versionen dieses AMI veröffentlicht. Weitere Informationen finden Sie unter [Windows Server-Versionsinformationen](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info).
Windows Server 2025, Windows Server 2022, Windows Server 2019 und Windows Server 2016 sind Long-Term Servicing Channel (LTSC)-Versionen. Windows Server 20H2 ist eine Semi-Annual Channel (SAC)-Version. Weitere Informationen finden Sie unter [Windows Server-Versionsinformationen](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info).
### Überlegungen
Hier sind einige Dinge, die Sie über Amazon-EC2-Windows-Container und Amazon ECS wissen sollten.
+ Windows-Container können nicht auf Linux-Container-Instances ausgeführt werden, und ebenso anders herum. Um sicherzustellen, dass die Aufgaben für Windows und Linux richtig platziert werden, bringen Sie Windows- und Linux-Container-Instances in separaten Clustern unter. Windows-Aufgaben sollten nur in Windows-Clustern platziert werden. Sie können sicherstellen, dass Windows-Aufgabendefinitionen nur auf Windows-Instances platziert werden, indem Sie die folgende Platzierungsbedingung einrichten: `memberOf(ecs.os-type=='windows')`.
+ Windows-Container werden für Aufgaben unterstützt, die EC2 und Fargate verwenden.
+ Windows-Container und Windows-Container-Instances unterstützen nicht alle Parameter für Aufgabendefinitionen, die für Linux-Container und Linux-Container-Instances verfügbar sind. Einige Parameter werden gar nicht unterstützt, andere verhalten sich auf Windows und Linux unterschiedlich. Weitere Informationen finden Sie unter [Unterschiede bei der Amazon-ECS-Aufgabendefinition für EC2-Instances, auf denen Windows ausgeführt wird](windows_task_definitions.md).
+ Sie müssen für das Feature „IAM-Rollen für Aufgaben“ Ihre Windows-Container-Instances so konfigurieren, dass das Feature beim Starten zugelassen wird. Ihre Container müssen den bereitgestellten PowerShell Code ausführen, wenn sie die Funktion verwenden. Weitere Informationen finden Sie unter [Zusätzliche Konfiguration der Amazon-EC2-Windows-Instances](task-iam-roles.md#windows_task_IAM_roles).
+ Das Feature „IAM-Rollen für Aufgaben“ verwendet einen speziellen Proxy, um Anmeldeinformationen für die Container bereitzustellen. Dieser Proxy für Anmeldeinformationen belegt Port 80 auf der Container-Instance. Wenn Sie also „IAM-Rollen für Aufgaben“ verwenden, ist Port 80 für Aufgaben nicht verfügbar. Für Webservice-Container können Sie einen Application Load Balancer und die dynamische Port-Zuweisung verwenden, um Ihren Containern standardmäßige HTTP-Verbindungen über Port 80 bereitzustellen. Weitere Informationen finden Sie unter [Verwenden von Load Balancing für die Verteilung des Service-Datenverkehrs in Amazon ECS](service-load-balancing.md).
+ Die Docker-Images des Windows-Servers sind groß (9 GiB). Also benötigen Ihre Windows-Container-Instances mehr Speicherplatz als Linux-Container-Instances.
+ Um einen Windows-Container auf einem Windows-Server ausführen zu können, muss die Betriebssystemversion des Basis-Image des Containers mit der des Hosts übereinstimmen. Weitere Informationen finden Sie unter [Kompatibilität mit Windows-Containern](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11) auf der Microsoft-Dokumentations-Website. Wenn auf Ihrem Cluster mehrere Windows-Versionen ausgeführt werden, können Sie mithilfe der Platzierungsbeschränkung `memberOf(attribute:ecs.os-family == WINDOWS_SERVER__)` sicherstellen, dass eine Aufgabe auf einer EC2-Instance platziert wird, die auf derselben Version ausgeführt wird. Weitere Informationen finden Sie unter [Abrufen der Amazon-ECS-optimierten Windows-AMI-Metadaten](retrieve-ecs-optimized_windows_AMI.md).
# Abrufen der Amazon-ECS-optimierten Windows-AMI-Metadaten
Die AMI-ID, der Image-Name, das Betriebssystem, die Container-Agent-Version und die Laufzeitversion für jede Variante des Amazon ECS-optimierten Produkts AMIs können programmgesteuert abgerufen werden, indem die Systems Manager Parameter Store-API abgefragt wird. Weitere Informationen zur Systems Manager Parameter Store-API finden Sie unter [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html)und [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html).
**Anmerkung**
Ihr administrativer Benutzer muss über die folgenden IAM-Berechtigungen verfügen, um die Amazon-ECS-optimierten AMI-Metadaten abzurufen. Diese Berechtigungen wurden der `AmazonECS_FullAccess`-IAM-Richtlinie hinzugefügt.
ssm: GetParameters
ssm: GetParameter
ssm: GetParametersByPath
## Systems Manager Parameterspeicher-Parameterformat
**Anmerkung**
Die folgenden Systems Manager Parameter Store-API-Parameter sind veraltet und sollten nicht zum Abrufen der neuesten Windows-Version verwendet werden: AMIs
`/aws/service/ecs/optimized-ami/windows_server/2016/english/full/recommended/image_id `
`/aws/service/ecs/optimized-ami/windows_server/2019/english/full/recommended/image_id`
Im Folgenden ist das Format des Parameternamens für jede Amazon-ECS-optimierte AMI-Variante aufgeführt.
+ Vollständige AMI-Metadaten für Windows Server 2025:
```
/aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
```
+ Windows Server 2025 Core AMI-Metadaten:
```
/aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
```
+ Metadaten von Windows Server 2022 Full AMI:
```
/aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
```
+ Metadaten von Windows Server 2022 Core AMI:
```
/aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
```
+ Windows Server 2019 Full AMI-Metadaten:
```
/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```
+ Windows Server 2019 Core AMI-Metadaten:
```
/aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
```
+ Windows Server 2016 Full AMI-Metadaten:
```
/aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
```
Das folgende Parameter-Namensformat ruft die Metadaten des neuesten stabilen Windows Server 2019 Full AMI ab
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```
Nachstehend finden Sie ein Beispiel des JSON-Objekts, das für den Parameterwert zurückgegeben wird.
```
{
"Parameters": [
{
"Name": "/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
"Type": "String",
"Value": "{\"image_name\":\"Windows_Server-2019-English-Full-ECS_Optimized-2023.06.13\",\"image_id\":\"ami-0debc1fb48e4aee16\",\"ecs_runtime_version\":\"Docker (CE) version 20.10.21\",\"ecs_agent_version\":\"1.72.0\"}",
"Version": 58,
"LastModifiedDate": "2023-06-22T19:37:37.841000-04:00",
"ARN": "arn:aws:ssm:us-east-1::parameter/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
"DataType": "text"
}
],
"InvalidParameters": []
}
```
Jedes der Felder oben in der Ausgabe steht zur Abfrage als Sub-Parameter zur Verfügung. Erstellen Sie den Parameterpfad für einen Sub-Parameter, indem Sie den Sub-Parameternamen an den Pfad für das ausgewählte AMI anhängen. Die folgenden Sub-Parameter sind verfügbar:
+ `schema_version`
+ `image_id`
+ `image_name`
+ `os`
+ `ecs_agent_version`
+ `ecs_runtime_version`
## Beispiele
Die folgenden Beispiele zeigen, wie Sie die Metadaten für jede Amazon-ECS-optimierte AMI-Variante abrufen können.
### Abrufen der Metadaten des neuesten stabilen Amazon-ECS-optimierten AMI
Sie können das neueste stabile Amazon ECS-optimierte AMI AWS CLI mit den folgenden AWS CLI Befehlen abrufen.
+ **Für das Amazon ECS-optimierte Windows Server 2025 Full AMI:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized --region us-east-1
```
+ **Für das Amazon ECS-optimierte Windows Server 2025 Core AMI:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized --region us-east-1
```
+ **Für das Amazon-ECS-optimierte Windows Server 2022 Full AMI:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized --region us-east-1
```
+ **Für das Amazon-ECS-optimierte Windows Server 2022 Core AMI:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized --region us-east-1
```
+ **Für das Amazon-ECS-optimierte Windows Server 2019 Full AMI:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized --region us-east-1
```
+ **Für das Amazon-ECS-optimierte Windows Server 2019 Core AMI:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized --region us-east-1
```
+ **Für das Amazon-ECS-optimierte Windows Server 2016 Full AMI:**
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized --region us-east-1
```
### Verwenden des neuesten empfohlenen Amazon ECS-optimierten AMI in einer Vorlage CloudFormation
Sie können auf das neueste empfohlene Amazon-ECS-optimierte AMI in einer CloudFormation -Vorlage verweisen, indem Sie auf den Systems Manager Parameterspeichernamen verweisen.
```
Parameters:
LatestECSOptimizedAMI:
Description: AMI ID
Type: AWS::SSM::Parameter::Value
Default: /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized/image_id
```
# Amazon-ECS-optimierte Windows-AMIs-Versionen
Sehen Sie sich die aktuellen und früheren Versionen von Amazon ECS-Optimized AMIs und die entsprechenden Versionen des Amazon ECS-Container-Agenten, Docker und des Pakets an. `ecs-init`
Die Amazon-ECS-optimierten AMI-Metadaten, einschließlich der AMI-ID für jede Variante, können programmgesteuert abgerufen werden. Weitere Informationen finden Sie unter [Abrufen der Amazon-ECS-optimierten Windows-AMI-Metadaten](retrieve-ecs-optimized_windows_AMI.md).
Auf den folgenden Registerkarten wird eine Liste der für Windows Amazon ECS optimierten Versionen AMIs angezeigt. Einzelheiten zum Verweisen auf den Systems Manager Manager-Parameter Store-Parameter in einer CloudFormation Vorlage finden Sie unter[Verwenden des neuesten empfohlenen Amazon ECS-optimierten AMI in einer Vorlage CloudFormation](retrieve-ecs-optimized_AMI.md#ecs-optimized-ami-parameter-examples-5).
**Wichtig**
Um sicherzustellen, dass Kunden standardmäßig über die neuesten Sicherheitsupdates verfügen, verwaltet Amazon ECS mindestens die letzten drei für Amazon AMIs ECS optimierten Windows-Versionen. Nach der Veröffentlichung des neuen Amazon ECS-optimierten AMIs Windows macht Amazon ECS die für Amazon ECS optimierten Windows, die älter sind AMIs , privat. Wenn es ein privates AMI gibt, auf das Sie zugreifen müssen, lassen Sie es uns wissen, indem Sie ein Ticket beim Cloud Support einreichen.
Windows Server 2016 unterstützt nicht die neueste Docker-Version, zum Beispiel 25.x.x. Daher erhält Windows Server 2016 Full AMIs keine Sicherheits- oder Bug-Patches für die Docker-Laufzeit. Es wird empfohlen, dass Sie auf eine der folgenden Windows-Plattformen wechseln:
Windows Server 2022 Voll
Windows Server 2022 Kern
Windows Server 2019 Voll
Windows Server 2019 Kern
**Anmerkung**
Die gMSA-Plugin-Protokollierung wurde mit der AMI-Version vom August 2025 von der dateibasierten Protokollierung `(C:\ProgramData\Amazon\gmsa)` auf Windows Event logging migriert. Das öffentliche Log-Collector-Skript erfasst alle gMSA-Protokolle. Weitere Informationen finden Sie unter [Erfassung von Container-Protokollen mit Amazon ECS Log Collector](ecs-logs-collector.md).
------
#### [ Windows Server 2025 Full AMI versions ]
Die folgende Tabelle listet die aktuellen und vorherigen Versionen des Amazon-ECS-optimierten Windows Server 2025 Full AMI und ihre entsprechenden Versionen von Amazon-ECS-Container-Agent und Docker auf.
| Vollständiges AMI für Amazon ECS für Windows Server 2025 | Version des Amazon-ECS-Container-Agenten | Docker-Version | Sichtbarkeit |
| --- | --- | --- | --- |
| **Windows\$1Server-2025-Englisch-Voll-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2025-Englisch-Voll-ECS\$1Optimiert-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2025-Englisch-Voll-ECS\$1Optimized-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2025-Englisch-Voll-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Öffentlich |
Verwenden Sie den folgenden AWS CLI Befehl, um das aktuelle Amazon ECS-optimierte Windows Server 2025 Full AMI abzurufen.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
```
------
#### [ Windows Server 2025 Core AMI versions ]
In der folgenden Tabelle sind die aktuellen und früheren Versionen des Amazon ECS-optimierten Windows Server 2025 Core AMI und die entsprechenden Versionen des Amazon ECS-Container-Agenten und Docker aufgeführt.
| Amazon ECS-optimiertes Windows Server 2025 Core-AMI | Version des Amazon-ECS-Container-Agenten | Docker-Version | Sichtbarkeit |
| --- | --- | --- | --- |
| **Windows\$1Server-2025-Englisch-Core-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2025-Englisch-Core-ECS\$1Optimized-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2025-Englisch-Core-ECS\$1Optimized-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2025-Englisch-Core-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Öffentlich |
Verwenden Sie den folgenden AWS CLI Befehl, um das aktuelle Amazon ECS-optimierte Windows Server 2025 Core AMI abzurufen.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
```
------
#### [ Windows Server 2022 Full AMI versions ]
Die folgende Tabelle listet die aktuellen und vorherigen Versionen des Amazon-ECS-optimierten Windows Server 2022 Full AMI und ihre entsprechenden Versionen des Amazon-ECS-Container-Agenten und -Dockers auf.
| Amazon-ECS-optimierter Windows Server 2022 Full AMI | Version des Amazon-ECS-Container-Agenten | Docker-Version | Sichtbarkeit |
| --- | --- | --- | --- |
| **Windows\$1Server-2022-Englisch-Voll-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2022-Englisch-Voll-ECS\$1Optimiert-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-202-Englisch-Voll-ECS\$1Optimiert-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2022-Englisch-Voll-ECS\$1Optimiert-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Öffentlich |
Verwenden Sie den folgenden AWS CLI Befehl, um das aktuelle Amazon ECS-optimierte Windows Server 2022 Full AMI abzurufen.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
```
------
#### [ Windows Server 2022 Core AMI versions ]
Die folgende Tabelle listet die aktuellen und vorherigen Versionen des Amazon-ECS-optimierten Windows Server 2022 Core AMI und ihre entsprechenden Versionen des Container-Agenten und Dockers von Amazon ECS auf.
| Amazon-ECS-optimierter Windows Server 2022 Core AMI | Version des Amazon-ECS-Container-Agenten | Docker-Version | Sichtbarkeit |
| --- | --- | --- | --- |
| **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-202-Englisch-Core-ECS\$1Optimiert-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-202-Englisch-Core-ECS\$1Optimiert-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2022-Englisch-Core-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Öffentlich |
Verwenden Sie den folgenden AWS CLI Befehl, um das aktuelle Amazon ECS-optimierte Windows Server 2022 Full AMI abzurufen.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
```
------
#### [ Windows Server 2019 Full AMI versions ]
Die folgende Tabelle listet die aktuellen und vorherigen Versionen des Amazon-ECS-optimierten Windows Server 2019 Full AMI und ihre entsprechenden Versionen von Amazon-ECS-Container-Agent und Docker auf.
| Amazon-ECS-optimierter Windows Server 2019 Full AMI | Version des Amazon-ECS-Container-Agenten | Docker-Version | Sichtbarkeit |
| --- | --- | --- | --- |
| **Windows\$1Server-2019-Englisch-Voll-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2019-Englisch-Voll-ECS\$1Optimiert-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2019-Englisch-Voll-ECS\$1Optimiert-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2019-Englisch-Voll-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Öffentlich |
Verwenden Sie den folgenden AWS CLI Befehl, um das aktuelle Amazon ECS-optimierte Windows Server 2019 Full AMI abzurufen.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```
------
#### [ Windows Server 2019 Core AMI versions ]
Die folgende Tabelle listet die aktuellen und vorherigen Versionen des Amazon-ECS-optimierten Windows Server 2019 Core AMI und ihre entsprechenden Versionen von Amazon-ECS-Container-Agent und Docker auf.
| Amazon-ECS-optimierter Windows Server 2019 Core AMI | Version des Amazon-ECS-Container-Agenten | Docker-Version | Sichtbarkeit |
| --- | --- | --- | --- |
| **Windows\$1Server-2019-Englisch-Core-ECS\$1Optimized-2026.03.13** | `1.102.0` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2019-Englisch-Core-ECS\$1Optimiert-2026.02.13** | `1.101.3` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2019-Englisch-Core-ECS\$1Optimized-2026.01.16** | `1.101.2` | `25.0.6 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2019-Englisch-Core-ECS\$1Optimized-2025.12.13** | `1.101.0` | `25.0.6 (Docker CE)` | Öffentlich |
Verwenden Sie den folgenden AWS CLI Befehl, um das aktuelle Amazon ECS-optimierte Windows Server 2019 Full AMI abzurufen.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
```
------
#### [ Windows Server 2016 Full AMI versions ]
**Wichtig**
Windows Server 2016 unterstützt nicht die neueste Docker-Version, zum Beispiel 25.x.x. Daher erhält Windows Server 2016 Full AMIs keine Sicherheits- oder Bug-Patches für die Docker-Laufzeit. Es wird empfohlen, dass Sie auf eine der folgenden Windows-Plattformen wechseln:
Windows Server 2022 Voll
Windows Server 2022 Kern
Windows Server 2019 Voll
Windows Server 2019 Kern
Die folgende Tabelle listet die aktuellen und vorherigen Versionen des Amazon-ECS-optimierten Windows Server 2016 Full AMI und ihre entsprechenden Versionen von Amazon-ECS-Container-Agent und Docker auf.
| Amazon-ECS-optimierter Windows Server 2016 Full AMI | Version des Amazon-ECS-Container-Agenten | Docker-Version | Sichtbarkeit |
| --- | --- | --- | --- |
| **Windows\$1Server-2016-Englisch-Voll-ECS\$1Optimized-2026.03.13** | `1.102.0` | `20.10.23 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2016-Englisch-Voll-ECS\$1Optimiert-2026.02.13** | `1.101.3` | `20.10.23 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2016-Englisch-Voll-ECS\$1Optimiert-2026.01.16** | `1.101.2` | `20.10.23 (Docker CE)` | Öffentlich |
| **Windows\$1Server-2016-Englisch-Voll-ECS\$1Optimiert-2025.12.13** | `1.101.0` | `20.10.23 (Docker CE)` | Öffentlich |
Verwenden Sie das folgende AWS CLI Amazon ECS-optimierte Windows Server 2016 Full AMI.
```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
```
------
# Erstellen eines eigenen Amazon-ECS-optimierten Windows-AMI
Verwenden Sie EC2 Image Builder, um Ihr eigenes benutzerdefiniertes Amazon-ECS-optimiertes Windows-AMI zu entwickeln. Das macht es einfach, ein Windows AMI mit Ihrer eigenen Lizenz auf Amazon ECS zu verwenden. Amazon ECS bietet eine verwaltete Image Builder-Komponente, die die Systemkonfiguration bereitstellt, die zum Ausführen von Windows-Instances zum Hosten Ihrer Container erforderlich ist. Jede von Amazon ECS verwaltete Komponente enthält einen bestimmten Container-Agent und eine Docker-Version. Sie können Ihr Image so anpassen, dass es entweder die neueste von Amazon ECS verwaltete Komponente verwendet oder wenn ein älterer Container-Agent oder eine Docker-Version benötigt wird, können Sie eine andere Komponente angeben.
Einen vollständigen Walkthrough für die Verwendung von EC2 Image Builder finden Sie unter [Erste Schritte mit EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/set-up-ib-env.html#image-builder-accessing-prereq) im *Benutzerhandbuch für EC2 Image Builder*.
Wenn Sie Ihr eigenes Amazon-ECS-optimiertes Windows AMI mit EC2 Image Builder erstellen, erstellen Sie ein Image-Rezept. Ihr Image-Rezept muss die folgenden Anforderungen erfüllen:
+ Das **Quell-Image** sollte auf Windows Server 2019 Core, Windows Server 2019 Full, Windows Server 2022 Core oder Windows Server 2022 Full basieren. Jedes andere Windows-Betriebssystem wird nicht unterstützt und ist möglicherweise nicht mit der Komponente kompatibel.
+ Bei der Angabe der **Erstellungs-Komponenten** ist die `ecs-optimized-ami-windows`-Komponente erforderlich. Die `update-windows`-Komponente wird empfohlen, wodurch sichergestellt wird, dass das Image die neuesten Sicherheitsupdates enthält.
Um eine andere Komponentenversion anzugeben, erweitern Sie das Kontrollkästchen **Optionen für die Versionierung** und geben Sie die Komponentenversion an, die Sie verwenden möchten. Weitere Informationen finden Sie unter [Auflisten der `ecs-optimized-ami-windows`-Komponentenversionen](#windows-component-list).
## Auflisten der `ecs-optimized-ami-windows`-Komponentenversionen
Wenn Sie ein EC2 Image Builder Rezept erstellen und die `ecs-optimized-ami-windows`-Komponente angeben, können Sie entweder die Standardoption verwenden oder eine bestimmte Komponentenversion angeben. Um zu bestimmen, welche Komponentenversionen verfügbar sind, sowie welcher Amazon-ECS-Container-Agent und Docker-Versionen in der Komponente enthalten sind, benutzen Sie AWS-Managementkonsole.
**Um die verfügbaren `ecs-optimized-ami-windows`-Komponentenversionen aufzulisten**
1. Öffnen Sie die EC2 Image Builder Builder-Konsole unter [https://console.aws.amazon.com/imagebuilder/](https://console.aws.amazon.com/imagebuilder/).
1. Wählen Sie auf der Navigationsleiste die Region aus, in der Sie Ihr Image erstellen.
1. Wählen Sie im Navigationsbereich unter dem Menü **Gespeicherte Konfigurationen** **Komponenten** aus.
1. Auf der **Komponenten**-Seite geben Sie ins Suchfeld `ecs-optimized-ami-windows` ein, ziehen das Qualifikationsmenü herunter und wählen **Schnellstart (von Amazon verwaltet)** aus.
1. Verwenden Sie die Spalte **Beschreibung**, um die Komponentenversion mit dem Amazon-ECS-Container-Agent und der Docker-Version zu ermitteln, die Ihr Image benötigt.
# Verwaltung von Windows-Container-Instances von Amazon ECS
Wenn Sie EC2-Instances für Ihre Amazon-ECS-Workloads verwenden, sind Sie für die Wartung der Instances verantwortlich.
Agent-Updates gelten nicht für Windows-Container-Instances. Wir empfehlen, dass Sie die neuen Container-Instances starten, um die Agent-Version in Ihren Windows-Clustern zu aktualisieren.
**Topics**
+ [Starten einer Container-Instance](launch_window-container_instance.md)
+ [Bootstrapping von Container-Instances](bootstrap_windows_container_instance.md)
+ [Verwenden eines HTTP-Proxys für Windows-Container-Instances](http_proxy_config-windows.md)
+ [Konfiguration von Container-Instances für den Empfang von Spot-Instance-Benachrichtigungen](windows-spot-instance-draining-container.md)
# Starten einer Amazon ECS Windows-Container-Instance
Ihre Amazon-ECS-Container-Instances werden mit der Amazon EC2 Konsole erstellt. Bevor Sie beginnen, sollten Sie sicherstellen, dass Sie die in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) beschriebenen Schritte ausgeführt haben.
Weitere Informationen zum Startassistenten finden Sie unter [Starten einer Instance mit dem neuen Launch Instance Wizard](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-launch-instance-wizard.html) im *Amazon-EC2-Benutzerhandbuch*.
Sie können den neuen Amazon-EC2-Assistenten verwenden, um eine Instance zu starten. Sie können die folgende Liste für die Parameter verwenden und die Parameter standardmäßig nicht aufgeführt lassen. Die folgenden Anweisungen führen Sie durch jede Parametergruppe.
## Verfahren
Bevor Sie beginnen, führen Sie die Schritte in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) aus.
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. In der Navigationsleiste oben auf dem Bildschirm wird die aktuelle AWS Region angezeigt (z. B. USA Ost (Ohio)). Wählen Sie eine Region aus, in der die Instance gestartet werden soll. Die Auswahl ist wichtig, da nur bestimmte Amazon EC2-Ressourcen zwischen Regionen geteilt werden können.
1. Wählen Sie im Dashboard der Amazon EC2-Konsole die Option **Instance starten** aus.
## Name und Tags
Der Instance-Name ist ein Tag, wobei der Schlüssel **Name** ist und es sich bei dem Wert um den von Ihnen angegebenen Namen handelt. Sie können Instance, Volumes und elastische Grafiken markieren. Bei Spot-Instances können Sie nur die Spot-Instance-Anforderung mit Tags (Markierungen) versehen.
Die Angabe eines Instance-Namens und zusätzlicher Tags ist optional.
+ Geben Sie unter **Name** einen beschreibenden Namen für die Instance ein. Wenn Sie keinen Namen angeben, kann die Instance anhand der ID identifiziert werden, die beim Starten der Instance automatisch generiert wird.
+ Wenn Sie zusätzliche Tags hinzufügen möchten, wählen Sie **Add additional tags** (Zusätzliche Tags hinzufügen) aus. Klicken Sie auf **Tag hinzufügen**, geben Sie dann einen Schlüssel und einen Wert ein und wählen Sie den Ressourcentyp aus, den Sie markieren möchten. Wählen Sie für jedes weitere Tag **Add another Tag** (Weiteres Tag hinzufügen) aus.
## Anwendungs- und Betriebssystem-Images (Amazon Machine Image)
Ein Amazon Machine Image (AMI) enthält die Informationen, die zum Starten einer Instance erforderlich sind. Ein AMI könnte beispielsweise die für die Funktion als Webserver erforderliche Software (z. B. Apache) und Ihre Website enthalten.
Die neuesten Amazon ECS-optimierten Versionen AMIs und ihre Werte finden Sie unter [Windows Amazon ECS-Optimized](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_windows_AMI.html) AMI.
Verwenden Sie die **Suchleiste**, um ein geeignetes Amazon ECS-optimiertes AMI zu finden, das von veröffentlicht wurde. AWS
1. **Geben Sie je nach Ihren Anforderungen eine der folgenden Optionen AMIs in die **Suchleiste** ein und drücken Sie die Eingabetaste.**
+ Windows\$1Server-2022-English-Full-ECS\$1Optimized
+ Windows\$1Server-2022-English-Core-ECS\$1Optimized
+ Windows\$1Server-2019-English-Full-ECS\$1Optimized
+ Windows\$1Server-2019-English-Core-ECS\$1Optimized
+ Windows\$1Server-2016-English-Full-ECS\$1Optimized
1. **Wählen Sie auf der Seite Choose an Amazon Machine Image (AMI)** den AMIs Tab **Community** aus.
1. Wählen Sie in der angezeigten Liste ein von Microsoft verifiziertes AMI mit dem letzten Veröffentlichungsdatum aus, und klicken Sie auf **Auswählen**.
## Instance-Typ
Der Instance-Typ definiert die Hardware-Konfiguration und Größe der Instance. Größere Instance-Typen haben mehr CPU und Arbeitsspeicher. Weitere Informationen finden Sie unter [Instance-Typen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
+ Wählen Sie unter **Instance-Typ** den Instance-Typ für die Instance aus.
Von dem von Ihnen ausgewählten Instance-Typ ist abhängig, welche Ressourcen zur Ausführung Ihrer Aufgaben verfügbar sind.
## Schlüsselpaar (Anmeldung)
Wählen Sie für **Schlüsselpaarname** ein vorhandenes Schlüsselpaar aus oder wählen Sie **Neues Schlüsselpaar erstellen**, um ein neues zu erstellen.
**Wichtig**
Wenn Sie die Option **Proceed without key pair (Not recommended)** (Ohne Schlüsselpaar fortfahren (Nicht empfohlen)) auswählen, können Sie keine Verbindung zur Instance herstellen, es sei denn, Sie wählen ein AMI aus, das entsprechend konfiguriert ist, um Benutzern eine andere Anmeldemöglichkeit zu erlauben.
## Netzwerkeinstellungen
Konfigurieren Sie die Netzwerkeinstellungen nach Bedarf.
+ **Networking platform** (Netzwerkplattform): Wählen Sie **Virtual Private Cloud (VPC)** aus und geben Sie dann im Abschnitt **Network interfaces** (Netzwerkschnittstellen) das Subnetz an.
+ **VPC**: Wählen Sie eine vorhandene VPC aus, in der die Sicherheitsgruppe erstellt werden soll.
+ **Subnetz**: Sie können eine Instance in einem Subnetz starten, das einer Availability Zone, einer Local Zone, Wavelength-Zone oder einem Outpost zugeordnet ist.
Um die Instance in einer Availability Zone zu starten, wählen Sie das Subnetz aus, in dem die Instance gestartet werden soll. Um ein neues Subnetz zu erstellen, wählen Sie **Create new subnet** aus, um die Amazon VPC-Konsole aufzurufen. Wenn Sie fertig sind, kehren Sie zum Launch Instance Wizard zurück und wählen Sie das Symbol zum Aktualisieren, um Ihr Subnetz in die Liste zu laden.
Um die Instance in einer Local Zone zu starten, wählen Sie ein Subnetz aus, das Sie in der Local Zone erstellt haben.
Um eine Instance in einem Outpost zu starten, wählen Sie ein Subnetz in einer VPC aus, die Sie dem Outpost zugeordnet haben.
+ **Auto-assign Public IP** (Öffentliche IP automatisch zuweisen): Wenn Ihre Instance über das öffentliche Internet zugänglich sein soll, muss das Feld **Auto-assign Public IP** (Öffentliche IP automatisch zuweisen) auf **Enable** (Aktivieren) festgelegt sein. Falls nicht, setzen Sie dieses Feld auf **Disable** (Deaktivieren).
**Anmerkung**
Container-Instances benötigen Zugriff, um mit dem Amazon-ECS-Service-Endpunkt zu kommunizieren. Dies kann über einen Schnittstellen-VPC-Endpunkt oder über Ihre Container-Instances mit öffentlichen IP-Adressen erfolgen.
Weitere Informationen zu Schnittstellen-VPC-Endpunkten finden Sie unter [Amazon ECS und Schnittstellen-VPC-Endpunkte (AWS PrivateLink)](vpc-endpoints.md).
Wenn Sie keinen Schnittstellen-VPC-Endpunkt konfiguriert haben und Ihre Container-Instances keine öffentlichen IP-Adressen haben, müssen Sie Netzwerkadressübersetzung (Network Address Translation, NAT) verwenden, um diesen Zugriff zur Verfügung zu stellen. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im *Amazon-VPC-Benutzerhandbuch* und unter [Verwenden eines HTTP-Proxys für Amazon-ECS-Linux-Container-Instances](http_proxy_config.md) in dieser Anleitung.
+ **Firewall (security groups)** (Firewall (Sicherheitsgruppen)): Verwenden Sie eine Sicherheitsgruppe, um Firewallregeln für Ihre Container-Instance zu definieren. Diese Regeln legen fest, welcher eingehende Netzwerkverkehr an Ihre Container-Instance weitergeleitet wird. Der gesamte übrige Datenverkehr wird ignoriert.
+ Um eine vorhandene Sicherheitsgruppe auszuwählen, wählen Sie **Select existing security group** (Vorhandene Sicherheitsgruppe auswählen) und wählen Sie die Sicherheitsgruppe aus, die Sie in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) erstellt haben.
## Speicher konfigurieren
Die von Ihnen ausgewählte AMI beinhaltet ein oder mehrere Speicher-Volumes, einschließlich eines Root-Volumes. Sie können zusätzliche Volumes angeben, die an die Instance angehängt werden sollen.
Sie können die Ansicht **Simple** (Einfach) verwenden.
+ **Storage type** (Speichertyp): Konfigurieren Sie den Speicher für Ihre Container-Instance.
Wenn Sie das Amazon-ECS-optimierte AMI für Amazon Linux verwenden, hat die Instance zwei konfigurierte Volumes. Das **Root**-Volume ist für die Nutzung durch das Betriebssystem und das zweite Amazon EBS-Volume (zugeordnet zu `/dev/xvdcz`) ist für die Nutzung durch Docker vorgesehen.
Sie haben auch die Möglichkeit, die Volume-Größen für Ihre Instance entsprechend den Anforderungen Ihrer Anwendung zu erhöhen oder zu verringern.
## Erweiterte Details
Erweitern Sie für **Advanced details (Erweiterte Details)** den Bereich zur Ansicht der Felder und geben Sie zusätzliche Parameter für die Instance an.
+ **Purchasing option** (Kaufoption): Wählen Sie **Request Spot instances (Spot-Instances anfordern)** aus, um Spot-Instances anzufordern. Außerdem müssen Sie in den anderen Felder im Zusammenhang mit Spot-Instances Werte festlegen. Weitere Informationen finden Sie unter [Spot-Instance-Anforderungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html).
**Anmerkung**
Wenn Sie Spot-Instances verwenden und die Meldung `Not available` angezeigt wird, muss möglicherweise ein anderer Instance-Typ angegeben werden.
.
+ **IAM instance profile** (IAM-Instance-Profil): Wählen Sie die IAM-Rolle Ihrer Container-Instance aus. Diese heißt normalerweise `ecsInstanceRole`.
**Wichtig**
Wenn Sie Ihre Container-Instance nicht mit den richtigen IAM-Berechtigungen starten, kann Ihr Amazon-ECS-Agent keine Verbindung mir Ihrem Cluster herstellen. Weitere Informationen finden Sie unter [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md).
+ (Optional) **User data** (Benutzerdaten): Konfigurieren Sie Ihre Amazon-ECS-Container-Instance mit Benutzerdaten, wie z. B. den Agenten-Umgebungsvariablen aus [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md). Amazon EC2-Benutzerdaten-Skripts werden nur einmal ausgeführt, wenn die Instance erstmals gestartet wird. Im Folgenden finden Sie einige gängige Beispiele dafür, wofür Benutzerdaten verwendet werden:
+ Standardmäßig startet Ihre Container-Instance in Ihrem Standard-Cluster. Für einen Start in einem nicht standardmäßigen Cluster wählen Sie die Liste **Advanced Details**. Fügen Sie dann das folgende Skript in das Feld **Benutzerdaten** ein und *your\$1cluster\$1name* ersetzen Sie es durch den Namen Ihres Clusters.
`EnableTaskIAMRole` aktiviert das Task-IAM-Rollenfeature für die Aufgaben.
Darüber hinaus sind die folgenden Optionen verfügbar, wenn Sie den `awsvpc`-Netzwerkmodus verwenden.
+ `EnableTaskENI`: Dieses Flag aktiviert das Aufgabennetzwerk und ist erforderlich, wenn Sie den `awsvpc`-Netzwerkmodus verwenden.
+ `AwsvpcBlockIMDS`: Dieses optionale Flag blockiert den IMDS-Zugriff für die Task-Container, die im `awsvpc`-Netzwerkmodus ausgeführt werden.
+ `AwsvpcAdditionalLocalRoutes`: Mit diesem optionalen Flag können Sie zusätzliche Routen im Aufgabennamespace haben.
Ersetzen Sie `ip-address` mit der IP-Adresse für die zusätzlichen Routen, zum Beispiel 172.31.42.23/32.
```
Import-Module ECSTools
Initialize-ECSAgent -Cluster your_cluster_name -EnableTaskIAMRole -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
'["ip-address"]'
```
# Bootstrapping von Windows-Container-Instances von Amazon ECS zur Weitergabe von Daten
Beim Starten einer Amazon-EC2-Instance haben Sie die Möglichkeit, Benutzerdaten an die EC2-Instance zu übergeben. Die Daten können für allgemeine automatisierte Konfigurationsaufgaben und sogar zur Ausführung von Skripts beim Start der Instance verwendet werden. In Amazon ECS werden Benutzerdaten hauptsächlich zur Übergabe von Konfigurationsinformationen an den Docker-Daemon und den Amazon-ECS-Container-Agenten verwendet.
Sie können mehrere Arten von Benutzerdaten an Amazon EC2 übergeben, darunter auch Cloud-Boothooks, Shell-Skripts und `cloud-init`-Anweisungen. Weitere Informationen zu diesen und anderen Formattypen finden Sie in der [Cloud-Init-Dokumentation](https://cloudinit.readthedocs.io/en/latest/explanation/format.html).
Sie können diese Benutzerdaten übergeben, wenn Sie den Amazon EC2-Start-Assistenten verwenden. Weitere Informationen finden Sie unter [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
## Standardmäßige Windows-Benutzerdaten
Dieses Beispiel-Benutzerdatenskript zeigt die Standardbenutzerdaten, die Ihre Windows-Container-Instances erhalten, wenn Sie die Konsole verwenden. Das Skript unten führt Folgendes durch:
+ Setzt den Clusternamen auf den Namen, den Sie eingegeben haben.
+ Legt die IAM-Rollen für Aufgaben fest.
+ Legt `json-file` und `awslogs` als verfügbare Protokolltreiber fest.
Darüber hinaus sind die folgenden Optionen verfügbar, wenn Sie den `awsvpc`-Netzwerkmodus verwenden.
+ `EnableTaskENI`: Dieses Flag aktiviert das Aufgabennetzwerk und ist erforderlich, wenn Sie den `awsvpc`-Netzwerkmodus verwenden.
+ `AwsvpcBlockIMDS`: Dieses optionale Flag blockiert den IMDS-Zugriff für die Task-Container, die im `awsvpc`-Netzwerkmodus ausgeführt werden.
+ `AwsvpcAdditionalLocalRoutes`: Mit diesem optionalen Flag können Sie zusätzliche Routen haben.
Ersetzen Sie `ip-address` mit der IP-Adresse für die zusätzlichen Routen, zum Beispiel 172.31.42.23/32.
Sie können dieses Skript für Ihre eigenen Container-Instances verwenden (vorausgesetzt, sie werden von dem für Amazon ECS optimierten Windows-Server-AMI gestartet).
Ersetzen Sie die Zeile `-Cluster cluster-name`, um Ihren eigenen Clusternamen anzugeben.
```
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
'["ip-address"]'
```
Für Windows-Aufgaben, die für die Verwendung des `awslogs`-Protokolltreibers konfiguriert sind, müssen Sie auch die `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE`-Umgebungsvariable für die Container-Instance festlegen. Verwenden Sie die folgende Syntax:
Ersetzen Sie die Zeile `-Cluster cluster-name`, um Ihren eigenen Clusternamen anzugeben.
```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
```
## Benutzerdaten für die Installation des Windows-Agenten
Mit diesem Beispiel-Benutzerdatenskript wird der Amazon-ECS-Container-Agent auf einer Instance installiert, die mit einem **Windows\$1Server-2016-English-Full-Containers**-AMI gestartet wurde. Es wurde anhand der Anweisungen zur Agenteninstallation auf der [ GitHubREADME-Seite des Amazon ECS Container Agent-Repositorys](https://github.com/aws/amazon-ecs-agent) angepasst.
**Anmerkung**
Dieses Skript dient als Beispiel. Der Einstieg in Windows-Container ist mit dem Amazon-ECS-optimierten Windows Server-AMI wesentlich einfacher. Weitere Informationen finden Sie unter [Erstellen eines Amazon-ECS-Clusters für Fargate-Workloads](create-cluster-console-v2.md).
Informationen zur Installation des Amazon ECS-Agenten auf Windows Server 2022 Full finden Sie in [Ausgabe 3753](https://github.com/aws/amazon-ecs-agent/issues/3753) unter GitHub.
Sie können dieses Skript für Ihre eigenen Container-Instances verwenden (vorausgesetzt, sie werden mit einer Version des **Windows\$1Server-2016-English-Full-Container**-AMI gestartet). Achten Sie darauf, die Zeile `windows` zu ersetzen, um Ihren eigenen Cluster-Namen anzugeben (wenn Sie keinen Cluster namens `windows` verwenden).
```
# Set up directories the agent uses
New-Item -Type directory -Path ${env:ProgramFiles}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS\data -Force
# Set up configuration
$ecsExeDir = "${env:ProgramFiles}\Amazon\ECS"
[Environment]::SetEnvironmentVariable("ECS_CLUSTER", "windows", "Machine")
[Environment]::SetEnvironmentVariable("ECS_LOGFILE", "${env:ProgramData}\Amazon\ECS\log\ecs-agent.log", "Machine")
[Environment]::SetEnvironmentVariable("ECS_DATADIR", "${env:ProgramData}\Amazon\ECS\data", "Machine")
# Download the agent
$agentVersion = "latest"
$agentZipUri = "https://s3.amazonaws.com/amazon-ecs-agent/ecs-agent-windows-$agentVersion.zip"
$zipFile = "${env:TEMP}\ecs-agent.zip"
Invoke-RestMethod -OutFile $zipFile -Uri $agentZipUri
# Put the executables in the executable directory.
Expand-Archive -Path $zipFile -DestinationPath $ecsExeDir -Force
Set-Location ${ecsExeDir}
# Set $EnableTaskIAMRoles to $true to enable task IAM roles
# Note that enabling IAM roles will make port 80 unavailable for tasks.
[bool]$EnableTaskIAMRoles = $false
if (${EnableTaskIAMRoles}) {
$HostSetupScript = Invoke-WebRequest https://raw.githubusercontent.com/aws/amazon-ecs-agent/master/misc/windows-deploy/hostsetup.ps1
Invoke-Expression $($HostSetupScript.Content)
}
# Install the agent service
New-Service -Name "AmazonECS" `
-BinaryPathName "$ecsExeDir\amazon-ecs-agent.exe -windows-service" `
-DisplayName "Amazon ECS" `
-Description "Amazon ECS service runs the Amazon ECS agent" `
-DependsOn Docker `
-StartupType Manual
sc.exe failure AmazonECS reset=300 actions=restart/5000/restart/30000/restart/60000
sc.exe failureflag AmazonECS 1
Start-Service AmazonECS
```
# Verwenden eines HTTP-Proxys für Windows-Container-Instances von Amazon ECS
Sie können Ihre Amazon-ECS-Container-Instances für die Verwendung eines HTTP-Proxys sowohl für den Amazon-ECS-Container-Agenten als auch für den Docker-Daemon konfigurieren. Das ist praktisch, wenn Ihre Container-Instances keinen externen Netzwerkzugriff über ein Amazon VPC-Internet-Gateway, NAT-Gateway oder eine Instance haben.
Um Ihre Amazon ECS Windows-Container-Instance für die Verwendung eines HTTP-Proxys zu konfigurieren, bestimmen Sie die folgenden Variablen beim Starten (mit Amazon EC2-Benutzerdaten).
`[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.mydomain:port", "Machine")`
Legen Sie `HTTP_PROXY` auf den Hostnamen (oder die IP-Adresse) und die Portnummer eines HTTP-Proxys fest, den der Amazon ECS-Agent verwenden soll, um eine Verbindung zum Internet herzustellen. Beispielsweise haben Ihre Container-Instances vielleicht keinen externen Netzwerkzugriff über ein Amazon VPC-Internet-Gateway, NAT-Gateway oder eine Instance.
`[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")`
Setzen Sie `NO_PROXY` auf `169.254.169.254,169.254.170.2,\\.\pipe\docker_engine`, um die EC2 Instance-Metadaten, IAM-Rollen für Aufgaben und Docker-Daemon-Datenverkehr aus dem Proxy zu filtern.
**Example Windows HTTP-Proxy-Benutzerdatenskript**
Das folgende PowerShell Beispielskript für Benutzerdaten konfiguriert den Amazon ECS-Container-Agenten und den Docker-Daemon so, dass sie einen von Ihnen angegebenen HTTP-Proxy verwenden. Sie können auch ein Cluster festlegen, in dem sich die Container-Instance selbst registriert.
Für die Verwendung dieses Skripts beim Starten einer Container-Instance befolgen Sie die Schritte in [Starten einer Amazon ECS Windows-Container-Instance](launch_window-container_instance.md) Kopieren Sie einfach das folgende PowerShell Skript und fügen Sie es in das Feld **Benutzerdaten** ein (achten Sie darauf, die roten Beispielwerte durch Ihre eigenen Proxy- und Clusterinformationen zu ersetzen).
Die Option `-EnableTaskIAMRole` ist erforderlich, um IAM-Rollen für Aufgaben zu aktivieren. Weitere Informationen finden Sie unter [Zusätzliche Konfiguration der Amazon-EC2-Windows-Instances](task-iam-roles.md#windows_task_IAM_roles).
```
Import-Module ECSTools
$proxy = "http://proxy.mydomain:port"
[Environment]::SetEnvironmentVariable("HTTP_PROXY", $proxy, "Machine")
[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")
Restart-Service Docker
Initialize-ECSAgent -Cluster MyCluster -EnableTaskIAMRole
```
# Konfiguration von Windows-Container-Instances von Amazon ECS für den Empfang von Spot-Instance-Benachrichtigungen
Amazon EC2 hält Ihre Spot-Instance an, beendet sie oder versetzt sie in den Ruhezustand, wenn der Spot-Preis den Höchstpreis für Ihre Anforderung überschreitet oder keine Kapazität mehr verfügbar ist. Amazon EC2 stellt eine Spot-Instance-Unterbrechungsbenachrichtigung bereit, was der Instance eine zweiminütige Warnung gibt, bevor sie unterbrochen wird. Wenn der Amazon-ECS-Spot-Instance-Ausgleich auf der Instance aktiviert ist, erhält ECS die Benachrichtigung über die Unterbrechung der Spot-Instance und versetzt die Instance in den Status `DRAINING`.
**Wichtig**
Amazon ECS prüft auf Benachrichtigungen über die Unterbrechung der Spot-Instance, die über die Instance-Aktionen `terminate` und `stop` verfügen. Wenn Sie entweder das Verhalten `hibernate` für die Unterbrechung von Instances beim Anfordern Ihrer Spot-Instances oder die Spot-Flotte angegeben haben, wird der Amazon-ECS-Spot-Instance-Ausgleich für diese Instances nicht unterstützt.
Wenn eine Container-Instance auf `DRAINING` festgelegt wird, lässt es Amazon ECS nicht zu, dass die Platzierung neuer Aufgaben in der Container-Instance geplant wird. Serviceaufgaben auf der betroffenen Container-Instance mit dem Status `PENDING` werden umgehend gestoppt. Wenn Container-Instances im Cluster verfügbar sind, werden Ersatzserviceaufgaben darauf gestartet.
Sie können Spot Instance Draining aktivieren, wenn Sie eine Instance starten. Sie müssen den `ECS_ENABLE_SPOT_INSTANCE_DRAINING`-Parameter festlegen, bevor Sie den Container-Agenten starten. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters.
```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_SPOT_INSTANCE_DRAINING", "true", "Machine")
# Initialize the agent
Initialize-ECSAgent -Cluster my-cluster
```
Weitere Informationen finden Sie unter [Starten einer Amazon ECS Windows-Container-Instance](launch_window-container_instance.md).
# Amazon-ECS-Cluster für externe Instances
Amazon ECS Anywhere bietet Unterstützung für die Registrierung einer *externen Instance*, wie einem On-Premises-Server oder einer virtuellen Maschine (VM) in Ihren Amazon-ECS-Cluster. Externe Instances sind für ausgeführte Anwendungen optimiert, die ausgehenden Datenverkehr generieren oder Prozessdaten verarbeiten. Wenn Ihre Anwendung eingehenden Datenverkehr erfordert, wird die Ausführung dieser Arbeitslasten aufgrund fehlender Elastic Load Balancing-Unterstützung weniger effizient. Amazon ECS hat einen neuen `EXTERNAL`-Starttyp, mit dem Sie Dienste erstellen oder Tasks auf externen Instances ausführen können.
## Unterstützte Betriebssysteme und Systemarchitekturen
Im Folgenden finden Sie eine Liste der unterstützten Betriebssysteme. Die `x86_64`- und `ARM64`-CPU-Architekturen werden unterstützt.
+ Amazon Linux 2023
+ Ubuntu 20, Ubuntu 22, Ubuntu 24
+ RHEL 9 — Sie müssen sicherstellen, dass Docker installiert ist, bevor Sie das [ECS Anywhere-Installationsskript](https://github.com/aws/amazon-ecs-agent/blob/master/scripts/ecs-anywhere-install.sh) ausführen. Weitere Informationen finden Sie in der Docker-Dokumentation unter [Docker Engine auf RHEL installieren](https://docs.docker.com/engine/install/rhel/).
Ab dem 7. August 2026 werden die folgenden Betriebssysteme von Amazon ECS Anywhere nicht mehr unterstützt:
+ Amazon Linux 2
+ CentOS Stream 9
+ REGEL 7, REGEL 8
+ Fedora 32, Fedora 33, Fedora 40
+ openSUSE Tumbleweed
+ Ubuntu 18
+ Debian 9, Debian 10, Debian 11, Debian 12
+ SUSE Enterprise Server 15
+ Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 20H2
## Überlegungen
Seien Sie sich der folgenden Überlegungen bewusst, bevor Sie externe Instances verwenden.
+ Sie können eine externe Instance auf einem Cluster gleichzeitig registrieren. Eine Anleitung zum Registrieren einer externen Instance bei einem anderen Cluster finden Sie unter [Abmelden einer externen Amazon-ECS-Instance](ecs-anywhere-deregistration.md).
+ Ihre externen Instanzen benötigen eine IAM-Rolle, mit der sie kommunizieren können. AWS APIs Weitere Informationen finden Sie unter [IAM-Rolle für Amazon ECS Anywhere](iam-role-ecsanywhere.md).
+ Ihre externen Instances sollten keine vorkonfigurierte Instance-Anmeldeinformationskette lokal definiert haben, da dies das Registrierungsskript beeinträchtigt.
+ Um Container-Logs an CloudWatch Logs zu senden, stellen Sie sicher, dass Sie in Ihrer Aufgabendefinition eine IAM-Rolle für die Aufgabenausführung erstellen und angeben.
+ Wenn eine externe Instance in einem Cluster registriert ist, wird das `ecs.capability.external`-Attribut mit der Instance zugeordnet. Dieses Attribut identifiziert die Instance als externe Instance. Sie können Ihren externen Instances benutzerdefinierte Attribute hinzufügen, die als Einschränkung für die Platzierung von Vorgängen verwendet werden sollen. Weitere Informationen finden Sie unter [Benutzerdefinierte Attribute](task-placement-constraints.md#ecs-custom-attributes).
+ Sie können Ihrer externen Instance Ressourcen-Tags hinzufügen. Weitere Informationen finden Sie unter [Hinzufügen von Tags zu externen Container-Instances für Amazon ECS](instance-details-tags-external.md).
+ ECS Exec wird für externe Instances unterstützt. Weitere Informationen finden Sie unter [Überwachen von Amazon-ECS-Containern mit ECS Exec](ecs-exec.md).
+ Im Folgenden finden Sie zusätzliche Überlegungen, die speziell für das Netzwerk mit Ihren externen Instances gelten. Weitere Informationen finden Sie unter [Netzwerk](#ecs-anywhere-networking).
+ Service-Load Balancing wird nicht unterstützt.
+ Serviceerkennung wird nicht unterstützt.
+ Tasks, die auf externen Instances ausgeführt werden, müssen die `bridge`, `host` oder `none`-Netzwerk-Modi verwenden. Der Netzwerkmodus `awsvpc` wird nicht unterstützt.
+ In jeder AWS Region gibt es Amazon ECS-Servicedomänen. Diese Service-Domains müssen den Datenverkehr an Ihre externen Instances senden dürfen.
+ Der auf Ihrer externen Instance installierte SSM Agent verwaltet IAM-Anmeldeinformationen, die alle 30 Minuten mit einem Hardware-Fingerabdruck gedreht werden. Wenn Ihre externe Instance die Verbindung zu verliert AWS, aktualisiert der SSM-Agent die Anmeldeinformationen automatisch, nachdem die Verbindung wiederhergestellt wurde. Weitere Informationen finden Sie unter [Überprüfen von On-Premises-Servern und virtuellen Maschinen mit einem Hardware-Fingerprint](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation) im *AWS Systems Manager -Benutzerhandbuch*.
+ Sie können Linux-Aufgaben auf externen Instances in einer IPv6 Nur-Only-Konfiguration ausführen, solange sich die Instanzen in Nur-Only-Subnetzen befinden. IPv6 Weitere Informationen finden Sie unter [Verwenden einer VPC im Modus „Nur IPv6“](task-networking.md#networking-ipv6-only).
+ Die `UpdateContainerAgent`-API wird nicht unterstützt. Anweisungen zum Aktualisieren des SSM Agent oder des Amazon-ECS-Agenten auf Ihren externen Instances finden Sie unter [Aktualisierung des AWS Systems Manager Agenten und des Amazon ECS-Container-Agenten auf einer externen Instance](ecs-anywhere-updates.md).
+ Amazon-ECS-Kapazitätsanbieter werden nicht unterstützt. Um einen Service zu erstellen oder einen eigenständigen Task für Ihre externen Instances auszuführen, verwenden Sie den `EXTERNAL`-Starttyp.
+ SELinux wird nicht unterstützt.
+ Verwenden von Amazon EFS Volumes oder Angeben eines `EFSVolumeConfiguration` wird nicht unterstützt.
+ Die Integration mit App Mesh wird nicht unterstützt.
+ Wenn Sie die Konsole verwenden, um eine externe Instance-Aufgabendefinition zu erstellen, müssen Sie die Aufgabendefinition mit dem JSON-Editor der Konsole erstellen.
+ Wenn Sie ein nicht für Amazon ECS optimiertes AMI verwenden, führen Sie die folgenden Befehle auf der externen Container-Instance aus, um Regeln für die Verwendung von IAM-Rollen für Aufgaben zu konfigurieren. Weitere Informationen finden Sie unter [Zusätzliche Konfiguration der externen Instance](task-iam-roles.md#enable_task_iam_roles).
```
$ sysctl -w net.ipv4.conf.all.route_localnet=1
$ iptables -t nat -A PREROUTING -p tcp -d 169.254.170.2 --dport 80 -j DNAT --to-destination 127.0.0.1:51679
$ iptables -t nat -A OUTPUT -d 169.254.170.2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679
```
### Netzwerk
Externe Amazon-ECS-Instances sind für die Ausführung von Anwendungen optimiert, die ausgehenden Datenverkehr generieren oder Daten verarbeiten. Wenn Ihre Anwendung eingehenden Datenverkehr erfordert, z. B. einen Webdienst, macht das Fehlen von Elastic Load Balancing-Unterstützung die Ausführung dieser Workloads weniger effizient, da diese Workloads nicht hinter einem Load Balancer platziert werden können.
Im Folgenden finden Sie zusätzliche Überlegungen, die speziell für das Netzwerk mit Ihren externen Instances gelten.
+ Service-Load Balancing wird nicht unterstützt.
+ Serviceerkennung wird nicht unterstützt.
+ Linux-Aufgaben, die auf externen Instances ausgeführt werden, müssen den Netzwerkmodus `bridge`, `host` oder `none` verwenden. Der Netzwerkmodus `awsvpc` wird nicht unterstützt.
Weitere Informationen zu den jeweiligen Netzwerkmodi finden Sie unter [Amazon-ECS-Aufgaben-Netzwerkoptionen für EC2-Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html).
+ Sie können Linux-Aufgaben auf externen Instances in einer IPv6 Nur-Only-Konfiguration ausführen, solange sich die Instanzen in IPv6 Nur-Only-Subnetzen befinden. Weitere Informationen finden Sie unter [Verwenden einer VPC im Modus „Nur IPv6“](task-networking.md#networking-ipv6-only).
+ Es gibt Amazon-ECS-Service-Domains in jeder Region, die den Datenverkehr an Ihre externen Instances senden dürfen.
+ Der auf Ihrer externen Instance installierte SSM Agent verwaltet IAM-Anmeldeinformationen, die alle 30 Minuten mit einem Hardware-Fingerabdruck gedreht werden. Wenn Ihre externe Instanz die Verbindung zu verliert AWS, aktualisiert der SSM-Agent die Anmeldeinformationen automatisch, nachdem die Verbindung wiederhergestellt wurde. Weitere Informationen finden Sie unter [Überprüfen von On-Premises-Servern und virtuellen Maschinen mit einem Hardware-Fingerprint](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation) im *AWS Systems Manager -Benutzerhandbuch*.
Die folgenden Domains werden für die Kommunikation zwischen dem Amazon-ECS-Service und dem Amazon-ECS-Agent verwendet, der auf Ihrer externen Instance installiert ist. Stellen Sie sicher, dass Datenverkehr zulässig ist und die DNS-Auflösung funktioniert. *region*Stellt für jeden Endpunkt die Regionskennung für eine AWS Region dar, die von Amazon ECS unterstützt wird, z. B. `us-east-2` für die Region USA Ost (Ohio). Die Endpunkte für alle Regionen, die Sie verwenden, sollten zulässig sein. Für Endpunkte `ecs-a` und `ecs-t` sollten Sie ein Sternchen (z. B. `ecs-a-*`) einschließen.
+ `ecs-a-*.region.amazonaws.com` – Dieser Endpunkt wird beim Verwalten von Aufgaben verwendet.
+ `ecs-t-*.region.amazonaws.com` – Dieser Endpunkt wird zum Verwalten von Task- und Container-Metriken verwendet.
+ `ecs.region.amazonaws.com` – Dies ist der Service-Endpunkt für Amazon ECS.
+ `ssm.region.amazonaws.com `— Dies ist der Service-Endpunkt für AWS Systems Manager.
+ `ec2messages.region.amazonaws.com`— Dies ist der Dienstendpunkt, der für die Kommunikation zwischen dem Systems Manager Manager-Agent und dem Systems Manager Manager-Dienst in der Cloud AWS Systems Manager verwendet wird.
+ `ssmmessages.region.amazonaws.com`: Dieser Service-Endpunkt ist zum Erstellen und Löschen von Sitzungskanälen mit dem Session Manager-Service in der Cloud erforderlich..
+ Wenn Ihre Aufgaben die Kommunikation mit anderen AWS Diensten erfordern, stellen Sie sicher, dass diese Dienstendpunkte zugelassen sind. Zu den Beispielanwendungen gehört die Verwendung von Amazon ECR zum Abrufen von Container-Images oder die Verwendung CloudWatch für CloudWatch Logs. Weitere Informationen finden Sie unter [Service-Endpunkte](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) in *Allgemeine AWS -Referenz*.
### Amazon FSx for Windows File Server mit ECS Anywhere
**Wichtig**
Die Windows-Unterstützung für Amazon ECS Anywhere ist veraltet. Dieser Abschnitt ist nicht mehr relevant.
Um die externen Instances Amazon FSx for Windows File Server mit Amazon ECS verwenden zu können, müssen Sie eine Verbindung zwischen Ihrem lokalen Rechenzentrum und dem AWS Cloud herstellen. Informationen zu den Optionen zum Verbinden Ihres Netzwerks mit Ihrer VPC finden Sie unter [Verbindungsoptionen für Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html).
### gMSA mit ECS Anywhere
**Wichtig**
Die Windows-Unterstützung für Amazon ECS Anywhere ist veraltet. Dieser Abschnitt ist nicht mehr relevant.
Die folgenden Anwendungsfälle wurden für ECS Anywhere unterstützt, als Windows ein unterstütztes Betriebssystem war.
+ Das Active Directory befindet sich im AWS Cloud — Für diese Konfiguration stellen Sie eine Verbindung zwischen Ihrem lokalen Netzwerk und der AWS Cloud Verwendung einer AWS Direct Connect Verbindung her. Informationen zum Erstellen der Verbindung finden Sie unter [Konnektivitätsoptionen für Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html). Sie erstellen ein Active Directory in der AWS Cloud. Informationen zu den ersten Schritten finden Sie AWS Directory Service unter [Einrichtung AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/setting_up.html) im *AWS Directory Service Administratorhandbuch*. Anschließend können Sie Ihre externen Instanzen über die AWS Direct Connect Verbindung mit der Domain verbinden. Informationen zum Arbeiten mit gMSA mit Amazon ECS finden Sie unter [Erfahren Sie, wie Sie gMSAs für EC2-Windows-Containers für Amazon ECS verwenden.](windows-gmsa.md).
+ Das Active Directory befindet sich im On-Premises-Rechenzentrum. – Für diese Konfiguration verbinden Sie Ihre externen Instances mit dem On-Premises-Active-Directory. Sie verwenden dann die lokal verfügbaren Anmeldeinformationen, wenn Sie die Amazon-ECS-Aufgaben ausführen.
# Erstellen eines Amazon-ECS-Clusters für Workloads auf externen Instances
Sie erstellen einen Cluster, um die Infrastruktur zu definieren, auf der Ihre Aufgaben und Services ausgeführt werden.
Bevor Sie beginnen, vergewissern Sie sich, dass Sie die Schritte in [Einrichtung für die Verwendung von Amazon ECS](get-set-up-for-amazon-ecs.md) ausgeführt haben, und weisen Sie die entsprechende IAM-Berechtigung zu. Weitere Informationen finden Sie unter [Beispiele für Amazon-ECS-Cluster](security_iam_id-based-policy-examples.md#IAM_cluster_policies). Die Amazon ECS-Konsole bietet eine einfache Möglichkeit, die Ressourcen zu erstellen, die von einem Amazon ECS-Cluster benötigt werden, indem ein CloudFormation Stack erstellt wird.
Um den Prozess der Clustererstellung so einfach wie möglich zu gestalten, verfügt die Konsole über Standardauswahlen für viele Auswahlmöglichkeiten, die wir unten beschreiben. Es gibt auch Hilfe-Panels für die meisten Abschnitte in der Konsole, die weiteren Kontext bieten.
Sie können die folgenden Optionen ändern:
+ Fügen Sie dem Cluster einen Namespace hinzu.
Über einen Namespace können Services, die Sie im Cluster erstellen, ohne zusätzliche Konfiguration eine Verbindung zu den anderen Services im Namespace herstellen. Weitere Informationen finden Sie unter [Amazon-ECS-Services verbinden](interconnecting-services.md).
+ Den Cluster für externe Instances konfigurieren
+ Weisen Sie einen AWS KMS Schlüssel für Ihren verwalteten Speicher zu. Weitere Informationen zur Erstellung eines Schlüssels finden Sie unter [Einen KMS-Schlüssel erstellen](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) im *Benutzerhandbuch für AWS Key Management Service *.
+ Fügen Sie Tags hinzu, die Ihnen helfen, Ihren Cluster zu identifizieren.
**So erstellen Sie einen neuen Cluster (Amazon ECS-Konsole)**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie die zu verwendende Region in der Navigationsleiste aus.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der Seite **Clusters** die Option **Create cluster** (Cluster erstellen) aus.
1. Konfigurieren Sie unter **Clusterkonfiguration** Folgendes:
+ Geben Sie für **Cluster-Name** einen eindeutigen Namen ein.
Der Name kann bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern und Bindestriche enthalten.
+ (Optional) Wenn der für Service Connect verwendete Namespace nicht mit dem Clusternamen identisch sein soll, geben Sie unter **Namespace** einen eindeutigen Namen ein.
1. (Optional) Verwenden Sie Container Insights, erweitern Sie **Überwachung** und wählen Sie dann eine der folgenden Optionen:
+ Um das empfohlene Container Insights mit verbesserter Beobachtbarkeit zu verwenden, wählen Sie **Container Insights mit verbesserter Beobachtbarkeit**.
+ Um Container Insights zu verwenden, wählen Sie **Container Insights**.
1. (Optional) Um ECS Exec zum Debuggen von Aufgaben im Cluster zu verwenden, erweitern Sie **Konfiguration zur Fehlerbehebung** und konfigurieren Sie dann Folgendes:
+ Wählen Sie **ECS Exec einschalten** aus.
+ (Optional) Geben Sie unter **AWS KMS Schlüssel für ECS Exec** den ARN des AWS KMS Schlüssels ein, den Sie zur Verschlüsselung der ECS Exec-Sitzungsdaten verwenden möchten.
+ (Optional) Wählen Sie für die **ECS-Exec-Protokollierung** das Protokollziel aus:
+ Um Logs an CloudWatch Logs zu senden, wählen Sie **Amazon CloudWatch**.
+ Um Protokolle an Amazon S3 zu senden, wählen Sie **Amazon S3**.
+ Um die Protokollierung zu deaktivieren, wählen Sie **Keine**.
1. (Optional) Verschlüsseln Sie die Daten im verwalteten Speicher. Geben Sie unter **Verschlüsselung** für **verwalteten Speicher** den ARN des AWS KMS Schlüssels ein, den Sie zum Verschlüsseln der verwalteten Speicherdaten verwenden möchten.
1. (Optional) Um Ihren Cluster leichter identifizieren zu können, erweitern Sie den Bereich **Tags**, und konfigurieren Sie dann Ihre Tags.
[Markierung hinzufügen] Wählen Sie **Add tag (Markierung hinzufügen)**, und führen Sie die folgenden Schritte aus:
+ Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein.
+ Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein.
1. Wählen Sie **Erstellen** aus.
## Nächste Schritte
Sie müssen die Instances im Cluster registrieren. Weitere Informationen finden Sie unter [Registrieren einer externen Instance in einem Amazon-ECS-Cluster](ecs-anywhere-registration.md).
Erstellen Sie eine Aufgabendefinition für den externen Starttyp. Weitere Informationen finden Sie unter [Erstellen einer Amazon-ECS-Aufgabendefinition mit der Konsole](create-task-definition.md).
Führen Sie Ihre Anwendungen als eigenständige Aufgaben oder als Teil eines Services aus. Weitere Informationen finden Sie hier:
+ [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md)
+ [Erstellung einer Amazon-ECS-Bereitstellung mit fortlaufender Aktualisierung](create-service-console-v2.md)
# Registrieren einer externen Instance in einem Amazon-ECS-Cluster
Für jede externe Instance, die Sie bei einem Amazon-ECS-Cluster registrieren, muss der SSM Agent, der Amazon ECS Container Agent und Docker installiert sein. Um die externe Instance in einem Amazon ECS-Cluster zu registrieren, muss sie zunächst als AWS Systems Manager verwaltete Instance registriert werden. Sie können das Installationsskript mit wenigen Klicks auf der Amazon-ECS-Konsole erstellen. Das Installationsskript enthält einen Systems Manager Aktivierungsschlüssel und Befehle zur Installation aller erforderlichen Agents und Docker. Das Installationsskript muss auf Ihrem On-Premises-Server oder VM ausgeführt werden, um die Installations- und Registrierungsschritte abzuschließen.
**Anmerkung**
Bevor Sie Ihre externe Linux-Instance beim Cluster anmelden, erstellen Sie die `/etc/ecs/ecs.config`-Datei auf Ihrer externen Instance und fügen alle gewünschten Container-Agent-Konfigurationsparameter hinzu. Sie können dies nicht tun, nachdem Sie die externe Instance in einem Cluster registriert haben. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
------
#### [ AWS-Managementkonsole ]
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie die zu verwendende Region in der Navigationsleiste aus.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der Seite **Cluster** einen Cluster aus, bei dem Ihre externe Instance registriert werden soll.
1. Wählen Sie auf der *name* Seite **Cluster:** die Registerkarte **Infrastruktur** aus.
1. Führen Sie auf der Seite **Register external instances** (Externe Instances anmelden) die folgenden Schritte aus.
1. Geben sie für **Dauer des Aktivierungsschlüssels (in Tagen)** die Anzahl der Tage ein, für die der Aktivierungsschlüssel aktiv bleibt. Nach der Anzahl der Tage, die Sie eingegeben haben, funktioniert der Schlüssel nicht mehr bei der Registrierung einer externen Instance.
1. Geben Sie für die **Anzahl der Instances** die Anzahl der externen Instances ein, die Sie mit dem Aktivierungsschlüssel bei Ihrem Cluster registrieren möchten.
1. Wählen Sie für **Instance-Rolle** die IAM-Rolle aus, die Sie Ihren externen Instances zuordnen möchten. Wenn noch keine Rolle erstellt wurde, wählen Sie **Erstellen einer neuen Rolle**, damit Sie Amazon ECS eine Rolle in Ihrem Namen erstellt. Weitere Informationen zu den erforderlichen IAM-Berechtigungen für Ihre externen Instances finden Sie unter [IAM-Rolle für Amazon ECS Anywhere](iam-role-ecsanywhere.md).
1. Kopieren Sie den Anmeldungsbefehl. Dieser Befehl sollte auf jeder externen Instance ausgeführt werden, die Sie beim Cluster registrieren möchten.
**Wichtig**
Der Bash-Teil des Skripts muss als Root ausgeführt werden. Wenn der Befehl nicht als Root ausgeführt wird, wird ein Fehler zurückgegeben.
1. Klicken Sie auf **Schließen**.
------
#### [ AWS CLI for Linux operating systems ]
1. Erstellen Sie ein Systems Manager-Aktivierungspaar. Dies wird für die Aktivierung verwalteter Instances von Systems Manager verwendet. Die Ausgabe enthält eine `ActivationId` und `ActivationCode`. Sie werden sie in einem späteren Schritt verwenden. Stellen Sie sicher, dass Sie die ECS Anywhere IAM-Rolle angeben, die Sie erstellt haben. Weitere Informationen finden Sie unter [IAM-Rolle für Amazon ECS Anywhere](iam-role-ecsanywhere.md).
```
aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
```
1. Laden Sie das Installationsskript auf dem On-Premises-Server oder der virtuellen Maschine (VM) herunter.
```
curl --proto "https" -o "/tmp/ecs-anywhere-install.sh" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
```
1. (Optional) Führen Sie auf Ihrem On-Premises-Server oder Ihrer virtuellen Maschine (VM) die folgenden Schritte aus, um das Installationsskript mithilfe der Skriptsignaturdatei zu überprüfen.
1. Laden Sie GnuPG herunter und installieren Sie es. Weitere Informationen GNUpg dazu finden Sie auf der [GnuPG-Website](https://www.gnupg.org). Für Linux-Systeme installieren Sie `gpg` mit dem Paketmanager auf Ihrer Linux-Variante.
1. Rufen Sie den öffentlichen Amazon-ECS-PGP-Schlüssel ab.
```
gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
```
1. Laden Sie die Signatur des Installationsskripts herunter. Die Signaturen sind ASCII-getrennte PGP-Signaturen, die in Dateien mit der Erweiterung `.asc` gespeichert sind.
```
curl --proto "https" -o "/tmp/ecs-anywhere-install.sh.asc" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh.asc"
```
1. Überprüfen Sie die Installationsskriptdatei mit dem Schlüssel.
```
gpg --verify /tmp/ecs-anywhere-install.sh.asc /tmp/ecs-anywhere-install.sh
```
Folgendes ist die erwartete Ausgabe:
```
gpg: Signature made Tue 25 May 2021 07:16:29 PM UTC
gpg: using RSA key 50DECCC4710E61AF
gpg: Good signature from "Amazon ECS " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: F34C 3DDA E729 26B0 79BE AEC6 BCE9 D9A4 2D51 784F
Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB 346F 50DE CCC4 710E 61AF
```
1. Führen Sie auf dem On-Premises-Server oder der virtuellen Maschine (VM) das Installationsskript aus. Geben Sie im ersten Schritt den Clusternamen, die Region und die Aktivierungs-ID des Systems Manager sowie den Aktivierungscode an.
```
sudo bash /tmp/ecs-anywhere-install.sh \
--region $REGION \
--cluster $CLUSTER_NAME \
--activation-id $ACTIVATION_ID \
--activation-code $ACTIVATION_CODE
```
Für einen On-Premises-Server oder eine virtuelle Maschine (VM), auf der der NVIDIA-Treiber für GPU-Workloads installiert ist, müssen Sie das `--enable-gpu`-Flag zum Installationsskript hinzufügen. Wenn dieses Flag angegeben wird, überprüft das Installationsskript, ob der NVIDIA-Treiber ausgeführt wird, und fügt dann die erforderlichen Konfigurationsvariablen zum Ausführen Ihrer Amazon-ECS-Aufgaben hinzu. Weitere Informationen zum Ausführen von GPU-Workloads und zum Angeben von GPU-Anforderungen in einer Aufgabendefinition finden Sie unter [GPUs In einer Amazon ECS-Aufgabendefinition angeben](ecs-gpu-specifying.md).
```
sudo bash /tmp/ecs-anywhere-install.sh \
--region $REGION \
--cluster $CLUSTER_NAME \
--activation-id $ACTIVATION_ID \
--activation-code $ACTIVATION_CODE \
--enable-gpu
```
Führen Sie die folgenden Schritte aus, um eine vorhandene externe Instance bei einem anderen Cluster zu registrieren.
**So registrieren Sie eine vorhandene externe Instance in einem anderen Cluster**
1. Halten Sie den Amazon-ECS-Container-Agent an.
```
sudo systemctl stop ecs.service
```
1. Bearbeiten Sie die `/etc/ecs/ecs.config`-Datei und stellen Sie auf der `ECS_CLUSTER`-Zeile sicher, dass der Clustername mit dem Namen des Clusters übereinstimmt, bei dem die externe Instance registriert werden soll.
1. Entfernen Sie die vorhandenen Amazon-ECS-Agentendaten.
```
sudo rm /var/lib/ecs/data/agent.db
```
1. Starten Sie den Amazon-ECS-Container-Agenten.
```
sudo systemctl start ecs.service
```
------
#### [ AWS CLI for Windows operating systems ]
1. Erstellen Sie ein Systems Manager-Aktivierungspaar. Dies wird für die Aktivierung verwalteter Instances von Systems Manager verwendet. Die Ausgabe enthält eine `ActivationId` und `ActivationCode`. Sie werden sie in einem späteren Schritt verwenden. Stellen Sie sicher, dass Sie die ECS Anywhere IAM-Rolle angeben, die Sie erstellt haben. Weitere Informationen finden Sie unter [IAM-Rolle für Amazon ECS Anywhere](iam-role-ecsanywhere.md).
```
aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
```
1. Laden Sie das Installationsskript auf dem On-Premises-Server oder der virtuellen Maschine (VM) herunter.
```
Invoke-RestMethod -URI "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install.ps1" -OutFile “ecs-anywhere-install.ps1”
```
1. (Optional) Das Powershell-Skript wird von Amazon signiert und daher führt Windows die Zertifikatvalidierung automatisch auf derselben Weise durch. Sie müssen keine manuelle Validierung durchführen.
Um das Zertifikat manuell zu überprüfen, klicken Sie mit der rechten Maustaste auf die Datei, navigieren Sie zu Eigenschaften und verwenden Sie die Registerkarte Digitale Signaturen, um weitere Details zu erhalten.
Diese Option ist nur verfügbar, wenn der Host das Zertifikat im Zertifikatspeicher hat.
Die Verifizierung sollte in etwa folgendermaßen aussehen:
```
# Verification (PowerShell)
Get-AuthenticodeSignature -FilePath .\ecs-anywhere-install.ps1
SignerCertificate Status Path
----------------- ------ ----
EXAMPLECERTIFICATE Valid ecs-anywhere-install.ps1
...
Subject : CN="Amazon Web Services, Inc.",...
----
```
1. Führen Sie auf dem On-Premises-Server oder der virtuellen Maschine (VM) das Installationsskript aus. Geben Sie im ersten Schritt den Clusternamen, die Region und die Aktivierungs-ID des Systems Manager sowie den Aktivierungscode an.
```
.\ecs-anywhere-install.ps1 -Region $Region -Cluster $Cluster -ActivationID $ActivationID -ActivationCode $ActivationCode
```
1. Stellen Sie sicher, dass der Amazon-ECS-Container-Agent ausgeführt wird.
```
Get-Service AmazonECS
Status Name DisplayName
------ ---- -----------
Running AmazonECS Amazon ECS
```
Führen Sie die folgenden Schritte aus, um eine vorhandene externe Instance bei einem anderen Cluster zu registrieren.
**So registrieren Sie eine vorhandene externe Instance in einem anderen Cluster**
1. Halten Sie den Amazon-ECS-Container-Agent an.
```
Stop-Service AmazonECS
```
1. Ändern Sie den Parameter `ECS_CLUSTER` so, dass der Clustername mit dem Namen des Clusters übereinstimmt, bei dem die externe Instance angemeldet werden soll.
```
[Environment]::SetEnvironmentVariable("ECS_CLUSTER", $ECSCluster, [System.EnvironmentVariableTarget]::Machine)
```
1. Entfernen Sie die vorhandenen Amazon-ECS-Agentendaten.
```
Remove-Item -Recurse -Force $env:ProgramData\Amazon\ECS\data\*
```
1. Starten Sie den Amazon-ECS-Container-Agenten.
```
Start-Service AmazonECS
```
------
Das AWS CLI kann verwendet werden, um eine Systems Manager Manager-Aktivierung zu erstellen, bevor das Installationsskript ausgeführt wird, um den Registrierungsprozess für externe Instanzen abzuschließen.
# Abmelden einer externen Amazon-ECS-Instance
Wir empfehlen, dass Sie die Instance sowohl bei Amazon ECS als auch AWS Systems Manager danach abmelden, wenn Sie mit der Instance fertig sind. Nach Aufhebung der Registrierung kann die externe Instance keine neuen Aufgaben mehr akzeptieren.
Wenn zum Zeitpunkt der Abmeldung auf der Container-Instance Aufgaben ausgeführt werden, bleiben diese Aufgaben aktiv, bis die Aufgaben auf andere Weise gestoppt werden. Diese Aufgaben werden jedoch nicht mehr von Amazon ECS überwacht bzw. erfasst. Falls diese Aufgaben auf Ihrer externen Instance Teil eines Amazon-ECS-Service ist, startet der Service-Scheduler eine andere Kopie der betreffenden Aufgabe in einer anderen Instance, sofern dies möglich ist.
Nachdem Sie die Instance deregistriert haben, bereinigen Sie die verbleibenden AWS Ressourcen auf der Instance. Sie können die Instance dann in einem neuen Cluster registrieren.
## Verfahren
------
#### [ AWS-Managementkonsole ]
1. [Öffnen Sie die Konsole auf Version 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)
1. Wählen Sie auf der Navigationsleiste die Region aus, in der Ihre externe Instance registriert ist.
1. Wählen Sie im Navigationsbereich **Clusters** und danach den Cluster aus, der Ihre externe Instance hostet.
1. Wählen Sie auf der *name* Seite **Cluster:** die Registerkarte **Infrastruktur** aus.
1. Wählen Sie unter **Container instances** (Container-Instances) die externe Instance-ID aus, deren Anmeldung aufgehoben werden soll. Sie werden zur Detailseite für Container-Instance umgeleitet.
1. Wählen Sie auf der *id* Seite **Container Instance:** die Option **Deregister** aus.
1. Überprüfen Sie die Meldung zum Abmelden. Wählen Sie **Abmelden von AWS Systems Manager** aus, um die externe Instance auch als verwaltete Instance von Systems Manager abzumelden. Wählen Sie **Deregister**.
**Anmerkung**
Sie können die externe Instance in der Systems Manager Konsole als verwaltete Instance von Systems Manager abmelden. Anweisungen dazu finden Sie im unter [Deregistrierung verwalteter Knoten in einer Hybrid- und Multi-Cloud-Umgebung](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-deregister-hybrid-nodes.html) im *Benutzerhandbuch für AWS Systems Manager *.
1. Nachdem Sie die Instance deregistriert haben, bereinigen Sie die AWS Ressourcen auf Ihrem lokalen Server oder Ihrer VM.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)
------
#### [ AWS CLI ]
1. Sie benötigen die Instance-ID und den Container-Instance-ARN, um die Registrierung der Container-Instance aufzuheben. Wenn Sie diese Werte nicht haben, führen Sie die folgenden Befehle aus
Führen Sie den folgenden Befehl aus, um die Instance-ID zu erhalten.
Sie verwenden die Instance-ID (`instanceID`), um den Container-Instance ARN (`containerInstanceARN`) abzurufen.
```
instanceId=$(aws ssm describe-instance-information --region "{{ region }}" | jq ".InstanceInformationList[] |select(.IPAddress==\"{{ IPv4 Address }}\") | .InstanceId" | tr -d'"'
```
Führen Sie die folgenden Befehle aus.
Sie verwenden `containerInstanceArn` als Parameter im Befehl, um die Registrierung der Instance (`deregister-container-instance`) aufzuheben.
```
instances=$(aws ecs list-container-instances --cluster "{{ cluster }}" --region "{{ region }}" | jq -c '.containerInstanceArns')
containerInstanceArn=$(aws ecs describe-container-instances --cluster "{{ cluster }}" --region "{{ region }}" --container-instances $instances | jq ".containerInstances[] | select(.ec2InstanceId==\"{{ instanceId }}\") | .containerInstanceArn" | tr -d '"')
```
1. Führen Sie den folgenden Befehl aus, um die Instance zu leeren.
```
aws ecs update-container-instances-state --cluster "{{ cluster }}" --region "{{ region }}" --container-instances "{{ containerInstanceArn }}" --status DRAINING
```
1. Nachdem die Container-Instance den Ausgleich abgeschlossen hat, führen Sie den folgenden Befehl aus, um die Registrierung der Instance aufzuheben.
```
aws ecs deregister-container-instance --cluster "{{ cluster }}" --region "{{ region }}" --container-instance "{{ containerInstanceArn }}"
```
1. Führen Sie den folgenden Befehl aus, um die Container-Instance aus SSM zu entfernen.
```
aws ssm deregister-managed-instance --region "{{ region }}" --instance-id "{{ instanceId }}"
```
1. Nachdem Sie die Registrierung der Instanz aufgehoben haben, bereinigen Sie die AWS Ressourcen auf Ihrem lokalen Server oder Ihrer VM.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)
------
# Aktualisierung des AWS Systems Manager Agenten und des Amazon ECS-Container-Agenten auf einer externen Instance
Auf Ihrem lokalen Server oder Ihrer VM müssen sowohl der AWS Systems Manager Agent (SSM Agent) als auch der Amazon ECS-Container-Agent ausgeführt werden, wenn Amazon ECS-Workloads ausgeführt werden. AWS veröffentlicht neue Versionen dieser Agenten, wenn Funktionen hinzugefügt oder aktualisiert werden. Wenn Ihre externen Instances eine frühere Version eines Agent verwenden, können Sie diese mithilfe der folgenden Verfahren aktualisieren.
## Aktualisieren des SSM Agent auf einer externen Instance
AWS Systems Manager empfiehlt, dass Sie den Aktualisierungsprozess des SSM-Agenten auf Ihren Instances automatisieren. Sie bieten verschiedene Methoden zur Automatisierung von Updates. Weitere Informationen finden Sie unter [Automatisieren von Updates für SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-automatic-updates.html) im *AWS Systems Manager -Benutzerhandbuch*.
## Aktualisieren des Amazon-ECS-Agenten auf einer externen Instance
Auf Ihren externen Instances wird der Amazon-ECS-Container-Agent aktualisiert, indem das `ecs-init`-Paket aktualisiert wird. Die Aktualisierung des Amazon-ECS-Agenten unterbricht nicht die ausgeführten Tasks oder Services. Amazon ECS stellt das `ecs-init`-Paket und Signaturdatei in einem Amazon S3 Bucket in jeder Region. Beginnend mit `ecs-init`-Version `1.52.1-1`, bietet Amazon ECS separate `ecs-init`-Pakete für die Verwendung in Abhängigkeit vom Betriebssystem und der Systemarchitektur an, die Ihre externe Instance verwendet.
Verwenden Sie die folgende Tabelle, um das `ecs-init`-Paket zu bestimmen, das Sie basierend auf dem Betriebssystem und der Systemarchitektur, die Ihre externe Instance verwendet, herunterladen sollten.
**Anmerkung**
Mit den folgenden Befehlen können Sie bestimmen, welches Betriebssystem und welche Systemarchitektur Ihre externe Instance verwendet.
```
cat /etc/os-release
uname -m
```
| Betriebssysteme (Architektur) | ecs-init-Paket |
| --- | --- |
| CentOS 7 (x86\$164) CentOS 8 (x86\$164) CentOS Stream 9 (x86\$164) SUSE Enterprise Server 15 (x86\$164) RHEL 7 (x86\$164) RHEL 8 (x86\$164) | `amazon-ecs-init-latest.x86_64.rpm` |
| CentOS 7 (aarch64) CentOS 8 (aarch64) CentOS Stream 9 (aarch64) RHEL 7 (aarch64) | `amazon-ecs-init-latest.aarch64.rpm` |
| Debian 9 (x86\$164) Debian 10 (x86\$164) Debian 11 (x86\$164) Debian 12 (x86\$164) Ubuntu 18 (x86\$164) Ubuntu 20 (x86\$164) Ubuntu 22 (x86\$164) Ubuntu 24 (x86\$164) | `amazon-ecs-init-latest.amd64.deb` |
| Debian 9 (aarch64) Debian 10 (aarch64) Debian 11 (aarch64) Debian 12 (aarch64) Ubuntu 18 (aarch64) Ubuntu 20 (aarch64) Ubuntu 22 (aarch64) Ubuntu 24 (aarch64) | `amazon-ecs-init-latest.arm64.deb` |
Gehen Sie folgendermaßen vor, um den Amazon-ECS-Agenten zu aktualisieren.
**So aktualisieren Sie den Amazon-ECS-Agenten**
1. Bestätigen Sie die Version des Amazon-ECS-Agenten, die Sie ausführen.
```
curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
```
1. Herunterladen des `ecs-init`-Paket für Ihr Betriebssystem und Systemarchitektur. Amazon ECS stellt die `ecs-init`-Paketdatei in einem Amazon S3 Bucket in jeder Region. Stellen Sie sicher, dass Sie den ** Bezeichner im Befehl durch den Namen der Region (z. B.`us-west-2`) ersetzen, der Sie geografisch am nächsten sind.
**amazon-ecs-init-latest.x86\$164.rpm**
```
curl -o amazon-ecs-init.rpm https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.x86_64.rpm
```
**amazon-ecs-init-latest.aarch64.rpm**
```
curl -o amazon-ecs-init.rpm https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.aarch64.rpm
```
**amazon-ecs-init-latest.amd64.deb**
```
curl -o amazon-ecs-init.deb https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.amd64.deb
```
**amazon-ecs-init-latest.arm64.deb**
```
curl -o amazon-ecs-init.deb https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.arm64.deb
```
1. (Optional) Überprüfen der Gültigkeit der `ecs-init`-Paketdatei mit der PGP-Signatur.
1. Laden Sie GnuPG herunter und installieren Sie es. Weitere Informationen GNUpg dazu finden Sie auf der [GnuPG-Website](https://www.gnupg.org). Für Linux-Systeme installieren Sie `gpg` mit dem Paketmanager auf Ihrer Linux-Variante.
1. Rufen Sie den öffentlichen Amazon-ECS-PGP-Schlüssel ab.
```
gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
```
1. Laden Sie die `ecs-init`-Paket-Signaturdatei herunter. Die Signatur ist eine ASCII-getrennte PGP-Signatur, die in einer Datei mit der Erweiterung `.asc` gespeichert ist. Amazon ECS stellt die Signaturdatei in einem Amazon S3 Bucket in jeder Region bereit. Stellen Sie sicher, dass Sie den ** Bezeichner im Befehl durch den Namen der Region (z. B.`us-west-2`) ersetzen, der Sie geografisch am nächsten sind.
**amazon-ecs-init-latest.x86\$164.rpm**
```
curl -o amazon-ecs-init.rpm.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.x86_64.rpm.asc
```
**amazon-ecs-init-latest.aarch64.rpm**
```
curl -o amazon-ecs-init.rpm.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.aarch64.rpm.asc
```
**amazon-ecs-init-latest.amd64.deb**
```
curl -o amazon-ecs-init.deb.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.amd64.deb.asc
```
**amazon-ecs-init-latest.arm64.deb**
```
curl -o amazon-ecs-init.deb.asc https://s3..amazonaws.com/amazon-ecs-agent-/amazon-ecs-init-latest.arm64.deb.asc
```
1. Verifizieren der `ecs-init`-Paketdatei mit dem Schlüssel.
**Für die `rpm`-Pakete**
```
gpg --verify amazon-ecs-init.rpm.asc ./amazon-ecs-init.rpm
```
**Für die `deb`-Pakete**
```
gpg --verify amazon-ecs-init.deb.asc ./amazon-ecs-init.deb
```
Folgendes ist die erwartete Ausgabe:
```
gpg: Signature made Fri 14 May 2021 09:31:36 PM UTC
gpg: using RSA key 50DECCC4710E61AF
gpg: Good signature from "Amazon ECS " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: F34C 3DDA E729 26B0 79BE AEC6 BCE9 D9A4 2D51 784F
Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB 346F 50DE CCC4 710E 61AF
```
1. Installieren Sie das Paket `ecs-init`.
**Für das `rpm`-Paket auf CentOS 7, CentOS 8 und RHEL 7**
```
sudo yum install -y ./amazon-ecs-init.rpm
```
**Für das `rpm`-Paket auf SUSE Enterprise Server 15**
```
sudo zypper install -y --allow-unsigned-rpm ./amazon-ecs-init.rpm
```
**Für das `deb`-Paket**
```
sudo dpkg -i ./amazon-ecs-init.deb
```
1. Den Service `ecs` neu starten.
```
sudo systemctl restart ecs
```
1. Überprüfen Sie, ob die Amazon-ECS-Agent-Version aktualisiert wurde.
```
curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
```
# Aktualisieren eines Amazon-ECS-Clusters
Sie können die folgenden Cluster-Eigenschaften ändern:
+ Einen Standard-Kapazitätsanbieter festlegen
Jeder Cluster kann über einen oder mehrere Kapazitätsanbieter und eine optionale Kapazitätsanbieter-Standardstrategie verfügen. Die Kapazitätsanbieter-Strategie legt fest, wie die Aufgaben über die Kapazitätsanbieter eines Clusters verteilt werden. Wenn Sie eine eigenständige Aufgabe ausführen oder einen Service erstellen, können Sie entweder die Kapazitätsanbieter-Standardstrategie des Clusters verwenden oder eine Strategie für Kapazitätsanbieter angeben, die die Standardstrategie überschreibt.
+ Aktivieren von Container Insights.
CloudWatch Container Insights sammelt, aggregiert und fasst Metriken und Protokolle aus Ihren containerisierten Anwendungen und Microservices zusammen. Container Insights bietet auch Diagnoseinformationen, wie z. B. Fehler beim Container-Neustart, damit Sie Probleme schnell isolieren und beheben können. Weitere Informationen finden Sie unter [Amazon-ECS-Container mithilfe von Container Insights mit verbesserter Beobachtbarkeit überwachen](cloudwatch-container-insights.md).
+ Fügen Sie Tags hinzu, um Ihnen bei der Identifizierung Ihrer Cluster zu helfen.
**Verfahren**
1. [Öffnen Sie die Konsole auf Version 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie auf der *name* Seite **Cluster:** die Option **Cluster aktualisieren** aus.
1. Um den Standardkapazitätsanbieter festzulegen, wählen Sie unter **Standardstrategie für Kapazitätsanbieter** die Option **Weitere hinzufügen** aus.
1. Wählen Sie für **Kapazitätsanbieter** den Kapazitätsanbieter aus.
1. (Optional) Geben Sie für **Basis** die Mindestanzahl von Aufgaben ein, die auf dem Kapazitätsanbieter ausgeführt werden.
Sie können nur einen **Basis**-Wert für einen Kapazitätsanbieter festlegen.
1. (Optional) Geben Sie für **Gewicht** den relativen Prozentsatz der Gesamtzahl der gestarteten Aufgaben ein, die den angegebenen Kapazitätsanbieter nutzen.
1. (Optional) Wiederholen Sie die Schritte für alle weiteren Kapazitätsanbieter.
1. Um Container Insights zu aktivieren oder zu deaktivieren, erweitern Sie **Überwachen** und aktivieren Sie dann **Container-Insights verwenden**.
1. Um Ihren Cluster leichter identifizieren zu können, erweitern Sie den Bereich **Tags**, und konfigurieren Sie dann Ihre Tags.
[Markierung hinzufügen] Wählen Sie **Add tag (Markierung hinzufügen)**, und führen Sie die folgenden Schritte aus:
+ Geben Sie bei **Key (Schlüssel)** den Schlüsselnamen ein.
+ Geben Sie bei **Value (Wert)** den Wert des Schlüssels ein.
[Tag (Markierung) entfernen] Wählen Sie **Remove (Entfernen)** rechts neben dem Schlüssel und dem Wert des Tags (Markierung).
1. Wählen Sie **Aktualisieren** aus.
# Löschen eines Amazon-ECS-Clusters
Wenn Sie ein Cluster nicht mehr verwenden, können Sie es löschen. Nachdem Sie den Cluster gelöscht haben, wechselt er zum `INACTIVE`-Zustand. Cluster mit dem Status `INACTIVE` Status können für einen bestimmten Zeitraum im Konto erkennbar bleiben. Dieses Verhalten kann sich jedoch in Zukunft ändern und Sie sollten sich nicht darauf verlassen, dass `INACTIVE`-Cluster bestehen bleiben.
Bevor Sie einen Cluster löschen, müssen Sie die folgenden Vorgänge ausführen:
+ Löschen aller Services im Cluster. Weitere Informationen finden Sie unter [Löschen eines Amazon-ECS-Service über die Konsole](delete-service-v2.md).
+ Anhalten aller derzeit ausgeführten Aufgaben. Weitere Informationen finden Sie unter [Beenden einer Amazon-ECS-Aufgabe](standalone-task-stop.md).
+ Abmelden aller angemeldeten Container-Instances im Cluster. Weitere Informationen finden Sie unter [Abmelden einer Amazon-ECS-Container-Instance](deregister_container_instance.md).
+ Löschen Sie den -Namespace. Weitere Informationen finden Sie unter [Löschen von Namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) im *AWS Cloud Map Entwicklerleitfaden*.
**Verfahren**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie die zu verwendende Region in der Navigationsleiste aus.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Klicken Sie auf der Seite **Clusters** (Cluster) auf die zu löschenden Cluster.
1. Wählen Sie oben rechts auf der Seite **Delete Cluster (Cluster löschen)** aus.
Es wird eine Meldung angezeigt, wenn Sie nicht alle dem Cluster zugeordneten Ressourcen gelöscht haben.
1. Geben Sie im Bestätigungsfeld **Löschen** ein*cluster name*.
# Abmelden einer Amazon-ECS-Container-Instance
**Wichtig**
Dieses Thema gilt nur für Container-Instances, die in Amazon EC2 erstellt wurden. Weitere Informationen über das Abmelden externer Instances finden Sie unter [Abmelden einer externen Amazon-ECS-Instance](ecs-anywhere-deregistration.md).
Wenn Sie eine von Amazon EC2 gestützte Container-Instance nicht mehr benötigen, können Sie ihre Registrierung im Cluster aufheben. Nach Aufhebung der Registrierung kann die Container-Instance keine neuen Aufgaben mehr akzeptieren.
Wenn zum Zeitpunkt des Aufhebens der Registrierung auf der Container-Instance Aufgaben ausgeführt werden, bleiben diese Aufgaben aktiv, bis Sie die Instance beenden oder die Aufgaben auf andere Weise gestoppt werden. Diese Aufgaben sind jedoch verwaist, d. h. sie werden von Amazon ECS nicht mehr überwacht bzw. erfasst. Falls eine verwaiste Aufgabe auf Ihrer Container-Instance Teil eines Amazon-ECS-Service ist, startet der Service-Scheduler eine andere Kopie der betreffenden Aufgabe in einer anderen Container-Instance, sofern dies möglich ist. Alle Container in verwaisten Dienstaufgaben, die bei einer Application-Load-Balancer-Zielgruppe registriert sind, werden aufgehoben. Sie beginnen mit dem Connection Draining gemäß den Einstellungen auf dem Load Balancer oder der Zielgruppe. Wenn eine verwaiste Aufgabe den `awsvpc`-Netzwerkmodus verwendet, werden ihre Elastic-Network-Schnittstellen gelöscht.
Wenn Sie die Container-Instance nach der Aufhebung der Registrierung zu einem anderen Zweck verwenden möchten, sollten Sie alle auf der Container-Instance ausgeführten Tasks vor Aufhebung der Registrierung stoppen. Auf diese Weise hören alle verwaisten Aufgaben auf, Ressourcen zu verbrauchen.
Beachten Sie beim Abmelden einer Container-Instance die folgenden Überlegungen.
+ Da es zu jeder Container-Instance eindeutige Statusinformationen gibt, sollte die Registrierung von Container-Instances nicht in einem Cluster aufgehoben und in einem anderen Cluster neu vorgenommen werden. Um Ressourcen von Container-Instances zu verschieben, empfehlen wir Ihnen, die Container-Instances aus einem Cluster zu beenden und neue Container-Instances in dem neuen Cluster zu starten. Weitere Informationen finden Sie unter [Beenden Ihrer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) im *Amazon-EC2-Benutzerhandbuch* und [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
+ Wenn die Container-Instance von einer Auto Scaling Scaling-Gruppe oder einem CloudFormation Stack verwaltet wird, beenden Sie die Instance, indem Sie die Auto Scaling-Gruppe oder den Auto CloudFormation Scaling-Stack aktualisieren. Andernfalls wird die Auto-Scaling-Gruppe oder CloudFormation eine neue Instance erstellen, nachdem Sie sie beenden.
+ Wenn Sie eine aktive Container-Instance mit verbundenem Amazon-ECS-Container-Agent beenden, hebt der Agent die Registrierung der Instance in Ihrem Cluster automatisch auf. Für gestoppte Container-Instances oder Instances mit nicht verbundenen Agents wird die Registrierung bei der Beendigung nicht automatisch aufgehoben.
+ Beim Aufheben der Registrierung einer Container-Instance wird die Instance aus dem Cluster entfernt, die Amazon-EC2-Instance wird jedoch nicht beendet. Wenn Sie die Instance nicht mehr benötigen, müssen Sie sie beenden, damit keine weiteren Kosten abgerechnet werden. Weitere Informationen finden Sie unter [Beenden Ihrer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) im *Amazon-EC2-Benutzerhandbuch*.
## Verfahren
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Wählen Sie auf der Navigationsleiste die Region aus, in der Ihre externe Instance registriert ist.
1. Wählen Sie im Navigationsbereich **Clusters** und danach den Cluster aus, der Ihre Instance hostet.
1. Wählen Sie auf der *name* Seite **Cluster:** die Registerkarte **Infrastruktur** aus.
1. Wählen Sie unter **Container instances** (Container-Instances) die Instance-ID aus, deren Anmeldung aufgehoben werden soll. Sie werden zur Detailseite für Container-Instance umgeleitet.
1. Wählen Sie auf der *id* Seite **Container Instance:** die Option **Deregister** aus.
1. Wählen Sie auf dem Bestätigungsbildschirm **Registrierung aufheben**.
1. Wenn Sie die Container-Instance nicht mehr benötigen, beenden Sie die zugrunde liegende Amazon-EC2-Instance. Weitere Informationen finden Sie unter [Beenden Ihrer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) im *Amazon-EC2-Benutzerhandbuch*.
# Entlastung von Amazon-ECS-Container-Instances
Es kann vorkommen, dass Sie eine Container-Instance aus Ihrem Cluster entfernen müssen, beispielsweise, um Systemaktualisierungen durchzuführen oder die Cluster-Kapazität herunterzuskalieren. Amazon ECS bietet die Möglichkeit, eine Container-Instance in einen `DRAINING`-Status zu überführen. Dies wird *Container-Instance-Ausgleich* genannt. Wenn eine Container-Instance auf `DRAINING` festgelegt wird, lässt es Amazon ECS nicht zu, dass die Platzierung neuer Aufgaben in der Container-Instance geplant wird.
## Ausgleichsverhalten für Services
Alle Aufgaben, die Teil eines Dienstes sind, die sich in einem `PENDING`-Zustand befinden, werden sofort gestoppt. Wenn im Cluster verfügbare Kapazität für Container-Instances vorhanden ist, startet der Service-Scheduler Ersetzungsaufgaben. Wenn nicht genügend Kapazität für Container-Instances vorhanden ist, wird eine Service-Ereignismeldung gesendet, die das Problem angibt.
Aufgaben, die Teil eines Dienstes auf der Container-Instance sind, die sich in einem `RUNNING`-Zustand befinden werden in einen `STOPPED`-Zustand übertragen. Service Scheduler versucht, die Aufgaben gemäß dem Bereitstellungstyp und den Konfigurationsparametern `minimumHealthyPercent` und `maximumPercent` des Services zu ersetzen. Weitere Informationen erhalten Sie unter [Amazon-ECS-Dienstleistungen](ecs_services.md) und [Parameter der Amazon-ECS-Servicedefinition](service_definition_parameters.md).
+ Beträgt der Wert für `minimumHealthyPercent` weniger als 100 % kann der Scheduler die Angabe `desiredCount` während des Ersetzens der Aufgabe vorübergehend ignorieren. Beträgt der Wert für `desiredCount` beispielsweise vier Aufgaben, kann der Scheduler bei einem Minimum von 50 % zwei bestehende Aufgaben stoppen, bevor er zwei neue Aufgaben startet. Bei einem Minimum von 100 % kann der Service-Scheduler keine vorhandenen Aufgaben entfernen, bis die Ersatzaufgaben als fehlerfrei angesehen werden. Wenn Aufgaben für Services, die keinen Load Balancer verwenden, den Status `RUNNING` aufweisen, werden Sie als fehlerfrei angesehen. Aufgaben für Services, die einen Load Balancer nutzen, gelten als fehlerfrei, wenn Sie den Status `RUNNING` aufweisen und die Container-Instance, auf der sie gehostet sind, vom Load Balancer als fehlerfrei gemeldet wird.
**Wichtig**
Wenn Sie Spot-Instances verwenden und `minimumHealthyPercent` größer oder gleich 100 % ist, hat der Service nicht genug Zeit, um die Aufgabe zu ersetzen, bevor die Spot-Instance beendet wird.
+ Der Parameter `maximumPercent` stellt eine Obergrenze für die Anzahl der laufenden Aufgaben während der Aufgabenersetzung dar, sodass Sie die Größe des Ersatzstapels festlegen können. Bei einem `desiredCount` von vier Aufgaben beispielsweise werden bei einem Maximum von 200 % vier neue Aufgaben gestartet, bevor die vier auszugleichenden Aufgaben gestoppt werden (sofern die hierfür erforderlichen Cluster-Ressourcen verfügbar sind). Bei einem Maximum von 100 % können keine Ersatzaufgaben gestartet werden, bis die Ausgleichsaufgaben gestoppt wurden.
**Wichtig**
Wenn sowohl `minimumHealthyPercent` als auch `maximumPercent` 100 % betragen, kann der Service vorhandene Aufgaben nicht entfernen und auch keine Ersatzaufgaben starten. Dies verhindert einen erfolgreichen Ausgleich von Container-Instances und verhindert neue Bereitstellungen.
## Ausgleichsverhalten für eigenständige Aufgaben
Alle eigenständigen Aufgaben im `PENDING`- oder `RUNNING`-Status bleiben unberührt. Sie müssen warten, bis sie von alleine stoppen, oder müssen sie manuell stoppen. Die Container-Instance bleibt im Status `DRAINING`.
## Entlastungsverhalten für Amazon ECS Managed Instances
Die Kündigung von Amazon ECS Managed Instances gewährleistet reibungslose Arbeitslastübergänge bei gleichzeitiger Kostenoptimierung und Aufrechterhaltung der Systemintegrität. Das Beendigungssystem bietet drei unterschiedliche Entscheidungspfade für die Beendigung von Instances, die jeweils unterschiedliche zeitliche Merkmale und Kundenauswirkungsprofile aufweisen.
Vom Kunden initiierte Beendigung
Bietet direkte Kontrolle über das Entfernen von Instances, wenn Sie Container-Instances sofort außer Betrieb nehmen müssen. `deregister-container-instance`Bei der Ausführung ist der `force` Anforderungsparameter auf true gesetzt. Das bedeutet, dass trotz laufender Workloads eine sofortige Kündigung erforderlich ist.
Vom System initiierte Beendigung im Leerlauf
Amazon ECS Managed Instances überwacht und optimiert die Kosten kontinuierlich und proaktiv, indem inaktive Amazon ECS-Container-Instances beendet werden, auf denen keine Aufgaben ausgeführt werden. ECS verwendet eine heuristische Verzögerung, um Container-Instances die Möglichkeit zu geben, neu gestartete Aufgaben zu übernehmen, bevor sie beendet werden. Dies kann mit dem Konfigurationsparameter des Kapazitätsanbieters `scaleInAfter` Amazon ECS Managed Instances angepasst werden.
Beendigung der Aktualisierung der Infrastruktur
Amazon ECS Managed Instances verwaltet und aktualisiert automatisch Software auf verwalteten Container-Instances, um Sicherheit und Compliance zu gewährleisten und gleichzeitig die Workload-Verfügbarkeit aufrechtzuerhalten. Weitere Informationen finden Sie unter [Patchen in Amazon ECS Managed Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html).
Das Beendingungssystem verfolgt einen zweiphasigen Ansatz, bei dem die Workload-Kontinuität mit den Anforderungen an die Infrastrukturverwaltung in Einklang gebracht wird.
**Phase 1: Ordnungsgemäße Abschlusszeit**
Während dieser Phase implementiert das System Strategien zur ordnungsgemäßen Entlastung, bei denen die Kontinuität der Workload an erster Stelle steht. Serviceaufgaben werden durch normale Amazon-ECS-Planungsprozesse ordnungsgemäß ausgeglichen. Eigenständige Aufgaben werden weiterhin ausgeführt, da sie möglicherweise auf natürliche Weise abgeschlossen werden. Das System überwacht, ob alle Aufgaben durch natürliche Abschlussprozesse den Status „Angehalten“ erreichen.
**Phase 2: Strenge Durchsetzung von Fristen**
Wenn durch einen ordnungsgemäßen Abschluss die Beendigungsziele nicht innerhalb eines akzeptablen Zeitrahmens erreicht werden, führt das System eine strikte Durchsetzung der Fristen durch. Die feste Frist wird in der Regel auf die Entlastungs-Initiierungszeit plus sieben Tage festgelegt, sodass ausreichend Zeit für einen ordnungsgemäßen Abschluss unter Wahrung der betrieblichen Anforderungen zur Verfügung steht. Die Durchsetzung umfasst automatische Verfahren zur erzwungenen Abmeldung und die sofortige Beendigung aller verbleibenden Aufgaben, unabhängig vom Abschluss-Status.
Eine Container-Instance hat den Ausgleich abgeschlossen, wenn alle Aufgaben, die auf der Instance ausgeführt werden, zu einem `STOPPED`-Zustand übergegangen sind. Die Container-Instance verbleibt in einem `DRAINING`-Zustand, bis sie erneut aktiviert oder gelöscht wird. Sie können den Status der Aufgaben auf der Container-Instance überprüfen, indem Sie den [ListTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ListTasks.html)Vorgang mit dem `containerInstance` Parameter verwenden, um eine Liste von Aufgaben auf der Instance abzurufen, gefolgt von einem [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html)Vorgang mit dem Amazon-Ressourcennamen (ARN) oder der ID jeder Aufgabe, um den Aufgabenstatus zu überprüfen.
Wenn Sie bereit sind, dass die Container-Instance erneut mit dem Hosten von Tasks beginnen kann, ändern Sie den Status der Container-Instance von `DRAINING` auf `ACTIVE`. Der Amazon ECS Service Scheduler berücksichtigt dann die Container-Instance für die Aufgabenplatzierung erneut.
## Verfahren
Die folgenden Schritte können verwendet werden, um eine Container-Instance mit der neuen AWS-Managementkonsole zum Ausgleich einzustellen.
Sie können auch die [UpdateContainerInstancesState](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateContainerInstancesState.html)API-Aktion oder den [update-container-instances-state](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-container-instances-state.html)Befehl verwenden, um den Status einer Container-Instance auf zu ändern`DRAINING`.
**AWS-Managementkonsole**
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der Seite **Clusters** einen Cluster aus, der Ihre Instances hostet.
1. Wählen Sie auf der *name* Seite **Cluster:** die Registerkarte **Infrastruktur** aus. Aktivieren Sie dann unter **Container instances** (Container-Instances) das Kontrollkästchen für jede Container-Instance, die Sie ausgleichen möchten.
1. Wählen Sie **Aktionen**, **Ausgleichen**.
# Ändern des Instance-Typs oder der Instance-Größe außerhalb der Auto Scaling Scaling-Gruppe
AWS empfiehlt, dass Sie Ihre Infrastruktur unveränderlich halten. Wenn Sie die Instance-Größen ändern müssen, können Sie entweder:
+ Horizontal skalieren und zusätzliche Instanzen hinzufügen. Stellen Sie dann zusätzliche Aufgaben auf diese Instanzen, oder Sie
+ Skalieren Sie vertikal, indem Sie eine neue larger/smaller Instance starten und dann die alte Instance entleeren.
Beide Ansätze tragen dazu bei, die Auswirkungen auf die Anwendungsverfügbarkeit zu minimieren.
Wenn Sie eine andere Methode zum Ändern der Instanz verwendet haben, wird möglicherweise die folgende Fehlermeldung angezeigt:
```
Container instance type changes are not supported.
```
Wenn Sie diesen Fehler erhalten, führen Sie die folgenden Schritte aus:
1. Starten Sie neue Instances mit dem gewünschten Instanztyp.
1. Löschen Sie Ihre alten Instance-Typen. Weitere Informationen finden Sie unter [Entlastung von Amazon-ECS-Container-Instances](container-instance-draining.md).
# Amazon-ECS-EC2-Container-Instances
Der Amazon-ECS-Agent ist ein Prozess, der auf jeder Container-Instance ausgeführt wird, die in Ihrem Cluster registriert ist. Dieser Prozess erleichtert die Kommunikation zwischen Ihren Container-Instances und Amazon ECS.
**Anmerkung**
Auf Linux-Container-Instances mountet der Agent-Container hochrangige Verzeichnisse wie `/lib`, `/lib64` und `/proc`. Dies ist für ECS-Features und -Funktionen wie Amazon-EBS-Volumes, `awsvpc`-Netzwerkmodus, Amazon ECS Service Connect und FireLens für Amazon ECS erforderlich.
Jede Amazon-ECS-Container-Agenten-Version unterstützt unterschiedliche Features und bietet Fehlerbehebungen aus früheren Versionen. Wir empfehlen grundsätzlich, die neueste Version des Amazon-ECS-Container-Agenten zu verwenden, wenn dies möglich ist. Die neueste Version für Ihren Container-Agenten finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
Der Amazon-ECS-Container-Agent enthält das `amazon-ecs-pause`-Image. Amazon ECS verwendet dieses Image für Aufgaben, die den `awsvpc`-Netzwerkmodus verwenden.
Informationen darüber, welche Funktionen und Verbesserungen in den einzelnen Agent-Versionen enthalten sind, finden Sie unter [https://github.com/aws/amazon-ecs-agent/releases](https://github.com/aws/amazon-ecs-agent/releases).
**Wichtig**
Die Mindestversion von Docker für zuverlässige Metriken ist die Docker-Version `v20.10.13` und neuer, die in Amazon-ECS-optimiertem AMI `20220607` und neuer enthalten ist.
Die Amazon-ECS-Agent-Versionen `1.20.0` und neuer haben die Unterstützung für Docker-Versionen älter als `18.01.0` eingestellt.
## Lebenszyklus
Wenn der Amazon-ECS-Container-Agent eine Amazon-EC2-Instance an Ihrem Cluster registriert, meldet die Amazon-EC2-Instance den Status als `ACTIVE` und den Agent-Verbindungsstatus als `TRUE`. Die Container-Instance kann Anfragen zur Ausführung von Aufgaben akzeptieren.
Wenn Sie eine Container-Instance anhalten (nicht beenden), lautet ihr Status weiterhin `ACTIVE`, der Agent-Verbindungsstatus wird jedoch innerhalb von wenigen Minuten in `FALSE` geändert. Alle Aufgaben, die gerade auf der Container-Instance ausgeführt wurden, werden gestoppt. Wenn Sie die Container-Instance erneut starten, stellt der Container-Agent erneut eine Verbindung zum Amazon-ECS-Service her und Sie können wieder Aufgaben auf der Instance ausführen.
Wenn Sie den Status einer Container-Instance in `DRAINING` ändern, werden keine neuen Aufgaben in die Container-Instance gestellt. Wenn möglich, werden alle auf der Container-Instance ausgeführten Serviceaufgaben entfernt, damit Sie Systemaktualisierungen vornehmen können. Weitere Informationen finden Sie unter [Entlastung von Amazon-ECS-Container-Instances](container-instance-draining.md).
Wenn Sie die Registrierung einer Container-Instance aufheben oder eine Container-Instance beenden, wird ihr Status umgehend in `INACTIVE` geändert und die Container-Instance ist nicht mehr in der Auflistung Ihrer Container-Instances aufgeführt. Allerdings ist nach der Beendigung noch für eine Stunde eine Beschreibung der Container-Instance möglich. Nach einer Stunde ist die Instance-Beschreibung nicht mehr verfügbar.
Sie können die Instances manuell ausgleichen oder einen Auto-Scaling-Gruppenlebenszyklus-Hook erstellen, um den Instance-Status auf `DRAINING` zu setzen. Weitere Informationen zu Auto-Scaling-Lebenszyklus-Hooks finden Sie unter [Lebenszyklus-Hooks für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html).
## Unterstützung für Docker
Amazon ECS unterstützt die letzten beiden Hauptversionen von Docker, die unter Amazon Linux veröffentlicht wurden. Derzeit umfasst dies Docker 20.10.x und Docker 25.x.
Die mindestens erforderliche Docker-Version für Amazon ECS finden Sie in der [Amazon ECS-Agentenspezifikationsdatei](https://github.com/aws/amazon-ecs-agent/blob/dev/packaging/amazon-linux-ami-integrated/ecs-agent.spec#L53) unter GitHub.
Wenn Sie das Amazon-ECS-optimierte AMI verwenden, ist Docker für die Verwendung mit dem Amazon-ECS-Container-Agenten vorinstalliert und konfiguriert. Das AMI beinhaltet eine Docker-Version, die von Amazon ECS getestet und unterstützt wird.
**Anmerkung**
Amazon ECS unterstützt zwar mehrere Docker-Versionen, wir empfehlen jedoch, die Docker-Version zu verwenden, die mit dem Amazon-ECS-optimierten AMI geliefert wird, um die beste Kompatibilität und Unterstützung zu gewährleisten.
## Amazon-ECS-optimiertes AMI
Weitere Informationen zum Amazon ECS-optimierten AMI finden Sie unter [Amazon ECS-Optimized](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html) Linux. AMIs
## Zusätzliche Informationen
Auf den folgenden Seiten finden Sie weitere Informationen zu den Änderungen:
+ [Amazon ECS Agent-Änderungsprotokoll aktiviert](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md) GitHub
+ [Versionshinweise zu Amazon Linux 2](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html).
+ [Versionshinweise für die Docker-Engine](https://docs.docker.com/engine/release-notes/27/) in der Docker-Dokumentation
+ [NVIDIA-Treiberdokumentation](https://docs.nvidia.com/datacenter/tesla/index.html) in der NVIDIA-Dokumentation
# Konfiguration des Amazon-ECS-Container-Agenten
**Gilt für**: EC2-Instances
Der Amazon-ECS-Container-Agent unterstützt eine Reihe von Konfigurationsoptionen, von denen die meisten durch Umgebungsvariablen eingerichtet werden.
Wenn Ihre Container-Instance mit einer Linux-Variante des Amazon-ECS-optimierten AMI gestartet wurde, können Sie diese Umgebungsvariablen in der Datei `/etc/ecs/ecs.config` setzen und dann den Agenten neu starten. Sie können diese Konfigurationsvariablen auch beim Starten mit Amazon EC2-Benutzerdaten in ihre Container-Instances schreiben. Weitere Informationen finden Sie unter [Bootstrapping von Amazon-ECS-Linux-Container-Instances zur Weitergabe von Daten](bootstrap_container_instance.md).
Wenn Ihre Container-Instance mit einer Windows-Variante des Amazon ECS-optimierten AMI gestartet wurde, können Sie diese Umgebungsvariablen mit dem PowerShell SetEnvironmentVariable Befehl festlegen und dann den Agenten neu starten. Weitere Informationen finden Sie unter [Ausführen von Befehlen beim Start einer EC2-Instance mit Benutzerdateneingabe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) im *Amazon-EC2-Benutzerhandbuch* und [Bootstrapping von Windows-Container-Instances von Amazon ECS zur Weitergabe von Daten](bootstrap_windows_container_instance.md).
Wenn Sie den Amazon ECS-Container-Agenten manuell starten (für nicht Amazon ECS-optimierte Systeme AMIs), können Sie diese Umgebungsvariablen in dem **docker run** Befehl verwenden, mit dem Sie den Agenten starten. Verwenden Sie diese Variablen mit der Syntax `--env=VARIABLE_NAME=VARIABLE_VALUE`. Bei sensiblen Informationen, beispielsweise Authentifizierungs-Anmeldeinformationen für private Repositorys, sollten Sie die Agent-Umgebungsvariablen in einer Datei speichern und sie alle auf einmal mit der Option `--env-file path_to_env_file` weitergeben. Sie können die folgenden Befehle verwenden, um die Variablen hinzuzufügen.
```
sudo systemctl stop ecs
sudo vi /etc/ecs/ecs.config
# And add the environment variables with VARIABLE_NAME=VARIABLE_VALUE format.
sudo systemctl start ecs
```
## Führen Sie den Amazon-ECS-Agenten mit dem Host-PID-Namespace aus
Standardmäßig wird der Amazon-ECS-Agent mit seinem eigenen PID-Namespace ausgeführt. In den folgenden Konfigurationen können Sie den Amazon-ECS-Agenten so konfigurieren, dass er mit dem Host-PID-Namespace ausgeführt wird:
+ SELinux Der Erzwingungsmodus ist aktiviert.
+ Die SELinux Sicherheitsrichtlinie von Docker ist auf true gesetzt.
Sie können dieses Verhalten konfigurieren, indem Sie die Umgebungsvariable `ECS_AGENT_PID_NAMESPACE_HOST` in Ihrer `/etc/ecs/ecs.config`-Datei auf `true` setzen. Wenn diese Variable aktiviert ist, `ecs-init` wird der Amazon ECS-Agent-Container mit dem PID-Namespace (`--pid=host`) des Hosts gestartet, sodass sich der Agent in Umgebungen, die die Option SELinux -enforcing, ordnungsgemäß booten kann. Dieses Feature ist in Amazon-ECS-Agent-Version `1.94.0` und höher verfügbar.
Fügen Sie die folgende Zeile zu Ihrer `/etc/ecs/ecs.config`-Datei hinzu, um dieses Feature zu aktivieren:
```
ECS_AGENT_PID_NAMESPACE_HOST=true
```
Nachdem Sie diese Änderung vorgenommen haben, starten Sie den Amazon-ECS-Agenten neu, damit die Änderung wirksam wird:
```
sudo systemctl restart ecs
```
Die folgenden Funktionen funktionieren nicht, wenn der SELinux Erzwingungsmodus aktiviert ist und die Docker-Sicherheitsrichtlinie auf true gesetzt ist, auch wenn sie aktiviert ist. `ECS_AGENT_PID_NAMESPACE_HOST=true`
+ Amazon ECS Exec
+ Amazon-EBS-Aufgabe anhängen
+ Service Connect
+ FireLens für Amazon ECS
## Verfügbare Parameter
Informationen zu den verfügbaren Amazon ECS-Container-Agent-Konfigurationsparametern finden Sie unter [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) on GitHub.
# Speichern der Konfiguration von Amazon-ECS-Container-Instances in Amazon S3
Die Konfiguration des Amazon-ECS-Container-Agenten wird mit der Umgebungsvariable kontrolliert. Die Linux-Varianten des Amazon-ECS-optimierten AMI suchen nach diesen Variablen in `/etc/ecs/ecs.config`, wenn der Containeragent startet, und konfigurieren den Agenten entsprechend. Unverfängliche Umgebungsvariablen, beispielsweise `ECS_CLUSTER`, können beim Starten durch Amazon-EC2-Benutzerdaten an die Container-Instance übergeben und folgenlos in diese Datei geschrieben werden. Andere vertrauliche Informationen, wie Ihre AWS Anmeldeinformationen oder die `ECS_ENGINE_AUTH_DATA` Variable, sollten jedoch niemals in Form von Benutzerdaten an eine Instance weitergegeben oder so geschrieben werden, dass sie in einer `.bash_history` Datei angezeigt werden können. `/etc/ecs/ecs.config`
Das Speichern von Konfigurationsinformationen in einem privaten Amazon S3-Bucket und das Erteilen der schreibgeschützten Zugriffsberechtigung Ihrer IAM-Rolle der Container-Instance ist eine sichere und bequeme Art, die Konfiguration der Container-Instance zur Startzeit zu ermöglichen. Sie können eine Kopie Ihrer `ecs.config`-Datei in einem privaten Bucket speichern. Sie können dann Amazon EC2 EC2-Benutzerdaten verwenden, um die Instance zu installieren AWS CLI und Ihre Konfigurationsinformationen zu kopieren, `/etc/ecs/ecs.config` wenn die Instance gestartet wird.
**So speichern Sie eine `ecs.config`-Datei in Amazon S3**
1. Sie müssen der Container-Instance die Rechte role (**ecsInstanceRole**) gewähren, um nur Lesezugriff auf Amazon S3 zu haben. Sie können dies tun, indem Sie der Rolle **AmazonS3 ReadOnlyAccess** zuweisen. `ecsInstanceRole` Informationen zum Anhängen einer Richtlinie an eine Rolle finden Sie unter [Aktualisieren der Berechtigungen für eine Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) im *Benutzerhandbuch für AWS Identity and Access Management *.
1. Erstellen Sie eine `ecs.config`-Datei mit gültigen Amazon-ECS-Agenten-Konfigurationsvariablen im folgenden Format. Dieses Beispiel konfiguriert private Registry-Authentifizierung. Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
```
**Anmerkung**
Eine vollständige Liste der verfügbaren Amazon ECS-Agenten-Konfigurationsvariablen finden Sie unter [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) on GitHub.
1. Um Ihre Konfigurationsdatei zu speichern, erstellen Sie in Amazon S3 einen privaten Bucket. Weitere Informationen erhalten Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
1. Laden Sie die Datei `ecs.config` in Ihren S3-Bucket hoch. Weitere Informationen finden Sie unter [Hochladen von Objekten](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) im *Benutzerhandbuch von Amazon Simple Storage Service*.
**So laden Sie eine `ecs.config`-Datei beim Start von Amazon S3**
1. Führen Sie in diesem Bereich die zuvor genannten Verfahren aus, um schreibgeschützten Amazon S3-Zugriff auf Ihre Container-Instances zu ermöglichen und eine `ecs.config`-Datei in einem privaten S3-Bucket zu speichern.
1. Starten Sie neue Container-Instances und verwenden Sie das folgende Beispielskript in den EC2-Benutzerdaten. Das Skript installiert die AWS CLI und kopiert Ihre Konfigurationsdatei in`/etc/ecs/ecs.config`. Weitere Informationen finden Sie unter [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
```
#!/bin/bash
yum install -y aws-cli
aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
```
# Installieren des Amazon-ECS-Container-Agenten
Wenn Sie eine Amazon-EC2-Instance in Ihrem Amazon-ECS-Cluster registrieren möchten und diese Instance kein AMI verwendet, das auf dem Amazon-ECS-optimierten AMI basiert, können Sie den Amazon-ECS-Container-Agenten manuell mit dem folgenden Verfahren installieren. Sie können dazu den Agent entweder von einem der regionalen Amazon-S3-Buckets oder vom öffentlichen Amazon Elastic Container Registry herunterladen. Wenn Sie den Agenten aus einem der regionalen Amazon-S3-Buckets herunterladen, können Sie optional die Gültigkeit der Container-Agentendatei mithilfe der PGP-Signatur prüfen.
**Anmerkung**
Die `systemd`-Einheiten für die Amazon ECS- und Docker-Services enthalten die Anweisung, auf die Beendigung von `cloud-init` zu warten, bevor beide Services gestartet werden. Der `cloud-init`-Prozess gilt erst als abgeschlossen, wenn die Ausführung der Amazon EC2-Benutzerdaten beendet wurde. Daher kann das Starten von Amazon-ECS oder Docker über Amazon-EC2-Benutzerdaten zu einer Systemblockade führen. Um den Container-Agent mit Amazon EC2-Benutzerdaten zu starten, können Sie `systemctl enable --now --no-block ecs.service` verwenden.
## So installieren Sie den Amazon-ECS-Container-Agent auf einer Nicht–Amazon Linux-EC2-Instance
Um den Amazon-ECS-Container-Agent auf einer Amazon-EC2-Instance zu installieren, können Sie den Agent von einem der regionalen Amazon-S3-Buckets herunterladen und installieren.
**Anmerkung**
Wenn Sie ein Nicht-Amazon-Linux-AMI verwenden, erfordert Ihre Amazon-EC2-Instance `cgroupfs`-Support für die `cgroup`-Treiber, damit der Amazon-ECS-Agent Ressourcenlimits auf Aufgabenebene unterstützt. Weitere Informationen finden Sie unter [Amazon ECS-Agent unter GitHub](https://github.com/aws/amazon-ecs-agent).
Die neuesten Dateien des Container-Agents von Amazon ECS nach Region für jede Systemarchitektur sind unten als Referenz aufgeführt.
| Region | Name der Region | Amazon-ECS-Init-Deb-Dateien | Amazon-ECS-Init-rpm-Dateien |
| --- | --- | --- | --- |
| us-east-2 | USA Ost (Ohio) | [Amazon ECS init amd64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| us-east-1 | USA Ost (Nord-Virginia) | [Amazon ECS init amd64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| us-west-1 | USA West (Nordkalifornien) | [Amazon ECS init amd64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| us-west-2 | USA West (Oregon) | [Amazon ECS init amd64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-east-1 | Asien-Pazifik (Hongkong) | [Amazon ECS init amd64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-northeast-1 | Asien-Pazifik (Tokio) | [Amazon ECS init amd64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-northeast-2 | Asien-Pazifik (Seoul) | [Amazon ECS init amd64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-south-1 | Asien-Pazifik (Mumbai) | [Amazon ECS init amd64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-southeast-1 | Asien-Pazifik (Singapur) | [Amazon ECS init amd64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ap-southeast-2 | Asien-Pazifik (Sydney) | [Amazon ECS init amd64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| ca-central-1 | Kanada (Zentral) | [Amazon ECS init amd64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| eu-central-1 | Europa (Frankfurt) | [Amazon ECS init amd64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| eu-west-1 | Europa (Irland) | [Amazon ECS init amd64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| eu-west-2 | Europa (London) | [Amazon ECS init amd64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| eu-west-3 | Europa (Paris) | [Amazon ECS init amd64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| sa-east-1 | Südamerika (São Paulo) | [Amazon ECS init amd64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.x86_64.rpm) [Amazon ECS init aarch64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| us-gov-east-1 | AWS GovCloud (US-Ost) | [Amazon ECS init amd64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
| us-gov-west-1 | AWS GovCloud (US-West) | [Amazon ECS init amd64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.arm64.deb) (arm64) | [Amazon ECS init x86\$164](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64) |
**So installieren Sie den Amazon-ECS-Container-Agent auf einer Amazon-EC2-Instance mit einem Nicht-Amazon Linux-AMI**
1. Starten Sie eine Amazon-EC2-Instance mit einer IAM-Rolle, die den Zugriff auf Amazon ECS erlaubt. Weitere Informationen finden Sie unter [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md).
1. Verbinden Sie sich mit der Instance.
1. Installieren Sie die neueste Docker-Version auf Ihrer Instance.
1. Prüfen Sie Ihre Docker-Version, um sicherzustellen, dass Ihr System den Anforderungen der Mindestversion entspricht. Weitere Informationen zur Docker-Unterstützung finden Sie unter [Amazon-ECS-EC2-Container-Instances](ecs-agent-versions.md).
```
docker --version
```
1. Laden Sie die entsprechende Amazon-ECS-Agent-Datei für Ihr Betriebssystem und Ihre Systemarchitektur herunter und installieren Sie sie.
Für `deb`-Architekturen:
```
ubuntu:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb
ubuntu:~$ sudo dpkg -i amazon-ecs-init-latest.amd64.deb
```
Für `rpm`-Architekturen:
```
fedora:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm
fedora:~$ sudo yum localinstall -y amazon-ecs-init-latest.x86_64.rpm
```
1. Bearbeiten Sie die `/lib/systemd/system/ecs.service`-Datei und fügen Sie am Ende des `[Unit]`-Abschnitts die folgende Zeile hinzu.
```
After=cloud-final.service
```
1. (Optional) Um die Instance bei einem anderen Cluster als dem `default`-Cluster anzumelden, bearbeiten Sie die `/etc/ecs/ecs.config`-Datei und fügen Sie den folgenden Inhalt hinzu. Das folgende Beispiel gibt den `MyCluster`-Cluster an.
```
ECS_CLUSTER=MyCluster
```
Weitere Informationen zu diesen und anderen Agenten-Laufzeitoptionen erhalten Sie unter[Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
**Anmerkung**
Sie können Ihre Agenten-Umgebungsvariablen optional in Amazon S3 speichern (diese können in Ihren Container-Instances zum Startzeitpunkt mithilfe von Amazon EC2-Benutzerdaten heruntergeladen werden). Dies empfiehlt sich für sensible Daten, wie beispielsweise Authentifizierungs-Anmeldeinformationen für private Repositorys. Weitere Informationen erhalten Sie unter [Speichern der Konfiguration von Amazon-ECS-Container-Instances in Amazon S3](ecs-config-s3.md) und [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
1. Starten Sie den Service `ecs`.
```
ubuntu:~$ sudo systemctl start ecs
```
## Ausführen des Amazon-ECS-Agenten mit dem Host-Netzwerkmodus
Beim Ausführen des Amazon-ECS-Container-Agenten erstellt `ecs-init` den Container-Agent-Container mit dem Netzwerkmodus `host`. Dies ist der einzige unterstützte Netzwerkmodus für den Container-Agent-Container.
Dies ermöglicht Ihnen, den Zugriff auf den [Amazon-EC2-Instance-Metadaten-Service-Endpunkt](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) (`http://169.254.169.254`) für die vom Container-Agenten gestarteten Container zu blockieren. Auf diese Weise wird sichergestellt, dass Container vom Container-Instance-Profil aus keinen Zugriff auf Anmeldeinformationen der IAM-Rolle haben, und erzwungen, dass die Aufgabe nur die Anmeldeinformationen der IAM-Aufgabenrolle verwendet. Weitere Informationen finden Sie unter [Aufgaben-IAM-Rolle für Amazon ECS](task-iam-roles.md).
Dies sorgt auch dafür, dass der Container-Agent nicht um Verbindungen und Netzwerkdatenverkehr auf der `docker0`-Brücke konkurrieren muss.
## Protokoll-Konfigurationsparameter für den Amazon-ECS-Container-Agenten
Der Amazon-ECS-Container-Agent speichert Protokolle auf Ihren Container-Instances.
Bei Container-Agent-Version 1.36.0 und höher befinden sich die Protokolle standardmäßig unter `/var/log/ecs/ecs-agent.log` auf Linux-Instances und unter `C:\ProgramData\Amazon\ECS\log\ecs-agent.log` auf Windows-Instances.
Bei Container-Agent-Version 1.35.0 und früher befinden sich die Protokolle standardmäßig unter `/var/log/ecs/ecs-agent.log.timestamp` auf Linux-Instances und unter `C:\ProgramData\Amazon\ECS\log\ecs-agent.log.timestamp` auf Windows-Instances.
Standardmäßig werden die Agent-Protokolle stündlich rotiert, wobei maximal 24 Protokolle gespeichert werden.
Im Folgenden finden Sie die Konfigurationsvariablen des Container-Agenten, die verwendet werden können, um das standardmäßige Agenten-Protokollierungsverhalten zu ändern. Detaillierte Informationen zu allen verfügbaren Konfigurationsparametern finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md) oder in der [README-Datei für Amazon ECS Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) unter GitHub.
Für Container-Agent Version 1.36.0 und höher folgt eine Beispielprotokolldatei für die Verwendung des `logfmt`-Formats.
```
level=info time=2019-12-12T23:43:29Z msg="Loading configuration" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-agent:latest" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-pause:0.1.0" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Amazon ECS agent Version: 1.36.0, Commit: ca640387" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Creating root ecs cgroup: /ecs" module=init_linux.go
level=info time=2019-12-12T23:43:29Z msg="Creating cgroup /ecs" module=cgroup_controller_linux.go
level=info time=2019-12-12T23:43:29Z msg="Loading state!" module=statemanager.go
level=info time=2019-12-12T23:43:29Z msg="Event stream ContainerChange start listening..." module=eventstream.go
level=info time=2019-12-12T23:43:29Z msg="Restored cluster 'auto-robc'" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Restored from checkpoint file. I am running as 'arn:aws:ecs:us-west-2:0123456789:container-instance/auto-robc/3330a8a91d15464ea30662d5840164cd' in cluster 'auto-robc'" module=agent.go
```
Im Folgenden finden Sie eine Beispielprotokolldatei für die Verwendung des JSON-Formats.
```
{"time": "2019-11-07T22:52:02Z", "level": "info", "msg": "Starting Amazon Elastic Container Service Agent", "module": "engine.go"}
```
# Konfiguration von Amazon-ECS-Container-Instances für private Docker-Images
Der Amazon-ECS-Container-Agent kann sich unter Verwendung der Standardauthentifizierung bei privaten Registrys authentifizieren. Wenn Sie die Authentifizierung bei privaten Registrierungen aktivieren, können Sie private Docker-Images in Ihren Aufgabendefinitionen verwenden. Dieses Feature wird nur von Aufgaben unterstützt, die EC2 verwenden.
Eine andere Methode zur Aktivierung der Authentifizierung in privaten Registern besteht AWS Secrets Manager darin, Ihre Anmeldedaten für die private Registrierung sicher zu speichern und sie dann in Ihrer Container-Definition zu referenzieren. Auf diese Weise können Ihre Aufgaben Images aus privaten Repositorys verwenden. Diese Methode unterstützt Aufgaben, die entweder EC2 oder Fargate verwenden. Weitere Informationen finden Sie unter [Verwenden von AWS Nicht-Container-Images in Amazon ECS](private-auth.md).
Der Amazon-ECS-Container-Agent sucht nach zwei Umgebungsvariablen, wenn er gestartet wird:
+ `ECS_ENGINE_AUTH_TYPE` gibt die Art der gesendeten Authentifizierungsdaten an.
+ `ECS_ENGINE_AUTH_DATA` enthält die tatsächlichen Anmeldeinformationen für die Authentifizierung.
Linux-Varianten des für Amazon ECS optimierten AMI scannen die `/etc/ecs/ecs.config` Datei beim Start der Container-Instance und bei jedem Start des Service (mit dem **sudo start ecs** Befehl) nach diesen Variablen. AMIs die nicht für Amazon ECS optimiert sind, sollten diese Umgebungsvariablen in einer Datei speichern und sie zusammen mit der `--env-file path_to_env_file` Option an den **docker run** Befehl übergeben, der den Container-Agenten startet.
**Wichtig**
Wir raten davon ab, diese Umgebungsvariablen für die Authentifizierung beim Start der Instance mit Amazon EC2-Benutzerdaten einzufügen oder sie mit der Option `--env` an den Befehl **docker run** zu übergeben. Diese Methoden eigenen sich nicht für vertrauliche Daten wie z. B. Anmeldeinformationen für die Authentifizierung. Anweisungen dazu, wie Sie die Anmeldeinformationen für die Authentifizierung Ihrer Container-Instance sicher hinzufügen, finden Sie unter [Speichern der Konfiguration von Amazon-ECS-Container-Instances in Amazon S3](ecs-config-s3.md).
## Authentifizierungsformate
Es gibt zwei Formate der Authentifizierung bei privaten Registrierungen: `dockercfg` und `docker`.
**dockercfg-Authentifizierungsformat**
Das Format `dockercfg` verwendet die in der Konfigurationsdatei gespeicherten Authentifizierungsinformationen. Diese Konfigurationsdatei wird erstellt, wenn Sie den Befehl **docker login** ausführen. Sie können diese Datei durch die Ausführung von **docker login** auf Ihrem lokalen System erstellen, wobei Sie den registrierten Benutzernamen, das Passwort und die E-Mail-Adresse eingeben. Sie können sich auch bei einer Container-Instance anmelden und den Befehl dort ausführen. Je nachdem, welche Docker-Version Sie verwenden, wird diese Datei entweder als `~/.dockercfg` oder `~/.docker/config.json` gespeichert.
```
cat ~/.docker/config.json
```
Ausgabe:
```
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "zq212MzEXAMPLE7o6T25Dk0i"
}
}
}
```
**Wichtig**
Bei neueren Docker-Versionen wird, wie oben zu sehen, eine Konfigurationsdatei mit einem äußeren `auths`-Objekt erstellt. Der Amazon-ECS-Agent unterstützt nur `dockercfg`-Authentifizierungsdaten im folgenden Format, ohne das `auths`-Objekt. Wenn das Dienstprogramm **jq** installiert ist, können Sie diese Daten mit dem folgenden Befehl extrahieren: **cat \$1/.docker/config.json \$1 jq .auths**.
```
cat ~/.docker/config.json | jq .auths
```
Ausgabe:
```
{
"https://index.docker.io/v1/": {
"auth": "zq212MzEXAMPLE7o6T25Dk0i",
"email": "email@example.com"
}
}
```
Im obigen Beispiel sollte die folgende Umgebungsvariable der Umgebungsvariablendatei (`/etc/ecs/ecs.config` für das Amazon-ECS-optimierte AMI), die der Amazon-ECS-Container-Agent während der Laufzeit lädt, hinzugefügt werden. Wenn Sie das Amazon-ECS-optimierte AMI nicht verwenden und den Agenten manuell mit dem Befehl **docker run** starten, müssen Sie die Umgebungsvariablendatei beim Starten des Agenten mit der Option `--env-file path_to_env_file` festlegen.
```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
```
Sie können mehrere private Registrierungen mit der folgenden Syntax konfigurieren:
```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example-01.com"},"repo.example-02.com":{"auth":"fQ172MzEXAMPLEoF7225DU0j","email":"email@example-02.com"}}
```
**docker-Authentifizierungsformat**
Das `docker`-Format verwendet eine JSON-Darstellung des Registrierungsservers, auf dem sich der Agent authentifizieren soll. Außerdem enthält es die Authentifizierungsparameter, die für diese Registrierung benötigt werden (z. B. Benutzername, Passwort und E-Mail-Adresse für dieses Konto). Für ein Docker Hub-Konto sieht die JSON-Darstellung wie folgt aus:
```
{
"https://index.docker.io/v1/": {
"username": "my_name",
"password": "my_password",
"email": "email@example.com"
}
}
```
In diesem Beispiel sollte die folgende Umgebungsvariable der Umgebungsvariablendatei (`/etc/ecs/ecs.config` für das Amazon-ECS-optimierte AMI), die der Amazon-ECS-Container-Agent während der Laufzeit lädt, hinzugefügt werden. Wenn Sie das Amazon-ECS-optimierte AMI nicht verwenden und den Agenten manuell mit dem Befehl **docker run** starten, müssen Sie die Umgebungsvariablendatei beim Starten des Agenten mit der Option `--env-file path_to_env_file` festlegen.
```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
```
Sie können mehrere private Registrierungen mit der folgenden Syntax konfigurieren:
```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"username":"my_name","password":"my_password","email":"email@example-01.com"},"repo.example-02.com":{"username":"another_name","password":"another_password","email":"email@example-02.com"}}
```
## Verfahren
Gehen Sie wie folgt vor, um private Registrierungen für Ihre Container-Instances zu aktivieren.
**So aktivieren Sie private Registrierungen im Amazon-ECS-optimierten AMI**
1. Melden Sie sich mit SSH an Ihrer Container-Instance an.
1. Öffnen Sie die Datei `/etc/ecs/ecs.config` und fügen Sie die Werte `ECS_ENGINE_AUTH_TYPE` und `ECS_ENGINE_AUTH_DATA` für Ihre Registrierung und Ihr Konto hinzu:
```
sudo vi /etc/ecs/ecs.config
```
Dieses Beispiel authentifiziert ein Docker Hub-Benutzerkonto:
```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
```
1. Überprüfen Sie, ob ihr Agent die Umgebungsvariable `ECS_DATADIR` nutzt, um seinen Status zu speichern:
```
docker inspect ecs-agent | grep ECS_DATADIR
```
Ausgabe:
```
"ECS_DATADIR=/data",
```
**Wichtig**
Wenn der vorherige Befehl die Umgebungsvariable `ECS_DATADIR` nicht zurücksendet, müssen Sie sämtliche Aufgaben, die auf dieser Container-Instance ausgeführt werden, abbrechen, bevor Sie Ihren Agenten stoppen. Neuere Agenten mit der Umgebungsvariable `ECS_DATADIR` speichern ihren Status und Sie können sie stoppen und starten, während Aufgaben problemlos ausgeführt werden. Weitere Informationen finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
1. Stoppen Sie den Service `ecs`:
```
sudo stop ecs
```
Ausgabe:
```
ecs stop/waiting
```
1. Den Service `ecs` neu starten.
+ Für das Amazon-ECS-optimierte Amazon Linux 2-AMI:
```
sudo systemctl restart ecs
```
+ Für das Amazon-ECS-optimierte Amazon Linux AMI:
```
sudo stop ecs && sudo start ecs
```
1. (Optional) Durch Abfragen der Agenten-Introspektions-API-Operation können Sie überprüfen, ob der Agent ausgeführt wird und Sie können Informationen über Ihre neue Container-Instance einholen. Weitere Informationen finden Sie unter [Amazon-ECS-Container-Introspektion](ecs-agent-introspection.md).
```
curl http://localhost:51678/v1/metadata
```
# Automatische Bereinigung von Amazon-ECS-Aufgaben und -Images
Jedes Mal, wenn eine Aufgabe auf einer Container-Instance platziert wird, prüft der Amazon-ECS-Container-Agent, ob die Images, auf die in der Aufgabe verwiesen wird, die neuesten Images des im Repository spezifizierten Tag sind. Wenn dies nicht der Fall ist, gestattet das Standardverhalten dem Agenten, die Images aus den jeweiligen Repositorys abrufen. Wenn Sie die Images in Aufgaben und Services häufig aktualisieren, kann sich der Container-Instance-Speicher schnell mit Docker-Images füllen, die Sie nicht mehr benötigen. Beispielsweise verwenden Sie vielleicht eine Pipeline für fortlaufende Integration und fortlaufende Bereitstellung (Continous Integration and continous deployment (CI/CD)).
**Anmerkung**
Das Verhalten des Amazon-ECS-Agenten beim Abrufen von Images kann mit dem Parameter `ECS_IMAGE_PULL_BEHAVIOR` angepasst werden. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
Ebenso können Container, die zu gestoppten Aufgaben gehören, mit ihren Protokollinformationen, Daten-Volumes und anderen Artefakten Container-Instance-Speicherplatz einnehmen. Diese Artefakte eignen sich für das Debugging von Containern, die unerwarteterweise gestoppt wurden. Doch der Großteil dieses Speichers kann nach einem gewissen Zeitraum problemlos freigemacht werden.
Standardmäßig bereinigt der Amazon-ECS-Container-Agent automatisch gestoppte Aufgaben und Docker-Images, die nicht von Aufgaben auf Ihren Container-Instances verwendet werden.
**Anmerkung**
Das Feature der automatischen Image-Bereinigung erfordert mindestens die Amazon-ECS-Container-Agenten-Version 1.13.0. Die neueste Version für Ihren Agent finden Sie unter [Überprüfen des Amazon-ECS-Container-Agenten](ecs-agent-update.md).
Mit den folgenden Agentenkonfigurationsvariablen können Sie Ihre automatische Aufgaben- und Image-Bereinigung an Ihre Bedürfnisse anpassen. Weitere Informationen zum Einrichten dieser Variablen auf Ihren Container-Instances finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
`ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`
Die Standardzeit, um auf das Löschen von Containern für eine gestoppte Aufgabe zu warten. Wenn der Wert unter 1 Sekunde eingestellt ist, wird der Wert ignoriert. Standardmäßig ist dieser Parameter auf 3 Stunden eingestellt. Sie können diesen Zeitraum jedoch auf bis zu 1 Sekunde verkürzen, wenn dies für Ihre Anwendung erforderlich ist.
Der Image-Bereinigungsprozess kann kein Image löschen, wenn noch ein Container darauf verweist. Nach dem Entfernen von Containern stehen alle Images, auf die nicht verwiesen wird, für die Bereinigung anhand der Konfigurationsparameter für die Image-Bereinigung zur Verfügung.
`ECS_DISABLE_IMAGE_CLEANUP`
Wenn Sie diese Variable auf `true` einstellen, ist die automatische Image-Bereinigung auf Ihrer Container-Instance deaktiviert und es werden keine Images automatisch entfernt.
`ECS_IMAGE_CLEANUP_INTERVAL`
Diese Variable gibt an, wie häufig der automatische Image-Bereinigungsprozess prüft, ob zu löschende Images vorhanden sind. Die Standardeinstellung ist 30 Minuten. Sie können diesen Zeitraum jedoch auch bis zu 10 Minuten verkürzen, wenn die Images häufiger gelöscht werden sollen.
`ECS_IMAGE_MINIMUM_CLEANUP_AGE`
Über diese Variable wird festgelegt, wie viel Zeit mindestens zwischen dem Abrufen eines Image und dem Löschen vergehen muss. So wird verhindert, dass gerade erst abgerufene Images gelöscht werden. Die Standardeinstellung ist 1 Stunde.
`ECS_NUM_IMAGES_DELETE_PER_CYCLE`
Diese Variable gibt an, wie viele Images bei einem einzigen Bereinigungszyklus entfernt werden. Der Standardwert ist 5 und der Minimumwert beträgt 1.
Wenn der Amazon-ECS-Container-Agent ausgeführt wird und die automatische Image-Bereinigung nicht deaktiviert ist, prüft der Agent mit einer Häufigkeit, die durch die Variable `ECS_IMAGE_CLEANUP_INTERVAL` angegeben wird, ob Docker-Images vorhanden sind, auf die nicht von laufenden oder gestoppten Containern verwiesen wird. Werden ungenutzte Images gefunden und diese sind älter als die durch die Variable `ECS_IMAGE_MINIMUM_CLEANUP_AGE` angegebene Mindestbereinigungszeit, entfernt der Agent die maximale Anzahl an Images, die durch die Variable `ECS_NUM_IMAGES_DELETE_PER_CYCLE` festgelegt ist. Das Image, dessen Referenz am längsten her ist, wird als erstes gelöscht. Nach dem Entfernen der Images wartet der Agent das nächste Intervall ab und wiederholt dann den Prozess.