EC2 Fundamentals
Amazon's core virtual server service — AMIs, instance types, and the purchase options that trade commitment for discount.
Want a visual for this topic?
Generate a diagram tailored to EC2 Fundamentals — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Launch an EC2 instance from the Console and connect to it
- •Explain what an AMI is and the difference between EBS-backed and instance-store-backed AMIs
- •Read an EC2 instance type name (e.g. m5.xlarge) and explain what each part means
- •Choose between On-Demand, Reserved, Spot, and Savings Plans for a given workload
What is it?
Amazon EC2 (Elastic Compute Cloud) is AWS's core virtual server service — it lets you rent virtual machines ('instances') of a chosen size and operating system, billed by the second, that you can launch, use, and terminate on demand. It's the most direct IaaS building block on AWS: you get root/administrator access to a virtual machine, and you're responsible for everything above the hypervisor layer — OS patching, software installation, application configuration.
Why it exists
Before EC2 (launched in 2006), running a server meant buying or leasing physical hardware with a multi-week to multi-month procurement cycle, and you had to guess your capacity needs months in advance. EC2 exists to collapse that procurement cycle down to seconds — you can launch a server that matches your exact CPU/RAM/storage needs, use it for an hour or a year, and terminate it the moment you're done, paying only for the time it actually ran.
Problem it solves
It solves the capacity-guessing problem (launch more instances in minutes if you underestimated, terminate instances immediately if you overestimated), the procurement-lead-time problem (seconds instead of weeks), and the idle-hardware-cost problem (a physical server you bought sits there costing money even at 2am with zero traffic; an EC2 instance you've terminated costs nothing).
Intuition
Renting a car versus owning one, applied to servers: you specify exactly what you need right now (a compact car for a quick errand, a van for moving furniture — a small instance for a dev environment, a large instance for a database), use it for exactly as long as you need, and return it (terminate it) the moment you're done, with none of the ownership burden of maintenance, insurance, or a fixed monthly payment regardless of use.
Analogy
A hardware rental shop where you can walk in, rent a specific power tool (choose an instance type matched to your job), use it for an hour or a month, and return it — versus buying every tool you might ever conceivably need and storing them in a garage (owning physical servers) whether you use them or not.
Technical explanation
An EC2 instance type name like m5.xlarge encodes: 'm' = the instance family (general purpose; other families include 'c' for compute-optimized, 'r' for memory-optimized, 'g'/'p' for GPU), '5' = the generation (newer generations are typically more efficient/cheaper per unit of performance), and 'xlarge' = the size within that family (nano/micro/small/medium/large/xlarge/2xlarge... — each step roughly doubles vCPU and RAM). Modern EC2 instances run on AWS's custom Nitro hypervisor, which offloads networking and storage virtualization to dedicated hardware, giving near-bare-metal performance despite being a virtualized instance.
Architecture
A typical EC2 deployment: an AMI (either an AWS-provided base OS image or a custom 'golden image' you've built with your application pre-installed) is used to launch one or more instances into a specific VPC subnet, each instance gets an attached EBS root volume (and optionally additional EBS volumes for data), a Security Group controls inbound/outbound traffic, and an IAM Role (not embedded credentials) is attached so the instance can call other AWS services. For anything beyond a single dev instance, instances are typically launched via an Auto Scaling Group rather than individually, so unhealthy instances are automatically replaced.
Workflow
- Choose or build an AMI. 2) Choose an instance type sized to your actual workload (start smaller and measure — right-sizing after the fact based on real CloudWatch metrics is standard practice, not a one-time guess). 3) Choose a purchase option (On-Demand for unpredictable/short-term, Reserved/Savings Plans for known steady-state, Spot for interruption-tolerant workloads). 4) Configure networking (VPC/subnet/Security Group) and attach an IAM Role. 5) Launch, connect (SSH key pair for Linux, RDP with a decrypted password for Windows), and configure the instance, or better, use EC2 User Data (a boot-time script) to automate that configuration instead of doing it manually so it's reproducible.
Example
A team running a stateless API service launches m5.large On-Demand instances behind a load balancer for their staging environment (unpredictable, low-traffic usage pattern where Reserved pricing wouldn't pay off), while their production environment runs the same instance type on a 1-year Savings Plan (steady, predictable baseline traffic where the ~30-40% discount is guaranteed savings), and a nightly batch-processing job that reprocesses analytics data runs on Spot Instances (interruption-tolerant, can simply retry if reclaimed, saving 60-90% versus On-Demand for a workload that doesn't need guaranteed availability).
Real-world usage
EC2 remains one of AWS's highest-revenue services and underlies a huge share of internet infrastructure — companies from small startups to Netflix (which runs the majority of its non-CDN infrastructure on EC2) use it as the base compute layer, often now increasingly alongside container orchestration (ECS/EKS) and serverless (Lambda) for specific workload types rather than EC2 for absolutely everything.
Trade-offs
EC2 sits between the extremes of full control (rent a bare-metal-like machine, manage everything above the hypervisor) and full abstraction (Lambda, where you never think about servers at all). Choosing EC2 over Lambda/containers is a deliberate tradeoff: more operational responsibility (patching, scaling configuration, health management) in exchange for more control over the runtime environment, ability to run any software regardless of execution-time limits, and often lower cost for genuinely constant, high-utilization workloads where Lambda's per-invocation pricing would be more expensive than a steadily-running instance.
Visual explanation
Picture a form with dropdowns: 'Choose an AMI' (the OS + pre-installed software template your instance boots from — Amazon Linux, Ubuntu, Windows Server, or a custom image you built) → 'Choose an Instance Type' (the hardware shape: how much CPU, RAM, network, and sometimes GPU) → 'Choose Storage' (an EBS volume, AWS's network-attached block storage, sized and typed separately from the instance) → 'Choose Networking' (which VPC/subnet, and a Security Group controlling what traffic is allowed) → Launch. Within seconds to a couple of minutes, that combination becomes a running virtual machine you can SSH or RDP into.
Advantages
- —
Full control over the operating system and installed software — anything that runs on Linux/Windows can run on EC2
- —
Wide range of instance types optimized for compute, memory, storage, GPU, or balanced general-purpose workloads
- —
Flexible purchasing options let you trade commitment for significant discounts on predictable workloads
- —
Mature ecosystem — virtually every deployment tool, monitoring agent, and configuration management system supports EC2 natively
Disadvantages
- —
You're responsible for OS patching, security updates, and runtime management — more operational burden than PaaS/serverless options
- —
Under-utilized instances (over-provisioned 'just in case') quietly waste money since you're billed for the instance running regardless of actual CPU usage
- —
Individual instance failures require either manual intervention or an Auto Scaling Group to auto-replace them — EC2 alone doesn't self-heal
- —
Boot/warm-up time (a minute or more) makes EC2 less suited than Lambda for workloads needing instant, bursty scale-to-zero-and-back
Common mistakes
- —
Over-provisioning instance size 'to be safe' without ever measuring actual CPU/memory utilization via CloudWatch, wasting money on unused capacity
- —
Manually configuring instances by hand (SSH in, install things) instead of using User Data or a golden AMI, making the setup non-reproducible and error-prone when you need to launch a second instance
- —
Choosing On-Demand pricing for a genuinely steady-state, predictable workload that would qualify for 30-70% savings under a Reserved Instance or Savings Plan
- —
Leaving unused/stopped instances' attached EBS volumes around — a stopped instance doesn't bill for compute, but its attached EBS storage keeps billing until you delete it
In the AWS Console
- 1
AWS Console → EC2 → Instances → Launch instances
Name your instance, choose an AMI (e.g. 'Amazon Linux 2023' from the Quick Start list), and choose an instance type (e.g. t3.micro, which is Free Tier eligible for testing).
t2.micro/t3.micro are the classic Free Tier instance types for learning — always check current Free Tier eligibility before launching anything larger.
- 2
Launch instances → Key pair (login)
Create a new key pair (or select an existing one) and download the .pem private key file — this is required to SSH into a Linux instance.
AWS never lets you download this file again after creation — losing it means losing SSH access to any instance launched with that key pair, though you can still access via EC2 Instance Connect or by attaching a new key via user data on reboot.
- 3
Launch instances → Network settings
Choose or create a Security Group; for a Linux instance you'll typically want to allow inbound SSH (port 22) only from your own IP, not 0.0.0.0/0.
Allowing SSH from anywhere (0.0.0.0/0) is one of the most common EC2 security misconfigurations — restrict to your IP or a bastion host.
- 4
Launch instances → Advanced details → User data
Optionally paste a shell script here to run automatically on first boot (e.g. installing a web server) instead of configuring the instance by hand after launch.
This is what makes instance configuration reproducible — critical once you're launching more than one instance or using Auto Scaling.
- 5
EC2 → Instances → select your instance → Connect
Use 'EC2 Instance Connect' for a browser-based SSH session (no key file needed if enabled), or copy the SSH command shown to connect from your local terminal using the downloaded .pem file.
Remember to chmod 400 the .pem file locally — SSH refuses to use a key file with overly permissive file permissions.
🎤 Interview questions
What is an AMI, and what's the difference between an AWS-provided AMI and a custom AMI? (Listen for: AMI = the template an instance boots from, including OS and pre-installed software; custom AMIs let you bake your own application/config into a reusable 'golden image.')
Walk through what each part of an instance type name like c5.2xlarge means. (Listen for: 'c' = compute-optimized family, '5' = generation, '2xlarge' = size tier within that family.)
When would you choose Spot Instances over On-Demand? (Listen for: interruption-tolerant, stateless, fault-tolerant workloads like batch processing — not for anything that can't handle being reclaimed with short notice.)
Why is using EC2 User Data better than manually configuring an instance after launch? (Listen for: reproducibility — the same script can launch identically-configured instances automatically, critical for Auto Scaling and disaster recovery.)
A stopped EC2 instance — are you still being billed for anything? (Listen for: no compute billing while stopped, but attached EBS volumes and any Elastic IP not attached to a running instance continue to incur charges.)
📂 Subtopics
AMIs and Storage: EBS-Backed vs Instance Store
What an AMI actually contains, and the difference between network-attached EBS storage and physically-local instance store.
~12 min
Purchase Options: On-Demand, Reserved, Spot, Savings Plans
Four ways to pay for the same EC2 capacity, trading commitment and interruption risk for discount.
~14 min