Cloud cost optimization is the discipline of reducing the cloud bill without reducing the workload. The ten things that actually move the bill are not the ones most teams think. The biggest savings come from the architectural decisions, not from the spot instance or the savings plan.
Table of contents
- The two cost levers
- Right-size the compute
- Pick the right storage tier
- Cache the egress
- Tune the database
- Schedule the dev environment
- FAQ
The two cost levers
The cloud bill has two levers:
- The unit cost. The cost per GB, per CPU-hour, per request. The lever is the SKU choice (on-demand vs. reserved, standard vs. infrequent access).
- The volume. The number of GB, the number of CPU-hours, the number of requests. The lever is the architecture (the size of the instance, the size of the database, the number of requests).
Most teams focus on the unit cost. Most of the savings are in the volume.
Right-size the compute
The first thing to check: are the instances right-sized? The team that has a workload that peaks at 20% CPU on an 8-core instance is paying for 80% of the CPU they are not using.
The right answer is usually to right-size the instance, not to move to spot. The savings on right-sizing are typically 30-50%; the savings on spot are 50-70% on top of right-sizing.
Pick the right storage tier
The third biggest cost in most cloud bills is storage. The team that has a workload with 1 TB of data on S3 Standard is paying $23/month. The same data on S3 Glacier Instant Retrieval is $4/month. The same data on S3 Glacier Deep Archive is $1/month.
The right answer depends on the access pattern. Data that is accessed once a year should be on Glacier Deep Archive. Data that is accessed once a month should be on S3 Standard-IA. Data that is accessed every day should be on S3 Standard.
Cache the egress
The fourth biggest cost is usually egress. The team that has a workload serving a lot of data to the internet is paying $0.09/GB for the egress. The right answer is to cache the egress with a CDN (CloudFront, Cloudflare, Fastly).
A CDN reduces the egress bill by 70-90% for workloads with a hot spot in the data. The savings on a workload serving 10 TB/month can be $900/month - more than the cost of the CDN itself.
Tune the database
The fifth biggest cost is usually the database. The team that has a workload running an oversized database instance is paying for CPU and memory they are not using. The right answer is to right-size the database, add an index, or move to a smaller instance.
The trap: the team tunes the database, the workload gets faster, and the team adds more features that use the freed-up capacity. The bill is the same. The right answer is to right-size, not to tune, and to keep the freed-up capacity as a buffer for the next month.
Schedule the dev environment
The sixth biggest cost is usually the dev environment. The team that has 50 dev instances running 24/7 is paying for 50 dev instances. The right answer is to schedule them: turn them on at 9am, turn them off at 6pm, and turn them on again on Monday morning.
The savings on a 50-instance dev environment that is scheduled to run 50 hours a week instead of 168: 70%. The team that does not do this is paying for dev capacity that is sitting idle 70% of the time.
Use spot and savings plans
The seventh biggest cost is the on-demand premium. The team that has a workload running on on-demand instances is paying 2-3x the price of the same workload on a 1-year savings plan.
The right answer: a 1-year savings plan for the baseline, spot for the burstable workloads, and on-demand for the short-lived test instances. The savings on a typical workload are 30-50%.
Delete the unused
The eighth biggest cost is usually the unused. The team that has 100 GB of unattached EBS volumes, 50 unused Elastic IPs, 1000 orphaned snapshots is paying for resources that are doing nothing.
The right answer: a monthly audit of unused resources, automated deletion of unattached volumes, and a policy that requires every resource to be tagged.
Tune the network
The ninth biggest cost is usually the network. The team that has a workload sending traffic across availability zones is paying for the cross-AZ transfer. The team that has a workload sending traffic across regions is paying 10x more.
The right answer: deploy the workload in a single availability zone if the workload is not latency-sensitive, deploy the database across zones if the database is the source of truth, and use a CDN for the internet-facing traffic.
Measure the cost per customer
The tenth biggest cost is usually the cost-per-customer that the team does not know. The team that has a workload serving 1000 customers does not know which customers are profitable and which are not.
The right answer: tag every resource with the customer it serves, build a cost-per-customer report, and use the report to make product decisions. The team that does this discovers that 20% of the customers are unprofitable and the workload is subsidized by the other 80%.
FAQ
What is cloud cost optimization?
The discipline of reducing the cloud bill without reducing the workload. The biggest savings come from the architectural decisions, not from the unit-cost levers.
What is the biggest cost optimization in the cloud?
Right-sizing the compute. Most teams have instances that are 2-3x larger than they need to be. Right-sizing typically saves 30-50%.
What is the difference between right-sizing and tuning?
Right-sizing reduces the size of the resource. Tuning reduces the workload on the resource. The two are complementary; right-sizing is the higher-impact lever.
How do I get started with cloud cost optimization?
Start with right-sizing the compute, then move to the storage tier, then to the egress, then to the database. The order is by impact; the savings are 30-50%, 30-50%, 70-90%, 30-50%.
What is FinOps?
FinOps is the practice of bringing financial accountability to the cloud spend. It is the discipline of making the trade-off between cost and performance a conscious, data-driven decision.
If you are sizing a cloud cost optimization project, the RunxBuild hosting calculator is the place to model the line items. The compute, the storage, the egress, the database - each one is a separate number, and the team’s mental model for the project is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual cost in one place.