A VPC NAT Gateway connects multiple Linodes to the public internet using shared public IPv4 addresses, while automatically blocking unsolicited inbound traffic.

• NAT Gateways use shared ports, allowing multiple Linodes to use a single public IPv4 address (a one-to-many NAT setup). This reduces the need for individual public IP assignments.
• Linodes using NAT Gateway can initiate connections to the public internet and receive responses. Devices on the public internet can't initiate connections to these Linodes unless NAT hole punching is used.
• NAT Gateway objects are assigned to VPC subnets, not individual interfaces. All Linodes in a subnet with an associated NAT Gateway use it for outbound connectivity unless 1:1 NAT is enabled on their interfaces.

Portset allocation

A NAT Gateway divides the available outbound ports on a public IPv4 address into equal-sized, isolated blocks called portsets. Each VPC interface on the subnet using the NAT Gateway for outbound traffic receives a unique portset.

When a Linode VPC interface is assigned the portset, for example 4096–8191 on IP address 46.128.8.128, it uses ports from that range to establish new outbound connections.

The number of interfaces a single public IP can support depends on your configured portset size. By default, each public IP assigned to a NAT Gateway supports up to 15 VPC interfaces.

Address allocation modes

NAT Gateway offers two modes for managing public IPv4 addresses; autoscaling (default) and manual.

Autoscaling mode (Default). The NAT Gateway automatically allocates additional public IPv4 addresses as needed to support more Linodes, up to a defined limit (default: 20 IPs). This helps prevent provisioning deployment failures when adding new workloads to a subnet. The gateway provisions an initial IP address when the first VPC interface is created in the subnet, and scales back down as interfaces are deleted. An IP address is automatically released whenever all of its assigned portsets are completely freed. If all interfaces in the subnet are deleted, the gateway scales down to zero IPs. Use autoscaling when your workflows do not require static egress IPs.

• Example - Autoscaling enabled. A cluster with 60 nodes is deployed inside a VPC subnet connected to a default NAT Gateway with autoscaling enabled. The platform automatically assigns four public IP addresses to provide enough portsets, supporting up to 60 nodes (15 nodes per IP address at the default 4,096-port size). When the cluster scales out to 100 nodes, the NAT Gateway dynamically allocates three more public IP addresses, bringing the total to seven and increasing capacity to 105 nodes. As a result, the deployment continues without interruption.

Manual scaling mode. You can manually assign reserved public IPv4 addresses to a NAT Gateway when fixed egress IPs, such as those required for allowlisting on firewall rules, are needed.

• Example - Manual IP assignments (static IPs). A cluster with 60 nodes is deployed inside a subnet connected to a static NAT Gateway configured with four fixed public IP addresses, supporting up to 60 nodes. When a request is made to scale the cluster to 100 nodes, the platform rejects the operation because the NAT Gateway has reached its capacity. To resolve this, manually reserve and assign three additional public IP addresses to the NAT Gateway, increasing the total capacity to 105 nodes. After updating the configuration, the cluster expansion completes successfully.

Subnet migration and IP recycling

Autoscaled NAT Gateways can be moved dynamically from one subnet to another. For example, if a subnet supporting 60 nodes has its NAT Gateway detached, the gateway automatically releases its active load and scales down to zero public IP addresses. As a result, instances in that subnet immediately lose external network access.

When that same NAT Gateway is subsequently attached to a different subnet containing 65 nodes, it provisions 5 new public IP addresses to support the new compute workloads. These IP addresses are freshly allocated out of the available infrastructure pool and may differ from the addresses previously used, ensuring efficient IP recycling.

1:1 NAT vs NAT Gateway

1:1 NAT provides IPv4 connectivity within the VPC and allows you to assign additional public IPv4 addresses to Linodes in the VPC. This setup gives each configured Linode its own public IPv4 address, which is used only by that Linode. Unless restricted by Cloud Firewall, the Linode is accessible from the public internet at this address.

NAT Gateway offers another way for Linodes in a VPC to access the public IPv4 internet. With NAT Gateway:

• Multiple Linodes in the VPC can share the same public IPv4 address (“one-to-many NAT”).
• Linodes using NAT Gateway can start connections to the public internet and receive responses, but devices on the public internet can't start connections to these Linodes unless NAT hole punching is used.

Ports, connections, and portset exhaustion

When a Linode in a VPC subnet sends outbound traffic through a NAT Gateway, the gateway translates the private IP address and port into a public IP address and allocated source port.

A NAT Gateway tracks connections using the 5-tuple: protocol, source IP and port, and destination IP and port. Each unique 5-tuple creates a new connection entry, so a single public IP address can support thousands of simultaneous connections across different destinations.

For example, if a NAT Gateway allocates a portset of 4,096 ports to a VPC Linode, the Linode can establish up to 4,096 simultaneous connections to 203.0.113.111 on port 80 (HTTP). It can also establish another 4,096 simultaneous connections to 203.0.113.111 on port 443 (HTTPS), because the destination port is different. In addition, it can establish another 4,096 simultaneous connections to 203.0.113.222 on port 80 (HTTP), because the destination IP address is different.

Portset exhaustion

Portset exhaustion happens when a Linode exceeds its limit of simultaneous connections to the same destination IP address, port, and protocol. When this occurs, new connection attempts to that specific destination endpoint fail or time out, while connections to other destination IP addresses or ports continue working normally.

To help prevent port exhaustion:

• Choose a portset size that matches your connectivity requirements and increase it if needed.
• Ensure TCP connections close properly so they can time out quickly. UDP connections can't be closed and time out after a period of inactivity.
• If you have very high connection requirements, use 1:1 NAT with a dedicated public IP for your Linode.

Availability

Available in most data centers with VPC.

Pricing

NAT Gateways are available at a flat hourly rate. Learn more.

Pricing for reserved IPs, public IPs and egress fees are separate from NAT Gateway.

📘

BETA Pricing

Auto-scaled IP addresses are provided at no extra charge during BETA and will incur standard billing upon General Availability.

Technical specifications

• Out of 65,536 total ports per public IPv4 address, ports 0–1023 (1,024 total) are reserved by the platform, leaving 64,512 usable ports available to assign across interfaces.

📘

The maximum portset size allowed is 16384. Larger sizes (e.g., 32,768) would only allow a single interface behind the NAT, at which point 1:1 NAT should be used instead.

Limits and considerations

• NAT Gateways work with Linodes using Linode interfaces. This feature is not supported when using legacy configuration profile interfaces.
• NAT Gateway is supported for LKE Enterprise (LKE-E) deployed within a VPC. Standard LKE does not currently support VPC networking or NAT Gateways.
• NAT Gateways is currently in Beta. Review the following operational constraints before deploying in production:
  • Autoscale IP Limit: Autoscaled NAT Gateways can provision up to 20 public IPv4 addresses by default. Higher limits may be approved on a case-by-case basis, subject to applicable conditions. Contact Customer Support to request a limit increase.
  • IAM permissions: Full NAT Gateway functionality is supported for unrestricted account users and IAM Service Accounts. However, restricted users may encounter limitations when creating, configuring, or viewing NAT Gateways.
  • High-Throughput & DDoS Protection: NAT Gateway Beta is designed for lower-throughput outbound traffic, such as API access and IP allowlisting. Traffic from a single public IP that exceeds monitored thresholds may trigger automated DDoS detection or mitigation safety measures. Customers with higher-throughput requirements should continue using 1:1 NAT during Beta.
  • Portset sizes: This Beta release supports portset sizes of 4096, (up to 15 nodes per IP), 8192 (up to 7 nodes per IP), and 16384 (up to 3 nodes per IP).
  • Terraform and CLI: Terraform and CLI support is not available during Beta. You can configure and manage NAT Gateways using Cloud Manager, and the Linode API.

Developer resources

• Linode API provides the ability to programmatically manage the full range of services on Akamai Cloud.
• Linode CLI is a wrapper around the Linode API that lets you manage your account and resources from the command line. Learn how to use the Linode CLI.
• Terraform is an Infrastructure-as-code tool that includes management features for various types of Akamai Cloud resources. Use Akamai's official Terraform Provider to provision Linode environments and to Create a NodeBalancer with Terraform. To learn more about Terraform see our documentation library’s Terraform section.