Before I try to break down the AWS and Azure cloud pricing jargon, let me give you some context. I am a crusty, old CTO who has been working in advanced technology since the 1980’s. (That’s more than 18 Moore’s Law cycles for processor and chipset fans, and I have lost count of how many technology hype cycles that has been.)
I have grown accustomed to the “deal of a lifetime” on the “technology of the decade” coming around about once every week. So, you can believe me, when I tell you have a very low BS threshold for dishonest sales folks and bogus technology claims. Yes, I am jaded.
My latest venture is a platform, ParkMyCloud, that brings together multiple public cloud providers. And I can tell you first hand that it is not for the faint-of-heart. It’s like being dropped off in the middle of the jungle in Papua, New Guinea. Each cloud provider has its own culture, its own philosophy, its own language and customers, its own maturity level and, worst of all — its own pricing strategy — which makes it tough for buyers to manage costs. I am convinced that the lowest circles of hell are reserved for people who develop cloud service pricing models. AWS and Azure cloud pricing gurus, beware. And reader, to you: caveat emptor.
AWS and Azure Terminology Differences
Case in point: You have probably read the comparisons of various services across the top cloud providers, as people try to wrap their minds around all the varying jargon used to describe pretty much the same thing. For example, let’s just look at one service: Cloud Computing.
In AWS, servers are called Elastic Compute Cloud (EC2) “Instances”. In Azure they are called “Virtual Machines” or “VMs”. Flocks of these spun up from a snapshot according scaling rules are called “auto scaling groups” in AWS. The same things are called “scale sets” in Azure.
Of course cloud providers had to start somewhere, then they learned from their mistakes and improved. When AWS started with EC2, they had not yet released virtual private clouds (VPCs), so their instances ran outside of VPCs. Now all the latest stuff runs inside of VPCs. The older ones are called, “classic” and have a number of limitations. The same thing is true of Azure. When they first released, their VMs were not set up to use what is now their Resource Manager or be managed in Resource Groups (the moral equivalent of CloudFormation Stacks in AWS). Now, all of their latest VMs are compatible with Resource Manager. The older ones are called, you guessed it … “classic”. (What genius came up with the idea to call the older versions of these, the ones you’re probably stranded with and no longer want, “classic”?)
Both AWS and Azure have a dizzying array of instances/VMs to choose from, and doing an apples-to-apples comparison between them can be quite daunting. They have different categories: General purpose, compute optimized, storage optimized, disk optimized, etc.
Then within each one of those, there are types or sizes. For example, in AWS the tiny, cheap ones are currently the “t2” family. In Azure, they are the “A” series. On top of that there are different generations of processors. In AWS, they use an integer after the family type, like t2, m3, m4 and there are sizes, t2.small, m3.medium, m4.large, r16.ginormus (OK, I made that one up).
In Azure, they use a number after the family letter to connote size, like A0, A1, A2, D1, etc. and “v1”, “v2” after that to tell what generation it is, like D1v1, D2v2.
The bottom line: this is very confusing for folks moving their workloads to public cloud from on-premise data centers (yet another Wonderland of jargon and confusion in its own right). How does one decide which cloud provider to use? How does one even begin to compare prices with all of this mess? Cheer up … it gets worse!
AWS and Azure Cloud Pricing – Examining Differences in Charging
To add to that confusion, they charge you differently for the compute time you use. What do I mean? AWS prices their compute time by the hour. And by hour, they mean any fraction of an hour: If you start an instance and run it for 61 minutes then shut it down, you get charged for 2 hours of compute time. Microsoft Azure cloud pricing is listed by the hour for each VM, but they charge you by the minute. So, if you run for 61 minutes, you get charged for 61 minutes. On the surface, this sounds very appealing (and makes me want to wag my finger at AWS and say, “shame on you, AWS”).
However, you really have to pay attention to the use case and the comparable instance prices. Let me give you a concrete example. I mentioned my latest venture, ParkMyCloud, earlier. We park (schedule on/off times) for cloud computing resources in non-production environments (without scripting by the way). So, here is a graph of 6 months worth of data from an m4.large instance somewhere in Asia Pac. The m4 processor family is based on the Xeon Broadwell or Haswell processor and it is one of the most commonly used instance types.
This instance is on a ParkMyCloud parking schedule, where it is RUNNING from 8:00 a.m. to 7:00 p.m. on weekdays and PARKED evenings and weekends. This instance, assuming Linux pricing, costs $0.125 per hour in AWS. From November 6, 2016 until May 9, 2017, this instance ran for 111,690 minutes. This is actually about 1,862 hours, but AWS charged for 1,922 hours and it cost $240.25 in compute time.
Why the difference? ParkMyCloud has a very fast and accurate orchestration engine, but when you start and stop instances, the cloud provider and network response can vary from hour-to-hour and day-to-day, depending on their load, so occasionally things will run that extra minute. And, even though this instance is on a parking schedule, when you look at the graph, you can see that the user took manual control a few times. Stuff happens!
What would the cost have been if AWS charged the same way as Azure? It would have only cost $232.69. Well, that’s not too bad over the course of six months, unless you have 1,000 of these. Then it becomes material.
However, I wouldn’t rush to judgment on AWS. If you look at the comparable Azure VM, the standard pricing DS2 V2, also running Linux, costs $0.152/hour. So, this same instance running in Azure would have cost $290.39. Yikes!
Therefore, in my particular use case, unless the Azure cloud pricing drops to make their CPU pricing more competitive, their per minute pricing really doesn’t save money.
The ironic thing about all of this, is that once you get past all the confusing jargon and the ridiculous approaches to pricing and charging for usage, the actual cloud services themselves are much easier to use than legacy on-premise services. The public cloud services do provide much better flexibility and faster time-to-value. The cloud providers simply need to get out of their own way. Pricing is but one example where AWS and Azure need to make things a lot simpler, so that newcomers can make informed decisions.
From a pricing standpoint, AWS on-demand pricing is still more competitive than Azure cloud pricing for comparable compute engine’s, despite Azure’s more enlightened approach to charging for CPU/Hr time. That said, AWS really needs to get in-line with both Azure and Google, who charge by the minute. Nobody likes being charged extra for something they don’t use.
In the meantime, ParkMyCloud will continue to help you turn off non-production cloud resources, when you don’t need them and help save you a lot of money on your monthly cloud bills. If we make anything sound more complex than it needs to, call us out. No hiding behind jargon here.
Azure vs. AWS 2017: what’s the deal? There’s been a lot of speculation lately that Microsoft Azure may be outpacing Amazon Web Services (AWS). We think that’s interesting and therefore worth taking a look at these claims. After all, AWS has been dominating the public cloud market for so long, maybe the media is just bored of that story, and ready for an underdog to jump ahead. So let’s take a look.
Is Azure catching up to AWS?
You may have seen some of the recent reports on both Microsoft and Amazon’s recent quarterly earnings. There have certainly been some provocative headlines:
With Amazon and Microsoft reporting their quarterly earnings at the same time, this is a good time to analyze the numbers and see where they stand in relation to one another. Upon closer inspection, here’s what the recent quarterly earnings reports showed:
AWS revenue grew 43% in the quarter, with quarterly earnings of $3.66 billion, annualized to $14.6 billion. Sales and earnings exceeded expectations given by analyst estimates. In the immediate wake of Amazon’s report, the stock went up.
Microsoft reported that its Intelligent Cloud division grew 11% to $6.8 billion, and that the Commercial Cloud division has a annualized run rate of $15.2 billion. These reported earnings only met analyst expectations, and therefore the stock fell by nearly 2 percent within hours.
We think it’s important to note when it comes to Microsoft’s reported earnings the Commercial Cloud business includes Office 365, not just Azure. We have never fully understood why the Office 365 business has been bundled in with Commercial Cloud, given that it’s a very different business than the IAAS services of Amazon and Google to which it is often compared.
Microsoft stated that Azure’s growth rate was 93%, without providing an actual revenue number. Once again, we find this lack of lack of earnings clarity somewhat problematic.
So is Azure bigger than AWS?
Well, currently no. There is little evidence of Azure surpassing AWS, aside from a small research study which pales in comparison to a clear majority of data stating otherwise.
But is Azure growing quickly?
Yes. In this regard, it’s important to consider what factors are at play in Azure’s growth, and whether they hold any weight as far as surpassing Azure outpacing AWS in the future.
Where is Azure actually gaining ground?
Now let’s take a look at what is driving Azure’s growth, and where Azure is gaining ground.
First of all, as companies grow beyond dipping their toes in the water of public cloud, they become more interested in secondary options for diversity and different business cases. Just from our own conversations, we’re finding that more and more AWS users are using Azure as a secondary option. While users might be interested to see what Azure can offer them in comparison, this doesn’t necessarily indicate that it will ultimately surpass AWS.
Take, for example, the results of aresearch survey released by data analytics providerSumo Logic and conducted by UBM Research. According to the survey of 230 IT professionals from 500+ employees, Azure actually beat AWS as the preferred primary cloud provider, taking the lead by a 10 percent margin, with 66 percent of participants preferring Azure as opposed to the 55 percent who relied in AWS.
This research is significant because it’s the first time that survey data on customer preferences has reported Azure taking a lead over AWS. However, the data also revealed that a significant number of enterprises are using more than one cloud provider. While Azure and AWS both take the lead, there is certainly an overlap in participants who use both, in addition to other up-and-coming providers.
Second, enterprises have been committed to a variety of Microsoft products for years. According to UBM Research survey data, over 50 percent of participants who preferred Azure as their primary cloud provider were coming from large enterprises with 10,000+ employees. This makes sense considering that Microsoft has a foothold in terms of relationships and enterprise agreements with these larger organizations and are able to cross-sell Azure.
Third, Azure has a strong base in Europe, where more users report using Azure rather than AWS as their primary provider. In a 451 Research Survey with 700 participants considered to be “IT decision makers,” AWS topped the list among all participants as the preferred provider among 39 percent of participants. While Azure saw an increase in users, it still landed in second place overall at 35 percent. However, among the European participants only, Azure took the top spot, with 43.7 percent naming Azure as their provider, and 32 percent sticking with AWS.
Why does the Azure vs. AWS debate matter?
Why does the Azure vs. AWS 2017 debate matter to, when choosing a new or secondary cloud provider? Well… in terms of market performance, it probably doesn’t. As always, the specific needs of your business are going to be what’s important.
One thing is for certain: the public cloud is growing and it’s here to stay. Let’s not forget that both Google and IBM both have growing public cloud offerings too (and Google is looking to expand their enterprise market this year.) All of this competition drives innovation, and therefore IaaS and PaaS offerings – and perhaps, better pricing.
For the customer, the basic questions remain the same when evaluating public cloud providers:
How understandable are the public cloud offerings to new customers?
How much do the products cost?
Are there adequate customer support and growth options?
Amazon Web Services (AWS) monthly bills start arriving in inboxes the world round about this time every month. When they do, there are two questions we like to ask AWS users.
One, did you look at your AWS bill?
For some readers, the idea that you might not is ridiculous. You may be surprised how many companies we’ve talked to where even key decision makers are unsure how much they are spending on cloud services. (Mature cloud users are more likely to worry about spend, as found by RightScale’s 2017 State of the Cloud Report, but that doesn’t mean that even those users have their eye on the bill each month.)
Okay, so let’s assume that you have looked at your AWS bill. Time for the second question. Was your AWS bill more than you expected this month?
For more and more cloud users, the answer is yes. Only 46% of enterprises monitor and rightsize cloud resources – which means 54% do nothing. Between resources left running when they’re not needed, incorrectly sized resources, and orphaned volumes, it’s easy for bills to climb out of control.
I’m a fan of automation – as a CEO, I think you should do everything possible to simplify your day-to-day, whether that means you overhaul your calendar system or automate tasks in AWS.
Amazon themselves is great at this. I’m sure you are well aware of Amazon’s quest for automation in their warehouses (robots) and distribution (drones) to reduce costs and deliver packages faster. (That’s a great goal, by the way – I am an Amazon Prime customer – love it.) If you’re interested in Amazon’s robots, check out this article from Business Insider. And as the use of drones to deliver product becomes reality, Amazon has created a service – check out Amazon Prime Air if you haven’t already.
So let’s look at another branch of Amazon – Amazon Web Services (AWS). AWS is a large distributor of cloud, which in and of itself is actually a utility that can be used on demand to provide compute, database, and storage services to small and large companies alike. It’s just like the way utility companies provide electricity, water and heat to homes and business. Over time, features and services have been built and sold to optimize these traditional utilities in order to simplify mundane tasks via automation and achieve ROI by saving more money than cost. Here are a few examples:
Nest to detect, learn, and automate programmable thermostats to save on heating and cooling
In-office motion sensors to detect movement to turn lights off/on
Motion sensors on faucets and hand dryers to eliminate water and electric waste
Gadgets on showers, toilets, etc. to reduce water consumption and waste
The point is, all of these utilities need to be optimized with 3rd party technologies to automate and reduce waste, and to optimize spend. At home, you’re the CFO (or maybe your spouse is 🙂) but you don’t want to spend more than you need to, and you will buy technology to automate mundane tasks and save yourself money if there is a tangible ROI.
Amazon is doing this with robots and drones – neither of which they built. So why not use 3rd party technology to automate for AWS, Azure, and Google Compute. Remember that the public cloud is a utility, and utilities have waste. In public cloud, what can we look at that’s mundane, that can be automated and where you can save dollars on cloud waste?
I have a simple one – automate tasks in AWS by turning servers off and on. Did you know that on average, 66% of what you spend on the public cloud is on compute (servers), and 45% of that is on non-production systems like development, test, and QA – servers that’s don’t need to run 7×24. That’s $6B in waste per year.
Even better than Nest, which you can install and set up in 30 minutes, ParkMyCloud can be setup and configured in 15 minutes or less. The next day, we will tell you how much you saved in the previous 24 hours by simply automating the mundane task of turning idles servers on/off with schedules.
There’s a reason Amazon is so successful – they automate mundane tasks in a simple, efficient way, follow their lead – automate today!
>_ Today we have a piece of advice: don’t write a script to save money on AWS. Here at ParkMyCloud, we spend a lot of time chatting with DevOps and infrastructure teams, listening to how they manage their cloud operations.
You can Take the DIY Approach (scripting)
Although there is a lot of ‘tooling’ out there to make their lives easier, many infrastructure guys still choose to drop to the command line to take control of their environments. They might do this by using automation tools like Chef or Puppet, continuous delivery tools like Jenkins or simply revert to Bash or PowerShell. They are using these tools because of the granular control they provide and because they can seemingly quickly ‘knock out a script’ to either solve a problem or provide a quick automation of a common task.
We’ve talked with a number of larger AWS customers who are optimizing thousands or even tens of thousands of instances using scripting technologies. Given the needs of their businesses, their internal customers are typically geographically distributed with hundreds of teams and team members utilizing their cloud infrastructure.
But do you really want to?
Although we love scripts as much as the next guy, when it comes to cloud we see a few problems with this approach. Firstly, cloud is the great democratizer of infrastructure. No longer do the business folk in finance, marketing, sales etc. need to call IT to bring on new resources. They know they can spin it up themselves – even if they don’t know they can turn it off just as easily. But if you want cloud users to take on responsibility and ensure governance, they need tools, not scripts. Secondly, supporting hundreds of teams and user-managed infrastructures without embedding DevOps resources in every team quickly becomes burdensome and inefficient. The way we see it, just because you can do it, doesn’t mean you should do it.
There is a reason that simple, single-purpose web apps are sweeping across the enterprise. Users like simple UI’s with little to no learning curve. Companies realized that if you want to empower internal stakeholders by providing tools that allow them to optimize their workflow and resource use, it’s much easier to sustain if the end users can ‘do it themselves’. Be it the crack dev team who begins to self-manage their non-production environment or the team of data-scientists who make the CFO wince when they run their clusters.
Leave it to the folks down under to turn things on their heads
As we listen and learn how our customers optimize their cloud environments, we are always excited when we see an entirely new way of doing something. Recently, we were chatting with Foster Moore, one of our Antipodean customers in New Zealand. They too were active users of automation scripts for cloud optimization.
Once they found ParkMyCloud, however, they realized that they could free up their DevOps team to work on higher value activities. With their new tool in hand they decided to turn upside down the way their teams thought about cloud computing. They created a simple ‘always-off’ schedule, which takes newly launched instances and turns them off by default unless a user needs them turned on. By having them held in a stopped-state until exactly when they need them they avoid all unnecessary running costs.
The lesson is, you don’t need to write a script to save money on AWS. While our customer’s overall approach would have been technically possible using scripts, the ability to enable all their teams to have a simple way to remove this ‘always-off schedule’ would have required custom application development. Instead they were able to use ParkMyCloud’s ‘snooze’ functionality which allows its parking schedules to be temporarily removed for user defined periods of time, which could be an 8-hour workday or any other compute resources needed to be available. By reversing the ‘always-on’ nature of cloud compute to ‘always-off’, they were able to empower their teams to cut costs by 40% – without a single script in sight.
One cool feature on the ParkMyCloud website is the little chat window we’ve added, which allows you talk directly to our team – usually Katy. Well, Katy gets a lot of random questions for sure, things like:
Are you a car park in London? No, but mind the gap!
Are you a cloud provider? No, but we love public cloud providers like AWS, Azure, Google, and the like, and look forward to helping you manage your resources from all of these providers.
Do you support Azure? We will soon. In fact, we just started the dev work – expect Azure out after the New Year.
Do you support AWS Reserved Instances?
We get that last question quite a lot, so we thought we would expand our answer here.
If you don’t know what an AWS Reserved Instance (RI) is, your best bet is to learn about this Amazon Web Services offering is directly on their site.
Let’s break it down a little more.
Can I see my AWS Reserved Instances in ParkMyCloud?
Short answer: yes.
When ParkMyCloud discovers and manages your environment, we don’t know if an instance is treated as an RI, as the RI magic happens on the backend with Amazon. When you reserve an instance, you’re not actually designating a specific instance or server. What you’re reserving is a billing structure and capacity, which is then automatically applied to running instances that match your specified parameters.
So, from third-party apps like PMC, these instances look just like any On-Demand EC2 instance. So, when PMC ingests and displays your instances, your RIs will show among your other instances.
Can I use both ParkMyCloud and AWS Reserved Instances to get savings at the same time?
Definitely. You can actually get maximum cost savings if you use RI for production instances, and PMC to manage your non-production instances. Updated November 2018: we now offer a Reserved Instance management solution to save you time and help you get the most out of your reservations – learn more here.
How can I save on my non-production servers?
For non-production environments (think test, dev, staging and QA), you can schedule servers off during nights and weekends using ParkMyCloud. Doing this typically saves PMC customers 65% or so off their monthly instance cost. The 65% range is based on a 50-hour workweek – meaning your instances run just 50 of the 168 hours in a given week – so they are parked a majority of the time to maximize savings.
How is that better than AWS Reserved Instances?
While AWS advertises RI savings as high as 75%, in reality for production RI savings typically run in the 30-40% range for the most commonly used instances (e.g., m3.medium, m4.large, m4.xlarge). Additionally, Reserved Instances require a 1-3 year upfront commitment, while PMC does not – leaving you more flexible.
If you have an AWS account which has both production and non-production in it and you have already purchased RI contracts, then using ParkMyCloud for non-production will, over time, shift the RI benefit to the production side (since those instances run 24×7) as your environment grows, the RI shift is factored in on the bill. Of course, if your environment is static then the shift does not occur – but whose AWS environment is not growing, right?
What else should I keep in mind?
Please also remember that unlike ParkMyCloud scheduling, Reserved Instances require you to specify the type, platform, payment option, instance type, offering class, and term length. You can optionally select an Availability Zone if you want to reserve capacity. Convertible RIs allow you to change some of these attributes, but at a reduced savings of around 45%.