Google Cloud for AWS Professionals: Compute

Updated November 21, 2017

Compare the compute services that Amazon Web Services (AWS) and Google Cloud provide in their respective cloud environments. Compute services are typically offered under four service models:

  • Infrastructure as a service (IaaS), in which users have direct, on-demand access to virtual machines, as well as a suite of related services to automate common tasks.
  • Platform as a service (PaaS), in which the machine layer is abstracted away completely, and users interact with resources by using high-level services and APIs.
  • Functions as a service (FaaS), a serverless computing model that allows you to run individual functions in response to a variety of triggers.
  • Containers as a service (CaaS), an IaaS/PaaS hybrid that abstracts away the machine layer but retains much of the flexibility of the IaaS model.

This article focuses on the IaaS, PaaS, FaaS, and CaaS services offered by Google Cloud and AWS.

IaaS comparison

For IaaS, AWS offers Amazon Elastic Compute Cloud (EC2), and Google Cloud offers Compute Engine. Google and Amazon take similar approaches to their IaaS services. Both Amazon EC2 and Compute Engine are:

  • Fundamental components of their cloud environment.
  • Used to run almost every type of customer workload in their platform.

At a high level, Amazon EC2's terminology and concepts map to those of Compute Engine:

Feature Amazon EC2 Compute Engine
Virtual machines Instances Instances
Machine images Amazon Machine Image Image
Temporary virtual machines Spot instances Preemptible VMs
Firewall Security groups Compute Engine firewall rules
Automatic instance scaling Auto Scaling Compute Engine autoscaler
Local attached disk Ephemeral disk Local SSD
VM import Supported formats: RAW, OVA, VMDK, and VHD Supported formats: RAW, OVA, VMDK, and VHD
Deployment locality Zonal Zonal

Virtual machine instances

Compute Engine and Amazon EC2 virtual machine instances share many of the same features. On both services, you can:

  • Create instances from stored disk images.
  • Launch and terminate instances on demand.
  • Manage your instances without restrictions.
  • Tag your instances.
  • Install a variety of available operating systems on your instance.

Machine access

Compute Engine and Amazon EC2 approach machine access in slightly different ways:

  • Amazon EC2 requires you to include your own SSH key if you want terminal access to the instance.
  • Compute Engine enables you to create the key when you need it, even if your instance is already running.
  • You can use Compute Engine's browser-based SSH terminal, which is available in the Google Cloud Console without ever needing to store keys on your local machine.

Instance types

Compute Engine and AWS share several high-level families of instance types, with differences in terminology, configuration, and SSD availability:

  • Amazon EC2 refers to these configurations as instance types.
  • Compute Engine refers to them as machine types.
  • Compute Engine allows you to depart from the predefined configurations, customizing your instance's CPU and RAM to fit your workload.
  • Compute Engine does not have specific categories for instances that use local SSD storage— you can add SSDs to all of Compute Engine's non-shared instance types. For details about how each environment implements locally attached SSDs, see Locally attached storage.

The following broad categories of instance type are common to Compute Engine and Amazon EC2:

Machine Type Description
Shared Core

Machines that run on a portion of a single physical CPU.

Suitable for tasks that don't require a lot of resources, but need to remain online for long periods of time.


Machines that provide a balance of compute, network, and memory resources.

Suitable for most general applications without specific resource demands.

High Memory

Machines that have a higher than standard ratio of memory to vCPUs.

Suitable for memory intensive applications that aren't computationally demanding. Some examples include high-performance database applications, applications that must keep large caches of data, and any large, data-driven applications such as enterprise management systems.

High CPU

Machines that have a higher than standard ratio of vCPUs to memory.

Suitable for computationally intensive applications that don't have unusually high memory needs. Some examples include data transformation software (e.g. video encoding), simulation software for science and engineering, and high-traffic web servers.


Machines that include discrete graphics processing units (GPUs).

Suitable for applications that require demanding mathematical processing. A typical example is machine learning, but there are many other tasks that benefit from the increased efficiency of advanced math processing GPUs provide.

SSD Storage

Machines that have local solid-state drive (SSD) storage.

Suitable for applications that depend on high throughput to storage. SSD storage offers faster data access than magnetic storage.

Dense Storage

Machines that include high-capacity magnetic media storage.

Suitable for applications that keep large amounts of data on local disks. In many cases, applications with large storage requirements can store data in other web services instead of on disks attached to VMs.

Temporary instances

Temporary instances are virtual machines that run on spare cycles of resources allocated to other processes. The result is an unpredictably available VM with a lower cost than a VM created with dedicated resources. Temporary instances are useful for:

  • Jobs that can be interrupted without losing work.
  • Low priority jobs that don't require completion within a specific timeframe.
  • Extra resources for jobs that benefit from a boost in computational power, when it's available. For example, rendering video.

Amazon EC2 offers temporary instances called spot instances and Compute Engine offers similar instances called preemptible VMs. Both provide similar functionality, but they have different pricing models.

Both spot instances and preemptible VMs are:

  • Restricted to a smaller set of available instance types and machine images than regular, on-demand instances.
  • Capable of the same performance as on-demand instances while running.
  • Fully controllable while running.

Amazon EC2 spot instances come in two varieties:

  • Regular spot instances are:
    • Auctioned on the Spot Market.
    • Launched when a bid is accepted.
    • Active until you terminate them, or AWS interrupts them.
  • Spot blocks are:
    • Given a fixed price below the regular, on-demand rate.
    • Limited to a maximum of six hours at the discounted rate.

Compute Engine preemptible VMs differ from spot instances as follows:

  • Pricing is fixed. Depending on machine type, preemptible VM prices can be discounted to nearly 80% of the on-demand rate.
  • If not reclaimed by Compute Engine, preemptible VMs run for a maximum of 24 hours and then are automatically terminated.
  • If you use a premium operating system with a license fee, you will be charged the full cost of the license while using that preemptible VM.

Machine images

Compute Engine and Amazon EC2 both use machine images to create new instances. Amazon calls these images Amazon Machine Images (AMIs), and Compute Engine simply calls them images.

Amazon EC2 and Compute Engine are similar enough that you can use the same workflow for image creation on both platforms. For example, both Amazon EC2 AMIs and Compute Engine images contain an operating system. They also can contain other software, such as web servers or databases. In addition, both services allow you to use images published by third-party vendors or custom images created for private use.

Amazon EC2 and Compute Engine store images in different ways. On AWS, you store images in either Amazon Simple Storage Service (S3) or Amazon Elastic Block Store (EBS). If you create an instance based on an image that is stored in Amazon S3, you will experience higher latency during the creation process than you would with Amazon EBS.

On Google Cloud, images are stored within Compute Engine. To view available images or to create or import images, you can visit the Cloud Console Images page or use the gcloud command-line tool in the Cloud SDK.

Unlike Amazon EC2, Compute Engine does not have a mechanism for making an image publicly available, nor does it have a community repository of available images to draw from. However, you can share images informally by exporting your images to Cloud Storage and making them publicly available.

Amazon's machine images are available only within a specific region. In contrast, Compute Engine's machine images are globally available.

Public images

Amazon EC2 and Compute Engine both provide a variety of public images with commonly used operating systems. On both platforms, if you choose to install a premium image with an operating system that requires a license, you pay a license fee in addition to normal instance costs.

On both services, you can access machine images for most common operating systems. For the complete list of images that are available on Compute Engine, see the public images list.

Amazon EC2 provides support for some operating system images that are not available as public images on Compute Engine:

  • Amazon Linux
  • Windows Server 2003 (Premium)
  • Oracle Linux (Premium)

Custom image import

Amazon EC2 and Compute Engine both provide ways to import existing machine images to their respective environments.

Amazon EC2 provides a service called VM Import/Export. This service supports a number of virtual machine image types—such as RAW, OVA, VMDK and VHD—as well as a number of operating systems, including varieties of Windows, Red Hat Enterprise Linux (RHEL), CentOS, Ubuntu, and Debian. To import a virtual machine, you use a command-line tool that bundles the virtual machine image and uploads it to Amazon Simple Storage Service (S3) as an AMI.

The process and requirements for importing machine images to Compute Engine are similar to those for Amazon EC2. Like VM Import/Export, the Compute Engine import tool supports RAW, OVA, VMDK, and VHD image types and Windows, RHEL, CentOS, Ubuntu, and Debian operating systems. To import a virtual machine, you upload the image to Cloud Storage and then use the gcloud command line tool or Cloud Console to finish the process of importing the image into Compute Engine. For more details about importing images and other virtual assets into Compute Engine, see Choosing an import method.

If you build your own custom operating systems and plan to run them on Compute Engine, ensure that they meet the hardware support and kernel requirements for custom images.

Apart from the cost of storing an image in Amazon S3 or Cloud Storage, neither AWS nor Google Cloud charge for their respective import services.

Automatic instance scaling

Both Compute Engine and Amazon EC2 support autoscaling, in which instances are created and removed according to user-defined policies. Autoscaling can be used to maintain a specific number of instances at any given point, or to adjust capacity in response to certain conditions. Autoscaled instances are created from a user-defined template.

Compute Engine and Amazon EC2 implement autoscaling in similar ways:

  • Amazon's Auto Scaling scales instances within a group. The Auto Scaler creates and removes instances according to your chosen scaling plan. Each new instance within the group is created from a launch configuration.
  • Compute Engine's autoscaler scales instances within a managed instance group. The autoscaler creates and removes instances according to an autoscaling policy. Each new instance within the instance group is created from an instance template.

Amazon's Auto Scaling allows for three scaling plans:

  • Manual, in which you manually instruct Auto Scaling to scale up or down.
  • Scheduled, in which you configure Auto Scaling to scale up or down at scheduled times.
  • Dynamic, in which Auto Scaling scales based on a policy. You can create policies based on either Amazon CloudWatch metrics or Amazon Simple Queue Service (SQS) queues.

In contrast, Compute Engine's autoscaler supports only dynamic scaling. You can create policies based on average CPU utilization, HTTP(S) load balancing serving capacity, or Cloud Monitoring metrics.

Internal networks

In both Compute Engine and Amazon EC2, new instances are automatically connected to a default internal network. In addition, you create an alternative network and launch instances into that network in both services. For a full comparison of Google Cloud networking and AWS networking, see the Networking article.


Amazon EC2 and Compute Engine both allow users to configure firewall policies to selectively allow and deny traffic to virtual machine instances. By default, both services block all incoming traffic from outside a network, and users must set a firewall rule for packets to reach an instance.

Amazon EC2 and Amazon Virtual Private Cloud (VPC) use security groups and network access control lists (NACLs) to allow or deny incoming and outgoing traffic. Amazon EC2 security groups secure instances in Amazon EC2-Classic, while Amazon VPC security groups and NACLs secure both instances and network subnets in an Amazon VPC.

Compute Engine uses firewall rules to secure Compute Engine virtual machine instances and networks. You create a rule by specifying the source IP address range, protocol, ports, or user-defined tags that represent source and target groups of virtual machine instances.

Block storage

Amazon EC2 and Compute Engine both support networked and locally attached block storage. For a detailed comparison of their block storage services, see Block storage.


This section compares the pricing models for Compute Engine and Amazon EC2.

On-demand pricing

Compute Engine and Amazon EC2 have similar on-demand pricing models for running instances:

  • Amazon EC2 charges by the second, with a minimum charge of one minute. Premium operational systems such as Windows or RHEL are charged by the hour, rounded up to the next hour.
  • Compute Engine charges by the second, with a minimum charge of one minute.

Both services allow you to run your instance indefinitely.

Discount pricing

Compute Engine and Amazon EC2 approach discount pricing in very different ways.

You can get discounted pricing in Amazon EC2 by provisioning reserved instances:

  • You must commit to a certain number of instances for either one or three years.
  • You receive a lower cost for those instances.
  • A three-year commitment gets you larger discounts than a one-year commitment.
  • The more you pay up front, the greater the discount.
  • Reserved instances are tied a specific instance type and availability zone at purchase.
  • You can switch availability zones and exchange reserved instances only with different instance types in the same family.

You can get a sustained-use discount for Compute Engine instances:

  • Compute Engine automatically applies discounts to your instances depending on how long the instances are active in a given month.
  • The longer you use an instance in a given month, the greater the discount.
  • Sustained-use discounts can save you as much as 30% of the standard on-demand rate.

FaaS comparison

For FaaS (Functions as a Service), Amazon provides AWS Lambda and Google Cloud provides Cloud Functions. These services have similar service models:

  • They are serverless computing platforms that allow you to run individual functions in response to a variety of triggers.
  • You are only charged while your functions are running.
  • They provide an economical way to host services with uneven usage patterns.

Service model comparison

AWS Lambda terms and concepts map to those of Cloud Functions as follows:

Feature AWS Lambda Cloud Functions
Code ingestion Zip upload, online IDE, deskop IDE, Amazon S3 Zip upload, online IDE, Cloud Storage, GitHub
Code update latency Typically within seconds Typically in less than 2 minutes
Max concurrent executions 1,000 per region by default 1,000 per function by default
Max deployment size 50 MB compressed, 250 MB uncompressed 100 MB compressed, 500 MB uncompressed
Triggers S3, DynamoDB, Kinesis Streams and Firehose, SNS, SES, Cognito, CloudFormation, CloudWatch, CodeCommit, scheduled events, AWS configuration changes, Amazon Echo, Amazon Lex, API Gateway (HTTP), IoT Button, CloudFront HTTP, Cloud Storage, Pub/Sub, Firebase, Cloud Logging
Languages supported Node.js, Java, Python, C#, Go Node.js 6, Node.js 8, Python
Memory allocations 128 MB to 1.5GB in 64 MB increments 128 MB, 256 MB, 512 MB, 1 GB, 2 GB
Timeout limits 1s to 15m 1s to 9m
Versioning Built-in Through Cloud Source Repositories
Automatic scaling Yes Yes
Logging Amazon CloudWatch Cloud Logging
Deployment locality Regional Regional
Pricing model Per request, duration in 0.1s increments, and data transfer. Duration cost scales with memory usage. Per request, duration in 0.1s increments, and data transfer. Duration cost scales with memory and CPU usage.

Launching and scaling

AWS Lambda and Cloud Functions share a number of features. Both offer serverless code execution with a variety of triggers and both automatically scale out when needed. Both offer simple deployment, scaling, and fault recovery. The architecture launches a compute container with a copy of your code and automatically scales the number of instances to handle your request load. No configuration or management is required to scale after the function is deployed.

Google employs a preemptive image-generation architecture that significantly reduces latency for first requests on any new instance. This can be a significant benefit for real-time applications or situations where your application must scale very quickly.

Supported languages and triggers

Lambda has been available longer than Cloud Functions and consequently supports more languages and trigger types. Cloud Functions supports Firebase Triggers, Google Cloud's operations suite logs, and Pub/Sub. With these tools, you can trigger a Cloud Function from just about any other Google Cloud service or event.

Runtime limits

Because FaaS platforms are designed to be purely transactional, deploying instances on a per-request basis, you cannot rely on them to continuously execute code beyond the initial request. You should design your application to be stateless and short-running. This applies to both Lambda and Cloud Functions:

  • AWS terminates execution after 15 minutes.
  • Cloud Functions terminates execution after 9 minutes.

Deploying FaaS

Amazon and Google take slightly different approaches to deploying FaaS. AWS Lambda supports deploying from a zip or jar file or through CloudFormation or S3. In addition to zip files, Google Cloud Cloud Functions can be deployed from a Git repository either in GitHub or Cloud Source Repositories. Git support closely links Cloud Functions to your deployment process. You can even configure automated updates based on webhooks.


AWS Lambda pricing includes a base rate per request plus a variable rate based on RAM allocation and compute time. AWS Lambda bills data transfer at the standard EC2 rate.

Cloud Functions charges a variable rate based on the amount of memory and CPU provisioned in addition to the invocation rate. Like AWS Lambda, Cloud Functions charges standard fees for egress bandwidth and does not charge for ingress traffic.

For details, see the Cloud Functions pricing page. To estimate how much your specific workload will cost, try the Google Cloud pricing calculator.

PaaS comparison

For PaaS, AWS offers AWS Elastic Beanstalk and Google Cloud offers App Engine. Both services provide similar functionality:

  • You can publish applications by pushing you code to a managed platform service.
  • The service manages:
    • Underlying infrastructure.
    • Automatic scaling.
    • Application version control.

Service model comparison

AWS Elastic Beanstalk configures and deploys a set of underlying AWS resources, such as Amazon EC2 instances or Amazon RDS databases, to create an appropriate runtime for your application based on your input configuration.

App Engine employs this same model. However, App Engine provides two distinct environments: App Engine standard environment and App Engine flexible environment, each designed with specific use cases in mind.

  • In App Engine standard environment, your code is deployed into container instances that run on Google's infrastructure. Because App Engine standard environment does not rely on underlying Compute Engine VM instances, it scales more quickly than App Engine flexible environment. However, App Engine standard environment's customization options are more limited than those of App Engine flexible environment, and you must use a runtime environment from the service's predefined set of runtime environments.
  • In App Engine flexible environment, your code is deployed into Docker containers running on Compute Engine VM instances, and these containers are managed by App Engine. You can choose from a larger list of supported runtimes than with App Engine standard environment, and you can create partially or fully customized runtimes. However, during high traffic spikes, your application might scale more slowly than it does on App Engine standard environment. For information about determining which App Engine environment is best for you, see Choosing an App Engine Environment.

Elastic Beanstalk could be integrated with such services:

  • Amazon DynamoDB: Fully managed NoSQL database that can store and retrieve any amount of data.
  • Amazon RDS: Managed relational database service powered by MySQL, PostgreSQL, MariaDB, Amazon Aurora, Oracle, Microsoft SQL Server.
  • Automatic scaling and load balancing.
  • Worker Tier environments with SQS integration allow processing of background and periodic tasks.
  • Integration with other AWS services and APIs.

Both App Engine environments can use the same set of platform services, such as:

  • Firestore: Persistent storage with queries, sorting, and transactions.
  • Cloud SQL: Relational database powered by MySQL or PostgreSQL (currently in beta).
  • Automatic scaling and load balancing.
  • Asynchronous task queues for performing work outside the scope of a request.
  • Scheduled tasks for triggering events at specified times or regular intervals.
  • Integration with other Google Cloud services and APIs.

Key components

Both AWS Elastic Beanstalk and App Engine operate on a similar set of key components. From a developer's perspective, AWS Elastic Beanstalk consists of the following key components:

  • Application version: A named/labeled iteration of deployable code submitted by developer.
  • Environment: A running instance of a specific application version deployed on AWS resources.
  • Environment configuration: A collection of parameters and settings that control how Elastic Beanstalk deploys and configures underlying AWS resources for a particular application version associated with a specific environment.
  • Application: A logical bucket for a collection of environments, environment configurations, and application versions.

App Engine consists of the following key components:

  • Version: A named iteration of deployable code submitted by developer, and a configuration file specifying how to deploy this code on App Engine to create a service.
  • Service: An App Engine application is made up of one or more services, which can be configured to use different runtimes and to operate with different performance settings. Each service consists of source code and a configuration file.
  • Service configuration file: A file that specifies how URL paths correspond to request handlers and static files. This file also contains information about the application code, such as the application ID and the latest version identifier.
  • Instance: An underlying compute resource on which a service is running. For App Engine flexible environment, an instance is a Docker container on a Compute Engine VM instance. For App Engine standard environment, an instance is a container running on Google's infrastructure.
  • Application: A logical bucket including one or more services. This bucket can be configured to use different runtimes and to operate with different performance settings.

At a high level, the platforms can be compared as follows:

Feature AWS Elastic Beanstalk App Engine standard environment App Engine flexible environment
Supported language runtimes Java, PHP, .NET, Node.js, Python (2.6, 2.7, 3.4), Ruby, Go Python 2.7, Java 7, PHP 5.5, Go 1.6 Python (2.7, 3.5), Java 8, Node.js, Go 1.8, Ruby, PHP (5.6, 7), .NET
Custom runtimes Yes No Yes
Autoscaling Yes Yes Yes
Free tier available Yes (based on the free tier of underlying AWS resources) Yes (28 instance-hours per day) No
Storage options Amazon S3, Amazon RDS, Amazon EFS, Amazon ElastiCache, Amazon DynamoDB Cloud Storage, Cloud SQL, Memcache, Firestore Cloud Storage, Cloud SQL, Memcache, Firestore
IAM roles Yes Yes Yes
Available locations US, EMEA, APAC US, EMEA, APAC US, EMEA, APAC
Application user authentication and authorization No, must be developed within the application Yes, with Firebase (multiple identity providers), Google Cloud Identity, OAuth 2.0 and OpenID Yes, with Firebase (multiple identity providers), Google and Google Workspace accounts, OAuth 2.0 and OpenID
Task and message queues Yes, using SQS Yes, using Pub/Sub and the Task Queue API Yes, using Pub/Sub and the Task Queue API
Application upgrades and A/B testing Rolling update with scaling based on backend capacity, blue/green deployment with one-time traffic swap. Weighted round-robin is possible with a DNS-based approach. Yes, with granular traffic splitting between versions Yes, with granular traffic splitting between versions
Monitoring Yes, health reporting, instance logs and environment event stream Yes, with Google Cloud's operations suite (request/response and activity logs), uptime checks Yes, with Google Cloud's operations suite (request/response and activity logs), uptime checks, custom metrics and alerts for underlying Compute Engine resources
Networking Can be placed into a VPC No network controls, only IP endpoints exposed to Internet Can be placed into a VPC network
Pricing Based on the cost of underlying AWS resources Based on chosen instance per hour Price consist of 3 parameters:
  • vCPU per core hour
  • memory per GB hour
  • persistent disk per GB per month
Debugging Yes, with X-ray Yes, with Google Cloud's operations suite Yes, with Google Cloud's operations suite

Custom runtimes

AWS Elastic Beanstalk and App Engine flexible environment both allow you to create your own custom runtime. This feature allows you to use other programming languages or use a different version or implementation of the platform's standard runtimes.

AWS Elastic Beanstalk supports customization through custom platforms, which are Amazon Machine Images (AMIs) that contain the binaries needed to run your application. You create custom platforms with Packer, an open source tool for creating identical machine images for multiple platforms from a single source configuration. Using a Packer configuration template, you can customize operating systems, languages, and frameworks, as well as metadata and configuration options that you need to serve your application.

App Engine flexible environment supports customization through custom runtimes. To create a custom runtime, you create a Dockerfile with a base image of your choice, and then add the Docker commands that build your desired runtime environment. Your Dockerfile might include additional components like language interpreters or application servers. You can leverage any software that can service HTTP requests.

In both cases, you are responsible for ensuring that all components are compatible and working with expected performance.

AWS Elastic Beanstalk uses Packer and allows users to control the entire OS image. App Engine flexible environment builds only Docker containers, allowing users to control only application code and its dependencies. An App Engine flexible environment user is not allowed to control things like the OS kernel version on underlying VMs.


Both AWS Elastic Beanstalk and App Engine support autoscaling. Autoscaling allows you to automatically increase or decrease the number of running backend instances based on your application's resource usage.

AWS Elastic Beanstalk autoscaling can be configured based on these scaling options:

  • Launch Configuration allows you to choose scaling triggers and describe parameters for them.
  • Manual scaling allows you set up minimum and maximum instance count, availability zones, and scaling cool-down.
  • Automatic scaling allows you to set up metrics-based parameters. Supported triggers include: Network in/out, CPU utilization, Disk r/w ops/bytes, Latency, Request Count, Healthy/Unhealthy host Count.
  • Time-based Scaling allows you to scale in or out instances (set up maximum, minimum and/or desired number of instances) based on your prediction on a recurring basis or a planned one-time event.

App Engine standard environment offers these scaling options:

  • Launch Configuration allows you to pick a scaling option and describe parameters.
  • Manual scaling allows you to set the number of instances to the service at the start.
  • Basic scaling allows you to set up maximum number of instances and idle time, after which the instance is shut down after receiving its last request.
  • Automatic scaling allows you to set minimum and maximum levels for number of instances, latency, and concurrent connections for a service.

App Engine flexible environment offers these scaling options:

  • Launch Configuration allows you to pick a scaling option and describe parameters.
  • Manual scaling works the same way that it does in App Engine standard environment.
  • Automatic scaling allows you to set a minimum and maximum number of instances, cool-down period, and target CPU utilization.

Application upgrades and A/B testing

You follow similar steps to deploy or upgrade an application in AWS Elastic Beanstalk and App Engine:

  1. Describe your application in a configuration file.
  2. Deploy the new version using a command-line tool.

Both services also offer deployment through their management consoles.

On AWS Elastic Beanstalk, performing in-place updates can cause your application to suffer a short outage. To avoid downtime, you can perform a blue/green deployment, in which you deploy the new version to a separate environment and then swap environment URLs. You can serve only one active version per environment. Weighted round-robin is possible with a DNS-based approach.

App Engine allows you to roll out updates to the current version without downtime, creating a new version and switching to it. You can also configure your App Engine application to split traffic based on either the requester's IP address or a cookie. You can serve a number of versions per service per application.


For debugging, the AWS Elastic Beanstalk console allows you to run an AWS X-Ray daemon on the instances in your development environment. This daemon gathers data about requests to servers and collaboration of application with other services. You can construct a service map that helps you troubleshoot problems in your application and find possible ways to optimize it.

On Google Cloud, you can use Cloud Debugger to inspect the state of an App Engine application at any code location without using logging statements and without stopping or slowing down your applications. Your users are not impacted during debugging. Using the debugger in production, you can capture the local variables and call-stack and link those variables back to a specific line location in your source code. You can use Debugger to analyze the production state of your application and understand the behavior of your code in production.


Monitoring of AWS Elastic Beanstalk environments in AWS Management Console consists of basic metrics such as CPU Utilization and Network in and out. Amazon CloudWatch adds Environment Health as well as basic EC2 monitoring metrics for underlying instances. User also can add Alarms for each of these metrics. All EC2 instances generate logs that you can use for troubleshooting problems with applications.

Monitoring of App Engine applications in the Google Cloud Console dashboard provides visibility into parameters such as total requests, CPU and memory utilization, latency, and instance uptime. Google Cloud's operations suite allows you to create alerting for different parameters and stores logs.


AWS Elastic Beanstalk allows you to manage the connectivity of AWS resources used by Environment. You can prompt Elastic Beanstalk to attach EC2 VMs to a specific VPC and configure Security Groups on those instances. This allows Elastic Beanstalk applications to achieve a level of network connectivity transparency that is similar to App Engine flexible environment.

App Engine standard environment completely abstracts networking configuration. The only networking-related settings you must work with apply to Load Balancing and Custom Domain name for your application's external address. You can also apply DOS Protection Service by using the dos.yaml file to establish a network "denylist". When deployed alongside with your application, it prompts App Engine to serve an error page in response to requests from prohibited IP ranges.

App Engine flexible environment uses Compute Engine virtual machines (VMs) to host your application in Docker containers. You can:

  • Configure VMs managed by App Engine flexible environment to be attached to VPC networks. VPC networks can reside in the same project as Flex app or be shared across multiple projects.
  • Configure VPC networks with App Engine flexible environment instances in them, to be connected to other destinations using Cloud VPN.
  • Apply Firewall settings to App Engine flexible environment instances using Instance Tags.
  • Map network ports on Flex instances to Docker container ports for debugging and profiling.

This flexibility helps when you're building App Engine flexible environment applications that require transparent connectivity to other services, running on Google Cloud or outside of it (on-premises or in another cloud).


AWS does not charge any additional fees for Elastic Beanstalk. You pay only for underlying EC2 instances and other resources.

App Engine standard environment charges by the minute of instance running. Billing begins when an instance starts and ends fifteen minutes after a manual instance shuts down or fifteen minutes after a basic instance has finished processing its last request. There is no billing for idle instances above the maximum number of idle instances set in the Performance Settings. There is also a free quota: 28 free instance-hours per day for Automatic Scaling Modules and 9 free instance-hours per day for Basic and Manual Scaling Modules.

App Engine flexible environment charges for resources of virtual machine types that you specify. Cost is determined by usage of parameters:

  • vCPU (per core hour)
  • Memory (per GB hour)
  • Persistent disk (per GB per month)

These charges are by the minute, with a minimum charge of ten minutes of usage.

For details, see the Compute Engine pricing page. To estimate how much your specific workload will cost, try the Google Cloud pricing calculator.

CaaS comparison

For CaaS, AWS offers Amazon EC2 Container Service (ECS), and Google Cloud offers Google Kubernetes Engine.

GKE and Amazon ECS have very similar service models. In each service, you create a cluster of container nodes. Each node is a virtual machine instance, and each runs a node agent to signal its inclusion in the cluster. Each node also runs a container daemon, such as Docker, so that the node can run containerized applications. You create a Docker image that contains both your application files and the instructions for running your application, and then you deploy the application in your cluster.

Amazon ECS is developed and maintained by Amazon. Google Kubernetes Engine is built on Kubernetes, an open-source container management system.

At a high level, Amazon ECS's terminology and concepts map to those of GKE as follows:

Feature Amazon ECS GKE
Cluster nodes Amazon EC2 Instances Compute Engine Instances
Supported daemons Docker Docker or rkt
Node agent Amazon ECS Agent Kubelet
Container group Task Pod
Deployment sizing service Service Replication Controller
Command line tool Amazon ECS CLI kubectl or gcloud
Portability Runs only on AWS Runs wherever Kubernetes runs

Platform components


In both Amazon ECS and GKE, a cluster is a logical grouping of virtual machine nodes. In Amazon ECS, a cluster uses Amazon EC2 instances as nodes. To create a cluster, you simply provide a name for the cluster, and Amazon ECS creates the cluster. However, this cluster is empty by default. You must launch container instances into the cluster before your application can be launched.

In GKE, a cluster uses Compute Engine instances as nodes. To create a cluster, you first provide basic configuration details set to your desired values, including:

  • Cluster name
  • Deployment zones
  • Compute Engine machine types
  • Cluster size

After you configure your cluster, GKE creates the cluster in the requested zone or zones.

Container groups

Both Amazon ECS and GKE group sets of interdependent or related containers into higher-level service units. In Amazon ECS, these units are called tasks and are defined by task definitions. In GKE, these units are called pods, and are defined by a PodSpec. In both tasks and pods, containers are colocated and coscheduled, and run in a shared context with a shared IP address and port space.

Container daemons

Each node machine must run a container daemon to support containerized services. Amazon ECS supports Docker as a container daemon. Google Kubernetes Engine supports both Docker and rkt.

Node agents

In Amazon ECS, each Amazon EC2 node runs an Amazon ECS agent that starts containers on behalf of Amazon ECS. Similarly, in GKE, each GKE node runs a kubelet that maintains the health and stability of the containers running on the node.

Service discovery

Amazon ECS and GKE both provide mechanisms for service discovery within a cluster. Amazon ECS provides a registry of service names mapped to DNS addresses. You refer to services using an alias that resolves to the service endpoint at runtime. You may also specify health check conditions in the service's task definition, and ECS will return only healthy services.

GKE clusters enable service discovery by way of the Kubernetes DNS add-on, which is enabled by default. Each Kubernetes service is assigned a virtual IP address that is stable for as long as the service exists. The DNS server watches the Kubernetes API for new services and then creates a set of DNS records for each. These records allow Kubernetes pods to perform name resolution of Kubernetes services automatically.


Amazon ECS supports only its native scheduler.

GKE is built on top of Kubernetes, which is a pluggable architecture. As such, GKE is fully compatible with the Kubernetes scheduler, which is open source and can run in any environment that Kubernetes can run in.

Deployment automation

On Amazon ECS, you can create a script to deploy tasks on each node. However, this behavior is not built into the service.

On GKE, you can use a DaemonSet to run a copy of a specific pod on every node in a cluster. When nodes are added or removed from the cluster, the DaemonSet automatically copies the pod to the new nodes or garbage collects the old nodes. When you delete the DaemonSet, the DaemonSet cleans up any pods it has created.

Disk management

Because Amazon ECS disks are host-specific, a container that relies on a given specific disk cannot be moved to a different host.

In contrast, GKE can mount disks dynamically on a node and assign the disks to a given pod automatically. You don’t need to run a pod on a specific node to use a specific disk.

Identity and access management

Amazon ECS is fully integrated with the AWS Identity and Access Management (IAM) service. GKE doesn’t currently support Google Cloud's IAM service.


In Amazon ECS, you can achieve multi-tenancy by creating separate clusters, and then manually configuring AWS IAM to limit usage on each cluster.

In contrast, GKE supports namespaces, which allow users to logically group clusters and provide a scope to support multi-tenant clusters. Namespaces allow for:

  • Creation of multiple user communities on a single cluster
  • Delegation of authority over partitions of the cluster to trusted users
  • Restriction of the amount of resources each community can consume
  • Restriction of available resources to those resources that are pertinent to a specific user community
  • Isolation of resources used by a given user community from other user communities on the cluster

Health checks

In Amazon ECS, you can detect failures by using Amazon ELB health checks. Amazon ELB performs health checks over HTTP/TCP. To receive health checks, all containerized services—even those that don't otherwise need to listen to a TCP port—must set up an HTTP server. In addition, each service must be bound to an ELB, even if the service does not otherwise need to be load balanced.

In GKE, you can perform health checks by using readiness and liveness probes:

  • Readiness probes allow you to check the state of a pod during initialization.
  • Liveness probes allow you to detect and restart pods that are no longer functioning properly.

These probes are included in the Kubernetes API and can be configured as part of a PodSpec.


Because the Amazon ECS agent can only be run on Amazon EC2 instances, Amazon ECS configurations effectively can only be run on Amazon ECS. In contrast, because GKE is built on Kubernetes, Google Kubernetes Engine configurations can be run on any Kubernetes installation.


Amazon charges for the Amazon EC2 instances and Amazon EBS disk volumes you use in your deployment. There is no additional charge for Amazon ECS's container management service.

Google Cloud charges for the Compute Engine instances and persistent disks you use in your deployment. In addition, GKE charges an hourly fee for cluster management. Clusters with five or fewer nodes do not incur this fee. See GKE pricing for more information.

What's next?

Check out the other Google Cloud for AWS Professionals articles: