Azureの公式ドキュメント更新「Port number」で最初に確認すべき点は、Azure API Management の VNet 構成リファレンスにあるポート番号の修正です。今回の更新では、外部 Azure Managed Redis をキャッシュ用途で利用する通信について、ポート番号が 1000 ではなく 10000 と記載されるようになりました。GitHub上の差分でも、対象ファイルは articles/api-management/virtual-network-reference.md の1ファイルで、該当行のポート番号が 1000 から 10000 に変更されています。(GitHub)
結論として、Azure API Management を VNet 内で利用しており、外部キャッシュとして Azure Managed Redis または Redis 互換キャッシュを使っている環境では、NSG、Azure Firewall、NVA、IaCテンプレート、運用手順書に TCP 10000 の許可設定が反映されているかを確認してください。一方で、このコミットだけを根拠に「Azure全体でポート要件が変わった」「強制移行が始まった」と判断するのは早計です。まずは自社環境が該当するかを切り分け、必要な範囲だけを変更するのが安全です。
Azureの公式ドキュメント更新「Port number」で何が変わったか
今回の「Port number」は、Azure API Management の仮想ネットワーク構成リファレンスに対する更新です。Microsoft Learnの該当ページは、VNetにデプロイされた API Management インスタンスのネットワーク構成を説明するもので、ページ上では対象が Developer と Premium と示されています。また、同ページではこのリファレンスが VNet にデプロイされた classic tiers の API Management インスタンス向けであり、v2 tiers の VNet injection については別のドキュメントを参照するよう案内されています。(Microsoft Learn)
変更の中心は、Required ports の表にある次の行です。
| 確認項目 | 内容 |
|---|---|
| 対象サービス | Azure API Management |
| 対象構成 | VNetにデプロイされた API Management |
| 対象ドキュメント | Virtual network configuration reference: API Management |
| 変更箇所 | 外部 Azure Managed Redis を使うキャッシュ関連通信のポート番号 |
| 変更前 | 1000 |
| 変更後 | 10000 |
| 通信方向 | Inbound & Outbound |
| 送信元 | VirtualNetwork |
| 宛先 | Virtual Network |
| プロトコル | TCP |
| 用途 | caching policies between machines のための外部 Azure Managed Redis へのアクセス |
| VNetタイプ | External & Internal |
Microsoft Learnの現在の表では、外部 Azure Managed Redis service for caching policies between machines の宛先ポート範囲が 10000、プロトコルが TCP、通信方向が Inbound & Outbound と記載されています。(Microsoft Learn)
この変更は、API Management の外部キャッシュ設定とも整合します。Microsoft Learnの外部 Redis 互換キャッシュ設定では、Azure Managed Redis を使う場合の既定の接続文字列が <cache-name>:10000,password=<cache-access-key>,ssl=True,abortConnect=False の形式で示されています。(Microsoft Learn)
この更新を「単なる1行修正」と見過ごしてはいけない理由
GitHubの差分だけを見ると、変更は1行です。しかし、Azureのネットワーク設定では、ポート番号の1桁違いが実際の通信断につながることがあります。
Azure API Management を VNet 内に配置している場合、NSGでサブネットへの入出力通信を制御します。Microsoft Learnでは、必要なポートが利用できない場合、API Management が正常に動作しなかったり、アクセス不能になったりする可能性があると説明されています。(Microsoft Learn)
特に注意したいのは、次のような環境です。
| 環境 | 確認すべき理由 |
|---|---|
| NSGで必要ポートだけを明示的に許可している | 1000 のみ許可し、10000 が未許可の可能性がある |
| Azure FirewallやNVAで東西トラフィックを制御している | NSGでは許可済みでも、経路上の別機器でブロックされる可能性がある |
| Bicep、ARM、TerraformでNSGルールを管理している | 古いドキュメントを元に 1000 をコード化している可能性がある |
| 外部 Azure Managed Redis を API Management のキャッシュに使っている | 今回の変更箇所に直接関係する |
| 複数リージョンでAPI Managementを運用している | リージョンごとのNSG、Firewall、外部キャッシュ設定に差分が出やすい |
| 運用手順書や監査チェックリストにポート番号を書いている | ドキュメント更新後も社内資料だけ古いまま残りやすい |
逆に、API Management をVNetに入れていない環境、外部キャッシュを使っていない環境、または対象ドキュメントとは別扱いのv2 tiers構成では、今回の更新をそのまま適用すべきとは限りません。まずは対象サービス、SKU、VNet構成、キャッシュ構成を確認してください。
影響を受ける可能性が高いケース
今回のAzure公式ドキュメント更新「Port number」で、実務上の確認優先度が高いのは次のケースです。
API ManagementをVNetにデプロイしている
対象ドキュメントは、API Management インスタンスを Azure 仮想ネットワークにデプロイした場合のネットワーク構成リファレンスです。該当ページでは、外部モードまたは内部モードのVNetに注入された API Management インスタンスの詳細なネットワーク構成を扱うと説明されています。(Microsoft Learn)
確認すべきポイントは、API Management のネットワーク構成が次のどちらに該当するかです。
| 構成 | 確認ポイント |
|---|---|
| External VNet mode | インターネット向けのAPI公開に加え、VNet内通信や外部キャッシュ通信が制御されているか |
| Internal VNet mode | 内部向けAPI基盤として、APIMサブネットからRedis側へ TCP 10000 が通るか |
| VNet未使用 | 今回のポート表の影響は限定的。別のネットワーク要件を確認する |
| v2 tiersのVNet injection | 対象ドキュメントをそのまま適用せず、v2 tiers向けの最新ドキュメントを確認する |
外部Redis互換キャッシュを使っている
API Management では、組み込みキャッシュに加えて、Azure Managed Redis などの外部 Redis 互換キャッシュを利用できます。外部キャッシュは、組み込みキャッシュの制約を補い、より大きなキャッシュ容量や構成管理の自由度を得たい場合に使われます。(Microsoft Learn)
特に、以下のようなポリシーや機能を使っている場合は確認が必要です。
| 利用機能 | 確認内容 |
|---|---|
cache-lookup / cache-store | レスポンスキャッシュで外部キャッシュを参照しているか |
cache-lookup-value / cache-store-value | 任意の値を外部キャッシュに保存・取得しているか |
caching-type="external" | 外部キャッシュを明示指定しているか |
caching-type="prefer-external" | 外部キャッシュが設定されている場合に優先利用されるか |
| Azure OpenAI APIのキャッシュ設計 | セマンティックキャッシュなどで外部キャッシュを利用していないか |
API Management のキャッシュ概要では、キャッシュには内部キャッシュと外部キャッシュがあり、外部キャッシュとして Azure Managed Redis などのRedis互換キャッシュを構成できると説明されています。(Microsoft Learn)
NSGやFirewallを厳格に制御している
セキュリティ要件が高い環境では、「VirtualNetwork同士なら何でも許可」ではなく、宛先ポートや送信元・宛先を細かく絞っていることがあります。この場合、古い設定で 1000 を許可していても、実際に必要な 10000 がブロックされる可能性があります。
AzureのNSGルールは優先度順に処理され、数値が小さいほど優先度が高く、通信がルールに一致すると以降のルールは処理されません。つまり、TCP 10000 の許可ルールを追加しても、それより高優先度の拒否ルールに一致していれば通信は通りません。(Microsoft Learn)
確認時は、単に「許可ルールがあるか」ではなく、次の条件まで見てください。
| 確認項目 | 見るべき内容 |
|---|---|
| Direction | Inbound と Outbound の両方で必要な通信が許可されているか |
| Protocol | TCPになっているか |
| Destination port | 10000 が含まれているか |
| Source / Destination | API ManagementサブネットとRedis側の通信範囲が合っているか |
| Priority | 拒否ルールより先に評価されるか |
| 適用場所 | サブネットNSG、NIC NSG、Azure Firewall、NVAのすべてで整合しているか |
| IaC | 手動変更だけでなく、BicepやTerraformにも反映されているか |
まず確認すべき設定項目
Azureの公式ドキュメント更新「Port number」を受けて、運用担当者が最初に行うべき確認は、影響範囲の棚卸しです。いきなり本番NSGを変更するのではなく、次の順番で確認すると安全です。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | API ManagementのSKUとVNet構成を確認 | Developer / Premium でVNetにデプロイされているか |
| 2 | 外部キャッシュ設定を確認 | Azure Managed Redis または Redis互換キャッシュを使っているか |
| 3 | ポリシーを確認 | cache-lookup、cache-store、cache-lookup-value、cache-store-value を使っているか |
| 4 | NSGルールを確認 | TCP 10000 が必要な方向で許可されているか |
| 5 | Firewall / NVAを確認 | NSG以外の経路制御でブロックされていないか |
| 6 | IaCと運用資料を確認 | 1000 の古い記載が残っていないか |
| 7 | 検証環境でテスト | キャッシュヒット、キャッシュミス、バックエンド負荷を確認 |
| 8 | 本番反映 | 変更管理に沿って段階的に適用する |
Azure CLIでAPI Managementの構成を確認する例
API Management のVNet構成やSKUは、Azure Portalで確認できます。CLIを使う場合は、次のように対象インスタンスの情報を取得できます。
az apim show \
--resource-group <resource-group-name> \
--name <apim-name> \
--query "{name:name, sku:sku.name, virtualNetworkType:virtualNetworkType, virtualNetworkConfiguration:virtualNetworkConfiguration}" \
-o jsonここで確認したいのは、virtualNetworkType がVNet利用を示す値になっているか、SKUが対象ドキュメントの範囲に該当するかです。v2 tiersを使っている場合は、今回のリファレンスだけで判断せず、v2 tiers向けのドキュメントを確認してください。
NSGルールを一覧する例
既存のNSGルールに 1000 だけが残っていないか、10000 が許可されているかを確認します。
az network nsg rule list \
--resource-group <resource-group-name> \
--nsg-name <nsg-name> \
--query "[].{name:name, priority:priority, direction:direction, access:access, protocol:protocol, source:sourceAddressPrefix, destination:destinationAddressPrefix, destinationPort:destinationPortRange, destinationPorts:destinationPortRanges}" \
-o table確認時は、destinationPort または destinationPorts に 10000 が含まれているかだけでなく、access が Allow か、direction が必要な方向と一致しているか、優先度の高いDenyルールに負けていないかを見てください。
TCP 10000 を許可する前に決めるべきこと
TCP 10000 が必要だと分かった場合でも、すぐに広い範囲で許可するのは避けるべきです。Azureのネットワーク設計では、可用性と最小権限のバランスを取る必要があります。
許可範囲をどこまで絞るか
Microsoft Learnでは、NSGやその他のネットワークルールでIPアドレスではなくサービス タグを使うことが推奨されています。これは、Azureのインフラ改善などでIPアドレスが変わる場合のダウンタイムを避けるためです。(Microsoft Learn)
ただし、すべてを VirtualNetwork で広く許可すればよいわけではありません。実務では、次の順に検討すると整理しやすくなります。
| 設計方針 | 向いているケース | 注意点 |
|---|---|---|
| サービス タグを使う | Azureサービス向けの通信を安定して管理したい | 対象サービスのタグが要件に合うか確認する |
| サブネットCIDRで絞る | APIMサブネットとRedis側サブネットが明確 | サブネット変更時にルール更新が必要 |
| Private Endpointや内部IPで絞る | Redis側の接続先を厳密に制御したい | 名前解決、ルーティング、Firewallルールも合わせて確認 |
| VirtualNetwork全体で許可 | 検証環境や暫定対応 | 本番では過剰許可になりやすい |
1000 の古いルールを削除してよいか
1000 のルールを見つけた場合でも、すぐ削除してはいけません。そのルールが API Management の外部キャッシュ用途だけに使われているとは限らないためです。
判断の目安は次のとおりです。
| 状況 | 推奨対応 |
|---|---|
| ルール名や説明にAPIM Redis用途と明記されている | 10000 への修正候補。ただし変更前に通信テストを行う |
| 他システムも同じNSGを共有している | 影響範囲を確認するまで削除しない |
| IaCで管理されている | 手動削除せず、コード側を修正して再デプロイする |
| 監査上の例外許可として登録されている | 変更履歴と承認フローを残す |
| 用途不明 | NSGフローログ、Firewallログ、担当チーム確認を行ってから判断する |
変更する場合のNSGルール例
以下は、TCP 10000 を許可するNSGルールの形式例です。実際の本番環境では、送信元・宛先・優先度を自社のネットワーク設計に合わせて調整してください。
az network nsg rule create \
--resource-group <resource-group-name> \
--nsg-name <nsg-name> \
--name Allow-APIM-Redis-10000-Inbound \
--priority 300 \
--direction Inbound \
--access Allow \
--protocol Tcp \
--source-address-prefixes VirtualNetwork \
--source-port-ranges '*' \
--destination-address-prefixes VirtualNetwork \
--destination-port-ranges 10000az network nsg rule create \
--resource-group <resource-group-name> \
--nsg-name <nsg-name> \
--name Allow-APIM-Redis-10000-Outbound \
--priority 301 \
--direction Outbound \
--access Allow \
--protocol Tcp \
--source-address-prefixes VirtualNetwork \
--source-port-ranges '*' \
--destination-address-prefixes VirtualNetwork \
--destination-port-ranges 10000この例では VirtualNetwork を広く指定していますが、セキュリティ要件が厳しい本番環境では、APIMサブネット、Redis側サブネット、Private Endpointの接続先などに絞り込むことを検討してください。また、優先度は既存ルールとの関係で決める必要があります。AzureのNSGでは、優先度の数値が小さいルールほど先に処理されます。(Microsoft Learn)
検証で見るべきポイント
ネットワーク変更後は、「APIが200を返したから問題なし」と判断しないことが重要です。API Management のキャッシュ関連処理は、キャッシュ接続に失敗してもAPI呼び出し自体がエラーにならない場合があります。Microsoft Learnでは、キャッシュ関連処理がキャッシュに接続できない場合でもAPI呼び出しはエラーを発生させず、読み取り操作ではポリシー式に null が返ると説明されています。(Microsoft Learn)
そのため、検証では次の観点を確認してください。
| 観点 | 確認内容 |
|---|---|
| キャッシュヒット | 2回目以降のリクエストでキャッシュが使われているか |
| キャッシュミス時の挙動 | バックエンドにフォールバックしても性能・負荷が許容範囲か |
| APIM Trace | cache-lookup や cache-store の結果が想定通りか |
| Application Insights | キャッシュ関連の失敗、バックエンド呼び出し増加、レイテンシ悪化がないか |
| Redis側メトリック | 接続数、拒否、タイムアウト、CPU、メモリの変化 |
| Firewall / NSGログ | TCP 10000 が拒否されていないか |
| 多リージョン | 各リージョンで同じように通信できるか |
API Management のキャッシュ設定では、キャッシュが利用できない場合にバックエンドへの負荷が増える可能性があります。Microsoft Learnでも、キャッシュ参照の直後に rate-limit または rate-limit-by-key ポリシーを構成し、キャッシュが利用できない場合のバックエンド過負荷を抑えることが推奨されています。(Microsoft Learn)
開発者が確認すべきポイント
開発者は、ネットワークルールだけでなく、API Management のポリシー定義を確認してください。外部キャッシュが使えない場合でもAPI自体が成功するケースがあるため、ポリシーのフォールバック設計が重要です。
確認する場所は主に次の3つです。
| 確認場所 | 見るべき内容 |
|---|---|
| API Management policy | cache-lookup、cache-store、cache-lookup-value、cache-store-value の有無 |
caching-type 属性 | external または prefer-external を指定しているか |
| フォールバック処理 | キャッシュミス時にバックエンド取得、既定値返却、rate-limitなどがあるか |
例えば、ユーザープロファイルや設定値を cache-lookup-value で取得している場合、キャッシュ接続が失敗すると値が取得できず、後続処理が想定外の分岐に入ることがあります。単なるレスポンスタイムだけでなく、「キャッシュから値が取れなかった時に業務ロジックが壊れないか」まで確認してください。
クラウド管理者が確認すべきポイント
クラウド管理者は、Azure上の実際の通信経路を確認する必要があります。NSGに許可ルールを追加しても、Azure Firewall、NVA、ルートテーブル、Private Endpoint、DNS設定のどこかで止まることがあります。
確認順序は次の通りです。
| 順序 | 確認対象 | 具体的な確認内容 |
|---|---|---|
| 1 | API Managementサブネット | 紐づくNSGとルートテーブルを確認 |
| 2 | Redis側ネットワーク | 接続先がパブリック、Private Endpoint、別VNetのどれか確認 |
| 3 | NSG | Inbound / Outbound の TCP 10000 を確認 |
| 4 | Azure Firewall / NVA | Network ruleで TCP 10000 が許可されているか |
| 5 | DNS | Redis接続先が想定したIPに解決されているか |
| 6 | ログ | 拒否ログやタイムアウトが発生していないか |
Azure Network Watcher の IP flow verify は、パケットが許可または拒否されるか、どのNSGルールが判断したかを確認するために使えます。NSGの有効ルールを確認する機能も、サブネットレベルとNICレベルのルール競合を調べる際に役立ちます。(Microsoft Learn)
ソリューションアーキテクトが見直すべき設計
ソリューションアーキテクトは、今回の更新をきっかけに「API Management と外部キャッシュをどの単位で接続するか」を見直すとよいでしょう。
外部キャッシュの設定では、API Management のリージョン、セルフホステッドゲートウェイの場所、または Default を指定できます。Microsoft Learnでは、複数リージョン構成の例として、特定リージョンのキャッシュ設定がある場合はそのリージョンで個別キャッシュを使い、それ以外はDefaultのキャッシュを使うケースが説明されています。(Microsoft Learn)
設計で確認したい観点は次の通りです。
| 設計観点 | 確認すべきこと |
|---|---|
| リージョン配置 | APIMとRedisが近いリージョンにあるか |
| 可用性 | Redis障害時にバックエンドが耐えられるか |
| セキュリティ | Redis接続の許可範囲を最小化できているか |
| 変更容易性 | ポートや接続先の変更をIaCで一元管理できているか |
| 監査性 | どのルールがどのドキュメント要件に対応するか説明できるか |
| コスト | 外部キャッシュ利用による追加コストと性能改善が見合うか |
特に、API Management をAI APIゲートウェイとして使い、Azure OpenAI APIなどの応答キャッシュやセマンティックキャッシュを設計している場合は、外部キャッシュの可用性と接続性がユーザー体験やコストに直結します。TCP 10000 のようなネットワーク要件は、単なるインフラ設定ではなく、API基盤全体の信頼性要件として扱うべきです。
技術意思決定者が押さえるべき運用判断
技術意思決定者にとって重要なのは、今回の更新を「今すぐ全環境に変更を入れる案件」と見るか、「該当環境だけを対象にした設定確認」と見るかの判断です。
今回のGitHubコミットは、コミットメッセージが「Port number」で、差分は1ファイルの1行修正です。GitHub上では 1000 から 10000 への変更が確認できますが、この差分だけからサービス全体の仕様変更、停止予定、移行期限までは読み取れません。(GitHub)
したがって、判断は次のように分けると現実的です。
| 状況 | 判断 |
|---|---|
| APIMをVNet内で使い、外部Managed Redisを利用 | 優先度高。ネットワークルールとIaCを確認 |
| APIMをVNet内で使うが外部キャッシュなし | 中程度。将来利用に備え、手順書とテンプレートを確認 |
| APIMをVNet外で利用 | 低め。影響は限定的だが公式ドキュメント更新として把握 |
| v2 tiersで別ドキュメントの対象 | 別途v2 tiers向け要件を確認 |
| 本番で障害兆候あり | 変更前にログ、NSG、Firewall、キャッシュ接続を優先調査 |
よくある失敗パターン
古いポート 1000 だけを許可したままにする
最も分かりやすい失敗は、古いドキュメントをもとに TCP 1000 だけを許可しているケースです。今回の更新後の表では、外部 Azure Managed Redis service for caching policies between machines のポートは TCP 10000 と示されています。(Microsoft Learn)
特に、過去に手順書を見ながら手動でNSGルールを作成した環境では、IaCに記録がなく、設定の根拠が追いにくいことがあります。該当する場合は、NSGルール名や説明欄に「APIM external cache」などの用途を追記し、将来の監査で判断できるようにしておきましょう。
NSGだけ直してFirewallを忘れる
Azure環境では、NSGだけで通信が決まるとは限りません。Azure Firewall、サードパーティNVA、VPN、ExpressRoute、Private Endpoint、ルートテーブルが関係する場合、NSG上は許可されていても実際の通信が失敗することがあります。
TCP 10000 を追加した後にキャッシュが使えない場合は、次の順に確認してください。
| 確認順 | 内容 |
|---|---|
| 1 | APIMサブネットのNSGで許可されているか |
| 2 | Redis側のNSGやFirewallで許可されているか |
| 3 | Azure FirewallまたはNVAのNetwork ruleで許可されているか |
| 4 | DNSが想定した接続先に解決されているか |
| 5 | ルートテーブルで意図しない経路に流れていないか |
| 6 | Redis接続文字列が :10000 を使っているか |
APIの成功だけでキャッシュ正常と判断する
API Management のキャッシュ処理では、キャッシュに接続できない場合でもAPI呼び出し自体が失敗しないことがあります。Microsoft Learnでも、キャッシュ関連操作が接続できない場合にAPI呼び出しはエラーを発生させず、読み取りでは null が返ると説明されています。(Microsoft Learn)
そのため、検証ではAPIのHTTPステータスだけでなく、APIM Trace、キャッシュヒット率、バックエンド呼び出し回数、Redis側メトリックを確認してください。
v2 tiersにも同じ設定をそのまま適用する
対象ページでは、このリファレンスがVNetにデプロイされた classic tiers の API Management インスタンスに適用され、v2 tiers のVNet injectionについては別ドキュメントを参照するよう示されています。(Microsoft Learn)
v2 tiersを使っている場合は、classic tiers向けの表をそのままコピペするのではなく、v2 tiers向けの最新ネットワーク要件を確認してください。特に、既存のclassic tierからv2 tierへの移行を検討している場合は、ポート、サービス タグ、Private Endpoint、外部キャッシュ構成をまとめて確認する必要があります。
移行準備としてやるべきこと
今回の更新を受けた移行準備は、「大規模移行」というよりも、ネットワーク要件の整合性確認として進めるのが現実的です。
既存環境の棚卸し
まず、API Management インスタンスを一覧化します。
| 棚卸し項目 | 記録する内容 |
|---|---|
| APIM名 | 対象インスタンス名 |
| リソースグループ | 管理単位 |
| SKU | Developer / Premium / v2 tiers など |
| VNet構成 | External / Internal / VNetなし |
| 外部キャッシュ | Azure Managed Redis、Redis互換キャッシュ、未使用 |
| 関連NSG | APIMサブネット、Redis側サブネット |
| Firewall経路 | Azure Firewall、NVA、なし |
| IaC管理 | Bicep、ARM、Terraform、手動 |
| 運用責任者 | 開発、インフラ、SRE、セキュリティなど |
この棚卸しで「VNet内APIM + 外部Redis互換キャッシュ + 厳格なネットワーク制御」に該当する環境を優先的に確認します。
IaCと運用資料を更新する
本番環境だけ手動で直しても、IaCに古い設定が残っていると、次回のデプロイで元に戻る可能性があります。次のファイルや資料を検索してください。
| 対象 | 検索キーワード例 |
|---|---|
| Bicep / ARM | 1000, destinationPortRange, networkSecurityGroups |
| Terraform | 1000, destination_port_range, azurerm_network_security_rule |
| CI/CD変数 | APIM, REDIS, PORT |
| 運用手順書 | API Management, Redis, 1000, 10000 |
| 監査資料 | Required ports, VNet, NSG |
| 障害対応Runbook | cache, Redis, APIM |
古い 1000 の記載を見つけた場合は、単純置換ではなく、用途を確認してから修正します。別システムのポート番号として使われている可能性があるためです。
段階的に検証する
変更は次の順番で進めると安全です。
| フェーズ | 作業 |
|---|---|
| 検証環境 | TCP 10000 許可後、キャッシュヒットとバックエンド負荷を確認 |
| ステージング | 本番に近いFirewall、DNS、Private Endpoint構成で確認 |
| 本番一部 | 低トラフィック時間帯に対象環境へ適用 |
| 本番全体 | 多リージョンや複数APIMへ展開 |
| 変更後監視 | APIM、Redis、Firewall、Application Insightsを確認 |
キャッシュが利用できない場合にバックエンドへリクエストが流れる設計では、短時間の確認だけでは問題を見落とすことがあります。ピーク時間帯やキャッシュミスが多い状態も想定して、バックエンド負荷とレイテンシを確認してください。
変更後のチェックリスト
最後に、実務でそのまま使えるチェックリストを整理します。
| チェック | 内容 |
|---|---|
| 対象確認 | API Management がVNet内で稼働している |
| SKU確認 | 対象ドキュメントの範囲に該当する |
| キャッシュ確認 | 外部 Azure Managed Redis またはRedis互換キャッシュを使っている |
| ポリシー確認 | キャッシュ系ポリシーが外部キャッシュを参照している |
| NSG確認 | Inbound / Outbound で TCP 10000 が許可されている |
| 優先度確認 | 高優先度のDenyルールにブロックされていない |
| Firewall確認 | Azure FirewallやNVAでも TCP 10000 が通る |
| 接続文字列確認 | Redis接続文字列が :10000 を使用している |
| IaC確認 | 1000 の古い記載が残っていない |
| 運用資料確認 | 手順書、監査資料、Runbookを更新した |
| 検証確認 | キャッシュヒット、キャッシュミス、バックエンド負荷を確認した |
| 監視確認 | APIM、Redis、Firewallログで拒否やタイムアウトがない |
まとめ：1000 ではなく 10000、ただし該当環境を見極めて対応する
Azureの公式ドキュメント更新「Port number」で確認すべき最大のポイントは、Azure API Management のVNet構成リファレンスにおいて、外部 Azure Managed Redis をキャッシュ用途で使う通信のポート番号が TCP 10000 と示されたことです。GitHubの差分では、該当箇所が 1000 から 10000 に修正されています。(GitHub)
対応の優先度が高いのは、VNet内のAPI Managementで外部Redis互換キャッシュを使い、NSGやFirewallで通信を厳格に制御している環境です。まずはAPI ManagementのSKU、VNet構成、外部キャッシュの有無、NSGとFirewallのルール、IaC内の古いポート記載を確認してください。
次に取るべき行動は明確です。自社のAPI Management環境を棚卸しし、TCP 10000 の許可が必要な環境だけを特定し、検証環境でキャッシュ動作を確認してから本番へ反映しましょう。ポート番号の修正は小さく見えても、API基盤の可用性、キャッシュ性能、バックエンド負荷に影響する可能性があります。公式ドキュメント更新を、ネットワーク設定と運用資料を見直す良いタイミングとして活用してください。
コメント