You wouldn’t buy an industrial dumpster for your kitchen, and you don’t need an EC2 T3 to do an M5d’s job.
According to the FinOps Foundation:
“Rightsizing is a form of optimization where measurements are taken over time to assess the periodic requirements of a workload running in the cloud, and to match it to a virtual resource which is sized to run it efficiently with a minimum of waste.”
And: “It is important to measure actual workload demand in small increments rather than using average load figures to be sure that workloads requiring larger instances for peak demand are accommodated. Rightsizing can be used as a technique to save cost but must always involve technology oversight as well.”
Rightly, rightsizing is a core practice of healthy FinOps. Gauging the size of the resource to the size of the job is an engineering precept as timeworn as building itself.
Rightsizing is a core practice of healthy FinOps. Gauging the size of the resource to the size of the job is an engineering precept as timeworn as building itself.
But because of how intuitive that fundamental truth is, people often think of rightsizing as easy. Just assess the job size over some interval, compare that to the available resources, and pick the resource that matches. The math appears so simple that people often choose to automate rightsizing, and many tools promise that all you have to do is flip a switch and watch the savings roll in.
I once heard a great FinOps story about an engineer accidentally spending hundreds of thousands of dollars when trying to save $8,000, and I know firsthand that rightsizing is anything but simple. When you select a cloud resource, you’re not just making a cost decision, you’re making a business decision. Cost is a key consideration of savvy business investment, but so are performance, governance, compliance, ROI, and more.
Done right, rightsizing can offer a friendly margin boost. Done wrong, it can land you in all kinds of hot water. I’ve made — and learned from — a number of rightsizing mistakes in my career. In this article, I outline the numerous tradeoffs of rightsizing, and how to avoid its unintended repercussions.
4 Key Tradeoffs Of Rightsizing
1. Cost vs. Performance
Earlier in my career, my team and I were looking at optimizing database workloads. The databases we were working on were processing an enormous amount of data, but it seemed easy enough to look at their utilization rates, notice they looked low, and decide to shrink them.
The problem was, my team was looking at the utilization rates on a daily basis, not an hourly basis. What we didn’t realize was that most of our users were accessing the system around 8 a.m., which meant utilization spiked at that hour and flattened out the rest of the day. The utilization metric in our sights before we “rightsized” was therefore a misleading average of these varying rates.
Maybe by now you can guess what happened. We shifted to a smaller resource which couldn’t handle the 8 a.m. spike, and we ended up with a litany of negative side effects. The burden shifted to other downstream parts of the system, which of course hadn’t been selected to accommodate that level of performance.
They failed too, and we wound up with an extremely costly outage that we had to waste yet more engineering time addressing.
We shelled out hundreds of thousands of dollars in customer credits to atone for the performance nightmare. We were trying to save about $8,000 per month, and our efforts wound up costing us hundreds of thousands.
Your lesson
Before you rightsize, you need an extremely granular understanding of what level of performance is required of which resources, and when. Hourly granularity is the gold standard. Be very careful, especially before entrusting this whole process to an automaton.
2. Cost vs. Governance
Another time, I was looking at rightsizing our cloud storage resources. There was data that our technical teams accessed pretty infrequently and, with such low retrieval rates, it seemed intuitive that we could afford to store the data in resources where storage cost less and retrieval cost more.
But this would have run us into a governance issue. It turned out this data was critical to monthly and quarterly reporting, and shifting it to those seemingly less expensive storage resources would have blown up our finance team’s month- and quarter-end accounting processes.
Not only would this have added stress to already stressful periods, it would also have made them more expensive. You can’t retrieve data in those resources immediately unless you pay more, sometimes as much as 10x the cost to retrieve it at the default speed.
Your lesson
In addition to what your data costs, you need to understand who’s using it, when, and how. Sometimes, you’re paying for governance convenience that would be costly in terms of time, money, and risk to forgo.
3. Cost vs. Compliance
Moreover, in addition to using, storing, and analyzing your data, you’re probably paying for some form of regulatory compliance. Companies in the healthcare space need their data to conform to HIPAA, which has extensive encryption requirements. Companies operating in Europe need to abide by GDPR. Falling afoul of these or any regulatory requirements can be extremely costly.
For example, a company based in the US but operating in the EU might be tempted to store their data on native shores, where they have more hardware. But this would expose them to GDPR risk, which could mean surrendering 2%–4% of their annual revenue.
Your lesson
Develop a deep understanding of what regulations your data is subject to, and make them a part of any rightsizing conversation.
4. Cost vs. ROI (Direct And Indirect)
At the end of the day, every cost conversation is really a business conversation, and should be framed in terms of what you’re getting in return. As CloudZero’s co-founder and CTO Erik Peterson posits: the question shouldn’t be “What did it cost?” but rather, “Was it worth it?” The only way to answer that question is to have a clear understanding of direct and/or indirect ROI.
By “direct ROI,” I mean revenue. Comparing cloud costs to cloud-driven revenue is a key component of cloud unit economics. The companies with the most mature cloud unit economics practices can break down cloud costs vs. cloud revenue by any number of dimensions, including customer, product, feature, team, and more.
By “indirect ROI,” I mean all the nonfunctional requirements — reliability, sustainability, performance, convenience — that go into building great software. It’s harder (though not always impossible) to put a dollar value on this, but you can sure feel it when it’s gone.
Your lesson
Develop systems by which you compare your cloud costs with your cloud ROI. (I happen to know a cloud cost optimization platform that’s excellent at this.)
Rightsizing Done Right
People need to stop thinking that rightsizing is simple, or easy, or something they can do without thinking. As a holistic practice, it’s just not something you can outsource to a robot without opening yourself up to all kinds of risk.
Not every rightsizing decision will require you to assess all of this risk. But many will, and the more fortified your processes are against incurring unnecessary vulnerabilities, the more you’ll do rightsizing right.
More on rightsizing: The 6-Step Guide To Rightsizing Your Instances In 2025
The Cloud Cost Playbook
The step-by-step guide to cost maturity
