ADVPERF01-BP02 Use appropriate scaling to handle burst traffic with cost considerations
Consider start-up latency and scaling needs to handle burst traffic for networking, compute, and storage resources.
Implementation guidance
Network Load Balancer (NLB) and Application Load Balancer (ALB) scaling parameters depend upon the following parameters:
-
Overall number of long-lived connections
-
New TCP/TLS connections per second expected
-
Data transfer in GB per second expected
NLB scaling needs are driven by elastic network interface at the Availability Zone level, whereas ALB scales across Availability Zones.
Consider Load balancer Capacity Unit (LCU) reservation, which you can use to proactively set a minimum capacity for your load balancer. This capability complements the load balancer's existing ability to auto scale based on your traffic pattern. Implement load balancers with target groups (like Auto Scaling groups).
For container workloads running on Amazon EKS, implement EKS Auto Scaling:
-
Set up horizontal scaling and node scaling using either Cluster Autoscaler or Karpenter
-
Set up pod scaling using horizontal pod scaling
Integrate with default Kubernetes metrics (like CPU and memory)
or extensive metrics (inputs like queue lengths, CPU usage, and
business metrics) using
Kubernetes Event-driven
Autoscaling (KEDA)
For databases like Amazon Aurora, enable storage auto scaling, which is a managed solution for storage expansion.