What Is Serverless Architecture? Scaling Without Servers

In a serverless setup, the provider runs your code in short-lived, event-triggered compute, so you provision no servers. It scales on its own, and you pay per execution.

APIs, file processing, scheduled jobs and webhooks are the usual fits, mostly because traffic for them arrives in bursts and then sits idle.

The Cloud Native Computing Foundation’s 2018 serverless whitepaper splits the model into function as a service (FaaS), backend as a service (BaaS), or both. By that definition, a platform that offers only managed backend services such as databases and authentication still counts as serverless, even with no functions in it.

What is serverless architecture?

Billing follows executions, not reserved capacity. That is the quickest way to tell serverless apart from a rented server, and it comes from the fact that the developer provisions and maintains nothing. The provider runs the code when an event fires.

The Cloud Native Computing Foundation’s serverless whitepaper (v1.0, 2018) describes it as building and running applications without server management, delivered through function as a service (FaaS), backend as a service (BaaS), or both.

Servers still exist, of course. The provider owns and patches them and picks where the code runs.

Teams pick this model when they want the provider to own the runtime layer of their software architecture.

People use “serverless architecture” and “serverless computing” as if they meant the same thing, and vendors do it too. Architecture is the application design: functions, managed services and event triggers wired together. Computing is the execution model underneath, where the platform allocates compute per event. FaaS is narrower still, just the component that runs your code, so it is one piece of a serverless design and not the whole. The distinction only really bites with FaaS.

BaaS products came first, with Parse in 2011 and Firebase in 2012. AWS Lambda launched in November 2014 (CNCF whitepaper).

How does serverless architecture work?

An event reaches a trigger, the platform finds or creates an execution environment, runs the function, returns the result, and freezes the environment for possible reuse. The developer writes the function and configures the trigger. The provider handles everything in between.

1. An event arrives at a trigger, such as an HTTP request or a file upload.
2. The platform looks for an idle, initialized execution environment.
3. If none exists, it builds one and runs the initialization code (a cold start).
4. The handler runs with the event as its input.
5. The result goes back to the caller and the environment is frozen.

Event sources and triggers

A trigger is whatever calls the function, and one function can sit behind several of them.

• HTTP requests routed through Amazon API Gateway
• Object uploads to Amazon S3
• Messages arriving on a queue
• Schedules defined in Amazon EventBridge
• Database changes

A synchronous caller waits for the response. An asynchronous caller such as S3 hands the event to an internal queue and moves on, which is how the AWS Compute Blog describes the path.

The trigger model comes from event-driven architecture. Serverless adds hosting and scaling on top of it.

Execution environments

Per the AWS Lambda documentation, an execution environment starts with Init, which starts extensions, bootstraps the runtime and runs static code outside the handler. That phase is limited to 10 seconds. Invoke comes next and runs the handler, with the function’s timeout setting as the cap. Shutdown then terminates the runtime and its extensions.

Each environment is isolated from the others. Lambda runs them on Firecracker microVMs, a lightweight virtual machine monitor that AWS built for Lambda and Fargate.

The Firecracker authors chose microVMs over containers because containers share a host kernel and isolate customers less strongly (Agache et al., NSDI 2020).

Why functions stay stateless

Nothing survives between invocations unless it is stored outside the function.

AWS describes Lambda as built for short-lived compute that does not retain state between invocations. Reuse of an environment is possible but never guaranteed. Concurrent requests also get separate environments with separate memory, and a crash or timeout resets the one in play.

Durable data belongs in a managed store such as Amazon DynamoDB or Amazon S3.

How function as a service and backend as a service fit together

Most serverless applications use both. Function as a service runs custom code in response to events, while backend as a service hands you databases, authentication and file storage as managed features.

The CNCF whitepaper treats a backend as a service/) layer as API-based services that replace pieces of a backend you would otherwise build and run yourself.

Amazon EventBridge routes events between services, and AWS Step Functions coordinates multi-step workflows across several functions.

An API gateway such as Amazon API Gateway maps HTTP routes to functions. In Datadog’s 2022 State of Serverless report, API Gateway accounted for more than half of its customers’ Lambda invocations.

Picture an image landing in S3. S3 triggers a function, and the function writes metadata to DynamoDB.

How serverless scaling and billing work

A serverless platform adds one execution environment per concurrent request and bills for requests and compute time. A function nobody calls costs nothing, unless you pay to keep environments warm.

The Lambda limits, per the AWS documentation, are easy to hit if you never read them. Account concurrency defaults to 1,000 concurrent executions per Region, and it is lower for new accounts. Each function can add 1,000 new execution environments every 10 seconds. Once concurrency runs out, requests start to drop (throttling).

Requests per second are capped at 10 times the concurrency quota. A function that finishes in 50 ms can hit that cap before it uses all its concurrency.

Capacity grows by adding copies of the environment, which is horizontal scaling, and shrinks to zero when traffic stops.

How Lambda bills

The Lambda bill is a request charge plus a compute charge. AWS charges $0.20 per million requests plus $0.0000166667 per GB-second of compute (x86, US East), with a monthly free tier of 1 million requests and 400,000 GB-seconds (AWS Lambda pricing).

A GB-second is one second of execution with 1 GB of memory configured. Doubling the memory doubles the per-second price, so right-sizing memory matters as much as shortening duration.

Rates differ by Region and CPU architecture. Arm-based functions cost less per GB-second than x86 in many Regions.

One recent change catches people out. Effective August 1, 2025, AWS bills the initialization phase at standard duration rates on all configurations. Before that, on-demand ZIP functions on managed runtimes ran their init code unbilled (AWS Compute Blog).

Provisioned concurrency adds its own charge for keeping environments initialized, whether or not requests arrive.

Cost crossover versus containers

Per-execution billing wins when a function sits idle most of the day. It loses when the function is busy nearly all of it.

A 1 GB function running every second of a 30-day month uses 2,592,000 GB-seconds. At the rate above, that is about $43 in duration charges alone, before the free tier and request fees (calculated from the published price).

No source publishes a universal break-even point, because it depends on memory, duration and what an always-on container costs in your Region.

If a function stays busy most of the day, price an always-on container with the same memory before committing.

What is a cold start, and how much does it matter?

Before the handler can run, the platform sometimes has to create a new execution environment, download the code, start the runtime and run initialization code. That wait is the cold start. It hits a small share of invocations, but those are the slowest requests you serve.

How often cold starts happen

It happens on the first call after a deploy, on a call after the environment sat idle and was reclaimed, on each additional concurrent request during a scale-up, and on the first call after a code or configuration change.

The frequency figures nearly agree. The durations do not, and neither source explains the gap.

AWS describes an aggregate across production workloads. Sedai, a cloud tooling vendor, reports per-runtime figures, with a small Node.js function near 3 seconds and .NET up to 14.

Treat both as ranges and measure your own function. The REPORT line in CloudWatch Logs carries an init duration for cold-started invocations.

It goes wrong when traffic jumps from zero to many concurrent requests and the p99 latency targets are strict. Each concurrent request needs its own environment, so a spike produces a burst of cold starts.

How to reduce cold start impact

SnapStart reuses one snapshot across many environments. Code that creates unique IDs, secrets or network connections during init needs changes before it is safe (AWS documentation).

Java managed runtimes carry no additional SnapStart charge, so it is the cheaper first step there. AWS points to provisioned concurrency when latency requirements are strict and SnapStart falls short.

A caller that is not waiting for a response never feels a cold start. Batch jobs and scheduled tasks rarely need any of this.

What limits apply to serverless functions?

Run time, memory, payload size and package size decide whether a workload fits. On AWS Lambda the hard ceilings are a 15-minute timeout, 10,240 MB of memory and a 6 MB synchronous payload.

AWS splits quotas into hard limits, which no support ticket changes, and soft limits that a Service Quotas request can raise. Concurrency is soft. Timeout, memory and payload size are not.

These are the figures from the AWS Lambda quotas page, as of October 2026.

• Timeout tops out at 900 seconds per invocation
• Memory runs from 128 MB to 10,240 MB, with one vCPU at 1,769 MB
• Payloads are 6 MB for synchronous requests and responses, and 1 MB for asynchronous events
• Packages are 50 MB zipped through the API, 250 MB unzipped, and 10 GB for container images
• /tmp storage runs from 512 MB to 10,240 MB

You cannot set CPU directly. It follows memory, so a CPU-bound function gets faster by raising the memory setting.

Check the live page before designing around a payload cap. Older copies of the quotas page and some third-party guides still show 256 KB for asynchronous events, while the current page shows 1 MB.

For anything bigger than the cap, pass an S3 object reference instead of the data.

Working around the 15-minute ceiling

Lambda durable functions, announced in December 2025, checkpoint progress and suspend execution for up to one year without compute charges while they wait (AWS What’s New).

They do not lift the per-invocation timeout. Each active stretch still runs inside the normal limits, which is how one request can span days, as InfoQ’s coverage explains.

Durable executions have caps of their own, per the AWS quotas page.

• 30,000 durable operations per execution
• 100 MB of persisted data per execution
• 1 MB payload per durable operation

Past those caps, a long workflow needs splitting into smaller executions.

What is serverless architecture used for?

HTTP APIs, event-triggered file and stream processing, scheduled jobs, webhooks and multi-step workflows are the usual fits. All of them are short, bursty and stateless by nature.

• APIs usually get one function per route behind Amazon API Gateway. In the same Datadog 2022 data, 80% of Lambda invocations coming from API Gateway went to single-purpose functions, a pattern more than 60% of its customers use.
• File and stream processing works well because an upload to Amazon S3 triggers a transform and nothing idles while the bucket is empty.
• Scheduled jobs, like a nightly report or cleanup, run from an Amazon EventBridge schedule.
• Webhooks are inbound callbacks from payment or messaging providers.
• Workflows are multi-step flows coordinated by AWS Step Functions.

A webhook endpoint suits a function because callbacks arrive in bursts and sit idle in between.

Data processing pipelines chain functions through queues, so each stage scales on its own.

Coca-Cola’s Vending Pass team replaced a hand-built 90-second delay between two Lambda calls with a Step Functions wait state, which simplified their logic and reduced cost (AWS News Blog).

A quick fit test helps. Is traffic spiky or unpredictable, is each run short, and does the code keep no state in memory? If two of those come back no, look at containers.

Which serverless platforms are available?

Platforms split into managed function services, serverless container services and self-hosted runtimes, and each sets its own limits. A function that fits one may not port to another.

Managed function platforms

Azure’s Flex Consumption plan goes further. The default timeout is 30 minutes and the host enforces no limit, though instances can still be terminated during scale-in, deployments or updates (Microsoft Learn). Microsoft now treats the Consumption plan as legacy and recommends Flex Consumption for new serverless apps.

Google renamed Cloud Functions (2nd gen) to Cloud Run functions in August 2024, and they now deploy as Cloud Run services (Google Cloud release notes).

Workers run code in V8 isolates inside an existing runtime process instead of starting a virtual machine per function. Cloudflare’s documentation says this removes the cold starts of the virtual machine model.

The trade is CPU time, which is 10 ms on the Free plan and up to 5 minutes on Paid (30 seconds by default), with time spent waiting on the network not counted.

Serverless containers and self-hosted runtimes

Cloud Run is Google’s serverless container platform, and it now hosts Cloud Run functions too. AWS Fargate offers serverless compute for ECS and EKS containers, billed per second for vCPU and memory with a one-minute minimum (AWS Fargate pricing).

Knative is open source and Kubernetes-based, with Serving scaling to zero and Eventing handling events. The CNCF accepted it as an incubating project in March 2022 and graduated it in September 2025.

OpenFaaS, a self-hosted FaaS framework from 2016, runs on Kubernetes, where scale to zero brings cold starts back (Palark).

Self-hosting swaps the provider’s operations work for your own. It buys portability, and it only pays off if you already run Kubernetes.

Serverless versus containers, microservices and virtual machines

Choose serverless for spiky, short, event-driven work and containers for steady or long-running services. Microservices describe how a system is split, which serverless can implement, and virtual machines give the most control for the most upkeep.

Comparing serverless with microservices mixes two different questions. Serverless answers where code runs and how it is billed, while a microservices architecture answers how the system is divided into services.

A function per service is one way to build microservices. Containers are another.

With containerization you own the image, its base layer and the scaling rules, and Kubernetes adds cluster upkeep on top.

The line between the groups has blurred. AWS Lambda Managed Instances, announced in November 2025, runs functions on EC2 instances in your account. Pricing is $0.20 per million requests, plus EC2 charges and a management fee of 15% of the EC2 on-demand price, with no separate duration charge. Each execution environment serves several requests at once, and asynchronous invocations can run up to 90 minutes.

It targets steady workloads that can use EC2 commitment pricing, which is the case where per-execution billing loses.

Serverless makes sense when traffic is spiky or unpredictable, each run is short and the team has no capacity for platform work. Containers or virtual machines win when load is steady around the clock, processes run long or keep state in memory, or you need control over the runtime or the OS.

Most production systems mix them. Functions handle the API layer and webhooks, and containers run the long-lived workers.

What are the trade-offs of serverless architecture, and when does it not fit?

Serverless trades operational work for provider dependence. You stop patching and planning capacity, and you give up control over the runtime, debugging and portability.

Advantages and drawbacks

On the plus side, the provider patches the OS and, in Auto update mode, the managed runtime. You skip capacity planning across normal traffic ranges, and small units ship and roll back on their own.

Against that, there is vendor lock-in through triggers, permissions and managed services. Debugging gets harder across ephemeral, distributed environments, and tracing across functions needs extra tooling. Audit trails are also harder to guarantee for compliance.

Lock-in sits in the glue, not the code. Event payload shapes, IAM roles and stores such as Amazon DynamoDB tie a function to its provider.

Cloudflare says Workers are easier to migrate because they target the service workers API.

On security, AWS documents a split. In Auto mode Lambda applies runtime patches to existing functions, and you keep the function code, its permissions and any rollback.

Container-image functions flip that. AWS publishes updated base images, and you rebuild and redeploy.

New Relic points out that ephemeral execution means failures vanish with the environment. AWS X-Ray and third-party tools such as Datadog exist to trace a request across functions before the evidence is gone.

When serverless does not fit

A hot, always-on pipeline is the wrong default candidate. Several situations rule serverless out.

• Work that runs longer than the platform ceiling and cannot be checkpointed
• Steady, high-volume load where compute is busy around the clock
• Latency targets that a cold start would break
• Large payloads or state held in memory
• Legacy applications that would need a rewrite to fit (Cloudflare calls such migrations prohibitively difficult in some cases)

Amazon’s Prime Video quality analysis team moved a stream-monitoring tool from a distributed serverless design to a single process on Amazon ECS. Infrastructure cost fell by over 90% (team post of March 22, 2023, quoted by Network World).

Summaries of the post name Step Functions orchestration and S3 hand-offs between steps as the bottlenecks. The team moved one service, not the whole platform.

Start serverless where the traffic shape fits, and treat a continuous, many-step pipeline as a candidate for containers first.

How to build and run a serverless application

Define the trigger, write a stateless handler, keep state in a managed store, set memory from measurements, describe everything as code, deploy through a pipeline, and add monitoring before the first release.

1. Choose the trigger and give each function one job.
2. Put state in a managed store such as Amazon DynamoDB or Amazon S3.
3. Measure memory with AWS Lambda Power Tuning, an open source Step Functions state machine that runs your function at several memory settings and ranks cost against speed.
4. Describe functions, triggers and APIs in an AWS SAM template, which extends CloudFormation with shorthand for serverless resources.
5. Deploy with the SAM CLI or the Serverless Framework.
6. Add logs, metrics and traces before launch.

Treating those templates as infrastructure as code keeps functions, permissions and triggers versioned together.

On tooling, Serverless Framework v4, generally available since June 2024, requires a paid subscription for organizations above $2 million in annual revenue. Authentication is mandatory, and v3 stays open source.

Non-AWS providers are deprecated in v4, so a multi-cloud project may stay on v3 or switch tools.

The SAM CLI runs sam local invoke and sam local start-api against a Lambda-like environment. It is an emulation, so a final test belongs in a real account.

A few errors show up again and again.

• Timeouts, including failures during the Init phase, which Lambda logs in INIT_REPORT
• Throttling from a quota mismatch (AWS flags that API Gateway’s default throttle of 10,000 requests per second exceeds Lambda’s default concurrency, and a load test finds it first)
• Oversized packages, since layers count toward the unzipped size limit
• Missing traces, because a cold start appears in AWS X-Ray as a separate initialization segment only when tracing is turned on

Serverless Architecture FAQ

Does serverless mean there are no servers?

No. Servers still run the code, but the provider owns, patches and scales them, and bills per execution instead of per machine.

The name describes what you stop managing, not what exists.

Is serverless architecture secure enough for regulated workloads?

Yes, when the responsibility split is followed. AWS applies runtime patches by default, while you keep function code, dependencies and permissions.

For audits, turn on AWS CloudTrail and Amazon CloudWatch logging from the first deployment. An execution environment keeps no evidence of its own once it is discarded.

Which programming languages does serverless support?

AWS Lambda ships managed runtimes for Node.js, Python, Java, .NET and Ruby. Go, Rust and other languages run through an OS-only or custom runtime.

Cloud Run functions covers a similar set and adds PHP, so check the runtime list of your platform before choosing a language.

How do you test and debug serverless functions?

Locally, the AWS SAM CLI runs a function in a Lambda-like environment with sam local invoke, and a debug port lets an IDE attach.

In production, rely on structured logs and AWS X-Ray traces. A local run is an emulation, so a final test belongs in a real account.

Which Workload to Move to Serverless First

Serverless architecture pays off first on asynchronous, bursty work such as scheduled jobs, webhooks and file or queue processing. A failed run there retries quietly, and a cold start delays nothing a user can see.

Start with scheduled jobs and webhooks, then move to file and queue processing, and leave user-facing APIs for last. The order follows latency exposure. Early moves teach the team monitoring and permission design before a cold start can reach a customer.

Judge each move after one full billing cycle. Per-invocation cost and p99 latency, with init duration counted, must both hold against the old baseline.

The price of the move is provider dependence and weaker local emulation.

This advice reflects platform behavior verified on October 30, 2026. Revisit it when AWS changes the timeout ceiling, durable function limits or Lambda Managed Instances pricing.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu is a front-end developer at TMS Outsource with 8+ years of experience in web technologies. He writes about developer tools, software platforms, and web workflows based on daily hands-on use.

Latest posts by Bogdan Sandu (see all)

• What Communications Teams Should Ask Before Commissioning a Mobile App - November 12, 2026
• How to Install Node JS in VS Code and Run Your First Script - November 11, 2026
• Protecting Users and Brand Standards Across Image-Driven Platforms - November 10, 2026