Azureでコンテナを動かしたいとき、候補に挙がるのが「Azure Kubernetes Service（AKS）」です。
名前は聞いたことがあっても、
「Kubernetesって難しそう……」
「Container AppsやApp Serviceと何が違うの？」
と戸惑っている方は多いのではないでしょうか。
一言でいうと、AKSは「Kubernetesの管理をMicrosoftに任せて、自分はアプリのデプロイに集中できるサービス」です。
これまで、Kubernetesを運用しようとすると、マスターノードの構築、etcdの管理、証明書の更新など、アプリケーション以外の作業に多くの時間を取られていました。
「Kubernetesのアップグレードで休日が潰れた……」
「証明書の期限切れでクラスターが動かなくなった」
こうした「面倒なインフラ管理」から解放され、アプリケーションのデプロイに集中できるようにしてくれるのが、このAKSです。
この記事では、AKSをこれから使い始める方に向けて、押さえておくべき基本概念をどこよりもわかりやすく解説します。
AKSの階層構造を理解しよう
AKSを理解するには、まずリソースの階層構造を把握することが重要です。これらは包含関係になっています。
フリートマネージャー（任意：複数クラスターを管理）
└── クラスター（1つのKubernetes環境）
└── ノードプール（同じスペックのVMグループ）
└── ノード（VM：実際の仮想マシン）
└── Pod（コンテナの入れ物）
└── コンテナ（アプリの実体）クラスター
「1つのKubernetes環境」を表す論理的な管理単位です。例えるなら「1つの会社・組織」です。
1つのクラスターには、コントロールプレーンと複数のノードプールが含まれます。開発/ステージング/本番で別々のクラスターを作ることが多いです。
ノードプール
「どんなVMを使うか」の設定とそのグループです。例えるなら「部署」です。
同じノードプール内のノードは全て同じスペック（VMサイズ、OS）になります。「CPU用ノードプール」と「GPU用ノードプール」を分けたり、「Systemノードプール（Kubernetes内部用）」と「Userノードプール（アプリ用）」を分けたりします。
ノード
実際の仮想マシン（VM）です。例えるなら「社員のPC」です。
この上でPodが動作します。ノードのVMサイズによって、コストと性能が決まります。AKSのコストの大部分はこのノード（VM）の料金です。
Pod
コンテナを動かす「箱」であり、Kubernetesにおけるデプロイの最小単位です。例えるなら「PC上で動くアプリ」です。
Kubernetesはコンテナを直接管理せず、Podという単位で管理します。スケールもPod単位で行われます。
基本的には「1つのPodに1つのコンテナ」ですが、密接に連携するコンテナ（メインアプリ＋ログ収集など）を同じPodに入れる「サイドカーパターン」もあります。
フリートマネージャー
複数のAKSクラスターを一元管理するためのサービスです。
複数リージョンにクラスターがある場合や、大規模なエンタープライズ環境で使用します。学習段階では不要です。
コントロールプレーンとノードの役割
階層構造がわかったところで、次に「誰がどう動かすのか」を理解しましょう。
AKSのクラスターは「コントロールプレーン」と「ノード」の2つの部分で構成されています。
コントロールプレーン：司令塔
コントロールプレーンは「Kubernetesの司令塔」です。「何をどう動かすか」を決め、状態を監視・維持します。AKSでは、このコントロールプレーンをMicrosoftが完全に管理してくれるため、ユーザーは意識する必要がありません。
コントロールプレーンが担う役割は以下の通りです。
- API Server：kubectlコマンドを受け付ける窓口
- Scheduler：「このPodはどのノードで動かす？」を決定
- Controller Manager：「Podを3つ維持」など、状態を常に監視・調整
- etcd：クラスターの設定・状態を保存するデータベース
例えるなら「工場長」や「指揮者」のような存在です。
ノード：作業員
一方、実際にコンテナを動かすのは「ノード」です。ノードはAzureの仮想マシン（VM）であり、コントロールプレーンからの指示を受けてPodを起動します。例えるなら「作業員」や「演奏者」です。
料金の関係
つまり、「コントロールプレーンはMicrosoft管理で無料（※価格レベルによる）、ノードはユーザー管理で有料」という関係性になっています。
Azureでコンテナを動かす方法
Azure上でコンテナやアプリを動かす方法は複数あります。用途や要件に応じて選択肢が用意されています。
App Service：常時稼働のWebアプリ
コードをアップロードするだけで、Azureが環境を用意して動かしてくれます。Dockerを知らなくても使えるため、小規模なWebアプリケーションや新規開発に最適です。月額固定料金で、常時稼働するWebアプリに向いています。
例えるなら「家具付きマンション」です。荷物（コード）だけ持っていけば、すぐに利用開始できます。
Azure Functions：イベント駆動の関数実行
イベント（HTTPリクエスト、タイマー、キューメッセージなど）をトリガーに関数単位で実行されます。使った分だけの従量課金で、Dockerを使わずにコードだけでデプロイできます。
App Serviceとの違いは、常時稼働ではなくイベント駆動という点です。
Container Apps：サーバーレスなコンテナ実行
Dockerイメージをデプロイするだけで、Azureが自動的にスケーリングやロードバランシングを行ってくれます。
内部ではKubernetesが動いていますが、ユーザーはKubernetesを意識する必要がありません。使った分だけの従量課金で、アクセスがないときは0にスケールダウンすることも可能です。この「0スケール」がContainer Appsの大きな特徴です。
例えるなら「Airbnb」です。家具（Dockerイメージ）は自分で持ち込み、使った日だけ課金されます。
AKS：Kubernetesをフル活用
Kubernetesの全機能を使える、最も自由度の高い選択肢です。
ノード（VM）レベルでの制御、カスタムネットワーク構成、Pod Security Policy、Helm、Istioなど、Kubernetesエコシステムのあらゆる機能を活用できます。
例えるなら「一戸建て」です。すべてを自分で管理する必要がありますが、リフォーム（カスタマイズ）は自由自在です。
どれを選べばいいの？
デプロイ対象と用途で整理すると、以下のようになります。
コードをそのままデプロイしたい場合：
- 常時稼働のWebアプリ → App Service
- イベント駆動・関数単位 → Azure Functions
Dockerイメージをデプロイしたい場合：
- シンプルに動かしたい、0スケールしたい → Container Apps
- Kubernetesの機能が必要 → AKS
料金体系を理解しよう
AKSの料金を理解する上で、「何が無料で何が有料なのか」を把握することが重要です。
AKSのコストは大きく分けて3つの要素で構成されます。
- クラスター管理（コントロールプレーン）：価格レベルによって無料〜有料
- ノード（VM）：常に有料。AKSコストの大部分を占める
- その他リソース：ディスク、ロードバランサー、ネットワーク等
AKS価格レベル（コントロールプレーン）
AKSでは、コントロールプレーンの価格レベルを選択できます。
Free：
- 料金：無料（クラスター管理費は¥0）
- SLA：なし（No SLA, non-production）
- ノード上限：10台を超えるスケールは非推奨
- 用途：学習・検証・実験
Standard
- 料金：有料
- SLA：Availability Zones使用時99.95%、未使用時99.9%
- ノード上限：5,000台
- コントロールプレーン自動スケール：あり
- 用途：本番ワークロード
Premium
- 料金：有料（Standardより高い）
- Standardの全機能に加え、長期サポート（LTS）2年間
- Kubernetesコミュニティサポート終了後も1年間、バグ修正とセキュリティ更新を提供
- 用途：ミッションクリティカルな本番環境
ノード（VM）：AKSコストの大部分
AKSのコストの大部分は、ノード（VM）の料金です。AKS価格レベルが「Free」でも、ノードのVM料金は必ずかかります。
料金計算ツールで見た例（Japan East、1台、730時間/月）：
- A2（2コア、3.5GB RAM）：約¥19,000/月
- Standard_B2s（2コア、4GB RAM）：約¥3,000/月
- Standard_D4ds_v5（4コア、16GB RAM）：約¥20,000/月
VMサイズと台数によって料金が大きく変わります。学習用であれば、小さいVMサイズ（Bシリーズ）で、ノード数を最小（1〜2台）にすることをおすすめします。
OSディスク
各ノードにはOSディスクが必要です。
- Standard HDD（S4 – 32GB）：約¥248/月/台
ノード数が増えればディスク代も増えます。
その他の料金
- Load Balancer：ServiceをLoadBalancerタイプで公開すると、Azure Load Balancerが作成され課金される
- パブリックIP：LoadBalancerやIngressで外部公開する場合
- 外向きネットワーク通信（Egress）：インターネットへの送信データ量に応じて課金
- 追加ストレージ：PersistentVolumeを使用する場合
コスト試算例
最小構成（学習用）の場合：
| 項目 | 料金/月 |
|---|---|
| クラスター管理（Free） | ¥0 |
| ノード（B2s × 1台） | 約¥3,000 |
| OSディスク（32GB × 1） | 約¥250 |
| 合計 | 約¥3,250/月 |
本番構成例の場合：
| 項目 | 料金/月 |
|---|---|
| クラスター管理（Standard） | 有料 |
| ノード（D4ds_v5 × 3台） | 約¥60,000 |
| OSディスク（32GB × 3） | 約¥750 |
| Load Balancer | 約¥2,000〜 |
| 合計 | 約¥65,000〜/月 |
※実際の料金はリージョン、使用状況、割引オプションにより変動します。
割引オプション
長期利用する場合は、以下の割引が適用できます。
- 1年/3年の節約プラン：コンピューティング料金を割引
- 予約インスタンス（Reserved Instances）：1年/3年予約で大幅割引
学習用の一時的な利用では不要ですが、本番環境では検討の価値があります。
コスト削減のコツ
学習が終わったらクラスターを「停止」または「削除」しましょう。
- 停止：ノードのVM料金が止まる（ディスク等は継続）。すぐ再開可能
- 削除：すべての課金が止まる。作り直しが必要
重要：クラスターを作成したまま放置すると、使っていなくてもVM料金が発生し続けます。学習が終わったら必ず停止または削除してください。
ネットワーク構成を理解しよう
AKSのネットワーク設定は、作成後に変更できない重要な項目です。
kubenet vs Azure CNI
どちらもPodへのIPアドレス割り当て方式です。パブリック/プライベートとは別の設定です。
kubenet（シンプル構成）
PodにはAKS内部の独自IPアドレス（例：172.16.x.x）が割り当てられます。VNetとは別のIP帯です。
他のAzureリソースとの通信はNAT経由になり、通信先から見ると接続元はノードのIPになります。学習用や単体で動くアプリには十分です。
Azure CNI（VNet統合）
PodにVNet内のIPアドレス（例：10.0.1.x）が直接割り当てられます。
他のAzureリソース（SQL Database、Storageなど）と直接プライベート通信できます。NSGでPod単位のアクセス制御も可能です。
どちらを選ぶ？
- とりあえず繋がればいい、学習用 → kubenet
- Pod単位で細かい制御が必要、本番環境 → Azure CNI
kubenetでもVNet統合すれば他のリソースと通信はできますが、Pod単位の制御（NSG、監査ログでどのPodからの通信か識別）が必要な場合はAzure CNIを選びます。
プライベートクラスター
API Server（kubectlの接続先）へのアクセスをVNet内に限定する設定です。ネットワーク構成（kubenet/Azure CNI）とは別の設定です。
- パブリッククラスター：インターネット経由でAPI Serverにアクセス可能
- プライベートクラスター：VNet内からのみAPI Serverにアクセス可能
本番環境ではセキュリティ上プライベートクラスターが推奨されますが、踏み台VMやVPN接続が必要になるため、学習用ではパブリッククラスターが便利です。
パブリック/プライベートの設定は作成後に変更できません。
ワークロードの種類を理解しよう
Kubernetesでは、「アプリをどう動かすか」のパターンをワークロードと呼びます。
Deployment：最も基本的なワークロード
常時稼働するアプリケーション（Webサーバー、APIなど）に使用します。指定した数のPodを維持し、障害時には自動で再作成されます。
StatefulSet：状態を持つアプリケーション
データベースやRedisなど、データを保持する必要があるアプリケーションに使用します。Podごとに固定のIDと永続ボリュームが割り当てられます。
DaemonSet：全ノードに配置
ログ収集エージェントや監視エージェントなど、全ノードに1つずつ配置したいアプリケーションに使用します。
Job / CronJob：バッチ処理
Jobは1回実行して終了するバッチ処理、CronJobは定期実行するバッチ処理に使用します。
学習を始める際は、まずDeploymentを使いこなせるようになることを目指しましょう。
サービスとイングレスを理解しよう
Podにアクセスするための「入り口」を作る仕組みです。
Service：Pod群への接続先
Podは動的に作成・削除されるため、直接IPアドレスを指定してアクセスできません。Serviceは、Pod群への安定した接続先を提供します。
Serviceには3つの種類があります。
- ClusterIP：クラスター内部からのみアクセス可能
- NodePort：ノードのポート番号で外部公開
- LoadBalancer：Azure Load Balancerを作成し、パブリックIPで外部公開
Ingress：HTTPレベルのルーティング
複数のServiceに対して、パスベース（/api、/webなど）やホストベース（api.example.com、web.example.comなど）でルーティングを行います。
App GatewayのL7ルーティングと同じ役割です。AKSでは、nginx-ingressを自分で構築するか、Azure Application GatewayをIngress Controllerとして使用（AGIC）できます。
構成管理：ConfigMapとSecret
アプリケーションの設定情報を管理する仕組みです。
ConfigMap：設定値の外出し
環境変数や設定ファイルの内容を保存します。
Dockerイメージに設定を埋め込むと、環境ごとにイメージを作り直す必要があります。ConfigMapを使えば、同じイメージを開発/本番で使い回せます。
Secret：機密情報の管理
パスワード、APIキー、証明書など、機密情報を保存します。
Base64エンコードされて保存されますが、暗号化ではないため、本番環境ではAzure Key Vaultとの連携が推奨されます。
まとめ：AKSを始めよう
今回は、AKSを使い始める前に知っておくべき基本概念について解説しました。
ポイントを整理すると、以下の通りです。
- コントロールプレーン（司令塔）はMicrosoft管理、ノード（VM）がユーザー管理・課金対象
- コードだけならApp Service/Functions、DockerならContainer Apps/AKS
- クラスター > ノードプール > ノード > Pod > コンテナの階層構造（包含関係）
- ノードプールは「VMのスペック設定」、ノードは「実際のVM」
- AKS価格レベル（Free/Standard/Premium）はSLAとノード上限の違い。VMの料金は別途かかる
- kubenetはシンプル、Azure CNIはPod単位の細かい制御が必要なときに使う
- ネットワーク構成とプライベート/パブリックは作成後に変更不可
- 学習用はFreeプラン、小さいVMサイズ、パブリッククラスターで十分
次回の「リソース作成編」では、実際にAKSクラスターを作成し、kubectlで操作する手順をハンズオン形式で解説します。
まずはAzureポータルを開いて、AKSクラスターを1つ作成するところから始めてみてください。
