Service Gateway and NAT on OCI: Choosing the Right Egress Path

Every workload on OCI eventually needs to reach something outside its own subnet. It might pull a software update from the internet, write a backup to Object Storage, or call another OCI service. How that traffic leaves the subnet is decided by which gateway you attach and how you route to it, and the choice affects security, performance, and cost. Pick the wrong gateway and you either expose resources you meant to keep private or pay for traffic that could have stayed on the OCI network for free. This guide explains the three egress gateways and how to choose between them.

These gateways are part of the wider network fabric, so start with the pillar guide to OCI networking. The subnets that route to them are covered in designing subnets on OCI, and the routing hub that connects to other networks is in the DRG explained.

The three gateways at a glance

OCI offers three gateways for traffic leaving a VCN toward the internet or toward OCI services. Each serves a distinct purpose, and a typical VCN uses more than one.

The internet gateway

The internet gateway provides two way connectivity between a public subnet and the internet. Resources that use it need a public IP address. It is the right choice for things that must be reachable from the internet, such as a public load balancer. It is the wrong choice for anything that only needs outbound access, because giving a resource a public IP and inbound reachability when it does not need them widens the attack surface for no benefit.

The NAT gateway

The NAT gateway lets resources in a private subnet reach the internet for outbound traffic only, without having a public IP and without being reachable from the internet. This is the standard pattern for application servers that need to pull updates or call external services but should never accept inbound connections. The NAT gateway gives them the outbound reach they need while keeping them private, which is exactly what most workloads should have.

The service gateway, the one that saves money

The service gateway is the most overlooked of the three and often the most valuable. It provides private access from your VCN to OCI services such as Object Storage, without the traffic ever traversing the internet. This matters for two reasons. First, security, because the traffic stays on the OCI network rather than going out and back through a NAT or internet gateway. Second, cost, because traffic to OCI services through a service gateway avoids the metered egress that internet bound traffic can incur. A workload that backs up heavily to Object Storage through a NAT gateway instead of a service gateway can run up avoidable charges.

A decision framework

1. Does the resource need to accept inbound connections from the internet? If yes, it belongs in a public subnet with an internet gateway. Keep this set as small as possible.
2. Does it need outbound internet access but no inbound? Put it in a private subnet and route internet bound traffic through a NAT gateway.
3. Does it talk to OCI services such as Object Storage? Route that traffic through a service gateway so it stays private and avoids egress charges.
4. Does it only talk to other internal networks? It may need no internet gateway at all, only a DRG route to the other networks.

Most private workloads end up with both a NAT gateway for general outbound traffic and a service gateway for OCI service traffic, with no internet gateway at all. That combination is secure and cost efficient, and it should be the default you reach for.

Routing ties it together

Attaching a gateway is only half the job. The subnet route table has to direct the right traffic to the right gateway. A default route can send all internet bound traffic to the NAT gateway, while a route for the OCI services range sends that traffic to the service gateway. Getting these routes right is what actually realises the security and cost benefits, so design them deliberately. For the wider cost picture of network traffic on OCI, see OCI networking cost.

Common mistakes

• Giving resources public IPs and internet gateways when a NAT gateway would meet their outbound only needs more safely.
• Sending OCI service traffic through a NAT gateway and paying egress charges that a service gateway would avoid.
• Attaching a gateway but forgetting the route table entry, so the traffic never reaches it.
• Leaving an internet gateway attached to a subnet that has no need to be reachable from the internet.

If you want an egress design that is secure and cost efficient from day one, our team sets these up as part of OCI networking and cost optimization engagements. See the OCI networking solution and the pillar guide to OCI networking for the full context.