Protect Your Cloud Sandbox: How to Set Up IAM Least Privilege as a Solo Dev
When you create your personal AWS account, the initial setup gives you the Root User credentials. A frequent mistake among new builders is using that root login (or creating an admin user with Administrator Access and *:* wildcards) for everyday development, tutorials, and CLI tasks. If an API key with wildcard permissions ever leaks into a public repository, an automated scanner can compromise your account in minutes.
Adopting the Principle of Least Privilege does not need to be complicated. Here is a practical, three-step guide to locking down your development workflow safely.
Step 1: Lock the Root User Behind MFA and Put It Away
The root user has unrestricted access to billing, resource termination, and account closing. Treat it like a master physical key:
- Log into the AWS Console as the Root user.
- Navigate to IAM → My security credentials.
- Under Multi-factor authentication (MFA), register a hardware key or mobile authenticator app (like 1Password, Bitwarden, or Google Authenticator).
- Verify you have zero active root access keys generated.
- Log out of root and do not use it for day-to-day coding.
Step 2: Create a Scoped Developer User or IAM Identity Center Role
Instead of granting blanket permissions, create an IAM policy restricted to the exact services you are learning—such as Lambda, DynamoDB, and CloudWatch logs.
Here is a minimal IAM policy JSON template for a serverless developer sandbox:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowLambdaAndDynamoDBDev",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionCode",
"lambda:UpdateFunctionConfiguration",
"lambda:GetFunction",
"lambda:InvokeFunction",
"dynamodb:CreateTable",
"dynamodb:DescribeTable",
"dynamodb:PutItem",
"dynamodb:GetItem",
"dynamodb:Scan"
],
"Resource": "*"
},
{
"Sid": "AllowCloudWatchLogsForDebugging",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:FilterLogEvents"
],
"Resource": "*"
}
]
}
Step 3: Use Temporary Credentials Instead of Long-Lived Access Keys
Instead of generating permanent
AKIA... access keys that sit forever in ~/.aws/credentials, switch to short-lived sessions via AWS IAM Identity Center (formerly AWS SSO):- Set up IAM Identity Center in your account (it is completely free to enable).
- Configure your local AWS CLI to use Identity Center:
1
aws configure sso
- When prompted, log in through your browser.
The CLI will fetch temporary security tokens that expire automatically after a few hours:
1
2
# Whenever your session expires, refresh credentials with one command:
aws sso login
If an expired session token ever leaks, it is already invalid—drastically reducing your security exposure.
Key Takeaway for Builders
Security in the cloud is not just an enterprise compliance task; it is an everyday operational habit. Setting up least-privilege policies early demonstrates real architectural maturity on your engineering profile.
Builders: How do you organize your IAM access when testing new AWS services? Do you use SSO, separate sandbox accounts via AWS Organizations, or dedicated dev roles? Let's hear your approach in the comments!
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article