16 articles on compute — what drives the cost, how it is priced, and where the savings actually are.
Bare-metal servers give you a whole physical machine with no hypervisor overhead; cloud VMs slice physical hosts into virtual instances. For steady, resource-hungry workloads bare metal can be cheaper per unit, but VMs win on flexibility. Here is the comparison with numbers.
Scaling up means fewer, larger instances; scaling out means many smaller ones. The per-vCPU price is often similar, but overhead, granularity, and resilience differ enough to change the total. Here is when each is cheaper, with numbers.
Serverless functions cost nothing when idle and scale to zero, but their per-request price is high; a VM costs a flat hourly rate no matter the load. There is a clear crossover in request volume where a VM becomes cheaper. Here is how to find it.
T-family burstable instances (t3, t4g) are the cheapest EC2 option for low-average-CPU workloads, using a CPU credit system. Understand credits and unlimited mode or you will get throttled or hit with surprise charges. Here is how they cost out.
Dedicated Hosts give you a whole physical server, needed for BYOL licensing and hard isolation, but priced per host regardless of how full it is. Regular instances (and dedicated instances) are cheaper for almost everything else. Here is the cost tradeoff.
EC2 offers dozens of instance families (general purpose, compute, memory, storage, and accelerated) each tuned to a resource profile. Picking the right family for your workload is the first and biggest cost lever. Here is how they map.
An EC2 instance's price combines family and size, region, purchase model (on-demand, Spot, or commitment), operating system licensing, and attached resources. Understanding each component is how you control the largest line on most AWS bills. Here is the full breakdown.
Hosted CI runners are billed per minute and get expensive at high build volume; self-hosted runners on your own compute can cost far less per minute but add operational and idle-capacity overhead. Here is the tradeoff.
AWS Batch adds no charge of its own; you pay for the EC2, Fargate, or Spot compute your jobs run on. Compute environment choice and Spot are the big levers. Here is how to run batch workloads cheaply.
Scale Sets add no charge of their own; you pay for the underlying VMs, disks, and load balancer. Autoscaling rules, instance size, and Spot instances decide the bill. Here is how to tune them for cost without hurting performance.
Spot instances (spare capacity at up to 90% off) can be reclaimed with little notice, so they suit fault-tolerant, interruptible, or checkpointed work. Diversifying pools and handling interruption make them safe. Here is the strategy.
GCP Batch adds no charge of its own; you pay for the Compute Engine VMs it runs your jobs on, including Spot. Spot workers, right-sized machines, and jobs that scale to zero are the levers. Here is how to run batch cheaply.
Elastic Beanstalk adds no charge of its own. You pay for the EC2, load balancer, RDS, and storage it provisions. That means every EC2 cost lever applies, and the environment type quietly decides the bill. Here is what to watch.
Azure Spot VMs run up to ~90% below pay-as-you-go, evictable with 30 seconds' notice. Here's the eviction model, what workloads fit, AKS Spot pools, and how to design for interruption.
App Service Plans bill per instance-hour by tier (B1 ~$13, S1 ~$70, P1v3 ~$120+/mo) times instances. Apps share a plan for free. Here's how to pick the tier and why consolidating apps is the big saving.
Spot VMs run 60-91% below on-demand for the same machine type, preemptible at any time. Here's what belongs on Spot, how it differs from preemptible, Spot GKE pools, and how to design for preemption.