ハイブリッドクラウド移行とは？接続方式・ネットワーク設計・アプリ配置判断まで解説

オンプレミスのサーバーを残したまま、一部のシステムをAWSやAzureへ移す。この「ハイブリッドクラウド移行」では、全面移行とは異なり、オンプレミスとクラウドを1つのネットワークとして設計し直す作業が発生します。本記事では、Site-to-Site VPNと専用線の帯域比較、CIDR重複を避けるアドレス設計、DNSの名前解決、どのアプリケーションをクラウド側へ出すかの判断基準までを、実装者の視点で解説します。接続方式の選定に迷っている方、段階移行の設計を任された方に向けた内容です。

まとめ：ハイブリッドクラウド移行で先に固める設計判断

設計判断の結論を先に示します。接続方式を分けるのは「帯域」と「開通までの期間」の2点です。検証段階や常時トラフィックが数百Mbpsに収まる間はSite-to-Site VPNで足り、本番のデータ転送が常時1Gbpsを超える見込みなら専用線（AWS Direct Connect、Azure ExpressRoute）を最初から申し込みます。専用線は開通まで数週間から数か月かかるため、後から切り替える前提でもVPN構築と並行して手配を始めるのが現実的です。

ネットワーク設計では、移行に着手する前にオンプレミスとクラウドのCIDR重複を解消し、DNSの名前解決を双方向に通しておきます。この2つを後回しにした移行は、ほぼ確実に手戻りが発生します。アプリケーション配置は「データがある側に処理を置く」が原則です。そしてハイブリッド構成は多くの場合、全面移行までの通過点として設計します。恒久的にハイブリッドを維持する判断は、規制要件やハードウェア制約など、オンプレミスに残す明確な理由があるときに限るべきです。

ハイブリッドクラウド移行の全体像とオンプレミス併用の構成パターン

ハイブリッドクラウド移行とは、オンプレミス環境を維持しながらパブリッククラウドを併用する構成へ段階的に移すことを指します。まず構成の型を押さえると、設計の論点が明確になります。

段階移行の入り口となるハイブリッド構成と全面クラウド移行との違い

全面移行が「ある時点で切り替える」のに対し、ハイブリッド構成は移行期間中もオンプレミスとクラウドの両方で本番システムが動きます。このため、両環境をまたぐ閉域接続・アドレス設計・名前解決という3つの設計項目が追加で発生します。ここが全面移行との決定的な違いです。

移行計画全体の立て方や費用の考え方は、発注者視点でまとめたクラウド移行の進め方（計画から移行方式・切り替えまでの手順）で解説しています。本記事はその中の「ハイブリッド構成を取る場合の技術設計」を深掘りする位置付けです。移行対象の棚卸しや優先順位付けが済んでいない段階なら、先に全体手順を確認してください。

オンプレミスに残す領域とクラウドへ出す領域の代表的な分割パターン

実務でよく見る分割は次の形です。順序は採用頻度の高い順に並べています。

• Webフロント・検証環境をクラウドへ出し、基幹DBと連携サーバーをオンプレミスに残す
• バックアップ・DR（災害対策）環境だけをクラウド側に持つ
• 新規開発はすべてクラウドで行い、既存システムは塩漬けのままオンプレミスで維持する

1つ目のパターンは負荷変動をクラウドの拡張性で吸収でき、効果が見えやすい反面、フロントとDBの間に往復遅延が入るため、後述するアプリ配置の判断が問われます。なお、オンプレミス側を仮想化基盤ごと自社専有のクラウドとして再構築する選択肢もあり、その構築方式はプライベートクラウドの構築方式と選定基準で扱っています。

オンプレミスとクラウドをつなぐ接続方式の比較とVPN・専用線の選定基準

ハイブリッド構成の品質は、接続回線でほぼ決まります。選択肢はインターネットVPNと専用線の2系統です。

Site-to-Site VPNの帯域上限と短期構築に向く場面

Site-to-Site VPNは、既存のインターネット回線上にIPsecトンネルを張る方式で、ルーター設定だけで数日以内に開通できます。AWSの公式ドキュメント（2026年7月時点）では、標準VPNトンネル1本あたりの帯域は最大1.25Gbps、パケット処理は最大14万PPSとされています。MTUも1446バイトに制限されるため、ジャンボフレーム前提の通信は通りません。

この上限を超えたい場合、Transit Gateway側でECMP（等コストマルチパス）を有効にし、複数トンネルを束ねて帯域を伸ばす構成が取れます。ただしECMPは動的ルーティング（BGP）の構成が前提で、静的ルートでは使えません。検証段階、または本番でも転送量が限定的なバックアップ用途なら、VPNで十分に実用になります。

専用線接続の帯域と冗長構成（Direct Connect・ExpressRoute）

専用線系のサービスは、通信事業者の閉域網や構内配線を経由してクラウドへ直結する方式です。公式ドキュメント（2026年7月時点）の記載では、AWS Direct Connectの専用接続は1・10・100・400Gbpsのポートを選択でき、パートナー経由のホスト接続なら50Mbpsからの小容量でも契約できます。Azure ExpressRouteは50Mbpsから10Gbpsの帯域を選択でき、大容量が必要ならExpressRoute Directで10・100・400Gbpsの直結ポートを確保できます。

冗長設計の考え方はサービスごとに異なります。ExpressRouteは1回線の契約で2台のMicrosoftエッジルーターへの2接続が標準で組み込まれます。Direct Connectは1接続では冗長になりません。回線障害に耐えるには、別ロケーションでの2本目か、VPNをバックアップ経路として併設する構成が要ります。専用線はどちらも物理工事や事業者手配を伴うため、申し込みから開通まで数週間から数か月を見込み、移行スケジュールの最初期に手配を始めてください。

IPアドレス・DNS・経路制御で押さえるネットワーク設計の要点

接続方式が決まったら、その上を流れる通信の設計に移ります。ここで手を抜くと移行後に直せない構造問題が残ります。

CIDR重複の回避とオンプレミスと重ならないアドレス設計の手順

オンプレミスとクラウドのアドレス帯が重複すると、経路制御が成立せず、NATで無理やり通す複雑な構成に追い込まれます。VPC・仮想ネットワークを作る前に、次の順で確定させます。

1. オンプレミス側で使用中のアドレス帯を棚卸しする（申請台帳ではなく実際のルーティングテーブルで確認）
2. RFC 1918のプライベート空間（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）から、未使用の連続ブロックをクラウド用に予約する
3. 将来のリージョン追加・環境追加を見込み、予約ブロックを環境単位に分割して割り当てる

サブネットの切り方と表記の読み方はCIDR表記の読み方とサブネット設計で基礎から解説しています。どうしても既存アドレスを変えられないシステムを移す場合は、VXLANなどのオーバーレイネットワークでL2を延伸して重複を吸収する手もありますが、障害切り分けが難しくなるため恒久構成には推奨しません。

オンプレミスとクラウドをまたぐDNS名前解決とフォワーダー設計

両環境のサーバーが互いを名前で引けない状態では、アプリケーションの段階移行は進みません。AWSならRoute 53 Resolverのインバウンド／アウトバウンドエンドポイントを設け、社内DNSには「クラウド側ゾーンへの条件付きフォワーダー」を、クラウド側には「社内ドメインをオンプレミスDNSへ転送するルール」を設定します。Azureでも同等の機能をDNS Private Resolverが担います。

設計時の落とし穴は、移行済みサーバーのレコード更新漏れです。移行のたびに旧IPを指すレコードが残ると、接続先が旧環境に戻る「サイレント切り戻し」が起きます。移行手順書にDNS更新と旧レコードのTTL短縮を組み込み、切り替え当日の作業ではなく事前作業として扱ってください。

アプリケーション配置の判断基準と7Rによる移行方式の使い分け

回線とネットワークが整ったら、どのシステムをどの順でクラウドへ出すかを決めます。感覚ではなく基準で決めるのがこの工程の要点です。

クラウド側へ出すワークロードの判断基準（レイテンシーとデータ配置）

判断の軸は2つです。第一に「データがある側に処理を置く」こと。オンプレミスのDBを参照するアプリをクラウドへ出すと、DBへの問い合わせのたびに専用線を往復し、ミリ秒単位の遅延が積み上がります。画面1回の表示で数十回クエリを発行する業務システムでは、この積み上げが体感速度を大きく落とします。アプリとDBはセットで移すか、セットで残すのが原則です。

第二に「変動と定常の切り分け」です。負荷が読めない新規サービスや月末だけ跳ねるバッチはクラウドの従量課金が向き、24時間フル稼働で負荷が一定のシステムはオンプレミス継続かリザーブド契約が向きます。この2軸で全システムを4象限に置くと、移行順序はほぼ機械的に決まります。

リホストからリファクタまで7つの移行方式（7R）と適用の順序付け

AWSが提唱する7R（リタイア・リテイン・リホスト・リロケート・リパーチェス・リプラットフォーム・リファクタ）は、ハイブリッド段階移行でも整理の枠組みとして機能します。実務では次の順で検討すると無駄がありません。

• 先にリタイア（廃止）とリテイン（残置）を確定し、移行対象の母数を減らす
• 残った対象はリホスト（そのまま移設）を第一候補にして早期に件数を稼ぐ
• DBなど運用負荷の重いものだけリプラットフォーム（マネージドサービスへ載せ替え）を選ぶ
• リファクタ（作り直し）は移行プロジェクトから切り離し、別予算の開発案件として扱う

移行と作り直しを同時にやると、障害時に「移行が原因か改修が原因か」を切り分けられなくなります。リファクタを移行スコープに含めない判断が、ハイブリッド移行を計画どおり進める分かれ目です。移行方式の選定から切り替え・並行稼働の確認までを外部に任せたい場合は、当社のシステムマイグレーション・リプレイスで現行システムの調査から移行後の安定稼働確認までを請け負っています。

ハイブリッド構成を採用すべきでない場面と接続設計の失敗パターン

ハイブリッドは万能ではありません。採用しない判断も含めて設計です。この章では条件を挙げて言い切ります。

ハイブリッドが過剰になる条件と全面クラウド移行を選ぶ判断基準

サーバー台数が20台未満で、ハードウェア依存（専用ボード・ライセンスのMACアドレス縛り等）も規制要件もないなら、ハイブリッド期間を長く取るべきではありません。専用線の月額費用と二重運用の人件費が、段階移行で減らせるリスクに見合わないためです。この規模なら一括のリホスト移行で数か月以内に完了させ、ハイブリッド状態は切り替え期間の数週間に限定します。

逆に恒久ハイブリッドを選ぶ理由になるのは、データの国内設置義務や監督官庁のガイドラインでクラウド不可の領域がある場合、工場設備のように現地処理が必須の場合、そして償却前のハードウェア資産が大量に残っている場合です。「なんとなく不安だからオンプレも残す」は理由になりません。残す対象には必ず残す根拠を文書化してください。残す領域が大きく専有基盤の再整備まで視野に入る場合は、プライベートクラウド移行で方式選定と手順を整理しています。

接続回線を単一障害点にする失敗と運用開始前に確認する冗長化の下限

最も多い失敗は、専用線1本またはVPN1本に全通信を依存させる構成です。ハイブリッド構成では回線断＝両環境をまたぐ全システムの停止を意味し、影響範囲は単一データセンター障害より広くなり得ます。本番運用に入る前の冗長化の下限は「経路の異なる2系統」です。専用線＋VPNバックアップの組み合わせなら、コストを抑えつつ経路多様性を確保できます。

もう1つの典型は、監視をオンプレミスとクラウドで別ツールのまま放置することです。障害時にどちら側の問題かを2つの画面で突き合わせる運用は、切り分けを遅らせます。回線・DNS・アプリの3層を1つの監視基盤に集約し、疎通監視は必ず「クラウド側からオンプレミスを見る」方向も含めて双方向で入れてください。

よくある質問

ハイブリッドクラウド移行の設計・運用で問い合わせの多い質問に答えます。

ハイブリッドクラウドとマルチクラウドの違いは何ですか？

ハイブリッドクラウドはオンプレミス（または自社専有環境）とパブリッククラウドの組み合わせを指し、マルチクラウドはAWSとAzureのように複数のパブリッククラウドを併用する形態を指します。設計上の違いは接続の向きです。ハイブリッドは自社拠点とクラウドの南北接続が主題になり、マルチクラウドはクラウド間の東西接続と運用ツールの共通化が主題になります。両方を同時に採る構成もありますが、接続コストと運用負荷は加算で増えます。

VPNと専用線はどちらから始めるべきですか？

検証と初期移行はVPNで開始し、専用線は必要が確定した時点で申し込む、が標準的な進め方です。ただし専用線は開通まで数週間から数か月かかるため、本番トラフィックが常時1Gbpsを超える見込みが最初からあるなら、VPN構築と同時に専用線を発注してください。VPNをそのまま専用線のバックアップ経路に転用できるので、先行投資が無駄になりません。

移行期間中のオンプレミスとクラウドのデータ同期はどうしますか？

データベースは「一方向レプリケーション＋切り替え時に向きを固定」が原則です。双方向同期は書き込み競合の解消が難しく、障害時の整合性確認に時間を取られます。AWSならDMS、AzureならDatabase Migration Serviceのような移行ツールで旧環境から新環境へ流し続け、切り替え当日に書き込み先を新環境へ一本化します。ファイルサーバーは差分転送ツールで夜間同期し、切り替え直前に最終差分だけを転送する方式が実績豊富です。

オンプレミスのIPアドレスをクラウドへそのまま持ち込めますか？

プライベートアドレスの持ち込みは原則として再設計を推奨します。同じアドレス帯を両環境で同時に使う期間が生じると経路制御が破綻するためです。どうしても変更できない場合はVXLAN等のオーバーレイでL2延伸する回避策がありますが、恒久構成には向きません。なおパブリックIPについては、AWS・AzureともBYOIP（自社保有アドレスの持ち込み）の仕組みが用意されており、外部公開系の移行では選択肢になります。

ハイブリッド構成の運用監視はどう統合すればよいですか？

監視サーバーをどちらか一方に置き、閉域接続経由で両環境を1つの基盤から見る構成にします。クラウド側の標準監視（CloudWatch、Azure Monitor）はクラウド内リソースに限定して使い、システム横断の死活監視・アラート集約はZabbixやDatadogのような横断ツールに寄せる分担が運用しやすい形です。回線そのものの監視（トンネル状態・BGPセッション・帯域使用率）を監視項目に含めることを忘れないでください。

関連記事

• クラウドとは？AWSとは何かを仕組み・料金・移行の判断まで事業者向けに解説：クラウドの基礎とAWSの全体像を移行判断の前提から整理しています
• オンプレミスとクラウドの違いとは？コスト・セキュリティ・拡張性で比較し選び方まで解説：どちらに何を置くかを決める前提となる両環境の比較です
• クラウドコンピューティングとは？仕組み・NISTの5つの特徴からサービス/実装モデルと採用判断まで解説：ハイブリッドクラウドを含む実装モデルの位置付けを体系的に解説しています