5 AWS Security Mistakes Beginners Make (That Can Get Your Account Hacked)

A leaked key or an open door in a new AWS account doesn’t announce itself. You usually find out when a surprise bill arrives or an email from AWS says your account may be compromised. These are 5 beginner security mistakes that are easy to make and just as easy to fix.

1. Using the root account for everything

When you sign up for AWS, you log in with the email you registered. That’s the root user, and it can do anything, including closing the account. Think of it as the master key to the whole building. You wouldn’t hand the master key to the delivery guy, and you shouldn’t use it for daily work either.

Fix: Turn on MFA for the root user, create a separate IAM user or role for daily work, and lock the root credentials away.

2. No MFA on anything

A password alone is one phishing email away from being useless. MFA means that even if someone steals your password, they still need your phone or authenticator app.

Fix: Enable MFA on the root user and on every IAM user. It takes about 3 minutes with any authenticator app.

3. Putting access keys in code (and pushing it to GitHub)

This is one of the most common ways accounts get compromised. A developer hardcodes an access key in a script, pushes it to a public repo, and automated bots scan GitHub for exactly this. AWS also scans public repos and may quarantine leaked keys, but you shouldn’t rely on that.

Fix: Never hardcode keys. On EC2, attach an IAM role to the instance so the app gets temporary credentials automatically. Locally, keep keys in ~/.aws/credentials, and add .env to your .gitignore. If a key ever leaks, delete it immediately and create a new one.

4. Opening SSH (port 22) to the whole internet

When you launch an EC2 instance, it’s tempting to set the SSH rule to 0.0.0.0/0 because it just works from anywhere. It also means every bot on the internet can try to log in to your server.

Fix: Restrict port 22 to your own IP only (the “My IP” option in the console), or use Session Manager so you don’t need port 22 open at all.

5. Giving every user or app AdministratorAccess

When you hit “Access Denied”, the quickest fix is to attach AdministratorAccess. It works, but now one leaked credential means full control of your account.

Fix: Follow least privilege. Give only what’s needed, such as read access to one S3 bucket, and expand only when something actually fails. IAM Access Analyzer can help you tighten policies later.

Bonus: New S3 buckets block public access by default now, but check the Block Public Access setting before you ever turn it off. Public buckets have caused some of the biggest data leaks in cloud history.

Security is like a tiffin carrier with a lid: the food inside is fine until the lid is left open. These five habits are the lid.

Your turn: which of these did you learn the hard way, or which one surprised you? Drop it in the comments 👇

One note on authenticity: I wrote this as habits and fixes rather than “this happened to me” stories, because I don’t know that you had a hacked account. If you actually did, or nearly did, add a one-line true story to any point. Real stories get more comments, but only keep ones that are true.