ec2 on Alperen Doc

ec2-instance-configuration-keys

Mon, 01 Jan 0001 00:00:00 +0000

EC2 Instance Configuration: Keys#

We need to get the PatientPing application running on a server, but first we need a secure way to connect to that server. Usually, this is done with ssh and a key pair.

Windows servers have extra hoops to jump through (some of them also requiring a key pair), but Linux systems make up the majority of cloud servers, even on Microsoft’s Azure, which gives me joy. We’ll focus on Linux for this document.

ec2-instances

Mon, 01 Jan 0001 00:00:00 +0000

EC2 Instances#

With a VPC, subnets, and a key pair in hand, we’re ready to launch our first AWS server instance.

Elastic Cloud Compute (EC2) is AWS’ flagship service for running servers on their infrastructure. It’s their answer to questions like:

How do I get a Linux or Windows box in Amazon’s cloud?
How do I provision dedicated hardware?
How do I build a server with a GPU attached?

Let’s create an instance and look at the choices we have to make along the way.

elastic-ips

Mon, 01 Jan 0001 00:00:00 +0000

Elastic IPs#

Our PatientPing server does need a public IP address to be reachable on the internet, but we’re going to use an “Elastic IP address” (EIP). This is an address that we can attach to any of our servers and move around as needed. You might be thinking:

“But Alperen, why not just use the nice automatic public IP address?”

Well, the “auto-provisioned IP address” that we opted not to use earlier has a few downsides:

aws-security-groups

Mon, 01 Jan 0001 00:00:00 +0000

Security Groups#

Wait, so anyone who knows my server’s public IP address can access it?!

On some level, yes. That’s why we need a layer of protection to inspect network traffic coming in and going out, and make sure it’s traffic we actually want. We need a firewall, or in AWS terms, a security group. It lets you set rules like:

All traffic coming from my server is allowed to go where it wants (i.e., outbound traffic).
Folks on the internet are allowed to reach my web server, but not my database server (i.e., inbound traffic).

ssh-to-aws-server

Mon, 01 Jan 0001 00:00:00 +0000

SSH to Our Server#

You may start to understand why people sometimes throw up their hands and use an “easier” provider like Vercel or Heroku. Those providers configure all the same things we’ve done so far, then sell it to you at a (steep) markup.

But if you can handle the basics on your own (and you can), you’ll save money and have more control over your infrastructure.

Seriously, some folks are happy to chew through C code full of malloc, calloc, and int *int_list_ptr = (int *)struct_list_of_ints;, but adding a route is too hard? Not you; onward and upward.

deploy-site-to-aws-server

Mon, 01 Jan 0001 00:00:00 +0000

Deploy the PatientPing Site#

Now that you can SSH into the patientping-web server, let’s get the PatientPing application running on it. We’ll install git, clone the app, install its dependencies, and start the web server.

Cost check: No new resources. You’re using the same EC2 instance; cost is unchanged.

Assignment#

Deploy the PatientPing application on the patientping-web instance.

SSH into your patientping-web instance (e.g. ssh patientping if you configured that in the previous lesson).
Install git on the instance (the base AMI may not include it). On Amazon Linux, run:


sudo dnf upgrade
sudo dnf install git

Install uv to be able to run the Python server:

curl -LsSf https://astral.sh/uv/install.sh | sh

Verify that you have both git and uv in PATH:

which git
which uv

Clone the GitHub repo of the PatientPing app to the EC2 instance:

cd ~
git clone https://github.com/bootdotdev/patientping-web.git
cd patientping-web
uv sync
uv run patientping.py

You should see the server start up on port 8080!

open-web-traffic

Mon, 01 Jan 0001 00:00:00 +0000

Open Web Traffic#

The PatientPing app is running on the server, but nobody can reach it because our patientping-public security group only allows inbound SSH traffic on port 22. Port 8080, where the app is listening, is blocked.

This is actually a good default. A firewall that blocks everything except what you explicitly allow is the safest starting point. You saw firsthand in the last lesson what that looks like: the browser just hangs because the packets never make it through.

creating-and-using-your-own-ami

Mon, 01 Jan 0001 00:00:00 +0000

Creating and Using Your Own AMI#

When we configured our server, we chose one of the out-of-the-box “base AMIs” that AWS provides. However, it’s also possible to make your own!

Why Create an AMI?#

Simple backup: You can snapshot a running server so that if something goes wrong, you can launch a new instance from that image and get back to a known good state.
Cold store and save on costs: Instead of leaving a server running 24/7 when you don’t need it, you can create an AMI, terminate the instance, and later launch a new instance from the AMI when you need it again. You pay only for the (cheaper) storage of the AMI/snapshot until you spin the server back up.
Transfer to a different region: AMIs are region-specific. If you want to run the same setup in another region, you can copy your AMI to that region and launch instances there. Handy for disaster recovery or moving closer to your users.
Cookie cutter for new servers: Once you have a server configured the way you want (OS, app, config), you can create an AMI from it and use that AMI as the basis for new instances (we’ll talk more about this soon).

Assignment#

Create an AMI from your patientping-web instance so you have a reusable image (and a simple backup).

aws-launch-template

Mon, 01 Jan 0001 00:00:00 +0000

Launch Template#

A launch template is a pre-baked configuration for EC2 instances.

As you know, an AMI is an image of the software on the server, but a launch template goes one step further: it also captures the “hardware” (instance type), the network configuration (subnet, security groups), and more. It’s a way to say, “This is the exact configuration I want for new servers.”

Assignment#

PatientPing is eventually going to need a bunch of servers. Create a launch template that uses the AMI you created.

launch-from-template-aws

Mon, 01 Jan 0001 00:00:00 +0000

Launch from Template#

The point of creating our launch template was so we could treat servers like cattle, not pets. Let’s do that.

We’ll terminate our patientping-web instance, and launch a brand new one from the patientping-web-launcher template to get the site back up. Because the AMI already has the app baked in, we’ll basically just need to SSH back in and start the app.

Assignment#

Terminate the current PatientPing instance and launch a replacement from your launch template.