
π¦ 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 GroupBut 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 ApplicationWith EC2:
1
2
3
4
5
6
7
8
9
AWS Console
β
Choose Configuration
β
Launch Instance
β
Connect
β
Run ApplicationThis 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 InstanceSo 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 optionsI might see instance types with names such as:
1
2
3
t3.micro
t3.small
t3.mediumThe 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 ServerThe 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 GroupFor 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 β 443For administrative SSH access:
1
2
SSH β 22
Source β Trusted IPI should avoid unnecessarily opening administrative ports to the entire internet.
For example, this:
1
2
3
SSH
22
0.0.0.0/0allows 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_IPThe 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
pwdor:
1
lsor:
1
uname -aThis 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
β
βΌ
ApplicationA 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
β
RunningStopping 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 resourcesSome 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
β
βββ EBSEC2 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 Controlwhile:
1
2
3
4
5
6
Lambda
β
βββ Run Functions
βββ No Server Management
βββ Event Driven
βββ Automatic infrastructure managementNeither 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 ApplicationThe 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. πβοΈ
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article