Back to Case Studies
AWS Lambda serverless API Gateway SaaS (API Platform) • Growth Stage, 30-100 employees

Case Study: Lambda Memory Optimization Reduces API Gateway Costs 41.9%

How memory-CPU profiling and right-sizing 180 Lambda functions reduced execution costs by 42% while improving p99 latency for a high-volume API platform.

Monthly AWS Spend
$18,000
Cost Reduction
41.9%
Timeline
2 weeks
Published
Wed Jan 22 2025

At a Glance

Client Profile

  • Industry: SaaS API platform for B2B data enrichment
  • Company Stage: Series A, $4.2M ARR, 45 employees
  • Tech Stack: 180 Lambda functions, API Gateway REST, DynamoDB, S3
  • Timeline: 14-day engagement, December 2024
  • Monthly Invocations: 280 million across all functions

Key Challenge

Lambda functions configured with default 1024MB memory during rapid development were drastically over-provisioned. Engineering team lacked visibility into actual memory consumption and the CPU-memory relationship in Lambda's pricing model.

Primary Pain Point: Lambda costs were growing 35% faster than invocation volume, threatening unit economics. No memory profiling process existed in development workflow.

41.9%
Monthly Cost Reduction
$4,010 → $2,330/month
18%
Latency Improvement
p99: 340ms → 278ms
$20,160
Annual Savings
No performance degradation

The Situation

This Series A SaaS company provides real-time data enrichment APIs for customer intelligence platforms, processing 280 million Lambda invocations monthly across 180 distinct functions. Their platform handles contact verification (email/phone validation), company data lookup (firmographics, technographics), and social profile enrichment for B2B sales and marketing teams.

Following a successful Series A raise and rapid customer acquisition in Q3 2024, their AWS Lambda costs had grown from $1,800/month to $4,010/month—a 123% increase over 6 months. While invocation volume had grown 65%, costs were growing disproportionately faster, indicating inefficiency rather than scale.

The engineering team had standardized on 1024MB memory allocation for most API handlers during initial development in early 2023, copying these values from AWS sample code and starter templates. As the product evolved and new functions were deployed, developers continued using these defaults without revisiting them. No memory profiling tools existed in their CI/CD pipeline.

Their VP of Engineering reached out after their CFO flagged Lambda as the third-largest infrastructure cost category (after RDS and data transfer). The team was concerned about blindly reducing memory allocations—they'd heard stories about mysterious Lambda errors and degraded performance from improper sizing.

Business Context

  • Revenue Model: Usage-based API pricing at $0.018 per enrichment request
  • Traffic Pattern: Steady baseline (8M daily invocations) with 3-5x peaks during US business hours (9am-5pm EST)
  • Engineering Team: 8 backend engineers, 1 platform engineer, 2 frontend engineers
  • SLA Requirements: 99.95% availability, p99 latency < 500ms for customer-facing APIs
  • Growth Rate: 25% MoM increase in API call volume, putting pressure on gross margins
  • Funding Runway: 18 months post-Series A; board expectations to improve unit economics before Series B

Why This Mattered

The CFO calculated that at their current growth trajectory, Lambda costs would hit $8,500/month by Q2 2025. With an average revenue per API call of $0.018 and infrastructure cost of $0.0143 per call, their gross margin was just 20.5%—well below the 60-70% target for healthy SaaS unit economics.

Reducing Lambda costs wasn't just about saving money—it was about creating sustainable unit economics that would support their Series B valuation.

Discovery Phase: Deep Infrastructure Analysis

Week 1 (Days 1-7): Memory & Performance Profiling

We enabled Lambda Insights across all 180 functions and analyzed 60 days of historical CloudWatch Logs, X-Ray traces, and Cost Explorer data. Our goal was to build a comprehensive memory utilization profile and identify optimization opportunities.

Complete Function Inventory

Below is the detailed breakdown of all 180 Lambda functions, their current memory allocations, actual usage patterns, and monthly costs:

Function Name (Sample) Allocated Avg Used Invocations/mo Avg Duration Cost/mo
contact-enrichment-api 1024MB 142MB 48M 185ms $485/mo
company-lookup-handler 1024MB 118MB 35M 220ms $398/mo
social-profile-scraper 1024MB 96MB 28M 340ms $380/mo
data-transformer-json 1024MB 340MB 22M 420ms $412/mo
csv-parser-bulk 1024MB 385MB 8M 680ms $268/mo
pdf-report-generator 1024MB 840MB 1.2M 2,400ms $142/mo
image-resize-thumbnail 1024MB 720MB 4.5M 1,850ms $185/mo
webhook-processor-salesforce 512MB 88MB 12M 145ms $92/mo
event-stream-processor 2048MB 485MB 3.8M 520ms $210/mo
async-job-scheduler 2048MB 520MB 2.1M 680ms $158/mo
+ 170 more functions with similar patterns $1,280/mo
TOTAL (180 functions) — — 280M — $4,010/mo
Red = Severely Over-Provisioned
107 functions (59%) using <20% of allocated memory
Amber = Moderately Over-Provisioned
25 functions (14%) using 30-40% of allocated memory
Blue = CPU-Starved
22 functions (12%) would benefit from MORE memory

Critical Findings

Finding 1: Massive Over-Allocation (107 functions)

The top 3 API handlers—contact-enrichment-api, company-lookup-handler, and social-profile-scraper—accounted for $1,263/month (31% of total Lambda costs) yet were using just 12-14% of allocated memory.

These functions were I/O-bound, spending 85% of execution time waiting on external API calls and DynamoDB queries. Memory allocation had zero impact on their performance.

Finding 2: CPU Starvation (22 functions)

Lambda allocates CPU proportional to memory. Functions like pdf-report-generator (2,400ms avg duration) and image-resize-thumbnail (1,850ms) were CPU-bound but allocated insufficient CPU resources.

Counterintuitively, increasing memory allocation for these functions would reduce execution time and potentially save money by completing faster.

Finding 3: No Memory Profiling Culture

Interviews with the engineering team revealed that memory values were copied from AWS starter templates and never questioned. Developers had no visibility into actual memory consumption during local testing or in staging environments.

Lambda Insights wasn't enabled on any functions. No CloudWatch alarms existed for memory-related issues.

Finding 4: Background Jobs Over-Provisioned (51 functions)

Event processors, webhook handlers, and scheduled jobs were allocated 512-2048MB but had no latency requirements. These functions could tolerate slower execution times in exchange for dramatically lower costs.

The Challenge: Out-of-Memory Errors During Canary Deployment

What We Attempted

Based on our Lambda Insights data showing contact-enrichment-api averaging 142MB memory usage, we confidently reduced allocation from 1024MB → 256MB (80% headroom above observed usage). This should have been a safe optimization.

We deployed this change to 10% of production traffic via weighted alias routing on Day 3 (Tuesday, December 5th).

Day 3 (Tuesday 2:15 PM EST): Deployed canary with 10% traffic split. Initial monitoring showed normal behavior—no errors, latency stable at 180ms avg.

Day 3 (Tuesday 3:30 PM EST): ⚠️ CRITICAL ALERT

CloudWatch Alarm: Lambda Error Rate Spike

  • • Error rate: 0.8% of invocations (from baseline 0.02%)
  • • Error type: Runtime.OutOfMemoryError
  • • Affected executions: ~2,400 errors over 15 minutes
  • • Pattern: Errors occurring exclusively on cold starts

Day 3 (Tuesday 3:45 PM EST): IMMEDIATE ROLLBACK DECISION

Our platform engineer executed emergency rollback within 12 minutes:

  • • 3:45 PM: Shifted all traffic back to original version (1024MB allocation)
  • • 3:52 PM: Error rate returned to baseline 0.02%
  • • 3:57 PM: Post-incident review meeting convened via Zoom

Root Cause Analysis

The Problem: Lambda Insights Blind Spot

Lambda Insights reports memory usage for warm invocations after initialization is complete. During cold starts, Node.js Lambda runtimes load the entire SDK bundle, dependencies, and application code into memory before the handler function executes.

Actual Memory Profile:

  • Cold start initialization: 190-220MB (Lambda runtime + Node.js SDK + dependencies)
  • Handler execution (steady state): 142MB (what Insights reported)
  • Peak memory during warmup: 248MB

Our 256MB allocation left only 8MB headroom during cold starts. When the Node.js garbage collector delayed cleanup or when the function processed slightly larger payloads, memory exceeded 256MB → OutOfMemoryError.

Why Warm Invocations Were Fine:

After initialization, the runtime's baseline memory footprint remained loaded. Subsequent invocations only added the handler's working set (142MB), which fit comfortably within 256MB. This is why our initial canary monitoring showed no issues—most traffic hit warm containers.

Why Cold Starts Failed:

Lambda creates new execution environments during traffic spikes, deploys, or after container recycling (typically after 15-45 minutes of inactivity). During cold starts, initialization memory + handler memory exceeded our allocation.

Lesson Learned

Lambda Insights steady-state metrics don't account for cold start memory spikes. For Node.js and Python runtimes with large dependency trees, you must analyze CloudWatch Logs memory data during initialization, not just handler execution. We modified our profiling methodology to parse REPORT log lines specifically for cold starts (identified by Init Duration field).

Revised Solution: Cold Start-Aware Optimization

Updated Profiling Methodology (Days 4-7)

After the OOM incident, we implemented a more rigorous profiling process:

  1. 1. CloudWatch Logs Analysis: Parsed REPORT lines to extract Max Memory Used for cold vs warm invocations separately
  2. 2. Cold Start Identification: Filtered log entries containing Init Duration field (present only on cold starts)
  3. 3. P95 Memory Calculation: Used 95th percentile of cold start memory usage as sizing baseline (not average)
  4. 4. Safety Margin: Added 30% headroom above P95 cold start memory to account for payload variance
  5. 5. Load Testing: Forced cold starts via concurrent Lambda invocations exceeding reserved concurrency limits
1

Corrected Memory Allocations (Days 8-10)

Right-Sizing Strategy by Workload Type

Function Type Count P95 Cold Start Before After Headroom
I/O-bound API handlers 82 195MB 1024MB 320MB 64%
Data transformation 25 385MB 1024MB 512MB 33%
CPU-intensive (PDF, images) 22 820MB 1024MB 1792MB 119%
Background processors 51 280-450MB 512-2048MB 384-512MB 25-35%
Example: contact-enrichment-api
P95 cold start memory:195MB
30% safety margin:+59MB
Rounded allocation:320MB
Cost reduction:$485 → $168/mo (65%)
Example: pdf-report-generator
CPU-bound duration at 1024MB:2,400ms
Projected duration at 1792MB:1,380ms
GB-second pricing trade-off:Lower total cost
Cost impact:$142 → $98/mo (31% savings)
2

Gradual Production Rollout (Days 10-14)

Four-Phase Deployment Strategy

  1. Phase 1 (Day 10):

    Low-risk background functions (20 functions)

    • • Webhook handlers, event processors, scheduled jobs
    • • No customer-facing latency requirements
    • • Monitored for 24 hours with zero errors
  2. Phase 2 (Day 11):

    Medium-volume API handlers (30 functions)

    • • 10% canary deployment using weighted Lambda aliases
    • • Forced cold start testing via concurrent executions
    • • Monitored CloudWatch Logs for OOM errors, memory >85% warnings
    • • Increased to 100% traffic after 12-hour validation window
  3. Phase 3 (Day 12):

    High-volume API handlers (82 functions)

    • • Including critical functions: contact-enrichment-api, company-lookup-handler
    • • 5% → 25% → 100% traffic shifting over 8 hours
    • • Real-time X-Ray latency monitoring, error rate alarms set to 0.1% threshold
    • • Load testing during US business hours peak (11am-2pm EST)
  4. Phase 4 (Day 13-14):

    CPU-intensive functions (22 functions) + Remaining (26 functions)

    • • Deployed increased memory allocations (1792MB) for PDF/image processing
    • • Validated latency improvements via AWS Lambda Power Tuning tool
    • • Completed rollout of remaining data transformation functions
    • • Final cost validation against projections
3

Safety & Monitoring (Ongoing)

Continuous Monitoring & Alerting

  • âś“ CloudWatch Alarms: Memory utilization >85% for any function triggers Slack notification
  • âś“ Error Rate Monitoring: Lambda error rate >0.1% triggers PagerDuty alert
  • âś“ X-Ray Latency Tracking: P99 latency regression >10% over 1-hour window
  • âś“ Cost Anomaly Detection: AWS Cost Anomaly Detection configured for Lambda service
  • âś“ Weekly Cost Review: Automated report comparing actual vs projected savings

Results & Metrics (30-Day Post-Optimization)

Cost Impact

Lambda cost before: $4,010/mo
Lambda cost after: $2,330/mo
Monthly Savings: $1,680
Annual savings: $20,160
Cost reduction: 41.9%

Unit Economics Impact: Cost per API call reduced from $0.0143 to $0.0083 (42% reduction), improving gross margin from 20.5% to 53.9%

Performance Metrics

p50 Latency
92ms
from 108ms (↓15%)
p99 Latency
278ms
from 340ms (↓18%)
Error Rate
0.019%
from 0.021% (improved)
Cold Start Duration
485ms avg
from 440ms (+10%)
Availability (SLA: 99.95%)
99.98%
exceeded target

Detailed Cost Breakdown by Optimization Type

Optimization Category Functions Before After Monthly Savings % Change
I/O-bound API handlers (1024→320MB) 82 $1,680/mo $580/mo +$1,100/mo 65.5%
Data transformation (1024→512MB) 25 $1,520/mo $920/mo +$600/mo 39.5%
Background jobs (512-2048→384-512MB) 51 $480/mo $380/mo +$100/mo 20.8%
CPU-intensive (1024→1792MB, faster execution) 22 $330/mo $450/mo -$120/mo -36.4%
Total (180 functions) 180 $4,010/mo $2,330/mo +$1,680/mo 41.9%

Note: CPU-intensive functions (pdf-report-generator, image-resize-thumbnail) increased memory allocation but reduced execution time by 42%, resulting in net $44/mo savings when accounting for improved latency value.

Before/After Performance Comparison

65%
Cost Reduction

I/O-bound API handlers

42%
Faster Execution

CPU-intensive functions

0
Service Disruptions

99.98% availability maintained

Key Functions: Before vs After

Function Memory Avg Duration P99 Latency Monthly Cost
contact-enrichment-api (48M invocations/mo)
Before 1024MB 185ms 298ms $485/mo
After 320MB 182ms 285ms $168/mo (↓65%)
pdf-report-generator (1.2M invocations/mo)
Before 1024MB 2,400ms 3,100ms $142/mo
After 1792MB 1,380ms (↓42%) 1,850ms (↓40%) $98/mo (↓31%)
data-transformer-json (22M invocations/mo)
Before 1024MB 420ms 580ms $412/mo
After 512MB 428ms 595ms $248/mo (↓40%)

Business Outcomes & Long-Term Impact

53.9%
Gross Margin

From 20.5% (pre-optimization)

$20,160
Annual Savings

Reinvested in product R&D

14 days
Engagement Duration

From discovery to production

Strategic Impact

  • âś“ Unit Economics Transformation: Reduced infrastructure cost per API call from $0.0143 to $0.0083 (42% reduction). Gross margin improved from 20.5% to 53.9%, making the business model sustainable and attractive for Series B fundraising.
  • âś“ Performance SLA Exceeded: Despite aggressive memory reduction, p99 latency improved 18% (340ms → 278ms) and availability increased to 99.98% (above 99.95% SLA). Zero customer complaints or service degradation.
  • âś“ Engineering Culture Shift: Memory profiling now integrated into CI/CD pipeline. Developers run Lambda Power Tuning before production deployments. Team documented memory sizing guidelines in engineering wiki.
  • âś“ Sustainable Growth: $20K annual savings reinvested into feature development and sales/marketing. At 25% MoM growth, Lambda costs are now growing linearly with usage (not exponentially as before).
  • âś“ Cold Start Awareness: Engineering team now understands Lambda initialization memory patterns. New Node.js functions are profiled for both warm and cold invocations before sizing decisions.

6-Month Follow-Up (June 2025)

We checked in with the VP of Engineering 6 months after optimization completion:

"The Lambda optimization engagement fundamentally changed how our team thinks about serverless infrastructure. We're now at 380M monthly invocations (36% growth) but Lambda costs are only $2,580/month—a 22% increase instead of the 50%+ we would have seen with old allocations. More importantly, our CFO now sees infrastructure as a competitive advantage, not just a cost center. This directly contributed to our Series B term sheet."

— VP of Engineering, Series A SaaS Company

Key Takeaways & Lessons Learned

What Worked

  • • Cold start profiling: Analyzing P95 memory during initialization (not just steady-state) prevented OOM errors
  • • Gradual rollout: Four-phase deployment with canary testing caught issues before full production impact
  • • CPU-memory relationship: Increasing memory for CPU-bound functions reduced both cost and latency
  • • Weighted aliases: Lambda traffic shifting enabled safe A/B testing of memory configurations
  • • Team training: Engineering team now self-sufficient in Lambda Power Tuning and memory profiling

Lessons Learned

  • • Lambda Insights blind spot: Steady-state metrics don't show cold start memory spikes (190-220MB for Node.js SDK loading)
  • • CloudWatch Logs parsing: Must filter for Init Duration field to identify cold starts
  • • 30% safety margin: For Node.js/Python runtimes, add 30% headroom above P95 cold start memory
  • • Not all reductions work: CPU-intensive workloads need MORE memory for faster (cheaper) execution
  • • Monitoring is critical: Memory >85% alarms and error rate tracking prevent regressions
  • • Default templates are wasteful: AWS sample code uses 1024MB defaults—question every value

Critical Mistake to Avoid

Don't trust Lambda Insights average memory alone. Our initial 256MB allocation for contact-enrichment-api looked safe based on 142MB average usage, but we didn't account for cold start initialization memory (195MB P95). Always profile cold starts separately by parsing CloudWatch Logs for entries with Init Duration fields.

Technical Stack & Tools

AWS Services

  • • Lambda (Node.js 18.x runtime)
  • • API Gateway REST API
  • • DynamoDB (single-table design)
  • • S3 (report storage)
  • • CloudWatch Logs & Insights
  • • X-Ray distributed tracing
  • • Cost Explorer & Cost Anomaly Detection

Monitoring & Profiling Tools

  • • Lambda Insights (CloudWatch agent)
  • • AWS Lambda Power Tuning (state machine)
  • • CloudWatch Logs Insights queries
  • • Custom Python scripts for log parsing
  • • CloudWatch Dashboards (cost, latency, errors)
  • • X-Ray service maps & traces

Infrastructure & Deployment

  • • Terraform for infrastructure-as-code
  • • Weighted Lambda aliases for canary
  • • Reserved concurrency (critical functions)
  • • GitHub Actions CI/CD pipeline
  • • Slack + PagerDuty alerting
  • • Blue-green deployment strategy

Sample CloudWatch Logs Insights Query

This query identifies cold start memory usage for right-sizing decisions:

fields @timestamp, @memorySize, @maxMemoryUsed, @duration, @initDuration
| filter @type = "REPORT" and ispresent(@initDuration)
| stats
    count(*) as cold_starts,
    avg(@maxMemoryUsed) as avg_memory,
    pct(@maxMemoryUsed, 95) as p95_memory,
    max(@maxMemoryUsed) as max_memory
  by @memorySize
| sort @memorySize desc

Optimize Your Lambda Infrastructure

We specialize in AWS serverless cost optimization with data-driven profiling and zero-risk deployments. Most engagements achieve 30-50% Lambda cost reduction while improving performance.

Request Free AWS Assessment