ECS, EKS, Fargate, and ECR at Enterprise Scale

Orchestrator versus compute

SAP-C02 container questions fail when candidates treat Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Fargate as three equal orchestrators. ECS and EKS schedule containers. Fargate is a serverless compute engine that runs ECS tasks or EKS pods so you do not patch container-instance AMIs. You can also run both orchestrators on Amazon EC2 (or on Outposts, and with different hybrid options).

Apex Health has two container platforms in one organization: a claims API that must ship with AWS-native IAM task roles and no Kubernetes specialists, and a genomics toolkit that already ships Helm charts and custom resource definitions (CRDs) used in academic Kubernetes clusters. Those are two different answers, not a mandate to put everything on EKS.

When ECS is enough

Choose ECS when the team thinks in AWS primitives: task definitions, services, target groups, IAM task roles, Amazon CloudWatch logs, and CodeDeploy blue/green. There is no per-cluster Kubernetes control-plane charge. You still pay for EC2 or Fargate, load balancers, and data transfer.

Capacity providers are how ECS asks for infrastructure:

• FARGATE and FARGATE_SPOT for Fargate tasks (Spot interrupts with a two-minute warning; use for interruption-tolerant workers).
• Auto Scaling group capacity providers for EC2, optionally with cluster auto scaling and even ASG warm pools.

Hard rules that win exam items:

• Associate the provider with the cluster before you put it in a strategy.
• A cluster may contain both ASG providers and Fargate providers.
• A single capacity-provider strategy cannot mix ASG providers with Fargate providers.
• You cannot update a service from an ASG provider to Fargate (or the reverse) without treating it as a different compute model; force a new deployment when switching a service from a launch type to a strategy.

Put the claims API on Fargate (FARGATE with a small FARGATE_SPOT weight only if the work is retry-safe). Put GPU transcoding on an EC2 ASG capacity provider with GPU instance types. Do not try to express both in one service strategy.

When the Kubernetes control plane is justified

Choose EKS when the requirement is the Kubernetes API: Helm, operators, admission webhooks, service meshes that assume Kubernetes, multi-cloud portability, or a platform team that already operates Kubernetes. AWS manages the control plane (API server, etcd, availability) for EKS standard clusters. EKS Auto Mode can also manage node provisioning, scaling, and OS patching for an extra compute-management charge on top of EC2.

You pay a per-cluster hourly fee based on Kubernetes version support: standard support is billed at $0.10 per cluster per hour; after 14 months a version can enter extended support at a higher published rate ($0.60 per cluster per hour in current public pricing, which is standard plus an extended-support adder). Confirm the Amazon EKS pricing page—do not freeze a number forever in a runbook without checking. Provisioned Control Plane tiers (XL through 8XL and beyond) add capacity for huge clusters on top of the version fee. Hybrid Nodes add per-vCPU-hour charges for on-premises nodes joining an EKS cluster.

If the stem is “we have no Kubernetes skills and no portability requirement,” paying for EKS (and staffing it) is usually the wrong Professional answer. If the stem is “operators, CRDs, and the same manifests on-premises and in AWS,” EKS is justified even though ECS would be cheaper.

Networking: awsvpc, discovery, and meshes

Fargate requires awsvpc. Each task or pod receives an elastic network interface (ENI), a private IP, and security groups as if it were an instance. On ECS on EC2, awsvpc is still the recommended mode; bridge (Linux default), host, none, and Windows default/nat exist for compatibility. host pins hostPort and blocks packing many copies of the same task on one instance. none has no external connectivity and cannot use service discovery.

Service discovery registers tasks in AWS Cloud Map. DNS names resolve inside the VPC to task private IPs, not to a load balancer, even if the service also has an ALB. Limits and constraints: up to 1,000 tasks per discovery-enabled service (Route 53 quota), Fargate platform 1.1.0+, no Classic Load Balancers, no shared Cloud Map namespaces, and awsvpc can use A/AAAA/SRV while bridge/host use SRV only. Health is typically ECS-managed custom health pushed to Cloud Map. Service Connect adds a managed way to connect services with namespaces and resilience without standing up a full third-party mesh. App Mesh on ECS Anywhere is not supported—another reason not to copy-paste a Region design onto external instances.

ENI density on EC2 with awsvpc is a capacity limit: instance types have a maximum ENIs, and each awsvpc task consumes one. That is why large ECS-on-EC2 services sometimes stay on bridge despite AWS recommending awsvpc—the exam will tell you if ENI exhaustion is the constraint.

Amazon ECR at enterprise scale

Amazon Elastic Container Registry (Amazon ECR) is the image store for both ECS and EKS. Private image replication supports cross-Region and cross-account destinations (not cross-partition, so no us-west-2 to cn-north-1). Configuration may include up to 25 unique destinations and 25 rules, each with up to 100 filters (for example only prod/ prefixes).

Replication is not retroactive: only images pushed or restored after you enable the rule replicate. Preexisting disaster-recovery copies need a one-time copy (or restore-after-enable). Replication does not delete or archive destinations when you delete the source. Repository policies and lifecycle policies do not copy with the image; use repository creation templates if destination repos must inherit encryption or immutability. Tag immutability can produce an untagged replica if the tag already exists. Cross-account replication requires a destination registry permissions policy allowing the source account ecr:ReplicateImage and usually ecr:CreateRepository. The source repository does not need a “allow destination to pull for replication” policy—that is a documented misconception.

Apex Health replicates prod/* from the shared-services account in us-east-1 to a DR account in eu-west-1. DR’s registry policy trusts the source account. Last year’s images were copied once with a batch job the day replication was turned on.

Hybrid: only with current limits

Amazon ECS Anywhere registers an on-premises server or VM to an ECS cluster using AWS Systems Manager hybrid activations. Launch type is EXTERNAL. Current documented limits that change designs: no service load balancing, no Cloud Map service discovery, no awsvpc (use bridge, host, or none), no ECS capacity providers, no EFS volume configuration, instance registered to one cluster at a time. External instances fit outbound or processing work; inbound web services without an ALB are a poor fit. Windows support for ECS Anywhere has been deprecated. Beginning 7 August 2026, several operating systems (including Amazon Linux 2, older Ubuntu/Debian/RHEL, and listed Windows Server versions) are no longer supported—plan OS upgrades, do not copy old blog AMIs.

EKS Anywhere means you run EKS Distro Kubernetes on your hardware and you operate that control plane. Amazon EKS Hybrid Nodes is the newer pattern when you want the EKS control plane in AWS and worker capacity on-premises or at the edge, billed per vCPU-hour. Do not use “Anywhere” as a vague synonym for every hybrid Kubernetes option.

Exam traps: Fargate as an orchestrator; mixing Fargate and ASG in one strategy; bridge on Fargate; assuming ECR replication backfills old tags; putting source-repo policies on the wrong account; ECS Anywhere plus ALB plus awsvpc; paying extended-support EKS rates because nobody upgraded Kubernetes; defaulting every microservice to EKS Provisioned Control Plane 8XL.