Core Implementation

Launching the Instance

Navigate to EC2 > Instances > Launch instances.

Name: lab-ec2-instance

AMI: Search for Amazon Linux 2023 AMI (64-bit x86). Confirm it is labelled as Free tier eligible.

Instance type: Select t2.micro (or t3.micro if t2.micro is not shown in your region — both are Free Tier eligible). The t2/t3 micro instances are burstable, meaning they accumulate CPU credits during idle periods and spend them during bursts. For a lab workload this is entirely appropriate. Do not select anything larger — it will not be covered by Free Tier and will incur charges.

Key pair: Select lab-ec2-key.

Network settings: Click Edit. Confirm the VPC is your default VPC. Confirm a public subnet is selected. Confirm “Auto-assign public IP” is set to Enable. For the firewall, select “Select existing security group” and choose lab-ec2-sg.

Advanced details > IAM instance profile: Select lab-ec2-role.

Leave storage at the default 8 GiB gp3 volume. This is Free Tier eligible.

Click Launch instance. AWS will return an instance ID. Click through to view the instance in the console.

Waiting for the Instance to Reach Running State

After launch, the instance will progress through pending to running. The Status check column will show “Initializing” until both the system reachability check and the instance reachability check pass — typically within 60 to 90 seconds.

Do not attempt to SSH until both status checks show a green checkmark. If you attempt connection while the instance is still initializing, you will receive a Connection refused or timeout error that has nothing to do with your configuration.

Connecting via SSH

Retrieve the public IPv4 address from the instance detail panel. Then connect:

ssh -i ./lab-ec2-key.pem ec2-user@<public-ip>

On first connection, SSH will display a host key fingerprint and ask if you want to continue. Type yes. This adds the instance to your ~/.ssh/known_hosts file. In production, you would verify this fingerprint against the EC2 console’s “Get system log” output before accepting it — that prevents man-in-the-middle attacks during first connection.

Once connected, run the following to confirm the instance identity and that the IAM role is accessible via the metadata service:

# Confirm instance ID
curl -s http://169.254.169.254/latest/meta-data/instance-id
 
# Confirm IAM role is attached and metadata service is responding
curl -s http://169.254.169.254/latest/meta-data/iam/info

The second command should return a JSON document containing the ARN of lab-ec2-role. If it returns a 404, the instance profile was not attached correctly during launch.

What correct output looks like:

{
  "Code" : "Success",
  "LastUpdated" : "2025-02-22T10:00:00Z",
  "InstanceProfileArn" : "arn:aws:iam::123456789012:instance-profile/lab-ec2-role",
  "InstanceProfileId" : "AIPA..."
}

What a misconfiguration looks like: If the IAM role was not attached, the /iam/info endpoint returns HTTP 404 - Not Found. If you cannot SSH at all, the most common causes are: key file permissions not set to 400, wrong username (must be ec2-user for Amazon Linux), or your IP has changed since you created the security group rule.