PostgreSQL용 AlloyDB의 비공개 서비스 액세스 및 Private Service Connect에 대한 자세한 내용은 PostgreSQL용 AlloyDB 문서의 비공개 IP 개요를 참고하세요.
연결 제한사항
PostgreSQL에서 AlloyDB로의 연결에는 다음과 같은 제한사항이 있습니다.
AlloyDB는 비공개 서비스 액세스를 사용한 비공개 연결을 지원합니다. 클러스터에 공개 IP 주소를 할당하는 것은 지원되지 않습니다.
클러스터가 생성된 후에는 AlloyDB 클러스터가 피어링된 VPC를 변경할 수 없습니다.
AlloyDB는 내부적으로 VPC 피어링을 사용하는 비공개 서비스 액세스를 사용하므로 전환 피어링이 지원되지 않습니다. AlloyDB 클러스터는 피어링된 동일한 VPC의 내부 IP 주소에만 연결할 수 있습니다. 다른 VPC에 연결하려면 중간 프록시를 사용해야 합니다. 자세한 내용은 다음 섹션을 참고하세요.
일반적인 연결 시나리오 및 해결 방법
이전 프로듀서 네트워크 아키텍처의 Cloud SQL 인스턴스에서 마이그레이션
그림 1. TCP 프록시 VM으로 지원되는 비공개 연결(확대하려면 클릭)
기존 프로듀서 네트워크 아키텍처의 PostgreSQL용 Cloud SQL 인스턴스에서 마이그레이션하려면 중개 프록시를 사용하여 연결을 설정해야 합니다. 이는 소스 Cloud SQL 인스턴스와 AlloyDB 대상 간에 직접 연결할 수 없기 때문입니다.
자체 프록시 솔루션을 설정할 수 있지만 Database Migration Service에서 제공하는 자동 생성 스크립트로 TCP 프록시 VM을 설정하는 것이 좋습니다.
TCP 프록시 연결 방법을 참고하세요.
동일한 Google Cloud 프로젝트에 있지만 다른 VPC의 소스에서 이전
AlloyDB 클러스터가 있는 VPC는 클러스터를 만든 후 변경할 수 없으므로 다음 옵션이 있습니다.
소스 인스턴스의 VPC를 대상 인스턴스의 VPC와 일치하도록 변경하는 것이 좋습니다. 예를 들어 Cloud SQL 인스턴스를 AlloyDB로 이전하려면 AlloyDB VPC와 일치하도록 Cloud SQL VPC를 업데이트합니다.
다른 Google Cloud 프로젝트의 소스에서 마이그레이션하려면 인터넷을 통해 마이그레이션하거나 내부 Google Cloud 연결의 경우 공유 VPC를 사용해야 합니다. 다음 옵션 중 하나를 선택합니다.
프록시 없이 공유 VPC를 사용합니다. AlloyDB 클러스터를 공유 VPC에 배치하려면 클러스터를 만들 때 소스가 있는 VPC를 선택하면 됩니다. 이렇게 하면 소스와 대상이 직접 연결됩니다.
프록시와 함께 공유 VPC를 사용합니다. AlloyDB 클러스터가 공유 VPC에 상주하지 않도록 하려면 중간 프록시를 사용해야 합니다. 자체 프록시 솔루션을 설정할 수 있지만 TCP 프록시 연결 방법을 사용하는 것이 좋습니다. 이 가이드라인에 따라 공유 VPC에 추가 네트워크 인터페이스가 있는 TCP 프록시를 만드세요.
대상에서 소스의 네트워크에 연결할 수 없도록 마이그레이션
이 방법은 인바운드 Google Cloud 트래픽에 네트워크의 방화벽을 여는 것이 우려되는 온프레미스 네트워크에서 이전할 때 권장됩니다. 이 시나리오에서는 Compute Engine 인스턴스를 중간 프록시로 사용하여 리버스 프록시를 설정할 수 있습니다. 역방향 SSH 연결 방법을 사용하는 것이 좋습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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)."]]
