Pratical Differences between GCP Cloud Functions and AWS Lambda Functions

It’s been a few months since I migrated from a GCP (Google Cloud Platform) environment to an AWS (Amazon Web Services) environment. At first, I thought I would find it strange and have difficulty adapting because I’ve heard reports from professionals going the opposite way complaining, but to my surprise, that didn’t happen.

During this transition, I decided to write and share in a didactic way the subtle differences I encountered. Instead of presenting a direct confrontation, I opted for a comparison guide to help other professionals who may be considering a similar transition.

In general, there are many similarities. Both services are serverless, falling into the category known as FaaS (Function as a Service), which reduces the need to manage and maintain servers. Additionally, they provide automatic scaling based on the number of requests received. Another characteristic is that both are services that fit within an event-driven architecture, well known to those who work with messaging.

Some practical points that are relevant to know:

01. Infrastructure:

Both platforms, AWS and GCP, adopt a model of dividing infrastructure into regions and zones. However, there are some differences in how these structures are implemented on each platform.

In AWS, the data center structure consists of AZs (Availability Zones), which represent an isolated physical data center within a region. For example, the “us-east-1” region, east coast of the United States, encompasses several AZs, identified by letters like “us-east-1a,” “us-east-1b,” and so on. Thus, a region in AWS is an area that covers multiple AZs.

On the other hand, in GCP, the region “us-west1” represents the west coast of the United States and contains multiple zones, such as “us-west1-a,” “us-west1-b,” and “us-west1-c,” also identified by letters. Each region corresponds to a specific geographical area where resources can be deployed.

In summary: Zones = Availability Zones = AZ

02. Different names, similar services

Even though we’re mainly talking about serverless functions in day-to-day development, we need to know much more about the framework involved in development, integration, deployment, and monitoring of our projects. Below, I present a mapping for the most well-known terms.

Google offers a more comprehensive list that includes other services and is available in this comparison.

03. Costs

The pricing structure is nearly identical between AWS and GCP. The main factors that impact cost in both services are the number of requests and the execution time. It’s important to note that other fees may be charged for parallel services, such as data transfer or storage costs, but these depend on the project context.

An important detail that can cause differences between the values is how computing time is calculated in each provider. In AWS, runtime is billed in increments of 1 millisecond. This means that each additional millisecond is charged separately.

In Google Cloud Functions, runtime is rounded up for each 100-millisecond interval after the first 100 milliseconds. This means that if function execution lasts less than 100 milliseconds, you will not be charged for that time. However, if it lasts more than 100 milliseconds, you will be charged for the total time rounded up to the next 100-millisecond increment. For example, a function executed for 260 ms would be billed as 300 ms.

Another similar factor with different criteria is the free tier offered by both providers. For example, AWS Lambda offers 1 million free requests per month and 400,000 GB-seconds of compute time, while Google Cloud Functions offers 2 million requests, 400,000 GB-seconds of provisioned memory, and 200,000 GHz-seconds of CPU time.

How to make processing calculations:

500,000 invocations / 40 ms duration / 128 MB

40 ms = 0.04 sec
128 MB = 0.125 GB

Usage Time: 500,000 invocations/month * 0.04 sec/invocation = 20,000 sec/month

Provisioned Memory: 20,000 sec/month * 0.125 GB = 2.5 GB-sec/month

3,000,000 invocations / 230 ms duration / 1024 MB

230 ms = 0.23 sec
1024 MB = 1 GB

Usage Time: 3,000,000 invocations/month * 0.23 sec/invocation = 690,000 sec/month

Provisioned Memory: 690,000 sec/month * 1 GB = 690 GB-sec/month

Online Calculators

AWS: https://calculator.aws/#/createCalculator/Lambda

GCP: https://cloud.google.com/products/calculator/

FAAS Calc: https://faascalc.com/

P.S.: I don’t trust Google’s calculator very much 🤷

04. Supported Languages:

Both services were accurate in including a good variety of supported languages. While Google’s Cloud Functions support Node.js, Python, Go, and Java, Ruby, PHP, and .NET, AWS Lambda Functions have a slightly longer list, making it easier to use TypeScript (using Node environment) and including Rust and PowerShell.

Additionally, as I mainly work with Python, I noticed the commitment of providers to keep technologies up to date. In GCP, it’s still possible to create a Lambda with Python 3.7, but in AWS, this is no longer allowed. It’s worth mentioning that both in AWS and GCP, Python 3.8 will be discontinued later this year (2024). A sadness for companies adhering to the “If it’s working, don’t touch it” culture.

05. Execution Time:

Another important distinction is the execution time and customization capability. In Google’s Cloud Functions (1st generation), the maximum duration time limit is 9 minutes (540 seconds), while in Cloud Functions (2nd generation), this time is 60 minutes (3,600 seconds) for HTTP functions and 9 minutes (540 seconds) for event-driven functions. In AWS Lambda Functions, the default timeout is 3 seconds but can be adjusted to a maximum of 15 minutes (900 seconds).

Execution time is an important aspect to consider, especially if the project makes use of synchronous external requests. If the average latency is high or unstable, this may result in the Lambda being terminated before it completes.

06. Integration with the Ecosystem:

Integration with the ecosystem was one of the factors that surprised me the most during the transition. AWS Lambda offers deep and flexible integration with the entire AWS ecosystem, which has been extremely helpful in the current architecture I work with. From seamless integrations with Amazon S3, Amazon DynamoDB, to Amazon API Gateway.

However, a downside is that this can lead to a high level of coupling. While both providers support HTTP integration, AWS requires the provisioning and configuration of a separate resource, the API Gateway, which is also charged separately. GCP has a much simpler HTTP integration.

07. Performance and Cold Start

I don’t intend to delve too much into this aspect since neither of the providers publicly discloses their cold start metrics.

Searching around the internet, I noticed that natively Google’s Cloud Functions start with a shorter time, but it’s quite complicated to make a comparison for this difference. However, I observed that in AWS, an inactive Lambda in Python takes an average of 200ms to start. This is without considering the “provisioned concurrency” feature, which is a functionality that allows eliminating Cold Start in AWS.

08. Command Line Tools (CLI)

Command line tools play an important role in managing cloud platforms. Both providers, AWS and GCP, offer their own CLI tools to facilitate automation, deployment, and resource management in the cloud.

8.1 GCP

gcloud tool: With gcloud, users can create, modify, and manage resources such as virtual machine instances, databases, and serverless services.

gsutil tool: With gsutil, file transfer, access policy configuration, and various other operations in Cloud Storage buckets can be performed. Little used in the context of GCP Cloud Functions.

bq tool: bq is a command-line tool primarily for BigQuery, GCP’s data analysis service. With bq, users can run SQL queries, load and export data, and manage datasets and tables. This tool is also rarely used in the context of GCP Cloud Functions.

8.2 AWS

AWS tool: AWS Command Line Interface is the primary tool for interacting with AWS services via the command line. With AWS CLI, users can manage EC2 instances, S3 buckets, Lambda functions, and a variety of other AWS services.

SAM tool: AWS SAM (Serverless Application Model) is an extension of AWS CLI that facilitates the creation, testing, and deployment of serverless applications on AWS. With AWS SAM, developers can define serverless resources using a simplified syntax and easily deploy them. AWS SAM overlays AWS CLI to provide us with some useful extra tools.

09. Conclusion:

As they say, the devil is in the details. Ultimately, AWS Lambda is more mature while Cloud Functions has a few fewer features, but it’s still quite comparable to AWS. Choosing between one provider or another is not necessarily a matter of one being better than the other, but rather of understanding the nuances and adapting to the differences.

Additionally, I realized the importance of considering not only the technical aspects but also the associated costs, developer experience, and project context. This migration has given me a broader view of the cloud computing landscape and empowered me to make more informed decisions about the infrastructure of my future projects.