AWS Security Baseline: What to Set Up in a New Account

The root user can do anything, including closing the account, so treat it as a break-glass identity:

1. Use a shared mailbox you control for the root email address, not one person's inbox, so recovery doesn't depend on an employee.
2. Set a long, unique password stored in your password manager.
3. Enable multi-factor authentication, and register a second device or key so one lost phone isn't a lockout.
4. Don't create access keys for the root user. If any exist, delete them.
5. Fill in the alternate contacts for billing, operations and security, so AWS notices reach real people.

Then stop using root. Sign in with it only for the few tasks that require it, and record each use in your operations log.

Give people named, temporary access rather than long-lived keys:

• People. Use a central identity provider with AWS IAM Identity Center, so employees sign in with single sign-on and multi-factor authentication and receive short-lived credentials. Remove someone from the provider and their AWS access ends.
• Roles by job. Start with a small set: administrator (few people), developer, read-only. Grant the narrowest permissions that let the job get done.
• Workloads. Use IAM roles attached to services, not access keys pasted into config. If a key is unavoidable, rotate it and store it in a secrets service.
• No shared logins. Every action should trace to a person or a role.

If you plan to separate development, staging and production, the multi-account setup guide explains why accounts are a stronger boundary than tags.

You can't investigate what you didn't record. Turn on:

• CloudTrail as a multi-region trail, delivering to a dedicated log bucket with restricted access and log file validation enabled.
• Configuration recording so you can see how resources changed over time.
• Threat detection for suspicious activity, using AWS's native service.
• A central findings view. AWS Security Hub aggregates findings from these services and runs standard checks. A third-party platform such as Wiz may fit once you run several accounts and want a view across them, which the Wiz, Prisma Cloud and native tools comparison helps you weigh.

Send alerts somewhere people will see them, such as a monitored email list or chat channel, and name who responds. An alert with no owner is a log line.

A few account-level defaults prevent the classic mistakes:

1. Block public access for S3 at the account level, and make exceptions deliberately, per bucket.
2. Enable default encryption for storage volumes and buckets.
3. Restrict network rules. Avoid opening administrative ports to the whole internet, and put databases in private subnets.
4. Retire the default virtual network if you don't use it, and build your own with clear public and private layers.
5. Keep a data inventory. Note which buckets and databases hold customer data.

To check what you already have, follow the steps in how to find public S3 buckets. Patching matters too: CISA's federal directives required agencies to patch critical vulnerabilities on internet-facing systems within 15 days¹, so decide how quickly your team updates server images and set a reminder.

Security and cost controls share tooling, so set both up together:

• Budget alerts. A sudden bill spike often signals a compromised credential mining cryptocurrency or a runaway job. Alert on both actual and forecasted spend.
• Tagging standard. Require an owner and environment tag on every resource, which speeds incident response and cost reviews.
• Service limits and region control. If you'll only use certain regions, block the rest with an organization policy.
• Backups. Turn on automated backups for databases and test a restore.
• A written baseline. Record what you set up and why, so the next account starts from the same list.

Cost reviews follow naturally from tags, so keep the AWS cost optimization checklist close. Before your first production deploy, run through the production deployment checklist.