How to Secure Your AWS Cloud Account with IAM and MFA: Complete Guide
By Braincuber Team
Published on March 3, 2026
We audited a D2C brand's AWS account last quarter. The founder had been using the root user for everything — launching EC2 instances, uploading to S3, even testing Lambda functions. One compromised password away from someone deleting their entire infrastructure. No MFA. No IAM users. The root access keys were hardcoded in a GitHub repo that had been public for 7 months. This beginner guide walks you through locking down your AWS account the right way — step by step, before something like this costs you $43,000 in unauthorized compute charges. *(Yes, we've seen that exact number.)*
What You'll Learn:
- How to lock down your root user and when you actually need it
- Creating an IAM user with AdministratorAccess for daily work
- Enabling MFA with Google Authenticator on both root and IAM accounts
- The AWS Shared Responsibility Model — what AWS protects vs. what you protect
- Writing inline IAM policies to restrict S3 bucket permissions
- Testing permission policies to verify deny rules actually work
Why Your Root User Is a Ticking Time Bomb
When you create an AWS account, the first identity created is the root user. Full, unrestricted control. It can delete resources, change ownership, close your entire AWS account. Using it for everyday tasks is like leaving your front door unlocked with a sign that says "come in."
AWS recommends using root only for a handful of account-level actions. Everything else goes through IAM users.
Root = Master Key
The root user has unlimited power. It can delete billing info, close the account, and change ownership. One compromised credential and your entire infrastructure is gone. AWS's own documentation says: do not use root for daily tasks.
IAM = Controlled Access
IAM users get specific permissions you define. Admin access, read-only, S3-only — you control the blast radius. If credentials leak, you revoke that one user. You don't lose the entire account.
MFA = Second Lock
Even if someone steals your password, they can't get in without your phone. Google Authenticator generates a time-based code that changes every 30 seconds. Enable it on both root and IAM. Non-negotiable.
Least Privilege = Sanity
Give users only the access they need. Your developer needs S3 upload access? Give them S3 upload. Not AdministratorAccess. Not PowerUserAccess. Exactly what they need and nothing more.
Root User vs. IAM User — When to Use Which
| Factor | Root User | IAM User |
|---|---|---|
| Access level | Unrestricted — everything | Customizable per-policy |
| Use for daily tasks | Never | Always |
| Billing changes | Yes — required | No access by default |
| Close AWS account | Yes — only root can | Cannot |
| Blast radius if compromised | Total — entire account | Limited to assigned policies |
| MFA support | Yes — enable immediately | Yes — enable immediately |
The 10-Step Security Setup Walkthrough
Follow these steps in order. Skip one and you're leaving a gap that someone will find. We've seen it happen 14 times in the last 18 months with D2C brands running on AWS.
Access the IAM Console
Open the AWS Management Console. Type IAM in the search bar and select it. This takes you to the IAM dashboard where you manage users, roles, and policies. Bookmark this page — you'll be back here constantly.
Create an IAM User for Daily Work
Click Users in the left sidebar, then Create user. Enter a username (e.g., adminuser). Check "Provide user access to the AWS Management Console". Scroll down and either set a custom password or let AWS generate one. Click Next to move to permissions.
Attach AdministratorAccess Policy
On the permissions page, select Attach existing policies directly. Search for and check AdministratorAccess. This gives the IAM user full admin privileges — everything except the rare root-only tasks like billing changes and account closure. Click Create user. Sign out of root. Sign in with this IAM user from now on.
Enable MFA on the Root Account
Sign in as root. Click your account name at the top-right corner and select Security Credentials. Click Assign MFA device. Select Virtual MFA device (Google Authenticator or Authy). Open the authenticator app on your phone, tap the + button, scan the QR code, and enter the two consecutive codes AWS displays. Once verified, MFA is live on root.
Enable MFA on Your IAM User
Sign in as the IAM user you just created. Go to Security Credentials the same way. Assign a Virtual MFA device and repeat the Google Authenticator setup. Both root and IAM accounts need MFA. Skipping the IAM user is the #1 mistake we see — people think root-only MFA is enough. It isn't.
Understand the Shared Responsibility Model
AWS protects the infrastructure — physical security, hardware, networking, facilities. You protect your stuff — data, user accounts, application configurations, encryption settings, and access policies. AWS calls this "Security OF the Cloud" vs. "Security IN the Cloud." If your S3 bucket is public, that's on you, not AWS.
Review RDS and S3 Responsibility Splits
For RDS: AWS automates database patching and maintains storage disks. You manage in-database users, roles, security groups, and encryption settings. For S3: AWS ensures encryption is available and keeps data separated. You define bucket policies, review configuration settings, and manage IAM permissions. If your database security group allows 0.0.0.0/0 on port 3306, AWS won't stop you.
Create an Inline Policy to Restrict S3 Permissions
Go to IAM > Users, select the user. Click Add permissions > Create inline policy. Select S3 as the service. Under Actions, find DeleteObject and set it to Deny. Under Resources, add the bucket ARN: arn:aws:s3:::your-bucket-name/*. Save the policy. This lets the user upload and view files but blocks deletion — exactly what you want for a developer who shouldn't be nuking production data.
Test the Permission Policy
Sign in as the restricted user. Navigate to S3 and open the target bucket. Upload a file — it should succeed. Now try deleting that same file. You'll see "Failed to delete objects". That's the Deny policy working. Always test permissions after creating them. We've seen policies that looked correct in the JSON editor but had the wrong resource ARN — granting access to the wrong bucket entirely.
Audit and Repeat for All Team Members
Repeat steps 2-3 for every team member who needs AWS access. Give each person their own IAM user — never share credentials. Use IAM Access Analyzer (built into the IAM console) to review what permissions are actually being used. We typically find 40-60% of granted permissions go unused. Remove what's not needed. Fewer permissions = smaller attack surface.
The S3 Deny Policy JSON
Here's the exact IAM inline policy that blocks DeleteObject on a specific S3 bucket. Copy this, replace the bucket name, and attach it to any user who should have read/write but not delete access.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyS3Delete",
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::your-bucket-name/*"
}
]
}
Shared Responsibility Model Breakdown
Stop assuming AWS handles everything. They don't. Here's the exact split for the two services D2C brands use most.
| Responsibility | RDS (AWS Does) | RDS (You Do) |
|---|---|---|
| Patching | Automates OS and DB patching | N/A |
| User management | N/A | Manage DB users, roles, permissions |
| Network access | N/A | Security groups, ports, IP rules |
| Encryption | Provides encryption options | Configure and enable encryption |
| Responsibility | S3 (AWS Does) | S3 (You Do) |
|---|---|---|
| Storage | Virtually unlimited capacity | N/A |
| Data isolation | Separates customer data | N/A |
| Access control | N/A | Bucket policies, IAM roles |
| Configuration | N/A | Public/private settings, versioning |
The Public Bucket Disaster
We've seen 3 D2C brands in the last year with publicly accessible S3 buckets containing customer PII — names, addresses, order histories. AWS won't block this for you. You have to check S3 > Permissions > Block public access and make sure it's enabled on every bucket. One brand's data was indexed by Shodan for 11 months before they noticed.
Root Access Keys = Live Grenade
Never create access keys for the root user. If they leak — in a GitHub commit, a Slack message, a contractor's laptop — someone can programmatically access every resource in your account. Create access keys only for IAM users with scoped permissions. And rotate them every 90 days. AWS IAM Access Advisor tells you which keys haven't been used — delete the idle ones.
Frequently Asked Questions
Can I recover my AWS account if I lose root MFA access?
Yes, but it's painful. You'll need to contact AWS Support, verify your identity through the email associated with the root account, and go through a manual recovery process that can take 24-72 hours. Store your MFA recovery codes in a secure password manager to avoid this.
Should I use IAM users or IAM Identity Center (SSO)?
For teams under 10 people with a single AWS account, IAM users work fine. Once you have multiple accounts or more than 15 team members, switch to IAM Identity Center (formerly AWS SSO) for centralized access management and temporary credentials.
Is Google Authenticator the best MFA option for AWS?
It's the easiest to set up. For higher security, use a hardware key like YubiKey — it's phishing-resistant and doesn't rely on your phone battery. Google Authenticator works well for most D2C teams. Just make sure you back up the QR code during setup.
How often should I rotate IAM access keys?
Every 90 days. AWS IAM Access Advisor shows you when keys were last used. If a key hasn't been used in 60+ days, deactivate it first, wait a week to confirm nothing breaks, then delete it. Unused keys are just attack surface sitting there waiting.
Does enabling MFA cost anything on AWS?
No. Virtual MFA with Google Authenticator or Authy is completely free. Hardware MFA keys like YubiKey cost $25-50 each but are a one-time purchase. There is no recurring AWS charge for MFA on any account type.
Is Your AWS Account Actually Secure?
We've audited 47 AWS accounts for D2C brands in the last 18 months. 31 of them had root access keys floating around in code repos, shared Slack channels, or contractor laptops. 22 had no MFA on root. Run this checklist. If you fail more than 2 items, your account is a breach waiting to happen. Let us audit it before someone else does.