技術ブログ

【AWS SAA対策】ECS × S3 アクセス設計の正解

はじめに

Amazon ECS を利用したマイクロサービス構成は、画像処理や動画変換などの スケールしやすいバックエンド処理と非常に相性が良い設計です。

一方で、SAA 試験や実務で頻繁に混乱を招くのが、
**「ECS タスクが AWS サービスへアクセスする際の IAM ロール設計」**です。

本記事では、
ECS コンテナから Amazon S3 にアクセスする場合の正しい設計を、
試験対策と実務の両面から解説します。

問題概要

ある会社は、AWS上に画像共有アプリケーションを構築することになりました。あなたはソリューションアーキテクトとして、Amazon ECSコンテナを利用したマイクロサービスを組み合わせたアーキテクチャを設計しています。コンテナの1つのタスクは画像データを取得後に、元画像を保存用に最適なサイズに変換してから、Amazon S3バケットに保存します。したがって、このタスクの処理にはAmazon S3へのアクセス許可を設定する必要があります。

どのようにAmazon ECSコンテナとAmazon S3バケットを構成すれば良いでしょうか。

選択肢

  1. Amazon S3へのアクセス権限を付与したタスク実行ロールを作成して、Amazon ECSのタスクに設定する。
  2. Amazon S3へのアクセス権限を付与したIAMロールを作成して、タスク定義において、taskRoleArnを利用して設定する。
  3. Amazon S3へのアクセス権限を付与したIAMロールを作成して、Amazon ECS コンテナインスタンスに設定する。
  4. Amazon ECSのタスク実行ロールを設定して、Amazon S3へのアクセス権限を付与する。

これより先は回答と解説が載っているので皆さんもまずは考えてみてください。



正解となる構成

2. Amazon S3 へのアクセス権限を付与した IAM ロールを作成し、
ECS のタスク定義において taskRoleArn として設定する。

なぜこの構成が正解なのか

ECS タスクが AWS サービスへアクセスする仕組み

ECS タスク内のコンテナが S3 などの AWS API を呼び出す場合、

  • AWS SDK / CLI が 署名付きリクエストを送信
  • そのために 一時的な認証情報(STS) が必要
  • この認証情報を提供するのが タスク IAM ロール

👉 「コンテナの中のアプリケーションが使う権限」= タスク IAM ロール


taskRoleArn の役割

  • タスク定義で taskRoleArn を指定
  • タスク起動時に ECS が STS を通じてロールを引き受け
  • その権限が タスク内のすべてのコンテナ に付与される
ECS Task
  └─ taskRoleArn
        └─ IAM Policy (S3 PutObject / GetObject)

これにより、
アプリケーションコード側では IAM 認証情報を意識せずに S3 へアクセスできます。

構成図(アーキテクチャ)

        +----------------------+
        |   Amazon ECS Task    |
        |  (Image Processor)  |
        |                      |
        |  taskRoleArn        |
        |  (S3 Access Role)   |
        +----------+-----------+
                   |
          AssumeRole (STS)
                   |
        +----------v-----------+
        |   Amazon S3 Bucket   |
        |   (Image Storage)   |
        +----------------------+

不正解の選択肢とその理由

❌ オプション1

S3 へのアクセス権限を付与したタスク実行ロールを作成して、ECS タスクに設定

なぜ不正解か?

タスク実行ロール(Task Execution Role)は、

  • ECS エージェントが タスクを起動するためのロール
  • 具体例
    • ECR からイメージを pull
    • CloudWatch Logs へログ送信
    • Secrets Manager / SSM から値取得

👉 コンテナ内アプリの権限ではない


❌ オプション4

タスク実行ロールに S3 権限を付与する

  • 一見動きそうに見えるが設計として誤り
  • 責務が混在し、最小権限の原則に反する
  • SAA では明確に不正解扱いされやすい

❌ オプション3

IAM ロールを ECS コンテナインスタンスに設定

なぜ不正解か?

  • これは EC2 起動タイプの古い設計
  • すべてのタスクが同じ権限を共有してしまう
  • マイクロサービス設計・セキュリティ観点で NG

👉 現在は「タスク単位で IAM ロール」がベストプラクティス

タスク実行ロール vs タスク IAM ロール(整理)

項目タスク実行ロールタスク IAM ロール
主体ECS エージェントコンテナ内アプリ
使用タイミングタスク起動時タスク実行中
主な用途ECR / Logs / SecretsS3 / DynamoDB / SQS
設定箇所taskExecutionRoleArntaskRoleArn

SAA 試験対策ポイント

  • 「コンテナが AWS API を呼ぶ」
    → タスク IAM ロール
  • 「ECR から pull / Logs 出力」
    → タスク実行ロール
  • ECS + S3 アクセス
    taskRoleArn が正解ワード

まとめ

ECS タスクから Amazon S3 へアクセスする場合の正解は、

  • S3 権限を持つ IAM ロールを作成
  • タスク定義で taskRoleArn として設定

これにより、

  • 最小権限
  • マイクロサービス単位の権限制御
  • SAA 試験でも確実に得点できる

という設計になります。

ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。

  • 選考ではありません
  • 履歴書不要
  • 技術の話が中心
  • 所要時間30分程度
  • オンラインOK

エンジニアと話してみる