AWS Compute

AWS EMR (Elastic MapReduce)computeAWS EMR (Elastic MapReduce) is a managed big data platform that runs distributed processing frameworks —… Amazon EC2computeAmazon EC2 provides resizable virtual machines (instances) in the AWS cloud. Auto Scaling EC2 EMRcomputeAuto Scaling for Amazon EC2 and EMR (Elastic MapReduce) is a service that automatically adjusts the number of… ECS, EKS, and FargatecomputeAWS offers two container orchestrators (ECS and EKS) and two compute modes (EC2 launch type and Fargate).

Where the work actually runs: instances, clusters, containers, and the scaling behaviour that decides what they cost.

‹ AWS

1. How the compute options relate

AWS Compute Spectrum: Control vs Management EC2 you manage OS EMR managed Hadoop/Spark ECS / EKS on EC2 you manage nodes Fargate no nodes Lambda functions Left: more control over instance type, OS, networking and cost tuning. Right: less to operate, billing closer to actual usage, tighter limits on runtime and hardware. Auto Scaling applies across the spectrum: EC2 groups, EMR managed scaling, ECS/EKS services.

Every AWS compute service ultimately runs on EC2 capacity; the services differ in how much of the stack AWS manages for you. With plain EC2 you choose the instance family, the AMI and the operating system, and you are responsible for patching, scaling and placement. EMR packages EC2 instances into a managed cluster with Spark, Hive, Trino and other big-data frameworks preinstalled and configured. ECS and EKS schedule containers; they can place tasks on EC2 instances you own, or on Fargate, where AWS provisions right-sized capacity per task and you never see the underlying hosts. Lambda, covered under Serverless, sits at the far end with per-invocation billing.

Auto Scaling is the cross-cutting concern: it decides how many instances, nodes or tasks run at any moment, and therefore most of the bill. Target-tracking policies on a metric such as CPU or queue depth are usually the right starting point, with scheduled scaling layered on for predictable daily peaks.

2. When to use which

WorkloadGood fitWhy
Long-running service needing specific OS, GPU or licensingEC2Full control of the instance
Batch Spark / Hive jobs over S3 dataEMRManaged cluster, Spot task nodes, transient clusters
Containerised microservices, AWS-native teamECS (EC2 or Fargate)Simpler control plane, deep IAM integration
Containers with Kubernetes tooling or portability needsEKSStandard Kubernetes API and ecosystem
Spiky container workloads, no node managementFargatePer-task capacity and billing
Variable traffic on any of the aboveAuto ScalingMatch capacity to demand

Cost and operational effort pull in opposite directions. EC2 with Reserved Instances or Savings Plans is usually cheapest per unit of compute at steady load, but carries the most operational work. Fargate and Lambda cost more per vCPU-hour yet remove idle capacity and host maintenance. Spot capacity can cut costs substantially for interruptible work such as EMR task nodes and stateless containers.

See AWS Serverless for Lambda and Step Functions, Networking for VPC placement, and Monitoring for the metrics that drive scaling decisions.