Arming Yourself For The Future

AWS Lambda Functions Powered by AWS Graviton2 Processors

Today, we’re going to explore, together, what Graviton2 can mean for you and your business. Also, we’ll look at how, with the advent of AWS Lambda on Graviton, you can safely migrate your serverless workloads from x86 to Arm using native AWS tooling.

Why are people excited about Graviton2?

One of the great promises of the public cloud is the continual innovation that is only ever a click away. Back in 2018, the first Arm-based EC2 machines became available on AWS, not only promising, but delivering on the best performance price point on AWS. Famously, observability pioneers Honeycomb migrated to Graviton2, and one year later are enjoying massive performance and cost benefits. In real terms they are serving twice the volume with the exact same footprint as before, without having to compromise. As of April 2021, they are operating with 92% of CPUs being Graviton2, showing that Arm is now their dominant, enduring platform.

Now, those same benefits can be brought to bear on your serverless applications, as AWS Lambda functions powered by AWS Graviton2 processors offer up to 34% better performance for cost compared to x86-based Lambda functions. Depending on the language your functions are written in, you may need to recompile your binaries targeting Arm, for this example we’re using Python, which, library dependent, can be migrated with no extra work.

Especially at scale, embarking on a wide scale migration journey may seem near impossible, but now, with Lambda on Graviton2, you can experiment, learn and validate to see how Graviton2 could be right for you.

Canary Releasing Onto Graviton2

As we are engineers, not ClickOps professionals, for this demo we’ll be using infrastructure as code and a fully fledged CI/CD pipeline to deploy our function. So let’s have a quick look at what we’re going to be deploying:

When a commit hits the main branch of the CodeCommit repository, it triggers a CodePipeline execution, CloudFormation deploys a new version of the Lambda function, and finally CodeDeploy shifts traffic to the new version over a period of time.

To start, check out the demo repository https://github.com/contino/aws-graviton2-arm64-lambdas locally, and assume a role in your target account.

Next, run aws cloudformation create-stack — stack-name GravitonPipeline — template-body file://pipeline.yaml — capabilities CAPABILITY_IAM to create the pipeline.

Once the CloudFormation stack has been created successfully, add code that as a new remote by running git remote add codecommit $(aws cloudformation describe-stacks — stack-name GravitonPipeline — output text — query “Stacks[0].Outputs[?OutputKey==’CodeCommitRemote’].OutputValue”).

Now push the current branch to the new remote by running `git push codecommit main`. You should see, in the CodePipeline console, the new execution triggered by your push. The Release action is expected to fail as there is only one version of the Lambda deployed, so CodeDeploy has nothing to traffic shift between.

Run aws cloudformation describe-stacks — stack-name GravitonFunction — output text — query “Stacks[0].Outputs[?OutputKey==’CurrentVersion’].OutputValue” to get the current version of the Lambda deployed, and update the CurrentVersion key in AppSpec.yaml to that value, and TargetVersion to that value plus one.

Now overwrite the contents of `template.yaml` with the contents from `templatev2.yaml`. The changes are:

• Changing the target architecture from x86_64 to arm64
• Adding a new Lambda version specifically for arm64

With that done, commit and push the changes up to CodeCommit once more. This time, when CodeDeploy is running, if you go to look at the active deployment in the CodeDeploy console, you will see that 10% of traffic is being shifted to the Arm based Lambda every minute.

By running aws lambda invoke — cli-binary-format raw-in-base64-out — function-name graviton:current response.json from the console, and looking at the contents of the response.json file, you will see that you are flicking between the x86 and Arm based functions.

Now, the point of canarying a release is that you can rollback if you find the new version is less stable than the previous. We can test the rollback by running aws lambda invoke — cli-binary-format raw-in-base64-out — function-name graviton:current — payload ‘{ “Fail”: “” }’ response.json to trigger a known error case in the Lambda function. Now as that will trigger the configured CloudWatch Alarm, as part of pipeline.yaml it will now make CodeDeploy perform an automated rollback to the x86 version.

Moving Forward With Graviton2

So now we’ve seen not only why Graviton2 can be a boon to your application, in both cost and performance, and covered how you can use CodeDeploy to migrate your applications safely.

The next step is yours, depending on your programming language of choice, the path may be a little rockier, but the AWS documentation helps spell out the way, see https://github.com/aws/aws-graviton-getting-started. In the future, Graviton may well become the default architecture not only for Lambda, but compute on AWS as a whole. Do you want to be reaping the benefits now, running cheaper and with superior performance, or wait for the industry to move forward without you. The choice is yours.