Rightsizing instances and storage options

Key role(s)


Eliminate waste by choosing the right families, sizes and resources options


Expenses reduction

Rightsizing allows you to regain control of expenses by eliminating obvious waste in instances and storage used.

Many tools can help to do this:

  • AWS Trusted Advisor
  • Azure Advisor
  • Google Cloud
  • CloudHealth
  • Turbonomic
  • Apptio
  • Cloud Checkr
  • Lota.Cloud
  • Teevity
  • ...

It is of course possible to do this work yourself by analyzing the use of each instance and deducing the best choices of instances, but the combinations are very numerous and there can be bottleneck factors that are difficult to detect with the eye. We always think about CPU and memory but what about IOPS? A tool can clearly help.

And it's not just a question of looking at VMs but also of asking the question about storage: what is the right class to use, what options, so that the service is delivered at the best price and without unnecessary waste.

Once the list of recommendations has been made, we have to analyze them and validate the changes : A tool can also be wrong or to be more precise may not be able to anticipate an increase in activity that you anticipated.

Finally, you must plan and execute the validated changes through your usual governance. Here is what the process can look like at a very high level:

High level process of instance and storage right sizing
High level process of instance and storage right sizing

Case of AWS

AWS EC2 has different families of instances.

  • For general use: A1, T2, T3, M4, M5
  • Optimized for computing: C4, C5
  • Optimized for memory: R5, R4, X1
  • Optimized for accelerated computing : P2, P3, G4, G3, F1
  • Optimized for storage: D2, I3, H1

Within each family, there are different sizes (micro, small, medium, large, xlarge, 2xlarge, 4xlarge...) which double in size each time.

For example, we can have selected a c4.2xlarge instance to cover an estimated need of 8GHz CPU and 11GB of Memory. Then realize that the maximum used is 1.5 GHz CPU and 7.5GB of memory. An M1.large instance would cover this requirement for half the cost. But we shouldn't stop there because M1 instances are first generation and there are new types with improved performance for a lower price. In our case an M4.large instance would be a better choice.

But we can go even further by looking for "burstable" instances, which do not have fixed performance like M4. A t2.large for example is normally limited to 60% of 2 CPUs but can be increased up to 2 if needed by using "credits". It is therefore possible to further reduce costs if this type of instance meets the need (76% cheaper than the initial c4.2xlarge).

See previous card

Monitoring the effectiveness of the optimizations

ID 1R1

See next card

Reserving instances

ID 1O2