3.1.2.4. Container Platforms for Scalability

3.1.2.4. Container Platforms for Scalability

Containers provide consistent packaging and fast startup — critical for scaling workloads quickly in response to demand.

ECS vs. EKS selection:

ECS scaling: Application Auto Scaling adjusts the desired count of ECS tasks based on CloudWatch metrics (CPU, memory, ALBRequestCountPerTarget). With Fargate, no instance scaling needed — just task scaling. On the EC2 launch type, an ECS capacity provider with managed scaling grows the cluster's Auto Scaling group when tasks can't be placed — for example, the extra tasks a rolling update runs when maximumPercent is above 100. For tasks that need minutes to warm up, keep a baseline MinCapacity and enable ALB slow start on the target group so each new target's share of requests ramps up over the slow-start window (30–900 seconds) instead of arriving all at once.

EKS scaling:

• Horizontal Pod Autoscaler (HPA): Scales pod replicas based on metrics
• Cluster Autoscaler: Adds/removes EC2 nodes when pods can't be scheduled
• Karpenter: AWS-native node provisioning — faster and more efficient than Cluster Autoscaler

# ECS Service Auto Scaling
ScalableTarget:
  Type: AWS::ApplicationAutoScaling::ScalableTarget
  Properties:
    ServiceNamespace: ecs
    ScalableDimension: ecs:service:DesiredCount
    MinCapacity: 2
    MaxCapacity: 50
ScalingPolicy:
  Type: AWS::ApplicationAutoScaling::ScalingPolicy
  Properties:
    PolicyType: TargetTrackingScaling
    TargetTrackingScalingPolicyConfiguration:
      TargetValue: 75
      PredefinedMetricSpecification:
        PredefinedMetricType: ECSServiceAverageCPUUtilization

Exam Trap: ECS tasks on Fargate have fixed CPU/memory combinations (e.g., 0.5 vCPU / 1 GB, 1 vCPU / 2-8 GB). You can't specify arbitrary values. If a question specifies a memory requirement that doesn't match a Fargate combination, the answer might involve EC2 launch type instead.