Top 58 AWS Interview Questions & Answers

AWS Lambda lets you upload code (as a ZIP package or a container image up to 10GB) in a supported runtime (Python, Node.js, Java, .NET, Go, Ruby, or a custom runtime) and have AWS run it automatically whenever a configured event occurs, without you provisioning or managing any servers.

The three core building blocks are:

1. The function — your actual code plus a handler entry point that AWS invokes with an event payload and a context object (containing metadata like the remaining execution time and request ID).

2. A trigger (event source) — the thing that invokes the function: an API Gateway request, an S3 object upload, a DynamoDB stream update, an SQS message, an EventBridge scheduled rule or event pattern, and dozens of other AWS services can all act as triggers.

3. An IAM execution role — a role that Lambda assumes on your function's behalf, defining exactly what other AWS resources and actions the function is allowed to perform (e.g., read from a specific S3 bucket, write to a specific DynamoDB table). This is separate from any permissions used to invoke the function itself, which are governed by resource-based policies on the function.

Lambda functions are inherently stateless between separate execution environments — you can't rely on in-memory data persisting across invocations, though AWS does opportunistically reuse a 'warm' execution environment for consecutive invocations, which is why connections initialized outside the handler (like a database client) can sometimes be reused, but should never be assumed to be guaranteed.

Current hard limits worth knowing: functions can run up to 15 minutes per invocation, use between 128 MB and 10,240 MB of memory (with CPU scaling proportionally, reaching a full vCPU at 1,769 MB), and the default account-wide concurrency limit is 1,000 concurrent executions per Region (a soft limit, raisable via a quota increase request).

API Gateway sits between clients (web apps, mobile apps, third-party integrators) and your backend compute (Lambda functions, containers on ECS/EKS, or even on-premises HTTP endpoints via VPC Link), acting as a fully managed reverse proxy layer. It handles a set of cross-cutting concerns that would otherwise need to be duplicated inside every individual backend service:

• Request routing — mapping specific paths and HTTP methods to specific backend targets (a specific Lambda function, an ECS service, etc.), effectively acting as the API's public contract independent of how the backend is actually implemented.

• Authentication and authorization — integrating with IAM, Amazon Cognito user pools, or custom Lambda authorizers to validate a caller's identity and permissions before a request ever reaches your business logic.

• Throttling and rate limiting — protecting backend services from being overwhelmed by enforcing per-client or per-API request rate limits (via usage plans and API keys), which is also a critical mechanism for staying within Lambda's account-wide concurrency limits.

• Request/response transformation — mapping between the shape of data a client sends and the shape your backend expects, without requiring backend code changes for minor API contract differences.

• Built-in observability — automatic integration with CloudWatch for metrics, logs, and (via X-Ray) distributed tracing across the request path.

AWS offers two main API Gateway types: REST APIs (the original, more feature-rich option, supporting request validation, API keys, and usage plans) and HTTP APIs (a newer, lower-latency, lower-cost option covering the most common use cases but with a slightly reduced feature set) — the choice between them typically comes down to whether you need REST API's more advanced features or HTTP API's better price/performance for simpler use cases.

When a Lambda function is invoked and there's no existing 'warm' execution environment available to handle it (either because it's the very first invocation, or because incoming traffic has scaled beyond the currently warm environments, or because an idle environment was recycled after a period of inactivity), AWS must provision a brand new execution environment before your code can run. This involves several steps: allocating a Firecracker microVM, downloading and mounting your deployment package or container image, starting the language runtime, and then running your initialization code (anything outside your handler function, like establishing a database connection or loading a large library) — only after all of that completes does your actual handler code run for the first time.

All of this added latency, beyond just executing your handler logic, is the 'cold start.' For lightweight interpreted runtimes like Python or Node.js, this has historically been in the 100-500ms range; JVM-based runtimes like Java were historically much worse (often several seconds) due to the JVM's own startup and class-loading overhead.

Once an execution environment is initialized, AWS keeps it 'warm' for a period and reuses it for subsequent invocations, skipping the initialization steps entirely — this is why cold starts are the exception, not the norm, for functions receiving steady traffic; AWS's own production data indicates cold starts occur in under 1% of invocations for typical workloads.

Cold starts matter most for latency-sensitive, synchronous, user-facing request paths (like an API Gateway-fronted endpoint a user is actively waiting on), and matter far less for asynchronous or batch workloads (like processing an SQS queue or an S3 event) where an extra few hundred milliseconds is inconsequential.

API Gateway sits between clients (web apps, mobile apps, third-party integrators) and your backend compute (Lambda functions, containers on ECS/EKS, or even on-premises HTTP endpoints via VPC Link), acting as a fully managed reverse proxy layer. It handles a set of cross-cutting concerns that would otherwise need to be duplicated inside every individual backend service:

• Request routing — mapping specific paths and HTTP methods to specific backend targets (a specific Lambda function, an ECS service, etc.), effectively acting as the API's public contract independent of how the backend is actually implemented.

• Authentication and authorization — integrating with IAM, Amazon Cognito user pools, or custom Lambda authorizers to validate a caller's identity and permissions before a request ever reaches your business logic.

• Throttling and rate limiting — protecting backend services from being overwhelmed by enforcing per-client or per-API request rate limits (via usage plans and API keys), which is also a critical mechanism for staying within Lambda's account-wide concurrency limits.

• Request/response transformation — mapping between the shape of data a client sends and the shape your backend expects, without requiring backend code changes for minor API contract differences.

• Built-in observability — automatic integration with CloudWatch for metrics, logs, and (via X-Ray) distributed tracing across the request path.

AWS offers two main API Gateway types: REST APIs (the original, more feature-rich option, supporting request validation, API keys, and usage plans) and HTTP APIs (a newer, lower-latency, lower-cost option covering the most common use cases but with a slightly reduced feature set) — the choice between them typically comes down to whether you need REST API's more advanced features or HTTP API's better price/performance for simpler use cases.

When a Lambda function is invoked and there's no existing 'warm' execution environment available to handle it (either because it's the very first invocation, or because incoming traffic has scaled beyond the currently warm environments, or because an idle environment was recycled after a period of inactivity), AWS must provision a brand new execution environment before your code can run. This involves several steps: allocating a Firecracker microVM, downloading and mounting your deployment package or container image, starting the language runtime, and then running your initialization code (anything outside your handler function, like establishing a database connection or loading a large library) — only after all of that completes does your actual handler code run for the first time.

All of this added latency, beyond just executing your handler logic, is the 'cold start.' For lightweight interpreted runtimes like Python or Node.js, this has historically been in the 100-500ms range; JVM-based runtimes like Java were historically much worse (often several seconds) due to the JVM's own startup and class-loading overhead.

Once an execution environment is initialized, AWS keeps it 'warm' for a period and reuses it for subsequent invocations, skipping the initialization steps entirely — this is why cold starts are the exception, not the norm, for functions receiving steady traffic; AWS's own production data indicates cold starts occur in under 1% of invocations for typical workloads.

Cold starts matter most for latency-sensitive, synchronous, user-facing request paths (like an API Gateway-fronted endpoint a user is actively waiting on), and matter far less for asynchronous or batch workloads (like processing an SQS queue or an S3 event) where an extra few hundred milliseconds is inconsequential.

AWS Lambda lets you upload code (as a ZIP package or a container image up to 10GB) in a supported runtime (Python, Node.js, Java, .NET, Go, Ruby, or a custom runtime) and have AWS run it automatically whenever a configured event occurs, without you provisioning or managing any servers.

The three core building blocks are:

1. The function — your actual code plus a handler entry point that AWS invokes with an event payload and a context object (containing metadata like the remaining execution time and request ID).

2. A trigger (event source) — the thing that invokes the function: an API Gateway request, an S3 object upload, a DynamoDB stream update, an SQS message, an EventBridge scheduled rule or event pattern, and dozens of other AWS services can all act as triggers.

3. An IAM execution role — a role that Lambda assumes on your function's behalf, defining exactly what other AWS resources and actions the function is allowed to perform (e.g., read from a specific S3 bucket, write to a specific DynamoDB table). This is separate from any permissions used to invoke the function itself, which are governed by resource-based policies on the function.

Lambda functions are inherently stateless between separate execution environments — you can't rely on in-memory data persisting across invocations, though AWS does opportunistically reuse a 'warm' execution environment for consecutive invocations, which is why connections initialized outside the handler (like a database client) can sometimes be reused, but should never be assumed to be guaranteed.

Current hard limits worth knowing: functions can run up to 15 minutes per invocation, use between 128 MB and 10,240 MB of memory (with CPU scaling proportionally, reaching a full vCPU at 1,769 MB), and the default account-wide concurrency limit is 1,000 concurrent executions per Region (a soft limit, raisable via a quota increase request).

An AZ consists of one or more discrete data centers with redundant power, networking, and connectivity, physically separated from other AZs in the same Region by a meaningful distance (often many kilometers) to avoid correlated failures like a single power grid outage or flood, but close enough (connected via high-bandwidth, low-latency private fiber, typically under 2ms) to support synchronous replication.

This design lets you build HA architectures without the latency penalty of cross-region replication. By deploying resources across at least two, ideally three, AZs, you protect against the most common category of cloud outage: a localized data center issue (power, cooling, or network failure) rather than a full regional disaster.

Most core AWS services are AZ-aware by design — Auto Scaling Groups can span AZs, RDS Multi-AZ places a standby in a second AZ, and ALBs distribute traffic across targets in multiple AZs. The architectural best practice is: never deploy production workloads in only one AZ, since that reintroduces a single point of failure at the data center level.

A health check is an automated, repeated test — commonly an HTTP GET to a specific endpoint (e.g., /health), a TCP connection attempt, or a custom script — that determines whether a resource (an EC2 instance, a container, a database endpoint) is capable of correctly serving traffic.

Health checks are the sensory layer of HA systems: without them, a load balancer or DNS service has no way of knowing a backend has failed, and would keep sending traffic into a black hole. Once a resource fails a configured number of consecutive checks (the 'unhealthy threshold'), the system responsible — an ALB target group, an Auto Scaling Group, or Route 53 — marks it unhealthy and reroutes traffic elsewhere.

There's an important design trade-off in how you write the health check endpoint itself: a 'shallow' health check that just returns 200 OK from the web server tells you the process is running but says nothing about whether it can actually reach its database or downstream dependencies. A 'deep' health check that verifies critical dependencies gives a much more accurate signal but risks marking an instance unhealthy due to a transient downstream blip, potentially causing unnecessary flapping. Most production systems use a middle ground: check the dependencies that are truly required for that specific instance to function, but avoid checking dependencies shared by the whole fleet (since that would take down every instance simultaneously).

A load balancer sits in front of a fleet of backend resources (EC2 instances, containers, Lambda functions) and distributes incoming requests according to an algorithm — round robin, least outstanding requests, or weighted distribution. In AWS, the main options are the Application Load Balancer (Layer 7, HTTP/HTTPS-aware, supports path/host-based routing), the Network Load Balancer (Layer 4, ultra-low latency, handles millions of requests per second and static IPs), and the Gateway Load Balancer (for third-party virtual appliances).

For HA specifically, the load balancer does three critical jobs: (1) it spreads load across multiple AZs so a single AZ failure doesn't take down the whole service, (2) it continuously runs health checks and automatically stops routing to unhealthy targets, and (3) it itself is deployed redundantly — AWS-managed load balancers are inherently multi-AZ and horizontally scaled behind the scenes, so the load balancer itself isn't a SPOF (unlike a self-managed nginx box would be).

A subtlety worth knowing: by default, ALBs and NLBs distribute traffic evenly across AZs regardless of how many healthy targets are in each AZ, unless you enable cross-zone load balancing, which spreads traffic evenly across all targets regardless of which AZ they're in. If AZs have unequal target counts and cross-zone is off, some instances can end up significantly more loaded than others.

Auto Scaling is most commonly framed as a cost/performance tool — scale out during traffic spikes, scale in during quiet periods — but it plays an equally important HA role that's easy to overlook: self-healing.

An Auto Scaling Group (ASG) continuously monitors the health of its instances (via EC2 status checks and, if attached, ELB health checks). If an instance fails a health check — whether due to a crash, a kernel panic, or simply being unreachable — the ASG automatically terminates it and launches a replacement, without any human intervention, restoring the group back to its desired capacity. This happens completely independent of scaling activity; even at a flat desired capacity of 4, if one instance dies, the ASG immediately launches a 5th... no wait, it terminates the unhealthy one and launches a new one to get back to 4.

For HA, this means your fleet is self-repairing: a hardware fault, an unresponsive process, or even someone accidentally terminating an instance is corrected automatically within minutes, without needing an on-call engineer to notice and intervene. Combined with launching across multiple AZs, this gives you both horizontal fault tolerance (multiple instances) and automatic recovery (replacement of failed ones) — two of the three pillars of HA, the third being fast traffic rerouting via the load balancer.

Building a secure, production-grade authentication system from scratch (handling password hashing, account recovery, multi-factor authentication, social/enterprise identity federation, and compliance requirements) is a substantial, security-critical undertaking that most application teams shouldn't have to reimplement themselves — this is a classic Backend-as-a-Service (BaaS) use case.

Amazon Cognito provides two related but distinct capabilities: User Pools, which are fully managed user directories handling sign-up, sign-in, password policies, multi-factor authentication, and federation with external identity providers (Google, Facebook, corporate SAML/OIDC providers) — after a successful login, a User Pool issues standard JSON Web Tokens (JWTs): an ID token (containing user identity claims), an access token (used to authorize API calls), and a refresh token (used to obtain new tokens without requiring the user to log in again). And Identity Pools (Federated Identities), which take those authenticated (or even unauthenticated/guest) identities and exchange them for temporary AWS IAM credentials, letting your application's client-side code directly and securely access specific AWS resources (like uploading directly to a specific S3 prefix) without routing every single interaction through a backend API.

In a typical serverless architecture, the integration flow looks like: a client authenticates against a Cognito User Pool and receives a JWT; that JWT is included in subsequent API calls to API Gateway; API Gateway is configured with a Cognito User Pool authorizer (or a custom Lambda authorizer that validates the JWT), which automatically validates the token's signature and expiration before the request is ever allowed to reach your backend Lambda function — meaning your actual business logic code never has to implement token validation itself, since that concern is handled entirely at the API Gateway layer.

Cognito also supports fine-grained authorization patterns beyond simple authentication, such as custom claims embedded in tokens (e.g., a user's role or tenant ID, usable by downstream authorization logic) and integration with AWS's broader IAM permission model via Identity Pools for scenarios needing direct, secure client-side access to specific AWS resources.

Function-as-a-Service (FaaS) — exemplified by AWS Lambda, Azure Functions, and Google Cloud Functions — lets you deploy your own custom application logic as discrete functions that the platform runs on demand in response to triggers, fully managing the compute infrastructure underneath. You still write real code; the platform just eliminates the server management aspect of running it.

Backend-as-a-Service (BaaS) goes a step further: entire categories of backend functionality are offered as fully managed, ready-to-use services that you integrate with (often directly from client-side code) rather than build yourself. Common BaaS examples on AWS include Amazon Cognito (user authentication and management — sign-up, sign-in, MFA, social login, all without writing your own auth service), DynamoDB or Amazon Aurora Serverless (managed databases you interact with directly), Amazon S3 (managed object storage), and AWS AppSync (managed GraphQL APIs with built-in real-time subscriptions and offline sync).

In practice, most real-world 'serverless' applications combine both models: FaaS (Lambda) for custom business logic that's specific to your application, and BaaS (Cognito, DynamoDB, S3, AppSync) for common, well-solved backend capabilities that don't need custom implementation. This combination lets teams focus their engineering effort on the actual differentiated business logic, while offloading undifferentiated, commodity backend capabilities entirely to managed services — sometimes reducing the amount of custom backend code needed by a significant margin compared to building every capability in-house.

Amazon SQS (Simple Queue Service) is a fully managed message queue: a producer service sends messages to a queue, and one or more consumer services poll that queue to retrieve and process messages, entirely decoupled in time from the producer. The producer doesn't need the consumer to be available at the moment it sends a message — SQS durably stores the message until a consumer is ready to process it, which is exactly what lets services fail independently without directly cascading failures onto each other.

SQS offers two queue types: Standard queues (near-unlimited throughput, at-least-once delivery, best-effort ordering — meaning duplicates and out-of-order delivery are both possible) and FIFO queues (strict ordering and exactly-once processing within a message group, at a lower throughput ceiling, useful when order genuinely matters, like sequential financial transactions for one account).

When a consumer retrieves a message, it becomes temporarily invisible to other consumers (the 'visibility timeout') while being processed; if the consumer successfully processes it, it explicitly deletes the message from the queue. If the consumer crashes or fails to delete it in time, the message becomes visible again and is redelivered — this is the mechanism behind at-least-once delivery, and why consumers must be designed to be idempotent (safely handle the same message being processed more than once).

A Dead Letter Queue (DLQ) is a separate SQS queue configured as the destination for messages that have failed processing a specified number of times (the 'maxReceiveCount'). Instead of a poison-pill message (one that will never successfully process, due to a bug or malformed data) being retried indefinitely and clogging the main queue — potentially blocking or slowing down processing of legitimately good messages behind it — it's automatically routed to the DLQ after exceeding the retry threshold, where it can be inspected, alerted on, and manually reprocessed or discarded once the underlying issue is fixed, without disrupting normal queue processing.

These three AWS messaging services solve overlapping but distinct problems, and choosing the right one is a common architecture decision:

Amazon SQS is fundamentally a queue: messages sit there until a consumer polls and processes them. It's a point-to-point (or point-to-multiple-competing-consumers) pattern — if multiple consumers poll the same queue, each individual message is only delivered to and processed by one of them (they compete for messages), which is ideal for distributing work across a pool of workers, like processing image uploads across a fleet of Lambda functions.

Amazon SNS is a pub/sub (publish/subscribe) service: a publisher sends a message to a topic, and SNS immediately pushes a copy of that message to every subscriber (SQS queues, Lambda functions, HTTP endpoints, email, SMS) subscribed to that topic. Unlike SQS, the same message is broadcast to every subscriber, not competed over — useful when multiple, independent services all need to react to the same event (e.g., 'OrderPlaced' needs to trigger email confirmation, inventory update, and analytics recording, all independently).

Amazon EventBridge is a more advanced event bus, purpose-built for event-driven architectures at scale. It supports content-based filtering via event pattern rules (route only events matching specific criteria — e.g., only 'OrderPlaced' events where the total is over $500 — to a specific target), integrates with dozens of AWS services and SaaS partners as event sources out of the box (via EventBridge's Schema Registry and partner integrations), and supports schema discovery/validation to help manage event contract evolution over time.

A common pattern combines them: EventBridge or SNS as the initial fan-out/routing layer (deciding which services care about an event), feeding into SQS queues in front of each individual consumer (giving each consumer its own durable buffer, backpressure handling, and retry/DLQ semantics) — this 'fan-out to SQS' pattern (SNS-to-SQS or EventBridge-to-SQS) is extremely common precisely because it combines pub/sub's broadcast capability with SQS's reliable, individually-buffered consumption model.

When a business process involves multiple steps that must happen in a specific sequence — possibly with conditional branching, parallel execution, waiting periods, and different error-handling behavior per step — implementing that coordination logic by hand (e.g., a single giant Lambda function calling other Lambdas, or a complex web of SNS/SQS chains) becomes hard to reason about, test, and observe as complexity grows.

AWS Step Functions solves this by letting you define the entire workflow declaratively as a state machine (using Amazon States Language, a JSON-based DSL, often visualized as a flowchart in the console), where each state can invoke a Lambda function, call another AWS service directly (Step Functions has native, non-Lambda integrations with over 200 AWS services, like directly starting an ECS task, calling DynamoDB, or invoking Bedrock, without needing a Lambda function purely to make the API call), branch based on conditions (Choice states), run steps in parallel (Parallel states) or iterate over an array of items (Map states, including a distributed Map mode for very large-scale parallel processing), wait for a specified time or an external callback (Wait/Task Token patterns, useful for human-approval steps or long-running external processes), and specify retry and catch behavior per individual step, with configurable backoff.

This gives you several concrete benefits over hand-rolled orchestration: built-in visual monitoring of exactly which step an in-progress execution is on and its full history (invaluable for debugging a stuck or failed workflow), centralized error handling and retry logic instead of scattering try/catch and retry code across many Lambda functions, and native support for long-running processes (Standard Workflows support executions up to one year, well beyond Lambda's 15-minute limit, by having Step Functions itself manage state between and across the individual, short-lived function invocations that make up the overall workflow).

Step Functions offers two workflow types: Standard (exactly-once execution semantics, full execution history, up to one year duration, priced per state transition) and Express (at-least-once execution semantics, optimized for high-volume, short-duration workloads, priced by execution duration and count rather than per transition) — the choice depends on whether you need Standard's auditability and long-duration support, or Express's higher throughput and lower cost for high-volume, short-lived workflows.

Lambda supports three fundamental invocation models, though the two most important to distinguish are synchronous and asynchronous:

Synchronous invocation (e.g., a Lambda called directly by API Gateway, an ALB, or an SDK RequestResponse call) means the caller sends the event and blocks, waiting for Lambda to finish executing and return a response before proceeding. If the function throws an error or times out, that failure is returned directly to the caller in real time — the caller (e.g., API Gateway) is fully responsible for deciding what to do about it (return an error to the end user, retry, etc.). Lambda itself does not automatically retry synchronous invocations on your behalf.

Asynchronous invocation (triggered by event sources like S3, SNS, or EventBridge, or explicit Event invocation type) means the caller hands off the event to Lambda's internal queue and immediately gets an acknowledgment that the event was accepted — the caller does not wait for the function to actually finish processing. Lambda then processes the event from its internal queue in the background. Critically, if the function fails, Lambda automatically retries the invocation (by default, up to 2 additional times, with a delay between attempts), completely independent of and invisible to the original caller. If all retries are exhausted and the function still fails, the event can be routed to a configured on-failure destination (an SQS queue, SNS topic, another Lambda function, or EventBridge bus) or a legacy Dead Letter Queue configuration, so the failed event isn't silently dropped.

A third model, event source mapping (used for poll-based sources like SQS, DynamoDB Streams, and Kinesis), is technically a distinct mechanism from both: Lambda's internal poller reads batches of records from the source and invokes your function synchronously per batch, but failures are handled according to the source's own semantics — for SQS specifically, a failed batch causes the relevant messages to become visible again in the SQS queue itself (governed by the queue's own visibility timeout and redrive policy/DLQ, rather than Lambda's own async retry/destination mechanism).

Understanding which model applies to a given trigger is essential for correct error-handling design: assuming an async-style automatic retry exists for a synchronous, API Gateway-fronted function (or vice versa) is a common source of production bugs around silently lost or unexpectedly duplicated processing.

Function-as-a-Service (FaaS) — exemplified by AWS Lambda, Azure Functions, and Google Cloud Functions — lets you deploy your own custom application logic as discrete functions that the platform runs on demand in response to triggers, fully managing the compute infrastructure underneath. You still write real code; the platform just eliminates the server management aspect of running it.

Backend-as-a-Service (BaaS) goes a step further: entire categories of backend functionality are offered as fully managed, ready-to-use services that you integrate with (often directly from client-side code) rather than build yourself. Common BaaS examples on AWS include Amazon Cognito (user authentication and management — sign-up, sign-in, MFA, social login, all without writing your own auth service), DynamoDB or Amazon Aurora Serverless (managed databases you interact with directly), Amazon S3 (managed object storage), and AWS AppSync (managed GraphQL APIs with built-in real-time subscriptions and offline sync).

In practice, most real-world 'serverless' applications combine both models: FaaS (Lambda) for custom business logic that's specific to your application, and BaaS (Cognito, DynamoDB, S3, AppSync) for common, well-solved backend capabilities that don't need custom implementation. This combination lets teams focus their engineering effort on the actual differentiated business logic, while offloading undifferentiated, commodity backend capabilities entirely to managed services — sometimes reducing the amount of custom backend code needed by a significant margin compared to building every capability in-house.

Amazon SQS (Simple Queue Service) is a fully managed message queue: a producer service sends messages to a queue, and one or more consumer services poll that queue to retrieve and process messages, entirely decoupled in time from the producer. The producer doesn't need the consumer to be available at the moment it sends a message — SQS durably stores the message until a consumer is ready to process it, which is exactly what lets services fail independently without directly cascading failures onto each other.

SQS offers two queue types: Standard queues (near-unlimited throughput, at-least-once delivery, best-effort ordering — meaning duplicates and out-of-order delivery are both possible) and FIFO queues (strict ordering and exactly-once processing within a message group, at a lower throughput ceiling, useful when order genuinely matters, like sequential financial transactions for one account).

When a consumer retrieves a message, it becomes temporarily invisible to other consumers (the 'visibility timeout') while being processed; if the consumer successfully processes it, it explicitly deletes the message from the queue. If the consumer crashes or fails to delete it in time, the message becomes visible again and is redelivered — this is the mechanism behind at-least-once delivery, and why consumers must be designed to be idempotent (safely handle the same message being processed more than once).

A Dead Letter Queue (DLQ) is a separate SQS queue configured as the destination for messages that have failed processing a specified number of times (the 'maxReceiveCount'). Instead of a poison-pill message (one that will never successfully process, due to a bug or malformed data) being retried indefinitely and clogging the main queue — potentially blocking or slowing down processing of legitimately good messages behind it — it's automatically routed to the DLQ after exceeding the retry threshold, where it can be inspected, alerted on, and manually reprocessed or discarded once the underlying issue is fixed, without disrupting normal queue processing.

These three AWS messaging services solve overlapping but distinct problems, and choosing the right one is a common architecture decision:

Amazon SQS is fundamentally a queue: messages sit there until a consumer polls and processes them. It's a point-to-point (or point-to-multiple-competing-consumers) pattern — if multiple consumers poll the same queue, each individual message is only delivered to and processed by one of them (they compete for messages), which is ideal for distributing work across a pool of workers, like processing image uploads across a fleet of Lambda functions.

Amazon SNS is a pub/sub (publish/subscribe) service: a publisher sends a message to a topic, and SNS immediately pushes a copy of that message to every subscriber (SQS queues, Lambda functions, HTTP endpoints, email, SMS) subscribed to that topic. Unlike SQS, the same message is broadcast to every subscriber, not competed over — useful when multiple, independent services all need to react to the same event (e.g., 'OrderPlaced' needs to trigger email confirmation, inventory update, and analytics recording, all independently).

Amazon EventBridge is a more advanced event bus, purpose-built for event-driven architectures at scale. It supports content-based filtering via event pattern rules (route only events matching specific criteria — e.g., only 'OrderPlaced' events where the total is over $500 — to a specific target), integrates with dozens of AWS services and SaaS partners as event sources out of the box (via EventBridge's Schema Registry and partner integrations), and supports schema discovery/validation to help manage event contract evolution over time.

A common pattern combines them: EventBridge or SNS as the initial fan-out/routing layer (deciding which services care about an event), feeding into SQS queues in front of each individual consumer (giving each consumer its own durable buffer, backpressure handling, and retry/DLQ semantics) — this 'fan-out to SQS' pattern (SNS-to-SQS or EventBridge-to-SQS) is extremely common precisely because it combines pub/sub's broadcast capability with SQS's reliable, individually-buffered consumption model.

When a business process involves multiple steps that must happen in a specific sequence — possibly with conditional branching, parallel execution, waiting periods, and different error-handling behavior per step — implementing that coordination logic by hand (e.g., a single giant Lambda function calling other Lambdas, or a complex web of SNS/SQS chains) becomes hard to reason about, test, and observe as complexity grows.

AWS Step Functions solves this by letting you define the entire workflow declaratively as a state machine (using Amazon States Language, a JSON-based DSL, often visualized as a flowchart in the console), where each state can invoke a Lambda function, call another AWS service directly (Step Functions has native, non-Lambda integrations with over 200 AWS services, like directly starting an ECS task, calling DynamoDB, or invoking Bedrock, without needing a Lambda function purely to make the API call), branch based on conditions (Choice states), run steps in parallel (Parallel states) or iterate over an array of items (Map states, including a distributed Map mode for very large-scale parallel processing), wait for a specified time or an external callback (Wait/Task Token patterns, useful for human-approval steps or long-running external processes), and specify retry and catch behavior per individual step, with configurable backoff.

This gives you several concrete benefits over hand-rolled orchestration: built-in visual monitoring of exactly which step an in-progress execution is on and its full history (invaluable for debugging a stuck or failed workflow), centralized error handling and retry logic instead of scattering try/catch and retry code across many Lambda functions, and native support for long-running processes (Standard Workflows support executions up to one year, well beyond Lambda's 15-minute limit, by having Step Functions itself manage state between and across the individual, short-lived function invocations that make up the overall workflow).

Step Functions offers two workflow types: Standard (exactly-once execution semantics, full execution history, up to one year duration, priced per state transition) and Express (at-least-once execution semantics, optimized for high-volume, short-duration workloads, priced by execution duration and count rather than per transition) — the choice depends on whether you need Standard's auditability and long-duration support, or Express's higher throughput and lower cost for high-volume, short-lived workflows.

Lambda supports three fundamental invocation models, though the two most important to distinguish are synchronous and asynchronous:

Synchronous invocation (e.g., a Lambda called directly by API Gateway, an ALB, or an SDK RequestResponse call) means the caller sends the event and blocks, waiting for Lambda to finish executing and return a response before proceeding. If the function throws an error or times out, that failure is returned directly to the caller in real time — the caller (e.g., API Gateway) is fully responsible for deciding what to do about it (return an error to the end user, retry, etc.). Lambda itself does not automatically retry synchronous invocations on your behalf.

Asynchronous invocation (triggered by event sources like S3, SNS, or EventBridge, or explicit Event invocation type) means the caller hands off the event to Lambda's internal queue and immediately gets an acknowledgment that the event was accepted — the caller does not wait for the function to actually finish processing. Lambda then processes the event from its internal queue in the background. Critically, if the function fails, Lambda automatically retries the invocation (by default, up to 2 additional times, with a delay between attempts), completely independent of and invisible to the original caller. If all retries are exhausted and the function still fails, the event can be routed to a configured on-failure destination (an SQS queue, SNS topic, another Lambda function, or EventBridge bus) or a legacy Dead Letter Queue configuration, so the failed event isn't silently dropped.

A third model, event source mapping (used for poll-based sources like SQS, DynamoDB Streams, and Kinesis), is technically a distinct mechanism from both: Lambda's internal poller reads batches of records from the source and invokes your function synchronously per batch, but failures are handled according to the source's own semantics — for SQS specifically, a failed batch causes the relevant messages to become visible again in the SQS queue itself (governed by the queue's own visibility timeout and redrive policy/DLQ, rather than Lambda's own async retry/destination mechanism).

Understanding which model applies to a given trigger is essential for correct error-handling design: assuming an async-style automatic retry exists for a synchronous, API Gateway-fronted function (or vice versa) is a common source of production bugs around silently lost or unexpectedly duplicated processing.

An Availability Zone (AZ) is one or more physically distinct data centers within a Region, each with independent power, cooling, and networking, but connected by low-latency private fiber (typically sub-2ms). A Region is a geographically separate area (e.g., us-east-1, ap-south-1) containing multiple AZs.

Multi-AZ architecture: You deploy resources (EC2 instances, RDS with a standby replica, ALB targets) across at least two, ideally three, AZs. If one AZ suffers a power or network failure, traffic automatically shifts to healthy AZs via the load balancer, and RDS Multi-AZ triggers an automatic failover to the standby in another AZ (typically 60-120 seconds for a single-standby deployment, or under 35 seconds for the newer two-readable-standby cluster deployment). This is the default baseline for 'highly available' production workloads because AZ-to-AZ latency is low enough to run synchronous replication without hurting application performance.

Multi-Region architecture: Here you replicate infrastructure into a completely separate Region, often thousands of kilometers away. Because inter-region latency is much higher (50-150ms+), synchronous replication becomes impractical for most transactional databases, so teams use asynchronous replication (e.g., Aurora Global Database, DynamoDB Global Tables, S3 Cross-Region Replication). Multi-Region protects against catastrophic, correlated failures — a Region-wide outage, a natural disaster, or regulatory data-residency requirements that force you to serve users from a specific geography.

The trade-off is cost and complexity versus resilience: Multi-AZ is nearly 'free' resilience you should almost always enable, while Multi-Region roughly doubles infrastructure cost, introduces eventual consistency challenges, and requires DNS-based failover (Route 53 health checks) plus careful thought about split-brain scenarios and data reconciliation.

Under the hood, an ALB target group is configured with a health check path (e.g., /health), an interval (default 30s), a timeout, and healthy/unhealthy threshold counts (default 5 consecutive successes/failures). The ALB's fleet of nodes independently sends HTTP/HTTPS requests to each registered target on that path.

When an instance fails the threshold number of consecutive checks, its state transitions from 'healthy' to 'unhealthy' in the target group, and the ALB immediately excludes it from the routing algorithm (round-robin or least-outstanding-requests). Crucially, this doesn't happen instantly — there's a detection window equal to (interval × unhealthy threshold), so a poorly tuned health check (e.g., 30s interval, 5 failures) could mean up to 150 seconds of degraded traffic before failover completes. For latency-sensitive systems, teams tighten this to something like a 5-10s interval with a 2-3 failure threshold.

For in-flight requests: any request already routed to the now-unhealthy instance is not automatically retried by the ALB — it either times out or returns an error to the client, unless you've enabled connection draining (deregistration delay). When an instance is deliberately deregistered (e.g., during a deploy or scale-in), the ALB stops sending new requests to it but allows existing in-flight requests up to the deregistration delay (default 300s) to complete before forcibly closing the connection. Note this graceful draining only applies to deliberate deregistration, not sudden health-check failures like a crash — in a true crash, in-flight requests simply fail and it's the client or upstream retry logic's job to recover.

This is why resilient architectures pair ALB health checks with client-side or service-mesh retry policies, idempotent APIs, and reasonable timeouts, rather than relying on the load balancer alone to guarantee zero dropped requests.

Amazon RDS offers two distinct Multi-AZ topologies, and mixing them up is a common interview stumble.

Multi-AZ DB instance deployment (the original, broadly available option): one primary and one standby instance in a second AZ. The standby uses storage-level, synchronous replication and exists purely for failover — it cannot serve read traffic. Typical failover time is 60-120 seconds. This is available for virtually every RDS engine (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server).

Multi-AZ DB cluster deployment (newer, currently for MySQL and PostgreSQL): one primary plus two readable standby instances spread across three AZs. Replication here is at a lower, more efficient layer, giving up to 2x faster write/commit latency compared to the single-standby option, since it uses a quorum-based commit across the three instances rather than fully synchronous replication with one standby. Because both standbys are already active and readable, failover is typically well under 35 seconds, and you get built-in read scaling via a dedicated reader endpoint without needing to provision separate read replicas.

The trade-off: the DB cluster deployment costs more (three instances instead of two) and has engine-version restrictions, but is the better choice whenever you need faster failover, better write throughput, and free read-scaling in one package. The single-standby DB instance deployment remains the right default for engines it doesn't yet support (Oracle, SQL Server) or when cost is the primary constraint.

Route 53 supports several routing policies relevant to DR and multi-region HA, but the core mechanism is: you attach a Route 53 Health Check to each record (e.g., one per Region), which periodically probes an endpoint (HTTP/HTTPS/TCP) from a distributed set of AWS health checkers around the world. If enough checkers report failure, Route 53 marks that record unhealthy and stops including it in DNS responses.

The most common failover pattern is Failover Routing Policy: you designate a Primary and a Secondary record. As long as the primary passes its health check, Route 53 only returns the primary's IP/endpoint. If the primary fails its health check, Route 53 automatically starts returning the secondary's endpoint instead — enabling active-passive multi-region failover without any application-level logic.

Other relevant policies include Latency-based routing (send users to whichever healthy Region gives them the lowest latency, useful for active-active), Geolocation/Geoproximity routing (route based on user location or compliance needs), and Weighted routing (gradually shift a percentage of traffic, useful for canary-testing a new region).

The major caveat with any DNS-based failover is DNS caching (TTL) — resolvers and client OSes cache DNS answers for the record's TTL duration, so a failover isn't instantaneous for every client; some may keep hitting the dead endpoint until their local cache expires. Lower TTLs (e.g., 30-60s) speed up failover propagation but increase the volume of DNS queries (and cost) since caches expire more often. This is also why Route 53 Application Recovery Controller (ARC) exists for scenarios needing faster, more controlled failover than DNS TTLs alone can guarantee.

Amazon EBS (Elastic Block Store) provides block storage volumes that live within a single Availability Zone and attach to exactly one EC2 instance at a time (with the exception of Multi-Attach for a small set of io1/io2 volumes, limited to instances within the same AZ, mainly used for clustered applications). If the AZ hosting an EBS volume fails, the volume is unavailable until that AZ recovers — the standard mitigation is taking regular snapshots (which are stored durably in S3, spanning multiple AZs) so a new volume can be recreated in another AZ if needed.

Amazon EFS (Elastic File System) is a fully managed NFS file system built for multi-AZ availability out of the box. Data is redundantly stored across multiple AZs within a Region automatically (for the 'Standard' storage class), and any number of EC2 instances, containers, or Lambda functions across multiple AZs can mount the same file system concurrently. This makes EFS a natural fit for shared state that many compute nodes need to read/write simultaneously — content management systems, shared configuration, or home directories in an HPC cluster.

The availability trade-off maps directly to the use case: EBS is ideal for a single instance's dedicated, high-performance disk (like a database's data volume, especially when paired with Multi-AZ RDS which handles replication at the database layer instead), while EFS is ideal when the storage itself needs to survive an AZ failure and be simultaneously shared. EFS does cost more per GB and has different latency characteristics (network file system overhead) compared to EBS's directly-attached block storage.

The CAP theorem, formalized by Eric Brewer, states that a distributed data store can provide at most two of the following three guarantees simultaneously: Consistency (every read receives the most recent write or an error), Availability (every request receives a non-error response, without guarantee it contains the latest write), and Partition tolerance (the system continues operating despite network partitions between nodes).

In practice, because network partitions are an unavoidable reality in any distributed cloud system (a network blip between AZs or Regions will happen eventually), Partition tolerance isn't really optional — so the real, practical trade-off cloud architects face is between Consistency and Availability specifically during a partition event.

CP systems (Consistency + Partition tolerance) refuse to serve potentially stale reads or accept writes if they can't confirm consistency across nodes during a partition — they sacrifice availability to guarantee correctness. Traditional relational databases with synchronous replication (like RDS Multi-AZ) lean CP for the primary.

AP systems (Availability + Partition tolerance) keep serving reads and writes even during a partition, accepting that some nodes might temporarily return stale data — they sacrifice strict consistency for uptime. DynamoDB's eventually-consistent read mode and Cassandra are classic AP examples.

Modern cloud databases increasingly offer tunable consistency (like DynamoDB letting you choose eventually-consistent vs. strongly-consistent reads per request) so you're not locked into one side of the trade-off for the whole system — you can pick CP behavior for operations that need correctness (like a financial balance check) and AP behavior for operations that just need speed (like a product view counter).

By default, load balancers distribute each incoming request independently across the healthy backend fleet, which works well for stateless applications where any instance can handle any request. Sticky sessions (session affinity) change this by ensuring all requests from a given client are routed to the same backend instance for a configured duration, typically implemented via an ALB-generated cookie (duration-based) or an application-generated cookie the ALB reads (application-based).

Sticky sessions are commonly needed when an application stores session state in the local memory of the instance handling it (in-process session objects, local caches) rather than in a shared, external store. Without stickiness, a user's next request could hit a different instance that has no knowledge of their session, causing them to appear logged out or lose in-progress state.

The HA complication: if the specific instance a user is 'stuck' to becomes unhealthy or is terminated (during a deploy, a scale-in event, or a crash), that user's session is lost, and they have to establish a new sticky session with a different instance — essentially reintroducing a small-scale, per-user single point of failure that the load balancer's redundancy was supposed to eliminate. It also makes scaling and deployments trickier, since you can't freely redirect a 'stuck' user's traffic without disrupting their session.

The standard architectural fix is to make the application stateless at the instance level by externalizing session state to a shared, resilient store (like ElastiCache for Redis or DynamoDB) that all instances can read/write, so any instance can serve any request regardless of session history — eliminating the need for sticky sessions entirely and restoring true instance-level fault tolerance. Sticky sessions should generally be treated as a stopgap for legacy or hard-to-refactor applications, not a long-term architectural choice for new systems designed for HA.

An Availability Zone (AZ) is one or more physically distinct data centers within a Region, each with independent power, cooling, and networking, but connected by low-latency private fiber (typically sub-2ms). A Region is a geographically separate area (e.g., us-east-1, ap-south-1) containing multiple AZs.

Multi-AZ architecture: You deploy resources (EC2 instances, RDS with a standby replica, ALB targets) across at least two, ideally three, AZs. If one AZ suffers a power or network failure, traffic automatically shifts to healthy AZs via the load balancer, and RDS Multi-AZ triggers an automatic failover to the standby in another AZ (typically under 60-120 seconds). This is the default baseline for 'highly available' production workloads because AZ-to-AZ latency is low enough to run synchronous replication without hurting application performance.

Multi-Region architecture: Here you replicate infrastructure into a completely separate Region, often thousands of kilometers away. Because inter-region latency is much higher (50-150ms+), synchronous replication becomes impractical for most transactional databases, so teams use asynchronous replication (e.g., Aurora Global Database, DynamoDB Global Tables, S3 Cross-Region Replication). Multi-Region protects against catastrophic, correlated failures — a Region-wide outage, a natural disaster, or regulatory data-residency requirements that force you to serve users from a specific geography.

The trade-off is cost and complexity versus resilience: Multi-AZ is nearly 'free' resilience you should almost always enable, while Multi-Region roughly doubles infrastructure cost, introduces eventual consistency challenges, and requires DNS-based failover (Route 53 health checks) plus careful thought about split-brain scenarios and data reconciliation.

Under the hood, an ALB target group is configured with a health check path (e.g., /health), an interval (default 30s), a timeout, and healthy/unhealthy threshold counts (default 5 consecutive successes/failures). The ALB's fleet of nodes independently sends HTTP/HTTPS requests to each registered target on that path.

When an instance fails the threshold number of consecutive checks, its state transitions from 'healthy' to 'unhealthy' in the target group, and the ALB immediately excludes it from the routing algorithm (round-robin or least-outstanding-requests). Crucially, this doesn't happen instantly — there's a detection window equal to (interval × unhealthy threshold), so a poorly tuned health check (e.g., 30s interval, 5 failures) could mean up to 150 seconds of degraded traffic before failover completes. For latency-sensitive systems, teams tighten this to something like a 5-10s interval with a 2-3 failure threshold.

For in-flight requests: any request already routed to the now-unhealthy instance is not automatically retried by the ALB — it either times out or returns an error to the client, unless you've enabled connection draining (deregistration delay). When an instance is deliberately deregistered (e.g., during a deploy or scale-in), the ALB stops sending new requests to it but allows existing in-flight requests up to the deregistration delay (default 300s) to complete before forcibly closing the connection. Note this graceful draining only applies to deliberate deregistration, not sudden health-check failures like a crash — in a true crash, in-flight requests simply fail and it's the client or upstream retry logic's job to recover.

This is why resilient architectures pair ALB health checks with client-side or service-mesh retry policies, idempotent APIs, and reasonable timeouts, rather than relying on the load balancer alone to guarantee zero dropped requests.

When you configure an ASG with multiple subnets (each in a different AZ), AWS's default behavior is AZ Rebalancing: the ASG algorithm tries to keep the number of running instances roughly even across all specified AZs, recalculating on every scaling activity. If you have desired capacity of 6 across 3 AZs, it aims for 2 per AZ.

Under the hood, the ASG launches into the AZ with the fewest instances first, and if a scaling event or AZ-rebalance requires moving capacity, it launches replacement instances in a healthy AZ before terminating instances in an over-represented or degraded one — a 'launch before terminate' pattern designed to avoid ever having a capacity dip, though this can be influenced by termination policies (e.g., OldestInstance, ClosestToNextInstanceHour).

This matters enormously for fault tolerance because if an AZ becomes unhealthy or capacity-constrained, the ASG will avoid launching there and rebalance the fleet into the remaining healthy AZs — but only if your ASG's max capacity and the subnet's IP address space actually allow it. A common real-world failure mode is: an ASG configured across 3 AZs but with a max capacity only slightly above desired capacity, or subnets with too-small CIDR blocks. When one AZ goes down, the ASG cannot fit the displaced instances into the remaining AZs, so overall capacity effectively drops by a third even though you 'configured for HA.'

Another subtlety: if you only place your ASG in 2 AZs instead of 3, you're now n+1 exposed — losing one AZ removes 50% of your capacity, versus roughly 33% with 3 AZs. Interviewers often probe this because 'multi-AZ' isn't binary; the number and balance of AZs directly determines your blast radius per failure.

API Gateway supports several authorization mechanisms, and one of the most flexible is a Lambda authorizer (formerly called a 'custom authorizer'): a dedicated Lambda function that API Gateway invokes before routing a request to your actual backend integration. This authorizer function receives the incoming request's authorization data (either a bearer token, in the TOKEN type, or the full set of request headers/query parameters/context, in the REQUEST type) and is responsible for validating it — this could mean verifying a JWT's signature and claims, checking a token against an external identity provider, or any other custom logic — and returning an IAM policy document that explicitly allows or denies the request, optionally along with a context object (custom key-value data, like the authenticated user's ID or role) that gets passed through to the downstream backend integration, saving that integration from needing to re-derive that information itself.

This pattern is powerful specifically because it supports arbitrary, custom authorization logic beyond what API Gateway's built-in Cognito or IAM authorizers directly support — validating tokens from a third-party identity provider, implementing custom API key logic, or applying business-specific authorization rules that depend on data beyond just the token itself.

The performance consideration that matters significantly at scale: without caching, every single incoming request triggers a separate Lambda authorizer invocation before the actual backend logic even runs — adding real latency (an extra Lambda invocation, including potential cold-start cost) and real additional cost (you're now paying for two Lambda invocations per request instead of one) to every single API call. API Gateway addresses this with authorizer result caching: you can configure a TTL (up to 1 hour) during which API Gateway caches the authorization result for a given identity source value (e.g., the specific bearer token presented), so subsequent requests presenting that exact same token within the TTL window skip invoking the authorizer function entirely and reuse the cached allow/deny decision and context object.

The trade-off with caching is a security and freshness consideration: if a token is revoked, or a user's permissions change, the cached authorization decision could remain in effect (incorrectly allowing or denying requests) until the cache TTL expires — so the cache duration needs to be tuned as a genuine trade-off between performance/cost (longer cache = fewer authorizer invocations) and security freshness (shorter cache = faster reflection of permission or token-revocation changes), rather than simply maximizing the cache TTL for cost savings without considering this risk.

These two Lambda concurrency controls solve genuinely different problems and are frequently confused with each other, though they can also be used together.

Reserved Concurrency sets both a guaranteed minimum and a hard maximum on the number of concurrent executions a specific function can use, carved out of the account's total concurrency pool (default 1,000 per account per Region). Setting reserved concurrency to 100 for a critical function means: that function is always guaranteed up to 100 concurrent executions, regardless of how much concurrency other functions in the account are consuming (protecting it from being starved by a noisy-neighbor function elsewhere in the same account) — but it can also never exceed 100 concurrent executions, even if the rest of the account's concurrency pool is completely idle (acting as a hard throttle/ceiling, which can also be used deliberately to protect a downstream dependency, like a database, from being overwhelmed by too many simultaneous Lambda invocations). Setting a function's reserved concurrency to 0 effectively disables it entirely (useful as an emergency 'kill switch' during an incident). This is purely a concurrency-allocation mechanism — it has no effect on cold starts.

Provisioned Concurrency, in contrast, is specifically about eliminating cold starts: it keeps a specified number of execution environments pre-initialized and kept warm continuously (running your INIT code ahead of time, before any actual invocation arrives), so that requests routed to those pre-warmed environments experience no cold-start latency at all. This comes at a materially higher cost, structurally similar to paying for reserved, always-on compute capacity (you pay for provisioned environments whether or not they're actively handling a request at any given moment), unlike Lambda's standard pay-per-invocation pricing model.

The practical decision: use Reserved Concurrency when you need to guarantee a function has capacity available (protecting a critical function from being starved by others) or need to cap a function's maximum concurrency (protecting a downstream dependency, like preventing a Lambda function from ever opening more simultaneous connections to a database than it can handle). Use Provisioned Concurrency specifically when cold-start latency is genuinely unacceptable for a portion of your traffic — commonly for latency-sensitive, synchronous, user-facing APIs with a JVM-based runtime or heavy initialization logic (though note that SnapStart has substantially reduced the need for Provisioned Concurrency specifically for cold-start elimination on supported runtimes, making Provisioned Concurrency increasingly reserved for either unsupported runtimes or cases needing absolute latency guarantees beyond what SnapStart's snapshot-restore approach provides). They can be combined: setting Provisioned Concurrency as a subset of a function's Reserved Concurrency, guaranteeing a portion of always-warm capacity while still allowing some additional standard (cold-start-eligible) scaling beyond that provisioned baseline if traffic exceeds it.

Lambda's core scaling unit is 'concurrency' — the number of execution environments actively processing requests at any given moment. Each concurrent request needs its own execution environment; if 50 requests arrive at exactly the same instant and no warm environments exist yet, Lambda needs to (up to its scaling rate limits) launch up to 50 separate execution environments simultaneously.

There are two distinct limits that govern this, and conflating them is a common mistake:

1. The concurrency limit (default 1,000 per account per Region, a soft/raisable limit) caps the total number of execution environments that can be running across all your functions in that account and Region at once. Once you hit this ceiling, additional synchronous invocations are throttled (return a 429 error) and additional asynchronous invocations are retried according to Lambda's async retry policy rather than processed immediately.

2. The burst concurrency / scaling rate limit governs how quickly Lambda can add new concurrent execution environments in response to a sudden spike, independent of the overall concurrency ceiling. Historically, Lambda could burst by 500-3000 new concurrent executions in the first minute (varying by Region) and then scale by an additional 500 per minute after that, though AWS has continued to improve burst scaling behavior over time; the specific number matters less than the underlying principle that scaling isn't instantaneous even when you're well under your overall concurrency limit — there's a rate cap on how fast new capacity can spin up, not just a ceiling on total capacity.

A useful mental model, and the actual formula AWS documents for capacity planning: required concurrency = (requests per second) × (average duration per request in seconds). If your API handles 30,000 requests/second, each averaging 20ms, you actually only need 600 concurrent executions (30,000 × 0.02), which comfortably fits within the default 1,000 concurrency limit — even though the raw '30,000 requests per second' figure sounds alarming at first glance. This is why interview candidates should always compute actual required concurrency rather than reasoning from raw request-per-second numbers alone, since duration matters just as much as request rate.

Reserved concurrency (a per-function setting that carves out a guaranteed, and simultaneously capped, portion of the account's total concurrency for one specific function) and Provisioned Concurrency (pre-initialized, always-warm execution environments kept ready to serve traffic immediately, eliminating cold starts for that portion of capacity, at a materially higher cost — roughly comparable in structure to paying for reserved EC2 capacity) are the two knobs available for fine-tuning this behavior per function.

In a monolith, debugging a slow or failing request is relatively simple — a single process, a single log stream, and typically a single stack trace tells you exactly where things went wrong. In a microservices or serverless architecture, a single logical request might touch API Gateway, three or four different Lambda functions, a DynamoDB table, an SQS queue, and an external third-party API — each of these emits its own separate logs, with no inherent, automatic way to correlate 'this specific log line in Service C' with 'this specific incoming request that started in Service A' unless something explicitly ties them together.

Distributed tracing solves this by propagating a shared trace ID (and parent/child span IDs marking each individual hop's start/end time) through every service boundary a request crosses — typically via HTTP headers on synchronous calls, or embedded in the message payload/attributes for asynchronous calls through SQS/SNS/EventBridge. AWS X-Ray is AWS's managed distributed tracing service: it collects trace segments (data about the work done by a single service for a given request, including timing, errors, and downstream calls made) from instrumented services, and stitches them together into a single, unified 'service map' and timeline view showing exactly how long each hop in the request took, where errors occurred, and which specific downstream call in a long chain was actually the bottleneck.

Without this, engineers debugging a slow or failing distributed request are stuck manually correlating timestamps and request parameters across many completely separate log streams, hoping they're actually looking at logs from the same logical request — a slow, error-prone, and often practically infeasible process at any meaningful scale or traffic volume, especially when multiple similar requests are happening concurrently and their logs interleave.

X-Ray integrates natively with API Gateway, Lambda, and many other AWS services (auto-instrumenting much of the trace propagation without requiring code changes for AWS-to-AWS hops), and supports custom instrumentation via the X-Ray SDK for capturing details about your own application-level logic and calls to external, non-AWS dependencies. AWS Distro for OpenTelemetry (ADOT) offers a more open-standards-based alternative/complement, letting the same instrumented application send traces to X-Ray or to other observability backends (like a self-hosted or third-party tracing platform) without vendor lock-in to X-Ray's specific SDK.

SQS (and most distributed messaging systems) guarantee at-least-once delivery, not exactly-once — a message might be delivered to a consumer more than once in several realistic scenarios: the consumer successfully processes a message but crashes or times out before it can call DeleteMessage to remove it from the queue (so SQS reasonably assumes it wasn't processed and redelivers it after the visibility timeout expires); a network blip between the consumer and SQS drops the delete confirmation even though the delete actually succeeded server-side; or (for FIFO queues specifically, within the same message group) a batch retry re-delivers messages that were already successfully processed earlier in that same batch.

Because of this, any Lambda function processing SQS messages that has side effects (writing to a database, charging a payment, sending a notification) needs to be explicitly designed to handle duplicate deliveries safely — this is not an edge case to handle defensively 'just in case,' it's an expected, normal operating condition of the system.

The standard implementation pattern: extract a unique identifier from each message — either a natural business key already present in the message (like an order ID) or SQS's own MessageId attribute — and, before performing the actual side-effecting work, check a durable store (commonly a DynamoDB table with the message ID as the partition key) to see if that message has already been successfully processed. If it has, skip the processing and simply acknowledge/delete the message (a no-op that's still 'successful' from the queue's perspective). If it hasn't, perform the work and then atomically record that this message ID has now been processed — using DynamoDB's conditional writes (ConditionExpression: attribute_not_exists(messageId)) is a common way to make this check-and-record step itself atomic and safe against a race condition where two concurrent Lambda invocations somehow process the same message ID simultaneously.

An important related design point: this idempotency check should ideally be combined with — or replace — naive 'exactly-once processing' assumptions in the business logic itself. For example, an idempotent 'set order status to SHIPPED' operation is naturally safe to repeat, while a non-idempotent 'increment inventory count by 1' operation is not — designing the actual state transitions to be idempotent by nature, wherever possible, is often simpler and more robust than only relying on a separate message-deduplication table layered on top of non-idempotent operations.

By default, a Lambda function runs in an AWS-managed VPC with access to the public internet and AWS service endpoints, but no access to resources inside your own private VPC (like an RDS instance or ElastiCache cluster in a private subnet with no public endpoint). To reach such resources, you must explicitly configure the function to attach to your VPC, specifying the relevant subnets and security groups.

Historically (prior to AWS's networking architecture improvements, generally completed by 2019), this had a serious cold-start cost: each new execution environment required Lambda to provision a dedicated Elastic Network Interface (ENI) directly in your VPC, and ENI creation/attachment was a genuinely slow operation (often taking many seconds), meaning VPC-attached functions could suffer cold starts an order of magnitude worse than non-VPC functions — a major, well-known pain point that shaped a lot of 'avoid VPC-attached Lambda if at all possible' conventional wisdom for years.

AWS's Hyperplane networking architecture fundamentally changed this by decoupling ENI provisioning from individual function cold starts: instead of creating a new ENI per execution environment on demand, AWS pre-provisions and shares a pool of Hyperplane ENIs across many execution environments and even across multiple functions/accounts sharing the same subnet and security group configuration, and routes traffic to the correct destination using a lightweight, high-performance internal network overlay. AWS has continued refining this — including using eBPF to rewrite the underlying tunnel headers, cutting internal tunnel latency from roughly 150 milliseconds down to around 200 microseconds — meaning the VPC-attachment cold-start penalty that used to be a defining Lambda limitation has, by the current generation of the platform, become negligible for the vast majority of workloads.

The practical implication for architects today: the old advice to aggressively avoid VPC-attached Lambda purely to dodge cold starts is largely outdated. VPC attachment should now be decided based on genuine architectural need (does this function actually need to reach a private-subnet resource, or can it use a public endpoint, VPC endpoint, or a Lambda function with a data API instead) rather than as a blanket performance optimization, since the historical performance justification for avoiding it has been substantially resolved at the platform level.

These three represent points on a spectrum from maximum abstraction (least operational responsibility, but less control and different cost characteristics) to maximum control (more operational responsibility, but finer-grained cost and performance tuning).

AWS Lambda is ideal for discrete, event-triggered units of work with a natural start and end, bounded by its 15-minute maximum execution time and per-invocation billing model (you pay only for actual execution time, down to the millisecond, with true scale-to-zero when there's no traffic at all). It's the best fit for API backends, event processing, and scheduled tasks that fit within its execution model.

AWS Fargate is a serverless compute engine specifically for containers, used with ECS or EKS: you define a container task (a Docker image plus CPU/memory requirements) and Fargate runs it without you ever provisioning, patching, or managing the underlying EC2 instances — AWS handles all of that. Compared to Lambda, Fargate supports much longer-running processes (no 15-minute cap), gives you a full container runtime environment (useful for existing containerized applications, or workloads needing more control over the runtime than Lambda's execution model allows), and can run persistent, always-on services (like a long-running API server or a background worker) rather than only short, discrete invocations. It doesn't scale to true zero as cheaply or instantly as Lambda for spiky, intermittent workloads, and its billing is based on provisioned task-level vCPU/memory for the duration a task runs, rather than Lambda's finer-grained per-invocation model.

ECS or EKS on EC2 gives you the same container orchestration capabilities as Fargate, but running on EC2 instances you provision and manage (or that an Auto Scaling Group manages on your behalf) — you're responsible for instance patching, capacity planning, and cluster-level scaling, but in exchange you get access to a much broader range of instance types (including specialized hardware like GPUs, or Spot Instances for significant cost savings), finer control over resource bin-packing across instances (potentially better cost efficiency at large, steady-state scale, since Fargate carries a per-task management premium compared to raw EC2 compute pricing), and the ability to tune the underlying OS/kernel if truly needed.

The general decision framework: use Lambda for event-driven, short-duration, bursty workloads where operational simplicity and true scale-to-zero matter most; use Fargate for longer-running or persistent containerized workloads where you still want to avoid managing servers; and use ECS/EKS on EC2 when you have large-scale, steady-state workloads where the cost savings from fine-grained instance/Spot management and denser bin-packing outweigh the added operational burden of managing the underlying compute yourself.

Lambda's core scaling unit is 'concurrency' — the number of execution environments actively processing requests at any given moment. Each concurrent request needs its own execution environment; if 50 requests arrive at exactly the same instant and no warm environments exist yet, Lambda needs to (up to its scaling rate limits) launch up to 50 separate execution environments simultaneously.

There are two distinct limits that govern this, and conflating them is a common mistake:

1. The concurrency limit (default 1,000 per account per Region, a soft/raisable limit) caps the total number of execution environments that can be running across all your functions in that account and Region at once. Once you hit this ceiling, additional synchronous invocations are throttled (return a 429 error) and additional asynchronous invocations are retried according to Lambda's async retry policy rather than processed immediately.

2. The burst concurrency / scaling rate limit governs how quickly Lambda can add new concurrent execution environments in response to a sudden spike, independent of the overall concurrency ceiling. Historically, Lambda could burst by 500-3000 new concurrent executions in the first minute (varying by Region) and then scale by an additional 500 per minute after that, though AWS has continued to improve burst scaling behavior over time; the specific number matters less than the underlying principle that scaling isn't instantaneous even when you're well under your overall concurrency limit — there's a rate cap on how fast new capacity can spin up, not just a ceiling on total capacity.

A useful mental model, and the actual formula AWS documents for capacity planning: required concurrency = (requests per second) × (average duration per request in seconds). If your API handles 30,000 requests/second, each averaging 20ms, you actually only need 600 concurrent executions (30,000 × 0.02), which comfortably fits within the default 1,000 concurrency limit — even though the raw '30,000 requests per second' figure sounds alarming at first glance. This is why interview candidates should always compute actual required concurrency rather than reasoning from raw request-per-second numbers alone, since duration matters just as much as request rate.

Reserved concurrency (a per-function setting that carves out a guaranteed, and simultaneously capped, portion of the account's total concurrency for one specific function) and Provisioned Concurrency (pre-initialized, always-warm execution environments kept ready to serve traffic immediately, eliminating cold starts for that portion of capacity, at a materially higher cost — roughly comparable in structure to paying for reserved EC2 capacity) are the two knobs available for fine-tuning this behavior per function.

In a monolith, debugging a slow or failing request is relatively simple — a single process, a single log stream, and typically a single stack trace tells you exactly where things went wrong. In a microservices or serverless architecture, a single logical request might touch API Gateway, three or four different Lambda functions, a DynamoDB table, an SQS queue, and an external third-party API — each of these emits its own separate logs, with no inherent, automatic way to correlate 'this specific log line in Service C' with 'this specific incoming request that started in Service A' unless something explicitly ties them together.

Distributed tracing solves this by propagating a shared trace ID (and parent/child span IDs marking each individual hop's start/end time) through every service boundary a request crosses — typically via HTTP headers on synchronous calls, or embedded in the message payload/attributes for asynchronous calls through SQS/SNS/EventBridge. AWS X-Ray is AWS's managed distributed tracing service: it collects trace segments (data about the work done by a single service for a given request, including timing, errors, and downstream calls made) from instrumented services, and stitches them together into a single, unified 'service map' and timeline view showing exactly how long each hop in the request took, where errors occurred, and which specific downstream call in a long chain was actually the bottleneck.

Without this, engineers debugging a slow or failing distributed request are stuck manually correlating timestamps and request parameters across many completely separate log streams, hoping they're actually looking at logs from the same logical request — a slow, error-prone, and often practically infeasible process at any meaningful scale or traffic volume, especially when multiple similar requests are happening concurrently and their logs interleave.

X-Ray integrates natively with API Gateway, Lambda, and many other AWS services (auto-instrumenting much of the trace propagation without requiring code changes for AWS-to-AWS hops), and supports custom instrumentation via the X-Ray SDK for capturing details about your own application-level logic and calls to external, non-AWS dependencies. AWS Distro for OpenTelemetry (ADOT) offers a more open-standards-based alternative/complement, letting the same instrumented application send traces to X-Ray or to other observability backends (like a self-hosted or third-party tracing platform) without vendor lock-in to X-Ray's specific SDK.

SQS (and most distributed messaging systems) guarantee at-least-once delivery, not exactly-once — a message might be delivered to a consumer more than once in several realistic scenarios: the consumer successfully processes a message but crashes or times out before it can call DeleteMessage to remove it from the queue (so SQS reasonably assumes it wasn't processed and redelivers it after the visibility timeout expires); a network blip between the consumer and SQS drops the delete confirmation even though the delete actually succeeded server-side; or (for FIFO queues specifically, within the same message group) a batch retry re-delivers messages that were already successfully processed earlier in that same batch.

Because of this, any Lambda function processing SQS messages that has side effects (writing to a database, charging a payment, sending a notification) needs to be explicitly designed to handle duplicate deliveries safely — this is not an edge case to handle defensively 'just in case,' it's an expected, normal operating condition of the system.

The standard implementation pattern: extract a unique identifier from each message — either a natural business key already present in the message (like an order ID) or SQS's own MessageId attribute — and, before performing the actual side-effecting work, check a durable store (commonly a DynamoDB table with the message ID as the partition key) to see if that message has already been successfully processed. If it has, skip the processing and simply acknowledge/delete the message (a no-op that's still 'successful' from the queue's perspective). If it hasn't, perform the work and then atomically record that this message ID has now been processed — using DynamoDB's conditional writes (ConditionExpression: attribute_not_exists(messageId)) is a common way to make this check-and-record step itself atomic and safe against a race condition where two concurrent Lambda invocations somehow process the same message ID simultaneously.

An important related design point: this idempotency check should ideally be combined with — or replace — naive 'exactly-once processing' assumptions in the business logic itself. For example, an idempotent 'set order status to SHIPPED' operation is naturally safe to repeat, while a non-idempotent 'increment inventory count by 1' operation is not — designing the actual state transitions to be idempotent by nature, wherever possible, is often simpler and more robust than only relying on a separate message-deduplication table layered on top of non-idempotent operations.

By default, a Lambda function runs in an AWS-managed VPC with access to the public internet and AWS service endpoints, but no access to resources inside your own private VPC (like an RDS instance or ElastiCache cluster in a private subnet with no public endpoint). To reach such resources, you must explicitly configure the function to attach to your VPC, specifying the relevant subnets and security groups.

Historically (prior to AWS's networking architecture improvements, generally completed by 2019), this had a serious cold-start cost: each new execution environment required Lambda to provision a dedicated Elastic Network Interface (ENI) directly in your VPC, and ENI creation/attachment was a genuinely slow operation (often taking many seconds), meaning VPC-attached functions could suffer cold starts an order of magnitude worse than non-VPC functions — a major, well-known pain point that shaped a lot of 'avoid VPC-attached Lambda if at all possible' conventional wisdom for years.

AWS's Hyperplane networking architecture fundamentally changed this by decoupling ENI provisioning from individual function cold starts: instead of creating a new ENI per execution environment on demand, AWS pre-provisions and shares a pool of Hyperplane ENIs across many execution environments and even across multiple functions/accounts sharing the same subnet and security group configuration, and routes traffic to the correct destination using a lightweight, high-performance internal network overlay. AWS has continued refining this — including using eBPF to rewrite the underlying tunnel headers, cutting internal tunnel latency from roughly 150 milliseconds down to around 200 microseconds — meaning the VPC-attachment cold-start penalty that used to be a defining Lambda limitation has, by the current generation of the platform, become negligible for the vast majority of workloads.

The practical implication for architects today: the old advice to aggressively avoid VPC-attached Lambda purely to dodge cold starts is largely outdated. VPC attachment should now be decided based on genuine architectural need (does this function actually need to reach a private-subnet resource, or can it use a public endpoint, VPC endpoint, or a Lambda function with a data API instead) rather than as a blanket performance optimization, since the historical performance justification for avoiding it has been substantially resolved at the platform level.

These three represent points on a spectrum from maximum abstraction (least operational responsibility, but less control and different cost characteristics) to maximum control (more operational responsibility, but finer-grained cost and performance tuning).

AWS Lambda is ideal for discrete, event-triggered units of work with a natural start and end, bounded by its 15-minute maximum execution time and per-invocation billing model (you pay only for actual execution time, down to the millisecond, with true scale-to-zero when there's no traffic at all). It's the best fit for API backends, event processing, and scheduled tasks that fit within its execution model.

AWS Fargate is a serverless compute engine specifically for containers, used with ECS or EKS: you define a container task (a Docker image plus CPU/memory requirements) and Fargate runs it without you ever provisioning, patching, or managing the underlying EC2 instances — AWS handles all of that. Compared to Lambda, Fargate supports much longer-running processes (no 15-minute cap), gives you a full container runtime environment (useful for existing containerized applications, or workloads needing more control over the runtime than Lambda's execution model allows), and can run persistent, always-on services (like a long-running API server or a background worker) rather than only short, discrete invocations. It doesn't scale to true zero as cheaply or instantly as Lambda for spiky, intermittent workloads, and its billing is based on provisioned task-level vCPU/memory for the duration a task runs, rather than Lambda's finer-grained per-invocation model.

ECS or EKS on EC2 gives you the same container orchestration capabilities as Fargate, but running on EC2 instances you provision and manage (or that an Auto Scaling Group manages on your behalf) — you're responsible for instance patching, capacity planning, and cluster-level scaling, but in exchange you get access to a much broader range of instance types (including specialized hardware like GPUs, or Spot Instances for significant cost savings), finer control over resource bin-packing across instances (potentially better cost efficiency at large, steady-state scale, since Fargate carries a per-task management premium compared to raw EC2 compute pricing), and the ability to tune the underlying OS/kernel if truly needed.

The general decision framework: use Lambda for event-driven, short-duration, bursty workloads where operational simplicity and true scale-to-zero matter most; use Fargate for longer-running or persistent containerized workloads where you still want to avoid managing servers; and use ECS/EKS on EC2 when you have large-scale, steady-state workloads where the cost savings from fine-grained instance/Spot management and denser bin-packing outweigh the added operational burden of managing the underlying compute yourself.

A standard Aurora cross-region read replica uses the database engine's native asynchronous logical replication (binlog-based for MySQL, or equivalent for PostgreSQL) to ship changes to a replica in another Region. This works, but logical replication has meaningful overhead — it has to parse, serialize, and replay individual SQL-level changes — leading to replication lag that can range from seconds to much longer under heavy write load.

Aurora Global Database instead replicates at the storage layer, shipping the same low-level redo log records that Aurora's distributed storage layer already uses internally for its own AZ-level durability, rather than going through the database engine's logical replication path at all. Because this bypasses the query engine almost entirely and uses purpose-built, dedicated network infrastructure between Regions, typical replication lag is under 1 second, even under significant write throughput — dramatically better than logical replication-based replicas.

Operationally, this translates into much better DR characteristics: Aurora Global Database advertises RPO of about 1 second and RTO of under 1 minute for a full regional failover (promoting a secondary Region's cluster to be the new primary), compared to the RPO of many seconds-to-minutes and higher manual RTO typical of logical cross-region replicas.

The trade-off is scope and cost: Global Database is Aurora-specific (MySQL- and PostgreSQL-compatible editions), replicates the entire cluster (not selectively), and costs more due to the dedicated replication infrastructure and the fact you're running compute in the secondary Region as well. It's the right choice when you need genuinely fast, reliable regional failover for a mission-critical Aurora workload — Warm Standby or Pilot Light DR patterns for Aurora are typically built on top of Global Database rather than plain cross-region read replicas for exactly this reason.

These two terms are frequently conflated but measure fundamentally different things. Durability is the probability that a given piece of stored data survives over a long period of time (usually expressed annually) without being lost or corrupted, regardless of whether you can access it at this exact moment. Availability is the probability that the service is up and able to successfully respond to a request right now.

Amazon S3 Standard advertises 99.999999999% ('11 nines') durability, designed by redundantly storing object data across a minimum of three Availability Zones. In practical terms, this means if you stored 10 million objects in S3, you'd statistically expect to lose one object roughly every 10,000 years — an extraordinarily low data-loss risk, achieved through massive redundancy and continuous integrity checking/repair happening behind the scenes.

However, S3's availability SLA is a separate, much lower number — 99.9% for S3 Standard — reflecting the realistic possibility of transient issues (throttling, brief regional degradation, network issues) that make the service temporarily unreachable or slow, even though the underlying data itself remains perfectly safe and intact. A request might fail with a 503 error during a brief availability blip, but that says nothing about whether your data was lost — it almost certainly wasn't, and a retry moments later typically succeeds.

This distinction matters directly for architecture decisions: a system needing to guarantee zero data loss (high durability requirement) but which can tolerate brief read/write delays should lean on S3's durability guarantees and build in client-side retries for the occasional availability blip, rather than assuming '11 nines' means the service is always instantly reachable — those are two entirely different guarantees, and treating them as interchangeable is a common architectural misunderstanding.

RTO (Recovery Time Objective) measures the maximum acceptable time between a disaster and full service restoration. RPO (Recovery Point Objective) measures the maximum acceptable amount of data loss, measured in time — e.g., an RPO of 15 minutes means you can lose at most 15 minutes of transactions.

AWS's four canonical DR strategies map directly onto these targets, forming a cost-versus-recovery-speed spectrum:

1. Backup & Restore (RTO: hours, RPO: hours) — You periodically snapshot data (RDS snapshots, EBS snapshots, S3 backups) to another Region and only spin up infrastructure from Infrastructure-as-Code templates when disaster strikes. Cheapest option, since nothing runs idle, but recovery involves provisioning everything from scratch.

2. Pilot Light (RTO: tens of minutes, RPO: minutes) — Core data stores (like an RDS replica) are kept continuously replicating in the DR Region, but compute (EC2, ECS) stays off. When needed, you 'ignite' by scaling up the pre-configured but dormant compute layer. Think of it as the pilot flame in a furnace — small, always on, ready to ignite the full system.

3. Warm Standby (RTO: minutes, RPO: seconds-minutes) — A scaled-down but fully functional copy of the full stack runs continuously in the DR Region, handling a fraction of production traffic or none at all. During failover, you scale it up to full capacity and redirect traffic via Route 53. Faster recovery than Pilot Light because compute is already running, just undersized.

4. Multi-Site Active-Active (RTO: near-zero, RPO: near-zero) — Full production capacity runs simultaneously in two or more Regions, actively serving live traffic behind a global routing layer (Route 53 latency or geolocation routing, or Global Accelerator). Failover is just a routing change since the standby is already handling real traffic. This is the most expensive and operationally complex option because it demands active-active data replication (e.g., DynamoDB Global Tables) and careful handling of write conflicts.

The architectural decision comes down to plotting your business's tolerance for downtime and data loss against the cost curve — each step up roughly multiplies both resilience and spend.

DynamoDB is a managed, multi-AZ NoSQL database by default — every table's data is automatically partitioned and each partition is synchronously replicated across three AZs within the Region using quorum-based consensus underlying AWS's storage layer. A write is only acknowledged to the client once a quorum (majority) of replicas confirm it, which is what makes DynamoDB durable and AZ-fault-tolerant without any configuration from the developer.

This replication model creates the classic CAP theorem trade-off on the read side, exposed through two read consistency options:

Eventually Consistent Reads (default): The request can be served by any replica, including one that hasn't yet received the very latest write. This is faster and consumes half the read capacity (0.5 RCU per 4KB) but can occasionally return slightly stale data — typically the staleness window is under a second.

Strongly Consistent Reads: The request is guaranteed to reflect all writes that received a successful response prior to the read. This is achieved by reading from a replica confirmed to be current relative to the quorum. It costs a full RCU per 4KB, has marginally higher latency, and is unavailable during certain network partition scenarios or when reading from a Global Secondary Index (GSIs only support eventual consistency).

For multi-region durability, DynamoDB Global Tables extend this further using multi-active replication across Regions with a 'last writer wins' conflict resolution based on timestamps — meaning Global Tables are inherently eventually consistent across Regions, even if you choose strong consistency within a single Region.

Architecturally, the lesson is: DynamoDB gives you tunable consistency per request, not a single global guarantee, so the application layer must decide, on a query-by-query basis, whether it needs the freshest possible data (e.g., reading your own just-placed order) or can tolerate slight staleness (e.g., a product catalog listing).

When you configure an ASG with multiple subnets (each in a different AZ), AWS's default behavior is AZ Rebalancing: the ASG algorithm tries to keep the number of running instances roughly even across all specified AZs, recalculating on every scaling activity. If you have desired capacity of 6 across 3 AZs, it aims for 2 per AZ.

Under the hood, the ASG launches into the AZ with the fewest instances first, and if a scaling event or AZ-rebalance requires moving capacity, it launches replacement instances in a healthy AZ before terminating instances in an over-represented or degraded one — a 'launch before terminate' pattern designed to avoid ever having a capacity dip, though this can be influenced by termination policies (e.g., OldestInstance, ClosestToNextInstanceHour).

This matters enormously for fault tolerance because if an AZ becomes unhealthy or capacity-constrained, the ASG will avoid launching there and rebalance the fleet into the remaining healthy AZs — but only if your ASG's max capacity and the subnet's IP address space actually allow it. A common real-world failure mode is: an ASG configured across 3 AZs but with a max capacity only slightly above desired capacity, or subnets with too-small CIDR blocks. When one AZ goes down, the ASG cannot fit the displaced instances into the remaining AZs, so overall capacity effectively drops by a third even though you 'configured for HA.'

Another subtlety: if you only place your ASG in 2 AZs instead of 3, you're now n+1 exposed — losing one AZ removes 50% of your capacity, versus roughly 33% with 3 AZs. Interviewers often probe this because 'multi-AZ' isn't binary; the number and balance of AZs directly determines your blast radius per failure. AWS's newer ARC Zonal Shift integration for ASGs adds an explicit recovery lever on top of this: it lets you (or AWS's autoshift automation) actively register the ASG so an impaired AZ can be treated as excluded, pausing new launches there and stopping unnecessary scale-in while capacity rebalances into healthy AZs.

RTO (Recovery Time Objective) measures the maximum acceptable time between a disaster and full service restoration. RPO (Recovery Point Objective) measures the maximum acceptable amount of data loss, measured in time — e.g., an RPO of 15 minutes means you can lose at most 15 minutes of transactions.

AWS's four canonical DR strategies map directly onto these targets, forming a cost-versus-recovery-speed spectrum:

1. Backup & Restore (RTO: hours, RPO: hours) — You periodically snapshot data (RDS snapshots, EBS snapshots, S3 backups) to another Region and only spin up infrastructure from Infrastructure-as-Code templates when disaster strikes. Cheapest option, since nothing runs idle, but recovery involves provisioning everything from scratch.

2. Pilot Light (RTO: tens of minutes, RPO: minutes) — Core data stores (like an RDS replica) are kept continuously replicating in the DR Region, but compute (EC2, ECS) stays off. When needed, you 'ignite' by scaling up the pre-configured but dormant compute layer. Think of it as the pilot flame in a furnace — small, always on, ready to ignite the full system.

3. Warm Standby (RTO: minutes, RPO: seconds-minutes) — A scaled-down but fully functional copy of the full stack runs continuously in the DR Region, handling a fraction of production traffic or none at all. During failover, you scale it up to full capacity and redirect traffic via Route 53. Faster recovery than Pilot Light because compute is already running, just undersized.

4. Multi-Site Active-Active (RTO: near-zero, RPO: near-zero) — Full production capacity runs simultaneously in two or more Regions, actively serving live traffic behind a global routing layer (Route 53 latency or geolocation routing, or Global Accelerator). Failover is just a routing change since the standby is already handling real traffic. This is the most expensive and operationally complex option because it demands active-active data replication (e.g., DynamoDB Global Tables) and careful handling of write conflicts.

The architectural decision comes down to plotting your business's tolerance for downtime and data loss against the cost curve — each step up roughly multiplies both resilience and spend.

DynamoDB is a managed, multi-AZ NoSQL database by default — every table's data is automatically partitioned and each partition is synchronously replicated across three AZs within the Region using the Multi-Paxos-based replication protocol underlying AWS's storage layer. A write is only acknowledged to the client once a quorum (majority) of replicas confirm it, which is what makes DynamoDB durable and AZ-fault-tolerant without any configuration from the developer.

This replication model creates the classic CAP theorem trade-off on the read side, exposed through two read consistency options:

Eventually Consistent Reads (default): The request can be served by any replica, including one that hasn't yet received the very latest write. This is faster and consumes half the read capacity (0.5 RCU per 4KB) but can occasionally return slightly stale data — typically the staleness window is under a second.

Strongly Consistent Reads: The request is guaranteed to reflect all writes that received a successful response prior to the read. This is achieved by reading from a replica confirmed to be current relative to the quorum. It costs a full RCU per 4KB, has marginally higher latency, and is unavailable during certain network partition scenarios or when reading from a Global Secondary Index (GSIs only support eventual consistency).

For multi-region durability, DynamoDB Global Tables extend this further using multi-active replication across Regions with a 'last writer wins' conflict resolution based on timestamps — meaning Global Tables are inherently eventually consistent across Regions, even if you choose strong consistency within a single Region.

Architecturally, the lesson is: DynamoDB gives you tunable consistency per request, not a single global guarantee, so the application layer must decide, on a query-by-query basis, whether it needs the freshest possible data (e.g., reading your own just-placed order) or can tolerate slight staleness (e.g., a product catalog listing).

Lambda functions themselves are inherently stateless and Region-scoped — there's no special 'multi-region Lambda' feature; achieving multi-region serverless simply means deploying the same function code (and the surrounding API Gateway, IAM roles, and other supporting configuration) independently into each target Region, typically via Infrastructure as Code (CloudFormation, CDK, Terraform) to keep every Region's deployment consistent and avoid configuration drift between them.

The genuinely hard part of a multi-region active-active serverless architecture is the stateful layer — the data. DynamoDB Global Tables is the natural fit here: it provides multi-active replication of table data across Regions, with each Region's table accepting both reads and writes locally (avoiding the higher latency of routing every single write back to one 'primary' Region), and asynchronously, continuously replicating changes to all other participating Regions, using last-writer-wins conflict resolution (as covered in the discussion of multi-region conflict resolution) for any genuinely concurrent writes to the same item across Regions.

Traffic routing typically uses Route 53 (latency-based or geolocation routing, directing each user to whichever active Region gives them the best latency or satisfies data-residency requirements) or, for lower-latency, more sophisticated routing needs, AWS Global Accelerator, which routes traffic over AWS's private global network backbone to the nearest healthy Regional endpoint at the network layer rather than relying on DNS-based routing and its associated TTL/caching delays.

Several serverless-specific considerations become important in this architecture: idempotency records (the deduplication tables discussed for safe SQS/webhook processing) need to be either Region-local (accepting that a request retried in a different Region after a failover might not be recognized as a duplicate) or themselves replicated via Global Tables (adding replication lag to the idempotency check itself, and potential edge cases if the same logical request somehow gets processed in two Regions before replication catches up); Lambda's reserved/provisioned concurrency settings need to be configured per-Region independently, since concurrency limits are themselves a Region-scoped resource, not something that spans Regions; and any Lambda functions calling other Region-scoped AWS services (like sending emails via SES, or invoking Bedrock for AI inference) need to ensure they're calling the correctly Regional endpoint for whichever Region that specific execution environment is running in, rather than hardcoding a single Region's endpoint, which would silently reintroduce a cross-region dependency (and associated latency and availability risk) into what's supposed to be a fully Region-independent, active-active architecture.

The overall architectural lesson is that 'serverless' doesn't make multi-region design easier in any fundamental way compared to a traditional EC2-based architecture — Lambda's statelessness genuinely simplifies the compute layer (no server state to synchronize, no instances to replicate), but the hard problems of multi-region architecture (data replication and conflict resolution, traffic routing, and Region-scoped resource configuration) remain exactly as real and require exactly the same careful design regardless of whether the compute layer happens to be serverless or traditional.

Traditionally, every new Lambda execution environment cold start runs through the same sequence: allocate a Firecracker microVM, download and mount the deployment package, start the language runtime, and then execute your initialization code (any code outside the handler function — for many applications, especially JVM-based ones using frameworks like Spring, this INIT phase is by far the slowest part, since it involves class loading, dependency injection container setup, connection pool warm-up, and JIT compiler warm-up, which for a Java application could historically take anywhere from 3 to 15 seconds).

SnapStart changes this fundamentally: when you publish a new version of a SnapStart-enabled function, AWS runs your full initialization code exactly once, in a special preparation step, and then takes a complete snapshot of the resulting Firecracker microVM's memory and disk state at that exact moment — capturing the fully warmed-up JVM, loaded classes, and initialized objects. This snapshot is encrypted and cached (using AWS's Hyperplane infrastructure for fast, low-latency access). From then on, whenever a new execution environment is needed for that published version, instead of running the full INIT sequence from scratch, Lambda simply restores directly from this pre-made snapshot — resuming execution from the point right after initialization completed, skipping essentially all of the expensive class-loading and JIT-warming work. This is what's cut Java cold starts from a historical 3-10 seconds down to roughly 90-150ms in current benchmarks — an improvement described as up to 90-94% reduction in P99 cold start latency.

A critical, security-relevant caveat that AWS explicitly documents: because the snapshot captures the exact in-memory state from that one initialization run — including any unique values generated during initialization, like a randomly-generated UUID, a cryptographic key, or a connection object — every subsequently-restored execution environment from that same snapshot would otherwise share those exact same values, unless explicitly handled. AWS addresses this via runtime hooks (in the JVM ecosystem, based on the Coordinated Restore at Checkpoint, or CRaC, standard) that let you register callbacks to run specific 'before checkpoint' and 'after restore' code — for example, deferring the generation of a unique connection ID or a fresh random seed until the after-restore hook runs, ensuring each restored environment gets genuinely fresh, unique values rather than an accidentally-reused one baked into the shared snapshot.

SnapStart is currently supported for Java 11+, Python 3.12+, and .NET 8+ (notably not yet available for Node.js or Ruby, or for container-image-packaged functions), and — as of a 2025 billing change — the INIT phase itself is now billed for ZIP-packaged functions using managed runtimes (previously the INIT phase was free), which shifts some of the cost calculus, though AWS's own production data shows cold starts still occur in under 1% of invocations for typical workloads, keeping the net cost impact of this billing change modest for most applications in practice.

SQS FIFO queues guarantee strict First-In-First-Out ordering and exactly-once processing, but only within a given message group (identified by a MessageGroupId you assign) — messages across different message groups within the same queue have no ordering guarantee relative to each other, which is what allows FIFO queues to still parallelize processing across many message groups simultaneously rather than being limited to one strictly sequential stream. Once a consumer successfully processes and deletes a message, it's gone from the queue permanently — there's no way to 're-read' history.

Amazon Kinesis Data Streams (and similarly, self-managed or MSK-hosted Kafka) work fundamentally differently: data is organized into an ordered, durable, append-only log, split across multiple shards (Kinesis) or partitions (Kafka). Within a single shard/partition, order is strictly preserved. Critically, consumers don't delete records after reading them — instead, each consumer independently tracks its own read position (a sequence number or offset) within the log, and records remain available in the stream for a configurable retention period (commonly 24 hours to 7 days for Kinesis, often much longer for Kafka) regardless of whether any consumer has read them yet. This means multiple, independent consumer applications can each read through the exact same stream at their own pace, and a consumer can be paused, restarted, or even deliberately rewound to reprocess historical data, all without affecting the stream or other consumers.

This fundamental difference has direct implications for backpressure: with SQS, if a consumer falls behind, messages simply accumulate in the queue (up to its retention period, commonly up to 14 days) — this handles backpressure gracefully for competing-consumer, work-distribution use cases, since additional consumer capacity can be added independently to drain the backlog faster, without any ordering complications across different worker instances. With Kinesis/Kafka, if a consumer falls behind, it simply reads from an increasingly stale offset within the log — the stream itself doesn't apply backpressure to producers (producers keep writing to the shard/partition regardless of consumer speed, up to the shard's own write throughput limit), so a critically slow consumer risks eventually falling behind the stream's retention window and permanently losing unread historical data, which is a materially different and often more operationally alarming failure mode than SQS's 'messages just pile up in the queue' behavior.

The architectural choice between them typically comes down to the specific ordering and replay requirements: SQS FIFO fits use cases needing strict per-entity ordering (e.g., all operations for a single user or order processed in sequence) with straightforward work distribution and no need to replay history; Kinesis/Kafka fit use cases needing multiple independent consumers reading the same event stream (like both a real-time analytics pipeline and a separate archival pipeline consuming the exact same events), needing to replay historical data (e.g., reprocessing after fixing a consumer bug), or requiring much higher sustained throughput than SQS FIFO's per-message-group limits comfortably support.

When a Lambda function finishes an invocation, AWS doesn't necessarily tear down the execution environment (the Firecracker microVM, initialized runtime, and any global/module-level state) immediately — it's frequently kept 'warm' for a period, ready to serve the next invocation without paying the cold-start cost again. This is a deliberate, valuable performance optimization: code written outside the handler function (module-level imports, a database connection pool initialized once at the top of the file, a cached configuration value) runs only once per execution environment, not once per invocation, and gets reused across every subsequent 'warm' invocation that environment handles.

This creates real correctness considerations that engineers frequently get wrong:

1. Assuming warm reuse is guaranteed — it is never guaranteed. AWS can and does create new execution environments at any time (to scale up for increased traffic, after an idle timeout, after a deployment, or simply as part of normal operational behavior), so code must be correct whether or not a given invocation happens to reuse a warm environment. A common bug: initializing a value outside the handler assuming it will always be present, without handling the case where a fresh, cold environment means that initialization genuinely hasn't run yet for this specific invocation's lifetime — usually not an issue since it DOES run before the very first invocation in any environment, but connection state (like a database connection that's since been closed by the remote server due to an idle timeout) can go stale in a way the code doesn't detect.

2. Stale or leaked state between invocations — because global/module-level variables persist across invocations within the same warm environment, any state inadvertently left mutated by one invocation (a global variable accidentally modified rather than reset, an in-memory cache that should have been invalidated, a partially-consumed iterator or generator) can silently leak into and affect a completely unrelated, later invocation handled by the same warm environment — a subtle bug class that has no equivalent in traditional per-request server models where each request typically gets fully independent execution context.

3. Connection pool sizing based on wrong assumptions — because Lambda scales by running many separate, isolated execution environments (rather than one process handling many concurrent requests, as with a traditional server), initializing a large connection pool per execution environment (assuming it needs to handle many concurrent requests within that one environment, as you might with a traditional multi-threaded server) is usually the wrong mental model — each execution environment typically handles requests one at a time (unless using Lambda's newer response streaming or specific concurrent-invocation-within-one-environment features), so a connection pool sized for high per-environment concurrency, multiplied across potentially hundreds or thousands of concurrently-running execution environments during a traffic spike, can easily and unexpectedly exhaust a downstream database's total connection limit — this is a well-known, common cause of Lambda-triggered database connection exhaustion incidents, and is precisely the problem services like Amazon RDS Proxy (which pools and multiplexes connections across many Lambda execution environments external to the functions themselves) are specifically designed to solve.

4. File system and /tmp state — Lambda provides a writable /tmp directory (up to a configurable size, historically 512MB, expandable up to 10GB) that persists across invocations within the same warm environment, which can be a useful, deliberate caching mechanism (e.g., caching a downloaded reference dataset) but becomes a correctness or resource-leak bug if code writes temporary files assuming they'll be cleaned up between invocations without explicitly deleting them, potentially exhausting the available /tmp space after enough warm invocations accumulate uncleaned files.

Traditionally, every new Lambda execution environment cold start runs through the same sequence: allocate a Firecracker microVM, download and mount the deployment package, start the language runtime, and then execute your initialization code (any code outside the handler function — for many applications, especially JVM-based ones using frameworks like Spring, this INIT phase is by far the slowest part, since it involves class loading, dependency injection container setup, connection pool warm-up, and JIT compiler warm-up, which for a Java application could historically take anywhere from 3 to 15 seconds).

SnapStart changes this fundamentally: when you publish a new version of a SnapStart-enabled function, AWS runs your full initialization code exactly once, in a special preparation step, and then takes a complete snapshot of the resulting Firecracker microVM's memory and disk state at that exact moment — capturing the fully warmed-up JVM, loaded classes, and initialized objects. This snapshot is encrypted and cached (using AWS's Hyperplane infrastructure for fast, low-latency access). From then on, whenever a new execution environment is needed for that published version, instead of running the full INIT sequence from scratch, Lambda simply restores directly from this pre-made snapshot — resuming execution from the point right after initialization completed, skipping essentially all of the expensive class-loading and JIT-warming work. This is what's cut Java cold starts from a historical 3-10 seconds down to roughly 90-150ms in current benchmarks — an improvement described as up to 90-94% reduction in P99 cold start latency.

A critical, security-relevant caveat that AWS explicitly documents: because the snapshot captures the exact in-memory state from that one initialization run — including any unique values generated during initialization, like a randomly-generated UUID, a cryptographic key, or a connection object — every subsequently-restored execution environment from that same snapshot would otherwise share those exact same values, unless explicitly handled. AWS addresses this via runtime hooks (in the JVM ecosystem, based on the Coordinated Restore at Checkpoint, or CRaC, standard) that let you register callbacks to run specific 'before checkpoint' and 'after restore' code — for example, deferring the generation of a unique connection ID or a fresh random seed until the after-restore hook runs, ensuring each restored environment gets genuinely fresh, unique values rather than an accidentally-reused one baked into the shared snapshot.

SnapStart is currently supported for Java 11+, Python 3.12+, and .NET 8+ (notably not yet available for Node.js or Ruby, or for container-image-packaged functions), and — as of a 2025 billing change — the INIT phase itself is now billed for ZIP-packaged functions using managed runtimes (previously the INIT phase was free), which shifts some of the cost calculus, though AWS's own production data shows cold starts still occur in under 1% of invocations for typical workloads, keeping the net cost impact of this billing change modest for most applications in practice.

SQS FIFO queues guarantee strict First-In-First-Out ordering and exactly-once processing, but only within a given message group (identified by a MessageGroupId you assign) — messages across different message groups within the same queue have no ordering guarantee relative to each other, which is what allows FIFO queues to still parallelize processing across many message groups simultaneously rather than being limited to one strictly sequential stream. Once a consumer successfully processes and deletes a message, it's gone from the queue permanently — there's no way to 're-read' history.

Amazon Kinesis Data Streams (and similarly, self-managed or MSK-hosted Kafka) work fundamentally differently: data is organized into an ordered, durable, append-only log, split across multiple shards (Kinesis) or partitions (Kafka). Within a single shard/partition, order is strictly preserved. Critically, consumers don't delete records after reading them — instead, each consumer independently tracks its own read position (a sequence number or offset) within the log, and records remain available in the stream for a configurable retention period (commonly 24 hours to 7 days for Kinesis, often much longer for Kafka) regardless of whether any consumer has read them yet. This means multiple, independent consumer applications can each read through the exact same stream at their own pace, and a consumer can be paused, restarted, or even deliberately rewound to reprocess historical data, all without affecting the stream or other consumers.

This fundamental difference has direct implications for backpressure: with SQS, if a consumer falls behind, messages simply accumulate in the queue (up to its retention period, commonly up to 14 days) — this handles backpressure gracefully for competing-consumer, work-distribution use cases, since additional consumer capacity can be added independently to drain the backlog faster, without any ordering complications across different worker instances. With Kinesis/Kafka, if a consumer falls behind, it simply reads from an increasingly stale offset within the log — the stream itself doesn't apply backpressure to producers (producers keep writing to the shard/partition regardless of consumer speed, up to the shard's own write throughput limit), so a critically slow consumer risks eventually falling behind the stream's retention window and permanently losing unread historical data, which is a materially different and often more operationally alarming failure mode than SQS's 'messages just pile up in the queue' behavior.

The architectural choice between them typically comes down to the specific ordering and replay requirements: SQS FIFO fits use cases needing strict per-entity ordering (e.g., all operations for a single user or order processed in sequence) with straightforward work distribution and no need to replay history; Kinesis/Kafka fit use cases needing multiple independent consumers reading the same event stream (like both a real-time analytics pipeline and a separate archival pipeline consuming the exact same events), needing to replay historical data (e.g., reprocessing after fixing a consumer bug), or requiring much higher sustained throughput than SQS FIFO's per-message-group limits comfortably support.

When a Lambda function finishes an invocation, AWS doesn't necessarily tear down the execution environment (the Firecracker microVM, initialized runtime, and any global/module-level state) immediately — it's frequently kept 'warm' for a period, ready to serve the next invocation without paying the cold-start cost again. This is a deliberate, valuable performance optimization: code written outside the handler function (module-level imports, a database connection pool initialized once at the top of the file, a cached configuration value) runs only once per execution environment, not once per invocation, and gets reused across every subsequent 'warm' invocation that environment handles.

This creates real correctness considerations that engineers frequently get wrong:

1. Assuming warm reuse is guaranteed — it is never guaranteed. AWS can and does create new execution environments at any time (to scale up for increased traffic, after an idle timeout, after a deployment, or simply as part of normal operational behavior), so code must be correct whether or not a given invocation happens to reuse a warm environment. A common bug: initializing a value outside the handler assuming it will always be present, without handling the case where a fresh, cold environment means that initialization genuinely hasn't run yet for this specific invocation's lifetime — usually not an issue since it DOES run before the very first invocation in any environment, but connection state (like a database connection that's since been closed by the remote server due to an idle timeout) can go stale in a way the code doesn't detect.

2. Stale or leaked state between invocations — because global/module-level variables persist across invocations within the same warm environment, any state inadvertently left mutated by one invocation (a global variable accidentally modified rather than reset, an in-memory cache that should have been invalidated, a partially-consumed iterator or generator) can silently leak into and affect a completely unrelated, later invocation handled by the same warm environment — a subtle bug class that has no equivalent in traditional per-request server models where each request typically gets fully independent execution context.

3. Connection pool sizing based on wrong assumptions — because Lambda scales by running many separate, isolated execution environments (rather than one process handling many concurrent requests, as with a traditional server), initializing a large connection pool per execution environment (assuming it needs to handle many concurrent requests within that one environment, as you might with a traditional multi-threaded server) is usually the wrong mental model — each execution environment typically handles requests one at a time (unless using Lambda's newer response streaming or specific concurrent-invocation-within-one-environment features), so a connection pool sized for high per-environment concurrency, multiplied across potentially hundreds or thousands of concurrently-running execution environments during a traffic spike, can easily and unexpectedly exhaust a downstream database's total connection limit — this is a well-known, common cause of Lambda-triggered database connection exhaustion incidents, and is precisely the problem services like Amazon RDS Proxy (which pools and multiplexes connections across many Lambda execution environments external to the functions themselves) are specifically designed to solve.

4. File system and /tmp state — Lambda provides a writable /tmp directory (up to a configurable size, historically 512MB, expandable up to 10GB) that persists across invocations within the same warm environment, which can be a useful, deliberate caching mechanism (e.g., caching a downloaded reference dataset) but becomes a correctness or resource-leak bug if code writes temporary files assuming they'll be cleaned up between invocations without explicitly deleting them, potentially exhausting the available /tmp space after enough warm invocations accumulate uncleaned files.

Traditional recovery mechanisms (ALB target health checks, ASG instance health checks) operate at the level of individual resources: each target or instance is independently probed, and only that specific resource is removed from rotation once it fails enough checks. This works well for isolated instance failures, but during a broader AZ-level 'gray failure' — where the AZ isn't fully down but is experiencing degraded performance, partial network issues, or elevated latency that doesn't cleanly fail standard health checks — traditional per-resource health checks can be slow or unreliable to detect the pattern, since individual instances might still technically pass their health checks while overall performance in that AZ silently degrades.

Amazon Application Recovery Controller's (ARC) Zonal Shift addresses this gap directly: it lets you (via console, CLI, or API) declare 'AZ X is impaired, shift all traffic away from it' as a single, explicit, AZ-level action. For a cross-zone-enabled ALB, this immediately removes the impaired AZ's zonal IP addresses from DNS and blocks all traffic to targets in that AZ, regardless of whether those individual targets are passing their own health checks. This is dramatically faster and more deterministic than waiting for degraded performance to eventually breach health check thresholds across many individual targets.

Zonal Autoshift extends this further into a fully automated, AWS-operated safety mechanism: AWS's own internal monitoring can trigger a zonal shift automatically on your behalf when it detects a potential AZ impairment, without you needing to notice and manually intervene — while giving you confidence it's safe to rely on via 'practice runs,' which periodically simulate a shift away from an AZ (even when there's no real impairment) specifically to verify your application has enough spare capacity in the remaining AZs to absorb the full load, catching capacity-planning gaps before a real incident does.

The integration now spans ALB (cross-zone enabled), NLB, EC2 Auto Scaling groups, and (as of 2026) EKS Auto Mode and Karpenter-managed clusters — pausing new capacity launches and voluntary node disruptions in the impaired AZ while redirecting live traffic, giving Kubernetes-based architectures the same AZ-level recovery lever that had previously only been available for classic EC2/ALB stacks.