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

【初心者向け】ゼロから学ぶ！ JuniperでAzure×AWS VPN接続 2026年7月31日 (検証実施時期：2025年6-10月) 株式会社エヌアイデイ ICTデザイン事業部ANA部第2課 Copyright(c)2026 NID All Rights Reserved 1

参加メンバー ICTデザイン事業部ANA部第2課 ICTデザイン事業部ANA部第2課 ICTデザイン事業部ANA部第2課 ICTデザイン事業部ANA部第2課 ICTデザイン事業部ANA部第2課 ICTデザイン事業部ANA部第2課 K.K. R.S. A.K. H.M. T.T. Y.K. （2年目 ※検証当時） （1年目 ※検証当時） （2年目 ※検証当時） （2年目 ※検証当時） （2年目 ※検証当時） （1年目 ※検証当時） ※2025年6月～10月検証実施 2

目次 本資料はマルチクラウド接続の基本検証結果を 整理したものである。 ・本検証の目的 ・本検証の目標 ・検証内容 ・検証結果 ・構築(概要) ・検証中の課題 ・総評、今後の課題 ※本資料に登場する会社名・製品・サービス名、ロゴマーク などは 該当する各社の商号・商標または登録商標です。 3

本検証の目的 ■背景 マルチクラウド構成の普及により今後のクラウドネットワーク分野では、 単一クラウド前提ではなく、 異なるクラウド間の接続設計・実装が求められている ■目的 Azure-AWS間のVPN接続方式および通信制御方式を確認する ■期待効果 マルチクラウド接続設計・実装のベースを確立することで、 実案件におけるマルチクラウド環境への知見を強化する 4

本検証の目標 ■検証前提 ・異なるクラウド間での接続性を確保できる再現容易な方式で検 証する ・VPNを用いたコスト効果の高い接続方式を採用し検証する ■検証目標 ①AzureとAWSの間でVPN接続を確立する ②仮想アプライアンス(Juniper)による通信制御について確認する 5

検証内容①内容説明 ■検証観点 VM単位での通信制御可否を確認するため、異なる通信パターンを設定する。 検証条件 ①特定のVM(VM1)とEC2は相互ICMP接続可能とする ②特定のVM(VM2)とEC2はVM2からのみICMP接続可能とする ③特定のVM(VM3)とEC2はICMP接続不可能とする ④EC2上にwebサーバを構築しVMからHTTP接続を可能とする 以上の条件について、Juniperで制御を行う。 6

検証内容②本検証の主な対象 ■Azure ・本検証での役割：通信元クラウド ■AWS ・本検証での役割：通信先クラウド ■Juniper ・本検証での役割：通信制御基盤 7

検証結果 VM単位およびプロトコル単位で通信制御が可能であることを確認した。 VM→EC2 通信 検証内容 特定のAzure上バーチャルマシン(VM1)とAWS上EC2につ いて、 ICMP通信で相互接続可能 特定のAzure上バーチャルマシン (VM2)とAWS上EC2につ いて、 EC2→VM 通信 検証結果 検証成功 検証成功 ICMP通信でAzure側からのみ接続可能 特定のAzure上バーチャルマシン (VM3)とAWS上EC2につ いて、 ICMP通信で接続不可能とする 検証成功 特定のAzure上バーチャルマシン(VM1)からAWS上EC2に むけて、 HTTP接続 検証成功 凡例 通信可能 通信不可 対象外 8

構築(概要) 本構成では、AzureとAWSをVPN接続し、Juniper vSRXにより通信制御を行う。 ■構成概要 ・Azure環境(VNet)に仮想マシン(VM)を配置する ・AWS環境(VPC)にEC2を配置する ・両環境をVPN Gatewayにより接続する ・Juniper vSRXを経由し通信制御を実施する ■通信経路 通信の経路は以下の通り Azure VM ⇔ Juniper vSRX ⇔ VPN ⇔ AWS EC2 9

構築(概要) ■通信制御の概要 ・Juniper vSRXにより通信制御を実施する ・VM単位で接続可否を制御する ・ICMPおよびHTTP通信を対象に検証する ■通信条件(設計方針) ・VMごとにICMP通信の許可/制限を設定する ・HTTP通信はEC2上のWebサーバにて受信するものとする 10

構築(概要) 本構成では、AzureとAWSをVPN接続し、Juniper SRXにより通信制御を行う 11

構築(概要) Azureに存在するVMからAWS内のEC2へ接続を試みる。 これらについて、業務通信の制御を想定し、 端末単位で接続制御を検証する。 図で示す通信の条件は以下の通りとする。 ①特定のAzure上バーチャルマシン(VM1)とAWS上EC2は 相互接続可能とする ②特定のAzure上バーチャルマシン (VM2)とAWS上EC2は VM2からのみ接続可能とする ③特定のAzure上バーチャルマシン (VM3)とEC2は 双方ともに接続不可能とする 12

構築(概要) 本スライドではICMP通信制御の条件のうち、①の通信を示す 凡例 双方向通信可能 片方向通信可能 通信不可能 13

構築(概要) 本スライドではICMP通信制御の条件のうち、②の通信を示す 凡例 双方向通信可能 片方向通信可能 通信不可能 14

構築(概要) 本スライドではICMP通信制御の条件のうち、③の通信を示す 凡例 双方向通信可能 片方向通信可能 通信不可能 15

構築(概要) Azureに存在するVMからAWS内のEC2へHTTP接続を試みる。 この試験のため、以下の構築を行う。 ・AWS内のEC2上にWebサーバー構築 ・EC2内のセキュリティグループに、 HTTP接続が出来るようインバウンドルールを追加(Port80) 16

構築(概要) 本検証において、検証するHTTP通信 凡例 双方向通信可能 片方向通信可能 通信不可能 17

検証に伴う課題① 過去のEntra IDの消失 問題 昨年の検証で利用したEntra IDを利用しようとしたところ、 接続不可能となっていた。 原因 ■テナントライフサイクル テナントに90日間誰もログインしなかった場合、 そのテナントは｢非アクティブ｣として削除されてしまう。 →テナントライフサイクルにかかったことにより、テナントが削除されていた。 対応 今回は新規テナントの立ち上げにより対応。 ポイント 課金可能アカウントの情報を登録しておくと、 テナントライフサイクルは回避可能！ 18

検証に伴う課題① 過去のEntra IDの消失 ログインを試みた際に発生した画面 19

検証に伴う課題② Azure Virtual Machine(VM)の種類 問題 Azure VMにおいて、インスタンスシリーズが多数あり、 単に金額のみで性能を決定するとスペックの過不足が発生しうるため、 各シリーズの性能について把握し採用しなければならない。 原因 インスタンスシリーズは全部で9種類。 ※詳細は次ページ 対応 コスト面とスペックの両面から検討し、 本検証では最安インスタンスのBsシリーズを選択した。 20

検証に伴う課題② Azure Virtual Machine(VM)の種類 種類 (参考) ※検証当時 21

検証に伴う課題③ AzureパブリックIPアドレスのプラン 問題 Azureにて、対外接続に利用するパブリックIPアドレスを取得するための プランとして、検討時には4つのプランが存在したが、最安値である Basicプランについて廃止が決定している。 種類 対応 Basicプランについては廃止と検証期間の重複に伴う コストや設定の変化を避けるため、採用しないこととした。 また、グローバル(ARM)はリージョンをまたぐ通信専用のプランである。 以上より、本検証目的に唯一適している 22 StandardパブリックIPアドレスを採用した。

検証に伴う課題④ Azure Virtual Networkの課金対象見誤り 問題 当初は課金要素として契約を予定をしていたが、 再調査の結果｢リージョン/Vnet間通信に関してのみ課金が必要｣ という要素であり、 Vnetを1つのみ作成する本検証では不要な課金ということが判明した。 対応 名称から契約が必要なリソースと誤認しやすいため、 課金要素を認識し、注意する必要がある。 特に、Vnetについては条件付き課金である点に注意が必要である。 23

検証に伴う課題⑤ サブスクリプション作成不可 問題 テナント作成後、サブスクリプションの作成ができなかった。 原因 サブスクリプションを作成するには利用するクレジットカード情報、 サブスクリプションの所属するテナントにおいて 課金が可能なアカウント情報が必要だった。 対応 新規に新サブスクリプションのアドミンアカウントを発行し、 そのアカウントを利用してサブスクリプションを作成した。 ポイント サブスクリプション作成前に利用クレジットカードを確定させると安心 24

検証に伴う課題⑥ 課金登録へのアカウント再利用不可 問題 Azureにてテナント作成に利用したアカウントについて、 課金登録では利用できない状況となった。 原因 新テナント作成時に利用したアカウントの所属テナントが 別テナントであり、新テナント内ではゲスト扱いであったこと。 対応 課金アカウントは新テナントに所属するアカウントのみが登録できる。 そのため、アカウントのテナント移動か新規アカウント発行が必要となる。 ポイント 1テナント1管理アカウントの原則を覚えておこう！ 25

検証に伴う課題⑥ 課金登録へのアカウント再利用不可 元テナント 旧テナントアカウント ([email protected]) 新テナント テナント作成 このアカウントでは 課金できない！ 新テナント内旧テナントアカウント (~.xxx.onmicrosoft.com#EXT#@yyy.onmicrosoft.com) アカウント作成 新テナントアカウント ([email protected]) このアカウントなら課金可 能！ 26

検証に伴う課題⑦ ロール権限付与の種類 問題 Azureのロール権限の付与についてサブスクリプション作成者に 自動的に権限が付与されていたが、 追加アカウントには権限が付与されていなかった。 原因 サブスクリプション作成者は自動的にOwner権限を持つが、 追加アカウントは作成しただけでは権限を持たない。 対応 追加アカウントについても｢アクセス制御(IAM)｣からロールを付与する ことで、リソースの操作が可能となった。 27

検証に伴う課題⑦ ロール権限付与の種類(詳細) 種類 ■ サブスクリプション作成者→ ｢Owner/Service Administrator/Account Administrator｣権限を持つ。 ■追加アカウント → 権限を持たない。 RBACで｢Owner/Contributor/Reader｣などを追加し、 必要に応じてサービス固有ロールを付与できる。 28

検証に伴う課題⑧ Azure Subnet内で利用できるPrivate IP 問題 Azureでは5つのIPアドレスが予約されているため、 それ以外のIPアドレスを利用する必要がある。 詳細 以下はAzureで予約されているPrivate IP一覧である。 29

検証に伴う課題⑨ Azureのリソース従量課金制御 問題 VPNGatewayやRoute Serverは固定で時間課金される費用が 想定より高額だったため、予算超過の懸念が生じた。 原因 ■VPNGateway(VpnGw1)： 約 6.3円/時間(約 4,500円/月) ※別途、データ転送量課金(アウトバウンド通信量に応じて)加算 ■Azure Route Server：約 70円/時間(約 50,000円/月) ※データ転送課金はなく、固定料金のみ 対応 Azure Route Serverの利用は廃止し、VPNGatewayは検証テスト後すぐに 削除して固定費用を抑えた。同時にコスト分析ダッシュボードにて 都度利用料を確認し、予算超過がないように管理した。 30

検証に伴う課題⑨ Azureのリソース従量課金制御 <ダッシュボード画面> 31

検証に伴う課題⑩ Juniper vSRXへのSSH接続失敗 問題 起動時以下のエラーが表示されSSH接続ができない。 原因 例として表示されていた以下のユーザ名の誤りが原因となり、｢root｣の 部分について｢ec2-user｣が正しいユーザ名だった。 対応 ユーザ名を確認し、接続コマンドを修正した。 32

検証に伴う課題⑪ VPN接続不可 問題 PSKは合っているものの認証エラーが出続けて、 IKEv1の段階から通信ができない。 原因 トラフィックセレクターの設定が不足している事が原因だった。 対応 トラフィックセレクター設定について追加することで、通信可能となった。 備考 本設定について内容が散逸していたため、 実際の環境構築の際に見落としやすい。 そのため、要注意の設定となる。 33

検証に伴う課題⑫ Azure側からのPing疎通不可 問題 VPN接続は可能となりAWS側からAzure側へのPing疎通確認はできたが、 Azure側からAWS側へのPingが飛ばない。 原因 Juniper vSRXでは、 FW設定によりICMP制御を明示的に行うことが必要だった。 対応 ICMPの許可設定を追加し、疎通確認が可能となった。 34

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

総評 ■成果 ①Azure環境をテナント用意部分から行うことで、Azure環境の立ち上げから 実用開始までの基礎部分を体験することができた。 ②Juniper SRXという今後利用シーンの増える可能性のある機器に関して各種 設定や使い方を確認することができた。 以上より、 本検証によって、 ・Azure環境及びJuniper SRXについて基本的知見を得ることができた。 ・手順確立により組織・チームとして再現性も確保できた。 36

総評 ■今後の課題 今後、本検証では検証しきれなかった以下の内容の検証が課題となる。 ・他プロトコル(HTTPS/SSH等)の検証 ・冗長構成検証 ・実運用を想定した監視/ログ設計の検討 ■最後に 本検証ではAzure領域について扱い方の基礎から学ぶことができた。 本検証で得ることのできたAzureポータルの操作やEntra IDの作成からAzureサ ブスクリプションの立ち上げなどの経験を今後のAzure関連領域での業務に活 かしていきたい。 37

参考資料 ・publickey クラウドインフラの市場状況について https://www.publickey1.jp/blog/25/aws30azure2220251synergy_research.html ・juniper SRXシリーズファイアウォール https://www.juniper.net/jp/ja/products/security/srx-series.html ・Azure portal でサイト間 VPN 接続を作成 https://learn.microsoft.com/ja-jp/azure/vpn-gateway/tutorial-site-to-site-portal ・AWSで実行されるvSRX仮想ファイアウォールの要件 https://www.juniper.net/documentation/jp/ja/software/vsrx/vsrx-consolidated-deployment-guide/vsrxaws/topics/concept/security-vsrx-aws-system-requirements.html ・juniper ルートベースVPNにおけるトラフィックセレクター https://www.juniper.net/documentation/jp/ja/software/junos/vpn-ipsec/topics/topic-map/security-traffic-selectors-inroute-based-vpns.html ・Microsoft Entra ID とは https://learn.microsoft.com/ja-jp/training/modules/manage-users-and-groups-in-aad/2-create-aad 38

• https://www.publickey1.jp/blog/25/aws30azure2220251synergy_research.html
• https://www.juniper.net/jp/ja/products/security/srx-series.html
• https://learn.microsoft.com/ja-jp/azure/vpn-gateway/tutorial-site-to-site-portal
• https://www.juniper.net/documentation/jp/ja/software/vsrx/vsrx-consolidated-deployment-guide/vsrx-aws/topics/concept/security-vsrx-aws-system-requirements.html
• https://www.juniper.net/documentation/jp/ja/software/junos/vpn-ipsec/topics/topic-map/security-traffic-selectors-in-route-based-vpns.html
• https://learn.microsoft.com/ja-jp/training/modules/manage-users-and-groups-in-aad/2-create-aad