AWSコンテナサービスの全体像と選択ポイント

はじめに

Dockerでコンテナの基礎を学んだ後、次のステップとしてAWSでのコンテナ運用を検討する方は多いでしょう。しかし、AWSには複数のコンテナ関連サービスが存在し、「どれを選べばよいのか」と迷うことは珍しくありません。

本記事では、AWSの主要なコンテナサービスであるECS、ECR、Fargate、App Runnerの特徴と役割を整理し、ユースケースに応じた選択基準を解説します。この記事を読むことで、以下のことが理解できるようになります。

AWSコンテナサービス全体の構成と各サービスの役割
ECS、Fargate、App Runnerの違いと使い分け
プロジェクト要件に応じた最適なサービスの選び方

AWSコンテナサービスの全体像

AWSのコンテナサービスは、大きく「レジストリ」「オーケストレーション」「コンピューティング」の3つのレイヤーに分類できます。それぞれのレイヤーが連携することで、コンテナアプリケーションのビルドからデプロイ、運用までを一貫してサポートします。

flowchart TB
    subgraph Registry["レジストリ層"]
        ECR["Amazon ECR<br/>コンテナイメージの保存・管理"]
    end
    
    subgraph Orchestration["オーケストレーション層"]
        ECS["Amazon ECS<br/>コンテナオーケストレーション"]
        EKS["Amazon EKS<br/>Kubernetes マネージド"]
    end
    
    subgraph Compute["コンピューティング層"]
        EC2["Amazon EC2<br/>仮想サーバー"]
        Fargate["AWS Fargate<br/>サーバーレスコンテナ"]
    end
    
    subgraph Simplified["簡易デプロイ"]
        AppRunner["AWS App Runner<br/>フルマネージドWebアプリ"]
    end
    
    ECR --> ECS
    ECR --> EKS
    ECR --> AppRunner
    
    ECS --> EC2
    ECS --> Fargate
    EKS --> EC2
    EKS --> Fargate

各レイヤーの役割

レイヤー	サービス	主な役割
レジストリ	Amazon ECR	コンテナイメージの保存・共有・脆弱性スキャン
オーケストレーション	Amazon ECS	コンテナの起動・停止・スケーリングの管理
オーケストレーション	Amazon EKS	Kubernetesクラスターのマネージドサービス
コンピューティング	AWS Fargate	サーバーレスでコンテナを実行
コンピューティング	Amazon EC2	仮想サーバー上でコンテナを実行
簡易デプロイ	AWS App Runner	ソースコードから直接デプロイ可能なフルマネージドサービス

Amazon ECR（Elastic Container Registry）

Amazon ECRは、AWSが提供するフルマネージドなコンテナレジストリサービスです。Docker Hubのようなパブリックレジストリとは異なり、プライベートなイメージ管理が可能で、AWS環境との統合がシームレスに行えます。

ECRの主な機能

ECRは単なるイメージ保存場所ではなく、エンタープライズ向けの機能を備えています。

イメージスキャン機能

ECRには、コンテナイメージの脆弱性を自動検出する機能が組み込まれています。プッシュ時またはオンデマンドでスキャンを実行でき、CVE（Common Vulnerabilities and Exposures）に基づいた脆弱性レポートを確認できます。

ライフサイクルポリシー

古いイメージを自動削除するルールを設定できます。例えば、「タグなしイメージは7日後に削除」「最新10個以外のイメージは削除」といったポリシーを定義することで、ストレージコストを最適化できます。

クロスリージョンレプリケーション

イメージを複数のAWSリージョンに自動的に複製できます。これにより、マルチリージョンでのデプロイや災害復旧（DR）対策が容易になります。

ECRの料金体系

ECRの料金は、ストレージ使用量とデータ転送量に基づいて計算されます。

項目	料金（東京リージョン）
ストレージ	0.10 USD/GB/月
データ転送（同一リージョン内）	無料
データ転送（リージョン外）	標準のデータ転送料金
無料利用枠	500 MB/月（プライベートリポジトリ、12か月間）

ECRの基本的な使い方

ECRへのイメージプッシュは、以下の手順で行います。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# ECRへのログイン
aws ecr get-login-password --region ap-northeast-1 | \
  docker login --username AWS --password-stdin \
  123456789012.dkr.ecr.ap-northeast-1.amazonaws.com

# イメージのタグ付け
docker tag my-app:latest \
  123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest

# イメージのプッシュ
docker push \
  123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest

Amazon ECS（Elastic Container Service）

Amazon ECSは、AWSネイティブのコンテナオーケストレーションサービスです。Kubernetesを使用しないシンプルなアプローチで、コンテナのデプロイ、スケーリング、管理を行えます。

ECSの主要コンポーネント

ECSを理解するには、以下の4つのコンポーネントを把握することが重要です。

flowchart TB
    subgraph ECSComponents["ECS コンポーネント"]
        Cluster["クラスター<br/>コンテナ実行環境のグループ"]
        Service["サービス<br/>タスクの起動数と配置を管理"]
        Task["タスク<br/>実行中のコンテナインスタンス"]
        TaskDef["タスク定義<br/>コンテナの設計図"]
    end
    
    Cluster --> Service
    Service --> Task
    TaskDef -.-> Task

クラスター（Cluster）

コンテナを実行するための論理的なグループです。クラスター内でタスクやサービスが動作します。開発環境用、本番環境用といった形で分離することが一般的です。

タスク定義（Task Definition）

コンテナの設計図となるJSON形式の設定ファイルです。使用するイメージ、CPU・メモリの割り当て、環境変数、ポートマッピングなどを定義します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


{
  "family": "my-web-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest",
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ],
      "essential": true,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-web-app",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

タスク（Task）

タスク定義に基づいて起動された実行中のコンテナインスタンスです。1つのタスクには複数のコンテナを含めることができます。

サービス（Service）

指定した数のタスクを常に維持し、負荷分散や自動復旧を管理します。「常に3つのタスクを実行」といった設定が可能です。

ECSの料金体系

ECSそのものには追加料金は発生しません。料金は、コンテナを実行するコンピューティングリソース（EC2またはFargate）に対して課金されます。

起動タイプ	料金体系
EC2起動タイプ	EC2インスタンスの料金のみ
Fargate起動タイプ	vCPU・メモリの使用量に基づく従量課金

AWS Fargate

AWS Fargateは、サーバーレスでコンテナを実行するためのコンピューティングエンジンです。ECSまたはEKSと組み合わせて使用し、EC2インスタンスの管理なしにコンテナをデプロイできます。

Fargateの特徴

Fargateを選択する最大のメリットは、インフラストラクチャ管理からの解放です。

サーバー管理が不要

EC2インスタンスのプロビジョニング、パッチ適用、スケーリングといった作業が不要になります。コンテナの実行に必要なリソースはAWSが自動的に管理します。

セキュリティの向上

各タスクは独自のカーネルで実行されるため、ワークロード間の分離が強化されます。これにより、マルチテナント環境でのセキュリティリスクが軽減されます。

細かなリソース指定

vCPUとメモリを細かく指定でき、無駄なリソースを排除できます。0.25 vCPU / 0.5 GBから16 vCPU / 120 GBまで幅広い構成をサポートしています。

Fargateのリソース設定

Fargateでは、タスクに割り当てるvCPUとメモリの組み合わせがあらかじめ決められています。

vCPU	メモリ（GB）
0.25	0.5、1、2
0.5	1〜4（1GB単位）
1	2〜8（1GB単位）
2	4〜16（1GB単位）
4	8〜30（1GB単位）
8	16〜60（4GB単位）
16	32〜120（8GB単位）

Fargateの料金体系

Fargateは、使用したvCPU・メモリ・ストレージに対して秒単位で課金されます。最低課金単位は1分です。

リソース	料金（東京リージョン）
vCPU	約0.05056 USD/vCPU/時間
メモリ	約0.00553 USD/GB/時間
エフェメラルストレージ	0.000111 USD/GB/時間（20GBを超える分）

料金例：1 vCPU / 2 GB メモリで1時間稼働

vCPU: 0.05056 USD × 1 = 0.05056 USD
メモリ: 0.00553 USD × 2 = 0.01106 USD
合計: 約0.062 USD/時間

Fargate Spot

割り込み耐性のあるワークロードには、Fargate Spotを利用することで最大70%のコスト削減が可能です。バッチ処理やCI/CDパイプラインなど、中断されても再実行可能なタスクに適しています。

AWS App Runner

AWS App Runnerは、ソースコードまたはコンテナイメージから直接Webアプリケーションをデプロイできるフルマネージドサービスです。インフラストラクチャの知識がなくても、数クリックでアプリケーションを公開できます。

App Runnerの特徴

App Runnerは、ECSやFargateよりもさらに抽象化されたサービスで、開発者体験を最優先しています。

ソースコードからの直接デプロイ

GitHubリポジトリを接続するだけで、App Runnerがソースコードからコンテナイメージをビルドし、自動的にデプロイします。Dockerfileすら不要で、言語ランタイム（Python、Node.js、Java、.NET、Go、PHP、Ruby）を指定するだけで動作します。

自動スケーリング

リクエストに応じてコンテナインスタンスが自動的にスケールアップ・ダウンします。アイドル時はプロビジョニングされたインスタンスがウォームスタンバイ状態で待機するため、コールドスタートを最小限に抑えられます。

組み込みのロードバランシング

Application Load Balancerを個別に設定する必要がありません。App Runnerが自動的にトラフィックを分散します。

App Runnerのリソース設定

App Runnerでは、以下の構成から選択できます。

vCPU	メモリ（GB）
0.25	0.5、1
0.5	1
1	2、3、4
2	4、6
4	8、10、12

App Runnerの料金体系

App Runnerの料金は、「プロビジョニング状態」と「アクティブ状態」で異なります。

状態	課金項目	料金（東京リージョン）
プロビジョニング	メモリのみ	0.009 USD/GB/時間
アクティブ	vCPU + メモリ	0.081 USD/vCPU/時間 + 0.009 USD/GB/時間
自動デプロイ	月額固定	1 USD/アプリ/月
ビルド	ビルド時間	0.005 USD/ビルド分

料金例：1 vCPU / 2 GB メモリ、1日8時間アクティブ、16時間プロビジョニング

アクティブ時間:
  vCPU: 0.081 USD × 1 × 8h = 0.648 USD
  メモリ: 0.009 USD × 2 × 8h = 0.144 USD

プロビジョニング時間:
  メモリ: 0.009 USD × 2 × 16h = 0.288 USD

1日あたり合計: 約1.08 USD

サービス選択のポイント

プロジェクトの要件に応じて、最適なサービスを選択することが重要です。以下のフローチャートを参考にしてください。

flowchart TB
    Start["コンテナサービスを選択"] --> Q1{"Kubernetesを<br/>使用したい？"}
    Q1 -->|Yes| EKS["Amazon EKS"]
    Q1 -->|No| Q2{"インフラ管理を<br/>最小化したい？"}
    
    Q2 -->|Yes| Q3{"アプリの複雑さは？"}
    Q2 -->|No| ECSEC2["ECS on EC2"]
    
    Q3 -->|シンプルなWebアプリ| AppRunner["App Runner"]
    Q3 -->|複雑なマイクロサービス| ECSFargate["ECS on Fargate"]
    
    ECSEC2 --> Note1["EC2インスタンスの<br/>細かな制御が必要な場合"]
    AppRunner --> Note2["最速でデプロイしたい<br/>シンプルなアプリ向け"]
    ECSFargate --> Note3["サーバーレスで<br/>柔軟な構成が必要な場合"]

選択基準の比較表

観点	ECS on EC2	ECS on Fargate	App Runner
管理負荷	高	中	低
柔軟性	高	中	低
学習コスト	高	中	低
コスト最適化	可能	限定的	限定的
起動速度	中	中	高
GPUサポート	あり	なし	なし

ユースケース別の推奨サービス

App Runnerが適している場合

Webアプリケーションやシンプルなapi
開発・テスト環境の迅速な構築
インフラの専門知識がないチーム
GitHubからの継続的デプロイを手軽に実現したい場合

ECS on Fargateが適している場合

マイクロサービスアーキテクチャ
バッチ処理やスケジュールタスク
VPC内のリソースとの連携が必要な場合
タスクごとのIAMロール設定が必要な場合

ECS on EC2が適している場合

GPUを使用する機械学習ワークロード
特定のインスタンスタイプが必要な場合
コストを細かく最適化したい場合
大規模で予測可能なワークロード

代表的なユースケース

実際のプロジェクトでどのようにサービスを組み合わせるか、具体的なパターンを紹介します。

パターン1：スタートアップのWebアプリケーション

スピード重視で最小限の運用負荷を目指す場合の構成です。

flowchart LR
    User["ユーザー"] --> AppRunner["App Runner"]
    AppRunner --> RDS["Amazon RDS"]
    AppRunner --> S3["Amazon S3"]
    
    GitHub["GitHub"] -->|自動デプロイ| AppRunner

フロントエンドとバックエンドをApp Runnerでホスティング
GitHubへのプッシュで自動デプロイ
データベースはAmazon RDSを使用
静的ファイルはS3に保存

パターン2：マイクロサービスアーキテクチャ

複数のサービスが連携する中〜大規模システムの構成です。

flowchart TB
    ALB["Application<br/>Load Balancer"] --> ServiceA["ユーザーサービス<br/>ECS Task"]
    ALB --> ServiceB["注文サービス<br/>ECS Task"]
    ALB --> ServiceC["在庫サービス<br/>ECS Task"]
    
    ServiceA --> RDS["Amazon RDS"]
    ServiceB --> DynamoDB["DynamoDB"]
    ServiceC --> ElastiCache["ElastiCache"]
    
    ECR["Amazon ECR"] -.->|イメージ| ServiceA
    ECR -.->|イメージ| ServiceB
    ECR -.->|イメージ| ServiceC
    
    subgraph Fargate["AWS Fargate"]
        ServiceA
        ServiceB
        ServiceC
    end

各マイクロサービスをECS on Fargateで実行
ALBでトラフィックをルーティング
サービスごとに最適なデータストアを選択
ECRでイメージを一元管理

パターン3：バッチ処理システム

定期的なデータ処理を行うシステムの構成です。

flowchart LR
    EventBridge["EventBridge<br/>スケジュール"] --> ECS["ECS Task<br/>（Fargate Spot）"]
    ECS --> S3["S3<br/>入力データ"]
    ECS --> RDS["RDS<br/>処理結果"]
    ECS --> SNS["SNS<br/>完了通知"]

EventBridgeでスケジュール実行
Fargate Spotでコスト最適化
処理完了時にSNSで通知

まとめ

AWSのコンテナサービスは、レジストリ（ECR）、オーケストレーション（ECS/EKS）、コンピューティング（Fargate/EC2）、簡易デプロイ（App Runner）という役割に分かれています。サービス選択のポイントは以下のとおりです。

App Runner：最も手軽にWebアプリをデプロイしたい場合に最適
ECS on Fargate：サーバーレスで柔軟なコンテナ運用を実現したい場合に推奨
ECS on EC2：コスト最適化やGPU利用など、細かな制御が必要な場合に選択

まずはApp Runnerで小さく始め、要件が複雑になるにつれてECS on Fargateへ移行するという段階的なアプローチも有効です。プロジェクトの規模、チームのスキルセット、運用負荷の許容度を考慮して、最適なサービスを選択してください。

はじめに#

AWSコンテナサービスの全体像#

各レイヤーの役割#

Amazon ECR（Elastic Container Registry）#

ECRの主な機能#

ECRの料金体系#

ECRの基本的な使い方#

Amazon ECS（Elastic Container Service）#

ECSの主要コンポーネント#

ECSの料金体系#

AWS Fargate#

Fargateの特徴#

Fargateのリソース設定#

Fargateの料金体系#

Fargate Spot#

AWS App Runner#

App Runnerの特徴#

App Runnerのリソース設定#

App Runnerの料金体系#

サービス選択のポイント#

選択基準の比較表#

ユースケース別の推奨サービス#

代表的なユースケース#

パターン1：スタートアップのWebアプリケーション#

パターン2：マイクロサービスアーキテクチャ#

パターン3：バッチ処理システム#

まとめ#

参考リンク#