Cloud egress costs are the line on a cloud bill that nobody budgets for and almost everybody eventually asks about. They rarely dominate an invoice, which is why they go unexamined; they grow steadily, which is why they eventually get noticed; and by the time anyone asks where they come from, the answer is usually an architecture decision made a year earlier by somebody who was thinking about resilience, performance or convenience and not about where the bytes would travel.
The underlying cause is an asymmetry most buyers never have explained to them. Getting data into a cloud platform is generally free. Moving it between regions, between networks, through certain gateways, or out to the internet is metered, per gigabyte, at rates that vary by path. That means the cost of a workload depends not only on what it does but on the route its traffic takes — and route is a design property that is easy to change on paper and expensive to change once systems depend on it.
This guide covers how data transfer is actually priced, using Azure as the main reference with comparisons where other platforms differ; the topology choices that create unnecessary hops; caching and content delivery that reduce repeat transfer; how to read a bill to find where transfer charges originate; and the exit costs that become relevant if you ever want to move. The broader discipline of controlling cloud spend is covered in our guide to preventing Azure bill shock, where data transfer appears as one of the categories that moves without warning.
Why data transfer charges catch UK businesses off guard
Four features of the pricing model combine to make transfer costs surprising.
The cost follows the path, not the activity. The same gigabyte costs nothing moving between two virtual machines in one virtual network, a small amount crossing a peering connection, more crossing between regions, and more again leaving to the internet. Two identical applications can have very different transfer bills depending on where their components sit relative to each other and to their users.
Several meters apply to one journey. A packet travelling from a spoke network through a hub firewall and out through a NAT gateway may incur peering charges in each direction, firewall data processing, NAT gateway processing and internet egress — four meters for one flow. Nobody designs for that total because nobody sees it as one cost.
Decisions made for good reasons have transfer consequences. Replicating to a second UK region for resilience, routing all traffic through a central firewall for inspection, serving files from storage rather than a cache, sending backups to another region — each is a defensible choice, and each creates a recurring transfer cost that scales with data volume rather than with anything the business would recognise as usage.
The charges land in unhelpful places on the bill. Transfer costs appear under service names like bandwidth, virtual network, NAT gateway or private link, frequently not attributed to the application that caused them. Finance sees a networking line growing; nobody can say which system it belongs to.
For UK organisations specifically, there is one structural driver worth naming. Data residency requirements commonly lead to using the UK South and UK West regions as a pair, with replication between them for resilience. That is often exactly the right decision, and the replication is cross-region traffic billed per gigabyte. Organisations that adopted a UK-paired design for compliance reasons are sometimes surprised that compliance has an ongoing bandwidth cost attached — not a reason to change the design, but a reason to size it.
In Cost Management, filter to the networking-related services — bandwidth, virtual network, NAT gateway, private link, firewall, VPN gateway — set granularity to monthly across the past year, and group by resource. Within a few minutes you will see whether transfer cost is flat, growing, or dominated by a handful of resources. Then group by meter rather than service, because the meter name tells you which path is being charged — inter-region, peering, internet — and that is what points to the architecture decision behind it.
Designed for function against designed with traffic paths in view
The comparison below highlights designing with traffic paths in view. The qualification is that function and resilience come first: an architecture that is cheap to run and fails over badly is not an improvement. The right column is not about minimising transfer at all costs; it is about knowing what each path costs so that resilience and inspection are chosen deliberately rather than paid for by accident.
Designed for function only
Paths are an accident of layout
Designed with paths in view
Each hop has a known cost and reason
The inspection row is the one that most often doubles a transfer bill without anyone noticing. A hub-and-spoke design that routes all spoke-to-spoke traffic through a central firewall sends each flow across two peering connections and through the firewall’s data processing meter. That is frequently the right security decision, and it is a decision with a per-gigabyte price. Knowing the price lets you choose which flows genuinely need inspection and which can take a direct path.
The replication row reflects how often resilience is configured once and never sized. Replicating everything to a second region continuously costs in proportion to the rate of change across the whole estate. Replicating the systems whose recovery objectives require it, at the frequency those objectives require, frequently costs a fraction — and matches the recovery plan better too. We cover how to set those objectives in our guide to Azure disaster recovery and failover.
Where avoidable transfer charges come from
The grid below groups the sources of transfer cost we find in UK cloud estates. Badges reflect how often each produces cost that serves no deliberate purpose, rather than how large the cost is in absolute terms.
The second row of the first card is the one most likely to be both expensive and unintended. It happens when a database is restored into a different region during an incident and never moved back, when a new service is deployed to whichever region the template defaulted to, or when a migration places tiers in different regions for capacity reasons. Every request between those tiers then crosses a region boundary, and an application that makes many small calls between its front end and its database generates a surprising volume of cross-region traffic.
The static asset row reflects the cheapest correction available. Serving images, documents, downloads and scripts from origin storage on every request means paying internet egress for every repeat download. A content delivery network caches those at locations close to users, so most requests never reach origin, and in many cases the CDN delivery rate is lower than origin egress as well.
The visibility card explains why the other two persist. Transfer charges that belong to nobody get reviewed by nobody, and architecture decisions that never consider transfer cost keep producing it. Attribution by tag and a monthly look at networking meters are what turn these from invisible to fixable.
Data transfer costs in UK cloud estates — the numbers
The figures below reflect what we find reviewing Azure estates for UK organisations of 20 to 500 staff, typically with between one and five subscriptions and a mix of migrated and newly built workloads.
The first figure explains why transfer cost is neglected. At six to fourteen per cent of spend it is rarely the largest line, and compute and storage receive the attention. But it is the category most likely to grow without a corresponding decision, because it scales with data volume and rate of change rather than with anything provisioned, and it can jump when a single architectural change — a new replication job, a restored database in the wrong region — starts moving data continuously.
The third figure is the one that makes review worthwhile. Getting on for half of transfer spend in the estates we review serves no deliberate purpose: traffic hairpinning through appliances that do not need to inspect it, tiers split across regions by accident, static content served from origin, replication broader than any recovery plan requires. Unlike compute right-sizing, most of these fixes do not change what the workload does — only the path its data takes.
The fourth figure explains why the third persists. Twelve per cent look at networking meters monthly. Everyone else sees a bandwidth or virtual network line, notes that it has grown, and has no way to say which system caused it.
Where transfer charges actually come from
The chart below shows the composition of data transfer and networking charges across UK Azure estates we have reviewed, by the path or service responsible. Proportions vary considerably with architecture, and the point is to show which categories to check first.
Internet egress leading is expected for anything serving users — websites, file downloads, APIs consumed externally. It is also the category most amenable to caching, because so much of it is the same content requested repeatedly. A content delivery network in front of an origin typically absorbs the large majority of repeat requests, and that single change is frequently the largest available reduction in transfer cost for a public-facing workload.
Cross-region at twenty-two per cent is mostly replication and backup copying, and some accidental split-tier traffic. The deliberate part should be sized to recovery objectives; the accidental part should be eliminated. Telling them apart requires looking at which resources the cross-region meters are attached to.
Firewall processing and peering together at around a quarter are the topology tax. They are not waste in themselves — inspection and segmentation are worth paying for — but they are frequently applied to traffic that does not need them, such as backup streams or replication flows routed through an inspection hub simply because that was the default route. Exempting trusted bulk flows from inspection, where policy allows, is a common and significant saving.
NAT gateway processing is the one people find most surprising, because it charges per gigabyte for traffic leaving through it, in addition to internet egress. Workloads that reach Azure platform services such as storage or databases via their public endpoints through a NAT gateway pay processing on traffic that could have taken a private path instead.
Benchmarks — transfer cost practice against what we find
The figures below show how often each practice is in place across UK organisations running workloads in Azure, at first review.
Adoption of data transfer cost controls in UK estates
The top two figures are reassuring and explain why transfer costs are usually modest rather than alarming: most organisations deploy close to their users and most applications sit in one region. The gaps appear in the middle and at the bottom. Fewer than half cache static content, a quarter have sized replication to need, and fewer than one in ten consider transfer cost before making an architectural change — which is the point at which it is cheapest to influence.
The bulk-flow exemption figure at seventeen per cent is the single change most likely to produce a noticeable reduction in an estate with a central firewall. Backups, replication and large internal transfers between trusted networks frequently pass through inspection only because the default route says so, and each gigabyte incurs firewall processing and two peering charges. Where security policy permits a direct path for those specific flows, the saving is immediate and the security posture for user and internet traffic is unchanged.
Same-region, cross-region and internet: the three prices
Almost every transfer decision comes down to which of three broad price bands a flow falls into, plus whichever processing meters it passes through on the way.
Within a region
Traffic between resources in the same virtual network is not charged. Traffic between peered virtual networks in the same region is charged per gigabyte in each direction — small per unit, but applied twice and to every flow that crosses. Azure has not, at the time of writing, charged for traffic between availability zones in the same region; other providers do, which matters if you are comparing platforms or running multi-cloud. The design implication is that grouping components that talk to each other heavily into the same network removes a meter entirely.
Between regions
Traffic crossing between regions is charged per gigabyte, with rates depending on the regions involved; transfer within Europe, including between the two UK regions, sits at the lower end of inter-region pricing, with transfer between continents higher. Global virtual network peering is charged at a higher rate than regional peering. This band is where replication, backup copies, and accidentally split applications live, and it is the band where deliberate sizing produces the clearest savings.
To the internet
Data leaving the platform to the internet is charged per gigabyte on a tiered basis, with an allowance free each month and the per-gigabyte rate falling as volume rises. This is the most expensive band per unit for most organisations’ volumes, and it applies to everything served to users, everything sent to external services, and everything that leaves when you migrate away. Inbound transfer, by contrast, is not charged, which is why moving data in is cheap and moving it out is the expensive direction.
On top of the band sit processing meters for the services traffic passes through: firewalls, NAT gateways, private endpoints, VPN gateways and others. These are charged per gigabyte processed regardless of whether the traffic is otherwise free, which is how a flow inside a single region can still generate a meaningful cost if it is routed through an appliance. Our guide to multi-site network design discusses the hub costs involved when branches connect through a cloud hub.
A data transfer cost review in six weeks
The sequence below takes an existing Azure estate from an unexplained networking line to an attributed, reduced and monitored one. It deliberately measures before changing anything, because transfer costs are easy to misattribute without data.
The order matters because measurement changes the conclusions. Organisations that act on the bill alone frequently attack the wrong line — reducing a CDN that was saving them money, or removing replication that a recovery plan depended on. Two weeks of flow logs and a meter-level breakdown reliably identify the handful of flows responsible for most of the avoidable spend.
The final ongoing step is the one that changes the long-term trajectory. Transfer cost is cheapest to control at design time and most expensive to change once systems depend on a route. A single question in the change process is what stops the next accidental cross-region dependency from being built.
Transfer cost readiness — where most UK estates sit
Combining the assessment areas gives an indication of how well an organisation understands and controls where its data travels and what that costs. The gauge reflects a first review of a UK Azure estate of moderate size with no previous networking cost review.
A score in the high thirties reflects sensible basic placement — workloads near users, most applications in one region — combined with almost no visibility or deliberate design of the paths between them. Placement scores reasonably. Caching scores moderately. Replication sizing, inspection routing and private paths score poorly. Attribution and monitoring score lowest, because networking cost is the line nobody owns.
As with most cost-control benchmarks in this series, the cheapest improvements are administrative: tagging, a monthly look at networking meters, and a transfer question in the change process. The architectural fixes — private paths, inspection exemptions, replication sizing — take more care but rarely require new spending, and frequently reduce other costs at the same time.
The caveat is scale. A small estate with modest traffic may have a transfer line too small to justify this effort, and the honest recommendation is to set a budget alert on the networking services and revisit if it moves. The work pays back in proportion to data volume and to the number of networks, regions and appliances in the design.
Indicative transfer pricing by path
The table below gives indicative UK-relevant Azure transfer pricing at the time of writing, converted to sterling and rounded, excluding VAT. Microsoft publishes rates in several currencies and adjusts them periodically; enterprise and partner agreements may differ. Treat these as orders of magnitude for comparing paths, and check the current pricing pages and your own agreement before using any figure in a business case.
| Path | Indicative cost per GB | Charged | Note |
|---|---|---|---|
| Inbound data to Azure | Free | No | The asymmetry that makes exit the expensive direction |
| Within a virtual network | Free | No | Group chatty components together to stay here |
| Regional virtual network peering | Around £0.01, each direction | Both inbound and outbound | Doubles for traffic hairpinned through a hub |
| Between regions within Europe, including UK South to UK West | Around £0.015–0.02 | Outbound from source region | The replication and backup band |
| Internet egress after the monthly free allowance | Around £0.05–0.07 at lower volume tiers | Outbound | Falls at higher volumes; the most expensive common band |
The ratios matter more than the exact figures. Internet egress per gigabyte is several times the cost of transfer between UK regions and several times again the cost of regional peering, and transfer within a network is free. That ordering is what drives the design guidance: keep heavily interacting components in one network, cross regions only where resilience requires it, and put a cache between your origin and the internet.
Processing meters — firewall, NAT gateway, private endpoint — sit on top of these and are not shown separately because they depend on the service tier. They are per gigabyte processed and can easily exceed the underlying transfer cost for flows that would otherwise be free, which is why routing is as important as region.
Topology choices that remove unnecessary hops
Most avoidable transfer cost is decided when the network is laid out. The patterns below are the ones we apply most often, and none of them requires giving up segmentation or inspection where those genuinely matter.
Keep chatty components in the same network
Application servers and the databases they query, or services that call each other constantly, should normally sit in the same virtual network, separated by subnets and network security groups rather than by separate peered networks. Subnet boundaries give you segmentation without a per-gigabyte meter; peering boundaries give you segmentation with one, charged in both directions. Reserve separate networks for genuinely separate workloads, environments or trust levels.
Inspect selectively with routing, not universally by default
Route tables decide which traffic goes through the hub firewall. The default in many designs sends everything, including backup streams and replication between trusted networks. Writing routes so that user traffic, internet-bound traffic and flows crossing trust boundaries are inspected, while specified trusted bulk flows take a direct path, keeps the security posture where it matters and removes the double peering and processing charge where it does not. Agree the exemptions with whoever owns security policy and document them.
Place private endpoints where they are consumed
A private endpoint placed centrally in a hub network means every spoke reaching that service crosses a peering connection to get there. Placing the endpoint in the spoke that uses it most, or giving heavy consumers their own endpoint, keeps the traffic local. The private endpoint processing charge remains, but the peering charges on top of it disappear.
Understand what a managed hub does by default
Managed hub services can be configured so that all traffic between connected networks and to the internet passes through a firewall in the hub. That is a powerful way to enforce consistent policy and it applies processing to every flow, which can be a large cost for high-volume internal traffic. If you use one, model the volume that will pass through inspection before enabling universal routing, and use its options to keep trusted bulk traffic off the inspected path where policy permits.
Break out to the internet from the cloud, not via the office
Some hybrid designs route cloud workloads’ internet traffic back through an on-premises firewall over a VPN or private circuit, which pays cloud egress to reach the office and then uses the office circuit to reach the internet. Where policy allows cloud-native inspection, local breakout from the cloud is cheaper and faster.
Put shared services near their consumers
Directory services, DNS resolvers, monitoring collectors and log forwarders are used by everything, so their placement determines a great deal of baseline traffic. A domain controller or log collector in a different region from most of the workloads using it generates steady cross-region traffic that is easy to miss because no single flow is large. Keep shared services in the region where most of their consumers run, and replicate them where you need them in a second region rather than having everything reach across.
Each of these is a layout decision rather than a feature to buy, which is why they are cheapest at design time. Retrofitting them later is usually possible and occasionally disruptive, which is the argument for asking the transfer question before a network is built rather than after its bill arrives.
The number that says how much is avoidable
If one figure decides whether a data transfer review is worth doing, it is the proportion of current transfer spend that serves no deliberate purpose.
Forty-three per cent means that across the estates we review, a little under half of what is spent moving data serves no purpose anyone chose. It is split roughly between three causes: traffic routed through processing it does not need, components separated across networks or regions by accident, and repeat content served from origin rather than cache.
The figure is worth treating with appropriate caution. Some of what looks avoidable turns out to be required once the reason is known — an inspection requirement that comes from a contract, a replication job that supports a recovery commitment. That is exactly why the review maps deliberate paths before removing anything. The useful outcome is not eliminating cost for its own sake; it is being able to say, for each significant transfer line, which decision it pays for.
What distinguishes transfer cost from most other cloud savings is that the fixes rarely touch what the workload does. Right-sizing a virtual machine risks performance; bringing an application’s tiers into one region usually improves it, because latency falls along with cost. A good share of transfer reductions are therefore free of the trade-offs that make other cost work contentious.
Caching, CDNs and reducing repeat transfer
Internet egress is the largest transfer category for most public-facing workloads, and a large share of it is the same content sent repeatedly. Caching is the remedy.
Put a CDN in front of anything served publicly
A content delivery network stores copies of content at locations near users and serves repeat requests from there, so origin egress is paid once per cache period rather than once per request. Images, scripts, stylesheets, documents and downloads are the obvious candidates, and for many sites they represent the majority of bytes served. The CDN’s own delivery charge is frequently lower per gigabyte than origin internet egress, so the saving comes from both reduced volume and a cheaper rate. There is a performance benefit too, which we discuss in our guide to Core Web Vitals and website speed.
Set cache rules deliberately
A CDN with short or absent cache lifetimes caches nothing useful. Review the headers your origin sends, set long lifetimes on versioned static assets, and use file naming that changes when content changes so that long caching does not serve stale files. Measure the cache hit ratio; a low ratio usually means configuration rather than content is the constraint.
Compress what can be compressed
Text-based responses — HTML, JSON, scripts, stylesheets, CSV exports — compress substantially, and compressed bytes are what you pay for. Enabling compression at the CDN or origin reduces transfer volume for API and web traffic with no change to the application.
Avoid shipping the same data repeatedly
Repeated full extracts to reporting systems or third parties, logs exported out of region on every collection cycle, and synchronisation jobs that copy everything rather than changes are all repeat transfer. Incremental transfer, change-based synchronisation and processing data where it lives rather than moving it to the processor all reduce volume. The same principle applies to deciding where analytics runs, which we touch on in our guide to real-time versus batch reporting.
Reading the bill to find where transfer comes from
Transfer cost is hard to act on until it is attributed. These steps take an undifferentiated networking line and turn it into specific flows.
Group by meter, not service. Service names such as bandwidth or virtual network are too coarse. Meter names distinguish inter-region transfer, peering in and out, internet egress and processing, and each points to a different architectural cause.
Group by resource. Within each meter, the resources responsible are usually few. A single storage account serving downloads, a single database replicating cross-region, or a single firewall processing all spoke traffic commonly accounts for most of a category.
Look for step changes. Monthly granularity across a year shows when a line jumped, and the activity log for that period usually names the change — a new replication policy, a restore into another region, a peering connection, a new public endpoint.
Use flow logs to confirm. Billing tells you what was charged; flow logs tell you what actually travelled between which addresses. Together they let you say with confidence that a particular application is sending a particular volume across a particular path.
Tag networking resources to workloads. Peering connections, gateways, firewalls and NAT gateways are often shared and untagged. Tagging them, and using cost allocation where shared resources serve several workloads, is what lets transfer cost appear against the system that causes it rather than in a networking bucket nobody owns.
Once a month, the same view — networking meters by resource, compared with the previous month — takes ten minutes and catches new transfer patterns while they are small. Adding it to an existing cost review is the single cheapest control in this guide.
Exit costs and the case for knowing them in advance
Because inbound transfer is free and outbound is charged, the cost of leaving a platform is mostly the cost of moving your data out. For an estate holding many terabytes, that is a material figure, and it is worth estimating before it becomes relevant rather than when a decision depends on it.
The position has improved. Following regulatory attention in the UK and Europe on switching costs in cloud markets, the major providers have introduced arrangements under which egress charges can be waived for customers migrating data away entirely, subject to conditions such as notifying the provider and completing the move within a set period. The detail and eligibility differ by provider and change over time, so check the current terms rather than assuming either that exit is free or that it is prohibitively expensive.
Two practical points follow. First, exit cost is a reason to keep data volumes deliberate — retaining everything indefinitely in hot storage enlarges both the monthly bill and any future move. Second, data that must be extracted routinely, such as backups held with a third party or exports to another system, is ongoing egress rather than an exit cost, and should be sized as such. Backup restore egress in particular is covered in our guide to cloud backup pricing.
The 12-point data transfer cost checklist
Items one to four establish visibility. Items five to nine reduce avoidable transfer. Items ten to twelve stop it returning.
- Break down twelve months of networking spend by meter and resource. Identify which paths are charged and which resources drive each.
- Enable flow logs with a set retention period. So attribution rests on what actually travelled rather than inference.
- Find the step changes and their causes. Match jumps in transfer cost to the changes in the activity log for the same period.
- Map which cross-region and inspection paths are deliberate. Record the reason for each; everything else is a candidate for change.
- Bring split application tiers into one region. Accidental cross-region dependencies cost transfer and add latency.
- Use private paths for platform services. Reach storage, databases and other services through private endpoints or service endpoints rather than public endpoints via NAT.
- Exempt trusted bulk flows from inspection where policy allows. Backups and replication rarely need to traverse the firewall twice.
- Size replication to recovery objectives. Replicate what the recovery plan requires, at the frequency it requires.
- Put a CDN in front of public content, with deliberate cache rules and compression. Usually the largest single reduction in internet egress.
- Tag networking resources to the workloads they serve. So transfer cost lands against a system with an owner.
- Add networking meters to the monthly cost review and budget alerts. Catch a new replication job or misplaced restore the next day.
- Estimate transfer impact before architecture changes. One question in the change process prevents most future accidental paths.
If only three items are completed, make them one, nine and eleven. The meter-and-resource breakdown tells you where the money is going. A CDN in front of public content is usually the largest single saving for anything serving users. And networking meters in the monthly review are what catch the next accidental path while it is still small. Together they take a few days and address most of the transfer cost UK estates can reasonably avoid.
What this looks like in practice
A UK engineering consultancy with 140 staff ran a document management system, a project portal for clients and a reporting database in Azure, split across UK South and UK West for resilience, with a hub virtual network and a central firewall through which all traffic was routed. Monthly Azure spend was around £11,500, of which networking services accounted for roughly £1,650 — a figure that had roughly doubled over eighteen months without any corresponding change the business could identify.
A meter-level breakdown found three things. Inter-region transfer from UK South to UK West had jumped fourteen months earlier, in the same week the reporting database had been restored from backup during an incident; it had been restored into UK West, never moved back, and the reporting application in UK South had been querying it across regions ever since. Firewall processing was the largest single networking line, driven largely by nightly backup traffic and continuous replication passing through the hub firewall on its way between networks. And internet egress was dominated by a single storage account serving large drawing files to clients through the project portal, with no caching in front of it.
None of these had been chosen. The restored database was a decision made under pressure during an incident. Routing replication through the firewall was the default route rather than a security requirement. And the project portal had been built to serve files directly because that was the simplest way to get it working.
Remediation took about four weeks. The reporting database was moved back to UK South alongside its application, which also reduced report run times noticeably. Backup and replication flows between trusted internal networks were given a direct path that bypassed the firewall, with the security team’s agreement that inspection added nothing for those flows. A CDN was placed in front of the project portal’s file storage with long cache lifetimes for drawing revisions, which are versioned and never change once issued. Networking resources were tagged and added to the monthly cost review.
Networking spend fell from about £1,650 to around £780 a month. The firm’s IT manager noted that the bigger benefit was that each remaining line could now be explained: replication for the recovery plan, inspection for user and internet traffic, delivery to clients.
Nobody had decided to spend eight hundred pounds a month on the database being in the wrong region. Somebody restored it at two in the morning during an outage, it worked, and that was that. We only found it because someone finally grouped the bill by meter and asked why a line had jumped in a particular week.
Two points generalise. The first is that the largest avoidable cost came from an incident decision that was never revisited, which is a common pattern and an argument for reviewing infrastructure changes made under pressure once the pressure has passed. The second is that fixing the transfer path also improved performance, which is typical of transfer work: removing an unnecessary hop usually helps latency as well as cost.
Common mistakes with cloud data transfer costs
The errors below recur in UK cloud estates. Most come from treating transfer as an unavoidable overhead rather than a consequence of design.
- Treating networking cost as a single line. Without a meter-level breakdown, transfer cost cannot be attributed to a path or a system, and nobody acts on it.
- Leaving application tiers in different regions. Often the result of an incident restore or a template default. Every request crosses a region boundary, costing transfer and adding latency.
- Routing every flow through the inspection hub. Backups and replication between trusted networks frequently traverse the firewall only because that is the default route, paying processing and peering twice.
- Replicating everything to the second region. Replication scope should follow recovery objectives. Broad continuous replication is a large recurring cost if the recovery plan does not need it.
- Serving public content from origin. Without a CDN, every repeat download pays internet egress. Usually the single biggest avoidable transfer cost for public workloads.
- Reaching platform services through NAT and public endpoints. NAT gateway processing is charged per gigabyte on traffic that could have taken a private path.
- Ignoring transfer cost at design time. Fewer than one organisation in ten estimates transfer impact before an architecture change, which is when it is cheapest to influence.
- Leaving flow logs without retention limits. Logs needed to diagnose transfer cost become a storage and ingestion cost of their own if retained indefinitely.
- Assuming exit is either free or impossible. Providers have introduced conditional egress waivers for migrating away; check the current terms rather than relying on either assumption.
- Excluding networking services from budgets. A budget that covers compute and storage but not networking will not alert when a new replication job starts.
Be careful not to cut transfer cost by weakening resilience or security without deciding to. Removing cross-region replication reduces the bill and may leave a system unrecoverable in a regional outage. Bypassing the firewall for a flow saves processing and may remove inspection that a contract or policy requires. The right sequence is to establish why each path exists before changing it, and to make any reduction in resilience or inspection an explicit decision by whoever owns that risk. Transfer cost is worth controlling; it is not worth controlling at the expense of the recovery plan or the security policy.
At a glance — cloud data transfer costs
| Question | Short answer |
|---|---|
| Why do transfer costs surprise people? | Inbound is free, outbound is metered, cost follows the path not the activity, and several meters apply to one journey |
| Typical share of Azure spend | Around 6–14 per cent for networking and data transfer in UK SME estates |
| Share typically avoidable | Around 43 per cent, from unneeded inspection, accidental cross-region paths and uncached content |
| The three price bands | Within a region (free in a network, small for peering), between regions (low per GB), to the internet (highest per GB) |
| Processing meters | Firewalls, NAT gateways and private endpoints charge per GB processed on top of transfer |
| Hub-and-spoke cost | Spoke-to-spoke via a hub pays peering twice plus firewall processing — worth it where inspection is needed, not by default |
| Largest single reduction for public workloads | A CDN in front of static content and downloads, with deliberate cache rules and compression |
| UK-specific driver | UK South and UK West pairing for residency and resilience creates cross-region replication cost — size it to recovery objectives |
| How to find the source | Group networking spend by meter and resource, look for step changes, confirm with flow logs |
| Commonest accidental cost | Application tiers split across regions, often after an incident restore |
| NAT gateway trap | Reaching platform services via public endpoints through NAT pays processing that private paths avoid |
| Exit costs | Mostly egress; providers now offer conditional waivers for full migrations away — check current terms |
| Cheapest ongoing control | Networking meters in the monthly cost review, with budget alerts covering networking services |
| Design-time control | One question in the change process: which new paths does this create and at what volume |
| What not to do | Cut resilience or inspection to save transfer cost without an explicit decision by the risk owner |
How Cloudswitched approaches cloud network costs
Cloudswitched designs and manages cloud networking for UK organisations, and data transfer cost is part of designing a network rather than something to discover on an invoice. In practice that means breaking networking spend down by meter and resource, enabling flow logs to confirm what is travelling where, mapping which cross-region and inspection paths exist for a reason, correcting the ones that do not, putting caching in front of public content, and tagging networking resources so cost lands against the workload that causes it. We treat resilience and security as constraints rather than targets: where a path exists for recovery or inspection, we size it, and we do not remove it without the risk owner deciding to.
Find out where your data transfer spend is going
We break your networking costs down by path and resource, identify the flows nobody chose, and redesign them without weakening resilience or security.
Talk to a Cloud Networking SpecialistFrequently Asked Questions
What are cloud egress costs?
Charges for data leaving a cloud platform or crossing certain boundaries within it, billed per gigabyte. In Azure, data coming into the platform is free, traffic within a single virtual network is free, and charges apply to traffic crossing peering connections, crossing between regions, and leaving to the internet. On top of those, services that traffic passes through — firewalls, NAT gateways, private endpoints — charge per gigabyte processed. The total for any flow depends on the route it takes, which is why architecture rather than usage usually determines the bill.
Why is my Azure bandwidth or networking cost growing?
Usually because something started moving data continuously along a charged path, rather than because the business is using more. Common causes are a database restored into a different region during an incident and never moved back, a new replication or backup policy copying data cross-region, traffic routed through a central firewall by default, or public content served from origin without caching. Group networking spend by meter and resource across the past year, find the month the line stepped up, and check the activity log for that period — the cause is usually named there.
Is data transfer between UK South and UK West charged?
Yes. Traffic between Azure regions is charged per gigabyte, and the two UK regions are separate regions for this purpose, although transfer within Europe sits at the lower end of inter-region pricing. That matters for UK organisations because data residency and resilience commonly lead to a UK South and UK West pairing with replication between them. The design is frequently right; the replication volume should be sized to what the recovery plan actually requires rather than replicating everything continuously by default.
Does Azure charge for traffic between availability zones?
At the time of writing, Azure does not charge for data transfer between availability zones in the same region, though it has discussed doing so in the past. Some other cloud providers do charge for inter-zone traffic in each direction, which matters when comparing platforms or running workloads across more than one. Check the current pricing page, because this is the kind of detail that changes, and design zone-redundant architectures on resilience grounds rather than on the assumption that zone transfer will always be free.
How much does internet egress cost from Azure?
Azure includes a free monthly allowance of internet egress, after which it is charged per gigabyte on a tiered basis with the rate falling at higher volumes. At typical SME volumes from UK regions it is in the region of a few pence per gigabyte at the time of writing — several times the cost of transfer between UK regions and several times again the cost of regional peering. Check the current pricing pages and your own agreement for exact rates, as they are published in several currencies and adjusted periodically.
Does a CDN actually reduce costs or just add one?
For public content requested repeatedly, it usually reduces cost. A CDN serves repeat requests from caches near users, so origin egress is paid once per cache period rather than once per request, and the CDN’s delivery rate is frequently lower per gigabyte than origin internet egress. The saving depends on cache hit ratio, which depends on cache configuration: long lifetimes on versioned static assets and correct headers from the origin. A CDN with poor cache rules can add a charge without removing much origin traffic, which is why measuring origin egress before and after is worthwhile.
Why does hub-and-spoke networking increase transfer costs?
Because traffic between two spokes travels through the hub, crossing two peering connections, each charged in both directions, and passing through whatever appliance sits in the hub, which charges for processing. That cost buys centralised inspection and control, which is often worth having. The saving comes from being selective: inspect user and internet traffic and anything policy requires, but give trusted bulk flows such as backups and replication a direct path where the security team agrees inspection adds nothing.
What is NAT gateway data processing and why is it on my bill?
A NAT gateway provides outbound internet access for private resources and charges per gigabyte processed, in addition to any internet egress. It often appears unexpectedly when workloads reach Azure platform services — storage accounts, databases — through their public endpoints, so the traffic leaves through the NAT gateway and back in. Using private endpoints or service endpoints for those services keeps the traffic on the Azure network and avoids the NAT processing charge for it.
How do I find which application is causing transfer costs?
Combine billing and flow data. In Cost Management, filter to networking services, group by meter to identify the path being charged, then by resource to identify which storage account, database, gateway or firewall is responsible. Enable virtual network flow logs to see which addresses are exchanging traffic across boundaries. Then tag networking resources to the workloads they serve, so future transfer cost appears against the system that causes it. Our guide to Azure migration cost covers how transfer fits into the wider cost picture during a move.
How much does it cost to leave a cloud provider?
Mostly the egress charge for moving your data out, because inbound transfer to the destination is typically free. For large estates that can be material. Following regulatory scrutiny of switching costs in the UK and Europe, major providers now offer conditional egress waivers for customers migrating away entirely, usually requiring notice and completion within a set period. Terms differ and change, so estimate the volume involved and check the current conditions rather than assuming exit is either free or prohibitive.
Should we reduce replication to save money?
Only as a deliberate decision by whoever owns recovery risk. Replication exists to meet recovery objectives, and removing it can leave a system unrecoverable in a regional outage. The right approach is to establish which systems need cross-region replication and at what frequency, size replication to that, and stop replicating systems whose recovery plan does not depend on it. That usually reduces cost substantially without weakening recovery, because broad default replication typically covers far more than any recovery plan requires.
Does this affect our office internet connection costs?
Indirectly. Cloud egress is charged by the cloud provider for data leaving its platform, while your office connection is a separate contract with your internet provider. They interact in that a cloud-first office downloads a great deal from cloud platforms, which affects how much bandwidth your circuit needs but not your cloud bill, since inbound to you is outbound from the provider to the internet and is often within allowances or served from caches. Office connectivity sizing is covered in our guide to managing bandwidth for cloud-heavy businesses.
Related reading
More guidance on designing, securing and paying for UK business cloud and IT:
Every network path should have a reason and a known cost
Cloudswitched maps where your data travels, removes the paths nobody chose, caches what is served repeatedly, and keeps resilience and inspection where they are genuinely needed.
Talk to a Cloud Networking Specialist
CloudSwitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
