Lambda

Last updated: Apr 24, 2026

Rationale

AWS Lambda is the service we use for serverless compute in the cloud. It allows us to execute workloads without managing servers, scaling automatically based on demand, and with minimal operational overhead.

The main reasons why we chose it over other alternatives are:

It integrates seamlessly with other AWS services, allowing us to easily connect with a variety of event sources.
As all its infrastructure is managed by AWS, administration and scaling are largely handled automatically, reducing operational complexity.
It complies with several certifications from ISO and CSA. Many of these certifications are focused on ensuring that the entity follows best practices regarding secure cloud-based environments and information security.
It supports multiple runtimes, including Python, Go, Node.js, and Ruby, giving flexibility to run different types of workloads.
It integrates with EventBridge Scheduler, enabling the execution of recurring short-lived workloads.
It supports Function URLs, direct HTTPS endpoints to a function that can be cryptographically restricted to Amazon CloudFront via Origin Access Control. This is how we expose public HTTPS APIs — see Public hosting.
Resources can be written as code using Terraform.
Lambda logs and performance can be monitored using Amazon CloudWatch.

Alternatives

Below are the alternatives we evaluated before choosing AWS Lambda, ordered from most to least interesting based on our specific needs.

Cloudflare Workers

Cloudflare Workers is a serverless edge-function platform by Cloudflare.

It is mainly focused on edge processing rather than general-purpose serverless compute.
It presents runtime limitations such as the lack of a file system, not even ephemeral, which constrains the set of workloads it can run.
It does not integrate easily with AWS services, where the rest of our workloads live.
It would fragment our stack and operational know-how by requiring us to support two cloud providers for serverless compute.

Cloudflare Workers was last reviewed on Apr 23, 2026.

Google Cloud Functions

Google Cloud Functions is the serverless compute service on Google Cloud.

It provides serverless execution comparable to AWS Lambda.
Adopting it would require supporting another cloud provider, fragmenting knowledge and tooling across platforms.
It would increase operational complexity without delivering capabilities we do not already have on AWS.

Google Cloud Functions was last reviewed on Apr 23, 2026.

Azure Functions

Azure Functions is the serverless compute service on Microsoft Azure.

It supports serverless workloads comparable to AWS Lambda.
Using it would introduce a second cloud platform to manage, adding complexity and operational overhead.
It does not integrate with the rest of our AWS stack.

Azure Functions was last reviewed on Apr 23, 2026.

Amazon EKS and Amazon ECS

Amazon EKS and Amazon ECS are AWS container-orchestration services.

They are preferred for CPU-bound, long-running workloads that require more control over runtime, dependencies, or networking.
They typically have higher operational overhead than AWS Lambda (cluster management, task definitions, auto-scaling configuration).
They have higher baseline cost than Lambda for low-traffic workloads because containers run on a compute-hour model rather than per-invocation.

Amazon EKS and Amazon ECS were last reviewed on Apr 23, 2026.

Usage

We use AWS Lambda for:

Serving I/O-bound HTTP APIs, exposed publicly via Public hosting.
Consuming SQS queues to process messages as they arrive.
Consuming DynamoDB Streams to perform actions when table items change.
Processing webhook requests to power our GitLab bot and Google Chat app.
Cleaning GitLab CI stale machines on a scheduled basis.