The Azure pricing calculator is a useful tool. It is also systematically misleading about total cost if you do not know where to look. Service prices are accurate — compute, storage capacity, managed service tiers. Those numbers are reliable. Egress, transactions, and operations at scale are where the gap between estimated and actual spend appears. These are documented, not hidden. But they are easy to miss during architecture, and expensive to discover in production. These are the four areas that consistently catch architects off guard.
Bandwidth Egress — The Cost Nobody Models
Azure charges for data leaving a region. Data entering a region is free. The trap is that egress costs are invisible in the Azure pricing calculator unless you explicitly add a bandwidth line item. Most architecture estimates built in the calculator omit it entirely.
The places where egress compounds badly are predictable once you know to look for them. Multi-region architectures with cross-region service calls — an API tier in UK South calling a database or cache in West Europe — generate egress on every call.
The Asymmetric Failover Trap: I’ve seen architectures where regions were talking heavily to each other because of an Azure SQL Failover Group. In this scenario, the database had failed over to the secondary region, but the API tier was still sitting in the primary. Azure SQL handles the failover to the secondary automatically, but it does not automatically fail back when the primary region comes back online. This leaves you in a “split-brain” cost state: the app stays healthy, but you are bleeding egress costs as every single database call crosses the regional boundary. If you don’t have a manual fail-back process in your runbook, your egress bill will climb until someone happens to notice the latency or the invoice.
Azure SQL — DTU vs vCore and When the Expensive Tier Is Cheaper
Azure SQL Database offers two purchasing models with meaningfully different cost structures at different scales. The DTU model is simple to reason about at low scale, but the vCore model separates compute from storage and unlocks zone redundancy.
The common mistake is staying on DTU past the right migration point. At Premium P4 (1,750 DTUs) and above, vCore is almost always more cost-effective for equivalent performance, and it enables zone redundancy that Premium-tier databases typically need anyway.
My Crossover Point: I generally start the vCore conversation once a database hits the P2 (250 DTU) level. Once you move past that, you’re usually paying for bundled resources you aren’t fully utilizing. If the client asks for Zone Redundancy or High Availability, the conversation ends—vCore is the only defensible choice.
Storage Transaction Costs — The Invisible Scaling Problem
Azure Blob Storage pricing has two components: capacity and operations (transactions). The capacity component is what most estimates capture. The operations component is what surprises teams at scale.
The Azure Files/Functions Quirk: If you are running Azure Functions on an App Service plan, you might notice Azure Files shares being automatically created. These are often set to 100 TiB Transaction Optimized storage. While you only pay for the storage you actually use, the “Transaction Optimized” tier can lead to unexpected billing spikes if you aren’t aware that every internal Function operation is triggering storage transactions in the background. It’s a classic example of “auto-provisioning” creating a cost footprint that architects didn’t explicitly sign off on.
The Free Tier Trap
Several Azure services have free tiers that are genuinely free at low scale and non-linearly priced at production scale. The free tier shapes the architecture decision early in development, but the pricing cliff only becomes visible later.
Azure Functions on the consumption plan gives 1 million executions per month free. At production volumes — a few million executions per day — the cost calculation changes. The consumption plan then often costs more per month than an equivalent Premium plan or App Service hosting, while also introducing cold-start latency.
The break-even between consumption pricing and committed or tier-based pricing is consistently lower than architects expect. The free tier anchors the perception of cost during development. The production bill is calculated against a different set of numbers.
The Gap Between Estimate and Bill
The Azure pricing calculator is a starting point. The bill is the reality check. The gap between them is almost always in the same places: egress that was not modelled, transaction costs that were not counted, or a pricing tier that made sense at development scale and the wrong choice at production scale.
The correction is not more complex tooling. It is modelling discipline applied at the right point in the architecture process — before the design is committed, not after the first production bill arrives. For any cross-region design, estimate the egress. For any Azure SQL database approaching Premium tier, evaluate whether vCore is cheaper. For any storage-intensive workload, count the operations, not just the capacity.
These are not edge cases. They are standard patterns in production Azure architectures, and they have standard solutions. The variable is whether the architecture team knows to look for them before the infrastructure is running.
