Quick Answer: How much does aws lambda cost for a small project or business?
For most small projects, AWS Lambda costs $0 per month. The service’s free tier covers 1 million requests and 400,000 GB-seconds of compute every month, which is far more than a typical small app uses. You pay only when your usage goes past those limits, and then it’s fractions of a cent per request.
The catch is that Lambda rarely sits alone. API Gateway, CloudWatch Logs, data transfer, and databases like DynamoDB often drive the real bill. So the honest answer is: Lambda itself is usually free at small scale, but the surrounding services are where budgets quietly grow.
Before signing off on a budget, compare request volume, memory settings, execution time, architecture choice, log retention, and the cost of every connected service.
Ninety percent of small teams that try AWS Lambda pay nothing at all. The other ten percent get a surprise bill, and it almost never comes from Lambda itself. That gap between “free” and “why is this $40?” is the whole story of serverless budgeting, and it’s worth understanding before a single function goes live.
The pitch behind Lambda is simple: run code without managing servers, pay only for what executes. That pitch is accurate. But “pay for what you use” becomes slippery when a dozen connected services each charge their own tiny meter. This guide walks through the real numbers, the traps, and the practical way to estimate a bill before it arrives.
The free tier does most of the work for small projects
AWS Lambda’s free tier is genuinely generous, and it does not expire for most account types. Every month, an account gets 1 million free requests and 400,000 GB-seconds of compute time. A GB-second is one gigabyte of memory running for one second.
Put that in plain terms. A function with 128 MB of memory (one-eighth of a GB) running for 100 milliseconds uses 0.0125 GB-seconds per call. Run it a million times and you’ve consumed about 12,500 GB-seconds, roughly 3% of the monthly allowance. A small API, a webhook handler, or a scheduled cleanup job will rarely come close to the ceiling.
The math gets interesting at scale. A function with 1 GB of memory running for a full second, invoked a million times, burns 1 million GB-seconds. That’s 2.5 times the free compute allowance, and that’s when the meter starts spinning. Memory size and execution duration multiply together, so a bloated function is the most common reason small teams see their first charge.
What Lambda actually costs beyond the free tier
Once usage crosses the free limits, pricing splits into two meters: requests and compute. Request pricing has historically sat around $0.20 per million requests. Compute pricing is charged per GB-second, and the rate depends on whether the function runs on x86 or Arm (Graviton) processors, with Arm typically cheaper. (AWS Lambda Pricing)
| Cost component | Typical rate (verify current pricing) | What drives it |
|---|---|---|
| Requests | ~$0.20 per 1M requests | Total invocation count |
| Compute (x86) | Per GB-second, tiered | Memory × duration × invocations |
| Compute (Arm) | Lower than x86 | Same formula, cheaper rate |
| Provisioned concurrency | Extra hourly charge | Pre-warmed instances kept ready |
| Ephemeral storage | Charged above the default | Temporary disk used per function |
Exact rates shift over time and vary by region, so treat the table as a shape, not a quote. AWS publishes the authoritative numbers on its Lambda pricing page, and that page should be the last thing anyone checks before committing to a budget.
Here’s the practical translation. A small business running 5 million requests a month with a lean 256 MB function averaging 150 ms would land somewhere in the low single-digit dollars for Lambda compute and requests combined. That’s less than most companies spend on coffee for a team meeting. The service is cheap at small scale in a way that surprises people who associate “cloud” with “expensive.”
The hidden costs that actually blow up small budgets
Ask anyone who has been surprised by a serverless bill and the story rarely involves Lambda. It involves the services holding Lambda’s hand.
API Gateway is the classic offender. Every API call routed through it carries its own per-request charge, and at high volume that line item can dwarf Lambda’s. A REST API with millions of monthly calls can cost more in gateway fees than in compute.
CloudWatch Logs is the silent one. Lambda writes logs by default, and log storage plus ingestion is billed separately. A chatty function logging every request at full verbosity can accumulate real money over months, especially with default retention set to “never expire.” Setting a 7- or 14-day retention policy is one of the simplest cost fixes available.
Data transfer adds another layer. Moving data out of AWS to the internet is billed per gigabyte, and a media-heavy app feels it fast. DynamoDB, S3, and other backing services each have their own pricing models, and on-demand database capacity in particular can spike under unexpected traffic.
The pattern is consistent: Lambda is the cheap part. The architecture around it is where discipline pays off. Teams that budget carefully tend to treat the function as one line item among many rather than the whole story.
Estimating a real bill before you build
The most reliable way to forecast cost is AWS’s own Pricing Calculator, which lets you model Lambda alongside every connected service. Guessing from blog posts (including this one) is fine for a sanity check, but the calculator produces numbers you can defend to a finance team.
A practical estimation process looks like this:
- Estimate monthly invocations from expected traffic, then add a healthy buffer for retries and background jobs.
- Multiply by average execution duration, measured rather than assumed.
- Multiply by memory allocation in GB to get GB-seconds.
- Compare the total against the free tier allowance.
- Price every connected service separately: gateway, database, storage, logging, and egress.
- Re-run the numbers at 3x and 10x traffic to see where the curve bends.
That last step matters more than the first five. Small projects rarely fail on current costs; they fail on costs that scale faster than revenue. A function that costs pennies today can cost real money at ten times the volume, and knowing the inflection point in advance changes design decisions.
For teams comparing infrastructure spend against other software line items, it helps to benchmark against familiar tools. The same budgeting discipline used to check how much a PS5 costs or what PlayStation Plus runs applies here: the sticker price is rarely the full picture, and the subscription tail matters as much as the upfront number.
Where Lambda beats the alternatives for small businesses
The comparison that matters most isn’t Lambda versus another serverless platform. It’s Lambda versus running a server.
A small always-on virtual machine might cost $10 to $20 a month and sit idle most of the time. Lambda costs nothing when idle and scales automatically when traffic spikes. For workloads with irregular traffic, like a contact form handler, an image resizer, or a nightly report generator, Lambda usually wins on cost and on operational simplicity. Nobody has to patch the operating system at 2 a.m.
The trade-off appears with steady, high-volume workloads. A function invoked constantly at high memory and long duration can eventually cost more than a reserved server, because you’re paying a premium for elasticity you no longer need. The crossover point depends on the workload, but the rule of thumb is simple: spiky traffic favors Lambda, flat traffic favors servers.
There’s also a developer-experience angle. Small teams without dedicated ops staff benefit enormously from not managing infrastructure. That saved time has a dollar value, even if it never appears on an invoice.
Practical mistakes that inflate Lambda bills
Experience across many small deployments surfaces the same handful of errors again and again.
Over-allocating memory. More memory also means more CPU, so the instinct is to max it out. But cost scales linearly with memory, and many functions run perfectly well at 256 MB. Testing at several memory settings and picking the sweet spot between speed and cost is worth an afternoon.
Ignoring the Arm option. Graviton-based functions typically cost less per GB-second than x86 for compatible workloads. Switching is often a one-line configuration change.
Leaving logs on forever. Default retention is unlimited. Set an explicit retention period.
Recursive invocations. A function that triggers itself through a queue or event source can loop and generate thousands of invocations in minutes. This is the single most common cause of shock bills, and it’s entirely preventable with concurrency limits and dead-letter queues.
Skipping budget alerts. AWS Budgets can notify a team before a bill spirals. It takes five minutes to configure and has saved countless small businesses from unpleasant surprises.
Forgetting about the surrounding stack. The function is one line on the invoice. The database, the gateway, and the storage are the rest of it.
When the bill starts to matter
There’s a threshold where Lambda stops being free and starts being a line item worth optimizing. For most small projects, that threshold sits somewhere north of several million monthly invocations combined with heavier memory and longer runtimes.
At that point, the levers are well known: trim memory to the smallest viable setting, shorten execution time by optimizing cold starts and dependencies, move to Arm where possible, cache aggressively to reduce invocation counts, and audit connected services for waste. None of these are exotic. They’re just disciplined.
Small businesses comparing infrastructure against other recurring software costs already do this kind of analysis. The same reasoning applied to what accounting software costs or how much Minecraft runs applies to cloud bills: the headline price is a starting point, and the real number emerges once usage patterns are understood.
It also helps to keep perspective. A small business spending $5 a month on Lambda while paying far more for a single SaaS subscription has a cost problem, but it isn’t Lambda. The service is doing exactly what it promised.
Conclusion
For the overwhelming majority of small projects and businesses, AWS Lambda costs nothing. The free tier’s 1 million requests and 400,000 GB-seconds per month cover typical small-scale workloads with room to spare, and beyond that the per-unit rates are measured in fractions of a cent.
The real budgeting work happens around Lambda, not inside it. API Gateway, CloudWatch Logs, data transfer, and databases carry their own meters, and those are the lines that surprise people. Teams that set log retention, cap concurrency, choose Arm where possible, and run the official pricing calculator before launch rarely get blindsided.
The honest summary: Lambda is one of the cheapest ways to run code in the cloud, provided the architecture around it is built with the same care as the code itself. Estimate first, monitor always, and let the free tier do its job.
Frequently asked questions
Is AWS Lambda really free for small projects?
In most cases, yes. The monthly free tier covers 1 million requests and 400,000 GB-seconds of compute, which exceeds what a typical small API, webhook handler, or scheduled job consumes. The catch is that connected services like API Gateway, CloudWatch Logs, and databases are billed separately and can generate charges even when Lambda itself stays free.
What is a GB-second and why does it matter?
A GB-second is one gigabyte of memory running for one second. Lambda charges compute by multiplying memory allocation by execution duration, so a function using 512 MB for half a second consumes 0.25 GB-seconds per call. Understanding this unit is the key to controlling cost, because memory and duration multiply together rather than adding up.
Does Lambda get more expensive as traffic grows?
Yes, but gradually and predictably at first. Costs scale linearly with invocations and compute time, so doubling traffic roughly doubles the Lambda line item once the free tier is exhausted. The bigger risk is that connected services scale too, sometimes faster, which is why modeling costs at 3x and 10x expected traffic before launch is worth the effort.
How can a small business reduce its Lambda bill?
The highest-impact moves are trimming memory to the smallest viable setting, shortening execution time, switching to Arm-based processors where compatible, setting a defined CloudWatch Logs retention period, and adding concurrency limits to prevent runaway recursive invocations. Budget alerts catch problems early, and the official pricing calculator confirms estimates before launch.
Is Lambda cheaper than running a small server?
It depends on traffic shape. For spiky or intermittent workloads, Lambda is almost always cheaper because idle time costs nothing. For steady, high-volume workloads running constantly, a reserved server can eventually cost less. The crossover point varies by workload, but irregular traffic strongly favors the serverless model.
Do I need to pay for API Gateway if I use Lambda?
Only if the function is triggered through an API. Lambda can be invoked directly, by schedule, by file uploads, or by database events, and those paths skip gateway charges entirely. When an HTTP API is required, the gateway becomes a separate line item that often exceeds the Lambda cost itself at high request volumes.
