StackServicesLambda

Lambda

Last updated: Nov 4, 2026


Rationale

AWS Lambda is the service that Fluid Attacks uses for serverless compute in the cloud. With it, Fluid Attacks runs workloads without server management, with automatic scaling that follows the demand, and with very little operational work.

These are the primary reasons why Fluid Attacks selected it and not other alternatives:

  • It integrates easily with other AWS services. Thus, Fluid Attacks can easily connect it to many event sources.
  • AWS manages all its infrastructure. Thus, administration and scaling are mostly automatic, and the operational complexity decreases.
  • It complies with some certifications from ISO and CSA. Many of these certifications make sure that the entity uses best practices for secure cloud-based environments and information security.
  • It supports more than one runtime, for example, Python, Go, Node.js, and Ruby. Thus, it can run different types of workloads.
  • It integrates with EventBridge Scheduler to run recurring short workloads.
  • It supports Function URLs. These are direct HTTPS endpoints to a function. Origin Access Control can cryptographically restrict them to Amazon CloudFront. This is how Fluid Attacks exposes public HTTPS APIs. Read Public hosting.
  • Fluid Attacks can write the resources as code with Terraform.
  • Fluid Attacks can monitor Lambda logs and performance with Amazon CloudWatch.

Alternatives

These are the alternatives that Fluid Attacks examined before it selected AWS Lambda. The list goes from the most interesting alternative to the least interesting one for the requirements of Fluid Attacks.

Cloudflare Workers

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

  • It is primarily for edge processing, and not for general-purpose serverless compute.
  • It has runtime limits, for example, it does not have a file system, not even an ephemeral file system. Thus, it can run only some types of workloads.
  • It does not integrate easily with AWS services, where the other workloads of Fluid Attacks are.
  • To use it, Fluid Attacks must support two cloud providers for serverless compute. Thus, its stack and operational knowledge must be in more parts.

Google Cloud Functions

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

  • It gives serverless execution that is similar to AWS Lambda.
  • To use it, Fluid Attacks must support one more cloud provider, and its knowledge and tools must be in more platforms.
  • It increases operational complexity, and it does not give capabilities that Fluid Attacks does not already have on AWS.

Azure Functions

Azure Functions is the serverless compute service on Microsoft Azure.

  • It supports serverless workloads that are similar to AWS Lambda.
  • To use it, Fluid Attacks must manage a second cloud platform, and this adds complexity and operational work.
  • It does not integrate with the other parts of the AWS stack of Fluid Attacks.

Amazon EKS and Amazon ECS

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

  • Fluid Attacks prefers them for CPU-bound workloads that run for a long time. These workloads must have more control over the runtime, the dependencies, or the networking.
  • They usually have more operational work than AWS Lambda (cluster management, task definitions, auto-scaling configuration).
  • Their baseline cost is higher than the cost of Lambda for workloads with low traffic. The reason is that containers use a compute-hour model, and not a cost for each invocation.

Usage

Fluid Attacks uses AWS Lambda for these tasks:

  • To serve I/O-bound HTTP APIs that are public through Public hosting
  • To consume SQS queues and process messages when they arrive
  • To consume DynamoDB Streams and do actions when table items change
  • To process webhook requests for its GitLab bots
  • To clean GitLab CI machines that are not in use, on a schedule

Other dependencies

On this page