AWS Lambda Now Supports arm64 (Graviton2), A Win For Our Planet!
Driving progress through pricing
One area that’s always fascinated me about AWS is how they use pricing to drive positive action from their customers.
Typically this is most apparent in how AWS incentivizes customers to adopt or migrate to the latest generation EC2 instance types. The value proposition for the customer is clear, for a lower hourly price, we’re going to give you an instance that performs faster (in some cases significantly). How often do you come across a business that continuously lowers your price over time while improving their offering?
Behind the scenes, if you’ve ever had to maintain on-prem infrastructure, you’ll be familiar with the incentives for AWS to want customers to migrate to their newest generation of hardware. As Werner Vogels famously said “Everything fails, all the time.”, and this becomes more true as hardware ages. This drives up maintenance costs, external vendor risk (a serious problem with recent chip shortages), among other headaches (/me looks around the room for the Intel rep… *cough’s into mask* critical CPU vulnerabilities *cough’s into mask*).
Where some businesses will grow their margins whenever they can realize cost savings, AWS and Amazon, in general, appear to pass much of those savings onto the customer. In my opinion, this is part of the secret sauce of Amazon’s success. It keeps them in a leading market position or at a minimum competitive, and drives some extreme levels of brand loyalty and trust from their customers.
Enough of the business strategy and pricing babble. Let’s talk tech!
You may or may not have heard that AWS Lambda as of today (Sept. 29th, 2021) now supports running on Graviton2 processors (arm64)! I’m ecstatic about this announcement, but before I explain why let’s get some background on what Graviton2 processors are first.
Why would someone want to use AWS Graviton processors?
“AWS Graviton processors are custom built by Amazon Web Services using 64-bit Arm Neoverse cores to deliver the best price performance for your cloud workloads running in Amazon EC2.”
From the AWS Graviton marketing pages it’s clear that in addition to traditional Intel and AMD processors customers can leverage an arm64 compatible processor built in-house by AWS and optimized for their cloud environment and customers needs.
Performance, as is the case with most (if not all?) new hardware roll outs at AWS, there’s a performance boost. For instance, from the same AWS Graviton marketing page they claim Graviton2 processors “provide up to 40% better price performance over comparable current generation x86-based instances”.
Price as indicated by the performance quote, they claim a 40% better price performance when compared to their Intel and AMD choices, this comes from a combination of improved performance per core and lower unit cost. On the pricing side a tangible example would be:
- t3.large (Intel x86) — $0.0832/hour
- t4g.large (Graviton2 arm64) — $0.0672/hour
- That’s nearly 20%!
Many (hazard I say most) customers on AWS are heavily into EC2, and with bills in the hundreds of thousands or millions of dollars range, 20% can be a huge cost reduction.
With the launch of Lambda on Graviton2 today, the Lambda pricing page also reflects a roughly 20% price reduction per compute unit for arm64 over x86.
Peter DeSantis (Senior Vice President of AWS Infrastructure and Support) did a great technical deep-dive at the Infrastructure Keynote from AWS re:Invent 2020 talking about the design and thought process behind the creation of AWS’s Graviton2 chips:
Graviton Challenge
Adopting and/or migrating workloads to arm64 unfortunately isn’t necessarily as easy as simply redeploying your application on a new Graviton2 powered instance type. Depending on your application stack and feature-set, you may be tied into an x86 architecture.
In an effort to try and accelerate adoption and migration of existing workloads to these Graviton2 instances, AWS has been running the Graviton Developer Challenge for the past few months, with some pretty cool prizes split across multiple category winners!
What about serverless workloads?
I’ve spent quite a bit of time talking about EC2 and how you can leverage Graviton2 processors to improve your EC2 footprint. However, if you were to ask me honestly, I almost never see a reason to use EC2 for workloads today, and Graviton2 support on EC2 doesn’t excite me. What does excite me? Serverless.
One of the most powerful advantages of leveraging the cloud to build modern applications is the ability to “go serverless”. Leveraging purpose built services that allow you write configuration code and let AWS handle the processing logic. Or when you need control of the logic, being able to write the code yourself and have it execute only when needed, eliminate persistent compute and idle spend, among many other operational, resiliency, and developer velocity advantages.
At the core of AWS’s serverless offering is a service called AWS Lambda. Being a member of the AWS Community Builders program has given me access to certain internal stakeholders at AWS and I’ve definitely made it known to them since the Graviton2 EC2 announcement that I’d love to see this offered in AWS Lambda! One of the nice advantages of building serverlessly is that you’re workload and code is often simple and abstracted enough that the underlying CPU architecture in many cases won’t matter. Most likely, AWS Lambda is going to be significantly easier to migrate compute workloads to Graviton2 than traditional EC2 workloads.
Combating climate change with serverless
The topic of climate change and how AWS pricing, serverless, and now Graviton2 helps us move in a better direction on climate change is an entire article in and of itself (currently sitting in my drafts). Hopefully I’ll get around to finishing it soon, for now though I’ll leave you with some thoughts.
One advantage we don’t often hear about when it comes to cloud workloads is the environmental impact. A responsibility that thankfully, is now starting to become front and center for a larger group of humans, governments and companies.
As mentioned earlier when Amazon finds ways to make things more efficient, they pass those cost savings onto customers. What many don’t realize, is those efficiency gains also have a material effect on the environment. It means reduced power consumption, reduced manufacturing of chips and servers, reduced land footprint for data centers, and so on…
Building modern applications using serverless architectures is at the apex of these gains — again, the actual math is for the longer format article on this topic — but you can probably imagine the resource utilization efficiency gains when you have no idle usage.
Graviton2 power performance
While I’m not aware of AWS making public the power utilization of these chips, there are couple insights available to us:
First is from that same AWS re:Invent 2020 Keynote on Infrastructure (link w/ time code) mentioned earlier:
Second is some estimates that were done by AnandTech based on available information at the time and they show potentially substantial power savings at the chip level alone:
- m5n (Intel) — 210W
- m5a (AMD) — 180W
- m6g (Graviton2) — Estimated 80–110W?
Sustainability in the Cloud
AWS has a goal of powering 100% of their operations with renewable energy by 2025, and has taken great effort to ensure their data centers are responsible environmentally.
Concerned about the environmental footprint of your on-prem data center? Don’t be, just use the Cloud.
AWS has a great page on their efforts around sustainability that I encourage you to check out.
Start using Lambda arm64 today?
I have a number of serverless workloads that I’ll begin switching over as soon as support for the architecture flag makes it into CloudFormation and CDK. As another community builder indicated today, an announcement that’s equally as important as the support in the Lambda itself. Update: looks like from the announcement, these changes have already made them into SAM and CDK! — However, there appear to still be some gaps in documentation, more info to come for sure.
In the meantime, here’s what it looks like in the AWS Management Console for Lambda when you try to create a new function:
The default remains x86_64 (Intel) but you now have an option to choose arm64 if you want to start using Graviton2 for your Lambda functions!
My first run with arm64 using the default “Hello from Lambda” code:
What are you doing with AWS to make your workloads more efficient and save the planet at the same time? Let me know in the comments below!
More content at plainenglish.io
