このトピックでは、Cloud NAT 使用時にこれらの各要素が Apigee のパフォーマンスにどのように影響するかを説明し、予想されるトラフィックのサポートに必要な静的 IP の数を計算する方法について説明します。
NAT IP の割り振り
割り振られる NAT IP の数は、NAT 構成でエフェメラル IP または静的 IP を使用するかどうかによって異なります。詳細については、Cloud NAT の制限の 1 ゲートウェイあたりの NAT IP アドレス数をご覧ください。
エフェメラル IP
エフェメラル IP を使用したデフォルトの NAT 構成では、ターゲット バックエンドへの接続に一意の送信元ポートを提供するために、必要に応じて IP が自動的に割り振られます。
静的 IP
ターゲット バックエンドの IP を許可リストに登録するために静的 IP が必要な場合は、Apigee インスタンス用に IP を手動で予約します。
バックエンド IP とポートの一意の組み合わせ
一意のターゲット バックエンド IP とポートの組み合わせの数を増やすことで、TPS を増やすことができます。ターゲットのバックエンド IP とポートのそれぞれに対して、同じ NAT IP とポートを使用できます。これにより、許可リストに登録する必要がある IP を追加しなくても、NAT IP を追加した場合と同じ結果が得られます。
一意のターゲット バックエンド IP とポートのペアを作成するには、IP またはポートが異なっている必要があります。たとえば、1 つの IP アドレスを持つロードバランサを 1 つ用意し、4 つの異なるポートをリッスンすることで、Apigee 用に 4 つの一意のバックエンド IP とポートの組み合わせを作成できます。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-19 UTC。"],[[["\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."]]
