Run a real API for $0 a month on Lambda's always-free tier

The AWS Lambda free tier limits are 1 million requests and 400,000 GB-seconds of compute a month, and they don't expire after 12 months the way some offers do. That's enough to run a real backend for $0, if you know which limit you'll hit first and what happens when traffic goes wrong. We built a small bookmarks API to find out, and turned the answers into a tested repo.

This article is for developers who want a free backend on AWS for a side project or a personal tool. You get the free-tier math, a front door that costs nothing, and a hard ceiling on the worst month. There are also alarms that cost nothing, plus an AWS Cloud Development Kit (CDK) stack.

Key takeaways

• For a fast API, the 1 million free requests run out long before the 400,000 GB-seconds. Extra memory costs nothing until requests get slow.
• A Lambda function URL costs nothing extra. With auth type NONE, your free requests belong to anyone who finds the URL.
• Reserved concurrency plus the function URL's request limit puts a hard cap on the bill. With 2 reserved copies at 256 MB, the worst possible month is $23.04.
• A CloudWatch alarm that uses metric math doesn't count toward the 10 free alarm metrics. Give each alarm one plain metric.

Lambda free tier limits: the math that matters

Lambda bills two things. Each request costs $0.20 per million after the first million. Lambda bills compute in GB-seconds: how long each request runs, rounded up to the next millisecond, times the memory you gave the function. The free tier covers 1 million requests and 400,000 GB-seconds every month, on the Free and Paid plans alike.

Arm and x86 functions draw from one shared allowance, not one each. AWS's Graviton launch post says Arm functions are "included in the AWS Free Tier up to the existing limits". A 2024 post on the AWS Architecture Blog says the 400,000 GB-seconds are "usable for functions across both x86 and AWS Graviton processors". Past the free tier, Arm compute costs $0.0000133334 per GB-second against $0.0000166667 for x86, so we use Arm.

Compute and requests run out at the same time only when requests are slow. You can work out that point for each memory size:

An API that answers in 20 ms is nowhere near any of these. Your limit is the request count, and extra memory costs you nothing inside the free tier, so we gave the function 256 MB for headroom.

Two more billing details matter. Rounding happens per request, so average the billed durations instead of rounding an average. And since August 1, 2025, Lambda bills the initialization phase of a cold start too.

What we measured on a laptop

The repo has a measure script that runs the bundled handler the way one Lambda environment does: load it once, then serve one request at a time. We ran 1,000 rounds of create, get, list and update, plus a delete in every second round, against DynamoDB Local on an Apple silicon laptop with Node.js 24.

The mean billed duration came out between 1.3 and 4.5 ms across four runs. The laptop was busy with other work, which explains the spread. Real Lambda adds a network trip to DynamoDB, so expect more, but still far below 1,600 ms. A successful request wrote 0 bytes of logs, and an average response was about 1.4 KB.

The free-tier-model script turns those numbers into a monthly picture:

Lambda, per month
  free by request count 1,000,000
  free by compute       352,422,907  (400,000 GB-s / GB-s per request)
  => 1,000,000 requests a month cost $0. The 1M request allowance runs out first.

Notice the gap. Compute alone would cover over 350 million requests a month, 350 times the request allowance. After you deploy, pass your real billed duration to the script with --duration-ms.

Choose a front door that costs nothing

Amazon API Gateway's free tier lasts 12 months and is for new customers only. Free plan accounts get none of it, since the Free plan comes with only the always-free offers. Without the free tier, an HTTP API costs $1.00 per million requests. A Lambda function URL is an HTTPS endpoint on the function itself, and the Lambda docs say there are "no additional charges for the URL endpoint itself".

The whole design fits in one picture:

The client signs each request. The function URL checks the signature, and the function reads and writes one DynamoDB table. CloudWatch watches the function's metrics and emails you through SNS when usage gets close to the free limits.

A function URL has two auth types. With NONE, Lambda runs your function for anyone on the internet, and each of those calls spends your free requests. With AWS_IAM, Lambda checks a Signature Version 4 (SigV4) signature before your code runs, and unsigned requests get 403.

We use AWS_IAM, and the handler uses the caller's identity to keep each caller's data apart:

// Stack: Lambda checks the signature before the function runs.
fn.addFunctionUrl({ authType: lambda.FunctionUrlAuthType.AWS_IAM, invokeMode: lambda.InvokeMode.BUFFERED });

// Handler: Lambda passes the signed caller's IAM ARN.
const owner = event.requestContext?.authorizer?.iam?.userArn;
if (!owner) return problem(403, 'this API needs AWS_IAM auth on the function URL');

The owner check matters if someone flips the URL to NONE later. Lambda then sends no identity at all, so the handler refuses the request rather than guess whose bookmarks to show. One more detail: since October 2025, new function URLs need both lambda:InvokeFunctionUrl and lambda:InvokeFunction permissions. CDK's grantInvokeUrl adds both, and a template test checks it.

Put a hard ceiling on the bill

The free tier is a monthly allowance, not a limit. Nothing stops a buggy client from sending 50 million requests. Reserved concurrency is the setting that bounds how much the function can run. It sets the most copies of the function that may run at once, and it costs nothing to configure.

Function URLs add a second limit. The docs say the maximum request rate "is equivalent to 10 times the configured reserved concurrency". Callers above either limit get HTTP 429. The Lambda metrics docs say throttled requests aren't recorded as invocations, and that invocations equal billed requests.

Those two limits give you a worst case you can compute. Below 100 ms per request, the rate limit caps the request count. Above 100 ms, concurrency caps compute. So the worst month is the one where every request takes 100 ms:

The repo uses 2 reserved copies, so a client can send at most 20 requests a second. With 1 copy at 128 MB, compute can't leave the free tier at all, and only requests can cost money. The repo's smoke test fires 60 parallel calls after a deploy and expects some of them to get 429.

One trap catches new accounts. Lambda keeps 100 units of account concurrency unreserved, and new accounts start with a lower concurrency quota. If your quota is too small to reserve 2 more units, the deploy fails. Check the quota in Service Quotas before you deploy, and ask for an increase rather than removing the cap.

Alarm before the free tier runs out

A monthly total is hard to alarm on, because a CloudWatch alarm can look back at most 7 days. Instead, we alarm on pace. If one day uses more than 1/31 of the monthly allowance, a 31-day month at that rate would run out. The alarm fires at 80% of that daily share: 25,806 invocations, or 10,322 GB-seconds.

The stack sets up the request alarm like this. This is a simplified excerpt; the real code builds the threshold and description from the stack's props:

new cloudwatch.Alarm(this, 'RequestsPace', {
  metric: fn.metricInvocations({ statistic: 'Sum', period: cdk.Duration.days(1) }),
  threshold: Math.floor((1_000_000 * 0.8) / 31), // 25,806
  comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_THRESHOLD,
  evaluationPeriods: 1,
  treatMissingData: cloudwatch.TreatMissingData.NOT_BREACHING,
});

A third alarm fires when Lambda throttles anything, so you know callers are getting 429. All three notify an Amazon Simple Notification Service (SNS) topic, which gives 1,000 email notifications free each month. If other functions share your account, set monthlyRequestBudget to this API's share, since they all draw from the same 1 million.

What we got wrong first: a paid alarm

Our first compute alarm used CloudWatch metric math. It took the daily Duration sum and multiplied it into GB-seconds, which made a tidy graph in the console. Our tests didn't check how the alarm was built, so nothing flagged it.

Then the fact check of the CloudWatch pricing page turned up the condition on the free alarms. The 10 free alarm metrics are "only applicable to Standard resolution alarms that list metrics directly". A metric math alarm lists an expression instead, so our free-tier alarm would have cost $0.10 a month. The fix moves the math into the threshold. The alarm watches the raw Duration sum, and the threshold becomes 41,288,000 ms a day at 256 MB.

A test now checks that every alarm names one metric and no math expression. We broke it on purpose by putting the metric math back, and the test failed. The same habit caught a bug in our model too: its first version rounded an average of billed durations up a second time, which overstated compute by 57%.

Keep storage at $0 too

DynamoDB's always-free tier gives 25 read and 25 write capacity units and 25 GB of storage per Region. It applies to provisioned tables, not on-demand ones. We provision 5 of each with no auto scaling, which leaves room for other tables in the account. Article 3 in this series goes deeper on DynamoDB design.

Every write is conditional. A create uses attribute_not_exists, so it can't overwrite. An update needs the version from the If-Match header, so two clients editing the same version can't both win, and a deleted bookmark can't come back. The integration tests run these conditions on DynamoDB Local, including 20 updates racing for one version.

What breaks the $0

Some settings add a charge without warning you. The ones that matter for this design:

Because of the logging line, the stack sets the system log level to WARN. That drops the START and REPORT lines of successful requests, so a good request writes nothing. To see your real billed duration and memory, deploy for a day with -c reportLines=true and query those lines with CloudWatch Logs Insights.

What it costs

These are us-east-1 prices from the AWS Price List API. They assume this API has the free tier to itself:

Responses leave AWS over the internet, and AWS gives 100 GB of data transfer out free each month across services. At about 1.4 KB per response, a million requests send 1.4 GB, so even if all of it counts you stay far inside that.

When this isn't the right fit

• A public API for browsers: AWS_IAM needs signed requests. Put real auth in front, such as Amazon Cognito, which a later article in this series covers.
• Traffic above the cap: if you need more than 20 requests a second, raise reserved concurrency and recompute the ceiling.
• Custom domains, AWS WAF (web application firewall) or request validation: we didn't need them here. API Gateway or Amazon CloudFront in front of the function adds them, at a price.
• Slow requests: a handler that takes seconds runs out of free compute first. Use the table above.

Try it yourself

The repo works without an AWS account first. npm run check type-checks, lints, runs the unit and CDK tests, and synthesizes with cdk-nag. Start DynamoDB Local in Docker, then run npm run test:int, npm run measure and npm run free-tier-model.

To deploy, you need a CDK-bootstrapped account. Run npm run deploy -- -c alertEmail=you@example.com, confirm the email, then run npm run smoke with the same credentials.

Clean up

Run npm run destroy. The stack keeps the bookmarks table on purpose, so delete it in the DynamoDB console when you're sure.

Has your own free-tier backend hit the request limit or the compute limit first? I'd like to hear where your real billed duration landed.