EC2 Autoscaling Under Bursty Traffic: An Evaluation of Tail Latency and Scaling Responsiveness : EC2 Autoscaling Under Bursty Traffic: A Tail Latency focused Comparison with AWS Lambda

Sammanfattning

Cloud-based services must remain responsive under bursty and unpredictable traffic patterns, yet the relationship between autoscaling configuration choices and tail latency behaviour under such conditions remains insufficiently understood. This thesis evaluates how different Amazon EC2 autoscaling configurations influence system performance under bursty high-load traffic, with a focus on tail latency at the 95th and 99th percentiles (p95 and p99), time-to-stability (TTS), and service level objective (SLO) compliance. The experiments were conducted on real AWS infrastructure using a controlled experimental design. Four configuration parameters were varied relative to a fixed baseline: scaling policy type, scaling policy aggressiveness, minimum instance capacity, and instance size. Three traffic patterns representing steep bursts, gradual ramps, and repeated bursts were evaluated across all configurations. AWS Lambda was included as a serverless reference architecture under identical workload conditions. The central finding is that reactive autoscaling on EC2 is primarily constrained by instance provisioning delay rather than detection latency. This delay, averaging 5 to 6.5 minutes across configurations, accounts for 60 to 65 percent of total scaling delay and cannot be eliminated through policy tuning alone. Minimum capacity proved to be the most effective configuration parameter in the evaluated setup: pre-provisioning five instances eliminated SLO violations entirely across all evaluated traffic patterns. AWS Lambda achieved the same result, with cold starts affecting only around 0.013% of requests and remaining within SLO headroom. The results provide empirical guidance for practitioners designing latency-sensitive systems under bursty workloads, highlighting that burst resilience depends more on pre-provisioned capacity than on scaling policy aggressiveness, and that the choice between EC2 and Lambda reflects a trade-off between configuration control and operational simplicity.