Experimental Evaluation of EC2-Based and Serverless Architectures for Bursty Web Application Workloads on AWS: Performance, Scalability, and Cost Trade-offs

Cloud applications can be deployed using continuously provisioned virtual machines or serverless platforms that allocate computing resources on demand. Choosing between these approaches is not straightforward because performance, scalability, reliability, and cost can change depending on workload characteristics. This study experimentally compares a fixed-capacity Amazon EC2 deployment with an AWS serverless architecture using Amazon API Gateway and AWS Lambda. Both implementations executed the same deterministic CPU-bound /compute workload based on 25,000 chained SHA-256 operations. The EC2 environment used a t3.small instance running Ubuntu 24.04 with Flask, Gunicorn, and Nginx, while the serverless environment used AWS Lambda with Python 3.12, x86_64 architecture, and 1024 MB of memory. Six workload profiles were evaluated: low, moderate, high, sudden burst, idle-to-burst, and sustained load. Each workload was executed three times on both architectures, producing 36 accepted formal trials. Because only three repetitions were available for each condition, the analysis focuses on descriptive statistics rather than statistical-significance claims. The results show that neither architecture was consistently superior across all conditions. During the sudden-burst workload, Serverless reduced mean latency by 32.1% and increased achieved throughput by 14.5%, although it also showed a 0.434% mean failure rate and a normalized cost per 1,000 successful requests 9.50 times that of EC2. In the idle-to-burst workload, Serverless reduced mean latency by 41.9% and increased throughput by 30.3%, while its normalized cost moved much closer to EC2 at 1.06 times the EC2 value. Overall, the findings indicate a workload-dependent trade-off: Serverless was often more responsive under burst-oriented traffic, whereas the tested EC2 configuration generally provided stronger request reliability and lower normalized cost. The observed Lambda concurrency ceiling of 10 is treated only as an account-specific experimental constraint and not as a general AWS Lambda scalability limit. Processed experimental data and non-sensitive reproducibility materials are provided with the record as supplementary material.