Amazon Web Services to Google Cloud Platform Service Mapping

May 7, 2015 | By

As a Developer Advocate on the Google Cloud Platform team, I am frequently asked what services we provide.  If the person I’m talking to is familiar with Amazon Web Services (AWS), the quickest way to jump start an explanation of Google Cloud Platform is to start with a comparison to AWS’s similar services, then cover the differences.

Below is a simple map between some of the major services in AWS and Google Cloud Platform.  This is not intended to be a complete mapping.  It would be unfair to both platforms to list every service because Google and Amazon are taking different approaches in many areas, making direct comparisons practically impossible.  I’m only listing the services where the comparison is helpful.

Updated September 23, 2015 — as a result of Amazon launching S3 Standard – Infrequent Access (IA) and Google Cloud Dataproc

Updated January 2nd, 2016 — The Google Cloud Platform team has published an extensive whitepaper that covers the contents of this blog post plus a lot more.  It’s a fantastic resource!

Category Amazon Web Services Google Cloud Platform
Compute EC2 Compute Engine
Compute EC2 Container Service Container Engine
Compute Elastic Beanstalk ** App Engine  **
Storage S3 Cloud Storage
Storage Amazon S3 Standard –
Infrequent Access (IA)
Cloud Storage Nearline
Storage Glacier Cloud Storage Nearline
Storage CloudFront Cloud Storage (edge caching is provided for public buckets)
Database RDS Cloud SQL
Database DynamoDB Cloud Datastore and Cloud Bigtable
Big Data Redshift BigQuery
Big Data SQS/Kinesis Cloud Pub/Sub
Big Data EMR Cloud Dataproc
Monitoring CloudWatch Cloud Monitoring and Cloud Logging
Networking Route53 Cloud DNS and Google Domains
Networking Direct Connect Cloud Interconnect
Other CloudFormation Cloud Deployment Manager
Other SES SendGrid (partner)

** AWS Elastic Beanstalk and Google App Engine are often described as similar offerings, but there are significant differences in their approaches.  Both offer auto-scaling, load balancing, monitoring, etc., but unlike App Engine, Elastic Beanstalk requires the typical system administration that raw VMs require (OS updates, etc.).  Google App Engine is a PaaS, meaning that it’s fully managed, so all of these administrative tasks are handled by Google.  The basic App Engine setup includes built-in services such as Task Queues, Memcache, Users API, and more.

If you require unmanaged VMs, Google also has auto-scaling, load balancing, and monitoring of unmanaged VMs as features of Google Compute Engine.  There is also an alternative hosting model now available as part of Google App Engine called Managed VMs.

My advice is to do your homework and understand these models thoroughly before diving in on either platform.  Each has unique advantages.

I’ll have more posts in the near future with more specifics on several of the offerings.  Stay tuned!


Filed in: Amazon AWS, Amazon CloudFront, Amazon EC2, Amazon S3, Google, Google Cloud Platform | Tags: , , , , , , , , , , , ,

About the Author (Author Profile)

Greg is a developer advocate for the Google Cloud Platform based in San Francisco, California
  • you forgot cloudformation -> deployment manager

    • I’ll add shortly. Thanks!

    • Greg Wilson

      Added. Thanks for the suggestions!

  • Jo Maitland

    Hey Greg, Thanks for sharing the comparison. Just an fyi, EMR and Dataflow are not the right comparison. Dataflow is more like Spark than it is MapReduce. You don’t have to worry about what’s parallelized or not.

    • Greg Wilson

      Hey Jo – I changed it to EMR -> Dataproc 🙂

  • In general I find that Google Cloud options are priced very competitively and the pricing and other documentation is often very easy to understand

    But not in the case of Google Cloud Storage as a cloudfront alternative.

    1. It’s not clear what the POPs offered by Google Cloud storage are. Cloudfront POPs are given here –

    2. It is 1.3x more expensive than Cloudfront in HTTP GET request pricing.

    Cloud Storage considers retrieving an object through its HTTP url is considered a class B XML request type which is priced at $0.01/10,000 ops. This is also not well documented and caused me some trouble. It did not occur to me that HTTP GET will be considered as an XML API operation. So I didn’t expect HTTP GET requests to be charged because everywhere I read (including the pricing is for XML API operation.

    I think this is one area Google Cloud can definitely improve 🙂

    • All fair Manu. I’ll pass this on to the product team. Thanks!!

  • Lipis

    Nice to see this list in the official documentation 🙂 Maybe you can also update the S3 IA there as well 🙂