Azure Kubernetes Service（AKS）のAdvanced Container Networking Servicesは、AKSクラスタのネットワークを「見える化」するだけの機能ではありません。ネットワークメトリック、フローログ、FQDNベースの通信制御、Layer 7ポリシー、暗号化、eBPFによる性能改善、複数クラスタ間接続までを扱う、AKS向けの高度なコンテナネットワーク機能群です。
2026年5月22日に更新された公式Overviewでまず押さえるべき結論は、Advanced Container Networking Servicesが Observability、Security、Performance、Connectivity の観点で整理され、特に Cross-cluster networking（Preview） が概要に含まれたことです。一方で、セキュリティ系や性能改善系の多くは Azure CNI Powered by Cilium が前提です。既存AKSクラスタに自動で同じ効果が適用されるわけではないため、管理者は「自社クラスタがCiliumか」「ACNSが有効か」「監視・ログ・ポリシー・コストに影響が出るか」を先に確認する必要があります。(Microsoft Learn)
Advanced Container Networking Services for AKSで何が変わるのか
Advanced Container Networking Services、以下ACNSは、AKSクラスタのネットワーク運用を高度化するためのサービス群です。公式Overviewでは、Container Network Observability、Container Network Security、Container Network Performanceが主要な機能セットとして説明され、さらにContainer Network Connectivityの文脈でCross-cluster networkingがPreviewとして整理されています。(Microsoft Learn)
今回の更新を「機能が勝手に有効化される変更」と捉えると誤解します。実務上のポイントは、AKSのネットワーク運用でACNSが扱う範囲が明確になり、監視、セキュリティ、性能、複数クラスタ接続を個別機能ではなく、ACNSの設計対象として考える必要が出てきたことです。
| 観点 | 内容 | 管理者・開発者への影響 |
|---|---|---|
| Observability | メトリック、Hubbleメトリック、フローログ、Azure Managed Prometheus、Azure Managed Grafanaとの連携 | 通信障害やDNS遅延、Pod間通信の異常をダッシュボードやログで追いやすくなる。ただし、ログ量とメトリックのカーディナリティ管理が必要 |
| Security | FQDNフィルタリング、Layer 7ポリシー、WireGuard Encryption、Cilium mTLS Encryption | IPアドレスではなくドメイン名やHTTPメソッド・パス単位で制御できる。Cilium前提の機能が多く、既存NetworkPolicyの挙動確認が必要 |
| Performance | eBPF Host Routing | Pod間通信の低遅延化・スループット改善を狙えるが、OS、Kubernetesバージョン、iptables利用状況の確認が必須 |
| Connectivity | Cross-cluster networking（Preview） | Azure Kubernetes Fleet ManagerとCilium Cluster Meshを使い、複数AKSクラスタ間のPod-to-Pod接続を設計できる。Previewのため本番採用は慎重に判断する |
MicrosoftDocsのGitHub履歴では、2026年5月19日にCross-cluster networking関連のドキュメント追加とOverviewへの追記が行われ、同日にCross Cluster NetworkingへPreview表記が追加されています。5月20日には関連リンクの修正も確認できます。つまり、今回のOverview更新では、複数クラスタ接続がACNSの全体像に入った点を特に確認すべきです。(GitHub)
また、WireGuard Encryptionについては、Overview上の見出しからPreview表記を外す変更履歴が確認できます。ただし、各機能の提供状態は関連ページやリージョン、クラスタ構成によって変わる可能性があるため、実際の採用前には対象機能の個別ドキュメントも確認してください。(GitHub)
ACNSはどのAKSクラスタに影響するのか
影響範囲は、現在のクラスタ構成によって大きく変わります。特に重要なのは、Ciliumデータプレーンを使っているかどうかです。
ACNSのObservabilityはCiliumと非Ciliumの両方で利用できる範囲がありますが、Container Network SecurityやContainer Network Performanceは、基本的にAzure CNI Powered by Ciliumが前提です。公式ドキュメントでも、Container Network SecurityはAzure CNI Powered by Ciliumのクラスタでのみ利用可能と説明されています。(Microsoft Learn)
| 現在のクラスタ状態 | 影響の見方 | 確認すべきこと |
|---|---|---|
| Azure CNI Powered by Cilium + ACNS有効 | 最も影響が大きい。Observability、Security、Performanceの検討対象になる | FQDN/L7/WireGuard/mTLS/eBPF Host Routingの利用有無、ログ量、ポリシー挙動 |
| CiliumだがACNS未有効 | 高度なACNS機能はまだ使っていない状態 | --enable-acnsを有効化する前に、コストとポリシー影響を評価 |
| 非Ciliumクラスタ | Observability中心。Security/Performance機能の多くは対象外 | Cilium移行が必要か、監視だけで足りるかを判断 |
| Azure Network Policy Managerから移行予定 | NetworkPolicyの挙動差に注意 | ipBlock、Named Port、LoadBalancer/NodePort経由のIngress、ローカルNode向けEgress |
| Windowsノードプールあり | Ciliumや一部ネットワーク機能の制約に注意 | Linuxノードプールへの分離、対象ワークロードの切り分け |
| 複数AKSクラスタ運用 | Cross-cluster networkingの検討対象 | Fleet Manager、Pod CIDR、VNet、セキュリティ境界、Preview利用可否 |
Azure CNI Powered by Ciliumには、Linuxのみ対応、ipBlockでPod IPやNode IPを許可できない、hostNetwork: trueのPodには通常のNetworkPolicyが適用されない、といった制限があります。CiliumのConfigMapも基本的にはAKS管理で、サポートされる変更は限定されています。既存クラスタをCiliumへ移行する場合は、単にデータプレーンを変えるのではなく、既存NetworkPolicyの棚卸しが必要です。(Microsoft Learn)
まず確認すべきAKS設定
ACNSを使う前に、管理者はクラスタの現在状態を確認します。特に見るべき項目は、Kubernetesバージョン、ネットワークプラグイン、データプレーン、ACNSの有効化状態、ノードOS、Azure MonitorやGrafana連携です。
# Azure CLIのバージョン確認
az version
# AKSクラスタのネットワークプロファイル確認
az aks show \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--query "{kubernetesVersion:kubernetesVersion, networkProfile:networkProfile}" \
-o yaml
# ノードOSとバージョンの確認
kubectl get nodes -o wide
# kube-system内のネットワーク・監視関連Podを確認
kubectl get pods -n kube-system | egrep 'cilium|ama-|hubble|retina'
# ContainerNetworkLog CRDを使っている場合の確認
kubectl get containernetworklog -AContainer network logsの設定確認では、az aks showの出力にある networkProfile.advancedNetworking.enabled や observability.enabled を確認する手順が公式ドキュメントで示されています。ログを使う場合は、ACNSが有効なだけでは不十分で、どの通信を記録するかを指定する ContainerNetworkLog カスタムリソースも確認する必要があります。(Microsoft Learn)
ACNSを有効化する方法と注意点
新規AKSクラスタでACNSを使う場合は、az aks createに --enable-acns を指定します。Cilium前提のセキュリティ機能まで見据えるなら、作成時点で --network-dataplane cilium を指定しておくのが分かりやすい設計です。既存クラスタでは az aks update --enable-acns で有効化できます。(Microsoft Learn)
az aks create \
--name $CLUSTER_NAME \
--resource-group $RESOURCE_GROUP \
--network-plugin azure \
--network-plugin-mode overlay \
--network-dataplane cilium \
--enable-acnsaz aks update \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--enable-acns注意したいのは、FQDNフィルタリングとLayer 7ポリシーの扱いです。公式ドキュメントでは、FQDNフィルタリングポリシーは --enable-acns で既定有効になり、Layer 7とFQDNの両方を有効にしたい場合は --acns-advanced-networkpolicies L7 を設定すると説明されています。ポリシーを段階導入する場合は、最初から本番Namespace全体に適用するのではなく、テスト用Namespaceや一部ワークロードで通信ログを確認してから広げるのが安全です。(Microsoft Learn)
ACNS全体を無効化する場合は --disable-acns、Observabilityだけを無効化する場合は --disable-acns-observability、Securityだけを無効化する場合は --disable-acns-security が用意されています。ただし、非CiliumクラスタではContainer Network Observabilityが中心になるため、機能単位での無効化可否がCiliumクラスタと異なります。(Microsoft Learn)
# ACNS全体を無効化
az aks update \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--disable-acns
# Security機能のみ無効化
az aks update \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--enable-acns \
--disable-acns-securityObservabilityを使うときの設計ポイント
Container Network Observabilityは、AKSのネットワーク障害調査を大きく変える機能です。従来は「Pod間通信が遅い」「DNS解決が不安定」「特定サービスだけタイムアウトする」といった問題を、アプリケーションログ、CoreDNSログ、NetworkPolicy、NSG、Firewallログを横断して追う必要がありました。ACNSでは、ノードレベルやPodレベルのネットワークメトリック、DNS、Pod間通信、サービス間通信のHubbleメトリック、フローログを活用できます。(Microsoft Learn)
| 使う情報 | 向いている場面 | 注意点 |
|---|---|---|
| Container network metrics | 異常検知、ダッシュボード、アラート、容量計画 | Ciliumではソースレベルのフィルタリングでコストを抑えやすい。非Ciliumでは細かなフィルタリングに制約がある |
| Stored logs | 監査、障害の後追い、通信経路の証跡確認 | Stored logsはCiliumデータプレーンが前提。ContainerNetworkLog CRDを作らないとログは生成されない |
| On-demand logs | 現在発生中の通信障害調査 | 長期保存ではなく、Hubble CLIやHubble UIでリアルタイムに見る用途に向く |
| Azure Managed Grafana | 運用チームの可視化 | 一部メトリックは既定で収集対象外の場合があり、必要に応じて設定調整が必要 |
Container network logsでは、Stored logsとOn-demand logsの2種類が説明されています。Stored logsは継続的な収集に向き、On-demand logsはリアルタイムのトラブルシューティングに向きます。Stored logsはACNSを有効にしただけではログが出ず、ContainerNetworkLog CRDで記録対象を定義する必要があります。(Microsoft Learn)
コスト面では、ログとメトリックを「全部取る」設計にしないことが重要です。Container network logsは集約によりデータ量を抑えられますが、細かなURL、Pod IP、個別フローのタイムスタンプなど高カーディナリティ情報は集約ログでは保持されない場合があります。詳細調査にはOn-demand logsを使う、長期分析にはフィルタ済みStored logsを使う、という使い分けが現実的です。(Microsoft Learn)
また、Azure Managed GrafanaのPod Flows系ダッシュボードで使われる hubble_flows_processed_total は、大規模クラスタで高カーディナリティになりやすいため既定ではスクレイプされないと説明されています。ダッシュボードに欠けているパネルがある場合は、メトリックのKeep listを見直す必要があります。(Microsoft Learn)
Security機能を使うときの判断基準
Container Network Securityは、AKS上の通信制御をより細かくしたい場合に有効です。ただし、セキュリティ機能を強くすると、アプリケーションの通信失敗やレイテンシ増加が表面化しやすくなります。運用では、FQDN、L4、L7、暗号化を一度に入れるのではなく、目的別に段階導入するのが安全です。
FQDNフィルタリングは外部サービス向け通信制御に向く
FQDNベースのフィルタリングは、IPアドレスではなくドメイン名で通信先を制御できます。外部SaaS、決済API、監視サービス、パッケージリポジトリなど、IPアドレスが変わりやすい接続先に向いています。IPアドレスの変更に合わせてNetworkPolicyを書き換える運用を避けられる点が大きなメリットです。(Microsoft Learn)
一方で、FQDNポリシーを使う場合はDNS経路の設計が重要です。アプリケーションが名前解決せずに直接IPアドレスへ通信している、独自DNSやNodeLocal DNSを使っている、Private Endpointの名前解決を分けている、といった環境では、期待した通りに制御・可視化できるかを事前に検証してください。
Layer 7ポリシーは便利だが高トラフィック経路では測定が必須
Layer 7ポリシーは、HTTPメソッド、URLパス、gRPC、Kafkaなどアプリケーション層の属性で通信を制御できます。たとえば「frontend から orders-api への GET /products は許可するが、POST /products は拒否する」といった制御が可能です。(Microsoft Learn)
ただし、L7ポリシーはEnvoyプロキシを経由するため、レイテンシへの影響を無視できません。公式ドキュメントでは、Envoyを通るトラフィックにはレイテンシがあり、3,000 requests per secondを超えると目立つ遅延劣化が起こる可能性があると説明されています。また、Ciliumのアップグレードやロールアウト中に既存セッションが終了する可能性があり、アプリケーション側のリトライ実装が求められます。(Microsoft Learn)
WireGuardとCilium mTLSは用途を分けて検討する
WireGuard Encryptionは、Cilium管理下のエンドポイント間通信をWireGuardプロトコルで暗号化する機能です。クラスタ内通信の盗聴や改ざんリスクを下げたい場合に検討できます。(Microsoft Learn)
Cilium mTLS Encryptionは、アプリケーション変更なしでPod-to-Pod通信にmTLSの暗号化と認証を提供する機能として説明されています。ただし、Cilium mTLSはPublic Previewであり、名前空間単位で有効化され、Pod単位のオプトイン・オプトアウトはできません。TCPベースのPod-to-Pod通信が対象で、UDP、WireGuardとの同時有効化、Istioとの併用、クロスクラスタ通信のmTLSなどには制限があります。本番環境では、Preview機能としてのサポート範囲とリスクを確認してから使うべきです。(Microsoft Learn)
Performance機能のeBPF Host Routingは「高速化」だけで判断しない
eBPF Host Routingは、従来のiptablesやnetfilter処理によるオーバーヘッドを減らし、Pod間通信のレイテンシ低下、スループット向上、CPU使用量の削減を狙う機能です。高トラフィックなマイクロサービス、リアルタイム処理、AI/MLワークロードなどでは魅力的な選択肢になります。(Microsoft Learn)
ただし、導入条件は厳しめです。公式ドキュメントでは、eBPF Host RoutingにはAzure CLI 2.71.0以降、Kubernetes 1.33以降、Azure Linux 3.0またはUbuntu 24.04、Azure CNI Powered by Ciliumが必要とされています。既存クラスタで有効化すると既存接続に影響する可能性も明記されています。(Microsoft Learn)
さらに、eBPF Host Routingを有効にするとホストネットワーク名前空間のiptablesルールがバイパスされます。AKSはiptablesルール利用中のクラスタでは有効化を検出・ブロックしようとしますが、運用側でもNode上のカスタムiptables、セキュリティエージェント、Egress制御、サードパーティCNI連携を事前に確認すべきです。Windowsノード、Confidential VM、Pod Sandboxing、Static Egress Gatewayなどにも制限があります。(Microsoft Learn)
Cross-cluster networkingはマルチクラスタ設計のPreview機能
今回のOverview更新で特に目立つのが、Container Network Connectivityとして整理されたCross-cluster networkingです。これはAzure Kubernetes Fleet ManagerとCilium Cluster Meshを使い、複数AKSクラスタ間で直接Pod-to-Pod通信を行うためのPreview機能です。ゲートウェイやプロキシを挟まず、フラットなPodネットワークでEast-West通信、マルチクラスタ可視化、一貫したポリシー適用を狙います。(Microsoft Learn)
利用シーンとしては、複数リージョンでの高可用性、共有サービスクラスタ、ステートフル/ステートレスのクラスタ分離、マルチクラスタでのセキュリティポリシー統一が考えられます。ただしPreviewであるため、ミッションクリティカルな本番環境にすぐ全面導入するより、検証環境で以下を確認するのが現実的です。(Microsoft Learn)
- Pod CIDRやVNetアドレス空間が重複していないか
- クラスタ間通信をどのセキュリティ境界で許可するか
- 障害時にどのクラスタへフェイルオーバーするか
- NetworkPolicyをクラスタ横断でどう管理するか
- ログとメトリックを単一の運用画面で追えるか
- Preview機能を本番SLAのある構成に含めてよいか
特に注意したいのは、「クロスクラスタ通信ができる」ことと「本番の災害対策として十分」なことは別だという点です。アプリケーションのセッション管理、データ整合性、DNS、Ingress、証明書、監査ログまで含めて設計しないと、通信経路だけつながっても実運用では使い切れません。
既存NetworkPolicyからCiliumへ移行する場合の落とし穴
ACNSの高度なSecurity機能を使うにはCiliumが重要になりますが、既存のAzure Network Policy Managerや他のNetworkPolicy運用から移行する場合、ポリシーの意味が完全に同じとは限りません。
Microsoftの移行ガイドでは、NPMとCiliumでは強制モデルが異なるため、既存ポリシーの互換性検証が必要とされています。たとえば、NPMでは許可されていたPod IPやNode IPへの通信が、Ciliumでは ipBlock の範囲内であってもブロックされる場合があります。また、LoadBalancerやNodePort経由のIngress、ローカルNode IPへのEgress、Named Portの扱いなども確認対象です。(Microsoft Learn)
実務では、移行前に次の観点で棚卸しします。
| 確認項目 | 失敗しやすい例 | 対応 |
|---|---|---|
ipBlock | 0.0.0.0/0 を許可しているのにPod/Node宛通信が落ちる | Pod宛は namespaceSelector や podSelector、Node宛はCiliumNetworkPolicyのentityで明示 |
| Named Port | 同じポート名が複数のポート番号に使われる | 数値ポートへ置き換えて検証 |
| LoadBalancer/NodePort | NPMでは届いていた外部通信がCiliumで拒否される | Ingressルールを明示的に定義 |
| ローカルNode宛Egress | Node上のエージェントやDNSへの通信が落ちる | host、remote-node、DNS向け通信を明示的に許可 |
| Windowsノード | Cilium Network Policyの対象外 | Linuxノードプールに対象ワークロードを配置 |
CiliumへのアップグレードではNode poolの再イメージが発生し、ネットワーク上の中断はNodeイメージアップグレードやKubernetesバージョンアップに近い影響になると説明されています。移行はメンテナンス時間帯に行い、PodDisruptionBudget、リトライ、Readiness Probe、外部依存先への通信確認を事前に整えておくべきです。(Microsoft Learn)
開発者が確認すべきアプリケーション側の影響
ACNSはインフラ機能ですが、開発者にも影響します。特にLayer 7ポリシー、FQDN制御、mTLS、フローログは、アプリケーションの通信仕様を前提にします。
開発者が確認すべきポイントは次の通りです。
- 外部APIへの通信先をIPアドレスではなくFQDNで整理しているか
- HTTPメソッド、パス、gRPCメソッド、Kafkaトピック単位で許可ルールを作れるほど通信仕様が明確か
- L7ポリシーで拒否された場合のHTTP 403などをアプリケーションが適切に扱えるか
- Ciliumロールアウト中の既存セッション終了に備えて、リトライやタイムアウト設計があるか
- DNS解決失敗時のログがアプリケーション側にも残るか
- mTLSやWireGuardを有効化しても、既存のサービスメッシュやサイドカー構成と競合しないか
Layer 7ポリシーは、単なるネットワーク遮断ではなく、アプリケーション層で許可・拒否を判断します。そのため、ポリシー設計はインフラチームだけで完結しません。API仕様、認証方式、エラーハンドリング、リトライ、Observabilityのラベル設計まで、開発チームと一緒に確認する必要があります。(Microsoft Learn)
コスト面で確認すべきこと
ACNSは有償サービスです。Azureの価格ページでは、Advanced Container Networking ServicesはKubernetesのObservability、Security、Compliance課題を簡素化するサービス群として説明され、価格はノード単位・時間単位の課金形態で示されています。実際の価格は契約、購入日、通貨、リージョンなどにより変わるため、見積もりではAzure Pricing Calculatorや契約ベースの価格を確認してください。(Microsoft Azure)
コストで失敗しやすいのは、ACNS自体のノード課金だけを見ることです。実際には、次のコストも合わせて見ます。
| コスト要素 | 見落としやすい点 | 対策 |
|---|---|---|
| ACNS利用料 | ノード数が増えるほど増える | 本番・検証・開発クラスタごとに必要性を分ける |
| Prometheusメトリック | Hubble系メトリックは高カーディナリティになりやすい | Ciliumではソースレベルのフィルタリングを使う |
| Log Analytics | Flow logsを広く取りすぎると取り込み量が増える | ContainerNetworkLog CRDでNamespaceやServiceを絞る |
| Grafana運用 | ダッシュボードだけ作ってアラート設計がない | 重要SLOに紐づくパネルと通知だけ先に作る |
| 調査工数 | ログはあるが検索できず使われない | KQL、Runbook、障害時の見る順番を決める |
最初から全Namespace、全Pod、全通信を記録するのではなく、重要な決済系API、外部SaaS連携、認証基盤、データベース接続、Ingress背後の主要サービスなどから対象を絞ると、コストと運用負荷を抑えながら効果を出しやすくなります。
展開前チェックリスト
ACNSを有効化・拡張する前に、次の順序で確認すると失敗しにくくなります。
| 手順 | 実施内容 | 完了条件 |
|---|---|---|
| 1 | 対象AKSクラスタを棚卸し | Kubernetesバージョン、Cilium有無、ノードOS、Windowsノード有無を一覧化 |
| 2 | 使いたいACNS機能を分類 | Observabilityだけか、Security/Performance/Connectivityまで使うかを決定 |
| 3 | 既存NetworkPolicyを確認 | ipBlock、Named Port、Ingress/Egressの暗黙許可依存を洗い出す |
| 4 | 検証環境でACNSを有効化 | az aks update --enable-acns 後、Pod間通信と外部通信のスモークテストを実施 |
| 5 | Observabilityを先に整備 | メトリック、ログ、Grafana、Log Analyticsの保存先とアラートを確認 |
| 6 | Securityポリシーを段階適用 | Namespace単位、アプリ単位でFQDN/L7ポリシーを広げる |
| 7 | 性能機能を別枠で検証 | eBPF Host Routingはiptables、OS、既存接続、Static Egress Gatewayの制約を確認 |
| 8 | ロールバック手順を用意 | --disable-acns-security や --disable-acns の利用条件をRunbook化 |
特に本番環境では、Observabilityを先に入れて通信の実態を見てからSecurityポリシーを適用する流れが安全です。通信の実態を把握しないままFQDNやL7の制限を入れると、アプリケーションが依存している外部API、DNS、Node向け通信、監視エージェント通信を誤って止める可能性があります。
まとめ：ACNSはAKSネットワーク運用の基盤として設計する
Advanced Container Networking Services for AKSは、単なる監視追加機能ではなく、AKSネットワークの可視化、制御、暗号化、性能改善、マルチクラスタ接続を扱う基盤です。2026年5月22日更新のOverviewでは、Cross-cluster networking（Preview）まで含めて、ACNSの守備範囲がより明確になりました。
次に取るべき行動は、すぐに全クラスタで有効化することではありません。まず、自社AKSクラスタをCilium、非Cilium、Windowsノード有無、NetworkPolicy利用状況、監視基盤の有無で分類してください。そのうえで、Observabilityを先に整え、通信実態を見える化してから、FQDN、Layer 7、暗号化、eBPF Host Routing、Cross-cluster networkingを必要な範囲で段階導入するのが現実的です。
ACNSは、導入すれば自動的に安全・高速になる魔法のスイッチではありません。効果を出すには、ネットワーク設計、アプリケーション通信仕様、ログコスト、移行手順を合わせて設計する必要があります。AKS管理者と開発チームが同じ通信マップを見ながら、まずは重要Namespaceや主要サービスから検証を始めるのが、もっとも失敗しにくい進め方です。
コメント