Every AWS security audit I run follows the same sequence. Not because security is formulaic, but because the highest-risk findings are almost always in the same places.
This is the checklist I use. It covers the findings that appear in 80% of the accounts I review and the ones that carry the most risk when they’re present.
Start here: the root account
Before anything else, check the root account.
Does the root account have an MFA device? If not, this is your top priority. The root account can do anything in AWS — delete the account, remove all audit logs, transfer ownership. Without MFA, anyone who knows the email and password has full control.
Fix: Log in as root → Account → Security credentials → Add MFA device. Takes 5 minutes.
Does the root account have an access key? It shouldn’t. Root access keys are a critical finding. They can’t be scoped or restricted — they have unrestricted access to everything.
Fix: IAM → Security credentials (as root) → Access keys → Delete. If something is using that key, find it and replace it with an IAM role or least-privilege user before deleting.
Is root used for daily operations? If CloudTrail shows regular root account logins for operational tasks, that’s a workflow problem. Root should only be used for account-level actions that can’t be delegated.
IAM: identity and access
Are there IAM users with long-term access keys? Access keys don’t expire. Keys that are more than 90 days old without rotation are a risk — especially for users who may have left the organization.
Check: IAM → Credential Report → look at access_key_1_last_rotated column.
Fix: Rotate or delete unused keys. For active use cases, migrate to IAM roles + short-lived credentials via AWS SSO or STS.
Does anyone have AdministratorAccess who doesn’t need it?
The most common finding. It’s given during setup (“I’ll tighten it later”) and never revisited.
Check: IAM → Policies → AdministratorAccess → see attached entities.
Fix: Replace with least-privilege policies for each user’s actual job function.
Are there inline policies on IAM users? Inline policies are attached directly to a user and invisible from the policy list. They’re easy to miss and often over-permissive.
Check: IAM → Users → [user] → Permissions tab → inline policies.
Are service accounts using IAM users instead of IAM roles? Any service, application, or Lambda function that’s authenticating with long-lived access keys (IAM user credentials) should be using IAM roles instead. Roles issue short-lived credentials that rotate automatically.
S3: object storage
Are any buckets publicly accessible? Check both the account-level S3 Block Public Access setting and individual bucket policies.
Account-level check: S3 → Block Public Access settings for this account.
Even with account-level protection enabled, some buckets may have legacy ACLs or policies that override it. Run: aws s3api list-buckets --query 'Buckets[].Name' and check each against Security Hub findings.
Do buckets with sensitive data have server-side encryption enabled? SSE-S3 is free and easy to enable. Buckets created before it became the default (late 2022) may not have it.
Are there S3 lifecycle policies? Buckets that are growing without lifecycle policies will accumulate indefinitely. Check cost-relevant buckets for policies that transition to cheaper storage classes or delete old objects.
CloudTrail: audit logging
Is CloudTrail enabled in all regions? This is the most common CloudTrail finding. Many accounts enable CloudTrail in their primary region but not in others. Resources in unmonitored regions generate no audit trail.
Check: CloudTrail → Trails → verify multi-region trail is enabled.
Fix: Create a multi-region trail. Cost is negligible ($2–5/month for most accounts).
Is the CloudTrail S3 bucket protected? If someone can delete or modify your CloudTrail logs, they can cover their tracks after a breach. The CloudTrail S3 bucket should have MFA Delete enabled, versioning on, and a bucket policy that only allows CloudTrail to write to it.
Are management events being logged?
Management events (API calls like CreateUser, AttachPolicy, DeleteBucket) are what you need for a meaningful audit trail. Data events (S3 object reads/writes) are optional and expensive — but worth enabling on buckets with sensitive data.
EC2 and VPC: network security
Are there security groups with 0.0.0.0/0 on sensitive ports? Port 22 (SSH) or 3389 (RDP) open to the internet is the most common network finding. These are almost always left over from debugging sessions.
Check: EC2 → Security Groups → filter by inbound rules with source 0.0.0.0/0.
Are EC2 instances using IMDSv2? IMDSv2 (Instance Metadata Service version 2) requires a session token, preventing SSRF attacks from accessing instance metadata. IMDSv1 is vulnerable.
Fix: aws ec2 modify-instance-metadata-options --instance-id <id> --http-tokens required
Is VPC Flow Logs enabled? Flow Logs capture network traffic metadata for your VPCs. Essential for incident response — without it, you can’t answer “where did that traffic come from?” after the fact.
Security Hub: the automated baseline
If Security Hub isn’t enabled, enable it. It runs continuously against CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices, surfacing findings automatically.
Check: Security Hub → Summary → look at the score and finding counts by severity.
The first run typically surfaces 50–200 findings in an account that hasn’t been reviewed. Most are low or medium severity. Focus on Critical and High first.
What comes after the checklist
A security audit produces a findings report — prioritized by risk, with remediation steps and effort estimates. Most findings are fixable in a few hours to a few days. Some require architectural changes that are phased over months.
The goal isn’t a perfect score. It’s knowing where your actual risk is and having a plan to address it.
Get a second set of eyes
If you want an independent audit of your AWS account security, I run a flat-fee engagement: IAM, S3, CloudTrail, VPC, Security Hub, and root account hygiene. Deliverable is a prioritized findings report with remediation guidance.
Contact me or email nick@coldsmokeconsulting.com. I’ll provide a CloudFormation template for read-only access — no manual IAM setup required.
Nick Allevato is an AWS Certified Solutions Architect Professional with 20 years of infrastructure experience. He runs Cold Smoke Consulting, an independent AWS consulting practice.