PR

AWS ECS/Fargateコスト最適化完全ガイド：月14万円の無駄を削った実践手法【2026年】

2025.07.14

AWS ECS/Fargateコスト最適化完全ガイド：月14万円の無駄を削った実践手法【2026年】

はじめに

ECS/Fargateで動かしているサービスのAWS請求書を見て「なんでこんなに高い？」と思った経験がある。

去年引き継いだシステムのタスク定義がcpu: 1vCPU, memory: 4GBで固定されていて、Container Insightsで確認したら実際のCPU使用率は平均8%、メモリは12%だった。月のFargateコストが28万円で、適切にサイジングしたら14万円台まで落とせた。設定を変えるだけで毎月14万円以上の削減になった。

この記事では、そういう「設定のまずさでお金が垂れ流されている」状態をどう見つけて直すか、2026年時点の実践手法をまとめる。

ECS vs Fargate の選択基準を整理する

まず前提を整理する。ECSはコンテナのオーケストレーションサービス。その「コンピュートエンジン」としてEC2を使うかFargateを使うかを選ぶ。

EC2起動タイプ Fargate
サーバー管理 自分でEC2を管理 AWSに任せる
コスト 大量・常時稼働なら安い 小〜中規模、スパイク有なら有利
起動速度 速い EC2より若干遅い（30〜90秒）
Spot活用 EC2 Spot Fargate Spot（最大70%オフ）

リクエストが1日中安定的に来るシステムで月数十台必要なら EC2の方が安い。スパイクがあったり台数が少なかったりするなら Fargate の方がシンプルでコスト効率が良い。

コスト最大の要因：タスクサイジングのミス

現状確認：Container Insightsで実態を把握する

まず Container Insights を有効化して実際のリソース使用率を計測する。

# Container Insightsを有効化
aws ecs update-cluster-settings \
  --cluster my-cluster \
  --settings name=containerInsights,value=enabled \
  --region ap-northeast-1

有効化後、CloudWatch Metrics のECS/ContainerInsights名前空間でCpuUtilizedとMemoryUtilizedが取得できる。

CloudWatch Insights でサービスごとの平均使用率を確認：

# CloudWatch Logs Insights（Container Insightsのパフォーマンスログ）
fields @timestamp, TaskId, CpuUtilized, MemoryUtilized, CpuReserved, MemoryReserved
| filter Type = "Task"
| stats 
    avg(CpuUtilized) as avg_cpu_utilized,
    max(CpuUtilized) as max_cpu_utilized,
    avg(MemoryUtilized) as avg_mem_utilized,
    max(MemoryUtilized) as max_mem_utilized,
    avg(CpuReserved) as cpu_reserved,
    avg(MemoryReserved) as mem_reserved
  by ServiceName
| sort avg_cpu_utilized desc

avg_cpu_utilizedがcpu_reservedの20%以下なら確実にオーバープロビジョニング。

適切なサイジングの目安

Fargateのタスクサイズは以下の組み合わせから選ぶ（2026年時点）：

CPU メモリ選択肢
256 (.25 vCPU) 512MB〜2GB
512 (.5 vCPU) 1GB〜4GB
1024 (1 vCPU) 2GB〜8GB
2048 (2 vCPU) 4GB〜16GB
4096 (4 vCPU) 8GB〜30GB

サイジングの目安：
– ピーク時CPU使用率が目標の70〜80%になるよう設定
– メモリは実際の最大使用量 × 1.3倍（OOMキラー対策）

引き継いだシステムは1vCPU/4GBで平均CPU 8%。適切なサイジングは256 CPU/512MBだった。コスト差は単純計算で75%削減。

タスク定義の更新方法

# 現在のタスク定義を取得
aws ecs describe-task-definition \
  --task-definition my-app:12 \
  --query 'taskDefinition' > task-def.json
# cpu/memoryを変更
# task-def.json の "cpu": "1024" → "256"、"memory": "4096" → "512" に変更
# 不要なフィールド（taskDefinitionArn, revision, status 等）を削除
# 新しいリビジョンとして登録
aws ecs register-task-definition --cli-input-json file://task-def.json
# サービスを更新
aws ecs update-service \
  --cluster my-cluster \
  --service my-service \
  --task-definition my-app \
  --force-new-deployment

Fargate Spotで最大70%のコスト削減

Fargate Spotとは

Fargate Spotは余剰AWSコンピュートキャパシティを使う仕組みで、通常Fargateより最大70%安い。ただし2分前通知で中断される可能性がある。

適用向き：
– バッチ処理、データ変換
– 開発・ステージング環境
– 中断しても問題ないワークロード

適用不向き：
– リアルタイムAPIサーバー（単独では使わない）
– ステートフルな処理

Spot + Ondemandの混在戦略

本番のAPIサーバーで使う場合は、Ondemand最低2タスクを保証しつつ、残りをSpotで調達するキャパシティプロバイダー戦略が定石。

{
  "capacityProviderStrategy": [
    {
      "capacityProvider": "FARGATE",
      "weight": 1,
      "base": 2
    },
    {
      "capacityProvider": "FARGATE_SPOT",
      "weight": 4,
      "base": 0
    }
  ]
}

base: 2で最低2タスクはOndemandで確保。追加スケールアウトはSpotが優先（weight 4:1）。自分がWebAPIシステムに適用したとき、月のFargateコストが約35%削減された。

# サービスをキャパシティプロバイダー戦略で更新
aws ecs update-service \
  --cluster my-cluster \
  --service my-service \
  --capacity-provider-strategy \
    capacityProvider=FARGATE,weight=1,base=2 \
    capacityProvider=FARGATE_SPOT,weight=4,base=0

オートスケーリングの正しい設定

ターゲット追跡スケーリングが基本

ECS Application Auto Scalingのターゲット追跡は、CPU使用率を指定のパーセンテージに保つよう自動でスケールする。

# スケーラブルターゲットの登録
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 \
  --max-capacity 20
# CPU使用率70%を目標にスケーリング
aws application-autoscaling put-scaling-policy \
  --policy-name cpu-tracking \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "ScaleInCooldown": 300,
    "ScaleOutCooldown": 60
  }'

ScaleOutCooldownを短く（60秒）、ScaleInCooldownを長く（300秒）設定するのがポイント。スケールアウトは素早く、スケールインは慎重に。

夜間・週末の自動スケールダウン

開発・ステージング環境なら業務時間外にタスク数を最小化するだけでコストを40〜50%削減できる。

# 平日の業務時間（9:00 JST）にスケールアウト
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/dev-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name scale-out-morning \
  --schedule "cron(0 0 ? * MON-FRI *)" \
  --scalable-target-action MinCapacity=2,MaxCapacity=10
# 平日の業務後（20:00 JST）にスケールダウン
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/dev-cluster/my-service \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name scale-down-evening \
  --schedule "cron(0 11 ? * MON-FRI *)" \
  --scalable-target-action MinCapacity=0,MaxCapacity=0

ステージング環境でこれを設定したら月のコストが$320→$140になった。

Haruの実体験：引き継ぎシステムでコスト調査した話

去年、Fargateで動く中規模SaaSのインフラ引き継ぎをした。前任者がEC2時代の感覚でタスクを定義していたらしく、全サービスが1vCPU/4GB固定だった。

Container Insightsで計測すると：
– APIサーバー（10タスク）：CPU平均8%、メモリ平均15%
– バッチ処理（3タスク）：CPU平均60%、メモリ平均70%
– 管理画面（2タスク）：CPU平均3%、メモリ平均8%

APIと管理画面のサイジングを変更し、バッチをFargate Spotに移行し、ステージング環境に夜間スケールダウンを設定した。

結果：
– 変更前：月28.4万円
– 変更後：月13.8万円（51%削減）

実作業時間は調査含めて丸1日（8時間）。コスパが良すぎる最適化作業だった。

ECRイメージの整理もコストに効く

Fargateのコストだけ見ていると見落としがちだが、ECRのストレージコストも積み重なる。不要なイメージを定期削除するライフサイクルポリシーを設定する。

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "productionタグ付きは保持",
      "selection": {
        "tagStatus": "tagged",
        "tagPrefixList": ["prod-"],
        "countType": "imageCountMoreThan",
        "countNumber": 5
      },
      "action": {
        "type": "expire"
      }
    },
    {
      "rulePriority": 2,
      "description": "未タグのイメージは7日で削除",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 7
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

次のステップ

ECS/Fargateのコスト最適化の次は、コンテナの基礎固めとセキュリティ強化に進むのが自然な流れ：

まとめ

ECS/Fargateのコスト最適化で優先度が高いのは以下の順番：

  1. Container Insightsで実際の使用率を計測（無計測の最適化は意味がない）
  2. タスクサイジングの見直し（大抵ここで30〜50%削減できる）
  3. Fargate Spotの活用（バッチ・開発環境から始めると安全）
  4. オートスケーリングとスケジュール設定（夜間ゼロ化が強力）

「設定を変えるだけで毎月数万円削減」という最適化は、エンジニアリングの中でも費用対効果が最も高い仕事のひとつ。まず自分のClusterのContainer Insightsを見るところから始めてほしい。

参考リンク

コメント

タイトルとURLをコピーしました