← Design Resilient Architectures

▶ Play from here · 177 min

Starts this lesson and continues through 16 more to the end of certification prep.

Containers and serverless — ECS, EKS, Fargate, Lambda

Why this lesson matters

Task statement 2.1 lists four relevant items: "How to migrate applications into containers", "The orchestration of containers (for example, Amazon ECS, Amazon EKS)", "Serverless technologies and patterns (for example, AWS Fargate, AWS Lambda)", and the skills "Determining when to use containers" and "Determining when to use serverless technologies and patterns."

Note what the exam guide just did: it put Fargate in the serverless bucket, not the container bucket. That's the key to the whole lesson.

Fargate is not an alternative to ECS or EKS. It is an alternative to EC2 underneath them.

   ORCHESTRATOR  (what schedules your containers)
   ┌──────────────┬──────────────┐
   │  Amazon ECS  │  Amazon EKS  │      ← choose on ecosystem
   └──────┬───────┴───────┬──────┘
          │               │
   CAPACITY  (what the containers run on)
   ┌──────┴───────────────┴──────┐
   │   Fargate   │   EC2         │      ← choose on control vs overhead
   └─────────────────────────────┘

Getting that two-axis picture right eliminates a whole family of distractors — options that offer "ECS or Fargate" as if it were a choice.

ECS — AWS's own orchestrator

From What is Amazon Elastic Container Service?, verified 2026-09-22:

"Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service that helps you easily deploy, manage, and scale containerized applications. As a fully managed service, Amazon ECS comes with AWS configuration and operational best practices built-in."

Three layers, verbatim: "Capacity - The infrastructure where your containers run", "Controller - Deploy and manage your applications", "Provisioning - The tools that you can use to interface with the scheduler."

The capacity options — this is the list the exam tests:

⚠️ ECS Anywhere is the answer to "we must run containers in our own data centre and manage them the same way." It is a genuine option and it turns up as a distractor when people don't know it exists.

The vocabulary, verbatim — the exam uses these exact words:

• Task definition — "The blueprint for the application."
• Cluster — "The infrastructure your application runs on."
• Task — "An application such as a batch job that performs work, and then stops."
• Service — "A long running stateless application."

⚠️ Task vs Service is examinable. A task runs and stops — batch. A service keeps a desired count of tasks running — long-lived. If a stem describes "maintain 10 copies and replace failures", that's a service, and it's the container analogue of an Auto Scaling group.

Two kinds of scaling, and they're different things:

• Cluster Auto Scaling — "Amazon ECS manages the scaling of Amazon EC2 instances that are registered to your cluster." (Scales the hosts.)
• Service Auto Scaling — "Amazon ECS increases or decreases the desired number of tasks in your service automatically." (Scales the tasks.)

On Fargate you only need the second one, because there are no hosts. That's one of the strongest arguments for Fargate in an exam answer about operational overhead.

Fargate — serverless capacity

From Architect for AWS Fargate for Amazon ECS, verified 2026-09-23:

"AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. With AWS Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing."

The workflow, verbatim: "you package your application in containers, specify the CPU and memory requirements, define networking and IAM policies, and launch the application."

The isolation guarantee is worth knowing because it answers security questions:

"Each Fargate task has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task."

Fargate Spot — the Domain 4 answer hiding in Domain 2:

"Fargate Spot - Run interruption tolerant Amazon ECS tasks at a discounted rate compared to the AWS Fargate price. Fargate Spot runs tasks on spare compute capacity. When AWS needs the capacity back, your tasks will be interrupted with a two-minute warning."

⚠️ Two-minute warning — that's a verified number, unlike the EC2 Spot notice period I flagged as unverified in SAA0 lesson 3. Note it applies to Fargate Spot here.

Load balancing on Fargate has a gotcha the exam likes:

"Amazon ECS services on AWS Fargate support the Application Load Balancer, Network Load Balancer, and Gateway Load Balancer load balancer types."

"When you create a target group for these services, you must choose ip as the target type, not instance. This is because tasks that use the awsvpc network mode are associated with an elastic network interface, not an Amazon EC2 instance."

⚠️ Target type ip, not instance, on Fargate. There is no instance to register.

Platform versions matter for a resilience reason:

"If a security issue is found that affects an existing platform version, AWS creates a new patched revision of the platform version and retires tasks running on the vulnerable revision."

So AWS will restart your tasks to patch them. Your design has to tolerate a task disappearing — which is the same statelessness requirement as lesson 2, arriving from a different direction.

⚠️ Fargate doesn't support every task definition parameter. "Fargate tasks don't support all of the Amazon ECS task definition parameters that are available. Some parameters aren't supported at all, and others behave differently." If a stem describes a workload needing privileged mode, GPU access, or specific kernel tuning, that points at EC2 capacity, not Fargate.

EKS — managed Kubernetes

From What is Amazon EKS?, verified 2026-09-23:

"Amazon Elastic Kubernetes Service (EKS) provides a fully managed Kubernetes service that eliminates the complexity of operating Kubernetes clusters."

Two approaches, verbatim, and the distinction is exactly the control-plane/data-plane split:

• EKS standard — "AWS manages the Kubernetes control plane when you create a cluster with EKS. Components that manage nodes, schedule workloads, integrate with the AWS cloud, and store and scale control plane information … are handled for you automatically."
• EKS Auto Mode — "EKS extends its control to manage Nodes (Kubernetes data plane) as well. It simplifies Kubernetes management by automatically provisioning infrastructure, selecting optimal compute instances, dynamically scaling resources, continuously optimizing costs, patching operating systems, and integrating with AWS security services."

The reason to choose EKS over ECS, verbatim, and it's the only one that really holds up:

"Amazon EKS is certified Kubernetes-conformant, so you can deploy Kubernetes-compatible applications without refactoring and use Kubernetes community tooling and plugins."

That's it. Portability and ecosystem. If a team already runs Kubernetes, has Helm charts, operators and Kubernetes-native tooling, or needs to run the same workloads on-premises — EKS. Otherwise ECS is less to operate.

Hybrid: "both in the Amazon Web Services (AWS) cloud and in your own data centers (EKS Anywhere and Amazon EKS Hybrid Nodes)."

Pricing shape — examinable because it differs from ECS:

"Amazon EKS has per cluster pricing … When using Amazon EKS, you pay separately for the AWS resources you use to run your applications on Kubernetes worker nodes."

⚠️ EKS charges per cluster; ECS does not charge for the orchestrator itself (ECS pricing "depends on the capacity option you choose"). For a small workload, that per-cluster fee is a real cost-optimisation argument for ECS. I have not verified the per-cluster hourly figure here — read the EKS pricing page.

Lambda — the other end of the spectrum

From What is AWS Lambda?, verified 2026-09-22:

"AWS Lambda is a serverless compute service. With Lambda, you can run code without provisioning or managing servers. Lambda automatically manages the underlying infrastructure – including server maintenance, capacity provisioning, scaling, and patching."

Lambda Functions, verbatim:

"Run code in response to events or API calls without managing servers. You write a handler function, connect it to a trigger (API Gateway, Amazon S3, Amazon SQS, EventBridge, and 200+ other AWS services), and Lambda executes it. Each invocation runs independently with no shared state, scaling horizontally to match demand."

The constraints that decide exam questions:

⚠️ The 15-minute ceiling is the single most useful Lambda fact on this exam. Any stem describing a job that runs longer — a large ETL batch, a video transcode, a database migration — rules Lambda out. The alternatives are Fargate tasks, AWS Batch, or Step Functions orchestrating shorter Lambdas.

⚠️ "One request per execution environment at a time" is why Lambda scales by adding environments rather than by threading. It also explains cold starts, and why a VPC-attached Lambda with a heavy init is a latency problem.

Lambda MicroVMs are new and worth one line, because they change the "Lambda can't do long-running" story:

"Isolated compute environments with near-instant startup and state retention for up to 8 hours. Designed for workloads needing a dedicated compute environment for each individual user or job."

Unlike Functions: "Any application – run your own binaries, listen on ports, use Linux OS capabilities", "Multiple concurrent connections per MicroVM", and "Memory and disk state preserved on suspend; restored on resume", with "Developer-controlled" scaling.

⚠️ This is recent. The SAA-C03 exam guide does not name Lambda MicroVMs, and I would not expect it on the exam yet. Know it exists; answer exam questions from the Functions constraints.

Choosing, under exam conditions

The resilience angle

Why does Domain 2 care about any of this? Because containers and serverless are horizontal scaling with the statelessness already enforced.

A Lambda invocation cannot keep state between requests — AWS says so. A Fargate task can be retired at any time for patching. An ECS service replaces failed tasks the way an Auto Scaling group replaces failed instances. The platform has taken lesson 2's precondition and made it non-optional.

That's the resilience argument, and it's the one to make in an interview: you don't choose serverless because it's fashionable; you choose it because it removes the failure modes you'd otherwise have to engineer around. The cost is the constraints — 15 minutes, no local state, cold starts — and if your workload can't live inside them, you take the operational overhead back.

Check yourself

1. A stem offers "ECS" and "Fargate" as two of the four options. What's wrong with the question — and how do you answer it anyway?
2. A nightly job takes 40 minutes. An option says "run it on Lambda". Why is that wrong?
3. ECS service or ECS task: "maintain exactly 6 copies of the API container"?
4. You're moving Fargate tasks behind an ALB and the target group won't register anything. What did you get wrong?
5. When is EKS the right answer over ECS?

Answers

1. They're on different axes — ECS is the orchestrator, Fargate is the capacity. Read the options for what they actually describe: "ECS" usually implies ECS on EC2, "Fargate" implies ECS on Fargate. Then choose on whether the stem cares about managing instances.
2. **Lambda's limit is "Up to 15 minutes per invocation".** 40 minutes doesn't fit. Use a Fargate task, AWS Batch, or Step Functions orchestrating shorter steps.
3. A service — "A long running stateless application", with a desired count. A task is "an application such as a batch job that performs work, and then stops."
4. Target type. On Fargate "you must choose ip as the target type, not instance", because awsvpc tasks attach to an elastic network interface rather than an instance.
5. When you need Kubernetes specifically: "certified Kubernetes-conformant, so you can deploy Kubernetes-compatible applications without refactoring and use Kubernetes community tooling and plugins" — existing Helm charts, operators, portability, or hybrid/on-premises via EKS Anywhere. Otherwise ECS is less to operate, and EKS charges per cluster.

Teaching this section

• Draw the two axes before naming any service. Orchestrator on top, capacity underneath. The "ECS vs Fargate" confusion evaporates and never comes back.
• Demo: the same task definition run with requiresCompatibilities of EC2 and then FARGATE. Seeing one artefact land on two capacity types makes the axis concrete.
• Best discussion prompt: "Our batch job takes 40 minutes and we want it serverless." Let them reach for Lambda, then read the 15-minute limit, then let them find Fargate/Batch themselves.
• Watch for: learners saying "we'll use Fargate instead of ECS". Correct it every time — Fargate is how ECS runs, not an alternative to it.
• Timing: 30 min presented, 15 on the choosing table. Give them ten stems and have them call orchestrator and capacity for each.