オンプレに残したい基幹API（Secondary API）と、Azureで外部公開したいPrimary API。クラウドとオンプレを安全につなぐには、ネットワーク接続だけでなく「入口」「認証」「運用監視」まで含めた設計が欠かせません。本記事では、代表的な接続方式と失敗しない構成パターンを整理します。
想定シナリオ：Primary APIをAzureで外部公開し、Secondary APIはオンプレに残す
よくある構成として、次のような役割分担があります。
- Primary API（Azure）：外部（インターネット）に公開する窓口。認証・認可、入力検証、監査ログ、レート制限など「対外的な責任」を担う。
- Secondary API（オンプレ）：基幹システムやレガシー資産、機密データに近い内部API。原則インターネット非公開で守る。
このとき課題になるのが、Azure上のPrimary APIからオンプレ内Secondary APIへ、安全に到達させる方法です。結論から言えば、単に疎通させるだけでなく、次の3層で設計すると破綻しにくくなります。
結論：安全な「Azure→オンプレ接続」は3層で考える
- ネットワーク層（どうつなぐか）：Site-to-Site VPN / ExpressRoute / Relayなど
- 入口層（どこで公開を受けるか）：APIM / Application Gateway(WAF) / Front Door 等で防御と制御
- アプリ層（誰が・何を・どこまで呼べるか）：OAuth2/OIDC、mTLS、IP制限、認可、監査、レート制限
「接続方式」だけで決めると、あとから認証や監視・遮断の要件が出たときに作り直しになりがちです。まずは選択肢を俯瞰し、要件に合わせて段階的に強化できる構成を選びましょう。
Azure（クラウド）からオンプレへ：代表的な接続方式の比較
Azure→オンプレへの到達手段は複数あり、要件（遅延・帯域・可用性・運用負荷・ネットワーク制約）で最適解が変わります。まずは全体像を表で整理します。
| 方式 | 特徴 | 向いているケース | 注意点 |
|---|---|---|---|
| Site-to-Site VPN（拠点間VPN） | Azure VNetとオンプレNWをIPsecで接続。比較的早く始められる。 | まず疎通したい／中小規模／段階導入／開発・検証から本番へ拡張 | インターネット回線品質に影響。帯域・遅延・ジッタは要検討。冗長化設計が重要。 |
| ExpressRoute | 専用線・閉域網でプライベート接続。高帯域・低遅延・安定性が期待できる。 | 高負荷API／厳しいSLA／安定したレイテンシが必要／大規模 | 手配・コスト・運用が重い。回線・冗長構成（2系統）を前提に設計したい。 |
| Azure API Management（APIM） | 公開APIの入口を集約。認証、制御、変換、監視を一元化しやすい。 | 外部公開を安全にしたい／APIガバナンス／複数API統合 | オンプレ到達はVPN/ExpressRoute、またはSelf-hosted Gateway等の設計が必要。 |
| Azure Relay | オンプレ側から外向き接続でトンネルを張り、インバウンド穴を開けず到達。 | オンプレが厳格で受信開放できない／最小変更で接続したい | 用途・プロトコル制約の整理が必要。高スループット用途は要評価。 |
| Application Gateway（+ WAF） | HTTPS終端、ルーティング、WAFで入口防御。バックエンドへ転送。 | Web/APIの入口を堅牢化したい／WAF必須／L7ルーティング | オンプレ到達は原則VPN/ExpressRoute前提。二重終端・証明書運用も検討。 |
まず押さえる前提：Secondary APIはインターネット非公開を基本にする
「Primary APIを外部公開したい」＝「Secondary APIも外部から到達できるようにする」ではありません。安全設計の原則として、Secondary APIは以下を基本方針にします。
- インターネットから直接到達させない（公開はPrimary側またはゲートウェイ層で止める）
- 通信経路はプライベートに寄せる（VPN/ExpressRouteなど）
- 呼び出し元を最小化（Primary APIやAPIMなど、呼び出し主体を限定）
- アプリ層の認証・認可も必ず行う（ネットワークだけに依存しない）
ネットワークで守り、入口で制御し、アプリで保証する。これが「Azureで公開しつつオンプレを守る」王道です。
方式別の具体像：どう接続し、どう守るか
Site-to-Site VPN（拠点間VPN）：最初の現実解になりやすい
AzureのVNetとオンプレネットワークをIPsec/IKEで接続し、プライベートIPで相互到達できるようにする方式です。API間通信なら、端末向けのPoint-to-SiteよりもSite-to-Siteが基本になります。
構成イメージ
[Internet] | (公開入口: APIM / AppGW / Front Door) | [Azure VNet] --- (S2S VPN) --- [On-Prem Network] | [Primary API] ----------------> [Secondary API]
設計のポイント
- アドレス設計：オンプレとAzureでIPレンジが重複しないようにする（重複はトラブルの原因になりやすい）。
- ルーティング：VNet側のルート（UDR）とオンプレ側の経路制御を整合させ、非対称ルーティングを避ける。
- 冗長化：単一トンネルだと回線・装置・メンテで止まるため、冗長構成（ゲートウェイ/回線/装置）を要件に応じて検討。
- セキュリティ境界：VPNでつながったから「全部通す」ではなく、オンプレ側FWで許可先IP/ポートをSecondary APIに限定し、必要最小の穴にする。
VPNは「まず疎通→運用しながら改善」が可能で、段階導入に向きます。一方で、帯域・遅延が厳しい本番要件ではExpressRouteへ移行・併用を検討します。
ExpressRoute：安定性とスケールを優先するなら強い
ExpressRouteは、インターネットを経由しないプライベート接続として設計でき、レイテンシのブレが少なく、帯域も確保しやすいのが魅力です。特に、次のような条件が揃うと採用価値が高まります。
- API呼び出し量が多く、VPNの帯域や揺らぎがボトルネックになる
- レスポンス時間の安定性（ジッタの小ささ）が重要
- 長期運用を前提に、接続の信頼性・冗長性を高めたい
設計のポイント
- 冗長経路：回線は単系統に寄せず、要件に応じて2系統・別経路の検討を行う。
- 経路広告（BGP）：ネットワーク運用の標準化を意識し、経路制御の責任分界を明確化する。
- 出口制御：Azure側からオンプレへ行ける＝オンプレからAzureへも行ける、になりがち。許可範囲を意図して狭める。
注意したいのは「高性能＝何でも解決」ではない点です。ExpressRouteで経路が安定しても、入口のDDoS/WAF、API認証やレート制限、監査が弱ければ安全性は上がりません。あくまでネットワーク層の強化として位置づけましょう。
Azure API Management（APIM）：公開APIの入口を“設計できる”ようにする
外部公開を本気で安全にするなら、APIMは非常に強力です。APIの入口をAPIMに寄せると、次が一気にやりやすくなります。
- 認証・認可（JWT検証、キー、OAuth2/OIDC連携）
- アクセス制御（IP制限、条件分岐、サブスクリプション）
- レート制限・スパイク抑制（DoSの軽減にも寄与）
- ヘッダ付与、URL書き換え、レスポンス変換などのゲートウェイ機能
- 監視・分析・トレーシングの起点化
オンプレへ安全に到達させるAPIMの代表パターン
- VPN/ExpressRouteでVNet接続し、APIMやバックエンドがオンプレへプライベート到達：王道。ネットワーク設計と相性が良い。
- Self-hosted Gatewayをオンプレに置く：オンプレ内にAPIMのゲートウェイを配置し、クラウド側の管理面と分離。オンプレ側は外向き接続中心にでき、受信開放を減らせる。
- （条件次第で）Hybrid Connections等を併用：ネットワーク制約が強い場合の折衷案として検討。
「Primary APIをAzureで公開」と言っても、外部からの入口をPrimary APIに直接当てるより、APIMを“公開面”にしてPrimary APIは内側に置く方がセキュアになりやすいです。理由は単純で、入口に必要な防御・制御をAPI本体から切り離して共通化できるからです。
Azure Relay：オンプレの受信ポート開放が難しいときの選択肢
オンプレ環境によっては「インバウンドは一切開けられない」「DMZのルールが厳格でVPNもすぐに通せない」といった事情があります。その場合、オンプレ側が外向きに接続を張り、クラウドからはその接続を介して到達する方式が現実解になります。
Azure Relayはその代表例で、オンプレ側から外向き通信を確立し、クラウド側からオンプレへ到達できる設計を取りやすいのが利点です。
設計のポイント
- “万能のネットワーク置き換え”ではない：用途やプロトコル、スループット要件を整理したうえで採用する。
- 認証・認可は別途必須：Relayで到達できても、APIの呼び出し権限を適切に制御する。
- 運用監視：接続の健全性を監視し、切断時のリトライ/フェイル動作を設計する。
Application Gateway（WAF）+ VNet：入口防御を強固にしたい場合
外部公開の入口として、Application Gateway（必要に応じてWAF）を置くと、HTTPS終端、L7ルーティング、WAFによる攻撃遮断などを入口で実装できます。特に、次の要件がある場合に強いです。
- WAFが必須（OWASP対策、Bot対策などを入口で実施したい）
- 複数バックエンド（APIM/アプリ/別サービス）への振り分けが必要
- TLSポリシーを入口で統一したい
ただしApplication Gateway単体でオンプレへ到達するわけではないため、オンプレ接続はVPN/ExpressRouteとセットで検討するのが基本です。「入口を守る（WAF）」「経路を守る（VPN/ER）」「APIを守る（APIM/認証）」を分担させると整理しやすくなります。
おすすめ構成パターン：要件別に“勝ち筋”を選ぶ
ここからは「結局どれにすればいいのか」を、現場で採用されやすい構成パターンとして具体化します。
パターン：APIM + Site-to-Site VPN（迷ったらまずこれ）
狙い：外部公開のガバナンス（認証・制御・監査）をAPIMで固めつつ、オンプレ到達はVPNで現実的に始める。
構成イメージ
[Internet] | [APIM（公開入口）] | [Primary API（Azure）] | (Azure VNet) --- S2S VPN --- (On-Prem) | [Secondary API（オンプレ）]
このパターンの強み
- 外部公開の入口をAPIMに集約でき、セキュリティ要件（認証、レート制限、監査）に強い
- VPNで早く疎通でき、段階的にExpressRouteへ移行しやすい
- Secondary APIはインターネット非公開のまま維持できる
実装時のポイント
- APIMでJWT検証やサブスクリプションキー等を組み合わせ、外部からの不正リクエストを入口で落とす
- オンプレFWで「Azure側送信元（NAT後IPやサブネット）→ Secondary APIの必要ポートのみ許可」にする
- Primary API→Secondary APIはmTLS（相互TLS）を検討し、ネットワーク内でも“なりすまし”を抑止する
パターン：APIM + ExpressRoute（本番高負荷・安定性重視）
狙い：APIトラフィックが多い、またはレスポンスの揺らぎが許容しづらい場合に、オンプレ接続をExpressRouteで堅牢化する。
向いている条件
- ピークトラフィックが大きい／大量のAPIコールが常態化
- レイテンシのブレがUXや処理に直結する
- VPNの運用（回線品質・切断・再接続）を吸収しきれない
注意点
- 回線手配、冗長構成、運用責任分界（キャリア/ネットワーク/クラウド）を事前に固める
- 「回線が強い＝安全」ではないため、APIMでの認証・制御、オンプレFWの最小許可は必ず維持する
パターン：オンプレ受信開放を避けたい（Relay / Self-hosted Gateway中心）
狙い：オンプレ側のセキュリティポリシーでインバウンドが厳しい場合に、外向き接続中心の形へ寄せる。
考え方
- オンプレにゲートウェイ（または接続コンポーネント）を置き、オンプレから外へ接続を張る
- クラウド側は「管理・認証・可観測性」を担い、オンプレ側は「実トラフィックの出口」を担う
このパターンが刺さる場面
- ネットワーク変更の承認が重く、VPN/ExpressRouteに着手するまで時間がかかる
- DMZに穴を開けられない、または開けたくない
- 段階的にクラウド移行しつつ、オンプレ資産と連携したい
セキュリティ設計：ネットワークがつながった瞬間に“守りが甘くなる”のを防ぐ
VPNやExpressRouteで到達できるようになると、つい「通ったからOK」となりがちです。しかし、そこで止めると内部侵害時の横展開や、設定ミスによる意図しない開放に弱くなります。安全にするためのチェックポイントを表でまとめます。
| 観点 | 推奨策 | 狙い |
|---|---|---|
| 外部公開の入口 | APIMやWAFで受け、Primary APIやSecondary APIへ直接当てない | 攻撃面を最小化し、防御・制御を共通化する |
| 認証・認可 | OAuth2/OIDC（JWT）を基本に、スコープ/ロールで細かく認可。必要ならmTLS併用 | ネットワーク内でも「誰が呼ぶか」を保証する |
| 通信の暗号化 | HTTPSを徹底。オンプレ区間でもTLSを維持し、証明書は計画的にローテーション | 盗聴・改ざん・なりすましを抑止する |
| 最小権限のネットワーク | オンプレFWで送信元/宛先/ポートを最小化。Azure側もNSGやFWで絞る | 到達可能範囲を“意図した最小”に固定する |
| レート制限・スパイク対策 | APIMで呼び出し制限、バースト制御、クォータを設定 | 過負荷・DoS・誤実装による突発トラフィックを抑える |
| 監査・可観測性 | 相関ID（Correlation ID）を統一し、APIM/アプリ/オンプレのログを追えるようにする | 障害解析とインシデント対応を高速化する |
| 秘密情報の管理 | キーや証明書は安全な保管（例：Key Vault）と自動更新を前提に設計 | 漏えいリスクと更新作業の属人化を抑える |
“API間通信”でやりがちな落とし穴：ネットワーク信頼だけに寄せない
オンプレへプライベート接続できると、「IP制限だけで十分」と考えたくなります。しかし、クラウド・オンプレをまたぐ構成は運用が長期化しやすく、設定変更も入ります。そこで有効なのが、アプリ層の保証を重ねる発想です。
- mTLS：Primary→Secondaryでクライアント証明書を要求し、正規クライアント以外の呼び出しを遮断
- JWT（署名検証）：APIMやPrimaryが発行・中継するトークンをSecondaryが検証し、権限に応じて処理を分岐
- 許可リスト（Allowlist）：呼び出し元サービスやアプリID単位で許可し、曖昧な共有キー運用を避ける
要件別の選び方：判断を速くする整理表
検討会で迷走しやすいのが「どれが正解か」の議論です。次の表のように、要件から逆算すると決めやすくなります。
| 要件 | 優先度が高い場合の推奨 | 補足 |
|---|---|---|
| 早くつなぎたい／検証から始めたい | S2S VPN +（可能なら）APIM | まず疎通を作り、設計の不足が見えたら強化する |
| 高帯域・低遅延・安定性が必須 | ExpressRoute + APIM | 回線冗長・運用設計もセットで考える |
| オンプレ側で受信を開けられない | Azure Relay または APIM Self-hosted Gateway | 外向き接続中心で設計し、到達範囲を制御する |
| 外部公開の統制（認証・制限・監査）が最重要 | APIM（入口集約） + WAF/ポリシー | API本体に防御ロジックを散らさないのがコツ |
| Web攻撃対策（WAF）が必須 | Application Gateway(WAF) + APIM | WAFは入口、APIMはAPI制御、と役割分担すると綺麗 |
可用性設計：接続経路が落ちたときに“APIが落ちたように見える”を防ぐ
クラウド→オンプレ連携は、アプリ自体が正常でも回線や経路の瞬断でユーザー影響が出ます。可用性は「ネットワーク冗長」だけでなく、「アプリのふるまい」まで含めて考えると実運用に強くなります。
ネットワーク側の基本
- VPNなら冗長トンネルや冗長装置、回線二重化を要件に応じて検討
- ExpressRouteなら冗長経路・冗長回線を前提に設計
- 経路障害の検知と切替（フェイルオーバー）を運用手順に落とし込む
アプリ側の基本（API連携の“強さ”はここで決まる）
- タイムアウト設計：オンプレ呼び出しのタイムアウトを無制限にしない（上流の待ち枯れを防ぐ）
- リトライ戦略：短い瞬断に備えるが、無限リトライや高頻度リトライは避ける（雪崩を防ぐ）
- サーキットブレーカー：オンプレが不調なときに早めに遮断し、全体遅延を拡大させない
- フォールバック：参照系ならキャッシュ返却、更新系なら受付だけして後続処理など、業務要件に合わせて設計
段階的な進め方：小さく始めて、必要に応じて強化する
最初から「最強構成」を狙うと、回線手配や運用設計で停滞しがちです。現実的には、次の順序が失敗しにくいです。
- 要件の棚卸し：帯域、遅延、可用性、セキュリティ（WAF/監査/認証）を最低限で言語化
- VPNで疎通を作る：到達性・名前解決・ルーティング・ログ設計の課題を顕在化させる
- 入口を整備（APIM/WAF）：外部公開の統制を先に固め、API本体の実装負担を減らす
- 最小許可（FW/NSG）を徹底：通った後に締めるのではなく、初期から絞る
- 監視・運用の型を作る：相関ID、失敗率、遅延、接続断を可視化し、切り分け可能にする
- 必要ならExpressRouteへ拡張：VPNの限界（帯域・安定性）が見えた段階で移行判断
よくある詰まりポイントと対策
IPレンジが重複してルーティングが崩れる
オンプレとAzureで同じプライベートIP帯を使っていると、経路が意図せず近い方に吸い込まれます。移行中に起きやすい事故なので、初期に必ずアドレス計画を確認します。
DNS解決ができず、疎通できないように見える
到達はできているのに名前解決ができず失敗するケースは頻出です。オンプレの名前解決が必要なら、Azure側のDNS設計（転送、プライベートDNS、解決経路）を早めに固めます。
非対称ルーティングで通信が返ってこない
Azure→オンプレは行けるのに、戻りが別経路に出てしまいFWで破棄されるケースがあります。トレースやログで「往復経路」を前提に確認し、ルートとNATの設計を見直します。
“つながった”途端に、オンプレ側が過負荷になる
クラウド側はスケールしやすい一方、オンプレAPIは急な負荷増に弱いことがあります。APIMでレート制限を入れ、スロットリングやキューイングなど“入口で吸収”する設計が有効です。
まとめ：外部公開はAzure側で完結させ、オンプレは最小公開で守る
AzureにPrimary APIを移して外部公開する場合、オンプレのSecondary APIまでインターネットに晒す必要はありません。安全で運用しやすい構成のポイントは次の通りです。
- Azure→オンプレ接続は、まずSite-to-Site VPNで現実的に始め、必要に応じてExpressRouteへ拡張する
- 外部公開の入口はAPIM（必要ならWAF）に集約し、認証・制御・監査を統一する
- Secondary APIはインターネット非公開を基本にし、FW/NSGで最小許可、さらにmTLS/JWT等のアプリ層保証を重ねる
- 可用性は回線冗長だけでなく、タイムアウト/リトライ/遮断/フォールバックまで含めて設計する
「まずVPNで疎通→入口（APIM）で統制→運用しながら必要なところを強化」という順序で進めると、過不足のないセキュア構成に着地しやすくなります。
コメント