AWS Serverless

Serverless on AWS is an operating model for applications. You choose managed services, connect them with events or requests, and let AWS manage much of the underlying capacity. You still own the application, data, access, configuration, failure behavior, and cost.

AWS Lambda is one serverless compute service. It is not the whole architecture. A useful serverless system often combines an entry point, event transport, compute, workflow coordination, and durable data.

The central shift is from managing hosts to designing interactions. You spend less time patching an operating system. You spend more time defining event contracts, permissions, retry behavior, concurrency limits, and observability across managed services.

The request and event model

Every serverless workload starts with a signal. A client sends an HTTP request. A file arrives in Amazon S3. A message enters Amazon SQS. A scheduled event fires. A business event reaches Amazon EventBridge.

The signal reaches a consumer. That consumer may be a Lambda function, a Step Functions workflow, or another AWS service integration. The consumer performs work and writes a result, emits another event, or returns a response.

This path has five useful stages:

1. Entry: API Gateway, an event source, or a schedule accepts the signal.
2. Routing: EventBridge rules, queues, topics, or direct integrations select a destination.
3. Compute: Lambda or another managed service performs a bounded unit of work.
4. Coordination: Step Functions records workflow state, applies choices, and handles retries or catches.
5. State: DynamoDB, S3, or another durable service stores data beyond one invocation.

You do not need every stage in every design. Keep the shortest path that preserves the required reliability and control.

Lambda as bounded compute

A Lambda function runs code inside an isolated execution environment. AWS creates and removes those environments as demand changes. A function receives an event through its handler and returns a result or error.

Treat each invocation as temporary. An execution environment may be reused, so initialized clients and temporary files may survive for a later invocation. That reuse is an optimization, not durable state. Store required state in a durable service.

Lambda default functions are designed for short-lived work. A single invocation has a maximum runtime, memory limits, payload limits, and regional concurrency quotas. Check current quotas before the workload depends on a value.

Initialization can add latency when Lambda creates an execution environment. Provisioned concurrency keeps a configured number of environments initialized, at additional cost. Use it only when measured latency requirements justify it.

Invocation changes failure behavior

Synchronous invocation keeps the caller on the request path. API Gateway can invoke Lambda and return the function response to the client. Errors travel back toward the caller, which decides whether to retry.

Asynchronous invocation queues an event inside Lambda and returns before the function finishes. Lambda has its own retry behavior for function errors. Configure event age, retry attempts, and a destination for exhausted events where the workload needs them.

Event source mappings poll streams or queues and invoke functions with batches. An SQS mapping hides messages during the visibility timeout. A failed batch can become visible again. Partial batch responses let the function identify only failed records.

Duplicate processing is possible. Make side effects idempotent. Given the same event more than once, an idempotent consumer produces the same intended business result without repeating an unwanted charge, shipment, or update.

Route, buffer, or orchestrate

Use EventBridge when several producers and consumers need event routing by pattern. An event bus evaluates rules and sends matching events to targets. Producers do not need to know every consumer.

Use SQS when a consumer needs a durable work buffer. A queue absorbs bursts and separates producer speed from consumer capacity. Queue age, depth, visibility timeout, and dead-letter handling become part of the design.

Use Step Functions when the application needs explicit workflow state. A state machine can order tasks, branch on data, run work in parallel, wait, retry, and catch errors. This keeps coordination out of ad hoc function-to-function calls.

These services solve different problems. EventBridge routes events. SQS buffers work. Step Functions coordinates steps. Combining them is normal when each boundary is deliberate.

Scaling is not capacity planning removed

Managed services can add capacity automatically, but every path still has a limiting component. Lambda concurrency can rise faster than a database, third-party API, or regional quota can tolerate.

Concurrency is the number of in-flight Lambda requests. Reserved concurrency protects capacity for a function and caps its maximum. That cap can protect a downstream dependency. Provisioned concurrency addresses initialization latency; it is not the same control.

For asynchronous work, queues provide backpressure. A growing queue shows that arrivals exceed processing capacity. For synchronous work, throttling and latency reach the caller directly. Load test the whole path, not only the function.

Security follows each hop

A Lambda execution role grants the function permission to call other AWS services. A resource-based policy grants a service, account, or other principal permission to invoke the function. These are separate directions of access.

Grant least privilege to both. Limit the execution role to required actions and resources. Limit invocation permission to expected sources where the service supports that condition.

Do not treat an API endpoint as authenticated because it is managed. API Gateway still needs an authorization design. Event sources still need resource policies or roles. Sensitive values belong in a secrets service, not in source code.

Observe the application, not one function

Lambda publishes invocation, duration, error, throttle, and concurrency signals through CloudWatch. Logs explain local behavior. Traces help connect latency across services. CloudTrail records control-plane API activity.

Application health needs business signals too. Track accepted orders, completed jobs, duplicate suppression, queue age, workflow failures, and dead-letter growth. A successful function invocation does not prove that the whole transaction completed.

Cost also follows the path. Lambda default functions charge for requests and execution duration. API Gateway, EventBridge, SQS, Step Functions, DynamoDB, CloudWatch, data transfer, and provisioned features have their own dimensions. Estimate and measure the full transaction.

Build and deploy as one application

AWS Serverless Application Model, or AWS SAM, extends infrastructure as code for serverless applications. A SAM template defines related resources and their connections. The SAM command line interface can build, test locally, package, and deploy the application through AWS CloudFormation.

Infrastructure as code makes event sources, permissions, concurrency, alarms, and data resources reviewable together. Deploy versions through a repeatable pipeline. Test failure and replay behavior as part of the release, not after an incident.

When serverless fits

Serverless fits event-driven applications, APIs, automation, data processing, and workflows that benefit from managed scaling and usage-based charging. It works best when tasks have clear boundaries and state lives in durable services.

It is a weaker fit when you require host-level control, unsupported runtimes or hardware, very long uninterrupted processes, or a cost model dominated by steady compute. A container or virtual machine may be clearer for those constraints.

Serverless does not remove operations. It changes the unit of operation from a server to a distributed transaction. Design each handoff, permission, limit, retry, and signal.

Learning path

1. Trace one API Gateway request into Lambda and back to the client.
2. Compare synchronous, asynchronous, and event source mapping invocation.
3. Add SQS and design idempotency, visibility timeout, and failed-record handling.
4. Route domain events with EventBridge without coupling producers to consumers.
5. Model a multi-step transaction in Step Functions.
6. Store durable state in DynamoDB or S3 and test consistency assumptions.
7. Define the application with AWS SAM and deploy through CloudFormation.
8. Load test concurrency, downstream capacity, retry paths, quotas, and cost.
9. Review the design with the AWS Serverless Applications Lens.