# 5 AWS settings attackers hope you skipped (10-minute check)

> Five account-level AWS settings that close the most common doors: S3 Block Public Access, IMDSv2 by default, root MFA, an all-Region CloudTrail trail and IAM Access Analyzer.

- Published: 2026-10-22
- Topics: AWS, Hardening, Baseline
- Canonical page: https://thesecguy.com/notes/5-aws-settings-attackers-hope-you-skipped/
- Publisher: The Sec Guy (https://thesecguy.com)

**Short answer:** Five account-level AWS settings close the doors attackers find open most often: S3 Block Public Access at the account level, IMDSv2 as the default for new EC2 instances, MFA on the root user, one CloudTrail trail across all Regions, and IAM Access Analyzer. Each takes about two minutes, and you do them once per account.

---

These five settings won't make an AWS account secure on their own. But they close the doors I see left open most often, and each one takes about two minutes. Do them once per account.

## 1. S3 Block Public Access, at the account level

Since **April 2023**, every *new* bucket gets Block Public Access turned on and ACLs turned off by default. ([AWS](https://aws.amazon.com/about-aws/whats-new/2023/04/amazon-s3-security-best-practices-buckets-default))

The catch: buckets created **before** that keep whatever settings they had. Older accounts are exactly where the forgotten public bucket lives.

**Do:** S3 → *Block Public Access settings for this account* → turn on all four options. If something genuinely needs to be public (a static website), serve it through CloudFront with Origin Access Control instead.

## 2. Make IMDSv2 the default for new EC2 instances

IMDSv1 answers any request from inside the instance, which is why a simple SSRF bug in a web app can be turned into "read this server's AWS credentials". IMDSv2 needs a session token first, which blocks most of those tricks.

Since **March 2024** you can set IMDSv2 as the default for all new instances in a Region with one account setting. It doesn't change existing instances. ([AWS](https://aws.amazon.com/about-aws/whats-new/2024/03/set-imdsv2-default-new-instance-launches))

**Do:** EC2 → *Settings* → *Data protection and security* → IMDS defaults → require IMDSv2, in every Region you use. Then watch the `MetadataNoTokenRejected` metric before you switch older instances over.

## 3. Root user: MFA on, no access keys

The root user can do everything, and IAM policies can't limit it. It should be used almost never.

**Do:** sign in as root once → *Security credentials* → add MFA (a passkey or hardware key if you can) → delete any root access keys. Then put the root email on a shared, monitored mailbox, not one person's inbox.

## 4. One CloudTrail trail, all Regions

CloudTrail's *Event history* only keeps **90 days** of management events. Breaches are often found later than that. A trail sends events to S3 for as long as you keep them.

**Do:** CloudTrail → *Create trail* → apply to all Regions → deliver to an S3 bucket in a separate, locked-down account if you can, with versioning and Object Lock.

## 5. IAM Access Analyzer for external access

Access Analyzer reads your resource policies and lists everything shared **outside your account or organization**: S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues and more.

**Do:** IAM → *Access Analyzer* → create an *external access* analyzer (one per Region). Review every finding. Anything you don't recognize is the first thing to fix.

---

**Next step:** check your buckets for the six ways a "private" bucket still leaks. The free field guide below walks through each one with the exact CLI command.

**Sources**
- AWS What's New, Apr 2023: [S3 applies two security best practices to new buckets by default](https://aws.amazon.com/about-aws/whats-new/2023/04/amazon-s3-security-best-practices-buckets-default)
- AWS What's New, Mar 2024: [Set IMDSv2 as default for all new instance launches](https://aws.amazon.com/about-aws/whats-new/2024/03/set-imdsv2-default-new-instance-launches)