Stop Using Your Root User: A Practical Guide to AWS IAM Roles & Least Privilege

A practical tutorial on AWS IAM security using the real world architecture of the CoverGen project. This post demonstrates how to stop using the Root User and implement a secure access model. Learn how to create an Admin user and a restricted QA Tester user with direct policy attachments, ensuring distinct access control between Staging and Production environments

Debjoty Mitra

Published Dec 30, 2025

Last modified Dec 30, 2025

If you have just started your cloud journey, you probably logged in using your email and password, spun up an EC2 instance, and felt like a wizard. But that email login is your Root User, and using it for daily tasks is like cutting bread with a chainsaw. Powerful, but dangerous if you slip.
﻿
Today I will help you to move away from the Root User and implement a secure, role based access structure using AWS IAM (Identity and Access Management). To demonstrate this, I will use a real world scenario from a project of mine called CoverGen.
The Architecture: CoverGen (Initial)Before touching the AWS console, let’s look at the very initial architecture diagram of my project. Things were very basic and I used the AWS account as the root user. It seems simple, right? But there is a big issue. The Root User has unlimited power. If I accidentally paste my Root access keys into a public GitHub repository (which happens more often than you think), a hacker doesn't just get access to my EC2 instances. They get my billing info, they can delete my account, and they can spin up 1000 Bitcoin mining servers in seconds :)
﻿
Furthermore, I want to hire a QA Tester to help me test the Staging environment. I don't want to give them my Root password. I also don't want them accidentally shutting down the Production server in  region-2  when they were just trying to test  region-1 .
The Solution: Secure ArchitectureTo solve this, I have used this architecture. I am now using the Root user and create two specific personas:
The Admin: Me (but safer). Has (almost) full access but is not the Root user.
The QA Tester: A restricted user who can only start and stop the Staging server.
Here is now what my architecture looks like:
﻿
Here is a step-by-step guide on how to do implement this:
Step 1: Create the Admin User (Stop Using Root!)The first rule of AWS is: Create an Admin user, then lock away the Root credentials.
Log in as Root one last time.
Go to IAM > Users > Create user.
Name it  Admin .
Attach the  AdministratorAccess  policy directly.
Enable MFA (Multi-Factor Authentication) for this user.
﻿
Now, log out of Root and log in as  Admin . You can now do everything the Root user could do, but if this account gets compromised, you can use the Root account to delete it. You can't delete a compromised Root account!
Step 2: The QA Tester (Direct Permission)For this specific implementation of CoverGen, we want to keep things simple. Instead of creating complex roles that the user has to switch into, we will attach the permissions directly to the QA Tester's account. This means as soon as they log in, they have exactly the access they need. No extra steps required.
Step 2.1: Create the QA UserGo to IAM > Users > Create user.
Name the user  covernge-qa-tester .
Select I want to create an IAM user.
Choose Custom password so you can log in as this user later to test.
﻿
Step 2.2: Create the PolicyWe need a policy that defines exactly what the QA Tester is allowed to do. In our case, they need to Start and Stop the staging server in  region-1 .
Go to IAM > Policies > Create Policy and use this JSON:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:DescribeInstances"
            ],
            "Resource": "arn:aws:ec2:YOUR-REGION:YOUR_ACCOUNT_ID:instance/i-xxxxxxxxx"
        }
    ]
}
Important:
Replace  i-xxxxxxxxx  with the actual Instance ID of your  covergen-staging  server.
We included  DescribeInstances  so the QA Tester can actually see the server list in the AWS console.
Step 2.3: Attach and FinalizeName this policy  SpecificEC2StartStopAccess .
Complete the user creation process.
Now, if you look at the  covergen-qa-tester  user summary, you will see the policy listed directly under the Permissions tab. There is no "Role" involved here. The permissions belong permanently to this user.
﻿
By attaching the policy directly, we created a seamless experience for the QA Tester. They don't need to understand what an "IAM Role" is or how to switch contexts. They just log in and do their job. While "Assuming Roles" is often used for cross-account access or temporary security, Direct Policy Attachment is a powerful and simple way to manage permissions for dedicated team members in a single account like CoverGen.