7 AWS Serverless Mistakes That Silently Inflate Your Cloud Bill

Serverless infrastructure has a deceptive cost model. You pay nothing when nothing runs, which creates the false comfort that bills will only ever be proportional to traffic. In practice, a handful of configuration and design mistakes routinely drive AWS costs 2-5x higher than they need to be — invisibly, until the bill arrives.

Here are the seven most common AWS serverless mistakes that inflate cloud bills, and exactly what to do about each one.

Mistake 1: Leaving Lambda Memory at the Default

The default Lambda memory allocation is 128MB. Most teams never change it. This is expensive in two ways:

First, 128MB gives your function minimal CPU. Slow execution means more billed milliseconds per invocation.

Second — and counter-intuitively — a higher memory allocation often costs less in total. Because Lambda billing is duration × memory, a function that runs in 200ms at 512MB may cost less than the same function running in 900ms at 128MB.

Fix: Run AWS Lambda Power Tuning against your functions. It tests multiple memory configurations and reports the cost-optimal setting. Do this for any function running more than a few thousand invocations per day.

Mistake 2: Using REST API Gateway When HTTP API Suffices

API Gateway REST APIs cost $3.50 per million requests. HTTP APIs cost $1.00 per million requests — a 70% reduction. Most teams defaulted to REST APIs when they were the only option. HTTP APIs now cover the majority of production use cases.

REST API features you likely do not need: request/response body transformation with mapping templates, usage plans with API keys, and AWS WAF integration at the API level (which you can add with CloudFront instead).

Fix: Audit your REST APIs. For each one, check whether you are using any REST-only features. If not, migrate to HTTP API. The Terraform or CloudFormation change is small; the bill reduction is immediate.

Mistake 3: DynamoDB On-Demand for Steady-State Tables

DynamoDB On-Demand is priced for unpredictability. It is the right choice when you genuinely cannot forecast read/write volume. It is the wrong choice for tables with stable, predictable traffic — and using it there costs roughly 6-7x more than provisioned capacity.

A table with 10 million reads and 2 million writes per month costs meaningfully less on provisioned capacity with auto-scaling than On-Demand, once traffic patterns are established.

Fix: After a table has two or more weeks of CloudWatch metrics, evaluate whether the traffic pattern is forecastable. If it is, switch to provisioned capacity with auto-scaling set to maintain 70% target utilization. Keep On-Demand for development environments and genuinely irregular batch tables.

Mistake 4: Initializing Clients and Connections Inside the Handler

Every AWS SDK client, database connection, or third-party API wrapper initialized inside the Lambda handler runs on every invocation. Moving initialization to module scope runs it once per execution environment, shared across all warm invocations.

At modest traffic — say, 5 million invocations per month — a 50ms connection setup inside the handler adds 250,000 seconds of billed compute. Outside the handler, that cost collapses to the number of cold starts.

Fix: Move all client initialization to module scope. This is one of the highest-ROI code changes you can make, and it also improves p50 response latency.

Mistake 5: No Concurrency Limits on Lambda

Without concurrency limits, a traffic spike, a retry storm, or a misconfigured event source can drive Lambda invocations to thousands per second. Each invocation bills independently. Lambda's default account-level concurrency limit (typically 1,000) provides some protection, but:

• That limit is shared across all functions in a region
• Reserved concurrency of zero is the only way to ensure a function cannot consume shared capacity unexpectedly
• Unreserved concurrency can allow a single function to starve all other functions in the same account

Fix: Set reserved concurrency limits on all production Lambda functions. Size them to the maximum realistic load, not theoretically infinite. For event-driven functions (SQS, Kinesis), also set the batch size and maximum concurrency on the event source mapping to prevent runaway scaling.

Mistake 6: Ignoring CloudWatch Logs Costs

CloudWatch Logs ingestion costs $0.50 per GB. Lambda functions log every invocation start, result, and any custom console.log output. At high invocation rates with verbose logging, this line item grows quickly and often surprises teams that are not watching it.

Log retention defaults to never expire. Old log data stored indefinitely adds storage costs.

Fix:

• Set log retention to 30-90 days on all Lambda log groups
• Use structured logging with a log level (INFO, DEBUG, ERROR) and suppress DEBUG logs in production
• Sample debug logs at 1-5% for high-volume functions rather than logging every invocation
• Review the CloudWatch line item in Cost Explorer monthly

Mistake 7: No Budget Alerts

AWS billing is billed in arrears. Without alerts, you discover problems at month-end. By then, the cost has already been incurred.

A misconfigured Lambda in an infinite retry loop, a DynamoDB table that gets unexpectedly hammered, or a forgotten development environment running at production scale — these are all problems that surface in the bill 20-30 days after they start, if you are not watching.

Fix: Create AWS Budgets for each major service category (Lambda, API Gateway, DynamoDB) and set alerts at 50%, 80%, and 100% of your expected monthly cost. Add a forecasted spend alert at 100% — this triggers before the period ends if spend is tracking above target. Route alerts to a Slack channel or an email address someone actually reads.

---

These are not obscure edge cases. Every one of these mistakes appears regularly in production AWS accounts across teams of all sizes. The good news is that most of them are configuration changes, not architectural rewrites.

If you want an infrastructure review that identifies and corrects these problems before they compound, talk to Clixo. We build and audit AWS serverless systems for product teams who need their infrastructure to be as reliable as their code.