SNAT — Outbound Access

SNAT (Source NAT) gives instances in your VPC a path to the internet without requiring each one to have its own public IP address. When outbound traffic leaves a covered subnet, the NAT Gateway replaces the private source IP with one of its Elastic IPs before forwarding the packet. Return traffic is automatically delivered back to the originating instance.

Typical Use Cases

Package and dependency installation. Instances in a private subnet need to pull from package managers (apt, yum, pip, npm) or container registries. SNAT gives them that connectivity without exposing them to inbound traffic.

Calling external APIs. Backend services that call third-party APIs, payment processors, or data providers need outbound internet access. With SNAT, that access is routed through a controlled set of EIPs, making IP whitelisting easy to manage.

Software and security updates. Any instance that needs to receive OS or software updates from public mirrors requires outbound internet connectivity. SNAT handles this cleanly across all instances in a subnet without individual EIP allocation.

Batch and data pipeline jobs. Workers that pull data from external sources or push results to cloud storage (S3, GCS, etc.) benefit from the high-throughput, shared-EIP model that SNAT provides.

How It Works

When an instance in a SNAT-covered subnet sends a packet to an internet destination:

  1. The packet hits the VPC route table. If the source subnet is covered by the NAT Gateway, the default route (0.0.0.0/0) points to the gateway.

  2. The gateway checks its SNAT entries. If the source subnet or source CIDR matches an entry, it replaces the private source IP with one of the EIPs in that entry, assigns an ephemeral port, and records the mapping.

  3. The packet goes out to the internet with a public source address.

  4. When the remote server replies, the gateway matches the reply to the connection record and delivers it to the original private instance.

SNAT Flow

SNAT Entries

A SNAT entry defines which private sources use the gateway for outbound traffic and which Elastic IPv4 address carries that traffic. The console's NAT Rules tab lists each entry with the following fields:

Field
Description

SNAT entry ID

System-assigned identifier for the entry.

Source subnets

One subnet, multiple subnets, or all.

Source CIDRs

One or more source address ranges. Use 0.0.0.0/0 only when every source routed to the gateway should be eligible for SNAT.

Elastic IPv4 addresses

One or more EIPs used as outbound source addresses for matching traffic.

You can create multiple SNAT entries on one gateway. Source scopes must not overlap in a way that creates ambiguous SNAT behavior; overlapping entries are rejected.

Scaling Egress Capacity with Multiple EIPs

The platform supports a large number of concurrent connections per EIP, so a single EIP handles most workloads comfortably. For horizontal scaling or workload isolation, you can bind additional EIPs to the gateway and include them in the SNAT entry, or split sources across multiple non-overlapping entries.

Reasons to spread traffic across multiple EIPs:

  • More simultaneous outbound connections across the gateway.

  • Separate egress addresses for different environments (e.g., production vs. staging CIDRs) that need distinct IP whitelisting upstream.

Last updated