Multiple development environments with AWS Identity Center and AWS organization

I’ve been working with AWS services for several years, initially managing development and production environments in a single AWS account. Like many, I used to store keys and secrets in an .env file, something like this:

LOCAL_DEV_ACCESS_KEY_ID=
LOCAL_DEV_SECRET_KEY=
...

For a while, I didn’t realize the limitations and risks of this approach. But as I started setting up development environments in AWS more thoughtfully, I discovered a better way. In this article, I’ll walk through my experience moving from the old approach to using AWS Identity Center and AWS Organizations. To keep things simple, let’s assume we’re using S3, Lambda, and Aurora.

About the Old Way

In the old way, I’d create an IAM user with just enough permissions to work on local development. This worked fine when I was the only one in the project. But as the team grew, I found myself creating separate IAM users for each team member, each with different levels of access.

The more people who joined the project, the more complicated it became. Here’s a taste of the challenges this brought:

1. Imagine a team member, userA, needs access to the production database for debugging. Instead of going through the devops team for temporary permissions, he asks userC to share their access key. Suddenly, userA has unrestricted access to production resources through userC’s credentials.

2. Follow that story, now suppose userA accidentally overwrites a critical file in S3 using userC’s key. But when you check in CloudTrail to see what happens, you only see the actions by userC

3. In another scenario, say a trusted devops engineer, with access to create new resources, uses Redshift or Kinesis for a side project without telling you. You don’t know until the surprise arrives in the monthly bill.

4. Cost management is also a problem when many environments are in an account. You will get trouble in measurement the cost for each environment.

These examples might sound hypothetical, but they illustrate the kind of risks that come with shared keys and unrestricted permissions in the real world.

New way

I wondered that there must be someways else to reach the resource safely and I found it. I know there are many ways to solve those above problems, but in this article, I just want to share this one. If you get another, I'm very appreciate to know it.

Using AWS Organizations

AWS Organizations enables you to set up separate accounts for each environment (e.g., one for staging, one for production), which effectively isolates each environment. This isolation reduces the chance of accidentally granting access to the wrong resources.

Organizations also lets you apply Service Control Policies (SCPs) across accounts, even restricting actions for root users (root user of an AWS account in the organization). For example, with SCPs, I can ensure users in a staging environment can only create specific EC2 instance types (t2.micro, t2.small, t3.micro) or limit their access to specific services like EC2, RDS, S3, and Lambda. If I’m the root user of a staging account, these policies prevent me from accessing services outside the approved list, like Kinesis or Redshift. SCPs provide account-wide guardrails, making them extremely useful for managing permissions and avoiding resource misuse.

In addition to isolating environments, having separate accounts for development and production simplifies cost management. This setup allows you to monitor costs more closely per environment, making budgeting and cost control more straightforward.

AWS Identity Center Benefits

AWS Identity Center (formerly known as AWS SSO) solves the key-sharing and traceability issues by allowing you to create and manage users independently of IAM. Here’s what makes Identity Center stand out:

1. No More Keys in Local Development: Each team member has their own Identity Center user. When they need to work with AWS, they create a session by logging in and authenticating via MFA, giving them temporary, secure access to the resources they’re allowed to use. They don’t need long-term keys or to keep credentials in an .env file, reducing the risk of accidental exposure or sharing.

2. Time-Limited Sessions for Security and Traceability: With Identity Center, sessions have configurable expiration times (typically one or two hours). This means users are regularly re-authenticated, which minimizes the risk of lingering access and prevents users from accessing resources indefinitely. Each session is also unique and recorded, creating a robust audit trail in CloudTrail. This way, you can trace each user’s specific actions during a session, solving issues like shared access and making troubleshooting much easier.

With AWS Organizations and Identity Center, permissions and resource access are managed centrally, eliminating the need to share IAM keys and providing a much higher level of control, security, and traceability.

Conclusion

I think that creating IAM user with permissions and access by keys may suitable for a small project or small team. Maybe it can also be used for CI/CD process to access AWS resources. It's simple, easy to setup.

But for the larger project, more members in your team, you maybe consider to use AWS Organization and AWS Identity. It's quite complicated, but it's more secure and can help you reduce headache for managing member and resources with many environments.

I hope this article will help you in someways, please let's me know if you have any concerns or questions. There will be part 2 to help you setup this approach later, see you ✌️.