【初心者向け】ゼロから学ぶ！JuniperでAzure×AWS VPN接続

クラウド活用が進むなかで、企業システムは単一クラウドだけで完結する構成から、複数のクラウドサービスを組み合わせるマルチクラウド構成へと広がりつつあります。今後のクラウドネットワーク分野では、AzureやAWSといった異なるクラウド間を安全かつ安定的に接続し、業務要件に応じて通信を制御する設計・実装力が求められます。

本検証では、Azure-AWS間のVPN接続方式および通信制御方式を確認することを目的に、Juniper vSRXを利用したマルチクラウド接続の基本検証をおこないました。検証実施時期は2025年6月～10月で、Azure環境の立ち上げからVPN接続、Juniperによる通信制御、疎通確認までを一連の流れとして実施しています。

※本記事はスライドの記載内容をもとに、検証の要点を簡潔にまとめています。詳細な検証内容や技術的な説明は埋め込みのスライド本文をご参照ください。

本検証の目的は、Azure-AWS間のVPN接続方式および通信制御方式を確認することです。マルチクラウド接続設計・実装のベースを確立することで、実案件におけるマルチクラウド環境への知見を強化することを期待効果としています。

具体的な検証目標は、AzureとAWSの間でVPN接続を確立すること、そして仮想アプライアンスであるJuniperによる通信制御について確認することです。検証では、異なるクラウド間での接続性を確保できる再現容易な方式を採用し、VPNを用いたコスト効果の高い接続方式を前提としました。

本構成では、AzureとAWSをVPN接続し、Juniper vSRXにより通信制御をおこないました。Azure環境にはVNetと仮想マシン(VM)を配置し、AWS環境にはVPCとEC2を配置しています。両環境はVPN Gatewayにより接続し、通信は「Azure VM ⇔ Juniper vSRX ⇔ VPN ⇔ AWS EC2」という経路でおこなう構成です。

通信制御の対象は、VM単位での接続可否、およびICMP・HTTP通信です。Juniper vSRXにより通信制御を実施し、VMごとにICMP通信の許可・制限を設定しました。また、HTTP通信については、AWS上のEC2にWebサーバーを構築し、EC2のセキュリティグループにHTTP接続用のインバウンドルールを追加して検証しました。

検証条件は、主に4つです。

一つ目は、特定のAzure上バーチャルマシンであるVM1とAWS上EC2が相互にICMP接続可能であること。

二つ目は、VM2とEC2がVM2からのみICMP接続可能であること。

三つ目は、VM3とEC2がICMP接続不可能であること。

四つ目は、EC2上にWebサーバーを構築し、VMからHTTP接続を可能とすることです。

※詳細な検証手順はスライド本文をご参照ください

検証の結果、VM単位およびプロトコル単位で通信制御が可能であることを確認しました。VM1とEC2の相互ICMP接続、VM2からEC2への片方向ICMP接続、VM3とEC2間のICMP接続不可、VM1からEC2へのHTTP接続の各条件について、いずれも検証成功となりました。

この結果から、Azure-AWS間においてVPN接続による安定通信の確立が低コストで実現可能であること、またJuniper vSRXシリーズを利用した通信制御が実務に対応できるレベルで可能であることを確認しました。以上より、Azure-AWS間におけるVPN接続およびJuniperによる通信制御は、実環境で適用可能なレベルで実現できると評価しています。

一方で、検証を進めるなかでは、Azure環境の立ち上げやクラウドサービス特有の仕様理解に関する課題も発生しました。例えば、過去の検証で利用したEntra IDを利用しようとしたところ接続不可能となり、テナントライフサイクルによりテナントが削除されていたことが判明しました。今回は新規テナントの立ち上げにより対応し、課金可能アカウントの情報を登録しておくことでテナントライフサイクルを回避できるという知見を得ました。

また、Azure VMの種類については、インスタンスシリーズが多数あり、単に金額のみで性能を決定するとスペックの過不足が発生しうるため、各シリーズの性能を把握して採用する必要があることを確認しました。本検証では、コスト面とスペックの両面から検討し、最安インスタンスのBsシリーズを選択しています。

AzureパブリックIPアドレスのプラン選定でも注意点がありました。検討時点では複数のプランが存在していましたが、Basicプランは廃止が決定していたため、廃止と検証期間の重複にともなうコストや設定の変化を避ける目的で採用しませんでした。また、グローバル（ARM）はリージョンをまたぐ通信専用のプランであることから、本検証目的に適したStandardパブリックIPアドレスを採用しました。

コスト面では、VPN GatewayやRoute Serverの固定時間課金が想定より高額であり、予算超過の懸念が生じました。そのため、Azure Route Serverの利用は廃止し、VPN Gatewayは検証テスト後すぐに削除して固定費用を抑えました。同時に、コスト分析ダッシュボードで都度利用料を確認し、予算超過がないよう管理しました。

技術面では、Juniper vSRXへのSSH接続失敗やVPN接続不可、Azure側からのPing疎通不可といった課題も発生しました。SSH接続ではユーザ名の誤りが原因であり、正しいユーザ名に接続コマンドを修正することで対応しました。VPN接続では、PSKは合っていたもののIKEv1の段階から通信できず、トラフィックセレクター設定の不足が原因でした。設定を追加することで通信可能となりました。さらに、Azure側からAWS側へのPingが飛ばない問題については、Juniper vSRXにおいてFW設定によりICMP制御を明示的におこなう必要があり、ICMPの許可設定を追加することで疎通確認が可能となりました。

これらの課題は、単に設定手順を確認するだけでは見落としやすいポイントです。特に、テナント・サブスクリプション・課金アカウント・ロール権限・ネットワーク設定・ファイアウォール制御は、クラウド環境を実利用に近い形で構築するうえで重要な確認事項となります。

本検証では、Azure-AWS間のVPN接続およびJuniper vSRXによる通信制御について、実環境で適用可能なレベルで実現できることを確認しました。また、Azure環境をテナント用意部分からおこなうことで、Azure環境の立ち上げから実用開始までの基礎部分を体験できました。さらに、Juniper SRXという今後利用シーンの増える可能性のある機器について、各種設定や使い方を確認できたことも成果です。

本検証によって、Azure環境およびJuniper SRXについて基本的知見を得ることができ、手順確立により組織・チームとして再現性も確保できました。これは、マルチクラウド環境を提案・設計・構築するSIerにとって、技術力の蓄積と標準化の両面で意義のある取り組みです。

※本資料に登場する会社名・製品・サービス名、ロゴマークなどは該当する各社の商号・商標または登録商標です。