Functions as a Service (FaaS) will run a growing share of production software because more and more work arrives as discrete events: payment webhooks, file uploads, scheduled jobs and the tool calls AI agents make. A function fits work that is short, bursty and stateless. Long jobs, steady heavy traffic and data-rich responses fit containers or durable workflows. The teams that spend least and ship fastest place each workload on purpose, and this guide shows how to do that with your own numbers.
Most cloud bills carry a quiet line item that nobody owns: servers waiting for work.
Picture a payments startup with forty services. Nine of them do one small thing, such as receive a webhook, build a nightly report or resize an upload. Each sits on a container that is idle for most of the day, and each was set up years ago by someone who has since moved teams. (This is an illustrative composite, not a client.) Nothing is broken. Yet those nine services collect a standing charge for waiting, and their owners spend time patching, scaling and watching them.
FaaS exists to remove that charge and that chore. It is also easy to overuse, and the published advice on when to use it is contradictory. This post gives you a way to decide, workload by workload, plus a view of where the model is heading.
Three shifts are moving functions to the center
Work now arrives as events. A payment gateway posts a webhook. A customer uploads a document for verification. A job reconciles a ledger at midnight. An agent decides to call a tool. Each has a clear start and end, and none needs to remember anything afterwards. AWS community writing on 2026 architecture describes serverless as the default fabric for event-driven systems, real-time experiences and AI apps that stream results [3]. Agents add volume, because one user request can fan out into many small tool calls, and every call is an invocation.
Idle time has a price. One 2026 cost comparison puts a two-minute daily backup job at about $0.90 a month as a function, against $72 a month on a container running around the clock [11]. Most companies own dozens of small jobs like this. Each looks trivial alone. Together they are a permanent fee for waiting.
The ceiling keeps rising. Lambda has long capped a single invocation at 15 minutes [9][10], while Google’s second-generation functions allow HTTP timeouts up to 60 minutes [10]. On September 9, 2026, AWS raised the limit to 90 minutes for asynchronous and event-source invocations on Lambda Managed Instances, and described durable functions that can carry a multi-step execution for up to a year [6]. Each increase moves another job from the container column into the function column.
One caution keeps this honest. Datadog’s 2023 report found that more than 70% of its AWS customers, 60% of its Google Cloud customers and almost half of its Azure customers used at least one serverless service, and it named container-based serverless platforms as the main growth driver [5]. The future described here is an operating model, where you run no servers and pay for use. Functions are its sharpest form for event work, and containers will keep a large share of the rest.
Do the arithmetic before you pick a platform
Published break-even points vary widely. One decision guide puts the crossover near 30 million invocations a month at 200 ms [15]. A cost guide citing Datadog places it around 1 million a day [16]. Another analysis draws the line at 50,000 a day or a 50% duty cycle [11]. A fourth finds container fleets cheaper than Lambda above 66 requests per second [14]. Each assumes different memory sizes, run times and extras, so none of them transfers to your system.
Use a measure you can compute from your own logs. Duty cycle is the busy seconds your code uses in a day divided by the 86,400 seconds in a day. Here it is for four typical workloads:
Workload | Runs per day | Average duration | Busy seconds per day | Duty cycle | Leans toward |
Nightly report | 1 | 120 s | 120 | 0.14% | Function |
Payment webhooks | 5,000 | 0.1 s | 500 | 0.58% | Function |
Image thumbnails | 50,000 | 0.4 s | 20,000 | 23.1% | Measure both |
Public API | 2,000,000 | 0.05 s | 100,000 | 115.7% | Container |
Read the last column with the thresholds from the cost comparison above: functions tend to win below roughly 10% duty cycle and containers above roughly 50% [11]. A figure above 100% means one always-on instance could not keep up alone, so you would need several running all day. The band in the middle is where you measure instead of guessing.
Define the term before you compare anyone’s numbers. One published table lists 200,000 requests a day at 50 ms as a 116% duty cycle. By the definition above, that workload is 11.6%. Small slips like this are common in cost articles, which is one more reason to run the math on your own data.
Averages also hide bursts. A workload that idles all day and spikes for ten minutes suits a function even when its average looks high, because a container must be sized for the spike and paid for all day. A flat 60% load has no spike to exploit.
Two analyses report savings of 30% to 48% and 46% from splitting event work and always-on services across the two models [11][12]. Both come from cost consultancies, so treat them as directional. The direction is still useful: the savings come from placement, and neither model wins across the board.
Where the bill hides
Compute gets the attention, and these lines cause the surprises.
Line item | Question to ask | Published example |
Outbound data | Bytes out per call, times calls per month, times the rate | 50 KB responses at about 4.8 TB a month cost roughly $430 in egress at $0.09 per GB, several times the compute bill [17] |
Latency insurance | Do you pay for warm capacity to hit a latency target? | A steady customer-facing API reported $8,200 a month on Lambda with provisioned concurrency [15] |
Network path | Do private network needs add gateway charges? | VPC requirements that create NAT Gateway costs are listed as a trigger to move to containers [12] |
Region hops | Does traffic cross zones or providers? | Cross-zone traffic runs $0.01 per GB each way, while same-region service traffic is free [17] |
Logs | How much is written, for how long, and does it hold personal data? | Long log retention can conflict with deletion duties under India’s DPDP guidance [22] |
Before you sign off on any platform, fill in that table for your five busiest functions. It takes an afternoon and it changes more decisions than any benchmark.
Agents: durable workflows as the spine, functions as the hands
An agent loop contains two kinds of work. Steps are short and independent: call a model, run a tool, write a result. Waiting is different: an approval, a slow third-party API, a human who replies in three hours.
Agent builders set limits at several levels, for example 30 seconds per tool call, 20 minutes per task loop and a cap on total sandbox lifetime [8]. A 30-second tool call is a natural function. A 20-minute loop sits at the edge of what a plain function can hold.
Waiting is where naive designs fail. One engineering write-up walks through an approval that may take three hours. Keeping a function open costs money and hits the 15-minute cap. Saving state and resuming later needs a queue, a state store, coordination logic, retry handling and version management [7]. A 2026 developer trends review reaches the same conclusion, noting that standard functions still time out on long agent tasks [4].
The pattern that works has four parts:
A workflow engine or durable function owns the plan and the state.
Each action runs as a small, idempotent function.
Results return as events that resume the workflow.
Anything slower than a second or two streams progress to the user [3].
The function stays small and the workflow carries the memory. This split also predicts where FaaS grows. The more agents a company runs, the more small actions it executes.
The Function Fit Test
Score each workload on five questions. Do it per function, because one application usually contains all three answers.
Question | Function | Measure it | Container or workflow |
Duty cycle | Under 10% | 10% to 50% | Over 50% |
Duration | Seconds to a few minutes | Close to the platform timeout | Beyond the timeout, or unpredictable |
State | None, or kept in a database | Small state per call | Held in memory across calls |
Data out per call | A few KB | Tens of KB at high volume, so price it | Megabytes per call [12] |
Residency | Covered by choosing a region | Needs data mapping first | Needs controls beyond region choice |
Mostly first column: use a function. Mostly last column: use a container or workflow. A mixed score usually means a split design, with a function at the edge that hands long work to a container or workflow.
Build functions you can move, test and trust
Four habits pay for themselves quickly.
Keep the handler thin. Moving a function between clouds means rewriting the handler signature, the event parsing and the service integrations, while the core logic stays the same [13]. Put business logic in a plain module and let the handler be a small adapter:
python
# core/invoice.py (no platform imports)
def build_invoice(order: dict) -> dict:
total = sum(i["qty"] * i["unit_price"] for i in order["items"])
return {"order_id": order["id"], "total": round(total, 2)}
# handler.py (the only platform-specific file; the exact shape varies by platform)
import json
from core.invoice import build_invoice
def handler(event, context):
order = json.loads(event["body"])
return {"statusCode": 200, "body": json.dumps(build_invoice(order))}
Make every handler idempotent. Webhook senders and queues retry, so the same event will arrive twice sooner or later. Store the event ID, check it first, and skip work you have already done.
Set short timeouts on event-driven work. Guidance from Dash0 suggests 3 to 6 seconds for API-style calls, with batch-driven sources tuned to batch size [9]. A short timeout turns a hung dependency into a fast, visible failure.
Trace from day one. Traditional APM tools struggle with short-lived distributed functions [2], and an older community survey ranked debugging and monitoring as the top serverless pain point [24]. That survey is dated, but the complaint still matches what teams report. Pass a correlation ID through every call, and look at OpenTelemetry, which developer trend reviews now list as part of the standard stack [4].
In India, where a function runs is a design decision
India’s Digital Personal Data Protection (DPDP) Act does not impose blanket localisation. Under Section 16 and Rule 15 of the 2025 Rules, cross-border transfer is allowed by default and restricted only for destinations the government notifies [18]. Two layers sit on top of that. Significant Data Fiduciaries may face conditions on specified categories of personal data and associated traffic data [19]. Sector rules apply today too, and the RBI requires payment data to be stored only in India [20]. Sources place full enforcement of the substantive obligations at 13 May 2027 [21].
Take the payment webhook. It is the textbook function, and it may carry payment data. Whether a given payload falls under the RBI rule is a question for your compliance team. The execution region and the log destination both belong in that conversation. Logs deserve the same care as the database, because personal data that lands in logs is treated like any other personal data [22].
A sensible default is to keep region a configuration value. One compliance guide advises keeping residency configurable so Indian users’ data can be localised without re-architecting [23]. This section is general information and not legal advice, so have counsel review your data flows.
A 30-day plan you can start on Monday
Week 1: inventory. List every scheduled job, webhook receiver and queue consumer. Pull 30 days of invocation counts and run times from your logs.
Week 2: score. Compute duty cycle for each, run the Fit Test and fill in the bill table for the busiest five. Shortlist three to five clear candidates.
Week 3: pilot one. Pick a low-risk, idempotent job. Split it into a core module and a thin handler. Add tracing, a timeout and an alert.
Week 4: compare. Run a week of side-by-side data on cost, p95 latency and error rate. Decide the next batch, and write down what stayed on containers and why. That record will save the next architect a lot of arguing.
Where this goes next
These are our predictions, held with moderate confidence.
Placement replaces ideology.
Teams will place workloads one at a time. The question shifts from “serverless or containers” to “which workload goes where.”
Agents become a leading source of invocations.
Every action an agent takes is a candidate function call.
Functions gain durable state at the edges.
Checkpointing and longer limits are already arriving [6], and they will pull more multi-step work into the model.
Buyers compare bills, and price per GB-second stops being the deciding number.
Egress, logging, warm capacity and execution region will sit next to it on the checklist.
Ten questions to ask any FaaS provider
Use these in your next evaluation, whichever platform you consider.
Which components are billed: requests, execution time, outbound transfer, logs, warm capacity?
What are the minimum billed duration and the monthly included usage?
What are the hard limits for memory, CPU, timeout and concurrency?
How does scaling behave at zero, at the instance ceiling and under throttling?
Where do functions execute, and where do logs and data at rest live?
Can functions reach your databases, object storage and private services over a private network without extra gateway charges?
Which triggers are supported: HTTP, schedule, queue, storage events?
How long are logs and metrics kept, and what does retention cost?
What would it take to move a function away later?
When a workload outgrows functions, is there a container or VM option on the same network?
We built Tower Functions to answer these in public, with the specifications and pricing on one page: https://tower.cloud/functions. Tower Cloud is an Indian cloud provider, ISO/IEC 27001:2022 and ISO/IEC 20000-1:2018 certified.
References
Serverless vs Containers in 2026, DEV Community:
Serverless Architecture in 2026, Middleware:
AWS Trends to Watch in 2026, DEV Community:
The developer tech stack trends worth watching in 2026, daily.dev:
Datadog, State of Serverless 2023 press release:
AWS, Lambda 90-minute function timeout on Lambda Managed Instances (Sep 9, 2026):
https://aws.amazon.com/about-aws/whats-new/2026/09/aws-lambda-90-minute-function/
AI Agents should be serverless and durable, Restate:
AI Agent Sandbox guide, Firecrawl:
AWS Lambda Timeout Best Practices, Dash0:
https://www.dash0.com/guides/aws-lambda-timeout-best-practices
AWS Lambda vs Google Cloud Functions, Blaxel:
Serverless vs Containers Cost Comparison 2026, The Cloud Standard:
Lambda vs Containers: When Pay-Per-Use Costs 3x More, byteiota:
https://byteiota.com/lambda-vs-containers-when-pay-per-use-costs-3x-more/
Serverless vs Containers in 2026 and When to Choose Each One, KodeKloud:
https://kodekloud.com/blog/serverless-vs-containers-in-modern-architectures-and-when-to-choose-each/
Serverless vs Containers: Data Transfer Costs, Hokstad Consulting:
https://hokstadconsulting.com/blog/serverless-vs-containers-data-transfer-costs
Serverless vs Containers decision framework, DEV Community:
Serverless Cost Optimization, Opsio:
https://opsiocloud.com/blogs/serverless-cost-optimization-guide/
Serverless platform comparison including egress, InventiveHQ:
Data Localisation Under the DPDP Act, Digital Anumati:
https://digitalanumati.com/insights/data-localisation-under-the-dpdp-act/
DPDP compliance for SaaS and technology companies, India Briefing:
https://www.india-briefing.com/news/dpdp-act-compliance-saas-companies-india-47090.html
DPDP and data residency, Proactive:
https://proactive.co.in/blog-details/dpdp-data-center-ai-residency
The DPDP Act 2026 practical compliance guide, Syslabs:
https://www.syslabs.in/blog/dpdp-act-2026-compliance-guide-india
The DPDP India 2026 Handbook, Levo:
India DPDP Compliance Guide for engineers, Vucense:
Serverless Adoption Survey, Serverless First (older survey):
https://serverlessfirst.com/emails/serverless-adoption-initial-survey-results/