Skip to main content

Going Serverless: Comparing Cloud Providers

Going Serverless: Comparing Cloud Providers

In this article, we are going to compare the leading cloud providers of serverless computing frameworks so that you have enough intel to make a sound decision when choosing one over the others. Realizing that every case is different, and what makes a huge impact in some decisions could easily be dismissable for others, our ultimate goal is to provide you with detailed overviews of three cloud provider options so that you are well-equipped to choose the one that best aligns with your unique objectives.

The three cloud providers we will be comparing are:

  • AWS Lambda
  • Azure Functions
  • Google Cloud

In order to compare these cloud providers, we have chosen a set of focal topics for you to consider: 

  • Pricing
  • Capacity and Support 
  • Scalability, Limits, and Restrictions
  • Security 
  • Documentation


AWS Lambda


AWS Lambda (Lambda) implements a pay-per-request pricing model:

Meter Price Free grant (per Month)
Execution Time* $0.000016/GB-s 400,000 GB-s
Total Executions* $0.20 per million executions 1 million requests


In Lambda, allocated memory and CPU are considered a single billable resource (in comparison, Google Computing Platform charges them separately) in this cloud provider. This allows expenses to be easily tracked and monitored so that your Lambda-specific budget can be kept under control. 

Bear in mind that, if any deployed Lambda functions work alongside other AWS services, you would incur additional charges that would need to be considered.

Capacity and Support:

Programming Languages:
Lambda natively supports Java, C#, Python, Node.js, Go, PowerShell, and Ruby. Additionally, Lambda provides a built-in Runtime API in case you have more specific requirements.

Events, Routines, and Interactions:
Users can create triggers or functions to: 

  • React upon a given schedule,
  • Handle resource lifecycle events, 
  • Act upon incoming HTTP requests 
  • Or even consume events from a queue. 

Lambda simply transforms the event into an object and passes it to your function. As long as the payload data is a well-formed JSON, the request can be processed. 

Integration with other AWS services (AWS DynamoDB, SQS, and Kinesis) greatly benefits Lambda, since it feeds your triggers/functions with little to no configuration needed. 

Scalability, Limits, and Restrictions:

AWS restricts the maximum of concurrent executions to 1,000, and the function and layer storage size to 75 GB per region. If needed, these limits can be increased by submitting an explicit request via the AWS Support Center. There are, however, limits that cannot be changed. You can find a comprehensive list in the AWS Lambda documentation here.

Lambda creates a new instance to process each new concurrent event. Each one frees up until the event is fully processed. But there is a limit for this initial burst of instances. Depending on the region, AWS instances’ concurrency limit varies from 500 to 3,000. If the scaling reaches its limit, any surpassing requests will fail and a retry strategy comes into play. These concurrency levels can be monitored using AWS Lambda metrics. Concurrency limit per region is available here.


Both Amazon and its users are responsible for security and vigilance. Here is how the AWS shared responsibility model breaks down the duties of each:

  • AWS Responsibility (Security of the cloud):
    AWS protects global infrastructure in which all AWS services run, including, but not limited to, AWS Lambda. All services provided by AWS are secure and its security practices are subject to third-party auditing.
  • End-User Responsibility (Security in the cloud):
    Some services (i.e EC2) demand fine-grain security config and monitoring. For other services (i.e: S3 or DynamoDB), the End-User is responsible for administering the data exposed and setting the access and permissions via IAM. AWS takes care of the rest.


Lambda has a comprehensive documentation website. It provides a developer guide, API references, and sample applications for hands-on experience.

The AWS Developer Guide covers topics such as:

  • Managing, configuring, and invoking functions
  • Lambda Runtimes and Applications
  • Interaction/integration with other services (Alexa, API Gateway, Cloudwatch, Cognito, DynamoDB, etc.)
  • Language-specific guides to build Lambda Functions (Node, Python, Java, C#, Go, etc.)
  • Enforcing security for AWS Lambda

You can combine Lambda console, CloudWatch, and other AWS services to track and take action on complex telemetry, such as request/error rates, load, consumption, and resource allocation. You can also add function logs, which CloudWatch will group by Lambda function, easing the process of debugging and testing during development. Each AWS service has dedicated tech support channels available in case you encounter an unrecoverable problem.


Azure Functions


Functions offer these different pricing plans in order to best meet your individual needs.

Capacity and Support:

Programming Languages:
Azure Functions supports these programming languages based on the Azure Functions version:


Language 1.x 2.x 3.x
C# .NET Framework 4.7 .NET Core 2.2 .NET Core 3.1
Javascript Node 6 Node 8 & 10 Node 10 & 12
Java N/A Java 8 Java 8
Python N/A Python 3.6 & 3.7 Python 3.6, 3.7 & 3.8

You can check the full specification here.

Events and Routines:
Functions support triggers (start execution of your code) and bindings (simplify coding for input and output data). You can create functions from scratch or use one of the templates to get you started quickly.

Scalability, Limits, and Restrictions:

When creating a Function app, your pricing plan will dictate the following behaviors:

  • How your function is scaled
  • The resources available to each function app instance
  • Support for advanced features, such as VNET connectivity

Both Consumption and Premium plans automatically add compute power when your code is running. Your app is scaled up when needed to handle the load, and scaled down when code stops running.
Premium plans provide some additional features, such as premium compute instances, the ability to keep instances warm indefinitely, and VNet connectivity.

To view a breakdown of the limits that apply to function apps when running in the various hosting plans, click here


Azure Functions has different ways to secure functions endpoints:

  • App Service Authentication/Authorization: The App Service platform enables Azure Active Directory (AAD) and several third-party identity providers to authenticate clients and implement custom authorization rules.
  • Use Azure API Management (APIM) to authenticate requests: With APIM, your Function app can be configured to accept requests only from the IP address of your APIM instance, enforcing single-source authentication.
  • Deploy your Function app to an App Service Environment (ASE): ASE provides a dedicated hosting environment in which to run your functions. ASE lets you configure a single front-end gateway that you can use to authenticate all incoming requests.


Azure has comprehensive documentation for Functions where you can find a quick overview, 5-minute quickstarts, and tutorials. It also gives you references and resources to expand your knowledge or learn more about a specific topic.

Microsoft has several courses related to the Azure components in their learning platform, Microsoft Learn, that provide different support plans based on user needs: 

  • Basic
  • Developer
  • Standard
  • Professional Direct
  • Premier


Google Cloud


Google Cloud (GC) includes a free tier with no expiration date, which gives you up to 2 million invocations per function, 400,000 GB-seconds, 200,000 GHz-seconds of computing time, and 5GB of Internet egress traffic per month. This allows you to get started on serverless applications and experiment with Google services at no cost. See the full Google Cloud pricing breakdown here

Capacity and Support:

Supported languages:
GC Functions can be written in Java, Node.js, Python, and Go.

Events and Triggers:
GC Functions support events (actions monitored in your GC Functions) and triggers (reactions based on the events happening). You cannot bind the same function to more than a single trigger at a time. You can, however, have the same trigger cause multiple functions to execute by simply deploying two different functions with the same trigger.

Scalability, Limits, and Restrictions:

Google provides the ability to resize clusters based on workload demands by automatically adding nodes to the clusters that may not have enough capacity to run. On the other hand, if a node in your cluster is underutilized and its Pods can be run on other nodes, GKE can delete the node to free up those resources.

Limits and Restrictions:
The following table shows the main limits GC has while deploying/running serverless functions:


Quota Description Limit Can be increased Scope
Number of functions Number of functions deployed per project 1,000 No per project
Max deployment size The maximum size of a single function deployment 100MB  for sources

500MB for sources plus modules

No per function
Max uncompressed HTTP request size Data sent to HTTP Functions in an HTTP request 10MB No per invocation
Max uncompressed HTTP response size Data sent from HTTP functions in an HTTP response 10MB No per invocation
Max event size for background functions Data sent in events to background functions 10MB No per event
Max function memory Amount of memory a function can use 2048MB No per function
Max function duration The maximum amount of time a function can run before it’s forcibly terminated 540 seconds No per invocation


GC features Cloud Identity and Access Management (IAM) so you can manage user rights to “CRUD” functions by adding or removing roles accordingly. Google also has predefined roles you can use to entitle users and then range from read-only to full access to your functions

You can manage your functions’ authentication by:

  • Using runtime service account as identity: This will automatically allow your functions to fetch the necessary permissions by obtaining and using authorization tokens.
  • Giving each function its own identity: This can be done by deploying the function with a named service account having the correct role.
  • Fetching identity access tokens: You can use the Compute Metadata Server to fetch identity tokens and access tokens.


GC offers extensive documentation, including how-to guides, quickstarts, API & references, and tutorials. Click here for more on this. Google Cloud also features multiple tech support channels, such as support packages, community forums, bug reports, and beta tester groups. 


Cloud Providers’ Comparison Table

Providers’ Comparison Table


In Summary

Today’s serverless computing alternatives offer a lot of information from which you can determine the best match for your individual needs. We have covered the main focal topics to provide you with enough insights, technical details, and specific limitations or strengths of each leading cloud providers.

Considerations like existing tech stacks or cloud providers’ footprint in your own organization could play a big role in your decision. For example, if your IT has traditionally worked with .Net Core, you could be inclined (but not limited to) to go with Azure Functions as your cloud provider. On the other hand, if your IT organization is language-agnostic and favors niche dominance and pioneering in the field, your choice would probably veer towards AWS Lambda.

Our goal is to provide you with a transparent, unbiased, and clear comparison of these cloud providers that enables you to make an informed decision when choosing serverless computing for your new and exciting endeavors.



New call-to-action