3.2 Lambda, Serverless Compute, and Container Services

AWS Solutions Architect Associate SAA-C03

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the AWS Solutions Architect Associate (SAA-C03) Exam Study Strategies and Exam Tips for SAA-C03 The AWS Well-Architected Framework

2 Domain 1: Design Secure Architectures (30%)

1.1 IAM Fundamentals — Users, Groups, Roles, and Policies 1.2 AWS Organizations, SCPs, and Multi-Account Strategy 1.3 VPC Security — Security Groups, NACLs, and VPC Endpoints 1.4 Encryption, KMS, and Secrets Management 1.5 AWS WAF, Shield, and Network Firewall 1.6 GuardDuty, Inspector, Macie, and Security Hub 1.7 The Shared Responsibility Model for Solutions Architects 1.8 Data Protection, Compliance, and Audit Services

3 Domain 2: Design Resilient Architectures (26%)

2.1 Elastic Load Balancing (ELB) — ALB, NLB, and GWLB 2.2 EC2 Auto Scaling — Dynamic, Predictive, and Scheduled 2.3 Multi-AZ and Multi-Region Architectures 2.4 Disaster Recovery Strategies — RTO and RPO 2.5 Decoupling with SQS, SNS, and EventBridge 2.6 AWS Step Functions and Workflow Orchestration

4 Domain 3: Design High-Performing Architectures (24%)

3.1 EC2 Instance Types, Purchasing Options, and Placement Groups 3.2 Lambda, Serverless Compute, and Container Services 3.3 Amazon S3 - Storage Classes, Lifecycle, and Performance 3.4 Block and File Storage - EBS, EFS, and FSx 3.5 Database Services - RDS, Aurora, DynamoDB, and More 3.6 CloudFront, Route 53, and Global Accelerator 3.7 Data Ingestion and Transformation - Kinesis, Glue, and EMR

5 Domain 4: Design Cost-Optimized Architectures (20%)

4.1 Compute Cost Optimization — Right-Sizing, RIs, Savings Plans, and Spot 4.2 Storage Cost Optimization — S3 Tiers, EBS, and Data Transfer 4.3 Database Cost Optimization 4.4 AWS Cost Management and Monitoring Tools

6 VPC and Networking Deep Dive

5.1 VPC Architecture — Subnets, Route Tables, and Gateways 5.2 VPC Connectivity — Peering, Transit Gateway, and Direct Connect 5.3 Amazon API Gateway 5.4 CloudFormation and Infrastructure as Code 5.5 AWS PrivateLink and Endpoint Services

7 Migration, Transfer, and Hybrid Services

6.1 The 7 Rs of Cloud Migration 6.2 AWS Snow Family — Snowball Edge Devices 6.3 CloudWatch, CloudTrail, and AWS Config 6.4 Amazon Cognito and Identity Federation 6.5 AWS DataSync and Transfer Family

8 Serverless Architecture and Application Services

7.1 Serverless Architecture Patterns 7.2 Advanced SQS Patterns — DLQ, Backpressure, and FIFO 7.3 Analytics Services — Athena, OpenSearch, and QuickSight 7.4 Container Orchestration — ECS, EKS, and ECR

9 Advanced Topics and Exam Scenarios

8.1 Advanced IAM — Permission Boundaries, Federation, and Cross-Account 8.2 Caching Strategies and ElastiCache Patterns 8.3 Hybrid Architecture — DNS, Storage, and Compute 8.4 SAA-C03 Scenario Practice — Putting It All Together

3.2 Lambda, Serverless Compute, and Container Services

Key Takeaways Explain This Topic AI

Lambda runs event-driven code with no servers, scales automatically per request, and bills per request plus GB-second of duration.

Lambda limits: 15-minute (900s) max timeout for standard functions (Lambda Managed Instances allow up to 90 minutes for asynchronous and event-source-mapping invocations), 128 MB-10,240 MB memory, 512 MB-10 GB ephemeral /tmp, 6 MB synchronous and 1 MB asynchronous payloads.

ECS orchestrates Docker containers on EC2 or Fargate; EKS runs upstream-compatible Kubernetes on EC2 or Fargate.

Fargate is serverless container compute - you declare vCPU and memory, AWS owns the host, and you pay per vCPU/GB-second.

Decision rule: short event task -> Lambda; containers with least ops -> Fargate; containers needing host/GPU/daemon control -> ECS/EKS on EC2; existing Kubernetes -> EKS.

Last updated: October 2026

Quick Answer: Lambda = event-driven, <=15 min, zero servers, scales to thousands instantly. Fargate = serverless containers, no host to patch. ECS on EC2 = Docker with full host control. EKS = managed Kubernetes control plane. Pick on execution duration, control needs, and how much operations you are willing to own.

AWS Lambda

AWS Lambda runs a function in response to an event and tears the environment down afterward. You never provision capacity; concurrency scales with incoming events. Pricing is per request plus per GB-second of compute, where vCPU is allocated proportionally to the memory you set (1,769 MB ~= 1 full vCPU), so raising memory can finish CPU-bound work faster and cheaper.

Lambda Limits (memorize these)

Dimension Limit

Max timeout 15 minutes (900 seconds); with Lambda Managed Instances, up to 90 minutes for asynchronous and event-source-mapping invocations (except Amazon MQ and Amazon DocumentDB)

• Memory 128 MB to 10,240 MB
• Ephemeral storage (/tmp) 512 MB to 10,240 MB

Concurrent executions 1,000 per Region default (soft, raise via quota; new accounts start lower and AWS raises the quota automatically with usage)

• Deployment package 50 MB zipped / 250 MB unzipped, or 10 GB container image
• Synchronous payload 6 MB request and response
• Asynchronous payload 1 MB
• Environment variables 4 KB total
• Lambda Invocation Models

• Source Invocation Notes
• API Gateway / ALB Synchronous Caller waits for the response (6 MB cap)
• S3 / SNS / EventBridge Asynchronous Internal queue, automatic retries, send failures to a DLQ
• SQS / Kinesis / DynamoDB Streams Event-source mapping (poll) Lambda polls and invokes in batches

Cold starts add latency on the first invoke of a new environment. Use Provisioned Concurrency to pre-warm latency-sensitive functions, and Reserved Concurrency to cap a function so it cannot starve other functions of the account pool. When work exceeds 15 minutes, hand off to Step Functions , Fargate , or AWS Batch instead of forcing it into Lambda.

Amazon ECS (Elastic Container Service)

ECS is AWS-native Docker orchestration. Core objects: a task definition (the blueprint - image, vCPU, memory, ports, env, IAM task role), a task (a running instance of that definition), a service (keeps a desired task count and registers with a load balancer), and a cluster (logical grouping).

• EC2 launch type Fargate launch type
• Host management You patch and scale EC2 AWS owns the host
• Scaling You scale the EC2 capacity Per task, automatic
• Billing EC2 instance price Per vCPU + GB per second
• Host access / daemons Full (SSH, GPU, custom agents) None
• Best for GPU, dense bin-packing, custom kernels Simplicity, least ops
• Amazon EKS (Elastic Kubernetes Service)

EKS runs an AWS-managed, multi-AZ Kubernetes control plane ; you bring worker capacity as EC2 managed node groups, self-managed nodes, or Fargate. Because it tracks upstream Kubernetes, existing manifests, Helm charts, and kubectl tooling work unchanged - the right answer whenever a question mentions an existing Kubernetes investment or portability across clouds.

AWS Fargate

Fargate is the serverless data plane for both ECS and EKS. You declare vCPU and memory per task; AWS provisions, isolates, and patches the host. Each task runs in its own kernel boundary for strong isolation, and billing is per vCPU and GB per second. Fargate is the default "least operational overhead" container answer unless the workload needs host access, GPUs, privileged daemons, or very dense bin-packing.

Choosing the Right Compute

• Scenario Best service
• Event-driven glue, <=15 min Lambda
• Containers with minimal ops ECS or EKS on Fargate
• Containers needing host/GPU control ECS or EKS on EC2
• Long-running stateful single node EC2
• Large-scale batch AWS Batch (EC2 or Fargate)
• Existing Kubernetes migration EKS

On the Exam: "Least operational overhead to run containers" -> Fargate. "Run code when an object lands in S3" -> Lambda. "Migrate a Kubernetes app keeping existing tooling" -> EKS. "Job runs 40 minutes" -> NOT a standard Lambda function (exceeds the 15-minute cap).

Worked Scenario: Picking the Compute Tier

A team receives image uploads to an S3 bucket and must generate three thumbnail sizes per image, then notify a downstream system. Each transform takes about eight seconds. Because the work is event-driven, short, and stateless, Lambda triggered by an S3 event is the strongest answer: it scales to thousands of concurrent invocations automatically and bills only for the seconds it runs. If the same team also runs a long-lived API behind a load balancer that occasionally serves heavy 30-minute report generations, that report job exceeds Lambda's 900-second ceiling, so it belongs on Fargate (or AWS Batch) instead.

This split - Lambda for the fast event handler, Fargate for the long task - is exactly the trade-off the exam wants you to recognize.

Common Traps to Avoid

Forcing long jobs into Lambda. A standard Lambda function cannot run longer than 15 minutes - more memory or Provisioned Concurrency does not help. (Lambda Managed Instances raise the cap to 90 minutes only for asynchronous and event-source-mapping invocations.) Move it to Fargate, Step Functions, or AWS Batch.

Choosing ECS-on-EC2 when the question says "least operational overhead." Managing EC2 hosts (patching, scaling, capacity) is operational overhead; Fargate removes it. Only pick EC2-backed when the workload needs host access, GPUs, privileged daemons, or dense bin-packing.

Picking ECS when an existing Kubernetes investment is mentioned. Re-platforming working Kubernetes manifests to the ECS API is rework; EKS keeps them.

Ignoring concurrency limits. A burst that exceeds the 1,000 default concurrent executions throttles unless you raise the quota or use Reserved Concurrency to protect critical functions.

Cold-start latency. For latency-sensitive synchronous APIs, plain on-demand Lambda may add cold-start delay; Provisioned Concurrency pre-warms environments to eliminate it.