This chapter focuses on cost optimization strategies for two core AWS serverless services: AWS Lambda and Amazon DynamoDB. As a developer, you must understand how to design and configure these services to minimize costs without sacrificing performance. On the DVA-C02 exam, cost optimization questions appear in approximately 10-15% of the total questions, often integrated into scenario-based questions that test your ability to choose the most cost-effective configuration. Mastering these patterns is essential for passing the exam and building production-ready applications.
Jump to a section
Imagine a busy corporate cafeteria where employees (your application's requests) go through a hot food line (your AWS services). The cafeteria charges per tray and per ingredient. Your goal: serve every employee with minimal cost. You have a hot food station (Lambda) that cooks each meal on demand. Each time an employee takes a tray, you pay for the cooking time and the tray itself. If an employee takes a huge tray (over-provisioned memory) or leaves it on the line unused (cold start waste), you pay more. The salad bar (DynamoDB) charges per scoop (read/write capacity) and per ingredient (storage). If you take too many scoops at once (provisioned capacity spikes), you pay a premium. The cafeteria manager (AWS Cost Explorer) shows you daily spending. You can optimize by: (1) right-sizing the tray size (Lambda memory) to match the meal, (2) using the 'pay-per-scoop' plan (DynamoDB on-demand) for unpredictable traffic, (3) prepping ingredients in bulk (Lambda provisioned concurrency) to avoid line delays, and (4) using a loyalty card (Savings Plans) for steady meals. The exam tests your ability to identify which lever to pull – tray size, scoop plan, or bulk prep – based on the application's traffic pattern.
1. AWS Lambda Cost Components
AWS Lambda pricing is based on three key factors: number of requests, duration, and provisioned concurrency. The first 1 million requests per month are free, and the first 400,000 GB-seconds of compute time per month are free. Beyond that, you pay $0.20 per 1 million requests and $0.0000166667 per GB-second. Duration is calculated from the time your code starts executing until it returns or terminates, rounded up to the nearest 1 ms. Memory is configurable from 128 MB to 10,240 MB in 1 MB increments. Duration cost is proportional to memory: a function with 1024 MB memory costs 8x more per second than one with 128 MB memory.
2. Lambda Cost Optimization Strategies
Right-size memory: Higher memory often reduces execution time because CPU and network resources scale with memory. However, increasing memory also increases cost per second. The optimal memory is where the product of memory and execution time is minimized. For example, a function that runs for 200 ms at 128 MB costs $0.0000000005 per invocation, while at 1024 MB it might run for 50 ms, costing $0.0000000008 – a 60% increase. Use AWS Lambda Power Tuning tool to find the sweet spot.
Minimize execution time: Optimize code to reduce runtime. Use efficient libraries, avoid synchronous HTTP calls, and leverage asynchronous processing where possible. Shorter execution directly reduces duration charges.
Use reserved concurrency: Reserved concurrency ensures a set number of concurrent executions are always available, but it also incurs charges even when not used. Only use it for latency-critical functions. For cost-sensitive workloads, prefer unreserved concurrency.
Leverage provisioned concurrency: Provisioned concurrency keeps a number of execution environments initialized and ready to respond immediately. You pay for the time they are provisioned, even if not used. This is cost-effective only for functions with predictable traffic patterns and high cold-start penalties.
Optimize request patterns: Batch events using SQS or Kinesis to reduce the number of invocations. For example, process 100 records in one invocation instead of 100 invocations.
Choose the right architecture: Arm64 (Graviton2) processors offer up to 34% better price-performance for many workloads. Switch to Arm64 if your runtime supports it.
3. DynamoDB Cost Components
DynamoDB pricing includes: read/write capacity (provisioned or on-demand), storage, data transfer, and optional features like Global Tables, DynamoDB Accelerator (DAX), and backups. For provisioned mode, you pay per WCU (Write Capacity Unit) and RCU (Read Capacity Unit) per hour. 1 WCU = one 1 KB write per second; 1 RCU = one 4 KB strongly consistent read per second (or two 4 KB eventually consistent reads per second). On-demand mode charges per request: $1.25 per million write request units and $0.25 per million read request units. Storage costs $0.25 per GB-month for standard tables.
4. DynamoDB Cost Optimization Strategies
Choose the right capacity mode: Use on-demand for unpredictable or variable traffic; provisioned for steady, predictable traffic. On-demand can be up to 7x more expensive than provisioned for sustained loads.
Use auto scaling: For provisioned capacity, enable auto scaling with target utilization (default 70%). This adjusts capacity based on actual usage, reducing over-provisioning.
Optimize item size: Smaller items consume fewer capacity units. Use short attribute names, compress data, and store only necessary attributes. Avoid storing large blobs; use S3 instead.
Use global secondary indexes (GSIs) sparingly: Each GSI consumes additional read/write capacity. Only create GSIs you need, and consider sparse indexes.
Leverage DynamoDB Accelerator (DAX): DAX is a fully managed, in-memory cache that can reduce read costs by offloading read traffic from the table. However, DAX itself costs money; evaluate if read cost savings justify DAX cost.
Use TTL: Enable Time to Live (TTL) to automatically delete expired items, reducing storage costs. TTL is free.
Choose eventual consistency: Eventual consistent reads cost half the RCUs of strongly consistent reads. Use eventual consistency when possible.
Batch operations: Use BatchGetItem and BatchWriteItem to reduce the number of requests. BatchWriteItem can write up to 25 items or 16 MB per request, reducing write costs.
Use reserved capacity: DynamoDB Reserved Capacity offers significant discounts (up to 50%) for committing to a minimum usage level for one or three years. This is cost-effective for stable workloads.
5. Interaction Between Lambda and DynamoDB
Lambda functions often read from or write to DynamoDB. Each interaction consumes capacity units. For example, a Lambda function that writes 10 items of 2 KB each to DynamoDB consumes 20 WCUs (since each 2 KB write requires 2 WCUs). If the function runs 1 million times per month, that's 20 million WCUs. At $0.00065 per WCU-hour (provisioned), that costs $13 per hour if provisioned, but with on-demand it's $25 per million writes = $250 per month. Optimizing the Lambda function to batch writes or reduce item size directly reduces DynamoDB costs.
6. Monitoring and Tools
AWS Cost Explorer: Visualize and analyze your spending. Filter by service (Lambda, DynamoDB) and usage type.
AWS Budgets: Set cost and usage budgets with alerts.
AWS Compute Optimizer: Recommends optimal Lambda memory settings based on historical usage.
DynamoDB Capacity Calculator: Estimate costs based on item size, read/write patterns, and consistency.
AWS Lambda Power Tuning: Open-source tool that tests different memory configurations and reports the optimal one for cost or performance.
7. Common Cost Traps
Over-provisioning DynamoDB: Setting high provisioned capacity for low-traffic tables leads to wasted spend. Always use auto scaling or on-demand.
Ignoring Lambda duration: A function that runs for 1 second at 128 MB costs the same as a function that runs for 125 ms at 1024 MB. Developers often choose higher memory for speed without checking if the cost increase is justified.
Not using reserved concurrency: For critical functions, unreserved concurrency can cause throttling, leading to retries and increased costs. But over-reserving also wastes money.
Using strongly consistent reads unnecessarily: Strongly consistent reads cost twice as much. Many applications can tolerate eventual consistency.
Storing large items in DynamoDB: Items larger than 1 KB consume multiple capacity units. For example, a 4 KB item consumes 4 WCUs per write and 1 RCU per strongly consistent read. Use S3 for large blobs and store the S3 key in DynamoDB.
Analyze current Lambda usage
Use AWS Cost Explorer to view Lambda costs by function, memory, and duration. Identify functions with high invocation counts or long durations. For each function, note the average memory setting, average duration, and number of invocations per month. This baseline helps prioritize optimization efforts.
Right-size Lambda memory
Run AWS Lambda Power Tuning on candidate functions. This tool invokes the function with different memory configurations (128 MB to 10,240 MB) and records execution time and cost. It outputs the optimal memory for cost, performance, or balance. For example, a function that runs at 128 MB for 300 ms might run at 512 MB for 80 ms, reducing cost by 30%. Apply the recommended memory setting.
Optimize Lambda code and dependencies
Reduce execution time by optimizing code: use async I/O, avoid cold starts by minimizing deployment package size, and use language-specific optimizations (e.g., Python's lru_cache). Remove unnecessary dependencies. For example, a Node.js function that loads a large SDK can be optimized by importing only the required modules. This reduces both duration and memory footprint.
Choose DynamoDB capacity mode
Evaluate traffic patterns. If traffic is unpredictable or spiky, select on-demand capacity. If traffic is steady and predictable, use provisioned capacity with auto scaling. For example, a production table with 10,000 reads/sec and 5,000 writes/sec consistently would be cheaper with provisioned (auto scaling set to 70% utilization). Use the DynamoDB Pricing Calculator to compare costs.
Optimize DynamoDB item size and access patterns
Reduce item size by using short attribute names, compressing data, and storing only necessary attributes. For example, change 'customer_name' to 'cn'. Use batch operations to reduce request count. For read-heavy workloads, use DAX if the cache hit ratio is high enough to offset DAX costs. Enable TTL to automatically delete expired data.
Implement monitoring and budgets
Set up AWS Budgets with alerts for Lambda and DynamoDB costs. Use Cost Explorer to track daily spend. Enable detailed billing reports. For example, create a budget that notifies you if Lambda costs exceed $100 in a month. Regularly review and adjust configurations based on usage patterns.
Enterprise Scenario 1: E-commerce Product Search
A large e-commerce company uses Lambda to process product search queries and DynamoDB to store product metadata. The system handles 10 million requests per day, with spikes during Black Friday (10x normal). Initially, they used provisioned DynamoDB capacity set to peak load, resulting in 90% underutilization on normal days. They also used 1024 MB Lambda functions with 200 ms average duration. By switching DynamoDB to on-demand, they eliminated over-provisioning costs, saving 60% on DynamoDB. For Lambda, they ran Power Tuning and found that 512 MB reduced duration to 100 ms, cutting Lambda costs by 50%. They also implemented DynamoDB DAX for the product catalog, reducing read costs by 70% but adding DAX cost. Overall, they reduced total cost by 45%.
Enterprise Scenario 2: IoT Data Ingestion
A manufacturing company ingests sensor data from thousands of devices. Each device sends a 1 KB payload every minute to an API Gateway endpoint, which triggers a Lambda function that writes to DynamoDB. They processed 5 million writes per day. Initially, they used provisioned DynamoDB with 10,000 WCUs, but actual usage varied between 2,000 and 8,000 WCUs. By enabling auto scaling with target utilization of 70%, they reduced provisioned capacity to an average of 4,000 WCUs, saving 60%. For Lambda, they used 128 MB memory with 50 ms duration. They further optimized by batching writes: instead of one write per invocation, they buffered data in SQS and used a Lambda function that reads up to 10 records and writes them in a single BatchWriteItem call, reducing write costs by 90%.
Common Pitfalls
Misconfiguring DynamoDB auto scaling: Setting the target utilization too low (e.g., 20%) leads to over-provisioning; too high (e.g., 99%) causes throttling during traffic bursts. The recommended default is 70%.
Ignoring Lambda cold starts: Provisioned concurrency can eliminate cold starts but at a cost. For latency-sensitive applications, the cost may be justified, but for batch processing, it's wasteful.
Not using AWS Compute Optimizer: This tool provides memory recommendations for Lambda functions. Many teams manually adjust memory without data-driven insights, leading to suboptimal cost-performance trade-offs.
DVA-C02 Objective 4.2: Troubleshooting and Cost Optimization
The exam tests your ability to identify cost optimization strategies for Lambda and DynamoDB in scenario-based questions. Key areas:
Lambda memory optimization: Questions often present a function with high duration and ask how to reduce cost. The correct answer is usually 'use AWS Lambda Power Tuning to find optimal memory' or 'increase memory to reduce duration and lower cost per invocation'. Wrong answers include 'decrease memory' (which increases duration and may increase cost) or 'increase timeout' (which does not reduce cost).
DynamoDB capacity mode selection: Given a traffic pattern (e.g., steady vs. unpredictable), choose between on-demand and provisioned. Wrong answers: using on-demand for steady traffic (more expensive) or provisioned for unpredictable traffic (risk of throttling or over-provisioning).
Auto scaling configuration: Questions may ask how to avoid throttling while minimizing cost. The answer is 'enable auto scaling with target utilization of 70%' or 'use on-demand'. Wrong answers: 'set high provisioned capacity' (costly) or 'disable auto scaling' (risk of throttling).
Item size and capacity units: Be able to calculate RCUs/WCUs. For example, a strongly consistent read of a 6 KB item consumes 2 RCUs (6 KB / 4 KB rounded up). A write of a 2.5 KB item consumes 3 WCUs (2.5 KB / 1 KB rounded up). Exam questions may ask how to reduce capacity consumption – answer: 'use smaller attribute names' or 'use eventual consistency'.
Batch operations: Questions may ask how to reduce DynamoDB write costs for a Lambda function that writes individual items. The correct answer is 'use BatchWriteItem to batch writes'.
Reserved capacity and Savings Plans: Know that reserved capacity offers discounts for 1- or 3-year commitments. Wrong answers: using reserved capacity for variable workloads (wasteful) or confusing with on-demand.
7. Common wrong answers: - 'Use DynamoDB Accelerator (DAX) to reduce costs' – DAX adds cost; it reduces read latency, not necessarily cost, unless it significantly reduces read capacity. - 'Increase Lambda timeout' – timeout does not affect cost; only duration matters. - 'Use provisioned concurrency for all functions' – provisioned concurrency incurs charges even when idle.
Edge cases:
Lambda functions with very short durations (<100 ms) may benefit from higher memory to reduce duration further, but the cost per GB-second may increase. The optimal is not always higher memory.
DynamoDB on-demand has a per-request cost that includes a 'burst' allowance. If you exceed the burst capacity, you get throttled, not charged more.
TTL deletions are free and do not consume write capacity.
Lambda cost = requests * (duration in seconds * memory in GB * $0.0000166667). First 1M requests and 400K GB-seconds free per month.
DynamoDB 1 WCU = 1 write of 1 KB per second; 1 RCU = 1 strongly consistent read of 4 KB per second or 2 eventually consistent reads.
Use AWS Lambda Power Tuning to find the memory configuration that minimizes cost for each function.
For DynamoDB, use on-demand for unpredictable traffic; provisioned with auto scaling for steady traffic.
Reduce DynamoDB costs by using smaller items, batch operations, TTL, and eventual consistency.
DynamoDB auto scaling reacts within minutes; sudden spikes may still cause throttling without on-demand.
Lambda provisioned concurrency charges for idle time; use only for latency-critical functions with predictable traffic.
AWS Compute Optimizer recommends optimal Lambda memory settings based on historical usage.
These come up on the exam all the time. Here's how to tell them apart.
DynamoDB Provisioned Capacity
Pay per WCU/RCU per hour (e.g., $0.00065 per WCU-hour).
Best for steady, predictable traffic patterns.
Can use auto scaling to adjust capacity (target utilization 70%).
Requires capacity planning to avoid throttling or over-provisioning.
Offers reserved capacity discounts (up to 50% for 1- or 3-year commitments).
DynamoDB On-Demand Capacity
Pay per request ($1.25 per million write units, $0.25 per million read units).
Best for unpredictable or variable traffic patterns.
No capacity planning needed; scales instantly.
Can be up to 7x more expensive than provisioned for sustained loads.
No reserved capacity; pay-as-you-go only.
Mistake
Increasing Lambda memory always increases cost.
Correct
Higher memory reduces execution time because CPU and network scale with memory. The total cost (memory * duration) may decrease if the duration reduction is proportionally larger than the memory increase. For example, doubling memory might halve duration, keeping cost the same or reducing it.
Mistake
DynamoDB on-demand is always cheaper than provisioned.
Correct
On-demand is typically 7x more expensive per request than provisioned for sustained workloads. It is cost-effective only for unpredictable or very low-traffic tables.
Mistake
Strongly consistent reads are always necessary.
Correct
Many applications can tolerate eventual consistency, which costs half the RCUs. Only use strongly consistent reads when your application requires read-after-write consistency.
Mistake
DynamoDB auto scaling eliminates all throttling.
Correct
Auto scaling reacts to increased traffic with a delay (up to 5 minutes). Sudden spikes can still cause throttling. Use on-demand for unpredictable spikes or add a buffer in provisioned capacity.
Mistake
Lambda provisioned concurrency is always beneficial.
Correct
Provisioned concurrency incurs charges even when not used. It is only cost-effective for functions with predictable traffic and high cold-start penalties (e.g., latency-sensitive APIs).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Start by right-sizing memory using AWS Lambda Power Tuning. Often, increasing memory reduces duration enough to lower overall cost. Also, optimize code to reduce runtime, use asynchronous processing, and batch requests. Consider switching to Arm64 (Graviton2) for up to 34% better price-performance. Finally, evaluate if the function can be replaced with a cheaper service like SQS or Step Functions.
Use on-demand when traffic is unpredictable, spiky, or when you cannot estimate capacity needs. Use provisioned capacity with auto scaling for steady, predictable workloads. On-demand is simpler but can be significantly more expensive for sustained usage. For example, a table with 10,000 reads/sec consistently would cost about $0.65/hour with provisioned (assuming 10,000 RCUs) vs. $9.00/hour with on-demand (10,000 reads/sec = 10,000 * 3600 = 36M reads/hour = $0.25 * 36 = $9.00).
Use eventually consistent reads whenever possible (half the RCU cost). Implement DAX if your read pattern has a high cache hit ratio (e.g., 80%+). Reduce item size by using short attribute names. Use global secondary indexes with fewer attributes to minimize read capacity. Consider using S3 for large blobs and store only the S3 key in DynamoDB.
Cold starts add latency but do not directly increase cost; you still pay only for execution duration. However, cold starts can cause timeouts or retries, which increase invocations and cost. Provisioned concurrency eliminates cold starts but charges for idle time. For cost-sensitive applications, optimize cold start time by reducing deployment package size and using languages like Python or Node.js.
For writes: WCUs = (item size in KB rounded up) * writes per second. For reads: RCUs = (item size in KB / 4 KB rounded up) * reads per second for strongly consistent, or half for eventually consistent. For example, if you have 100 writes/sec of 2.5 KB items, you need 100 * 3 = 300 WCUs. For 200 reads/sec of 6 KB items strongly consistent, you need 200 * 2 = 400 RCUs.
No. Reserved capacity is only available for provisioned capacity mode. For on-demand, you pay per request with no discounts. If you have a steady workload, switching to provisioned and purchasing reserved capacity can save up to 50%.
Avoid storing large items directly. Store the blob in S3 and keep only the S3 key and metadata in DynamoDB. This reduces storage costs and capacity unit consumption. For example, a 100 KB item would consume 100 WCUs per write and 25 RCUs per strongly consistent read – very expensive. S3 costs about $0.023 per GB, far cheaper.
You've just covered Cost Optimisation for Developers: Lambda, DynamoDB — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?