100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
AWS

EC2 Fundamentals

Learn what Amazon EC2 is, how virtual server instances work in the cloud, and how to launch, connect to, and manage them safely.

ComputeBeginner9 min readJul 10, 2026
Analogies

What Is Amazon EC2?

Amazon Elastic Compute Cloud (EC2) lets you rent virtual servers, called instances, by the second instead of buying physical hardware. Each instance is launched from an Amazon Machine Image (AMI) — a template containing an operating system and pre-installed software — and runs on AWS's shared physical infrastructure while appearing to you as an isolated machine with its own CPU, memory, storage, and network interface. Because instances can be created and destroyed through an API call, EC2 turns compute capacity into an elastic resource you scale up or down as demand changes, rather than a fixed asset you plan around for years.

🏏

Cricket analogy: Renting an EC2 instance is like a franchise signing an overseas player for just one IPL season instead of drafting them for a ten-year contract — you get MS Dhoni-level firepower exactly when you need it and release the roster slot once the tournament ends.

AMIs, Key Pairs, and Launching an Instance

Launching an instance requires four key decisions: which AMI to boot from, which instance type sizes the CPU and memory, which key pair provides SSH access, and which security group acts as a virtual firewall controlling inbound and outbound traffic. AWS publishes AMIs for common operating systems like Amazon Linux 2023 and Ubuntu, and you can also create your own custom AMI from a configured instance to standardize deployments. The key pair's private half never leaves your machine — AWS only stores the public half on the instance — so losing the private key means losing password-based recovery options unless you use tools like EC2 Instance Connect or Systems Manager Session Manager.

🏏

Cricket analogy: Choosing an AMI is like picking a pre-set fielding template — say, an aggressive powerplay field with two slips — before the match starts, so the team takes the field already configured for the situation instead of arranging positions from scratch.

bash
# Launch a t3.micro instance from an Amazon Linux 2023 AMI
aws ec2 run-instances \
  --image-id ami-0c101f26f147fa7fd \
  --instance-type t3.micro \
  --key-name my-ec2-keypair \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --count 1 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-server-01}]'

# Connect once running
ssh -i my-ec2-keypair.pem ec2-user@<public-ip-address>

Connecting to and Inspecting a Running Instance

Once an instance is running, you typically connect over SSH on port 22 for Linux or RDP on port 3389 for Windows, both governed by the attached security group rules. Every instance can also query the Instance Metadata Service (IMDS) at the well-known address 169.254.169.254 from inside the guest OS to retrieve its own instance ID, region, IAM role credentials, and user-data script — information the operating system uses for self-configuration without needing hardcoded values. Storage is typically provided by Elastic Block Store (EBS) volumes that persist independently of the instance's compute lifecycle, attaching much like a virtual hard drive that can be detached and reattached elsewhere.

🏏

Cricket analogy: Querying instance metadata is like a batter checking the scoreboard and required run rate mid-innings — the instance looks up its own context, such as region and role, to decide how to play the situation without needing someone to shout instructions from the boundary.

Always use Instance Metadata Service Version 2 (IMDSv2), which requires a session token obtained via a PUT request before any metadata GET call. IMDSv1's simple GET-based access is a known SSRF (server-side request forgery) risk, and AWS now lets you enforce IMDSv2-only mode per instance.

Instance Lifecycle: Stop, Start, and Terminate

EC2 instances move through distinct states — pending, running, stopping, stopped, shutting-down, and terminated — and understanding the difference between stopping and terminating is essential for both cost control and data safety. Stopping an EBS-backed instance halts compute billing while preserving the root volume, so you can start it again later with the same data intact, though the public IP address usually changes unless an Elastic IP is attached. Terminating an instance is permanent: by default the root EBS volume is deleted along with it unless you explicitly set DeleteOnTermination to false, and any data on an instance store (ephemeral) volume is lost the moment the underlying host reassigns that physical disk space.

🏏

Cricket analogy: Stopping an instance is like a team going into a rain delay — play pauses, the scoreboard and team sheet are preserved exactly as they were, and the match resumes later from that same state rather than restarting from ball one.

Instance store volumes are physically attached to the host and are ephemeral: data is lost on stop, terminate, or underlying hardware failure — never store anything you can't afford to lose on instance store without a replication or backup strategy. EBS-backed root volumes survive a stop/start cycle but are still deleted on termination unless DeleteOnTermination is explicitly disabled.

  • EC2 instances are virtual servers billed by the second, launched from AMI templates and defined by an instance type, key pair, and security group.
  • Custom AMIs let you snapshot a configured instance so future launches start from a standardized, ready-to-run image.
  • Security groups act as stateful virtual firewalls controlling which ports and sources can reach an instance.
  • The Instance Metadata Service lets an instance query its own identity and temporary IAM credentials; always require IMDSv2 for security.
  • Stopping an EBS-backed instance halts billing while preserving the root volume; terminating deletes the instance and, by default, its root volume.
  • Instance store (ephemeral) volumes lose all data on stop or terminate, unlike EBS volumes which persist independently of instance lifecycle.
  • Elastic IPs prevent the public IP address from changing across stop/start cycles, which matters for DNS-dependent workloads.

Practice what you learned

Was this page helpful?

Topics covered

#AWS#AWSFundamentalsStudyNotes#CloudComputing#EC2Fundamentals#EC2#Fundamentals#Amazon#AMIs#StudyNotes#SkillVeris