直近、業務でECSへのデプロイワークフローを実装することになりました。

主な流れは以下の通りです。

1. フロントエンドのビルド
2. Docker Image のビルド
3. ECR へのログイン
4. ECR へPush
5. ECS のサービス更新

この中でボトルネックになるのが 「2. Docker Image のビルド」 です。

毎回フルビルドしていると時間がかかりすぎるため、キャッシュの利用は必須です。

Docker Buildx のキャッシュバックエンドには、大きく分けて以下の3つの選択肢があります。

1. GitHub Actions Cache (type=gha)
2. GitHub Container Registry (type=registry)
3. Amazon ECR (type=registry)

これらを比較検討した結果、今回は 「GitHub Actions Cache (type=gha)」 を採用しました。

その理由はズバリ、「利用料（ランニングコスト）」と「実装（設定）コスト」が最も低かったからです。

比較検討：3つのキャッシュ戦略

それぞれの特徴を「コスト」と「手間」の観点で整理しました。

1. Amazon ECR (type=registry)

AWS環境に統一できるメリットはありますが、以下のデメリットがあります。

• 実装コスト
  IAMロールの設定、aws-actions/amazon-ecr-login の設定が必要。
• 利用料
  • データ転送量
    GitHub Actions (インターネット) ⇔ AWS ECR 間の通信が発生します。
    NAT Gatewayを経由する場合などは特に通信費がかさむ可能性があります。
  • ストレージ料金
    キャッシュイメージの分だけECRのストレージ料金が発生します。
  • 実行時間
    ネットワーク越しにPush/Pullするため、ビルド時間が伸び＝GitHub Actionsの課金対象時間（Minutes）も消費します。

2. GitHub Container Registry (type=registry)

GitHubのエコシステム内で完結しますが、こちらも考慮が必要です。

• 実装コスト
  docker/login-action での認証設定や、パッケージの読み書き権限設定が必要。
• 利用料
  • Organizationのプランによっては、GHCRのストレージ容量やデータ転送量に制限・課金が発生する場合があるらしい

3. GitHub Actions Cache (type=gha)

今回採用した方法です。

• 実装コスト
  認証設定が一切不要。YAMLに数行書くだけ。
• 利用料
  • 通信費ゼロ
    GitHub Actionsの内部ネットワークで完結するため、外部への転送コストがかかりません。
  • ストレージ無料
    リポジトリあたり10GBまで利用可能（超過分は古いものから自動削除されるだけなので、追加課金のリスクがない）。
  • 実行時間短縮
    ネットワークが高速なため、キャッシュのリストアが速く、結果としてActionsの実行時間を節約できます。

比較まとめ表

なぜ type=gha を選んだか

今回の要件において、私が重視したのは以下の2点です。

1. ワークフローの利用料を抑えたい
   • 無駄なデータ転送費やストレージ料金を払いたくない。
   • ビルド時間を短縮して、GitHub Actionsの利用枠（Minutes）を節約したい。
2. 実装コストを最小限にしたい
   • キャッシュのためだけにIAM権限を調整したり、Secretsを管理したりする手間を省きたい。
   • シンプルに保ち、メンテナンスしやすくしたい。

この2点を満たすのが type=gha でした。

「ローカル開発環境でも同じキャッシュを使いたい」という要件があれば registry 系が候補に挙がりますが、今回は「CIの高速化」が主目的だったため、迷わずこちらを選択しました。

実装コード

設定は驚くほどシンプルです。docker/build-push-action に cache-from / cache-to を追加するだけです。

      # Buildxのセットアップ（必須）
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      # ビルド & Push
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.login-ecr.outputs.registry }}/my-app:latest
          # ★ここがポイント
          cache-from: type=gha
          cache-to: type=gha,mode=max

ポイント：mode=max

cache-to: type=gha,mode=max を指定することで、最終的なイメージだけでなく、中間レイヤー（npm install などを行ったレイヤー）もキャッシュされます。
これにより、コードを少し変更しただけでもフルビルドが走るのを防げます。

まとめ

技術選定において「高機能であること」も重要ですが、「コストがかからない」「設定が楽」 というのは、運用を続ける上で正義です。

ECSデプロイのビルド時間に悩んでいる方は、まずは一番手軽で財布に優しい type=gha から試してみてはいかがでしょうか。