How to reduce data transfer costs on Azure

Why this matters

Data transfer is the line item that grows without a deploy. Azure does not bill ingress in most services, so teams watch compute and storage and forget that every byte sent out has a meter. Egress to the internet, traffic between regions, traffic between availability zones, and data processing on network services all land in different meters.

The hard part is that one request can cross several meters. A VM in one region calls a storage account in another through a private endpoint. You pay egress from the storage region, private endpoint processing, and maybe NAT Gateway processing if the call leaves through a NAT. The application team sees one API call. Finance sees four lines.

The goal is not to remove every charge. It is to stop paying for traffic you did not intend: chatty calls between regions, image pulls from a distant registry, logs shipped across the world, and public egress for traffic that could stay private. Small design choices beat heroic refactors.

Before you start

Get read access to Cost Management and Billing for every subscription in scope. You need to see cost by meter, not just a monthly total. Ask for Cost Management Reader and Billing Reader. If you use tags for cost allocation, confirm the tags are present on the resources that move data, not just on the VMs.

Draw the traffic paths before you change anything. List each application tier, the region and zone it runs in, the storage and databases it calls, and the networks it crosses. Mark the paths that leave a region, leave a zone, or leave Azure. Include backups, container image pulls, log shipping, and analytics exports. These are the paths that hide.

Pick a baseline period. A full month is better than a week if traffic has a weekly cycle. Record the bandwidth meters, the top resources by cost, and the cost per GB or per 1,000 requests for the main services. You will compare against this after changes. Do not start with a target percentage. Start with a list of paths and a list of meters.

How to do it

Work from the bill backward to the architecture. In Cost Management, open Cost analysis, set the scope to the subscription or billing account, and filter Service name to Azure Bandwidth, Azure Front Door, Content Delivery Network, NAT Gateway, Private Link, and Virtual Network. Group by Meter and Resource. Export the result to a spreadsheet if you need to join it to your architecture map.

Fix the easy structural issues first. Put chatty services in the same region. Keep container images, package feeds, and backups close to the compute that reads them. Stop sending analytics queries across continents when a local replica will do. These changes are usually configuration, not code.

Then tune the network path. Private access is not automatically cheaper. A private endpoint adds hourly and per GB processing charges. A NAT Gateway adds per GB processing. A service endpoint is free but has its own limits. Compare the full path: source egress, processing, and destination ingress. Sometimes the cheapest path is a public endpoint with a tight firewall, not a private endpoint.

At the edge, cache and compress. Azure Front Door and Azure CDN can serve repeated content from an edge location and reduce origin egress. Turn on compression. Set correct cache-control headers. For APIs, use ETags, pagination, and compact payloads. None of this helps if every response is unique and uncacheable. Measure the cache hit ratio before you credit the edge with savings.

1. Map every path that leaves a region. List each service pair that talks across regions, zones, or the internet. Include backups, container registries, log exports, and analytics jobs. Mark the owner and the approximate volume for each path.
2. Read the bandwidth meters first. Open Cost analysis and filter by the meters named in this guide. Group by resource and sort by cost. Export the rows so you can match each charge to a path on your map.
3. Move chatty workloads into one region. Place the application, its database, its cache, and its storage in the same region when latency allows. Move container images and package feeds close to the compute that pulls them. Recheck the meters after the move.
4. Check zone and peering routing. Traffic between availability zones is billed in both directions. Traffic across VNet peering can be billed on both sides. Review route tables and hub-spoke designs so traffic does not cross a region twice through a firewall.
5. Compare private endpoint, service endpoint and public egress. Price the full path, not just the egress line. Include private endpoint processing, NAT Gateway processing, firewall processing, and destination ingress. Pick the path with the lowest total for your volume.
6. Cache at the edge and compress payloads. Put Front Door or Azure CDN in front of cacheable content and set long cache lifetimes for static assets. Enable compression and use ETags for APIs. Keep authenticated responses out of shared caches.
7. Put guardrails on regions and public IPs. Use Azure Policy to audit or deny public IP creation outside approved cases. Restrict which regions teams can deploy to. Add tags for cost allocation so new traffic paths show up under the right owner.
8. Review replication and backup settings. Check storage account redundancy and backup vault redundancy against the recovery plan. Geo-replication and cross-region restore can move data across regions. Keep read access close to the users who need it.

How to check it worked

Compare like with like. A lower bill after a traffic drop could mean you lost users. Track cost per GB, cost per 1,000 requests, and total requests alongside the bill. Use a rolling four-week window. If requests stayed flat and the bandwidth meters fell, the change worked.

Check the path, not just the total. If internet egress fell but Private Link processing rose, you may have moved the cost, not removed it. Look at NAT Gateway, Private Link, Azure Firewall, and peering meters in the same view. Sort by resource and confirm the expected resources moved.

Watch the user side. Check latency from the regions your users actually use. Look at cache hit ratio, error rate, and retry count. A cache that serves stale data or a route that adds hops will show up here. Give it two to four weeks before you call it done.

Mistakes to avoid

Do not chase egress by adding processing charges. A private endpoint or NAT Gateway can cost more than the egress it replaces for high-volume, low-value traffic. Model the full path with your own volumes. Do not assume private is cheaper.

Do not move everything into one region to save bandwidth. Users in another continent will pay in latency, and you may need a second region for recovery anyway. Keep the data close to the users and compute that need it, and accept some transfer.

Do not cache private data without a plan. Front Door and CDN cache by URL and headers. If your cache key ignores authorization, one user can receive another user's response. Set cache-control to private or bypass the cache for authenticated endpoints. Test with two accounts.

Do not forget backups, images, and logs. These run on schedules and are easy to miss. Check the redundancy setting on backup vaults and storage accounts. Pull container images from a registry in the same region. If you want an outside review, the Cloud cost audit from Cloudverg is a two-week, fixed price engagement at $4,500 that includes a data transfer and egress review. It is one option among managed cost tools, a consultant, or an internal review.

Frequently asked questions