💿 Serverless Ephemeral Storage Calculator
Lambda ephemeral storage pricing: 512 MB free per invocation. Sounds generous. Across 50 functions in 3 environments, each allocating 2 GB /tmp for log pre-processing — that adds up silently. Model GB-seconds, invocations, duration, and the bill before AWS sends it.
📐 Ephemeral Storage Profile
Set your function's /tmp allocation, avg duration, and monthly invocation volume. 512 MB is free. Every GB beyond that costs $0.0000000309/GB-second — small unit, large multiplier.
Lambda Ephemeral Storage: /tmp Beyond 512 MB Costs Extra
AWS Lambda provides each execution environment with ephemeral storage mounted at /tmp. This writable directory persists for the lifetime of the execution environment (a "warm" container reused across invocations) and is the only local storage surface available to Lambda functions. The first 512 MB is free across all architectures (x86_64 and arm64/Graviton). Any allocation beyond 512 MB is billed at $0.0000000309 per GB-second — an extremely small per-unit cost that can compound dramatically at scale with large storage allocations or high invocation volumes.
How This Calculator Works
| Component | Formula | Rate |
|---|---|---|
| GB-Seconds | Invocations × Duration(s) × Storage(GB) | Total ephemeral storage consumption across all invocations |
| Storage Cost | GB-Seconds × $0.0000000309 | $0.0000000309 per GB-second (beyond 512 MB free tier) |
| Cost Per Million | Total Storage Cost ÷ Monthly Invocations (Millions) | Normalized per-million invocation storage cost |
When Ephemeral Storage Costs Become Material
At 10 GB of /tmp with 1-second average duration and 5 million monthly invocations, total GB-seconds = 5,000,000 × 1 × 10 = 50,000,000 GB-seconds. Cost = 50,000,000 × $0.0000000309 = $1.55/month — negligible. But at 10 GB /tmp with 60-second duration (common for video processing or ML inference) and 50 million invocations, costs climb to ~$927/month. The calculator helps identify the inflection point where optimizing /tmp usage — by streaming data to S3 instead of buffering locally, or by reducing allocated storage to the minimum needed — yields meaningful savings.
Monitoring /tmp Usage in Production
Lambda does not emit a native CloudWatch metric for /tmp utilization. You must instrument your function code to track os.statvfs('/tmp') and emit a custom metric or structured log. Functions that silently fill /tmp beyond the allocated limit will receive ENOSPC (No space left on device) errors — which manifest as cryptic 500 responses. The df -h /tmp command run inside a Lambda execution environment is the quickest diagnostic, but it requires an active execution context. For production observability, emit a gauge metric at the end of each invocation and alert when utilization exceeds 80% of the configured limit.