Happy Tuesday!

If you’re new to cloud, you might think security is something you “add later.”
But here’s the truth:
Every cloud engineer makes security decisions—often without even realizing it.

Let’s walk through the first choices you make in AWS that quietly shape your app’s security, and why they matter for your day-to-day work and interviews.

When you create your first AWS environment, you start with a VPC (Virtual Private Cloud).

You pick a CIDR block.
You decide how many subnets you need.
You choose which ones are public and which are private.

It feels like a networking exercise, but it’s actually your first security move.

Why it matters:
A public subnet means resources can get traffic from the internet.
A private subnet keeps things internal.

If you put a database in a public subnet, it’s exposed.
If you keep it private, only your app can reach it.

Key move:
Always put sensitive resources (like databases) in private subnets.
Only expose what absolutely needs to be public.

Reference:
VPCs and Subnets in Amazon VPC

Every time you launch an EC2 instance or a load balancer, you attach a security group.

Security groups are like bouncers at the door.
They decide who gets in and who doesn’t.

By default, security groups allow no inbound traffic.
You have to explicitly open ports.

Why it matters:
If you open port 22 (SSH) to the world, anyone can try to log in.
If you only allow your office IP, you cut down on risk.

Key move:
Be specific with your rules.
Only open the ports and sources you need.

Reference:
Security Groups for Your VPC

IAM (Identity and Access Management) is how AWS controls who can do what.

When you create a new user, role, or policy, you’re making a security decision.

It’s easy to give broad permissions like “AdministratorAccess” just to get things working.

But every extra permission is a potential risk.

Why it matters:
If a role has more access than it needs, a mistake or a compromise can do more damage.

Key move:
Follow the principle of least privilege.
Give each user, service, or app only the permissions it needs—nothing more.

Reference:
IAM Best Practices

When you enable logging, you’re deciding what evidence you’ll have if something goes wrong.

CloudTrail records every API call in your account.
VPC Flow Logs capture network traffic details.

It’s easy to skip these at first, but if you don’t turn them on, you’ll have no way to investigate issues later.

Why it matters:
If something suspicious happens, logs are your only way to see what went down.

Key move:
Enable CloudTrail in every region.
Turn on VPC Flow Logs for critical subnets.

Store logs in a secure S3 bucket with limited access.

Reference:
Logging AWS API Calls with AWS CloudTrail

Many AWS services come with default settings that seem convenient, but can open you up to risk.

Why it matters:
Attackers look for defaults.
If you don’t review and adjust them, you’re trusting AWS’s choices—not your own.

Key move:
Always review default settings before launching a new service.
Check for public access, encryption, and permissions.

Security isn’t just about firewalls and encryption.

It’s about the small choices you make every day.

If you build the habit of asking, “Is this secure by default?”
You’ll avoid most rookie mistakes.

And when you’re in an interview, you’ll be able to explain not just what you did, but why you did it.

That’s what sets you apart.

Every AWS project starts with a handful of quiet security decisions.

The best engineers spot them early and build strong habits from day one.

— Mike

Official AWS Documentation Links: