Lower NAT and outbound traffic costs on Oracle Cloud

Why this matters

Outbound traffic on Oracle Cloud rarely arrives as one big line. It shows up as NAT gateway hours, NAT data processing, and internet egress from private subnets. A team adds a VCN for a new app and gives it a NAT gateway, then forgets it. Another team sends backups and package updates over the internet because the route table has no service gateway rule. The bill grows in small pieces.

The NAT gateway is easy to leave alone. It has no public address to scan, so nobody looks at it. But every private subnet that needs a patch, a container image, or an API call can push traffic through it. If the same traffic repeats, caching or a private path to Oracle services cuts both egress and NAT processing.

This guide focuses on the NAT layer and the outbound path, not on general storage or database tuning. You will map what leaves your VCN, move Oracle service traffic to the service gateway, remove duplicate NAT gateways, and put alerts on the remaining egress.

Before you start

Get read access to the compartments that hold your VCNs. You need to see route tables, subnets, NAT gateways, internet gateways, service gateways, dynamic routing gateways, and public IPs. In the Console, the Networking area shows these per VCN. Also open Cost Analysis, Monitoring, Logging, and Budgets.

List every VCN and its owner. Mark which ones are production, staging, sandbox, and shared services. For each private subnet, write down what it calls: Oracle Object Storage, OCI Container Registry, an external SaaS API, package mirrors, or a partner endpoint. Ask application owners about fixed IP allowlists, because moving egress changes the source address.

Pick a nonproduction VCN first. Enable VCN Flow Logs on a subnet or VNIC and send them to a log group. Flow logs have their own storage and processing cost, so scope the capture to the subnets you suspect. Set a short retention for the test. Tell the team that route changes can break running jobs, and agree on a window.

How to do it

Start with evidence, not a cleanup. Turn on flow logs for a day or a week, then query the top source addresses and destinations. Use Cost Analysis to see which compartments and NAT gateways are moving data. Compare the two views: the flow log shows the app, and Cost Analysis shows the charge.

Next, fix the path for Oracle services. A service gateway keeps traffic to supported Oracle services inside the VCN's private network. It does not pass through the NAT gateway, and it does not need a public IP. Add the route rule and the security rule, then test from one host before you roll it out.

Then reduce the number of NAT gateways and the traffic that needs them. Consolidate where it is safe, move outbound-only hosts behind a proxy if caching helps, and remove public IPs from hosts that only need outbound access. Each change should have a rollback route table.

1. Map every outbound path. List each private subnet, its route table, and the NAT gateway it uses. Mark which destinations are Oracle services and which are public internet endpoints. This map becomes your change list.
2. Turn on flow logs and NAT metrics. Enable VCN Flow Logs on the busiest private subnets and send them to OCI Logging. Check the NAT gateway metrics in Monitoring at the same time. Use a short retention window so the test stays cheap.
3. Send Oracle service traffic to the Service Gateway. Add a route rule for the Oracle Services Network through the service gateway. Add the matching security rule, then test from one host. Confirm that the traffic no longer shows up as NAT egress.
4. Remove unused NAT gateways. Find NAT gateways with low hours and no active route tables after the service gateway change. Update any remaining routes, then delete the idle gateway. Check for staging and sandbox VCNs that nobody owns.
5. Consolidate egress in a hub VCN. Route selected VCNs through a shared hub only when the saved gateway hours beat the added routing cost. Test latency and failover before production. Keep separate gateways for teams that need isolated blast radii.
6. Add a caching proxy for repeated pulls. Put a caching proxy in the hub VCN for package managers and container image pulls. Point build agents and batch jobs at the proxy. Measure cache hits before you remove direct egress.
7. Replace public jump hosts with OCI Bastion. Move administrative access to OCI Bastion and remove public IPs from hosts that only need outbound access. Confirm that monitoring agents still report. This cuts exposure and can remove a NAT path.
8. Set budgets and route alerts. Create a budget for each compartment that owns a NAT gateway. Add alerts on outbound data transfer and NAT data processed. Send them to the team that can change the route table, not only to finance.

How to check it worked

Use Cost Analysis with a daily view, filtered to the compartments you changed. Group by service and by tag. Look at NAT gateway hours, NAT data processed, and outbound data transfer separately. A drop in one line with a rise in another is not a win.

Check Monitoring for the NAT gateway metrics. Bytes out should fall after service gateway and proxy changes. If hours stay flat but data falls, you still have idle gateways. If data falls but hours do not, remove the gateway or change the design.

Run a flow log query for the top ten sources and destinations again. Confirm that Object Storage and other supported Oracle services now show the service gateway path, not a public address. Check that no instance gained an unexpected public IP. Keep the dashboard for a month and review after each release.

Mistakes to avoid

Do not delete a NAT gateway before you update every route table that points to it. A blackhole route breaks package updates, backups, and monitoring agents at the same time. Change the route to the new gateway first, test, then delete the old one.

Do not treat the NAT gateway as a firewall. It hides private addresses, but security lists and network security groups still control traffic. A flat private subnet with open egress can still reach anything on the internet. Use NSGs and a proxy allowlist for outbound control.

Do not consolidate every VCN into one NAT without measuring the new path. Cross-VCN traffic may cross a dynamic routing gateway or local peering, which adds configuration and possibly charges. A single gateway can also become a bottleneck or a single failure domain for teams that need separate blast radii.

If you want a second set of eyes, the Cloud cost audit is $4,500/month, fixed scope, and includes an egress review. It is one option. Internal cleanup or a narrow network review may fit better.

Frequently asked questions