⚡ Quick Answer
Serverless computing lets you run code without provisioning or managing servers — the cloud provider handles all the infrastructure. You write functions (small, single-purpose code units), deploy them, and are billed only for the milliseconds they actually run. FaaS (Function as a Service) is the core model: functions are triggered by events (an HTTP request, a file upload, a database change) and scale automatically from zero to millions of invocations. AWS Lambda is the most widely used FaaS platform; equivalents are Azure Functions and Google Cloud Functions.

What Does "Serverless" Actually Mean?

The name "serverless" is a slight misnomer — there are absolutely still servers involved. What it means is that you don't see, manage, or pay for the servers when your code isn't running. The cloud provider owns and operates all the underlying infrastructure; you simply deploy your code and let the platform handle the rest.

In traditional cloud computing (IaaS), you provision a virtual machine, install an OS, configure software, and pay for that VM 24/7 whether it's doing anything or not. In serverless, the model flips: your code sleeps when there's nothing to do, wakes up in milliseconds when triggered, executes, and then goes dormant again. You pay only for the compute time consumed during execution — typically measured in 1-millisecond increments.

This model delivers three major advantages: no infrastructure management (no OS patching, no capacity planning, no server configuration), automatic scaling (the platform scales from 0 to thousands of concurrent executions instantly without any configuration), and pay-per-use billing (a function that runs 1,000 times per month costs a tiny fraction of a VM that runs idle 99.9% of the time).

FaaS — Function as a Service

FaaS is the compute model that underlies serverless. The key characteristics of a serverless function are:

Event-triggered
Functions don't run continuously. They execute in response to a trigger — an HTTP request, a file upload to object storage, a message in a queue, a database change, or a scheduled cron timer.
🔒
Stateless
Each function invocation is independent and isolated. The function cannot assume any local state persists between invocations. Persistent data must be stored externally (database, object storage, cache).
⏱️
Short-lived
Functions are designed for fast execution. AWS Lambda has a maximum timeout of 15 minutes. Azure Functions can run longer depending on the plan. Long-running processes (hours or days) are not suited for FaaS.
📈
Auto-scaling
The platform automatically provisions execution environments in parallel to handle concurrent invocations. A sudden spike from 1 to 10,000 requests per second is handled without any manual scaling action.

AWS Lambda — The Most Widely Used FaaS Platform

AWS Lambda, launched in 2014, popularised the serverless model and remains the most widely used FaaS platform. Understanding Lambda is essential for AWS certifications and gives you a solid mental model for Azure Functions and Google Cloud Functions, which work similarly.

A Lambda function consists of your code (uploaded as a ZIP file or container image), a runtime (the language environment — Node.js, Python, Java, Go, .NET, Ruby, and more are supported), and a handler (the entry point function within your code that Lambda calls). You configure the function's memory (128 MB to 10 GB), timeout (up to 15 minutes), and the IAM role that defines what AWS resources it can access.

Lambda functions are priced on two dimensions: invocation count (the first 1 million requests per month are free; $0.20 per million thereafter) and compute duration (charged in 1-millisecond increments based on memory allocation). For many workloads, Lambda is dramatically cheaper than running equivalent EC2 instances — a function that runs 100ms, 100,000 times per day, costs roughly $2/month.

Lambda equivalents across cloud providers

AWS Lambda — the original FaaS service, launched 2014. Most widely used.
Azure Functions — Microsoft's equivalent. Integrates tightly with Azure Event Grid, Service Bus, and Cosmos DB triggers.
Google Cloud Functions (1st gen) and Cloud Run functions (2nd gen) — Google's FaaS offerings. Integrates with Pub/Sub, Firestore, and Cloud Storage triggers.
Cloudflare Workers — a serverless edge computing platform that runs functions at CDN edge locations worldwide, not just in datacenters. Extremely low latency for globally distributed workloads.

Event-Driven Architecture

Serverless functions are naturally stateless and short-lived, which makes them a perfect fit for event-driven architecture (EDA) — a design pattern where application components communicate by producing and consuming events rather than by making direct, synchronous API calls.

In a traditional monolithic or microservices architecture, Service A calls Service B directly: "process this payment now." In an event-driven architecture, Service A emits an event: "payment submitted" — and any interested services (payment processor, notification service, inventory system, audit logger) independently consume and react to that event. The producer doesn't know or care who consumes it.

This decoupling has significant benefits: resilience (if the notification service is down, the payment still processes — the event is queued), scalability (each consumer scales independently based on its queue depth), and extensibility (add a new consumer without changing the producer). The trade-off is increased system complexity and the need for careful management of event ordering and delivery guarantees.

📤
Event Producer
The service or system that generates an event when something happens. A user uploads a file, a sensor reports temperature, a payment is submitted. The producer publishes the event and moves on — it doesn't wait for consumers to finish.
🚌
Event Bus / Message Queue
The infrastructure that routes events from producers to consumers. AWS uses EventBridge (event bus) and SQS/SNS (queues/topics). Azure uses Event Grid and Service Bus. GCP uses Pub/Sub. These systems buffer, route, and deliver events durably.
📥
Event Consumer
A function or service that subscribes to and processes events. Multiple consumers can subscribe to the same event independently. A Lambda function triggered by an SQS message is a classic event consumer pattern.
🔗
Trigger
The specific event source that invokes a serverless function. Common triggers: HTTP request (API Gateway), file upload (S3), database change (DynamoDB Streams), message in queue (SQS), scheduled time (EventBridge Scheduler / cron).

Common Serverless Use Cases

🌐
REST APIs & Web Backends
API Gateway + Lambda is a classic pattern for building HTTP APIs. Each endpoint maps to a Lambda function. Scales to millions of requests with zero server management.
🖼️
Image & File Processing
Trigger a Lambda when a file is uploaded to S3 — resize an image, transcode a video, extract text from a PDF, or validate a document. Run only when there's work to do.
Scheduled Jobs
Replace cron jobs on EC2 with scheduled Lambda triggers. Run a nightly report, clean up old database records, or send a daily email digest — pay only for the seconds it runs.
📊
Real-Time Data Processing
Process streaming data from IoT sensors, application logs, or clickstreams in real time. Lambda integrates with Kinesis, DynamoDB Streams, and SQS for event-by-event processing.
🤖
Chatbots & Automation
Serverless functions are ideal for webhook handlers — Slack bots, GitHub Actions triggers, or Stripe webhook processors that run only when invoked and sleep the rest of the time.
🔔
Notifications & Alerts
Fan-out notifications at scale: one event triggers a Lambda that sends push notifications, emails, and SMS simultaneously via SNS — without managing a notification server.

Serverless vs Containers vs VMs

Property Serverless (FaaS) Containers Virtual Machines
Infrastructure managementNone — fully managedLow — manage container orchestrationHigh — manage OS, patching, scaling
ScalingAutomatic, scales to zeroAutomatic with orchestrator (K8s)Manual or scheduled auto-scaling
Billing modelPer invocation + duration (ms)Per running container (seconds)Per running VM (hours)
Cold startYes — latency on first invocationMinimal (containers start in ms)Slow (minutes to boot OS)
Max execution time15 min (Lambda), varies by providerUnlimitedUnlimited
Stateful workloadsPoor — stateless by designGood — with persistent volumesBest — full persistent storage
Best forIrregular, event-driven, short tasksMicroservices, consistent workloadsLegacy apps, full OS control needed

The Cold Start Problem

The most discussed performance trade-off of serverless is the cold start. When a serverless function hasn't been invoked for a period of time, the provider scales it down to zero — no execution environment is running. When the next request arrives, the provider must: (1) allocate compute resources, (2) download and initialise the function code, (3) start the language runtime, and (4) execute the handler. This process typically adds 100ms to several seconds of latency on top of the normal execution time.

Cold starts are worst with runtimes that have slow initialisation — Java and .NET have significantly worse cold starts than Node.js or Python because of JVM/CLR startup overhead. Large deployment packages (ZIP files with many dependencies) also increase cold start time.

Mitigation strategies: AWS Lambda Provisioned Concurrency keeps a specified number of execution environments pre-warmed, eliminating cold starts for latency-sensitive workloads (at additional cost). Keeping functions warm with periodic scheduled pings (every few minutes) is a cheaper but less reliable approach. Choosing lightweight runtimes (Node.js, Python) and minimising deployment package size also reduces cold start impact.

🎯 Key Concepts to Remember

Serverless = no server management + pay-per-use + auto-scale.

FaaS = functions triggered by events, stateless, short-lived.

Cold start = latency on first invocation after idle period.

Event-driven = producers emit events, consumers react independently. The decoupling is the key architectural benefit.

Serverless Security Considerations

Serverless shifts the security boundary significantly toward the application layer. Since the provider manages the underlying infrastructure, you no longer need to patch OS vulnerabilities or harden server configurations — but you are fully responsible for your function code, dependencies, and IAM permissions.

Overly permissive IAM roles are the most common serverless security mistake. Following the principle of least privilege is critical: each Lambda function should have its own IAM role with only the permissions it specifically needs. A function that reads from one S3 bucket should not have write access to other buckets or access to unrelated services.

Dependency vulnerabilities in your function's package dependencies (npm packages, Python pip packages) are a significant risk. Serverless functions often pull in many third-party packages, each of which may contain known CVEs. Regular dependency scanning and updates are essential.

Injection attacks remain relevant in serverless — SQL injection, command injection, and event data injection can all occur if function code processes user-supplied input without proper validation and sanitisation.

Key Scenarios

Scenario: A company wants to process images uploaded to cloud storage — resize them and generate thumbnails — without managing any servers. What is the best architecture? Answer: Serverless — a Lambda function triggered by S3 upload events. Runs only when an image is uploaded, scales automatically, and costs near zero for low volumes.
Scenario: An application needs to run a task that takes 45 minutes to complete. Is AWS Lambda appropriate? Answer: No — Lambda has a maximum execution timeout of 15 minutes. Use a container (ECS/Fargate) or a VM for long-running jobs.
Scenario: A serverless API has high p99 latency on the first request of the day. What is the likely cause and solution? Answer: Cold start latency. Solution: enable Provisioned Concurrency to keep execution environments pre-warmed.
Scenario: What is the main billing advantage of serverless over always-on VMs for a workload that runs 5 minutes per hour? Answer: Pay-per-use — serverless charges only for those 5 minutes of actual execution. A VM runs (and is billed) for the full 60 minutes even when idle.
Scenario: A Lambda function has been granted full S3 access, full DynamoDB access, and full EC2 access even though it only needs to read from one S3 bucket. What security principle is being violated? Answer: Principle of least privilege. The function should have an IAM role with only read access to the specific S3 bucket it needs.

Preparing for a Cloud Certification?

Check out the best study resources for AWS, Azure, and CompTIA cloud exams.

View Resources →

Related Articles