Para crear una migración en Database Migration Service, se debe establecer 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 IP de anunciantes permitidos
Este método funciona configurando el servidor de base de datos de origen para que acepte conexiones desde la IP de salida de la instancia de Cloud SQL.
Si eliges este método, Database Migration Service te guiará
durante el proceso de configuración durante la creación de la migración.
Es fácil de configurar.
No requiere ninguna configuración personalizada del firewall.
El tráfico de red se produce a través de la Internet pública.
Menos segura
Disminución del rendimiento
Proxy a través de VM alojada en la nube: túnel SSH inverso
Establece la conectividad desde el destino hasta la fuente a través de un túnel SSH inverso seguro.
Requiere una VM de host de bastión en el proyecto de la plataforma Google Cloud , así como una máquina (por ejemplo, una laptop en la red) que tenga conectividad con la fuente.
Database Migration Service recopila la información necesaria en el momento de la creación de la migración y genera automáticamente la secuencia de comandos para configurar todo.
Es fácil de configurar.
No requiere ninguna configuración personalizada del firewall.
Se recomienda para situaciones de migración de corta duración (POC o migraciones de bases de datos pequeñas).
La VM de host bastión es de tu propiedad y la administras tú, y puede generar costos adicionales.
Proxy a través de VM alojada en la nube: TCP
Establece la conectividad desde el destino hasta la fuente con un proxy TCP a través de una VM alojada en la nube.
Database Migration Service recopila la información necesaria en el momento de la creación de la migración y genera automáticamente la secuencia de comandos para configurar todo.
Es relevante en las migraciones de AlloyDB en las que la fuente se encuentra en la arquitectura de red anterior.
Es fácil de configurar.
No requiere ninguna configuración personalizada del firewall.
La VM de host bastión es de tu propiedad y la administras tú, y puede generar costos adicionales.
Intercambio de tráfico entre VPC
Este método funciona configurando las VPC para que se comuniquen entre sí.
Solución Google Cloud nativa.
Es fácil de configurar.
Tiene un ancho de banda alto.
Se recomienda para migraciones de larga duración o de gran volumen.
Se aplica si las bases de datos de origen y destino están alojadas en Google Cloud, o si la fuente está conectada a la VPC de destino a través de 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 a la IP privada de tu base de datos de origen
sin consumir la cuota de intercambio de tráfico. En su lugar, este método de conectividad utiliza los adjuntos de red que creas en tu VPC.
Establece conexiones con la IP privada de origen a través de una conexión de red.
Este método no consume la cuota de intercambio de tráfico en tu VPC.
Es el método de conectividad privada de la fuente más fácil de configurar.
Requiere configurar una conexión de red y ajustar las reglas de firewall.
No puedes modificar el adjunto de red después de establecer la
conexión.
Para obtener más información sobre el acceso privado a servicios y Private Service Connect en AlloyDB para PostgreSQL, consulta Descripción general de la IP privada 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 a través del acceso privado a servicios. 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 intercambia tráfico el clúster de AlloyDB después de crearlo.
Dado que AlloyDB usa el acceso privado a servicios, que internamente usa el intercambio de tráfico entre VPCs, no se admite el intercambio de tráfico transitivo. Tu clúster de AlloyDB solo puede acceder a direcciones IP internas en la misma VPC con la que está interconectado. Para llegar a otras VPC, debes usar un proxy intermediario. Para obtener más detalles, consulta la siguiente sección.
Situaciones y soluciones comunes de conectividad
Migra 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 desde una instancia de Cloud SQL para PostgreSQL en la arquitectura de red del productor anterior, debes establecer la conectividad con un proxy intermediario. Esto se debe a que no es posible tener 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 del proxy TCP con la secuencia de comandos generada automáticamente que proporciona Database Migration Service.
Consulta el método de conectividad del proxy TCP.
Migra desde una fuente en el mismo proyecto de Google Cloud , pero en una VPC diferente
Dado que la VPC en la que reside el clúster de AlloyDB no se puede cambiar después de que se crea 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 deseas migrar una instancia de Cloud SQL a AlloyDB, actualiza la VPC de Cloud SQL para que coincida con la VPC de AlloyDB.
Para agregar otra interfaz de red, agrega --network-interface network=SOURCE_NETWORK_NAME al comando gcloud compute instances create-with-container que aparece en el script.
A continuación, se muestra un ejemplo de comando para crear el proxy:
Migra desde una fuente en un proyecto Google Cloud diferente
Para migrar desde una fuente en un proyecto Google Cloud diferente, debes migrar a través de Internet o, para la conectividad Google Cloud interna, usar una VPC compartida. Selecciona una de las siguientes opciones:
Usar una VPC compartida sin un proxy Si deseas que tu clúster de AlloyDB resida en una VPC compartida, simplemente selecciona la VPC en la que reside tu fuente cuando crees el clúster. De esta manera, 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 intermedio. Puedes configurar tu propia solución de proxy, pero te recomendamos que uses el método de conectividad de proxy TCP. Sigue estos lineamientos para crear un proxy TCP con una interfaz de red adicional en una VPC compartida.
Migra sin permitir que el destino llegue a la red de la fuente
Se recomienda este método cuando se migra desde una red local, en la que existe la preocupación de abrir el firewall de la red al tráfico Google Cloud entrante. Para este caso, puedes configurar un proxy inverso con una instancia de Compute Engine como proxy intermediario. Te recomendamos que uses el método de conectividad SSH inversa.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-05 (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)."]]
