【入門編】PulumiでAWS App RunnerとECS Fargateを使い分ける判断基準:コストと運用のトレードオフをコードから徹底解説 – インフラ構成管理(IaC)活用バイブル

こんにちは!クラウドインフラの世界へようこそ。
日々、膨大なサーバーやコンテナの管理に頭を悩ませていませんか?「これをマスターすれば、毎日のインフラ作業が劇的に楽になりますよ」——今日は、そんな未来を約束するモダンなインフラ構築の扉を一緒に叩いていきましょう。

私たちがクラウド上でコンテナを動かすとき、必ず直面する究極の二大巨頭があります。それが AWS App Runner と Amazon ECS (Fargate) です。

「どっちを使えばいいの?」
「コストと運用のバランスはどう見極めるべき?」

今回は、次世代のインフラ構築ツール「Pulumi」を使いこなしながら、この永遠の問いにコードの観点から鮮やかな答えを出してみましょう。初心者の方にもスッと腹落ちするように、基礎の基礎から丁寧に、かつ現場のプロが唸るリアルな知見を交えて解説していきますね。

—

1. App Runner vs ECS Fargate:コードから見る「手間」と「自由度」

まずは、この2つのサービスの思想の違いを、インフラエンジニアの視点でスパッと整理しておきましょう。

  • AWS App Runner:
  • 思想: 「面倒なことは全部AWSに任せて、コードをデプロイすることだけに集中しよう」
  • 特徴: ロードバランサー、HTTPS証明書、オートスケーリング、CI/CDパイプラインの連携が、文字通り「数行の設定」で爆誕します。
  • Amazon ECS (Fargate):
  • 思想: 「インフラストラクチャの細部まで完全にコントロールし、複雑なマイクロサービスを協調させよう」
  • 特徴: Vpc, Subnet, Security Group, Target Group, ECS Cluster, Task Definition, Service… と、組み立てるパーツが多い分、無限のカスタマイズ性を誇ります。

なぜ「Pulumi」を使うのか?

Terraformでもおなじみですが、Pulumiの最大のエグい(最高な)強みは、TypeScriptやPythonといった「本物のプログラミング言語」でインフラを書けることです。
JSONやYAML、独自のHCLにイライラさせられる時代は終わりました。変数が使え、関数が使え、IDEの強力な補完が効く。この体験を知ってしまうと、もう昔には戻れなくなりますよ。

—

2. トラフィック量とコストで選ぶ!「正しい判断基準」

インフラ選定の基準は、突き詰めると「お金(コスト)」と「運用の手抜き度(Cognitive Load:認知的負荷)」のトレードオフです。

1. App Runnerを選ぶべきケース:

  • トラフィックが不規則、または夜間などはアクセスがほぼゼロになる。
  • 「インスタンスが0台(アイドル時)」のコストを極限まで削りたい。
  • インフラの維持管理に割く人手がない(または開発に集中したい)。
  • ※App Runnerはリクエストがない時に「インスタンスを0にスケールダウン(正確には課金停止に近い状態)」できるため、閑散期のコストが劇的に安くなります。

2. ECS Fargateを選ぶべきケース:

  • 24時間365日、一定のトラフィックがあり、常時起動が前提である。
  • 複数のコンテナ(サイドカーなど)を密結合させて1つのタスクとして動かしたい。
  • 複雑なVPCルーティングや、社内プライベートネットワーク(VPC Endpoint)との統合が必要。

—

3. 環境構築と「Hello World」:Pulumi事始め

百聞は一見に如かず。実際に手を動かして、Pulumiのセットアップから始めましょう。今回は、汎用的で書きやすい TypeScript を使用します。

ステップ1: ツールのインストール

お使いの環境(MacならHomebrewなど)で、Pulumi CLIとAWS CLIをサクッとインストールします。

Pulumiのインストール
brew install pulumi/tap/pulumi

動作確認
pulumi version

ステップ2: プロジェクトの初期化

適当なディレクトリを作り、Pulumiのプロジェクトを立ち上げます。

mkdir pulumi-container-lab && cd pulumi-container-lab
pulumi new aws-typescript

途中でプロジェクト名やパスワード(スタンプ用)を聞かれますが、基本はEnter連打でOKです。AWSの認証情報(`aws configure` など)が事前に通っていることを確認しておいてくださいね。

—

4. 実装コード例:App RunnerとECS Fargateの構築

お待たせしました。ここからが本番です。
今回は「App Runnerでサクッと動かすパターン」と「ECS Fargateで堅牢に動かすパターン」の心臓部を、Pulumiのコードで直感的に比較します。

パターンA: App Runnerで爆速リリース(`index.ts` のイメージ)

App Runnerがいかに「コードの記述量が少ないか」に驚いてください。

import as pulumi from “@pulumi/pulumi”;
import as aws from “@pulumi/aws”;

// 1. App Runnerのサービスを定義
// たったこれだけで、LBもSSLもオートスケーリングも全部ラップして勝手にやってくれます。
const appRunnerService = new aws.apprunner.Service(“my-fast-service”, {
serviceName: “hello-apprunner”,
sourceConfiguration: {
// パブリックなECRイメージを指定
imageRepository: {
imageIdentifier: “public.ecr.aws/aws-containers/hello-app-runner:latest”,
imageRepositoryType: “ECR_PUBLIC”,
imageConfiguration: {
port: “8000”,
},
},
autoDeploymentsEnabled: true, // ソース更新を自動検知
},
// インスタンスのスペック(CPU / Memory)を明示的に指定
instanceConfiguration: {
cpu: “1024”, // 1 vCPU
memory: “2048”, // 2 GB
},
});

// 外の世界へ公開されるURLを出力
export const appRunnerUrl = appRunnerService.serviceUrl;

これだけです。 たったこれだけのコードで、AWSのマネージドなオートスケーリング付きWebアプリ環境が手に入ります。すごすぎませんか?

—

パターンB: ECS Fargateで堅牢な基盤構築

一方で、ECS Fargateは「守りを固める」プロ仕様です。VPCの準備からタスク定義まで、エンジニアの意図を100%コードに反映させます。

import as pulumi from “@pulumi/pulumi”;
import as aws from “@pulumi/aws”;
import as awsx from “@pulumi/awsx”; // 複雑な構成をエレガントに書けるPulumi公式ライブラリ

// 1. 専用のセキュアなVPCを作成(パブリック/プライベートサブネットを自動生成)
const vpc = new awsx.ec2.Vpc(“custom-vpc”, {
numberOfAvailabilityZones: 2,
});

// 2. ECSクラスターの作成
const cluster = new aws.ecs.Cluster(“my-cluster”);

// 3. Fargate用ロードバランサー付きサービスの定義(AWSXの強力な抽象化を活用)
const fargateService = new awsx.ecs.FargateService(“my-fargate-service”, {
cluster: cluster.arn,
vpcSubnetIds: vpc.privateSubnetIds, // 安全なプライベートサブネットに配置
taskDefinitionArgs: {
container: {
image: “nginx:latest”, // 任意のコンテナイメージ
cpu: 256,
memory: 512,
portMappings: [{ containerPort: 80 }],
},
},
desiredCount: 2, // 冗長化のために常時2タスクを維持
});

// アクセス用のロードバランサーURLを出力
export const fargateUrl = fargateService.service.loadBalancer?.apply(lb => lb.dnsName);

App Runnerに比べて、VPCやサブネット、ネットワークの疎通といった「インフラの解像度」が高いことが分かりますよね。ミッションクリティカルなシステムや、社内ニッチな連携が必要な場合は、迷わずこちらを選びます。

—

5. デプロイと動作確認:魔法のコマンド

コードが書けたら、いよいよAWSへ反映させます。Pulumiの真骨頂を見る瞬間です。

pulumi up

画面に「これから何が作成されるか(プレビュー)」が美しく表示されます。内容を確認して `yes` を選ぶと、魔法のようにクラウド上にリソースが組み上がっていきます。

処理が終わると、先ほどコード内で `export` したURL(`appRunnerUrl` や `fargateUrl`)がコンソールにピタッと表示されます。そのURLをブラウザに叩いて、おなじみの「Welcome to nginx!」やサンプルアプリの画面が表示された瞬間、最高に痺れるエンジニアタイムの訪れです。

—

まとめ:賢いエンジニアは「適材適所」をコードで制す

今回は、App RunnerとECS Fargateの選定基準を、Pulumiのコード設計の視点から紐解いてみました。

  • スピードとコストの最適化(閑散期ゼロ円の魅力) を取るなら $\rightarrow$ App Runner
  • コントロール性とエンタープライズな拡張性 を取るなら $\rightarrow$ ECS Fargate

そして、どちらを選ぶにしても、Pulumiを使えばそのインフラ構成の意図がコードとして美しく、強固に残り続けます。

「これをマスターすれば、毎日の作業が劇的に楽になりますよ」。
今日のこの知識を武器に、ぜひあなたの次のプロジェクトでPulumiとコンテナ基盤の使い分けを実践してみてください。インフラを書く楽しさが、きっと何倍にも膨らむはずです。

それでは、素晴らしいクラウドライフを!

タイトルとURLをコピーしました