Verwenden von Amazon ECS Exec zum Debuggen - Amazon ECS

Verwenden von Amazon ECS Exec zum Debuggen

Mit Amazon ECS Exec können Sie direkt mit Containern interagieren, ohne zuerst mit dem Host-Container-Betriebssystem interagieren, eingehende Ports öffnen oder SSH-Schlüssel verwalten zu müssen. Sie können ECS Exec verwenden, um Befehle in einem Container auszuführen oder eine Shell zu erhalten, der auf einer Amazon-EC2-Instance oder auf AWS Fargate ausgeführt wird. Dies erleichtert das Sammeln von Diagnoseinformationen und die schnelle Fehlerbehebung. Beispielsweise können Sie ECS Exec in einem Entwicklungsumfeld verwenden, um problemlos mit verschiedenen Prozessen in Ihren Containern zu interagieren und Ihre Anwendungen zu beheben. Und in Produktionsszenarien können Sie es verwenden, um Bruchglas-Zugriff auf Ihre Container zu erhalten, um Probleme zu debuggen.

Sie können Befehle in einem laufenden Linux- oder Windows-Container mit ECS Exec über die Amazon-ECS-API, AWS Command Line Interface (AWS CLI), AWS-SDKs oder die AWS–Copilot-CLI ausführen. Weitere Informationen zur Verwendung von ECS Exec sowie einem Video-Walkthrough unter Verwendung der AWS-Copilot-CLI finden Sie in der Dokumentation zu Copilot Github.

Sie können ECS Exec auch verwenden, um strengere Zugriffssteuerungsrichtlinien beizubehalten und den Containerzugriff zu überwachen. Wenn Sie diese Funktion selektiv aktivieren, können Sie steuern, wer Befehle ausführen kann und für welche Tasks diese Befehle ausgeführt werden können. Mit einem Protokoll der einzelnen Befehle und ihrer Ausgabe können Sie ECS Exec verwenden, um zu überwachen, welche Aufgaben ausgeführt wurden, und Sie können CloudTrail verwenden, um zu überwachen, wer auf einen Container zugegriffen hat.

Architektur

ECS Exec nutzt AWS Systems Manager (SSM) Session Manager, um eine Verbindung mit dem laufenden Container herzustellen und verwendet AWS Identity and Access Management-Richtlinien (IAM) zum Steuern des Zugriffs auf ausgeführte Befehle in einem laufenden Container. Dies wird ermöglicht, indem die notwendigen SSM Agent-Binärdateien in den Container eingebunden werden. Der Amazon ECS- oder AWS Fargate-Agent ist dafür verantwortlich, den SSM-Core-Agent innerhalb des Containers neben Ihrem Anwendungscode zu starten. Weitere Informationen erhalten Sie unter Systems Manager Session Manager.

Sie können überwachen, welcher Benutzer auf den Container zugegriffen hat, indem Sie AWS CloudTrail verwenden und jeden Befehl (und ihre Ausgabe) in Amazon S3 oder Amazon CloudWatch Logs protokollieren. Um Daten zwischen dem lokalen Client und Container mit Ihrem eigenen Verschlüsselungsschlüssel zu verschlüsseln, müssen Sie den AWS Key Management Service (AWS KMS) -Schlüssel bereitstellen.

Überlegungen zur Verwendung von ECS Exec

Zu diesem Thema sollten Sie sich mit den folgenden Aspekten vertraut machen, die mit ECS Exec verbunden sind:

  • ECS Exec wird für AWS Fargate, externe Instances (ECS Anywhere), auf Amazon EC2 gehostete Linux-Container und die folgenden für Amazon ECS optimierten Windows-AMIs (mit der Container-Agent-Version 1.56 oder höher) unterstützt:

    • 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-optimiertes Windows Server 20H2 Core AMI

  • ECS Exec wird derzeit nicht mit AWS Management Console unterstützt.

  • ECS Exec wird derzeit nicht für Aufgaben unterstützt, die mit einem Kapazitätsanbieter für Auto-Scaling-Gruppen gelauncht wurden.

  • Wenn Sie Amazon VPC-Endpunkte mit Amazon ECS verbinden, müssen Sie die Schnittstelle Amazon VPC-Endpunkte für Systems Manager Session Manager erstellen. Weitere Informationen finden Sie unter Erstellen Sie die VPC-Endpunkte von Systems Manager Session Manager, wenn Sie die ECS-Exec-Funktion verwenden.

  • Sie können ECS Exec nicht für vorhandene Aufgaben aktivieren. Es kann nur für neue Aufgaben aktiviert werden.

  • Wenn ein Benutzer Befehle für einen Container mit ECS Exec ausführt, werden diese Befehle als der root-Benutzer ausgeführt. Der SSM Agent und seine untergeordneten Prozesse werden auch dann als Root ausgeführt, wenn Sie eine Benutzer-ID für den Container angeben.

  • Für die ECS Exec-Sitzung ist eine Standardzeitüberschreitung von 20 Minuten konfiguriert. Weitere Informationen finden Sie unter Angeben eines Zeitüberschreitungswerts für Leerlaufsitzungen im AWS Systems Manager-Benutzerhandbuch.

  • Der SSM Agent erfordert, dass auf das Container-Dateisystem geschrieben werden kann, um die erforderlichen Verzeichnisse und Dateien zu erstellen. Daher wird das Schreibschützen der Root-Dateisystem mit dem readonlyRootFilesystem-Aufgabendefinitionsparameter oder eine andere Methode nicht unterstützt.

  • Benutzer können alle Befehle ausführen, die im Container-Kontext verfügbar sind. Die folgenden Aktionen können zu verwaisten und Zombie-Prozessen führen: Beenden des Hauptprozesses des Containers, Beenden des Befehls-Agenten und Löschen von Abhängigkeiten. Um Zombie-Prozesse zu bereinigen, empfehlen wir Ihnen, das initProcessEnabled-Flag an Ihre Aufgabendefinition anzufügen.

  • Obwohl das Starten von SSM-Sitzungen außerhalb der execute-command-Aktion möglich ist, führt dies dazu, dass die Sitzungen nicht protokolliert und gegen das Sitzungslimit gezählt werden. Wir empfehlen, diesen Zugriff einzuschränken, indem Sie die ssm:start-session-Aktion mit einer IAM-Richtlinie verweigern. Weitere Informationen finden Sie unter Beschränken des Zugriffs auf die Aktion „Sitzung starten“.

  • ECS Exec wird einige CPU und Speicher verwenden. Sie sollten dies berücksichtigen, wenn Sie die CPU- und Arbeitsspeicherressourcenzuordnungen in Ihrer Aufgabendefinition angeben.

  • Sie müssen die AWS CLI Version 1.22.3 oder höher oder die AWS CLI Version 2.3.6 oder höher verwenden. Informationen zur Aktualisierung der AWS CLI finden Sie unter Installation oder Aktualisierung auf die neueste Version der AWS CLI im AWS Command Line Interface-Benutzerhandbuch Version 2.

  • Sie können ECS Exec nicht verwenden, wenn Sie mit run-task eine Aufgabe auf einem Cluster launchen, der verwaltete Skalierung mit asynchroner Platzierung verwendet (eine Aufgabe ohne Instance launchen).

  • Sie können ECS Exec nicht für Microsoft-Nano-Server-Container ausführen. Weitere Informationen zu Nano-Server-Containern finden Sie unter Nano-Server auf der Docker-Website.

Voraussetzungen für die Verwendung von ECS Exec

Bevor Sie ECS Exec verwenden, stellen Sie sicher, dass Sie die folgenden Aktionen ausgeführt haben:

  • Installieren und Konfigurieren der AWS CLI. Weitere Informationen finden Sie unter AWS CLI.

  • Installieren Sie das Session Manager-Plugin für AWS CLI. Weitere Informationen finden Sie unter Installieren des Session Manager-Plugins für AWS CLI.

  • ECS Exec hat Versionsanforderungen abhängig davon, ob Ihre Aufgaben auf Amazon EC2 oder AWS Fargate gehostet werden:

    • Wenn Sie Amazon EC2 verwenden, müssen Sie ein für Amazon ECS optimiertes AMI verwenden, das nach dem 20. Januar 2021 mit einer Agent-Version von 1.50.2 oder höher veröffentlicht wurde. Weitere Informationen finden Sie unter Amazon ECS-optimierte AMIs.

    • Wenn Sie AWS Fargate verwenden, müssen Sie die Plattformversion 1.4.0 oder höher (Linux) oder 1.0.0 (Windows) verwenden. Weitere Informationen finden Sie unter AWS Fargate-Plattformversionen.

Aktivieren und Verwenden von ECS Exec

Erforderliche IAM-Berechtigungen für ECS Exec

Die ECS Exec-Funktion erfordert eine Aufgaben-IAM-Rolle, um Containern die Berechtigungen zu erteilen, die für die Kommunikation zwischen dem verwalteten SSM Agenten (execute-command-Agent) und den SSM-Dienst. Weitere Informationen finden Sie unter Aufgaben-IAM-Rolle für Amazon ECS. Sie sollten einer Aufgaben-IAM-Rolle die folgenden Berechtigungen hinzufügen und die Aufgaben-IAM-Rolle in Ihre Aufgabendefinition aufnehmen. Weitere Informationen finden Sie unter Hinzufügen und Entfernen von IAM-Richtlinien.

Verwenden Sie die folgende Richtlinie für Ihre Aufgaben-IAM-Rolle, um die erforderlichen SSM-Berechtigungen hinzuzufügen.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel", "ssmmessages:CreateDataChannel", "ssmmessages:OpenControlChannel", "ssmmessages:OpenDataChannel" ], "Resource": "*" } ] }

Änderungen an optionalen Aufgabendefinition

Wenn Sie den Task-Definitionsparameter auf initProcessEnabled oder true setzen, startet dies den Init-Prozess innerhalb des Containers, der alle gefundenen Zombie-SSM Agent-untergeordneten Prozesse entfernt. Folgendes ist ein Beispiel.

{ "taskRoleArn": "ecsTaskRole", "networkMode": "awsvpc", "requiresCompatibilities": [ "EC2", "FARGATE" ], "executionRoleArn": "ecsTaskExecutionRole", "memory": ".5 gb", "cpu": ".25 vcpu", "containerDefinitions": [ { "name": "amazon-linux", "image": "amazonlinux:latest", "essential": true, "command": ["sleep","3600"], "linuxParameters": { "initProcessEnabled": true } } ], "family": "ecs-exec-task" }

Aktivieren von ECS Exec für Ihre Aufgaben und Services

Sie können die ECS Exec-Funktion für Ihre Dienste und eigenständige Aufgaben aktivieren, indem Sie das --enable-execute-command-Flag festlegen, wenn Sie eine der Folgenden AWS CLI-Befehle verwenden: create-service, update-service, start-task oder run-task.

Wenn Sie beispielsweise den folgenden Befehl ausführen, wird die ECS Exec-Funktion für einen neu erstellten Dienst aktiviert. Weitere Informationen zum Erstellen von Services finden Sie unter create-service.

aws ecs create-service \ --cluster cluster-name \ --task-definition task-definition-name \ --enable-execute-command \ --service-name service-name \ --desired-count 1

Nachdem Sie ECS Exec für eine Aufgabe aktiviert haben, können Sie den folgenden Befehl ausführen, um zu bestätigen, dass die Aufgabe zur Verwendung bereit ist. Wenn die lastStatus-Eigenschaft des ExecuteCommandAgent als RUNNING aufgelistet wird und die enableExecuteCommand-Eigenschaft auf true festgelegt ist, dann ist Ihre Aufgabe fertig.

aws ecs describe-tasks \ --cluster cluster-name \ --tasks task-id

Das folgende Ausgabeschnippsel ist ein Beispiel davon, was Sie sehen könnten.

{ "tasks": [ { ... "containers": [ { ... "managedAgents": [ { "lastStartedAt": "2021-03-01T14:49:44.574000-06:00", "name": "ExecuteCommandAgent", "lastStatus": "RUNNING" } ] } ], ... "enableExecuteCommand": true, ... } ] }

Ausführen von Befehlen mit ECS Exec

Nachdem Sie bestätigt haben, dass ExecuteCommandAgent ausgeführt wird, können Sie eine interaktive Shell in Ihrem Container mit dem folgenden Befehl öffnen. Wenn Ihre Aufgabe mehrere Container enthält, müssen Sie den Containernamen mithilfe des --container-Flag angeben. Amazon ECS unterstützt nur das Initiieren interaktiver Sitzungen. Daher müssen Sie das --interactive-Flag verwenden.

Mit dem folgenden Befehl wird ein interaktiver /bin/sh-Befehl für einen Container namens container-name für eine Aufgabe mit der ID task-id ausgeführt.

aws ecs execute-command --cluster cluster-name \ --task task-id \ --container container-name \ --interactive \ --command "/bin/sh"

Protokollieren und Auditing mit ECS Exec

Aktivieren der Protokollierung und Überwachung in Ihren Aufgaben und Diensten

Amazon ECS bietet eine Standardkonfiguration für Protokollierungsbefehle, die mit ECS Exec ausgeführt werden, indem Protokolle mit dem awslogs-Protokolltreiber, der in Ihrer Aufgabendefinition konfiguriert ist, an CloudWatch Logs geschickt werden. Wenn Sie eine benutzerdefinierte Konfiguration bereitstellen möchten, unterstützt AWS CLI ein --configuration-Flag sowohl für die create-cluster- und update-cluster-Befehle. Es ist auch wichtig zu wissen, dass für das Container-Image script und cat installiert werden müssen, damit Befehlsprotokolle korrekt in Amazon S3 oder CloudWatch Logs hochgeladen werden können. Weitere Informationen zum Erstellen von Clustern finden Sie unter create-cluster.

Anmerkung

Diese Konfiguration verarbeitet nur die Protokollierung der execute-command-Sitzung. Dies wirkt sich nicht auf die Protokollierung Ihrer Anwendung aus.

Im folgenden Beispiel wird ein Dienst erstellt und anschließend wird die Ausgabe zu Ihrer CloudWatch Logs LogGroup mit dem Namen cloudwatch-log-group-name und Ihrem Amazon S3 Bucket mit dem Namen s3-bucket-name protokolliert.

Sie müssen einen vom Kunden verwalteten AWS KMS-Schlüssel verwenden, um die Protokollgruppe zu verschlüsseln, wenn Sie die CloudWatchEncryptionEnabled-Option auf true setzen. Weitere Informationen zum Verschlüsseln der Protokollgruppe finden Sie unter Verschlüsseln von Protokolldaten in CloudWatch Logs mit AWS Key Management Service im Amazon CloudWatch Logs-Benutzerhandbuch.

aws ecs create-cluster \ --cluster-name cluster-name \ --configuration executeCommandConfiguration="{ \ kmsKeyId=string, \ logging=OVERRIDE, \ logConfiguration={ \ cloudWatchLogGroupName=cloudwatch-log-group-name, \ cloudWatchEncryptionEnabled=true, \ s3BucketName=s3-bucket-name, \ s3EncryptionEnabled=true, \ s3KeyPrefix=demo \ } \ }"

Die logging-Eigenschaft bestimmt das Verhalten der Protokollierungsfunktion von ECS Exec:

  • NONE: Die Protokollierung ist deaktiviert

  • DEFAULT: Protokolle werden an den konfigurierten awslogs-Treiber gesendet (Wenn der Treiber nicht konfiguriert ist, wird kein Protokoll gespeichert.)

  • OVERRIDE: Protokolle werden an die bereitgestellte Amazon CloudWatch Logs Group, Amazon S3 Bucket oder beide gesendet

Erforderliche IAM-Berechtigungen für das Protokollieren von Amazon CloudWatch Logs oder Amazon S3

Um die Protokollierung zu aktivieren, benötigt die Amazon ECS-Aufgabenrolle, die in Ihrer Aufgabendefinition referenziert wird, zusätzliche Berechtigungen. Diese zusätzlichen Berechtigungen können der Aufgabenrolle als Inline-Richtlinie hinzugefügt werden. Je nachdem, ob Sie Ihre Protokolle an Amazon CloudWatch Logs oder Amazon S3 weiterleiten, unterscheiden sich diese.

Amazon CloudWatch Logs

Das folgende Beispiel einer Inline-Richtlinie fügt die erforderlichen Amazon CloudWatch Logs-Berechtigungen hinzu:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:DescribeLogGroups" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:DescribeLogStreams", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:region:account-id:log-group:/aws/ecs/cloudwatch-log-group-name:*" } ] }
Amazon S3

Das folgende Beispiel einer Inline-Richtlinie fügt die erforderlichen Amazon S3-Berechtigungen hinzu:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetBucketLocation" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetEncryptionConfiguration" ], "Resource": "arn:aws:s3:::s3-bucket-name" }, { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::s3-bucket-name/*" } ] }

IAM-Berechtigungen, die für die Verschlüsselung mit Ihrer eigenen AWS KMS key(KMS-Schlüssel) erforderlich ist

Standardmäßig verwenden die zwischen Ihrem lokalen Client und dem Container übertragenen Daten TLS 1.2-Verschlüsselung, die AWS bietet. Um Daten mit Ihrem eigenen KMS-Schlüssel weiter zu verschlüsseln, müssen Sie einen KMS-Schlüssel erstellen und die kms:Decrypt-Berechtigung für Ihre Aufgaben-IAM-Rolle hinzufügen. Diese Berechtigung wird von Ihrem Container verwendet, um die Daten zu entschlüsseln. Weitere Informationen zum Erstellen eines KMS-Schlüssels finden Sie unter Erstellen von Schlüsseln.

Sie würden die folgende Inling-Richtlinie zu Ihrer Aufgaben-IAM-Rolle hinzufügen, die die AWS KMS-Berechtigungen erfordern. Weitere Informationen finden Sie unter Erforderliche IAM-Berechtigungen für ECS Exec.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "kms-key-arn" } ] }

Damit die Daten mit Ihrem eigenen KMS-Schlüssel verschlüsselt werden, muss dem Benutzer oder der Gruppe, der/die die execute-command-Aktion verwendet, die kms:GenerateDataKey-Berechtigung gewährt werden.

Die folgende Beispielrichtlinie für Ihren Benutzer oder Ihre Gruppe enthält die erforderliche Berechtigung, Ihren eigenen KMS-Schlüssel zu verwenden. Sie müssen den Amazon-Ressourcennamen (ARN) Ihres KMS-Schlüssels angeben.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:GenerateDataKey" ], "Resource": "kms-key-arn" } ] }

Verwenden von IAM-Richtlinien, um den Zugriff auf ECS Exec zu beschränken

Sie können den Benutzerzugriff auf die API-Aktion Execute-command beschränken, indem Sie einen oder mehrere der folgenden IAM-Richtlinienbedingungsschlüssel verwenden:

  • aws:ResourceTag/clusterTagKey

  • ecs:ResourceTag/clusterTagKey

  • aws:ResourceTag/taskTagKey

  • ecs:ResourceTag/taskTagKey

  • ecs:container-name

  • ecs:cluster

  • ecs:task

  • ecs:enable-execute-command

Mit dem folgenden Beispiel einer IAM-Richtlinie können Benutzer Befehle in Containern ausführen, die innerhalb von Aufgaben mit einem Tag ausgeführt werden, das einen environment-Schlüssel und development-Wert hat und in einem Cluster mit dem Namen cluster-name.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecs:ExecuteCommand", "ecs:DescribeTasks" ], "Resource": "arn:aws:ecs:region:aws-account-id:task/cluster-name/*", "Condition": { "StringEquals": { "ecs:ResourceTag/environment": "development" } } } ] }

Im folgenden IAM-Richtlinienbeispiel können Benutzer die execute-command-API nicht verwenden, wenn der Containername production-app lautet.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "ecs:ExecuteCommand" ], "Resource": "*", "Condition": { "StringEquals": { "ecs:container-name": "production-app" } } } ] }

Mit der folgenden IAM-Richtlinie können Benutzer Aufgaben nur starten, wenn ECS Exec deaktiviert ist.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecs:RunTask", "ecs:StartTask", "ecs:CreateService", "ecs:UpdateService" ], "Resource": "*", "Condition": { "StringEquals": { "ecs:enable-execute-command": "false" } } } ] }
Anmerkung

Da die execute-commandAPI-Aktion nur Task- und Clusterressourcen in einer Anforderung enthält, werden nur Cluster- und Task-Tags ausgewertet.

Weitere Informationen zu IAM-Richtlinienbedingungsschlüsseln finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für den Amazon Elastic Container Service in der Service Authorization-Referenz.

Beschränken des Zugriffs auf die Aktion „Sitzung starten“

Während das Starten von SSM-Sitzungen auf Ihrem Container außerhalb von ECS Exec möglich ist, kann dies möglicherweise dazu führen, dass die Sitzungen nicht protokolliert werden. Sitzungen, die außerhalb von ECS Exec gestartet wurden, zählen ebenfalls zum Sitzungskontingent. Wir empfehlen, diesen Zugriff einzuschränken, indem Sie die ssm:start-session-Aktion direkt für Ihre Amazon ECS-Aufgaben mithilfe einer IAM-Richtlinie verweigern. Sie können den Zugriff auf alle Amazon ECS-Aufgaben oder bestimmte Aufgaben basierend auf den verwendeten Tags verweigern.

Nachfolgend finden Sie eine Beispiel-IAM-Richtlinie, die den Zugriff auf die ssm:start-session-Aktion für Tasks in allen Regionen mit einem angegebenen Clusternamen verweigert. Optional können Sie einen Platzhalter mit cluster-name einschließen.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ssm:StartSession", "Resource": "arn:aws:ecs:*:111122223333:task/cluster-name/*" } ] }

Nachfolgend finden Sie eine Beispiel-IAM-Richtlinie, die den Zugriff auf die ssm:start-session-Aktion für Ressourcen in allen Regionen, die mit Tag-Schlüssel Task-Tag-Key markiert sind und Tag-Wert Exec-Task haben, verweigert.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ssm:StartSession", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Task-Tag-Key": "Exec-Task" } } } ] }

Beheben von Problemen mit ECS Exec

Im Folgenden finden Sie Hinweise zur Fehlerbehebung, um zu diagnostizieren, warum Sie bei der Verwendung von ECS Exec einen Fehler erhalten.

Überprüfen Sie mit dem Amazon ECS Exec Checker

Das Amazon ECS Exec Checker-Skript bietet eine Möglichkeit, zu überprüfen und zu bestätigen, ob Ihr Amazon ECS-Cluster und Ihre Aufgabe die Voraussetzungen für die Verwendung der ECS Exec-Funktion erfüllt haben. Das Exec-Checker-Skript überprüft, das sowohl Ihre AWS CLI-Umgebung als auch Ihre Cluster und Aufgaben bereit für ECS Exec sind, indem es verschiedene APIs in Ihrem Namen aufruft. Das Tool benötigt die neueste Version des AWS CLI und dass jq verfügbar ist. Weitere Informationen finden Sie unter Amazon ECS Exec-Checker auf GitHub.

Fehler beim Aufruf von execute-command

Wenn ein The execute command failed-Fehler auftritt, könnte folgendes die möglichen Ursachen sein.

  • Der Task verfügt nicht über die erforderlichen Berechtigungen. Stellen Sie sicher, dass für die Aufgabendefinition, die zum Starten der Aufgabe verwendet wird, eine Aufgaben-IAM-Rolle definiert ist und dass die Rolle über die erforderlichen Berechtigungen verfügt. Weitere Informationen finden Sie unter Erforderliche IAM-Berechtigungen für ECS Exec.

  • Der SSM-Agent ist nicht installiert oder wird nicht ausgeführt

  • Es gibt einen Amazon-VPC-Schnittstellen-Endpunkt für Amazon ECS, aber es gibt keinen für Systems Manager Session Manager