Para criar uma migração no serviço de migração de bases de dados, tem de estabelecer a conetividade entre a instância de origem e a instância de destino do AlloyDB. Existem vários métodos suportados. Escolha o que funciona melhor para a carga de trabalho específica.
Método de rede
Descrição
Vantagens
Desvantagens
Lista de autorizações de IPs
Este método funciona configurando o servidor da base de dados de origem para aceitar ligações
do IP de saída da instância do Cloud SQL.
Se escolher este método, o serviço de migração de bases de dados oferece-lhe instruções
durante o processo de configuração da criação da migração.
Fácil de configurar.
Não requer nenhuma configuração personalizada da firewall.
O tráfego de rede ocorre através da Internet pública.
Menos seguro.
Diminuição do desempenho.
Proxy através de VM alojada na nuvem: túnel SSH inverso
Estabelece a conetividade do destino à origem através de um túnel SSH inverso seguro.
Requer uma VM de anfitrião de bastião no Google Cloud projeto da plataforma, bem como uma máquina
(por exemplo, um portátil na rede) que tenha conetividade à
origem.
O serviço de migração de bases de dados recolhe as informações necessárias no momento da criação da migração e gera automaticamente o script para configurar tudo.
Fácil de configurar.
Não requer nenhuma configuração personalizada da firewall.
Recomendado para cenários de migração de curta duração (POC ou migrações de bases de dados pequenas).
A VM bastion é detida e gerida por si e pode incorrer em custos adicionais.
Proxy através de VM alojada na nuvem – TCP
Estabelece a conetividade da origem ao destino através de um proxy TCP através de uma VM alojada na nuvem.
O serviço de migração de bases de dados recolhe as informações necessárias no momento da criação da migração e gera automaticamente o script para configurar tudo.
Relevante em migrações do AlloyDB em que a origem está na arquitetura de rede antiga.
Fácil de configurar.
Não requer nenhuma configuração personalizada da firewall.
A VM bastion é detida e gerida por si e pode incorrer em custos adicionais.
Intercâmbio da VPC
Este método funciona configurando as VPCs para comunicarem entre si.
Solução Google Cloud nativa.
Fácil de configurar.
Largura de banda elevada.
Recomendado para migrações de longa duração ou de grande volume.
Aplicável se as bases de dados de origem e de destino estiverem alojadas no
Google Cloudou se a origem estiver ligada à VPC de destino
através de uma VPN (alojada na nuvem ou nas instalações) ou do Cloud Interconnect.
Interfaces do Private Service Connect
As interfaces do Private Service Connect permitem que a base de dados de destino inicie ligações ao IP privado da base de dados de origem sem consumir a quota de peering. Em alternativa, este método de conetividade
usa associações de rede que cria na sua VPC.
Estabelece ligações ao IP privado de origem através de uma associação de rede.
Este método não consome a quota de intercâmbio na sua VPC.
O método de conetividade privada de origem mais fácil de configurar.
Requer a configuração de uma associação de rede e o ajuste das regras de firewall.
Não pode modificar a associação de rede depois de estabelecer a ligação.
Para mais informações sobre o acesso a serviços privados e o
Private Service Connect no
AlloyDB para PostgreSQL,
consulte a vista geral do IP privado
na documentação do AlloyDB para PostgreSQL.
Limitações de conetividade
A conetividade do PostgreSQL ao AlloyDB tem as seguintes limitações:
O AlloyDB suporta a conetividade privada através do acesso a serviços privados. A atribuição de um endereço IP público a um cluster não é suportada.
Não é possível alterar a VPC com a qual o cluster do AlloyDB está interligado após a criação do cluster.
Uma vez que o AlloyDB usa o acesso a serviços privados, que usa internamente o intercâmbio de VPC, o intercâmbio transitivo não é suportado. O cluster do AlloyDB só pode alcançar endereços IP internos na mesma VPC com a qual está em peering. Para alcançar outras VPCs, tem de usar um proxy intermediário. Para mais detalhes, consulte a secção seguinte.
Cenários e soluções de conetividade comuns
Migre de uma instância do Cloud SQL na antiga arquitetura de rede do produtor
Figura 1. Uma ligação privada facilitada pela VM de proxy TCP
(clique para aumentar)
Para migrar de uma instância do Cloud SQL para PostgreSQL na arquitetura de rede do produtor antigo, tem de estabelecer a conetividade através de um proxy intermediário. Isto deve-se ao facto de não ser possível ter conetividade direta entre a instância do Cloud SQL de origem e o destino do AlloyDB.
Pode configurar a sua própria solução de proxy, embora recomendemos que configure a VM de proxy TCP com o script gerado automaticamente fornecido pelo serviço de migração de bases de dados.
Consulte o método de conetividade do proxy TCP.
Migre de uma origem no mesmo Google Cloud projeto, mas numa VPC diferente
Uma vez que não é possível alterar a VPC na qual o cluster do AlloyDB reside após a criação do cluster, tem as seguintes opções:
A opção recomendada é alterar a VPC da instância de origem para corresponder à VPC da instância de destino. Por exemplo, se quiser migrar uma instância do Cloud SQL para o AlloyDB, atualize a VPC do Cloud SQL para corresponder à VPC do AlloyDB.
Para adicionar outra interface de rede, anexe --network-interface network=SOURCE_NETWORK_NAME ao comando gcloud compute instances create-with-container que aparece no script.
Migre de uma origem num Google Cloud projeto diferente
Para migrar a partir de uma origem num Google Cloud projeto diferente, tem de migrar através da Internet ou, para a conetividade Google Cloud interna, usar uma VPC partilhada. Selecione uma das seguintes opções:
Use uma VPC partilhada sem um proxy. Se quiser que o cluster do AlloyDB resida numa VPC partilhada, basta selecionar a VPC onde a origem reside quando criar o cluster. Desta forma, a origem e o destino têm conetividade direta.
Use uma VPC partilhada com um proxy. Se não quiser que o cluster do AlloyDB resida numa VPC partilhada, tem de usar um proxy intermediário. Pode configurar a sua própria solução de proxy, mas recomendamos que use o método de conetividade de proxy TCP. Siga estas diretrizes para criar um proxy TCP com uma interface de rede adicional numa VPC partilhada.
Migre sem permitir que o destino alcance a rede da origem
Este método é recomendado quando migra de uma rede no local, em que existe uma preocupação em abrir a firewall da rede ao tráfego Google Cloud recebido. Para este cenário, pode configurar um proxy inverso através de uma instância do Compute Engine como proxy intermediário. Recomendamos que use o método de conetividade SSH inversa.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
