DEV Community: Jonathan Vogel

Access Denied: What Every AWS Beginner Gets Wrong About IAM

Jonathan Vogel — Wed, 20 May 2026 19:45:19 +0000

The IAM mental model I wish someone had drawn on a whiteboard for me when I was starting out with AWS.

If you want a video to follow along with this blog, you can find it on the AWS Developers Youtube Channel

I spun up a Lambda function and tried to have it read from an S3 bucket only to get Access Denied.

This wasn't a typo or misconfiguration. I just straight up didn't understand IAM. So I did what every beginner does, I attached AdministratorAccess, the error went away, and I moved on.

What I didn't think about at the time is that I'd just given that Lambda function permission to do anything in my account. Delete databases. Create resources that cost money. Access data across every service it had no business touching. All because it needed to read from one S3 bucket.

I talk to students and developers getting started with AWS all the time, and this is the pattern. Everything goes smooth when you follow the tutorial. When it comes to implementing your own project, you run into a permission blocker. You come up with an easy solution. You slap on AdministratorAccess and now you have a security problem you don't even know about. The Access Denied error was actually trying to help you. It was telling you exactly which permission was missing. You just didn't know how to read it yet.

This post is the mental model I wish I'd had. Once you understand what I'm about to lay out, Access Denied stops being a wall and starts being a useful message.

What IAM Actually Is

IAM stands for Identity and Access Management. Not sure if that name really helps you, let me put it differently.

IAM is the bouncer at the door of every AWS service. Every time anything happens in your account, whether you click a button in the console, your code calls an API, or a Lambda function tries to read from a database, IAM checks two things.

Who are you?
Are you allowed to do this?

If the answer to either question is "no," you get Access Denied. Those two questions are the entire foundation. The rest of this post is about how they get answered.

Users, Roles and Policies

Three concepts make up the whole model when you're getting started.

IAM Users = Employee Badge

An IAM user is a persistent identity. It represents a person who needs to log into the console or use the CLI. It has long-term credentials, a username and password for the console, or access keys for programmatic access.

Think of it like an employee badge. It's yours, it has your name on it, and it works every day until someone revokes it.

IAM Roles = Visitor Pass

An IAM role is temporary. It doesn't belong to anyone permanently. Instead, it gets assumed (borrowed) by whoever needs it at that moment. AWS gives the assumer temporary credentials that expire automatically.

Think of it like a visitor pass at an office. You check in, you get a badge, it works for a few hours, then it stops working.

Rule of thumb. If it's a person logging in, that's a user. If it's a service doing something, a Lambda function, an EC2 instance, another AWS account, that's a role. Roles are how Lambda functions access S3, how EC2 instances talk to DynamoDB and how one AWS account talks to another. The credentials are always short-lived, so there's nothing sitting around that could be stolen.

Policies = Permission Slip

A policy is a JSON document that says "this identity is allowed to do these actions on these resources." You attach policies to users or roles. Without a policy attached, an IAM identity can do nothing. You have to explicitly grant every single permission.

A simple policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

This says: allow reading objects from one specific S3 bucket. Nothing else.

The Mental Model

A user or role is who you are. A policy is what you're allowed to do. Identity plus permission. That's the whole thing.

The Least Privilege Principle

This is the one concept that makes everything in IAM make sense. It applies across all of computer security, not just cloud.

Least privilege means: give every identity only the permissions it needs to do its job. Nothing more.

You already saw the wrong version in my story. I gave a Lambda function permission to do everything because it needed to do one thing. AdministratorAccess makes the error go away, but it also means anything in your account can do anything to your account.

That's like giving every employee in a company a key that opens every door because they needed to open one.

The right approach is to figure out exactly which actions your identity needs, on exactly which resources, and grant only that. That Lambda function I mentioned at the start? The policy it actually needed:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

One action. One bucket. If that function ever gets compromised, the damage is limited to reading objects from one bucket, not your entire account.

"But figuring out exact permissions sounds like a lot of work." It can take some extra minutes upfront. AWS gives you a tool called IAM Access Analyzer that looks at what your identity actually used over a period of time and generates a scoped policy based on real activity. You let your service run, then Access Analyzer tells you what it actually needed. You don't have to guess.

Your IAM Starter Checklist

I share this with every student setting up a new AWS account. Bookmark it and come back at the end of every project.

1. Lock down your root user

When you first create an AWS account, you start as the root user. Root can do anything, including things no other identity can do, like closing the account entirely. It's the "break glass in case of emergency" identity.

Enable MFA on root immediately. That's multi-factor authentication, so even if someone gets your password, they still can't log in without your second factor. Then stop using root for daily development.

2. Set up daily access

For day-to-day work, create a separate identity. If you're learning on a personal account, an IAM user with MFA works fine. If you're working with a team or thinking about production, IAM Identity Center is the current best practice. It gives you temporary credentials and scales well when you add team members.

3. Use roles for services

When you build things, Lambda functions, EC2 instances, anything running code, use roles. They don't need long-lived access keys. They need roles with temporary credentials.

4. Start with managed policies, then tighten

AWS has pre-built managed policies for common use cases. They're a reasonable starting point when you're learning. As you understand what your application actually needs, narrow the permissions down. You don't have to write perfect policies on day one, but you should be moving toward least privilege over time.

5. Never put access keys in your code

Putting keys directly in source code is a bad idea. They should never be in config files or any variable pushed to Git. Use roles instead. If you ever accidentally push AWS keys to a public repo, rotate them immediately. Bots scan for exposed keys within minutes.

Quick Reference

Step	What to Do	Why
Lock down root	Enable MFA, stop using root daily	Root = key that opens all doors
Set up daily access	IAM user (learning) or Identity Center (teams)	Limits root exposure
Use roles for services	Lambda, EC2 get roles, not users	Temporary credentials, nothing to steal
Start managed, then tighten	Use AWS managed policies first	Don't guess permissions on day one
No keys in code	Use roles, not hardcoded credentials	Bots scan for exposed keys within minutes

What I Tell Students Who Are Afraid of IAM

Every time someone tells me "I just attach AdministratorAccess because IAM is confusing," I tell them the same thing. The confusion comes from not having the mental model. Now you have it.

Users are people. Roles are services. Policies define what any of them can do. Least privilege means only what you need, nothing more. And Access Denied is IAM telling you exactly which permission is missing. Read the error. It's trying to help you.

Next time you get Access Denied, and you will, don't reach for AdministratorAccess. Check the policy. You've got this.

The best time to learn IAM was when you created your AWS account. The second best time is right now.

Click here for more info on AWS Free Tier.

You Deleted Everything and AWS Is Still Charging You

Jonathan Vogel — Fri, 13 Mar 2026 18:33:50 +0000

The AWS cleanup checklist I wish someone had given me when I was starting out with cloud.

I talk to computer science students regularly. There's one fear that comes up more than almost anything else: "I am worried about spinning up stuff in the cloud and charges getting out of control."

I used to feel this. Some time ago, I set up a relational database on RDS, some virtual machines as EC2 instances, an S3 bucket to upload some data. After I was done, I deleted everything on the AWS console. Deleted my database. Terminated my instances. Then I got a bill I wasn't expecting.

Didn't everything get deleted? Literally AWS told me "deleting" in the console. I didn't think anything was running. What happened?

That experience stuck with me. As I work with students building on AWS, I see the exact same thing happen to them. Last semester alone, I heard some version of this story from students.

I'm gonna walk us through what's actually going on and give you a checklist to eliminate this fear when building out on AWS.

What's Actually Charging You After You "Delete Everything"

Here's an example. You delete your RDS instance at the end of a semester project. Makes sense. Project's done. But during deletion, AWS offers to create a final snapshot of your database. It's a checkbox. You probably don't even register that it's there. You click through, the database goes away, and that snapshot sits in your account quietly costing you money.

Same thing with EC2. You terminate your instances and depending on how your volumes were configured, the EBS volumes that were attached don't always get deleted with the instance. They're still there, billing. Invisible unless you know where to look.

And then there's this one that gets people: Elastic IPs. When you terminate an instance, the Elastic IP doesn't get deleted with it. It just sits there, unattached, costing you a few dollars per month. Not huge, but it adds up when you forget about it. That one catches people off guard.

None of this is hidden. It's all documented. But nobody tells you to look for it when you're learning, and the console doesn't wave a red flag that says "hey, you still have billable resources over here."

Why This Frustrates Me

Here's the part that actually gets to me as a Developer Advocate. When a student gets a surprise bill, they don't usually think "I missed a step in my cleanup." They think "AWS secretly charges you even after you delete stuff." They tell their classmates and that becomes the narrative. I've heard it in person, on discord, etc. "Be careful with AWS, they'll charge you for nothing." It's not cool because it can scare people away from learning skills that would genuinely help their careers.

AWS doesn't charge you in mysterious ways. It charges you in specific, predictable ways that nobody taught you to look for. That's a knowledge gap. The purpose of this post is to shed some light on this.

There's a Better Way Now

Here's something I wish existed when I was starting out. AWS now has a free account plan where you get $100 in credits just for signing up, and you can earn up to $200 total by completing activities like launching an EC2 instance or creating a budget. The key part: you literally cannot be billed. There's no scenario where you wake up to a surprise charge. When your credits run out or six months pass, whichever comes first, your account just closes. That's it. No bill.

If you want more flexibility -- say you're working on a longer project or you don't want to risk your account closing mid-semester -- you can choose the paid account plan instead. You still get the same $200 in credits, but your account stays open after they're used up. The tradeoff is that you can be billed beyond your credits, which is exactly why the billing alarm later in this post matters. Set that up on day one and you're covered.

I've been guiding more students toward these options lately and it keeps coming up enough that I'll probably write a dedicated post about it soon.

The Cleanup Checklist

This is what I share with every student I work with now. I tell them to bookmark it and come back to it at the end of every project.

Start With Your Bill, Not Your Console

Before you click around trying to find leftover resources, go to AWS Billing Dashboard from the AWS console. Look at the current month's charges broken down by service. This tells you exactly which services are costing money right now.

If you see a charge for RDS, go check RDS. If you see a charge for EC2, go check EC2. Let this be your map.

Use Resource Explorer

Looking for an exhaustive list of everything going on in your AWS account across all regions?

Instead of clicking through every service console in every region hoping you didn't forget something, Resource Explorer gives you a single search interface across your entire account. All services. All regions. One view.

That last part matters more than you'd think. I've seen students create resources in us-east-1 for a tutorial and us-west-2 for a class project, then only check one region during cleanup and assume everything's gone. Resource Explorer solves that completely. Resource Explorer in the console. If your account is truly clean, you'll see very little. If it's not, you'll see exactly what's still hanging around.

Check the Usual Suspects

Even with Resource Explorer, it helps to know the specific things that catch people. These are the ones I see come up a lot:

Snapshots (EBS and RDS) Check EC2 -> Snapshots and RDS -> Snapshots. Common silent cost I see among students. They get created automatically, often during deletion workflows, and nobody thinks to look for them. These snapshot costs can add up - something like 100 GB could be $5/month.

Unattached EBS Volumes Go to EC2 -> Volumes and filter by state: "available." If a volume shows "available," it's not attached to anything. It's just sitting there being billed.

Elastic IPs Check EC2 -> Elastic IPs. If any are listed and not associated with a running instance, release them.

NAT Gateways If you followed a VPC tutorial with public and private subnets, check VPC -> NAT Gateways. These run about $32/month whether you're pushing traffic through them or not. If you don't need it, delete it.

Set Up a Billing Alarm

This takes two minutes and it's the single most important thing you can do on a new AWS account.

Go to Billing -> Budgets
Create a low budget, say $5 or $10
Set an alert at 80% of that threshold
Add your email

What I Tell Students Who Are Afraid to Start

Every time I meet a student who communicates to me in a way that signals "I'm scared of cloud billing getting out of control," I tell them the same thing. That fear is valid. Every dollar matters when you're a student. Once you understand where surprise charges actually come from, which is a pretty short list, the fear goes away.

The students who get burned are the ones who don't know about snapshots, orphaned volumes, and unattached Elastic IPs. Now you do.

I tell students these three things:

If you want zero billing risk, choose the free account plan when you sign up. You get up to $200 in credits and you cannot be charged. The tradeoff is that your account closes when credits run out or after six months. If you'd rather keep your account open longer, go with the paid plan -- you get the same credits, just set up a billing alarm so nothing sneaks past you.
Set up a billing alarm no matter which plan you pick
Bookmark this checklist and come back to it at the end of every project

Start the account. Build the project. Learn the skills. And when the semester ends, come back to this checklist.

Quick Reference

Check	Where to Look	What to Do
Billing by service	Billing Dashboard -> Bills	See which services are charging you
All resources, all regions	Resource Explorer	Find anything still alive in your account
Snapshots	EC2 -> Snapshots, RDS -> Snapshots	Delete what you don't need
Orphaned EBS volumes	EC2 -> Volumes -> filter "available"	Delete unattached volumes
Elastic IPs	EC2 -> Elastic IPs	Release unassociated IPs
NAT Gateways	VPC -> NAT Gateways	Delete if project is done
Billing alarm	Billing -> Budgets	Set one up before you do anything else

Or to avoid any billing entirely, choose the free account plan when signing up. You still get credits, but you are never billed. Note: when you run out of credits (or 6 months pass, whichever comes first), AWS closes your account.

Click here for more info on AWS Free Tier.

The best time to set up a billing alert was when you created your account. The second best time is right now.