AWS EC2 Basics: Your First Virtual Server
A beginner-friendly tour of Amazon EC2 — instance types, AMIs, key pairs, security groups, launching via the console, SSH access, the free tier, and the difference between stopping and terminating an instance.
What you'll learn
- ✓What an EC2 instance actually is and how to launch one in the console
- ✓How AMIs, instance types, and key pairs fit together
- ✓Security groups — the firewall every EC2 instance lives behind
- ✓How to SSH into your instance and prove it is yours
- ✓The t2.micro/t3.micro free tier — what is free and what is not
- ✓The crucial difference between stopping and terminating an instance
Prerequisites
- •An AWS account — see What Is AWS? for the basics
- •A terminal with an SSH client (built into macOS, Linux, and modern Windows)
EC2 — Elastic Compute Cloud — is AWS’s flagship service. It rents you virtual servers by the second. Most of the rest of AWS exists to make EC2 either easier to use or unnecessary, but every cloud engineer eventually needs to launch one. This post walks through the moving parts and gets you SSHed into a real instance.
What an EC2 instance is
An EC2 instance is a virtual machine running on AWS’s infrastructure. From inside, it looks and feels like a normal Linux box: you SSH in, you install packages, you run servers. From outside, AWS gives you the knobs to choose how much CPU and RAM it has, which Linux (or Windows) image it boots, which network it lives on, and who can reach it.
Conceptually you are picking values along five axes:
- Region and Availability Zone — where the physical machine lives
- AMI (Amazon Machine Image) — what disk image it boots from
- Instance type — how much CPU, RAM, and network it has
- Key pair — the SSH key you will use to log in
- Security group — the firewall in front of it
Click through the launch wizard once and these five appear in order.
AMIs: the disk image
An AMI is a snapshot of a root disk plus a tiny bit of metadata. When you launch an instance, AWS copies that snapshot onto a new virtual disk and boots from it.
Useful AMIs to know:
- Amazon Linux 2023 — AWS’s own distro, tuned for EC2. A reasonable default.
- Ubuntu 22.04 / 24.04 LTS — what most documentation on the internet assumes.
- Debian, Red Hat, SUSE — all officially supported by their vendors.
- Windows Server — if you need it (and you do not need it for a learning instance).
You can also create your own AMI from a running instance. That is how teams ship “golden images” preloaded with their app, security agents, and config.
Instance types: t3.micro and friends
An instance type names a family and a size. t3.micro means the t3 family at the micro size. Family letters hint at the workload:
- t — burstable, general-purpose. CPU credits accumulate when idle, get spent when busy. Great for low-utilization workloads.
- m — general-purpose, balanced CPU and memory.
- c — compute-optimized. Cheaper per CPU.
- r — memory-optimized. Cheaper per GB of RAM.
- g, p — GPU. For ML training and inference.
Sizes scale roughly linearly: large has twice the vCPU of medium, xlarge twice that again, and so on. Prices scale the same way. For a learning instance, t3.micro (2 vCPU, 1 GB RAM) is more than enough.
The free tier
For the first 12 months of a new AWS account, EC2 gives you 750 hours per month of t2.micro or t3.micro (depending on region). 750 hours is enough to run one instance non-stop the entire month with hours to spare.
What is free:
- Compute hours, up to 750/month
- 30 GB of EBS general-purpose storage
- 15 GB of data transfer out
What is not free:
- A second running instance (the hours apply to one at a time)
- Larger instance types (
t3.small,m5.large, etc.) — full price from minute one - Elastic IPs attached to a stopped instance — small but real charge
- Data transfer above the cap
The classic surprise bill comes from launching a few m5.large instances “just to try”, forgetting to terminate them, and getting charged for a week before you notice. Set a billing alarm at $5 on day one.
Key pairs
EC2 does not let you set a password on a Linux AMI. You authenticate with a key pair: a private key that lives on your laptop and a public key AWS injects into ~/.ssh/authorized_keys on the instance at first boot.
Create one in the console (EC2 → Key Pairs → Create key pair) or with the CLI:
aws ec2 create-key-pair \
--key-name my-laptop \
--query 'KeyMaterial' \
--output text > my-laptop.pem
chmod 400 my-laptop.pem
The .pem file is downloaded once, at creation. If you lose it, AWS cannot recover it — you replace the key by attaching the instance’s disk to another instance and editing authorized_keys. Save it somewhere safe.
Security groups: the firewall
A security group is a stateful firewall attached to your instance. It has two rule sets:
- Inbound — which IPs and ports can reach the instance
- Outbound — what the instance is allowed to talk to (default: anything)
For a web server you might allow:
- SSH (port 22) from your IP only
- HTTP (port 80) from anywhere
- HTTPS (port 443) from anywhere
A common beginner mistake is opening SSH to 0.0.0.0/0 (“from anywhere”). For a learning instance that is fine; for anything real, restrict it to your IP and use AWS Systems Manager Session Manager if you need broader access.
# Find your public IP for the SSH rule
curl ifconfig.me
# 203.0.113.45
Security groups are stateful: if you allow an inbound HTTP request, the response is allowed automatically. You do not need a matching outbound rule.
Launching an instance via the console
The end-to-end click path:
- EC2 console → Launch instance.
- Name the instance (e.g.,
learn-ec2). - Pick an AMI — Amazon Linux 2023 or Ubuntu 24.04 LTS.
- Pick t3.micro (look for the “Free tier eligible” badge).
- Pick or create a key pair. Download the
.pemif it is new. - Under Network settings, create a new security group:
- Allow SSH from “My IP”
- Optionally allow HTTP from “Anywhere”
- Leave storage at the default 8 GB gp3.
- Launch instance.
After 30–60 seconds, the instance is in running state with a public IPv4 address.
SSHing in
With the key file and the public IP, you can connect.
ssh -i my-laptop.pem ec2-user@203.0.113.42
# The authenticity of host ... can't be established.
# Are you sure you want to continue connecting (yes/no)?
yes
# Welcome to Amazon Linux 2023
# [ec2-user@ip-172-31-1-23 ~]$
The default username depends on the AMI: ec2-user for Amazon Linux, ubuntu for Ubuntu, admin for Debian, centos for CentOS. SSH errors usually trace to one of three things:
- Wrong username
- Security group not allowing your IP
- Key file permissions too loose (
chmod 400 my-laptop.pemfixes it)
Once you are in, you have a full Linux server. Install packages, run a web server, host a script. It is yours.
Try it yourself. Launch a t3.micro. SSH in. Install nginx (sudo dnf install nginx -y or sudo apt install nginx -y), start it (sudo systemctl start nginx), then visit http://<public-ip> in your browser. If you allowed HTTP in the security group, you see the nginx welcome page. If not, you get a timeout — go back to the security group and add the rule.
Public IPs and Elastic IPs
The public IPv4 address attached to a running instance is not stable. Stop and start the instance and it changes. For anything where DNS matters, you have three options:
- An Elastic IP — a reserved public IP you attach to your instance. Free while attached to a running instance, charged a small amount per hour when not.
- A load balancer in front of the instance with its own stable DNS name.
- A DNS record you update on each restart (cheap and cheerful for learning).
For now, just bookmark the public IP and know it will change after a stop.
Stop vs terminate
This trips up almost every beginner. The two actions look similar in the menu but mean very different things.
Stop. The instance shuts down. AWS releases the CPU and memory, you stop paying for compute, but the EBS root disk persists. You can start the instance again later and pick up where you left off — files, installed packages, the lot. You still pay for the EBS storage (typically pennies a month for the default 8 GB).
Terminate. The instance is destroyed. By default, the EBS root disk is destroyed too. There is no undo. The next time you launch, you start from a fresh AMI.
The rule of thumb: stop when you are done for the day and might come back tomorrow. Terminate when you are sure you are done and never want to see it again.
# Stop (keeps disk, can restart later)
aws ec2 stop-instances --instance-ids i-0abc1234def567890
# Terminate (deletes the instance)
aws ec2 terminate-instances --instance-ids i-0abc1234def567890
You can also enable termination protection in the console — a checkbox that prevents accidental termination until you explicitly turn it off. Worth flipping on for anything you care about.
Try it yourself. From the running instance, write hello world to ~/notes.txt. Stop the instance from the console. Wait a minute, then start it again. SSH in (note the IP may have changed) and confirm ~/notes.txt is still there. Now terminate the instance and confirm AWS removes it from your list. Practice the distinction once and you will not forget it.
Costs to watch
EC2 itself is the obvious line item, but a few sneaky charges trip people up:
- EBS volumes keep accruing charges after the instance is stopped.
- Elastic IPs charge if they are not attached to a running instance.
- Snapshots of EBS volumes are persisted to S3 and billed by GB.
- Data transfer out to the internet is per GB after the free tier.
The fix for all of this is a billing alarm in CloudWatch. Set one for $5 the day you open the account. You will get an email long before anything serious happens.
Where EC2 fits in the bigger picture
EC2 is the rawest compute in AWS. It is the right tool when you want full control of the operating system: custom kernels, specific package versions, anything that does not fit into a managed runtime.
For most modern workloads, AWS offers higher-level options that ride on top of EC2 invisibly:
- ECS / EKS / App Runner for containers
- Lambda for short-lived functions — see AWS Lambda Basics
- Elastic Beanstalk for “give me a URL for this code”
Knowing EC2 well makes those higher-level services easier to understand, because they are all built on the same primitives.
Recap
You now know:
- An EC2 instance is a virtual server you rent by the second
- An AMI is the disk image; an instance type is the CPU/RAM size; a key pair is the SSH credential
- Security groups are stateful firewalls and SSH from
0.0.0.0/0is fine to learn but bad in production - The free tier covers 750 hours/month of
t2.microort3.microfor the first year - Stop keeps the disk and lets you resume; terminate destroys the instance
- Set a billing alarm on day one and you will not get surprises
Once a first instance works end-to-end — SSH in, run a web server, see it from your browser — the rest of AWS starts making much more sense.
Next steps
If managing servers sounds like more work than your project deserves, the natural next read is the Lambda post — the serverless alternative for short-lived work.
Useful adjacent reading:
- AWS Lambda Basics — for functions instead of servers
- AWS S3 Basics — for storing the files your instance produces
- What Is AWS? — for the broader service landscape
Questions or feedback? Email codeloomdevv@gmail.com.