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.
Before you say how...
Let me explain.
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, like S3 buckets, Lambda functions, or SQS queues. They define who can access the resource, including other AWS accounts or the public.
Here’s 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—but blocked 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 ensure resources themselves are protected—even if IAM permissions exist.
Example: Our financial reports bucket had IAM permissions for finance guys, 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
OOps that sounded cringe. haha
But just like weight loss or fitness, success in AWS access control 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 which ultimately prevents mistakes, leaks, or misuse.
Ignoring one layer is like skipping cardio or not tracking calories.
You might get some results, but you’ll eventually hit problems.
In AWS, ignoring resource policies while relying solely on IAM can lead to “mystery denied” errors and frustrated users.
Takeaways from the battlefield
Always 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.
Cheers
Top comments (0)