5. Compute

The compute domain offers various paradigms, from full OS control with Virtual Machines to abstracted Serverless functions.

AWS Batch

Service Introduction: Efficiently runs hundreds of thousands of batch computing jobs by dynamically provisioning the optimal quantity and type of compute.

Common Usage: Paradigm: Managed Batch. Automates the scheduling of containerized workloads for high-volume data processing.

Project Examples:

• Running overnight financial risk simulations on a fleet of Spot Instances.
• Automating large-scale video transcoding jobs for a media library.

Amazon EC2

Service Introduction: Provides secure, resizable virtual machine capacity in the cloud.

Common Usage: Paradigm: Virtual Machines (IaaS). Required for applications needing specific OS configurations or legacy software compatibility.

EBS Snapshot vs. Instance Store vs. Hibernation vs. Auto Scaling (exam-critical — four different problems, easy to conflate): See the dedicated entries below for each. Quick comparison:

Feature	EBS Snapshot	Instance Store	Hibernation	Auto Scaling
Primary Goal	Backup & recovery	High-speed local I/O	Faster app resume	Fleet availability
Persistence	Permanent (in S3)	Ephemeral (lost on stop)	Preserves RAM to EBS	Manages instance lifecycle
Storage Type	Block (network)	Block (local)	Block (EBS root)	N/A (compute)
Key Advantage	Region-resilience	Lowest cost/latency	No data-reload delay	No single point of failure

Exam Example (SAA-C03 pattern): "A data science team uses an EC2 instance to load a massive in-memory dataset, which takes 20 minutes to initialize. They want to stop the instance overnight to save costs but avoid the 20-minute reload time the next morning. Which feature should they use?"

• Correct Answer: EC2 Hibernation — Preserves the in-memory dataset across a stop/start cycle so it doesn't need to reload.
• Why not the others? — An EBS Snapshot backs up the volume but doesn't preserve running RAM state; Instance Store would lose the data entirely on stop; Auto Scaling manages fleet capacity, not a single instance's memory state.

Summary to Remember EC2 Families (exam-critical): The exam expects you to reason about "family fit" rather than memorizing every specific type. Use this summary to categorize them easily:

• R Family (RAM/Memory-Optimized) — Best for huge RAM-to-vCPU ratios and in-memory analytics. Think: "R is for RAM."
• C Family (Compute-Optimized) — Best for CPU-bound tasks like video encoding, high-performance web servers, or batch processing. Think: "C is for Compute (CPU)."
• I Family (Storage-Optimized) — Best for workloads requiring massive local NVMe throughput or high random I/O, such as data warehouses. Think: "I is for I/O (Storage)."
• M Family (General Purpose) — A balanced ratio of compute, memory, and networking. Think: "M is for Middle or Mainstream."
• P/G Families (Accelerated Computing) — Optimized for graphics (GPU) or machine learning. Think: "P is for Pictures."

Pro Tip: If you ever see a question where an application is crashing with "out-of-memory" errors even though CPU usage is low, the architectural fix is often to switch from a C or M family to an R family to get more RAM per dollar.

EC2 Purchasing Options (exam-critical — one of the most frequently tested topics on SAA-C03): The question is almost always "which pricing model fits this workload's interruption-tolerance and predictability?"

• On-Demand — Pay per second/hour, no commitment. Most expensive per-hour rate. Correct answer for short-term, spiky, or unpredictable workloads, or anything you can't risk being interrupted and haven't committed to yet (e.g., testing a new app for the first time).
• Reserved Instances (RIs) — 1 or 3-year commitment for up to ~72% discount vs. On-Demand, in exchange for commitment to instance family/Region. Standard RI — biggest discount, but locked to instance type; can't change family. Convertible RI — smaller discount, but lets you change instance family/OS during the term. Best for steady-state, predictable workloads you know will run for the full term (e.g., a production database running 24/7 for years).
• Savings Plans — Similar discount to RIs (up to ~72%) but commit to a dollar amount per hour rather than a specific instance type — automatically applies to any instance family/size/Region (Compute Savings Plans) or a specific family in a Region (EC2 Instance Savings Plans). More flexible than RIs when the workload's exact instance type may change over the term, while still needing the steep discount of a long-term commitment.
• Spot Instances — Bid on spare AWS capacity for up to ~90% discount, but AWS can reclaim the instance with only a 2-minute warning whenever it needs the capacity back. Correct answer for fault-tolerant, flexible, stateless workloads that can handle interruption: batch jobs, CI/CD build fleets, big-data processing (EMR), or stateless web tiers behind an ASG/ALB. Never the right answer for anything requiring guaranteed availability (e.g., a production database, a workload with a strict deadline).
• Dedicated Hosts — A physical server fully dedicated to you, giving visibility into the underlying sockets/cores — the answer when a question mentions bringing your own per-socket/per-core licenses (e.g., existing Windows Server or SQL Server licenses tied to physical cores) or regulatory/compliance requirements for physical isolation.
• Dedicated Instances — Instances that run on hardware dedicated to your account, but without the visibility/control into sockets and cores that Dedicated Hosts provide. Answers "physically isolated from other customers" without the licensing angle.

Purchasing Option	Discount vs. On-Demand	Commitment	Can Be Interrupted by AWS?	Best For
On-Demand	None (baseline)	None	No	Unpredictable, short-term, spiky workloads
Reserved Instances	Up to ~72%	1 or 3 years	No	Steady-state, known-duration workloads
Savings Plans	Up to ~72%	1 or 3 years ($/hr spend)	No	Steady-state spend, flexible instance type
Spot Instances	Up to ~90%	None (can be reclaimed)	Yes (2-min warning)	Fault-tolerant, flexible, interruptible jobs
Dedicated Hosts	Varies	Optional (1/3-yr for discount)	No	BYOL per-socket/core licensing, compliance

Exam Example (SAA-C03 pattern): "A company runs a nightly batch job that processes large video files for 4 hours. The job can be paused and resumed without data loss, and the company wants to minimize cost. Which EC2 purchasing option is MOST cost-effective?"

• Correct Answer: Spot Instances — The workload is explicitly fault-tolerant/resumable, which is exactly the profile Spot is priced for (up to 90% off), and the 2-minute interruption warning is a non-issue since the job can pause and resume.
• Why not Reserved Instances or Savings Plans? — Both require a 1-3 year commitment; a job running a few hours nightly doesn't need (and shouldn't pay for) continuous long-term capacity.
• Why not On-Demand? — Works, but is the most expensive option for a workload that tolerates interruption — leaves cost savings on the table.

Project Examples:

• Hosting a high-performance web application on a fleet of Linux instances.
• Running a Microsoft SQL Server on Windows with dedicated host requirements.
• Running a fault-tolerant genomics batch-processing pipeline on Spot Instances to cut compute costs by up to 90%.

EBS Snapshot

Service Introduction: An incremental, point-in-time backup of an Amazon EBS volume.

Common Usage: Stored in Amazon S3, making it Region-resilient and able to survive the failure of an entire Availability Zone. Automatically encrypted if the source volume is encrypted. This is a backup/DR tool, not something used for live I/O — restore a snapshot to a new volume in any AZ to recover.

Project Examples:

• Backing up a production database volume nightly for disaster recovery.
• Restoring a volume to a different AZ after an AZ-wide outage.

EC2 Instance Store

Service Introduction: Block storage physically attached to the host computer running an EC2 instance.

Common Usage: Ephemeral — all data is lost on stop or termination — but offers the highest possible IOPS/lowest latency of any EC2 storage option, and is the lowest-cost option since it's bundled into the instance's hourly rate. Cannot be detached and moved to another instance.

Instance Store vs. Provisioned IOPS EBS (io1/io2) — the cost-reasoning gap that trips people up (exam-critical): Both can deliver very high, consistent IOPS — so a question that just says "needs 40,000 IOPS" feels like a Provisioned IOPS (io1/io2) question, because that's the named feature built for guaranteeing an IOPS number. But io1/io2 bills you per provisioned IOPS, per month, on top of the per-GB volume cost — that pricing model exists precisely because EBS is network-attached, durable storage, and guaranteeing a performance number over the network costs AWS (and therefore you) more. Instance store, by contrast, is local NVMe physically bolted to the host — storage-optimized instance families (I3, I4i, etc.) already include very high baseline IOPS (often 100K+) in their hourly compute price, with no separate per-IOPS charge at all.

So the deciding question is never just "how many IOPS do I need" — it's "does this data need to survive a stop/terminate, or is it disposable?":

• Data must persist (survive a stop, be restorable, be shareable across instances) → you have to use EBS, and if it also needs guaranteed high IOPS, that's Provisioned IOPS (io1/io2) — there's no cheaper way to get durable, guaranteed-IOPS storage.
• Data is temporary/disposable (scratch space, cache, intermediate render frames, buffers you discard when done) → Instance Store gets you the same or higher IOPS for free, bundled into an instance you're already paying for — paying extra for io1/io2's durability guarantee is wasted spend on data you're going to throw away anyway.

Exam Example (SAA-C03 pattern, real-world question): "A media company is designing a new application for graphic rendering. The application requires up to 400 GB of storage for temporary data that is discarded after the frames are rendered. The application requires approximately 40,000 random IOPS to perform the rendering. What is the MOST cost-effective storage option?" Answer choices: General Purpose SSD (gp3) EBS / Provisioned IOPS SSD (io1/io2) EBS / EFS / EC2 Instance Store.

• Correct Answer: EC2 Instance Store (on a storage-optimized instance type). The data is explicitly temporary and discarded — the exact profile instance store is built for — and a storage-optimized instance's local NVMe already provides 40,000+ IOPS as part of the hourly compute cost, no extra per-IOPS billing.
• Why not Provisioned IOPS (io1/io2)? — Technically works (it can hit 40,000 IOPS), but you'd be paying a premium for guaranteed durability and network-attached availability that this workload doesn't need at all, since the data is thrown away after rendering — this is the trap: the "correct-sounding" feature-match answer isn't the cost-effective one.
• Why not gp3 or EFS? — Neither reliably sustains 40,000 random IOPS at baseline without significant additional provisioned throughput cost (gp3) or is architected for that IOPS profile at all (EFS is a shared, network file system, not built for single-instance high-random-IOPS scratch workloads).
• Pattern to remember: whenever a question explicitly says data is temporary/discarded/scratch and asks for the MOST cost-effective option (not just "which works"), that combination is a strong signal to check Instance Store before reaching for the EBS tier that matches the IOPS number on paper.

Project Examples:

• Using local NVMe instance store as scratch space for a temporary big-data processing job.
• Running a cache layer where data loss on restart is acceptable.
• Rendering video frames on a storage-optimized instance's local NVMe instance store, discarding the data once each frame is output.

EC2 Hibernation

Service Introduction: A feature that "pauses" an EC2 instance instead of fully stopping it.

Common Usage: The in-memory (RAM) state is saved to the root EBS volume on stop, and restored on start, so the application resumes exactly where it left off instead of re-bootstrapping. Avoids the reload penalty for apps that take a long time to load large in-memory datasets. Only available for instances backed by EBS volumes (not instance store); you pay only for EBS storage + preserved RAM while hibernated, not for compute.

Project Examples:

• Hibernating a data science instance overnight to avoid a 20-minute in-memory dataset reload each morning.
• Pausing a long-running analytics session on a developer's on-demand instance to save compute costs between work sessions.

Spot vs. Hibernation (exam-critical — don't conflate): Spot is a purchasing model for interruptible workloads; Hibernation is a lifecycle feature for preserving state. Spot is interrupted by AWS (2-minute warning) when it needs capacity back and assumes the workload is stateless/resumable from scratch. Hibernation is stopped/started by the user to save cost and assumes the opposite — that reloading state (e.g., a 20-minute in-memory dataset load) is expensive enough to be worth preserving RAM to EBS. Hibernation only works on EBS-backed instances (not Instance Store) and is never a substitute for Spot's ~90% discount — it saves the reload penalty, not the compute rate.

Feature	Spot Instances	EC2 Hibernation
Primary Goal	Massive cost savings on compute	Faster application resume by saving state
Interruption	Interrupted by AWS based on capacity	Paused/resumed by the user to save costs
Data Persistence	Stateless; data on local storage is lost	Stateful; preserves RAM state to EBS
Constraint	Not for production databases or deadlines	Only for EBS-backed instances (no Instance Store)

Amazon EC2 Auto Scaling

Service Introduction: Maintains application availability by automatically adding or removing EC2 instances based on defined health checks and metrics.

Common Usage: Paradigm: Automated Scaling. Ensures systems are resilient and cost-optimized by matching capacity to demand.

Scaling Policy Types (exam-critical — pick based on what triggers the scaling decision):

• Target Tracking — You set a target metric value (e.g., "keep average CPU at 50%"), and Auto Scaling automatically creates and manages the CloudWatch alarms and math to hit it. The simplest and most commonly correct answer when a question just wants a metric held near a target, with no other special conditions.
• Step Scaling — You define scaling steps based on the size of the alarm breach (e.g., CPU 50-70% → add 1 instance; CPU >70% → add 3 instances). Use when the response should scale more aggressively the further a metric drifts from the threshold — target tracking can't do this proportional response.
• Simple Scaling — Legacy; one scaling action per alarm, then a mandatory cooldown before the next action can trigger. Rarely the best-practice answer in current exam versions — target tracking or step scaling supersede it.
• Scheduled Scaling — Scale based on a known, predictable time (e.g., add capacity every weekday at 8 AM before a traffic wave hits, then scale in at 6 PM). Correct answer whenever a question describes a predictable, calendar-based pattern rather than reacting to live metrics.
• Predictive Scaling — Uses ML to forecast traffic and pre-provisions capacity ahead of anticipated spikes (e.g., recurring daily/weekly patterns), combining the responsiveness of dynamic scaling with the lead time of scheduled scaling.

Other Exam-Critical Details:

• Health Check Grace Period — The time Auto Scaling waits after an instance launches before it starts performing health checks on it, preventing a slow-booting instance from being killed and replaced in an infinite loop before it's finished initializing.
• Cooldown Period — After a scaling activity, Auto Scaling pauses further scaling actions for this duration to let the new capacity register its metrics, preventing over-correction from launching/terminating too many instances in a short window.
• Lifecycle Hooks — Let you pause an instance in a Pending or Terminating state to run custom actions (e.g., pull final logs before termination, run bootstrap scripts before it enters service) before Auto Scaling proceeds.
• Warm Pools — A pool of pre-initialized instances kept in a stopped/running state outside the ASG, ready to be moved in when scaling out — cuts the time-to-serve-traffic for workloads with slow boot/initialization, without paying full On-Demand compute rates for idle capacity.

Project Examples:

• Implementing a self-healing web fleet that replaces failed instances automatically.
• Scaling a processing fleet up to 100 instances during a Black Friday sale using target tracking on CPU utilization.
• Pre-scaling a fleet every weekday morning ahead of a predictable 9 AM traffic surge using scheduled scaling.

AWS Elastic Beanstalk

Service Introduction: An easy-to-use PaaS for deploying and scaling web applications developed with Java, .NET, PHP, Node.js, Python, Ruby, and Go.

Common Usage: Paradigm: Platform-as-a-Service (PaaS). Developers upload code, and Beanstalk handles deployment, load balancing, and scaling.

Project Examples:

• Rapidly deploying a Python Flask API with automated health monitoring.
• Managing a multi-environment (Dev/Test/Prod) deployment for a Java application.

AWS Outposts

Service Introduction: A fully managed service that extends AWS infrastructure and services to virtually any on-premises or co-location facility.

Common Usage: Paradigm: Hybrid Cloud. Used for workloads with strict low-latency or local data processing requirements.

Project Examples:

• Running low-latency manufacturing execution systems on a factory floor.
• Processing high-frequency healthcare data locally for data residency compliance.

AWS Serverless Application Repository

Service Introduction: A managed repository for discovering, deploying, and publishing serverless applications and components.

Common Usage: Paradigm: Serverless Template Sharing. Accelerates development by utilizing pre-built, community-verified architectural patterns.

Project Examples:

• Deploying a standardized image-resizing microservice to an AWS account.
• Publishing a custom internal data-cleansing function for use by other teams.

VMware Cloud on AWS

Service Introduction: An integrated cloud offering that allows you to run VMware vSphere-based workloads on the AWS global infrastructure.

Common Usage: Paradigm: Hybrid/Migration. Facilitates "lift-and-shift" migrations of VMware environments without re-platforming.

Project Examples:

• Extending an on-premises data center into AWS for disaster recovery.
• Migrating a legacy VMware cluster to AWS to retire aging on-site hardware.

AWS Wavelength

Service Introduction: Infrastructure optimized for mobile edge computing, embedding AWS compute and storage within 5G networks.

Common Usage: Paradigm: Edge Computing. Minimizes latency for mobile users by placing compute at the carrier's network edge.

Project Examples:

• Deploying ultra-low latency augmented reality (AR) services for 5G devices.
• Managing real-time vehicle-to-infrastructure communication for autonomous fleets.