Überlegungen zur Verwendung von ECS Exec Voraussetzungen für die Verwendung von ECS Exec Architektur Verwenden von ECS Exec Protokollieren und Auditing mit ECS Exec Verwenden von IAM-Richtlinien, um den Zugriff auf ECS Exec zu beschränken

Überwachen von Amazon-ECS-Containern mit ECS Exec

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 damit Break-Glass-Zugriff auf Ihre Container 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. Einzelheiten zur Verwendung von ECS Exec sowie eine Videoanleitung zur Verwendung der AWS -Copilot-CLI finden Sie in der -Copilot-GitHubDokumentation.

Sie können ECS Exec auch verwenden, um strengere Zugriffssteuerungsrichtlinien beizubehalten und den Containerzugriff zu überwachen. Wenn Sie dieses Feature 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 mit ECS Exec prüfen, welche Aufgaben ausgeführt wurden, und Sie können mit CloudTrail prüfen, wer auf einen Container zugegriffen hat.

Ü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 derzeit nicht mit unterstützt AWS Management Console.
ECS Exec wird für Aufgaben unterstützt, die auf der folgenden Infrastruktur ausgeführt werden:
- Linux-Container auf Amazon EC2 auf jeder Amazon-ECS-optimierten AMI, einschließlich Bottlerocket
- Linux- und Windows-Container auf externen Instances (Amazon ECS Anywhere)
- Linux- und Windows-Container auf AWS Fargate
- Windows-Container auf Amazon EC2 auf folgenden Amazon-ECS-optimierten Windows-AMIs (mit der Container-Agent-Version 1.56 oder höher):
  - 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 und Amazon VPC
- Wenn Sie Amazon-VPC-Endpunkte als Schnittstelle mit Amazon ECS verwenden, müssen Sie die Schnittstelle Amazon-VPC-Endpunkte für Systems Manager Session Manager (ssmmessages) erstellen. Weitere Informationen zu Systems Manager VPC-Endpunkten finden Sie unter Verwenden AWS PrivateLink von zum Einrichten eines VPC-Endpunkts für Session Manager im AWS Systems Manager -Benutzerhandbuch.
- Wenn Sie die Schnittstelle Amazon VPC-Endpunkte mit Amazon ECS verwenden und AWS KMS key für die Verschlüsselung verwenden, müssen Sie die Schnittstelle Amazon-VPC-Endpunkt für AWS KMS key erstellen. Weitere Informationen finden Sie unter Verbinden mit AWS KMS key über einen VPC-Endpunkt im AWS Key Management Service -Entwicklerhandbuch.
- Wenn Sie Aufgaben haben, die auf Amazon EC2-Instances ausgeführt werden, verwenden Sie den -awsvpcNetzwerkmodus. Wenn Sie keinen Internetzugang haben, z. B. nicht für die Verwendung eines NAT-Gateways konfiguriert sind, müssen Sie die Schnittstelle Amazon VPC-Endpunkte für den Systems Manager Session Manager () erstellenssmmessages. Weitere Informationen zu Überlegungen zum awsvpc-Netzwerkmodus finden Sie unter Überlegungen. Weitere Informationen zu Systems Manager VPC-Endpunkten finden Sie unter Verwenden AWS PrivateLink von zum Einrichten eines VPC-Endpunkts für Session Manager im AWS Systems Manager -Benutzerhandbuch.
ECS Exec und SSM
- 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.
- Der SSM-Agent erfordert, dass das Container-Dateisystem in 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.
- 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“.
Die folgenden Funktionen werden als Sidecar-Container ausgeführt. Daher müssen Sie den Containernamen angeben, auf dem der Befehl ausgeführt werden soll.
- Laufzeit-Überwachung
- Service Connect
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.
ECS Exec verwendet etwas CPU und Arbeitsspeicher. Sie sollten dies berücksichtigen, wenn Sie die CPU- und Arbeitsspeicherressourcenzuordnungen in Ihrer Aufgabendefinition angeben.
Sie müssen AWS CLI Version 1.22.3 oder höher oder AWS CLI Version 2.3.6 oder höher verwenden. Informationen zum Aktualisieren der AWS CLI finden Sie unter Installieren oder Aktualisieren der neuesten Version der AWS CLI im AWS Command Line Interface -Benutzerhandbuch Version 2.
Sie können nur eine ECS-Exec-Sitzung pro Prozess-ID-Namespace (PID) haben. Wenn Sie einen PID-Namespace in einer Aufgabe freigeben, können Sie ECS-Exec-Sitzungen nur in einem Container starten.
Für die ECS Exec-Sitzung ist eine Zeitüberschreitung von 20 Minuten konfiguriert. Dieser Wert kann nicht geändert werden.
Sie können ECS Exec nicht für vorhandene Aufgaben aktivieren. Es kann nur für neue Aufgaben aktiviert werden.
Sie können ECS Exec nicht verwenden, wenn Sie verwenden, run-task um eine Aufgabe auf einem Cluster zu starten, der verwaltete Skalierung mit asynchroner Platzierung verwendet (Starten einer Aufgabe ohne Instance).
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 abgeschlossen haben:

Installieren und Konfigurieren der AWS CLI. Weitere Informationen finden Sie unter AWS CLI.
Installieren Sie das Session Manager-Plugin für die AWS CLI. Weitere Informationen finden Sie unter Installieren des Session Manager-Plugins für AWS CLI.
Sie müssen eine Aufgabenrolle mit den entsprechenden Berechtigungen für ECS Exec verwenden. Weitere Informationen finden Sie unter Aufgaben-IAM-Rollen.
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 verwenden AWS Fargate, 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.

Architektur

ECS Exec verwendet AWS Systems Manager (SSM) Session Manager, um eine Verbindung mit dem ausgeführten Container herzustellen, und verwendet AWS Identity and Access Management (IAM)-Richtlinien, um den Zugriff auf ausgeführte Befehle in einem ausgeführten Container zu steuern. 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 zusammen mit Ihrem Anwendungscode zu starten. Weitere Informationen erhalten Sie unter Systems Manager Session Manager.

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

Verwenden von ECS Exec

Änderungen an optionalen Aufgabendefinition

Wenn Sie den Aufgabendefinitionsparameter initProcessEnabled auf festlegentrue, wird der Init-Prozess innerhalb des Containers gestartet. Dadurch werden alle gefundenen untergeordneten Prozesse des Zombie-SSM-Agenten 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 Services und eigenständigen Aufgaben aktivierenupdate-service, indem Sie das ---enable-execute-commandFlag angeben, wenn Sie einen der folgenden AWS CLI Befehle verwenden: create-service, start-task, oder run-task.

Wenn Sie beispielsweise den folgenden Befehl ausführen, ist die ECS-Exec-Funktion für einen neu erstellten Service aktiviert, der auf Fargate ausgeführt wird. 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 \
    --launch-type FARGATE
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}" \
    --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 für die 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.

Der folgende Befehl führt einen interaktiven /bin/sh Befehl für einen Container namens container-name für eine Aufgabe mit der ID task-id aus.

Die Aufgaben-ID ist der Amazon-Ressourcenname (ARN) der Aufgabe.


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 Services

Wichtig

Weitere Informationen zu CloudWatch Preisen finden Sie unter -CloudWatch Preise. Amazon ECS stellt außerdem Überwachungsmetriken bereit, die ohne zusätzliche Gebühren bereitgestellt werden. Weitere Informationen finden Sie unter Überwachen von Amazon ECS mit CloudWatch .

Amazon ECS bietet eine Standardkonfiguration für die Protokollierung von Befehlen, die mit ECS Exec ausgeführt werden, indem mithilfe des in Ihrer Aufgabendefinition konfigurierten awslogs Protokolltreibers Protokolle an CloudWatch Logs gesendet 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 das Container-Image erfordertcat, dass script und installiert werden, damit Befehlsprotokolle korrekt in Amazon S3 oder CloudWatch Logs hochgeladen werden. 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 Cluster erstellt und die Ausgabe dann in Ihren CloudWatch Protokollen mit dem LogGroup Namen cloudwatch-log-group-name und Ihrem Amazon S3-Bucket mit dem Namen protokollierts3-bucket-name.

Sie müssen einen vom AWS KMS Kunden verwalteten Schlüssel verwenden, um die Protokollgruppe zu verschlüsseln, wenn Sie die CloudWatchEncryptionEnabled Option auf festlegentrue. Informationen zum Verschlüsseln der Protokollgruppe finden Sie unter Verschlüsseln von Protokolldaten in - CloudWatch Protokollen 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 von bereitgestellten Amazon CloudWatch Logs LogGroup, den Amazon S3-Bucket oder beides gesendet.

Erforderliche IAM-Berechtigungen für Amazon CloudWatch Logs oder Amazon S3-Protokollierung

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 Richtlinie hinzugefügt werden. Sie unterscheiden sich je nachdem, ob Sie Ihre Protokolle an Amazon CloudWatch Logs oder Amazon S3 weiterleiten.

Erforderliche IAM-Berechtigungen für die Verschlüsselung mit Ihrem eigenen AWS KMS key (KMS-Schlüssel)

Standardmäßig verwenden die zwischen Ihrem lokalen Client und dem Container übertragenen Daten die AWS von bereitgestellte TLS-1.2-Verschlüsselung. 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 fügen Ihrer Aufgaben-IAM-Rolle die folgende Inline-Richtlinie hinzu, die die AWS KMS Berechtigungen erfordert. 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 beschränken den Benutzerzugriff auf die API-Aktion execute-command, 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/*",
                "arn:aws:ecs:region:aws-account-id:cluster/*"
            ],
            "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:region:aws-account-id:task/cluster-name/*",
                "arn:aws:ecs:region:aws-account-id:cluster/*"
            ]
        }
    ]
}

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": "arn:aws:ecs:*:*:task/*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Task-Tag-Key": "Exec-Task"
                }
            }
        }
    ]
}

Hilfe zu Problemen, die bei der Verwendung von Amazon ECS Exec auftreten können, finden Sie unter Fehlerbehebung bei Problemen mit Exec.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Fehlerbehebung-FAQ

Empfehlungen zu Compute Optimizer