I've tried to forecast cloud spend accurately enough times to appreciate why it's difficult — and the difficulty is structural, not a matter of not trying hard enough.
Cloud billing is deliberately complex. This is not a conspiracy — it reflects genuinely complex underlying infrastructure with many variable components. But the complexity serves providers as much as customers: it makes cost comparison difficult, overruns easy to miss, and the full bill hard to predict from first principles. Understanding the specific sources of cloud cost unpredictability is the prerequisite for managing it.
Pricing Complexity
Major cloud providers — AWS, Google Cloud, Azure — publish pricing pages with thousands of line items. A single service like AWS EC2 has hundreds of pricing variations: instance type, operating system, region, pricing model (on-demand, reserved, spot), tenancy, and data transfer direction all affect cost. A developer estimating infrastructure for a new feature cannot simply look up "compute cost" — they must know the specific configuration of every resource involved.
Pricing also differs between regions. Running the same workload in eu-west-1 (Ireland) versus eu-west-2 (London) costs approximately 8% to 15% more in London across most compute and storage categories. Most teams default to the region nearest their user base without comparing regional pricing — a reasonable decision in many cases, but not one made consciously.
Different services within the same provider have completely different pricing structures. S3 is charged per GB stored and per request. Lambda is charged per execution and per GB-second of runtime. RDS is charged per instance hour plus storage plus I/O operations. CloudFront is charged per GB transferred and per request. Building a system that uses all of these services requires correctly estimating costs across four entirely different pricing models and ensuring none of the estimates is wildly wrong.
Usage Variability
Cloud costs scale with usage rather than with headcount or time. This means costs vary month to month based on what users actually did — not what was predicted. Traffic spikes, data growth, and feature adoption all affect the bill independently of each other and often independently of revenue.
The most common source of unexpected cost variability is data egress — data transferred out of the cloud provider's network. Providers charge $0.08 to $0.15 per GB for egress from the cloud to the internet, and most cost estimates focus on compute and storage while treating bandwidth as a footnote. For applications serving media, large files, or high-volume API responses, egress can represent 20% to 40% of total cloud spend and is highly sensitive to traffic patterns.
Auto-scaling adds variability by design — it provisions more resources when traffic is high and releases them when it falls. This is the right approach for variable workloads, but it means that an unusually high-traffic month (from a viral moment, a major campaign, or a DDoS event) produces an unusually high bill. Auto-scaling protects uptime; it does not cap cost.
The Cloud Cost Estimator Calculator models baseline monthly spend from your infrastructure configuration and adds variability assumptions for traffic and data growth. Comparing the baseline estimate against a 2× traffic scenario shows the cost range rather than a single figure — producing a more honest forecast.
Hidden Costs
Several cloud cost categories are consistently underestimated or missed entirely in initial infrastructure planning:
Data transfer between services: Moving data between different AWS services within the same region is often free but not always. Data transfer between regions is always charged. Data flowing between a web server in one availability zone and a database in another availability zone incurs charges that accumulate at high transaction volumes. Architecture decisions that minimise cross-zone data transfer reduce costs meaningfully at scale.
API call charges: Many AWS services charge per API call in addition to per-resource fees. S3 charges $0.0004 per 1,000 GET requests. DynamoDB charges per read and write unit. At low volume these charges are negligible; at high request volume they become material. An application making 100 million S3 GETs per month pays $40 in request charges alone, independent of storage costs.
Support plans: AWS developer support starts at $29/month; business support at 10% of monthly usage (minimum $100). For production applications requiring timely support responses, business support is essentially mandatory — and its cost scales with usage in a way that is rarely included in infrastructure cost estimates.
Third-party SaaS tools: Observability (Datadog, New Relic), error tracking (Sentry), log management (Papertrail, Logtail), and security scanning tools that integrate with cloud infrastructure add meaningful monthly costs that are not cloud bills but are infrastructure costs in practice. A comprehensive observability stack for a production application can cost £300 to £1,500/month depending on log volume and tooling choices.