「AWS ECS で構築したい」というご相談が増えています。ECS (Elastic Container Service) は Fargate と EC2 launch type の 2 系統に加え、タスク定義・デプロイ方式・監視に落とし穴があり、初回構築で判断ミスをすると本番直後に事故ります。
本記事は、AWS ECS を候補にしている情シス・エンジニア向けに、EKS との違い、Fargate と EC2 の使い分け、タスク定義の勘所、本番運用の 6 パターン、CI/CD 連携までを整理した入門ガイドです。「構築を任せたい」ときの判断軸も最後に扱います。
結論: ECS を選ぶ判断軸は「Fargate / EC2」より前にある
先に結論を書きます。ECS の設計で最初につまずくのは Fargate と EC2 launch type の比較ではなく、そもそもコンテナ化が要る用途か、EKS ではなく ECS を選ぶ根拠があるかの 2 点です。
「AWS EKS 構築外注」を検討すべきか、AWS App Runner 構築依頼や AWS Lambda 開発委託で足りるのか、といった前段の判断軸のほうが本番運用の成否を左右します。順番を逆にすると作り直しになります。
注意
EKS と比較して ECS を選ぶ前に、まず「そもそもコンテナが要るか」を握ってください。単一の Web アプリなら App Runner や Lambda で足りるケースが多く、コンテナ化が目的化すると保守負担だけが増えます。
AWS ECS とは ─ EKS との違い・使い分け
AWS ECS (Elastic Container Service) は、Docker コンテナを AWS 上で動かすためのオーケストレーションサービスです。Kubernetes を採用する EKS と役割は近いですが、内部の作法は異なります。EKS が Kubernetes 標準 API に沿うのに対し、ECS は AWS 独自のタスク定義・サービス定義で動きます。
ECS と EKS のどちらを選ぶかは、Kubernetes 運用の知見が社内にあるか、マルチクラウド前提かで概ね決まります。「AWS Kubernetes 構築ベンダー」に依頼して EKS を選ぶ会社もありますが、社内に運用経験者がいなければ、ECS のほうが日常運用は軽くなります。
| 観点 | ECS | EKS |
|---|---|---|
| API | AWS 独自 (タスク定義) | Kubernetes 標準 API |
| 学習コスト | 低〜中 (AWS 経験があれば速い) | 中〜高 (Kubernetes 前提) |
| マルチクラウド | 事実上不可 | 可 (同じマニフェストで動く) |
| 運用人材の確保 | AWS エンジニアで足りる | Kubernetes 運用経験者が要る |
| コスト (最小) | Fargate 従量課金 | EKS クラスタ料金 + Fargate / EC2 |
| エコシステム | AWS サービス連携が濃い | OSS の Kubernetes 資産が使える |
ECS を選んだあとに待っているのが、Fargate と EC2 launch type の使い分けです。ここは次章で細かく見ていきます。
Fargate と EC2 launch type ─ どちらを選ぶか
Fargate と EC2 launch type の使い分けは、ECS の設計で最も相談を受ける論点です。「Fargate はサーバーレスだから楽」と言い切る記事もありますが、実運用では負荷特性と費用の読みやすさで判断が変わります。
Fargate が有利になる条件
Fargate は、EC2 のホスト管理を AWS 側に任せられるのが最大の利点です。OS パッチや Auto Scaling Group のメンテナンスから解放されるので、少人数の情シス体制で回すなら第一候補になります。バッチ処理・低頻度の Web API・PoC の高速立ち上げも Fargate が向きます。
「AWS Fargate 構築運用代行」の相談で多いのは、負荷が読めないうちは Fargate で立ち上げ、傾向が見えてから EC2 への切り替えを検討する段階戦略です。
EC2 launch type が有利になる条件
一方、EC2 launch type は常時稼働のワークロードで単価が下がります。Reserved Instance や Compute Savings Plans を組み合わせると、Fargate に比べて 30〜40% 安くなるケースがあります。GPU が必要な機械学習や、コンテナ密度を上げて絞り込みたい要件でも EC2 が選ばれます。「AWS EC2 構築代行相場」を比較する場合は、単価だけでなく運用工数まで加味した総額で判断してください。
| 判断軸 | Fargate | EC2 launch type |
|---|---|---|
| 運用負荷 | 低 (ホスト管理不要) | 中〜高 (OS パッチ・スケール管理) |
| 単価 (常時稼働) | 高い | 割引契約で下げやすい |
| 起動速度 | 数十秒 | 数分 (EC2 起動を含む) |
| GPU / 特殊ハード | 不可 | 可 |
| コンテナ密度 | 1 タスク 1 マイクロ VM | 1 ホストに複数タスク集約 |
FIXIT結局、Fargate と EC2 はどっちを選べばいいの？
Hayate使い分けの目安は、常時稼働か・チームに AWS 運用の余力があるかの 2 点です。
Dodai自分は、負荷が読めない段階では Fargate から始めます。運用が先に事故ります。
FIXITHayateタスク定義の互換性は高いので、切り替えは軽いです。判断を先送りしなくて大丈夫です。
Dodai先送りした分だけ設計の負債は膨らみます。段階戦略で始めます。
タスク定義の基本と落とし穴 (メモリ / CPU / 起動失敗)
タスク定義は ECS の設計図に相当します。「起動失敗した」「本番で落ちた」の大半は、タスク定義の記述ミスに集中します。
メモリ / CPU 設定の勘所
Fargate は指定した CPU / メモリで課金が決まる従量課金です。過剰に確保すると単価が跳ね上がり、絞りすぎると OOM (Out of Memory) で強制終了します。開発環境で通ったからと本番に持ち込むと、実データ量で数分後に落ちる、というのが典型です。
負荷テストは本番前に必須です。想定ピーク負荷の 1.5〜2 倍で 30 分回し、メモリの頭打ちを確認、CPU は 70% を超えないラインで初期値を置くのが安全です。ここを省くと Auto Scaling の閾値も机上の値になります。
起動失敗の典型パターン
タスク起動失敗の代表例は 3 つです。1 つ目は ECR (Elastic Container Registry) の権限不足で pull できないケース。2 つ目は Secrets Manager や Parameter Store の環境変数注入で権限が足りず即死するケース。3 つ目はヘルスチェック URL が起動時間に間に合わず ALB がタスクを殺し続けるケースです。
コツ
本番投入前のチェックリスト。1) タスク実行ロール (task execution role) に ECR /
Secrets Manager の権限が付いているか、2) ヘルスチェックの初期猶予
(healthCheckGracePeriodSeconds) が起動時間を上回っているか、3) CloudWatch
Logs の出力先が設定されているか、4) 停止時の SIGTERM
ハンドリングをアプリ側で実装しているか。この 4
点を握れば、初回本番投入直後の事故はほぼ防げます。
本番運用に耐える 6 構成パターン
本番運用に耐える ECS 構成には、実務でよく採用される 6 パターンがあります。すべて一度に組む必要はなく、重要度と運用体制に合わせて段階的に足すのが現実的です。
1. Blue/Green デプロイ
新旧バージョンを並行稼働させ、ALB のリスナールールで一気に切り替えます。ロールバックが数秒で済むため、金融・EC の高可用性ワークロードに向きます。CodeDeploy と組むと自動化が楽です。
2. Rolling Update デプロイ
タスクを 1 台ずつ入れ替える標準方式です。設定がシンプルで、社内システムや低優先度のワークロードで採用されます。ロールバックは Blue/Green より遅くなります。
3. Canary リリース
一部トラフィックだけを新バージョンに流し、指標を確認してから全量切り替える方式です。App Mesh や ALB のウェイテッドターゲットグループで実現します。「AWS マイクロサービス開発会社」で複数サービスを並列運用するなら、Canary を標準にすると事故が減ります。
4. Auto Scaling
CPU / メモリ / カスタムメトリクスに応じてタスク数を増減させます。急な負荷増に耐えるよう、下限を業務時間帯に合わせるのが実務のコツです。EC2 launch type ならクラスタ Auto Scaling も併用します。
5. ログ収集 (CloudWatch / OpenSearch)
CloudWatch Logs で集めるのが基本ですが、検索性を高めるなら OpenSearch へ流します。監査要件が厳しい業種では S3 への長期保管も組み込みます。
6. Monitoring (CloudWatch / Datadog)
CPU / メモリ / タスク数の 3 指標を最低限のダッシュボードにします。SLO を握れるなら、レイテンシ p95 とエラー率も足します。アラート閾値は数日試運転してから本番投入するのが安全です。
周辺構成もセットで押さえます。データ層は「AWS RDS 構築移行代行」「AWS Aurora 移行構築会社」で RDBMS を、「AWS DynamoDB 開発構築」でキー・バリュー用途を切り出します。ネットワーク側は「AWS VPC VPN 構築会社」で拠点接続、CDN は「AWS CloudFront 構築依頼」で前段に置きます。組織拡大を見据えるなら「AWS Control Tower 導入構築」でマルチアカウント基盤を作り、「AWS IAM 組織設計委託」で権限分離を整えると稼働後の膨張を防げます。トポロジは「AWS ネットワーク設計外注」で扱う現場もあります。
CI/CD 連携 (CodePipeline / GitHub Actions パターン)
ECS の継続的デプロイは、主に 2 パターンで組みます。AWS 内で完結させる CodePipeline + CodeBuild + CodeDeploy の座組と、GitHub 側で完結させる GitHub Actions + OIDC の座組です。
AWS 完結型のメリットは、権限管理を IAM に閉じられる点と、Blue/Green を CodeDeploy が肩代わりする点です。「AWS CI CD パイプライン構築」の一次実装はこちらが速く、AWS DevOps 導入支援会社の得意領域でもあります。
開発チームが GitHub 中心の場合は、GitHub Actions から OIDC で一時クレデンシャルを取り、aws ecs update-service でデプロイする形が扱いやすくなります。Secrets を GitHub に置かなくて済み、監査対応もクリアしやすくなります。
補足
どちらのパターンでも、ECR への push は GitHub Actions で行い、ECS のデプロイだけを CodeDeploy に任せるハイブリッド構成もよく採用されます。CI/CD は一枚岩にせず、責務ごとに切り分けたほうが後の保守が軽くなります。
Infrastructure as Code は初期構築の時点から入れておくのが安全です。「AWS Terraform 開発 委託」や「AWS CDK 開発 委託」の座組でモジュール化し、CloudFormation で自動化する現場もあります。後から入れると本番と差分が発生し、再現性が崩れます。「AWS インフラ アズ コード 構築」は最初の設計方針に含めてください。
コンテナ・サーバーレスの費用の勘どころ
ECS の費用は「Fargate / EC2 の稼働料金 + データ転送 + 監視 + ログ保管」で構成されます。Fargate は割り当てた vCPU とメモリの量に対して秒単位で課金される仕組みで、CPU を絞ってメモリだけ多めに割り当てる調整で単価が下がることがあります。
「AWS 開発費用相場」を相談されるとき、議論は Fargate の単価に集中しがちですが、実運用では CloudWatch Logs と NAT Gateway の転送量が想定外に膨らみます。ログの保持期間と外部 API のトラフィック量を先に見積もっておくと、月次費用の予測精度が上がります。
「AWS 運用保守費用相場」の観点では、Reserved Instance や Compute Savings Plans で常時稼働の EC2 launch type の単価を 30〜40% 下げる方法があります。契約期間が縛られるので、負荷特性が読めない段階で契約するのは避けます。「AWS 構築代行料金」を比較するときも、初期構築だけでなく 12 ヶ月分の運用費まで並べて総額で判断してください。
「構築代行」を検討するときの判断軸
自社体制だけでの構築が厳しい場合、「AWS ECS 導入構築代行」を外部に依頼する選択肢が出てきます。ただし要件定義前に依頼すると、業者主導で使わない機能まで組まれるリスクがあります。
依頼のタイミングは、社内で「Fargate と EC2 の使い分け」「デプロイ方式」「監視の閾値」の 3 点について仮の答えが出た段階が現実的です。この段階なら「AWS 構築代行会社」「AWS 開発パートナー 選定」の候補と会話しながら、設計方針の妥当性検証と実装の分担が同時に進みます。
FIXITDodaiFIXITDodai100 点は要りません。方針の当たりがあれば業者側で埋められます。
選定の軸は、「AWS 構築 ベンダー 比較」で「AWS 導入支援 会社」の実績を並べるだけでなく、Infrastructure as Code の運用体制を持っているか、AI 駆動開発のクリエイティブスタジオのように AI エージェントで運用の一部を自動化しているかまで踏み込むと外れが減ります。「AWS 技術力 高い 開発会社」を選ぶなら、コードレビューとテストの段取りを事前に聞きます。「AWS コンテナ 構築 会社」「AWS コンテナ 移行 開発会社」「AWS クラウド ネイティブ 開発 ベンダー」も同じ領域を指しますが、「AWS 構成 見直し 構築 会社」まで提案できる相手を選ぶと技術負債を抑えられます。「AWS 最新 技術 開発 対応 会社」を謳う候補には、実装事例と失敗事例の両方を確認してください。
FIXIT では AI 駆動開発サービス の一部として AWS ECS の設計・構築・運用引き継ぎのご相談を受け付けています。設計方針の妥当性検証だけの利用でも構いません。お問い合わせ窓口 からどうぞ。関連する論点は システム導入が失敗する 12 の兆候 でも整理しています。