AWS 21：コンテナ ― ECR・ECS・Fargate でサーバーの世話を減らす

一言でいうと：動く環境ごと箱に詰めて運ぶ

コンテナは、アプリと、そのアプリが動くのに必要なもの（ランタイム・ライブラリ・設定）を、1つの箱に詰めたものです。

名前の由来は、港で見る輸送用のコンテナです。昔の船荷は、樽・袋・木箱と形がばらばらで、積み替えのたびに人手がかかりました。形のそろった鉄の箱に詰めるようになってから、中身が何であっても、同じ船・同じクレーン・同じトラックで運べるようになりました。

ソフトウェアのコンテナも同じです。

図では、EC2 の中にあった「アプリ」「ランタイム」「ライブラリ」の札が、黄色い箱の中に移りました。OS だけは箱の外、つまり置き場所の側に残っています。この点が次に説明する仮想マシンとの大きな違いです。

箱は、開発者のパソコンでも、テスト環境でも、本番の AWS でも、同じ形のまま動きます。「手元では動いたのに」の多くは、ここで消えます。

コンテナを作って動かす道具として最も広く使われているのが Docker（ドッカー）です。この章でも Docker を例に説明します。

仮想マシンとの違い：OS を持ち歩かない

EC2 は仮想マシンです。1台の物理サーバーを、仮想化のしくみで何台分かに区切り、それぞれが自分専用の OS をまるごと持って動きます（第9章）。

コンテナは、もう一段軽いしくみです。

図の左は、1台の物理サーバーの上に EC2 が2つ載った形です。どちらにも赤い「OS（まるごと）」があります。右はコンテナで、OS は下に1つだけ。その上に、アプリとライブラリだけの小さな箱が3つ載っています。

コンテナが「軽い」「速い」と言われるのは、この OS を持ち歩かない作りのためです。起動が速いので、混んできたときに素早く数を増やせますし、新しい版への入れ替えも短い時間で済みます。

ただし、コンテナもどこかのサーバーの上で動いていることは変わりません。そのサーバー（載せ台）を自分で用意するか、AWS に任せるかが、後で出てくる Fargate の話になります。

イメージとコンテナ：型と、型から作った実物

コンテナを作るには、まず イメージを作ります。イメージは、コンテナの型です。たい焼きの型と、焼き上がったたい焼きの関係に似ています。

図の Dockerfile を1行ずつ読んでみます。

FROM node:22-slim        土台にする公式のイメージ（Node.js 22 入り）
WORKDIR /app             作業場所を /app にする
COPY package*.json ./    使う部品の一覧をコピー
RUN npm ci --omit=dev    部品を入れる
COPY . .                 アプリのプログラムをコピー
EXPOSE 3000              3000番のポート（第8章）で待つ
CMD ["node", "server.js"] 起動したら最初に実行する命令

docker build でこの手順書からイメージを作り、docker run でイメージからコンテナを起動します。1つのイメージから、何個でもまったく同じコンテナを起動できます。

大事な約束は、イメージの中身は後から変えないことです。直したいときは Dockerfile かアプリを直して、新しいイメージを作り直します。そうすると「版 1.4.0 のイメージ」と言えば中身が1つに決まり、何が動いているのか・どこへ戻せばいいのかが明確になります。EC2 に SSH で入って手で直していたころとの大きな違いです。

ECR：イメージをしまっておく AWS の倉庫

作ったイメージは、動かす場所から取りに行ける置き場に置く必要があります。この置き場をコンテナレジストリと呼び、AWS では ECR（Elastic Container Registry）が受け持ちます。

図の流れは、左の開発者や CI が push し、右の動かす側が pull します。ECR のリポジトリの中には、1.4.0・1.3.2・1.3.1 と過去の版も並んでいます。新しい版に問題があれば、1つ前のタグを指定し直すだけで戻せます。

ECR には次のような特徴があります。

タグは必ず版で付けましょう。latest（最新）という名前だけで運ぶと、「いま本番で動いている latest はいつの latest か」が誰にもわからなくなります。

ECS の4つの言葉：クラスター・タスク定義・タスク・サービス

イメージを置いただけでは、まだ何も動きません。コンテナを起動し、落ちたら起動し直し、ALB に登録する係が要ります。この「コンテナの世話係」をオーケストレーターと呼び、AWS の標準の世話係が ECS（Elastic Container Service）です。

ECS を使うには、4つの言葉を覚えれば十分です。

図の右の黒い板がタスク定義です。イメージ photolog-web:1.4.0、CPU 0.5 vCPU、メモリ 1 GB、ポート 3000、ログは CloudWatch Logs へ、と書いてあります。この設計図から作られた実物が、左の「タスク 1」「タスク 2」です。

タスク定義には版番号が付きます。イメージのタグを 1.4.0 から 1.5.0 に変えると、タスク定義も「photolog-web の7番目」から「8番目」へと新しい版になります。何をいつ変えたかが、版の並びでそのまま残ります。

サービスが数を保つ：止まったタスクは自動で入れ替わる

サービスの一番大事な仕事は、望む数を保つことです。

図では、サービスに「タスクをいつも2つ動かす」と書いてあります。タスク 1 がメモリ不足などで止まると（札1）、サービスはすぐに気づき、同じタスク定義からタスク 3 を起動します（札2）。

人は何もしません。書いたのは「2つ」という望む数だけです。

これは第12章の Auto Scaling グループの「壊れたら入れ替わる」と同じ考え方です。そして、同じ理由でタスクはステートレスにしておく必要があります（第12章）。ログインの状態や、利用者が上げた写真をタスクの中に置いていると、入れ替わった瞬間に消えます。写真は S3（第15章）、データは RDS（第13章）に置くという第16章の作りは、コンテナになってもそのまま活きます。

どこで動かすか：EC2・Fargate・Managed Instances

コンテナも、どこかのサーバーの上で動きます。ECS では、その載せ台を3通りから選べます。

Fargate（ファーゲート）は、「サーバーを見ないでコンテナを動かす」方式です。タスク定義に「0.5 vCPU・1 GB」と書くと、AWS がその大きさの置き場を用意してタスクを載せます。OS の修正も、載せ台の台数も、あなたは考えません。

ECS Managed Instances は 2025年に加わった方式で、EC2 の豊富な種類を使いつつ、世話は AWS に任せます。

どれを選んでも、タスク定義・タスク・サービスという考え方は同じです。変わるのは「載せ台の世話を誰がするか」だけです。この本では、特別な理由がなければ Fargate で説明を進めます。

Fargate のタスクは、1つずつ自分の IP を持つ

ここから、第16章の VPC の舞台にタスクを置いてみます。

Fargate では、タスク1つごとにネットワークの差し口（ENI＝Elastic Network Interface。サーバーの LAN ケーブルの差し口のようなもの）が付き、プライベート IP アドレス（第5章）が1つ割り当てられます。このやり方を awsvpc ネットワークモードと呼び、Fargate ではこれしか選べません。

セキュリティグループの書き方は、EC2 のときとまったく同じです。

「SG から SG を許す」（第8章）書き方にしておけば、タスクの IP が入れ替わるたびに変わっても、設定を直す必要はありません。

混んできたらタスクを増やす：サービスの自動スケーリング

サービスの「望む数」は、自動で増減させることもできます。考え方は第12章の Auto Scaling とまったく同じです。

図では、CloudWatch（第17章）が CPU 85% を見つけ（札1）、ECS がタスク 3・4 を足しています（札2）。足されたタスクは、ALB に自動で登録されます。

EC2 の Auto Scaling と比べて違うのは、速さです。EC2 は OS の起動から始まるので、使えるようになるまで分単位かかることがあります。Fargate のタスクは、イメージを取ってきてプログラムを起動するだけなので、多くの場合もっと短い時間で使えるようになります（イメージが大きいと遅くなるので、イメージは小さく保ちます）。

最小の数は2以上にしておきましょう。1つだと、そのタスクが入れ替わる間は誰も応答できません。2つ以上にして、2つの AZ に分けておくのが第16章以来の基本です。

2つのロール：ECS が準備に使う鍵と、アプリが使う鍵

タスクには、IAM ロール（第3章）を2種類付けます。名前が似ていて混同しやすいので、表で分けておきます。

図の左の赤い枠がタスク実行ロール、右がタスクロールです。左は「タスクを起動するための準備」、右は「起動したアプリが仕事をするため」と覚えると区別できます。

どちらのロールも、アプリのプログラムからは一時的な鍵が自動で渡されるので、アクセスキーを作ってイメージや環境変数に入れる必要はありません（第3章）。第20章で学んだように、データベースのパスワードは Secrets Manager に置き、タスク定義の secrets の欄で「この秘密を環境変数 DB_PASSWORD として渡して」と書くだけです。

最小権限（第3章）も同じです。タスクロールには「photolog の写真用バケットに置く」だけを許し、他のバケットは触れないようにします。

新しい版の届け方：ローリングとブルー/グリーン

新しい版をどう届けるか（第19章）も、ECS が引き受けてくれます。

ローリング（既定）は、図の左のように少しずつ入れ替えるやり方です。

一度に何割まで増やしてよいか・減らしてよいかは、サービスの設定（最小ヘルシー率・最大率）で決めます。

ブルー/グリーンは、図の右のように、今の版（ブルー）を動かしたまま新しい版（グリーン）を丸ごと並べて起動し、確かめてから ALB の送り先を切り替えるやり方です。問題があれば、送り先を戻すだけで一瞬で元に戻せます。ECS は 2025年から、このブルー/グリーンをサービスの設定だけで使えるようになり、少しずつ流す量を増やすカナリアや段階的（リニア）な切り替えも選べます。

どちらの場合も、デプロイサーキットブレーカーを有効にしておくと、新しいタスクが起動に失敗し続けたときに ECS が自動で前の版に戻します。CloudWatch のアラーム（第17章）と組み合わせて戻すこともできます。

第19章の GitHub Actions からは、「イメージを build → ECR に push → タスク定義のイメージのタグを替える → サービスを更新」という流れを自動で行います。

作り方：5つの手順と、イメージを上げるコマンド

コンソールで作る場合の流れは、左の5つの手順です。

右のコマンドの $REGISTRY は、123456789012.dkr.ecr.ap-northeast-1.amazonaws.com のような ECR の住所です。

実務では、第18章の IaC で書きます。AWS CDK には「ALB 付きの Fargate サービス」をまとめて作る部品があり、次のように短く書けます。

new ecsPatterns.ApplicationLoadBalancedFargateService(this, "Web", {
  cluster,
  cpu: 512,            // 0.5 vCPU
  memoryLimitMiB: 1024,
  desiredCount: 2,
  taskImageOptions: {
    image: ecs.ContainerImage.fromEcrRepository(repo, "1.4.0"),
    containerPort: 3000,
  },
});

この1つで、ALB・ターゲットグループ・サービス・タスク定義・ロググループまでが作られます。中で何が作られるのかは、ここまでの説明で全部読めるはずです。

フォトログでは：EC2 の Auto Scaling を ECS サービスに置き換える

フォトログの構成で変わるのは、「計算する」部品だけです。

図の黄色い囲みが ECS サービスです。web タスクを2つ以上、常に動かします。

右の「縮小ジョブ」は、利用者が上げた大きな写真を小さな一覧用の写真にする処理です。Web のタスクの中でやると、その間ほかの利用者を待たせてしまいます。そこで、別のタスク定義にしておき、必要なときだけ起動する使い方ができます。ECS は、サービスとして動かし続けるだけでなく、1回だけタスクを起動して、終わったら止めることもできるのです。

ただ、「写真が上がったときだけ何かを動かす」なら、もっと向いた部品があります。それが次の第22章の Lambda と、第24章のキューです。

EC2 の構成と比べる：いつコンテナを選ぶか

第16章の EC2 構成と、この章の ECS on Fargate を並べます。

判断の問いにすると、次のようになります。

新しく Web アプリを AWS に出すなら、まずは ECS on Fargate を候補にするのが今の定番です。EC2 の知識（VPC・SG・ALB・Auto Scaling）はそのまま使えるので、ここまでの章は無駄になりません。

EKS・ECS Express Mode・App Runner はいつ選ぶか

コンテナを動かす AWS のサービスは、ECS だけではありません。

EKS は強力ですが、Kubernetes 自体に覚えることがたくさんあり、クラスター1つごとに時間単位の料金もかかります。「Kubernetes を使う理由」がはっきりあるときに選びましょう。理由がなければ ECS で十分です。

ECS Express Mode は、ECS の上で「よくある Web の形」をまとめて作ってくれる入口です。https://サービス名.ecs.リージョン.on.aws のような URL が発行され、証明書（第14章）の更新も任せられます。作られたものは ALB・サービス・タスク定義といった、この章で学んだ部品そのものです。

古い記事では「手軽さなら App Runner」と紹介されていることがありますが、上のとおり状況が変わっています。記事の日付に注意しましょう。

お金：何に対して払うのか

ECS そのものには料金がかかりません。 払うのは、タスクを動かす載せ台と、周りの部品の分です。

Fargate の料金は「割り当てた量」に対してかかります。タスクが暇でも、0.5 vCPU・1 GB を確保している間は払い続けます。夜中に誰も使っていなくても、最小の数のタスクは動き続けていることを覚えておいてください。

安くする方法としては、Arm の CPU（Graviton）を選ぶ、止まっても困らない処理に Fargate Spot（空いている能力を割安で使う代わりに、途中で止められることがある）を使う、Savings Plans（第4章）を使う、などがあります。単価はリージョンで違うので、Pricing Calculator（第4章）で試算し、料金ページで確認しましょう。

よくある落とし穴

コンテナを始めたばかりのころに、よく起きる事故をまとめます。

どれも、第16〜20章で学んだこと（ステートレス・秘密の管理・NAT・監視）と地続きの事故です。コンテナになっても、構成を考える原則は変わりません。

片付け：作った順の逆に消す

練習で作ったものは、次の順で消します。

ほかに、NAT ゲートウェイや VPC エンドポイントを作った場合は、それも忘れずに消します（第7章）。タスク定義は、登録を解除しておけば料金はかかりません。

普段の運用では、ECR のライフサイクルルールを必ず設定しておきましょう。CI が毎日イメージを push していると、古いイメージの保存料が少しずつ積もります。「最新の10個だけ残す」「タグの無いイメージは1日で消す」のように書いておけば、自動で片付きます。

第18章の IaC で作っていれば、スタックを消すだけで全部が消えます。手作業で作ったものほど、消し忘れが出ます。