Launch Your First Secure EC2 Server

Launch a Linux EC2 instance and lock it down with a custom security group.

Introduction

30 Second Summary

Every time you shop online, stream a show, or check the weather on your phone, you are talking to a server running in the cloud. Someone had to launch that server. Someone had to decide who gets in and who stays out.

In this project, you will launch your own Linux server on AWS, connect to it from your laptop, discover a real security vulnerability in its default setup, and fix it by locking down access to only your IP address.

What You'll Build

A secure Linux server in the cloud that you can SSH into from your macOS Terminal, run commands on, and prove to anyone that only you can access it.

By the end of this project, you'll have:

  • A cloud server you can connect to from your laptop and run commands on, just like a real ops engineer.
  • A mental model of how VPCs, subnets, internet gateways, security groups, and instances connect, backed by architecture diagrams you can explain to someone else.
  • A locked-down security group that blocks the entire internet from reaching your server while still letting you in.
  • Secret Mission: install a web server on your instance and open HTTP traffic to the world while keeping SSH locked to your IP only.

Are there any prerequisites?

You need an AWS account (free tier is fine) and a Mac. That is it. macOS has SSH built in through Terminal, so you do not need to install any additional tools or code editors.

Before We Start

Before you launch anything in AWS, take a moment to commit to what you're about to build and why it matters.

Orient Yourself in the AWS Console

Before you launch a server, you need to know where it will physically live. AWS operates data centers across the globe, organized into regions and Availability Zones.

In this step, you'll sign in to the AWS Console, pick a region close to you, and discover the networking infrastructure that AWS already set up in your account. This existing network is where your EC2 instance will live.

In this step, get ready to:
  • Choose an AWS region for your server.
  • Locate your default VPC and its networking components.
  • Map out how regions, Availability Zones, VPCs, and subnets connect.
Sign in and choose a region

Your server needs a home. AWS divides the world into regions. Each region is an independent cluster of data centers in a specific geographic area.

  • Open your browser and navigate to the AWS Management Console at https://console.aws.amazon.com.
  • Sign in with your AWS account credentials.
  • In the search bar at the top, type EC2 and select EC2 from the results.
  • Look at the top-right corner of the navigation bar. You'll see a region name like N. Virginia displayed there.
  • Click the region selector and choose a region close to your physical location (e.g., US East (N. Virginia)).

After selecting your region, notice the region code (e.g., us-east-1) displayed in the navigation bar. This code identifies your region in all AWS services.

What is a region?

A region is a geographic area containing multiple isolated data centers. Choosing a region close to you means lower latency when connecting to your server.

Each region operates independently. Resources you create in one region don't appear in another.

Don't see EC2 in the console?

Make sure you're signed into the correct AWS account. If the search bar returns no results, try refreshing the page.

help me find the EC2 service in the AWS Console

Explore your default VPC

Every AWS account comes with a default VPC (Virtual Private Cloud) already created in each region. This is the private network where your EC2 instance will run.

  • In the search bar at the top of the console, type VPC and select VPC from the results.
  • In the left navigation pane, click Your VPCs.
  • You'll see one VPC listed with a CIDR of 172.31.0.0/16. This is your default VPC.

Now explore the resources AWS created inside this VPC.

  • In the left navigation pane, click Subnets. You'll see one subnet per Availability Zone in your region (e.g., us-east-1a, us-east-1b, etc.).
  • Click Internet gateways in the left pane. You'll see one internet gateway attached to your default VPC. This is the door between your VPC and the public internet.
  • Click Route tables in the left pane. Find the main route table associated with your default VPC. It has a route sending 0.0.0.0/0 (all internet traffic) to the internet gateway.
  • Click Security groups in the left pane. You'll see a default security group that acts as a virtual firewall for resources in the VPC.

What is a VPC?

A VPC is your own private network inside AWS. It's logically isolated from other customers' networks.

The CIDR 172.31.0.0/16 defines the range of private IP addresses available inside the VPC. Every subnet, instance, and resource inside gets an address from this range.

What is an Availability Zone?

An Availability Zone (AZ) is a physically separate data center within a region. Each AZ has independent power, cooling, and networking.

Your default VPC spreads subnets across multiple AZs so that if one data center fails, resources in other AZs keep running.

Understand the architecture

You've now seen all the pieces. Here's how they fit together, from the outside in:

  • Region — the geographic area you chose (e.g., us-east-1).
  • VPC — your private network inside that region (172.31.0.0/16).
  • Subnets — one per Availability Zone, each a smaller slice of the VPC's IP range.
  • Internet gateway — connects your VPC to the public internet.
  • Route table — traffic rules that send internet-bound packets (0.0.0.0/0) through the internet gateway.
  • Security group — a firewall that controls which traffic can reach your resources.

Think of it as nesting boxes. Your region contains the VPC, which contains subnets spread across Availability Zones, with an internet gateway as the single exit to the outside world and security groups guarding each resource inside.

Before you move on, take a moment to confirm what you've found.

  • Look at the region code in your console's top-right corner. Confirm it matches the region you selected earlier.
  • Switch back to Subnets in the VPC left pane. Name at least two Availability Zones you see listed in the Availability Zone column (e.g., us-east-1a and us-east-1b).

Only see one subnet?

Some newer regions have fewer Availability Zones. As long as you see at least two subnets with different AZ names, you're all set. If you see only one, try switching to a larger region like us-east-1 which has multiple AZs.

help me find Availability Zones and subnets in my VPC

Your networking foundation is mapped out. Next up, you'll launch a real EC2 instance into this VPC and connect to it from your Terminal.

Launch Your First EC2 Instance and Connect

You have explored the networking backbone that your server will live in. Now it is time to actually launch a server inside that network and prove you can reach it from your laptop.

In this step, you will launch an EC2 instance with default settings and connect to it via SSH. This gives you an early win and sets up the security problem you will fix in the next step.

In this step, get ready to:
  • Launch an EC2 instance named "my-first-server" using the AWS Console.
  • Create a key pair and download the private key to your laptop.
  • SSH into your running instance from macOS Terminal.
Launch your EC2 instance

The EC2 launch wizard walks you through choosing an operating system, an instance size, and a key pair for secure login. You will accept most defaults to get running quickly.

  • Return to the EC2 console. In the left navigation pane, click Instances.
  • Click the Launch instances button at the top of the page.

The launch wizard opens with several sections to configure. Walk through each one:

  • Under Name and tags, enter my-first-server in the Name field.
  • Under Application and OS Images (Amazon Machine Image), confirm that Quick Start is selected and Amazon Linux is highlighted.
  • Confirm that the AMI shown is Amazon Linux 2023 AMI and is marked Free tier eligible.
  • Under Instance type, select a type that is marked Free tier eligible (t2.micro or t3.micro depending on what your account shows).

What is an AMI?

An AMI (Amazon Machine Image) is a pre-built template that contains the operating system and software for your server. Think of it like a ready-made hard drive image. Amazon Linux 2023 is AWS's own lightweight Linux distribution optimised for cloud workloads.

Now configure the key pair that lets you log in:

  • Under Key pair (login), click Create new key pair.
  • Enter my-ec2-key as the Key pair name.
  • Select RSA for Key pair type.
  • Select .pem for Private key file format.
  • Click Create key pair. Your browser automatically downloads a file called my-ec2-key.pem to your Downloads folder.

What is a key pair?

A key pair is a pair of cryptographic keys. The public key lives on the server and the private key (the .pem file) stays on your laptop. When you SSH in, the server checks that your private key matches the public key it has on file. Without the .pem file, nobody can log in.

  • Under Network settings, leave everything at the defaults. The wizard will create a security group allowing SSH from anywhere.
  • In the Summary panel on the right, review your settings and click Launch instance.

You will see a success message confirming that your instance is launching.

  • Click View all instances to go back to the Instances list.
  • Watch the Instance state column. It starts as Pending and transitions to Running within a minute or two.
  • Wait until the Status check column shows 2/2 checks passed. This confirms both system-level and instance-level health checks are complete.

Refresh the instance list

If the state still says Pending after a minute, click the refresh icon at the top of the Instances table. Status checks can take 2-3 minutes to pass after the instance reaches Running.

Connect to your instance via SSH

Your server is running in the cloud. Now you need to prove you can reach it from your laptop using SSH.

  • Press Cmd+Space to open Spotlight search.
  • Type Terminal and press Enter to open it.

Before you can use your key file, you need to set its permissions so only you can read it. If you skip this, SSH will refuse to use the key.

  • Set permissions on your key file by running this command:
chmod 400 ~/Downloads/my-ec2-key.pem

What does chmod 400 do?

The chmod 400 command sets the file to read-only for your user account and removes all access for everyone else. SSH requires that private key files are not accessible by other users on the system.

Now grab the public IP address of your instance from the console:

  • Back in the EC2 console, click on your my-first-server instance to open its details.
  • Find the Public IPv4 address field in the instance summary. Copy this IP address.

Before you run the SSH command, what do you think you will see if the connection succeeds?

  • Connect to your instance by running this command:
ssh -i ~/Downloads/my-ec2-key.pem ec2-user@[[EC2_PUBLIC_IP="your EC2 public IPv4 address"]]

What does this SSH command do?

The -i flag tells SSH which private key file to use for authentication. ec2-user is the default username on Amazon Linux instances. The IP address at the end is the public address AWS assigned to your instance.

SSH will ask you to confirm the server's fingerprint the first time you connect. Type yes and press Enter.

You should see the Amazon Linux welcome banner and a command prompt. You are now running commands on a server in the cloud.

  • Confirm your identity on the remote server by running:
whoami

You should see ec2-user printed in the terminal. This proves you are logged into the remote instance, not your local machine.

How did traffic reach your instance?

Your SSH connection travelled from your laptop over the public internet, through the internet gateway attached to your VPC, into the public subnet where your instance lives.

Before reaching the instance, traffic passed through the security group firewall. Because the security group currently allows SSH from any IP address, your connection was permitted.

  • Disconnect from the instance by running:
exit

Your terminal prompt returns to your local machine.

SSH connection timed out or was refused?

  • Make sure the instance state is Running and status checks show 2/2 checks passed before attempting SSH.
  • Verify you copied the Public IPv4 address (not the Private IPv4 address) from the instance details.
  • If you see "Permission denied (publickey)", confirm you ran chmod 400 on the correct file path: ~/Downloads/my-ec2-key.pem.

Help me troubleshoot my SSH connection to EC2.

You now have a cloud server you can control from your laptop. Next up, you will discover a real security vulnerability hiding in this setup's default configuration.

Discover the Security Problem

Your instance is running and you've already connected to it over SSH. You have a real cloud server under your control.

But there's a problem hiding in your network configuration. When you launched with the default Network settings, the wizard quietly created a security group that allows SSH access from anywhere on the planet. In this step, you'll see the vulnerability with your own eyes.

In this step, get ready to:
  • Examine the security group attached to your instance.
  • Identify why the default inbound rule is a security vulnerability.
  • Find your public IP address in preparation for the fix.
Examine your instance's security group

Every EC2 instance has a security group acting as a virtual firewall. It controls which traffic is allowed in and out. Let's inspect the one attached to your instance.

  • Return to the EC2 console in your browser.
  • Click Instances in the left navigation pane.
  • Select your instance my-first-server by clicking on its name.
  • Click the Security tab in the instance details panel below.

Before you look at the inbound rules, make a prediction. When you launched your instance, you left the Network settings at their defaults. What do you think the Source field says for the SSH rule? Does it restrict who can connect, or does it allow anyone?

  • Under Security groups, click the security group link (named something like launch-wizard-1).
  • Click the Inbound rules tab.

You'll see one rule: Type: SSH, Port range: 22, Source: 0.0.0.0/0. That 0.0.0.0/0 means every device on the entire internet is allowed to attempt SSH connections to your server.

What does 0.0.0.0/0 mean?

In CIDR notation, 0.0.0.0/0 represents every possible IP address. It's the widest possible gate. When a security group rule uses this as the Source, it means "allow traffic from anywhere."

Think of it like a building with a door that has no lock. Anyone who walks up can try the handle.

How does traffic flow to your instance?

Here's the architecture: a request from the internet enters your VPC through the internet gateway, reaches the subnet where your instance lives, and hits the security group. The security group checks its inbound rules. Right now, port 22 has a wide-open gate labeled "Entire Internet Allowed."

Your instance sits behind this single checkpoint. If the rule allows it, the traffic passes straight through.

Understand why this is dangerous

You might think your private key keeps you safe. After all, nobody can SSH in without it. But having SSH open to the world creates real risk.

Why is open SSH a problem?

Automated bots constantly scan the internet for servers with port 22 open. With 0.0.0.0/0 as the source, your server will receive brute-force login attempts around the clock.

Your private key protects you today. But if it were ever leaked, accidentally committed to a repository, or shared by mistake, anyone could instantly access your machine. Best practice is to restrict SSH to only known IP addresses. This way, even a compromised key is useless from an unauthorized network.

Find your public IP address

To lock down SSH access, you need to know your own public IP address. AWS provides a simple tool for this.

  • Open a new browser tab.
  • Visit https://checkip.amazonaws.com.
  • You'll see a single line of text showing your current public IP address (for example, 203.0.113.42).
  • Copy this IP address and save it somewhere (a sticky note, a text file, or just leave the tab open).

Why do I need my IP address?

In the next step, you'll create a new security group that only allows SSH from your specific IP. Instead of "anyone on the internet can try," the rule will say "only this one address can connect." That's the difference between a wide-open door and a door that only opens for your key card.

Your IP might change

Most home internet connections use dynamic IP addresses that change occasionally. If you lose SSH access later, revisit checkip.amazonaws.com and update your security group rule with your new IP.

You've now identified the vulnerability: your server's SSH port is open to the entire internet. You also have your public IP address ready. In the next step, you'll create a custom security group that slams that door shut and only lets your IP through.

Lock Down Your Server with a Custom Security Group

In the last step, you saw the problem with your own eyes. Your server's security group allows SSH connections from any IP address on the planet.

The fix is to create a brand-new security group that only permits SSH from your specific IP address. This is standard production practice for securing EC2 instances.

In this step, get ready to:
  • Create a custom security group with SSH restricted to your IP.
  • Replace the launch-wizard security group on your instance.
  • Verify SSH still works from your machine.
Create a custom security group

You are going to build a new security group from scratch with a single, tightly scoped rule. Only your IP address will be allowed through on port 22.

  • In the EC2 console, expand Network & Security in the left navigation pane.
  • Click Security Groups.
  • Click the Create security group button.
  • In the Security group name field, enter ssh-my-ip-only.
  • In the Description field, enter Allow SSH from my IP only.
  • For VPC, confirm your default VPC is selected (it should be pre-filled).

Now add the inbound rule that restricts SSH to only your IP address.

  • Scroll down to Inbound rules and click Add rule.
  • Set Type to SSH.
  • Set Source to My IP. The console automatically fills in your current public IP address with a /32 suffix.
  • Leave Outbound rules at the default (all traffic allowed).
  • Click Create security group at the bottom of the page.

You should see a green success banner and your new ssh-my-ip-only security group listed with its inbound rule.

What does /32 mean?

In CIDR notation, /32 means "this exact single IP address." It is the most restrictive source you can set. Compare this to 0.0.0.0/0 which means "every IP address on the internet."

By choosing My IP, the console looked up your public IP (the same one you found at checkip.amazonaws.com) and appended /32 to lock access to that single address.

Don't see your VPC in the dropdown?

Make sure you are in the same region you used when launching your instance. Check the region selector in the top-right corner of the console.

Help me find my default VPC in the security group creation page.

Swap the security group on your instance

Your new security group exists, but it is not attached to anything yet. You need to remove the old open group and attach the new locked-down one.

  • In the left navigation pane, click Instances.
  • Select your my-first-server instance by clicking its checkbox.
  • Click Actions in the top menu bar.
  • Choose Security, then Change security groups.
  • Under Associated security groups, find the existing launch-wizard security group and click Remove next to it.
  • In the search box, type ssh-my-ip-only and select it from the results.
  • Click Add security group.
  • Click Save.

Verify the swap by clicking the Security tab in the instance details panel. You should see ssh-my-ip-only listed and the inbound rule showing your IP with /32 on port 22.

Why replace instead of edit?

You could edit the old launch-wizard group's rules, but creating a dedicated group with a clear name is better practice. It makes your intent obvious to anyone reading the configuration later. In production, you would have many security groups named by purpose.

Test the fix

The security group swap takes effect immediately. Before you run the SSH command, predict what you think will happen. Will the connection succeed or fail?

  • Open Terminal on your Mac (press Cmd+Space, type Terminal, press Enter).
  • Connect to your instance by running this command:
ssh -i ~/Downloads/my-ec2-key.pem ec2-user@[[EC2_PUBLIC_IP="your EC2 instance's public IPv4 address"]]

The connection succeeds because your current IP address matches the /32 rule you just created. You should see the Amazon Linux welcome banner.

  • Run this command to confirm you are on the remote machine:
whoami

You should see ec2-user printed in the terminal.

  • Disconnect from the instance by running:
exit

You are back on your local machine. Your server is now hardened. Only your IP address can reach it over SSH.

How can you confirm someone else would be blocked?

Switch back to the EC2 console and check the Security tab on your instance. The inbound rule's Source column now shows your specific IP with /32 instead of 0.0.0.0/0. Any connection attempt from a different IP address is silently dropped by the security group before it ever reaches your instance.

Connection timed out?

If the SSH command hangs and eventually times out, your IP address may have changed since you created the rule. This happens if your ISP rotates addresses or if you switched networks.

Visit https://checkip.amazonaws.com again. If the IP differs from what the security group shows, edit the inbound rule in ssh-my-ip-only to use your new IP.

Help me fix my SSH connection timeout after changing security groups.

Your server is locked down and proven accessible. Next up, you will take on a Secret Mission to install a web server and serve a page to the world while keeping SSH restricted to your IP only.

Secret mission

Serve a Web Page to the World

Your server is locked down and secure. But a server that nobody can reach isn't very useful. Can you install a web server and open it to the world, while keeping SSH restricted to only your IP?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project is Free Tier eligible, so there are no costs while your account stays within Free Tier limits. The instance does consume Free Tier hours while running.

Cost warning

Your EC2 instance uses Free Tier hours while it is in the Running state. If you leave it running and exceed 750 hours in a month (across all Free Tier eligible instances), you will start incurring charges. Stop or terminate the instance when you are not actively using it.

Resources you used:

  • EC2 instance: my-first-server (running, Free Tier eligible).
  • Security group: ssh-my-ip-only (attached to the instance).
  • Security group: launch-wizard-1 (not attached, but still exists in your account).
  • Key pair: my-ec2-key (public key stored in AWS).
  • Local key file: ~/Downloads/my-ec2-key.pem (private key on your Mac).

Keep everything running

No action needed. Choose this if you are still actively building or want to practise more SSH commands on your instance.

  • Your instance stays in the Running state and continues consuming Free Tier hours.
  • Monitor your usage in the AWS Billing console under Free Tier to make sure you stay within limits.

Pause - I'll come back to this later

Stop the instance to pause compute billing. Your security groups, key pair, and instance configuration remain intact so you can restart later.

  • In the EC2 console, select your my-first-server instance.
  • Choose Instance state, then Stop instance.
  • Confirm by clicking Stop.
  • The instance state changes to Stopped. Compute charges stop immediately. EBS storage charges are negligible within Free Tier.
  • When you are ready to resume, select the instance and choose Instance state, then Start instance. Note that the public IP address will change after a restart.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps in order.

  • Terminate the instance: select my-first-server in the EC2 console, choose Instance state, then Terminate instance. Confirm by clicking Terminate. Wait until the instance state shows Terminated.
  • Delete the security groups: in the left navigation pane, choose Security Groups. Select ssh-my-ip-only, choose Actions, then Delete security groups. Enter Delete to confirm. Repeat for launch-wizard-1.
  • Delete the key pair from AWS: in the left navigation pane, choose Key Pairs. Select my-ec2-key, choose Actions, then Delete. Enter Delete in the confirmation field and click Delete.
  • Delete the local key file by running this command in Terminal:
rm ~/Downloads/my-ec2-key.pem

Why can't I delete the security group?

Security groups cannot be deleted while they are attached to a resource. Make sure the instance state shows Terminated before attempting to delete its security groups. It may take a minute for the termination to complete.

Nice Work!

Nice Work!

You just launched a Linux server in the AWS cloud, connected to it from your laptop, and locked it down so only you can access it. That is real cloud security in action.

Here's what you accomplished:

  • Launched an EC2 instance and connected to it over SSH from your macOS Terminal, proving you can control a cloud server from your laptop.
  • Discovered a real security vulnerability (SSH open to 0.0.0.0/0) in the default configuration and understood why it puts your server at risk.
  • Created a custom security group that restricts SSH access to your IP only, following production-grade AWS security practices.
  • Secret Mission: Installed Apache, served a custom web page to the world on port 80, and configured port-level access control (HTTP open, SSH restricted).

Ready to quiz yourself?