Compute Services

The compute spectrum: EC2, containers, serverless

AWS compute services form a management ladder: each rung hands more operational work to AWS and gives up more low-level control. The Cloud Practitioner skill is placing EC2, containers, and serverless on that ladder and matching a workload to the rung that meets it with the least management.

One term the page leans on: serverless means AWS provisions, patches, and scales the underlying servers for you. No instances to manage, and you pay only for what you use. The servers still exist; you never operate them.

Amazon EC2 (virtual servers), top rung. Amazon EC2^[1] provides resizable virtual machines: you own the guest OS, patching, scaling, and capacity, so EC2 offers the most control.

Containers (Amazon ECS and Amazon EKS), middle rung. A container packages an application with its dependencies so it runs the same way everywhere. Amazon Elastic Container Service (ECS)^[2] is AWS's own orchestrator and Amazon Elastic Kubernetes Service (EKS)^[3] is managed Kubernetes; images live in Amazon Elastic Container Registry (ECR)^[4].

Serverless (AWS Lambda and AWS Fargate), bottom rungs. AWS Lambda^[5] runs your function code in response to events with no servers to provision, billed only while it runs. AWS Fargate^[6] is a serverless compute engine that runs your ECS or EKS containers without you provisioning EC2 hosts. Fargate is not itself a container, it is where containers run. And serverless is not automatically cheapest: Lambda wins for spiky or idle workloads, but a steady, always-busy workload can cost more than a right-sized EC2 instance. The ladder trades management for control, not always a lower bill.

The compute management ladder: EC2 (you manage OS, scaling, capacity) → containers → Fargate → Lambda (AWS manages all below your code). Climbing down trades low-level control for less ops work.

EC2 instance-type families: match the bottleneck

When EC2 is the right rung, the next choice is the instance-type family, and this section matches one to a workload. AWS groups instances into instance-type families^[7] tuned to different resource profiles. The Cloud Practitioner exam asks which family fits a described workload, not how to size or benchmark one.

General purpose: a balanced mix of compute, memory, and networking. A sensible default for web servers, small databases, and development environments when no single resource dominates.
Compute optimized: a high ratio of CPU to memory. Best for compute-bound work such as batch processing, high-performance computing (HPC), media transcoding, and modeling.
Memory optimized: large amounts of RAM per instance. Best for in-memory caches, large in-memory databases, and real-time big-data analytics.
Storage optimized: high local-disk throughput and IOPS. Best for large transactional databases, data warehousing, and workloads that read and write a lot to local storage.
Accelerated computing: hardware accelerators such as GPUs. Best for machine-learning training and inference, graphics rendering, and scientific simulation.

The exam pattern is straightforward: the stem names a bottleneck ("CPU-bound batch job," "large in-memory dataset," "GPU-based ML training") and the correct answer is the family whose profile matches that bottleneck. Choosing the wrong family means paying for capacity you never use.

Elasticity: Auto Scaling and Elastic Load Balancing

This section covers how an EC2 workload's capacity tracks demand instead of being fixed for peak (the job of two services the exam frequently pairs) and then rounds up the remaining in-scope compute services.

Amazon EC2 Auto Scaling. Amazon EC2 Auto Scaling^[8] automatically adds instances when demand rises and removes them when demand falls, keeping the fleet at the size the workload actually needs. This both protects availability during spikes and saves money during quiet periods. It is the practical, exam-level definition of cloud elasticity.

Elastic Load Balancing (ELB). Elastic Load Balancing^[9] distributes incoming application traffic across multiple targets (EC2 instances or containers) and across multiple Availability Zones. It performs health checks and routes traffic away from unhealthy targets, so a single failed instance does not take the application down.

Used together, an Auto Scaling group keeps the right number of healthy instances running while a load balancer spreads traffic across them: the canonical AWS answer to "how do I make this application both highly available and cost-efficient under changing load." Keep the roles distinct: Auto Scaling changes the instance count; ELB only distributes traffic and never adds capacity itself. The figure below traces it: traffic reaches Elastic Load Balancing, which spreads it across healthy EC2 instances in multiple Availability Zones, while Amazon EC2 Auto Scaling adjusts that instance count.

Other in-scope compute services. A few more services round out the topic:

AWS Batch^[10] runs large numbers of batch computing jobs and provisions the compute for you, the answer when the scenario is "run many batch jobs" rather than a single server.
AWS Elastic Beanstalk^[11] deploys and manages a web application from your uploaded code, handling the EC2 instances, load balancing, and scaling for you while you retain access to the underlying resources.
Amazon Lightsail^[12] bundles a virtual server, storage, and networking at a simple, predictable monthly price, the easiest path for a small website, blog, or simple app.
AWS Outposts^[13] brings AWS compute and services into your own data center for workloads that must stay on-premises for latency or data-residency reasons.

The Auto Scaling + ELB pattern: ELB health-checks and spreads traffic across EC2 instances in multiple Availability Zones; Auto Scaling adjusts the count.

Exam patterns: which compute service when

Cloud Practitioner compute questions almost always describe a business need and ask you to pick the service that fits with the least unnecessary effort, so this section maps each cue phrase to its service. Recognizing the cue words is most of the work.

"Run code without managing servers" / "pay only when it runs" / "event-driven." The answer is AWS Lambda^[5]. Watch the duration cue: a single Lambda invocation can run for at most 15 minutes^[14], so a job that runs longer is a distractor. Push it to EC2, Fargate, or AWS Batch.

"Run containers but don't manage the servers." The answer is AWS Fargate^[6] (with ECS or EKS). If the stem instead stresses "we already use Kubernetes," the orchestration answer is Amazon EKS^[3]; if it just says "run containers on AWS," Amazon ECS^[2] fits. Container images live in Amazon ECR^[4].

"Full control of the OS" / "specific operating system or licensed software" / "lift-and-shift a legacy app." The answer is Amazon EC2^[1]. EC2 is also right whenever the question emphasizes flexibility or long-running, stateful processes.

"Automatically adjust capacity to demand." The answer is Amazon EC2 Auto Scaling^[8], usually fronted by Elastic Load Balancing^[9] for high availability.

"Simplest, fixed monthly price for a small website." The answer is Amazon Lightsail^[12], not raw EC2.

"Just upload my code and let AWS handle the infrastructure." The answer is AWS Elastic Beanstalk^[11].

"Run a large fleet of batch jobs." The answer is AWS Batch^[10].

"Must run in our own data center." The answer is AWS Outposts^[13]. Distractors typically offer a more-managed service that ignores a stated constraint (a longer-than-15-minute job pointed at Lambda, raw EC2 where Lightsail's simplicity was requested, or a Region-based service where on-premises was required).

EC2 vs containers vs serverless: who manages what

Concern	Amazon EC2	Containers (ECS/EKS on EC2)	Serverless (Lambda / Fargate)
You manage	OS, patching, scaling, capacity	EC2 hosts + container orchestration config	Nothing below your code/container
Unit of deployment	Virtual machine (instance)	Container image (from Amazon ECR)	Function code (Lambda) or task (Fargate)
Scaling	EC2 Auto Scaling groups	Service auto scaling of tasks/pods	Automatic per request / per event
Billing basis	Per running instance (by the second)	Per running EC2 host capacity	Per request/duration (Lambda) or per task (Fargate)
Best for	Full control, legacy or licensed apps	Portable microservices at scale	Event-driven, spiky, or low-ops workloads

Decision tree

Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

EC2 gives the most control and the most management

Amazon EC2 provides resizable virtual servers where you own the OS and stay responsible for patching, scaling, and capacity, so it trades maximum control for maximum operational work. Pick it for legacy or licensed apps, a specific operating system, or long-running stateful workloads that need low-level access.

Trap Reaching for EC2 when the scenario's real goal is to minimize operational overhead. That points at a managed or serverless service instead.

2 questions test this

Lambda runs code with no servers to manage

AWS Lambda runs event-driven code in response to triggers like S3 uploads, API calls, and schedules, with no servers to provision and billing only while your code executes. It is the answer whenever a scenario says "run code without managing servers" and scales automatically with the request rate.

Trap Choosing Amazon EC2 for a short event-driven task whose requirement is explicitly "no servers to manage."

5 questions test this

Lambda caps a single invocation at 15 minutes

AWS Lambda caps one invocation at 15 minutes, so anything longer-running belongs on Amazon EC2, AWS Fargate, or AWS Batch. The 15-minute ceiling is the single most-tested Lambda limit, so match the workload's runtime against it before answering.

Trap Pointing a job that needs more than 15 minutes at Lambda. It will time out, not stretch.

1 question tests this

A company is migrating a legacy application that runs continuously and requires 2 hours to complete batch processing jobs. The operations…

Fargate runs containers without managing servers

AWS Fargate is a serverless, pay-as-you-go compute engine that runs Amazon ECS or Amazon EKS tasks without you provisioning, patching, or scaling EC2 hosts. Pick it for "run containers but don't manage the underlying servers," paying only for the resources each task uses.

Trap Selecting the EC2 launch type for containers when the scenario explicitly says the team should not manage the underlying instances.

8 questions test this

ECS is AWS-native orchestration; EKS is managed Kubernetes

Amazon ECS is AWS's own container orchestrator, while Amazon EKS is managed, conformant Kubernetes for teams already standardized on Kubernetes tooling. Choose EKS when the scenario stresses existing Kubernetes skills or portability; choose ECS for a generic "run containers on AWS" with less Kubernetes overhead.

Trap Picking Amazon EKS when no Kubernetes requirement exists. It adds Kubernetes complexity that plain Amazon ECS avoids.

13 questions test this

ECR stores and versions container images

Amazon Elastic Container Registry (ECR) is a managed registry that stores, versions, and shares the container images that Amazon ECS, Amazon EKS, and AWS Lambda pull at deploy time. It supports private repositories with IAM-based access control.

Trap Confusing Amazon ECR, which stores the container images, with Amazon ECS, which runs them: the registry holds images while the orchestrator schedules the running containers.

Auto Scaling is elasticity made automatic

Amazon EC2 Auto Scaling launches instances when demand rises and terminates them when it falls, keeping capacity matched to load between a minimum, desired, and maximum size. This automatic add-and-remove behavior is the exam-level definition of cloud elasticity.

Trap Equating elasticity with high availability. Spreading across Availability Zones is the HA mechanism, while elasticity is scaling capacity to demand.

4 questions test this

ELB spreads traffic across healthy targets

Elastic Load Balancing (ELB) automatically distributes incoming traffic across multiple targets in one or more Availability Zones, runs health checks, and routes only to healthy targets so one failed instance doesn't take the app down. It also scales its own capacity as traffic changes.

Trap Confusing Elastic Load Balancing with Amazon Route 53 for spreading traffic: ELB balances requests across targets within and across Availability Zones, while Route 53 does routing at the DNS level.

3 questions test this

Auto Scaling plus ELB is the HA pattern

Pairing Amazon EC2 Auto Scaling with Elastic Load Balancing keeps the right number of healthy instances running and spreads traffic across them and across Availability Zones: the canonical AWS pattern for high availability and cost-efficiency under changing load. Auto Scaling adjusts the count; ELB distributes the traffic.

Trap Assuming a load balancer alone adds capacity. ELB only distributes traffic; Amazon EC2 Auto Scaling is what changes the instance count.

2 questions test this

Match the EC2 family to the workload's bottleneck

Amazon EC2 instance families target resource profiles: general purpose (balanced), compute optimized (CPU-bound batch and HPC), memory optimized (large in-memory data), storage optimized (high local-disk IOPS), and accelerated computing (GPUs for ML and graphics). The exam describes a bottleneck and asks which family fits it.

6 questions test this

Compute optimized fits CPU-bound work

Compute-optimized Amazon EC2 instances offer a high CPU-to-memory ratio for compute-bound workloads such as batch processing, high-performance computing, media transcoding, high-performance web servers, and machine-learning inference. Reach for this family when raw processing power, not RAM, is the constraint.

Trap Choosing compute optimized for a large in-memory dataset. That RAM-bound profile wants the memory-optimized family instead.

2 questions test this

Memory optimized fits large in-memory data

Memory-optimized Amazon EC2 instances provide a large amount of RAM per instance for workloads that process big data sets in memory, such as in-memory and high-performance databases, in-memory caches, and real-time big-data analytics. Reach for this family when memory, not CPU, is the constraint.

Trap Picking memory optimized for a CPU-bound batch or HPC job. That compute-bound profile wants compute optimized instead.

1 question tests this

A company operates an in-memory database and in-memory analytics workload that must process very large data sets entirely in memory. Which…

Accelerated computing means GPU-backed instances

Accelerated-computing Amazon EC2 instances add hardware accelerators such as GPUs to handle floating-point math, graphics processing, and pattern matching far faster than CPUs alone, fitting machine-learning training and inference, graphics rendering, and scientific simulation. The hardware accelerator is the distinguishing feature.

Trap Provisioning GPU-backed accelerated instances for a general-purpose web or CPU workload. You pay for accelerators the app never uses.

Lightsail is the simple, fixed-price server

Amazon Lightsail bundles a virtual server, storage, and networking into a plan at a low, predictable monthly price: the simplest choice for a small website, blog, or simple app versus assembling raw Amazon EC2 and VPC pieces yourself.

Trap Reaching for Amazon Lightsail when the workload needs fine-grained Amazon EC2 instance choice, advanced networking, or large-scale auto scaling.

Elastic Beanstalk runs your uploaded code for you

AWS Elastic Beanstalk takes uploaded application code and automatically provisions the EC2 instances, load balancing, auto scaling, and health monitoring to run it, while you keep full access to and control of the underlying AWS resources. It is the PaaS-style "just deploy my app" answer.

Trap Assuming Elastic Beanstalk hides or locks the underlying resources. You retain full access to the EC2 instances and other AWS resources it creates.

1 question tests this

A developer with limited infrastructure experience wants the simplest way to deploy a web application and have AWS automatically provision…

AWS Batch runs many batch jobs and provisions the compute

AWS Batch runs large numbers of batch computing jobs and automatically provisions the right quantity and type of compute (across Amazon EC2, Spot, and AWS Fargate) based on the jobs submitted. It is the answer for "run many batch jobs at scale" rather than standing up servers yourself.

Trap Standing up a single Amazon EC2 server to grind through a large batch-job fleet instead of letting AWS Batch provision and scale the compute.

Less management means less low-level control

Moving from Amazon EC2 toward containers and then serverless (AWS Fargate, AWS Lambda) hands more of the stack to AWS and cuts operational overhead, but gives up low-level runtime control. The exam frames this as "reduce operational overhead" versus "need full control over the environment."

Trap Choosing Amazon EC2 to "reduce operational overhead". It maximizes control but also maximizes the management you own.

2 questions test this

The compute spectrum: EC2, containers, serverless

EC2 instance-type families: match the bottleneck

Elasticity: Auto Scaling and Elastic Load Balancing

Exam patterns: which compute service when

EC2 vs containers vs serverless: who manages what

Decision tree

Cheat sheet

Also tested in

References