[[["易于理解","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-09-04。"],[[["\u003cp\u003eThis document details how Cloud NAT impacts Apigee performance, specifically in scenarios involving southbound traffic to target backends with public IP addresses.\u003c/p\u003e\n"],["\u003cp\u003eCloud NAT's transactions per second (TPS) capacity in Apigee instances is determined by the number of NAT IPs, the uniqueness of backend IP and port combinations, and whether target backends allow connection reuse.\u003c/p\u003e\n"],["\u003cp\u003eUtilizing unique combinations of backend IP addresses and ports can enhance TPS without the need for additional NAT IPs, which may be significant when dealing with allow-lists.\u003c/p\u003e\n"],["\u003cp\u003eConnection reuse, achieved through the \u003ccode\u003eConnection: keep-alive\u003c/code\u003e header, can improve the efficiency of NAT usage by reducing the need for new TCP connections, though its effectiveness depends on various connection factors.\u003c/p\u003e\n"],["\u003cp\u003eThe number of NAT IPs can be varied based on whether ephemeral or static IPs are utilized, with static IPs being necessary when IP allow-listing is needed at the target backend.\u003c/p\u003e\n"]]],[],null,["# Performance considerations for Apigee Cloud NAT\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\nSouthbound traffic between Apigee and a target backend with a public IP address uses [Cloud NAT](https://cloud.google.com/nat/docs/overview) to translate\nthe private IP address of the Apigee instance into a public IP address. Each Apigee\ninstance has its own Cloud NAT gateway. This topic explains the factors that impact Apigee performance when using\nCloud NAT.\n\nOverview\n--------\n\n\nEach new TCP session formed between an Apigee instance and a target backend must be mapped to a unique 4-tuple that includes the following:\n\n- The NAT IP address\n- The NAT port\n- The backend IP address\n- The backend port\n\nThere are three key factors that determine the transactions per second (TPS) that Cloud NAT can support in an Apigee instance:\n\n1. The number of NAT IPs allocated (dynamically or statically)\n2. The number of unique backend IP address and port combinations configured\n3. Whether or not connection reuse is allowed by the target backend\n\n\nThis 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.\n\nNAT IP Allocations\n------------------\n\n\nThe number of NAT IPs allocated will vary depending on the use of *ephemeral* or *static* IPs in the NAT configuration.\nSee the **NAT IP addresses per gateway** in the [Cloud NAT Limits](/nat/quota#limits) for more information.\n\n### Ephemeral IPs\n\n\nIn the default NAT configuration using ephemeral IPs, the IPs are automatically allocated as needed to provide unique source ports for connections to target backends.\n\n### Static IPs\n\n\nIf 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.\n\nUnique Backend IP and Port Combinations\n---------------------------------------\n\n\nYou can increase TPS by increasing the number of unique target backend IP and port combinations. The same NAT IP and source 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.\n\n\nTo 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.\n| **Note**: If the backend is a Network Load Balancer (NLB) at another Cloud Provider, make sure it supports concurrent usage of the same NAT IP and source port against multiple IP addresses of that NLB. You might need to disable features like \"cross-zone load balancing\" or \"client IP address preservation\" to make it work. Otherwise, you might encounter variety of connectivity errors related to connection reuse. Please reach out to the relevant Cloud Provider for assistance.\n\nConnection Reuse\n----------------\n\nReusing HTTP connections also increases the efficient use of NAT by removing the\nneed to open a new TCP connection. Target backends can use this feature by setting the\n**`Connection`** header to**`keep-alive`** in the response,\nwhich is the default setting for HTTP/1.1. The target backend server can also set `connection timeout`\nand `max reuse` parameters to improve efficiency.\n\nWhile connection reuse can theoretically be supported by enabling **`keep-alive`**\nin the response, in practice, connection reuse depends on the following:\n\n- If the Apigee instance has an existing connection to the target backend\n- If the existing connection has pending responses\n- If the existing connection is near the end of its lifecycle\n\nEach of these factors will affect the extent to which the target backend can reuse connections."]]
