Para crear una migración en Database Migration Service, debe establecerse la conectividad entre la instancia de origen y la instancia de destino de AlloyDB. Se admiten varios métodos. Elige la que mejor se adapte a la carga de trabajo específica.
Método de red
Descripción
Ventajas
Desventajas
Lista de IPs permitidas
Este método consiste en configurar el servidor de la base de datos de origen para que acepte conexiones de la IP de salida de la instancia de Cloud SQL.
Si eliges este método, el servicio de migración de bases de datos te guiará por el proceso de configuración durante la creación de la migración.
Fácil de configurar.
No requiere ninguna configuración de firewall personalizada.
El tráfico de red se produce a través de la red pública de Internet.
Menos seguro.
Rendimiento reducido.
Proxy mediante una VM alojada en la nube: túnel inverso SSH
Establece la conectividad del destino al origen a través de un túnel inverso SSH seguro.
Requiere una VM de host bastion en el proyecto de la plataforma, así como una máquina (por ejemplo, un portátil en la red) que tenga conectividad con la fuente. Google Cloud
Database Migration Service recoge la información necesaria en el momento de crear la migración y genera automáticamente la secuencia de comandos para configurarlo todo.
Fácil de configurar.
No requiere ninguna configuración de firewall personalizada.
Recomendado para escenarios de migración de corta duración (pruebas de concepto o migraciones de bases de datos pequeñas).
La máquina virtual bastion es de tu propiedad y tú la gestionas, por lo que puede incurrir en costes adicionales.
Proxy a través de una VM alojada en la nube (TCP)
Establece la conectividad desde el destino hasta la fuente mediante un proxy TCP a través de una máquina virtual alojada en la nube.
Database Migration Service recoge la información necesaria en el momento de crear la migración y genera automáticamente la secuencia de comandos para configurarlo todo.
Es relevante en las migraciones de AlloyDB en las que el origen se encuentra en la arquitectura de red antigua.
Fácil de configurar.
No requiere ninguna configuración de firewall personalizada.
La máquina virtual bastion es de tu propiedad y tú la gestionas, por lo que puede incurrir en costes adicionales.
Emparejamiento de VPC
Este método funciona configurando las VPCs para que se comuniquen entre sí.
Solución nativa Google Cloud .
Fácil de configurar.
Ancho de banda alto.
Recomendado para migraciones de larga duración o de gran volumen.
Se aplica si las bases de datos de origen y de destino están alojadas en Google Cloudo si el origen está conectado a la VPC de destino mediante una VPN (alojada en la nube o local) o Cloud Interconnect.
Interfaces de Private Service Connect
Las
interfaces de Private Service Connect permiten que tu base de datos de destino inicie conexiones con la IP privada de tu base de datos de origen sin consumir cuota de peering. En su lugar, este método de conectividad utiliza las conexiones de red que creas en tu VPC.
Establece conexiones con tu IP privada de origen mediante un acoplamiento de red.
Este método no consume cuota de emparejamiento en tu VPC.
Es el método de conectividad privada de origen más fácil de configurar.
Requiere configurar una conexión de red y ajustar las reglas de cortafuegos.
No puedes modificar la conexión de red después de establecer la conexión.
Para obtener más información sobre el acceso a servicios privados y Private Service Connect en AlloyDB para PostgreSQL, consulta la descripción general de las IPs privadas en la documentación de AlloyDB para PostgreSQL.
Limitaciones de conectividad
La conectividad de PostgreSQL a AlloyDB tiene las siguientes limitaciones:
AlloyDB admite la conectividad privada mediante el acceso a servicios privados. No se admite la asignación de una dirección IP pública a un clúster.
No puedes cambiar la VPC con la que se empareja el clúster de AlloyDB después de crear el clúster.
Como AlloyDB usa el acceso a servicios privados, que internamente usa el emparejamiento de VPCs, no se admite el emparejamiento transitivo. Tu clúster de AlloyDB solo puede acceder a direcciones IP internas de la misma VPC con la que está emparejado. Para acceder a otras VPCs, debes usar un proxy intermediario. Para obtener más información, consulta la siguiente sección.
Situaciones y soluciones de conectividad habituales
Migrar desde una instancia de Cloud SQL en la antigua arquitectura de red del productor
Figura 1. Una conexión privada facilitada por la VM del proxy TCP
(haz clic para ampliar)
Para migrar de una instancia de Cloud SQL para PostgreSQL en la antigua arquitectura de red del productor, debes establecer la conectividad mediante un proxy intermediario. Esto se debe a que no es posible tener una conectividad directa entre la instancia de Cloud SQL de origen y el destino de AlloyDB.
Puedes configurar tu propia solución de proxy, aunque te recomendamos que configures la VM de proxy TCP con la secuencia de comandos generada automáticamente que proporciona Database Migration Service.
Consulta el método de conectividad del proxy TCP.
Migrar desde una fuente del mismo proyecto Google Cloud , pero en otra VPC
Como la VPC en la que reside el clúster de AlloyDB no se puede cambiar una vez creado el clúster, tienes las siguientes opciones:
La opción recomendada es cambiar la VPC de la instancia de origen para que coincida con la de la instancia de destino. Por ejemplo, si quieres migrar una instancia de Cloud SQL a AlloyDB, actualiza la VPC de Cloud SQL para que coincida con la VPC de AlloyDB.
Para añadir otra interfaz de red, añade --network-interface network=SOURCE_NETWORK_NAME al comando gcloud compute instances create-with-container que aparece en la secuencia de comandos.
Migrar desde una fuente de otro proyecto Google Cloud
Para migrar desde una fuente de otro proyecto, debes migrar a través de Internet o, para la conectividad interna, usar una VPC compartida. Google Cloud Google Cloud Selecciona una de las opciones siguientes:
Usa una VPC compartida sin proxy. Si quieres que tu clúster de AlloyDB se encuentre en una VPC compartida, solo tienes que seleccionar la VPC en la que se encuentra tu origen al crear el clúster. De esta forma, el origen y el destino tienen conectividad directa.
Usa una VPC compartida con un proxy. Si no quieres que tu clúster de AlloyDB resida en una VPC compartida, debes usar un proxy intermediario. Puedes configurar tu propia solución de proxy, pero te recomendamos que uses el método de conectividad de proxy TCP. Sigue estas directrices para crear un proxy TCP con una interfaz de red adicional en una VPC compartida.
Migrar sin permitir que el destino acceda a la red del origen
Este método se recomienda cuando se migra desde una red local, en la que se teme abrir el cortafuegos de la red al tráfico entrante. Google Cloud En este caso, puedes configurar un proxy inverso mediante una instancia de Compute Engine como proxy intermediario. Te recomendamos que uses el método de conectividad SSH inverso.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-08-21 (UTC)."],[[["\u003cp\u003eDatabase Migration Service requires establishing connectivity between the source instance and the AlloyDB destination instance for migrations, with several methods available.\u003c/p\u003e\n"],["\u003cp\u003eThe IP allowlist method is suitable for short-lived migrations, offering ease of configuration but transmitting network traffic over the public internet, which affects security and performance.\u003c/p\u003e\n"],["\u003cp\u003eProxy methods via cloud-hosted VMs, using either Reverse-SSH tunnels or TCP proxies, are recommended for short-lived migrations and offer ease of configuration without custom firewall adjustments.\u003c/p\u003e\n"],["\u003cp\u003eVPC peering is a native Google Cloud solution that provides high bandwidth and is ideal for long-running or high-volume migrations, but it is only available if both source and destination are hosted in Google Cloud or are connected to the same VPC.\u003c/p\u003e\n"],["\u003cp\u003eFor sources in different networks or on-premise instances, using a proxy or migrating over the public internet are viable options, and there are guides to aid with this process.\u003c/p\u003e\n"]]],[],null,["# Networking methods\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/networking-methods \"View this page for the MySQL version of Database Migration Service.\") \\| [PostgreSQL](/database-migration/docs/postgres/networking-methods \"View this page for the PostgreSQL version of Database Migration Service.\") \\| PostgreSQL to AlloyDB\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nTo create a migration in Database Migration Service, connectivity must be established between the source instance and the AlloyDB destination instance. There are various methods supported. Choose the one that works best for the specific workload. \n\nConnectivity limitations\n------------------------\n\nThe PostgreSQL to AlloyDB connectivity has the following limitations:\n\n- AlloyDB supports private connectivity using [private services access](/alloydb/docs/configure-connectivity). Assigning a public IP address to a cluster is not supported.\n- You can't change the VPC with which the AlloyDB cluster is peered after the cluster is created.\n- Because AlloyDB uses private services access which internally uses VPC peering, [transitive peering](/vpc/docs/vpc-peering#specifications) isn't supported. Your AlloyDB cluster can only reach internal IP addresses in the same VPC with which it is peered. In order to reach other VPCs, you must use an intermediary proxy. For more details, see the following section.\n\nCommon connectivity scenarios and solutions\n-------------------------------------------\n\n### Migrate from a Cloud SQL instance in the old producer network architecture\n\n[](#lightbox-trigger) **Figure 1.** A private connection facilitated by the TCP proxy VM (click to enlarge)\n\nTo migrate from a Cloud SQL for PostgreSQL instance in the old producer\nnetwork architecture, you must establish connectivity using an intermediary\nproxy. This is because it isn't possible to have direct connectivity between\nthe source Cloud SQL instance and the AlloyDB destination.\nYou can set up your own proxy solution, although we recommend setting up\nthe TCP proxy VM with the auto-generated script provided by Database Migration Service.\nSee [TCP proxy connectivity method](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-tcp-proxy-via-cloud-hosted-vm).\n\n### Migrate from a source in the same Google Cloud project but in a different VPC\n\nBecause the VPC in which the AlloyDB cluster resides can't be changed after the cluster is created, you have the following options:\n\n- The recommended option is to change the VPC of the source instance to match the VPC of the destination instance. For example, if you want to migrate a Cloud SQL instance to AlloyDB, [update the Cloud SQL VPC](/sql/docs/postgres/configure-private-ip#existing-private-instance) to match the AlloyDB VPC.\n\n | **Caution:** Configuring a private IP address for an existing Cloud SQL instance causes the instance to restart, resulting in downtime.\n- If it's not possible to change the VPC of the source instance to match the VPC of the destination instance, then use an intermediary virtual machine (VM) as a proxy. You can set up your own proxy solution, although we recommend using the [TCP proxy connectivity method](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-tcp-proxy-via-cloud-hosted-vm). After Database Migration Service generates your script in the Google Cloud console, add another network interface to the command for creating a TCP proxy instance, and configure it to match the VPC of the source instance. This way, the proxy has connectivity to both the source and destination VPCs.\n\n To add another network interface, append `--network-interface network=SOURCE_NETWORK_NAME` to the `gcloud compute instances create-with-container` command that appears in the script.\n | **Note:** For custom mode VPC networks, you have to explicitly specify the subnet. The argument you need to append is `--network-interface network=SOURCE_NETWORK_NAME,subnet=`\u003cvar translate=\"no\"\u003eSOURCE_SUBNET_NAME\u003c/var\u003e.\n\n An example command to create the proxy: \n\n ```bash\n gcloud compute instances create-with-container … \\\n --network-interface subnet=DESTINATION-SUBNET-NAME \\\n --network-interface network=SOURCE-NETWORK-NAME\n ```\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eDESTINATION-SUBNET-NAME\u003c/var\u003e: The name of the destination subnet.\n - \u003cvar translate=\"no\"\u003eSOURCE-NETWORK-NAME\u003c/var\u003e: The name of the source network.\n\nFor more information, see [Create VM instances with multiple network interfaces](/vpc/docs/create-use-multiple-interfaces#creating_virtual_machine_instances_with_multiple_network_interfaces).\n\n### Migrate over the public internet\n\nThis method is recommended when migrating from an on-premise instance or from\nother cloud providers, where there's no existing VPN or Interconnect connection\nto Google Cloud. To use this method, you need to\n[configure your destination AlloyDB cluster to use an outbound public IP address](/alloydb/docs/connect-public-ip#add-outbound-connectivity).\n\n### Migrate from a source in a different Google Cloud project\n\nTo migrate from a source in a different Google Cloud project, you must either migrate over the internet, or, for internal Google Cloud connectivity, use a shared VPC. Select one of the following options:\n\n- Use a shared VPC without a proxy. If you want your AlloyDB cluster to reside in a shared VPC, then simply select the VPC where your source resides when creating the cluster. This way, source and destination have direct connectivity.\n\n- Use a shared VPC with a proxy. If you don't want your AlloyDB cluster to reside in a shared VPC, then you must use an intermediary proxy. You can set up your own proxy solution, but we recommend using the [TCP proxy connectivity method](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-tcp-proxy-via-cloud-hosted-vm). Follow [these guidelines](#intermediaryproxy) to create a TCP proxy with an additional network interface on a shared VPC.\n\n### Migrate without allowing the destination to reach the network of the source\n\nThis method is recommended when migrating from an on-premise network, where there's a concern of opening the network's firewall to incoming Google Cloud traffic. For this scenario, you can set up a reverse proxy using a Compute Engine instance as an intermediary proxy. We recommend using the [reverse SSH connectivity method](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-reverse-ssh-tunnel)."]]
