Amazon ECR
Amazon ECR（Elastic Container Registry）は、コンテナイメージを保存・管理するマネージドサービスです。
開発者
│
▼
Docker Build
│
▼
コンテナイメージ
│
│ Push
▼
Amazon ECR
│
│ Pull
▼
Amazon ECS
│
▼
コンテナ実行
ECRはイメージを保存するサービスであり、コンテナを実行するサービスではありません。
ECRの主な機能
- コンテナイメージの保存
- イメージのタグ管理
- IAMによるアクセス制御
- 脆弱性スキャン
- ライフサイクルポリシー
- レプリケーション
| 種類 | 特徴 |
|---|---|
| ECR Private | アクセスを制御するプライベートレジストリ |
| ECR Public | イメージを一般公開するためのレジストリ |
ECRへのPush
基本的な流れは以下のとおりです。
① ECRリポジトリを作成
↓
② ECRへ認証
↓
③ Dockerイメージをビルド
↓
④ ECR用のタグを設定
↓
⑤ ECRへPush
認証例：
aws ecr get-login-password \
--region ap-northeast-1 \
| docker login \
--username AWS \
--password-stdin \
123456789012.dkr.ecr.ap-northeast-1.amazonaws.com
イメージのビルド：
docker build -t my-app:latest .
タグの設定：
docker tag my-app:latest \
123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1
Push：
docker push \
123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1
※ アカウントIDやリポジトリ名はサンプルです。
TagとDigest
| 項目 | 説明 |
|---|---|
| Tag |
latestやv1.0.0などの名前 |
| Digest | イメージの内容に基づく識別子 |
my-app:latest
my-app:v1.0.0
my-app@sha256:xxxxxxxx...
タグの上書きが許可されている場合、同じタグでも参照するイメージが変わる可能性があります。
Digestを指定すると、特定のイメージを明確に識別できます。
Tag Immutability
Tag Immutabilityは、イメージタグの上書きを制限する機能です。
例えば、v1.0.0を一度登録した後、同じタグで別のイメージを登録できないようにします。
本番環境で利用するイメージの再現性を高めるために役立ちます。
イメージスキャン
ECRでは、イメージの脆弱性スキャンを利用できます。
基本スキャンとAmazon Inspectorを利用する拡張スキャンがあります。
ただし、スキャンですべての脆弱性を検出できるわけではありません。ベースイメージや依存ライブラリの更新も必要です。
ライフサイクルポリシー
ECRでは、古いイメージを整理するためのライフサイクルポリシーを利用できます。
my-app:v1
my-app:v2
my-app:v3
my-app:v4
my-app:v5
古いイメージを自動削除することでストレージ使用量を管理できます。
ただし、ロールバックに必要なイメージまで削除しないよう注意します。
Amazon ECS
Amazon ECS（Elastic Container Service）は、コンテナの起動・停止・配置・スケーリングなどを管理するコンテナオーケストレーションサービスです。
3-1. ECSの基本構成
| 用語 | 説明 |
|---|---|
| Cluster | タスクやサービスを管理する論理的なまとまり |
| Task Definition | コンテナの実行設定を定義するテンプレート |
| Task | タスク定義に基づいて起動する実行単位 |
| Service | 指定した数のタスクを継続的に維持する仕組み |
| Container | タスク内で実行されるアプリケーション |
ECS Cluster
│
└── ECS Service
│
├── Task 1
│ └── Container
│
├── Task 2
│ └── Container
│
└── Task 3
└── Container
Task Definition
Task Definitionには、主に以下の情報を定義します。
- コンテナイメージ
- CPU・メモリ
- コンテナポート
- 環境変数
- ログ出力先
- IAMロール
- ボリューム
- 起動コマンド
Fargate向けの簡略化した例です。
{
"family": "my-app",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "256",
"memory": "512",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"taskRoleArn": "arn:aws:iam::123456789012:role/myAppTaskRole",
"containerDefinitions": [
{
"name": "web",
"image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1",
"essential": true,
"portMappings": [
{
"containerPort": 80,
"protocol": "tcp"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/my-app",
"awslogs-region": "ap-northeast-1",
"awslogs-stream-prefix": "ecs"
}
}
}
]
}
ロググループやIAMロールなどは、事前に適切に準備する必要があります。
タスク定義のリビジョン
タスク定義を変更すると、新しいリビジョンとして登録されます。
my-app:1
↓
my-app:2
↓
my-app:3
例えば、コンテナイメージを更新した場合です。
my-app:1
image: my-app:v1
my-app:2
image: my-app:v2
タスク定義のリビジョンは、デプロイやロールバックを理解するうえで重要です。
4. ECSの起動方式
ECSでは、主にEC2とFargateを実行基盤として利用できます。
| 項目 | EC2 | Fargate |
|---|---|---|
| 実行基盤 | EC2インスタンス | AWS管理の基盤 |
| サーバー管理 | 利用者が管理 | AWSが管理 |
| インスタンスタイプ | 選択できる | 直接選択しない |
| ホストOS管理 | 利用者側で対応 | AWSが管理 |
| リソース指定 | インスタンス容量を考慮 | タスク単位でCPU・メモリを指定 |
| 向いている用途 | ホストの細かな制御が必要 | 運用負荷を抑えたい |
ECSはコンテナの管理、Fargateはコンテナの実行基盤です。
AWS Fargate
Fargateは、EC2インスタンスを直接管理せずにコンテナを実行するためのサーバーレスコンピューティング基盤です。
Amazon ECS
│
▼
Task Definition
│
▼
AWS Fargate
│
▼
コンテナ実行
Fargateのメリット
- EC2インスタンスの構築が不要
- ホストOSのパッチ適用を直接管理しなくてよい
- タスク単位でCPU・メモリを指定できる
- ECS Serviceと連携してスケーリングできる
- アプリケーション開発に集中しやすい
ただし、コンテナイメージやアプリケーションのセキュリティ管理は引き続き必要です。
Fargateの制約
Fargateでは、ホストOSへの直接アクセスや、ホストの細かなカスタマイズには制約があります。
CPUとメモリには利用できる組み合わせが定められており、EC2と同じ自由度で利用できるわけではありません。
Fargateのネットワーク
FargateでECSタスクを実行する場合、awsvpcネットワークモードを利用します。
タスクごとにENI（Elastic Network Interface）が割り当てられ、VPC内で通信します。
VPC
│
└── Private Subnet
│
├── ECS Task A
│ └── ENI
│
└── ECS Task B
└── ENI
タスクにセキュリティグループを設定することで、通信を制御できます。
Public SubnetとPrivate Subnet
| 配置先 | 特徴 |
|---|---|
| Public Subnet | 適切なルートとパブリックIPなどがあればインターネット通信が可能 |
| Private Subnet | インターネットへ直接接続する構成を前提としない |
FargateタスクをPrivate Subnetに配置した場合、外部サービスへアクセスするための通信経路を別途用意する必要があります。
代表的な方法は、NAT GatewayとVPCエンドポイントです。
NAT Gatewayを利用する構成
一般的なパブリックNAT Gatewayを利用する場合、NAT GatewayはPublic Subnetに配置します。
Private Subnetのルートテーブルでは、インターネット宛ての通信をNAT Gatewayへ転送するように設定します。
VPC
│
├── Private Subnet
│ │
│ └── Fargate Task
│ │
│ │ インターネット宛て通信
│ ▼
│ Route Table
│ │
│ │ 0.0.0.0/0 → NAT Gateway
│ │
└── Public Subnet
│
└── NAT Gateway
│
▼
Internet Gateway
│
▼
Internet
NAT Gatewayを利用すると、Private Subnet内のタスクから外部サービスへ通信できます。
ただし、NAT Gatewayには利用料金が発生します。
また、NAT Gatewayを利用しても、外部からPrivate Subnet内のタスクへ自由に接続できるようになるわけではありません。
VPCエンドポイントを利用する構成
AWSサービスへのアクセスには、VPCエンドポイントを利用する方法もあります。
Private Subnet
│
▼
Fargate Task
│
▼
VPC Endpoint
│
▼
AWS Service
VPCエンドポイントを利用すると、対応するAWSサービスへインターネットを経由せずにアクセスできます。
ただし、VPCエンドポイントを1つ作成すれば、すべてのAWSサービスへアクセスできるわけではありません。
利用するサービスに応じたエンドポイントが必要です。
Private SubnetからECRのイメージを取得する
ECRからプライベートイメージを取得する場合、ECRだけでなくS3への通信も関係します。
ECRとS3の関係
ECRでは、コンテナイメージのレイヤーデータの取得にS3が利用されます。
FargateのLinuxプラットフォームバージョン1.4.0以降で、Private SubnetからVPCエンドポイント経由でECRのプライベートイメージを取得する場合、代表的には以下のエンドポイントが必要です。
| エンドポイント | 種類 | 主な用途 |
|---|---|---|
com.amazonaws.region.ecr.api |
Interface | ECR APIへのアクセス |
com.amazonaws.region.ecr.dkr |
Interface | Docker Registryへのアクセス |
com.amazonaws.region.s3 |
Gateway | イメージレイヤーデータなどの取得 |
Private Subnet
│
▼
Fargate Task
│
├── ECR API Endpoint
│
├── ECR Docker Registry Endpoint
│
└── S3 Gateway Endpoint
※ Fargateのプラットフォームバージョンやイメージ取得方式によって必要な通信経路は異なります。
Secrets Managerを利用する場合
タスク起動時にSecrets Managerからシークレットを取得する場合は、Secrets Managerへの通信経路も必要です。
CloudWatch Logsへログを送信する場合も、同様に通信経路を考慮します。
NAT Gatewayを使用しない構成では、必要に応じて以下のエンドポイントを検討します。
- ECR API
- ECR Docker Registry
- S3
- Secrets Manager
- CloudWatch Logs
セキュリティグループとルートテーブル
エンドポイントを作成しても、通信設定が不適切であれば接続できません。
確認する項目は以下のとおりです。
- タスクのセキュリティグループ
- Interface Endpointのセキュリティグループ
- S3 Gateway Endpointを関連付けたルートテーブル
- VPCのDNS設定
- エンドポイントポリシー
- IAM権限
Private SubnetからECRへアクセスできない場合は、IAM権限だけでなくネットワーク経路も確認します。
ECSのIAMロール
ECSでは、Task Execution RoleとTask Roleを区別する必要があります。
| IAMロール | 主な役割 |
|---|---|
| Task Execution Role | ECS基盤がタスクを起動・管理するための権限 |
| Task Role | コンテナ内のアプリケーションなどがAWSサービスへアクセスする権限 |
Task Execution Role
Task Execution Roleは、ECSの実行基盤がAWSサービスへアクセスするためのIAMロールです。
代表的な用途は以下のとおりです。
- ECRからコンテナイメージを取得する
-
awslogsログドライバーでCloudWatch Logsへログを送信する - タスク定義で参照するシークレットを取得する
ECS / Fargate
│
│ Task Execution Role
▼
Amazon ECR
CloudWatch Logs
Secrets Manager
タスクを起動・管理するための権限と理解すると整理しやすくなります。
Task Role
Task Roleは、コンテナ内のアプリケーションがAWSサービスへアクセスするためのIAMロールです。
例えば、アプリケーションがS3からファイルを取得する場合に利用します。
ECS Task
│
└── Application
│
│ Task Role
▼
Amazon S3
S3以外にも、DynamoDBやSQSなどへのアクセスに利用できます。
また、後述するECS ExecのSSM通信権限もTask Roleに設定します。
2つのIAMロールの比較
| 比較項目 | Task Execution Role | Task Role |
|---|---|---|
| 主な利用者 | ECSの実行基盤 | コンテナ内のアプリケーションなど |
| ECRからの通常のイメージ取得 | 対象 | 通常は対象外 |
awslogsによる標準ログ送信 |
対象 | 通常は対象外 |
| タスク定義のシークレット参照 | 対象 | 通常は対象外 |
| アプリケーションからS3へアクセス | 通常は対象外 | 対象 |
| アプリケーションからDynamoDBへアクセス | 通常は対象外 | 対象 |
| ECS ExecのSSMメッセージ通信 | 通常は対象外 | 対象 |
ECSとSecrets Manager
コンテナアプリケーションでは、データベースのパスワードやAPIキーなどを利用する場合があります。
これらをDockerfileやコンテナイメージに直接埋め込むことは避けます。
Secrets ManagerやSystems Manager Parameter Storeを利用することで、機密情報を外部で管理できます。
タスク定義でシークレットを参照する
ECSのタスク定義では、secretsを利用して機密情報をコンテナへ渡せます。
{
"containerDefinitions": [
{
"name": "web",
"image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1",
"essential": true,
"secrets": [
{
"name": "DB_PASSWORD",
"valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:my-app/db-password"
}
]
}
]
}
※ 必要な部分のみを抜き出した例です。
この構成では、タスク起動時にシークレットを取得し、環境変数として渡します。
この取得処理に必要な権限は、通常、Task Execution Roleに設定します。
また、Secrets Managerのシークレットをカスタマー管理KMSキーで暗号化している場合は、Task Execution Roleにkms:Decrypt権限も必要です。
KMSキーポリシーなどによるアクセス許可も確認します。
アプリケーションから直接取得する場合
アプリケーションコードがSecrets Manager APIを呼び出して値を取得する場合は、Task Roleの権限を利用します。
タスク定義でシークレットを参照
│
▼
Task Execution Role
アプリケーションがAPIで取得
│
▼
Task Role
同じSecrets Managerへのアクセスでも、誰が取得するかによって必要なIAMロールが異なります。
ECS ServiceとAuto Scaling
ECS Serviceでは、Desired Countを指定してタスク数を維持できます。
ECS Service
Desired Count：3
│
├── Task A
├── Task B
└── Task C
タスクが異常終了した場合、ECS Serviceは必要なタスク数を維持するように動作します。
Desired Count
| 設定 | 意味 |
|---|---|
| Desired Count = 1 | 1つのタスクを維持 |
| Desired Count = 3 | 3つのタスクを維持 |
| Desired Count = 5 | 5つのタスクを維持 |
ただし、必要なコンピューティング容量やネットワーク条件が満たされなければ、指定した数のタスクを起動できない場合があります。
Service Auto Scaling
ECSでは、Application Auto Scalingを利用してサービスのタスク数を調整できます。
代表的な指標には、以下があります。
- CPU使用率
- メモリ使用率
- ALBのリクエスト数
CPU使用率が上昇
│
▼
Auto Scaling
│
▼
Desired Countを増加
│
▼
新しいタスクを起動
EC2起動方式の容量管理
EC2起動方式では、タスク数を増やしてもEC2インスタンス側に十分な容量がなければタスクを配置できません。
ECS Service
│
│ タスク数を増やしたい
▼
EC2 Cluster
│
├── EC2-A：空き容量なし
└── EC2-B：空き容量なし
この場合、サービスのスケーリングだけでなく、EC2インスタンスの容量も考慮する必要があります。
ECS Capacity Providerなどを利用して、Auto Scalingグループと連携する構成もあります。
ECSとALB
ECSでWebアプリケーションを運用する場合、ALBと組み合わせる構成があります。
利用者
│
▼
Application Load Balancer
│
├── ECS Task A
├── ECS Task B
└── ECS Task C
ALBは、複数のタスクへHTTP/HTTPSリクエストを分散します。
ターゲットグループ
ALBでは、ターゲットグループを利用して転送先を管理します。
Fargateのawsvpcネットワークモードでは、ターゲットグループのターゲットタイプとしてipを使用します。
ヘルスチェック
ALBでは、ターゲットの正常性を確認するヘルスチェックを設定できます。
例えば、アプリケーションに次のエンドポイントを用意します。
GET /health
ALBのヘルスチェックとコンテナヘルスチェックは別の仕組みです。
| 項目 | 役割 |
|---|---|
| ALBヘルスチェック | ロードバランサーの転送先として正常か確認 |
| コンテナヘルスチェック | コンテナ内部のアプリケーション状態を確認 |
障害調査では、どちらのヘルスチェックが失敗しているかを区別します。
ECSのRolling Update
Rolling Updateでは、既存タスクを段階的に新しいタスクへ置き換えます。
開始時
Task A：v1
Task B：v1
Task C：v1
更新途中
Task A：v2
Task B：v1
Task C：v1
更新途中
Task A：v2
Task B：v2
Task C：v1
更新完了
Task A：v2
Task B：v2
Task C：v2
段階的に更新するため、全タスクを同時停止する方式と比べて可用性を維持しやすくなります。
minimumHealthyPercentとmaximumPercent
Rolling Updateでは、デプロイ中のタスク数を制御するために以下の設定を利用します。
| 設定 | 意味 |
|---|---|
| minimumHealthyPercent | デプロイ中に維持する正常なタスク数の下限 |
| maximumPercent | デプロイ中に実行できるタスク数の上限 |
例えば、次の構成を考えます。
Desired Count：4
minimumHealthyPercent：50%
maximumPercent：200%
この場合、概念的には以下のように整理できます。
- 正常なタスクを最低2つ維持する
- デプロイ中のタスク数は最大8つまで許容する
ただし、実際のタスク起動・停止順序や正常性の判定は、サービスの設定やヘルスチェックなどに依存します。
Deployment Circuit Breaker
Deployment Circuit Breakerは、ECSのRolling Updateでデプロイ失敗を検出する仕組みです。
新しいタスクが正常に起動・稼働できず、サービスが安定状態に到達できない場合に、デプロイの失敗を検出します。
新しいタスク定義でデプロイ
│
▼
新タスクを起動
│
▼
タスク起動失敗
またはヘルスチェック失敗
│
▼
Deployment Circuit Breaker
│
▼
デプロイ失敗を検出
│
▼
ロールバック（有効時）
ロールバック
Deployment Circuit Breakerでは、ロールバックを有効にできます。
失敗を検出した場合、以前に正常完了したデプロイへ戻すことができます。
ただし、ロールバックを有効にしていない場合は、自動的に以前の状態へ戻るとは限りません。
利用できるデプロイ方式
Deployment Circuit Breakerは、ECSのRolling Updateで利用する仕組みです。
CodeDeployによるBlue/Greenと同じものではありません。
| 項目 | Deployment Circuit Breaker |
|---|---|
| 対象 | ECS Rolling Update |
| 主な役割 | デプロイ失敗の検出 |
| ロールバック | 設定により可能 |
| 主な確認対象 | タスクの起動・正常性など |
失敗しきい値の設定
Deployment Circuit Breakerでは、失敗のカウント方法やしきい値を設定できます。
AWS公式ドキュメントでは、以下の方式が定義されています。
| 設定 | 内容 |
|---|---|
BOUNDED_PERCENT |
Desired Countに基づく割合で計算し、上下限を適用 |
UNBOUNDED_PERCENT |
Desired Countに基づく割合で計算し、上下限を適用しない |
COUNT |
固定の失敗回数を指定 |
また、resetOnHealthyTaskによって、正常なタスクが起動した際に失敗カウントをリセットするかどうかも制御できます。
ECSのBlue/Greenデプロイ
Blue/Greenデプロイでは、旧バージョンと新バージョンの実行環境を分けて用意します。
ALB
│
▼
本番トラフィック
│
▼
Blue：旧タスク
│
│ 切り替え
▼
Green：新タスク
新しい環境を事前に検証し、正常性を確認してから本番トラフィックを切り替えることができます。
ECS向けAppSpec
CodeDeployを利用してECSへデプロイする場合、AppSpecで新しいタスク定義などを指定します。
version: 0.0
Resources:
- TargetService:
Type: AWS::ECS::Service
Properties:
TaskDefinition: "arn:aws:ecs:ap-northeast-1:123456789012:task-definition/my-app:2"
LoadBalancerInfo:
ContainerName: "web"
ContainerPort: 80
この例では、デプロイするタスク定義と、ロードバランサーが転送するコンテナ・ポートを指定しています。
ECSのライフサイクルフック
CodeDeployによるECSデプロイでは、Lambda関数を利用したライフサイクルフックを設定できます。
| イベント | 用途 |
|---|---|
| BeforeInstall | 新しいタスクセットを作成する前の検証 |
| AfterInstall | 新しいタスクセット作成後の検証 |
| AfterAllowTestTraffic | テストトラフィックを流した後の検証 |
| BeforeAllowTraffic | 本番トラフィック切り替え前の検証 |
| AfterAllowTraffic | 本番トラフィック切り替え後の検証 |
新しいタスクセットを作成
│
▼
テストトラフィックを送信
│
▼
検証用Lambda関数
│
▼
正常性を確認
│
▼
本番トラフィックを切り替え
ECS向けのCodeDeployフックと、EC2向けのCodeDeployフックは同じではありません。
また、ECS自身のデプロイ機能を利用する場合は、CodeDeploy向けAppSpecを必ず使用するわけではありません。
CloudWatch Alarmとロールバック
ECSでは、CloudWatch Alarmを利用してデプロイ中の異常を検出する構成があります。
例えば、以下のようなメトリクスを監視します。
- HTTP 5xxエラー
- アプリケーションのエラー率
- CPU使用率
- レイテンシー
新バージョンをデプロイ
│
▼
エラー率が上昇
│
▼
CloudWatch Alarm
│
▼
デプロイ異常を検出
│
▼
ロールバック（設定時）
ただし、CloudWatch Alarmを作成しただけで、すべてのECSデプロイが自動的にロールバックされるわけではありません。
デプロイ方式に対応した失敗検出やロールバック設定が必要です。
18. ECSのログ管理
ECSでは、CloudWatch Logsなどへコンテナログを送信できます。
ECS Task
│
▼
Container
│
▼
CloudWatch Logs
awslogsログドライバー
タスク定義のlogConfigurationで、CloudWatch Logsへの出力を設定できます。
{
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/my-app",
"awslogs-region": "ap-northeast-1",
"awslogs-stream-prefix": "ecs"
}
}
}
アプリケーションが標準出力や標準エラー出力へログを書き出す構成では、ログを集約しやすくなります。
このような標準的なログ送信に必要な権限は、通常、Task Execution Roleで扱います。
FireLens
FireLensは、Fluent BitやFluentdなどを利用したログルーティングの仕組みです。
Application Container
│
▼
FireLens
│
├── CloudWatch Logs
├── Amazon S3
└── その他の転送先
複数の転送先を利用したい場合や、ログの加工・転送を行いたい場合に役立ちます。
FireLensとIAMロール
FireLensでログ転送用コンテナがAWSサービスへアクセスする場合、必要な権限は通常、Task Roleに設定します。
一方、ECS基盤がFireLensの設定ファイルを取得するなどの処理では、Task Execution Roleが関係する場合があります。
つまり、ログ関連の権限であっても、すべてExecution Roleに付与するわけではありません。
| 処理 | 主に利用するロール |
|---|---|
awslogsによる標準ログ送信 |
Task Execution Role |
| FireLensのログ転送用コンテナによるAWS APIアクセス | Task Role |
| ECS基盤によるFireLens設定取得 | Task Execution Roleなど |
誰がAWS APIを呼び出すかによってIAMロールを判断することが重要です。
ECS Exec
ECS Execは、実行中のコンテナ内でコマンドを実行するための機能です。
AWS Systems Managerの仕組みを利用します。
ECS Execを有効化する
ECS Execを利用するには、サービスまたはタスクでenableExecuteCommandを有効にする必要があります。
例えば、サービスを更新する場合は次のように指定できます。
aws ecs update-service \
--cluster my-cluster \
--service my-service \
--enable-execute-command \
--force-new-deployment
既存タスクに設定を反映するには、新しいタスクを起動する必要があります。
ECS ExecのIAM権限
ECS Execでは、コンテナ内のマネージドSSMエージェントがSystems Managerのメッセージングサービスと通信します。
そのため、以下の権限をTask Roleに付与します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
}
]
}
このssmmessages権限はTask Execution Roleではなく、Task Roleに設定します。
また、ECS Execを呼び出す利用者やIAMロール側にも、ecs:ExecuteCommandなどの適切な権限が必要です。
コマンドの実行
aws ecs execute-command \
--cluster my-cluster \
--task <task-id> \
--container web \
--interactive \
--command "/bin/sh"
利用するには、対応するAWS CLIやSession Manager Pluginなどの準備も必要です。