🧭 はじめに
PJでコンテナ（EKS）上の基幹システム構築は経験しているんですが…
- ロールの関係上、業務では全然コンテナに触らない
- そもそも AWS周りのコンテナサービスに全然触ったことが無い！
ということで、
Japan AWS Jr.Championsの活動である 「コンテナ・サーバレス もくもく会」 に参加し、
AWSのコンテナサービスに触ったことをきっかけに、継続的に触ってみることにしました。
触った内容・学んだ内容を備忘として残しておければと思います。
（AWSコンテナ初学者の一助になれば良いなという想いもありつつ）
🛠️ 今回やること
- ECSサービス上で簡単なアプリを動かしてみて、ロードバランサーからアクセスしてみる
ハンズオン実施概要
- 事前準備
- ロードバランサーの作成
- ECSサービスの作成
ハンズオン実施
①事前準備
今回はECSサービスを動かしてみて必要な設定要素をさらうことが目的なので、
以下のような形で（Hello ECS！」と表示させるのみとします。
Healthチェックは/healthにて実施します。
前回までと同じく、ECRにイメージをPush。
from fastapi import FastAPI
app = FastAPI()
@app.get("/health")
def health():
return {"status": "ok"}
@app.get("/")
def root():
return {"message": "Hello ECS!"}
Dockerfileは以下。
ここのポートの設定でちょっと躓きましたが、それについては後ほど。
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app ./app
EXPOSE 8080
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8080"]
ECRにイメージをPush。
ここまではECSタスクを動かしたときと一緒。
② ターゲットグループの作成
ECS Fargate で稼働するコンテナを ALB（Application Load Balancer）と接続するため、
まずは ターゲットグループ を作成します。
このターゲットグループが、ALB からのリクエストをコンテナへ転送する中継地点となります。
⚠️ 注意点①：ターゲットタイプ
ECS Fargate では、IP アドレス型 のターゲットグループしか利用できません。
そのため、作成時は必ずターゲットタイプとして 「IPアドレス」 を選択します。
（ここはよくハマりポイントになります）
⚠️ 注意点②：ターゲットポート
ターゲットポートには、コンテナアプリケーションがリッスンしているポート番号 を指定します。
今回は Dockerfile 内でアプリの受け口を 8080 に指定しているため、
ターゲットポートにも 8080 を指定します。
（ALB → ターゲットグループ → コンテナ という経路で通信が行われます）
③ ロードバランサー（ALB）の作成
続いて、ALB を作成し、先ほどのターゲットグループと接続します。
🧰 設定ポイント
-
スキーム：今回はインターネット経由でアクセスするため、「インターネット向け」を選択します
-
リスナーとルーティング：
今回は HTTPS 用の証明書を用意していないため、
HTTP (80) でリスナーを作成し、転送先として先ほどのターゲットグループを指定します。
このターゲットグループは、後ほど ECS サービス設定でも使用します。 -
ヘルスチェックパス：
コンテナアプリケーションで/healthをエンドポイントとして実装しているため、
ヘルスチェックパスにも/healthを指定します。
📝 ALB が
/healthへのアクセスで 200 を返せる状態であれば、ECS サービスのデプロイも正常に進みます。
④ ECSサービスの作成（ALB接続）
ALB とターゲットグループの作成が完了したら、いよいよ ECS サービス を作成していきます。
ECS サービスを利用することで、タスクのスケーリング・冗長化・ALB との接続 が可能になります。
🧭 基本設定
タスク定義の指定、キャパシティプロバイダー戦略の指定、ネットワーキングの設定など、
基本的な項目は「ECS タスク実行時」と同様です。
今回はこれに加えて ロードバランシング の設定を追加していきます。
🌐 ロードバランシング設定
-
VPC の選択：
事前に ALB を構築した VPC を選択します。
💡 ECS サービスのタスク定義と同一 VPC である必要があります。 -
コンテナの選択：
タスク定義で設定したコンテナが選択可能になります。
このとき指定する コンテナポート は、ターゲットグループで指定したポートと一致している必要があります（今回は8080）。
⚙️ ロードバランサーの指定
-
ロードバランサー：
既存の ALB を選択します。 -
リスナー：
作成済みのリスナー（今回はHTTP:80）を選択します。
-
ターゲットグループ：
ALB のリスナールールで設定したターゲットグループを指定します。
ヘルスチェックパスを設定済みであれば、自動的に候補が表示されます。
設定が完了したら、その他はデフォルトのままサービスを作成します。
作成後、クラスターの「サービス」タブ から状態や設定が確認できます。
タスクの状態は「タスク」タブで確認可能です。
サービス経由で自動的にタスクが起動していることがわかります。
これでOK！と思いきや、サービス作成後、以下のようなエラーが出ました
ResourceInitializationError: unable to pull secrets or registry auth:
The task cannot pull registry auth from Amazon ECR:
There is a connection issue between the task and Amazon ECR.
Check your task network configuration.
operation error ECR: GetAuthorizationToken, exceeded maximum number of attempts, 3,
https response error StatusCode: 0, RequestID: , request send failed,
Post "https://api.ecr.ap-northeast-1.amazonaws.com/
": dial tcp xx.xx.xx.xx:443: i/o timeout
これは ECS タスクが ECR に接続できない ことが原因です。
今回の構成では パブリックサブネット 上にタスクを配置しているため、
「パブリック IP の割り当て」を有効化する必要があります。
この設定により、ECR や CloudWatch Logs といった AWS サービスへインターネット経由でアクセス可能となり、
正常にタスクが起動するようになります。
設定変更後は問題なくタスクが起動し、ALB 経由でアクセス可能になりました🎉
疎通確認
ECSサービスが立ち上がったので、ALBのDNSに対してアクセスしてみます。
正常に立ち上がってますね！
/healthにアクセスしてみます。
ステータスコードも正常です。
今回ハマったポイント
今回、ECS サービスと ALB を疎通させるにあたり、ポート設定の不一致でかなり躓きました。
ALB–ECS サービス構成では、以下の ①〜③ のポートがすべて一致していなければ、
ターゲットグループと ECS サービス間の疎通に失敗し、ヘルスチェックで落ちてタスクが正常に起動しませんでした
| # | 設定箇所 | 役割・意味 | 例 | 注意点 |
|---|---|---|---|---|
| ① | Dockerfile（CMD） | コンテナ内でアプリが Listen するポート |
1025 or 8080
|
アプリケーションが実際に受け付けるポート |
| ② | ECS タスク定義（containerPort） | ALB などがタスクに接続する宛先ポート | 1025 |
コンテナ内で Listen するポート（①）と一致させる必要あり |
| ③ | ターゲットグループ（Target Group） | ALB → ECS タスク への転送先ポート | 1025 |
ECS コンテナポート（②）と一致させる必要あり |
| ④ | ALB リスナー（Listener） | 外部クライアントが ALB にアクセスするポート |
80（HTTP） or 443（HTTPS） |
ALB 側で受け付けるポート。①〜③とは別でもOK（ALBで変換される） |
👉 ポイント：
- ①②③ が一致していなければ ALB と ECS の疎通に失敗します。
- ④ は外部アクセスの受け口のため、別ポートでも ALB が内部の ①〜③ へ転送する形になります。
- 特に Dockerfile のポートとターゲットグループのポートの不一致はよくあるミスです。
おわりに
これで、ECS サービスを利用して シンプルなアプリケーションを ALB 経由で立ち上げる ことに成功しました！
ECS では、以下のように 「タスク（Run Task）」 と 「サービス（ECS Service）」 の2つの使い方があることも理解できました
-
🧰 タスク（Run Task）：
バッチ処理やジョブ実行のように「実行 → 完了」で終わる一時的な処理に向いている。 -
🌐 サービス（ECS Service）：
タスクを常時稼働させ、Web サーバーやアプリケーションサーバーとして運用するのに適している。
この違いを理解し、ユースケースごとに使い分けることで、
ECS をより柔軟かつ実践的に活用できるようになりそうです