プライベート IP の使用方法の詳細

このページでは、Cloud SQL でプライベート IP を使用する方法について説明します。プライベート IP を使用して Cloud SQL インスタンスを構成する詳細な手順については、プライベート IP の構成をご覧ください。

Cloud SQL ネットワーキングのための Terraform ソリューションについては、Simplified Cloud Networking 構成ソリューションをご覧ください。

概要

プライベート IP を使用して Cloud SQL インスタンスを構成するには、プライベート サービス アクセスが必要です。プライベート サービス アクセスを使用すると、VPC ネットワークと基盤となる Google サービス プロデューサーの VPC ネットワークの間にプライベート接続を作成できます。Cloud SQL などのサービスを提供する Google エンティティは、サービス プロデューサーと呼ばれます。各 Google サービスは、リソースをプロビジョニングするためのサブネットを作成します。サブネットの IP アドレス範囲は通常、/24 CIDR ブロックです。これはサービスによって選択されるもので、割り振られた IP アドレス範囲から取得されます。

プライベート接続を使用すると、インターネットまたは外部 IP アドレスを使用せずにサービスに到達できます。このため、プライベート IP はパブリック IP よりもネットワーク レイテンシを低く抑えます。

プライベート サービス アクセスを使用して、次のように Cloud SQL インスタンスに接続します。

プライベート IP アドレスはリージョン間で接続できます。プロジェクト間で共有 VPC を使用して接続することもできます。

割り振り済みの IP アドレス範囲

プライベート IP を使用する VPC ネットワークで Cloud SQL インスタンスを使用するには、IP アドレス範囲を割り振って、この VPC のプライベート サービス アクセスを設定する必要があります。Cloud SQL インスタンスを整理するには、プライベート接続に複数の IP アドレス範囲を割り振る場合もあります。プライベート IP 用に Cloud SQL インスタンスを構成する場合、VPC ネットワークと割り振られた IP アドレス範囲の両方を選択できます。

割り振る範囲のサイズ

Cloud SQL と使用予定の他の Google マネージド サービスには十分なサイズの IP 範囲を割り振ってください。それぞれのサービスでは、割り振られた範囲内にある専用の IP ブロックが必要になります。最小サイズは単一の /24 ブロック（256 アドレス）ですが、推奨サイズは /16 ブロック（65,536 アドレス）です。

IP アドレス範囲を割り振る場合は、作成するインスタンスの数を考慮する必要があります。

サブネット マスク アドレス 使用可能な Cloud SQL インスタンス
/2425650
/23512100
/221024200
/212048400
/204096800

Cloud SQL は /24 CIDR 範囲を範囲単位として使用し、個々の単位は単一リージョン内の Cloud SQL インスタンスにのみ使用できます。たとえば、2 つの Cloud SQL インスタンスを 2 つの異なるリージョンに作成する場合は、/24 CIDR 範囲が少なくとも 2 つ必要です。

さらに、プロジェクトでの Cloud SQL の使用開始が 2021 年 4 月 1 日よりも前の場合は、Postgres インスタンスが同じ範囲単位を MySQL や SQL Server のインスタンスと共有することはできないため、各リージョン内に専用の範囲単位が必要になります。新しいプロジェクトは、この制限の対象にはなりません。

ネットワークのプライベート サービス アクセスを設定する

特定の VPC ネットワークで初めてプライベート IP 接続を構成する場合は、Cloud SQL のプライベート サービス アクセスを設定する 1 回限りの手順を行う必要があります。

プライベート サービス アクセスを確立したら、プライベート IP を使用するように構成された Cloud SQL インスタンスを作成できます。また、既存の Cloud SQL インスタンスにプライベート IP を構成することもできます。詳しい手順については、プライベート IP の構成をご覧ください。

確立済みの接続を変更するたびに、vpc-peerings の更新もする必要があります。

プライベート IP の要件

プライベート IP を使用するには、ネットワークとアプリケーション環境が以下の要件を満たしている必要があります。また、初めてプライベート IP を設定するには、追加の IAM 権限が必要です。

アプリケーション環境要件

  • GKE から接続する場合は、VPC ネイティブ クラスタ上で GKE 1.8 以降を実行している必要があります。

API と IAM の要件

  • プロジェクトで Service Networking API を有効にする必要があります。

    • 共有 VPC ネットワークを使用している場合は、ホスト プロジェクトで Service Networking API も有効にする必要があります。

  • プライベート サービス アクセス接続を管理するため、ユーザーには次の IAM 権限が必要です。ユーザーに必要な権限がない場合は、権限不足エラーが発生することがあります。
    • compute.networks.list
    • compute.addresses.create
    • compute.addresses.list
    • servicenetworking.services.addPeering

    共有 VPC ネットワークを使用している場合は、同じユーザーを追加して、ホスト プロジェクトにも同じ権限を割り当てる必要があります。

例

次の例では、お客様の VPC ネットワークが Google サービスの 10.240.0.0/16 アドレス範囲を割り振り、その範囲を使用するプライベート接続を確立しました。各 Google サービス（Cloud SQL など）は、Cloud SQL インスタンスなどの新しいリソースを所定のリージョンにプロビジョニングするために、割り振られたブロックからサブネットを作成します。

プライベート IP 構成の図の概要。

  • プライベート接続には 10.240.0.0/16 割り当て範囲が割り当てられます。Google サービスは、新しいリソースがプロビジョニングされるサブネットをこの割り当てから作成できます。
  • プライベート接続の Google サービス側では、Google がお客様のプロジェクトを作成します。このプロジェクトは分離されていて他のお客様と共有されることはなく、費用はお客様がプロビジョニングしたリソースに対してのみ発生します。
  • 各 Google サービスは、リソースをプロビジョニングするためのサブネットを作成します。サブネットの IP アドレス範囲は通常、/24 CIDR ブロックです。これはサービスによって選択されるもので、割り振られた IP アドレス範囲から取得されます。サービス プロデューサーのサブネットは変更できません。サービスは、そのサービスで以前に作成された既存のリージョン サブネットに新しいリソースをプロビジョニングします。サブネットがいっぱいの場合、サービスは同じリージョンに新しいサブネットを作成します。
  • お客様のネットワーク内の VM インスタンスは、サービスがサポートしていれば、あらゆるリージョンのサービス リソースにアクセスできます。サービスによっては、リージョン間通信をサポートしていないものもあります。詳細については、関連するサービスのドキュメントをご覧ください。
  • VM インスタンスが別のリージョンのリソースと通信する場合、リージョン間トラフィックのアウトバウンド データ転送の費用が引き続き適用されます。
  • Cloud SQL インスタンスには、IP アドレス 10.240.0.2 が割り当てられます。お客様の VPC ネットワークでは、宛先が 10.240.0.2 のリクエストは、プライベート接続を経由してサービス プロデューサーのネットワークへとルーティングされます。サービス ネットワークに到達すると、サービス ネットワークにはリクエストを正しいリソースに送るルートが含まれます。
  • VPC ネットワーク間のトラフィックは、公共のインターネットを経由せず、Google のネットワーク内を内部的に転送されます。

ネットワークに関する問題

Cloud SQL は、リージョンごとにプライベート サービス アクセス IP 範囲から /24 サブネットを割り振ります。たとえば、PostgreSQL インスタンスを 2 つのリージョンに配置するには、割り振られた IP アドレス範囲にサイズが /24 の利用可能なサブネットが少なくとも 2 つ含まれている必要があります。

プライベート IP アドレスを使用した Cloud SQL インスタンスへの接続については、RFC 1918 アドレス範囲が自動的に承認されます。これにより、すべてのプライベート クライアントは、Cloud SQL Auth Proxy を経由せずにデータベースにアクセスできます。

Cloud SQL は、デフォルトでは VPC から RFC 1918 以外のサブネット ルートを学習しません。RFC 1918 以外のルートをエクスポートするには、Cloud SQL へのネットワーク ピアリングを更新する必要があります。

セキュリティ

プライベート サービス アクセスを介したトラフィックでは、特定のレベルの暗号化が提供されています。詳細については、Google Cloud の仮想ネットワークの暗号化と認証をご覧ください。

Cloud SQL Auth Proxy は、プライベート IP を使用して接続するように構成できます。また、IAM 認証情報を使用して認証を行い、ローテーション SSL / TLS 証明書を使用してエンドツーエンドでの暗号化を実施します。

セキュリティ要件で、ユーザーが管理するセルフマネージド SSL / TLS 証明書が必要とされる場合は、SSL / TLS の構成方法をご覧ください。

プライベート IP アドレスを持つインスタンスごとに 1 つの VPC ネットワークを作成すると、すべてのインスタンスを「デフォルト」の VPC ネットワークに接続するよりも適切にネットワークが分離されます。

複数の VPC の接続

Cloud SQL では、プライベート サービス アクセスによりプライベート IP アドレスがサポートされます。Cloud SQL インスタンスを作成すると、Cloud SQL は Cloud SQL VPC という独自の Virtual Private Cloud（VPC）内にインスタンスを作成します。プライベート IP を有効にするには、Cloud SQL VPC と VPC ネットワークの間にピアリング接続を設定する必要があります。これにより、VPC ネットワーク内のリソースは、Cloud SQL VPC ネットワーク内の Cloud SQL リソースの内部 IP アドレスにアクセスできます。

Cloud SQL では、VPC ネットワーク ピアリングを使用してプライベート サービス アクセスを内部的に実装します。これにより、同じプロジェクトや組織に属しているかどうかにかかわらず、2 つの VPC ネットワーク間で内部 IP アドレスを接続できます。ただし、VPC ネットワーク ピアリングは推移的ではないため、直接ピアリングされている 2 つの VPC 間のルートのみをブロードキャストします。追加の VPC がある場合、元の VPC で設定された接続を使用して Cloud SQL リソースにアクセスすることはできません。

この制限を軽減し、プライベート IP アドレスを使用して Cloud SQL インスタンスを複数の VPC に接続するには、次の接続オプションを使用できます。

  • カスタム アドバタイズ ルートを使用して接続する
  • 中間プロキシ（SOCKS5）を使用して接続する
  • Cloud SQL Auth Proxy をサービスとして使用して接続する

複数の VPC を接続する方法については、インスタンスを複数の VPC に接続するをご覧ください。

プライベート IP に関するクイック リファレンス

プライベート IP を使用して Cloud SQL インスタンスを管理する場合、次のトピックが役立ちます。

トピック ディスカッション
共有 VPC ネットワーク 共有 VPC ネットワーク内にプライベート IP アドレスを持つ Cloud SQL インスタンスを作成できます。ただし、共有 VPC ネットワークのプライベート IP アドレスを既存の Cloud SQL インスタンスに割り当てることはできません。
リージョン プライベート IP はリージョン間で接続できます。
レガシー ネットワーク レガシー ネットワークから Cloud SQL インスタンスのプライベート IP に接続することはできません。レガシー ネットワークでは、VPC ネットワーク ピアリングやプライベート サービス アクセスがサポートされていません。
プライベート IP の削除 プライベート IP を使用するように Cloud SQL インスタンスを構成した後で、そのインスタンスからプライベート IP 機能を削除することはできません。
パブリック IP とプライベート IP パブリック IP とプライベート IP の両方を使用して同じ Cloud SQL インスタンスに接続できます。どちらの接続方法も他方に影響しません。
既存の Cloud SQL インスタンス インスタンス作成時にプライベート IP を使用するようにインスタンスを構成できます。プライベート IP を使用するように既存のインスタンスを構成することもできます。プライベート IP を使用するように既存のインスタンスを構成するか、接続先のネットワークを変更すると、インスタンスが再起動され、数分のダウンタイムが発生します。
静的 IP アドレス パブリックとプライベートの IP アドレスについては、Cloud SQL インスタンスの受信アドレスは静的であり、変更されることはありません。送信アドレスは常に静的であるとは限りませんが、外部サーバー レプリカの送信パブリック IP アドレスは例外で、常に静的です。
レプリカ レプリカは、プライマリ インスタンスからプライベート IP ステータスを継承します。レプリカにプライベート IP を直接構成することはできません。プライベート IP アドレスを使用してレプリカに接続している場合は、プライマリ インスタンスから継承されるため、レプリカに追加の VPC プライベート接続を作成する必要はありません。
Cloud SQL Auth Proxy プライベート IP を使用して Cloud SQL インスタンスに接続するには、Cloud SQL Auth Proxy が、そのインスタンスと同じ VPC ネットワークにアクセスできるリソース上に存在する必要があります。インスタンスで両方の IP タイプが有効になっている場合、Cloud SQL Auth Proxy は、デフォルトでパブリック IP を使用します。確実にプライベート IP を使用するようにするには、-ip_address_types=PRIVATE フラグを Cloud SQL Auth Proxy に渡す必要があります。詳細。
サーバーレス VPC アクセス App Engine スタンダード環境、Cloud Run、または Cloud Run 関数などのサーバーレス ソースから接続する場合は、アプリケーションまたは関数は、Cloud SQL Auth Proxy を使用せずにサーバーレス VPC アクセスを介してインスタンスに直接接続します。
VPC ネットワーク ピアリング プライベート サービス アクセスを使用する接続は、VPC ネットワーク ピアリングに依存します。ただし、このピアリングは Google Cloud の内部にあるため、VPC ネットワーク ピアリングを明示的に作成する必要はありません。プライベート サービス アクセス接続を作成した後、その基になる VPC ネットワーク ピアリングの情報は Google Cloud コンソールの VPC ネットワーク ピアリングのページで確認できますが、プライベート接続を削除する場合を除き、VPC ネットワーク ピアリングを削除しないでください。

VPC ネットワーク ピアリングの詳細を確認する。
VPC Service Controls VPC Service Controls を使用すると、データの引き出しのリスクを軽減できます。VPC Service Controls で Cloud SQL インスタンスの周囲に境界を作成します。VPC Service Controls により、境界内部のリソースへのアクセスが制限されます。境界内のクライアントとリソースだけが相互に通信可能です。詳細については、VPC Service Controls の概要をご覧ください。また、VPC Service Controls を使用する場合の Cloud SQL の制限事項も確認してください。Cloud SQL で VPC Service Controls を使用するには、VPC Service Controls の構成をご覧ください。
推移的ピアリング 通信できるのは、直接ピアリングしたネットワークだけです。推移的ピアリングはサポートされていません。たとえば、VPC ネットワーク N1 が N2 と N3 にピアリングされ、N2 と N3 が直接接続されていない場合、VPC ネットワーク N2 は VPC ネットワーク ピアリング経由で VPC ネットワーク N3 と通信できません。

1 つのプロジェクト内のクライアントは、共有 VPC ネットワークを使用して、複数のプロジェクトの Cloud SQL インスタンスに接続できます。
Cloud SQL インスタンスの移動 Cloud SQL インスタンスは、プロジェクトが所有するネットワーク間でのみ移動できます。また、Cloud SQL インスタンスはプロジェクト間で移動することも、異なるプロジェクトでホストされているネットワーク間で移動することもできません。

次のステップ