IAM Policies vs Resource Policies: Lessons from Production (and the Gym)

Source: Dev.to

Background

Early in my AWS journey, I ran into a problem that had me scratching my head for hours.

A frontend engineer came up to me:

“Tony, I just want users to see our app logos and images, but it’s not working. They keep getting denied.”

I double‑checked the IAM permissions—everything looked fine. The user had the right access. So why were people still blocked?

It wasn’t IAM at all. It was the S3 bucket’s resource policy.

That’s when it clicked: managing AWS access is a lot like managing a gym or sticking to a disciplined fitness routine.

IAM Policies = Your Personal Trainer

IAM policies are like your personal trainer. They define what you (the identity) are allowed to do:

• Can you lift weights today?
• Can you run on the treadmill?
• Can you skip cardio?

In AWS, IAM policies attach to users, groups, or roles. They control what actions an identity can perform and on which resources.

In production I also enforced MFA for all IAM users. Think of it like adding a second checkpoint before entering a VIP gym area—you might have the keycard (password), but without the fingerprint (MFA), you can’t get in. Simple, but it drastically increases security.

Resource Policies = The Gym Rules

Resource policies are like the rules posted on the gym wall. Even if your trainer gives you permission, the rules might still restrict your access:

• Only VIP members can use certain equipment
• Some areas are off‑limits

In AWS, resource policies attach directly to resources (S3 buckets, Lambda functions, SQS queues, etc.). They define who can access the resource, including other AWS accounts or the public.

What I Did in Production

• ALB Logs – Edited the bucket policy so our Application Load Balancer could send access logs safely, without extra permissions.
• Frontend Images/Logos – Created a bucket policy allowing users to read logos and images while blocking access to sensitive files. Users got exactly what they needed.

Scaling Access: IAM vs. Resource Policies

One thing I learned quickly: scale changes everything.

• IAM policies scale best for identities. One policy can manage multiple users, groups, or roles—perfect for internal teams.
• Resource policies scale best for resources. When sharing across accounts or publicly, resource policies give the resource control over access.

Using both together is essential. IAM ensures users only do what they should, while resource policies protect the resources themselves—even if IAM permissions exist.

Example: Our financial reports bucket had IAM permissions for finance users, but the resource policy restricted access to our AWS account only. Layered security prevented accidental or malicious access and gave us peace of mind.

Layered Security = Layered Discipline

Success in AWS access control, like fitness, comes from layers of discipline:

• IAM = your workout plan → defines what identities can do
• Resource policy = gym rules → defines who can access resources

Both together produce sustainable results and prevent mistakes, leaks, or misuse. Ignoring one layer is like skipping cardio or not tracking calories—you might see some progress, but problems will surface later.

In AWS, relying solely on IAM while ignoring resource policies can lead to “mystery denied” errors and frustrated users.

Takeaways

• Check both IAM and resource policies. A deny in either will block access.
• Enforce MFA. It’s a small step with huge security payoff.
• Use resource policies for cross‑account or public access—especially when sharing logs, images, or APIs.
• Test every access path. Users may have the right IAM permissions but still get blocked.
• Think in layers: identity control + resource control = secure, scalable access.