Skip to main content
In this lesson we’ll cover resiliency patterns and operational considerations for Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). Topics include ECS launch types, task and service placement, CI/CD deployment flows, deployment circuit breakers, and EKS cluster autoscaling options (Cluster Autoscaler and Karpenter). We start with ECS and then move on to EKS.

​
Amazon ECS: Launch Types, Tasks, Services, and Resiliency

ECS supports two primary compute launch types:
Fargate is serverless (you don’t manage hosts) and is great for simplifying resiliency. Use EC2 when you need more control, custom driver/kernel features, or specialized instance types.
A presentation slide titled "ECS – Launch Type" showing two rounded buttons labeled "Unmanaged instances" (blue) and "Managed instances" (orange), with bullet notes about EKS/ECS autopilot and Google and Microsoft logos plus an "Autocopilot" button. The slide is credited to KodeKloud.
With the EC2 launch type you can run unmanaged instances or use managed options such as ECS Capacity Providers for finer control over scaling and instance lifecycle. Fargate removes host operations, enabling faster deployments and AWS-managed isolation, but imposes constraints on host-level configuration and privileged operations.

​
Task Definitions and Services

A task definition is the reusable blueprint that defines how a task (one or more containers) runs:
  • container images and startup commands
  • CPU and memory allocations (task-level or container-level)
  • port mappings, network mode
  • environment variables and secrets
  • IAM task role and execution role
  • volumes and logging configuration
  • compatibility: EC2, Fargate, or both
A service references a task definition and manages the desired count, deployment strategy, and the scheduler behavior that keeps tasks running (e.g., replacing failed tasks automatically).
A diagram titled "ECS – Task Definition" showing a task definition icon feeding into Amazon ECS, which hosts Service A and Service B running containerized tasks inside an ECS with Fargate environment.
Running multiple services on a cluster lets you isolate application boundaries, scale independently, and reduce operational overhead. Many resiliency knobs—placement, scaling policies, and deployment strategies—are configured at the task definition or service level.

​
Integration with Load Balancing, Auto Scaling, and Monitoring

ECS integrates with common AWS resiliency primitives:
  • Elastic Load Balancers (ALB/NLB) for traffic distribution and health checks
  • Auto Scaling Groups (ASG) for EC2 capacity scaling (EC2 launch type)
  • Amazon CloudWatch for metrics, logs, and alarms to drive scaling or alerting
A diagram of an AWS ECS setup showing a user hitting an ELB that routes traffic to an ECS cluster of containers, with an Auto Scaling Group connected to CloudWatch for scaling/monitoring. All components are shown inside a VPC.

​
ECS Placement Strategies (EC2 launch type)

Placement strategies determine how tasks are placed onto EC2 instances. Choose based on availability, utilization, and fault isolation needs: (See ECS task placement: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html)
A diagram titled "ECS Placement Strategies" showing three placement examples—Binpack, Random, and Spread—where a task definition is placed onto EC2 instances with colored container icons. Each example illustrates different ways containers are distributed across EC2 hosts.

​
CI/CD Patterns for ECS

A typical CI/CD flow for ECS includes:
  1. Source control triggers: GitHub, GitLab, AWS CodeCommit
  2. Build: AWS CodeBuild or external runners build artifacts and container images
  3. Registry: Push images to Amazon ECR or third‑party registries
  4. Deployment: Update ECS service to reference a new task definition or image tag using AWS CodeDeploy, CodePipeline, or other CD tools
This pipeline usually includes testing and validation so newly launched tasks are production-ready and resilient by design.
A CI/CD pipeline diagram showing a developer pushing code to AWS CodeCommit, which triggers AWS CodeBuild and then AWS CodeDeploy. The deployment targets Amazon ECS (Fargate) where container tasks for a service are launched.

​
Deployments, Circuit Breakers, and Rollbacks

ECS supports deployment circuit breakers and traffic-shifting deployments (via CodeDeploy). When enabled, ECS monitors health checks and application metrics during a rollout and can:
  • stop the rollout if failures exceed a threshold
  • roll back to the previous stable revision automatically
  • minimize downtime by preventing unhealthy revisions from becoming active
(See deployment circuit breaker docs: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html)
A flow diagram titled "ECS Circuit Breaker Flow Diagram" showing a "Tasks Status" decision branching to "Tasks Healthy" and "Tasks Failing" paths. Each path leads to Amazon ECS boxes with container icons (blue for healthy, orange for failing) and a "Stop rollout / Rollback to previous version" action.

​
Amazon EKS: Kubernetes Resiliency Patterns

Kubernetes primitives and how they relate to resiliency: When using EKS, you can run pods on Fargate (each pod gets a Fargate-managed compute environment) or on EC2 worker nodes (pods share instance capacity).
A diagram of an Amazon EKS cluster architecture showing a VPC spread across three Availability Zones with Network Load Balancers, NAT gateways, subnets, and worker nodes. Each AZ contains subnets with nodes (EC2) running Kubernetes pods and associated networking components.
Think of Kubernetes resiliency as layers from the inside out: container → pod → replica → node → Availability Zone → cluster → region. Successful high-availability designs address failures at every layer.
A diagram titled "Resilience Layers in Kubernetes" showing nested concentric rounded rectangles representing layers from Container at the center through Pod, Replicas, Multi-Node, Multi-AZ, Multi-Cluster up to Multi-Region. An orange container icon marks the innermost element.

​
Availability Zone Considerations

Avoid the anti-pattern of running all pods on a single node or single Availability Zone. If that node or AZ fails, the entire workload may become unavailable. To improve resiliency:
  • Run multiple nodes across multiple AZs.
  • Use scheduling constraints to distribute pods:
    • topologySpreadConstraints
    • node affinity
    • podAntiAffinity
  • Consider separate node groups for different availability or hardware needs.
A diagram titled "Resilience at Availability Zone Level" showing an Amazon EKS cluster split across two Availability Zones with nodes hosting Kubernetes pods. It also includes a deploy icon illustrating deployment/CI within the setup.

​
Multi-cluster and Multi-region Strategies

For control-plane redundancy beyond a single cluster, run multiple clusters and route traffic across them (for example, an ALB/NLB per cluster plus Route 53 or AWS Global Accelerator). This pattern improves resilience against cluster- or region-level failures but increases operational complexity (deployments, state management, cross-cluster networking).
A cloud architecture diagram titled "Resilience at Cluster Level" showing user traffic routed through AWS Route 53 and Global Accelerator to Network Load Balancers that forward requests to multiple Amazon EKS clusters. Each cluster contains an ingress controller and pods to provide resilient, distributed application hosting.
If you require regional or global failover, multi-cluster or multi-region architectures (with Route 53 or Global Accelerator) provide the strongest protection — but they add operational cost and complexity. Choose the approach that matches your business continuity requirements.

​
Cluster Autoscaling: Cluster Autoscaler vs Karpenter

Two prominent autoscaling approaches for EKS:
  • Cluster Autoscaler
    • Watches for unschedulable pods and scales node groups (ASGs) to provide capacity.
    • Works well with managed node groups and existing ASG patterns.
  • Karpenter
    • Open-source autoscaler designed for AWS that provisions right-sized instances rapidly.
    • Selects instance types that best fit pending pods, supports mixed instance types and Spot, and often provides faster provisioning and cost optimization.
A diagram titled "Kubernetes Cluster Autoscaler" showing pods inside a node and a separate pod stuck in a pending state due to insufficient resources. It shows a Cluster Autoscaler triggering AWS Autoscaling to provision a new node.
Karpenter extends the autoscaling model by choosing instance types and sizes that match the resource profile of pending pods and by provisioning capacity quickly to reduce scheduling latency.
A diagram titled "Cluster Autoscaling Using Karpenter" showing pending and unschedulable Kubernetes pods, the scheduler, existing capacity, and a Karpenter component. Arrows illustrate Karpenter provisioning additional node capacity to schedule the pods.
Karpenter and Cluster Autoscaler can be complementary depending on workload patterns: Cluster Autoscaler for stable managed node groups and Karpenter for rapid, flexible right-sizing and mixed-instance optimizations.

​
Summary and Design Guidance

Key resiliency concepts to apply when designing container platforms on AWS:
  • Choose the right compute model:
    • Use Fargate for operational simplicity and managed isolation.
    • Use EC2 when you need host-level control, specialized hardware, or drivers.
  • Define task definitions (ECS) or pod specs (EKS) carefully to include resource requests/limits, health checks, and IAM roles.
  • Use placement strategies or scheduling constraints to prevent single-node or single-AZ failures from taking down workloads.
  • Integrate health checks, ALB/NLB, CloudWatch metrics, and automated scaling to detect and recover from failures quickly.
  • Protect deployments with circuit breakers and automated rollback mechanisms.
  • For cluster-level scaling, evaluate Cluster Autoscaler and Karpenter and pick the tool that matches your provisioning, cost, and speed requirements.
  • Consider multi-cluster or multi-region strategies only when required by your RTO/RPO and business continuity goals.

Watch Video