AWS SAA-C03: Containers, Serverless, DynamoDB & Cognito — 10 Concepts Worth Knowing
This post covers the AWS container, serverless, and database services that appear heavily on the SAA-C03 exam — ECS, EKS, Fargate, Lambda, DynamoDB, API Gateway, Step Functions, and Cognito. For each one, the focus is on what the exam actually tests, not what the documentation says.
1. ECS Launch Types — EC2 vs Fargate
ECS (Elastic Container Service) runs Docker containers on AWS. It has two launch types with completely different operational models:
EC2 Launch Type:
- You provision and manage the underlying EC2 instances
- The ECS agent runs on each instance and communicates with the ECS control plane
- AWS handles starting and stopping containers — you handle the instances they run on
- More control, more operational overhead
Fargate Launch Type:
- Fully serverless — no EC2 instances to provision, patch, or scale
- Define CPU and memory per task; AWS runs it
- Just create task definitions and Fargate handles the rest
- You pay per task, not per instance
Exam shortcut: Any question containing "no infrastructure to manage," "serverless containers," or "don't want to manage EC2" → Fargate.
2. ECS IAM Roles — Two Roles, Completely Different Jobs
ECS uses two distinct IAM roles. Confusing them is one of the most common exam mistakes:
EC2 Instance Profile (EC2 Launch Type only):
- Attached to the EC2 instance, used by the ECS agent
- Lets the agent: pull images from ECR, send logs to CloudWatch, access Secrets Manager / Parameter Store
- This is infrastructure-level access — the host needs it to run containers
ECS Task Role:
- Attached to the task definition — your container's application code uses this
- Each service should have its own Task Role with only the permissions it needs
- Example: a container that reads from S3 needs an S3 read permission in its Task Role, not in the Instance Profile
The exam trap: A question asks which role allows a container to read from S3. The answer is Task Role — not Instance Profile.
3. EKS — Managed Kubernetes on AWS
EKS (Elastic Kubernetes Service) runs managed Kubernetes clusters. The exam doesn't test Kubernetes internals — it tests when you'd choose EKS over ECS.
Choose EKS when:
- The team already uses Kubernetes on-premises or on another cloud
- You need cloud-agnostic portability (Kubernetes works on Azure and GCP too)
- You're lifting and shifting an existing K8s workload to AWS
EKS node options:
- Managed Node Groups: AWS creates and manages EC2 instances in an ASG
- Self-Managed Nodes: you create EC2s and register them to the cluster
- Fargate: no nodes at all — fully serverless
EKS storage: Uses a Container Storage Interface (CSI) driver. Supported: EBS (single-AZ), EFS (multi-AZ, works with Fargate), FSx for Lustre, FSx for NetApp ONTAP.
Exam shortcut: "Company already uses Kubernetes" = EKS. "Starting fresh on AWS" = ECS.
4. Lambda — The Limits That Appear in Questions
Lambda is a major exam topic and specific numbers appear in exam questions directly:
| Limit | Value |
|---|---|
| Memory | 128 MB – 10 GB (1 MB increments) |
| Max execution time | 900 seconds (15 minutes) |
| Tmp disk (/tmp) | 512 MB – 10 GB |
| Concurrency | 1,000 per region (increasable via support ticket) |
| Deployment zip | 50 MB compressed / 250 MB uncompressed |
| Environment variables | 4 KB |
Key behaviours:
- Increasing RAM also scales CPU and network — they're linked
- Container images can be used as Lambda packages (must implement Lambda Runtime API)
- For arbitrary Docker images → ECS/Fargate, not Lambda
- The 15-minute limit is the most-used exam filter: any workload needing longer than 15 minutes eliminates Lambda as an option
5. Lambda Concurrency — The Regional Throttling Trap
Lambda concurrency is shared across all functions in a region. This creates a specific failure mode the exam tests:
The problem:
All Lambda functions in a region share 1,000 concurrent executions. If one high-traffic function consumes all 1,000, every other Lambda function in that region gets throttled — even completely unrelated ones.
The fix: Set Reserved Concurrency on each function to cap its maximum concurrency and protect the region's shared pool.
Throttle behaviour by invocation type:
- Synchronous (API Gateway → Lambda): returns ThrottleError 429 immediately
- Asynchronous (S3 event → Lambda): retries automatically, then routes to Dead Letter Queue (DLQ)
Provisioned Concurrency: Pre-warms Lambda execution environments to eliminate cold start latency. Lambda SnapStart (Java only) achieves the same by snapshotting the initialised environment.
6. Lambda at the Edge — CloudFront Functions vs Lambda@Edge
When you need to run logic at CloudFront edge locations, AWS gives you two options:
CloudFront Functions:
- JavaScript only
- Sub-millisecond startup, millions of requests per second
- Can only intercept Viewer Request and Viewer Response
- Native CloudFront feature — managed entirely within CloudFront
- Use for: URL rewrites, header manipulation, lightweight auth token checks
Lambda@Edge:
- Node.js or Python
- More compute time, heavier logic
- Intercepts all four CloudFront events: Viewer Request, Origin Request, Origin Response, Viewer Response
- Use for: complex routing, A/B testing, full authentication at the edge
Lambda in VPC: Lambda runs outside your VPC by default. To reach RDS, ElastiCache, or internal services, deploy Lambda into a VPC subnet with a security group. It uses an ENI to connect.
7. DynamoDB Capacity Modes — Provisioned vs On-Demand
DynamoDB is a fully managed NoSQL database. The exam tests capacity mode selection heavily:
Provisioned Mode (default):
- Define Read Capacity Units (RCU) and Write Capacity Units (WCU) in advance
- Add auto-scaling to adjust based on CloudWatch metrics
- Cheaper per operation for stable, predictable traffic
On-Demand Mode:
- Scales instantly with zero capacity planning
- Pay per request — more expensive per operation
- Right answer for: new applications with unknown traffic, workloads with steep sudden spikes
DynamoDB core model:
- Tables made of Items, each with Attributes — flexible schema (attributes can differ per item)
- Primary Key: Partition Key alone, or Partition Key + Sort Key (composite)
- Max item size: 400 KB
- Data types: Scalar (String, Number, Binary, Boolean, Null), Document (List, Map), Sets
Exam shortcut: "Traffic is unpredictable / spike-heavy" = On-Demand. "Steady, cost-sensitive workload" = Provisioned with auto-scaling.
8. DAX vs ElastiCache — Caching DynamoDB Reads
Both are in-memory caches. The exam tests which to use for DynamoDB:
DynamoDB Accelerator (DAX):
- Purpose-built for DynamoDB — sits transparently in front of the table
- Microsecond read latency for cached items
- No application code changes — uses the same DynamoDB API
- Caches individual item lookups and query/scan results
- Default 5-minute TTL
ElastiCache (Redis or Memcached):
- General-purpose cache
- Used to store aggregated or computed results (e.g. leaderboard totals, session data)
- Requires explicit cache logic in application code — populate, read, and invalidate manually
Exam shortcut:
- "Cache DynamoDB reads with no code change" → DAX
- "Cache computed or aggregated results" → ElastiCache
9. DynamoDB Streams and Global Tables
DynamoDB Streams:
- An ordered, time-stamped log of every item-level change (create, update, delete)
- 24-hour retention
- Trigger Lambda functions in response — the standard serverless event-driven pattern
- Use cases: send notifications on new records, replicate to another table, real-time analytics
DynamoDB Global Tables:
- Multi-region, active-active replication
- Applications can read AND write to the table in any configured region
- Changes replicate to all regions automatically
- Pre-requisite: DynamoDB Streams must be enabled
TTL (Time to Live): Set an expiry timestamp attribute on any item. DynamoDB deletes expired items automatically at no cost. Use for: session tokens, temporary cache entries, regulatory retention limits.
Exam trap — Global Tables vs RDS Multi-AZ:
RDS Multi-AZ = passive standby, sync replication, failover only — the standby cannot serve writes or reads. DynamoDB Global Tables = active-active, writes in any region. These are completely different patterns and the exam tests whether you know the distinction.
10. API Gateway, Step Functions, and Cognito
API Gateway:
The managed front door for serverless APIs. Handles versioning, environments (dev/prod), auth, throttling, caching, and request/response transformation.
Integration types:
- Lambda: expose a REST API backed by Lambda — the most common serverless pattern
- HTTP Endpoint: proxy to an internal API or ALB
- AWS Service: directly expose SQS, Step Functions, Kinesis through the API layer
Endpoint types:
- Edge-Optimised (default): routes through CloudFront edge locations — for global clients
- Regional: for same-region clients
- Private: VPC-only access via a VPC endpoint (ENI)
Security options: IAM Roles (internal apps), Cognito User Pools (external users), Lambda Authoriser (custom logic).
Step Functions:
Builds visual serverless workflows by orchestrating Lambda functions and AWS services. Supports sequence, parallel execution, conditions, timeouts, error handling, retries, and human approval steps.
Integrates with Lambda, EC2, ECS, on-premises servers, API Gateway, and SQS.
Exam pattern: "Orchestrate multiple Lambda functions" or "multi-step workflow with error handling" → Step Functions.
Amazon Cognito:
Handles user authentication so you don't build it yourself. Two distinct components with different jobs:
Cognito User Pools (CUP):
- User directory: sign up, sign in, password reset, MFA, email/phone verification
- Supports federated login: Google, Facebook, SAML providers
- Returns a JWT token on successful authentication
- Integrates directly with API Gateway and ALB — they validate the JWT automatically
Cognito Identity Pools (Federated Identity):
- Takes a token (from User Pools or any identity provider) and exchanges it for temporary AWS credentials
- Users can then directly access AWS services: S3, DynamoDB, Lambda
- IAM policies defined in Cognito, customisable per user_id for fine-grained row-level access
Full pattern:
User logs in → User Pools → JWT → Identity Pools → temporary AWS credentials → direct S3/DynamoDB access.
Exam trigger phrase: "hundreds of users," "mobile users," "federated identity," "authenticate with SAML" → Cognito, not IAM.
The Through-Line
Every service in this section does one thing: removes a layer of infrastructure management.
- Fargate removes EC2 from containers
- Lambda removes servers from compute
- DynamoDB removes database instance management
- API Gateway removes API infrastructure
- Cognito removes the need to build auth backends
- Step Functions removes the need to manage workflow state
The exam tests whether you know which tool removes which layer — and what the limits and edge cases are for each one.
Top comments (0)