AWS Amplify is a framework to accelerate web and mobile application development. I needed to build an API that would return a binary object. Specifically, it allows me to download a PDF file. I could not find an example so I am documenting it here. In the end it was crazy simple. You just need to add a single line "BinaryMediaTypes": ["application/pdf"] to the AWS::ApiGateway::RestApi resource in the CFN template created by Amplify. You should make this change after Amplify generates the API but before you push it to AWS.

I published a post this summer with a few simple demo applications I use when configuring AWS infrastructure. I needed something similar for a serverless application on AWS. In other words, a Lambda function sitting behind an API Gateway or Application Load Balancer (ALB).

I tend to use this simple Node.js function. It will return whatever it received as input. This is useful when you are debugging the infrastructure. For example, configuring Cognito with API Gateway or OIDC with ALB.

In this final post I’ll list a few additional optimizations for reducing the first invocation times. See part one and two for more details.

Burst CPU

According to this video Lambda functions get additional CPU during the initialization phase. That extra CPU can help with JIT compilation but .NET lazy compiles code as it encounters it. Therefore, the function handler is not compiled until it’s executed, which is after the CPU is constrained.

In part one, I looked at what happens the first time an ASP.NET application is invoked in Lambda. When we left off, we had a roughly 3 second initial response time. In this post I’ll focus on the initialization phase and part three will focus on invocation.

ReadyToRun

As I mentioned earlier, one cause of long cold start times in .NET is Just In Time (JIT) compilation. As each .NET assembly is loaded, the runtime converts the Intermediate Language (IL) into machine code for the specific platform it is running on. ReadyToRun tells the compiler to generate machine code at compile time. This allows us to skip that step during initialization. Note that you must compile on the same platform you plan to run on. Therefore, we must build on a Linux machine for this to work in Lambda. I am using CodeBuild to build my project. I can enable ReadyToRun by adding the following to the PropertyGroup of my project file.

The ability to host an ASP.NET project in AWS Lambda is a great way to get started with serverless. However, cold starts can result in a slow first invocation of the ASP.NET function. In this post I’ll set up a typical, albeit simple, application to gather benchmarks. In part two and three, I will explore a few options to speed up initialization and invocation respectively.

Background

A Lambda function is fundamentally different from a traditional application. Most important to the topic of Cold Starts is how an application is initialized. On a traditional web server, the application is initialized before it goes into service. The first invocation may be a little slower as caches warm up, but the application itself was already running. In Lambda, the application is initialized when the first invocation arrives. The request is enqueued, Lambda copies your application into a container, initializes the application, and then forwards the request to the container. The same thing happens as Lambda scales out and adds new containers. For subsequent invocations the application is already running the response is much faster. Often one or two orders of magnitude faster.

Chalice is a Python serverless microframework for AWS that enables you to quickly create and deploy applications that use Amazon API Gateway and AWS Lambda. In this blog post, I discuss how to create unit tests for Chalice. I’ll use Chalice local mode to execute these tests without provisioning API Gateway and Lambda resources.

Creating a new project

Let’s begin by creating a new Chalice project using the chalice command line.

Note: You might want to create a virtual environment to complete the tasks in this post.