Azure Kubernetes Service（AKS）のネットワーク運用で、「どの通信が詰まっているのか分からない」「IPベースの制御ではポリシー管理がつらい」「Pod間通信の暗号化をどう考えるべきか」と悩むチームは多いはずです。今回取り上げる Advanced Container Networking Services for Azure Kubernetes Service（AKS） は、AKSのネットワーク監視・セキュリティ・パフォーマンス改善をまとめて扱うための機能群です。
結論から言うと、2026年4月時点で重要なのは、Advanced Container Networking Servicesを単なる監視機能ではなく、Ciliumを軸にしたAKSネットワーク強化スイートとして捉えることです。特に、Container Network ObservabilityはCilium以外の環境でも使いやすい一方、Container Network SecurityやContainer Network PerformanceはAzure CNI Powered by Ciliumが前提になります。新規AKSクラスターや刷新案件では、最初からCilium前提で設計する価値が高まっています。(Microsoft Learn)
Azureの最新動向: Advanced Container Networking Services for AKSの2026年4月更新ポイント
2026年4月更新で押さえるべきポイントは、Advanced Container Networking Servicesの位置づけがより明確になったことです。Microsoft Learnの概要では、Advanced Container Networking Servicesが Container Network Observability、Container Network Security、Container Network Performance の3つの機能セットで構成されると整理されています。これにより、AKSのネットワーク課題を「見える化」「制御」「高速化」の3方向から検討しやすくなりました。(Microsoft Learn)
4月下旬のMicrosoftDocsの変更履歴を見ると、概要ページに Cilium mTLS Encryption の項目が追加され、さらにWireGuard Encryptionの「preview」表記を外す変更も行われています。つまり、ACNSはネットワーク観測だけでなく、Pod間通信の暗号化やゼロトラスト寄りの通信制御を含む領域へ広がっていると見てよいでしょう。ただし、Cilium mTLSの詳細ページではpublic previewとして扱われているため、本番導入では最新の公式ドキュメントとサポート条件を確認する必要があります。(GitHub)
Advanced Container Networking Servicesで何ができるのか
Advanced Container Networking Servicesは、AKSクラスターのネットワークを強化するための機能群です。ネットワークトラフィックの可視化、通信ポリシーの細かな制御、eBPFを活用したルーティング最適化などを組み合わせて、コンテナー化されたアプリケーションの運用性を高めます。(Microsoft Learn)
| 機能セット | 主な役割 | 対応条件の考え方 | 実務での使いどころ |
|---|---|---|---|
| Container Network Observability | ネットワークメトリクス、Hubbleメトリクス、ネットワークログによる可視化 | Cilium / 非Ciliumの両方で利用可能 | 障害調査、DNS遅延調査、Pod間通信の把握、Grafanaでの監視 |
| Container Network Security | FQDNフィルタリング、L7ポリシー、WireGuard、Cilium mTLSなど | Azure CNI Powered by Ciliumが前提 | ゼロトラスト、外部接続制御、Pod間通信の暗号化、通信ポリシー強化 |
| Container Network Performance | eBPF Host Routingによる通信最適化 | Azure CNI Powered by Ciliumが前提 | レイテンシ改善、東西通信の効率化、ネットワーク経路の最適化 |
この表で重要なのは、すべての機能が同じ条件で使えるわけではない点です。監視だけを始めたい既存クラスターではObservabilityから入りやすい一方、FQDNフィルタリングやL7ポリシー、WireGuard、mTLS、eBPF Host Routingまで使いたい場合は、Cilium前提の設計に寄せる必要があります。(Microsoft Learn)
Container Network Observabilityは最初に導入しやすい機能
Advanced Container Networking Servicesの中で、多くのAKS運用チームが最初に検討しやすいのが Container Network Observability です。これは、クラスター内のネットワークトラフィックやパフォーマンスを可視化する機能で、Ciliumデータプレーンと非Ciliumデータプレーンの両方で動作します。(Microsoft Learn)
メトリクスで見るべきポイント
Container Network Observabilityでは、ノードレベルのCPU、メモリ、ネットワークパフォーマンスに加え、Hubbleメトリクスを通じてDNS解決、Pod間通信、サービス間通信の状況を把握できます。Azure MonitorのManaged PrometheusやAzure Managed Grafanaとの統合も説明されており、メトリクス保存と可視化をAzure側の管理サービスに寄せやすい構成です。(Microsoft Learn)
実務では、まず次のようなダッシュボードを作ると効果が出やすくなります。
- DNS解決時間が急に伸びていないか
- 特定NamespaceやWorkloadで通信量が急増していないか
- サービス間通信で失敗や再試行が増えていないか
- ノード単位でネットワーク帯域やパケット処理に偏りがないか
- リリース後にPod間通信のパターンが変わっていないか
たとえば、アプリケーション側では「外部APIの応答が遅い」としか見えていない障害でも、HubbleメトリクスでDNS解決やサービス間通信の遅延を切り分けられる可能性があります。従来のアプリログだけでは追いづらかった「ネットワーク層の兆候」を、SREやインフラ担当が同じ画面で確認できる点が大きな価値です。
ネットワークログはトラブルシュートと監査に使う
Container network logsでは、送信元・宛先IP、ポート、プロトコル、フロー方向などのメタデータを取得できます。これは単なるログ保管ではなく、接続問題の調査、通信パターンの監視、セキュリティポリシーの検証に使える材料です。(Microsoft Learn)
たとえば、次のようなケースで役立ちます。
| ケース | ログで確認したいこと | 次のアクション |
|---|---|---|
| 新しいNetworkPolicy適用後に通信できない | どの送信元・宛先・ポートが拒否されているか | ポリシーの例外追加、名前空間単位の見直し |
| 外部SaaSへの通信が不安定 | 宛先、ポート、プロトコル、発生時間の傾向 | DNS、FQDNポリシー、外部側障害の切り分け |
| 監査で通信経路を説明したい | どのWorkloadがどの外部ドメインやサービスへ通信しているか | 許可リスト化、不要通信の削減 |
| リリース後に通信量が増えた | 変更前後で増えたフロー | アプリ側の実装変更、リトライ増加、キャッシュ不備を確認 |
Product Ownerにとっても、Observabilityは「障害対応を早くする」だけではありません。サービスのSLOを守るために、リリース前後で通信の変化を定量的に確認できる点が重要です。
Container Network SecurityはCilium前提で考える
Container Network Securityは、AKSクラスターのネットワークセキュリティを強化する機能群です。公式概要では、eBPFを利用してカーネルレベルでネットワークポリシーを適用すると説明されています。ただし、この機能はAzure CNI Powered by Ciliumを使うクラスターでのみ利用できます。(Microsoft Learn)
FQDNベースのフィルタリングでIP管理から脱却する
FQDN-based filteringは、IPアドレスではなくFQDNを基準にネットワークポリシーを作成する機能です。KubernetesではPod IPや外部サービスのIPが変わりやすいため、IPベースの許可リストを運用し続けると、更新漏れや過剰許可が起きやすくなります。FQDNベースにすると、たとえば api.example.com のようなドメイン単位で通信を制御しやすくなります。(Microsoft Learn)
ただし、万能ではありません。FQDN filteringの詳細では、Container Network Security機能にはAzure CNI Powered by CiliumとKubernetes 1.29以上が必要とされています。また、ユニバーサルワイルドカードのようにすべてのドメインへ一致させる指定はサポートされず、node-local DNSやKubernetes service namesにも制限があります。FQDNポリシーを「便利な許可リスト」として雑に使うのではなく、業務上必要な外部接続を棚卸ししたうえで段階的に適用するべきです。(Microsoft Learn)
L7ポリシーはアプリケーション単位の制御に向く
Layer 7 policyは、HTTPメソッド、URL、ヘッダーなど、アプリケーション層の属性を基準に通信を制御する機能です。L3/L4のIP・ポート制御より細かく、「このAPIパスだけ許可する」「特定のgRPCやKafka通信を制御する」といった設計に向いています。公式ドキュメントでは、HTTP、gRPC、Kafkaなどのプロトコルに対するサポートが説明されています。(Microsoft Learn)
一方で、L7ポリシーはEnvoyを経由するため、レイテンシへの影響を無視できません。公式の制限事項では、Envoyプロキシを通過するトラフィックにはレイテンシが伴い、3,000 requests per secondを超えると顕著なレイテンシ低下が発生する可能性があると説明されています。また、Istioなど別方式のL7ポリシーとの互換性にも注意が必要です。(Microsoft Learn)
実務では、すべての通信にL7ポリシーをかけるより、次のように対象を絞る方が現実的です。
| 適用候補 | 理由 |
|---|---|
| 管理系API | 不正操作や誤操作の影響が大きい |
| 決済・個人情報関連API | 最小権限と監査の要求が強い |
| 外部連携API | 接続先や操作範囲を限定したい |
| マルチテナント環境の内部API | テナント間の不要な到達性を減らしたい |
WireGuard EncryptionはPod間通信の暗号化を検討する機能
WireGuard Encryptionは、AKSクラスター内のCilium管理エンドポイント間で暗号化通信を提供する機能です。詳細ページでは、WireGuardがAdvanced Container Networking Servicesの機能セットの一部であり、Azure CNI Powered by Ciliumに基づいて実装されると説明されています。(Microsoft Learn)
重要なのは、WireGuardを有効にすればすべての通信が暗号化されるわけではないことです。公式ドキュメントでは、暗号化対象は異なるノード間のPodトラフィックで、同一ノード上のPod間通信やノード自身が生成するトラフィックは対象外とされています。さらに、WireGuardはFIPS準拠ではなく、ソフトウェアレベルの暗号化によりレイテンシやスループットへ影響する可能性があります。(Microsoft Learn)
導入時の実務上の注意点は明確です。WireGuardはAzure CNI Powered by Ciliumでのみサポートされ、暗号化トンネルにはUDP 51871を使用します。ファイアウォールやネットワーク制御を厳しくしている環境では、ノードIP間でUDP 51871を許可していないために有効化後の通信で詰まる可能性があります。(Microsoft Learn)
また、Advanced Container Networking Servicesを有効化してもWireGuardは自動では有効になりません。WireGuardを使うには --acns-transit-encryption-type wireguard を指定する必要があります。既存クラスターで有効化する場合、Cilium agentのロールアウト再起動が発生し、大規模クラスターでは一時的な影響が出る可能性があるため、メンテナンス時間帯での作業が推奨されます。(Microsoft Learn)
Cilium mTLS Encryptionは期待値と制限を分けて見る
2026年4月更新で特に注目されるのが、概要ページに追加された Cilium mTLS Encryption です。Cilium mTLSは、アプリケーション変更や追加のネットワークスタックなしに、KubernetesのPod間トラフィックへ透過的な相互TLS暗号化と認証を提供すると説明されています。(Microsoft Learn)
ただし、詳細ページではpublic previewとして扱われています。そのため、本番環境での全面採用というより、まずは検証環境や限定Namespaceで評価する段階と考えるのが安全です。mTLSはNamespace単位で有効化され、Pod単位での個別opt-in / opt-outはサポートされません。また、現時点ではTCPベースのPod間通信が対象で、UDPは暗号化・認証の対象外です。(Microsoft Learn)
さらに、Cilium mTLSには見落としやすい制限があります。L4/L7 network policy enforcementとの併用、WireGuardとの同一クラスター併用、Istioとの併用、カスタムCAの持ち込み、クロスクラスター通信のmTLS化などには制限があります。ゼロトラスト要件があるからといって、既存のIstioやNetworkPolicy設計へそのまま追加できるとは限りません。(Microsoft Learn)
Container Network Performanceはレイテンシ改善の選択肢
Container Network Performanceは、AKS上のコンテナー化アプリケーションのネットワークパフォーマンスを最適化する機能セットです。概要ページでは、eBPFを活用してネットワークルーティングを強化し、レイテンシを下げることを目的とすると説明されています。対象はAzure CNI Powered by Ciliumを使うクラスターです。(Microsoft Learn)
中心となるのは eBPF Host Routing です。これはAKSクラスター内のトラフィックフローを最適化するためにeBPFを使う機能です。実務では、マイクロサービス間通信が多いシステム、低レイテンシが求められるAPI基盤、Pod間通信量が多いデータ処理基盤などで検討価値があります。(Microsoft Learn)
ただし、パフォーマンス機能は「有効化すれば必ず速くなる」ものではありません。アプリケーション側のリトライ設計、DNS、外部サービス応答、Node SKU、リージョン間通信など、遅延要因は複数あります。導入前にObservabilityでベースラインを取り、ステージング環境でレイテンシ、スループット、CPU使用率を比較する流れが現実的です。
導入前に確認すべきチェックリスト
Advanced Container Networking Servicesを導入する前に、まず現在のAKS環境を棚卸しします。特に、Ciliumを使っているかどうかで利用できる機能が大きく変わります。
| 確認項目 | 判断基準 | 見落とすと起きる問題 |
|---|---|---|
| ネットワークデータプレーン | Security / Performanceを使うならAzure CNI Powered by Ciliumが必要 | 非Cilium環境でFQDN、L7、WireGuard、eBPF Host Routingを期待してしまう |
| Kubernetesバージョン | CiliumデータプレーンのObservability / SecurityはKubernetes 1.29以降が条件 | 古いクラスターで有効化できない、サポート条件に合わない |
| Azure CLI | ACNS利用手順ではAzure CLI 2.79.0以上が前提 | コマンドオプションが使えない、手順通りに進まない |
| 監視基盤 | Azure Monitor Managed PrometheusやAzure Managed Grafanaとの連携を検討 | メトリクスは取れても運用チームが見られない |
| セキュリティ要件 | FQDN、L7、WireGuard、mTLSのどれが必要かを分ける | 暗号化と通信制御を混同し、過剰設計になる |
| コスト | Advanced Container Networking Servicesは有償提供として案内されている | ノード数増加時のランニングコストを見落とす |
公式の有効化手順では、Azure CLI 2.79.0以上が前提とされ、Ciliumを使う新規AKSクラスターでは --network-dataplane cilium と --enable-acns を指定します。既存クラスターでは 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-acns既存クラスターで有効化する場合は、次の形式です。
az aks update \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--enable-acnsWireGuardも同時に検討する場合は、Advanced Container Networking Servicesを有効にしたうえで、暗号化タイプとしてWireGuardを指定します。
az aks update \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--enable-acns \
--acns-transit-encryption-type wireguardどのチームがどう活用すべきか
Advanced Container Networking Servicesは、担当者によって見るべきポイントが異なります。
| 読者 | 注目すべきポイント | 最初のアクション |
|---|---|---|
| IT管理者 | Cilium前提条件、監視基盤、暗号化、ポリシー運用 | 既存AKSのCNI、Kubernetesバージョン、CLIバージョンを棚卸しする |
| SRE / Platform Engineer | Hubbleメトリクス、ネットワークログ、L7可視化、eBPF Host Routing | 障害時に見るダッシュボードとアラートを先に設計する |
| Product Owner | 障害復旧時間、セキュリティ要件、リリース影響、コスト | どのサービスで通信可視化・暗号化が事業価値に直結するか決める |
| セキュリティ担当 | FQDN制御、L7制御、WireGuard、mTLS、監査ログ | 外部接続先と重要APIを洗い出し、段階的な許可リスト化を進める |
| Microsoftエコシステム利用企業 | Azure Monitor、Managed Prometheus、Azure Managed Grafanaとの統合 | 既存のAzure監視運用へどう取り込むか検討する |
グローバル展開しているサービスでは、リージョンやチームごとにAKSの設計がばらつきやすくなります。その場合、Advanced Container Networking Servicesを「各クラスターの便利機能」として導入するのではなく、プラットフォーム標準の一部として扱う方が効果的です。たとえば、新規クラスターはAzure CNI Powered by Ciliumを標準とし、Observabilityは原則有効、Security機能は重要度に応じてFQDN、L7、暗号化を段階的に適用する、といったルールにできます。
失敗しやすいポイントと回避策
Advanced Container Networking Servicesは便利ですが、前提条件や制限を見落とすと期待した効果が出ません。
| 失敗しやすいポイント | なぜ問題になるか | 回避策 |
|---|---|---|
| 非CiliumクラスターでSecurity機能まで使えると思い込む | Container Network SecurityはAzure CNI Powered by Ciliumが前提 | まずCNIとデータプレーンを確認し、必要なら移行計画を作る |
--enable-acns だけでWireGuardが有効になると思う | WireGuardは別途暗号化タイプの指定が必要 | --acns-transit-encryption-type wireguard を明示する |
| WireGuardとmTLSを同じ目的で重ねる | Cilium mTLSではWireGuardとの同一クラスター併用に制限がある | 通信暗号化の目的を整理し、どちらを使うか選ぶ |
| L7ポリシーを高トラフィックAPIへ無検証で適用する | Envoy経由によるレイテンシ影響が出る可能性がある | ステージングでRPS、p95/p99レイテンシ、CPUを測る |
| FQDNポリシーで広すぎるワイルドカードを使う | サポートされない指定や過剰許可につながる | 必要な外部接続先を棚卸しし、段階的に絞る |
| 監視ダッシュボードを後回しにする | 障害時に何を見るべきか分からない | 有効化直後にDNS、Pod間通信、Namespace別通信量を可視化する |
| コストを導入後に確認する | ACNSは有償提供として案内されている | ノード数、常時稼働時間、リージョンを前提に見積もる |
特に注意したいのは、Advanced Container Networking Servicesを「ネットワークの問題を自動で解決する機能」と見なさないことです。実際には、可視化で原因を見つけやすくし、ポリシーで通信を制御し、Cilium/eBPFで性能改善の選択肢を増やすものです。アプリケーション設計、リトライ、タイムアウト、DNS、外部依存サービスの管理は引き続き重要です。
既存AKSクラスターではどう進めるべきか
既存クラスターでは、いきなりSecurityやPerformanceまで有効化するより、段階的に進めるのが安全です。
最初はObservabilityで通信を見える化する
まずはContainer Network Observabilityを使い、現状の通信パターンを把握します。どのNamespaceがどこへ通信しているか、DNS解決が遅くないか、リリース後に通信量が変わっていないかを確認します。これにより、後続のFQDNポリシーやL7ポリシーを設計する材料が揃います。
次にCilium前提の移行可否を判断する
SecurityやPerformance機能が必要なら、Azure CNI Powered by Ciliumへの移行や新規クラスターでの採用を検討します。既存クラスターの移行は、Windowsノードプール、ネットワークポリシーエンジン、Node Auto Provisioningなど、周辺条件によって制約が出る場合があります。移行の可否は、公式ドキュメントと検証環境で確認してから進めるべきです。(GitHub)
セキュリティ機能は重要ワークロードから適用する
FQDNやL7ポリシーは、すべてのNamespaceへ一気に適用するとトラブルシュートが難しくなります。まずは外部接続先が明確なサービス、管理系API、個人情報を扱うAPIなど、対象を絞って適用します。ログとメトリクスで拒否や遅延を確認しながら、段階的に範囲を広げるのが現実的です。
新規AKSクラスターではCilium前提の設計が有力
新規にAKSクラスターを作る場合は、Advanced Container Networking Servicesを後付けの機能として見るのではなく、初期設計に組み込む方が効率的です。特に、将来的にFQDNフィルタリング、L7ポリシー、WireGuard、Cilium mTLS、eBPF Host Routingを使う可能性があるなら、Azure CNI Powered by Ciliumを前提に検討する価値があります。(Microsoft Learn)
設計時は、次の順番で決めると迷いにくくなります。
- クラスターで必要なネットワーク要件を整理する
監視だけか、通信制御まで必要か、暗号化要件があるかを分けます。 - Ciliumを標準にするか判断する
Security / Performance機能を使うならCilium前提で設計します。 - 監視基盤を先に決める
Azure Monitor Managed Prometheus、Azure Managed Grafana、既存監視基盤のどこで見るかを決めます。 - ポリシー適用範囲を決める
FQDN、L7、mTLS、WireGuardをどのNamespaceやWorkloadへ適用するかを段階的に設計します。 - ステージングで負荷と障害時の動きを確認する
レイテンシ、スループット、Cilium agentのロールアウト、ポリシー拒否時の挙動を確認します。
Advanced Container Networking Servicesの更新から見るAKS運用の方向性
2026年4月時点のAdvanced Container Networking Servicesを見ると、AKSのネットワーク運用は「接続できるかどうか」だけでは不十分になっています。今後は、どのWorkloadがどこへ通信しているか、通信がポリシーに合っているか、Pod間通信が暗号化されているか、レイテンシの原因がネットワークかアプリケーションかを、継続的に判断できる設計が求められます。
そのため、次に取るべき行動は明確です。まず既存AKSクラスターのCNI、Kubernetesバージョン、Azure CLIバージョン、監視基盤を棚卸ししてください。次に、Observabilityから始めて通信の実態を可視化し、必要に応じてAzure CNI Powered by Ciliumを前提としたSecurity / Performance機能の導入を検討します。新規クラスターでは、将来のネットワーク制御や暗号化要件を見越して、最初からAdvanced Container Networking Servicesを設計に含めるのが現実的です。
コメント