A Portuguese version is available here
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 of professionals going the other way complaining, but to my surprise, that didn't happen.
And in 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.
The cloud standards we use today are primarily an effort of NIST (National Institute of Standards and Technology). These standards have guided the development and implementation of cloud technologies, ensuring a consistent and secure approach across all cloud computing providers. Because of these standards, there are many similarities between AWS and GCP's FaaS (Function as a Service) offerings.
From the practical points that are relevant to know:
01. Infrastructure:
Both AWS and GCP platforms adopt a model of dividing infrastructure into regions and zones, following the standards established by NIST (National Institute of Standards and Technology).
In the context of cloud computing, a region refers to a specific geographical area where resources can be deployed. Within each region, there are Availability Zones, which represent distinct physical data centers, isolated from each other, where services are executed.
It is important to note that, on both platforms, some services may not be available in all regions. However, for serverless function services, they are present in the Brazilian region, known as sa-east-1 in AWS and southamerica-east1 in GCP.
One point that stands out in the differences is the nomenclature of Availability Zones, where GCP professionals refer to them simply as "zone," while AWS professionals call them "AZ."
02. Different Names, Similar Services
Even though I'm basically talking about serverless functions in everyday development, we need to know much more about the framework involved for development, integration, deployment, and monitoring of our projects. Thus, below is a mapping for the most well-known services:
| Type | AWS | GCP |
| Serverless Functions | Lambda Function | Cloud Functions |
| API endpoints | API Gateway | Cloud Endpoints |
| Content Delivery Network (CDN) | Cloudfront | Cloud CDN |
| Kubernetes (K8s) Service | EKS | GKE |
| Messaging Queue Service | SQS and SNS | Cloud Pub/Sub |
| Operation, Log, and Monitoring | CloudWatch | Cloud Logging and Cloud Monitoring |
Google offers a more complete list that includes other services and is available in this comparison.
03. Costs
The pricing structure is almost identical between AWS and GCP. The main factors that impact the cost on both services are the number of requests and the execution time. It is important to note here 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 a difference between the values is how the computing time is calculated on each provider. In AWS, the execution time is charged in increments of 1 millisecond. This means that each additional millisecond is charged separately.
In Google Cloud Functions, the execution time is rounded up for each interval of 100 milliseconds after the first 100 milliseconds. This means that if the 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 milliseconds increment. For example, a function executed for 260 ms would be billed as 300 ms.
Furthermore, another important detail about price is that in GCP, computing time is measured considering memory allocation (GB per second) and CPU processing power (GHz per second).
We can also analyze the free tiers offered by cloud providers for their serverless function services.
| Provider | Free Invocations per Month | Free Compute Time (GB-seconds) per Month | Free CPU Time (GHz-seconds) per Month |
| Google Cloud Functions | 2 million | 400,000 | 200,000 |
| AWS Lambda | 1 million | 400,000 | - |
How to calculate processing:
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 much 🤷
04. Supported Languages:
Both services were spot on in including a good variety of supported languages. While Google's Cloud Functions support includes Node.js, Python, Go, and Java, Ruby, PHP, and .NET, AWS Lambda's list is slightly more extensive, facilitating the use of TypeScript (using Node environment) and including Rust and PowerShell.
Additionally, as I mainly work with Python, I noticed the providers' commitment to keeping technologies up to date. In GCP, it is 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 in GCP, Python 3.8 will be discontinued later this year (2024). A sadness for companies adhering to the culture of "If it ain't broke, don't fix it."
05. Execution Timeout:
The execution time is a crucial factor to consider when choosing between Google Cloud Functions and AWS Lambda. In Google Cloud Functions, the timeout varies according to the function's generation: in the first generation, the limit is 9 minutes (540 seconds), while in the second generation, it can reach 60 minutes (3,600 seconds) for HTTP functions and remains at 9 minutes (540 seconds) for event-driven functions.
On the other hand, in AWS Lambda, the default timeout is only 3 seconds but can be adjusted to up to 15 minutes (900 seconds) as needed. These limits can directly affect the performance and functionality of your serverless functions, especially in cases of synchronous external requests.
Below is a table summarizing the execution time limits on both platforms:
| Platform | Generation | Timeout |
| Google Cloud Functions | 1st | 540s |
| Google Cloud Functions | 2nd (HTTP) | 3,600s |
| Google Cloud Functions | 2nd (Event) | 540s |
| AWS Lambda | - | 3s (default) to 900s (max) |
06. Integration with Ecosystem:
Integration with the ecosystem was one of the factors that surprised me the most during the transition. AWS Lambda offers a very flexible integration with the entire AWS ecosystem, which has been extremely useful in the current architecture I work in. From seamless integrations with Amazon S3, Amazon DynamoDB, and Amazon API Gateway.
However, a downside is that this can lead to a high level of coupling. Although both providers support HTTP integration, AWS requires provisioning and configuring a separate resource, API Gateway, which is also charged separately.
Performance and startup time are critical aspects to consider when evaluating serverless computing options between Google Cloud Functions and AWS Lambda. Although startup time metrics are not publicly disclosed by providers, a superficial analysis reveals some significant differences.
Research indicates that Cloud Functions have a natively faster startup time compared to AWS Lambdas. However, it is challenging to draw an accurate comparison due to the lack of detailed information.
In AWS, for example, an inactive Python Lambda can start on average around 200ms, but it is worth noting that this value does not consider the use of the provisioned concurrency feature, a functionality that eliminates Cold Start by keeping instances ready to respond to requests.
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 can be performed on Cloud Storage buckets. It is less utilized in the context of GCP Cloud Functions.bq tool: The bq is a command-line tool primarily intended 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 less utilized in the context of GCP Cloud Functions.
8.2 AWS
AWS tool: The AWS Command Line Interface is the primary tool for interacting with AWS services through the command line. With the AWS CLI, users can manage EC2 instances, S3 buckets, Lambda functions, and a variety of other AWS services.SAM tool: The AWS SAM (Serverless Application Model) is an extension of the AWS CLI that makes it easy to create, test, and deploy serverless applications on AWS. With AWS SAM, developers can define serverless resources using a simplified syntax and deploy them with ease. AWS SAM overlays AWS CLI to provide us with some useful extra tools.
09. Conclusion:
As they say, the devil is in the details. The choice between AWS Lambda and Google Cloud Functions goes beyond comparing technical features. Although AWS Lambda is considered more mature, Google Cloud Functions is also a robust option, with its own range of advantages and features. The decision between the two providers should be based not only on technical characteristics but also on associated costs, developer experience, and the specific context of the project.
My migration from GCP to AWS was surprisingly smooth, contrasting with reports of difficulties I heard from professionals who went the other way. This can be attributed to the integrations and facilities offered by AWS, highlighting the importance of choosing a platform that meets the specific needs of the project and development team.
Overall, this migration not only expanded my knowledge of cloud computing and cloud-native but also highlighted the importance of platform independence. Developing and deploying software independently of underlying cloud providers not only facilitates portability between different services but also maximizes resource utilization, resulting in significant cost savings.
