EC2 101: Servers-as-a-service

When I first started on AWS, I struggled to understand virtual compute. I picked T3 micro for everything because it was cheap, and for most use cases, it did the job. Sticking to one type of EC2 instance, however, is like picking one screwdriver size from your toolbox for everything... it may work for several projects, but you're creating more work for yourself if you don't select the right tool for the job. Now, I can't just select a random instance for my projects. I actually need to know what these instance types mean.

EC2 is the foundation of almost everything we build on AWS. The decisions we make in those first five minutes from considering instance types, security groups, storage, and networking will heavily influence the success of our projects. By the end of this article, you'll understand when EC2 can be useful in your projects AND be able to spin up EC2 instances for your use cases.

What is EC2?

EC2 stands for Elastic Compute Cloud. At its core, it's a virtual server running in an AWS data center. Think of it like a “server rental”, where you can shop pre-built servers designed to host specific types of applications, then “rent” space on those servers as needed. Rather than a virtual server or machine, we call it an instance. When you launch one, you pick the specs, you pick the operating system, and then you can be up and running in minutes. The elastic part is what's really key here. You can add computing resources to, remove computing resources from, or launch hundreds of instances on demand.

You may be comfortable with your current setup, however, given that you've been able to build hobby projects with no trouble. So that begs the question...

Why should I use an EC2 instance instead of running my app locally?

Think about the town that you live in, and what methods of transport you use. You may drive a car for daily transit, ride a motorcycle to save money on gas and take it for joyrides, or use a moving truck when you’re moving between homes. Do you personally own and maintain a car, motorcycle and a moving truck? Maybe you would if you owned a moving business, needed a daily driver for running errands, and enjoyed riding a motorcycle for fun. Most people, however, rarely use a moving truck, and some don’t even drive a car if their city has good public transit. Those folks wouldn’t own the moving truck... they would just rent it for the time they need it.

Imagine that you’re building a house on an empty plot of land. You’ll need some heavy equipment to build that house, including an excavator to dig the foundation, a crane to lift scaffolding, maybe a concrete mixer to lay a base layer for the house to sit on. Would you buy the excavator, crane, and concrete mixer outright, use it to build the house and just... keep them around? I’d bet that you’d rather just rent the equipment for the time you need it.

That’s what you’re doing when you spin up an EC2 instance. Lets say you’re training a machine learning model, and you only have access to a laptop with minimal graphics capacity... not very strong computing power, which is essential for fast model training. Would you buy a whole new computer to train these models, or would you rent access to an existing server for the exact computing time and computing capacity your model needs to be trained? If you chose the latter, EC2 provides that service.

EC2 has many instance types, each built for different types of workloads. EC2 can also scale automatically depending on how much traffic or compute power you demand from it. Your laptop, on the other hand, can’t install more graphics cards into itself instantly when a program bottlenecks it’s capabilities.

Now, before we launch our own EC2 instance, let me break down six key components you need to know about.

Amazon Machine Image (AMI): The Amazon Linux AMI is a maintained Linux image provided by AWS for use on Amazon EC2. It offers a stable, secure environment for running applications and includes packages for easy AWS integration, such as launch configuration tools and popular AWS libraries. AWS provides ongoing security and maintenance updates for all instances running the AMI, at no additional charge to EC2 users.
Instance Type: This is your instance's hardware specs. It defines the CPU, memory, storage, and network. We'll dive deeper into this later in the demo.
Key Pairs: With this you're able to authenticate and connect to your instance via SSH or RDP. If you are using Windows, when you use a key pair, AWS holds the public key. You hold the private key, but remember to always store this safely. Losing it can mean that you're locked out of your instance.
Security Groups: You can look at these as a stateful firewall that controls traffic that goes in and out of your instances.
Networking: This is a component that we need to discuss without going too deep. Here's what you need to know when it comes to networking on AWS. The Amazon VPC, or Virtual Private Cloud, allows you to configure subnets where you launch your instances into. These subnets can be public or private, with public subnets having a route directly to an internet gateway and private subnets not exposed to the internet. Within the VPC, you have full control over how you configure this. If you're interested in knowing more about the Amazon VPC, let me know in the comment section below.
EBS Volume (Amazon Elastic Block Store): This is a separate disk or storage that persists independently from your instance. We'll discuss why this matters later in the demo.

In this demo, we're going to launch an EC2 instance as a web server that we can connect to from the internet. To connect to the instance, we'll use Session Manager, a fully managed service that provides secure, auditable, and browser-based remote access to your EC2 instances. This means we won't need a key pair. To make this work, we first need to create an IAM role.

Part 1: Create an IAM Role for Session Manager

In the AWS Console, search for "IAM" and open the IAM console.
Click on "Roles," then click "Create role."
For the trusted entity type, select "AWS service."
Under use cases, select "EC2." Then select the additional use case "EC2 role for AWS SystemManager." This will allow us to connect to our instance via System Manager.
Click "Next." You'll see the policy that is already attached to this role. This is what allows browser-based access to your instance.
Click "Next" and enter a name for the role. We'll use ec2-ssm-role.
Verify the policy is attached in Step 1: “Select trusted entities” and click "Create role."

Part 2: Launch the EC2 Instance

Back in the AWS Console, ensure you are in the correct region. Select the region closest to you or your users. For example, if you're on the West Coast, select "US West 2 (Oregon)." If you're on the East Coast, "US East 1" may be a better fit. Remember, you want to select the region that will be geographically closest to your users as possible, whether that's you or your user base, to lower the latency for the average request.
Search for "EC2" and open the EC2 console. Click "Dashboard" in the left side menu.
Click "Launch Instance".
Enter a name for your instance. We'll use My First Instance.
Under "Application and OS Images," select "Amazon Linux." This is the AMI we will use for this session, and it provides all the AWS tools and features we need to work directly with AWS. You can optionally select the architecture (x86 or ARM). We'll leave this as default.
Under "Instance type," you can compare the different types of server. Don’t be intimidated by the instance type names. My colleague Brooke Jamieson wrote a wonderful article demystifying instance type naming conventions in AWS. For this demo, select t2.micro.

This falls under the free tier, which helps save on costs. If you're unsure which instance type to choose, you can click "Get advice," enter your workload requirements (e.g., web hosting, low cost), and AWS will provide recommendations. You can also click "Compare instance types" to view configurations side by side.
Under "Key Pair," select "Proceed without a key pair." Normally, best practice would be to generate a key pair, but for demonstration purposes we will be using SSM instead.
Under "Network settings," use the default VPC. AWS comes preconfigured with a VPC in each region that includes subnets, security groups, an internet gateway, and everything you need to launch instances and connect to the internet.
Under "Security groups," create a new security group. Allow SSH traffic (port 22) from "My IP" so that only your personal computer can access the instance via SSH. You also have the option to add HTTP and HTTPS traffic, but we'll configure that later.
Under "Configure storage," leave the default of 8 GB of EBS. You can increase this if needed.
Under "Advanced details," find the "IAM instance profile" dropdown and select the EC2-SSM-role we created earlier. This is what allows SSM to be accessed from our EC2 instance.
Click "Launch instance."

Part 3: Connect to Your Instance via Session Manager

Click on your instance ID to view its details. You'll see the state is "Running" and the status check says "Initializing." Three status checks need to pass before you can log in. You can also access this info by clicking on the "Instances" option in the left-side EC2 menu.
While waiting, scroll down to the details section. Here you'll see the instance ID, public IP address, private IP address (for access within the VPC), public DNS address, hostname, instance type, and all the configurations we set up.
Once all three status checks have passed, select your instance and click "Connect."
Select "SSM Session Manager" and click "Connect." If the Connect button is grayed out, your instance is not fully loaded yet. Wait and try again.
You're now inside your instance via the browser. Now, we can verify the identity of the users logged in to the instance. To verify, type:
```
whoami
```
You'll see the logged-in user is ssm-user.

Part 4: Install and Start a Web Server

First, update your instance:
```
sudo yum update -y
```
sudo literally means “Super User Do”. This runs the command as a super user. yum is the package manager for Amazon Linux. Think of it like an app store for your instance. update checks for the latest versions of everything installed, and -y auto-confirms so you don't have to approve each update.
Install Apache, one of the most popular web servers in the world:
```
sudo yum install httpd -y
```
Start the Apache web server:
```
sudo systemctl start httpd
```
Enable Apache to start automatically on reboot:
```
sudo systemctl enable httpd
```
Verify that Apache is running:
```
sudo systemctl status httpd
```
You should see the status as "active (running)" and "enabled."

Part 5: Fix the Security Group to Allow Web Traffic

Go back to the AWS Console and copy your instance's public IP address. Paste it into your browser. You'll notice the page doesn't load. You get a blank page or a connection error.
This is because our security group only allows port 22 (SSH). To access our web server, we need to allow port 80 (HTTP). Remember, the security group is a stateful firewall. If we don't allow the traffic, it will be denied.
In the EC2 console, go to your instance's "Security" tab and click on the security group.
Click "Edit Inbound Rules."
Add a new rule: Type "HTTP" (port 80), Source "Anywhere." This means anyone on the internet can access your web server via HTTP. We're not configuring HTTPS here because that requires a certificate.
Click "Save rules."
Go back to your browser and refresh. You should now see the default Apache test page.

Part 6: Customize Your Web Page

Back in your Session Manager terminal, run:

sudo bash -c 'echo "<h1>Hello from EC2</h1>" > /var/www/html/index.html'

This writes a simple HTML header to the Apache default index file.
Go back to your browser and refresh. You should now see "Hello from EC2."

You now have a running, customized web server in the AWS cloud.

Finishing Thoughts

Your discipline and focus have paid off, dear developer. You've created an IAM policy to control traffic, selected an EC2 instance type, started an instance and run your code on an AWS managed server. You can now officially tell your friends you "build software in the cloud". That's pretty cool if you ask me.

I challenge you to build more complex applications using EC2, and try to incorporate new instance types into your architectures. Alternatively, if this is your first step on your cloud journey, I challenge you to migrate a project from a class, club or hobby onto the cloud using AWS services. If you're an advanced developer, consider the AWS Compute Optimizer to brainstorm ideas to optimize your architecture to reduce cost. Most importantly, if there's anything I hope you learned today... it's that Lamborghini's are cheaper to rent.

Until next time,
Lucas