EC2 Key Pairs Explained: Never Lose Access Again
What is an EC2 key pair, how does it work, and what happens if you lose it? A beginner's guide to creating, storing, and recovering AWS key pairs.
Series: AWS Beginners Guide (4 articles)
- …
- 4EC2 Key Pairs Explained: Never Lose Access Again This article
Here's how it usually goes. You launch your first EC2 instance, AWS pops up a download for a file called something like
my-server.pem, and you save it without thinking. Three weeks later you reinstall your OS, or clean out your Downloads folder, or switch laptops. Now the server is running, you're paying for it, and you can't get in.That file is a key pair, and it deserves a lot more attention than the half-second most people give it. This article covers what a key pair actually is, how to create one properly, where to keep it, and what to do on the bad day when it's gone.
What is an EC2 key pair?
A key pair is two linked files: a public key and a private key. They're generated together, and they only work as a match.
The public key goes onto your EC2 instance. On Linux, AWS drops it into
~/.ssh/authorized_keys for the default user. The private key stays with you. When you connect over SSH, your computer proves it holds the private key that matches the public one on the server. No password crosses the network, which is the whole point.Think of it as a padlock and its key. The padlock (public key) can sit on a hundred doors, and anyone can look at it. Only the key (private key) opens them. If someone copies your private key, they can open every door that padlock is on, so treat that file like a password.
There's one detail that surprises people: AWS does not keep your private key. It shows you the file once, at creation, and then forgets it exists. AWS can't resend it, and support can't recover it.
For Windows instances the story is slightly different. The private key isn't used for SSH login, it's used to decrypt the Administrator password so you can connect over RDP.
RSA vs ED25519, and .pem vs .ppk
When you create a key pair in the console, you get two choices that look more important than they are.
| Option | What it means | What to pick |
|---|---|---|
| RSA | The older, universally supported key type | Pick this for Windows instances, or if something old in your toolchain complains |
| ED25519 | Newer, shorter keys, faster to generate and verify | A good default for Linux instances |
| .pem | The standard OpenSSH format | Use on Mac, Linux, WSL, and the Windows OpenSSH client |
| .ppk | The PuTTY format | Only if you connect from Windows using PuTTY |
If you're on a recent Windows version, the built-in OpenSSH client handles
.pem files fine, so you can skip PuTTY entirely. ED25519 is for Linux instances only, so if you ever launch a Windows server, create an RSA pair for it.How to create a key pair in the console
- Open the EC2 console and go to Network & Security → Key Pairs
- Click Create key pair
- Give it a name that says what it's for, like
portfolio-server-2026rather thankey1 - Choose the key type and file format from the table above
- Click Create key pair
The private key downloads straight away. Move it somewhere permanent before you do anything else.
One thing worth knowing: key pairs are regional. A key pair you create in
ap-south-1 doesn't exist in us-east-1. If you launch an instance in a different region and your key isn't in the dropdown, that's why.How to create one from the command line
If you prefer the terminal, this does the same thing and saves the key file in one go:
1
2
3
4
5
6
7
aws ec2 create-key-pair \
--key-name portfolio-server-2026 \
--key-type ed25519 \
--query 'KeyMaterial' \
--output text > portfolio-server-2026.pem
chmod 400 portfolio-server-2026.pem
The
chmod 400 matters. SSH will refuse to use a private key that other users on your machine can read, and the error message you get back doesn't make the cause obvious.The better habit: bring your own key
There's a way of doing this that avoids the lost-key panic entirely. Instead of letting AWS generate the pair, generate it yourself and upload only the public half.
1
2
3
4
5
6
7
# Generate a key pair on your own machine
ssh-keygen -t ed25519 -f ~/.ssh/aws-main -C "aws-main"
# Upload just the public key to AWS
aws ec2 import-key-pair \
--key-name aws-main \
--public-key-material fileb://~/.ssh/aws-main.pub
Now the private key was never a one-time download. It lives in your
~/.ssh folder, it's part of whatever backup you already run, and you can regenerate the public file from it whenever you want:1
ssh-keygen -y -f ~/.ssh/aws-main
That last command is handy for another reason. If you find an old
.pem file and can't remember which instance it belongs to, it prints the public key, and you can compare it against what's in authorized_keys on the server.Where to store your private key
Some habits that will save you, roughly in order of how often people skip them:
- Move it out of Downloads on day one. A dedicated
~/.ssh/folder is the usual home. - Back it up somewhere encrypted. A password manager that supports file attachments works, or an encrypted drive. A plain cloud folder doesn't count.
- Keep it out of Git. Put
*.pemin your.gitignorebefore your first commit. Bots scan public repositories for AWS keys constantly, and a leaked private key is an open door. - Use different keys for different projects. If one leaks, you only have one project to clean up.
- Never send it over chat or email. If a teammate needs access, add their public key to the server instead of sharing yours.
Can you change the key pair on a running instance?
Not the way most beginners expect. The key pair you pick at launch is baked in at that moment. There's no "change key pair" button in the console for an instance that already exists.
What you can do is add another public key to the server yourself. Connect with your current key, open
~/.ssh/authorized_keys, and paste in the new public key on its own line. From then on, either private key will work.Deleting a key pair in the EC2 console has an equally surprising effect: it removes the record from AWS, but it does not remove the public key from instances that already use it. Those servers will keep accepting the old private key. So deleting a key from the console is not a way to revoke access. To actually revoke it, remove the line from
authorized_keys on each server.What to do if you lose your private key
Take a breath, because the instance isn't lost. You can't get the old key back, but you can get back into the machine. Which method fits depends on how your instance was set up.
If you can still reach the instance another way. If EC2 Instance Connect works (it's on by default for recent Amazon Linux and Ubuntu AMIs, and needs port 22 open to AWS's service range) or Systems Manager Session Manager is set up, use either of those to open a shell, then add a new public key to
authorized_keys. This is the easy case, and it's a good reason to set up Session Manager before you need it.If you can't, replace the key through the root volume. This is the classic fix, and it works for any EBS-backed Linux instance:
- Create a new key pair and keep the private key safe this time
- Launch a small temporary instance in the same Availability Zone, using the new key pair
- Stop the original instance
- Detach its root volume and attach it to the temporary instance as a secondary disk
- SSH into the temporary instance, mount the extra disk, and add your new public key to the
.ssh/authorized_keysfile on it - Unmount, detach the volume, and reattach it to the original instance as its root device (
/dev/xvdaor/dev/sda1, depending on the AMI) - Start the original instance and connect with the new key
- Terminate the temporary instance
Two warnings before you try it. Stopping an instance gives it a new public IP unless it has an Elastic IP, so check the address again before you reconnect. And instance-store-backed instances can't be stopped at all, so this method doesn't apply to them.
AWS also publishes a Systems Manager automation called
AWSSupport-ResetAccess that does this for you, and a user data method that swaps the key during a stop and start. Both are worth a look if the manual route feels fiddly. The most boring fix, if the instance holds nothing you can't recreate, is to launch a fresh one with a new key and move on.Quick checklist
- Name your key pairs after the project, not
key1 - Move the
.pemfile out of Downloads immediately - Run
chmod 400on it - Back it up somewhere encrypted
- Add
*.pemto.gitignore - Consider generating your own key and importing the public half
- Set up Session Manager now, while you still have access
One last thing
Do the backup step today, not after you finish reading the next tutorial. Open your
.ssh folder, check the key you launched your current instance with is actually in there, and if it's not, track it down while you still remember which download it was.Locked out of an instance and not sure which recovery method fits? Drop a comment with how you launched it and I'll help you work out the quickest way back in.
Series: AWS Beginners Guide (4 articles)
- …
- 4EC2 Key Pairs Explained: Never Lose Access Again This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article