# AWS Serverless Cost Optimization: Best Practices That Actually Move the Needle > Actionable AWS serverless cost optimization best practices for Lambda, API Gateway, and DynamoDB — reduce your bill without sacrificing reliability or performance. - **Published:** 2025-07-05 - **Author:** Clixo - **Reading time:** 6 min read - **Tags:** aws, serverless, cost-optimization, lambda, cloud-infrastructure - **Canonical URL:** https://clixo.sh/blog/aws-serverless-cost-optimization-best-practices Serverless infrastructure is easy to start with and surprisingly easy to overpay for. The billing model — pay per request, per millisecond, per GB transferred — means that sloppy defaults compound quietly until a bill arrives that does not match the traffic you remember seeing. Most teams are overpaying by 30-60% without knowing it. These are the best practices that actually reduce AWS serverless costs at the function, API, and data layer. ```mermaid flowchart LR A["Serverless Cost Optimization"] --> B["Lambda"] A --> C["API Gateway"] A --> D["DynamoDB"] A --> E["Cross-Cutting"] B --> B1["Right-size memory"] B --> B2["Graviton ARM"] B --> B3["Hoist init outside handler"] C --> C1["REST to HTTP API"] C --> C2["Enable caching"] D --> D1["On-Demand to Provisioned"] D --> D2["Avoid table scans"] E --> E1["Tag all resources"] E --> E2["Budget alerts"] ``` ## Lambda Cost Optimization Best Practices ### Right-Size Memory Allocation Lambda's pricing model ties CPU to memory: more memory means more CPU allocation, which often means shorter execution time. The cost formula is `duration × memory`, which means the cheapest configuration is not always the lowest memory setting. Use AWS Lambda Power Tuning (an open-source Step Functions state machine) to run your function at multiple memory configurations and identify the minimum-cost point. Many functions are cheapest at 512MB or 1GB, not at the 128MB default. ### Reduce Package Size to Shrink Init Time Initialization time is billed. A function that takes 800ms to cold-start before handling its first invocation is paying for that 800ms. Lean packages — under 5MB — cold-start meaningfully faster than 80MB packages. Use a bundler. Tree-shake aggressively. Audit and remove unused dependencies every quarter. ### Hoist Expensive Initialization Outside the Handler Database connections, SDK clients, and configuration fetches that happen inside the handler run on every invocation. Moving them to module scope means they run once per container lifecycle and are reused across warm invocations. At high invocation rates, this compounds significantly. A database connection that takes 40ms to establish, called 10 million times per month, adds 400,000 seconds of billed duration — roughly $6.50 at standard Lambda pricing. Entirely avoidable. ### Use Graviton (ARM) Architecture Lambda functions on Graviton2 cost approximately 20% less per GB-second than x86 equivalents. For most Node.js and Python functions, the migration is a single architecture flag change with no code modification. Test first — run a load test on both architectures — but Graviton is almost always worth adopting. ### Apply Compute Savings Plans AWS Compute Savings Plans apply to Lambda usage and deliver up to 17% discount on a one-year commitment, or more on three-year. Unlike Reserved Instances, Savings Plans are flexible across function configurations, regions, and runtimes. If your Lambda spend is predictable, Savings Plans are low-risk cost reduction. ## API Gateway Cost Optimization ### Migrate REST APIs to HTTP APIs REST API Gateway costs roughly $3.50 per million requests. HTTP API Gateway costs $1.00 per million requests — a 70% reduction. HTTP APIs support most common use cases: Lambda integrations, JWT authorization, CORS, custom domains, and stage variables. The main capability gaps are usage plans, API keys (for rate limiting by key), and some advanced request/response transformations. If you do not need those features, migrating existing REST APIs to HTTP APIs is one of the highest-ROI changes you can make to an AWS serverless bill. ### Enable Caching for Stable Endpoints API Gateway caching stores responses at the CloudFront layer for a configurable TTL. For endpoints whose output does not change on every request — product listings, configuration data, reference lookups — caching eliminates Lambda invocations entirely. A cache hit costs nothing in Lambda compute. The cache itself costs roughly $0.02/hour for a 0.5GB cache in us-east-1. Do the math for your traffic volume; caching pays for itself quickly on endpoints with any meaningful request rate. ### Set Throttling Limits Unlimited Lambda invocations driven by a misbehaving client or a traffic spike can produce a bill with no corresponding revenue. API Gateway throttling (burst and rate limits at the stage or method level) caps exposure. This is not just a cost control measure — it is also a reliability practice. ## DynamoDB Cost Optimization Best Practices ### Switch Predictable Workloads to Provisioned Capacity DynamoDB On-Demand capacity is convenient and scales to zero, but it costs roughly 6-7x more per read/write unit than provisioned capacity. For tables with predictable or forecastable traffic — user accounts, order records, product catalog — provisioned capacity with auto-scaling is significantly cheaper. Use On-Demand for: new tables with unknown traffic patterns, batch jobs that run irregularly, and development/staging environments. Use Provisioned with auto-scaling for: any table that has consistent baseline traffic. ### Enable DynamoDB Standard-IA for Cold Data DynamoDB Standard-Infrequent Access storage class reduces storage costs by roughly 60% for tables that are not accessed frequently. If you have tables that hold historical records, audit logs, or archived data that you need to retain but rarely query, Standard-IA cuts the storage bill substantially with no query behavior changes. ### Avoid Scans Table scans consume read capacity units proportional to the table size, not the result set size. A scan on a 10GB table to find 50 records consumes the same RCUs as reading the entire 10GB. Scans on large tables can spike costs significantly. Design access patterns first, then design your table. Global Secondary Indexes add write cost but eliminate scan cost — usually a favorable trade. ## Cross-Cutting Practices ### Tag Everything Cost allocation tags let you slice your AWS bill by team, product, environment, and feature. Without tags, you are optimizing in the dark. Apply tags at the resource level for Lambda functions, API Gateways, and DynamoDB tables, then use Cost Explorer tag-based grouping to see where money is actually going. ### Set Budget Alerts at Multiple Thresholds AWS Budgets can notify you when actual or forecasted spend crosses a threshold. Set alerts at 50%, 80%, and 100% of your monthly target for each service. This catches runaway costs before the bill closes, when you still have options. ### Review Costs Monthly, Not Quarterly Cloud costs drift. A change deployed on day 3 of the month shows up in the bill 28 days later if you only check at month end. Weekly Cost Explorer reviews take 10 minutes and catch problems early. Monthly deep dives are where you make structural changes. Serverless billing rewards attention. The teams with the lowest AWS bills are not the ones with the least infrastructure — they are the ones who treat cost as a first-class engineering concern. If you want a cloud infrastructure setup designed for cost efficiency from the start, [talk to Clixo](https://clixo.sh/#contact). We build AWS systems that are production-ready and appropriately priced. --- Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh) [Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)