![[アップデート] AWSマネジメントコンソールから簡単にECS Execでコンテナに接続できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-6d4fdf3578638cab4e6e4655b3d692aa/15a803840d72679e6593006354d5766b/amazon-elastic-container-service)
[アップデート] AWSマネジメントコンソールから簡単にECS Execでコンテナに接続できるようになりました
2025.09.05ECS Execでパパッとコンテナに接続したい
こんにちは、のんピ(@non____97)です。
皆さんはECS Execでパパッとコンテナに接続したいなと思ったことはありますか? 私はあります。
コンテナ内に乗り込んでトラブルシューティングをする際はECS Execが非常に便利です。
ECS ExecでECSタスクのコンテナでシェルアクセスする場合は以下のように、接続先の情報を指定する必要があります。
> aws ecs execute-command \
--cluster <クラスター名> \
--task <タスクID> \
--container <コンテナ名> \
--interactive \
--command '/bin/sh'
接続したいコンテナに合わせてこれらの情報を組み立ててコマンドを実行するのは地味に大変です。コピペミスに気づかず中々接続できないという経験もあります。
その手間を軽減するために、以下記事で紹介されているssshのようなツールを使っている方もいるでしょう。
今回、アップデートによりAWSマネジメントコンソールからECS Execでコンテナに接続できるようになりました。
これにより、自身が手元に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.
実際に試してみました。
やってみた
検証環境
検証環境は以下のとおりです。
![[アップデート] AWSマネジメントコンソールからECS Execでコンテナに接続できるようになりました検証環境構成図.png](https://devio2024-2-media.developers.io/upload/0RqxpJ2Gm3nEdxVLGKLWmq/2025-09-05/IHBEJxFuXt3i.png)
以下記事でBIG-IPの検証をした時のVPCがあったのでそのまま再利用します。
ECSタスクのデプロイ
ECSタスクのデプロイをします。
デプロイする際には以下記事で準備したコードを使用します。
AWS CDKでデプロイする際に指定するパラメーターは以下のとおりです。
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)でした!
