Containers

カテゴリ概要

Azure のコンテナサービスは、マネージド Kubernetes の AKS を中心に、サーバーレスコンテナの Container Instances（ACI）、アプリケーション指向の Container Apps など複数の選択肢を提供している。AWS との最大の違いは、Azure に ECS（Elastic Container Service）相当の独自コンテナオーケストレーターが存在しない点である。Azure ではコンテナワークロードの選択肢は「Kubernetes ベース（AKS）」か「サーバーレス / PaaS（Container Apps / ACI）」の二択となり、AWS のように ECS か EKS かという選択は発生しない。

サービスマッピング一覧

主要サービス詳細

AKS / Azure Kubernetes Service（AWS: EKS）

Azure が提供するマネージド Kubernetes サービスで、EKS と同等の位置づけ。

AWS エンジニアが知っておくべき違い:

• コントロールプレーンが無料 — AKS 最大の差別化ポイント。EKS ではクラスターごとに $0.10/時間（約 $73/月）のコントロールプレーン料金が発生するが、AKS ではコントロールプレーンの料金が無料。課金はワーカーノードの VM 料金のみ。開発・検証用クラスターを気軽に作成できる
• Azure に ECS 相当は存在しない — AWS では「ECS（AWS 独自のオーケストレーター）か EKS（Kubernetes）か」という選択肢があるが、Azure ではマネージド Kubernetes は AKS 一択。このため、Azure でのコンテナオーケストレーションは Kubernetes のスキルが前提となる
• Azure CNI と kubenet の 2 つのネットワークモデル — Azure CNI は Pod に VNet の IP アドレスを直接割り当て、kubenet は Pod にノード内部の IP を割り当てる。AWS の VPC CNI プラグインに相当するのは Azure CNI だが、IP アドレスの消費が大きいため、Azure CNI Overlay モードの利用が推奨されている
• Microsoft Entra ID との統合が強力 — クラスターの認証に Entra ID を統合でき、Azure RBAC で Kubernetes リソースへのアクセス制御が可能。AWS では IAM と Kubernetes RBAC のマッピングに aws-auth ConfigMap や EKS Access Entry を使用するが、Azure ではより直接的な統合が提供されている
• AKS Automatic（自動モード） — ノードプールの管理、スケーリング、セキュリティ設定などを Azure が自動管理するモード。EKS Auto Mode に相当する機能で、Kubernetes の運用負荷を大幅に削減できる

Azure Container Instances / ACI（AWS: Fargate 単体利用に近い）

コンテナイメージを指定するだけで、VM やオーケストレーターを意識せずにコンテナを即時実行できるサーバーレスサービス。

AWS エンジニアが知っておくべき違い:

• 単体でコンテナを実行できる — AWS の Fargate は ECS または EKS のバックエンドとして使用するが、ACI はオーケストレーターなしで単体のコンテナ（またはコンテナグループ）を直接実行できる。「コンテナを 1 つだけすぐに動かしたい」というユースケースに最適
• コンテナグループという概念 — ACI では複数のコンテナを 1 つのコンテナグループとしてまとめ、同一ホスト上で実行できる。Kubernetes の Pod に近い概念で、サイドカーパターンなどに対応可能
• AKS の仮想ノードとして連携可能 — AKS の Virtual Kubelet を通じて ACI をバースト先として利用できる。通常はAKS のノードプールで処理し、急激な負荷増加時に ACI にオーバーフローさせる構成が可能。EKS + Fargate プロファイルに近い使い方だが、よりバースト的な利用に適している
• 長時間実行には向かない — ACI は一時的なワークロード、バッチ処理、CI/CD パイプラインでの利用を想定しており、常時稼働のサービスには Container Apps や AKS が推奨される

Azure Container Apps（AWS: App Runner / Fargate に近い）

コンテナ化されたアプリケーションをサーバーレスで実行するための PaaS サービスで、インフラ管理を最小化しつつコンテナワークロードを運用できる。

AWS エンジニアが知っておくべき違い:

• 内部的に Kubernetes（AKS）ベースだが、Kubernetes の知識は不要 — Container Apps は内部で AKS を使用しているが、ユーザーは Kubernetes を意識する必要がない。App Runner のシンプルさと Fargate + ECS の柔軟性を兼ね備えた位置づけ
• Dapr（Distributed Application Runtime）が統合されている — マイクロサービス間の通信、状態管理、Pub/Sub、バインディングなどのビルディングブロックを、Dapr のサイドカーとして自動注入できる。AWS では同等の機能を実現するには App Mesh や自前のサービスメッシュ構成が必要
• リビジョン管理とトラフィック分割が標準機能 — デプロイごとにリビジョンが作成され、複数リビジョン間でトラフィックを重み付けで分割できる。カナリアデプロイやブルー/グリーンデプロイが追加サービスなしで実現可能。AWS では CodeDeploy + ALB や App Mesh での設定が必要
• KEDA ベースのスケーリング — HTTP リクエスト数、キューの長さ、CPU 使用率など多様なメトリクスに基づく自動スケーリングが宣言的に定義可能。0 インスタンスへのスケールイン（ゼロスケール）にも対応しており、トラフィックがないときはコストがゼロになる
• Container Apps Environment でマルチアプリ管理 — 複数の Container Apps を同一の Environment（共有ネットワーク + ログ設定）にデプロイでき、アプリ間通信はサービスディスカバリで自動解決される

Azure Container Registry / ACR（AWS: ECR）

コンテナイメージを保存・管理するプライベートレジストリサービスで、ECR と同等の位置づけ。

AWS エンジニアが知っておくべき違い:

• Geo レプリケーションが標準サポート — Premium SKU で複数リージョンにイメージを自動レプリケーションできる。ECR ではクロスリージョンレプリケーションを個別に設定する必要がある
• ACR Tasks でイメージのビルドも可能 — レジストリ側でコンテナイメージのビルドを実行できる。ソースコードの変更やベースイメージの更新をトリガーに自動ビルドが可能で、簡易的な CI パイプラインを ACR 内で完結できる。ECR にはこの機能はなく、CodeBuild 等の別サービスが必要
• SKU による機能の段階分け — Basic、Standard、Premium の 3 つの SKU があり、Premium ではGeo レプリケーション、プライベートリンク、カスタマーマネージドキーなどの上位機能が利用可能
• AKS との統合が簡潔 — AKS からACR へのアクセスは az aks update --attach-acr コマンドで簡単に設定可能。EKS + ECR の場合は IAM ロールの設定が必要

Azure Linux / Mariner（AWS: Bottlerocket）

Microsoft が開発したコンテナ実行に特化した軽量 Linux ディストリビューション。

AWS エンジニアが知っておくべき違い:

• AKS ノードプールの OS として選択可能 — AKS のワーカーノードに Azure Linux を指定することで、コンテナ実行に最適化された軽量 OS が利用できる。Bottlerocket が EKS のノードで利用可能なのと同様の位置づけ
• CBL-Mariner ベース — Microsoft 内部で広く使用されている CBL-Mariner をベースとしており、セキュリティ更新が迅速に提供される
• パッケージが最小限 — コンテナ実行に必要なコンポーネントのみを含み、攻撃対象面（Attack Surface）を最小化している。Bottlerocket と同様の設計思想

AWS との主要な違い

ECS 相当のサービスが存在しない

AWS のコンテナ戦略は「ECS（AWS 独自のオーケストレーター）」と「EKS（Kubernetes）」の二本柱だが、Azure には ECS に相当する独自のコンテナオーケストレーターが存在しない。Azure でコンテナオーケストレーションが必要な場合は AKS（Kubernetes）が唯一の選択肢となる。Kubernetes の学習コストが懸念される場合は、Container Apps（内部的に AKS ベースだが Kubernetes を隠蔽）が代替として推奨される。AWS で「ECS の手軽さは欲しいが EKS ほどの複雑さは不要」というユースケースでは、Azure では Container Apps が最も近い選択肢となる。

コントロールプレーンのコストモデル

EKS ではクラスターごとにコントロールプレーン料金（$0.10/時間、約 $73/月）が発生するため、小規模な開発・検証用クラスターでもコストが嵩む。AKS ではコントロールプレーンが無料のため、環境ごとにクラスターを分離しやすく、マルチクラスター構成のコストハードルが低い。ただし、AKS の Uptime SLA（99.95% / 99.99%）を有効にする場合は追加料金が発生する点に注意。

Container Apps という独自のレイヤー

AWS には App Runner があるが、Container Apps はそれよりも高機能な位置づけにある。Dapr 統合によるマイクロサービスのビルディングブロック、KEDA ベースの柔軟なスケーリング、リビジョン管理によるトラフィック分割など、App Runner にはない機能を多数備えている。「Kubernetes の運用負荷を避けたいが、Fargate + ECS 程度の柔軟性は欲しい」という要件に対して、Container Apps は有力な選択肢となる。

サービス選定の指針