# AWS Core Compute Services

> Chapter 3 of the Courseiva AWS-CLOUD-PRACTITIONER curriculum — https://courseiva.com/learn/aws-cloud-practitioner/aws-core-services-compute

**Official objective:** 2.2 — Describe AWS compute services

## Introduction

Exam domain 2.2 of the CLF-C02 exam asks you to describe AWS compute services. This concept is the foundation of all cloud computing because it solves the core problem of how to run applications without buying and maintaining physical servers. Understanding it is critical because questions on EC2, its pricing models, and serverless options like Lambda appear on nearly every exam paper.

## The Three-Tier Catering Company Analogy

The Head Chef of a large catering company is the central figure responsible for all the cooking.

The head chef needs to prepare meals for thousands of guests across hundreds of events. Instead of buying one massive, permanent kitchen that sits empty when not in use, they use a flexible system. For a small wedding, they rent a single food truck with a chef. For a massive conference, they hire a fleet of food trucks, each with a specialised chef, and park them all together to form a temporary, giant kitchen. After the event, they return the trucks. This is exactly how AWS Core Compute Services work. The virtual servers (food trucks) are called Amazon EC2 instances. They are rented, not bought. You can scale up to hundreds for a huge event or scale down to zero after. The menu (operating system and software) is pre-configured in an Amazon Machine Image (AMI) – the recipe card. If a food truck breaks down, the head chef simply orders a new one using the same recipe. The head chef never owns a single truck; they just rent them for exactly as long as needed, paying only for the cooking time.

## Core explanation

Compute is the term for the processing power that runs your applications. In the old IT world, if you wanted to run a website, you bought a physical computer, installed an operating system, plugged it in, connected it to the internet, and maintained it 24/7. That physical computer was a server. This approach had huge problems: you paid for the server even when nobody visited your website; if the server broke, the website went offline; and if your website became popular, you had to buy another server, which took days or weeks to arrive.

AWS Core Compute Services replace that physical server with virtual servers. A virtual server is a software-based simulation of a physical computer that runs on powerful hardware owned by AWS. The primary service for this is Amazon Elastic Compute Cloud, or Amazon EC2. 'Elastic' means it can grow and shrink on demand. 'Compute' means processing power. 'Cloud' means it is delivered over the internet.

To launch an EC2 instance (your virtual server), you start with an Amazon Machine Image (AMI). An AMI is a template that contains the operating system (like Windows or Linux), software, and configuration settings. It is like the recipe and the initial setup for your server baked together. You select an AMI, choose your instance type (how much CPU, memory, and storage you need), and launch it. Within minutes, your virtual server is running in an AWS data centre and you can connect to it remotely.

AWS offers different ways to pay for these EC2 instances. This is a critical exam topic. The main pricing models are:

- On-Demand: You pay by the hour or second with no long-term commitment. Best for unpredictable workloads or applications you are testing.
- Reserved Instances: You commit to one or three years and get a significant discount (up to 72% off On-Demand). Best for steady-state, predictable applications like a company's internal database.
- Spot Instances: You bid for unused EC2 capacity and can get up to 90% off On-Demand. The catch is that AWS can reclaim the instance with only two minutes' notice if the capacity is needed elsewhere. Best for fault-tolerant, flexible workloads like big data processing or rendering.
- Savings Plans: A flexible model where you commit to a consistent amount of compute usage (measured in dollars per hour) for one or three years, and you get a discount that applies across EC2, AWS Lambda, and AWS Fargate.

AWS also offers compute services beyond EC2. AWS Lambda is a 'serverless' compute service. 'Serverless' does not mean there are no servers; it means you do not manage or even see the servers. You simply upload your code and define a trigger (like an HTTP request or a file upload). AWS Lambda runs your code only when that trigger happens and automatically scales it to millions of requests. You pay only for the compute time your code consumes – down to the millisecond. This is ideal for short-running tasks like processing a user upload or querying a database.

Another service is AWS Elastic Container Service (ECS) and its Kubernetes-based counterpart Amazon EKS. These are 'container' services. A container is a lightweight, portable package that contains your application code along with all its dependencies (libraries, runtime). Think of a container as a shipping container: you pack your application inside, and it runs the same way on your laptop, in a testing environment, or on AWS. ECS and EKS manage the clusters of EC2 instances that run those containers. AWS Fargate is a 'serverless' compute engine for containers – you run your containers without managing the underlying servers, similar to how Lambda works for code.

Finally, AWS Elastic Beanstalk is a Platform as a Service (PaaS) offering. You upload your code and configuration, and Elastic Beanstalk automatically handles provisioning EC2 instances, load balancing, auto-scaling, and monitoring. It is the 'I just want to deploy my app, I do not want to think about servers' option.

In summary, AWS Core Compute Services give you choices. You can have full control (EC2), automatic scaling and serverless (Lambda, Fargate), container orchestration (ECS, EKS), or a fully managed platform (Elastic Beanstalk). The CLF-C02 exam expects you to know the core differences between these services, the pricing models of EC2, and when to choose each one.

## Real-world context

An IT professional, call her Priya, works for a startup that runs a mobile game. The game's backend needs to handle traffic that spikes dramatically every evening when players log in after work. Priya cannot buy physical servers because she does not know how many players she will have next week.

Priya starts by choosing Amazon EC2. She selects the latest Amazon Linux AMI and chooses a general-purpose instance type (like t3.medium) for the main game logic. She launches six On-Demand instances to handle the current load. Because her workload is predictable (evening peaks), she also purchases one Reserved Instance for the base load that runs 24/7, saving 40% compared to running that instance On-Demand.

For processing player profile pictures that get uploaded sporadically, Priya uses AWS Lambda. She writes a Python function that resizes images and stores them in Amazon S3. She pairs it with Amazon API Gateway, so when a player uploads a photo via the app, an HTTP request triggers the Lambda function. She pays only for the milliseconds the function runs – far cheaper than having an EC2 instance waiting for uploads all day.

For the chat feature, the startup decided to containerise the chat server using Docker. Priya uses Amazon ECS with AWS Fargate. She defines the task (the container configuration) and lets Fargate manage the servers. When chat usage spikes, Fargate automatically adds more containers. When it drops, it removes them. Priya never logs into a server to configure anything.

To handle rapid deployment of new features, Priya uses AWS Elastic Beanstalk. She uploads her Node.js code, and Elastic Beanstalk automatically stands up an environment with a load balancer, auto-scaling group, and EC2 instances. If she needs to test a new version, she creates a separate environment.

The practical tasks Priya performs daily include:

- Monitoring EC2 instance CPU utilisation using Amazon CloudWatch to decide if she should scale up or down.
- Configuring auto-scaling groups to automatically add new EC2 instances when CPU exceeds 70% and remove them when it drops below 30%.
- Updating AMIs every month to include the latest security patches, then using those AMIs for all new instances.
- Testing new instance types (like compute-optimised c5 for the game logic) to see if they reduce cost while maintaining performance.
- Troubleshooting a misconfigured security group that is blocking traffic to the EC2 instances, often by checking the inbound rules.

This scenario shows that an IT professional's day is not about racking servers; it is about selecting the right compute service, configuring it to be resilient and cost-effective, and automating scaling so the application handles millions of users without human intervention.

## Exam focus

The CLF-C02 exam heavily tests your understanding of EC2 pricing models. This is the single most tested concept within 'AWS Core Compute Services'. You will see multiple questions asking you to identify the cheapest pricing model for a given scenario. The trap questions are designed to trick you into choosing On-Demand when Reserved or Spot is correct, or vice versa.

Key exam topics you must memorise:

- On-Demand is for unpredictable workloads, short-term spikes, or applications you are testing for the first time. It is the most flexible but most expensive on a per-hour basis.
- Reserved Instances (standard) require a 1- or 3-year commitment and offer the biggest discount for steady-state workloads (like a database running 24/7). Convertible Reserved Instances let you change instance attributes but offer a smaller discount.
- Spot Instances are for fault-tolerant, flexible, or stateless workloads. The critical trap: a question will say 'urgent batch processing' and 'need to finish in one hour'. If the workload is fault-tolerant and time-insensitive (like rendering frames), Spot is correct. If it is time-critical (like an urgent financial calculation), you might want On-Demand or Reserved.
- Savings Plans are a newer, more flexible alternative to Reserved Instances. They apply to compute usage broadly (EC2, Lambda, Fargate) at a consistent dollar-per-hour commitment.

Another frequent exam topic is the difference between EC2 and Lambda. The trap: a question will ask 'which compute service is best for a long-running application?' Lambda has a 15-minute execution timeout. If the scenario involves a web server running constantly, EC2 is the answer. If it involves processing a file upload that takes seconds, Lambda is the answer.

The exam also tests your understanding of AWS Elastic Beanstalk vs. EC2. The trap: Elastic Beanstalk is a way to deploy and manage applications; it actually uses EC2 instances under the hood. If a question asks for a managed platform that handles provisioning and scaling automatically, the answer is Elastic Beanstalk. But if the question asks for 'full control over the operating system and networking', the answer is raw EC2.

Key definitions to memorise:

- AMI (Amazon Machine Image): a template for an EC2 instance containing the OS and software.
- Instance type: the specification of CPU, memory, and storage for an EC2 instance (e.g., t3.micro, m5.large).
- Auto Scaling: a service that automatically adjusts the number of EC2 instances based on demand.
- Load Balancer: distributes incoming traffic across multiple EC2 instances to ensure no single instance is overwhelmed.
- Fargate: a serverless compute engine for containers.
- Lambda: a serverless compute service for running code in response to events.

Finally, be aware of 'vertical scaling' vs. 'horizontal scaling' questions. Vertical scaling means making an instance more powerful (e.g., from t3.micro to t3.large). Horizontal scaling means adding more instances (e.g., from 2 instances to 10 instances). Elasticity in AWS primarily refers to horizontal scaling. The exam may test this distinction.

## Step by step

1. **Choose an AMI** — You start by selecting an Amazon Machine Image. This is a pre-configured template. For example, you might choose 'Amazon Linux 2' or 'Ubuntu 22.04'. The AMI provides the operating system and sometimes pre-installed software like a web server. For CLF-C02, remember that an AMI is region-specific and you can create custom AMIs from your own instances.
2. **Select an Instance Type** — You choose how much CPU, memory, and network performance your virtual server needs. AWS groups instance types into families: general-purpose (t3, m5), compute-optimised (c5), memory-optimised (r5), storage-optimised (i3), and GPU-optimised (p3). For a basic web server, a general-purpose t3.micro is often enough and is eligible for the AWS Free Tier. The exam tests that you can match a workload to an instance family.
3. **Configure Network and Security** — You specify which Virtual Private Cloud (VPC) subnet the instance will launch in. You also create or select a Security Group, which acts as a virtual firewall. For a web server, you must allow inbound traffic on port 80 (HTTP) and port 443 (HTTPS). You also choose whether to assign a public IP address. Security groups are stateful, meaning if you allow inbound traffic, the outbound return traffic is automatically allowed.
4. **Add Storage** — You attach an Amazon Elastic Block Store (EBS) volume to act as the hard drive for the instance. You can add multiple volumes, set their size (in GB), and choose between solid-state drives (SSD) or hard disk drives (HDD). You also decide if the volume should be deleted when the instance is terminated. For exam study, remember that EBS volumes persist independently of the instance's life cycle unless you enable 'Delete on Termination'.
5. **Launch and Connect** — You launch the instance by clicking the 'Launch' button. AWS provisions the virtual server within seconds to minutes. You then connect to it using a key pair (a private key file) and a tool like SSH (for Linux) or RDP (for Windows). Once connected, you can install software, configure the application, and start serving traffic. This step also includes the option to add tags for cost tracking and management.
6. **Monitor and Scale** — After the instance is running, you monitor its performance using Amazon CloudWatch. If utilisation is high, you can manually change the instance type (vertical scaling) or create an Auto Scaling group to automatically launch more instances (horizontal scaling). Auto Scaling works with a Load Balancer to distribute traffic. For the exam, understand that auto-scaling can be based on schedules, demand (CPU utilisation), or health checks.

## Comparisons

### EC2 (Virtual Servers) vs Lambda (Serverless Functions)

**EC2 (Virtual Servers):**
- Runs continuously 24/7; ideal for always-on applications.
- You manage the OS, patches, and scaling manually or via Auto Scaling.
- Billed per second/hour for the time the instance is running, even if idle.

**Lambda (Serverless Functions):**
- Runs only when an event triggers it; maximum execution time is 15 minutes.
- You never manage the OS or servers; AWS handles scaling automatically.
- Billed per invocation and duration of code execution (rounded to nearest millisecond).

### On-Demand Pricing vs Reserved Instances Pricing

**On-Demand Pricing:**
- No upfront payment and no long-term commitment.
- Highest per-hour cost among the main options.
- Best for unpredictable workloads, testing, or short-term projects.

**Reserved Instances Pricing:**
- Requires a 1-year or 3-year commitment (partial or full upfront).
- Significant discount (up to 72%) compared to On-Demand.
- Best for steady-state, predictable workloads that run continuously.

### EC2 (Full Control) vs Elastic Beanstalk (Managed Platform)

**EC2 (Full Control):**
- Full control over the OS, software, and networking.
- You must manually configure scaling, load balancing, and monitoring.
- Ideal for complex, customised environments or legacy applications.

**Elastic Beanstalk (Managed Platform):**
- AWS automatically provisions EC2 instances, load balancers, and auto-scaling.
- You just upload your code and define configuration settings.
- Best for developers who want to focus on code, not infrastructure.

### EBS (Block Storage) vs Instance Store (Ephemeral Storage)

**EBS (Block Storage):**
- Persistent; data survives instance stop/start and termination (if not deleted).
- Can be detached from one instance and attached to another in the same AZ.
- Billed separately from the EC2 instance.

**Instance Store (Ephemeral Storage):**
- Ephemeral; data is lost when the instance is stopped or terminated.
- Physically attached to the host machine; cannot be detached.
- Included in the instance cost (no separate billing).

## Common misconceptions

- **Misconception:** Setting up an EC2 instance is exactly like setting up your personal laptop with an operating system and apps. **Reality:** While the concept is similar, an EC2 instance is a virtual server running in a data centre. You connect to it remotely, it has no physical screen, and you configure networking (Security Groups, VPC) separately. You cannot just plug in a monitor. (Newcomers assume 'virtual computer' means 'like my laptop'. They miss the additional cloud-specific concepts like virtual private cloud (VPC) subnets and security group rules that control access.)
- **Misconception:** Once you launch an EC2 instance, you cannot change its instance type without losing all your data. **Reality:** You can stop an EC2 instance, change its instance type, and start it again. The data on the Amazon EBS (Elastic Block Store) volume persists. The instance retains its IP addresses (unless elastic IP is involved) and configuration. (Similar to changing a car engine, many assume it is impossible or destructive. The ability to resize is a core feature of virtualisation, but beginners do not understand the separation of compute (instance) and storage (EBS volume).)
- **Misconception:** AWS Lambda is always the cheapest and best compute option for every application. **Reality:** Lambda is best for short-running, event-driven tasks (up to 15 minutes). For long-running processes (like a web server running 24/7), EC2 or containers are more cost-effective. Lambda also has cold start latency and limited customisation of the runtime environment. (Lambda is heavily marketed as cost-effective, so beginners think it is universally superior. They overlook its limitations around execution time, memory (max 10 GB), and lack of persistent local storage.)
- **Misconception:** An AMI is the same thing as a snapshot of a running EC2 instance. **Reality:** An AMI is a template used to launch new instances. A snapshot is a backup of an EBS volume. An AMI can include one or more snapshots, plus metadata (like launch permissions and block device mapping). You can create an AMI from a running instance, but they are distinct concepts. (Both involve 'images' of a server. Beginners conflate them because both are used for creating new instances. The distinction matters for exam questions about backup, recovery, and instance cloning.)

## Key takeaways

- Amazon EC2 gives you virtual servers that you can launch in minutes, paying only for what you use.
- The four main EC2 pricing models are On-Demand, Reserved Instances, Spot Instances, and Savings Plans.
- On-Demand is for unpredictable workloads; Reserved Instances are for steady-state workloads with a 1- or 3-year commitment.
- Spot Instances can save up to 90% but can be reclaimed by AWS with two minutes' notice.
- AWS Lambda runs your code in response to events, scales automatically, and you pay only for the compute time consumed.
- AWS Fargate is a serverless compute engine for containers, so you do not manage the underlying servers.
- An AMI (Amazon Machine Image) is the template that defines the OS and software for an EC2 instance.
- Auto Scaling and Load Balancers work together to make your application highly available and scalable.

## FAQ

**What is the difference between EC2 and Lambda?**

EC2 provides virtual servers that run continuously and give you full control. Lambda runs your code only when triggered, scales automatically, and you pay per invocation and duration. EC2 is for always-on apps; Lambda is for event-driven, short-lived tasks.

**Can I run a free EC2 instance forever?**

No. The AWS Free Tier includes 750 hours per month of a t2.micro or t3.micro instance for 12 months. After 12 months or if you exceed 750 hours, you pay standard On-Demand rates.

**What happens if I stop an EC2 instance?**

When you stop an EC2 instance, it shuts down. You are not charged for the instance itself, but you are still charged for any attached EBS volumes (storage). The instance retains its private IPv4 address and any Elastic IP address, but the public IPv4 address is released. You can start it again later.

**What is a Spot Instance and why would I use it?**

A Spot Instance is EC2 capacity that AWS sells at a steep discount (up to 90%) because it is unused. You place a bid for a price. If the Spot price drops below your bid, you get the instance. If the price rises above your bid, AWS reclaims the instance with a two-minute warning. Use Spot for flexible, fault-tolerant tasks like data processing, rendering, or batch jobs.

**How do I choose between Reserved Instances and Savings Plans?**

Both offer discounts for a 1-year or 3-year commitment. Reserved Instances require you to specify instance family and region, and apply only to EC2. Savings Plans are more flexible: you commit to a dollar amount per hour, and it covers EC2, Lambda, and Fargate usage. Savings Plans are generally better if your usage may vary across instance types or services.

**What is AWS Fargate?**

Fargate is a serverless compute engine for containers. You define your container (Docker image) and its requirements (CPU, memory). Fargate runs the container for you without needing to manage or provision EC2 instances. It is simpler than running ECS on EC2 and is ideal for teams that want to focus on applications, not servers.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/aws-cloud-practitioner/aws-core-services-compute