ECS・EKSコスト最適化入門｜Fargate Spot・Karpenter・Graviton3でコンテナ料金を最大70%削減する実践ガイド

コンテナ化したアプリをECSやEKSに乗せたものの、月末の請求書を見て「こんなに高いはずじゃなかった」と感じたことはないだろうか。

コンテナはオンプレのVMと違い、EC2ノードの料金だけでなく、Fargate、ネットワーク転送、ECRのストレージなど、複数の費用が絡み合う。「とりあえずFargateで動かした」「EC2をオンデマンドで用意した」という構成のままだと、最大で本来の3倍近いコストがかかっていることもある。

この記事では、ECS・EKSのコスト最適化を体系的に解説する。Fargate SpotによるFargate料金の70%削減、KarpenterによるEC2ノードの動的最適化、Graviton3プロセッサへの移行、そしてリソース適正化の実務的な手順を紹介する。

なぜコンテナのコスト管理は難しいのか

オンプレのVMware環境では、vCPUとメモリの割り当てを一度決めたら基本的に固定だった。クラウドのコンテナ環境は動的にスケールする分、コスト要因が増える。

ECSやEKSにかかるコストは大きく5つに分解できる。

・コンピュート費用: EC2インスタンス（ノード）またはFargate vCPU/GB時間の料金
・コントロールプレーン費用: EKSの場合はクラスター1つあたり$0.10/時間（ECSはコントロールプレーン無料）
・ストレージ費用: ECRのコンテナイメージ保管料金（$0.10/GB/月、2026年執筆時点）
・ネットワーク費用: AZをまたぐ通信料金（片道$0.01/GB）、ロードバランサー料金
・その他: CloudWatch Logs、X-Ray、App Mesh等の付随サービス

このうち最も大きいのはコンピュート費用で、全体の60～80%を占めることが多い。ここを最適化するのが最もインパクトが大きい。

FargateとEC2ノードグループ：どちらが安いか

「FargateはEC2より高い」という印象を持つエンジニアは多い。実際のところはワークロードによって変わる。

1. Fargate料金の仕組み

Fargateは「使った分だけ」の課金で、vCPUと実行時間・メモリと実行時間で計算される（2026年3月時点・東京リージョン）。

# Fargate料金（東京リージョン・2026年3月時点）
vCPU時間:   $0.05056/vCPU時間
メモリ時間: $0.00553/GB時間

# 計算例: 0.5vCPU / 1GB / 24時間/日 / 30日
vCPU料金:   0.5 × $0.05056 × 24 × 30 = $18.20
メモリ料金: 1 × $0.00553 × 24 × 30   = $3.98
月額合計:   約$22.18

2. EC2ノードグループとの比較

EC2ノードを使う場合は、コンテナが何個乗っていようと同じインスタンス費用を払う。EC2ノードの使用率が高いほど、1コンテナあたりのコストは下がる。

逆に言えば、EC2ノードが常時30%以下の使用率しかないなら、Fargateのほうが安くなることが多い。

3. 使い分けの実務基準

現場での判断基準はシンプルだ。

・常時稼働・高負荷なサービス: EC2ノード + Reserved Instance or Savings Plansが有利
・負荷変動が大きい・バッチ処理: Fargate or Fargate Spot
・開発・ステージング環境: Fargateで管理工数を省く
・スパイク的なワークロード: Fargate Spotが最も安い

Fargate Spotでコストを最大70%削減する

Fargate Spotは、AWSの余剰Fargateキャパシティを使う購入オプションで、オンデマンド比で最大70%安くなる。EC2スポットインスタンスと同様の仕組みだが、EC2インスタンスを直接管理しなくてよい点が大きなメリットだ。

1. Fargate Spotが向くワークロード

・バッチ処理・データ変換: 途中で中断されても再実行できるもの
・CI/CDのテスト実行: ビルドやテストのコンテナ
・機械学習の前処理: チェックポイントを持つトレーニング
・キューから読み込む非同期処理: SQSトリガーのワーカー

逆に「2分以内に中断の通知が来て、タスクが強制終了しても問題ない」という要件を満たせないサービスには向かない。

2. ECSでFargate Spotを設定する手順

ECSサービスでキャパシティプロバイダー戦略を設定することで、FargateとFargate Spotを組み合わせられる。

# AWS CLIでキャパシティプロバイダー戦略を設定する例
# ECSサービス更新（Fargate:Fargate_SPOT = 1:3の比率）
aws ecs update-service \
  --cluster my-cluster \
  --service my-service \
  --capacity-provider-strategy \
    capacityProvider=FARGATE,weight=1,base=1 \
    capacityProvider=FARGATE_SPOT,weight=3

base=1 を設定することで、最低1タスクは確実にFargate（オンデマンド）で動き、残りはFargate Spotで動く。本番サービスにFargate Spotを使う場合は、最低限の安定タスクをFargate側で確保するのが鉄則だ。

3. 実際のコスト削減効果

月100時間のバッチタスク（0.5vCPU / 2GB）をFargate Spotに切り替えた場合の試算（2026年3月時点）。

本番サービスにFargate Spotを組み込む場合はECSサービスのデプロイメント設定でヘルスチェック猶予期間（healthCheckGracePeriodSeconds）を長めに取ること。スポットの中断時にタスクが素早く別キャパシティへ再スケジュールされるので、ヘルスチェックのタイムアウトが短すぎると不必要に失敗判定される。

EKSのEC2ノードコスト最適化：Karpenterの活用

EKSでEC2ノードを使う場合、Cluster AutoscalerよりもKarpenterのほうがコスト効率が高い場面が多い。

1. Cluster AutoscalerとKarpenterの違い

Cluster Autoscalerは「ノードグループ」の単位でスケールするため、あらかじめインスタンスタイプを固定する必要がある。一方、Karpenterはポッドのリソース要求を見て、最も安いインスタンスタイプを動的に選択して起動する。

2. KarpenterのNodePool設定例

# Karpenter NodePool 設定例（YAML）
# Spot + On-demandを混在させてコスト最適化
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
        - key: "kubernetes.io/arch"
          operator: In
          values: ["arm64"]         # Graviton3を優先
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["c7g", "m7g", "r7g"]   # Graviton3系
      nodeClassRef:
        apiVersion: karpenter.k8s.aws/v1
        kind: EC2NodeClass
        name: default
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m

consolidationPolicy: WhenEmptyOrUnderutilized を設定することで、使用率の低いノードを自動的に削除し、ポッドを空きスペースのあるノードへ移動させる。これにより「半分しか使っていないノードが2台あるのに、1台にまとめれば足りる」という無駄を自動で解消できる。

3. スポットインスタンスをEKSで安全に使う

EKSでスポットを使う際は、複数のインスタンスタイプをサポートすることが安定性のカギだ。

・複数AZにノードを分散: 特定AZのスポット枯渇に備える
・Instance Diversification: m5/m5a/m6i/m6aなど複数ファミリーを許可する
・Pod Disruption Budget設定: スポット中断時に一度に落ちるポッド数を制限
・Spot Interruption Handler: aws-node-termination-handlerを導入して中断通知を受け取る

スポットインスタンスについての詳細はAWSスポットインスタンス入門を参照してほしい。

Graviton3でコンテナ料金をさらに削減

AWSのGraviton3（ARM64アーキテクチャ）プロセッサを使うEC2インスタンスは、x86と同等またはそれ以上のパフォーマンスを持ちながら、料金は約20%安い。コンテナワークロードとの相性が特に良い。

1. Graviton3対応インスタンスファミリー

・c7g: CPU集約型ワークロード（APIサーバー、バッチ処理）
・m7g: 汎用（WebサービスのECSノード全般）
・r7g: メモリ集約型（キャッシュ・インメモリDB連携）
・t4g: バースト可能（開発環境・低負荷サービス）

2. コンテナイメージのマルチアーキテクチャ対応

Graviton3（ARM64）で動かすにはコンテナイメージをARM64向けにビルドする必要がある。マルチアーキテクチャイメージを使えば、ARM64とx86_64の両方で同じイメージタグを使える。

# Docker BuildxでマルチアーキテクチャイメージをビルドしてECRにプッシュ
docker buildx create --use

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  --tag 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest \
  --push \
  .

既存のDockerfileのほとんどは修正不要だ。ただし、バイナリを直接ダウンロードするステップがある場合は、$TARGETARCH変数を使って分岐する必要がある。

Graviton移行の詳細な手順についてはAWS Graviton移行入門で詳しく解説している。

コンテナリソースの適正化（Right-sizing）

コンテナコスト最適化の中で最も見落とされがちなのが、CPU・メモリの「過剰割り当て」だ。

「本番で落ちては困る」という心理から余裕を持ってリソースを設定しがちだが、requestsを大きくするほどノードに乗せられるポッド数が減り、コンテナあたりのコストが上がる。

1. Requests/Limitsの設計原則

# EKS Pod のリソース設定例
resources:
  requests:
    cpu: "250m"      # 実際の平均使用量の110～120%が目安
    memory: "256Mi"  # P95使用量を基準にする
  limits:
    cpu: "500m"      # バースト上限（requestsの2倍以内が一般的）
    memory: "512Mi"  # OOMKill防止のためメモリはtighterに

2. Vertical Pod Autoscaler（VPA）でRight-sizing

KubernetesのVPAを使うと、実際のリソース使用量を観察して適切なrequests値を自動推奨してくれる。まずは推奨モード（updateMode: "Off"）で動かし、提案値を確認してから実際に適用するのが安全だ。

# VPA 設定（推奨モード：自動変更なし、値の確認のみ）
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Off"   # "Auto"にすると自動適用

# 推奨値の確認
kubectl describe vpa my-app-vpa
# "Recommendation" セクションにcpu/memoryの推奨値が表示される

3. ECSタスク定義のRight-sizing

ECSの場合はAWS Compute Optimizerがタスク定義のCPU・メモリ割り当ての推奨値を出してくれる。AWS Cost Optimization Hubでも「過剰プロビジョニングされたECSサービス」の推奨が表示されるので、定期的に確認する習慣をつけたい。

ECSのコンテナは、タスク定義で指定したcpuとmemoryの全量に課金されるため、過剰割り当てはFargate環境では直接コストに跳ね返る。

EKSコントロールプレーン料金の見落とし

EKSでよく見落とされるのがコントロールプレーン料金だ。クラスター1つにつき$0.10/時間（約$73/月）が固定でかかる。

複数の小さなクラスターを持っている環境では、クラスターを統合するだけで大幅にコストを下げられることがある。

・Namespaceで分離できるなら統合する: 開発・ステージング・本番が別クラスターになっている場合、開発とステージングを1クラスターにまとめるだけで$73/月節約できる
・クラスター数を最小化する: セキュリティ要件やコンプライアンス上の分離が必要ない環境では、NamespaceとNetworkPolicyで分離する
・一時クラスターを使い捨てにしない: CI/CDのテスト用クラスターを「作りっぱなし」にすると月数百ドルの無駄になる

よくある落とし穴と対処法

【落とし穴1】AZ間通信料金の無視

ECSサービスやEKSポッドが異なるAZのデータベースやキャッシュと通信すると、AZをまたぐ通信料金（$0.01/GB双方向）が発生する。

・ECSサービス: タスク配置制約でAZを揃える（attribute:ecs.availability-zone == ap-northeast-1a）
・EKS: トポロジー分散制約（topologySpreadConstraints）でAZ内コロケーションを優先
・RDSやElastiCache: マルチAZ構成でもアプリと同じAZのエンドポイントに接続するよう設計する

【落とし穴2】ログの過剰出力

コンテナのログをそのままCloudWatch Logsに流すと、ログ量に比例してデータ取込料金（$0.76/GB、東京リージョン・2026年執筆時点）がかかる。デバッグレベルのログを本番環境でも垂れ流しにしていると、月数万円の余分なコストになることもある。

本番環境のログレベルはINFO以上に絞り、デバッグログはサンプリング（100リクエストに1つなど）にすることで大幅に削減できる。

【落とし穴3】ECRプルがNAT Gateway経由になっている

ECRからコンテナイメージをプルするとき、VPCエンドポイント（ECR用）を設定していないとNAT Gatewayを経由してしまい料金が発生する。EKSノードやECSタスクが同じリージョンのECRからプルする場合、VPCエンドポイントを設定すればNAT Gateway経由のデータ転送料をゼロにできる。

必要なVPCエンドポイントは以下の3つだ。

・com.amazonaws.ap-northeast-1.ecr.api
・com.amazonaws.ap-northeast-1.ecr.dkr
・com.amazonaws.ap-northeast-1.s3（ECRのレイヤーデータはS3に保存されるため）

コスト最適化のチェックリスト

本記事のまとめ

ECSとEKSのコスト最適化ポイントを整理すると：

・Fargate Spot: バッチや非同期処理をFargate Spotに移すだけで最大70%削減。設定コストが低い割に効果が大きい
・Graviton3: コンテナイメージをマルチアーキテクチャ対応にするだけで約20%削減。ECSでもEKSでも適用可能
・Karpenter: EKSでEC2ノードを使うならKarpenterのConsolidation機能でノード数を常に最小化
・Right-sizing: CPU/メモリのrequests設定を実測値ベースで見直す。VPAやCompute Optimizerを活用
・隠れコスト: AZ間通信、ECRプルのNAT経由、EKSクラスターのコントロールプレーン料金を見落としがち

まずFargate Spotへの切り替えとGraviton3移行を組み合わせるだけで、コンテナコストの30～40%削減は現実的に達成できる。コンテナ環境の構成設計についてはAmazon ECS入門やAmazon EKS入門も合わせて読んでほしい。