AWS FOR THE REAL WORLD
⏱️
Reading time: 10 minutes
🎯
Main Learning: Wildcards come from the tooling, not from laziness. Put least privilege at the account level
and let an agent write the policies.
Hey 👋🏽 I have shipped my share of s3:* at unusual hours and told myself I would refactor it later - which obviously never happened 😅 So when someone on r/aws asked why developers can't write least privilege policies and put it down to laziness, I was excited to read through all of the comments.
Almost nobody in there defends wildcards. They just explain what it actually costs to avoid them: one denied action at a time, ten minutes per deploy, and a deadline that doesn't move - very relatable, especially if you use CloudFormation in any way 😬 In this issue: the five reasons the thread brought up, where the OP still has a point, and the setup I use instead 🫡
Sponsored
|
Search without the cluster
Typesense — the open source alternative to Algolia
|
Typo-tolerant search from a single binary. No shard count to pick, no JVM heap to tune, no cluster to keep alive — and natural language
search is built in.
Smaller learning curve than Elasticsearch • Django & Laravel Scout integrations
Check it out on GitHub →
Sponsored by Typesense, a tool we run ourselves.
📚 This Week's Deep Dive
A security audit found s3:* and
AdministratorAccess on nearly every role. The person doing the
audit called it laziness. 125 comments explained why it isn't.
The loop, not the intent
"You are out of your mind if you think I'm going to take 30 swings at solving a permissions problem. At 10 minutes per build/deploy, 30
iterations is all day."
AWS denies one action at a time, so you find them one by one. That's the honest math for a single resource.
One SDK call is not one IAM action
s3:GetObject alone gives you a working happy path and a lying
error message. Without s3:ListBucket, a missing object returns
403 instead of 404. Add a customer managed KMS key and you need
kms:Decrypt on top. Three statements for what the developer
experienced as one call.
Access Analyzer doesn't survive the move to prod
Your error paths never ran, so they're not in CloudTrail and not in the generated policy. The ARNs come out hardcoded to your dev bucket
names. And the trail still contains the three approaches you abandoned on Tuesday.
|
📰 This Week in AWS
🔍DynamoDB does vector search in single-digit milliseconds
|
Store embeddings as a plain list of floats, put a vector index on the attribute, query it with the new SearchVectors API. No
separate vector database, no sync pipeline. S3 Vectors still wins on price for infrequent queries.
|
Read More →
|
🔀Network Load Balancer got listener rules
|
The first real routing logic on an NLB. One dual-stack NLB now sends IPv6 clients to IPv6 targets and IPv4 to IPv4, no
translation, client IP preserved on both. Source IP type is the only condition so far, but the direction is clear.
|
Read More →
|
📦Lambda can run code straight from your own S3 bucket
|
Set S3ObjectStorageMode to REFERENCE and Lambda skips the copy into its own storage. No code storage quota, faster function
activation, no extra Lambda charges. The managed default also went from 75GB to 300GB per region.
|
Read More →
|
|
That's it for this issue. If you take one thing away: stop paying the least privilege cost per role. Put the hard boundary at the account level with separate accounts and SCPs, and let your IaC and your agent write the scoped grants. And read what comes out. A policy nobody reviewed is not least privilege, no matter who typed it 😅 See you in the next one! Sandro & Tobi |