AKS と Azure Container Apps、結局どっちを使うべきか？使い分けを整理してみた
こんにちは、久しぶりの投稿です
最近は、いままでと全く違う仕事をする事になり、覚えることも増えてきたりしている事と、PhysicalAIやAgenticAIの社会実装に向けての実証実験や課題解決など、バタバタしていることもあり、何よりも念願のPS5proとドグマ2をゲットして眠れない日々も続いていたりと忙しい毎日です
はじめに
「Azure Container Apps（ACA）が出たし、AKS からそっちに移行しよう」という声を聞くことが増えてきました。
確かに ACA はマネージド度が高くて魅力的なサービスです。ただ、AKS と ACA は上位互換・下位互換の関係にあるわけではなく、そもそも設計思想と得意領域が異なります。
この記事では、両者のアーキテクチャ上の違いを整理しながら、「どちらを選ぶべきか」の判断軸を提示します。
TL;DR
| 判断基準 | AKS | Azure Container Apps |
|---|---|---|
| ワークロードの複雑さ | 複雑・多様 | シンプル・均質 |
| インフラ制御の必要性 | 高い | 低くてよい |
| チームの Kubernetes スキル | あり | なくてもよい |
| 既存の Helm / manifest 資産 | 流用したい | ゼロから |
| スケール戦略 | 細かく制御したい | 自動任せでよい |
| 大規模既存システムからの移行 | 現状維持推奨 | 原則非推奨 |
AKS とは
Azure Kubernetes Service は、Kubernetes クラスタをマネージドで提供するサービスです。コントロールプレーンの管理は Azure が担いますが、ノードプールの構成・ネットワークポリシー・Ingress・DaemonSet など、Kubernetes の概念はそのまま使えます。
AKS の主な特徴
- フルマネージドのコントロールプレーン（無償）
- ノードプールの柔軟な構成（CPU/GPU/スポット混在など）
- 既存の Helm Chart・Kubernetes manifest がそのまま動く
- Calico, Azure CNI など豊富なネットワーク選択肢
- DaemonSet, StatefulSet, Job, CronJob すべて対応
- AKS Automatic モードにより運用負荷を大幅に削減可能（2024年〜）
AKS アーキテクチャ概要
ポイント：Control Plane は Azure が管理しますが、ノードプール・ネットワーク・ワークロード種別はすべて利用者が設計・制御します。
Azure Container Apps とは
Azure Container Apps（ACA）は、Kubernetes を意識させないコンテナ実行環境です。内部的には Kubernetes + KEDA + Envoy + Dapr を組み合わせた基盤の上で動いていますが、利用者からはその詳細が隠蔽されています。
ACA の主な特徴
- Kubernetes の知識不要で使える
- KEDA ベースのオートスケール（0スケール含む）がデフォルト
- HTTP/イベント駆動のワークロードにフィット
- Dapr サイドカーのネイティブサポート
- リビジョン管理・A/Bトラフィック分割が簡単
- Consumption プランにより、アイドル時はほぼ無料
ACA アーキテクチャ概要
ポイント：利用者が定義するのは Container App の設定とスケールルールだけです。Kubernetes・Ingress・スケーラーはすべて Azure が管理する内部レイヤーに隠蔽されており、直接触ることはできません。
何が違うのか：技術的な比較
コントロールの粒度
AKS では Kubernetes の全機能を使えますが、ACA では 抽象化レイヤーによって操作できる範囲が制限されています。
| 機能 | AKS | ACA |
|---|---|---|
| DaemonSet | ✅ | ❌ |
| StatefulSet | ✅ | ❌（Volumes は使えるが StatefulSet の概念なし） |
| カスタム Ingress Controller | ✅ | ❌（内部の Envoy は直接触れない） |
| NetworkPolicy | ✅ | ❌ |
| Node Affinity / Taint | ✅ | ❌ |
| GPU ノード | ✅ | 限定的（Consumption Dedicated のみ） |
| Helm | ✅ | ❌ |
スケーリング
ACA の強みはスケールゼロを含む自動スケールです。ただし、コールドスタートが発生するため、常時レスポンスを求められる用途には注意が必要です。
AKS では KEDA を自分でインストールすることで同等のイベントドリブンスケールを実現しつつ、最小レプリカ数を 1 以上に保つなど細かい制御も可能です。
ネットワーク
AKS では VNet インジェクション・プライベートクラスタ・Calico ポリシーなど、エンタープライズ要件に応じた詳細な構成が可能です。
ACA も VNet 統合はサポートしていますが、ネットワークポリシーの細粒度制御はできません。厳格なセキュリティ要件がある本番環境では、この差が大きく響きます。
ACA が本領を発揮するシナリオ
- 新規の軽量マイクロサービス：チームに Kubernetes 知識がなく、シンプルに HTTP サービスを動かしたい
- イベントドリブンなバックエンド処理：キューメッセージ処理、Webhook レシーバー、バッチジョブなど
- 開発・検証環境：スケールゼロでコストを最小化したい
- サイドカーパターンを手軽に使いたい：Dapr の採用を検討しているチーム
AKS を継続すべきシナリオ
- 大規模・商用・既存稼働中のシステム：安定稼働している基盤に手を入れるコストとリスクが純粋にマイナス
- 複雑なネットワーク要件：Network Policy、カスタム Ingress、マルチテナント分離など
- 既存の Helm Chart・GitOps 資産がある：Argo CD や Flux との組み合わせで成熟した運用基盤がある
- DaemonSet が必要なワークロード：ログエージェント、セキュリティエージェント、GPU ノード活用など
- ステートフルなワークロードが含まれる：データベース、キャッシュ、メッセージブローカーなど
よくある誤解
「ACA のほうが安い」
ワークロードが常時稼働している大規模な本番環境では、Consumption プランの従量課金が逆に割高になることがあります。AKS の Reserved Instance 活用や Spot ノードプールのほうがコスト効率が高いケースは多々あります。
「ACA に移行すれば運用が楽になる」
既存の AKS 環境が安定しているなら、移行作業そのものの工数・リスク・検証コストのほうがはるかに大きいです。AKS Automatic モード（2024年 GA）や Node Auto-Provisioning によって、AKS 自体の運用負荷もかなり下がっています。
「Kubernetes をやめれば属人化が解消される」
Kubernetes の属人化が問題なら、解決策は プラットフォームエンジニアリングの整備・Internal Developer Platform の構築であって、サービス乗り換えではありません。
移行を検討するとしたら
どうしても移行・統合を検討するなら、以下のアプローチが現実的です。
- 新規サービスだけ ACA で立てる：既存を動かさず、新規ワークロードから段階的に ACA を採用する
- Strangler Fig パターン：既存 AKS の一部機能を切り出して ACA へ。全量一括移行は避ける
- PoC でコールドスタート・ネットワーク要件・コストを必ず検証：机上の検討だけで進めない
選択の判断フロー
どちらを選ぶか迷ったときの判断軸をフローチャートで整理します。
まとめ
ACA は「AKS の進化版」ではなく、ターゲットが異なるサービスです。
- シンプルなワークロード・新規開発 → ACA
- 複雑な要件・大規模既存システム → AKS
- 大規模既存 AKS からの ACA 移行 → 費用対効果を冷静に試算してから判断
特に、すでに大規模に商用稼働している AKS 環境を「流行っているから」「マネージドだから」という理由だけで移行するのは、技術的なリスクに見合わないケースがほとんどです。
アーキテクチャの判断は、流行ではなく要件とトレードオフの分析から始めましょう。
Discussion