Networking methods for source database connectivity

To move data from your source database server into the destination Cloud SQL for PostgreSQL instance, Database Migration Service needs to connect to your source instance. That connection can be established over the public internet, or through a series of private connections in your project's Virtual Private Cloud (VPC).

This page provides an overview of each available source database connectivity method, as well as a recommendation section to help you choose the right solution for your migration:

  • Method comparison provides a comparison table for available source connectivity methods.

  • IP allowlist describes network connectivity to the public IP of your source database.

  • Forward-SSH tunnel provides an overview for dedicated Secure Shell (SSH) tunnels.

  • Private connectivity describes how you can establish a connection to the private IP of your source database.

After you familiarize yourself with different connectivity methods and their requirements, you can use the decision tree diagram to pick the right solution for your scenario.

Method comparison

Every connectivity method comes with different benefits and requirements. Use the following table to compare them at a glance, and then learn more details in the sections dedicated for each method.

Networking method Advantages Disadvantages
IP allowlist
  • The easiest connectivity method to set up.
  • Useful when your source database can't be reached through private networks in Google Cloud.
  • Requires that you expose an IPv4 address of your source database server to the public internet. This requires extra security measures. For example, we recommend that you use TLS certificates and firewall rules for securing the connection.
  • Configuring the firewall rules may require assistance from the IT department.
Forward SSH tunnel

  • More secure than connecting over public IP with an IP allowlist.

    The initial connection is established through Secure Shell (SSH) ports over the public internet. Once the connection is active, all traffic travels over a secure, private connection.

  • Useful when your source database can't be reached through private networks in Google Cloud, but you don't want to expose your source database server directly to the public internet.
  • Using an intermediate server (the forward-SSH tunnel machine) for connectivity might introduce additional latency.
  • You must set up and maintain the forward-ssh host server. The server must be online for the whole duration of your migration.
Private connectivity with Virtual Private Cloud peering
  • The connection is established to the private IP address of your source database.
  • This connectivity method is best suited for sources whose private IP address can be reached from your Google Cloud VPC network.

IP allowlist for source database connectivity

When you use the IP allowlist connectivity method, Database Migration Service attempts to establish a connection to a publicly available IP address of your source database server.

Requirements for IP allowlist connectivity

At a high level, to use this connectivity method you need to ensure the following:

  • You must expose your source's IP address to the public internet (either directly, or with a publicly recognized hostname through a Domain Name Server (DNS)).

  • You need to allow incoming connections from Database Migration Service public IP addresses.

  • Optional: IP allowlist connectivity uses unencrypted connections by default. We recommend that you use TLS certificates to secure your connection. Database Migration Service offers support for different TLS types so that you can pick the best solution depending on what your source database can support. For more information, see Use SSL/TLS certificates to encrypt network connections.

Configure IP allowlist connectivity

Configuring public IP connectivity requires different steps depending on you source database type. For more information, see:

Forward-SSH tunnel for source database connectivity

This connectivity method is a mixture of public and private network connectivity. The connection itself is established through Secure Shell (SSH) ports to the public IP address of the tunnel host server. Once the connection is active, all traffic travels over a secure tunnel to the private IP address of your source database.

A networking diagram that shows a high-level connectivity setup over a dedicated SSH tunnel server.
Figure 2. Migration networking example: source connectivity over an SSH tunnel. (click to enlarge)
A networking diagram that shows a high-level connectivity setup over a dedicated SSH tunnel server.

Requirements for forward-SSH tunnels

To create the connection, you need to expose SSH ports to the public internet on your tunnel server. When connectivity is established, all traffic is routed through the private tunnel connection.

It's possible to terminate the tunnel on the same server where you host your source database, but we recommend that you use a dedicated tunnel server. This way you aren't exposing your source database directly to the public internet. The tunnel server can be any Unix/Linux host that can be reached from the internet via SSH, and can access your source database.

For certain connectivity scenarios, we recommend that you use the private connectivity with Virtual Private Cloud peering networking method instead of a forward-SSH tunnel:

  • For self-hosted sources that reside inside inside Google Cloud, Database Migration Service can access the private IP of your source database with the private connectivity configuration. You don't need to set up a separate SSH server to establish the connection.

  • For Cloud SQL sources, you also don't need to use an SSH tunnel to establish a connection to the private IP of your database. But you need a reverse proxy VM because of the transitive peering limitation.

Configure forward-SSH tunnel connectivity

Configuring connectivity through a forward-SSH tunnel requires different steps depending on you source database type. For more information, see:

Private connectivity with VPC peering

This method lets you connect to your source through the private IP addresses in your Virtual Private Cloud (VPC). You don't need to expose any interfaces to the public internet to use this method, but it requires that your source database IP address or hostname can be reached from your Google Cloud VPC.

Depending on what source database you have, this connectivity method might require you to set up additional network components (such as Cloud VPN or a reverse proxy VM):

A networking diagram that shows a high-level connectivity setup with a VPC peering and a Cloud SQL source database.
Figure 3. Migration networking example: private IP source connectivity with Virtual Private Cloud peering for a Cloud SQL source. (click to enlarge)
A networking diagram that shows a high-level connectivity setup with a VPC peering and a Cloud SQL source database.

A networking diagram that shows a high-level connectivity setup over a dedicated SSH tunnel server.
Figure 4. Migration networking example: private IP source connectivity with Virtual Private Cloud peering and Cloud VPN for sources that reside in other cloud offerings. (click to enlarge)
A networking diagram that shows a high-level connectivity setup over a dedicated SSH tunnel server.

Requirements for private IP connectivity

This connectivity method is best suited for sources whose private IP address can be reached from your Google Cloud VPC network. For self-hosted sources that reside in Google Cloud, you can establish direct peering connections with a private connectivity configuration in Database Migration Service. For other types of sources you might need additional network components such as such as Cloud VPN or a reverse proxy VM (or both).

Private IP connectivity requires the following:

  • You need to have a Virtual Private Cloud network with private services access enabled.

    This is the network that you peer with Database Migration Service and your source database server. You need to have enough space to allocate IP ranges for both components.

  • For Cloud SQL for SQL Server sources: Your source Cloud SQL must have private IP enabled. It needs to be peered to the same VPC network where you intend to create the private connectivity configuration for Database Migration Service. You also need to set up a reverse proxy Virtual Machine (VM) on Compute Engine.

  • For managed sources in Microsoft Azure or Amazon Web Services: You need to have a Cloud VPN or Cloud Interconnect configured in the same VPC network where you intend to create the private connectivity configuration for Database Migration Service. If you can't create the private connectivity configuration in the same VPC network, you need to set up a reverse proxy Virtual Machine (VM) on Compute Engine.

Configure private IP connectivity with VPC peering

To use private IP connectivity with Virtual Private Cloud peering, your source database private IP must be reachable from your Virtual Private Cloud. Depending on your network architecture, you might need to use additional components such as a reverse proxy VM or Cloud VPN.

To learn more about configuring private IP connectivity for different database sources, see:

Source network connectivity decision tree

When you are familiar with all supported source connectivity methods and their requirements, you can follow the questions in the diagram to help you pick the right connectivity method for your scenario.

A decision tree diagram with guiding questions to help you pick the right connectivity method.
Figure 5. Source network connectivity decision tree. (click to enlarge)

What's next