Azure Kubernetes Service（AKS）を運用している管理者にとって、2026年4月の重要ポイントは明確です。AKSのWireGuard in-transit encryptionが一般提供（GA）となり、Azure CNI powered by CiliumとAdvanced Container Networking Servicesを使うクラスターで、ノードをまたぐPod間通信をアプリ改修なしに暗号化しやすくなりました。
ただし、すべての通信が暗号化されるわけではありません。同一ノード上のPod間通信、ノード自身が発信する通信、hostNetwork: true のPodは対象外です。導入前に、Cilium構成、UDP 51871の許可、性能影響、Advanced Container Networking Servicesの費用を確認しておく必要があります。Microsoft公式情報では、WireGuard in-transit encryption for Azure Kubernetes Service（AKS）はAzure CNI powered by CiliumとAdvanced Container Networking Servicesを使うクラスター向けに一般提供となったと説明されています。(Microsoft Azure)
Azure Kubernetes Serviceの最新動向：WireGuard in-transit encryption for AKSで何が変わったか
2026年4月24日の更新で注目すべき点は、WireGuardベースの転送中暗号化が「プレビュー機能」ではなく「本番利用を検討できる一般提供機能」になったことです。Microsoft Tech Communityでは、GAによりプレビュー登録が不要になり、基本的な動作範囲や設定モデルはパブリックプレビューから変わらないと説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務上の意味は、単に「暗号化機能が増えた」というより、AKSのネットワークセキュリティ設計において、Pod間通信の暗号化を標準的な選択肢として検討しやすくなったことです。
| 更新ポイント | 実務での意味 |
|---|---|
| WireGuard in-transit encryptionがGA | 本番クラスターへの採用判断を進めやすくなった |
| Azure CNI powered by Ciliumが前提 | 既存AKSのネットワーク構成確認が必要 |
| Advanced Container Networking Servicesの一部 | 機能だけでなくコスト・運用範囲も確認が必要 |
| アプリ改修なしでネットワーク層に適用 | アプリケーションチームの改修負荷を抑えやすい |
| 暗号化対象は限定的 | 「AKS内の全通信が暗号化される」と誤解しないことが重要 |
特に、金融、医療、公共系、グローバルSaaS、社内基幹システムなど、通信経路の保護や監査説明が求められる環境では、今回のGAはセキュリティ設計の見直し材料になります。
AKSのWireGuard in-transit encryptionとは
WireGuard in-transit encryption for AKSは、AKSクラスター内の特定通信をWireGuardで暗号化する機能です。Microsoft Learnでは、WireGuardによる転送中暗号化は、Podやノード間で移動するデータを保護し、盗聴や改ざんリスクを軽減するための機能として説明されています。(Microsoft Learn)
ここで重要なのは、WireGuardが「AKSにVPNサーバーを立てる機能」ではないという点です。AKSでは、Ciliumデータプレーンと連携し、クラスター内の対象通信をネットワーク層で透過的に暗号化します。アプリケーション側でTLS設定を追加したり、サービスごとに暗号化処理を実装したりするものではありません。
つまり、IT管理者やプラットフォームチームにとっては、次のような価値があります。
- アプリケーションのコード変更なしで、ノード間Pod通信の保護を強化できる
- サードパーティ製の独自暗号化ツールを追加せず、AKSのマネージドなネットワーク機能として扱える
- Kubernetesネットワークの設計・監査・運用ルールに組み込みやすい
- セキュリティ要件が強いワークロードをAKSへ移行する際の説明材料になる
一方で、アプリケーションレベルのTLSやゼロトラスト設計を不要にするものではありません。WireGuard in-transit encryptionは、あくまでAKSクラスターネットワーク内の特定経路を保護する機能として位置付けるべきです。
暗号化される通信と暗号化されない通信
WireGuard in-transit encryption for AKSを検討する際、最初に確認すべきなのは「どの通信が暗号化されるか」です。Microsoft Learnでは、暗号化対象は異なるノード上のPod間通信であり、同一ノード上のPod間通信やノード発信の通信は対象外とされています。(Microsoft Learn)
| 通信の種類 | 暗号化対象 | 判断ポイント |
|---|---|---|
| 異なるノード上のPod間通信 | 対象 | WireGuardで保護される中心的な通信経路 |
| 同一ノード上のPod間通信 | 対象外 | ノード外へ出ないためWireGuardを経由しない |
| ノード自身が発信する通信 | 対象外 | 現時点ではWireGuard経由ではない |
hostNetwork: true のPod通信 | 対象外 | Pod固有のネットワークIDではなくホスト側のIDを使うため |
| AKS外部への通信 | 機能の主対象外 | 必要に応じてTLS、Private Link、NSG、Firewallなどと併用する |
たとえば、API PodとWorker Podが別々のノードで動いている場合、そのPod間通信は暗号化対象になります。一方、同じノード上にスケジュールされたPod同士の通信は、WireGuardの対象にはなりません。
この違いを理解せずに「AKS内通信はすべて暗号化済み」と説明してしまうと、監査やセキュリティレビューで問題になります。導入時は、アーキテクチャ図やセキュリティ設計書に「暗号化対象」と「対象外」を明記しておくことが重要です。
WireGuard in-transit encryptionの仕組み
AKSのWireGuard in-transit encryptionは、Azure CNI powered by Ciliumを前提に動作します。Microsoft Learnでは、Ciliumベースの構成において、WireGuardエージェントがキー管理、インターフェイス設定、ピア更新を担うと説明されています。(Microsoft Learn)
仕組みを実務向けに整理すると、次の流れです。
| 処理 | 内容 |
|---|---|
| キー生成 | 各ノードがWireGuard用の公開鍵・秘密鍵ペアを自動生成する |
| 公開鍵共有 | 公開鍵はCiliumNodeカスタムリソースを通じて共有される |
| 専用インターフェイス作成 | 各ノードに cilium_wg0 インターフェイスが作成される |
| ピア更新 | ノードの追加・削除に応じてWireGuardピアが動的に更新される |
| キー管理 | 鍵はAzure側で管理され、手動設定は不要 |
Microsoft Learnでは、キーはメモリ上に保存され、120秒ごとにローテーションされるとも説明されています。(Microsoft Learn)
この仕組みにより、管理者がノードごとにWireGuard設定ファイルを配布したり、公開鍵を手作業で管理したりする必要はありません。Kubernetesクラスターのノード追加やスケール操作と合わせて、暗号化ピアも自動的に追従します。
VNet Encryptionとの違い：どちらを選ぶべきか
AKSの転送中暗号化を考える際、WireGuardだけでなくAzure Virtual Network encryptionとの違いも押さえておく必要があります。Microsoft Learnでは、Azure Virtual Network encryptionは仮想ネットワーク内のAzure Virtual MachinesおよびVirtual Machine Scale Sets間のトラフィックを暗号化する機能として説明されています。(Microsoft Learn)
| 比較項目 | WireGuard in-transit encryption for AKS | Azure Virtual Network encryption |
|---|---|---|
| 主な対象 | AKS内の異なるノード上のPod間通信 | VNet内のVM間通信 |
| 適用レイヤー | Ciliumを使ったAKSネットワーク | Azure Virtual Network |
| 前提条件 | Azure CNI powered by Cilium、Advanced Container Networking Services | 対応VM SKU、Accelerated Networkingなど |
| 性能特性 | ソフトウェアベースのためCPU・スループット影響を評価すべき | 対応環境ではハードウェア支援により低オーバーヘッドを狙える |
| 向いているケース | AKSのPod間通信を重点的に保護したい | VNet全体のVM間通信を広く保護したい |
| 注意点 | 同一ノードPod通信やノード発信通信は対象外 | 対応SKUやサポート対象シナリオの確認が必要 |
判断基準はシンプルです。
AKSのPod間通信を重点的に保護したい場合は、WireGuard in-transit encryptionを優先的に検討します。特に、既にAzure CNI powered by Ciliumを使っている、または今後Ciliumベースへ移行する予定があるなら、導入候補に入りやすい機能です。
一方、VNet内のVM間通信全体を広く暗号化したい場合は、Azure Virtual Network encryptionを検討します。ただし、Virtual Network encryptionには対応VM SKUや利用シナリオ上の制約があるため、AKSの構成と合わせて確認が必要です。Microsoft Learnでは、AKSに関するVirtual Network encryptionのサポート状況もネットワーク構成によって異なると説明されています。(Microsoft Learn)
導入前に確認すべきチェックリスト
WireGuard in-transit encryption for AKSは便利な機能ですが、設定フラグを入れるだけで安全になるわけではありません。導入前に、次の項目を確認してください。
| 確認項目 | 確認内容 | 見落とすと起きる問題 |
|---|---|---|
| ネットワークプラグイン | Azure CNI powered by Ciliumか | そもそもWireGuardを有効化できない |
| Advanced Container Networking Services | 有効化済みか、費用を許容できるか | 想定外のコストや承認漏れが起きる |
| Azure CLI | 2.71.0以上か | コマンドが利用できない可能性がある |
| UDP 51871 | ノードIP間で許可されているか | WireGuardトンネルが成立しない |
| 既存クラスター更新 | メンテナンス時間帯を確保しているか | Ciliumエージェント再起動で一時影響が出る可能性がある |
| 性能検証 | レイテンシ、スループット、CPU使用率を測るか | 本番後に性能劣化が発覚する |
| FIPS要件 | FIPS準拠が必須か | WireGuardはFIPS準拠ではないため要件不一致になる |
hostNetwork Pod | 対象ワークロードに含まれるか | 暗号化対象と誤認する |
| ネットワークポリシー併用 | 併用時の性能影響を確認するか | レイテンシ増加やスループット低下を見落とす |
Microsoft Learnでは、WireGuard encryptionはAzure CNI powered by Ciliumでのみサポートされ、UDP 51871を各AKSノード間で許可する必要があると説明されています。また、Advanced Container Networking Servicesは有料オファリングです。(Microsoft Learn)
さらに、WireGuardはソフトウェアレベルで動作するため、レイテンシやスループットに影響する可能性があります。Microsoft Learnでは、ワークロード特性やクラスター構成により結果は変わるため、レイテンシやスループットに敏感なアプリケーションでは非本番環境で評価することが推奨されています。(Microsoft Learn)
新規AKSクラスターで有効化する手順
新規クラスターでWireGuard in-transit encryptionを使う場合は、Azure CNI、Ciliumデータプレーン、Advanced Container Networking Services、WireGuard暗号化タイプをまとめて指定します。Microsoft Learnの手順では、--enable-acns と --acns-transit-encryption-type wireguard を使います。(Microsoft Learn)
export CLUSTER_NAME="<aks-cluster-name>"
export RESOURCE_GROUP="<resource-group-name>"
az aks create \
--name $CLUSTER_NAME \
--resource-group $RESOURCE_GROUP \
--location eastus \
--network-plugin azure \
--network-plugin-mode overlay \
--network-dataplane cilium \
--enable-acns \
--acns-transit-encryption-type wireguard \
--generate-ssh-keysポイントは、Advanced Container Networking Servicesを有効化しただけではWireGuardは有効にならないことです。WireGuardを使うには、暗号化タイプとして wireguard を明示する必要があります。
既存AKSクラスターで有効化する手順
既存クラスターに対して有効化する場合は、az aks update を使います。
export CLUSTER_NAME="<aks-cluster-name>"
export RESOURCE_GROUP="<resource-group-name>"
az aks update \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--enable-acns \
--acns-transit-encryption-type wireguardここで注意すべきなのは、既存クラスターでWireGuardを有効化すると、全ノードのCiliumエージェントに対してロールアウト再起動が発生することです。Microsoft Learnでは、大規模クラスターでは時間がかかる可能性があり、ワークロードに一時的な影響が出る可能性があるため、メンテナンス時間帯や低トラフィック時間帯での実施が推奨されています。(Microsoft Learn)
本番環境では、いきなり全体へ適用するのではなく、次の順序で進めると安全です。
- 開発またはステージング環境で有効化する
- Pod間通信の疎通、レイテンシ、スループットを測定する
- ネットワークポリシーや監視設定との相性を確認する
- メンテナンス時間帯に本番へ適用する
- 適用後にCiliumとWireGuardの状態を確認する
有効化後の確認方法
WireGuardが有効になっているかは、CiliumのデバッグCLIで確認できます。Microsoft Learnでは、Cilium Pod内で cilium-dbg encrypt status を実行して、暗号化状態を確認する手順が示されています。(Microsoft Learn)
kubectl -n kube-system exec -ti ds/cilium -- bash
cilium-dbg encrypt status期待する確認ポイントは次のとおりです。
Encryption: Wireguard
Interface: cilium_wg0
Number of peers: <ノード数 - 1>Number of peers は、基本的にノード数から1を引いた数になります。たとえば3ノード構成であれば、各ノードから見えるピア数は2になるのが目安です。
より詳細に確認したい場合は、次のコマンドでWireGuardピアの状態を確認します。
kubectl exec -n kube-system ds/cilium -- cilium-dbg debuginfo --output json | jq .encryption確認時は、listen-port が 51871 になっているか、peer-count が想定どおりか、last-handshake-time が更新されているかを見ます。通信できない場合は、まずノード間のUDP 51871がブロックされていないかを確認してください。
無効化する場合の手順
検証の結果、性能や要件に合わない場合は、WireGuardだけを無効化できます。
az aks update \
--resource-group $RESOURCE_GROUP \
--name $CLUSTER_NAME \
--enable-acns \
--acns-transit-encryption-type noneこのとき、Advanced Container Networking Services全体を無効化するのではなく、転送中暗号化タイプを none に戻す点がポイントです。Container Network ObservabilityやContainer Network Securityの他機能を継続利用している場合は、影響範囲を事前に確認してください。
失敗しやすいポイント
Advanced Container Networking Servicesを有効化しただけで満足してしまう
Advanced Container Networking Servicesを有効化しても、WireGuardはデフォルトでは有効になりません。--acns-transit-encryption-type wireguard を指定して初めてWireGuard暗号化が有効になります。(Microsoft Learn)
設定後は、必ず cilium-dbg encrypt status で状態を確認してください。管理画面やIaCの設定値だけを見て「有効になっているはず」と判断するのは危険です。
「AKS内の全通信が暗号化される」と誤解する
WireGuard in-transit encryptionの主な対象は、異なるノード上のPod間通信です。同一ノード上のPod間通信、ノード発信通信、hostNetwork: true のPod通信は対象外です。(Microsoft Learn)
監査資料や顧客説明では、「AKS内通信を暗号化」と雑に表現するのではなく、「異なるノード上のPod間通信を暗号化」と具体的に書くべきです。
性能検証をせずに本番へ適用する
WireGuardはソフトウェアベースの暗号化です。CPU使用率、レイテンシ、スループットに影響する可能性があります。特に、低レイテンシが求められるAPI、リアルタイム処理、データ転送量が多いバッチ、メッシュ状に通信するマイクロサービスでは、事前検証が欠かせません。
検証では、平均値だけでなく、p95、p99レイテンシ、CPU使用率、再送、タイムアウト率も確認してください。暗号化前後でアプリケーションのSLOに影響がないかを見ることが重要です。
FIPS要件を見落とす
Microsoft Learnでは、WireGuardはFIPS準拠ではないと明記されています。(Microsoft Learn)
政府機関、金融、医療、特定のグローバル規制対応などでFIPS準拠が必須の場合、WireGuardを採用できるかはセキュリティ部門や監査部門と確認する必要があります。「暗号化されるから要件を満たす」と判断しないでください。
既存クラスターへの適用を通常作業として扱う
既存AKSクラスターで有効化すると、Ciliumエージェントのロールアウト再起動が発生します。大規模クラスターでは時間がかかり、一時的な影響が出る可能性があります。(Microsoft Learn)
本番適用時は、変更管理、ロールバック手順、監視アラートの確認、関係者への通知まで含めて計画するべきです。
IT管理者とプロダクトオーナーが取るべき次の行動
今回のGAを受けて、すべてのAKSクラスターに即適用する必要はありません。まずは、セキュリティ要件とネットワーク構成に照らして、導入対象を選別するのが現実的です。
| 立場 | 次にやること |
|---|---|
| IT管理者 | 既存AKSクラスターのCNI、Cilium利用状況、ACNS有効化状況を棚卸しする |
| セキュリティ担当 | 転送中暗号化要件、FIPS要件、監査説明の粒度を確認する |
| プラットフォームエンジニア | 非本番クラスターでWireGuardを有効化し、性能と疎通を検証する |
| プロダクトオーナー | 対象サービスのリスク、追加コスト、リリース影響を判断する |
| SRE/運用担当 | 監視、トラブルシューティング手順、無効化手順をRunbook化する |
導入判断では、次の3つを基準にすると迷いにくくなります。
1つ目は、保護したい通信が本当に「異なるノード上のPod間通信」なのか。
対象外通信が多い場合、WireGuardだけでは期待する効果が得られません。
2つ目は、CiliumベースのAKSネットワークへ移行する価値があるか。
既にAzure CNI powered by Ciliumを使っているなら導入ハードルは低めです。一方、別のネットワークプラグインを使っている場合は、ネットワーク移行そのものの計画が必要です。
3つ目は、性能影響とコストを許容できるか。
Advanced Container Networking Servicesは有料であり、WireGuardはソフトウェアベースで性能影響が出る可能性があります。セキュリティ強化の価値と運用コストをセットで評価してください。
まとめ：AKSのWireGuard GAは「暗号化の選択肢」ではなく「設計見直しのきっかけ」
WireGuard in-transit encryption for AKSのGAは、Azure Kubernetes Serviceのネットワークセキュリティを強化するうえで重要な更新です。Azure CNI powered by CiliumとAdvanced Container Networking Servicesを利用するAKSクラスターでは、異なるノード上のPod間通信をアプリ改修なしで暗号化できます。
一方で、同一ノード上のPod間通信、ノード発信通信、hostNetwork Podは対象外です。さらに、FIPS非準拠、性能影響、UDP 51871の許可、既存クラスター更新時のCiliumエージェント再起動など、導入前に確認すべき点もあります。
まずは、対象クラスターのネットワーク構成を棚卸しし、非本番環境でWireGuardを有効化して性能と運用影響を測定してください。その結果をもとに、セキュリティ要件の高いワークロードから段階的に導入するのが、現実的で失敗しにくい進め方です。
コメント