ECSマネージドインスタンスにおけるイメージPullメカニズムの設定分析

ENECHANGE所属のエンジニア id:tetsushi_fukabori こと深堀です。
急速に寒くなってきた2025年10月13日の週にこの記事を執筆しています。皆さんはお健やかにお過ごしでしょうか。
私はというとつい最近勤続5年の休暇を頂いて、家族の犬と二人でキャンプ＆登山をしてきました。
家族の犬は原産が寒い地域の大型犬なのでもはや寒いレベルのキャンプがたいそう楽しかったらしく、5℃を下回っていそうな気温でも外の地面でうたた寝をしていました。身体が強すぎる。

---

今回は2025年09月30日に発表されたAmazon ECSのManaged Instancesに関する記事です。
Managed Instancesは発表直後から様々な技術ブログで解説が取り上げられているので詳細は省略しますが、Fargateの簡便さとEC2インスタンスのコストの優秀さ・制御しやすさを両取りするようなECSのインフラ機能で、AWSが管理するEC2インスタンス上でECSタスクを稼働させる機能です。
個人的にはセキュリティ周りなどをAWSが引き受けてくれる点が特に良いのだろうと思っています。

aws.amazon.com

今回着目したのはManaged Instances上ではECSエージェントの設定はどうなっているのか？特にイメージPull設定についてどうなっているのか？です。
iselegantさんの下記の記事にでも触れられていますが、Managed InstancesはEC2インスタンスなのでイメージのキャッシュが効くことが期待されます。
一方で、キャッシュの利用についてはECSエージェントの設定の影響を受けますが、Managed Instancesではインスタンスの起動テンプレートに介入できないためECSエージェントの設定を調整できず、AWSの設定に従う形になります。

iselegant.hatenablog.com

今回はこのような状況でECSエージェントの振る舞いを通じてManaged InstancesにおけるECSエージェントのイメージPull設定を調査しました。
併せてECSにおけるイメージのキャッシュに関して調査・整理しています。

この記事を届けたい人

• ECSエージェントのイメージPull設定による振る舞いを理解したい方
• Managed Instancesのコンテナイメージのキャッシュ設定を把握したい方

概略

この記事は長いので忙しい人向けに先に概略を書いておきます。

• Managed InstancesにおけるECSエージェントの振る舞い（ECS_IMAGE_PULL_BEHAVIOR）はalways相当のもよう
  • ECRからのイメージPullに失敗した場合、ローカルにイメージが存在していてもエラー終了します
• ECSエージェントのキャッシュ関連の振る舞いは以下のように整理できる
  • defaultはまずPullを試行し、その成否によらずコンテナ作成を実行
  • alwaysはまずPullを試行し、Pull失敗はタスクのエラー終了、Pull成功はコンテナ作成を実行
  • onceはまず過去にECSエージェント経由でPullに成功しているか履歴をチェックし、Pull成功の履歴がなければPullを試行し、その成否によらずコンテナ作成を実行
  • prefer-cachedはローカルのイメージの存在をチェックし、存在しなければPullを試行し、その成否によらずコンテナ作成を実行
• ECSエージェントの振る舞いとは別にDockerエンジンによるレイヤーキャッシュやローカルイメージの利用が以下の点で介在しうるため、ユーザーから見るとECSエージェントのREADMEと相違しているように見えることがある
  • Pull時にマニフェストの各レイヤーのハッシュ値に一致するレイヤーがローカルに存在する場合、そのレイヤーを流用（"Already exists"）しNW経由でのダウンロードは行わない
  • コンテナ作成時にローカルに必要なイメージが存在する場合、そのイメージを利用してコンテナを作成する

追記

この記事を執筆中にドキュメントにイメージキャッシュについて記載が追加されたようです。

docs.aws.amazon.com

When Amazon ECS starts a task that runs on Amazon ECS Managed Instances, Amazon ECS pulls the image remotely only if it wasn't pulled by a previous task on the same container instance or if the cached image was removed by the automated image cleanup process. Otherwise, the cached image on the Amazon ECS Managed Instance is used. This ensures that no unnecessary image pulls are attempted.

機械翻訳は以下の通り。

Amazon ECS が Amazon ECS マネージドインスタンス上で実行されるタスクを開始すると、同じコンテナインスタンス上の以前のタスクによってイメージがプルされていない場合、またはキャッシュされたイメージが自動イメージクリーンアッププロセスによって削除されている場合にのみ、Amazon ECS はリモートでイメージをプルします。それ以外の場合は、Amazon ECS マネージドインスタンス上にキャッシュされたイメージが使用されます。これにより、不要なイメージのプルが試行されることがなくなります。

積極的にキャッシュを使うよ、という記載ですね。
ただ、以降の検証結果と併せて考えると、このドキュメントの記載は「Dockerエンジンによるレイヤーキャッシュ利用」も含んだ記載になっているように見えます。

ECSエージェントのイメージPullの振る舞い（ECS_IMAGE_PULL_BEHAVIOR）

ECSエージェントとは

まず前提ですが、ECSはコンテナ化されたアプリケーションを実行するためのサービスです。
自分のPCにDockerをインストールして、docker runをするのと基本的には何も変わりません。
その際、どのコンピューティング環境でコンテナを実行するかで選択肢があります。

1. Fargate
2. EC2インスタンス
3. EC2インスタンス（Managed Instances） ←New!

それぞれについては別記事に譲ります。

これらのコンピューティング環境上でコンテナを起動するためにはイメージを取得してコンテナを起動する主体が必要です。
ローカルマシンであれば人間がdocker image pullやdocker runを実行しますが、ECSにおいてこれを実行する存在がECSエージェントです。
ECSエージェントはコンピューティング環境で起動している常駐プロセスで、APIを通じてAWSサービスやCLIとやり取りします。
ECSエージェントはOSSとして公開されていて仕様を読めます。

github.com

ECSエージェントの振る舞いはコンピューティング環境の環境変数（≠ECSタスクの環境変数）や設定ファイルを通じて操作でき、以下に設定がまとまっています。

github.com

ECSエージェントのイメージPull設定

ECSエージェントにはエージェントがイメージをリポジトリからどのように取得するかを指定するECS_IMAGE_PULL_BEHAVIORという設定があり、以下の説明があります。

The behavior used to customize the container image and digest pull process. If default is specified, the image/digest will be pulled remotely, if the pull fails then the cached image/digest on the instance will be used. If always is specified, the image/digest will be pulled remotely, if the pull fails then the task will fail. If once is specified, the image/digest will be pulled remotely if it has not been pulled before or if the image was removed by image cleanup, otherwise the cached image/digest on the instance will be used. If prefer-cached is specified, the image/digest will be pulled remotely if there is no cached image, otherwise the cached image/digest in the instance will be used.

機械翻訳すると以下のとおりです。

コンテナイメージとダイジェストのプルプロセスをカスタマイズするために使用される動作。default が指定されている場合、イメージ/ダイジェストはリモートでプルされ、プルが失敗した場合はインスタンスにキャッシュされたイメージ/ダイジェストが使用されます。always が指定されている場合、イメージ/ダイジェストはリモートでプルされ、プルが失敗した場合はタスクが失敗します。once が指定されている場合、イメージ/ダイジェストが以前にプルされていない場合、またはイメージがイメージのクリーンアップによって削除された場合は、イメージ/ダイジェストがリモートでプルされます。それ以外の場合は、インスタンスにキャッシュされたイメージ/ダイジェストが使用されます。prefer-cached が指定されている場合、キャッシュされたイメージがない場合はイメージ/ダイジェストがリモートでプルされ、そうでない場合はインスタンスにキャッシュされたイメージ/ダイジェストが使用されます。

つまり

• イメージをPullに行くのかローカルを優先するのか
• イメージのPullに失敗したらどう振る舞うのか
• イメージのキャッシュ有無に対してどう振る舞うのか

を規定する設定値になります。

ECSタスクをEC2インスタンス（含むManaged Instances）で動かす場合、毎回Pullするよりは使いまわしたい…など考える場合に重要なパラメータです。

ECSエージェントのPull設定ごとの振る舞い

実際にソースコードを追い、また実際の挙動を見ながらECS_IMAGE_PULL_BEHAVIOR設定値ごとの振る舞いをシーケンス図で図解します。

default

まずdefaultは以下のような振る舞いになります。

---
title: ECS_IMAGE_PULL_BEHAVIOR=default
---
sequenceDiagram
    box ECSエージェント
    participant TM as タスクマネージャー
    participant TE as タスクエンジン
    participant DB as Pull履歴DB
    end
    
    box Docker
    participant DE as Dockerエンジン
    participant IS as イメージストア
    end
    
    participant ECR as リモートレジストリ

    Note over TM,ECR: イメージPullフェーズ
    TM->>TE: Pull開始
    TE->>DE: PullImage要求
    DE->>ECR: イメージ取得
    
    alt Pull成功
        ECR->>IS: イメージダウンロード
        ECR-->>DE: Pull成功
        DE-->>TE: Pull成功
        TE-->>TM: Pull完了イベント
        Note right of TM: ✅ Pull成功、コンテナ作成フェーズへ
    else Pull失敗
        ECR--xDE: Pull失敗
        DE--xTE: Pull失敗
        TE-->>TM: Pull完了イベント
        Note right of TM: Pull失敗だがコンテナ作成フェーズへ
    end

    Note over TM,ECR: コンテナ作成フェーズ<br>イメージストアにイメージがあれば起動成功✅<br>イメージがなければ起動失敗＝タスクがエラー終了❌

READMEに書いてある内容と同じに見えますが、ポイントはECSエージェントとDockerエンジンを分けている点です。
READMEに書いてある内容をそのまま読み下すと以下のように理解できるかと思います。

default が指定されている場合、イメージ/ダイジェストはリモートでプルされ、プルが失敗した場合はインスタンスにキャッシュされたイメージ/ダイジェストが使用されます。

1. 必ずイメージのPullが行われる
2. 失敗した場合だけキャッシュされたイメージを使う

この説明だと「ECRからのイメージ/レイヤーのダウンロード＝NW経由の転送が毎回発生する」かのように読めるかと思います。私はそう読みました。
しかし、このREADMEの説明はあくまでECSエージェント視点でのみ書かれており、Dockerエンジンを含むユーザーから見える振る舞いそのものを表現してはいません。

Dockerエンジンはどのように振る舞うかと言うと、Pullの実行時にまずマニフェストの取得を試みます。

matsuand.github.io

1 つのマニフェストには、イメージに関するレイヤー、サイズ、ダイジェスト値などの情報を含みます。

ここにおけるダイジェストとはDockerイメージ全体を一意に特定するキーとなる文字列で、latestなどのタグの状況によらずイメージで不変です。
またレイヤーに関する情報としてハッシュ値があり、これはレイヤーを一意に特定するキーです。記憶ではおおよそ「直前のレイヤーのハッシュ＋このレイヤーでのコマンド（COPY .envなどの文字列）を情報源として生成されるハッシュ値」だったと思います。文脈も含めて判断している、ということですね。

Dockerエンジンはマニフェストに含まれるレイヤーのハッシュ値と同じハッシュ値をローカルのイメージストアから検索し、見つかった場合は「Already exists.」メッセージのみ表示して実際のNW転送を行いません。
つまりdefaultにおいては「ECSエージェントは必ずPullを行う」「Dockerエンジンはローカルにイメージ/レイヤーが存在しない分だけNW転送を行う」という振る舞いになるため、コンピューティング環境上にすでにイメージ・レイヤーが存在する場合は実際のNW転送は発生せず、見た目上Pullをせずにローカルイメージを使ったように観察されます。

結果としてdefaultでは以下のように振る舞います。

• ローカルにイメージなし
  • Pull成功→NW転送あり、Pullしたイメージでコンテナ作成✅️
  • Pull失敗→イメージがなくコンテナが起動できないためタスク失敗❌️
• ローカルにイメージあり
  • Pull成功→NW転送はなく、ローカルイメージでコンテナ作成✅️
  • Pull失敗→ローカルイメージでコンテナ作成✅️

結構READMEを読んだだけと印象が違うのではないでしょうか？

always

alwaysは以下のような振る舞いになります。

sequenceDiagram
    box ECSエージェント
    participant TM as タスクマネージャー
    participant TE as タスクエンジン
    participant DB as Pull履歴DB
    end
    
    box Docker
    participant DE as Dockerエンジン
    participant IS as イメージストア
    end
    
    participant ECR as リモートレジストリ

    Note over TM,ECR: イメージPullフェーズ
    TM->>TE: Pull開始
    TE->>DE: PullImage要求（強制）
    DE->>ECR: イメージ取得
    
    alt Pull成功
        ECR->>IS: イメージダウンロード
        ECR-->>DE: Pull成功
        DE-->>TE: Pull成功
        TE-->>TM: Pull完了
        Note right of TM: ✅ Pull成功、コンテナ作成フェーズへ
    else Pull失敗
        ECR--xDE: Pull失敗
        DE--xTE: Pull失敗
        TE-->>TM: Pullエラー
        Note right of TM: ❌ タスク失敗
    end

    Note over TM,ECR: コンテナ作成フェーズ<br>イメージストアにイメージがあれば起動成功✅<br>イメージがなければ起動失敗＝タスクがエラー終了❌

重要なポイントはPullの失敗が必ずタスクの失敗になることです。
always以外では、Pullの失敗は直接的にタスク失敗にはなりません。ローカルにイメージが存在さえすればコンテナが作成できるからです。

結果としてalwaysでは以下のように振る舞います。

• ローカルにイメージなし
  • Pull成功→NW転送あり、Pullしたイメージでコンテナ作成✅️
  • Pull失敗→Pull失敗を理由にタスク失敗❌️
• ローカルにイメージあり
  • Pull成功→NW転送はなく、ローカルイメージでコンテナ作成✅️
  • Pull失敗→Pull失敗を理由にタスク失敗❌️

once

onceは以下のような振る舞いになります。

sequenceDiagram
    box ECSエージェント
    participant TM as タスクマネージャー
    participant TE as タスクエンジン
    participant DB as Pull履歴DB
    end
    
    box Docker
    participant DE as Dockerエンジン
    participant IS as イメージストア
    end
    
    participant ECR as リモートレジストリ

    Note over TM,ECR: イメージPullフェーズ
    TM->>TE: Pull開始
    TE->>DB: 過去のPull成功履歴確認
    
    alt Pull成功済み
        DB-->>TE: Pull成功済み
        TE-->>TM: Pullスキップ
        Note right of TM: ✅ Pull不要、コンテナ作成フェーズへ
    else Pull未実行 or 失敗履歴あり
      DB-->>TE: Pull未実行 or 失敗履歴
      TE->>DE: PullImage要求
      DE->>ECR: イメージ取得
    
      alt Pull成功
          ECR->>IS: イメージダウンロード
          ECR-->>DE: Pull成功
          DE-->>TE: Pull成功
          TE->>DB: Pull成功履歴記録
          TE-->>TM: Pull完了
          Note right of TM: ✅ Pull成功、コンテナ作成フェーズへ
      else Pull失敗
          ECR--xDE: Pull失敗
          DE--xTE: Pull失敗
          TE-->>TM: Pullエラー
          Note right of TM: ❌ タスク失敗
      end
    end

    Note over TM,ECR: コンテナ作成フェーズ<br>イメージストアにイメージがあれば起動成功✅<br>イメージがなければ起動失敗＝タスクがエラー終了❌

onceは少し毛色が違い、「過去にECSエージェント経由でイメージをPullし成功したか」をチェックします。
このチェックにはECSエージェントが持っているDB（ただのテキストファイルかもしれません）を参照します。

そのうえで「Pullが成功した履歴があればPullしない」「Pullが成功した履歴がなければ（実際のローカルイメージの有無によらず）Pullする」ことになります。
とは言え、履歴がなくともローカルイメージがある場合のPullはNW転送を伴わないため、ほぼPullをしないのと同等です。

結果としてonceでは以下のように振る舞います。

• ローカルにイメージなし
  • Pull成功→NW転送あり、Pullしたイメージでコンテナ作成✅️
  • Pull失敗→イメージがなくコンテナが起動できないためタスク失敗❌️
  • Pullしない→イメージがなくコンテナが起動できないためタスク失敗❌️
• ローカルにイメージあり
  • Pull成功→NW転送はなく、ローカルイメージでコンテナ作成✅️
  • Pull失敗→ローカルイメージでコンテナ作成✅️
  • Pullしない→ローカルイメージでコンテナ作成✅️

ここで「Pullしない」と書いたのはECSエージェントによるPull成功の履歴が存在するパターンです。
履歴はローカルのイメージ状態に依存しないため、履歴はあるけどイメージがない…という状態があり得るのでこのように記載しています。

prefer-cached

prefer-cachedは以下のような振る舞いになります。
直訳するとprefer-cachedは「キャッシュされたものを好む」のようです。

sequenceDiagram
    box ECSエージェント
    participant TM as タスクマネージャー
    participant TE as タスクエンジン
    participant DB as Pull履歴DB
    end
    
    box Docker
    participant DE as Dockerエンジン
    participant IS as イメージストア
    end
    
    participant ECR as リモートレジストリ

    Note over TM,ECR: イメージPullフェーズ
    TM->>TE: Pull開始
    TE->>DE: InspectImage（ローカル確認）
    DE->>IS: ローカルイメージ検索
    
    alt ローカルイメージあり
        IS-->>DE: イメージあり
        DE-->>TE: ローカルイメージ存在
        TE-->>TM: Pullスキップ
        Note right of TM: ✅ Pullスキップ、コンテナ作成フェーズへ
    else ローカルイメージなし
        IS--xDE: イメージなし
        DE--xTE: ローカルにイメージなし
        TE->>DE: PullImage要求
        DE->>ECR: イメージ取得
        
        alt Pull成功
            ECR->>IS: イメージダウンロード
            ECR-->>DE: Pull成功
            DE-->>TE: Pull成功
            TE-->>TM: Pull完了
            Note right of TM: ✅ Pull成功、コンテナ作成フェーズへ
        else Pull失敗
            ECR--xDE: Pull失敗
            DE--xTE: Pull失敗
            TE-->>TM: Pull完了
            Note right of TM: Pull失敗だがコンテナ作成フェーズへ
        end
    end

    Note over TM,ECR: コンテナ作成フェーズ<br>イメージストアにイメージがあれば起動成功✅<br>イメージがなければ起動失敗＝タスクがエラー終了❌

ポイントはまずローカルイメージを確認することです。
このローカルイメージは、onceと異なり、どのような方法で手に入れているかを問いません。
ローカルイメージがあればPullしない、ということで、最も省力的な振る舞いでしょう。

結果としてprefer-cachedでは以下のように振る舞います。

• ローカルにイメージなし
  • Pull成功→NW転送あり、Pullしたイメージでコンテナ作成✅️
  • Pull失敗→イメージがなくコンテナが起動できないためタスク失敗❌️
• ローカルにイメージあり
  • Pullしない→ローカルイメージでコンテナ作成✅️

ECS_IMAGE_PULL_BEHAVIORとローカルイメージ状態による振る舞いのまとめ

ユーザー視点でみえる振る舞いをまとめます。

	イメージ無	イメージ有
default	✅️Pullしたイメージで起動 or ❌️Pull失敗でエラー	✅️ローカルイメージで起動
always	✅️Pullしたイメージで起動 or ❌️Pull失敗でエラー	✅️ローカルイメージで起動 or ❌️Pull失敗でエラー
once	✅️Pullしたイメージで起動 or ❌️Pull失敗でエラー or ❌️Pullせずイメージなしでエラー	✅️ローカルイメージで起動
prefer-cached	✅️Pullしたイメージで起動 or ❌️Pull失敗でエラー	✅️ ローカルイメージで起動

これを踏まえて以降では実験によりManaged Instancesの場合のECSエージェントのECS_IMAGE_PULL_BEHAVIOR設定を確認してみます

Managed InstancesにおけるECSエージェント設定を確認

方針

前述の整理をベースにすると、以下の観点で調査することでManaged Instances上のECSエージェントのECS_IMAGE_PULL_BEHAVIOR設定を確認できそうです。

1. イメージが有る状態でPullを失敗させて、タスク実行時にエラーになるか？
   • なる→always
   • ならない→default or once or prefer-cached
2. 一度イメージをPullさせたうえでイメージを削除し、タスク実行時にエラーになるか？
   • なる→once
   • ならない→default or prefer-cached
3. イメージが有る状態でPullを実行させ、リポジトリ向けにマニフェストの取得リクエストが発生するか？
   • 発生する→default
   • 発生しない→prefer-cached

正直に言うと、3つ目は実験するのが困難なのであまり到達したくないです。
Pullの失敗はECRの権限をIAMポリシーから奪うことで実現するつもりなので、リクエストが発生するdefaultは権限チェック＆リジェクトの待ち時間が長い…など微妙な方法で判定ができるかもしれませんが…どうでしょう。

方法

まずはalwaysを特定できるようStep Functionsステートマシンを作ります。
単純に検証するだけだと一発でECS RunTaskで良いかもしれませんが、せっかくなので性能面も確認してみましょう。
ユーザー管理のEC2インスタンスのタスクも加え、比較がわかりやすいようにします。

作ったステートマシンは以下のとおりです。
長いのでGistでどうぞ。

ECS_IMAGE_PULL_BEHAVIOR毎の振る舞いの違いを確認するステートマシン例 · GitHub

Gist内にStep FunctionsのステートマシンのJSONと、ECSタスクで実行するイメージのDockerfileと実行スクリプトも含めています。
ステートマシンの概観は以下のとおりです。

ステートマシン概観

この状態で緑の「三回目のRunTask」でalways設定のステートがPull失敗によりエラーになります。
同じタイミングでManaged Instancesのステートがエラーになれば設定はalways相当とわかります。
RunTaskのレーンは三回とも同一で、左から「Managed Instances」「default」「always」「once」「prefer-cached」です。

実験結果

結果は以下のとおりです。

実行結果。`always`とManaged Instancesがエラー終了した。

この通り、alwaysとManaged Instancesがエラー終了しているため、調査結果はManaged InstancesのECS_IMAGE_PULL_BEHAVIOR設定はalwaysとなりました。

考察

実行時間も含めて考察してみます。

初回のRunTask

まず初回のRunTaskは以下のような処理時間になっています。

一回目のRunTaskのステートの処理時間

テストのためにイメージを重くしてあるのと、RunTask自体も多少時間がかかるよう1分ほどの時間がかかるwaitがある処理にしています。
結果を見ると、Managed Instancesだけ他より40秒ほど処理時間が長く、他のEC2インスタンスのタスクはほぼ同じ処理時間で終了しています。
これはManaged InstancesはEC2インスタンスのプロビジョニング時間が含まれるためです。

• Managed Instancesのステート
  1. 必要なEC2インスタンスのインスタンスタイプなどを決定
  2. EC2インスタンスをプロビジョニング
  3. イメージのPull
  4. RunTask
• 他のステート
  1. イメージのPull
  2. RunTask

この違いにより、40秒ほどでインスタンスをプロビジョニングできていることがわかります。

二回目のRunTask

次に二回目のRunTaskは以下のような処理時間になっています。

二回目のRunTaskのステートの処理時間

結果を見ると、すべてのパターンでステートの実行時間は短くなっており、これはイメージのPullがスキップまたは実質的なNW転送なしになったためと考えられます。
実行しているコマンドがジャスト1分で完了するものであることから、ほぼすべての時間がコマンドの実行時間になっている、という点からもそのように見えます。
ただ、Managed Instancesは20秒ほど他のステートよりも処理時間が長いです。
インスタンスは入れ替わっていませんでしたが、Managed Instances特有の何らかのチェック処理が走っているかもしれません。

三回目のRunTask

最後に三回目のRunTaskは以下のような処理時間でした。

三回目のRunTaskのステートの処理時間

結果を見ると、Managed Instancesとalwaysはどちらも20秒程度でステートが失敗しています。
これはECRの権限を奪ったことでイメージPullができなかったためであり、権限を奪った場合にエラーと判断するのは20秒ほど時間がかかるのでしょう。
傍証として、defaultもonceやprefer-cachedに比べて20秒ほど処理時間が長く、最初にPullを試行しているためECRの権限エラー分処理時間が長くなっていると考えると整合します。
onceとprefer-cachedはイメージのPull自体行わないため、ほぼすべての時間がコマンドの実行時間になっています。

ほか

実は最初期にはFargateもレーンに加えたステートマシンになっていました。
が、Fargateは当然毎回プロビジョニングとイメージPullを行うのでステートの処理時間が長くなり、結果としてManaged InstancesのEC2インスタンスが終了してしまいました。
Managed InstancesのRunTask完了からおおよそ3分程度でインスタンスが終了したため、インスタンス上のイメージの使い回しを意識するならインスタンスの自動終了を考慮に含めておく必要がありそうです。

考察まとめ

• Managed InstancesはECRからのPullに失敗するとタスクがエラー終了するのでECS_IMAGE_PULL_BEHAVIOR = alwaysとなっている
• ECS_IMAGE_PULL_BEHAVIORによる振る舞いの違いはDockerエンジンも含めて考えると机上検討の通りになる
• Managed Instancesは自動でEC2インスタンスが終了するのでイメージのキャッシュ効率を考えるのであれば考慮に入れる必要がある

まとめ

Amazon ECSのManaged Instancesについて、ECSエージェントの設定、特にECS_IMAGE_PULL_BEHAVIORで設定されるイメージPullの振る舞いについて実験しました。
この結果、Managed InstancesではECS_IMAGE_PULL_BEHAVIOR = alwaysが設定されていることが確認できました。
同時にECSエージェントのREADMEを読むだけでは分かりにくい、ユーザーから見たキャッシュ利用の振る舞いについても整理し、理解しやすい形にしてみました。
みなさんがECSタスクのインフラ選定やECSエージェントの設定を決定する際のインプットとして活用いただければ嬉しいです。