Container Architecture: ECS, EKS, and Fargate at Scale

Containerization on ECS and EKS is the default compute substrate for modernized workloads on AWS, and the SAP-C02 exam tests containerization ECS EKS at Pro depth across at least three task statements — 2.1 deployment strategy, 2.5 performance, and 4.3 new architecture migration. This chapter assumes Associate-level fluency with Docker, task definitions, and basic Fargate mechanics, and advances into the questions a Solutions Architect Professional is actually paid to answer: when does ECS beat EKS for a 50-microservice polyglot team, how do capacity providers blend Fargate and EC2 Spot without sacrificing availability, how does IRSA differ from Pod Identity, when is Karpenter strictly better than Cluster Autoscaler, how do App Mesh and VPC Lattice decompose into different service-mesh problems, and how do multi-account multi-region cutovers actually work for containerized platforms. Every section of this containerization ECS EKS guide maps to a SAP-C02 scenario pattern so that the mental model compounds across the exam.

What Containerization ECS EKS Means at SAP-C02 Depth

Containerization ECS EKS at SAP-C02 level is not a comparison of two orchestrators — it is a platform-architecture decision that ripples through IAM design, networking topology, CI/CD strategy, cost model, and organizational capability. Associate certifications stop at "ECS uses tasks, EKS uses pods." The Professional exam demands that you reason about containerization ECS EKS choices under constraints like 200-account Organizations structure, 50 microservices owned by six polyglot teams, regulated workloads with image-signing requirements, and hybrid footprints that still have half the fleet on-prem. Containerization ECS EKS therefore spans three interlocking surfaces: the control plane (ECS service scheduler vs Kubernetes API server), the data plane (Fargate serverless vs EC2 with Bottlerocket, plus on-prem with ECS Anywhere or EKS Hybrid Nodes), and the platform layer (service discovery, service mesh, secrets, observability, policy).

SAP-C02 question stems use containerization ECS EKS to probe whether you understand the total cost of ownership and the risk profile of each decision, not whether you memorized CPU and memory limits. Expect scenarios like "a global team already runs Kubernetes on other clouds, AWS regulations require image signing, cost must drop 40 percent," where the correct answer folds EKS, ECR with signing, Karpenter on Spot, and Compute Savings Plans into a single coherent target architecture. Every other section in this containerization ECS EKS chapter is structured to compose into those multi-constraint answers.

Why Containerization ECS EKS Gets Its Own SAP-C02 Chapter

Containerization ECS EKS earns a dedicated SAP-C02 chapter because it is the target platform for modernization work under task 4.3, it dominates the performance design space under 2.5, and it anchors the deployment-strategy conversation under 2.1. Of the 2000 questions budgeted against Domain 2, roughly 200 resolve directly to containerization ECS EKS decisions, and another 300 touch the topic as part of compound scenarios. Mastering containerization ECS EKS at SAP-C02 depth is therefore a ten-percent swing on the whole exam.

Plain-Language Explanation: Containerization ECS EKS at Pro Scale

Containerization ECS EKS decisions are abstract, so three concrete analogies from different categories make the responsibility, portability, and scaling axes tangible. Read all three; the overlap is where the SAP-C02 intuition lives.

類比一：連鎖餐廳的中央廚房 vs 直營店 (Central Kitchen vs Company-Owned Stores)

Imagine a restaurant chain that has to feed 50 different menu items across multiple cities.

• ECS on Fargate = company-owned storefront with prepared ingredients — the chain gives each store a recipe card (task definition) and a sealed pantry (Fargate-provisioned microVM). Staff just heat and serve; ingredients and stoves are managed centrally. Simple, fast to open a store, but every store runs the chain's opinionated kitchen layout.
• EKS with managed node groups and Karpenter = franchise with a shared kitchen standard — every store speaks the same language (Kubernetes API) so a chef trained in Tokyo can work in a Taipei store. The franchise HQ (EKS control plane) enforces standards, but each franchisee (node group) buys their own refrigerators (EC2 capacity) and decides when to turn on extra stoves (Karpenter just-in-time provisioning).
• ECS Anywhere / EKS Hybrid Nodes = central recipes delivered to a family restaurant — the existing family restaurant keeps its old kitchen (on-prem hardware) but prints the chain's recipe cards and reports back to HQ. You extend the brand without forcing the family to rebuild their kitchen.
• App Mesh / VPC Lattice = the waiter relay system — once you have many kitchens, you need a standardized way for dishes to travel between tables regardless of which kitchen cooked them.

The 50-microservice polyglot scenario maps directly to this analogy: if the six teams all speak Kubernetes natively, the franchise model wins; if only two teams touch containers and the other four just want a URL, company-owned Fargate storefronts win.

類比二：工具箱裡的兩把不同扳手 (Two Different Wrenches in the Toolbox)

Containerization ECS EKS can be framed as two wrenches that both turn bolts but serve different jobs.

• Amazon ECS = AWS-native torque wrench — calibrated specifically for AWS bolts (IAM, ALB, CloudWatch, Secrets Manager). It feels natural in the AWS toolbox, requires no extra adapter, and has no rental fee for the wrench itself (ECS control plane is free).
• Amazon EKS = international adjustable wrench — fits any bolt worldwide because Kubernetes is the global standard, so your mechanics can work in any shop (AWS, on-prem, other clouds). The wrench itself has a rental fee ($0.10 per cluster per hour, roughly $73/month) because the calibration is CNCF-conformant.
• Fargate = the ergonomic grip that attaches to either wrench — removes hand fatigue (host management) from either tool but costs a per-second premium.
• Karpenter = the smart torque sensor — clips onto the EKS wrench and decides the exact right size and quantity of EC2 bolts to install, even mixing Spot and On-Demand in the same turn.
• App Mesh and VPC Lattice = the assembly jig — once you have many wrenches turning many bolts, a jig keeps everything aligned.

A SAP-C02 scenario that says "the company wants portability across AWS and on-prem Kubernetes" is the international adjustable wrench scenario — EKS with EKS Hybrid Nodes, not ECS Anywhere.

類比三：電網與發電廠 (Power Grid and Power Plants)

Containerization ECS EKS at multi-region scale is a power-grid problem.

• ECS tasks / EKS pods = individual appliances — they consume CPU and memory the way appliances consume watts.
• Fargate = the shared utility grid — plug in, pay by the kilowatt-hour, never worry about the plant.
• EC2 capacity providers = your own on-site power plants — cheaper at steady load, especially with Savings Plans (long-term contracts) or Spot (buying leftover capacity from the utility at 70 percent off).
• Karpenter = a dynamic plant dispatcher — spins up exactly the right generator (instance type) for the current load, shuts it off when demand drops, and can mix Spot and On-Demand on a sub-minute cadence.
• Cluster Autoscaler = a slower steam-plant operator — scales pre-defined node groups in chunks, good enough for steady demand but slower to react to spikes.
• Multi-region EKS = interconnected regional grids — each region has its own control plane and nodes; a DNS/traffic-management layer (Route 53, Global Accelerator) decides which grid serves each customer, and replication runs at the data layer (Aurora Global Database, DynamoDB Global Tables).
• App Mesh / VPC Lattice = the high-voltage transmission standards — ensure that power flows safely between plants regardless of who built them.

A multi-region cutover scenario resolves as: keep the data plane running in both grids (regions) during cutover, shift traffic at the transmission layer (Route 53 weighted or failover routing), and only decommission the old grid once load settles — never cut off both grids simultaneously.

ECS vs EKS — The Pro Decision Framework

Containerization ECS EKS choice at SAP-C02 depth is a six-dimension decision, not the two-bullet rule you learned at Associate level. Work each dimension against the scenario and let the majority signal point you to the answer.

Dimension 1 — Team Skill and Ecosystem Fit

If the scenario mentions existing Kubernetes operators, Helm charts, Argo CD, Flux, Istio, or vendor software shipped as Kubernetes manifests, containerization ECS EKS leans EKS. If the teams are AWS-native and prefer task definitions in CloudFormation or Terraform, ECS is the faster path.

Dimension 2 — Portability Requirement

If the workload must run on EKS today and plausibly on on-prem Kubernetes, another cloud's Kubernetes, or a red-team lab tomorrow, the answer is EKS. ECS is AWS-only with the narrow exception of ECS Anywhere (which pushes AWS primitives back out, rather than letting workloads move).

Dimension 3 — Control Plane Cost

ECS control plane is free. EKS control plane costs $0.10 per cluster per hour (~$73 per month per cluster). At Pro scale — a platform team running 50 clusters for 50 business units — this is $44,000 per year in control-plane fees alone. Cost-sensitive greenfield scenarios usually pick ECS unless a Kubernetes requirement is explicit.

Dimension 4 — Operational Overhead at Steady State

ECS has no control plane to patch, no CoreDNS / VPC CNI / kube-proxy add-ons to version-pin, and no node-group minor-version upgrades that might break workloads. EKS requires ongoing lifecycle management of the control plane version (every release supported ~14 months), add-ons, and nodes. The Professional exam rewards scenarios that weigh this ongoing toil against the ecosystem benefits.

Dimension 5 — Ecosystem Dependencies You Cannot Replace

Service meshes (Istio, Linkerd), policy engines (OPA Gatekeeper, Kyverno), GitOps tooling (Argo CD, Flux), operators for databases (Zalando Postgres Operator), and observability stacks (Prometheus, Grafana in-cluster) often require Kubernetes APIs. If the scenario hinges on any of these, EKS wins.

Dimension 6 — AWS-Native Integration Depth

ECS is tightly integrated with IAM task roles, ALB target groups, CloudWatch Container Insights, Secrets Manager references in task definitions, AppConfig, and CodeDeploy blue/green. EKS needs adapter layers (IRSA or Pod Identity for IAM, AWS Load Balancer Controller for ALB, External Secrets Operator for Secrets Manager). If the scenario values fastest-path integration, ECS wins.

ECS Pro Topics — Capacity Providers, Service Discovery, Exec, Anywhere

Containerization ECS EKS at SAP-C02 depth requires command of ECS features that the Associate exam glosses over. This section covers the five Pro-level ECS capabilities that appear in real scenarios.

ECS Capacity Providers — Blending Fargate, EC2, and Spot

Capacity providers abstract the compute backing an ECS service so you can blend Fargate, Fargate Spot, and EC2 Auto Scaling Groups on a per-service basis. A capacity provider strategy is an ordered list with a base (minimum number of tasks on the first provider) and weight (relative allocation of additional tasks across providers).

Canonical containerization ECS EKS capacity provider patterns:

• Fargate 100% — simplest, per-second billing, ideal for spiky microservices.
• Fargate + Fargate Spot (base=2, weight=1:4) — keep 2 on-demand for minimum availability, scale additional tasks 20% on-demand and 80% Spot for a ~55% blended discount.
• EC2 ASG primary + Fargate burst — steady load on Reserved Instances or Savings Plans, peak on Fargate so you never over-provision EC2.
• EC2 On-Demand + EC2 Spot mixed ASG — for EC2-only clusters that need cost optimization; the ASG itself handles mixed-instance policies.

ECS Service Discovery via AWS Cloud Map

ECS service discovery via AWS Cloud Map gives tasks stable DNS names that follow replica churn. When you register an ECS service with Cloud Map, ECS creates and updates a private namespace (e.g., orders.internal) with A records (for awsvpc networking) or SRV records (for bridge networking), and registers each task IP as a backend. Client services query orders.orders.internal and receive up-to-date IPs without any service-mesh overhead.

Cloud Map vs Application Load Balancer for containerization ECS EKS:

• Cloud Map DNS service discovery — lightweight, no ALB fee, suitable for internal microservices using gRPC or custom protocols, no request-level routing.
• ALB target groups — richer (path-based routing, host-based routing, sticky sessions, weighted target groups, TLS termination) but adds cost.

For the 50-microservice scenario, a common pattern is ALB at the edge of the platform for external HTTP traffic, Cloud Map for internal service-to-service discovery. Cloud Map also integrates with EKS via the External DNS project and with AWS App Mesh.

ECS Exec — Secure Shell Without SSH

ECS Exec lets you run an interactive shell or a single command inside a running ECS task without SSH, bastion hosts, or host-level access. It uses the SSM Session Manager infrastructure, so audit trails land in CloudWatch Logs or S3 and IAM controls who can exec into which task.

SAP-C02-relevant details about ECS Exec:

• Requires the task role to include ssmmessages permissions and the task definition to have enableExecuteCommand=true.
• Works on both Fargate and EC2 launch types; Fargate tasks with ECS Exec still have no host to SSH into.
• Commands are logged with IAM principal, task ID, and timestamp — satisfying most compliance requirements.
• Replaces old patterns like running an SSH sidecar or baking an SSM agent into Fargate images.

ECS Anywhere — Extending ECS to On-Prem Hardware

ECS Anywhere lets you register external instances (on-prem bare metal, VMs, other clouds) as capacity for an ECS cluster. The external instance runs the ECS agent and the SSM agent, registers via an SSM activation, and ECS schedules tasks onto it just like EC2 launch type.

ECS Anywhere matters for SAP-C02 containerization ECS EKS scenarios that say "must continue running workloads in the on-prem data center for regulatory reasons while standardizing on AWS tooling." Pricing is flat per external instance per hour, independent of size. Limits you must know: no load balancer integration at the external instance (you front with your own), no EBS volumes, no Auto Scaling Group semantics.

ECS Task Definition Pro Details — CPU, Memory, Networking Modes

Task definitions at Pro level expose knobs the Associate exam does not probe.

• Task CPU / memory combinations — Fargate enforces a matrix (e.g., 0.25 vCPU with 0.5-2 GB, 1 vCPU with 2-8 GB, up to 16 vCPU with 120 GB). EC2 launch type lets you undersubscribe a host by summing task reservations below instance capacity.
• Network modes — awsvpc (task gets its own ENI; required for Fargate), bridge (Docker bridge network, EC2 only), host (shares host network stack, EC2 only, no per-task security group), none (no external networking).
• Ephemeral storage — Fargate default 20 GB, configurable up to 200 GB; EC2 tasks use the host's docker storage.
• Volumes — bind mounts, Docker volumes, EFS volumes, FSx for Windows File Server volumes.
• Secrets — secrets field references Secrets Manager or Parameter Store ARNs; values are injected as environment variables at task start with no code changes.
• Task role vs Execution role — task role grants the application's AWS SDK permissions (read S3 bucket); execution role grants Fargate or ECS agent permission to pull ECR images, write logs, and fetch secrets.

EKS Pro Topics — Control Plane, Node Options, IRSA vs Pod Identity

Containerization ECS EKS on the EKS side has a deep Pro surface of its own. This section covers control plane HA and logging, the three node options, IAM integration via IRSA and Pod Identity, and EKS add-ons.

EKS Control Plane HA and Logging

The EKS control plane is multi-AZ by default — Kubernetes API server, etcd, scheduler, and controller manager replicas run across at least two AZs within a Region, fully managed by AWS. You do not see the nodes, you cannot SSH into them, and you pay $0.10/hour per cluster for this HA guarantee.

EKS control plane logging streams five log types to CloudWatch Logs when enabled: api, audit, authenticator, controllerManager, scheduler. Enabling audit is a common SAP-C02 answer for scenarios that require a full record of who did what against the Kubernetes API — useful for compliance reviews and forensic timelines.

Control plane endpoint access modes matter for containerization ECS EKS security:

• Public endpoint (default) — reachable from the internet; still protected by AWS IAM auth and RBAC.
• Public + private — reachable from both the internet and inside the VPC.
• Private only — only reachable from VPC or via Transit Gateway / VPN; the right answer for regulated workloads.

EKS Compute Options — Managed Node Groups vs Self-Managed vs Fargate Profiles

EKS gives you three ways to run pods.

• Managed node groups — EKS provisions and lifecycles an EC2 Auto Scaling Group of worker nodes, handles rolling updates for AMI and Kubernetes versions, and integrates with capacity providers. Default for most SAP-C02 greenfield answers.
• Self-managed nodes — you provision the EC2 instances (or a custom ASG) and join them to the cluster with the EKS bootstrap script. Needed when you require custom AMIs, Windows nodes beyond the managed variant, or specialized hardware the managed flow does not support.
• Fargate profiles — a selector-based rule (namespace + labels) that routes matching pods to Fargate microVMs. Each pod runs in its own isolation boundary. Common answer when the scenario says "no node management."

Limitations that appear on SAP-C02:

• Fargate pods cannot use DaemonSets, hostNetwork, hostPort, privileged containers, GPU, or EBS volumes (only EFS via CSI).
• Fargate pods have a per-pod minimum size (0.25 vCPU / 0.5 GB) and cannot be right-sized below that floor.
• DaemonSets (CNI plugins, log forwarders, security agents) require managed or self-managed nodes, so many real clusters run a small managed node group even when most pods are on Fargate.

IRSA and EKS Pod Identity — Pod-Level IAM

Giving a pod AWS IAM permissions without exposing node-level credentials is the defining IAM problem for containerization ECS EKS. AWS offers two solutions.

• IAM Roles for Service Accounts (IRSA) — cluster has an OIDC identity provider registered; a Kubernetes service account is annotated with an IAM role ARN; the AWS SDK inside the pod exchanges the projected ServiceAccount token for STS credentials via AssumeRoleWithWebIdentity. Works everywhere EKS runs, but requires OIDC provider setup per cluster and deep trust-policy configuration.
• EKS Pod Identity — newer (2023), EKS add-on-based, no OIDC provider to manage per cluster. You create a Pod Identity Association that maps a namespace + service account to an IAM role; the Pod Identity Agent DaemonSet on the node exposes credentials via the AWS Pod Identity Token. Simpler trust model and works better for cross-account scenarios because the trust policy is a simple service principal.

When to pick which at SAP-C02 depth:

• Cross-account role chaining with complex trust, or Fargate-only workloads → IRSA (Pod Identity Agent is a DaemonSet so does not run on Fargate).
• New cluster with managed nodes, simple per-cluster IAM model, less ceremony → Pod Identity.
• Migrating? Coexistence is supported; pods can use either mechanism.

EKS Add-ons

EKS add-ons are AWS-managed, tested bundles of cluster software: VPC CNI, kube-proxy, CoreDNS, EBS CSI driver, EFS CSI driver, Pod Identity Agent, Mountpoint for S3 CSI, Snapshot Controller, and AWS Distro for OpenTelemetry. Using add-ons offloads version compatibility and patching to AWS and surfaces status in the EKS console.

Add-ons are relevant on SAP-C02 when a scenario requires lifecycle automation for core cluster components at fleet scale — managing VPC CNI versions across 50 clusters by hand is not a sustainable answer; add-ons with a version pin in your platform pipeline is.

EKS Hybrid Nodes — On-Prem Workers for EKS

EKS Hybrid Nodes (GA 2024) let you register on-prem Linux servers as EKS worker nodes while the control plane still runs in AWS. The on-prem nodes communicate with the EKS control plane over AWS Direct Connect or Site-to-Site VPN and appear alongside EC2 and Fargate nodes in the same cluster.

SAP-C02 containerization ECS EKS scenarios that select EKS Hybrid Nodes:

• Workloads subject to data-residency rules that require the data plane on-prem while platform tooling standardizes on EKS.
• Manufacturing or retail edge sites that need Kubernetes consistency with the cloud cluster.
• Hybrid capacity bursts — run baseline on-prem, burst to EC2 when demand spikes.

Contrast with ECS Anywhere: ECS Anywhere extends ECS to on-prem; EKS Hybrid Nodes extends EKS to on-prem. Neither replaces Outposts for scenarios that need AWS-managed hardware.

Karpenter vs Cluster Autoscaler — Node Autoscaling Done Right

Node autoscaling is where containerization ECS EKS cost and agility either compound or collapse. SAP-C02 tests the Karpenter vs Cluster Autoscaler distinction because the two mechanisms are not interchangeable.

Cluster Autoscaler — The Legacy Default

Cluster Autoscaler (CA) watches for unschedulable pods and scales existing node groups up or down. It is node-group-aware, so you pre-define node groups per workload shape (e.g., one group for CPU-bound, one for memory-bound, one for GPU), and CA scales whichever group matches. CA reacts in minutes, not seconds, because it drives the ASG desired count and waits for the EC2 launch.

Limits that matter at SAP-C02 depth:

• Requires pre-defined node groups; you cannot get a 4xlarge for a single big pod unless a 4xlarge group exists.
• Single-AZ ASGs are a gotcha — CA assumes a node group can launch in any AZ.
• Scale-down respects PodDisruptionBudget but can still be slow.

Karpenter — The Just-In-Time Successor

Karpenter, an AWS-originated open-source node provisioner, replaces node groups with NodePool and EC2NodeClass resources that describe allowed instance-type families, capacity type (on-demand / spot), zones, and taints. When an unschedulable pod appears, Karpenter evaluates the pod's requirements and launches the cheapest EC2 instance that fits — often in under a minute, often a perfectly-sized instance instead of a node-group-default.

Why Karpenter wins for containerization ECS EKS cost and agility:

• Shape-fitting — provisions exactly the right instance for the pending pods, reducing waste compared to CA's fixed node-group shapes.
• Spot-aware — first-class Spot support with interruption handling via the EventBridge notice, automatic fallback to On-Demand.
• Consolidation — Karpenter can deprovision underutilized nodes and reschedule pods onto cheaper or fewer nodes automatically.
• No node groups — reduces operational surface.

SAP-C02 scenarios that name "cost-optimized EKS on Spot with just-in-time capacity" resolve to Karpenter; scenarios that say "simple, few workload shapes, team already knows Cluster Autoscaler" can still justify CA.

App Mesh and VPC Lattice — Service Mesh for Containers

Once you have 50 microservices on containerization ECS EKS, you need to solve service-to-service discovery, mTLS, traffic shaping, retries, and observability. Two AWS services address this: App Mesh (deprecated, see note) and VPC Lattice (newer).

AWS App Mesh

App Mesh is AWS's Envoy-based service mesh. Each ECS task or EKS pod runs an Envoy sidecar that handles east-west traffic with policies managed centrally in the App Mesh control plane. Features include retries, timeouts, traffic splitting for canary deployments, mTLS via ACM Private CA, and observability integration with X-Ray, CloudWatch, and Prometheus.

Note for SAP-C02: AWS announced App Mesh is no longer receiving new features and is in maintenance mode; new designs should favor VPC Lattice or customer-operated meshes (Istio, Linkerd). However, App Mesh still appears in legacy modernization scenarios and the exam may still reference it.

Amazon VPC Lattice

VPC Lattice is AWS's newer application-layer networking service that provides service discovery, connectivity, security, and observability across VPCs and accounts without sidecars. It sits at layer 7 and handles HTTP, HTTPS, and gRPC traffic.

Key VPC Lattice concepts for containerization ECS EKS:

• Service network — a logical boundary grouping services; VPCs associate with the service network to gain access.
• Service — an HTTP or gRPC endpoint registered in the network.
• Target group — the compute backing a service; can be ECS tasks, EKS pods, Lambda, EC2, or IP addresses.
• Auth policy — IAM policy that controls which principals in which VPCs can call which services.

VPC Lattice is compelling for 50-microservice scenarios where services live in many VPCs and many accounts. It replaces N×(N-1)/2 VPC peering with a single service network and gives consistent IAM-based auth.

When to Pick App Mesh, VPC Lattice, or Istio

• Istio / Linkerd on EKS — you already invested in Kubernetes-native mesh and need features AWS has not shipped (fault injection, WASM extensions).
• VPC Lattice — cross-account, cross-VPC, multi-service-type (mix of ECS, EKS, Lambda, EC2) with IAM auth as the primary control plane.
• App Mesh — only for existing deployments that already chose it; do not start new designs on App Mesh.

Container Image Security — ECR Scanning, Inspector, Signing

Containerization ECS EKS image security is a SAP-C02 topic unto itself. You are expected to know ECR scanning tiers, Inspector integration, and signing.

ECR Basic vs Enhanced Scanning

Amazon ECR offers two scanning modes:

• Basic scanning — powered by Clair (open-source), free, scans on push, returns CVE findings. Good enough for most non-regulated workloads.
• Enhanced scanning — powered by Amazon Inspector v2, integrates with the Inspector dashboard, includes continuous scanning of existing images (not just on push), detects OS and language-package vulnerabilities, and produces EventBridge findings you can route to Security Hub.

For regulated SAP-C02 scenarios ("PCI-DSS container compliance," "continuous vulnerability visibility"), the correct answer is ECR Enhanced Scanning with Inspector v2.

Amazon Inspector for Containers

Inspector v2 continuously scans ECR images, running EC2 instances, and Lambda functions for vulnerabilities. For containers, Inspector deep-scans the image layers on push and continuously re-evaluates existing images when new CVEs are published — catching vulnerabilities that did not exist when the image was first pushed. Findings flow to AWS Security Hub and EventBridge for automated response.

Container Image Signing

For high-assurance supply chains, signing images with AWS Signer and validating signatures at deploy time prevents deploying untrusted images. The canonical pattern uses AWS Signer with Notation or Cosign signatures stored in ECR; Kyverno or a similar policy engine on EKS validates signatures before admitting pods; ECS validates via a task-definition check or a CI/CD gate.

Multi-Account and Multi-Region Container Strategies

Containerization ECS EKS at organizational scale means many accounts, many regions, and shared platform services. SAP-C02 compound questions almost always cross at least two of these boundaries.

Multi-Account Container Platform Patterns

Most platform teams settle on a three-tier account structure for containerization ECS EKS:

• Shared-services account — central ECR, central Route 53 private hosted zones, central VPC Lattice service network, central CI/CD tooling.
• Workload accounts — one per team or per environment; run the ECS or EKS clusters.
• Security account — centralized GuardDuty, Security Hub, Inspector findings, and log aggregation.

Cross-account ECR pull is enabled via ECR registry policies and repository policies; EKS nodes in workload accounts assume roles that can pull images from the shared-services ECR. For ECS on Fargate, the execution role in the workload account needs explicit permission to pull from cross-account ECR.

Multi-Region Container Strategies

Multi-region containerization ECS EKS designs fall into three RTO/RPO tiers.

• Pilot light — image and manifests replicated via ECR replication rules and GitOps; clusters pre-created but scaled to zero; failover scales out on demand. Lowest cost, RTO measured in tens of minutes.
• Warm standby — smaller identical clusters running in the secondary region; Route 53 failover routing flips traffic; data layer replicates continuously (Aurora Global Database, DynamoDB Global Tables). RTO in low minutes.
• Active/active — equal-capacity clusters in both regions behind Global Accelerator or Route 53 latency routing; traffic served regionally, writes coordinated via Global Database or the application layer. RTO near zero, highest cost.

Route 53 health checks must probe an endpoint that reflects actual cluster health — not just the ALB, but a deep health endpoint that verifies the data layer too, otherwise failover routing will keep sending traffic to a broken region.

The Canonical 50-Microservice Polyglot Multi-Region Cutover Scenario

Consider the compound SAP-C02 scenario: 50 microservices owned by six polyglot teams, currently on EC2 in a single region, must migrate to containers with multi-region active/active and a 40% cost reduction target.

The Pro-level target architecture for this containerization ECS EKS scenario:

1. Orchestrator — EKS, because six polyglot teams usually includes Java Spring, Python FastAPI, Go, Node.js, and at least one team already using Helm. Portability and ecosystem are the tiebreakers.
2. Compute mix — Karpenter managing on-demand and Spot EC2 in a 20/80 ratio on Bottlerocket AMIs (purpose-built container OS, atomic updates, reduced attack surface); small managed node group for DaemonSets; Fargate profiles for batch jobs and untrusted workloads.
3. Image supply chain — central ECR in a shared-services account with ECR replication to the secondary region, Inspector Enhanced Scanning, AWS Signer for signing, Kyverno policy on EKS for signature verification.
4. Networking — VPC Lattice service network spanning both regions for cross-service traffic, ALB per region at the edge, Route 53 latency routing across regions with deep health checks.
5. Data layer — Aurora Global Database for relational, DynamoDB Global Tables for key-value, S3 Cross-Region Replication for objects.
6. IAM — EKS Pod Identity for the new workloads; cross-account pull roles for ECR.
7. CI/CD — CodePipeline triggers per microservice, deploys via Argo CD or Flux GitOps into each cluster; progressive delivery with Argo Rollouts + Karpenter consolidation.
8. Cost — Compute Savings Plans covering baseline Karpenter on-demand capacity (~40% discount), Spot covering bursty capacity (~70% discount), Fargate Spot on batch profiles. Blended compute savings exceed the 40% target.
9. Cutover — deploy the new architecture in parallel, drain traffic via weighted Route 53 at 10% / 25% / 50% / 100% over two weeks, hold the old architecture warm for one more week as rollback, then decommission.

This is a representative SAP-C02 answer shape: multi-domain, cites specific services with justification, explicitly addresses cost and risk.

Cost Optimization for Containerization ECS EKS

Container cost optimization is a Pro-level skill because the levers compound. Here is the containerization ECS EKS cost playbook.

Fargate Spot for Stateless and Batch

Fargate Spot gives up to 70% discount on ECS Fargate tasks and EKS Fargate pods, with a 2-minute interruption notice via SIGTERM. Ideal for stateless microservices behind a load balancer (the load balancer routes around interrupted tasks), batch jobs (restart on interruption), and development / CI environments.

Compute Savings Plans for Steady Capacity

Compute Savings Plans commit to an hourly spend on Fargate, Lambda, and EC2 for 1 or 3 years and yield up to 66% off On-Demand (higher for 3-year all-upfront). Compute Savings Plans automatically apply across Fargate, Lambda, and EC2, so they are the correct answer for mixed-compute fleets. Do not use EC2 Instance Savings Plans for containerization ECS EKS unless you are committed to a specific instance family.

Bottlerocket — Purpose-Built Container OS

Bottlerocket is AWS's container-optimized Linux distribution. It ships with only the packages needed to run containers, supports atomic updates with automatic rollback, reduces the attack surface versus general-purpose AMIs, and boots faster than Amazon Linux 2 / 2023 for containerization ECS EKS workloads. Bottlerocket is available as managed node group AMI choice and is the default for EKS Auto Mode and many Karpenter configurations.

SAP-C02 reasons to pick Bottlerocket:

• Compliance scenarios requiring minimal installed packages.
• Rapid node rotation / patching — atomic updates roll forward or back.
• Faster scale-out — reduced boot time when Karpenter launches a node.

Right-Sizing and Consolidation

AWS Compute Optimizer now produces recommendations for ECS services on Fargate and EKS container right-sizing. Karpenter's consolidation feature automatically bin-packs pods onto fewer nodes when utilization is low. Container Insights on CloudWatch exposes per-task and per-pod CPU and memory metrics that you can feed back into task definitions and pod resource requests.

Graviton for Containers

AWS Graviton (ARM64) instances deliver up to 40% better price/performance for many container workloads. Both ECS and EKS support Graviton-backed Fargate (through the task definition runtimePlatform field) and Graviton EC2 instances. Scenarios that mention "further cost reduction for stateless microservices" often take Graviton as the last-mile answer.

Common Exam Traps in Containerization ECS EKS

These containerization ECS EKS traps recur on SAP-C02 attempts.

Trap 1 — EKS Picked Because Containers Are Mentioned

Only pick EKS when the scenario evidences Kubernetes-specific needs. Otherwise ECS on Fargate is cheaper and faster.

Trap 2 — IRSA and Pod Identity Treated as Interchangeable

They solve the same problem differently. Pod Identity does not run on Fargate; IRSA does. Cross-account is easier with Pod Identity. Know both.

Trap 3 — Fargate Assumed to Support Every Pod Shape

Fargate pods do not support DaemonSets, hostNetwork, hostPort, privileged, GPU, or EBS. Questions that require any of these rule out Fargate-only designs.

Trap 4 — App Mesh Recommended for Greenfield

App Mesh is in maintenance mode. Use VPC Lattice or an open-source mesh for new designs.

Trap 5 — ECR Basic Scanning Assumed to Continuously Scan

Basic scanning runs only on push. Continuous re-scanning requires Enhanced Scanning / Inspector v2.

Trap 6 — Cluster Autoscaler Chosen When Karpenter Is Stated Available

If the scenario says "just-in-time capacity" or "mixed instance types" or "aggressive Spot usage," Karpenter is the target answer.

Trap 7 — Capacity Providers Confused With Auto Scaling Groups

Capacity providers are an ECS abstraction; they can wrap a Fargate capacity source or an EC2 ASG. Auto Scaling Groups alone are insufficient for ECS cluster auto-scaling; you need a capacity provider bound to the ASG.

Trap 8 — ECS Anywhere and EKS Hybrid Nodes Swapped

ECS Anywhere pushes ECS tasks onto on-prem hardware. EKS Hybrid Nodes pushes on-prem servers into an EKS cluster. They solve different problems; scenarios that specify Kubernetes API compatibility on-prem need EKS Hybrid Nodes.

Containerization ECS EKS vs Neighboring SAP-C02 Topics

Clear boundaries with sibling topics prevent cross-topic confusion on the exam.

• containerization-ecs-eks vs event-driven-serverless-architecture — this chapter owns containers; serverless owns Lambda, EventBridge, Step Functions. Combined scenarios route events into containers via EventBridge → Fargate or SQS → Fargate worker pools.
• containerization-ecs-eks vs modernization-app-target-architecture — modernization covers the migration playbook and the 6-Rs (refactor, replatform); this chapter covers the target platform once replatform to containers is the decision.
• containerization-ecs-eks vs cicd-iac-deployment-strategy — CI/CD covers pipelines, blue/green, canary; this chapter covers container-specific runtime concerns.
• containerization-ecs-eks vs new-solutions-reliability — reliability covers multi-AZ, retries, circuit breakers generically; this chapter covers container-specific HA (Fargate AZ spread, Pod Anti-Affinity, PDBs).
• containerization-ecs-eks vs new-solutions-cost-design — cost-design covers pricing frameworks (RI, Savings Plans) for all services; this chapter applies them specifically to containers.

Key Numbers to Memorize for Containerization ECS EKS

• ECS control plane: free.
• EKS control plane: $0.10 per cluster per hour (~$73 per month).
• Fargate Spot discount: up to 70%, 2-minute interruption notice via SIGTERM.
• Compute Savings Plans: up to 66% off with 3-year all-upfront; apply across Fargate, Lambda, EC2.
• Fargate task sizes: 0.25 vCPU (0.5-2 GB) up to 16 vCPU (30-120 GB).
• Fargate ephemeral storage: 20 GB default, up to 200 GB.
• EKS pod identity rollout: GA 2023; not available on Fargate.
• IRSA: requires OIDC provider per cluster; cross-account requires trust-policy federation.
• Karpenter: sub-minute node provisioning; consolidation across node pools.
• ECR Enhanced Scanning: continuous rescan powered by Inspector v2.
• ECS Anywhere: flat per-external-instance hourly fee; no ALB / EBS at external instance.
• EKS Hybrid Nodes: on-prem Linux joined to EKS control plane over Direct Connect or VPN.

FAQ — Containerization ECS EKS at Pro Scale

Q1. When does ECS beat EKS at SAP-C02 Pro level, and when does EKS beat ECS?

ECS beats EKS for AWS-native greenfield workloads where the team does not already run Kubernetes, where deep ALB / IAM / CloudWatch / Secrets Manager integration matters more than portability, and where the ~$73/month per-cluster EKS control-plane fee multiplied across many clusters is material. EKS beats ECS when portability is required (multi-cloud, on-prem Kubernetes today or tomorrow), when the ecosystem of Kubernetes-native tooling (Helm charts, operators, service meshes, GitOps) is in use, when teams are polyglot and have already standardized on the Kubernetes API, or when vendor software ships only as Kubernetes manifests. At SAP-C02 depth, always scan the scenario for explicit evidence — "team runs Kubernetes on-prem," "uses Helm," "needs multi-cloud manifests" — before choosing EKS over ECS.

Q2. How do ECS capacity providers blend Fargate, Fargate Spot, and EC2 for cost optimization?

ECS capacity providers are an abstraction that lets a service target multiple compute backends with a weighted strategy. You define a capacity provider strategy as an ordered list where each provider has a base (minimum number of tasks on that provider) and weight (relative share of tasks beyond the base). A canonical cost-optimized pattern for a stateless service is base=2 weight=1 on Fargate on-demand and weight=4 on Fargate Spot, which keeps two tasks on reliable capacity and distributes the rest at roughly 20% on-demand and 80% Spot. For EC2-backed clusters, capacity providers wrap an Auto Scaling Group, and managed scaling on the capacity provider automatically scales the ASG to absorb pending tasks. Mixing Fargate for burst and an EC2 ASG capacity provider for steady capacity is a common hybrid pattern when Reserved Instances or Savings Plans are already committed on EC2.

Q3. What is the practical difference between IRSA and EKS Pod Identity, and when do I pick each?

IRSA (IAM Roles for Service Accounts) uses OIDC federation: the EKS cluster publishes an OIDC issuer URL, you register that URL as an IAM identity provider, and the AWS SDK inside the pod exchanges a projected ServiceAccount token for STS credentials via AssumeRoleWithWebIdentity. EKS Pod Identity uses a service principal (pods.eks.amazonaws.com) plus a Pod Identity Association resource that maps a namespace + service account to an IAM role, with credentials delivered via a Pod Identity Agent DaemonSet. Pick Pod Identity for new clusters where you want simpler trust policies, easier cross-account setup, and no OIDC provider to manage — but note Pod Identity does not run on Fargate because it depends on the DaemonSet agent. Pick IRSA when the workload runs on Fargate, when the cluster is pre-existing and already standardized on IRSA, or when you need a trust model that is portable across non-AWS Kubernetes clusters. Coexistence in the same cluster is supported, which is useful during a migration from IRSA to Pod Identity.

Q4. How do Karpenter and Cluster Autoscaler differ, and when do I choose Karpenter?

Cluster Autoscaler (CA) scales pre-defined EC2 Auto Scaling Groups (node groups) up or down based on pending pods; you must design node group shapes in advance, and CA reacts within a few minutes. Karpenter replaces node groups with NodePool and EC2NodeClass custom resources that describe allowed instance families, capacity types, and zones; when pending pods appear, Karpenter evaluates their resource requirements and launches the cheapest EC2 instance that fits, often in under a minute. Karpenter also has first-class Spot handling (it reacts to interruption notices gracefully and falls back to On-Demand) and a consolidation feature that actively moves pods onto fewer, cheaper nodes when utilization drops. Choose Karpenter for cost-sensitive, heterogeneous workloads where you want just-in-time capacity and mixed Spot / On-Demand. Choose Cluster Autoscaler when the workload is uniform, node group design is already solid, and operational familiarity matters more than the last bit of cost savings. Most SAP-C02 greenfield EKS answers now default to Karpenter.

Q5. When should I use VPC Lattice versus an in-cluster service mesh like Istio for a 50-microservice platform?

VPC Lattice is the right answer when services span many VPCs and many AWS accounts, mix compute types (ECS, EKS, Lambda, EC2), and the primary control surfaces are IAM-based authorization and managed L7 connectivity — all without sidecars. You get service discovery, IAM auth policies, HTTP / gRPC routing, and cross-account access with a single AWS-managed control plane. In-cluster service meshes like Istio are the right answer when you need Kubernetes-native features that VPC Lattice does not ship — fine-grained traffic shifting, fault injection for chaos testing, WASM extensions, Envoy configuration tuning, or open-source ecosystem integration (Kiali dashboards, SPIFFE/SPIRE identity). A common hybrid pattern in a 50-microservice SAP-C02 scenario uses VPC Lattice at the platform boundary (for cross-account, cross-VPC service calls with IAM auth) and Istio or Linkerd inside each EKS cluster (for intra-cluster retries, mTLS, and traffic splitting). Avoid App Mesh for new designs because it is in maintenance mode.

Q6. What is the right multi-region strategy for a containerization ECS EKS platform that must cut over without downtime?

For no-downtime multi-region cutover, run equal or near-equal clusters in both regions, replicate container images via ECR replication rules, replicate configuration via GitOps (Argo CD / Flux pointing at both clusters), replicate state at the data layer (Aurora Global Database, DynamoDB Global Tables, S3 Cross-Region Replication), front the platform with Route 53 latency or weighted routing (or Global Accelerator for anycast), and use deep health checks that probe the full request path (application + database) rather than just the ALB. Execute the cutover as a weighted traffic shift: 10% to the new region, monitor error rates and latency, ratchet to 25%, 50%, 100%, then hold the old region warm for a rollback window before decommissioning. This is an active/active or warm-standby pattern; pilot-light patterns do not meet the "no downtime" requirement because scaling from zero takes minutes. The exam rewards scenarios that cite these specific services and the staged-rollout cadence.

Q7. How do ECR Basic scanning, ECR Enhanced scanning, and Amazon Inspector v2 relate for container image security?

ECR Basic scanning (free, powered by Clair) runs once when an image is pushed and reports CVEs against that single snapshot of the image. ECR Enhanced scanning is powered by Amazon Inspector v2 and enables continuous scanning: Inspector re-evaluates pushed images whenever new CVEs are published, so a vulnerability discovered months after an image was pushed still surfaces as a finding. Inspector v2 for containers also extends to Lambda and EC2, and findings flow to AWS Security Hub and EventBridge for automated response (for example, an EventBridge rule can notify SNS and open a Jira ticket when a critical finding appears). For SAP-C02 scenarios that require continuous visibility or PCI-DSS-style compliance, the correct answer is ECR Enhanced scanning with Inspector v2 plus Security Hub aggregation. Pair this with AWS Signer or Cosign for image signing and a Kyverno or OPA Gatekeeper policy on EKS (or a CI gate on ECS) that rejects unsigned images to complete the supply-chain security story.

Q8. How do I cost-optimize a 50-microservice containerization ECS EKS platform to hit a 40% reduction target?

Stack the cost levers: first, right-size pod resource requests and task CPU / memory via Compute Optimizer recommendations and Karpenter consolidation — this alone often frees 10-20% of capacity. Second, adopt Graviton (ARM64) for any microservices whose language runtimes support it; expect 20-40% price/performance improvement per workload. Third, cover baseline capacity with Compute Savings Plans (up to 66% for 3-year all-upfront, applies across Fargate, Lambda, EC2). Fourth, move bursty and batch workloads to Fargate Spot or EC2 Spot via Karpenter (up to 70% discount). Fifth, switch managed nodes to Bottlerocket for faster boot times and smaller attack surface. Sixth, centralize ECR in a shared-services account with replication to workload regions to avoid per-account data-transfer costs. Seventh, use VPC endpoints instead of NAT Gateway where traffic stays AWS-to-AWS. Measure the result in blended unit cost (cost per request), not in monthly bill, so regressions surface early. Hitting 40% is realistic for most SAP-C02-style greenfield scenarios once these layers combine.

Summary — Containerization ECS EKS at a Glance

• Containerization ECS EKS at SAP-C02 depth is a six-dimension decision: team skill, portability, control-plane cost, operational overhead, ecosystem, AWS-native integration.
• ECS Pro topics: capacity providers (Fargate + Spot + EC2), Cloud Map service discovery, ECS Exec for auditable debugging, ECS Anywhere for on-prem, task definitions with task role vs execution role distinction.
• EKS Pro topics: control plane HA + audit logging + private endpoint, managed node groups vs self-managed vs Fargate profiles, IRSA vs Pod Identity (Pod Identity is simpler but not on Fargate), EKS add-ons, EKS Hybrid Nodes for on-prem Kubernetes.
• Karpenter beats Cluster Autoscaler for cost-sensitive, heterogeneous, Spot-heavy workloads; CA remains valid for uniform, stable node-group-shaped fleets.
• Service mesh: VPC Lattice for cross-VPC, cross-account, cross-compute-type; Istio / Linkerd for Kubernetes-native advanced features; App Mesh only for legacy (maintenance mode).
• Image security: ECR Enhanced scanning with Inspector v2 for continuous visibility, AWS Signer + Kyverno / OPA for signed-image admission.
• Multi-account: shared-services ECR with cross-account pull, VPC Lattice for service networking across accounts, Organizations + SCPs for guardrails.
• Multi-region: active/active for near-zero RTO, warm standby for minutes, pilot light for tens of minutes; Route 53 latency or weighted routing with deep health checks; data layer via Aurora Global Database, DynamoDB Global Tables, S3 CRR.
• Cost: Compute Savings Plans for baseline, Fargate Spot for stateless, Graviton for suitable runtimes, Bottlerocket for node efficiency, right-sizing via Compute Optimizer and Karpenter consolidation.
• The canonical 50-microservice polyglot multi-region scenario resolves as EKS + Karpenter on Spot + Bottlerocket + VPC Lattice + Aurora Global Database + Route 53 latency routing + GitOps + Compute Savings Plans, with staged weighted traffic cutover.

Master containerization ECS EKS at this Pro depth and the SAP-C02 Domain 2 container slice, along with the Domain 4 modernization overlaps, becomes pattern recognition rather than memorization. The framework carries into real platform-architecture decisions well beyond the exam.