AWS

Serverless Cost Traps: Why Lambda and Fargate Can Bleed Your Budget

June 30, 2026·5 min read·CloudBudgetMaster

Understand the Pricing Model

AWS Lambda charges per request ($0.20 per 1M), per GB‑second of execution, and for provisioned concurrency. Memory is allocated in 128 MiB increments; the CPU share scales linearly with memory. Data transfer out of the function is billed at standard internet rates.
AWS Fargate bills per vCPU‑second and GB‑second of memory, plus a small storage fee ($0.10 per GB‑month). The price is fixed for the amount you request, regardless of actual usage, and you also pay for the ENI attached to each task.

Understanding that you pay for what you request, not just what you use, is the first step to spotting waste.

Common Cost Traps

Trap	Why It Happens	Typical Impact
Over‑provisioned Lambda memory	Developers set 1024 MiB to be safe, but the function only needs 128 MiB. Higher memory increases the GB‑second rate and also bumps the CPU, leading to higher cost per invocation.	5‑10× per‑invocation cost increase.
Unbounded provisioned concurrency	Leaving a high provisioned concurrency value after a traffic spike means you pay for idle capacity 24/7.	Hundreds of dollars per month for a few hundred reserved instances.
Infinite retry loops	A bug that retries on failure can generate millions of extra requests.	Unexpected spikes that dwarf normal traffic.
Fargate tasks with oversized vCPU/memory	Using `0.5 vCPU` + `2 GiB` for a lightweight container that only needs `0.25 vCPU` + `0.5 GiB`.	Up to 4× cost per task hour.
Running long‑lived jobs on Fargate	Fargate is optimized for short‑lived containers. A 12‑hour batch job pays the same per‑second rate as a 5‑minute request, but you could switch to Spot or EC2 for lower price.	Unnecessary expense for batch workloads.
Not using Fargate Spot	Spot pricing can be 70‑80 % cheaper. Ignoring it means you pay full price for tasks that could tolerate interruption.	Missed savings on non‑critical workloads.

Detect Waste with the CLI and CloudWatch

List Lambda functions with high memory bash aws lambda list-functions --query "Functions[?MemorySize>`256`].FunctionName" --output text Review each function and compare actual average duration (see step 2).
Pull duration metrics bash aws cloudwatch get-metric-statistics \ --namespace AWS/Lambda \ --metric-name Duration \ --dimensions Name=FunctionName,Value=my-function \ --statistics Average \ --period 86400 \ --start-time $(date -u -d '-7 days' +%Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \ --query "Datapoints[0].Average" If the average duration is far below the allocated memory‑based timeout, you can safely lower memory.
Find provisioned concurrency that is idle bash aws lambda get-provisioned-concurrency-config \ --function-name my-function \ --qualifier $LATEST \ --query "AllocatedProvisionedConcurrentExecutions" Cross‑reference with Invocations metric; if allocated > used for > 24 h, cut it.
Identify oversized Fargate tasks bash aws ecs list-clusters --output text | tr '\t' '\n' | while read CLUSTER; do \ aws ecs list-services --cluster $CLUSTER --output text | tr '\t' '\n' | while read SERVICE; do \ aws ecs describe-services --cluster $CLUSTER --services $SERVICE \ --query "services[0].{Name:serviceName,CPU:taskDefinition.cpu,Memory:taskDefinition.memory}"; \ done; \ done Spot any service where CPU > 256 (256 CPU units = 0.25 vCPU) and Memory > 512 (512 MiB) for workloads that don’t need it.
Check Fargate Spot usage bash aws ecs list-tasks --cluster my-cluster --desired-status RUNNING --launch-type FARGATE_SPOT --output text If the list is empty, you are not using Spot at all.

Immediate Remediation Steps

Right‑size Lambda memory: Use the open‑source AWS Lambda Power Tuning tool (sam deploy with the provided template) to run a few thousand invocations at different memory levels. Choose the setting that gives the lowest cost per request.
Turn off unused provisioned concurrency: Run a script that sets ProvisionedConcurrentExecutions to 0 for any function where Invocations < AllocatedProvisionedConcurrentExecutions for the past 48 h.
Add concurrency limits: In the console or via CLI, set ReservedConcurrentExecutions to a realistic ceiling to prevent runaway scaling.
Enable SnapStart for Java functions (if applicable) to cut cold‑start duration, allowing you to lower memory while keeping latency low.
Adjust Fargate task definitions: Edit the task definition JSON and reduce cpu and memory fields to the minimum that passes your performance tests.
Switch appropriate services to Fargate Spot: Add --capacity-provider-strategy capacityProvider=FARGATE_SPOT,weight=1 to your aws ecs run-task command or update the service’s capacity provider strategy.
Set maximum task runtime: Use stopTimeout in the task definition to force termination after a reasonable period, preventing runaway containers.

Guardrails for Ongoing FinOps Discipline

CloudWatch Alarms: Create alarms on EstimatedCharges for the AWS/Lambda and AWS/ECS namespaces. Example alarm for Lambda cost > $5 in a day: bash aws cloudwatch put-metric-alarm \ --alarm-name LambdaDailyCost \ --metric-name EstimatedCharges \ --namespace AWS/Billing \ --statistic Maximum \ --period 86400 \ --threshold 5 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 1 \ --alarm-actions arn:aws:sns:us-east-1:123456789012:FinOpsAlerts
Tagging: Enforce a team and environment tag on every Lambda and Fargate task. Use the tag‑based cost allocation report to spot which groups own the most serverless spend.
Automated budgets: In the AWS Budgets console, set a budget for Lambda and Fargate services with alerts at 50 % and 90 % of the limit.
Periodic review: Schedule a bi‑weekly script that runs the CLI queries above, outputs a CSV, and emails the engineering leads. Treat the report as a mandatory ticket for any function or task that appears on the list.

CloudBudgetMaster continuously scans Lambda and Fargate configurations, flags over‑provisioned memory, idle provisioned concurrency, and non‑Spot Fargate tasks, and shows the exact dollar impact so you can remediate before the spend spikes.