Let’s revisit Google and Amazon pricing since the AWS November 2016 Price Reduction.
We’ll analyse instance costs, for various workloads and usages. All prices are given in dollars per month (720 hours) for servers located in Europe (eu-west-1).
Shared CPU Instances
Shared CPU instances give only a bit of CPU. The physical processor is over allocated and shared with many other instances running on the same host. A shared CPU instance may burst to 100% CPU usage for short periods but it may also be starved of CPU and paused. Note that these instances are cheap but they are not reliable for non-negligible continuous workloads.
The smallest instances on both cloud is 500MB and a few percent of CPU. That’s the cheapest instance. It’s usable for testing and minimal needs (can’t do much with only 5% of CPU and 500MB).
The infamous t2.small and it’s rival the g1-small are usually the most common instance types in use. They come with 2GB of memory and a bit of CPU. It’s cheap and good enough for many use cases (excluding production and time critical processing, which need dedicated CPU time).
The Cheapest Production Instances
Production instances are all the instances with dedicated CPU time (i.e. everything but the shared CPU instances).
Most services will just run on the cheapest production instance available. That instance is very important because it determines the entry price and the specifications for everything.
The cheapest production instance on Google Cloud is the n1-standard-1 which gives 1 CPU and 4 GB of memory.
AWS is more complex. The m3.medium is 1 CPU and 4 GB of memory. The c4.large is 2 CPU and 4 GB of memory.
m3/c3 are the previous family generation (pre-2015), using older hardware and an ancient virtualisation technology. c4/m4 are the current generation, it has enhanced networking and reserved bandwidth for EBS, among other system improvements.
Either way, the Google entry-level instance is significantly cheaper than both AWS entry-level instances. There will be a lot of these running, expect massive costs savings by using Google cloud.
I’m a believer that one should optimize for manageability and not raw costs. That means adopting c4/m4 as the standard for deployments (instead of c3/m3).
Given this decision, the smallest production instance on AWS is the c4.large (2 CPU, 4GB memory), a rather big instance when compared to the n1-standard-1 (1 CPU, 4GB memory). Why are we forced to pay for two CPUs as the minimal choice on AWS? That does set a high base price.
Not only Google is cheaper because it’s more competitive but it also offers more tailored options. The result is a massive 68% discount on the most commonly used production instance.
Personal Note: I would criticize the choice of AWS to discontinue the line of m4.medium instance type (1 CPU).
Instances by usage
A server has 3 dimensions of specifications: CPU performances, memory size and network speed.
Most applications only have a hard requirement in a single dimension. We’ll analyse the pricing separately for each usage pattern.
Network Heavy
Typical Consumers: load balancers, file transfers, uploads/downloads, backups and generally speaking everything that uses the network.
What should we order to have 1Gbps and how much will it be?
- The minimum on Google Cloud is the n1-highcpu-4 instance (4 CPU, 4 GB memory).
- The minimum on AWS is the c4.4xlarge instance (16 CPU, 30 GB memory).
AWS bandwidth allowance is limited and correlated to the instance size. The big instances -with decent bandwidth- are incredibly expensive.
To give a point of comparison, the c4|m4|r3.large instances have a hard cap at 220 Mbits/s of network traffic (Note: It also applies internally within a VPC).
All Google instances have significantly faster network than the equivalent [and even bigger] AWS instances, to the point where they’re not even playing in the same league.
Google has been designing networks and manufacturing their own equipment for decades. It’s fair to assume than AWS doesn’t have the technology to compete.
CPU
Typical Consumers: web servers, data analysis, simulations, processing and computations.
Google is cheaper per CPU.
Google CPU instances have half the memory of AWS CPU instances[1]. While that could have justified a 10% difference, it doesn’t justify double[2].
Note: The performances per CPU are equivalent on both cloud (though the CPU models and serial numbers may vary).
[1] A sane design decision. Most CPU bound workloads don’t need much memory. (Note: if they do, they can be run on “standard” instances).
[2] Pricing is mostly linked to CPU count. Additional memory is cheap.
Memory
Typical Consumers: database, caches and in-memory workloads.
Google is cheaper per GB of memory.
Google memory instances have 15% less memory than AWS CPU instances. While that could have justified a few percent difference, it sure as hell doesn’t justify double[2].
[2] Pricing is mostly linked to CPU count. Additional memory is cheap.
Local SSD and Scaling Up
There are software that can only scale up, typically SQL databases. A database holding tons of data will require fast local disks and truckloads of memory to operate non-sluggishly.
Scaling up is the most typical use case for beefy dedicated servers, but we’re not gonna rent a single server in another place just for one application. The cloud provider will have to accommodate that need.
Google allows to attach local 400GB SSDs to any instance type ($85 a month per disk).
Some AWS instances comes with small local SSD (16-160GB), you’re out of luck if you need more space than that. The only option to get big local SSD is the special i2 instances family, they have specifications in powers of 800GB local SSD + 4 CPU + 15 GB RAM (for $655 a month).
The Google SSD model is superior. It’s significantly more modular and cheaper (and more performant but that’s a different topic).
Disk Intensive Load: A job that requires high volume fast disks (i.e. local SSD) but not much memory.
AWS forces you to buy a big instance (i2.xlarge) to get enough SSD space whereas Google allows you to attach a SSD to a small instance (n1-highcpu-4). The lack of flexibility from AWS has a measurable impact, the AWS setup is 406% the costs of the Google setup to achieve the same need.
Database: A typical database. Fast storage and sizeable memory.
Bigger Database: Sometimes there is no choice but to scale up, to whatever resources are commanded by the application.
On AWS (i2.8xlarge) 32 cores, 244GB memory, 2 x 800 GB local SSD in RAID1 (+ 6 SSD unused yet gotta pay for it).
On Google Cloud (n1-highmem-32): 32 cores, 208 GB memory, 4 x 375 GB local SSD in RAID10.
This last number is meant to show that the lack of flexibility of AWS can (and will) snowball quickly. Only a very particular instance can fulfil the requirements, it comes with many cores and 4800 GB of unnecessary local SSD. The AWS bill is $4k (273%) higher than the equivalent setup on Google Cloud.
Custom Instances
Google offers custom machine types. You can pick how much CPU and memory you want, you’ll get that exact instance with a tailored pricing.
It is quite flexible. For instance, we could recreate any instance from AWS on Google Cloud.
Of course, there are physical bounds inherent to hardware (e.g. you can’t have a single core with 100 GB of memory).
Reserved Instances
Reserved Instances are bullshit!
Reserving capacity is a dangerous and antiquated pricing model that belongs to the era of the datacenter.
The numbers given in this article do not account for any AWS reservation. However, they all account for Google sustained use discount (30% automatic discount on instances that ran for the entire month).
If your infrastructure is so small that you can reserve all your 4 instances upfront, you should reconsider why you use AWS in the first place. There are more appropriate and cheaper options available.
If your infrastructure is big enough that you have dozens of servers (or thousands), you should already be aware that:
- Long term commitment is a huge risk. Most people underestimate it.
- Predictions are always off. Most people are overconfident in their predictions.
- You are no exception to most people.
- Reservation is a mess when having many AWS accounts (dev, staging, prod).
- Anything that is testing/transient is too short-lived to be reserved.
- Less than 50% of reservable stuff can actually be reserved (margin for change/error).
Most people managers are stubborn. If you your manager is stubborn and really insists on reserving instances, you should bet exclusively on “1 year full upfront“.
Conclusion
AWS was the first generation of cloud, Google is the second. The second generation is always better because it can learn from the mistakes of the first and it doesn’t have the old legacy to support.
2016 should be remembered as the year Google became a better choice than AWS. If 50% cheaper is not a solid argument, I don’t know what is.
References:
Cloud Storage Performance, a benchmark with graphs on network performance.
Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network, A Google Research Paper, the story on what powers their internal network.
Amazon does everything wrong, and Google does everything right, A message by an employee from Amazon than Google, not directly relevant but still a good read.
The HFT Guy 
Excellent post! I have been looking for a clear comparison like this one for a while. Thanks!
LikeLike
At its heart Google is a engineering driven technology company, Where as amazon is a business driven ecommerce company. Now that google has opened up their cloud for general purpose computing, we will see more cost savings in future.
LikeLike
Any CTO using AWS and not GCE should be held accountable for not only wasting money on AWS, but also accountable for the inferior network latency of AWS.
LikeLike
Switching to GCE after using AWS for almost 4 years has paid off big time. I’m glad others have come to the same conclusion. I’ve also noticed much less latency across the board with GCE.
LikeLike
Outstanding, many thanks for this
LikeLike
The article is excellent, but I don’t agree with you regarding reserved instances and here’s why:
When a company joins AWS/GCE/Azure, most of the time they get credits for few hundreds/thousands of dollars which is being mostly used for testing, scaling etc. until they decide about configurations, instances, EBS etc…
When a company decides to expand due to higher demand, they don’t need to throw those instances away, on many clusters solutions you can set which machine is “weak” (which will get less request) and which machine is “strong”. Also, you could use the reserved instances for other purposes (like a backup machine ready to pick up extra traffic for example).
The 50-75% price decrease is really hard to ignore and this could be the thing that helps a company to go either with GCE or AWS IMHO.
LikeLike
Great article! A couple of things:
AWS do not oversubscribe CPUS like suggested in this article (or memory/disks), only NICS are oversubscribed, which is why they don’t provide exact performance statistics on the network performance.
Secondly, why not use both? Chuck teraform in the middle and provision in the most appropriate cloud for that workload. Want to run your SMS/Email/DNS and CDN services out of AWS while running your container farm out of GC, you can do that with teraform. It isn’t a 1 cloud farm rules them all landscape anymore.
LikeLiked by 3 people
Umm… there’s some good work here – you looked at multiple instance types and included performance. Overall I have to say it’s still oversimplified, though. For one thing, having an option to use some reserved instances for large apps that need many of them is not bullshit – it saves money on instances that are going to have saturated usage profiles. Many folks misuse them, which _is_ bullshit, but that’s not the same thing. Have a look at how instance usage and configuration affect pricing for AWS, Google, Azure and SoftLayer: http://cloudserviceevaluation.com/2016/09/01/public-cloud-pricing-is-complex-so-youre-probably-leaving-money-on-the-table-part-1
LikeLike
I find your comparison to be seriously flawed.
A t2.medium is given for 40% sustained use (without guarantee). The instance types you give for Google, Softlayer and Azure are given for 2 dedicated cores.
You compare groups of 4 instances, so that’s 1.6 CPUs on AWS vs 8 CPUs on Google, SoftLayer and Azure. That’s 5 times the processing power. If your site gets any decent traffic, the AWS setup won’t be able keep up and your site will go down.
LikeLike
Great read. But Windows-based VMs are waaay more expensive at Google, than at AWS’s.
LikeLike
In fact, if you only want run instance, AWS is not the best option for you.
AWS is not anymore question about Server, It’s about Service, Service who save your time and money.
There Google need lot of work for catch up AWS.
I’m surprise you didn’t mention Spot instances, which is give you the much cheaper instances on market.
All the Best.
LikeLiked by 2 people
In fact, if you only want run instance, AWS is not the best option for you.
AWS is not anymore question about Server, It’s about Service, Service who save your time and money.
There Google need lot of work for catch up AWS.
I’m surprise you didn’t mention Spot instances, which is give you the much cheaper instances on market.
All the Best.
LikeLiked by 1 person
Of course it’s not about just having some servers or it would be talking about some OVH softlayer and digital ocean.
AWS and Google Cloud have all the necessary services. If you just look at the sheer numbers, AWS has more. If you actually try to use them, Google Cloud have only the most important, plus some exclusives, and they are more polished.
Regarding spot instances. Google Cloud has better: pre-emptible instances, 80% off. I’ll add a paragraph about that.
LikeLike
Unfortunately Google Cloud SQL doesn’t offer Postgres, which makes it a non-starter for me. And I’m not going to use some rando third-party provider like ElephantSQL when RDS already works so well. I’m just starting to use Elasticsearch and the same argument applies.
LikeLike
What about setting up PostgreSQL on Compute Engine as described in these tutorials:
https://cloud.google.com/solutions/set-up-postgres
https://cloud.google.com/solutions/setup-postgres-hot-standby
Do you think there would be any potential downsides to running PostgreSQL in this way?
LikeLike
PostgreSQL is an experiment feature now. Maybe consider it again when it is out of beta?
LikeLike
One year later and Google Cloud SQL for Postgres is now available. 🎉
LikeLike
This is certainly a reason to look at GCE, however, the reason to pick AWS (or even Azure) is not always just cost. For example, AWS has very sophisticated and mature enterprise-class quota and reporting systems (Azure not so much). If just buying IaaS capacity then GCE might be a good choice.
LikeLiked by 1 person
I don’t know what quota and reporting you’re talking about.
I find AWS to be seriously lacking in that regards, it only has the most trivial information. It is notorious that one has to pay for a 3rd party tool to get good accounting and summary. (Cloudability or CloudCheckr).
LikeLike
I think there is a slight typo in the ‘Cheapest Production Instances’ paragraph; I think it should be ‘m3.medium’ instead of ‘c3.medium’, to match the graph:
‘AWS is more complex. The c3.medium is 1 CPU and 4 GB of memory. The c4.large is 2 CPU and 4 GB of memory.’
LikeLike
Indeed. Fixed.
LikeLike
Corroborating these figures, James Watters (Pivotal SVP) said at re:invent they saved 50% by moving from AWS to Google Cloud. For an 8 figures bill, that’s a lot.
– https://twitter.com/felipehoffa/status/804478208330514432
– https://www.youtube.com/watch?v=BUN0wx2e6Dc&t=287
Thanks for sharing your numbers!
(I work at Google)
LikeLike
Thanks for this.
I picke GCE on AWS based on the price advantage over pre emptible and customizability of instances.
Nice to know the the actual figures.
LikeLike
What happened between you and AWS?
Google cloud egress pricing is $0.12/g, while AWS is $0.09. Data transfer cost is one of the most important things for a cloud hosting, and you didn’t mention it? just because AWS is cheaper?
For “network heavy” usage, c4.4x is only $600+ per month, but do you have any idea how much it cost for the data transfer in this usage case? You recommend c4.4x for “1gbps”, lets say it’s average 0.32gbps, then it is 40M per second, 101250G per month. It cost at least $10000 per month, so you still care about the $600+?
“Cheapest Production Instances” is also a joke. Why you comparison c4.large(2vcpu) with n1-standard-1(2cpu)? Obviously it is should compare with n1-standard-2(2cpu).
And you ignored the “reserved instance pricing” (which is 30%~60% off) in whole comparison just because you “don’t like it”?
What a misleading article.
LikeLiked by 1 person
Nothing much. I run things on AWS, Google, Digital Ocean and even some private datacenters. I try to keep up with the current state of affairs, sometimes one provider is half the price for twice the performances, not my fault, just reading the bill.
I don’t mention traffic costs because it was always a minimal part of the bill in all companies I’ve seen.
We can discuss it now. First, Google and AWS intra region traffic is free. You can absolutely push 101250G GB between instances for $0.
For web sites, all public traffic goes through a CDN, usually Akamai or CloudFlare (if you don’t have a CDN already, you should go get CloudFlare). It saves a huge amount of bandwidth.
Google Cloud has direct links to the major CDN providers, see CDN Interconnect. You automatically get reduced pricing and reduced latency for all that traffic (4cts/GB in NA, 5cts/GB in EU). Once again, Google Cloud is 50% cheaper.
Special case: If you want to run a very bandwidth intensive site (e.g. image sharing, video sharing, file sharing), the first thing to do is to NOT do that on the cloud, or you’re gonna bankrupt yourself. It’s one of the very few applications that cannot run on the cloud.
LikeLike
For instance bandwidth:
You mentioned “network heavy”, right? So you should involve the data transfer cost in “network heavy” usage, right? Google is $0.12, AWS is $0.09. Please add this to your original article to avoid misleading people.
For the CDN:
Both Google and AWS have their own CDN service. Since your article is comparing Google vs AWS, you should compare their own CDN, not 3rd party. Seems you still refuse to talk about their network pricing.
3rd party CDN:
You should not mention 3rd party CDN what will make the comparison very complicated. And you have many wrongs.
Cloudflare’s ‘free’ plan is a shared service not for only micro personal site.(see their terms: https://www.cloudflare.com/terms/). A “network heavy” instance is obviously for an enterprise usage. Their enterprise pricing is not public.
The “4cts/GB in NA” is Intra-region, the final cost per GB will be $0.04+CDN cost. Example, if using Fastly, the cost will be $0.04+$0.12=$0.16/G. While AWS cloudfront is only $0.085. Yes it is almost 50% cheaper! But winner is AWS.
And you forget a very important thing: Google intra-region has no DISCOUNT. While AWS cloudfront can be lower to $0.02/G. In the above example,
Google+fastly cost: $0.04+0.085=$0.125/G
AWS cloudfront cost: $0.02/G
Then how much you will save on a “network heavy” project?
LikeLike
Data transfer = $0 because the traffic within a VPC is free.
Big enterprises are on Akamai, SMB are on CloudFlare. Don’t care about AWS and Google CDN, the pricing is plain terrible and the features are not on-par. If you care so much about money, use CloudFlare, it’s a fixed price that doesn’t depend on traffic (and there is a great free tiers).
“Then how much you will save on a “network heavy” project?”.
Assuming you want to push multiple Gbps all day along. If it’s private traffic, you’ll save the number stated in the graph. If it’s public traffic, you’re gonna bankrupt yourself on either cloud.
“You should not mention 3rd party CDN what will make the comparison very complicated. And you have many wrongs.”
The real world has CDN, especially if they have lots of traffic. I get that you want me to focus on a very particular case that may be slightly in favour of AWS… and I won’t do it because it’s not realistic. That could be part of another article comparing CDN, caching strategy and traffic costs though. 😉
LikeLike
“If you care so much about money, use CloudFlare”
What’s your logic? I’m not asking you how to choose a CDN, I’m pointing out your wrongs in the calculation of CDN costs.
Don’t mix truth and opinion. Yes you can have your own opinion. But first tell the truth.
The truth is Google cloud CDN cost is much higher than AWS.
When using 3rd party CDN with Google, the cost maybe even higher.
Without CDN, Google compute egress traffic is also much higher than AWS.
Please add these info to your “Network Heavy” section, or you are misleading your readers.
One thing I agree with you, that this is a “particular case”, who need a 1gps in an instance with only 4vpus? I think the AWS instance is more reasonable: better hardware with better network. Your article is talking about costs, so you should compare general case.
Your “Local SSD and Scaling Up” is also “particular case”. Local ssd is not recommend for general usage, because it is not safe and scalable. You are misleading your readers at this point. And “800G storage” is very particular case, you should compare a reasonable size of storage. Generally users start with a small ssd.
Also, buying reserved instance is not “dangerous”. One big advantage of cloud hosting comparing to dedicated server is Scalability. You can buy small instances and switch to larger when your business growing. If your project failed at beginning you don’t lost much on the hosting. You can use it for another project, or sell the reversed instance. You can also convert your instance type.
In fact, I’ve used both aws and Google cloud for years and recently planning to switch one of my projects from AWS to Google ( for an important reason that your article didn’t mention), that is why I found your article by Google search. But your whole article is meaningless.
LikeLike
“Data transfer = $0 because the traffic within a VPC is free.” that is not true, traffic within AZ is free, single region have multiple AZs, traffic between AZs is 0.01$/GB
LikeLike
very important article about cloud services, but my comment is apart of the topic. I am not sure why would be funny the last animated gif (the pattern with some other gifs say that). the people in the boat maybe was very injured or maybe is death. No problem if you do not publish this comment
LikeLike
The point is that reserving instances is a dangerous game, just like grenade fishing.
The 2 guys are fine. There is the full video on the internet in where you can see them standing up afterwards, somewhat stunned but okay =)
LikeLike
Knowing very little about the benefits/capabilities in each of the comparisons – what would be recommended so as to run a small ecommerce WordPress website using Google Cloud? Would the f1-micro be enough?
LikeLike
Use a wordpress hoster that does just that.
LikeLiked by 1 person
I didn’t understand about cloud price, Google Cloud and AWS is confusing, not really for beginner.
I tried to find how to calculate the price (total price per month for wordpress), but I didn’t find anything.
I’m interesting but I’m afraid because I was read some of people rent $30/$40 plan and end up charged more than $100 per month.
LikeLike
AWS and Google are oriented toward business needs.
You won’t get much of anything for $30. Try DigitalOcean instead.
LikeLike
[…] to on-demand pricing, Google is proving to be very competitive. Research has shown that it can be significantly cheaper. This isn’t the only cost benefit Google provides, […]
LikeLike