Specs, region, billing, bandwidth, availability, security, scaling, support — eight factors that decide whether you overpay, pick the wrong region, or overbuy bandwidth.
When people pick a cloud server, the first instinct is to ask "how many cores and how much RAM?" But the things that actually decide whether a site feels fast and what it costs are mostly elsewhere. Here is an eight-factor decision order you can reuse.
One rule: pick the region first, work out bandwidth second, decide specs last. Do it in any other order and you will overpay.
Start with the job, not the spec
Before comparing anything, answer one question: what is this machine primarily for? The optimal answer differs a lot by job.
- Websites, blogs, admin panels — bandwidth and I/O are the bottleneck; spare CPU is enough
- APIs and microservices — availability zones and autoscaling matter more
- Databases and caches — memory and network quality come first, CPU second
- Model training or batch work — GPU type and storage throughput are the story
Factor 1: Region beats specs
This is the most underestimated factor. The further your users are from the server, the higher the latency — and the lower the conversion.
Rule of thumb: the same machine usually sits at 15–30ms from Hong Kong to users in Greater China and Southeast Asia, but over 150ms from US West. That extra hundred milliseconds is something users feel. For the exact gap between Hong Kong and Singapore, and how much it degrades at peak hour, see Hong Kong vs Singapore regions.
- Users in Greater China / Taiwan / Hong Kong / Southeast Asia → Hong Kong or Singapore
- Users in North America, west coast → US West (Oregon / Los Angeles)
- Users in Europe → Frankfurt or Ireland
- Unsure → run two regions and let real data decide
Do not pick purely on sticker price. A US West node 20% cheaper that costs you 10% of conversion is not cheaper. Latency is a hidden cost you should price in revenue terms.
Factor 2: Size for the median, not the peak
If 2 vCPU and 4 GB does the job, do not jump to 8 and 16. In real projects, most machines sit below 30% CPU utilisation indefinitely.
- Static sites and admin panels: 1–2 vCPU, 2–4 GB
- Typical production systems: 2–4 vCPU, 4–8 GB is the workhorse range
- High-concurrency APIs: start at 4 vCPU and pair with autoscaling
Check your monitoring after launch. Lots of idle CPU and memory means you overbought. Start small and grow — most providers let you resize in seconds and refund proportionally when you scale down.
Factor 3: Working out bandwidth
Bandwidth is the easiest thing to get wrong in both directions: too little and things stall, too much and you pay for idle capacity.
Peak bandwidth (Mbps) ≈ page size (KB) × peak concurrency ÷ 1024 ÷ 0.7 So a 300KB first paint with 50 concurrent users is about 21Mbps. Add headroom, pick 30Mbps — or just put a CDN in front.
- Text and API heavy: 1–5 Mbps usually suffices
- Image and video heavy: front it with a CDN and keep 5 Mbps on the origin as fallback
- Downloads and large files: pay per traffic rather than for fixed bandwidth
Factor 4: Billing mode drives long-run cost
| Billing | Best for | Typical saving | Risk |
|---|---|---|---|
| On-demand | Development, spikes, unpredictable load | None | Most expensive over time |
| Monthly / annual | Stable production workloads | ~40–60% | Requires forecasting |
| Reserved / savings plans | Committed one-year load | ~50–70% | Locked-in term |
| Spot / preemptible | Batch jobs, rendering, interruptible work | ~90% | Can be reclaimed |
Practical advice: use on-demand while building, switch to a committed plan once production stabilises. This is how most teams cut cloud spend by 30–50% — not by buying cheaper machines, but by not paying full price for idle hours. How the three commitment types differ, and what it costs to back out early: AWS Reserved Instances and Savings Plans.
Factor 5: Availability and backups
- Confirm whether multi-availability-zone deployment is available for production
- Check that automatic snapshot policies are enabled
- For databases, confirm point-in-time recovery, not just nightly dumps
- Check cross-region replication for off-site disaster recovery
Factor 6: Secure by default
- Never expose SSH to the whole internet — restrict by security group source IP
- Create individual sub-accounts under least privilege; do not share one key
- Enable login alerts and unfamiliar-location notifications
- Shut down machines you no longer need — powered-off instances usually stop incurring traffic charges
Factor 7: The scaling path
Can the setup you pick today grow into the setup you need in six months? Look for two things: smooth resize without rebuild, and native load balancer and autoscaling support. If scaling up means rebuilding the machine, every capacity increase turns into a small migration project.
Factor 8: Support is a hidden cost
Official ticket response times vary widely. When something breaks, whether an engineer can pinpoint it in thirty minutes is often worth more than the few hundred you saved. Treat ticket response time — and whether a human engineer answers — as part of the decision.
Common mistakes
- Comparing price without comparing region — 5× the latency, real conversion loss
- Buying the top spec on day one — the long tail does not need it
- Forgetting bandwidth and egress — usually the biggest surprise on the invoice
- One billing mode for everything — on-demand is cheaper for dev
- Launching without backups — the most expensive mistake on this list
Run your workload through these eight factors and the decision usually becomes clear. After that it is just comparing quotes.