Cloud Cost Optimization Guide
Cloud costs rarely spike from one dramatic mistake — they creep from small defaults left unexamined: an oversized database instance nobody resized after launch, a CDN configuration paying for egress that a different provider offers free, or autoscaling rules that scale up eagerly but never scale back down. The fix is usually not "move to a cheaper provider" but "stop paying for capacity and features you are not using."
Start by pulling your actual bill apart by service — compute, storage, database, egress/bandwidth, and third-party APIs are usually the five largest line items — and attack the biggest one first. Bandwidth/egress in particular is worth a hard look: providers charge wildly different rates for data leaving their network, and this is one of the few cost levers where switching providers for a single component (not your whole stack) can meaningfully help.
Use free tiers deliberately, not accidentally
Free tiers are real and generous for early-stage apps: Cloudflare Workers (100,000 requests/day free), Vercel and Netlify hobby tiers for frontend hosting, AWS/GCP/Azure always-free compute and database allowances, and Supabase/PlanetScale free database tiers all cover meaningful production traffic before you pay anything. The trap is exceeding a free tier limits without noticing — set billing alerts (all major providers support this) at low dollar thresholds from day one so you get a signal before a traffic spike turns into a surprise bill, rather than after.
Cut egress and bandwidth costs
Bandwidth/egress is one of the most variable costs across providers and one of the easiest to optimize independently. Cloudflare R2 charges no egress fees at all (a deliberate competitive difference from S3/GCS), making it the cheapest option for apps serving a lot of media to end users; pairing any origin storage with Cloudflare CDN or another CDN in front of it caches responses at edge locations and avoids repeated origin egress charges entirely for cacheable content. If you are on AWS/GCP and cannot move storage, at minimum ensure a CDN sits in front of anything served repeatedly — serving directly from S3/GCS without a CDN is one of the most common avoidable cost sources.
Right-size compute and use edge where it fits
Oversized database and compute instances are the most common single line-item waste — check actual CPU/memory utilization (most providers show this in their console) and downsize instances running consistently under 30-40% utilization. For request-driven workloads without constant background processing, serverless/edge compute (Cloudflare Workers, AWS Lambda, GCP Cloud Functions, Vercel Functions) charges only for actual execution time rather than a constantly-running instance — genuinely cheaper for spiky or low-traffic APIs, though it can cost more than a fixed instance at very high sustained request volume, so this is not universally the cheaper option above a certain traffic threshold.
Autoscaling: scale down as aggressively as you scale up
Most autoscaling misconfigurations are not about scaling up too slowly — they are about scaling down too conservatively, leaving extra instances running long after a traffic spike passes. Set scale-down cooldown periods that match your actual traffic pattern (a spiky app needs a shorter cooldown than one with smooth daily cycles), and use scheduled scaling (scale to zero or minimum overnight) for workloads with predictable low-traffic windows — supported on AWS Auto Scaling, GCP autoscaler, and Azure equivalent. Cloud Run and Google App Engine both support true scale-to-zero for idle periods, which is worth using directly if your traffic has real idle windows.
Audit third-party API and managed service spend
LLM APIs, email/SMS services (Twilio, SendGrid), and managed search (Algolia) often become a larger line item than raw compute once an app has real usage — apply the same instrumentation discipline here as to cloud infra: tag spend by feature, set budget alerts with each vendor directly, and periodically check whether you are paying for a tier of a service (a managed database connection pooler, or a CDN premium features) that your actual traffic does not need yet.
Frequently asked questions
What is the single biggest cloud cost most teams overlook?
Bandwidth/egress fees, particularly serving media or large API responses directly from storage without a CDN in front. Cloudflare R2 zero-egress-fee model plus a CDN layer is often the highest-leverage single change for media-heavy apps.
Is serverless/edge compute always cheaper than a regular server?
No. It is typically cheaper for spiky, low-to-moderate traffic because you pay only for execution time, but at very high sustained request volume a fixed, right-sized instance can be cheaper than paying per-invocation. Check your actual traffic pattern before assuming either is universally cheaper.
How do I avoid a surprise bill from exceeding a free tier?
Set billing/budget alerts at low dollar thresholds the day you set up any cloud account, not after you notice a large bill. Every major provider (AWS, GCP, Azure, Cloudflare, Vercel, Netlify) supports this, and it is the single easiest cost-control step teams skip.
Should autoscaling rules focus more on scaling up or scaling down?
Scaling down is the more commonly misconfigured side. Most teams tune scale-up thresholds carefully but leave conservative (or missing) scale-down cooldowns, which leaves extra paid instances running well after traffic has dropped.