I Gave Myself an AWS Security Checklist Before Building Anything — Here’s Why 🔐☁️
What happens when you start building on AWS before thinking about security? 😅 As a beginner exploring cloud security, I created a simple checklist to secure my AWS environment before starting a project. From MFA and IAM to S3 permissions, credentials, networking, monitoring, and even unexpected AWS bills—here are the lessons that changed the way I approach building in the cloud.
I Gave Myself an AWS Security Checklist Before Building Anything — Here’s Why 🔐☁️
Let me confess something.
When I first started exploring AWS, I had exactly one thing on my mind:
“What can I build?” 😭
EC2? Let's launch it.
S3? Let's create a bucket.
IAM? We'll figure that out later.
Security?
“Yeah yeah, we'll do that after the project works.” 🤡
And honestly, I don't think I was alone.
When you're learning cloud, it's incredibly exciting to create your first resource, deploy your first application, or see your project actually running on AWS.
But somewhere between “Wow, I deployed my application!” and “Wait... who can access this?”, I realized I had been thinking about cloud the wrong way.
So I made myself a simple rule:
Before I build anything on AWS, I check the security first.
And that's how my little AWS security checklist was born. 📝
🚪 Rule #1: Secure the Root User
Let's start with the person who basically has the keys to the entire kingdom.
The AWS root user has full access to the AWS account.
And when I say full access, I mean... this is not the account you want casually using while sitting in a college canteen with your laptop connected to questionable Wi-Fi. 😭
So one of my first priorities became:
Secure the root user and enable MFA.
MFA adds another layer of authentication beyond just a password.
Because let's be honest:
Passwords can be forgotten.
Passwords can be leaked.
And “Password123!” is not a security strategy. 😂
The root account is extremely powerful, so my approach is simple:
Secure it. Store it safely. Don't use it for everyday tasks.
👤 Rule #2: Ask “Who Actually Needs Access?”
Then came IAM.
At first, IAM felt like another AWS abbreviation I needed to memorize.
But eventually I realized it's actually answering one of the most important questions in cloud security:
Who can do what?
Imagine giving every person in your college the keys to every classroom, every lab, the principal's office, and the server room.
Would that be a good idea?
Probably not. 😂
That's basically why least privilege matters.
If someone only needs to read data, they shouldn't automatically have permission to delete it.
If an application only needs access to one resource, it shouldn't necessarily have access to everything in the account.
So now, whenever I think about permissions, I ask:
“Does this identity really need this permission?”
If the answer is “well... maybe,” that's usually my cue to investigate further. 👀
🔑 Rule #3: MFA. Yes, Again.
If there's one security habit I don't want to compromise on, it's MFA.
It's easy to think:
“I'll set it up later.”
And we all know what later means.
Later = somewhere between never and the next time something goes horribly wrong. 😭
MFA adds an additional authentication factor, making account compromise harder even if a password is stolen.
So I prefer to enable it early rather than treating it as a “I'll get around to it” task.
Small effort.
Big difference.
🫣 Rule #4: Please Don't Put AWS Credentials on GitHub
This one deserves its own emotional support section.
Imagine spending days building a project...
You push your code to GitHub...
And then you realize you've accidentally pushed your AWS access keys too.
Congratulations. 🎉
You have now created a project and a potential security incident.
Obviously, I'm exaggerating—but accidentally exposing credentials is a serious risk.
So I've developed a habit:
Before pushing code, I ask:
“Did I accidentally leave any secrets in here?”
Credentials, API keys, tokens, passwords...
Anything that shouldn't be public stays out of the repository.
And whenever possible, applications should use safer mechanisms such as IAM roles and temporary credentials instead of embedding long-term credentials directly into code.
Because GitHub is many things.
A secret vault is not one of them. 😭
🪣 Rule #5: S3 Buckets Are Not Your Personal Dropbox
S3 looks deceptively simple.
Create a bucket.
Upload some files.
Done.
Except... permissions exist. 😭
And that's where things get interesting.
If I'm storing something in S3, I need to think about:
Who should access it?
Should it be public?
Who can read it?
Who can write to it?
Who can delete it?
Do I actually need public access?
The goal isn't simply to make everything inaccessible.
The goal is to give appropriate access to the appropriate people or applications.
Because “I made it public because my application wasn't working” is not exactly a cloud security philosophy. 😂
💸 Rule #6: Security Also Means Protecting My Wallet
Here's something I learned as a student:
Cloud security isn't only about protecting data.
It's also about protecting your AWS bill. 💀
You create an EC2 instance for testing.
You finish your experiment.
You think:
“I'll delete it tomorrow.”
Tomorrow becomes next week.
Next week becomes:
“Why did AWS charge me?” 😭
That's why I also consider billing awareness part of my AWS checklist.
AWS Budgets and billing alerts can help you keep track of your spending and detect unexpected costs.
Because the scariest notification isn't always:
“Suspicious login detected.”
Sometimes it's:
“Your AWS bill is higher than expected.” 💀
🌐 Rule #7: Just Because You Can Make It Public Doesn't Mean You Should
When you're building something, you want it to work.
And sometimes the easiest solution seems to be:
“Let's just make it accessible from everywhere.”
Problem solved!
Security problem created. 😭
That's why networking became another important part of my checklist.
Before exposing something publicly, I ask:
- Does this resource really need to be public?
- Which ports actually need to be open?
- Who should be able to connect?
- Can I restrict access?
- Can the resource remain private?
Services and concepts such as security groups, private networking, and controlled access become much easier to understand when you stop thinking about them as exam topics and start thinking:
“Would I actually want everyone on the internet to reach this?”
Usually...
No. 😂
👀 Rule #8: Don't Just Secure. Observe.
Here's another thing I had to learn:
Security isn't just about building walls.
You also need to know what is happening behind those walls.
Logging and monitoring can help you understand activity in your AWS environment.
Because imagine someone asks:
“What happened?”
And your only answer is:
“Umm... I don't know.” 🧍♀️
Not ideal.
Visibility helps you investigate unusual activity, troubleshoot problems, and understand what's happening inside your environment.
So now I don't just ask:
“Is this secure?”
I also ask:
“Would I know if something went wrong?”
🧠 My Final AWS Security Checklist
After all these lessons, my checklist became pretty simple:
Before I build:
🔐 Secure the root account
📱 Enable MFA
👤 Understand IAM and least privilege
🔑 Protect credentials and secrets
🪣 Review S3 access
🌐 Avoid unnecessary public exposure
💸 Set up billing awareness
👀 Think about logging and monitoring
📱 Enable MFA
👤 Understand IAM and least privilege
🔑 Protect credentials and secrets
🪣 Review S3 access
🌐 Avoid unnecessary public exposure
💸 Set up billing awareness
👀 Think about logging and monitoring
And finally...
🔄 Review everything again.
Because the truth is, security isn't a checkbox you tick once and forget.
It's an ongoing process.
From “Can I Build This?” to “Can I Build This Securely?”
This has probably been the biggest change in the way I approach AWS.
Earlier, my thought process looked something like this:
Idea → Build → Deploy → 😳 Security?
Now I'm trying to make it:
Understand → Secure → Build → Monitor → Improve.
I'm still learning. I'm still going to make mistakes. And I'm definitely still going to occasionally stare at an AWS console wondering:
“Okay... what exactly did I just create?” 😂
But that's the point of learning cloud security.
You don't need to know everything before you start.
You just need to develop the habit of asking the right questions.
So before my next AWS project, I'll probably ask myself:
“What am I building?”
But more importantly:
“How can I build it securely?” 🔐☁️
Because in the cloud, security shouldn't be the thing we remember after deploying.
It should be part of the plan from the very beginning. 🚀
# cloud-security# aws-community-builders# application-security# security-and-compliance# aws-iam-identity-center
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article