Right Sizing - assessing current cloud builds and the execution performance

Definition - Right sizing is the process of matching instance types and sizes to your workload performance and capacity requirements at the lowest possible cost. ... Speed and performance are often prioritized over cost, which results in oversized instances and a lot of wasted spend on unused resources.

Picking of the right instance type and size, by way of deciding on the instance family and best attributes, usually in terms of cpu, memory and processing power, to match your application needs and performance, is not simple, but it’s also not black magic.

The usual situation is that when an application is not performing to the desired speed, application development up-sizes the instance provision. But the resulting situation is that much of what is built in the cloud is provisioned too large, over-sized, and does the job, but, has a low utilisation.

There are four primary aspects to a server instance ( or database instance ) utilisation – its CPU usage, memory usage, network throughput and data throughput. And then of course there is daily load – times of peak demand, compared to times of medium and low. If your application build is not scalable ( to align with load demands ), and not microservices architected and even serverless, then your need ( and application performance and thus customer experience of the application function delivered ) needs to at least meet and perform well at the peak demand.

But at this peak demand, if all four of the primary aspects register as low usage ( CPU less than 40%, low data throughput, low disk usage, low memory usage ) – then it means the provisioned instance IS TOO LARGE !

As example – if in AWS the provisioned instance is a .4xLarge – then downsize it to a .2xLarge – and check the statistics of usage again for a period of hours and days. Perhaps it can be reduced further to a .xLarge. SO when an instance is running a peak of 15% say, reducing the instance size by half will at most likely put CPU utilisation at 30%, so another reduction to 60% utilisation. Confirming application function timing and user experience will confirm that even at 60% CPU – no degradation is seen.

Checking logs and monitor statistics ( like AWS Trusted Advisor, or Optimisation Opportunity analytics, or even CloudWatch utilisation logs will enable all the deep analysis of actual utilisation that is taking place.

Meanwhile compute consumption costs have been halved or better quartered.