AWS STS (AWS Security Token Service) is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users you authenticate (federated users). This guide uses Ram’s costly security mistake to illustrate why AWS STS and temporary credentials are essential for bulletproof AWS security.
Understanding AWS Security Risks
Chapter 1: Meet Ram (Who Could Totally Be You)
Meet Ram. Ram is a happy-go-lucky developer working on a sleek new app that’s going to “revolutionize how people track their sourdough starters” (his words, not mine). One fine Monday, after a weekend of coding and exactly zero hours of sleep, he decides it’s time to deploy his app to AWS. In a fit of caffeine-fueled brilliance — you know, that dangerous zone where you feel simultaneously invincible and completely exhausted — Bob uploads his AWS access keys to GitHub.
“It’s just a quick push,” he mumbles to himself. “I’ll remove them later.”
Narrator: He would not remove them later.
Chapter 2: When the Internet Comes Knocking
Within 37 seconds — yes, you read that right, SECONDS — automated bots scanning GitHub found Ram’s keys. Before Bob could even finish his second cup of coffee (or the first, really), mysterious users had spun up 73 EC2 instances mining cryptocurrency in his name.
His phone buzzed with AWS billing alerts that escalated from “Hmm, that’s weird” to “OH DEAR GOD” in the span of minutes. By lunchtime, his AWS bill had rocketed past four figures.
Ram’s team had what HR diplomatically called a “growth opportunity discussion.” Ram now has a new desk closer to the intern, who, frankly, seems a little too smug about the whole situation.
“Have you tried not sharing your keys publicly?” the intern asks, helpfully.
What is AWS STS and Why It Matters
Chapter 3: Enter AWS STS (Security Token Service) — Your Digital Bouncer
What if — stay with me here — you didn’t hand out your master keys like they’re flyers for a struggling nightclub?
AWS Security Token Service (STS) is essentially a bouncer for your AWS resources. It gives you temporary credentials with limited scope and lifetime. It’s like saying, “You can borrow my house keys, but they’ll self-destruct in 15 minutes, and they only open the front door — not my secret candy drawer.”
Core Concepts of AWS STS
AWS STS provides temporary security credentials consisting of three components:
Access Key ID: Identifies the temporary credential
Secret Access Key: Used for cryptographic signing
Session Token: Validates the temporary credential’s authenticity
Key Difference from IAM Credentials: Unlike permanent IAM credentials, STS credentials:
Automatically expire after a configured time (15 minutes to 36 hours)
Cannot be revoked manually (but can be restricted via IAM policies)
Are generated on-demand through API calls like AssumeRole
This temporary nature significantly reduces the security risk if credentials are accidentally exposed.
STS is perfect for:
Assuming roles (temporarily becoming someone else in AWS-land)
Contractors who need access (but not forever, please god not forever)
Mobile or web apps (where hardcoding secrets is the digital equivalent of hiding your spare key under a doormat that says “SPARE KEY HERE”)
After Ram’s incident, his team implemented mandatory STS usage. Now when Bob makes his signature “I’m about to do something questionable” face, at least the damage has an expiration date.
Figure 1: How AWS STS credentials work: User/Application → AWS STS AssumeRole API call → Temporary Credentials → Access to AWS Resources
AWS Credentials: Permanent vs. Temporary
Feature
IAM Access Keys
STS Temporary Credentials
Lifetime
Until manually revoked
15 minutes to 36 hours
Revocation
Manual deletion required
Automatic expiration
Use cases
Long-term programmatic access
Cross-account access, federation
Security risk if exposed
High (requires manual revocation)
Limited (expires automatically)
MFA integration
Limited
Supports MFA condition in policies
Key Features of AWS STS
Chapter 4: AssumeRole — The Gandalf of Identity Management
Let’s say Ram needs to access an S3 bucket from a Lambda function that lives in another AWS account. Instead of sharing permanent access keys (we’ve learned our lesson!), he uses AssumeRole.
This is basically Lambda putting on a temporary disguise with very specific powers:
“YOU SHALL PASS… but only for 15 minutes, and only to read objects from this specific bucket, and we’re tracking your every move, so behave yourself.”
Ram , watching his Lambda function execute properly with minimal permissions: “Is this what responsible adulthood feels like?”
Figure 2: The AWS STS role assumption process: Ram’s app → AWS STS → Assumed role credentials → Secure resource access
Implementation Guide: Using AssumeRole
Let’s walk through a complete example of using AssumeRole to access resources in another AWS account:
-
Prerequisites
Source AWS Account (where you’re coming from): 111122223333
Target AWS Account (where resources are): 444455556666
Target S3 Bucket: “target-account-reports” Create a Role in the Target Account
In Account 444455556666, create an IAM role with:
Trust Policy:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole"
}]
}
Permission Policy:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::target-account-reports",
"arn:aws:s3:::target-account-reports/*"
]
}]
}
- Assume the Role via AWS CLI
aws sts assume-role \
--role-arn "arn:aws:iam::444455556666:role/CrossAccountRole" \
--role-session-name "RamCrossAccountSession" \
--duration-seconds 3600
- Use the Temporary Credentials
export AWS_ACCESS_KEY_ID=returned-access-key-id
export AWS_SECRET_ACCESS_KEY=returned-secret-access-key
export AWS_SESSION_TOKEN=returned-session-token
aws s3 ls s3://target-account-reports/
Chapter 5: But My App Needs Access Too!
Mobile apps shouldn’t hold permanent AWS credentials. That’s like taping your credit card to your phone with a note saying “PIN = 1234.” Not great.
Instead, smart developers use Amazon Cognito or a secure backend to call operations like GetSessionToken or AssumeRoleWithWebIdentity.
Here’s how it works:
User logs into your app
Your backend says “Cool, I know who you are. Here’s a temporary pass with very specific permissions.”
The app gets just enough access to work, and then the credentials expire faster than your motivation at the gym
Ram’s app now authenticates properly with AWS STS. His users are happy, his data is secure, and his AWS bill has returned to numbers that don’t cause chest pain.
7 Powerful AWS STS Strategies for Bulletproof AWS Security
Ram’s AWS bill hit the roof because he missed something obvious: AWS security isn’t some optional extra. Trust me, I’ve been there. If he’d known these seven strategies I picked up the hard way, he could’ve avoided the money drain, sleepless nights, and that brutal meeting where his manager just stared at him for what felt like eternity.
Here’s how to keep your cloud environment safe — and your job secure — with some street-smart AWS STS moves.
Ditch Hardcoded Credentials — Always Use Temporary Ones
Look, we’ve all done it. That moment at 2AM when you’re just trying to make the damn thing work? Don’t hardcode those IAM keys. Just don’t. It’s like leaving your front door wide open in a sketchy neighborhood. Use AWS STS for short-lived credentials instead. I’ve started using AWS Vault lately — game changer for keeping secrets where they belong.
Pro Tip: I learned this after finding my AWS keys on GitHub (yeah, major facepalm) — treat credentials like you would your bank PIN: never written down, never shared, always temporary.
Use AssumeRole for Cross-Account Access
Need to connect stuff across accounts? Don’t share long-term keys — I made that mistake once and spent a weekend cleaning up the mess. Set up proper trust relationships and tight permissions for each role.
Example from my own setup: Ram’s Lambda in Account A reads from an S3 bucket in Account B — but only for 15 minutes, and only from that specific bucket. No more, no less.
Add a Second Lock with Session Policies
Even after you’ve assumed a role, lock it down further with session policies. My team started doing this after our staging environment incident (don’t ask). It lets you create ultra-specific permissions that expire.
It’s basically like telling a contractor: “Yes, you can come in today between 1–2pm, but you can only use this bathroom, not wander around the house.”
Require MFA for Sensitive Role Assumption
For anything important — and I mean ANYTHING touching production or billing — tie that AssumeRole to multi-factor authentication. Saved my bacon last quarter when someone got hold of our deploy keys.
I now have a physical YubiKey attached to my keychain. Overkill? Not after you’ve experienced the alternative.
Use Cognito or Web Identity Federation for Apps
Found out the hard way that baking AWS creds into mobile apps is asking for trouble. A user decompiled our app and had admin access within hours. Now we authenticate through Amazon Cognito and issue temporary tokens.
My users don’t notice the difference, but my security team certainly does. Sleep is actually possible again.
Monitor Everything with AWS CloudTrail
Track every damn thing. Every STS call, every role assumption. Our CloudTrail logs caught a weird pattern of AssumeRole calls at 3AM on a Sunday that turned out to be the early signs of a breach attempt.
When stuff hits the fan, these logs are gold. I’ve printed out our CloudTrail screenshots and stuck them on our wall of “things that saved us.”
Tune Session Duration to the Task
Got caught with my pants down when a session lasted way longer than needed. Now I match durations to the actual work. Quick script? 15 minutes. Complex data pipeline? Maybe an hour.
For our Jenkins builds, we dropped from the default 12 hours to 30 minutes and it’s still plenty. Shorter window, smaller risk.
By using these seven tactics (which I learned mostly through painful experience), you’ll create solid AWS security without making your workflow torture. The principle of least privilege doesn’t have to mean maximum frustration.
Chapter 6: Tuku’s Hard-Earned AWS STS Wisdom
NEVER hardcode long-term AWS keys (seriously, just don’t)
Treat AWS permissions like spicy food: give out the minimum amount necessary to get the job done
Rotate credentials regularly, like you’re supposed to rotate your mattress (you do that, right?)
Keep logs of who accessed what, when, and for how long (your future self will thank you during security audits)
Enable MFA for sensitive operations to add an extra layer of security
Implement session policies to further restrict permissions during role assumption
“I used to fear AWS security,” Ram tells newcomers. “Now I just fear the intern’s judgmental stares.”
Tuku now sleeps better at night. He’s even started a side project teaching other developers how to use AWS STS to not light their AWS bills on fire. His desk might still be next to the intern, but his newfound AWS security practices have earned him a “Most Improved Security Awareness” certificate, which he proudly displays next to his “World’s Okayest Developer” mug.
AWS STS Integration with Other Services
AWS STS works seamlessly with several other AWS services to enhance your security posture:
Amazon Cognito: Provides authentication, authorization, and user management for web and mobile apps
AWS Lambda: Functions can assume roles to access resources securely
AWS IAM Identity Center: Centralized access management across multiple AWS accounts
AWS CloudTrail: Logs all AWS STS API calls for auditing and monitoring
By integrating these services with AWS STS, you can create a comprehensive security architecture that follows the principle of least privilege while maintaining flexibility.
Troubleshooting Common Issues
Even with the best intentions, you might encounter some hiccups when implementing AWS STS. Here are some common issues and their solutions:
“Access Denied” Errors
If you’re seeing “Access Denied” when assuming a role:
Check the trust relationship on the IAM role
Verify the permissions policy attached to the role
Ensure your source identity has permission to perform sts:AssumeRole
Session Duration Issues
If your session expires too quickly:
Check the maximum session duration on the IAM rolehttps://blog.costq.ai/wp-admin/post.php?post=229&action=edit
Adjust the duration-seconds parameter in your AssumeRole call
Remember that session duration cannot exceed the maximum set on the role
Cross-Account Access Problems
For cross-account issues:
Verify account IDs in the trust relationship
Check for resource policies that might restrict access
Ensure proper resource ARNs in permission policies
FAQ: Common Questions About AWS STS
What is STS in AWS?
AWS STS (Security Token Service) is a web service that enables you to request temporary, limited-privilege credentials for IAM users or federated users. These credentials expire automatically, reducing security risks.
What does AWS STS AssumeRole do?
The AssumeRole operation returns a set of temporary security credentials that you can use to access AWS resources. It’s commonly used for cross-account access, allowing a user or application in one AWS account to access resources in another account with specific permissions.
How long do AWS STS credentials last?
The default duration is 1 hour (3600 seconds), but you can specify a duration between 15 minutes (900 seconds) to 36 hours (129,600 seconds), depending on the operation and your account settings.
What’s the difference between AWS STS and IAM?
IAM (Identity and Access Management) manages long-term users and permissions, while STS provides temporary security credentials. IAM is for setting up your identity infrastructure, while STS is for dynamically granting temporary access within that infrastructure.
When should I use AWS STS instead of IAM users?
Use STS when:
Implementing cross-account access
Enabling federation with external identity providers
Providing temporary access to mobile or web applications
Running automated scripts that need AWS access
Adhering to the principle of least privilege for elevated permissions
TL;DR: Why You Want AWS STS
Feature
Why You Want It
🕑 Temporary
Keys expire, reducing risk
🎯 Scoped
Only access what’s needed
🔄 Rotatable
Rotate often, worry less
🧼 Clean
No more hardcoding credentials
Want to Be Like Ram ? Start using IAM roles + AWS STS today. Your future self (and your AWS bill) will thank you.
Top comments (0)