This page applies to Apigee, but not to Apigee hybrid.
View
Apigee Edge documentation.
Southbound traffic between Apigee and a target backend with a public IP address uses Cloud NAT to translate the private IP address of the Apigee instance into a public IP address. Each Apigee instance has its own Cloud NAT gateway. This topic explains the factors that impact Apigee performance when using Cloud NAT.
Overview
Each new TCP session formed between an Apigee instance and a target backend must be mapped to a unique 4-tuple that includes the following:
- The NAT IP address
- The NAT port
- The backend IP address
- The backend port
There are three key factors that determine the transactions per second (TPS) that Cloud NAT can support in an Apigee instance:
- The number of NAT IPs allocated (dynamically or statically)
- The number of unique backend IP address and port combinations configured
- Whether or not connection reuse is allowed by the target backend
This topic explains how each of these factors impacts Apigee performance when using Cloud NAT and describes how to calculate the number of static IPs that may be required to support anticipated traffic.
NAT IP Allocations
The number of NAT IPs allocated will vary depending on the use of ephemeral or static IPs in the NAT configuration.
Ephemeral IPs
In the default NAT configuration using ephemeral IPs, the IPs are automatically allocated as needed to provide unique source ports for connections to target backends. A maximum of 300 ephemeral IPs can be allocated for an Apigee instance.
Static IPs
If static IPs are required so that the IPs can be allow-listed for the target backend, the IPs are manually reserved for an Apigee instance. A maximum of 50 static IPs can be allocated for an Apigee instance.
Unique Backend IP and Port Combinations
You can increase TPS by increasing the number of unique target backend IP and port combinations. The same NAT IP and port can be used for each of the target backend IPs and ports. This achieves the same result as adding more NAT IPs without requiring additional IPs that must be allow-listed.
To create a unique target backend IP and port pair, the IP or the port must be different. For example, it is possible to have a single load balancer with one IP address, but listening on 4 different ports, to make 4 unique backend IP and port combinations for Apigee.
Connection Reuse
Reusing HTTP connections also increases the efficient use of NAT by removing the
need to open a new TCP connection. Target backends can use this feature by setting the
Connection header to keep-alive in the response,
which is the default setting for HTTP/1.1. The target backend server can also set connection timeout
and max reuse parameters to improve efficiency.
While connection reuse can theoretically be supported by enabling keep-alive
in the response, in practice, connection reuse depends on the following:
- If the Apigee instance has an existing connection to the target backend
- If the existing connection has pending responses
- If the existing connection is near the end of its lifecycle
Each of these factors will affect the extent to which the target backend can reuse connections.