In a quiet move yesterday, Amazon Web Services apparently abandoned their Elastic Compute Unit (ECU) approach to describing and selling EC2 instance types and towards a more traditional vCPU approach. This was done without any formal announcement and I wonder what effect it will have (positively or negatively) on customers.
For existing AWS customers that have grown accustomed to ECU over the course of the past years, this could be a somewhat disruptive change, especially for those at larger scale that have invested a lot of time and money optimizing instance size and horizontal scalability based on their own performance testing and analysis of which kind and how many EC2 instances they need for their use case. Initially, this may not matter much for existing deployments, but it will have an impact on scaling out or for new use cases. Bottom line – these types of customers are pretty savvy and will find ways to adjust.
For new or prospective AWS customers, the ECU was always a gnarly concept to grasp and it took time. More traditional deployments, like those based upon VMware were always declared with vCPU. Bottom line – more traditional IT Ops admins and new AWS customers will likely welcome this move as a move toward familiarity and simplicity.
However, for all customers, there is one aspect of this that could be problematic. AWS is a massive scale cloud provider, with a wide variety mix of servers and processor architectures in existence. Therefore, two instances each with 2 vCPU will not necessarily be equivalent. One instance could reside on top of a 2012-based processor while the other could reside on top of a 2014-based processor. Many people have written about the fact that EC2 processor architecture varies across instance types and across regions, even those described as having the “same specs”. Therefore, some savvy organizations have moved to a “deploy and ditch” strategy whereby they deploy many instances, interrogate them all for processor architecture and then ditch all the ones that are not up to current or fastest specs.
This will further escalate an important transparency event for AWS. AWS will need to clarify the physical processor architecture strategy per instance type or instance family. As a customer, I will want to know which instance types are based on Sandy Bridge processor architectures for example – because that tells me what a vCPU will equate to. I will want to know the processor strategy similarities/differences between an m2 and an m3 or between an m3.medium and m3.large. And if there are no differences – I will want to know that also and have something in writing stating as such. Customers wanted this before with ECU, but ECU gave AWS a way to deflect these customer questions.
ECU was a foreign concept to grasp initially, but it did provide one benefit – a standard of measure. Now that AWS has moved to a vCPU strategy will customers applaud this or complain? I’d love to hear your thoughts in the comments below.
Read Complimentary Relevant Research
2019 Planning Guide Overview: Architecting Your Digital Ecosystem
Technical professionals are confronting increasingly complex technology ecosystems. They must overcome this complexity to create solutions...
View Relevant Webinars
How Analytics, APIs, and Cloud Will Drive CRM/CX in 2018
Customer relationship management (CRM) drives the customer experience, which drives revenue and retention, which drives investment and...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.