How to reduce data transfer costs on Oracle Cloud

Why this matters

Data transfer on Oracle Cloud is easy to miss because it does not live with compute. Inbound traffic is free, so the first bill looks fine. The charges show up later on outbound paths: internet egress through an internet gateway or NAT gateway, traffic between regions, and some traffic from managed services.

The usual cause is a path nobody owns. A team adds a NAT gateway for package updates. Another team puts a public IP on an API. A backup job copies buckets to a second region for safety. Each choice is reasonable on its own. Together they turn into a line item that grows with usage and is hard to trace back to a person or an app.

You can fix a lot without changing what the product does. Route Oracle service traffic through a service gateway. Keep chatty services in one region. Compress responses. Stop copying data you do not need to copy. The work is mostly routing and placement, which means it sticks once you set it up.

Before you start

Get access to Cost Analysis and Usage Reports in the OCI Console. You need permission to view compartments, VCNs, route tables, gateways, and budgets. If you cannot see a compartment, ask for read access first. Read-only access is enough for the review.

Draw the current paths. List each VCN, its subnets, internet gateways, NAT gateways, service gateways, dynamic routing gateways, local peering, remote peering, and any FastConnect or VPN. Mark which workloads talk to the internet, to other regions, to on-premises, and to Oracle services such as Object Storage.

Pick a baseline window that matches a normal week. Note releases, month-end jobs, and backup schedules so you do not compare a quiet week with a busy one. Tell app owners what you are doing. Route changes are small, but a wrong route rule can break egress or make private traffic fail.

Decide on a tagging scheme before you touch routes. Cost-tracking tags on gateways, buckets, and compute let you group spend by app later. Without tags, you get a total and no owner.

How to do it

Start with the flows you can see, then change the route for the biggest one. Cost Analysis shows the total and the service. Flow logs show the source, destination, port, and action. Use both, because a cost line does not tell you which subnet caused it, and a flow log does not tell you the charge.

Service gateway changes are the safest early win. They remove traffic from NAT gateways and keep it on the Oracle network. Cross-region replication and external API calls need a different fix: move the job, compress the payload, or accept the cost with a budget alert.

1. Tag gateways and buckets by owner. Apply cost-tracking tags to NAT gateways, internet gateways, dynamic routing gateways, Object Storage buckets, and the compute that drives the traffic. Use the same app and cost center keys across compartments. Cost Analysis can then group data transfer by team instead of showing one large total.
2. Build a baseline in Cost Analysis. Filter to networking and data transfer charges and group by region, compartment, and tag. Export a Usage Report CSV for the same period and keep it. You will compare against this file after the changes.
3. Trace the top flows with VCN flow logs. Turn on flow logs for the subnets that handle outbound traffic. Look for repeated destinations, large byte counts, and traffic that leaves through a NAT gateway when it could stay private. Capture a day or a week, not a few minutes.
4. Add a service gateway to each VCN. Create a service gateway and add a route rule for the Oracle Services Network. Point Object Storage and other supported OCI service traffic at it, and leave internet traffic on the NAT or internet gateway. Keep the default route for internet traffic and add the service route for OCI destinations.
5. Move internal calls to private endpoints. Use private IPs and private endpoints for service-to-service calls, including Object Storage private endpoints where you need them. Remove public IPs from workloads that only serve other workloads in the same VCN. Public egress is for users outside your network, not for your own API tier.
6. Keep chatty workloads in one region. Place app servers, caches, and databases that talk often in the same region, and use regional subnets and local peering where they fit. Cross-region calls add latency and billable traffic. If a workload must be split, cache the data it repeats and batch the rest.
7. Compress and cache outbound responses. Turn on HTTP compression at the load balancer or web server for JSON and text. Cache static assets and repeat API responses close to the user. Compare the cost of a CDN or cache tier against the origin egress it removes before you add one.
8. Review replication and backup targets. List every cross-region bucket replication, database backup copy, and image sync. Keep copies in the same region unless a recovery plan needs them elsewhere. For the ones you keep, set a schedule and retention that match the plan, not a default that copies everything.
9. Set a budget and alert on egress. Create a budget on the cost-tracking tag or compartment that holds the traffic. Add alerts at your own thresholds so a spike reaches the owner before the invoice does. Review the alert monthly and adjust the threshold as usage changes.

How to check it worked

Open Cost Analysis for the same filters you used in the baseline and compare the outbound data transfer line items. Look at the trend, not one day. If the total fell, check that the traffic did not simply move to another line, such as a cross-region charge or a managed service.

Use flow logs to confirm the top talkers now go where you expect. Object Storage calls from private subnets should show the service gateway path, not a NAT gateway. If you see the old path, check route tables and the subnet that hosts the workload.

Where Monitoring exposes gateway metrics, chart bytes in and out for the NAT gateway and internet gateway. A flat line after a service gateway change is the result you want. Check the budget alert history after the first cycle and make sure the message reached a person who acts on it.

Mistakes to avoid

Expecting the service gateway to cover everything. It handles same-region traffic to supported Oracle services. It does not cover the public internet, other regions, or your data center. Traffic to a partner API still leaves through a NAT or internet gateway and is billed as egress.

Assuming FastConnect is always cheaper. FastConnect gives you a private path and predictable routing, but the port and cross-connect have a cost, and egress still applies. Compare it with internet egress for your actual volume. Do not move a small, steady flow to a dedicated circuit without checking.

Leaving public IPs on internal services. A public load balancer in front of an internal API is a common cause of avoidable egress. Use a private load balancer or private IP. Reserve public entry points for traffic that must come from outside.

Forgetting managed service and third-party traffic. Logs shipped to an external SIEM, monitoring agents, container image pulls from public registries, and email APIs all leave the network. Put them on the same tag and budget as the rest. If you want a second set of eyes, the Cloud cost audit from Cloudverg is a fixed-scope review at $4,500/month, and it can sit beside your own review or a consultant's.

Frequently asked questions