Serverless and Container Architectures

Serverless and containers are the default design choices for new workloads on modern AWS architectures, and task statement 2.1 of the SAA-C03 exam guide tests serverless and containers under the banner of "design scalable and loosely coupled architectures." In this chapter you will learn serverless and containers on AWS at the depth a Solutions Architect Associate actually needs — not just "what is Lambda," but why Lambda reserved concurrency is different from provisioned concurrency, when SnapStart eliminates the JVM cold start, how Fargate task definitions map CPU and memory, when App Runner beats ECS, and when EKS beats both. Serverless and containers together form the beating heart of Domain 2 on SAA-C03, so treating serverless and containers as one unified design space is the fastest route to exam-ready intuition.

What Is Serverless and What Are Containers on AWS

Serverless and containers are two execution paradigms that share one goal: let you ship application code without owning a virtual machine. On AWS, serverless and containers converge around a small list of services — AWS Lambda for serverless functions, AWS Fargate for serverless containers, Amazon ECS and Amazon EKS for container orchestration, and AWS App Runner for fully managed container-based web applications. Serverless and containers sit side-by-side in the SAA-C03 exam guide because the architect decision is almost always "which of the serverless and containers options fits this workload," not "serverless or EC2."

The SAA-C03 depth on serverless and containers goes well beyond CLF-C02. At associate level, you are expected to:

• Choose between serverless and containers for a given workload using latency, duration, concurrency, and operational budget as inputs.
• Configure AWS Lambda for production — runtime selection, memory tuning, timeout, VPC attachment, Layers, Destinations, dead-letter queues, reserved concurrency, provisioned concurrency, and SnapStart.
• Design ECS task definitions and services that integrate with Application Load Balancer, Auto Scaling, and AWS Fargate.
• Recognize when managed Kubernetes on Amazon EKS is worth the added control plane fee.
• Pick AWS App Runner as the fast-path answer for stateless web apps.
• Combine serverless and containers with event sources — API Gateway, EventBridge, SQS, SNS, S3, Kinesis — into production event-driven patterns.

Serverless and containers also overlap heavily with messaging-and-decoupling (the sibling topic) and with api-gateway-and-edge. Expect SAA-C03 scenarios to mix all three; this chapter keeps focus on the compute layer while pointing out the integration seams.

Why Serverless and Containers Dominate Domain 2

Domain 2 of SAA-C03 weighs 26 percent of the exam, and task statement 2.1 alone spawns roughly 450 questions in the ExamHub SAA-C03 budget. Within task 2.1, serverless and containers carry the largest share because almost every "design a scalable, loosely coupled architecture" scenario resolves to Lambda behind API Gateway, Fargate behind ALB, or an event-driven pipeline involving serverless and containers together. Mastering serverless and containers is the single highest-leverage activity you can do for SAA-C03.

Core Operating Principles of Serverless and Containers

Serverless and containers share three operating principles that show up in almost every SAA-C03 scenario.

Principle 1 — The Responsibility Gradient

Serverless and containers form a gradient of AWS-managed responsibility. At the left you manage the OS (EC2-backed ECS / EKS). In the middle, AWS manages the host but you still define CPU / memory per task (Fargate). At the right, AWS manages everything including scaling decisions (Lambda, App Runner). Each step right removes operational burden but also removes knobs. SAA-C03 questions use this gradient to filter services: "fully managed" → App Runner or Lambda, "I still need to pick instance type" → ECS on EC2 or EKS on EC2.

Principle 2 — Scale Unit Differs per Service

Serverless and containers all scale horizontally, but the unit of scale differs. Lambda scales invocations (per request). Fargate scales tasks (per container group). ECS services scale tasks behind a load balancer based on CloudWatch metrics. EKS scales pods via Horizontal Pod Autoscaler. App Runner scales concurrent request handlers. Knowing the scale unit tells you where the bottleneck will appear and which metric to watch.

Principle 3 — Pay for Active Work, Not for Idle Capacity

Serverless and containers on AWS are all billed for the work you actually do, but the granularity ranges from per-millisecond (Lambda) to per-second (Fargate, App Runner) to per-hour (EKS control plane). This pricing-shape difference drives cost optimization decisions covered in the cost-optimized-compute topic.

AWS Lambda Deep Dive for SAA-C03

AWS Lambda is the canonical serverless compute of serverless and containers on AWS. SAA-C03 tests Lambda far deeper than CLF-C02 — you need to configure Lambda for production, not just recognize it.

Lambda Runtimes and Packaging

Lambda supports managed runtimes (Python, Node.js, Java, Go, .NET, Ruby) plus custom runtimes via Lambda Runtime API or as a container image up to 10 GB. Deployment packages can be:

• Zip file uploaded directly (up to 50 MB zipped, 250 MB unzipped).
• Zip file referenced from S3 (same size limit).
• Container image from Amazon ECR (up to 10 GB).

Runtime choice matters for cold start: Python and Node.js typically start in under 200 ms, Go is similarly fast, Java and .NET historically cold-start in the 1–5 second range — which is why SnapStart exists.

Lambda Hard Limits You Must Memorize

• Timeout: 15 minutes (900 seconds) maximum per invocation. Default is 3 seconds.
• Memory: 128 MB minimum, 10,240 MB (10 GB) maximum, allocated in 1 MB increments. vCPU scales proportionally with memory, reaching 6 vCPUs at 10 GB.
• Ephemeral /tmp storage: 512 MB default, configurable up to 10,240 MB.
• Deployment package: 50 MB direct zip, 250 MB unzipped, 10 GB container image.
• Payload: 6 MB synchronous invocation, 256 KB asynchronous event.
• Environment variables: 4 KB total per function.
• Concurrent executions: 1,000 default per account per Region (soft limit, raise via Service Quotas).

Lambda Memory and Performance Tuning

Lambda memory is also the CPU dial. Doubling memory from 512 MB to 1,024 MB doubles vCPU allocation and often halves duration, which on net can reduce cost. Right-sizing memory is therefore both a performance and a cost exercise. AWS Lambda Power Tuning (open-source Step Functions state machine) is the canonical tool for automating this. SAA-C03 expects you to know that memory is the primary tuning lever for Lambda.

Lambda in a VPC

By default Lambda runs in an AWS-managed VPC with public internet egress. To reach private resources (RDS in private subnet, ElastiCache, internal ALB, on-prem via Direct Connect) you attach Lambda to your VPC by specifying subnets and security groups. Hyperplane ENIs (shared Elastic Network Interfaces) are created on a per-function per-subnet basis, so modern VPC-attached Lambda no longer suffers the old 10-second cold-start penalty.

Key VPC-attached Lambda facts for SAA-C03:

• Attach to at least two subnets in different AZs for high availability.
• VPC-attached Lambda cannot reach the public internet unless the subnet routes through a NAT gateway or VPC endpoint.
• To reach S3 or DynamoDB privately from VPC Lambda, use VPC Gateway Endpoints (free) rather than NAT gateway (paid).

Lambda Layers

Lambda Layers package shared libraries, dependencies, or custom runtimes as reusable artifacts attached to multiple functions. Each function can attach up to 5 layers, and total unzipped size across layers plus code must stay under 250 MB. Layers reduce deployment package size, centralize library updates, and let an organization share common code (logging, tracing, proprietary SDK wrappers) across dozens of functions without copy-pasting dependencies.

Typical Layers use cases:

• Packaging large dependencies (NumPy, Pandas) once for many Python functions.
• Distributing a company-wide observability SDK.
• Providing a custom runtime for a language Lambda does not manage natively.

Lambda Destinations

Lambda Destinations route the success or failure outcome of an asynchronous invocation to another AWS service without writing plumbing code. Supported destinations are SQS, SNS, EventBridge, and another Lambda function. Destinations replace ad hoc code that publishes results and are the successor pattern to only-DLQ handling.

• On success destination: receives the full request and response context; useful for chaining.
• On failure destination: receives after all retries exhausted; replaces or complements DLQ.

Lambda Concurrency Model — Reserved vs Provisioned

Concurrency is the number of simultaneously executing invocations of a Lambda function. SAA-C03 heavily tests two concurrency controls that are often confused.

Reserved concurrency guarantees a floor and caps a ceiling of concurrent executions for a function. The reserved value is both the maximum that function can reach and the amount carved out from the account-level pool. Reasons to set reserved concurrency:

• Protect a downstream system (e.g., an RDS database with a connection limit) from overwhelming parallelism.
• Guarantee a critical function always has concurrency available even when other functions burn through the account quota.
• Set reserved concurrency to zero to disable a function as a circuit breaker.

Provisioned concurrency pre-initializes a specified number of execution environments so they are warm and ready to respond with no cold start. Provisioned concurrency has its own hourly price on top of standard invocation cost and is the canonical cold-start mitigation for latency-critical APIs.

The crucial distinction for SAA-C03:

• Reserved concurrency is a limit (and reservation) on concurrency. It does not eliminate cold starts.
• Provisioned concurrency is a warm pool of pre-initialized environments. It eliminates cold starts for the provisioned count.
• The two can be combined: reserved = 200, provisioned = 50 means "cap at 200, keep 50 warm."

Lambda SnapStart

Lambda SnapStart dramatically reduces cold-start latency for Java, Python, and .NET functions by taking a Firecracker microVM snapshot of the initialized execution environment and restoring from that snapshot on cold start. SnapStart is free (no extra charge), has no per-hour cost like provisioned concurrency, and is the first choice for Java workloads with unpredictable traffic.

SnapStart key facts:

• Works with supported managed runtimes; not available for container-image functions.
• Snapshot is taken after the init phase, so any singleton client you create in init is captured warm.
• Because the snapshot is reused, you must be careful with uniqueness (random seeds, unique IDs generated once at init would repeat across restored envs). AWS provides runtime hooks to reinitialize such state.
• Cold starts drop from seconds to sub-second for typical Java Spring Boot apps.

Lambda Event Sources

Lambda is the Swiss Army knife of serverless and containers in part because of the huge list of event sources. Top SAA-C03-relevant sources:

• Synchronous invokers: API Gateway, Application Load Balancer, Cognito, Step Functions (Task states).
• Asynchronous invokers: S3 events, SNS, EventBridge, SES, CodeCommit.
• Poll-based (event source mapping): SQS, Kinesis Data Streams, DynamoDB Streams, Amazon MQ, Kafka (MSK and self-managed).

Each invoker class has different retry semantics — synchronous retries are the client's responsibility, async invokers retry twice with exponential backoff, poll-based sources re-deliver from the stream or queue. SAA-C03 scenarios on idempotency and retry typically hinge on which invoker class is in play.

AWS Fargate — Serverless Containers

AWS Fargate delivers the "serverless" half of serverless and containers at the container granularity. Fargate is not a separate orchestrator; it is a serverless compute engine that ECS and EKS can both target.

What Fargate Is and Is Not

Fargate is a serverless launch type for containers. You supply a task definition (ECS) or a pod spec (EKS) with CPU and memory requirements, and Fargate provisions the host capacity invisibly. Fargate is always used through ECS or EKS — you never use Fargate standalone.

Fargate key characteristics:

• Per-second billing for vCPU and memory reserved by the task.
• Task-level isolation (each task runs in its own microVM via Firecracker).
• No EC2 instances to patch, no host-level tuning, no cluster capacity planning.
• Supports Linux (x86 and Graviton ARM64) and Windows containers.

ECS Task Definition — Fargate Edition

An ECS task definition is the blueprint for your container. Key fields for SAA-C03:

• Family and revision — versioned identifier.
• Task CPU and task memory — total for the task. Fargate allows specific CPU / memory combinations (e.g., 0.25 vCPU with 0.5–2 GB, 1 vCPU with 2–8 GB, up to 16 vCPU with 120 GB).
• Network mode — must be awsvpc for Fargate. Each task gets its own ENI and primary private IP.
• Container definitions — image, port mappings, environment variables, secrets (from Secrets Manager or Parameter Store), log configuration (CloudWatch Logs, Firelens).
• Task role — IAM role granting the application code access to AWS services (e.g., read from an S3 bucket).
• Execution role — IAM role Fargate assumes to pull the ECR image and write logs on your behalf.

The distinction between task role and execution role is one of the highest-yield SAA-C03 details for Fargate.

Fargate Launch Type vs EC2 Launch Type

Amazon ECS supports two launch types: Fargate and EC2. Both run the same task definitions (with small network mode and volume differences), but the operating model differs.

• Fargate launch type: no EC2 to manage, per-second billing, slightly higher per-unit price, 20–60 s task startup time, ideal for variable or spiky workloads.
• EC2 launch type: you manage the EC2 cluster (capacity providers automate scaling), cheaper at steady state especially with Spot or Reserved Instances, can use instance-store disks, supports GPU and bare metal.

Amazon ECS — AWS-Native Container Orchestration

Amazon ECS is the AWS-native orchestrator for serverless and containers. ECS is deeply integrated with every AWS primitive (IAM, VPC, ALB, CloudWatch, EventBridge, Secrets Manager) and has no per-cluster control-plane fee. At SAA-C03 depth you must understand ECS task, service, and cluster roles plus their scaling behaviors.

ECS Building Blocks

• Cluster — logical grouping of compute capacity (Fargate tasks or EC2 instances registered as container instances).
• Task definition — blueprint (image, CPU, memory, networking, IAM, logging).
• Task — a running instantiation of a task definition.
• Service — a controller that keeps N desired tasks running and registers them with a load balancer target group. Services handle rolling and blue/green deployments.
• Container instance — an EC2 instance running the ECS agent; only relevant to EC2 launch type.
• Capacity provider — abstracts the compute backing a service (Fargate, Fargate Spot, EC2 Auto Scaling Group).

ECS Service Scaling

ECS services scale in two dimensions:

1. Service Auto Scaling (task count) — target tracking, step scaling, or scheduled scaling based on CloudWatch metrics like CPU utilization, memory utilization, ALB request count per target, or custom metrics.
2. Cluster Auto Scaling (EC2 launch type only) — capacity providers automatically scale the underlying Auto Scaling Group so pending tasks can be placed.

For SAA-C03, the common scaling pattern is: ALB in front of an ECS service, target tracking on ALBRequestCountPerTarget, backed by Fargate so you never worry about host-level scaling.

ECS Integration with ALB

ECS integrates natively with Application Load Balancer and Network Load Balancer via target groups. Each task registers its ENI and port with the target group on start and deregisters on stop. This enables zero-downtime rolling deployments and blue/green deployments (via CodeDeploy integration).

Amazon EKS — Managed Kubernetes

Amazon EKS is AWS's managed Kubernetes offering and the other major container orchestrator in serverless and containers on AWS. EKS runs upstream Kubernetes, is CNCF-conformant, and lets you bring any Kubernetes-native tooling (kubectl, Helm, Argo CD, Istio, Flux).

When to Choose EKS over ECS

• The team already operates Kubernetes clusters on-premises or on other clouds.
• You need multi-cloud or hybrid portability (same manifests run on EKS, GKE, AKS).
• You depend on Kubernetes-native software (operators, custom controllers).
• Your vendors ship Helm charts rather than AWS-native templates.
• Compliance, platform, or developer standardization requires Kubernetes APIs.

EKS costs $0.10 per cluster per hour for the control plane (roughly $73 per cluster per month), plus the underlying EC2 or Fargate compute. ECS control plane is free, which is why cost-sensitive SAA-C03 scenarios usually prefer ECS unless a clear Kubernetes requirement is stated.

EKS Compute Options

EKS supports three compute backends:

• Managed node groups — EKS provisions and manages an EC2 Auto Scaling Group of worker nodes.
• Self-managed nodes — you provision your own EC2 instances and join them to the cluster.
• Fargate profiles — pods matching a profile run on Fargate, serverless.

Fargate-backed EKS delivers the serverless and containers promise at the Kubernetes layer, though some cluster-wide daemons (CNI plugins, log agents via DaemonSet) do not run on Fargate and still require managed nodes for cluster add-ons.

AWS App Runner — Fully Managed Containers for Web Applications

AWS App Runner is the newest member of serverless and containers on AWS and the simplest. App Runner runs stateless web applications and APIs from a container image (ECR) or directly from source code (GitHub) with zero infrastructure decisions — no VPC, no load balancer, no auto scaling policy to tune.

App Runner Key Capabilities

• Deploy from ECR image or GitHub source with automatic builds.
• Automatic HTTPS endpoint with managed TLS certificate.
• Auto-scaling concurrency from zero to configurable maximum based on concurrent requests per instance.
• Built-in private VPC connector to reach RDS, ElastiCache, or internal services.
• Per-second billing for vCPU, memory, and a small per-request fee.

App Runner is ideal for SaaS backends, internal tools, prototype APIs, and any stateless web workload that would otherwise need a small Fargate service. The trade-off is less flexibility: no sidecars, no custom networking beyond the VPC connector, no WebSocket (at time of SAA-C03 v1.5 of the exam guide), and no non-HTTP workloads.

When App Runner Wins Over ECS or Lambda

• Stateless HTTP API that needs to run longer than 15 minutes per request (rules out Lambda).
• Team wants zero infrastructure to manage and is fine with opinionated defaults (rules out ECS setup overhead).
• Traffic is moderate and variable; scale-to-zero saves money.
• Deployment simplicity is paramount — push to main, App Runner redeploys.

AWS Step Functions — Orchestrating Serverless and Containers

Step Functions is the orchestration layer that stitches serverless and containers into durable workflows. You describe a state machine in Amazon States Language (JSON) with states like Task, Choice, Parallel, Map, and Wait. Each Task state can invoke Lambda, run an ECS task, call any AWS SDK action, or wait for a callback.

SAA-C03 reasons to add Step Functions to a serverless and containers design:

• Orchestrate a multi-step pipeline across Lambda, ECS, and SQS with visual state tracking.
• Replace home-grown retry, timeout, and error-handling code with declarative configuration.
• Coordinate long-running workloads by chaining shorter Lambda invocations within the 1-year maximum Standard workflow duration (or 5 minutes for Express workflows).
• Fan out parallel processing with Map state and aggregate results.

Express vs Standard workflows are a common SAA-C03 detail: Standard for long-running durable (up to 1 year, exactly-once, at-least-once steps), Express for high-volume event-processing (up to 5 minutes, at-least-once, at most 100,000 state transitions per second).

Cold Start Mitigation Strategies for Serverless and Containers

Cold starts are the single most-tested latency concern in serverless and containers on SAA-C03. Here is the full toolkit, ranked.

1. Choose a fast-starting runtime — Python, Node.js, Go cold-start fastest; Java and .NET slowest.
2. Keep deployment packages small — prune unused dependencies, separate shared code into Layers.
3. Lazy-initialize heavy SDK clients outside the handler but avoid global state that breaks SnapStart.
4. Enable SnapStart for Java, Python, .NET — free, snapshot-based init acceleration.
5. Configure Provisioned Concurrency for latency-critical APIs — keep N execution environments warm.
6. Increase memory — bigger memory means more CPU, so init and handler both run faster.
7. Remove VPC attachment if the function does not need private resources — though modern VPC-attached Lambda is much faster than it used to be.
8. Pre-warm Fargate services — maintain a minimum task count so scale-out events are not on the critical path.

Event-Driven Patterns Combining Serverless and Containers

Serverless and containers on AWS shine brightest when combined with event sources into reusable patterns. SAA-C03 loves pattern-matching questions.

Pattern 1 — API Gateway + Lambda + DynamoDB

The canonical three-tier serverless pattern. API Gateway terminates HTTPS, enforces auth via Cognito or Lambda authorizer, rate-limits, and forwards to Lambda. Lambda reads and writes DynamoDB. End-to-end zero servers to manage, scales from zero to tens of thousands of requests per second.

Pattern 2 — S3 Event → Lambda → Downstream

User uploads object, S3 publishes an object-created event, Lambda processes (generate thumbnail, extract text, validate), output lands in another S3 bucket or DynamoDB. Use SNS or EventBridge in the middle if multiple consumers need the event.

Pattern 3 — SQS → Lambda (Poll-Based)

Queue smooths traffic bursts; Lambda event source mapping polls SQS in batches. Use reserved concurrency to protect a downstream database from Lambda's parallelism. Use a DLQ or Lambda Destination for failure.

Pattern 4 — Fargate Worker Pool + SQS

For CPU-heavy or long-running (> 15 min) tasks, replace Lambda with a Fargate service that polls SQS. Scale tasks on queue depth (CloudWatch custom metric or SQS ApproximateNumberOfMessages target tracking).

Pattern 5 — EventBridge + Many Targets

EventBridge event bus receives events from SaaS partners, custom apps, or AWS services; rules route to Lambda, Step Functions, Fargate task, SQS, or Kinesis. The fan-out and content-based routing pattern of choice.

Pattern 6 — Step Functions Orchestration of Lambda and ECS Tasks

Step Functions coordinates a pipeline: ingest with Lambda, transform with Fargate ECS task (runs 30 minutes), notify with SNS. Explicit state machine gives operational visibility and declarative retry.

When to Choose Which — The Serverless and Containers Decision Framework

SAA-C03 rewards a clear decision process. Walk through these filters in order.

Step 1 — Duration Filter

• Every invocation finishes in under 15 minutes? Lambda is possible.
• Some invocations run longer? Rule out Lambda; move to containers or EC2.

Step 2 — Packaging Filter

• Code is a single function triggered by an event? Lambda.
• Code is a full application with multiple processes, sidecars, or non-HTTP workloads? Containers.
• Code is a stateless HTTP service from a Git repo or single image? App Runner is worth considering.

Step 3 — Orchestration Filter

• No Kubernetes requirement, want AWS-native, lowest control-plane cost? ECS.
• Team already operates Kubernetes or needs portability? EKS.
• Want zero orchestration decisions? App Runner.

Step 4 — Host-Management Filter

• No EC2 to manage, per-task billing, variable load? Fargate (on ECS or EKS).
• Need specific instance types, GPU, or steady-state cost optimization? EC2 launch type (on ECS or EKS).

Step 5 — Cost-Optimization Filter

• Bursty or unpredictable? Lambda or Fargate.
• Steady and high-volume? Containers on EC2 with Savings Plans or Spot.
• Interruption-tolerant batch? Fargate Spot or EC2 Spot.

Stateless vs Stateful in Serverless and Containers

Serverless and containers on AWS work best for stateless workloads. Stateful workloads need a conscious design choice about where state lives.

• Lambda — fully stateless by design; any required state belongs in DynamoDB, RDS (via RDS Proxy), ElastiCache, or S3.
• Fargate tasks — ephemeral by default; use EFS volumes for shared state or external datastores.
• ECS / EKS on EC2 — can use instance-store for local high-speed state, but treat any node as cattle-not-pets.
• App Runner — stateless only; no persistent volumes.

For databases, managed services (Amazon RDS, Aurora, DynamoDB, ElastiCache, MemoryDB) are the default SAA-C03 answer; self-managed databases on containers only appear in narrow edge cases.

Key Numbers to Memorize for Serverless and Containers

• Lambda timeout: 15 minutes (900 seconds) maximum, 3 seconds default.
• Lambda memory: 128 MB to 10,240 MB in 1 MB increments; 6 vCPUs at 10 GB.
• Lambda /tmp: 512 MB default, up to 10,240 MB configurable.
• Lambda deployment package: 50 MB zipped direct, 250 MB unzipped, 10 GB container image.
• Lambda payload: 6 MB synchronous, 256 KB asynchronous.
• Lambda concurrent executions: 1,000 per Region default (soft limit).
• Lambda Layers: 5 layers per function, 250 MB total unzipped including code.
• Fargate CPU/memory combos: 0.25 vCPU (0.5–2 GB) up to 16 vCPU (30–120 GB).
• Fargate Spot discount: up to 70 percent.
• ECS control plane: free.
• EKS control plane: $0.10 per cluster per hour (~$73 per month).
• Step Functions Standard workflow duration: up to 1 year per execution.
• Step Functions Express workflow duration: up to 5 minutes per execution.
• App Runner billing: per-second vCPU and memory plus per-request fee.

Common Exam Traps in Serverless and Containers

Trap patterns repeat on every SAA-C03 attempt. Knowing them is free points.

Trap 1 — Lambda for Long-Running Jobs

"Process a 3-hour batch job" is never Lambda. The answer is AWS Batch on Fargate or EC2, an ECS task, or Step Functions orchestrating multiple shorter Lambda invocations with Map state.

Trap 2 — Reserved Concurrency Confused With Provisioned Concurrency

Reserved caps and reserves quota; provisioned pre-warms environments. If the question asks about cold starts, provisioned concurrency or SnapStart is correct — not reserved.

Trap 3 — Fargate Treated as a Peer of ECS

Fargate is a launch type for ECS and EKS, not a separate orchestrator. The correct phrasing is "ECS on Fargate" or "EKS on Fargate."

Trap 4 — EKS Chosen When ECS Is Cheaper and Sufficient

If the scenario does not mention Kubernetes, Helm, multi-cloud, or open-source operators, ECS on Fargate is usually the right (and cheaper) answer.

Trap 5 — VPC-Attached Lambda Assumed to Have Internet Access

VPC Lambda needs a NAT gateway in a public subnet for internet egress, or VPC endpoints for AWS service access. This trap appears in scenarios mentioning external API calls.

Trap 6 — DLQ Treated as Sufficient Observability

Modern architectures use Lambda Destinations for both success and failure routing. DLQ is a legacy subset.

Trap 7 — App Runner Ignored

SAA-C03 added App Runner to the supported services list. For a stateless HTTP API from a Git repo or single image, App Runner is often the best answer — but candidates unfamiliar with the service default to ECS on Fargate.

Serverless and Containers vs Neighboring Topics — Boundary Lines

SAA-C03 keeps serverless and containers separate from closely-related topics. Know the borders.

• serverless-and-containers vs messaging-and-decoupling (both task 2.1) — the compute side vs the messaging side. SQS, SNS, EventBridge live in messaging; Lambda and Fargate live here. Most exam scenarios combine both.
• serverless-and-containers vs elastic-compute-scaling (task 3.2) — this topic covers what runs; elastic-compute-scaling covers how it scales and is sized. Lambda concurrency tuning is shared between topics; instance-family selection lives in elastic-compute-scaling.
• serverless-and-containers vs cost-optimized-compute (task 4.2) — the cost view of the same services. Spot Fargate, Lambda memory tuning, and Savings Plans for Compute live in cost-optimized-compute.
• serverless-and-containers vs api-gateway-and-edge (task 2.1) — API Gateway is the trigger, Lambda is the compute. The integration pattern crosses both topics.
• serverless-and-containers vs high-availability-multi-az (task 2.2) — Lambda and Fargate provide HA by default across AZs; multi-Region HA lives in high-availability-multi-az.

Practice Question Signals — Task 2.1 Mapped Exercises

Use the SAA-C03 question bank to drill serverless and containers patterns. Signal phrases and correct answers:

1. "Process image upload events with minimal operational overhead" → S3 event → Lambda.
2. "Run a stateless HTTP API from a Git repository with no infrastructure management" → AWS App Runner.
3. "Containerized microservices with team that already knows Kubernetes" → Amazon EKS.
4. "Long-running container task (> 15 minutes) with no EC2 to manage" → ECS on Fargate.
5. "Reduce cold-start latency for Java API without added hourly cost" → Lambda SnapStart.
6. "Guarantee zero cold starts for latency-critical endpoint" → Lambda Provisioned Concurrency.
7. "Prevent a Lambda function from overwhelming an RDS database" → Reserved concurrency on the Lambda function.
8. "Coordinate Lambda and Fargate steps in a multi-step workflow with built-in retry and visualization" → AWS Step Functions.
9. "Fan-out events from one source to multiple Lambda functions and an SQS queue" → EventBridge or SNS.
10. "Run batch workloads longer than 15 minutes cost-effectively on interruptible capacity" → AWS Batch on Fargate Spot or EC2 Spot.

FAQ — Serverless and Containers Top Questions

Q1. When should I choose AWS Lambda over Fargate for serverless and containers workloads?

Choose AWS Lambda when the workload is event-driven, finishes each invocation in under 15 minutes, benefits from per-millisecond billing, and does not need custom networking stacks or sidecars. Choose AWS Fargate when the workload is a long-running container, needs multi-container task design with sidecars, runs non-HTTP protocols, or exceeds the 15-minute Lambda timeout. Many production architectures use both: Lambda for event glue and synchronous APIs, Fargate for background workers and CPU-heavy tasks.

Q2. What is the difference between reserved concurrency and provisioned concurrency in AWS Lambda?

Reserved concurrency sets both a ceiling and a guaranteed floor of concurrent executions for a single Lambda function, carving that count out of the account-level concurrency pool. Reserved concurrency does not eliminate cold starts. Provisioned concurrency pre-initializes a specified number of execution environments so they are ready to respond immediately with no cold start, costs an hourly fee on top of invocation charges, and is the right choice for latency-critical APIs. The two can be used together: reserved concurrency caps total parallelism while provisioned concurrency warms a subset of those environments.

Q3. How does Lambda SnapStart reduce cold starts and when should I use it instead of provisioned concurrency?

Lambda SnapStart takes a snapshot of the initialized execution environment after the init phase completes and restores from that snapshot when a cold start is needed. For supported runtimes — Java, Python, and .NET managed runtimes — SnapStart can drop cold-start latency from several seconds to sub-second at no additional cost. Use SnapStart first when it is available because it is free. Use provisioned concurrency when SnapStart is not supported (container images, unsupported runtimes), when you need guaranteed sub-100 ms p99 latency regardless of initialization complexity, or when your function uses dynamic state that would break SnapStart semantics.

Q4. When should I use Amazon EKS instead of Amazon ECS for container orchestration?

Choose Amazon EKS when your team already operates Kubernetes on-premises or on another cloud and wants portable manifests, when you rely on the Kubernetes ecosystem (Helm, operators, service meshes like Istio, GitOps tools like Argo CD), when vendor software ships as Kubernetes manifests, or when organizational standardization mandates Kubernetes APIs. Choose Amazon ECS when you want the fastest path from Dockerfile to production on AWS, deep native integration with IAM / CloudWatch / ALB, the lowest control-plane cost (ECS control plane is free vs EKS at $0.10 per cluster per hour), or simpler mental models without Kubernetes-specific concepts. For most greenfield AWS-only workloads, ECS on Fargate is the fastest and cheapest choice.

Q5. When is AWS App Runner the right answer over ECS on Fargate?

AWS App Runner is the right answer for stateless HTTP web applications and APIs when the team wants zero infrastructure to manage. App Runner handles the load balancer, HTTPS certificate, auto scaling, deployments, and VPC connector automatically. Choose App Runner when the workload is HTTP-only, stateless, can run from an ECR image or GitHub source, and the team prefers opinionated defaults. Choose ECS on Fargate when you need full networking control, multi-container tasks with sidecars, non-HTTP protocols, or fine-grained deployment strategies like blue/green with CodeDeploy.

Q6. How do I run workloads longer than 15 minutes without Lambda in the serverless and containers space?

Workloads that exceed Lambda's 15-minute timeout have several serverless and containers options. ECS on Fargate and EKS on Fargate run containers for any duration with no host management. AWS Batch orchestrates long-running batch jobs on Fargate or EC2 with queuing, retries, and Spot support. Step Functions Standard workflows coordinate multi-step processes for up to 1 year, chaining shorter Lambda invocations with Map and Parallel states. For the lowest operational overhead of a long-running HTTP service, AWS App Runner also works. The decision usually hinges on whether the workload is HTTP (App Runner or Fargate behind ALB), batch (AWS Batch), or multi-step orchestration (Step Functions driving Lambda and Fargate).

Q7. What are the right event-driven patterns to combine serverless and containers on AWS?

The canonical event-driven patterns combining serverless and containers on AWS are: API Gateway + Lambda + DynamoDB for three-tier serverless APIs; S3 events → Lambda for object-processing pipelines; SQS → Lambda with reserved concurrency for protected downstream systems; SQS → Fargate worker pool for CPU-heavy or long-running tasks; EventBridge rules routing to Lambda, Step Functions, Fargate, or SNS for fan-out and content-based routing; and Step Functions orchestrating Lambda and Fargate tasks for durable multi-step workflows. Kinesis Data Streams or DynamoDB Streams → Lambda event source mapping covers real-time streaming processing. The SAA-C03 exam rewards recognizing these patterns from scenario wording more than memorizing service details.

Summary — Serverless and Containers at a Glance

• Serverless and containers on AWS span AWS Lambda (functions), AWS Fargate (serverless containers), Amazon ECS (AWS-native orchestration), Amazon EKS (managed Kubernetes), and AWS App Runner (fully managed container web apps).
• Lambda has a hard 15-minute ceiling, memory 128 MB to 10 GB, VPC-attachable, supports Layers, Destinations, reserved concurrency, provisioned concurrency, and SnapStart.
• Reserved concurrency caps parallelism; provisioned concurrency pre-warms environments; SnapStart snapshots the init phase for zero-cost cold-start reduction on Java, Python, .NET.
• Fargate is a serverless launch type used by ECS and EKS — never a standalone orchestrator. Task definitions capture CPU, memory, networking, IAM roles, logging.
• ECS is free at the control plane and the fastest path for AWS-native containers. EKS costs $0.10 per cluster per hour and is the right answer when Kubernetes portability or ecosystem is required.
• App Runner is the "zero-decision" option for stateless HTTP apps from ECR or GitHub.
• Cold start mitigation ranks: fast runtime → small package → SnapStart → provisioned concurrency → larger memory.
• Serverless and containers combine with SQS, SNS, EventBridge, Kinesis, and Step Functions into reusable event-driven patterns that dominate SAA-C03 Domain 2.
• Apply the decision framework in order: duration filter → packaging filter → orchestration filter → host-management filter → cost-optimization filter.

Master serverless and containers at this depth and the 450-question Domain 2.1 slice of SAA-C03 becomes pattern recognition rather than memorization. The same mental model carries into DVA-C02 and SAP-C02 when you continue the AWS certification path.