オンプレミスとクラウドを接続する基本構成

2026年7月19日2026年7月20日

当ページのリンクには広告が含まれています。

対象レベル：Level 2〜3
想定読了時間：20分
身につく成果：オンプレミスとクラウドを接続する構成を比較し、基本設計の確認項目を説明できる
関連スキル：IPsec VPN／専用線／BGP／DNS／冗長化／障害切り分け

オンプレミス環境にある業務サーバーや社内ネットワークと、AWSやAzureなどのクラウドを接続する構成は、「ハイブリッドクラウド」と呼ばれます。

クラウド移行案件では、すべてのシステムを一度にクラウドへ移すとは限りません。

たとえば、次のような構成がよくあります。

Webサーバーだけクラウドへ移行する
データベースはオンプレミスに残す
Active Directoryや認証サーバーを継続利用する
オンプレミスのバックアップデータをクラウドへ転送する
社内端末からクラウド上の業務システムを利用する

このようなシステムでは、オンプレミスとクラウドの間に安全な通信経路を作る必要があります。

ただし、VPNトンネルを確立しただけでは、安定したハイブリッドネットワークとはいえません。

実務では、次の項目をまとめて設計する必要があります。

IPアドレス
ルーティング
冗長化
セキュリティ
DNS
帯域と遅延
監視
障害時の切り替え

本記事では、オンプレミスとクラウドを接続する基本構成と、ネットワークエンジニアが設計時に確認すべきポイントを解説します。

結論：基本構成は「VPN」と「専用線」の2種類

オンプレミスとクラウドを接続する代表的な方式は、大きく次の2種類です。

インターネットVPN
専用線・閉域網接続

さらに、本番環境の重要なシステムでは、専用線を主回線、インターネットVPNをバックアップ回線として併用する構成があります。

接続方式	特徴	主な用途
インターネットVPN	インターネット上に暗号化トンネルを作る	検証、小規模環境、バックアップ
専用線・閉域接続	通信事業者などを介してプライベート接続する	基幹システム、大容量通信
専用線＋VPN	専用線を主回線、VPNを予備回線にする	停止影響が大きい本番環境

AWSではSite-to-Site VPNとDirect Connect、AzureではVPN GatewayとExpressRoute、Google CloudではCloud VPNとCloud Interconnectが、それぞれ代表的なサービスです。AWSのDirect ConnectやAzure ExpressRoute、Google CloudのCloud Interconnectは、オンプレミスとクラウドをプライベートな経路で接続するために使われます。

なぜオンプレミスとクラウドを接続するのか

ハイブリッド接続が必要になる代表的な理由は、次の4つです。

1．段階的にクラウドへ移行するため

既存システムを一度にすべて移行すると、障害発生時の影響や移行リスクが大きくなります。

そのため、次のように段階的に移行することがあります。

第1段階：開発・検証環境をクラウドへ移行
第2段階：Web・アプリケーションサーバーを移行
第3段階：データベースや認証基盤を移行
第4段階：オンプレミス環境を縮小

移行期間中は、クラウド上のアプリケーションからオンプレミスのデータベースへアクセスするなど、両環境をまたぐ通信が必要です。

2．オンプレミスの既存資産を利用するため

クラウドへ移行しにくいシステムもあります。

特殊なハードウェアを使用している
製造設備と接続している
古いOSやアプリケーションが稼働している
ライセンス上の制約がある
データの保管場所に要件がある

この場合、既存システムをオンプレミスに残しながら、クラウド上の新しいシステムと連携させます。

3．クラウドをバックアップ先として利用するため

オンプレミスのデータをクラウドストレージへバックアップする構成です。

平常時はバックアップデータだけを転送し、災害や障害が発生したときにクラウド側でシステムを復旧します。

ただし、バックアップデータの量が多い場合、回線帯域だけでなく、復旧時にデータを戻す時間も考えなければなりません。

4．社内からクラウドのプライベート環境へアクセスするため

クラウド上のサーバーにパブリックIPアドレスを付与せず、社内ネットワークからだけアクセスさせる構成です。

管理画面、社内業務システム、データベースなどをインターネットへ直接公開しないことで、攻撃対象となる範囲を小さくできます。

基本構成1：インターネットVPN

インターネットVPNでは、オンプレミス側のVPNルーターまたはファイアウォールと、クラウド側のVPNゲートウェイの間にIPsecトンネルを作成します。

社内LAN
   │
オンプレミスルーター／ファイアウォール
   │
   ├── インターネット
   │        │
   │     IPsec VPN
   │        │
クラウドVPN Gateway
   │
VPC／VNet
   │
クラウドサーバー

AWS Site-to-Site VPNでは、オンプレミス側の物理装置またはソフトウェアがCustomer Gateway Deviceに相当します。クラウド側では、単一VPCに接続するVirtual Private Gatewayや、複数VPCを集約するTransit Gatewayなどを使用します。

インターネットVPNのメリット

インターネットVPNは、新しい物理回線を敷設しなくても開始できるため、比較的短期間で導入しやすい方式です。

向いている用途は次のとおりです。

検証環境
開発環境
小規模システム
通信量が少ないシステム
専用線開通までの暫定接続
専用線障害時のバックアップ

IPsecによって通信を暗号化できることも重要な特徴です。

インターネットVPNの注意点

インターネットを経由するため、通信品質は利用中のインターネット回線に影響されます。

確認すべき項目は次のとおりです。

回線の上り帯域
遅延と揺らぎ
パケットロス
VPN装置の暗号化性能
NATの有無
固定グローバルIPアドレス
ISP障害時の影響
通信量増加時の性能

特に見落とされやすいのが、オンプレミス側の上り帯域です。

クラウドからデータをダウンロードする処理だけでなく、バックアップやログ転送、ファイルアップロードでは、オンプレミスからクラウドへの上り通信が多くなります。

基本構成2：専用線・閉域網接続

専用線系の接続では、クラウド事業者や通信事業者が提供するプライベートなネットワーク経路を使用します。

オンプレミス
   │
顧客ルーター
   │
通信事業者・接続拠点
   │
クラウド専用接続サービス
   │
クラウドルーター／ゲートウェイ
   │
VPC／VNet

Azure ExpressRouteは、接続プロバイダーを利用してオンプレミスネットワークをMicrosoft Cloudへプライベート接続するサービスです。Google CloudのDedicated Interconnectも、オンプレミスネットワークとGoogleのネットワークを物理的な直接接続で結びます。

専用線接続のメリット

一般的には、インターネットVPNと比べて次の点で有利です。

通信品質を安定させやすい
大容量通信に対応しやすい
遅延を予測しやすい
インターネット経路から分離できる
基幹システムに採用しやすい

大量のバックアップ、データベース連携、VDI、ファイルサーバーなど、継続的に多くのデータを送受信するシステムで検討されます。

専用線接続の注意点

専用線を利用しているからといって、すべての通信が自動的に暗号化されるとは限りません。

「パブリックインターネットを経由しないこと」と「通信内容が暗号化されていること」は別の要件です。

暗号化が必要な場合は、専用線上にIPsec VPNを重ねる構成も検討します。AWSはDirect Connect上でプライベートIPのSite-to-Site VPNを利用する構成を提供しており、Google CloudにもInterconnect上でHA VPNを使用する構成があります。

また、次のコストと作業期間を考慮する必要があります。

回線初期費用
月額回線費用
接続ポート費用
通信事業者の費用
ルーターや光トランシーバー
データ転送料
回線開通までの期間
現地作業や接続拠点での作業

基本構成3：専用線＋VPNバックアップ

停止影響が大きいシステムでは、専用線だけに依存しない構成を検討します。

                      ┌─ 専用線 ─────────┐
オンプレミスルーター ─┤                    ├─ クラウド
                      └─ Internet VPN ───┘

通常時は専用線を使用し、専用線に障害が発生した場合はインターネットVPNへ切り替えます。

AzureではExpressRouteとSite-to-Site VPNを共存させ、VPNをバックアップとして使用する構成が案内されています。

ただし、回線を2本用意するだけでは十分ではありません。

次のような共通部分が残っていると、障害時に両方の回線が同時に利用できなくなる可能性があります。

同じオンプレミスルーターを使用している
同じISPに依存している
同じ建物引き込み経路を使用している
同じ電源設備を使用している
同じクラウド接続拠点を使用している
同じルートテーブル設定に誤りがある

冗長化では「回線が2本あるか」ではなく、どの障害まで継続できるかを確認します。

Azure VPN Gatewayでは、アクティブ・アクティブ構成にすると、両方のゲートウェイインスタンスからオンプレミスVPN装置へトンネルを確立できます。

クラウドごとの主なサービス名称

名称は異なりますが、基本的な役割は共通しています。

役割	AWS	Azure	Google Cloud
仮想ネットワーク	VPC	Virtual Network	VPC Network
インターネットVPN	Site-to-Site VPN	VPN Gateway	Cloud VPN／HA VPN
専用線系接続	Direct Connect	ExpressRoute	Dedicated／Partner Interconnect
動的経路制御	BGP	BGP	Cloud Router／BGP
集約ルーター	Transit Gateway	Virtual WAN／Hub VNet	Network Connectivity Center
ハイブリッドDNS	Route 53 Resolver	DNS Private Resolver	Cloud DNS Forwarding

ここで重要なのは、クラウド固有のサービス名を暗記することではありません。

まず、次の役割を理解してください。

オンプレミス側ルーター
        ↓
接続回線・VPNトンネル
        ↓
クラウド側ゲートウェイ
        ↓
クラウドルートテーブル
        ↓
サブネット
        ↓
サーバー・PaaS

設計ポイント1：IPアドレスを重複させない

ハイブリッド接続で最初に確認すべき項目は、IPアドレスです。

たとえば、オンプレミスとクラウドの両方で 192.168.1.0/24 を使用している場合、ルーターは同じ宛先ネットワークを区別できません。

良い例

オンプレミス：10.10.0.0/16
AWS VPC：     10.20.0.0/16
Azure VNet：  10.30.0.0/16
管理用：      10.40.0.0/20

問題がある例

本社LAN：     192.168.1.0/24
AWS VPC：     192.168.1.0/24

アドレスが重複している場合、NATによる回避策もありますが、設計と障害切り分けが複雑になります。

将来の拠点追加、VPC追加、他クラウド接続まで考え、最初からアドレス管理表を作成することが重要です。

設計ポイント2：スタティックルートとBGPを選ぶ

オンプレミスとクラウドの間で通信するには、お互いのネットワークへの経路が必要です。

経路を設定する方法は、大きく次の2つです。

スタティックルート

管理者が経路を手動で登録します。

10.20.0.0/16 → VPNトンネル1

小規模でネットワーク変更が少ない環境では、構成を理解しやすい点がメリットです。

一方で、拠点やクラウドネットワークが増えると、経路の追加・削除作業が増えます。

BGP

オンプレミスルーターとクラウド側ゲートウェイが、経路情報を動的に交換します。

オンプレミス → 10.10.0.0/16を通知
クラウド     → 10.20.0.0/16を通知

BGPを利用すると、回線障害時に経路を自動的に切り替えやすくなります。

Azure VPN GatewayもBGPによる動的ルーティングをサポートしています。

ただし、BGPを有効にしただけで、意図した経路になるとは限りません。

次の項目を確認します。

広報するネットワーク
受信を許可するネットワーク
デフォルトルートの扱い
主回線と予備回線の優先順位
AS番号
経路集約
非対称ルーティング
BGPセッション切断時の動作

設計ポイント3：戻り経路まで確認する

疎通試験では、送信元から宛先へ届く経路だけでなく、宛先から送信元へ戻る経路も必要です。

往路：
オンプレ端末
  → VPN
  → クラウドルーター
  → クラウドサーバー

復路：
クラウドサーバー
  → クラウドルーター
  → VPN
  → オンプレ端末

往路だけ正しくても、復路がインターネットゲートウェイや別のファイアウォールへ向いていると、通信は成立しません。

特に次の構成では、非対称ルーティングに注意します。

VPNと専用線を併用している
ファイアウォールが複数ある
拠点間WANとクラウド接続が混在している
デフォルトルートをクラウドへ通知している
クラウド内に複数のルートテーブルがある
NAT装置を経由している

設計ポイント4：DNSを忘れない

IPアドレスでは通信できるのに、ホスト名では接続できない場合、DNS設計に問題がある可能性があります。

ハイブリッド環境では、次の両方向の名前解決が必要です。

オンプレミス → クラウドのプライベートDNS名
クラウド     → オンプレミスの社内DNS名

たとえば、次のようにドメインを分けます。

オンプレミス：corp.example
クラウド：    cloud.example

オンプレミスDNSに条件付きフォワーダーを設定し、cloud.example の問い合わせをクラウド側のResolverへ転送します。

クラウド側では、corp.example の問い合わせをオンプレミスDNSへ転送します。

AWS Route 53 Resolverでは、オンプレミスからVPCへ問い合わせを受けるInbound Endpointと、VPCからオンプレミスDNSへ問い合わせるOutbound Endpointを利用できます。

Azure DNS Private Resolverも、オンプレミスとAzure間の双方向のプライベートDNS名前解決に利用できます。

Google Cloudでは、Cloud DNSのフォワーディングゾーンやDNSサーバーポリシーを使用して、オンプレミスとGoogle Cloud間の名前解決を構成できます。

DNS設計で確認すること

どのDNSサーバーが各ドメインを管理するか
条件付きフォワーダーの設定
DNS通信のルーティング
UDP/TCP 53番ポートの許可
DNSサーバー障害時の動作
複数拠点からの問い合わせ経路
Private Endpointなどの名前解決
キャッシュとTTL
切り替え時の名前解決

設計ポイント5：ファイアウォールを複数箇所で確認する

クラウドでは、オンプレミス側ファイアウォール以外にも複数の制御ポイントがあります。

オンプレミス端末
  ↓
オンプレミスFW
  ↓
VPN／専用線
  ↓
クラウドFW
  ↓
サブネットACL
  ↓
Security Group／NSG
  ↓
OSファイアウォール
  ↓
アプリケーション

通信できないときは、すべての制御ポイントを確認します。

通信要件表の例

送信元	宛先	プロトコル	ポート	用途
10.10.10.0/24	10.20.10.10	TCP	443	社内端末からWebシステム
10.20.20.0/24	10.10.30.20	TCP	1433	アプリからDB
10.20.0.0/16	10.10.1.53	UDP/TCP	53	DNS問い合わせ
10.10.50.10	10.20.50.10	TCP	22	運用管理

「オンプレミスとクラウド間をすべて許可する」という設定は避け、必要な送信元、宛先、ポートに限定します。

設計ポイント6：冗長化の範囲を決める

冗長化では、どの障害を対象にするかを明確にします。

障害対象	冗長化の例
VPNトンネル	複数トンネル
オンプレ装置	ルーター／FWを2台構成
ISP	異なるISPを使用
回線	VPNと専用線を併用
接続拠点	異なるロケーションへ接続
クラウドリージョン	複数リージョンへ接続
電源	異なる電源系統
DNS	複数Resolver／DNS経路

AWS Direct Connectでは、可用性要件に応じて複数接続や複数ロケーションを使用するレジリエンシーモデルが用意されています。

ただし、冗長構成を作っただけでは不十分です。

実際に障害を発生させ、切り替わることを試験する必要があります。

設計ポイント7：帯域と性能を見積もる

必要帯域は、「利用者数×平均通信量」だけでは判断できません。

次の通信を洗い出します。

通常の業務通信
バックアップ
ログ転送
OSアップデート
ウイルス対策ソフトの更新
ファイル転送
データベース同期
災害復旧時のデータ転送
監視通信
バッチ処理

転送時間の簡易計算

100GBのデータを100Mbpsの回線で転送する場合、理論上の最低時間は次のように考えます。

100GB × 8 = 800Gb

800Gb ÷ 100Mbps
= 8,000秒
= 約2.2時間

実際には、プロトコルのオーバーヘッド、暗号化処理、パケットロス、他の通信との競合があるため、さらに時間がかかります。

VPN装置の仕様を見るときも、インターフェース速度だけではなく、IPsec利用時の実効性能を確認します。

設計ポイント8：MTUとフラグメンテーション

VPNでは、元のIPパケットへIPsec用のヘッダーが追加されます。

そのため、元のパケットサイズが大きいと、フラグメンテーションやパケット破棄が発生する場合があります。

典型的な症状は次のとおりです。

pingは成功する
小さいWebページは開ける
大きなファイル転送だけ失敗する
特定のWebサイトやAPIがタイムアウトする
TCP接続は確立するがデータが流れない

確認項目は次のとおりです。

WANインターフェースのMTU
VPNトンネルのMTU
TCP MSS調整
Path MTU Discovery
ICMP Fragmentation Neededの許可
トンネル方式によるオーバーヘッド

「VPNは接続済み」と表示されていても、すべてのサイズのパケットが正常に流れるとは限りません。

構築までの基本手順

オンプレミスとクラウドを接続するときは、次の順序で進めます。

手順1：通信要件を整理する

最初に、誰がどこへ通信するのかを整理します。

送信元：
宛先：
プロトコル：
ポート：
通信量：
通信時間帯：
停止可能時間：
暗号化要件：

手順2：IPアドレスを確認する

オンプレミス、クラウド、他拠点、他VPC・VNetとの重複を確認します。

手順3：接続方式を選定する

可用性、帯域、導入時期、コストをもとにVPNか専用線を選びます。

手順4：クラウド側ネットワークを作成する

VPCまたはVNet、サブネット、ルートテーブル、VPNゲートウェイなどを作成します。

手順5：オンプレミス側装置を設定する

IKE、IPsec、対向IPアドレス、暗号化方式、事前共有鍵、BGPなどを設定します。

手順6：ルーティングを設定する

オンプレミスからクラウド、クラウドからオンプレミスの両方向に経路を設定します。

手順7：セキュリティ設定を行う

ファイアウォール、Security Group、NSG、ACL、OSファイアウォールを設定します。

手順8：DNSを設定する

条件付きフォワーダーやResolver Endpointを設定します。

手順9：疎通試験を行う

IP疎通、ポート疎通、名前解決、アプリケーション通信を順番に確認します。

手順10：障害試験を行う

主回線停止、VPNトンネル停止、ルーター停止などを実施し、切り替え時間と通信影響を確認します。

試験項目の例

疎通試験では、pingだけで完了させないことが重要です。

試験	確認内容
トンネル確認	IKE・IPsecセッションが確立している
BGP確認	BGPピアがEstablishedになっている
経路確認	対向ネットワークの経路を学習している
ICMP試験	許可した宛先へpingできる
TCP試験	必要なアプリケーションポートへ接続できる
DNS試験	双方向にプライベート名を解決できる
大容量転送	想定した帯域と転送時間を満たす
冗長化試験	主回線停止時に予備回線へ切り替わる
復旧試験	主回線復旧後に想定経路へ戻る
ログ確認	障害と切り替えを監視で検知できる

よくある失敗

失敗1：IPアドレスが重複していた

クラウド環境を先に作成し、後からオンプレミスと接続しようとしたところ、同じアドレス帯を使用していたケースです。

クラウド環境を作成する前に、全社のIPアドレス管理表を確認します。

失敗2：クラウド側の戻り経路がなかった

オンプレミスからクラウドへパケットは届いているものの、クラウド側ルートテーブルにオンプレミス宛ての経路がなく、応答が返りません。

パケットキャプチャーやフローログを使い、どこまで通信が届いているか確認します。

失敗3：VPNは正常だがSecurity Groupで拒否されていた

VPNトンネルがUPであることと、アプリケーション通信が許可されていることは別です。

VPN、経路、ファイアウォール、OS、アプリケーションを階層ごとに確認します。

失敗4：専用線を1本だけ導入した

高品質な回線でも、装置故障、工事断、接続拠点障害は発生します。

停止影響が大きい場合は、異なる経路の回線やVPNバックアップを設計します。

失敗5：DNSを設計していなかった

IPアドレス指定では通信できても、FQDNを使用するアプリケーションが動作しません。

特にPrivate Endpoint、データベース、認証基盤では、DNSを接続設計の一部として扱う必要があります。

失敗6：切り替え試験を実施していなかった

主回線と予備回線を用意していても、BGP属性やスタティックルートの優先度が原因で、自動切り替えされないことがあります。

本番開始前に、実際に主回線を停止する試験を行います。

通信できないときの切り分け手順

障害調査は、下位レイヤーから順番に行います。

1．物理・回線

インターフェースはUPか
ISPや専用線に障害はないか
オンプレミス装置のCPU・メモリは正常か

2．VPN・BGP

IKEセッションは確立しているか
IPsec SAは作成されているか
暗号化・復号化カウンターは増えているか
BGPピアはEstablishedか
BGPで必要な経路を受信しているか

代表的な確認コマンドの考え方は次のとおりです。

show crypto ikev2 sa
show crypto ipsec sa
show bgp summary
show route

実際のコマンドは装置やOSによって異なります。

3．経路

オンプレミス側にクラウド宛て経路があるか
クラウド側にオンプレミス宛て経路があるか
より具体的な別経路が存在しないか
デフォルトルートへ送られていないか
戻り経路は同じ接続を通るか

4．セキュリティ

オンプレミスFWで許可されているか
クラウドFWで許可されているか
Security Group／NSGで許可されているか
ACLで拒否されていないか
OSファイアウォールで許可されているか

5．DNS

IPアドレスを直接指定すると通信できるか
正しいIPアドレスが返っているか
条件付きフォワーダーは正しいか
DNSサーバーまでの経路はあるか

6．アプリケーション

サービスは起動しているか
正しいIPアドレスで待ち受けているか
正しいポートで待ち受けているか
アプリケーションログにエラーはないか

顧客へ説明するときの伝え方

技術に詳しくない顧客へは、サービス名から説明しないことが重要です。

悪い説明例は次のとおりです。

BGPを有効化したIPsecトンネルをVGWに接続し、VPCのルートテーブルへ伝播させます。

これでは、何のための構成なのか伝わりません。

次の順番で説明します。

目的
通常時の通信
障害時の動作
制約
費用と運用

説明例

社内からクラウド上の業務システムへ安全に接続するため、オンプレミスとクラウドの間に暗号化された通信経路を作ります。
通常時は専用線を使用し、専用線に障害が発生した場合はインターネットVPNへ自動的に切り替えます。
これにより、回線障害時も業務を継続しやすくなります。
一方で、予備回線への切り替え中は一時的に通信が切断される可能性があるため、事前に切り替え試験を実施します。

経営層への説明例

回線を二重化する目的は、通信速度を上げることではなく、1つの障害で業務システム全体が停止するリスクを下げることです。

技術を、コストや業務継続性、リスクへ翻訳して説明することが、設計・提案エンジニアに求められます。

英語ドキュメントで覚えておきたい表現

英語	意味
hybrid connectivity	ハイブリッド接続
on-premises network	オンプレミスネットワーク
site-to-site VPN	拠点間VPN
dedicated connection	専用接続
private connectivity	プライベート接続
customer gateway	顧客側ゲートウェイ
route propagation	経路伝播
advertised routes	広報経路
learned routes	学習した経路
redundant tunnels	冗長トンネル
failover	障害時の切り替え
asymmetric routing	非対称ルーティング
conditional forwarding	条件付きフォワーディング
inbound endpoint	受信用エンドポイント
outbound endpoint	送信用エンドポイント
overlapping IP ranges	重複したIPアドレス範囲

障害調査で使える検索キーワード

site-to-site VPN tunnel is up but no traffic
BGP session established but routes not learned
hybrid network asymmetric routing
on-premises cannot resolve private DNS
IPsec VPN MTU fragmentation
dedicated connection VPN failover

英語で検索できるようになると、クラウド事業者の公式ドキュメントや海外ベンダーのナレッジへ直接たどり着きやすくなります。

基本設計書に記載する項目

ハイブリッド接続の基本設計書には、少なくとも次の項目を記載します。

接続概要

接続元拠点：
接続先クラウド：
利用サービス：
主回線：
予備回線：
暗号化方式：
動的経路制御：

IPアドレス

オンプレミスネットワーク：
クラウドネットワーク：
VPNトンネル内アドレス：
BGPピアアドレス：
管理用アドレス：

ルーティング

オンプレミスから広報する経路：
クラウドから広報する経路：
主回線の優先制御：
予備回線の優先制御：
デフォルトルートの扱い：
経路集約：

可用性

ルーター冗長化：
ISP冗長化：
VPNトンネル数：
専用線の接続拠点：
クラウド側ゲートウェイ構成：
想定切り替え時間：

監視

回線状態：
VPNトンネル状態：
BGP状態：
遅延：
パケットロス：
帯域使用率：
経路変更：
DNS応答：

試験

正常系疎通試験：
名前解決試験：
性能試験：
主回線停止試験：
オンプレ装置停止試験：
復旧試験：
監視通知試験：

まとめ

オンプレミスとクラウドを接続する方法は、大きくインターネットVPNと専用線系接続に分けられます。

小規模な環境や検証ではVPNから始めやすく、基幹システムや大容量通信では専用線が候補になります。停止影響が大きい場合は、専用線とVPNを組み合わせたバックアップ構成も検討します。

ただし、安定したハイブリッドネットワークを作るために重要なのは、回線の種類だけではありません。

IPアドレスは重複していないか
往路と復路の経路は正しいか
BGPで意図した経路を選べるか
DNSを双方向に解決できるか
ファイアウォールは必要な通信だけを許可しているか
装置、回線、ISPに単一障害点が残っていないか
障害時に本当に予備回線へ切り替わるか
トンネル、経路、帯域を監視できるか

これらを整理し、「なぜこの構成にするのか」「障害時にどう動くのか」を説明できれば、単なる設定作業ではなく、設計・提案を担えるネットワークエンジニアへ近づけます。

次に学ぶ記事：

VPN障害を切り分け、顧客と海外ベンダーに報告するまで

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

Yuki