Introduction and Context

The Problem This Lab Solves

Every cloud application eventually runs compute somewhere. Whether it’s a backend API, a data processing job, or a build server, someone had to provision, configure, and secure that compute. EC2 is the foundational AWS compute primitive — understanding how to deploy it correctly, not just quickly, is the difference between infrastructure that holds up and infrastructure that creates incidents.

This lab is not about clicking through the EC2 wizard and calling it done. It is about understanding the network context your instance lives in, why you scope security group rules the way you do, and how IAM roles replace the dangerous habit of embedding credentials in running servers.

The Scenario

You are a cloud engineer onboarding to a small team that runs its services on AWS. Before you are trusted to touch production, you need to demonstrate you can provision compute correctly from scratch. That means: a running Linux instance, reachable over SSH from your IP only, with an IAM instance profile attached, and a clear audit trail of what was created and why.

What You Will Build

By the end of this lab you will have:

• A running EC2 instance (Amazon Linux 2023, t2.micro or t3.micro) inside your default VPC
• A security group that permits SSH only from your current IP address
• An IAM role with an instance profile attached to the instance
• A confirmed SSH session into the running instance

Measurable End Result

You will know this lab is complete when you can run the following from your local terminal and receive a successful response:

ssh -i ./lab-key.pem ec2-user@<your-instance-public-ip> "echo 'Connected successfully' && curl -s http://169.254.169.254/latest/meta-data/instance-id"

The output will print Connected successfully followed by the instance ID. That confirms networking, key authentication, and instance metadata access are all functioning.