G-gen の本間です。Google Cloud のネットワーク機能である ハイブリッドサブネット について解説します。ハイブリッドサブネット機能を使うと、オンプレミスネットワークと VPC ネットワーク間で、同じ IP アドレス範囲を共有できます。 概要 ハイブリッドサブネットとは 料金 仕様 ルーティング ルートのアドバタイズ プロキシ ARP の使用 ハイブリッドサブネットを使用した VM 移行 制約事項と注意点 概要 IP アドレスの管理 使用できない環境・サービス オンプレミスネットワーク ルーティング 使用できない通信 概要 ハイブリッドサブネットとは ハイブリッドサブネット とは、Google Cloud の Virtual Private Cloud ネットワーク（以下、VPC ネットワーク）とオンプレミスネットワーク間で、同じ IP アドレス範囲を共有できる機能です。 通常、VPC ネットワークとオンプレミスネットワークを Cloud VPN（IPsec-VPN）や Cloud Interconnect（専用線）で接続する場合、IP アドレス範囲を重複させることはできません。しかし、ハイブリッドサブネットを使用することで、両環境にまたがる単一の論理的なサブネットを構成できます。 この機能は主に、オンプレミスのサーバーを Google Cloud へ移行する際、IP アドレスを変更せずに段階的に移行する目的で使用されます。 一般的に、クラウドへサーバーを移行する際には、サーバーの IP アドレスの変更を視野に入れるケースがあります。この場合、DNS レコードの更新、ファイアウォールルールの修正、依存するアプリケーションの設定変更なども付随して必要となります。 しかし、ハイブリッドサブネットを使用することで、オンプレミス環境と Google Cloud 環境を接続した状態でも同じ IP アドレス範囲をもつサブネットを Google Cloud に用意できるため、IP アドレスの変更が不要です。周辺システムの設定変更を最小限に抑え、Google Cloud 移行時のダウンタイムやリスクを低減できます。 参考 : About migrating to Google Cloud with Hybrid Subnets 料金 ハイブリッドサブネット機能自体の使用には、追加料金は発生しません。 VPC ネットワークのリソースや、送受信されるトラフィックに対する標準的な Google Cloud の料金のみが適用されます。 参考 : Virtual Private Cloud の料金 仕様 ルーティング ハイブリッドサブネットが有効になっているサブネットでは、パケットの転送動作が通常のサブネットとは異なります。 通常のサブネットでは、パケットの宛先がローカルまたはピアリングのサブネットルートと一致する場合、そのリソースへパケットを転送します。また、パケットの宛先が、実行中の Compute Engine VM（以下、VM）や内部転送ルールに関連付けられていなければ、パケットは破棄されます。一方、ハイブリッドサブネットでは以下のように処理されます。 パケットの宛先が一致する場合 パケットの宛先が、サブネット内で実行中の VM のネットワークインターフェースや内部転送ルールと一致する場合、通常のサブネット同様にそのリソースへパケットを配信します。 パケットの宛先が一致しない場合 パケットの宛先が、サブネット内の実行中の VM のネットワークインターフェースや内部転送ルールに一致しない場合でも、パケットは破棄されません。代わりに、ローカルまたはピアリングの静的ルート・動的ルートのネクストホップにパケットが転送されます。この動作により、クラウド上に存在しない宛先へのトラフィックを、オンプレミスネットワークへ正しく転送するための経路が確保されます。 参考 : About migrating to Google Cloud with Hybrid Subnets - Routing in the VPC network ルートのアドバタイズ Google Cloud へ移行されたサーバーへトラフィックを正しく引き込むため、Cloud Router からオンプレミスのルーターに対し、移行された個別の IP アドレスの /32 ルートをアドバタイズする必要があります。このルートは、Cloud Router にカスタムルートとして手動で設定する必要があります。 Border Gateway Protocol（以下、BGP）の最長一致の原則（Longest Prefix Match）により、オンプレミス側のより広い範囲のルート（ /24 など）よりも、Google Cloud 側からアドバタイズされた /32 ルートが優先されます。これにより、通信が正しく Google Cloud 上のサーバーに到達します。 プロキシ ARP の使用 サーバーが Google Cloud に移行された後も、オンプレミス側の他のクライアントは、対象サーバーが同じサブネット内にいると認識して ARP リクエストを送信します。このとき、オンプレミス側のルーターがプロキシ ARP で代理応答し、トラフィックを Cloud Router 経由で Google Cloud へ転送します。 このように、ハイブリッドサブネットを使用するには、オンプレミス側のネットワーク機器（ルーターなど）でプロキシ ARP を有効にする必要があります。 ハイブリッドサブネットを使用した VM 移行 ハイブリッドサブネットを使用して、オンプレミスから Google Cloud へサーバーの移行を行う際の、手順の概要は以下のとおりです。 オンプレミスのルーターが BGP をサポートし、プロキシ ARP を有効にできることを確認する Google Cloud 側で、オンプレミスと同じ IP アドレス範囲を持つ VPC サブネットを作成し、ハイブリッドサブネットルーティングを有効にする Cloud VPN や Cloud Interconnect を構成し、Cloud Router でオンプレミス環境との BGP セッションを確立する Migrate to Virtual Machines などの移行ツールを使用して、サーバーを Google Cloud に移行する 移行したサーバーの IP アドレス（ /32 ）を Cloud Router のカスタムアドバタイズルートに追加する VM の動作確認・試験を行う すべての移行が完了したら、ハイブリッドサブネットルーティングを無効にし、通常の VPC ルーティングに戻す ハイブリッドサブネット機能の有効化自体は簡単で、手順2のサブネット作成時に合わせて設定できます。またサブネットの新規作成時だけでなく、既存のサブネットに対しても、ハイブリッドサブネットを有効化できます。詳細な手順は以下のドキュメントを参照してください。 参考 : Prepare for Hybrid Subnets connectivity 参考 : Migrate workloads to Google Cloud with Hybrid Subnets 参考 : Disable hybrid subnet routing 制約事項と注意点 概要 当記事では、ハイブリッドサブネットの主要な制限を記載します。制限の詳細と、最新情報は公式ドキュメントを参照してください。 参考 : About migrating to Google Cloud with Hybrid Subnets - Limitations IP アドレスの管理 ハイブリッドサブネットには、IP アドレスの重複を自動的に防ぐ仕組みがありません。 そのため、オンプレミス環境と Google Cloud 環境で同じ IP アドレスが同時に使用されないよう、管理者が手動で厳密に IP アドレスを管理する必要があります。具体的には、Google Cloud 側への移行が完了したオンプレミスサーバーは速やかに停止するといった考慮が求められます。 使用できない環境・サービス ハイブリッドサブネットは、Google Cloud VMware Engine をサポートしていません。よってサーバーの移行先が Google Cloud VMware Engine の場合は、前述の移行手順を用いることはできません。 また Microsoft Azure や Amazon Web Services（AWS）とのプライベート接続で、ハイブリッドサブネットを用いることはできません。 オンプレミスネットワーク ハイブリッドサブネットで接続するオンプレミス側の対向機器となるルーターでは、プロキシ ARP の有効化と /32 ルートのアドバタイズの許容が求められます。 事前に使用する機器の仕様や設定を確認してください。 ルーティング ネットワークタグによる静的ルーティングの使用不可 Google Cloud の VPC ネットワークでは本来、Compute Engine VM のネットワークタグ機能を用いて静的ルートを設定可能です。しかし、ハイブリッドサブネットを使用している場合、ネットワークタグを使った静的ルーティングは使用できません。ハイブリッドサブネットでネットワークタグによる静的ルーティングを行っている場合、トラフィックが急増した際にパケットロスを引き起こす原因となります。 リージョンまたぎの通信は不可 ハイブリッドサブネット内のルーティングで宛先に通信を送る際、経路のネクストホップは、サブネットと同じリージョン内に存在する必要があります。異なるリージョンをネクストホップに指定した場合、パケットが破棄され、通信ができません。本来、Google Cloud の VPC ネットワークでは、本来であれば「東京リージョンのサブネットから、大阪リージョンの VPN ゲートウェイへ経路を向ける」といったルーティングも可能です。しかし、ハイブリッドサブネットでは仕様上、そのような設定はできないため注意してください。 使用できない通信 ハイブリッドサブネット環境では、IPv6 トラフィック、ブロードキャストトラフィック、マルチキャストトラフィックはサポートされていません。 また、Network Connectivity Center、ハイブリッド接続 NEG、ハイブリッド NAT とハイブリッドサブネットを併用することはできません。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。

こんにちは。 ソフトクリエイトでMicrosoft 365の導入・移行を担当している 「たかはし」 です。 案件で直面した課題対応で得た知識を主として共有していければと考えております。 今回はExchange Onlineへの移行に際して、SPFレコード登録の課題解決のために調査した内容を紹介させていただきます。   SPFレコードは、運用を続けるほど長くなる傾向があります。各種SaaS、拠点回線のグローバルIP、業務システムや複合機の送信元を足していくと、気づいたときには1行が数百文字になってくる可能性があります。 そうなると、DNSサービスの仕様によっては登録できないことや、登録ができたとしてもSPFレコードが正常に動作しない場合があるため、SPFレコードの制限と登録方法についてまとめました。

こんにちは。クロスインダストリー第1本部クラウドコンサルティング2課の清水です。 以前、「共通(アウトバウンド)VPCにDNS Firewallルールグループを1つだけ関連付ければ、配下の個別VPCすべての名前解決を一括でフィルタできるのでは」という設計を実機で検証しました(詳しくはこちらの記事で解説しています)。この「転送ルール方式」は、個別VPCから共通VPCへ、特定ドメイン宛のDNSクエリだけをResolverの転送ルールで送り込む仕組みです。ところが検証の結果、DNS Firewallは「関連付けたVPC自身が送出するDNSクエリ」しか評価せず、転送ルールで共通VPC側に送り込んだクエ…