Abstract

AWS Lambda is one of the most popular services in AWS. Lambda is famous as a Function as a Service which enables developers to deploy server function only with writing some codes, without caring about a health of servers or deploying them.

In this article, I explain that current Lambda is beyond "FaaS" and has become a "Container Runtime".

AWS Lambda as a "Function"

What is "Function"? We can deploy a function written in one of programming languages, like following:

def handler_name(event, context): 
    ...
    return some_value

This function runs without launching any server infrastructure including network. This is amazing! Now such "serverless" function has become very popular.

Not only such scripts, Lambda can run also "Container". Scripts for Lambda can't include some "dependencies" for file size limit or so (we have to use Lambda layer) but container has fewer limitations in this point, it is useful. However, even in a container, we have to write "handler function" to accept a trigger which invoke Lambda function.
This makes it difficult to run and test systems in other environment than AWS Lambda. This reduces "portability", which is one of the biggest advantage of a container.

AWS Lambda as a "Container runtime"

In AWS there are popular services as a container runtime - Elastic Container Service(ECS) and App Runner. Besides this, Lambda has become very useful container runtime with some new features.

Feature1: Function URL

https://docs.aws.amazon.com/lambda/latest/dg/lambda-urls.html

Function URL create and attache URL to Lambda. A request to the URL means a "trigger" to invoke Lambda Function without API Gateway. The access to the URL can be limited only by IAM.

We can set Function URL enabled like this:

Even when Lambda is in VPC, Function URL is always active (even in Private Subnet!). This could make a big security hole without caution.

Feature2: Lambda Web Adapter

https://github.com/awslabs/aws-lambda-web-adapter

This enables us to deploy any container which accept/response HTTP on Lambda. Web Adapter can be used with only few lines in Dockerfile.

# Lambda WebAdapter
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.7.1 /lambda-adapter /opt/extensions/lambda-adapter
ENV PORT=3000
ENV READINESS_CHECK_PATH=/health

Those addtional lines makes no changes a behavior of the container. This means we can run a container of web-server on any environment, local, some container services, Lambda.

This provides "portability" between Lambda and other runtimes.

Runs Container on Lambda

1. Create Docker Image with Web Adapter
2. Deploy to Elastic Container Resistory(ECR)
3. Create Lambda Function with container image: 　　　　　　
4. Create Function URL 　　　　　　
5. Enjoy!

By these only few steps, you can achieve "web-server" with accessible URL and great scalability based on Lambda. This is wonderful, we have got a very useful container runtime (Someone said it's similar to Cloud Run of Google Cloud).

This is my hobby project chiitiler, which can run on Lambda without any other infrastructures.

https://github.com/Kanahiro/chiitiler/blob/main/Dockerfile

Conclusion

Running containers on Lambda provides us dramatically redused cost and strong scalability than ECS or App Runner. In addition, Lambda is very easy to use with simple and few settings. I believe Lambda is the best container runtime in AWS! Please try it.