Skip to main content
Students, welcome back. In this lesson we compare the main AWS compute platforms from a performance perspective so you can choose the right option for your workload. The selection is often binary and driven by workload characteristics such as CPU, memory, network, disk I/O, and latency requirements. Primary platforms to consider:
  • Amazon EC2 (virtual machines)
  • Amazon ECS (container orchestration)
  • AWS EKS (Kubernetes-based container orchestration)
  • AWS Lambda (serverless)
Each platform trades off control, operational overhead, and raw performance. Below we examine those trade-offs and provide guidance for typical scenarios.
A presentation slide titled "Compute Platform Selection – Introduction" showing four orange AWS icons labeled Amazon EC2, Amazon ECS, AWS EKS, and AWS Lambda. The icons are evenly spaced across the slide with a copyright note for KodeKloud.
CPU (compute) considerations CPU is like engine horsepower: EC2 (and EC2-backed ECS/EKS) provides the broadest range of CPU capacity and instance types, including high-CPU families and multi-socket instances for sustained, heavy compute. Key points:
  • Burstable T-series (T2/T3/T3a/T4g) use a CPU credit model — monitor CPUCreditBalance and CPUCreditUsage in CloudWatch. Other families (M, C, R, etc.) are not credit-based and are better for sustained CPU.
  • Containers running on EC2 inherit the instance’s CPU characteristics (including credit behavior on T-series). If you use Fargate or Lambda, those serverless options have fixed vCPU profiles and different limits.
  • For sustained high CPU, choose EC2-backed deployments (EC2, ECS/EKS on EC2). For small, bursty compute and reduced ops, Fargate or Lambda may be acceptable.
Burstable instances (T-series) are cost-effective for variable CPU workloads but will throttle when CPU credits are exhausted. Do not use them for sustained high-CPU tasks.
A grid of numbered cards showing colorful circular icons and labels for system metrics (CPU Utilization, CPU Credit Balance/Usage, CPU Surplus Credit, Disk Read/Write Ops, Network in/out, and Network Packets in/out). The image includes a small "© Copyright KodeKloud" notice in the bottom-left.
Memory utilization Memory is the application’s cargo space. Serverless memory limits and container task memory settings are typically lower than what you can provision on a large EC2 instance. Important memory constraints:
  • AWS Lambda currently supports up to 10 GB of memory per function.
  • Fargate tasks and other serverless container options impose task-level memory limits that may not match large EC2 instance memory sizes.
  • For sustained workloads needing more than serverless memory limits, choose EC2 or ECS/EKS on EC2 so you can select instances with adequate RAM.
Also note: T-series instances are tuned for CPU-burstable workloads and are not ideal for sustained high CPU or very large memory requirements.
A presentation slide titled "Memory Utilization" showing an app icon with colorful memory chips above it and two horizontal memory-usage bars below (one mostly full, one mostly empty). The image illustrates differing memory usage levels for an application.
Latency (response time) Latency is the elapsed time between a request and the corresponding response. Platform choice affects both baseline and tail latency. Considerations:
  • EC2 provides the most predictable, low-latency behavior since you provision capacity directly.
  • Fargate can be low latency when containers are warm; cold starts are possible but generally smaller than Lambda cold starts.
  • Lambda has cold-start latency risk. Mitigate with provisioned concurrency or by keeping functions warm if latency is critical.
  • For consistent low-latency under heavy load, EC2-backed deployments are usually the safest option.
The image is a diagram titled "Latency" showing AWS Lambda and Amazon EC2 icons above a timeline from "Request" to "Completion." It illustrates latency as the time between a request and its completion, with the caption "How quickly your system responds to requests."
Network I/O (throughput) Network performance matters for high-throughput services, real-time streaming, or heavy egress. Guidance:
  • EC2 instances can be sized for network capacity (for example, instances that advertise “High”, “10 Gbps”, or more). Use instances with enhanced networking (ENA) for lower latency and higher throughput.
  • For long-lived, high-throughput connections and heavy egress/ingress, EC2 is generally preferred.
  • Serverless options (Lambda, Fargate) work well for bursty or lower-throughput networking patterns but may not match the sustained network throughput of large EC2 instances.
A simple diagram titled "Network I/O" showing data flowing from an Input marker on the left to an Output marker on the right via a network represented by a row of purple dots. The input and output are shown as colored map-pin icons with hand/arrow and thumbs-up symbols.
Disk I/O (storage throughput and IOPS) Disk I/O is critical for databases, log ingestion, and heavy read/write workloads. EC2 storage options include:
  • EBS volumes (gp3, io2, io2 Block Express) with provisioned IOPS and high throughput.
  • Instance store local NVMe on certain instance families for extremely low-latency, high-throughput ephemeral storage.
Notes:
  • Lambda can access Amazon EFS for shared file storage, but this adds latency and cost, and Lambda has a maximum execution time of 15 minutes.
  • For sustained high IOPS and throughput, EC2 (or ECS/EKS backed by EC2) typically offers better performance-per-dollar.
A slide titled "Disk I/O" showing hard drive icons with colored "Read" and "Write" labels. It recommends Amazon EC2 (IOPS SSD or EBS‑optimized) for heavy disk usage and standard SSDs or lower‑cost options for less frequent use.
Platform comparison snapshot Recommended reading: Summary and recommendations
  • Choose EC2 or ECS/EKS with EC2 launch type when you need:
    • Sustained high CPU
    • Large memory beyond serverless limits
    • Sustained high network throughput
    • Heavy disk I/O with provisioned IOPS or local NVMe
  • Choose Fargate or Lambda when you prioritize operational simplicity and your workload fits within serverless resource limits (bursty or lower steady-state usage).
  • For latency-sensitive services with strict response-time SLAs, prefer EC2 or carefully provisioned Fargate/EKS tasks; for Lambda, mitigate cold starts with provisioned concurrency or keep warmers.
  • If your application requires more than Lambda’s memory limit (10 GB) or sustained heavy I/O, use EC2-based deployments.
These distinctions appear on exams and in architecture decisions. For performance-driven requirements (high CPU, memory, disk, or sustained network), default to EC2 or container orchestration backed by EC2. When operational simplicity and pay-per-use are more important and resource needs fit serverless limits, consider Fargate or Lambda.

Watch Video