A View of Growing ARM Adoption on AWS Lambda

by Vantage Team


Lambda Adoption

ARM will soon represent the majority of Lambda costs.

Despite the reputation that AWS has when it comes to cloud costs they generally are always working to save customers money. The latest example is the introduction of Graviton2 processors that are newly available for Lambda users as of 2022. Vantage data, despite being heavily skewed towards more cost-conscious customers, shows that AWS customers are increasingly converting their Lambda runtimes to ARM Graviton processors, and we expect that soon the majority of Lambda running time will be on ARM CPUs at the current rate.

Let’s examine the benefits of using ARM and how you can migrate your Lambda workloads to ARM and save.

ARM vs x86 Pricing on Lambda

Let’s get a primer on Lambda pricing, which involves CPU runtime, memory consumption, the number of requests made to invoke a Lambda function, and ephemeral storage. Switching to ARM only impacts the compute portions of pricing, which AWS expresses in billing statements as GB-seconds, or the amount of memory and the duration of time that a function runs. AWS has also recently introduced tiered pricing but the amount of Lambda usage required to hit the first discount tier is high at 6 billion GB-seconds or 190 years of compute per month.

For comparison, Lambda pricing is the following:

Architecture Cost
ARM $0.0000133334 per GB-second
x86 $0.0000166667 per GB-second

ARM memory costs $0.0000000017 per 128 MB while x86 memory costs $0.0000000021 per 128 MB. Between lower costs and more efficient runtime, AWS claims a 34% lower cost to run Lambda function on ARM than on x86.

Moving Lambda Functions to ARM

To take advantage of ARM processors on Lambda, some action is required depending on what runtime you are leveraging for Lambda functions.

Lambda Runtime Ease of Switching to ARM
Python 3.7 Not possible
NodeJS, Python 3.8+, Java, Ruby, .NET Easy
Custom Runtime (Amazon Linux), Go* Moderate
Container Image Moderate

Ease of ARM Graviton2 migration for different Lambda runtime options

As explained in the AWS tutorial on switching to Graviton for Lambda, the primary determining factor in the difficulty of upgrading is whether your function has binary dependencies. Custom runtimes and container images typically do have binary dependencies. For example, a specific architecture is specified when building a Docker image.

Presumably: AWS Also Wins

At the end of the day, AWS also has an incentive here which is to say that presumably despite the costs being lower for customers running on Graviton2, the margins are supposedly better to AWS. When customers get the benefit of cost savings from making this switch, AWS presumably also gets a healthier margin on a per-unit basis.

* Go is supported on Graviton with one additional step.