Skip to content
Notifications
Clear all

Unpopular opinion: You shouldn't use serverless if your team doesn't understand IAM.

3 Posts
3 Users
0 Reactions
4 Views
(@cloud_infra_rookie)
Honorable Member
Joined: 1 month ago
Posts: 224
Topic starter   [#10399]

Hey everyone, I saw this opinion floating around and it got me thinking.

I'm still learning AWS and just starting with Lambda. Can someone explain why IAM is so critical for serverless? I get that it controls permissions, but what are the concrete mistakes a beginner team makes? Like, giving a function too many permissions? What happens then?

Also, if a team *doesn't* understand IAM well yet, what should we learn first before even trying serverless? Is it just AWS IAM fundamentals, or are there specific patterns?



   
Quote
(@grafana_knight_shift_2)
Estimable Member
Joined: 2 months ago
Posts: 110
 

The real risk isn't just giving a function too many permissions, it's that those over-permissive roles become templates. Someone copies the first Lambda's role for the next one, and suddenly you've got 30 functions with `"*"` on S3 and DynamoDB.

Start with the principle of least privilege for a single, simple function. Make it write to one specific DynamoDB table and nowhere else. That forces you to learn how policies actually attach to resources. Do that manually in the console first, so you see the JSON.

Before serverless, get comfortable with IAM policies on a plain EC2 instance or even just the CLI. If you can't confidently restrict a CLI user to read-only access in one S3 bucket, you're not ready.


Sleep is for the weak


   
ReplyQuote
(@ci_cd_crusader_v2)
Estimable Member
Joined: 3 months ago
Posts: 135
 

Too many permissions isn't just a performance or security smell, it's an invitation to lateral movement. A beginner team writes a Lambda that needs to read from a DynamoDB table, but they slap on `dynamodb:*`. Later, some script or another function gets the same role. Now you've got a chain where a compromise in one place can wipe your whole database, not just read from it.

The real irony is teams jump to serverless to avoid managing servers, but IAM is the new server. It's more complex and more dangerous than patching an OS. If you can't trace exactly which service can do what to which resource, you've just outsourced your security headache.

Learn IAM by building something that *can't* work without the right policy. Like a tiny CLI tool that must write to a specific S3 path and fails everywhere else. That pain is the teacher.


null


   
ReplyQuote