Cost-Optimized Compute

EC2 pricing gives you a lever for every level of commitment. On-Demand charges by the second with no upfront commitment — the default, and the right starting point for a new or unpredictable workload. Spot Instances request unused EC2 capacity at savings AWS describes as up to 90% off On-Demand, in exchange for the instance being reclaimed on short notice — a fit for fault-tolerant, flexible work like batch processing or stateless workers, never for anything that can't handle an interruption. Reserved Instances commit to a specific instance configuration (type and Region) for a 1- or 3-year term for a significant discount. Savings Plans commit instead to a dollar amount of usage per hour, for the same 1- or 3-year terms, but apply automatically across instance families, sizes, and (for Compute Savings Plans) even AWS Lambda and Fargate — more flexible than a Reserved Instance's fixed configuration, in exchange for committing to spend rather than to a specific instance.

aws ec2 run-instances \
  --instance-market-options '{"MarketType":"spot"}' \
  --image-id ami-0abcdef1234567890 \
  --instance-type c7g.xlarge

Matching the purchasing option to the workload is the actual skill being tested. A steady-state production fleet that runs the same instance type around the clock is the textbook case for a Reserved Instance or Savings Plan — the commitment matches reality, so the discount is close to free money. A workload whose instance types or Regions might change over the commitment period fits a Savings Plan better than a Reserved Instance, precisely because it isn't locked to one configuration. A batch job, CI runner, or anything that can checkpoint and resume fits Spot. A brand-new workload with unknown, still-settling usage patterns should start On-Demand and move to a commitment only once the usage is predictable enough to commit to.

Sizing matters as much as purchasing option: an oversized instance running at 10% CPU utilization wastes money no discount fixes. For workloads that run on a predictable schedule — a nightly batch job, a dev environment nobody uses overnight — EC2 hibernation or simply stopping instances outside their working hours avoids paying for idle compute at all, which beats any purchasing discount on the hours you don't need.

Load balancer choice affects cost too, not just capability. An Application Load Balancer and a Network Load Balancer are priced similarly, by the hour plus a usage-based dimension — the cost driver is running more load balancers than needed, not which type you pick for a workload that genuinely needs layer 7 or layer 4 features. A Gateway Load Balancer specifically routes traffic through third-party virtual appliances (like a firewall) and is priced for that use case; reaching for it without an actual appliance to route through adds cost with no benefit.

On the compute side, Fargate Spot extends the same interruption tradeoff to serverless containers: significant savings for fault-tolerant container workloads, without managing EC2 Spot capacity yourself.