Serverless on AWS: What It Actually Costs vs Traditional Hosting

The serverless promise

The pitch for serverless is compelling: no servers to manage, automatic scaling, and you only pay for what you use. For many workloads, this is genuinely true. But the reality is more nuanced than the marketing suggests.

We have deployed dozens of applications on AWS serverless infrastructure — Lambda, API Gateway, DynamoDB, S3, and CloudFront. Some of them cost pennies per month. Others would have been cheaper on a traditional EC2 instance. The difference comes down to understanding your workload.

How serverless pricing works

Before we compare costs, let us understand what you are actually paying for with serverless on AWS.

AWS Lambda

Lambda charges for two things: the number of requests and the compute time (measured in GB-seconds). At the time of writing:

• Requests: £0.17 per million requests (first million free per month)
• Compute: £0.0000133 per GB-second (400,000 GB-seconds free per month)

A typical API endpoint that runs for 200ms using 256MB of memory costs roughly £0.0000008 per invocation. That is less than a thousandth of a penny.

API Gateway

API Gateway charges per request:

• REST API: £2.85 per million requests
• HTTP API: £0.90 per million requests

HTTP APIs are significantly cheaper and sufficient for most use cases. We default to HTTP APIs unless a project specifically needs REST API features like request validation or usage plans.

DynamoDB

DynamoDB charges for reads, writes, and storage:

• On-demand reads: £1.09 per million read request units
• On-demand writes: £1.09 per million write request units
• Storage: £0.228 per GB per month

For predictable workloads, provisioned capacity is cheaper but requires upfront planning.

S3 + CloudFront

For static assets and frontend hosting:

• S3 storage: £0.02 per GB per month
• CloudFront data transfer: £0.075 per GB (first 1TB)
• CloudFront requests: £0.009 per 10,000 HTTPS requests

Real-world cost comparison

Let us compare three typical application profiles.

Scenario 1: Marketing site with a contact form

A Next.js marketing site served via CloudFront with a Lambda-backed contact form that receives around 500 submissions per month and 50,000 page views.

Winner: Serverless. Not even close. For low-traffic sites, serverless is essentially free.

Scenario 2: SaaS application with 5,000 daily active users

A React SPA with a serverless API handling 2 million API requests per month, 500,000 database reads, and 200,000 writes.

Winner: Serverless. Roughly one-third the cost, with automatic scaling included.

Scenario 3: High-traffic API processing 50 million requests per month

A data-intensive API with long-running Lambda functions (average 500ms, 512MB) handling 50 million requests monthly.

Winner: EC2. At high, consistent traffic volumes, the per-request cost of Lambda and API Gateway exceeds the flat cost of always-on servers.

The hidden costs people forget

Cold starts

Lambda functions that have not been invoked recently take 100-500ms longer to respond on the first request. For most APIs this is acceptable. For latency-sensitive real-time applications, it can be a problem. Provisioned concurrency eliminates cold starts but adds a fixed monthly cost that partially negates the pay-per-use benefit.

API Gateway adds up

API Gateway is often the largest line item in a serverless bill, not Lambda itself. At 50 million requests per month, HTTP API alone costs £45. Consider whether you genuinely need API Gateway or whether Lambda function URLs (free) would suffice for internal services.

Monitoring and logging

CloudWatch Logs charges for ingestion and storage. A chatty Lambda function logging every request can generate surprisingly large log bills. We configure log retention policies (14-30 days) and use structured logging to keep costs predictable.

Developer time

This is the cost that never appears on the AWS bill but often dominates the total. Serverless applications require different debugging approaches, different testing strategies, and different deployment patterns. If your team is new to serverless, factor in the learning curve.

On the flip side, serverless eliminates server patching, OS updates, capacity planning, and 3am pages when a server runs out of disk space. For small teams without dedicated DevOps, this operational simplicity is worth more than any line item on the bill.

When serverless makes sense

Based on our experience deploying production applications, serverless is the right choice when:

• Traffic is unpredictable or spiky. Auto-scaling is built in. You do not pay for idle capacity during quiet periods.
• Your team is small. No servers to maintain means your developers spend time on features, not infrastructure.
• You are building a new application. Greenfield projects can be designed for serverless from the start, avoiding the architectural compromises of retrofitting.
• Traffic is moderate. Under 10-20 million requests per month, serverless is almost always cheaper than EC2.

When traditional hosting wins

Serverless is not always the answer:

• High, consistent traffic. If your servers are running at 70%+ utilisation around the clock, reserved EC2 instances will be cheaper.
• Long-running processes. Lambda has a 15-minute execution limit. Batch jobs, video processing, and ML inference often need more time.
• Stateful applications. Applications that rely on in-memory state or persistent connections (WebSocket servers, game servers) are awkward to run on Lambda.

Our recommendation

For most of the applications we build — React SPAs with API backends serving thousands to low millions of requests per month — serverless on AWS is the clear winner. It is cheaper, requires less operational overhead, and scales without intervention.

We default to serverless and only recommend EC2 or container-based hosting when the workload profile specifically demands it. And because we define all infrastructure as code with AWS CDK, switching between approaches is a configuration change, not a rewrite.

The best way to know which approach is right for your application is to model your expected workload against both pricing models. We do this as part of every project scoping exercise, so there are no surprises when the first AWS bill arrives.

Want help modelling costs for your project? Take a look at our cloud infrastructure services or get in touch — we are happy to walk through the numbers with you.