Lambda costs are based on GB per millisecond. Two dimensions: memory and time. Most optimization advice focuses on memory. But the real wins? Batching and architecture changes.

1. Understand Your Costs First

Set up cost allocation tags. Use Cost Explorer. Drill down by stack and function name. Without visibility, you're optimizing blind.

In SST, you can tag all functions with one transform:

$transform(sst.aws.Function, (args, _opts, name) => {
    args.tags ??= { 'function:name': `${$app.name}-${$app.stage}-${name}` };
  });

2. Right-Size Memory

Every Lambda logs a REPORT with max memory used vs allocated. Query it with CloudWatch Logs Insights. If max memory is way below allocated? You're overpaying.

Important: Memory also determines CPU. Cut memory too much and your function runs slower. Use Lambda Power Tuning to find the sweet spot.

3. Reduce Timeouts

Default timeout of 15 minutes? That's a cost time bomb. Query actual durations with Logs Insights. Set timeouts based on real p99 values, not worst-case fears.

4. Switch to ARM

ARM (Graviton2) is ~20% cheaper than x86. For new projects, ARM should be your default. Watch out for dependencies that don't support ARM, and bundling issues if your CI/CD runs on x86.

5. Use Your Lambda Less (The Big Win)

This is where the 98% savings came from.

Before: EventBridge → Lambda (one per event). 700 concurrent Lambdas. Downstream system crashing. $280/month.

After: EventBridge → SQS → Lambda with batch size 40 + concurrency limit. $3/month.

Same for caching: store rules in the execution environment, use CloudFront for edge caching, cache at the database layer. Fewer invocations = lower costs.

🚀 Read the Full Tutorial →