By 2023, global spending on cloud services is expected to increase by roughly 82% compared to 2021 costs. With that amount of increase, keeping costs down is vital and you need an effective right sizing strategy to do that.
You don’t want server instances that are too hot (high cost) or too cold (low performance). While determining the right size and type of your instances may not be completely straightforward, having the right data will help when it comes to finding the instances that are just right.
Aimably can help you find that perfect balance of the size and types of your instances.
Plus no worries about gate-crashing bears. (Server instances don’t actually come with any bears. Sorry.)
This post will cover:
- What does “right sizing” even mean?
- Don’t pay for what you don’t use
- Right sizing best practices to get the highest performance
- Is right sizing the right move?
- So you’ve decided to right size your instances
Let’s look at some options.
What does “right sizing” even mean?
Simple answer is that right sizing gets you more bang for your buck.
In AWS, you choose server instances by type and size. Then you add that server into your infrastructure and use it for workloads. Regardless of how much of the server’s capacity is in use, you still pay per hour for using that server.
If you frequently have leftover capacity, it’s time to look at the instance type or size that you bought initially.
Right sizing, then, is adjusting those types and sizes to match your workload and capacity requirements for the lowest cost possible - finding the server instances that are just right for your business.
Deployed instances are assessed in relation to performance, usage, and workload to identify and eliminate those inactive and idle instances that you’re still paying for.
Optimally-sized resources can reduce your spending by 36% per year, which can add up to $55 million. With right sizing, cutting down those cloud costs is a lot easier than it seems. For example, you probably still have some on-demand instances you used years ago that are now dormant but still raising your costs.
Don’t pay for what you don’t use
Let’s say you decide to start going to the gym. New day, new you, or maybe you just need to get out of your WFH rut and talk to someone other than your dog.
The gym offers several options - pay-as-you-go, monthly, yearly, and so on. You don’t want to get locked into a contract (again) but you’re really committed to it this time so you go for the monthly membership.
You go faithfully for a few weeks, then less faithfully, then not at all. But you’re still paying that membership fee month after month anyway.
A few years down the line, you want to expand your home or you're adding to your family because the dog started to look a little lonely. You have an accountant audit your finances to see exactly where you stand.
Naturally, the accountant reviews all your necessary and unnecessary expenses. When they get to the monthly gym membership, they ask how often per month you go to the gym.
“I haven’t had the time lately,” you say. “I can’t remember the last time.”
The accountant gives you the sort of look that would make even the most frugal squirm in shame. “Why are you still paying for a membership you never use?”
That’s a good question. Why are you paying for something you don’t use?
When it comes to instance purchases, it turns out it’s not so different from that gym membership. Let’s take a look at a few of the common causes of unnecessary spending.
Overprovisioning cloud resources
Companies tend to architect their systems only once; after that, everything is an add-on to the original architecture. Early on, companies can overestimate the amount of resources they ultimately need, but never re-evaluate the estimate later.
There’s also the problem of giving permission to create cloud resources without any governance controls. Without an architect or specialist making those selections, it’s very likely that there will be resources in use that weren’t selected properly.
Migrating existing inefficiencies to the cloud
Companies often don’t assess their current infrastructure for distribution problems so they simply transfer one ineffective system to another platform and don’t get a much different result.
While the “lift and shift” strategy can work when migrating your data, you’ll also lose out on cloud-specific benefits. It can be daunting to consider potentially rebuilding your app entirely, but rearchitecting does come with hyper-specific perks like:
- Increased accessibility via an internet connection
- Predictable costs
- Auto upgrade and maintenance
- Increased scalability
- Deploy changes faster
- More secure than on-premises storage
The long and short of it is: You chose to migrate to the cloud for a reason, so make the best use of what an optimized cloud architecture has to offer.
Where speed is king
The early days of software companies are all about speed: Produce fast, sell fast, grow fast.
Spending is a distant, distant metric while investors and executives emphasize and incentivize getting the company through those first growth stages. As that company scales, it sees higher revenue, greater stability, expanded client base - and an increase in their expenses.
Once the company has (figuratively) learned to walk on its own, priorities need to change. Operations need to be examined for efficiency and performance. Incentives get changed and infrastructure teams need to be able to respond.
70% of startups fail due to scaling too fast, too soon. Quick growth is exciting and rewarding, no doubt about it. Tracking financial performance and efficiencies doesn’t hold a candle to it. But if you want to keep that excitement building, you need to re-evaluate your strategy.
Right sizing best practices to get the highest performance
As I said at the beginning, the right data is key to finding those types and sizes of instances that fit just right for your company.
Collecting that data is pretty simple and very likely you’re already monitoring some - or all - of this data. Now it’s just a matter of putting it to work in the right way.
Know your usage needs
You can’t make an informed decision on how many resources you actually need if you don’t know how many resources you’re actually using.
Analyze your performance data
Keep track of your performance data over a few weeks and compare those metrics to your workload requirements. This will help you determine which instances are underutilized.
Eliminate idle resources
Make sure you fully terminate these underutilized instances so you don’t have extra resources (which you’ll continue to be charged for) lingering in your cloud infrastructure.
Migrate between instance families
An instance could simply be in the wrong place. Before terminating an instance, determine whether or not it’d actually be beneficial to migrate it within the same instance family - or another one entirely.
Continuously monitor your sizing
Right sizing is a continuous process. As your workload and usage changes, your sizing requirements will change, too. There’s no quick fix or one-and-done to maintaining the optimum AWS size.
Is right sizing the right move?
Not everyone is on the bandwagon, however, and it’s worth considering these criticisms. Granted, it’s the lone dissenting voice in a chorus of praise for right sizing, but when the leading authority on AWS billing makes a statement, it’s not a bad idea to hear him out.
While Corey Quinn acknowledges that right sizing makes a lot of sense in theory, his main argument is that the cost savings isn’t worth the labor expense. He has a point.
For larger companies, right sizing doesn’t make sense in practice. Right sizing is all about reviewing instances one by one. Not such a labor-intensive effort for an earlier stage company with a small server footprint, but a larger company is going to be taking on a monolith of established architecture.
In addition, right-sizing best practice may suggest that you change server type, and perhaps even OS. In these cases, you have to consider vendors or divisions that run on specific bundled libraries. If you upgrade the entire OS, what happens to those dependencies? What if the versions are no longer compatible with each other?
Instead of solving one problem, you’ve now created many, many others.
You do have alternatives to right sizing, though. Let’s look at a few before we dive straight into what start-ups and smaller- to mid-sized companies stand to gain from right sizing their instances.
Implement auto scaling
Instead of having multiple instances running all the time for your predicted peak load, use auto scaling configurations to add these resources only when your load demands.
By tracking and monitoring your usage, performance, and workload, these tools help minimize costs and optimize your infrastructure.
When it comes to auto scaling services, you have a pretty decent range of services. AWS offers three native tools that cover the broad range of compute auto-scaling logic, which you can choose from:
Additionally, if you use any of the below services that abstract computing functionality on top of the core compute services, AWS provides native scaling functionality in their configurations as well:
Finally, if you use Kubernetes, AWS recommends you configure scaling using one of these 2 third-party services:
Both services automatically adjust when there are insufficient resources or underutilized clusters. Karpenter’s documentation, however, is much more accessible for a new or inexperienced user.
Spot Instances
AWS allows you to purchase the use of instances that are temporarily available for use instead of permanent assignment, and calls these spot instances. When one spot instance becomes no longer available it can be programmatically replaced with another, with a brief moment of inaccessibility during the switch.
Each specific spot instance has its own price, as a result of current demand, but the price is always cheaper than a conventional instance. Spot instances are great for any non-production scenario or for use in scaling or container cluster additions, where you can guarantee that the base instance is always going to be there but the additional ones are expected to go on and offline regularly.
Keep in mind, Spot Instances are not right sizing; they’re just a pricing technique. But, they make an auto scaling configuration (which is right sizing) come out to the best price.
Reserved Instances
Reserved Instances (RI) don’t necessarily mean you’re getting the right size instance, but it is a way to lower spending.
RIs sacrifice flexibility for predictability: You commit to a usage level and pay the same amount whether you use it all or not.
The discount (Amazon offers up to 72%) makes this an attractive option, but it’s an especially good option if you’re consistently using the same virtual server and monitor usage in order to adjust your RIs appropriately.
If you can’t lock into a set payment contract at the moment, though, RIs are not going to be the best solution.
Lean on the experts
When you embark on right sizing and cost optimization, it’s important to get it right, without causing any unexpected harm along the way. That’s why it can take a lot of time and effort to master these techniques; time you might not have available due to other commitments.
If you find yourself in need of expertise, the team at Aimably will be happy to help. We serve as your embedded AWS financial team. Through tried and true financial planning, reporting, and analysis techniques, our experts develop and maintain cloud financial maturity for you.
In addition to cost optimization and right size analysis services, Aimably offers a suite of software tools to ensure your spending stays on track and matches your budgeted expectations.
So you’ve decided to right size your instances
After weighing all the options, you’ve decided right sizing is the way to go and you’re going to take it on yourselves. Great. Now what?
Well, your best approach is to imagine that you’re moving from physical hardware to the cloud. You’re going to want to analyze all your workloads for the ideal AWS configuration that matches their needs. The good news is that there’s a 5-step workload assessment method designed for data center migrations, which you can easily apply to this project.
Using this method will take some of the complexity out of analyzing your infrastructure and provide a good starting point for analyzing your needs.
- Business impact: Assess the workload and gauge its impact on your business.
- Application architecture assessment: Evaluate application readiness for a cloud environment.
- Technical characteristics: Consider Common integrations/dependencies, integration/interoperability, and customization/support.
- Non-functional requirements (NFRs): Understand how NFRs affect your workload.
- Support and cost: Evaluate the support resources required and the operational costs to determine if there actually is a benefit.
Always keep in mind that right sizing is not a quick process. It takes time and patience to work out which resources can be eliminated and which are still necessary. It’s tempting to immediately jump in when you come across a problem, but spot-fixes are just going to make your cloud architecture more confused and inefficient in the long run.
You don’t want your instances too big or two small, too hot or too cold; you want them to be just right, which is all about responding instead of reacting.
What are you waiting for? Schedule a consultation with Aimably today!
