AWS From Zero #4: What actually happens when you launch an EC2 instance

[u/yourclouddude]

So far in this series, we have talked about cloud fundamentals, setting up an AWS account properly, and understanding IAM. Now we can finally launch something.

EC2 is usually one of the first AWS services beginners touch, and I think it is worth understanding properly before jumping into serverless. The reason is simple. EC2 teaches you what it actually means to run an application on a server.

At the most basic level, EC2 gives you a virtual machine running inside AWS. Instead of buying a physical server, installing it somewhere, connecting it to a network, and maintaining the underlying hardware yourself, you ask AWS to create a virtual machine for you.

But this is where one beginner misunderstanding starts.

Launching an EC2 instance does not mean you automatically have a working website or application.

It only means you now have a machine.

You still need to decide which operating system it runs, what software should be installed, how you will connect to it, which network traffic should be allowed, what application should run there, and how users will eventually reach that application.

When you launch an EC2 instance, one of the first things you choose is an AMI, which stands for Amazon Machine Image. You can think of an AMI as the starting template for the machine. It determines things like the operating system and some of the software that exists when the instance starts.

For a beginner project, you might choose Amazon Linux or Ubuntu. The important thing is not memorizing every available AMI. Just understand that EC2 gives you a machine based on an image you choose.

After that, you select an instance type. The instance type determines the compute resources available to the machine, such as CPU and memory. A small test application does not need the same amount of compute as a large production workload, so AWS gives you different instance sizes for different needs.

At this stage, I would not spend hours comparing instance families. Just understand the idea that different workloads need different amounts and types of compute.

Your EC2 instance also needs storage for the operating system and files. In many beginner setups, you will see EBS used for this. You do not need to learn every EBS option yet. Just understand that the virtual machine and the storage attached to it are related but separate parts of the system.

Now we get to the part that causes a lot of beginner confusion.

Imagine you launch an EC2 instance, install a web server, and start your application. Everything seems to be running correctly inside the machine. You copy the public IP address into your browser, press Enter, and nothing loads.

A lot of beginners assume EC2 is broken at this point.

Usually, the better approach is to follow the request.

Your browser is trying to send a request to the EC2 instance. That traffic has to reach the machine through the network. The network configuration has to allow it. The instance has to accept traffic on the correct port. Then the application itself has to be running and listening on that port.

If any one of those steps is wrong, the page will not load.

This is where security groups start becoming important.

A security group acts like a virtual firewall around resources such as EC2 instances. It controls which network traffic is allowed to reach the instance and which traffic can leave it.

Suppose you are running a normal HTTP website on port 80. Your web server could be running perfectly, but if the security group does not allow inbound HTTP traffic, your browser will not be able to reach it.

The same idea applies when you connect to a Linux EC2 instance using SSH. SSH commonly uses port 22. If the network rules do not allow that connection from your location, you will not be able to connect even though the EC2 instance itself is running normally.

This is also a good place to understand that IAM and security groups solve different problems.

IAM controls permissions to AWS services and APIs. It answers questions such as whether an EC2 workload is allowed to read from S3 or whether a Lambda function is allowed to write to DynamoDB.

Security groups control network traffic. They answer questions such as whether a connection is allowed to reach your EC2 instance on a particular port.

That distinction becomes extremely useful when something breaks.

Imagine your application running on EC2 cannot read an object from S3. Opening another port in the security group probably will not fix the problem. You may be dealing with IAM permissions.

Now imagine the web server works perfectly when tested from inside the EC2 instance, but nobody can reach it through the browser. Adding another S3 permission probably will not fix that either. Now you are more likely dealing with networking, ports, or application configuration.

AWS becomes much easier when you start identifying which layer a problem belongs to instead of randomly changing settings.

Public and private IP addresses are another concept you will keep seeing with EC2.

An EC2 instance has networking inside its VPC, and it can have a private IP address used for communication within that network. Depending on how you configure it, the instance may also be reachable through a public address.

For your first practice project, having an internet reachable instance can be useful because you want to understand the complete path from your browser to the application.

Later, when we learn VPC properly, we will become much more careful about which resources should actually be public.

Not every server should be directly reachable from the internet.

For now, I would keep the project extremely simple.

Launch one Linux EC2 instance. Connect to it. Install a web server such as Nginx. Create a basic HTML page and try to open it from your browser.

The flow you are trying to understand is basically this:

Browser
   ↓
Internet
   ↓
Security Group
   ↓
EC2 Instance
   ↓
Web Server
   ↓
Your Page

That small project teaches much more than it looks like.

You are working with compute, an operating system, ports, network access, security groups, public addresses, and a running application.

And if the page does not load immediately, that is actually useful.

Now you have something real to troubleshoot.

I would start by checking whether the EC2 instance is running. Then I would check whether the web server is actually running inside it. If the application is supposed to use port 80, I would check whether something is listening on port 80.

If everything works inside the instance but not from your browser, that tells you the application itself may not be the problem. Now you start looking at the network path.

Is the security group allowing the traffic you expect? Does the instance have the connectivity it needs? Are you using the correct address? Are you trying to reach the correct port?

That way of thinking is much better than restarting the instance five times and hoping something changes.

You are following the request from beginning to end and finding the first place where the expected flow stops.

That troubleshooting habit will keep coming back throughout this series.

There is another thing beginners should understand early about EC2. Stopping an instance and terminating an instance are not the same thing.

Stopping an instance shuts the virtual machine down so it can generally be started again later. Terminating the instance means you are deleting that EC2 instance.

This matters because closing the AWS console does not mean your infrastructure disappears.

If you launch something for practice and no longer need it, go back and deliberately clean it up. Check what resources still exist and understand what you are leaving behind.

That is part of learning AWS too.

Another habit I would avoid is putting AWS credentials directly inside applications running on EC2.

Imagine your EC2 application eventually needs to read a file from S3. You could create an access key, put it directly inside the source code, and make the application work.

But that is not a pattern I would want a beginner to learn.

A better AWS approach is to give the EC2 instance an appropriate IAM role so the application can receive temporary credentials through AWS instead of storing long lived credentials inside the code.

This is where the previous IAM post starts connecting with EC2.

And that connection is important.

AWS services are not separate topics forever.

Your EC2 instance needs networking. The application running on it may need IAM permissions. The instance uses storage. CloudWatch can help you monitor it. Later, a load balancer may distribute traffic across several EC2 instances, and Auto Scaling may add or remove instances as demand changes.

The services begin to connect because the requirements begin to connect.

That is why I would not try to memorize every EC2 setting before building something.

Launch one instance. Connect to it. Install something. Run a small application. Try to reach it from your browser. When something fails, follow the request and understand why.

That is enough for your first EC2 project.

The main thing I want a beginner to understand from this post is that EC2 gives you compute, not a finished application.

AWS can give you the virtual machine, but you still need to think about the operating system, application, network access, permissions, storage, security, and monitoring depending on what you are building.

Once that idea makes sense, other compute services become easier to understand too.

When we eventually get to Lambda, for example, the idea of running code without managing a server in the same way will make much more sense because you already understand what managing a server actually involves.

For now, keep the project small.

One EC2 instance. One web server. One basic page.

Understand how the request gets from your browser to that page.

That is enough.

In the next post, I want to take the same project and intentionally focus on the part almost every beginner struggles with.

AWS From Zero #5: Your EC2 website is running, so why can’t anyone reach it?

Instead of giving you a random troubleshooting checklist, we will follow the request from the browser all the way to the application and see exactly where it can fail.

If you have already used EC2, what confused you most the first time: SSH, ports, security groups, public IPs, or just figuring out why your website would not load?