※これは Japan AWS Jr.Champions の活動である「コンテナ・サーバレス もくもく会」で実施したハンズオンのアウトプットです。
🧭 はじめに
PJでコンテナ（EKS）上の基幹システム構築は経験しているんですが…
- ロールの関係上、業務では全然コンテナに触らない
- そもそも AWS周りのコンテナサービスに全然触ったことが無い！
ということで、
Japan AWS Jr.Championsの活動である 「コンテナ・サーバレス もくもく会」 に参加し、
AWSのコンテナサービスに時間の許す限り触ってみることにしました。
🐳 今回のゴール
まずは AWSに閉じた話での入門編 ということで、今回は以下を実施しました👇
- 事前準備：ECRにイメージをプッシュする
- ECS：簡単なタスクを実行してみる
- AWS Batch：ECS（Fargate）を動かしてみる
🛠️ ハンズオンの狙い
- ECR / ECS / AWS Batch といった AWSコンテナサービスの基本概念 を理解する
- 実際にコンテナを動かしながら 構成要素や流れ を整理する
本記事では、③AWS BatchからECS（Fargate）を動かしてみるを実施してみたいと思います。
AWS Batchについて
AWS Batchとは
AWS Batch は、コンテナを利用してバッチ処理を効率的に実行できるマネージドサービスです。
数十〜数万規模のバッチジョブを、自動的にスケーリングしながら効率的に実行できます。
- インフラ管理不要：Fargate や EC2 を基盤としてジョブを実行できる
- ジョブスケジューリング機能：依存関係や優先度をもとに順序制御が可能
- コスト最適化：必要な分だけ計算リソースを動的に起動・停止できる
ECS / EKS / Lambda との違い
AWS Batch は内部的に ECS または EKS を利用していますが、概念的な役割は以下のように異なります👇
| サービス | 役割 / 特徴 | 主なユースケース |
|---|---|---|
| ECS / EKS | コンテナ実行基盤そのもの | Webアプリ、APIサーバ、定常タスクなど |
| Lambda | イベント駆動で短時間の処理を実行 | 軽量な処理、APIバックエンド、トリガー処理など |
| AWS Batch | コンテナ実行を「ジョブ」として管理・スケジュール | データ処理、ログ集計、バッチ処理、大量計算など |
- ECS / EKS は「常時動かす・制御する」ためのコンテナ基盤
- Lambda は「即時実行・短時間処理」に最適
- AWS Batch は「大量ジョブをスケジュール・実行管理」するのに特化
💡 ざっくり言うと、「ECS でバッチ処理をうまく回す仕組み」を AWS がラップして提供しているのが AWS Batch です。
AWS Batchの構成要素
AWS Batch では、以下の 3つの構成要素 を組み合わせてジョブを実行します👇
🧮 コンピューティング環境（Compute Environment）
ジョブを実際に実行するための 実行基盤 です。
Fargate または EC2 を選択でき、ここで定義した環境の中でジョブが実行されます。
主な設定項目
-
環境タイプ：
Fargate/Fargate Spot/EC2 - 最大 vCPU 数：同時に実行できるジョブのキャパシティ
- VPC / サブネット / セキュリティグループ：ネットワーク設定
- サービスリンクロール：Batch と ECS 間の連携に利用される IAM ロール
🔸 今回はハンズオンのため、Fargate（Spot含む）を利用してシンプルに構築します。
🗂️ ジョブキュー（Job Queue）
ジョブキューは、送信されたジョブを一時的に保管し、実行順序や優先度を管理 する役割を持ちます。
複数のコンピューティング環境を接続し、優先度に応じて実行リソースを割り当てることができます。
主な設定項目
- 優先度：複数のキューを設定した場合、どちらを優先的に実行するか
- 接続先コンピューティング環境：ジョブを実行する実行基盤を指定
- オーケストレーションタイプ：Fargate or EC2
🧾 ジョブ定義（Job Definition）
ジョブ定義は、どのコンテナイメージをどんなリソース構成で実行するか を定義するテンプレートです。
ECS の「タスク定義」と似ています。
主な設定項目
- コンテナイメージ：ECRなどに格納されたイメージを指定
- リソース設定：vCPU / メモリ / 一時ストレージサイズ
- 実行ロール：ジョブ実行時に必要な IAM ロール
- ログ設定：CloudWatch Logs への出力設定
- 試行回数：ジョブの再試行回数
💡 AWS Batch の「ジョブ」は、このジョブ定義をもとに実行されます。
同じジョブ定義を使って、パラメータを変えながら複数のジョブを同時実行することも可能です。
📝 まとめ
| 構成要素 | 役割 | 主な設定内容 |
|---|---|---|
| コンピューティング環境 | ジョブの実行基盤 | Fargate/EC2、vCPU、ネットワーク設定 |
| ジョブキュー | ジョブの順序・優先度管理 | 優先度、接続する環境、実行戦略 |
| ジョブ定義 | ジョブ実行のテンプレート | イメージ、リソース設定、ロール、ログ出力 |
ハンズオン実施概要
📊 アーキテクチャ図
今回は、S3に出力されたアクセスログを、S3出力イベントをトリガーにLambdaを起動し、LambdaからAWS Batchを起動してアクセスログの集計を行う機能を実装してみます。
アクセスログはこんな感じのファイルをサンプルとして用意しました。
接続時間やステータスの集計結果を出してみたいと思います。
✐ 実施概要
- 事前準備（S3バケットの作成）
- IAMロールの作成
- AWS Batchの設定
- Lambda作成・イベント通知の有効化
①事前準備（S3バケットの作成）
事前準備として、アクセスログ出力用と集計結果出力用の2つのS3バケットを作成します。
設定はデフォルトで問題無し。
アクセスログ出力用：
Lambda作成後、イベント通知を設定し、アクセスログの出力をトリガーにLambdaをキックする設定を入れる
集計結果格納用：
AWS Batchで起動したECSタスクにて集計した結果を出力する。
②AWS Batch用のIAMロールの作成
AWS BatchからECSタスクをキックする際に、ECSタスクで使用するIAMロールを作成します。
※第2章のタスクロール・タスク実行ロールと同じ役割
※やりたいことは同じなので第2章で作成済みのものを今回は使用します。（AmazonECSTaskExecutionRolePolicy, AmazonS3FullAccessを付与）
③AWS Batchの設定
①コンピューティング環境の作成
「AWS Batch」＞「環境」＞「環境を作成」＞「コンピューティング環境」を選択
以下設定値を入力して環境を作成
今回はFargateでジョブを実行するので、Fargateを選択します。
| 項目 | 設定値 |
|---|---|
| コンピューティング環境設定 | Fargate |
| 名前 | 任意の名前を設定 |
| サービスリンクロール | デフォルト（AWSServiceRoleForBatch） |
Spotインスタンスを使うことで、念のため更に料金を下げておきます。
| 項目 | 設定値 |
|---|---|
| Fargate Spot容量を使用 | 有効化 |
| 最大vCPU | 1（今回は最小でOK） |
続いてネットワークの設定。
ここではBatchで動かすECSタスクとAWSサービスが通信可能であるように設定する必要があります。
今回は特にプライベートなネットワーク環境は構築していないので、Defaultのリソースを使用。
| 項目 | 設定値 |
|---|---|
| 仮想プライベートクラウド（VPC）ID | 任意のVPCを選択（Defaultでも問題無い） |
| サブネット | インターネット通信可能なサブネットを選択（Defaultで問題無い） |
| セキュリティグループ | アウトバウンドルールでPort:443 送信先0.0.0.0/0のアウトバウンドルールを持つセキュリティグループを指定。（Defaultで問題無い） |
②ジョブキューの作成
「AWS Batch」＞「ジョブキュー」＞「作成」を選択
以下設定値を入力してジョブキューを作成
| 項目 | 設定値 |
|---|---|
| オーケストレーションタイプ | Fargate |
| 名前 | 任意の名前を設定 |
| 優先度 | 1（今回は1つのジョブキューのみを作成するため |
| 接続されたコンピューティング環境 | 前の手順で作成したコンピューティング環境を設定 |
③ジョブ定義の作成
「AWS Batch」＞「ジョブ定義」＞「作成」を押下
以下の値を入力してジョブ定義を作成する（記載の無い項目はデフォルト値でOK）
実行ロールはECSのタスク実行ロールと同じ役割と思って良いかと思います。
| 項目 | 設定値 |
|---|---|
| オーケストレーションタイプ | Fargate |
| エフェメラルドストレージ | 21（今回は最小値で問題無い） |
| 実行ロール | ステップ4にて作成したIAMロールを選択 |
| ジョブの試行 | 1 |
イメージはECRにプッシュしたDockerイメージを指定。
ジョブロールはECSのタスクロールと同じイメージ。オプションと書いてありますが、これを指定しないとエラーが起きました、、
| 項目 | 設定値 |
|---|---|
| イメージ | ECRにPushしたイメージのURIを指定 |
| ジョブロール | ステップ4にて作成したIAMロールを選択 |
| vCPU | 1.0（最小でOK） |
| メモリ | 2GiB（最小でOK） |
| 項目 | 設定値 |
|---|---|
| ログドライバー | awslogs |
これで、AWS BatchでECSタスクを実行可能になりました。
④AWS Lambdaの設定・S3イベント通知の有効化
Lambda関数を作成し、AWSBatchを起動するソースコードをデプロイする。
（今回はGPT君に書いてもらいました）
import os
import json
import boto3
from datetime import datetime
from urllib.parse import unquote_plus
batch = boto3.client("batch")
# 環境変数で設定（コンソール or IaC でセット）
JOB_QUEUE_ARN = os.environ["BATCH_JOB_QUEUE_ARN"]
JOB_DEFINITION_ARN = os.environ["BATCH_JOB_DEFINITION_ARN"]
OUTPUT_BUCKET = os.environ["OUTPUT_BUCKET"]
JOB_NAME_PREFIX = os.environ.get("JOB_NAME_PREFIX", "accesslog-aggregate")
def lambda_handler(event, context):
print("Event:", json.dumps(event))
results = []
for rec in event.get("Records", []):
bucket = rec["s3"]["bucket"]["name"]
key = unquote_plus(rec["s3"]["object"]["key"]) # URLエンコード解除
# 入力ファイル名から日付を抽出
# ファイル形式: accesslog_YYYYMMDD.csv
base_name = os.path.basename(key)
date_str = base_name.replace("accesslog_", "").replace(".csv", "")
# 出力ファイル: YYYYMMDD/summary_YYYYMMDD.csv
output_key = f"{date_str}/summary_{date_str}.csv"
# ジョブ名はユニークに（日付＋timestamp）
job_name = f"{JOB_NAME_PREFIX}-{date_str}-{int(datetime.utcnow().timestamp())}"
response = batch.submit_job(
jobName=job_name,
jobQueue=JOB_QUEUE_ARN,
jobDefinition=JOB_DEFINITION_ARN,
containerOverrides={
"command": [
"--input-bucket", bucket,
"--input-prefix", key,
"--output-bucket", OUTPUT_BUCKET,
"--output-key", output_key
]
}
)
print("Submitted job:", response["jobId"], "for key:", key)
results.append({
"jobName": job_name,
"jobId": response["jobId"],
"inputKey": key,
"outputKey": output_key
})
return {"submitted": results}
環境変数で以下を設定する
| 項目 | 設定値 |
|---|---|
| BATCH_JOB_DEFINITION_ARN | 作成したAWS Batchのジョブ定義のARNを設定 |
| BATCH_JOB_QUEUE_ARN | 作成したジョブキューのARNを設定 |
| OUTPUT_BUCKET | 作成した集計結果格納用のS3バケット名を設定 |
続いて、S3でイベント通知を有効化し、ログ出力をトリガーにLambdaをキック出来るようにします。
「S3」＞「集計結果格納用のS3バケット」＞「プロパティ」＞「イベント通知」＞「イベント通知を作成」を選択
以下設定値を入力し、イベント通知を作成
ちなみに、S3イベント通知でLambdaをキックすることで、バケット名やプレフィックスは引数としてLambdaに渡すことが出来ます。
| 項目 | 設定値 |
|---|---|
| 名前 | 任意の名前を設定 |
| イベントタイプ | PUT（s3:ObjectCreated:Put） |
| 送信先 | Lambda関数（前の手順で作成したLambda関数） |
これで実装完了！動作確認していきます。
動作確認
アクセスログ出力用のS3バケットにアクセスログのサンプルを格納してみます。
これをトリガーにAWS Batchジョブが起動するはず。
AWS Batchコンソールを開き、「ジョブ」＞「結果を更新」を押下して、ジョブが開始していることを確認出来ました。
ジョブのステータスがSucceededになった後、集計結果格納用のS3バケットに集計結果が出力されていることを確認
こんな感じでアクセスログの集計結果を出せました。
🏁 おわりに
今回までで、
- 事前準備：ECR にイメージをプッシュする
- ECS：簡単なタスクを実行してみる
- AWS Batch：ECS（Fargate）を動かしてみる
という一連の流れを通して、コンテナを活用したバッチ処理の基本を体験しました。
コンテナの知識がゼロでも、AWS のマネージドサービスを組み合わせることで
シンプルかつ実践的なバッチ処理環境を素早く構築できる ことに改めて驚かされました。
一方で、コンテナ活用の真価はここから。
Kubernetes や EKS、より高度な運用設計、CI/CD パイプラインとの統合など、
深掘りすべき領域はまだまだ多くあります。
今後も継続的に学び、コンテナ活用の幅を広げていきたいと思います！