[アップデート] AWSマネジメントコンソールから簡単にECS Execでコンテナに接続できるようになりました

トラブルシューティング時の手間削減に
2025.09.05
 ECS Execでパパッとコンテナに接続したいこんにちは、のんピ(@non____97)です。
皆さんはECS Execでパパッとコンテナに接続したいなと思ったことはありますか? 私はあります。
コンテナ内に乗り込んでトラブルシューティングをする際はECS Execが非常に便利です。
https://dev.classmethod.jp/articles/ecs-exec/
ECS ExecでECSタスクのコンテナでシェルアクセスする場合は以下のように、接続先の情報を指定する必要があります。

					
			> aws ecs execute-command \
    --cluster <クラスター名> \
    --task <タスクID> \
    --container <コンテナ名> \
    --interactive \
    --command '/bin/sh'

		
		
接続したいコンテナに合わせてこれらの情報を組み立ててコマンドを実行するのは地味に大変です。コピペミスに気づかず中々接続できないという経験もあります。
その手間を軽減するために、以下記事で紹介されているssshのようなツールを使っている方もいるでしょう。
https://dev.classmethod.jp/articles/sssh-ecs-exec-tool/
今回、アップデートによりAWSマネジメントコンソールからECS Execでコンテナに接続できるようになりました。
https://aws.amazon.com/jp/about-aws/whats-new/2025/09/ecs-exec-aws-management-console/
これにより、自身が手元にECS Exec用のコマンドを組み立てる手間から解放されました。
What's Newには以下のように記載されていることから、AWSマネジメントコンソールから接続する際はCloudShell経由で操作するようですね。
Once enabled, simply navigate to a task details page, select a container, and click "Connect" to open an interactive session through CloudShell. The console also displays the underlying AWS CLI command, which you can customize or copy to use in your local terminal.
実際に試してみました。
 やってみた 検証環境検証環境は以下のとおりです。
以下記事でBIG-IPの検証をした時のVPCがあったのでそのまま再利用します。
https://dev.classmethod.jp/articles/big-ip-multi-az-ha-cluster-cloudformation/
 ECSタスクのデプロイECSタスクのデプロイをします。
デプロイする際には以下記事で準備したコードを使用します。
https://dev.classmethod.jp/articles/aws-cdk-ecs-fargate-bastion/
AWS CDKでデプロイする際に指定するパラメーターは以下のとおりです。
./lib/parameter/index.ts

					
			export const ecsFargateBastionStackParams: EcsFargateBastionStackParams = {
  env: {
    account: process.env.CDK_DEFAULT_ACCOUNT,
    region: process.env.CDK_DEFAULT_REGION,
  },
  property: {
    vpcId: "vpc-0287f01407d1276f0",
    vpcEndpointParams: {
      vpcEndpointSubnetSelection: {
        subnetType: cdk.aws_ec2.SubnetType.PRIVATE_ISOLATED,
        availabilityZones: ["us-east-1a"],
      },
      shouldCreateEcrVpcEndpoint: true,
      shouldCreateSsmVpcEndpoint: true,
      shouldCreateLogsVpcEndpoint: true,
      shouldCreateS3VpcEndpoint: false,
    },
    ecsFargateParams: {
      ecsFargateSubnetSelection: {
        subnetType: cdk.aws_ec2.SubnetType.PRIVATE_ISOLATED,
        availabilityZones: ["us-east-1a"],
      },
      clusterName: "ecs-fargate-bastion",
      ecrRepositoryPrefix: "ecr-public-pull-through",
      repositoryName: "ecr-public-pull-through/docker/library/busybox",
      imagesTag: "stable-musl",
      desiredCount: 1,
      inboundFromEcsServiceAllowedSecurityGroupId: [
        {
          securityGroupId: "sg-0691659b4f2310e1a",
          ports: [cdk.aws_ec2.Port.allTcp(), cdk.aws_ec2.Port.allIcmp()],
        },
      ],
    },
  },
};

		
		
正常にAWS CDKでのデプロイが完了すると以下のようにECSタスクが立ち上がっていました。
また、ECSサービスの設定画面でECS Execが有効かどうかも確認できました。
ECS Execの有効/無効も簡単に切り替えできそうです。
 ECS Execによる接続それでは、実際にECS Execで接続をします。
接続したいECSタスクのコンテナ一覧までスクロールすると、接続ボタンが増えていました。
試しに接続横のトグルをオープンして表示されたAWS CLIコマンドをコピーをクリックします。
すると、以下のようにAWS CLIを用いてESC Execで接続する際のコマンドが表示されました。


既にタスクIDなど接続に必要な情報が入力されているのはありがたいですね。手元のターミナルで操作されたい方はこちらのコマンドをコピペして実行しましょう。
続いて、接続をクリックします。
すると、CloudShellのターミナルが立ち上がり、このコマンドを実行するための新しい環境が作成されますというメッセージと共に、AWS CLIを用いてESC Execで接続する際のコマンドが表示されました。
実行をすると、CloudShellの新しいタブが開き、ECS Execのセッションが開始されました。
良い感じですね。
適当にコマンドを叩きます。

					
			/ # whoami
root
/ # 
/ # hostname
ip-10-0-3-48.ec2.internal
/ # 
/ # df -hT
Filesystem           Type            Size      Used Available Use% Mounted on
overlay              overlay        29.4G      9.3G     18.5G  34% /
tmpfs                tmpfs          64.0M         0     64.0M   0% /dev
shm                  tmpfs         460.6M         0    460.6M   0% /dev/shm
tmpfs                tmpfs         460.6M         0    460.6M   0% /sys/fs/cgroup
/dev/nvme0n1p1       ext4            4.8G      2.0G      2.7G  43% /dev/init
/dev/nvme1n1         ext4           29.4G      9.3G     18.5G  34% /etc/hosts
/dev/nvme1n1         ext4           29.4G      9.3G     18.5G  34% /etc/resolv.conf
/dev/nvme1n1         ext4           29.4G      9.3G     18.5G  34% /etc/hostname
/dev/nvme0n1p1       ext4            4.8G      2.0G      2.7G  43% /managed-agents/execute-command/amazon-ssm-agent
/dev/nvme0n1p1       ext4            4.8G      2.0G      2.7G  43% /managed-agents/execute-command/ssm-agent-worker
/dev/nvme0n1p1       ext4            4.8G      2.0G      2.7G  43% /managed-agents/execute-command/ssm-session-worker
/dev/nvme0n1p1       ext4            4.8G      2.0G      2.7G  43% /managed-agents/execute-command/certs
/dev/nvme0n1p1       ext4            4.8G      2.0G      2.7G  43% /managed-agents/execute-command/configuration
tmpfs                tmpfs         460.6M         0    460.6M   0% /proc/acpi
tmpfs                tmpfs          64.0M         0     64.0M   0% /proc/kcore
tmpfs                tmpfs          64.0M         0     64.0M   0% /proc/keys
tmpfs                tmpfs          64.0M         0     64.0M   0% /proc/timer_list
tmpfs                tmpfs          64.0M         0     64.0M   0% /proc/sched_debug
tmpfs                tmpfs         460.6M         0    460.6M   0% /sys/firmware
tmpfs                tmpfs         460.6M         0    460.6M   0% /proc/scsi
/ # 
/ # ps auxf
PID   USER     TIME  COMMAND
    1 root      0:00 /dev/init -- sh
    7 root      0:00 sh
    8 root      0:00 /managed-agents/execute-command/amazon-ssm-agent
   23 root      0:00 /managed-agents/execute-command/ssm-agent-worker
  105 root      0:00 /managed-agents/execute-command/ssm-session-worker ecs-execute-command-gcy62qyu4l2f9kqch37z3phh7y
  115 root      0:00 /bin/sh
  126 root      0:00 ps auxf

		
		
「ECS Execだぞ」という感じがしますね。
 トラブルシューティング時の手間削減にAWSマネジメントコンソールからECS Execでコンテナに接続できるようになったアップデートを紹介しました。
トラブルシューティング時の手間削減に非常に役立ちそうですね。積極的に使いましょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!