AWS Security Audit Checklist: What to Check in Your Account

Most AWS security issues aren't zero-day exploits. They're misconfigurations. Port 22 open to the internet. Root account with no MFA. An S3 bucket that should be private but isn't.

I've written before about the day Liberra first told me about an open port, a public S3 bucket, and MFA missing on my own account... this is the practical version, the actual checks, laid out so you can run every one of them yourself.

AWS surfaces findings across GuardDuty, Security Hub, Trusted Advisor, IAM, and more. By the time you've read through all of it, you don't know what's actually a problem and what's just noise.

IAM: who can get in, and with what

IAM, AWS's system for who can log in and what they're allowed to do, starts with root. Root MFA (multi-factor authentication, a code from your phone on top of your password) is the first thing to check. Root is the very first login created when the account was made, it can do anything, no restrictions. If root MFA is off, turn it on before anything else on this list.

IAM users need MFA too, not just root. Same protection, extended to every person who logs into the console.

IAM access keys older than 90 days. Access keys don't expire on their own, so nobody gets reminded to change them. A key made for a one-time script years ago can still be active today, still doing whatever it was given permission to do. Rotate or deactivate anything past 90 days.

Unused users and unused permissions. Someone who left the team, or a project that ended, can leave behind an active key with full permissions still sitting in IAM. That's as much a risk as a stranger getting in. Same logic applies to permissions on active users, admin access given for one task should still not be attached months later. Check the last-activity column under IAM Users and shrink anything nobody's touched.

Network: what's reachable from outside

Security groups with 0.0.0.0/0 on port 22 (SSH) or 3389 (RDP). That string means open to the entire internet, not your laptop, not your office, anyone. This is how accounts get brute-forced. Restrict the source to your own IP, or use SSM Session Manager, which connects to an instance without needing an open inbound port at all.

Run the same check on database ports. 3306 (MySQL), 5432 (Postgres), 1433 (SQL Server), 6379 (Redis) open to 0.0.0.0/0 is a direct route to your data that skips your application entirely. These should almost never face the open internet.

S3: what's public, and what's recoverable

Public buckets. Check the Access column in S3, anything showing "Public" should be a decision you made on purpose. Turn on Block Public Access at the account level, a single switch that stops any bucket from being made public even by accident.

Versioning off. Versioning keeps every past version of a file, so overwriting or deleting something by mistake stays reversible instead of becoming permanent. It's a checkbox on the bucket's Properties tab.

Encryption off. Server-side encryption means AWS encrypts the data sitting inside the bucket, so a misconfigured permission doesn't hand over plain, readable files. New buckets default to it now, but buckets created before that changed are worth checking.

Logging and alarms: knowing when something happens

CloudTrail off, or only running in one region. CloudTrail records every action taken in the account, by a person or a script. It should cover every region, because anyone probing your account isn't going to do it in the region you check every day.

No CloudWatch alarms. CloudWatch is AWS's monitoring service, it watches numbers and can notify you the moment one crosses a line. Without any alarms set, nobody gets told about a root login, a spike in failed API calls, or a jump in spend, until the bill or the damage shows up later.

GuardDuty disabled. It watches account activity for patterns that look like an actual attack, not just a misconfiguration. Free for the first 30 days, worth turning on.

Databases: what's exposed, what's recoverable

RDS (AWS's managed database service) set to Publicly Accessible. That setting gives the database a direct route from the internet instead of only from inside your own network. It should be "No" unless there's a specific reason it needs to be reached directly.

Snapshots and the final-snapshot setting. RDS can skip creating a backup right before a database is deleted, a checkbox called "skip final snapshot." Left on for anything that matters, a deleted database leaves nothing behind to restore from. Worth checking that automated backups are actually running on a schedule too.

General hygiene: attack surface you forgot about

Unused resources. An EC2 instance nobody's using is still running software that can have a vulnerability, still costing money, and still sitting there unpatched because nobody's watching it. Same for old load balancers, detached EBS volumes (storage drives no longer attached to anything, still billing), and snapshots from projects that ended.

Tagging. Tags are just labels on a resource, who owns it, what project it belongs to, what environment it's in. Without them, a misconfigured bucket or instance blends into everything else in the account instead of standing out to someone.

The problem with doing this manually

You can check all of this yourself. IAM for keys, MFA, and unused users. EC2 for security groups. S3 for bucket permissions. CloudTrail. CloudWatch. RDS. GuardDuty.

That's seven different consoles, and Trusted Advisor adds more findings on top of that, most of them low priority. You end up spending more time reading checks than actually fixing anything.

How to do this in Liberra

Connect your AWS account. Go to the Security page. It pulls findings from IAM, security groups, S3, CloudTrail, RDS, and more into one place, no console-hopping.

Then just ask: "What are the actual security issues I should care about?" It knows your account, so it can tell you what's critical, what's low risk, and what to fix first.

"Any security groups open to the internet?" comes back with the specific group names and rules. "Is my root account secure?" checks MFA and whether root is even being used day to day. "What IAM issues do I have?" surfaces the old keys, the unused users, the missing MFA, all at once.

Reads like this are free, no approval needed, it just explains what it found and why it matters. Fixing something is different, every change waits for your approval before it runs, and the risky ones, opening a port to the world or making something public, ask again every time, even inside the same conversation. Deletes are blocked outright in the code, not a setting you could turn off. That part stays on you, in the console.

Founder, Liberra AI