2026年4月30日の Azure 公式ドキュメント更新「[APIM] Update virtual-network-reference port for cache」は、Azure API Management（APIM）を仮想ネットワーク内で運用している環境、とくに外部キャッシュに Azure Managed Redis を使う環境で確認すべき更新です。結論から言うと、APIM サブネットの NSG、Azure Firewall、NVA、IaC 定義に TCP 10000 の通信許可が反映されているかを確認してください。
この更新は、すべての APIM 利用者に即影響する変更ではありません。対象になりやすいのは、クラシック層の APIM を VNet にデプロイし、キャッシュポリシーで外部 Redis 互換キャッシュを使っている環境です。Microsoft Learn の該当リファレンスは、VNet にデプロイされたクラシック層の API Management インスタンス向けのネットワーク構成設定であり、v2 層の VNet 挿入は別ドキュメントで扱われます。(Microsoft Learn)
Azureの公式ドキュメント更新「[APIM] Update virtual-network-reference port for cache」で何が変わったか
今回の更新で注目すべき点は、APIM の VNet 構成リファレンスにあるキャッシュ関連ポートの記述です。GitHub の該当コミットでは articles/api-management/virtual-network-reference.md が更新され、外部キャッシュの説明が Azure Cache for Redis から Azure Managed Redis に寄せられました。あわせて ms.date も 2026年4月30日に更新されています。(GitHub)
現在の Microsoft Learn では、外部 Azure Managed Redis サービスへのキャッシュポリシー用通信として、Inbound & Outbound、送信元 VirtualNetwork、宛先 Virtual Network、宛先ポート 10000、プロトコル TCP、アクション Allow が記載されています。(Microsoft Learn)
| 確認項目 | 更新後の確認ポイント | 実務上の意味 |
|---|---|---|
| 外部キャッシュ用ポート | Azure Managed Redis 向けに TCP 10000 を確認 | NSG、Firewall、NVA、IaC の許可ルールを見直す |
| 内部キャッシュ用ポート | TCP 6381 – 6383 は内部キャッシュとして継続 | 既存の内部キャッシュ通信を誤って閉じない |
| 対象ドキュメント | APIM classic tiers の VNet デプロイ向け | v2 層や非 VNet 構成には同じ前提で適用しない |
| 必須度の見方 | キャッシュ関連行は optional とされる | APIM 全体の稼働ではなく、キャッシュ機能利用時に重要 |
注意したいのは、GitHub の最初のコミット 468a492 では追加行に 1000 と見える記述があり、その後同日の Port number コミットで 10000 に修正されている点です。運用設定に反映する場合は、単一コミットだけで判断せず、現在公開されている Microsoft Learn と最新のリポジトリ内容を確認してください。(GitHub)
影響を受けやすい環境
今回の Azure 公式ドキュメント更新で優先的に確認すべきなのは、次のような環境です。
- Azure API Management の Developer または Premium のクラシック層を VNet にデプロイしている
- External mode または Internal mode で APIM を運用している
- APIM のキャッシュポリシーで外部 Redis 互換キャッシュを使っている
- 外部キャッシュとして Azure Managed Redis を使っている、または移行予定がある
- APIM サブネットの NSG で既定拒否に近い制御をしている
- Azure Firewall、NVA、UDR、Private Endpoint、閉域網構成を組み合わせている
- Bicep、ARM テンプレート、Terraform などで NSG ルールをコード管理している
逆に、APIM を VNet にデプロイしていない環境、キャッシュポリシーを使っていない環境、外部キャッシュを構成していない環境では、今回のポート更新が直接の障害要因になる可能性は高くありません。ただし、将来的に Azure Managed Redis へ移行する予定がある場合は、移行前チェック項目に含めておくべきです。
TCP 10000を確認すべき理由
Azure API Management で外部キャッシュを使う場合、APIM は Redis 接続文字列を使ってキャッシュに接続します。Microsoft Learn では、Azure Managed Redis を使う場合、APIM から接続文字列を利用するためにアクセスキー認証を有効にする必要があり、現時点では APIM から Azure Managed Redis へ Microsoft Entra 認証で接続できないと説明されています。(Microsoft Learn)
また、同じドキュメントでは既定の接続文字列の形式として <cache-name>:10000,password=<cache-access-key>,ssl=True,abortConnect=False が示されています。つまり、Azure Managed Redis を APIM の外部キャッシュとして使う場合、ポート 10000 は接続文字列とネットワーク許可の両方で整合している必要があります。(Microsoft Learn)
設定が合っていない場合、APIM の本体は起動していても、キャッシュ参照やキャッシュ保存だけが失敗することがあります。たとえば、レスポンスキャッシュのヒット率が急に下がる、バックエンドへのリクエスト数が増える、ポリシー実行時に外部キャッシュ接続エラーが出る、といった形で表面化します。
まず確認するべき設定
APIMが該当する構成か確認する
最初に、APIM インスタンスが今回のリファレンスの対象かを確認します。
| 確認項目 | 見る場所の例 | 判断基準 |
|---|---|---|
| APIM の層 | Azure portal の APIM 概要 | Developer または Premium のクラシック層か |
| VNet 構成 | APIM の Network 設定 | External または Internal mode で VNet にデプロイされているか |
| 外部キャッシュ | Deployment + infrastructure > External cache | Azure Managed Redis または Redis 互換キャッシュが登録されているか |
| キャッシュポリシー | API、Product、Global の policy | cache-lookup、cache-store、cache-lookup-value、cache-store-value などを使っているか |
| リージョン設定 | External cache の Use from | Default、特定リージョン、セルフホステッドゲートウェイのどれか |
外部キャッシュの Use from は見落としやすいポイントです。APIM では Default のキャッシュ設定を使う場合もあれば、特定リージョンの設定が Default を上書きする場合もあります。マルチリージョン構成では、すべてのリージョンで同じキャッシュ設定が使われるとは限りません。(Microsoft Learn)
NSGでTCP 10000が許可されているか確認する
APIM サブネットに NSG を適用している場合は、少なくとも次の観点で確認します。
| 方向 | 確認する通信 | ポート | 注意点 |
|---|---|---|---|
| 送信 | APIM サブネットからキャッシュ側への通信 | TCP 10000 | Azure Managed Redis を外部キャッシュに使う場合に重要 |
| 受信 | VNet 内から APIM サブネット側への関連通信 | TCP 10000 | 公式表では Inbound & Outbound とされているため、片方向だけで判断しない |
| 送受信 | 内部キャッシュ関連 | TCP 6381 – 6383 | 外部キャッシュ更新と混同して削除しない |
| 送受信 | Rate limit の同期カウンター | UDP 4290 | キャッシュとは別だが、近い行にあるため変更時に巻き込まない |
NSG ルールを修正する場合は、既存の広い許可ルールに依存しているのか、明示的に TCP 10000 を許可する必要があるのかを分けて確認してください。とくに「Deny All Outbound」に近い設計をしている環境では、ドキュメント更新が障害予防の重要なシグナルになります。
Azure FirewallやNVAも確認する
APIM サブネットの NSG だけを直しても、途中に Azure Firewall や NVA がある場合は通信が止まることがあります。次のような構成では、NSG とあわせて経路上の制御ポイントも確認してください。
| 構成 | 確認ポイント |
|---|---|
| Azure Firewall 経由 | APIM サブネットからキャッシュの宛先へ TCP 10000 が許可されているか |
| NVA 経由 | ルーティング後の実通信ログで TCP 10000 が拒否されていないか |
| Private Endpoint 利用 | 名前解決がプライベート IP に向いているか、通信先 IP が想定どおりか |
| VNet ピアリング | VirtualNetwork として許可した範囲に実際の通信先が含まれるか |
| マルチリージョン | 各リージョンの APIM とキャッシュの組み合わせごとに許可されているか |
ログを見るときは、APIM 側のポリシーエラーだけでなく、Firewall の deny ログ、NSG フローログ、キャッシュ側の接続メトリックを合わせて確認すると原因を切り分けやすくなります。
移行準備として見るべきポイント
今回の更新は、単なるポート番号の修正だけではなく、Azure Managed Redis への移行準備という文脈でも重要です。Microsoft は Azure Cache for Redis の Basic、Standard、Premium レベルを 2028年9月30日に廃止し、Azure Managed Redis への移行を推奨しています。また、Enterprise および Enterprise Flash レベルは 2027年3月31日に廃止される予定です。(Microsoft Learn)
APIM の外部キャッシュとして Azure Cache for Redis を使っている場合、Azure Managed Redis へ移行するときに「接続文字列だけ差し替えれば終わり」と考えるのは危険です。次の項目を移行計画に含めてください。
| 移行時の確認項目 | 具体的に見る内容 |
|---|---|
| 接続文字列 | ホスト名、ポート、アクセスキー、ssl=True の整合性 |
| 認証方式 | APIM から Azure Managed Redis へ接続する場合、アクセスキー認証が必要か |
| ネットワーク許可 | TCP 10000 が NSG、Firewall、NVA で許可されているか |
| キャッシュポリシー | 既存の cache-lookup や cache-store が移行後も意図どおり動くか |
| リージョン設定 | Default とリージョン別キャッシュの優先関係が変わらないか |
| IaC | Terraform、Bicep、ARM テンプレートのポート定義が古くないか |
| 監視 | キャッシュヒット率、バックエンド負荷、接続失敗ログを移行前後で比較できるか |
移行テストでは、単に APIM からバックエンド API が呼べるかだけでなく、キャッシュヒット時とキャッシュミス時の両方を確認します。キャッシュが効いていない状態でも API は返ることがあるため、レスポンス時間、バックエンド呼び出し回数、キャッシュ側メトリックを見ないと失敗に気づきにくいからです。
失敗しやすいポイント
6380をすべて10000に置き換えてしまう
今回の更新は、Azure Managed Redis を APIM の外部キャッシュとして使う場合に TCP 10000 を確認する話です。すべての Redis 互換キャッシュ、すべての既存 Redis 接続、すべてのアプリケーション設定を一律に 10000 へ置き換えるべきではありません。
カスタム Redis、既存の Azure Cache for Redis、社内 Redis、Kubernetes 上の Redis などは、それぞれ接続ポートが異なる場合があります。接続文字列、キャッシュの種類、通信経路を確認してから変更してください。
optionalを「不要」と読み替える
公式表の目的欄では、キャッシュ関連の構成は optional とされています。これは、APIM サービス全体の正常性に必須ではないという意味であり、キャッシュ機能を使っている環境でも不要という意味ではありません。
外部キャッシュを使うポリシーがあるなら、その機能にとっては必要な通信です。特に、本番環境でキャッシュを前提にバックエンド負荷を設計している場合、キャッシュ接続の失敗は性能問題やコスト増につながります。
468a492の差分だけを見て1000と判断する
該当コミットの差分だけを見ると、外部 Azure Managed Redis のポートが 1000 に見える箇所があります。しかし、その後の同日コミットで 10000 に修正され、現在の Microsoft Learn でも 10000 と記載されています。運用設定に反映する前に、必ず最新の公開ドキュメントを確認してください。(GitHub)
IaCだけ更新して実環境の経路を見ない
Terraform や Bicep の NSG 定義を更新しても、実際の通信が Azure Firewall や NVA を通る場合は、そこで拒否されることがあります。IaC のレビューでは「NSG に 10000 を足したか」だけでなく、「実際に APIM からキャッシュまで TCP 10000 が通るか」を確認しましょう。
運用チームが取るべき次のアクション
今回の Azure 公式ドキュメント更新を受けて、運用チームは次の順番で確認すると効率的です。
| 優先度 | アクション | 対象者 |
|---|---|---|
| 高 | APIM が VNet デプロイか、外部キャッシュを使っているか確認する | クラウド管理者、APIM 管理者 |
| 高 | APIM サブネットの NSG に TCP 10000 の許可が必要か確認する | ネットワーク管理者 |
| 高 | Azure Firewall、NVA、UDR、Private DNS の影響を確認する | ネットワーク管理者、アーキテクト |
| 中 | Terraform、Bicep、ARM テンプレートのポート定義を更新する | IaC 担当、DevOps |
| 中 | 移行計画に Azure Managed Redis の接続文字列とポート確認を追加する | ソリューションアーキテクト |
| 中 | キャッシュヒット率、APIM ポリシーエラー、バックエンド負荷を監視する | SRE、運用担当 |
| 低 | 内部キャッシュ用 TCP 6381 – 6383 を誤って削除していないか棚卸しする | クラウド管理者 |
最初にやるべきことは、APIM の外部キャッシュ設定とネットワーク制御の棚卸しです。Azure Managed Redis を使っている、または移行予定がある場合は、TCP 10000 を NSG、Firewall、NVA、IaC、監視項目のすべてで確認してください。今回の更新は小さなドキュメント変更に見えますが、閉域網やゼロトラスト寄りの設計では、キャッシュ機能の可用性に直結する確認ポイントです。
コメント