Most cloud costs are visible the moment you provision them. Egress is not. It is charged on data leaving, accrues from traffic patterns rather than from anything you switched on, and it is the line most likely to surprise a team that watched everything except the network.
Compute, storage, and database costs all share a comforting property, you decide to incur them when you provision the resource, so they are at least visible to the person who created them. Egress is different. Nobody provisions egress. It accrues from how data moves, from an application that chats more than it needs to across regions, a backup that replicates to another continent, a reporting job that pulls large data sets out to an on premises tool. The traffic was a side effect of a design decision made for other reasons, and the cost arrives later, attached to no obvious switch anyone can point to. This is why egress is the cost that surprises teams most, and why controlling it is more about architecture than about configuration. This guide explains how OCI charges for network traffic and the choices that keep that traffic, and its cost, under control.
The principle to internalise is that data movement is charged asymmetrically and by direction relative to OCI and to the wider internet. Data coming in is generally not charged. Data going out to the internet, egress, is charged beyond a monthly allowance. Traffic between regions is charged. Traffic within an availability domain is the cheapest, and traffic that stays inside OCI on the private network is far cheaper than traffic that leaves to the internet. The exact allowances and rates are explained alongside the rest of the pricing model in How OCI Pricing Actually Works, and OCI is widely noted for a more generous egress allowance than some other providers, a point that features in OCI vs AWS Cost Comparison. But generous is not free, and at scale egress is real money.
| Traffic pattern | Relative cost | Implication |
|---|---|---|
| Inbound to OCI | Generally free | Ingesting data is cheap |
| Within an availability domain | Lowest | Keep chatty components close |
| Between regions | Charged | Replicate deliberately, not by default |
| Out to the internet | Charged beyond allowance | The line that surprises teams |
Egress surprises because it is invisible at provisioning time and only appears in the bill after the traffic has flowed. A team designs an architecture that, quite reasonably, places a service in one region and its data in another, or routes user traffic out through a path that crosses a charged boundary, and the design works perfectly. The cost of all that crossing only becomes apparent at the end of the month, by which point the traffic has already happened. Unlike an over provisioned instance, which you can see is too big the moment you look at it, egress leaves no standing artefact to inspect. You have to look at the flow, not the inventory, which is a different and less familiar discipline, and the reason egress is the classic contributor to the bill shock discussed in Avoiding OCI Bill Shock.
Because egress follows traffic, the levers are architectural. The biggest is data locality, keeping data close to the things that use it so that the chatty traffic between an application and its data stays within the cheapest boundary rather than crossing a charged one. An application in one region querying a database in another generates charged cross region traffic on every query, and the cost scales with how chatty the application is, which can be considerable. Placing the application and its data in the same region, ideally the same availability domain for the busiest paths, removes that cost entirely. The second lever is replication discipline, replicating data across regions only where the durability or recovery requirement genuinely justifies it, rather than as a reflexive default, because cross region replication is a continuous egress cost.
Traffic that can stay inside OCI should stay inside OCI, because the private network is far cheaper than routing out to the internet and back. Services that need to talk to OCI services, such as object storage, can do so over a private path rather than over the public internet, which avoids the egress charge that the public route would incur. Designing the network so that internal communication uses private connectivity, and only genuinely external traffic leaves to the internet, is one of the larger structural savings available, and it is invisible unless someone looks at how the traffic is actually routed. The same principle governs hybrid connectivity to on premises, where a dedicated connection can be both cheaper and more predictable than internet egress for sustained, high volume traffic.
Large one off data movements, migrations, bulk exports, and the like, can generate substantial egress if they leave OCI, and they are worth planning rather than running blind. Backups that replicate across regions are a continuous egress cost wearing the clothes of data protection, and they should be sized to the recovery requirement rather than applied to everything, a point that connects directly to OCI Storage Cost Optimization because storage and network cost are entangled. A replication policy chosen for durability without regard to its egress cost can produce a network bill that exceeds the storage it protects, which is the kind of imbalance that only surfaces when someone looks at both lines together rather than each in isolation.
Because egress is invisible by default, the first control is simply to make it visible, to break network cost out in the cost reporting so that it can be seen, attributed, and questioned. A team that can see its egress cost rising will ask why, and the why is usually a traffic pattern that can be redesigned. A team that cannot see it has no way to act. This is why network cost belongs on the cost dashboard alongside compute and storage, and why the standing cost review should look at the network line specifically, because it is the line most likely to grow quietly. Visibility does not lower egress on its own, but it is the precondition, because you cannot redesign a traffic pattern you cannot see.
Network and egress cost is one of the harder areas to optimise because it requires looking at traffic flows rather than resource inventories, which is exactly why it is so often left unexamined. Our Cost Governance work makes network cost visible in the reporting, identifies the cross region and internet bound traffic patterns that drive egress, and recommends the architectural changes, data locality, private routing, and disciplined replication, that lower it at the source. Because egress is entangled with storage, replication, and architecture decisions made for other reasons, we look at it in the context of the whole design rather than as an isolated line, which is the only way the structural savings become visible.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.