Day 5 - Week 6 Review: Serverless + Containers Combined

The theme of Week 6 was "managed compute." AWS keeps absorbing more of the burden of running servers yourself, and we trace the spectrum from Lambda (fully serverless) through Fargate (serverless containers) to ECS/EKS (orchestration), sorting out each service's position and trade-offs. On the SAA-C03 exam this topic is tested along two axes: "which service do you choose" and "how do you connect them."

The spectrum of operational burden: EC2 (fully managed by you) → ECS/EKS + EC2 (node management) → ECS/EKS + Fargate (orchestration only) → Lambda (functions only). Moving to the right, operational burden shrinks and the AWS abstraction layer gets thicker. From a cost optimization standpoint, the right side is not always better: the steadier and higher the traffic, the cheaper EC2 or containers can be compared with Lambda. The selection criteria are "traffic pattern" and "the team's operational capability."

Week 6 Core Services at a Glance

Lambda Core Review

Lambda specs quick reference:

Cold start mitigation strategies: Language choice (Python/Node.js are fast, Java/C# are slow), increasing memory (CPU is allocated proportionally), Provisioned Concurrency (keeps warm environments), Lambda SnapStart (snapshot restore for Java 11+, up to 10× improvement).

Reserved vs Provisioned Concurrency:

• Reserved: "Reserve up to N concurrent executions for this function" — other functions cannot use this capacity. For isolation. Does not fix cold starts.
• Provisioned: "Always keep N warm execution environments" — 0ms cold start. Incurs additional cost.

⚠️ Trap — Lambda VPC and internet access: When you attach Lambda to a VPC, it cannot access the internet by default. It can reach resources inside the VPC (RDS, ElastiCache), but external APIs and AWS Public Endpoints (the default DynamoDB and S3 endpoints) are blocked. Solutions: a private subnet + NAT Gateway (internet access), or a VPC Gateway/Interface Endpoint (AWS service access). Lambda's Hyperplane ENI has solved the ENI creation delay problem since 2019, but the NAT Gateway cost still exists.

Criteria for Choosing an API Gateway Type

Comparing the 3 API Gateway types:

Lambda Authorizer caution: The default caching TTL is 300 seconds. Setting the TTL to 0 invokes the Authorizer Lambda on every request, increasing cost and latency. Set the TTL appropriately, but when permissions must be revoked immediately (token blacklist), TTL 0 is needed. You must understand this trade-off.

Server → client push with the WebSocket API: Store the connectionId in $connect, and when the server POSTs to the Callback URL (execute-api.region.amazonaws.com/{stage}/@connections/{connectionId}), the message is pushed to the client. Server push is impossible without the connectionId.

Going deeper — REST API vs HTTP API decision tree:

Need API Keys + usage limits for external partners?
  → REST API (Usage Plan)

Integrate AWS services (DynamoDB, SQS) directly without Lambda?
  → REST API (AWS Service Integration + Mapping Templates)

JWT authentication from an external OIDC provider (Auth0, Okta)?
  → HTTP API (JWT Authorizer)

Simple Lambda/HTTP backend, cost optimization?
  → HTTP API

Real-time two-way communication?
  → WebSocket API

Criteria for Choosing Step Functions

Standard vs Express decision criteria:

• Does execution run longer than 5 minutes? → Standard is required
• Is exactly-once processing needed? (payments, inventory deduction) → Standard
• High throughput of thousands to hundreds of thousands per second? → Express (100K/s, 1M concurrent executions)
• Store logs in CloudWatch and minimize cost? → Express (billed per execution count, no charge for state transitions)

The waitForTaskToken pattern — workflows involving people:

1. Step Functions passes the taskToken from the Task State to SQS/SNS/EventBridge
2. A person in charge approves or rejects
3. The processing system calls SendTaskSuccess(taskToken) or SendTaskFailure(taskToken)
4. Step Functions receives the result and moves on to the next state

If you do not set HeartbeatSeconds, the task waits up to the maximum execution time (the 1-year quota). If you set it, the task fails with States.HeartbeatTimeout when no SendTaskHeartbeat arrives within HeartbeatSeconds, and you must handle it with a Catch block.

The power of Distributed Map: Run 10,000 parallel child workflows to process large amounts of data in S3 in parallel. ToleratedFailurePercentage allows some failures, and ResultWriter stores results in S3 to get around the 256KB state data limit.

Going deeper — the Saga pattern and compensating transactions: In a microservices environment, distributed transactions spanning multiple services cannot use 2PC (2-Phase Commit), because it creates tight coupling between services and reduces availability. The Saga pattern, proposed by Garcia-Molina in 1987, processes each step as a local transaction and, on failure, cancels the already-completed steps in reverse order with compensating transactions. In Step Functions, you implement a Saga with Retry (exponential backoff retries) and Catch + States.ALL (catching all error types). Because a compensating transaction can itself fail, idempotency is important.

Criteria for Choosing a Container Service

ECS vs EKS vs Fargate decision tree:

Need the Kubernetes standard (multi-cloud, open-source ecosystem)?
  → EKS

Need GPU / specialized instances?
  → ECS/EKS + EC2 Launch Type

Minimize node management burden, simple service deployment?
  → ECS + Fargate

Need strong kernel-level security isolation (regulated industry)?
  → Fargate (Firecracker MicroVM)

Complex deployment patterns (CRD, Operator, Helm)?
  → EKS

Run only some workloads serverless in EKS?
  → EKS + Fargate Profiles (but no DaemonSets)

Two patterns for IAM permissions:

• ECS: Task Role (application code permissions) + Task Execution Role (agent permissions)
• EKS: IRSA (IAM Roles for Service Accounts) — per-Pod IAM Role based on OIDC tokens

Both patterns share the same principle: "grant IAM permissions per workload, not at the instance/node level."

⚠️ Collected traps — commonly confused concepts:

1. Task Role vs Task Execution Role: The Execution Role is for the ECS agent to pull from ECR + send CW logs. The Task Role is for the container code to call S3/DDB. Swapping them causes permission errors.

2. Fargate networking mode: Fargate supports only awsvpc mode. bridge and host are not possible.

3. 3 ECR VPC Endpoints: ecr.api + ecr.dkr + S3 Gateway Endpoint. If any one is missing, image pulls from a private subnet fail.

4. IRSA vs Instance Profile: In EKS, if you set only the node Instance Profile, every Pod on the same node gets the same permissions — you need IRSA for per-Pod control.

5. Standard vs Express: Payment processing (exactly-once, over 5 minutes) = Standard. Order status lookup (high throughput, under 5 minutes) = Express.

Integrated Architecture — Mixing Serverless + Containers

[ User request flow ]

Mobile/Web Client
      │
      ├─ REST/JSON ──→ API Gateway (REST) ──→ Lambda ──→ DynamoDB / S3
      │                                             └──→ SQS → Lambda (async processing)
      │
      ├─ GraphQL ───→ AppSync ──→ DynamoDB / Lambda / OpenSearch
      │              (Real-time Push via Subscription ↓ Client)
      │
      └─ WebSocket → API Gateway (WS) ──→ Lambda ($connect, $default)
                                              └──→ DynamoDB (store connectionId)
                                              └──→ Push to other clients

[ Backend container service ]

ALB → ECS Fargate (awsvpc mode)
        │ Task Role (S3, DynamoDB permissions)
        └──→ RDS Proxy → Aurora Multi-AZ

[ Orchestration ]

EventBridge (schedule / events)
      └──→ Step Functions (Standard)
              ├─ Lambda (each step)
              ├─ ECS Fargate Task (batch processing)
              ├─ waitForTaskToken (human approval)
              └─ Distributed Map (large-scale parallel S3 processing)

Case study — e-commerce order processing system: A typical exam scenario. Order creation (API GW → Lambda → DDB) → payment processing (Step Functions Standard, Saga pattern, exactly-once) → inventory deduction (Lambda → DDB) → shipping request (SQS → ECS Fargate) → real-time shipment tracking updates (AppSync Subscription → Mobile App). Each step has a reason a different service is optimal: payment must be exactly-once, so Standard Step Functions; shipping handling is batch-like, so Fargate; real-time status notifications use AppSync Subscription.

Case study — media processing pipeline: Upload a video to S3 → EventBridge → Step Functions Distributed Map (10,000 chunks processed in parallel, each chunk transcoded by Lambda) → store the results with ResultWriter in S3 → distribute through CloudFront CDN. In this architecture, the Distributed Map in Standard Step Functions can do large-scale parallel processing without AWS Batch or EMR, and when processing fails, it can tolerate some failures with ToleratedFailurePercentage and then reprocess.

A DR Perspective — Availability Design of the Week 6 Services

Going deeper — Lambda Destinations vs DLQ: Both are Lambda failure-handling mechanisms, but their purposes differ. A DLQ (Dead Letter Queue) sends the failed event to SQS or SNS when an asynchronous invocation fails. Lambda Destinations are more powerful: they can handle both success and failure (a DLQ handles only failure), support 4 target types (SQS, SNS, Lambda, EventBridge), and include the function response and context information in addition to the original event. In general, Lambda Destinations are recommended over a DLQ. Failure handling for Event Source Mapping (SQS, Kinesis, DDB Streams) must be configured separately, and ReportBatchItemFailures supports partial batch success.

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

A Lambda function normally handles only a small number of requests, but every day at 9 AM hundreds of users connect at the same time and cold starts cause it to violate the response latency SLA. What is the best solution?

• ASet Reserved Concurrency high to block interference from other functions
• BConfigure Provisioned Concurrency and scale up at 8:55 AM with Application Auto Scaling
• CRaise the Lambda function's memory to the maximum (10GB) to shorten initialization time
• DMigrate the Lambda function to EC2

Question 2

You are providing an API to external SaaS partners. You must limit each partner to 10,000 requests per month, block requests when the limit is exceeded, and provide a per-partner usage dashboard. What is the best API Gateway type and feature?

• AHTTP API + Lambda Authorizer
• BREST API + Usage Plan + API Key
• CWebSocket API + $connect handler
• DHTTP API + JWT Authorizer

Question 3

In an order processing system, three steps (payment charge, inventory deduction, shipping request) must run in order. The payment charge must run exactly once, and if any step fails, the previous steps must be canceled (refund, inventory restoration). What is the best architecture?

• ASQS FIFO → Lambda chain → each Lambda synchronously invokes the next Lambda
• BStep Functions Standard + Saga pattern (compensating transactions with Retry + Catch)
• CStep Functions Express (high throughput, cost-effective)
• DEventBridge event chain (each service publishes and subscribes to events)

Question 4

You are building a real-time collaborative document editing service. When multiple users edit the same document, one user's changes must be delivered to the other users immediately. What is the best AWS architecture?

• AREST API Gateway + client polling (checking for changes every second)
• BAPI Gateway WebSocket + Lambda (store the connectionId in $connect, push to all connections on change)
• CAppSync GraphQL + Subscription
• DSNS + client HTTP Long Polling

Question 5

You deploy an ECS Fargate service in a private subnet, and the containers must pull images from ECR without internet access. What components are required?

• AJust set up a NAT Gateway and access ECR over the internet
• BSet up only the com.amazonaws.region.ecr.dkr VPC Endpoint
• Cecr.api Interface Endpoint + ecr.dkr Interface Endpoint + S3 Gateway Endpoint
• DUse the ECR Public Registry and access it without VPC Endpoints

Question 6

In an EKS cluster, the payment service Pod must access only Secrets Manager, and the log collection Pod must access only CloudWatch. When the two Pods run on the same node, how do you grant IAM permissions per Pod?

• AGrant both permissions to the EC2 node Instance Profile
• BSet an IAM access key in each Pod's environment variables
• CUse IRSA to attach a separate IAM Role to each Pod's Service Account
• DStore IAM credentials in a Kubernetes Secret

Question 7

One million new files are uploaded to an S3 bucket every night. Each file must be processed independently and the results stored in DynamoDB, and if the processing failure rate exceeds 5%, the entire job must stop and send a notification. What is the best architecture?

• AEventBridge schedule → Lambda (sequential processing)
• BS3 event → SQS → Lambda (parallel processing, 1 million)
• CStep Functions Standard + Distributed Map (ToleratedFailurePercentage=5)
• DAWS Batch + ECS Fargate

Question 8

In an insurance claims processing system, when a customer submits a claim, a reviewer must approve or reject it within 5 business days. If the reviewer does not respond, an escalation email must be sent. What is the best way to implement this workflow?

• ASQS + Lambda (check the DLQ every 5 days)
• BStep Functions Standard + waitForTaskToken + HeartbeatSeconds (5 days) + Catch (States.HeartbeatTimeout → escalation)
• CRun a notification Lambda 5 days later with EventBridge Scheduler
• DStep Functions Express + waitForTaskToken

Question 9

A startup is launching its initial service, and a backend team of 3 with no Kubernetes experience wants to deploy a container-based API server. Fast launch and minimal operational burden are the priorities. What is the best combination of services?

• AEKS + Managed Node Groups + Helm
• BECS + Fargate + ALB
• CECS + EC2 Launch Type + ASG
• DEKS + Fargate Profiles

Question 10

A fintech company provides a multi-tenant API. Each tenant has its own DynamoDB table and S3 bucket, and the Lambda function must access only the correct resources for each tenant. In addition, Lambda cold starts must be prevented to minimize API response latency. What is the best design?

• ADeploy a separate Lambda function per tenant + configure Provisioned Concurrency on each function
• BA single Lambda function + pass the tenant ID through environment variables + access DynamoDB through an EC2 Instance Profile + Provisioned Concurrency
• CA single Lambda function + switch to a per-tenant IAM Role at runtime with STS AssumeRole + Provisioned Concurrency
• DDeploy a per-tenant ECS Fargate service + isolate with Task Roles

Question 11

A Lambda function is invoked asynchronously to process images. You must capture the events for images that failed processing and reprocess them, and for successfully processed images start a downstream pipeline on a separate EventBridge bus. What is the best configuration?

• AConfigure a DLQ (Dead Letter Queue) as SQS to handle only failed events
• BConfigure Lambda Destinations: success → EventBridge, failure → SQS
• CInside the Lambda, use try/catch to call EventBridge put-events on success and SQS send-message on failure
• DAnalyze failure patterns with CloudWatch Logs Insights and reprocess manually

Question 12

A company is optimizing its AWS serverless services and is reviewing the following workloads: (1) 50,000 order status lookups per second (each lookup completes within 3 seconds), (2) 100 large report generations per month (each report takes 20 minutes). If you use Step Functions, which type should you use for each?

• A(1) Standard, (2) Standard
• B(1) Express, (2) Standard
• C(1) Express, (2) Express
• D(1) Standard, (2) Express