Amazon ECS Express Mode がリリース

Last updated at 2025-11-27Posted at 2025-11-27

はじめに

2025 年 11 月 21 日、AWS は Amazon Elastic Container Service（ECS）向けの新機能「Express Mode」を発表しました。
Express Mode は、コンテナイメージを用意するだけで、インフラストラクチャを自動構成し、数分以内に HTTPS 対応のアプリケーションをデプロイできる機能です。
本記事では、Express Mode の詳細、従来との違い、実際の使い方、コストや制限事項についてまとめています。
この機能は全 AWS 商用リージョンおよび AWS GovCloud (US)リージョンで即座に利用可能となっています。

Express Modeとは

概要

Express Modeは、コンテナ化されたアプリケーションを迅速にデプロイできるECSの新機能です。
開発者はコンテナイメージを提供するだけで、ECSが自動的にインフラストラクチャをオーケストレーションします。

主な特徴

主な特徴としては以下の 4 つです。

ワンクリックセットアップ
AWS 提供のドメイン名と HTTPS 対応
自動スケーリングと負荷分散
完全な制御性の維持

ワンクリックセットアップ

ECS コンソールまたは AWS CLI から、コンテナイメージ URI と 2 つの IAM ロールを指定するだけでデプロイが完了します。

AWS 提供のドメイン名と HTTPS 対応

デプロイと同時に一意の URL が自動生成され、即座に HTTPS でアクセス可能になります。

自動スケーリングと負荷分散

トラフィックパターンに応じてタスク数が自動調整され、Application Load Balancer（ALB）による負荷分散が行われます。
最大 25 の Express Mode サービスを 1 つの ALB に統合できます。

完全な制御性の維持

自動構成されたすべてのリソースはアカウント内で完全にアクセス可能で、必要に応じて後から直接変更することもできます。

自動構成されるリソース

Express Mode を使用すると、以下の AWS リソースが自動的に作成されます。

ECS クラスター：指定がない場合は default クラスターが使用される
Fargate タスク定義：サーバーレスなコンテナ実行環境
ECS サービス：タスクのライフサイクル管理
Application Load Balancer：トラフィックの負荷分散
Route 53 レコード：AWS 提供のドメイン名
ACM 証明書：HTTPS 対応のための SSL/TLS 証明書
セキュリティグループ：最小権限の原則に基づいた設定
Auto Scaling ポリシー：デフォルトでは CPU 使用率ベース

仕組み

Express Mode がどのようにインフラストラクチャを自動構成し、アプリケーションをデプロイするのか、その仕組みを詳しく見ていきます。

アーキテクチャ概要

Express Mode は AWS Fargate をコンピュートエンジンとして使用し、サーバーレスなコンテナ実行環境を提供します。

主要コンポーネント

Fargate タスク

コンテナの実行環境として、AWS Fargate が使用されます。
サーバー管理が不要で、CPU/メモリは個別に設定可能です。

Application Load Balancer

トラフィックの負荷分散を担当し、host-header ベースのリスナールールにより複数のサービスを区別します。
Express Mode の重要な特徴として、最大 25 のサービスを 1 つの ALB に統合できます。
各サービスには一意のドメイン名が割り当てられ、ALB が host-header を使ってルーティングします。
この仕組みにより、サービス間の分離を維持しながら ALB のコストを削減できます。

Route 53

AWS 提供のドメイン名を自動生成します。
各サービスに一意の URL が割り当てられ、ALB をターゲットとした A レコードが自動作成されます。

AWS Certificate Manager（ACM）

SSL/TLS 証明書の自動発行と管理を担当します。
証明書の更新も自動で行われるため、手動での管理は不要です。

Auto Scaling

デフォルトでは、CPU 使用率ベースの Auto Scaling ポリシーが設定されます。
トラフィックパターンに応じてタスク数が自動的に調整され、最小タスク数から最大タスク数の範囲内でスケールします。

セキュリティグループ

最小権限の原則に基づいたセキュリティグループが自動で作成され、必要なポートのみが開放されます。

デプロイフロー

Express Mode でのデプロイは、以下のフローで自動的に実行されます。

すべてのプロセスが自動化されており、ユーザーの介入は不要です。

何が変わったのか

Express Mode の導入により ECS でのコンテナデプロイがどのように変わったのか、従来の課題と新機能による変化を見ていきます。

従来の課題

主な課題としては以下の 2 つがありました。

複雑なインフラ設定
ALB コストの増加

複雑なインフラ設定

従来の ECS では、VPC、サブネット、セキュリティグループ、ALB、ターゲットグループ、ECS クラスター、タスク定義、サービス定義、Route 53 のドメイン設定、ACM の証明書発行、Auto Scaling ポリシーなど多くのコンポーネントを個別に設定する必要がありました。
高度な AWS の知識が必要で、初回デプロイまで数時間から数日かかることも珍しくありませんでした。

ALB コストの増加

各サービスに個別の ALB が必要で、小規模なマイクロサービスでもフルコストの ALB が発生していました。
5 つの API サービスを運用する場合、ALB 5 個分の料金が発生します。

Express Mode による変化

Express Mode の導入により、従来の課題がすべて解決されました。

シンプルな設定

コンテナイメージ URI と 2 つの IAM ロールを指定するだけでデプロイが完了します。
インフラコンポーネントはすべて自動作成されるため、数分で本番環境へデプロイ可能になりました。

コスト最適化

最大 25 のサービスを 1 つの ALB に統合できます。
従来のECSでは 5 つの API サービスを運用する場合、各サービスに個別の ALB が必要でしたが、Express Mode では 1 つの ALB に統合できるため、ALB コストを大幅に削減できます。

迅速なデプロイ

数分以内にデプロイが完了し、自動生成された HTTPS URL で即座にアクセス可能です。

完全な制御性の維持

自動構成されたすべてのリソースはアカウント内で完全にアクセス可能です。
必要に応じてカスタマイズでき、通常の ECS サービスへの移行も可能です。

比較表

項目	従来の ECS	Express Mode
初期設定時間	数時間〜数日	数分
必要な設定項目	10 以上のリソース	3 つ
HTTPS 設定	手動	自動
ALB コスト（5 サービス）	ALB 5 個分	ALB 1 個分

使い方

Express Mode の実際の使い方を、サンプルアプリケーションを使って説明します。

サンプルアプリケーションの準備

実際に動作するシンプルな Flask アプリケーションを作成します。

アプリケーションコードの作成

app.py

from flask import Flask, jsonify
import os

app = Flask(__name__)

@app.route('/')
def hello():
    hostname = os.environ.get('HOSTNAME', 'unknown')
    return f'Hello from ECS Express Mode! Container: {hostname}'

@app.route('/health')
def health():
    return jsonify({'status': 'healthy'}), 200

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=80)

requirements.txt

Flask==3.0.0
gunicorn==21.2.0

Dockerfile の作成

Dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 80

CMD ["gunicorn", "--bind", "0.0.0.0:80", "app:app"]

Amazon ECR へのプッシュ

コンテナイメージをビルドし、Amazon ECR にプッシュします。

Docker イメージのビルド

実行コマンド

# Dockerイメージをビルド
docker build -t express-mode-demo .

# ビルドされたイメージを確認
docker images | grep express-mode-demo

ECR リポジトリの作成

実行コマンド

aws ecr create-repository \
  --repository-name express-mode-demo \
  --region ap-northeast-1

イメージのプッシュ

実行コマンド

# ECR にログイン
aws ecr get-login-password --region ap-northeast-1 | \
  docker login --username AWS --password-stdin \
  <account-id>.dkr.ecr.ap-northeast-1.amazonaws.com

# イメージにタグ付け
docker tag express-mode-demo:latest \
  <account-id>.dkr.ecr.ap-northeast-1.amazonaws.com/express-mode-demo:latest

# プッシュ
docker push <account-id>.dkr.ecr.ap-northeast-1.amazonaws.com/express-mode-demo:latest

Express モードでのデプロイ

Express モードの選択

ECS コンソールを開き、ナビゲーションバーから「Express モード」を選択

アプリのセットアップ

以下の情報を入力

イメージ URI：ECR のイメージ URI
タスク実行ロール：ecsTaskExecutionRole（なければ作成）
インフラストラクチャロール：ecsInfrastructureRoleForExpressServices（なければ作成）

オプション設定

以下の情報を入力

クラスター：デプロイ先の ECS クラスター
名前：express-mode-demo
コンテナポート：80
ヘルスチェックパス：/health

作成

「作成」ボタンを押下後、デプロイ進行状況は「タイムラインビュー」で確認できます。

動作確認

デプロイが完了したら、自動生成された URL にアクセスして動作を確認します。

実行コマンド

# アクセステスト
curl https://<auto-generated-url>/

# ヘルスチェック確認
curl https://<auto-generated-url>/health

想定結果

# アクセステスト
# Hello from ECS Express Mode! Container: ecs-express-mode-demo-xxxxx

# ヘルスチェック確認
# {"status": "healthy"}

ブラウザで URL にアクセスすることも可能です。

Express Mode を使うべきケース

Express Mode は強力な機能ですが、すべてのユースケースに最適というわけではありません。
本章では Express Mode の使用が推奨されるケースと、通常の ECS を使うべきケースを説明します。

Express Mode が適しているケース

Web アプリケーションと API

ステートレスな HTTP リクエストを処理する Web アプリケーションや API に最適です。
RESTful API や Web アプリケーションのバックエンドなど、リクエスト・レスポンス型のアプリケーションであれば Express Mode で迅速にデプロイできます。

迅速なプロトタイピング

新機能の検証や概念実証（PoC）など、インフラセットアップに時間をかけずに素早くアプリケーションを動かしたい場合に有効です。
数分で HTTPS アクセス可能な環境が整うため、アイデアの検証サイクルを大幅に短縮できます。

開発者の生産性向上

スタートアップの小規模チームやフロントエンドエンジニアが独自に API をデプロイしたい場合など、AWS の深い知識がなくても独立してデプロイできる環境を提供します。
インフラチームのサポートを待たずに開発者が自律的にデプロイできるようになります。

通常の ECS を使うべきケース

高度なネットワーク要件がある場合

カスタム VPC エンドポイントや複雑なネットワークトポロジー、プライベートリンク、VPC ピアリングの詳細な制御が必要な場合は、通常の ECS を使用します。
Express Mode は標準的なネットワーク構成を前提としているため、高度なカスタマイズには対応していません。

Blue/Green デプロイが必要な場合

Express Mode はデフォルトで Blue/Green デプロイに対応していません。
ゼロダウンタイムでの切り替えやロールバックの容易さが重要な場合は、通常の ECS サービスで明示的に設定する必要があります。

EC2 起動タイプが必要な場合

Express Mode は Fargate のみをサポートしています。
GPU インスタンスの使用や特定の EC2 インスタンスタイプでの実行、コスト最適化のためのスポットインスタンスの活用などが必要な場合は、通常の ECS を使用します。

採用判断フロー

Express Mode から通常の ECS への移行

Express Mode で作成されたリソースはすべてアカウント内でアクセス可能なため、アプリケーション要件が進化した際には、通常の ECS サービスへシームレスに移行できます。
まずは Express Mode で始めて、必要に応じて段階的に高度な機能を追加していくアプローチが推奨されます。
初期段階では迅速なデプロイを優先、サービスが成熟するにつれて細かな制御が必要になったタイミングで移行、という戦略が効果的です。

コストと制限事項

Express Mode を使用する前に知っておくべきコストと制限事項について説明します。

料金体系

Express Mode 機能自体に追加料金は発生しません。
ただし、Express Mode で作成される AWS リソースに対して、通常の利用料金が発生します。

コスト構成要素

Fargate：タスクの vCPU とメモリ使用量に応じた課金
Application Load Balancer：ALB 稼働時間と LCU（Load Balancer Capacity Unit）に応じた課金
データ転送：アウトバウンドデータ転送量に応じた課金
CloudWatch Logs（オプション）：ログの取り込み量と保存量に応じた課金

コスト最適化のポイント

ALB 共有の活用：同じネットワーク設定を使用するサービスを 1 つの ALB に統合することで ALB コストを大幅に削減することが可能

制限事項

機能面の制限

起動タイプ：Fargate のみ対応（EC2 起動タイプは非対応）
ALB 共有：1 つの ALB あたり最大 25 サービスまで
Blue/Green デプロイ：デフォルトでは非対応（通常の ECS サービスへの移行が必要）
カスタム VPC エンドポイント：手動設定が必要

運用上の注意点

Express Mode で作成されたリソースは手動変更可能だが、大幅なカスタマイズには通常の ECS への移行を推奨
26 個目以降のサービスは新しい ALB が自動作成される

まとめ

今回発表された Express Mode は従来の ECS の柔軟性を維持しながらデプロイの複雑さを大幅に削減する実用的な機能です。
コンテナイメージを指定するだけで、数分以内に HTTPS 対応の本番環境が構築できます。
自動構成されたすべてのリソースはアカウント内でアクセス可能なため、必要に応じてカスタマイズや通常の ECS への移行も可能です。
従来は数時間から数日かかっていた初期セットアップが数分で完了するため、まずは非本番環境で実際に試してみることをお勧めします。
インフラ設定の手間を省き、開発者がビジネス価値の提供に集中できる環境を提供する本機能はコンテナデプロイの敷居を大きく下げるものとなるでしょう。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up