Azure VNet costs: where "free" networking actually bills you

Networking is the part of the Azure bill nobody can explain. Compute maps to a VM someone remembers creating; storage maps to data someone remembers keeping. But "Virtual Network Peering — Data Transfer Out"? That maps to a decision somebody made eight months ago and forgot. Here is the full map: what actually bills on a VNet, how each item is metered, and how to trace every networking line back to the thing that caused it.

New to cloud? CAMPUX is a free, build-first course. Start here →

An Azure virtual network costs nothing by itself — no hourly charge, no per-VNet fee. The bill comes from what you attach to it: peering traffic, NAT Gateway, private endpoints, VPN and ExpressRoute gateways, Azure Firewall, Bastion, public IPs, and internet egress — and the exact rates vary by region, so always check current pricing. That is the honest one-paragraph answer, and it is also why "azure vnet costs" is such a frustrating thing to search for. Microsoft is not lying when it says the VNet is free. It is just that nobody runs a bare VNet. The moment your network does anything useful — reaches another VNet, reaches the internet, gets reached privately, gets inspected — a meter starts, and the meter is named after a service you may not remember attaching.

I have spent enough time in Cost Analysis untangling other people's networking charges to know the pattern. The bill is rarely wrong — it is unattributed. So this article does two jobs. First, the billing map: every networking item that charges, and how it charges. Second, the tracing method: how to get from a line in Cost Analysis back to the gateway, firewall, or peering that produced it.

One rule up front: I am not going to quote prices. Azure networking rates vary by region, change over time, and differ between tiers; any number I typed here would be wrong for someone within a month. What does not change quickly is the billing model — hourly, per gigabyte, or both — and that is what you need to reason about your architecture. For actual rates, the official pages are linked in the table below.

Why "the VNet is free" is true and useless

A VNet is an address space and some subnet definitions. That is metadata, and Azure does not charge for metadata. You can create fifty VNets, attach NICs, and put NSGs on everything — NSGs are free too — and the networking bill stays at zero. Traffic between VMs inside one VNet, in one region, does not bill either.

But a VNet in that state is an island. Real networks connect to things, and every connection type is a product with its own meter:

• Connect to another VNet → peering, billed per gigabyte crossing it.
• Connect out to the internet at scale → NAT Gateway, billed hourly plus per gigabyte.
• Let a PaaS service connect in privately → private endpoints, billed hourly plus per gigabyte.
• Connect to on-premises → VPN or ExpressRoute gateway, billed hourly around the clock.
• Inspect the traffic → Azure Firewall, billed hourly plus per gigabyte.
• Administer the VMs without public IPs → Bastion, billed hourly.

Notice the two billing shapes. Some items bill per gigabyte — they cost nothing when quiet and scale with traffic. Others bill per hour — they cost the same whether they carry a terabyte or nothing at all. That distinction is the whole game. Traffic-shaped costs are fixed by fixing the traffic. Hour-shaped costs are fixed by deleting the resource — and hour-shaped costs on forgotten resources are where dev subscriptions quietly bleed.

The billing map: every VNet-attached charge and how it meters

Here is the full map. The "billing model" column is the part worth memorising; the pricing links are where the actual numbers live. Rates vary by region and change over time — treat the links as the source of truth, not anything you read in a blog, including this one.

A few of these deserve a sentence more than a table row gives them.

Peering is the one people misjudge most, because it is free to create and stays free while quiet. The cost is purely traffic, both directions metered, and the rate steps up when the VNets are in different regions. For the mechanics behind that, see VNet peering explained.

The gateways — VPN and ExpressRoute — are the opposite shape: almost pure standing cost, an hourly meter that runs from deployment until deletion, regardless of traffic. There is no pause button on a VPN gateway. Choosing between the two is its own topic — see ExpressRoute vs VPN Gateway — but for billing they share one property: an idle one costs the same as a busy one.

Azure Firewall combines both shapes — hourly plus per gigabyte — which is why it dominates the networking bill in hub-and-spoke designs. Hold that thought; it matters for the honesty section below, because a big firewall line is not automatically a problem.

Private endpoints are death by a thousand cuts. One is cheap, but the standard secure pattern is an endpoint per PaaS service — storage, key vault, SQL, container registry — per environment, and the hourly meters stack. If cost is part of your endpoint decision, private endpoints explained covers the trade-off against free-but-weaker service endpoints.

Inter-zone traffic earns its hedge. Azure spent years announcing and deferring a charge for traffic between availability zones, and half the internet still repeats it as current. As of 2026 that charge is retired — zone-to-zone traffic in a region does not bill separately. Verify against the bandwidth pricing page before betting a design review on it, because this rule has moved before. But do not let a stale post scare you out of zone redundancy.

Traffic-shaped costs are fixed by fixing the traffic. Hour-shaped costs are fixed by deleting the resource. Most networking bill surprises are hour-shaped costs on resources nobody remembers.

How to actually find each one in Cost Analysis

Knowing the map is half the job. The other half is tracing a real line item back to a real resource, and Cost Analysis will do it if you interrogate it in the right order.

Step one: group by service name

Open Cost Analysis at the subscription scope (or management group if you own several), set the view to the current month, and group by service name. Networking charges will not appear as one "networking" bucket — they split across services: Virtual Network, VPN Gateway, ExpressRoute, Azure Firewall, Azure Bastion, NAT Gateway, Azure Private Link, and Bandwidth. That last one is the catch-all for data transfer, including internet egress. This first pass tells you which product is billing; it does not yet tell you why.

Step two: group the expensive service by meter

Click into whichever service is biggest and group by meter (or meter subcategory). This is where the map pays off, because meter names are the bridge between the bill and the architecture:

• Peered traffic shows up under Virtual Network Peering meters — separate ingress and egress meters, and distinct meters for global (cross-region) peering. If the global meters are the big ones, you have chatty cross-region traffic.
• NAT Gateway splits into a gateway-hours meter and a data processed meter. Hours big and data near zero? That gateway is furniture — delete it.
• VPN and ExpressRoute gateways bill on per-hour meters named for their SKU. A flat, unchanging daily amount is the signature of an idle gateway.
• Private Link shows per-endpoint hourly meters plus data processed. Steady growth here usually tracks environment sprawl, not traffic growth.
• Internet egress lives under Bandwidth as data-transfer-out meters, charged past the monthly free allowance.

The shape of the daily cost chart is itself a diagnostic. A flat line means hour-based meters — standing infrastructure. A spiky line that follows business hours means data meters — real traffic. Flat lines in subscriptions labelled "dev" or "sandbox" are where I look first.

Step three: tag the shared stuff so blame lands correctly

The organisational failure mode: the hub firewall and gateways serve everyone, so their cost lands on whichever subscription hosts the hub — and some app team gets asked why "their" networking bill is enormous. Fix it with tags before it becomes an argument. Tag gateways, firewalls, Bastion hosts and shared peerings with an owner tag that says platform, and tag workloads with their team. Cost Analysis grouped by tag then splits platform cost from workload cost, and the monthly conversation becomes "is the platform sized right?" instead of "who spent this?". This is standard FinOps hygiene, covered properly in Class 32 on cost management and FinOps.

The three quiet monthly burners

Across every environment I have audited, three offenders come up so often they deserve their own section. None of them are exotic. All of them are boring, which is exactly why they survive.

1. The idle VPN gateway in a dev subscription

Someone needed to test hybrid connectivity in March. They deployed a VPN gateway, ran the test, moved on. It has billed every hour since, carrying nothing, because deleting it felt risky and nobody owned the decision. VPN gateways are the perfect forgotten cost: no traffic signal, no errors, no noise — just a flat hourly meter. A VPN gateway in a non-production subscription should be presumed abandoned until someone claims it.

2. The NAT Gateway someone attached and forgot

NAT Gateway solves a real problem — SNAT port exhaustion and stable outbound IPs — and attaching one takes about a minute, which is the problem. It gets attached during an incident, the pain stops, and the hourly meter runs from then on. Six months later the workload has moved and the gateway processes nothing, still billing. The tell in Cost Analysis: gateway-hours meter present, data-processed meter near zero.

3. Chatty cross-region peering from a misplaced service

This one is traffic-shaped, so it grows instead of sitting flat. A service gets deployed in the wrong region — a template default, a capacity constraint, a copy-paste — and talks constantly to a database or queue back home over global peering. Every gigabyte bills, both directions, at cross-region rates. Nothing is broken, so nobody notices, but the Virtual Network Peering meters climb month over month. The fix is usually not a networking fix at all: move the misplaced service next to what it talks to, and the line collapses.

The honest part: some of this is architecture, not waste

Every cost-cutting article implies the goal is to drive these numbers to zero, and that is wrong in a way that will hurt you in a design review. A chunk of your networking bill is the price of decisions made on purpose. The hub firewall bills hourly because it is supposed to be always on — an inspection point that pauses at night is not a security control. The ExpressRoute gateway bills while idle at 3am because your on-premises connection is supposed to exist at 3am. Calling that "waste" is a category error.

The actual skill — the one that separates someone who can read a bill from someone who can defend one — is separating intentional platform cost from forgotten cost. Intentional cost has an owner, a reason someone can state, and a tag that says so. Forgotten cost has none of those. The uncomfortable truth is that the difference is not visible in Cost Analysis at all; the same flat hourly line can be a load-bearing firewall or an abandoned gateway. The bill cannot tell you which. Only ownership can.

Which means the fix for forgotten cost is not a clever query — it is lifecycle discipline. Budgets with alert thresholds on every subscription, so a flat new hourly cost gets a human's attention within days instead of quarters. Auto-teardown of dev environments, so the idle gateway problem cannot accumulate. A standing rule that hour-billing resources (gateways, firewalls, Bastion, NAT) require an owner tag at creation, enforced by policy. None of this is glamorous, and all of it is worth more than any one-time cleanup. I built a free hands-on lab that walks through exactly this guardrail set — the cost guardrails lab — and the surrounding theory lives in the FinOps class. Both are free; you can check whether I know what I am talking about before trusting any of this.

Questions people also ask

Do Azure virtual networks cost money?

No — the virtual network itself is free. You can create a VNet, carve it into subnets, and attach network interfaces without paying anything for the VNet resource. The money starts when you attach billable services to it: peering to another VNet, a NAT Gateway, private endpoints, a VPN or ExpressRoute gateway, Azure Firewall, Bastion, or public IP addresses. Traffic leaving Azure to the internet also bills per gigabyte after a monthly free allowance. So a VNet full of VMs talking only to each other inside one region can genuinely cost nothing on the networking side, while a hub-and-spoke design with a firewall and gateways bills around the clock.

Why is my Azure networking bill so high?

Usually one of four things: an always-on gateway (VPN, ExpressRoute or Bastion) billing hourly whether or not traffic flows, an Azure Firewall billing hourly plus per gigabyte processed, cross-region VNet peering carrying chatty traffic at a higher per-gigabyte rate than in-region peering, or internet egress from something moving more data out than you realised. Open Cost Analysis, group by service name, then group the expensive service by meter — the meter names tell you which resource type is billing and whether the charge is hourly (idle-capable) or per gigabyte (traffic-driven). Hourly charges you can kill by deleting idle resources; per-gigabyte charges you fix by moving or fixing the traffic.

Does VNet peering cost money in Azure?

Yes. Creating the peering is free, but every gigabyte that crosses it is metered — and it is charged on both sides, an ingress meter and an egress meter, so the same traffic shows up twice in Cost Analysis. Peering within a region is cheap per gigabyte; global peering between regions costs noticeably more and varies by the zones involved. Rates change, so check the Virtual Network pricing page rather than trusting any number in a blog post. The practical takeaway: peering cost is a traffic problem, not a resource problem. A quiet peering costs nearly nothing; a chatty cross-region one can become one of the biggest lines on the bill.

How do I find networking costs in Azure Cost Analysis?

Open Cost Analysis at the subscription or management group scope, then group by service name. Networking charges surface under services like Virtual Network, VPN Gateway, ExpressRoute, Azure Firewall, Azure Bastion, NAT Gateway, Azure Private Link and Bandwidth. Click into a service and group by meter: the meter name tells you the exact billing mechanism — for example the Virtual Network Peering meters for peered traffic, the NAT Gateway data-processed meter, or gateway-hour meters for VPN and ExpressRoute. Hour-based meters mean the resource bills while idle; data-based meters mean traffic is driving the cost. Tag shared resources like firewalls and gateways with an owner so the charge attributes to the platform team instead of whichever app team looks guilty that month.

Is traffic between availability zones charged in Azure?

As of 2026, no — Microsoft retired the planned charge for data transfer between availability zones, so traffic between zones within the same virtual network is not billed as a separate line item. That removed a cost argument against zone-redundant designs, which is good news. Two hedges: first, confirm against the current bandwidth pricing documentation, because networking billing rules have changed before and can change again; second, do not confuse zone traffic with region traffic. Traffic between regions — over global VNet peering or out to the internet — is very much still charged per gigabyte.