- Newest
- Most votes
- Most comments
You're on the right track with some of your security considerations, but let me clarify a few important points about AWS best practices for your scenario.
Having separate AWS accounts for Test and Prod environments is indeed a best practice. This provides strong isolation between environments and limits the blast radius if credentials are compromised.
Regarding IAM users versus roles, there's a fundamental security difference. IAM users have long-term credentials (passwords and access keys) that don't automatically expire. IAM roles, on the other hand, provide temporary credentials that are automatically rotated. For applications running on AWS services like EC2, the recommended approach is to use IAM roles rather than embedding user credentials.
For your backend application accessing S3, the most secure approach would be:
- Create an IAM role in each account (Test and Prod) with the specific permissions needed to access only the relevant S3 bucket
- Attach this role to the AWS service running your backend (like EC2, Lambda, etc.)
- Let the application use the role's temporary credentials automatically
This approach avoids storing any long-term credentials in your application or instances. If you were to use an IAM user with access keys embedded in your application, those credentials would be at risk of exposure and wouldn't automatically rotate.
If your backend is running outside of AWS, you might need to use IAM users with access keys, but this is less secure than using roles. In this case, implement strict key rotation policies and use the principle of least privilege when assigning permissions.
For organizations, the management account should be highly restricted and not used for operational workloads. Your backend users or roles should be defined in the respective member accounts (Test and Prod), not in the management account.
Remember to implement the principle of least privilege by granting only the specific permissions needed (like specific S3 actions on specific buckets) rather than broad permissions.
Sources
Security best practices for Amazon S3 - Amazon Simple Storage Service
Community | Securely Access Resources with IAM Service Roles
SEC03-BP02 Grant least privilege access - AWS Well-Architected Framework
What’s the difference between an IAM User and an IAM Role in AWS? | AWS re:Post
If your backend is running on AWS you should use roles. If it’s external you may need to use IAM access keys or OIDC authentication
Thanks for your reply! I read that also for external access, roles are recommended. And could you maybe also explain the reason for why to use roles considering my questions, also for AWS internal services? What is the advantage over just using an IAM user directly? Stuff like "no long-lived credentials" doesn't really make sense to me. Because at least an external backend still needs long-lived credentials to even authenticate with the user. Or is that the reason for why roles only make sense for AWS internal services? Because there, you can attach the role to the service directly and actually CAN omit the user?
Relevant content
asked 3 years ago
asked 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 10 months ago

ChatGPT also told me all the time that I don't need to store credentials. But that's not true is it? Because my backend still needs to authenticate with an IAM user that I need credentials for. And these temporarily assumed role credentials seem like a nice-sounding technical gimmick to me. But what are they worth if I still need to authenticate for the IAM user with static credentials at the very beginning?