🧭 はじめに

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 をより柔軟かつ実践的に活用できるようになりそうです