Serverless

Serverless environments

Serverless is excellent for spiky, event-shaped work and expensive for steady high-throughput traffic. We will tell you which one you have before writing any of it.

LambdaEventBridgeStep FunctionsHonest maths

What does serverless mean on AWS?

Serverless on AWS means running code without managing servers: Lambda for the code, API Gateway for HTTP, EventBridge and SQS for messages between services, Step Functions for work that outlives a Lambda timeout. You are billed for execution rather than for uptime.

The problem

Serverless is a cost decision before it is an architecture decision

A queue consumer that runs eight hours a day is a great Lambda. The same code running flat out around the clock costs more than the container it replaced, and you gave up a debugger to get there. The arithmetic takes an afternoon and it saves arguments later.

ms
billing granularity
DLQ
on every consumer
IaC
everything in Terraform
What you get

Included in the engagement

Workload triage

Which parts of the system are genuinely event-driven, which are steady-state, and what each costs in both shapes at your real volumes.

Event-driven backbone

EventBridge or SQS between services, with dead letter queues and replay, so a bad afternoon is recoverable instead of lost.

Step Functions for long work

Multi-step jobs that outlive a Lambda timeout, with the state machine visible rather than buried in retry logic.

Cold starts and concurrency

Provisioned concurrency where latency is a user-facing promise, reserved concurrency where a runaway function could otherwise drain the account limit.

Local development that works

If the only way to test is to deploy, your team will stop testing. Pipelines and local harnesses come with the build.

How it runs

How a serverless build runs

Triage first. Some of what you have should not be a Lambda, and we will say which.

  1. Workload triage

    Which workloads suit Lambda and which do not. Steady high-throughput work is usually cheaper on containers, and the maths goes in writing.

  2. Event backbone

    EventBridge and queues between components, so a slow consumer degrades instead of taking the producer down with it.

  3. Long work into Step Functions

    Anything past a few minutes, or anything needing retries and compensation, becomes a state machine rather than a chain of functions calling functions.

  4. Concurrency and cold starts

    Reserved and provisioned concurrency where latency matters, set from measurements, with the monthly cost of that choice stated.

  5. Local loop and deploy

    A development loop that runs on a laptop, and infrastructure as code so an environment gets rebuilt rather than repaired.

Comparison

Lambda or a container, by workload shape

The same code can be right in either place. What decides it is how many hours a day the work is actually running.

Lambda or a container, by workload shape
DimensionLambdaContainers on ECS or EKS
BillingPer millisecond of executionPer second the task runs, idle included
Spiky trafficScales to zero between the spikesYou pay for the floor you keep warm
Steady high trafficCosts more once utilisation stays highCheaper once a task is busy most of the hour
Cold startTens to hundreds of milliseconds, removed by provisioned concurrency at a priceNone once the task is running
Maximum run time15 minutes per invocationNo limit
Local debuggingA test harness, or deploy to find outRun the same image on a laptop
What you still operateNothing below the functionCluster or Fargate, plus image patching
Fit

Who this is for

If none of these sound like you, say so on the call and we will tell you honestly whether this is the right piece of work to start with.

  • Your traffic is spiky and you are paying for idle capacity between the spikes.
  • Background jobs are running on an EC2 box nobody wants to own.
  • An existing Lambda estate has grown past the point where anyone can trace a request.
Questions

Asked before every engagement

Anything missing, email [email protected].

Is serverless always cheaper?

No. Below roughly steady, continuous utilisation it usually wins on price and always wins on operational effort. Above that a right-sized container is cheaper. We run the numbers on your traffic and put them in writing.

Can we mix serverless and containers?

Almost every system we run does. API on containers, event processing on Lambda, is a common and sensible split.

What is the maximum a Lambda function can run for?

Fifteen minutes per invocation. Work that takes longer belongs in Step Functions, which orchestrates several short functions and keeps the state visible, or in a container task with no time limit.

How do you deal with cold starts?

Provisioned concurrency on the functions where latency is a promise to a user, and nothing on the rest, because it costs money whether the function runs or not. Trimming the deployment package and avoiding heavy initialisation gets most of the win for free.

What happens when an event fails to process?

It lands in a dead letter queue rather than disappearing. Every consumer we build has one, plus a replay path, so a bad afternoon is something you reprocess rather than something you explain to a customer.

How do developers test serverless code locally?

With a local harness and contract tests, so the loop does not require a deploy. If the only way to check a change is to push it, testing quietly stops happening, and that shows up later as incidents.

Should our API run on Lambda?

If traffic is spiky or low, yes. If it is steady and high, a container behind a load balancer is usually cheaper and easier to debug. We run the numbers against your actual request volume and put them in writing before anything is built.

Send us your AWS bill

Thirty minutes with an engineer, no slide deck. We will tell you what we would change first and what it would cost to have us do it.

Talk to an engineer