Azure Functions からオンプレミス API に接続しようとすると、「ローカルでは動くのに Azure にデプロイするとタイムアウトする」という相談はとても多いです。その大半はファイアウォールに送信元 IP を開けただけで「そもそもの通信経路」が用意されていないことが原因です。本記事では、その仕組みと具体的な解決パターン（Hybrid Connections / VNet 統合 + VPN・ExpressRoute / Flex Consumption）を、設計のポイントやトラブルシュートまで含めて整理します。
Azure Functions からオンプレ API に接続できない典型パターン
まず、よくある問い合わせシナリオを整理します。
- Function App（多くは Consumption プラン）から社内の HTTP(S) API に接続したい
- オンプレ側ファイアウォールには、Function App の「送信元 IP アドレス」を許可登録済み
- ローカル PC からは VPN 経由などで API にアクセスできる
- しかし Azure にデプロイした Functions からは 接続タイムアウト（接続先が応答しない） になる
なぜローカルでは成功するのに Azure では失敗するのか
ポイントは次の 2 つです。
- ローカル PC には「社内ネットワークへの経路」がある
例：社内 LAN に直接接続、もしくは VPN クライアントで社内ネットワークにルーティング済み。 - Azure Functions からオンプレへの経路はデフォルトでは存在しない
Function App はインターネット側には出られても、「社内 IP アドレス宛の経路」は用意されていません。
つまり、「オンプレ側ファイアウォールで Function の IP を許可」したとしても、
- Azure Functions 側にはオンプレネットワークへのルートがない
- パケットがそもそも社内ルーター・ファイアウォールまで到達しない
という状態です。ここを理解しておくと、後の設計判断がとてもスムーズになります。
解決の基本方針：送信元 IP ホワイトリスト ＋「到達経路」の準備
結論を一言で言うと、次のようになります。
送信元 IP をホワイトリスト登録するだけでは不十分で、「Azure Functions からオンプレまでの到達経路（トンネル or 中継）」を作る必要があります。
Azure Functions でオンプレ API に安全に到達するための代表的な方法は次の 3 つです。
| 方式 | 概要 | 必要なプラン | オンプレ側準備 | 向いているケース |
|---|---|---|---|---|
| Hybrid Connections (Azure Relay) | オンプレにインストールしたエージェント(HCM)から Azure へ 443/TLS で「穴」を開けて中継 | Functions が Windows かつ Consumption 以外 | 中継サーバに HCM をインストール。HCM から社内 API への疎通を確保 | 特定の API/ポートだけを素早くつなぎたい PoC、小規模構成 |
| VNet 統合 + VPN / ExpressRoute | Functions を VNet に参加させ、その VNet とオンプレを VPN または ER で接続 | Premium / Dedicated(App Service Plan) / Flex Consumption など VNet 統合対応プラン | サイト間 VPN ゲートウェイまたは ExpressRoute、ルート・ファイアウォール設定 | 本番・大規模、複数サーバや DB など広く社内リソースへ接続したい場合 |
| Flex Consumption プラン | Linux ベースの最新サーバーレスプラン。VNet 統合が可能で、オンプレへも VPN/ER 経由で到達 | Flex Consumption 対応リージョン / ランタイム | VNet とオンプレ間の VPN / ExpressRoute、DNS/ルーティング | 「サーバーレス × プライベートネットワーク」を両立したい、Linux 関連の新規開発 |
以降では、それぞれをもう少し深掘りします。
Hybrid Connections（Azure Relay）でオンプレ API に接続する
仕組みのイメージ
Hybrid Connections は Azure Relay の機能で、オンプレ側から Azure へ「アウトバウンド 443/TLS」で張るトンネルを通して、Azure からオンプレ API にアクセスできるようにする仕組みです。
ざっくりとした流れは下記の通りです。
- Azure Portal で「Hybrid Connection」を作成（接続先のホスト名＋ポートを登録）
- オンプレのサーバ（Windows）に Hybrid Connection Manager（HCM） をインストール
- HCM が Azure Relay へ 443/TLS で接続し、コネクションを維持
- Function App が Hybrid Connection 経由で、社内 API のホスト:ポートにアクセス
利用できるプランと制約
- Functions が Windows で動作していることが必須
- Consumption プランでは利用不可（Free/Shared/Basic/Standard/Premium/Isolated など App Service Plan 系で利用）
- TCP ベースのプロトコルのみ対応（UDP は不可）
- 1 Hybrid Connection = 1 ホスト＋1 ポートの単位
このため、
- Functions が Consumption プランのまま
- Linux プランで動かしている
といったケースでは、まず Windows + Premium / Dedicated プランへの移行 を検討する必要があります。
設定手順の例
- Function App を Windows + Premium / Dedicated プランで作成（またはスケールアップ）
- Azure Portal の Function App > Networking > Hybrid connections から新規作成
- 接続名、ターゲットホスト名（例：intra-api.example.local）、ポート（443 など）を登録
- オンプレの中継サーバ（できれば DMZ など）に HCM をインストールし、Azure Relay にサインイン
- HCM 管理画面で、先ほど作成した Hybrid Connection を紐づけ
- 社内から HCM 経由で対象 API にアクセスできるかを確認（telnet / curl など）
- Function のコードからは、通常通り
https://intra-api.example.local/...へアクセス
オンプレ側ファイアウォールでは、HCM サーバから Azure Relay への 443/TLS アウトバウンド を許可するだけでよく、社内 API をインターネット公開する必要はありません。
メリット・デメリット
| 項目 | 内容 |
|---|---|
| メリット | オンプレ側は アウトバウンド 443 のみ 開ければよい VPN や ExpressRoute のようなネットワーク設備が不要 特定 API だけをピンポイントで公開でき、構成がシンプル |
| デメリット | TCP/特定ポートごとの設定が必要で、接続先が多いと管理が煩雑 Windows ＋ Consumption 以外の Functions に限定される HCM を置くサーバの運用・監視が必要 |
VNet 統合 + VPN / ExpressRoute でオンプレに接続する
仕組みのイメージ
もう一段「ちゃんとした」ネットワーク構成を取りたい場合は、次の組み合わせが王道です。
- Function App を Azure 仮想ネットワーク（VNet）に統合
- その VNet とオンプレネットワークを サイト間 VPN または ExpressRoute で接続
こうすることで、Functions からオンプレのプライベート IP（10.x.x.x / 172.x.x.x / 192.168.x.x など）に、あたかも社内サーバの 1 台かのようにアクセス できます。
どのプランで VNet 統合が使えるか
現在の仕様では、Functions の VNet 統合は下記のプランで利用できます。
- Flex Consumption プラン
- Premium プラン（Elastic Premium）
- Dedicated（App Service Plan）
- Container Apps（Functions をコンテナアプリとしてホストする場合）
従来の Consumption プランには VNet 統合がありません。そのため、オンプレときちんと閉域接続したい場合は、いずれかのプランへ移行する前提で設計する必要があります。
構成のざっくり手順
- Functions を Premium / Dedicated / Flex Consumption のいずれかで作成
- Azure 側でオンプレと接続する VNet を用意
- サブネットは Functions 統合用に、/27〜/24 程度を専用で確保（推奨サイズはプランにより異なる）
- その VNet とオンプレを、ExpressRoute またはサイト間 VPN で接続
- オンプレ側 VPN ゲートウェイ / ルータのルート設定を合わせる
- Function App > Networking > VNet Integration から、先ほどのサブネットに統合
- オンプレ側ファイアウォールに、VNet のアドレスレンジや VPN のトンネルを通過するルールを設定
- 必要なら NAT Gateway を VNet 側に設置し、送信元 IP を固定（オンプレ側での IP ホワイトリストに利用）
メリット・デメリット
| 項目 | 内容 |
|---|---|
| メリット | Functions 以外の Azure リソース（VM、App Service、PaaS など）も同じ VNet からオンプレにアクセス可能 オンプレ DB・AP・ファイルサーバなど、複数の社内リソースに一括で到達 ネットワークチームの運用プロセス（ルータ/ファイアウォール/監査など）に乗せやすい |
| デメリット | VPN/ExpressRoute の構築コスト・運用コストがかかる ルート表、NSG、オンプレ側ルータの設定など、ネットワーク設計の難易度が上がる Consumption プランのままでは利用できないため、プラン移行が前提になる |
Flex Consumption プランで「サーバーレス × プライベートネットワーク」を両立する
Flex Consumption プランとは
Flex Consumption は Linux ベースの Azure Functions ホスティングプランで、従来の Consumption と同じ「使った分だけ課金・スケール to ゼロ」を維持しつつ、
- VNet 統合によるプライベートネットワーク対応
- インスタンスメモリサイズの選択
- 高速なスケールアウトと Always-ready インスタンスによるコールドスタートの軽減
などを追加した、より高度なサーバーレス実行環境です。
また、最近のドキュメントでは 「推奨されるサーバーレスプラン」 として Flex Consumption が案内されており、特に Linux Functions は今後 Flex Consumption への移行が強く推奨されています。
Flex Consumption と VNet 統合
Flex Consumption では、前述の VNet 統合機能が利用でき、下記のようなことが可能です。
- VNet 統合を通じて、VNet 内の Azure サービスや Private Endpoint へアクセス
- その VNet が VPN や ExpressRoute でオンプレと接続されていれば、オンプレ API にも到達
- NSG / UDR / Azure Firewall などのネットワーク制御を活用しつつ、サーバーレスらしいスケール特性を維持
「サーバーレスでありながら社内ネットワークの一員として動かす」には、Flex Consumption が最もバランスの良い選択肢になりつつあります。
Flex Consumption を使ったオンプレ接続の進め方
- Flex Consumption プランが利用可能なリージョン・ランタイムか確認（Azure CLI の
az functionapp list-flexconsumption-locationsなど） - VNet とオンプレを VPN/ExpressRoute で接続（既存のハイブリッドネットワークがあればそれを利用）
- Flex Consumption の Function App を作成し、VNet 統合を有効化
- DNS・ルート表・NSG を適切に設定
- Functions からオンプレのホスト名 / IP へ接続テスト
既に Linux Consumption プランで運用中の Functions があり、今後もサーバーレスでオンプレ接続を続けたい場合は、Flex Consumption への移行を強く検討する価値があります。
プラン別にできるネットワーク機能の早見表
| プラン | VNet 統合 | Hybrid Connections | Private Endpoint（Functions 自身） | オンプレ接続の推奨パターン |
|---|---|---|---|---|
| Consumption（Windows） | 不可 | 不可 | 不可 | 基本的に「直接オンプレ」は難しい。Premium/Flex などへの移行を検討 |
| Consumption（Linux） | 不可（今後 Flex へ移行推奨） | 不可 | 不可 | Flex Consumption への移行を前提に設計 |
| Flex Consumption（Linux） | 可（Regional VNet Integration） | 不可（Linux 非対応） | 可 | VNet 統合 + VPN/ExpressRoute 経由でオンプレに到達 |
| Premium（Elastic Premium） | 可 | 可（Windows のみ） | 可 | VNet 統合 + VPN/ER、または Hybrid Connections |
| Dedicated（App Service Plan） | 可 | 可（Windows のみ） | 可 | VNet 統合 + VPN/ER、または Hybrid Connections |
この表からもわかる通り、「オンプレにちゃんとつなぎたい」＝ Consumption のままでは厳しく、Flex / Premium / Dedicated への移行がほぼ必須 という構図です。
導入前チェックリスト：ここを押さえておくとハマりにくい
1. Function の実行プランと OS
- 現在のプラン（Consumption / Premium / Dedicated / Flex Consumption）
- 実行 OS（Windows / Linux）
ここで分かること：
- Hybrid Connections が選べるかどうか（Windows かつ Consumption 以外）
- VNet 統合が選べるかどうか（Flex / Premium / Dedicated など）
2. Azure～オンプレ間の経路
- 既に ExpressRoute / サイト間 VPN があるか
- ある場合、その VNet は新しい Functions と同じリージョン・サブスクリプションで使えるか
- ルート表、オンプレ側ルータ / ファイアウォールに、Azure 側ネットワークの経路が登録されているか
3. DNS 解決
オンプレ API が intra-api.example.local のような内部ホスト名の場合、下記のいずれかが必要です。
- VNet の DNS サーバをオンプレ DNS に向ける（フォワーダ設定など）
- Azure 内に DNS フォワーダ（DNS Server VM や Azure DNS Private Resolver）を立ててオンプレ DNS に転送
- どうしても DNS 構成が難しい場合は、一時的に /etc/hosts への静的登録も検討（ただし運用は大変）
VNet 統合した Functions は、VNet の DNS 設定をそのまま利用するため、DNS の設計ミスが原因でタイムアウトするケースが非常に多い 点にも注意が必要です。
4. ポート・ファイアウォール
- Hybrid Connections の場合
- HCM から Azure Relay（インターネット）への 443/TLS アウトバウンドが許可されているか
- HCM から社内 API までの経路（TCP:443 など）が空いているか
- VNet 統合（VPN/ExpressRoute）の場合
- Functions 統合サブネット（または NAT Gateway の IP）からオンプレ API へのポートが許可されているか
- オンプレから Azure への戻り経路が正しくルーティングされているか
5. 送信元 IP の安定化が必要か
オンプレ側ファイアウォールが「特定の送信元 IP からのみ許可」というポリシーであれば、
- VNet 統合 + NAT Gateway で、Azure 側の送信元 IP を固定
- オンプレのファイアウォールに、その NAT の public IP を登録
という構成がよく使われます。
ユースケース別：最短ルートの選び方
「まずは素早く動かしたい」場合
次の条件に当てはまれば、Hybrid Connections が最短です。
- Functions を Windows + Premium / Dedicated で動かしても問題ない
- 接続したい API/ポートが限定的（例：社内 REST API が数本程度）
- VPN/ExpressRoute を新設するほどの規模ではない
手順も比較的シンプルで、「HCM を 1 台立てて Hybrid Connection を紐づけるだけ」で動くため、PoC や短期プロジェクトと相性が良いです。
「本番運用で、広範囲な社内リソースにアクセスしたい」場合
DB、AP、ファイルサーバなど、オンプレリソースに幅広くアクセスしたい場合は、VNet 統合 + VPN/ExpressRoute が王道です。
- 既に ExpressRoute / VPN がある → そこに乗せるだけなので特におすすめ
- 今後も Azure へのシステム移行が続く → ハイブリッドネットワークの基盤としても有効
一度 VNet～オンプレの閉域接続を作っておけば、Functions 以外にも VM や PaaS から同じ経路で社内にアクセスできます。
「サーバーレス志向を維持したい・Linux 中心」な場合
Linux Functions をサーバーレスで運用しつつ、プライベートネットワークとの連携も重視したい場合は、Flex Consumption が第一候補になります。
- 今から新規で Linux Functions を作る
- 既存の Linux Consumption Functions を、今後も長く運用したい
といったケースでは、Flex Consumption を前提に設計した方が、将来のサポートや機能面で有利です。
トラブルシュートの要点
1. Kudu / SSH コンソールから L4 疎通を確認
「アプリからタイムアウト」とだけ見ると原因が分かりづらいので、まずは Functions 実行環境から L4 レベルの疎通を確認します。
- Windows（App Service on Windows）の場合
tcpping <host> <port> - Linux（Flex / Linux Premium など）の場合
nc -vz <host> <port>
ここで接続できない場合は、アプリコードではなくネットワーク構成（VNet 統合、VPN/ExpressRoute、ファイアウォール、NSG、ルート表）の問題と切り分けできます。
2. DNS 解決を確認
ホスト名でアクセスしている場合は、下記も合わせてチェックします。
- Windows：
nslookup intra-api.example.local - Linux：
dig intra-api.example.localまたはnslookup
ここで期待する IP が返ってこなければ、DNS 設定（VNet の DNS サーバ、フォワーダ、Private DNS Zone など）を見直してください。
3. Hybrid Connection Manager（HCM）のログ
Hybrid Connections 利用時は、HCM 側の状態も重要です。
- Azure Relay への接続が「Connected」になっているか
- エラーが出ていないか（証明書エラー、プロキシエラーなど）
- オンプレ API 宛の接続要求が届いているか
HCM が Azure 側に接続できていない場合、Function 側からは常にタイムアウトになります。
4. VPN/ExpressRoute 経路・ルート表の確認
VNet 統合 + VPN/ExpressRoute で接続している場合、ルート周りでよくハマります。
- VNet のルート表（UDR）で、オンプレ宛 IP が VPN/ER ゲートウェイに向いているか
- オンプレ側のルータ・ゲートウェイで、Azure VNet 宛の戻り経路が設定されているか
- BGP を使っている場合、経路がフィルタされていないか
片方向だけルートが通っている（行きは行けるが戻って来られない）と、タイムアウトとして現れます。
5. タイムアウト設定とリトライ戦略
ネットワーク構成が整っていても、
- オンプレ API 側の応答までに時間がかかる
- 一時的なネットワーク輻輳でレスポンスが遅くなる
といった理由で、Functions 側でタイムアウトするケースがあります。
- HTTP クライアントのタイムアウト値を適切に設定
- ポリシーライブラリ（Polly など）を使い、一定回数のリトライやサーキットブレーカーを実装
- ログから、どのリクエストがどれだけ時間がかかっているのかを可視化
単純に「Functions の実行時間上限」だけを伸ばすのではなく、アプリケーション側のリトライ戦略もセットで設計することが重要です。
よくある勘違いとアンチパターン
「Consumption でも Hybrid Connections が使える」は誤り
Hybrid Connections は Windows Functions かつ Consumption 以外のプラン でのみ利用可能です。Linux Functions や Consumption プランでは使えません。
Consumption でオンプレ接続を実現したい場合は、
- Premium / Dedicated / Flex Consumption へのプラン移行
- もしくは Functions を Azure Container Apps や AKS に移し、そちらで VNet 統合
といった方針を検討してください。
「Private Endpoint を作ればオンプレに直接つながる」は誤り
Private Endpoint は、Azure PaaS（Storage, SQL, Service Bus など）を VNet 内からプライベートアクセスするための仕組み です。オンプレのサーバそのものに Private Endpoint を張ることはできません。
オンプレ資産への接続には、
- Hybrid Connections
- VNet 統合 + VPN / ExpressRoute
のいずれかを選択する必要があります。
「送信元 IP さえ分かればなんとかなる」は半分だけ正しい
オンプレ側ファイアウォールで「送信元 IP をホワイトリスト登録」すること自体は正しいのですが、
- IP アドレスは VNet 統合 + NAT Gateway などでコントロールする
- その前に そもそものネットワーク経路を作る（Hybrid Connections or VPN/ExpressRoute）
というステップが欠けていると、いつまでたっても疎通しません。
まとめ
Function App からオンプレ API に接続したいとき、「IP を開けたのに繋がらない」 状態のほとんどは、
- Azure Functions からオンプレまでの 到達経路が用意されていない
- 利用中のプランで本来サポートされていないネットワーク機能を前提にしている
ことが原因です。
改めて、解決の選択肢を整理すると次の通りです。
- Hybrid Connections：Windows + Premium/Dedicated で、特定 API への最短ルート
- VNet 統合 + VPN/ExpressRoute：本番・大規模向けの王道構成
- Flex Consumption：サーバーレスを維持しつつ VNet / オンプレ接続を実現する最新プラン
「まずはどのプランで Functions を動かしているか」「自社に既に VPN/ExpressRoute があるか」の 2 点を起点に、最適なネットワーク統合方式を検討してみてください。
コメント