Migration to NGINX routers and load balancers

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation.

Throughout August and September 2015, we're migrating our Apigee Edge cloud routers and load balancers to NGINX (pronounced "Engine X"). NGINX, an open-source web server, provides even better performance and higher concurrency than our existing load balancers and routers.

What this means to our cloud customers

The bottom line is that this change should be transparent to you and requires no action on your part other than verification that your systems are working as expected. Following are descriptions of the steps we'll be taking, along with answers to some frequently asked questions.

Step 1 - Software update

We'll upgrade all routers to the new NGINX-based router by leveraging our phased deployment model to help ensure services aren’t impacted as a result of this activity.

Step 2 - Remove the load balancer tier in non-production environments

With the new NGINX router handling the load balancing functionality, we will begin the process of removing the existing load balancer tier in your non-production environment(s) first. Production load balancers will remain intact and unchanged during this step. Prior to the removal of existing load balancers, we will take an exhaustive approach towards ensuring traffic is working as expected. No action is required on your part to complete this step. However, you should report any issues to Apigee, and we'll work with you to resolve the issues prior to proceeding with Step 3.

Step 3 - Remove the load balancer tier in production environments

Upon successful completion of Step 2, we will determine a set of maintenance windows to remove the load balancer tier in production environment(s) using the same approach mentioned in Step 2 to ensure runtime API traffic continues to work as expected.

Changes to product functionality

Here are some changes to product functionality with the switch to NGINX.


The following properties are no longer supported in ProxyEndpoints:

  • allow.http10
  • allow.http11
  • allow.http.method.*
  • allow.POST.without.content.length
  • allow.PUT.without.content.length

To work around this deprecation, see the following community article: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.

Frequently asked questions

Following are answers to some frequently asked questions about the NGINX migration.

Will this potentially change public IPs? Some of our merchants specifically allow access from the known IPs, and when they change the merchants's flow breaks.
During Step 1, the answer is ‘No’ since we aren’t touching the existing load balancers, which will not directly change any of the IPs serving traffic. However, given the nature of the Amazon Web Services (AWS) load balancing service, normal scaling rules apply, which means IPs may change as part of its scaling logic (existing functionality). This is why we do not recommend implementing Northbound allowlisting configurations with the Apigee Edge product suite. During Steps 2 and 3, there are allowlist implications with the removal of the load balancer and its associated IP addresses. As a result, we’ll coordinate closely with you during these steps to ensure a smooth transition by providing a new set of IP addresses for which to allow access.
Will this affect the IP restrictions that we have in place on our origin servers?
No changes are required, assuming the origin servers are the target endpoint servers (servers called from the proxy bundle). This change is on the Northbound side of Apigee or the ingress point into Apigee.
Will our existing CNAME require change?
No. Existing CNAME entries will continue to function as expected.
SSL certificate migration will be painful. How are you going to handle this?
If you're using SSL, the initial step will not impact the existing SSL configuration. However, we will need to coordinate closely with you to ensure SSL is set up properly on the new router prior to proceeding with Steps 2 and 3.
What if my app/client does not support SNI?
Steps 2 and 3 will be delayed until SNI support is confirmed.
Will there be any downtime?
We do not expect any downtime. The changes will be implemented using our standard deployment model during our existing release windows.