Create an EC2 key pair, chmod 400 the .pem file, launch a t2.micro with an SSH-only security group, SSH in, query IMDSv2 metadata, and clean up ā all from the CLI.
Before creating anything, review the key pair model that AWS uses. Understanding why the process works this way helps you debug connection problems and make correct security decisions.
aws ec2 describe-key-pairs \
--query "KeyPairs[*].{Name:KeyName,Type:KeyType,Created:CreateTime}" \
--output tableWhen you create an EC2 key pair, AWS generates a public/private RSA or ED25519 key pair and gives you the private key once ā it is never stored by AWS again.
When an instance launches, cloud-init reads the public key from the AWS metadata service and writes it to /home/ec2-user/.ssh/authorized_keys before the instance becomes reachable.
SSH then uses standard public-key authentication: your private key proves your identity without sending a password over the network.
The describe-key-pairs command lists the key pairs currently registered in this region.
If devops-lab-key still exists from Lesson 301, you will see it here.
A table listing any existing key pairs in the region:
---------------------------------------------------------------------
| DescribeKeyPairs |
+--------------------+----------+-----------------------------------+
| Created | Name | Type |
+--------------------+----------+-----------------------------------+
| 2026-05-23T... | devops-lab-key | rsa |
+--------------------+----------+-----------------------------------+If no key pairs exist, the table is empty ā that is fine.
Lesson 303 creates its own key pair named devops-ssh-lab.