AWS Builder Center
πŸ“¦ EC2 Explained by Actually Launching One: AMIs, EBS, Security Groups & SSH

πŸ“¦ EC2 Explained by Actually Launching One: AMIs, EBS, Security Groups & SSH

A beginner-friendly guide to Amazon EC2 that explains what happens when you launch a virtual server in AWS, including AMIs, instance types, EBS storage, Security Groups, key pairs, and SSH.

πŸ“¦ EC2 Explained by Actually Launching One

After learning about serverless services such as Lambda and DynamoDB, I wanted to understand the other side of AWS:
What actually happens when I launch my own server in the cloud?
That's where Amazon EC2 comes in.
EC2 stands for Elastic Compute Cloud.
In simple terms, it allows me to run virtual servers in AWS.
The architecture looks something like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
🌍 Internet
β”‚
β–Ό
AWS VPC
β”‚
β–Ό
Public Subnet
β”‚
β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ EC2 β”‚
β”‚ Server β”‚
β””β”€β”€β”€β”¬β”€β”€β”€β”€β”˜
β”‚
β”Œβ”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”
β–Ό β–Ό
EBS Disk Security Group
But launching an EC2 instance involves several decisions.
Let's break them down.

🧠 What Is Amazon EC2?

Amazon EC2 provides resizable compute capacity in AWS.
Instead of buying a physical server, I can create a virtual machine in the cloud.
For example:
1
2
3
4
5
6
7
8
9
10
11
Traditional:

Buy Server
↓
Install OS
↓
Configure Network
↓
Install Software
↓
Run Application
With EC2:
1
2
3
4
5
6
7
8
9
AWS Console
↓
Choose Configuration
↓
Launch Instance
↓
Connect
↓
Run Application
This makes it possible to create compute resources much faster.

πŸ–₯️ Step 1: Choosing an AMI

When launching an EC2 instance, one of the first things I choose is an AMI.
AMI stands for:
Amazon Machine Image
I think of an AMI as a template used to create an EC2 instance.
It can contain things such as:
  • Operating system
  • Software
  • Configuration
  • Required files
For example:
1
2
3
4
5
6
7
8
AMI
β”‚
β”œβ”€β”€ Linux
β”œβ”€β”€ OS configuration
└── Software
β”‚
β–Ό
EC2 Instance
So when I launch an EC2 instance, I'm essentially saying:
"Create a virtual machine using this image."

βš™οΈ Step 2: Choosing an Instance Type

Next comes the instance type.
This determines the compute resources available to my virtual machine.
Depending on the instance family and size, this can include different amounts of:
1
2
3
4
CPU
Memory
Network performance
Storage options
I might see instance types with names such as:
1
2
3
t3.micro
t3.small
t3.medium
The exact choice depends on the workload.
For a simple learning project, I don't need a powerful server.
This taught me an important AWS lesson:
Choose resources based on the workload rather than simply choosing the biggest option.

πŸ” Step 3: Creating a Key Pair

If I want to connect to a Linux EC2 instance using SSH, I need an appropriate authentication method.
One common option is an EC2 key pair.
Conceptually:
1
2
3
4
5
Private Key
β”‚
β”‚ Authentication
β–Ό
EC2 Server
The private key is sensitive.
I should protect it carefully and never publish it in a public repository or send it to other people.
This is one of those small details that becomes very important when working with cloud infrastructure.

🌐 Step 4: Choosing the Network

EC2 instances run inside a VPC.
So I need to decide things such as:
1
2
3
4
5
6
7
VPC
↓
Subnet
↓
IP addressing
↓
Security Group
For a simple learning setup, I might place an instance in a subnet designed for the required connectivity.
This connects directly to the AWS networking concepts I learned in my previous articles.

πŸ›‘οΈ Step 5: Configuring the Security Group

A Security Group acts as a virtual firewall for the instance.
For a web server, I might need:
1
2
3
4
Inbound

HTTP β†’ 80
HTTPS β†’ 443
For administrative SSH access:
1
2
SSH β†’ 22
Source β†’ Trusted IP
I should avoid unnecessarily opening administrative ports to the entire internet.
For example, this:
1
2
3
SSH
22
0.0.0.0/0
allows connection attempts from anywhere.
A narrower source is generally preferable when practical.

πŸ’Ύ Step 6: Understanding EBS

Launching an EC2 instance isn't just about CPU and memory.
The server also needs storage.
That's where Amazon EBS β€” Elastic Block Store comes in.
A simple mental model is:
1
2
3
4
5
6
7
EC2
β”‚
β”‚
β”Œβ”€β”€β”€β–Όβ”€β”€β”€β”
β”‚ EBS β”‚
β”‚ Volumeβ”‚
β””β”€β”€β”€β”€β”€β”€β”€β”˜
EBS provides block storage that can be attached to EC2 instances.
I can think of it somewhat like a virtual disk attached to my server.
It can contain things such as:
  • Operating system files
  • Applications
  • Logs
  • Application data

🧩 Putting the Pieces Together

At this point, the EC2 architecture looks like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
🌍 Internet
β”‚
β–Ό
AWS VPC
β”‚
β–Ό
Subnet
β”‚
β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ Security Group β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”˜
β”‚
β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ EC2 β”‚
β”‚ Instance β”‚
β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜
β”‚
β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ EBS β”‚
β”‚ Volume β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
Each component has a different responsibility.

πŸ”‘ Step 7: Connecting to Linux EC2

After the instance is running, I can connect to it using SSH when the instance and network configuration allow it.
The general command looks like:
1
ssh -i "my-key.pem" ec2-user@PUBLIC_IP
The exact username depends on the operating system image.
For example, different Linux distributions can use different default users.
Once connected, I'm no longer just looking at an AWS dashboard.
I'm inside my cloud server.
I can run commands such as:
1
pwd
or:
1
ls
or:
1
uname -a
This is where EC2 starts feeling like an actual server rather than an AWS resource.

🌐 Turning EC2 Into a Web Server

Now I can install a web server or application.
For example, conceptually:
1
2
3
4
5
6
7
8
9
10
Internet
β”‚
β–Ό
EC2
β”‚
β–Ό
Web Server
β”‚
β–Ό
Application
A browser can then request the application's public endpoint when the networking and security configuration permit it.
This is one of the easiest ways to understand what EC2 actually provides.

πŸ”„ What Happens When I Stop an EC2 Instance?

This was another useful concept to learn.
EC2 instances have different lifecycle states.
A simplified view is:
1
2
3
4
5
6
7
8
9
10
11
Launch
↓
Running
↓
Stop
↓
Stopped
↓
Start
↓
Running
Stopping an instance is different from terminating it.

Stop

The instance is stopped, but its EBS-backed data can remain available.

Terminate

The instance is permanently removed.
This distinction matters when experimenting.
Before terminating anything, I should understand what data and resources will be affected.

🧹 Don't Forget Cleanup

This is probably one of the most important habits I'm developing while learning AWS.
After finishing a lab, I should check what I created.
For example:
1
2
3
4
5
6
EC2 instance
EBS volumes
Elastic IPs
Load Balancers
NAT Gateways
Other resources
Some resources can continue generating charges even when I think I'm "done" with the project.
So my workflow is becoming:
1
2
3
4
5
6
7
8
9
Create
↓
Experiment
↓
Learn
↓
Check resources
↓
Clean up

⚠️ Common Beginner Mistakes

❌ Mistake 1: Opening every port

More open ports means a larger attack surface.
Only allow the traffic the application actually requires.

❌ Mistake 2: Sharing private keys

Private keys should remain protected.
Never commit them to public Git repositories.

❌ Mistake 3: Choosing an unnecessarily large instance

A larger instance isn't automatically better.
Match resources to the workload.

❌ Mistake 4: Forgetting EBS volumes

Storage is another part of the infrastructure that needs to be understood and managed.

❌ Mistake 5: Forgetting to terminate test resources

An experiment isn't finished just because I closed the browser tab.
I need to check the resources I created.

🧠 What EC2 Taught Me About AWS

After working through EC2, I can now see how several AWS concepts connect:
1
2
3
4
5
6
7
8
9
10
11
VPC
β”‚
β”œβ”€β”€ Subnet
β”‚
β”œβ”€β”€ Route Table
β”‚
β”œβ”€β”€ Security Group
β”‚
└── EC2
β”‚
└── EBS
EC2 isn't an isolated AWS service.
It sits inside the larger AWS networking and security architecture.
That's why learning the services individually is useful, but understanding how they connect is even more important.

⚑ EC2 vs Lambda

One interesting comparison is:
1
2
3
4
5
6
EC2
β”‚
β”œβ”€β”€ Virtual Server
β”œβ”€β”€ OS Management
β”œβ”€β”€ Software Management
└── More Infrastructure Control
while:
1
2
3
4
5
6
Lambda
β”‚
β”œβ”€β”€ Run Functions
β”œβ”€β”€ No Server Management
β”œβ”€β”€ Event Driven
└── Automatic infrastructure management
Neither is automatically "better."
They solve different problems.
That's one of the biggest lessons I've learned while exploring AWS:
Choose the service based on the workload, not just because it's popular.

🎯 Final Takeaway

Before learning EC2, I thought:
"EC2 is just a virtual machine."
Now I see it as a combination of several AWS building blocks:
AMI β†’ Instance Type β†’ VPC β†’ Subnet β†’ Security Group β†’ EBS β†’ Authentication
And that makes the architecture much easier to understand.
My mental model now looks like:
1
2
3
4
5
6
7
8
9
10
11
12
13
AWS
β”‚
VPC
β”‚
Subnet
β”‚
Security Group
β”‚
β–Ό
EC2
/ \
/ \
EBS Application
The more AWS services I learn, the more I'm starting to see how they fit together into complete cloud architectures.
One AWS concept at a time. πŸš€β˜οΈ
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article