Securing Your AWS Account in the First 24 Hours (A Checklist)
You just created a new AWS account. Maybe it’s for a personal project, a startup, or a new workload at your company. Whatever the reason, the clock is ticking. An unsecured AWS account is a magnet for attackers, and the damage can happen fast, from cryptomining charges to full data breaches.
The good news? You can dramatically reduce your risk by following a clear set of steps in the first 24 hours. This article is that checklist.
Let’s get started.
Why the First 24 Hours Matter
New AWS accounts are often in their most vulnerable state right after creation. Default settings are permissive, there’s no monitoring in place, and credentials are frequently mishandled. Automated bots constantly scan for exposed keys and misconfigured resources. Stories of developers waking up to five-figure AWS bills after accidentally committing credentials to GitHub are not myths, they happen regularly.
Treating security as a “day one” priority is not paranoia. It’s engineering discipline.
Phase 1: Protect the Root Account
The root account is the single most powerful identity in your AWS environment. It has unrestricted access to everything, and it cannot be limited by IAM policies. Your first actions should be to lock it down.
1. Set a Strong, Unique Password for the Root User
The password you chose during sign-up might have been rushed. Go to the account settings and make sure the root password is long, random, and stored in a reputable password manager. Do not reuse a password from another service.
2. Enable Multi-Factor Authentication (MFA) on the Root Account
This is the single most important step on this entire list. Go to the IAM console, select the root user, and enable MFA. A hardware security key (such as a YubiKey) is the strongest option. A virtual MFA app like Google Authenticator or Authy is a solid alternative. Avoid SMS-based MFA if possible, as it is vulnerable to SIM-swapping attacks.
3. Do Not Generate Access Keys for the Root Account
The root user should never have programmatic access keys. If keys already exist for the root account, delete them immediately. There is no legitimate operational reason to use root access keys.
4. Store Root Credentials Securely and Rarely Use Them
After setting up the root account, you should almost never log into it again. Store the credentials and MFA recovery codes in a secure vault (a physical safe or an encrypted password manager with restricted access). The root account should only be used for the handful of tasks that specifically require it, such as changing the account’s support plan or closing the account.
Phase 2: Set Up Proper IAM Identity Management
Now that root is locked away, you need a secure way for humans and services to interact with the account.
5. Create an IAM Admin User or Use AWS IAM Identity Center
Create a dedicated IAM user (or, even better, use IAM Identity Center if you’re working within AWS Organizations) with administrative permissions. This is the identity you’ll use for day-to-day management — not root.
If you’re managing a single account, an IAM user in the “Administrators” group is sufficient. If you’re managing multiple accounts, invest the time to set up IAM Identity Center (formerly AWS SSO) from the start. It will save you enormous headaches later.
6. Enable MFA for All Human IAM Users
Every person who can log into the AWS console should have MFA enabled. No exceptions. Consider creating an IAM policy that denies all actions until MFA is activated, which encourages users to set it up immediately upon first login.
7. Apply the Principle of Least Privilege
Resist the temptation to give every user or role full admin access. Start with the minimum permissions required for each person or service, and expand only when there is a justified need. Use AWS managed policies as a starting point, but review what they allow. The “PowerUserAccess” policy, for example, is far more permissive than most people realize.
8. Create an IAM Password Policy
Configure a strong password policy for IAM users in your account. Enforce minimum length (at least 14 characters), require a mix of character types, and enable password expiration if your organization requires it. This is found under IAM > Account settings.
Phase 3: Enable Logging and Monitoring
You can’t protect what you can’t see. Visibility into account activity is non-negotiable.
9. Enable AWS CloudTrail in All Regions
CloudTrail records every API call made in your account. It’s your audit trail, your forensic evidence, and your early warning system. Create a trail that applies to all regions and logs to a dedicated S3 bucket. Enable log file validation so you can verify that logs haven’t been tampered with.
This is one of those services that costs very little but provides enormous value. Do not skip it.
10. Enable CloudTrail Log File Integrity Validation
When you set up CloudTrail, enable digest file delivery. This allows you to later verify that no log files were modified or deleted after delivery. In the event of a security incident, you need to trust your logs.
11. Turn On AWS Config
AWS Config continuously monitors and records your resource configurations and evaluates them against rules. Enable it in all regions. It answers questions like: “When did this security group change?” and “Is this S3 bucket publicly accessible?”
You can start with the AWS Config conformance packs, which provide pre-built rule sets for common compliance frameworks.
12. Enable Amazon GuardDuty
GuardDuty is a threat detection service that analyzes CloudTrail logs, VPC flow logs, and DNS logs to identify malicious activity. It can detect things like cryptocurrency mining, compromised credentials, and unusual API calls. Enabling it takes about 30 seconds, and it starts working immediately.
There is a 30-day free trial, and the ongoing cost is typically very reasonable relative to the protection it provides.
13. Set Up Billing Alerts and Anomaly Detection
Security incidents often show up as billing anomalies first. Go to the Billing and Cost Management console and enable the following:
AWS Budgets: Create a monthly budget with a threshold alert. Even a simple “notify me if my spend exceeds $50” can save you from a surprise bill.
Cost Anomaly Detection: This service uses machine learning to detect unusual spending patterns and alert you automatically.
An unexpected spike in EC2 or Lambda charges could be the first sign that someone is using your account for unauthorized purposes.
Phase 4: Secure Your Network Defaults
Every new AWS account comes with default networking resources that are more permissive than you might want.
14. Review and Restrict Default Security Groups
Every VPC comes with a default security group that allows all outbound traffic and allows all inbound traffic from resources assigned to the same security group. While this isn’t publicly open, it’s more permissive than most workloads need. Adopt the practice of creating custom, purpose-specific security groups and never attaching the default security group to resources.
15. Delete or Ignore the Default VPC (Use Custom VPCs Instead)
The default VPC in each region comes with public subnets and an internet gateway already attached. It’s designed for convenience, not security. For any real workload, create a custom VPC with a deliberate network design — private subnets for backend services, public subnets only where necessary, and proper route table configuration.
You don’t necessarily need to delete the default VPC (some AWS services expect it to exist), but make a rule to never deploy production workloads into it.
16. Block Public Access to S3 at the Account Level
One of the most common AWS security headlines involves publicly exposed S3 buckets. AWS now provides an account-level setting called “S3 Block Public Access.” Enable all four options at the account level. If a specific bucket later needs public access (for static website hosting, for example), you can override it deliberately for that one bucket. The default should be locked down.
Phase 5: Establish Account-Level Protections
These steps create safety nets that protect you across the entire account.
17. Enable EBS Default Encryption
Navigate to the EC2 console and enable default EBS encryption for each region you plan to use. This ensures that every new EBS volume is encrypted automatically, without requiring the person launching the instance to remember to check a box. You can use the AWS-managed key or specify a customer-managed KMS key.
18. Configure Account-Level Contacts
Under Account Settings, make sure the security, billing, and operations contact fields are filled in with valid email addresses. AWS uses these contacts to reach you in the event of abuse notifications or security issues. If these emails go to an unmonitored inbox, you might miss a critical warning.
19. Enable AWS Security Hub (Optional but Recommended)
Security Hub aggregates findings from GuardDuty, Config, IAM Access Analyzer, and other services into a single dashboard. It also runs automated security checks against industry benchmarks like CIS AWS Foundations. If you’ve already enabled the services listed above, Security Hub ties everything together and gives you a centralized security posture score.
20. Enable IAM Access Analyzer
IAM Access Analyzer helps you identify resources in your account that are shared with an external entity — for example, an S3 bucket policy that grants access to another AWS account, or an IAM role that can be assumed externally. Enable it in each region. It runs continuously and alerts you when it finds unintended external access.
Phase 6: Plan for the Worst
Security isn’t just about prevention. You also need to prepare for the possibility that something goes wrong.
21. Document Your Incident Response Plan
Even a simple one-page document is better than nothing. Answer these questions in advance:
Who is responsible for responding to a security alert?
How do we revoke compromised credentials?
Where are our logs stored and how do we access them?
Who do we contact at AWS for support?
Under pressure during an incident is the worst time to figure out these answers.
22. Know How to Contact AWS Support
If your account is compromised, you may need to contact AWS quickly. Make sure you know how to open a support case, and consider whether your current support plan (Basic, Developer, Business, or Enterprise) provides the response time you’d need in an emergency. Business-level support or above gives you 24/7 access to Cloud Support Engineers.
23. Create an Emergency “Break Glass” Procedure for Root Access
Since you’ve locked down root access (as described in Phase 1), document the procedure for accessing it in an emergency. Who has access to the password vault? Where is the MFA device stored? What approvals are needed? This should be written down, tested, and reviewed periodically.
Final Thoughts
None of these steps are difficult. Most take less than five minutes. But together, they form a security foundation that will protect you from the vast majority of common AWS threats.
The most expensive security incident is the one you could have prevented with ten minutes of configuration on day one. Don’t learn that lesson the hard way.
Bookmark this checklist. Share it with your team. Run through it every time a new account is created. Your future self will thank you.