five aws settings that stop most cloud breaches

most aws breaches aren't hacks, they're settings someone never flipped

every time you read one of those "millions of records exposed" headlines, the postmortem is almost never some genius zero day. it's usually a bucket left public, a root account with no mfa, or an access key that's been sitting in a github repo since 2021. aws gives you the tools to stop basically all of that, they're just off by default or buried in a console nobody visits after setup day. here's the five that matter most, and how to actually check them on your own account.

turn on cloudtrail, everywhere

cloudtrail logs every api call made in your account. who logged in, what they created, what they deleted, from what ip. without it, when something goes wrong you're guessing. with it, you can reconstruct exactly what happened.

the mistake people make is turning it on in one region and forgetting the rest. attackers know this and specifically look for regions you don't normally use. you want a trail that covers all regions and writes logs to an s3 bucket you don't touch for anything else, ideally with log file validation turned on so nobody can quietly edit the history.

go to cloudtrail in the console, check if you have an active trail marked "all regions" and "read/write events: all." if you see "no trails," that's not a gap, that's a blindfold you put on yourself.

block public s3 at the account level, not just the bucket

s3 buckets have been the source of more accidental data leaks than almost anything else in cloud history. the fix isn't remembering to check every bucket's permissions one by one, it's flipping a single account-wide switch called block public access.

this setting overrides any individual bucket policy or acl that tries to make something public, even if a future teammate misconfigures one by accident. go to s3, then "block public access settings for this account," and turn all four options on unless you have a documented, specific reason not to (like actually hosting a public static website, which should live in its own carefully scoped account anyway).

require mfa on every single user

a password alone is one phishing email away from being useless. mfa is the cheapest, highest impact security control that exists, and aws makes it free to enable, there's no excuse here.

check this under iam, credential report. pull the report and look at the mfa_active column for every user. root account included, actually root account especially, since it can't be restricted by iam policies. if you see any "false" next to a human user, that's your next ten minutes.

for extra credit, set up an iam policy that denies most actions unless mfa was used in that session. it stops a leaked password from being enough on its own.

stop using long lived access keys, use roles

an access key pair that never expires is basically a spare house key taped under the doormat. if it leaks in a log, a laptop backup, or a public repo, it works forever until someone notices and rotates it, which might be never.

roles solve this by handing out short lived, automatically rotating credentials instead. an ec2 instance, a lambda function, or a person logging in through sso can assume a role and get temporary permissions that expire in an hour or so. no static secret sitting around waiting to be found.

if you're auditing your own setup, go to iam, users, and look for anyone with access keys older than 90 days. that's a strong sign something should be migrated to role based access instead.

turn on guardduty for the stuff you didn't think to check

the first four settings close known doors. guardduty is there for the ones you didn't know existed. it's aws's managed threat detection service, it watches cloudtrail, dns logs, and vpc flow logs for patterns like credential compromise, crypto mining, or traffic to known bad ips, and it costs nothing to turn on for a baseline tier.

go to guardduty in the console, click enable, and let it run for a week before you tune anything. it will quietly flag things you'd never catch manually, like an ec2 instance suddenly talking to an ip range associated with command and control traffic.

the takeaway

none of this requires a security team or a big budget, it's five checkboxes you can walk through this afternoon. cloudtrail so you have a record, blocked public s3 so nothing leaks by accident, mfa so stolen passwords aren't enough, roles instead of static keys so there's nothing long lived to steal, and guardduty watching for whatever slips through. go check your own account against this list before you read the next breach headline and realize it was your account they were talking about.