Why I Chose AWS STS: A Simple Model I Wish I Learned Earlier
Hello builders and cloud engineers 👋
Why I Chose AWS STS: A Simple Model I Wish I Learned Earlier
Hello builders and cloud engineers 👋
This is not a post about a production outage or a security breach.
It is about a mental model I learned recently — one that makes AWS security easier to reason about and harder to get wrong.
That model is **AWS STS and temporary credentials**.
What You Will Learn From This
By the end of this article, you should clearly understand:
- Why permanent AWS access keys are dangerous by design
- What AWS STS does, without AWS jargon
- How IAM roles + STS limit blast radius
- A simple way to explain this to others
A Real-World Analogy (House Access)
Think of your AWS account as a house.
You have:
- A main door
- Multiple rooms
- A locker with valuables
Now think about access.
Old model: Physical keys
- You give a physical key to someone
- The key works anytime
- It opens everything it was designed to open
- It never expires unless you change the lock
This is how AWS access keys work.
The Thief Problem (Why Keys Are Risky)
Now introduce one more character.
A thief.
If the thief gets a copy of the key:
- He does not need to break anything
- He can enter silently
- He can return again and again
- You may never know until damage is done
This is not a bug. This is expected behavior of permanent credentials.
The Better Model: Smart Locks (AWS STS)
Now change only one thing.
You remove physical keys.
Instead:
- The door generates a temporary PIN
- The PIN works for a short time
- The PIN opens only specific rooms
- After expiry, it stops working automatically
This is AWS STS.
Technology Mapping

real world mapping with aws services

Assume role
Key point: No permanent keys are stored in the application.
Why This Matters (Even If Nothing Is Broken)
You may say:
“I would never make such a mistake in production.”
That’s exactly the point.
STS is not about fixing mistakes. It is about designing systems where mistakes expire on their own.
- Credentials leak less often than we fear
- But when they do, permanent keys are unforgiving
- Temporary credentials are survivable
Clear Opinion (Based on Design, Not Fear)
In modern AWS systems:
- Applications should not own long-lived secrets
- Humans should not rotate keys manually
- Access should die automatically
IAM roles + STS should be the default. Access keys should be a last resort.
Mental Model
Always ask three questions about access:
- Who can access?
- What can they access?
- For how long?
STS forces you to answer the third question.That is its real value.
Closing Thought
A thief can steal a key. A thief cannot steal time-limited access.
I didn’t learn AWS STS because something failed. I learned it because this model is simply better.
In the next article, I plan to write about: Shared IAM roles, why they scale well, and where they quietly become risky.
Because good cloud security is not about fear. It is about good defaults.
메타데이터
- post_id
- da8ff6c6caef
- slug
- why-i-chose-aws-sts-a-simple-model-i-wish-i-learned-earlier-da8ff6c6caef
- url
- https://medium.com/@vinodbokare0588/why-i-chose-aws-sts-a-simple-model-i-wish-i-learned-earlier-da8ff6c6caef
- canonical_url
- https://medium.com/@vinodbokare0588/why-i-chose-aws-sts-a-simple-model-i-wish-i-learned-earlier-da8ff6c6caef
- author_url
- https://medium.com/@vinodbokare0588
- status
- ok
- fetched_at
- 2026-08-19 18:15:50