[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-26。"],[[["\u003cp\u003eThis guide explains how to migrate client-to-Apigee routing from a managed instance group (MIG) to a Private Service Connect (PSC) based configuration.\u003c/p\u003e\n"],["\u003cp\u003eThe migration is relevant for those currently using a Global external HTTPS Load Balancer (Classic) with a managed instance group (MIG) for routing traffic to Apigee and want to switch to using PSC.\u003c/p\u003e\n"],["\u003cp\u003eMigration involves configuring northbound routing to Apigee endpoints using the Apigee CLI, creating NEGs for multi-region use cases, testing the new load balancer, and switching DNS entries to the new load balancer endpoint.\u003c/p\u003e\n"],["\u003cp\u003eBecause the global external HTTPS load balancer does not support PSC NEG backends, a new global external HTTPS load balancer needs to be created and have the traffic switched to it.\u003c/p\u003e\n"]]],[],null,["# Migrate northbound routing to Private Service Connect\n\n*This page\napplies to **Apigee** , but not to **Apigee hybrid**.*\n\n\n*View [Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) documentation.*\n\n| **Important:** This topic only applies to organizations that were created with VPC peering enabled. See also [Apigee networking options](/apigee/docs/api-platform/get-started/networking-options).\n\n\nThis document explains how to migrate your client-to-Apigee (also called \"northbound\") routing configuration\nfrom a managed instance group (MIG) configuration to a [Private Service Connect (PSC)](/apigee/docs/api-platform/system-administration/northbound-networking-psc) based\nconfiguration.\n\nOverview\n--------\n\nIf you are currently using the\n[managed instance group (MIG)\nbased configuration](/apigee/docs/api-platform/get-started/install-cli#configure-routing) using a [Global\nexternal HTTPS Load Balancer (Classic)](/load-balancing/docs/https) for routing external traffic to Apigee, you can choose\nto migrate this \"northbound\" traffic to use a PSC based configuration.\n| **Important:**Because the classic global external HTTPS load balancer does not support PSC NEG backends, you must create a new global external HTTPS load balancer and switch the incoming traffic through DNS.\n\nMigration steps\n---------------\n\n| **Note:** To ensure that the load balancer operates as expected, you must carry over any classic HTTPS load balancer [configurations or add-on features](/load-balancing/docs/features) to the new global load balancer.\n\n1. Configure northbound routing to Apigee endpoints. For this task, follow the steps under the **External routing (PSC)** tab under [Configure routing](/apigee/docs/api-platform/get-started/install-cli#configure-routing) in the Apigee CLI provisioning document.\n2. If you have multiple Apigee instances (a multi-region use case), create corresponding NEGs for each of the Apigee regions and attach them to the backend service of the load balancer. See [Expanding Apigee to multiple regions](/apigee/docs/api-platform/system-administration/multi-region).\n3. Test the new global load balancer endpoint.\n4. When testing is complete, switch all of your existing DNS entries to point to the new load balancer endpoint. Note the following: **Note:**\n | - Different DNS providers support different kinds of routing policies. For example: [Cloud DNS supports](/dns/docs/zones/manage-routing-policies) weighted round robin (WRR) routing policy, which ensures the traffic is distributed according to the configured weights. Such routing policy can be leveraged for switching the traffic between the 2 load balancer endpoints.\n | - The new global external load balancer (GXLB) endpoint can be added to the customer's DNS endpoint with small weight, enough to allow 5% or 10% of their traffic. This can be slowly ramped to allow 100% of traffic on the new GXLB endpoint and 0% on the old GXLB (Classic) endpoint.\n | - Remove the old GXLB (Classic) endpoint from the DNS, and delete the old GXLB (Classic) along with the MIG backend."]]
