Picking the right EC2 instance family and type requires the consideration of multiple factors. It’s no wonder why many organizations that have moved quickly into AWS, without taking the time to fully understand how to architect applications for both cost and performance, are waking up with significant budget over runs.
But who can blame all those development teams? After all, everywhere I turn these days there are signs from AWS telling me to build faster or somebody will disrupt my business model.
With all this pressure who has time to wait and consider all of the factors that go into selecting the right EC2 instance? And to consider whether performance or cost are top of mind at that moment.
As we’ve discussed before the performance and cost considerations are multidimensional. On the performance side application resource demands include memory, CPU, network and disk I/O. On the cost side of the equation you need to take into account On-Demand vs. Reserved Instance pricing as well as your existing RI inventory.
In our 6.1 release we’ve made significant improvements to our vertical scaling actions across AWS and Azure as well as how to manage those actions based on tags and account or subscription based view.
I’d like to go a bit deeper on the AWS EC2 performance side and the dimensions we’ve added to our scaling decisions. When you select an EC2 instance family and type you are making a decision around CPU both the underlying hardware generation, represented as Elastic Compute Units (ECUs) and the number of cores. You’re also selecting a memory capacity anywhere from 2GiB to 3904 GiB. Turbonomic’s scaling decisions, up and down, have taken those dimensions into account as well as the on-demand pricing.
With 6.1 we’ve added network dimensions including overall communication bandwidth dedicated network the EC2 instance has to communicate with EBS.
Consider a continuous I/O intensive workload like a database or a batch process that runs once a day and needs to right a bunch of info to the disk. AWS offers EBS optimized templates with a dedicated network channel for those communications and a separate network channel for communicating with other services inside or outside the region.
With non-EBS optimized, the same network channel is used for both types of communications. Communications to the EBS volume and to any other services external to the EC2 instance. See the figure below.
EBS Optimization is offered on select EC2 instance families and types. For newer generations it comes free of charge and for older ones there is an additional cost. So going to EBS optimized is not always the right option. Sometime its free and sometime it will cost you.
With Turbonomic’s common abstraction model and analytics engine we consider all of the possible scenarios. If I/O throughput warrants a dedicated channel, we’ll scale to an EC2 instance that supports it and turn on EBS optimization as needed. If demand characteristics warrant one network channel, we’ll take that into account in our scaling decision.
And as you probably know by now, those scaling decisions are never done in isolation. They are based on taking all of the resource demands into account and satisfying them at the lowest possible cost. Including taking into account any current or future reserved instances.
But here is the best part: There is no threshold to set up or a minimum amount of time to collect data and provide you with decisions. You can spin up a Turbonomic instance in minutes and you’re all set up.
So you don’t have to ask your development teams to slow down and risk being disrupted but you do need to Turbonomic to your stack or risk giving your finance team a headache or your end-users unacceptable performance.