The Lambda Blog

Serverless Cloud Guide

Menu
  • Home
  • Categories
  • Projects
  • About Us
  • Privacy Policy
  • Disclaimer
  • Contact
Menu
lambda cloudformation

Update Lambdas to run on Amazons new ARM based Graviton2 processors easily using Cloudformation

Posted on December 13, 2021August 14, 2022 by user
Navigation » Home » Lambda

AWS recently announced the general availability of their new ARM based Graviton2 processors for Lambdas. Now normally the reason I like serverless design and architecture is so we don’t have to worry about all that, but pay attention to two very important things in the announcement.

  • Your Lambdas can achieve up to 34% cost/performance improvements by running on the Graviton2s.
  • It is not the default for Lambdas which will continue to run on the x86 based architecture unless set.

So unless your Lambda workloads are dependent on the underlying architecture for any reason, there is absolutely no reason not to flip the switch and update your Lambdas to use this. Every compute second saving counts quite literally to your overall costs.

The architecture can be set manually using the Lambda console, you should see the section below if you manually create a Lambda.

lambda console architecture

Or you could use the AWS CLI to do a bulk update for all you existing Lambdas. But neither of which is going to be as scalable and easy unless you have been going with an infrastructure as code solution like AWS cloudformation.

Lets see the simple way to update all the Lambdas in a stack.

Adding or updating the Function Globals section of the Cloudformation template.

There is a new “Architectures” property for the AWS Function Resource in the Cloudformation yaml.

We can set it to one of two values, x_86 or arm64. The default is x_86 and we want to override the default consistently without remembering to set it each time we define a new Lambda. For the majority of use cases, you should be good to override the default and for those cases you actually need x_86, well set it at the individual Lambda property.

The way to set a default for your cloudformation stack is to define the Globals section of the cloudformation template. It is a good practice to use the Globals to enforce any consistent setting for all your functions. I typically always override the timeout as for the most part I don’t want rogue Lambdas running for 15 minutes. I also typically set thee runtime here as almost always I go with the same language runtime for a single stack.

And now, I also set the architecture, like so.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: One of my cloudformation yamls

Globals:
  Function:
    Architectures:
      - arm64
    Runtime: python3.9
    Timeout: 300

That’s it. Simply deploy the template and all your Lambdas in thee stack will be updated.

And with this you have some future proofing the next architecture AWS brings out.

Recent Posts

  • Coding a JSON format logger in Python for use as a Lambda Layer package
  • Configuring an S3 Bucket to send events to a Lambda destination for processing
  • How to request a public SSL certificate for a domain name from the AWS Certificate Manager Console
  • Creating automated CloudFormation Stack Build and Deployments with AWS CodePipeline and CodeBuild
  • A concise guide to setting up the AWS command-line libraries on your local development environment
  • How to implement a Lambda Authorizer for an AWS AppSync API and invoke the API with the required Authorization Token
  • Filtering CloudWatch Logs by LogGroups and LogStreams and reading them using Python and the Boto3 SDK
  • Azure AD Multi Tenancy issue in AWS Cognito
  • Setting up Enterprise Federation from Azure Active Directory to Amazon Cognito using Open ID Connect
  • How to Setup IAM Multifactor Authentication (MFA) for the AWS CLI

Categories

  • Amplify
  • API Gateway
  • AppSync
  • AWS CLI
  • CloudFormation
  • CloudWatch
  • Cognito
  • DynamoDB
  • EventBridge
  • KMS
  • Lambda
  • Projects
  • Route 53
  • SES
  • SNS

Post Tags

ACM Amplify API Gateway AppSync AWS CLI Azure Boto3 CloudFormation CloudWatch CodeBuild CodePipeline Cognito DynamoDB EventBridge Firebase IAM KMS Lambda OIDC Project Python Rekognition Route53 S3 SAM SES SNS VPC

©2022 The Lambda Blog