2026年5月28日のAzure Networking更新で、Application Gateway for ContainersのIstioサービスメッシュ連携が一般提供（GA）になりました。結論から言うと、AKSなどのKubernetes上でIstioサービスメッシュを使っている環境では、外部からメッシュ内サービスへ入る南北トラフィックを、Application Gateway for Containers経由でより扱いやすく、安全に構成しやすくなります。
特に重要なのは、Application Gateway for ContainersとIstioメッシュ内サービス間のmTLS接続や証明書ライフサイクル管理を、ALB Controller Service Mesh Extensionで自動化できる点です。これまでIngress側でmTLSを個別に構成していた環境では、証明書ローテーションや設定重複の運用負荷を下げられる可能性があります。一方で、Gateway APIの利用が前提で、Ingress APIやIstio Ambient modeは対象外です。導入前に、Istioのバージョン、namespaceラベル、Gateway/HTTPRouteの設計を必ず確認しましょう。Azure Updatesではこの機能がApplication Gatewayの一般提供機能として掲載されており、Azureの「Launched」は実稼働対応として提供されるステータスです。(Microsoft Azure)
Azure Networkingの更新で何が変わったのか
今回の更新は、Application Gateway for ContainersをIstioサービスメッシュの入口として使いやすくするものです。
Application Gateway for Containersは、Kubernetesクラスターで動作するワークロード向けのレイヤー7負荷分散と動的トラフィック管理を担うAzureのサービスです。AKSのIngress/ Gateway設計で使われ、HTTP/HTTPSルーティング、mTLS、gRPC、WAF、WebSocketなどの機能をサポートします。(Microsoft Learn)
Istioのようなサービスメッシュは、主にサービス間の東西トラフィックを扱い、セキュリティ目的でmTLSを使うことが多い仕組みです。外部からメッシュ内サービスへ入る南北トラフィックでは、入口となるゲートウェイの構成が必要になります。Microsoft Learnでは、Application Gateway for Containersがサービスメッシュ拡張機能を提供し、証明書ライフサイクル管理の自動化と構成複雑性の軽減を目的としていると説明されています。(Microsoft Learn)
| 変更点 | これまで起きやすかった課題 | GA後に期待できる効果 |
|---|---|---|
| Istioサービスメッシュ連携がGA | プレビュー機能としての採用判断が難しい | 本番導入の検討対象にしやすい |
| mTLS接続の自動化 | Ingress側でmTLS設定が重複しやすい | Application Gateway for Containersとメッシュ内サービス間の保護を標準化しやすい |
| 証明書ライフサイクル管理の自動化 | 証明書ローテーション時の手作業や設定漏れが発生しやすい | 運用負荷と人的ミスを減らしやすい |
| ALB Controller Service Mesh Extensionを利用 | コントローラー、証明書、Istio設定の責務が分散しやすい | 拡張機能によりIstio連携の構成を整理しやすい |
| Gateway APIが前提 | Ingress API中心の既存構成ではそのまま使えない | Gateway APIへの移行計画が必要 |
対象になる環境と、すぐに影響を受けにくい環境
この更新の対象は、すべてのAzure利用者ではありません。影響が大きいのは、AKSまたはKubernetes上でApplication Gateway for ContainersとIstioを組み合わせている、または組み合わせる予定があるチームです。
| 現在の構成 | 影響度 | 確認すべきこと |
|---|---|---|
| Application Gateway for Containersを使っていない | 低 | すぐに設定変更は不要。今後AKSの入口設計を見直す際の選択肢として確認 |
| Application Gateway for Containersは使っているがIstioは使っていない | 低〜中 | サービスメッシュ導入予定がなければ急ぎの対応は不要 |
| Istioサービスメッシュを使っている | 中 | 外部公開経路がIstio Ingress Gatewayなのか、Application Gateway for Containersなのかを整理 |
| Application Gateway for ContainersとIstioを併用している | 高 | ALB Controller Service Mesh Extension、Gateway API、mTLS設定を確認 |
| Ingress API中心で構成している | 高 | この連携ではGateway APIが必要。移行方針を検討 |
| Istio Ambient modeを使っている、または検討している | 高 | 今回の連携はsidecarベースのIstioを前提としており、Ambient modeはサポート対象外 |
Microsoft Learnでは、ALB Controller Service Mesh Extensionを使うにはGateway APIでIngress意図を定義する必要があり、Ingress APIはサポートされないと明記されています。また、この統合はIstioのsidecarベースのサービスメッシュを前提とし、Ambient modeはサポートされません。(Microsoft Learn)
管理者が最初に確認すべきポイント
管理者は、いきなりHelm chartを入れるのではなく、まず既存環境が前提条件を満たしているかを確認しましょう。特に重要なのは、Istioの方式、Gateway APIの利用状況、ALB Controllerの導入状態です。
| 確認項目 | 判断基準 | 確認例 |
|---|---|---|
| Istioのバージョン | Istio v1.24以上か | istioctl version、AKS add-onのrevision確認 |
| Istioの方式 | sidecarベースか | Ambient modeの場合は対象外 |
| ALB Controller | Application Gateway for Containersを管理できる状態か | kubectl get pods -n azure-alb-system |
| API方式 | Gateway APIで設計できているか | Gateway、HTTPRouteリソースの有無 |
| namespaceラベル | Istio injection用ラベルが正しいか | OSS IstioとAKS Istio add-onでラベルが異なる |
| mTLS方針 | メッシュ参加サービスでmTLSを強制するか | PeerAuthenticationの設計 |
| 本番影響 | 既存Ingress経路と重複しないか | DNS、証明書、フロントエンドIP、ヘルスチェックを確認 |
Application Gateway for ContainersのIstio連携は、Istio v1.24以上をサポートします。さらに、ALB Controller Service Mesh ExtensionをIstioより先に入れた場合は、Istio導入後に拡張機能のDeploymentを再起動する必要があります。(Microsoft Learn)
ALB Controller Service Mesh Extensionの役割
今回の中心になるのが、ALB Controller Service Mesh Extensionです。
この拡張機能は、ALB Controllerとは別のHelm chartで導入します。Microsoft Learnでは、拡張機能は2つのPodで構成され、active/standby構成によりノード障害時の回復性を確保しつつ、Application Gateway for ContainersとIstio間の証明書ライフサイクル管理、メッシュ参加サービスへのmTLS構成を暗黙的に扱うと説明されています。(Microsoft Learn)
実務上は、次のように役割を分けて考えると理解しやすくなります。
| コンポーネント | 主な役割 |
|---|---|
| Application Gateway for Containers | 外部からのHTTP/HTTPSトラフィックを受け、Kubernetes内のバックエンドへルーティング |
| ALB Controller | KubernetesのGateway APIリソースを監視し、Azure側のApplication Gateway for Containersリソースへ反映 |
| ALB Controller Service Mesh Extension | Istioメッシュとの連携、mTLS構成、証明書ライフサイクル管理を支援 |
| Istio sidecar | サービス間通信の制御、mTLS、可観測性、トラフィック制御を担当 |
| Gateway / HTTPRoute | 入口、リスナー、ルーティング先を宣言的に定義 |
この構成では、Application Gateway for Containersを「メッシュの外側にある入口」、Istioを「メッシュ内部の通信制御」として分離できます。これにより、外部公開の制御をAzure Networking側に寄せつつ、サービス間通信のセキュリティや可観測性はIstioに任せる設計が取りやすくなります。
開発者が確認すべき設定
開発者やプラットフォームエンジニアが注意すべきなのは、アプリケーションコードよりもKubernetesリソースの設計です。今回の機能は、アプリに直接SDKを組み込むものではありません。Gateway API、HTTPRoute、namespaceラベル、IstioのPeerAuthenticationが主な確認対象です。
namespaceラベルの違いに注意する
Istioのsidecar injectionを有効化するラベルは、利用しているIstioの種類によって異なります。
オープンソースIstioでは、一般的に次のようなラベルを使います。
apiVersion: v1
kind: Namespace
metadata:
name: app-prod
labels:
istio-injection: enabled一方、AKSのIstio add-onでは、インストールされたIstio revisionに対応するistio.io/revラベルを使います。Microsoft Learnの例では、asm-1-27のようなrevisionが示されています。(Microsoft Learn)
apiVersion: v1
kind: Namespace
metadata:
name: app-prod
labels:
istio.io/rev: asm-1-27ここを間違えると、Podにsidecarが注入されず、mTLS前提の通信が成立しない可能性があります。特に、開発環境ではオープンソースIstio、本番環境ではAKS Istio add-onというように環境差がある場合は、マニフェストをそのまま流用しないでください。
mTLSを強制する範囲を明確にする
メッシュ内サービスでmTLSを強制する場合、IstioのPeerAuthenticationを使います。Microsoft Learnの例では、対象namespaceでmode: STRICTを指定しています。(Microsoft Learn)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: app-prod
spec:
mtls:
mode: STRICT注意点は、mTLSを強制する範囲です。namespace全体に適用すると、そのnamespace内のサービスはmTLS前提になります。まだsidecar化できていないPod、外部監視ツール、古いジョブが同じnamespaceにいると通信失敗の原因になります。
本番導入では、まず次の順番で確認すると安全です。
| 順序 | 確認内容 | 失敗しやすいポイント |
| -: | ———————– | ———————————– |
| 1 | 対象namespaceを分ける | 既存Podを巻き込んでmTLS必須化してしまう |
| 2 | sidecar injectionを有効化 | ラベル違いでsidecarが入らない |
| 3 | テスト用HTTPRouteで疎通確認 | Gatewayは正常でもHTTPRouteがAcceptedにならない |
| 4 | PeerAuthenticationを適用 | STRICT化後に一部Podだけ通信できなくなる |
| 5 | 本番DNSや証明書を切り替え | 旧Ingress経路と新経路が並行して混乱する |
Gateway APIへの移行が必要なケース
既存環境でKubernetes Ingress APIを中心に運用している場合、今回のIstio連携をそのまま有効化できるとは限りません。ALB Controller Service Mesh ExtensionではGateway APIが必要で、Ingress APIはサポートされないためです。(Microsoft Learn)
移行時は、IngressをHTTPRouteへ機械的に置き換えるだけでは不十分です。次の観点で設計を見直しましょう。
| Ingress APIで見ていた項目 | Gateway APIで整理する項目 |
|---|---|
| host/pathベースのルーティング | GatewayのlistenerとHTTPRouteのrules |
| TLS終端 | Gateway listenerのHTTPS設定 |
| backend service | HTTPRouteのbackendRefs |
| namespaceをまたぐ参照 | allowedRoutesやReferenceGrant |
| 入口の所有者 | インフラ管理者がGateway、アプリチームがHTTPRouteを管理する分担 |
Gateway APIの利点は、インフラ側の入口定義とアプリ側のルーティング定義を分離しやすいことです。たとえば、プラットフォームチームがGatewayを管理し、各アプリチームが自分のnamespace内でHTTPRouteを管理する設計にすると、権限分離と変更レビューがしやすくなります。
導入手順の全体像
実際の導入では、Microsoft Learnの手順に沿って進めるのが基本です。大きな流れは、ALB Controllerの準備、Service Mesh Extensionの導入、Istio側のnamespace/mTLS設定、Gateway/HTTPRouteの作成、状態確認です。公式手順でも、Istioサービスメッシュへトラフィックをルーティングするために、namespace定義、mTLS有効化、Gateway、HTTPRouteの作成が示されています。(Microsoft Learn)
| ステップ | 作業内容 | 管理者・開発者の注意点 |
|---|---|---|
| 1 | Application Gateway for ContainersとALB Controllerを用意 | add-onかHelmか、管理方式を決める |
| 2 | ALB Controller Service Mesh Extensionを導入 | ALB Controllerとは別のHelm chartで導入 |
| 3 | 拡張機能Podを確認 | alb-controller-istio-extensionのPodがReadyか確認 |
| 4 | Istio対象namespaceを定義 | OSS IstioかAKS add-onかでラベルを変える |
| 5 | mTLS方針を設定 | PeerAuthenticationでSTRICT化する範囲を限定 |
| 6 | Gatewayを作成 | ALB managedかBYOかでannotationやfrontend指定が変わる |
| 7 | HTTPRouteを作成 | backend service名、port、namespace参照を確認 |
| 8 | 状態を確認 | Accepted、Programmed、ResolvedRefsを見る |
| 9 | 疎通と監視を確認 | HTTPステータス、Istio telemetry、ログ、証明書ローテーション時の挙動を確認 |
確認コマンドの例は次のとおりです。
kubectl get pods -n azure-alb-system
kubectl get gateway -A
kubectl get httproute -A
kubectl get peerauthentication -AGateway作成後は、Gatewayのstatusにアドレスが割り当てられ、AcceptedやProgrammedがTrueになっていることを確認します。HTTPRoute作成後も、ルートがAcceptedでApplication Gateway for Containers側がProgrammedになっていることを確認する流れが公式手順で示されています。(Microsoft Learn)
ALB managedとBYOのどちらを選ぶべきか
Application Gateway for Containersには、ALB ControllerにAzureリソースのライフサイクルを管理させる方式と、Azure側のリソースを事前に用意してKubernetesから参照するBYO方式があります。Microsoft Learnでは、ALB Controller管理方式とBring your own（BYO）デプロイの2つが説明されています。(Microsoft Learn)
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| ALB managed | 検証環境、Kubernetes側で完結したい環境、プラットフォームチームが標準化したい環境 | Azure側のfrontend名が自動生成になる場合がある |
| BYO | 本番環境、命名規則やAzureリソース管理を厳密にしたい環境、既存の運用ルールに合わせたい環境 | AzureリソースとKubernetesリソースの対応管理が必要 |
公式手順では、ALB ControllerがAzure Resource Manager上にApplication Gateway for Containersリソースを作成する場合、frontendリソース名はfe-<8文字のランダム文字列>の形式になると説明されています。frontend名を制御したい場合はBYOデプロイ戦略を検討します。(Microsoft Learn)
本番環境では、DNS、証明書、監視、IaC、監査ログの都合でリソース名が重要になることがあります。その場合、最初からBYOを選んだ方が後の移行コストを抑えられます。
既存環境から移行する際の注意点
既にIstio Ingress Gatewayや別のIngress Controllerで外部公開している場合、Application Gateway for Containersへの切り替えは「入口の置き換え」になります。アプリケーションのコンテナは変えなくても、DNS、TLS、mTLS、ヘルスチェック、ルーティング条件が変わるため、段階的に進めるべきです。
特に失敗しやすいのは次の5つです。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| Ingress APIのまま進める | Service Mesh Extensionが前提を満たさない | Gateway APIへ移行する |
| namespaceラベルを間違える | sidecarが注入されずmTLS通信が失敗する | OSS IstioとAKS add-onのラベル差分を確認 |
| mTLS STRICT化を急ぐ | 一部Podやジョブが通信不能になる | 対象namespaceを分け、段階的に有効化 |
| 旧Ingressと新GatewayのDNSが混在 | どちらに通信しているか分からなくなる | 検証用ホスト名を用意してから本番切替 |
| 証明書ローテーションの確認を省く | 本番運用後に期限切れや更新失敗に気づく | 短期検証用証明書で更新挙動を確認 |
移行時は、まず検証用ホスト名でApplication Gateway for Containers経由のルートを作り、メッシュ内サービスへのmTLS通信が成立することを確認します。その後、トラフィックの一部だけを新経路へ向ける、またはメンテナンス時間帯にDNSを切り替えるなど、切り戻し可能な形で進めるのが現実的です。
セキュリティ面で見るべきポイント
今回のGAは「mTLSが使えるようになった」というだけではありません。実務では、誰が入口を管理し、どこでTLSを終端し、どの区間をmTLSで保護するかを整理することが重要です。
おすすめは、通信経路を次のように分解して確認することです。
| 区間 | 主な確認点 |
|---|---|
| クライアント → Application Gateway for Containers | HTTPS、証明書、WAF、許可するホスト名 |
| Application Gateway for Containers → Istioメッシュ内サービス | Service Mesh ExtensionによるmTLS、対象namespace、Backend設定 |
| サービス間通信 | IstioのmTLS、AuthorizationPolicy、Telemetry |
| 運用者アクセス | Gateway/HTTPRouteを変更できるRBAC、Azure側の権限 |
| 監査・監視 | Application Gateway for Containersのログ、Istio telemetry、アラート |
mTLSを導入しても、すべてのセキュリティ課題が自動で解決するわけではありません。たとえば、HTTPRouteを誰でも変更できる状態では、意図しないbackendへトラフィックを流せてしまう可能性があります。Kubernetes RBACで、Gatewayを触れるチームとHTTPRouteを触れるチームを分ける設計が有効です。
開発・運用チーム別のアクション
最後に、チームごとに次に取るべき行動を整理します。
| 役割 | すぐ確認すること | 次のアクション |
|---|---|---|
| Azure管理者 | Application Gateway for Containersの利用有無、リージョン、ALB管理方式 | BYOかALB managedかを決め、IaC管理方針を整理 |
| AKS管理者 | Istioの方式、version、ALB Controllerの状態 | Service Mesh Extension導入の検証環境を用意 |
| アプリ開発者 | Service、port、HTTPRouteのbackendRefs | Ingress定義をHTTPRouteへ移行できるか確認 |
| セキュリティ担当 | mTLS範囲、証明書、WAF、権限分離 | namespace単位のmTLS強制範囲とRBACをレビュー |
| SRE/運用担当 | 監視、ログ、切り戻し手順 | Accepted/Programmed状態、5xx、レイテンシを監視対象に追加 |
今回の「Application Gateway for Containers – Service Mesh integration with Istio」のGAは、Istioメッシュを使うAKS環境にとって、外部公開とmTLS運用を整理する良いタイミングです。まずは既存のIngress経路、Istio方式、namespaceラベル、Gateway API対応状況を棚卸ししてください。そのうえで、検証環境にALB Controller Service Mesh Extensionを入れ、Gateway/HTTPRouteとmTLSの動作を確認するのが最初の一歩です。
コメント