AWS & Cloud

Why Your AWS Bill Keeps Growing After You Move to Serverless

11 min read · Shelorve practice note · For CTOs, engineering leaders, and cloud architects

The FinOps discipline was largely built around EC2 and reserved instance pricing. The core practices — rightsizing instances, purchasing reserved capacity, identifying idle resources — assume a world where infrastructure is provisioned in discrete units and billed by the hour. Serverless changes the problem completely. And organisations that migrate to serverless expecting their AWS bill to fall are often surprised when it grows.

Why traditional FinOps does not transfer

In a serverless architecture, there are no instances to rightsize. There is no reserved capacity to purchase in the traditional sense. The cost model is entirely consumption-based — and the visibility problem is fundamentally different. A serverless AWS bill is composed of millions of very small charges across Lambda invocations, DynamoDB reads and writes, API Gateway requests, EventBridge events, and Step Functions state transitions. Understanding where cost is coming from requires a completely different set of practices.

The most common mistake is treating serverless as cheaper by default. It can be significantly cheaper to operate than equivalent EC2-based architectures — but only if the specific cost drivers of serverless are actively managed. Without management, serverless architectures tend to grow in cost proportionally to traffic, plus the overhead of unoptimised configurations that were never reviewed after initial deployment.

The tagging foundation

The first FinOps action for a serverless architecture is tagging. Every Lambda function, every DynamoDB table, every API Gateway stage, every EventBridge rule must be tagged with at minimum the team, product, and environment. Without this, cost allocation across business units is impossible and optimisation decisions are made without the data to support them. Shelorve makes tagging a mandatory infrastructure-as-code standard from the first deployment — retrofitting tags to a large serverless estate is painful.

Lambda cost optimisation

Lambda pricing is a function of invocation count, duration, and memory allocation. Memory allocation is the primary optimisation lever that most teams underuse. Lambda allocates CPU proportional to memory — a 1,024MB function gets twice the CPU of a 512MB function. For compute-intensive functions, increasing memory allocation can reduce duration enough to lower total cost even though the per-GB-second rate is the same. AWS Lambda Power Tuning is the standard tool for this analysis — it runs a function at different memory configurations and plots cost against performance. Shelorve runs it on all production functions during initial deployment and as part of quarterly FinOps reviews.

DynamoDB cost optimisation

DynamoDB is frequently the largest unexpected cost item in serverless architectures. On-demand capacity mode charges per request and can become expensive at scale. For tables with predictable traffic patterns, provisioned capacity with auto-scaling is significantly cheaper — the difference can be 50–70% on high-throughput tables. Inefficient query patterns compound the problem: queries that perform table scans rather than key-based lookups consume read capacity proportional to items evaluated, not items returned. In tables with millions of records, a single poorly-designed query can consume the equivalent of hours of provisioned read capacity.

API Gateway and data transfer costs

API Gateway request charges are predictable, but data transfer costs are not. Responses containing large payloads — particularly uncompressed JSON responses to API consumers — can generate significant data transfer charges that are invisible in architecture reviews because they do not appear in service-level cost breakdown. Enabling response compression on API Gateway and designing APIs to return only the fields the consumer needs rather than full records are two of the highest-ROI optimisations available in serverless architectures.

"The serverless bill is not hard to optimise. It is hard to see. Fix the visibility first — the optimisation follows from understanding where the cost is actually coming from."

— Shelorve AWS Practice

The quarterly FinOps review

Serverless FinOps is not a project. It is a quarterly discipline. Traffic patterns change, business requirements evolve, and the cost profile of a serverless estate drifts from its optimised state within months of initial tuning. Shelorve conducts quarterly FinOps reviews for every AWS environment under Application Managed Services — reviewing spend against architecture, identifying the specific functions, tables, and API routes driving cost growth, and implementing changes with measurable outcomes. AMS clients consistently see year-on-year AWS spend reduction, rather than the unmanaged growth that is the default.

AWS & Cloud

Ready to apply
these principles?

Tell us about your AWS environment. We will tell you what a FinOps review would find and what it would cost to fix.