IBM Cloud VPC: Routing Private Subnet Traffic Through a NAT Gateway

You provisioned a VSI in a private IBM Cloud VPC subnet, but the instance cannot reach public endpoints for package updates or external API calls. Assigning a floating IP to every instance works, but it exposes each interface to inbound traffic and complicates allow-listing on external services. The practical alternative is to route the subnet through a NAT gateway so instances share a single outbound address while remaining unreachable from the internet by default.

The useful takeaway: use a NAT gateway when private-subnet workloads need outbound internet and you want a stable public IP for external firewalls. Use a public gateway instead when you only need simple zonal egress and do not require a fixed outbound address.

Public Gateway Versus NAT Gateway

A public gateway is a zonal VPC resource that gives a subnet outbound internet access without per-instance floating IPs. It is an egress path, not a security boundary, and the outbound address is not guaranteed to remain fixed. A NAT gateway is a dedicated gateway resource attached to a specific public floating IP. Traffic from instances in the subnet is translated to that IP as it leaves the VPC, which makes it easier to allow-list your VPC in external systems. Both options require a route in the subnet routing table that sends default traffic to the gateway.

When to choose each

• Public gateway: lower complexity, no additional gateway hourly charge, suitable for general patching and updates where the outbound IP does not matter.
• NAT gateway: fixed outbound IP, better for allow-listing third-party APIs, charged hourly plus data-processing fees, and deployed per zone.

Worked Example: Route a Private Subnet Through a NAT Gateway

Run these commands in the IBM Cloud CLI after targeting the correct account and region. You need networkAdmin platform access or an IAM policy with VPC network permissions. Replace every placeholder with your own resource IDs, and verify flag names in the current IBM Cloud CLI reference before running.

# Create the NAT gateway in the same zone as the subnet
ibmcloud is nat-gateway create &NATF_GATEWAY_NAME \
  --vpc &VPC_ID \
  --zone &ZONE \
  --resource-group &RESOURCE_GROUP_ID \
  --floating-ip &FLOATING_IP_ID

# Add a default route to the subnet routing table
ibmcloud is routing-table-route-add &ROUTING_TABLE_ID \
  --destination 0.0.0.0/0 \
  --target-type nat_gateway \
  --target &NAT_GATEWAY_ID

Expected checks:

• ibmcloud is nat-gateway &NAT_GATEWAY_ID returns status available.
• The subnet routing table lists a route for 0.0.0.0/0 targeting the NAT gateway.
• From a VSI in the subnet, curl -I https://example.com succeeds, and curl ifconfig.co returns the NAT gateway's floating IP.

Risk: creating a NAT gateway starts billing immediately. If the route points to a gateway in a different zone than the subnet, traffic may fail or traverse zone boundaries unexpectedly.

Limitation: Zonal Scope and Cost

An IBM Cloud VPC NAT gateway is zonal. If your subnet spans multiple zones, a single NAT gateway in one zone does not automatically serve instances in another zone. You typically need a NAT gateway per zone and routing-table entries that direct each zone's subnet to its local gateway. There is no automatic failover between NAT gateways, so plan for capacity and test the path from each zone.

To verify the result after deployment, log in to a VSI in the private subnet and run:

curl -s https://ifconfig.co/json

The ip field should match the floating IP attached to the NAT gateway. If it returns the VSI's private IP or an error, the default route is missing or the gateway is not yet available.

Removing the Gateway

Because this operation changes state and incurs cost, remove it when no longer needed. First delete the default route from the routing table, then delete the NAT gateway. Deleting the gateway releases its floating IP unless you detach and retain it first.