Skip to main content
In this lesson we cover AWS Lambda and serverless patterns that improve availability, fault tolerance, and operational resilience. At a high level, AWS Lambda is a serverless, event-driven compute service. Functions are invoked by events or requests, perform work, then return or persist results. Common triggers include S3 object events, API Gateway, EventBridge, CloudWatch events, SNS, and SQS. A frequent pattern is an HTTP API exposed by API Gateway that invokes Lambda, which then reads from or writes to DynamoDB.
A simple AWS serverless workflow diagram titled "Lambda – API Workflow" showing users calling Amazon API Gateway, which invokes a Lambda function that interacts with Amazon DynamoDB. Icons and arrows illustrate the flow from users → API Gateway → Lambda → DynamoDB.
API Gateway is a natural insertion point for resiliency controls: throttling, usage plans, rate limiting, caching, WAF, and request validation. It effectively acts as a load balancer/abstraction in front of Lambda and can reduce load and failure surface for your functions. Lambda integrates tightly with monitoring and alerting. CloudWatch emits metrics and alarms that can trigger EventBridge rules, invoke another Lambda, or publish to SNS for operator notifications.
A slide titled "Lambda – Monitoring and Alerting Workflow" showing icons for Amazon CloudWatch, an AWS Lambda function, and Amazon SNS connected by arrows. It illustrates CloudWatch triggering a Lambda which then sends alerts via SNS.
Key Lambda characteristics
A presentation slide titled "Features" showing five numbered cards labeled Serverless, Event-driven, Language Support, Fault Tolerance, and Automatic Scaling, each with a colorful circular icon. The cards are arranged horizontally across the slide.
Resiliency patterns and operational details
  1. Versioning and Aliases — safe deployments and instant rollbacks
  • Lambda supports immutable versions and mutable aliases. Publish a version (for example v1, v2) and point an alias (for example checkout-prod) at a version.
  • Aliases support traffic shifting so you can perform canary or blue/green deployments. Example: keep 90% of traffic on v1 and route 10% to v2 to validate behavior in production. Monitor error rates and latency, then switch to 100% when confident. If problems occur, point the alias back to v1 for an immediate rollback.
A diagram showing AWS Lambda versioning and aliases for resilience: a Lambda function with labeled versions V1 and V2 and an alias "checkout-prod" that routes 90% of traffic to V1 and 10% to V2. The function handles cart validation, payment processing, and order confirmation.
  1. Decoupling with queues (SQS) and asynchronous processing
  • Decoupling user-facing requests from background work improves responsiveness and resilience. Example flow: a seller uploads a product image to S3; S3 can publish an event to an SQS queue (or EventBridge/SNS), and a Lambda function consumes messages from SQS to process the image (resize, watermark, store optimized version). The upload returns quickly; image processing is handled asynchronously.
A diagram titled "Asynchronous Invocation" showing sellers upload product images to an S3 bucket, which places a message on an SQS queue. A Lambda function pulls the job and processes the images (resizes, adds watermarks, saves optimized versions).
Retry and failure semantics — quick reference
Asynchronous vs SQS semantics differ: asynchronous Lambda retries are handled by the Lambda service (use DLQ/destinations), while SQS retries are controlled by SQS visibility timeouts and the queue’s redrive policy.
  1. Automatic retries and Dead-Letter Queues (DLQs)
  • Built-in retry behavior gives basic fault tolerance. For more robust handling, combine retries with DLQs and notifications (SNS) so operators can be alerted to examine and reprocess failures. Use asynchronous invocation destinations for programmable failure routing.
  1. Cold starts, warm starts, and concurrency
  • Execution phases: container initialization (cold start), runtime initialization, and handler invocation. Cold starts add latency because a new execution environment must be provisioned and code loaded.
  • Lambda scales by provisioning execution environments; N concurrent requests may require up to N environments (subject to account concurrency limits).
  • The regional default concurrent execution limit is typically 1,000 (check current AWS quotas). If you require higher concurrency, request a quota increase.
  • Provisioned Concurrency keeps a pool of initialized execution environments ready to handle traffic and reduces cold-start latency. Note that this incurs additional cost.
  • Reserved Concurrency sets a maximum concurrency for a function or reserves part of the account concurrency for it, useful for limiting noisy neighbors or protecting downstream resources.
A timeline diagram titled "Lambda Function Scaling" that shows numbered requests and bars labeled "Init" and "Invoke" across time markers (t1–t6). It illustrates how Lambda instances initialize and handle concurrent requests, with a concurrent-requests count along the bottom.
  1. Mitigating cold-start latency
  • Use Provisioned Concurrency for latency-sensitive workloads and schedule capacity ahead of known traffic spikes.
  • Warm-up techniques (periodic invocations) are sometimes used, but Provisioned Concurrency is the supported, reliable method to guarantee warm environments.
A slide showing an AWS Lambda "Cold Start" flow: a trigger calls AWS Lambda, which during the cold period downloads the code, starts a new container, loads the runtime, and then executes the function.
A slide titled "Mitigation with Provisioned Concurrency" showing a flow: a trigger (lightning bolt) points to an AWS Lambda icon, then to a "Warm Instance" box, and finally to the Lambda function being invoked. It illustrates using provisioned concurrency to keep a warm Lambda instance ready for invocation.
Provisioned Concurrency reduces cold starts but increases cost because you pay for pre-initialized capacity. Use it selectively for critical, latency-sensitive functions and schedule scaling to match traffic patterns.
  1. VPC access and Elastic Network Interfaces (ENIs)
  • Lambda can run inside your VPC to access resources such as RDS, ElastiCache, or internal services. When configured for a VPC, Lambda creates ENIs in the specified subnets so the function can reach VPC resources.
  • For high availability and better scaling, configure multiple private subnets across multiple Availability Zones (one or more subnets per AZ). This allows Lambda to create ENIs in each AZ and improves resilience.
  • AWS manages ENIs for Lambda. Historically, ENI creation added cold-start overhead; platform improvements have reduced this, but VPC configuration can still affect cold-start times and scaling behavior.
A diagram titled "Lambda inside a VPC" showing an AWS VPC with a Lambda function in one private subnet connecting via an Elastic Network Interface to an Amazon RDS instance in another private subnet (both shown in AZ1).
  1. Regional availability and multi-AZ behavior
  • Lambda is a regional service and AWS operates it across multiple Availability Zones for durability and availability. You do not need to place functions in specific AZs: Lambda runs across the region and uses multiple AZs automatically.
  • If your function uses VPC subnets, provide subnets in multiple AZs so Lambda can create ENIs across them and maintain network reachability and availability.
A diagram titled "Scaling with High Availability in VPC" showing the AWS Cloud split into three Availability Zones, each running Lambda service instances. An AZ health check across the zones marks zones as healthy or unhealthy to illustrate high-availability scaling.
Best practices and checklist
  • Use versioning and aliases for safe, incremental deployments and instant rollbacks.
  • Decouple user-facing operations from background processing using SQS, SNS, or EventBridge to improve responsiveness and fault isolation.
  • Configure retries, DLQs, and notification workflows to ensure failures are captured and surfaced to operators.
  • Understand cold starts vs. warm starts; use Provisioned Concurrency for predictable low-latency responses.
  • When running Lambdas in a VPC, configure subnets across multiple AZs to improve availability and allow network access to your resources.
  • Monitor Lambda metrics (invocations, errors, duration, throttles, concurrent executions) in CloudWatch and create alarms for operational thresholds.
Exam tip: architectures that show S3 → SQS → Lambda (async processing), versioned Lambda aliases with traffic-shifting (canary rollouts), or Provisioned Concurrency for latency-sensitive workloads are common scenarios — understand the retry and DLQ semantics for each.
Links and references This concludes the lesson on Lambda resiliency and serverless high availability.

Watch Video