Send feedback
Migrate northbound routing to Private Service Connect
Stay organized with collections
Save and categorize content based on your preferences.
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.
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.
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 .
Test the new global load balancer endpoint.
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.
Send feedback
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2024-10-07 UTC.
[{
"type": "thumb-down",
"id": "hardToUnderstand",
"label":"Hard to understand"
},{
"type": "thumb-down",
"id": "incorrectInformationOrSampleCode",
"label":"Incorrect information or sample code"
},{
"type": "thumb-down",
"id": "missingTheInformationSamplesINeed",
"label":"Missing the information/samples I need"
},{
"type": "thumb-down",
"id": "otherDown",
"label":"Other"
}]
[{
"type": "thumb-up",
"id": "easyToUnderstand",
"label":"Easy to understand"
},{
"type": "thumb-up",
"id": "solvedMyProblem",
"label":"Solved my problem"
},{
"type": "thumb-up",
"id": "otherUp",
"label":"Other"
}]
Need to tell us more?
{"lastModified": "Last updated 2024-10-07 UTC."}
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-10-07 UTC."]]