AWS
Intermediate 14 min read AWS

AWS Serverless Stack

Functions, gateways, queues and state machines

API Gateway + Lambda + DynamoDB + S3 + SQS is the canonical AWS serverless stack. Events in, code runs, state is managed — you pay per use and scale with zero servers.

LambdaAPI GatewayStep FunctionsSQSSNSevent-drivenserverless
Prerequisites: AWS Service Map Serverless
Before we start

What you will learn

  • Assemble an API Gateway + Lambda + DynamoDB stack
  • Explain event-driven integration with SQS/SNS/EventBridge
  • Manage Lambda cold starts, concurrency and permissions
In 60 seconds

API Gateway fronts HTTP endpoints; Lambda runs the logic; DynamoDB/S3 store state; SQS/SNS/EventBridge move events; Step Functions orchestrate multi-step flows. Everything scales automatically and bills per use.

Introduction

What is this?

AWS Lambda runs your code at up to 10GB of memory and 15-minute limits, handling concurrency and scaling. API Gateway exposes REST/HTTP/WebSocket APIs with authentication and throttling. SQS (queues), SNS (fan-out topics) and EventBridge (event bus + rules) move events between services. Step Functions orchestrates state machines for multi-step, stateful workflows. S3/ DynamoDB provide storage. This stack turns a backend into a set of small leased functions.

Motivation

Why do you need it?

  • Serverless collapses ops: no servers to patch, no capacity planning, per-request billing.
  • Event-driven glue (SQS/SNS/EventBridge) makes systems resilient to spikes by buffering.
  • Step Functions replaces fragile cron+retry loops with auditable state machines.
  • It is the common denominator interviewers expect you to sketch on a whiteboard.
Think about it

Mental model

Imagine

A restaurant kitchen with a ticket rail

Think of

AWS serverless

Tickets (events/requests) arrive on the rail; chefs (Lambda) grab one, cook, and pass the result. The rail (SQS) absorbs rushes; the manager (Step Functions) sequences multi-course meals. No one owns a stove — the kitchen scales on demand.

Mechanics

How it works

  • API Gateway authenticates, throttles and routes a request to a Lambda via an IAM-based integration.
  • Lambda runs in a sandbox with its own memory/timeout/concurrency; you pay per request and GB-seconds.
  • SQS buffers work for asynchronous consumers; DLQs catch poisoned messages for repair.
  • SNS/EventBridge fan out one event to many subscribers with filtering rules.
  • Step Functions coordinates stateful flows with retries, timeouts and human-approval steps.
  • Permissions are role-based: API Gateway assumes an execution role to invoke Lambda; Lambda assumes roles to reach DynamoDB/S3.

The canonical serverless payment/order flow.

Client
API Gateway
Lambda (order)
DynamoDB
SQS queue
Lambda (worker)
Real world

In production

  • A checkout endpoint validates via Lambda, records in DynamoDB, and enqueues an invoice job to SQS consumed by a worker Lambda.
  • EventBridge rules route 'order.created' to audit, analytics and notification subscribers independently.
  • Step Functions runs a 12-step refund flow with retries, compensating steps and a log for every transition.
Guidelines

Best practices

  • Keep functions small, stateless and idempotent; let storage own the state.
  • Use queues for anything that doesn't need a synchronous answer, with a DLQ.
  • Set Lambda reserved concurrency to protect downstream databases from fan-out.
  • Enable X-Ray/structured logging and tag functions for cost attribution.
Watch out

Common mistakes

  • Putting VPC-attached Lambdas without NAT/endpoints, breaking internet access.
  • Synchronous calls between services that should be queued — a spike becomes a timeout storm.
  • Fat functions (500MB zips, cold npm trees) inflating cold starts.
  • Forgetting idempotency: retries replay side effects unless you dedupe.
Root cause analysis

Common issues

Error
API Gateway returns 504 repeatedly
Root cause

Lambda integration timed out (sync integration waits) or function over memory

Fix

Increase Lambda timeout/memory or go async via SQS for long-running work.

Error
Lambda can't reach an RDS instance
Root cause

Function in VPC lacks route to the DB SG or VPC placement

Fix

Attach the function to the same VPC/subnets as RDS and allow the DB SG to accept from Lambda SG.

Error
Messages reprocessed twice after crash
Root cause

SQS at-least-once semantics and non-idempotent handler

Fix

Make consumers idempotent (dedupe key in DynamoDB) before relying on retries.

When things break

Debugging tips

  • Check CloudWatch Logs group per function and the X-Ray trace for Init vs runtime time.
  • For throttled invocations, check concurrency limits and reserved concurrency rather than code.
  • SQS messages stuck? Inspect the DLQ and the message attributes/handlers.
  • API returns 429/403? Look at usage plans, authorizers and the execution role.
Interviews

Interview checkpoint

Practice

Hands-on lab

Deploy a Hello-World Lambda End-to-End
30 min · intermediate
In progress
Objectives
  • Create and deploy a Lambda function
  • Invoke it directly and confirm the result
  • Identify the IAM execution role and log group created

Deploy a Hello-World Lambda End-to-End

30 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which service lets Lambda process messages reliably when downstream is slow?

2

A Lambda in a VPC can always reach the public internet by default.

Go deeper

Official documentation

AWS — Lambda developer guide
docs
AWS — API Gateway developer guide
docs
AWS — Step Functions
docs