Migrate northbound routing to Private Service Connect

This page applies to Apigee, but not to Apigee hybrid.

View Apigee Edge documentation.

Important: This topic only applies to organizations that were created with VPC peering enabled. See also Apigee networking options.

This document explains how to migrate your client-to-Apigee (also called "northbound") routing configuration from a managed instance group (MIG) configuration to a Private Service Connect (PSC) based configuration.

Overview

If you are currently using the managed instance group (MIG) based configuration using a Global external HTTPS Load Balancer (Classic) for routing external traffic to Apigee, you can choose to migrate this "northbound" traffic to use a PSC based configuration.

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.

Migration steps

Note: To ensure that the load balancer operates as expected, you must carry over any classic HTTPS load balancer configurations or add-on features to the new global load balancer.

1. Configure northbound routing to Apigee endpoints. For this task, follow the steps under the External routing (PSC) tab under Configure routing in the Apigee CLI provisioning document.
2. 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.
3. Test the new global load balancer endpoint.
4. When testing is complete, switch all of your existing DNS entries to point to the new load balancer endpoint. Note the following:
   Note:

   • Different DNS providers support different kinds of routing policies. For example: Cloud DNS supports 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.
   • 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.
   • Remove the old GXLB (Classic) endpoint from the DNS, and delete the old GXLB (Classic) along with the MIG backend.