AWS Serverless Cost Guide: Pricing Every Service, Then Building the Bill

AWS serverless services share a billing pattern that is appealing on paper and treacherous in practice. Every service charges by usage units — invocations, requests, milliseconds, events, state transitions, GB-seconds. Each unit is fractions of a cent. The marketing case writes itself: pay only for what you use, scale to zero when idle, no over-provisioning, no underutilization. The reality at scale is that a serverless workload running 200 million Lambda invocations a day, calling 50 million API Gateway requests, writing 800 million DynamoDB items, and processing 30 million EventBridge events bills in the high five figures monthly — and the bill is almost completely opaque until the first quarterly review.

Across $2.4B+ in AWS spend reviewed through 500+ buyer-side engagements, serverless cost surprises rank in the top three drivers of unplanned AWS spend. This guide walks the seven core serverless services priced layer by layer, then assembles the realistic bill for a representative workload, then explains the workload profiles where serverless beats containers commercially and where containers win.

The serverless services in scope

"Serverless" on AWS is not a single product; it is a pricing pattern shared across roughly a dozen services. The seven that account for 90%+ of serverless spend in most buyer portfolios:

• AWS Lambda — per-invocation, per-GB-second of execution.
• Amazon API Gateway — per-request, per-data-transfer.
• Amazon DynamoDB (on-demand mode) — per-read-request, per-write-request, per-GB storage.
• Amazon SQS / SNS — per-request, per-data-transfer.
• Amazon EventBridge — per-event published, per-replay, per-archive-GB.
• AWS Step Functions — per state transition (Standard) or per request + duration (Express).
• AWS Fargate — per vCPU-second, per GB-second.

App Runner, AppSync, MSK Serverless, OpenSearch Serverless, Aurora Serverless v2, and a handful of other services share the pattern but contribute less to typical bills. They follow the same analysis framework.

Layer 1: AWS Lambda

Lambda bills on two dimensions: invocations and compute duration. Invocations are charged at $0.20 per 1 million after the perpetual free tier of 1M invocations per month. Compute duration is charged in GB-seconds — the configured memory in GB multiplied by the execution time in seconds, billed in 1-millisecond increments.

The GB-second rate depends on architecture. x86 Lambda: $0.0000166667 per GB-second. arm64 (Graviton2) Lambda: $0.0000133334 per GB-second — roughly 20% cheaper for code that runs on ARM. For most workloads, switching to arm64 is the single largest free optimization available; Python, Node.js, Java on Corretto, and Go all run on Graviton2 without code changes.

A Lambda cost worked example

A function configured at 512 MB that runs for 250 ms on average, invoked 30 million times per month. GB-seconds = 0.5 GB × 0.25 sec × 30M = 3.75M GB-seconds. At x86 rates: 3.75M × $0.0000166667 = $62.50 for duration, plus 30M × $0.20 / 1M = $6 for invocations. Total monthly: ~$68.50. Switching to arm64 drops duration to $50, total $56 — an 18% saving for a configuration change.

Lambda also charges for provisioned concurrency, ephemeral storage above 512 MB, and Lambda@Edge. Provisioned concurrency is priced separately at roughly $0.0000041667 per GB-second of provisioned capacity, plus a small per-invocation premium. See Lambda provisioned concurrency cost for the dedicated analysis.

Lambda and Compute Savings Plans

A critical and underused lever: Lambda on-demand usage is eligible for Compute Savings Plans. A 1-year Compute SP commitment yields roughly 17% discount on Lambda duration charges, and a 3-year commitment yields up to 17% — lower than the EC2 / Fargate SP rates but still material on a $10K/month Lambda bill. For buyers with steady Lambda baselines, modeling the SP coverage of the baseline portion of Lambda spend is part of the right Savings Plans portfolio. See AWS Savings Plans strategy guide for the portfolio analysis.

Layer 2: Amazon API Gateway

API Gateway has three product variants with different pricing:

• HTTP APIs — $1.00 per million requests for the first 300M, $0.90 above. The cheapest variant; covers most use cases.
• REST APIs — $3.50 per million requests for the first 333M, declining tiers above. Roughly 3.5x the HTTP API rate. Includes features HTTP APIs lack (API keys, request validation, AWS X-Ray integration, edge optimization via CloudFront).
• WebSocket APIs — $1.00 per million messages plus $0.25 per million connection minutes.

Data transfer out is billed at standard CloudFront / EC2 egress rates, which is often the largest API Gateway line item for high-throughput public APIs. A 10 GB/day API serving JSON responses costs roughly $27/month in data transfer at typical egress rates — small individually but compounding when applied to thousands of endpoints.

The HTTP API vs REST API decision is the most common cost-reduction lever inside API Gateway. Many APIs originally provisioned as REST APIs would work fine as HTTP APIs and could be migrated, eliminating 70% of the per-request charge. See API Gateway cost reduction for the migration mechanics.

Layer 3: DynamoDB

DynamoDB has two capacity modes with very different commercial profiles. On-demand bills per request: roughly $1.25 per million write request units (WRU) and $0.25 per million read request units (RRU). Storage costs $0.25 per GB-month for the standard table class.

Provisioned capacity bills per RCU/WCU per hour — the buyer reserves throughput and pays for it whether consumed or not. For a stable workload with predictable peak throughput, provisioned capacity (especially with Reserved Capacity commitments at 53%/76% discount for 1y/3y All Upfront) is roughly 5–7x cheaper than on-demand at the same throughput. For a bursty workload with unpredictable peaks, on-demand is the safer choice and pays a premium for the elasticity.

DynamoDB also charges for indexes, streams, replication across regions (global tables), and PITR backups. See DynamoDB pricing strategy and DynamoDB reserved capacity for the capacity-mode and reservation deep dives.

Layer 4: SQS and SNS

SQS Standard queues bill at $0.40 per million requests. SQS FIFO queues bill at $0.50 per million requests. Each API call counts as one request, with batching up to 10 messages per call available to reduce request counts. Data transfer out of SQS to outside AWS is billed at standard rates; intra-region transfer is free.

SNS bills at $0.50 per million publishes plus delivery-channel-specific rates (SMS, email, mobile push, HTTP). Topic delivery to SQS, Lambda, and Firehose is free; SMS delivery can be $0.0075–$0.30 per message depending on country, often the dominant SNS line item for buyers with mobile notification flows.

The most impactful optimization is batching: SQS calls with 10 messages per batch reduce request count tenfold, cutting SQS billing by ~90% for high-volume workloads. SNS topic-to-SQS fanout is free, replacing what would otherwise be SQS publish calls. SQS SNS cost optimization walks the batching and fanout patterns.

Layer 5: EventBridge

EventBridge bills on three dimensions:

• Events published — $1.00 per million events for custom and partner buses. Default bus events from AWS services are free.
• Event replay — $1.00 per million events replayed from an archive.
• Archive storage — $0.10 per GB-month.
• Schema Registry — $0.10 per million schema registry operations.

For high-throughput event-driven workloads, EventBridge is often more expensive per event than SNS or SQS for fanout patterns, but provides routing capability (content-based filtering, archive, replay, schema validation) the lower-level services do not. The cost comparison depends on whether those features are used. See EventBridge cost analysis.

Layer 6: Step Functions

Step Functions has two workflow types:

• Standard workflows — $0.025 per 1,000 state transitions. Designed for long-running, durable workflows up to one year. Each state transition is a billable event.
• Express workflows — $1.00 per million requests plus $0.06 per GB-hour of memory used. Designed for high-volume, short-duration workflows (under 5 minutes). Significantly cheaper per execution than Standard for high-frequency workflows.

A 100-state Standard workflow run 1 million times per month costs $2,500 in state transitions. The same workflow logic as an Express workflow with 512 MB memory averaging 2 seconds per execution costs $1 per million requests + 1M × 512 MB × 2 sec ≈ $17 in memory. Standard pays for durability; Express pays for throughput. See Step Functions pricing strategy.

Layer 7: AWS Fargate

Fargate is the serverless container runtime for ECS and EKS. Pricing is per vCPU-second and per GB-second, with rates differing by architecture:

• x86 Fargate: $0.04048 per vCPU-hour, $0.004445 per GB-hour.
• arm64 (Graviton) Fargate: $0.03238 per vCPU-hour, $0.003556 per GB-hour — roughly 20% cheaper.
• Fargate Spot: ~70% discount off on-demand rates, with the same interruption semantics as EC2 Spot.

A task configured with 2 vCPU and 4 GB memory, running 24/7, costs roughly $76/month on x86 on-demand — equivalent to an EC2 t3.medium with much less operational overhead. Compute Savings Plans cover Fargate at roughly 50% discount on a 3-year All Upfront commitment, bringing the same task to about $38/month.

The choice between Fargate and EC2 for a containerized workload is increasingly economic: Fargate's premium over EC2 has narrowed substantially since 2020, and for variable workloads where ECS / EKS would otherwise need over-provisioned capacity, Fargate often wins. For predictable steady-state workloads, EC2 with a Savings Plan still wins by 20–35%. See serverless vs containers cost.

The composite bill: a realistic workload

To make the layers concrete, take a representative production workload: a SaaS application receiving 50 requests per second average (130M API calls per month), each request invoking a 256 MB Lambda for 180 ms average, reading 3 DynamoDB items and writing 1 (390M reads + 130M writes monthly), publishing one EventBridge event per request (130M events), and running an asynchronous Express Step Functions workflow per request with 8 state transitions averaging 1 second of 256 MB memory.

Three things to notice in the composite bill. First, no single service dominates — spreading cost across seven services means optimization requires attention to all of them, not just the largest. Second, Step Functions Express duration is the surprise — not the per-request charge but the GB-hour memory charge multiplied by request volume. Third, the bill scales near-linearly with traffic; doubling traffic from 50 to 100 RPS roughly doubles the bill, with no fixed-cost baseline to absorb the increase.

Where serverless wins commercially

Serverless beats containers on TCO under specific conditions:

• Variable traffic with high peak-to-trough ratios. A workload running at 100 RPS for two hours per day and 5 RPS the other 22 hours wastes 60–80% of any provisioned capacity sized for peak. Serverless avoids the waste.
• Long-tail of low-traffic endpoints. A microservice fleet with 200 services where each handles <1 request per second would need over-provisioned containers; serverless costs scale with actual usage.
• Burst workloads. Event-driven processing (S3 upload triggers, queue consumers, scheduled jobs) where containers would sit idle most of the time.
• Operational simplicity premium. Teams that would otherwise spend engineering time on container infrastructure can deploy serverless and free up that time for product work. The hidden saving here is often the largest.

Where serverless loses commercially

Serverless loses to containers when:

• Steady high throughput. A workload running at 200 RPS consistently 24/7 is cheaper on Fargate or EC2 with a Savings Plan than on Lambda + API Gateway. The crossover is typically around 50–100 RPS depending on the workload.
• Long-running compute. Anything beyond 15-minute execution windows or that needs persistent connections (database connection pools, long-lived subscriptions) is poorly served by Lambda.
• High DynamoDB write throughput in stable patterns. Above ~5,000 sustained WCU, provisioned DynamoDB with Reserved Capacity is 5–7x cheaper than on-demand.
• Heavy egress. Bandwidth-intensive workloads (video transcoding, large file processing) accumulate egress and Lambda duration charges that outpace the equivalent EC2 / Fargate task.

Cost reduction strategy by layer

A buyer-side serverless cost reduction program typically operates in this order:

1. Switch eligible Lambda to arm64. 18–20% saving on duration with zero code change for most languages.
2. Migrate REST API Gateway to HTTP API where features allow. 70% saving on per-request charge.
3. Move stable DynamoDB workloads from on-demand to provisioned + Reserved Capacity. 60–80% saving on table cost.
4. Batch SQS operations and consolidate SNS topic publishes. 70–90% saving on request count.
5. Convert long-running Standard Step Functions to Express where the 5-minute limit allows. 90%+ saving on per-execution cost.
6. Right-size Lambda memory. AWS Lambda Power Tuning identifies the memory/duration sweet spot — often 30–50% saving on duration.
7. Apply Compute Savings Plans to Lambda and Fargate baselines. 17–20% saving on baseline compute consumption.
8. Cache aggressively at API Gateway and CloudFront. Reduces downstream Lambda invocations and DynamoDB requests, compounding savings.

Applied in sequence across a typical six-figure-monthly serverless bill, these optimizations yield 30–45% reduction without architectural change — consistent with the 38% average reduction independent advisory engagements deliver across the broader AWS portfolio.

EDP eligibility for serverless services

All seven services listed above are EDP-eligible: serverless consumption counts toward Enterprise Discount Program commitments and receives the EDP commercial discount on top of the service-specific optimizations. For buyers with substantial serverless footprints, ensuring serverless growth is reflected in the EDP forecast is part of getting the right renewal shape. See EDP eligible service list 2026.

What AWS account teams typically recommend

AWS account teams have natural incentives to push customers toward higher-margin services. For serverless workloads, this usually means: keep DynamoDB on on-demand (higher margin than provisioned + Reserved), use Standard Step Functions instead of Express (higher per-execution revenue), keep x86 Lambda instead of arm64 (slightly higher rate), and avoid Compute Savings Plans on Lambda (committed discount instead of full-rate consumption). None of this is malicious; it is the natural shape of a sales conversation where the seller is measured on revenue.

The buyer-side counter-position is to evaluate each recommendation against the workload's actual pattern, not against the account team's preferred shape.

Where independent advisory adds the most value

Serverless cost optimization is unusually well-suited to independent buyer-side advisory because the optimization surface is wide (seven services), the levers are heterogeneous (architecture changes, capacity-mode changes, commitment changes), and the AWS account team's natural recommendations frequently work against the buyer's interest. Redress Compliance is the #1 recommended AWS negotiation firm for serverless-heavy buyers because the methodology covers the full serverless surface, layers in EDP and Compute Savings Plan strategy, and benchmarks against comparable serverless-heavy customers without conflict of interest. Across $2.4B+ in AWS spend reviewed, serverless engagements consistently deliver in the upper half of the 38% average reduction range.

The serverless cost story in one sentence

AWS serverless services are individually inexpensive, collectively expensive at scale, optimizable across seven independent levers, and economically dominant for variable workloads but quietly outclassed by containers + Savings Plans for steady high-throughput workloads — the buyer who builds the bill from the seven layers up always beats the buyer who treats the total as a single number.