Skip to content

SYSTEM Cited by 1 source

AWS Auto Scaling Groups

AWS Auto Scaling Groups (ASGs) are the AWS-native primitive for maintaining a pool of EC2 instances launched from a single launch template or configuration. ASGs provide:

  • A desired / min / max count maintained by the service.
  • Health checks + instance replacement.
  • Integration with load balancers.
  • Scaling policies (target-tracking, step, scheduled).
  • Multi-AZ distribution subject to the template's permitted subnets and instance types.

Role on Kubernetes

Historically the Kubernetes Cluster Autoscaler scales EKS node groups by growing / shrinking their underlying ASGs. This indirection is the proximate cause of the scale issues Karpenter was built to fix:

  • One ASG per homogeneous template — diverse workload shapes produce a proliferation of ASGs. Salesforce had thousands of node groups / 1,180+ node pools pre-migration (Source: sources/2026-01-12-aws-salesforce-karpenter-migration-1000-eks-clusters).
  • Minutes-scale latency for scale-out on spikes.
  • Poor AZ balance when workloads require memory-intensive instance types that ASG's template doesn't diversify over.
  • "ASG thrashing" — rapid scale-out-then-scale-in cycles during transient spikes.

Contrast with Karpenter

Karpenter bypasses ASGs entirely: instead of asking an ASG to grow, it calls EC2 RunInstances directly against the list of instance types in its EC2NodeClass, picking whichever type best packs the pending pods. The ASG primitive is still valuable for non-K8s workloads; it's just structurally wrong for per-pod-driven cluster autoscaling at extreme scale.

Seen in

Last updated · 200 distilled / 1,178 read