SAP-C03 Containers, Auto Scaling, Ingress and Edge: ECS, EKS, Fargate, VPC Lattice, ECR, Load Balancers and CloudFront

Choose Amazon EKS when the organization already depends on Kubernetes (manifests, Helm charts, GitOps tools such as Argo CD, custom operators and CRDs) or needs Kubernetes portability; choose Amazon ECS when the team has no Kubernetes investment and wants the least to learn and operate. Both are managed control planes, so neither requires you to run masters or etcd. The second, separate decision is where tasks or pods run: on AWS Fargate (no servers to patch, scale or right-size) or on EC2 capacity you manage through Auto Scaling groups, managed node groups or Karpenter.

Per-service permissions come from the workload identity, not from the infrastructure. On ECS, each task definition gets its own task role, which the application code uses for AWS API calls. The task execution role is different: the ECS agent assumes it to pull images from Amazon ECR, fetch secrets for the task and send logs. Sharing one broad execution role, or one broad task role, across services breaks least privilege. On EKS the equivalent is EKS Pod Identity (or IAM roles for service accounts), which maps a Kubernetes service account to an IAM role.

Fargate cannot run GPU workloads, privileged containers or Kubernetes DaemonSets, because there is no node you control: each pod or task gets its own isolated compute environment. On EKS, pods are sent to Fargate only when they match a Fargate profile (namespace and optional labels); a pod that needs a GPU or a DaemonSet that needs node-level access stays Pending, because no Fargate setting provides that capability, and node autoscalers manage EC2 nodes, not Fargate. The fix is mixed capacity: add EC2 managed node groups (with GPU instance types where needed) for those workloads and keep everything else on Fargate. A node-level agent on Fargate has to run as a sidecar in each pod instead, and only if it does not need privileged mode.

Capacity provider strategies on ECS

An ECS service can spread tasks across capacity providers such as FARGATE and FARGATE_SPOT (or Auto Scaling group providers). A strategy has two numbers per provider:

• base: the minimum number of tasks placed on that provider first. Only one provider in a strategy may have a base greater than zero.
• weight: after the base is met, remaining tasks are split in proportion to the weights. FARGATE weight 1 with FARGATE_SPOT weight 3 puts about three of every four extra tasks on Spot.

Put the guaranteed baseline (base) on regular FARGATE, never on Spot: if Spot capacity is unavailable, ECS does not fall back to regular Fargate, so a Spot baseline can go unmet.

Handling Fargate Spot interruptions

When AWS reclaims Fargate Spot capacity, the task receives a two-minute warning (also published as an ECS task state change event to Amazon EventBridge) and the container receives SIGTERM. ECS sends SIGKILL after the container's stopTimeout, which defaults to 30 seconds and can be raised to 120 seconds on Fargate. To avoid losing in-flight work, the application must catch SIGTERM, stop taking new work (for example, stop receiving SQS messages) and finish or checkpoint the current item, and stopTimeout must be long enough for that. EC2 Spot Instance interruption warnings do not apply to Fargate tasks.

For microservice communication and observability on AWS, use Amazon ECS Service Connect when every service runs on ECS, and Amazon VPC Lattice when services span compute types (EC2, ECS, EKS, Lambda), VPCs or accounts and need IAM-based request authorization. Both are managed: neither asks you to run your own Envoy sidecars. AWS App Mesh reached end of support on 30 September 2026, and AWS points its users to Service Connect for ECS and to VPC Lattice for cross-VPC and cross-account traffic, so App Mesh is never a design choice for new work.

Neighbouring options solve less. AWS Cloud Map DNS discovery alone gives names but no proxy, so no retries and no HTTP status metrics. Internal ALBs per service add infrastructure to manage and give no client-side retries. AWS PrivateLink tolerates overlapping CIDRs but needs an endpoint service and interface endpoints per service and cannot authorize individual IAM roles per request. Transit Gateway requires non-overlapping address space and offers only network-level controls.

VPC Lattice connects clients to services through a service network: a logical boundary that holds services (each with listeners, rules and target groups) and associations. A client VPC reaches every service in a service network once the VPC is associated with it (or through a service network VPC endpoint); traffic is routed by Lattice, not by your route tables, so VPC CIDRs may overlap.

Cross-account setup

1. The owning account (often a central networking account) creates the service network and shares it through AWS Resource Access Manager with other accounts or the whole organization. Services can be shared the same way.
2. Service owners associate their services with the shared service network.
3. Consumer accounts create a service network VPC association for each client VPC. No VPC peering, transit gateway attachment or private hosted zone is required.

Auth policies and SigV4

With auth type AWS_IAM, Lattice evaluates IAM-style auth policies at two levels, and a request must be allowed by both: the service network policy (typically a coarse guardrail such as "principals in my organization") and the service policy (fine-grained, for example "only the billing role may call vpc-lattice-svcs:Invoke on these paths"). Auth policies apply to HTTP and HTTPS listeners. Lattice can only identify the caller when the request is signed with SigV4 (or SigV4A) for the vpc-lattice-svcs service, using the caller's IAM credentials (with an unsigned-payload header). An unsigned request is anonymous, so a policy that allows only specific roles or organization members returns HTTP 403. Read the symptom: a 403 means the request reached Lattice and was denied by policy; a timeout or refused connection points at the network path instead.

Service Connect gives ECS services short names, retries, outlier detection and traffic metrics by having ECS inject and manage a proxy in every task; you configure it, you never maintain the proxy container. Two pieces of configuration make it work:

• Task definition: the container's port mapping gets a name, and an appProtocol (http, http2 or grpc) so the proxy can produce protocol-aware metrics such as 5xx counts.
• ECS service: Service Connect is turned on with an AWS Cloud Map namespace (shared by every service that should talk to each other, across clusters), the port name, a discovery name and the client alias (DNS name and port) that callers use.

A service is either a client service (it only calls others) or a client-server service (it also publishes endpoints). The behaviour most often tested: running tasks do not learn about endpoints added after they started. When a new client-server service joins the namespace, services deployed afterwards can reach it, but a long-running client cannot until you start a new deployment of that client. The proxy receives its endpoint list when the task launches, so only new tasks pick up new endpoints.

ECR offers two scan types, chosen for the whole registry (you cannot mix them per repository):

With enhanced scanning, the registry scanning configuration holds rules that pair a frequency (continuous or scan on push) with repository name filters (wildcards allowed). If a repository matches both a continuous and a scan-on-push filter, continuous wins; a repository that matches no filter is not scanned. That lets you rescan production repositories continuously and scan everything else once at push to control Inspector charges. Amazon GuardDuty Runtime Monitoring is a different control: it watches running workloads for threats, not images for CVEs.

Gating deployments and pinning releases

Tag immutability rejects any push that would move an existing tag, so a release tag permanently identifies one image and the repository enforces it whoever pushes, so IAM push permissions alone cannot give that guarantee. To stop vulnerable images reaching production, a pipeline stage waits for the image's enhanced scan to complete, reads its findings and fails on the severities you set (for example CRITICAL). Deploying by image digest is another way to pin exactly what runs.

Lifecycle policies

A lifecycle policy removes unneeded images automatically with no code. Each rule has a rulePriority (lower numbers are evaluated first) and a selection:

• tagStatus: untagged, tagged (with tagPrefixList, such as release-, or tagPatternList with wildcards, such as release-*) or any (which must have the highest rulePriority number, so it is evaluated last).
• countType: sinceImagePushed with a countUnit of days (age-based, for example expire untagged images after 7 days) or imageCountMoreThan (count-based, for example keep the newest 20 release images).

Two rules govern how a policy reads: tag patterns match literally except where they contain a wildcard, and the count type decides the behaviour (a count rule keeps a number of images, an age rule expires images by time). Lifecycle policies are ECR's built-in retention mechanism; tag immutability governs overwrites, not retention.

Lambda scaling is governed by concurrency, and each control solves a different problem:

Two traps recur. First, provisioned concurrency also guarantees capacity, but it costs money and targets cold starts; if latency is fine and the need is a guaranteed share of the pool, reserved concurrency is the cheaper answer. Without reserved concurrency every function draws from one shared pool, however large that pool is. Second, capping an SQS-triggered function with reserved concurrency alone lets the poller keep scaling; its invocations are throttled, the batches return to the queue, each counts as a receive, and after maxReceiveCount healthy messages land in the dead-letter queue with no code error. Set maximum concurrency on the event source mapping instead, and keep reserved concurrency at or above the total maximum concurrency of the function's SQS sources.

Container scaling has two layers that must both work: the number of tasks or pods, and the capacity they run on. With Fargate only the first layer exists; with EC2 capacity you also have to scale instances.

Amazon ECS service auto scaling

ECS services scale through Application Auto Scaling with target tracking, step or scheduled policies. Target tracking works only on a metric that falls proportionally as tasks are added, so pick it from the workload:

• CPU or memory bound: average CPU or memory utilization.
• Request bound behind an ALB (for example I/O-bound tasks waiting on a database, with low CPU): ALBRequestCountPerTarget, with the target set to the request rate one task handles comfortably. The load balancer's total RequestCount does not change as tasks are added, so totals across the load balancer do not suit target tracking; per-target metrics exist for this reason.
• Queue workers: backlog per task (visible SQS messages divided by running tasks, built with CloudWatch metric math), with the target equal to the backlog one task can clear in an acceptable time. Raw queue depth does not scale proportionally.

Scheduled scaling suits known, repeating patterns; step scaling adds or removes fixed increments when an alarm breaches; target tracking is the usual choice when a metric reflects load per task.

ECS on EC2: capacity providers

If tasks sit in PROVISIONING because the cluster lacks room, or scale-in terminates instances that still run tasks, use an Auto Scaling group capacity provider with managed scaling (ECS publishes a capacity metric based on the tasks it needs to place and scales the group to it) and managed termination protection (instances running tasks are protected from scale-in). Managed scaling responds to tasks waiting for placement rather than to instance utilization, and it replaces custom scaling and draining code.

Amazon EKS: Horizontal Pod Autoscaler and node scaling

The Horizontal Pod Autoscaler scales a Deployment's replicas on metrics from the Kubernetes Metrics Server (or custom and external metrics through an adapter). Utilization is measured against the containers' resource requests, so a pod template without CPU requests leaves the HPA showing unknown and never scaling, even when kubectl top works. Pods also need nodes:

Karpenter's advantage comes from flexibility: the broader the instance requirements a NodePool allows, the better it can fit pods and consolidate nodes. Disruption budgets limit how many nodes may be voluntarily disrupted at once, and consolidation is a voluntary disruption, so a budget that allows none also stops consolidation. Amazon EKS Auto Mode runs Karpenter-based node management for you if the team does not want to operate it.

Pick the front door from the protocol and the features the scenario names, then from cost at the traffic pattern:

Two combinations recur. To offer an HTTP API privately to many customer VPCs with overlapping CIDRs and route by path, put an NLB endpoint service in front of an ALB (an NLB can register an ALB-type target group). And for steady, very high traffic that uses no API Gateway features, an internal ALB with Lambda targets is usually far cheaper than any per-request API pricing, because ALB charges by hours and capacity units; moving from a REST API to an HTTP API reduces the cost but keeps it per request.

TCP or TLS listener on an NLB

An NLB listener decides where TLS ends. A TLS listener terminates TLS at the NLB: it holds a certificate from AWS Certificate Manager, applies a security policy and sends traffic to targets decrypted (or re-encrypted). A TCP listener on the same port passes the encrypted byte stream through untouched, so TLS terminates at the targets, which hold the certificates. Choose TCP passthrough when encryption must be end to end, when the targets authenticate clients with mutual TLS (device certificates, for example), or when the application protocol inside TLS, such as MQTT, is handled entirely by the targets; choose a TLS listener to offload certificate management and decryption from the targets. Either way the NLB never needs to understand the protocol inside the connection.

Client IP preservation on an NLB

For instance targets, client IP preservation is on by default. For IP targets with TCP or TLS it is off by default and is turned on with the target group attribute preserve_client_ip.enabled=true (then the targets' security groups must allow the clients' addresses). Proxy protocol v2 is the alternative only when the application can parse its header. An ALB passes the client address in X-Forwarded-For instead.

AWS Load Balancer Controller on EKS

• An Ingress becomes an ALB; a Service of type LoadBalancer with aws-load-balancer-type: external becomes an NLB. The controller creates load balancers as internal unless the scheme annotation says internet-facing.
• Target type: instance registers worker nodes on a NodePort; ip registers pod IPs directly. Pods on Fargate can only be IP targets, so an Ingress for Fargate pods needs alb.ingress.kubernetes.io/target-type: ip and an NLB Service needs aws-load-balancer-nlb-target-type: ip.
• IngressGroups: Ingresses that share the same alb.ingress.kubernetes.io/group.name are merged into one ALB, while each team still owns its Ingress object. group.order sets precedence (lower values are evaluated first), so a catch-all / Ingress gets the highest order. The load-balancer-name annotation only names an ALB; it does not merge Ingresses.
• TargetGroupBinding attaches a Service to a load balancer created outside Kubernetes.

Use CloudFront Functions for lightweight, high-volume logic on viewer events (URL rewrites, redirects, header and cookie manipulation, cache-key normalization, simple token checks) and Lambda@Edge when the logic needs network calls, the request body, more time or memory, or origin events.

Where the trigger sits matters as much as which service. Viewer request functions run on every request, before the cache is checked; origin request functions run only on cache misses. So logic that must apply to cached objects too (authorization, a redirect for every visitor) belongs on viewer request, and a check that needs an outbound call to a third-party API, such as introspecting an opaque token, has to be Lambda@Edge on viewer request.

Keep cache keys narrow

Every header, cookie or query string in the cache policy becomes part of the cache key and fragments the cache. Include only what changes the response: for an A/B test, only the variant cookie, never all cookies. Values that the origin or a function needs but that do not change the cached object belong in an origin request policy. Headers that CloudFront generates, such as the viewer-country header, must be added to a cache or origin request policy before an origin-facing function or the origin receives them.