AWS Lambda and serverless functions
Code that runs only when something happens, and costs nothing when nothing does.
Serverless compute
Chosen per project
Maintainable handover
Lambda suits work that is bursty, occasional or triggered by an event: a nightly report, a webhook from a payment gateway, a thumbnail generated when a file lands in a bucket. For all of those, running a server twenty-four hours a day to wait for something is poor value.
It is a bad fit for steady, high-volume traffic, where the same load on a small always-on instance is cheaper and simpler — and for anything with a long startup cost or an execution time beyond the function limit.
What we build with AWS Lambda
Scheduled jobs — reports, reconciliations, reminders, cleanups
Webhook receivers from payment, messaging or logistics providers
Media processing triggered by an upload
Small APIs with unpredictable or very low traffic
Where it fits — and where it does not
Good fit when
Spiky or infrequent workloads
Event-triggered work with a short runtime
Glue between managed services
Consider something else when
Steady high traffic — a container usually costs less per request
Long-running jobs beyond the execution limit
Workloads where cold-start latency is unacceptable
Lambda or a container?
The honest split. Cost crosses over sooner than serverless marketing suggests.
Bursty traffic
Lambda — you pay only for the bursts.
Steady traffic
Container — cheaper per request at volume.
Event triggers
Lambda — wiring to S3, queues and schedules is built in.
Long jobs
Container or batch — Lambda has a hard time limit.
How we work with AWS Lambda
One job per function
Small, single-purpose handlers that are easy to reason about and cheap to redeploy.
Infrastructure as code
Functions, triggers and permissions defined in SAM or Terraform, so environments match.
Least privilege
An IAM role per function granting exactly the resources it touches, nothing wider.
Failure handling
Dead-letter targets and alarms, so a function failing silently at 3am is noticed.
Our typical AWS Lambda setup
| Concern | What we use |
|---|---|
| Runtimes | Node.js, Python and .NET |
| Triggers | API Gateway, EventBridge schedules, S3 events, SQS |
| Packaging | Zip or container image, deployed from CI |
| Permissions | One narrowly scoped IAM role per function |
| Observability | CloudWatch logs, metrics and alarms on errors and duration |
Frequently asked questions
No. It is dramatically cheaper for low or spiky usage and often more expensive for sustained high traffic. We would size it against your actual request pattern rather than assume.
They matter for user-facing requests and rarely for background work. Where they matter, provisioned concurrency or a lighter runtime helps — but if latency is critical throughout, a container is the simpler answer.
It can, and for some products that works well. For a conventional business application we would normally keep the main app on a container and use Lambda for the event-driven edges.
Services built with AWS Lambda
Cloud Solutions
Hosting designed around what your application actually needs, with the monitoring and backups that make it safe to rely on.
API Development
The interfaces that let your systems talk to each other, and let partners build on top of what you have.
Custom Software Development
Software shaped around the way your business already works, instead of a packaged product you have to reorganise around.
SaaS Development
Building a software product means building a business system around it too — tenancy, billing, onboarding and support tooling.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.