Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Best practices for structuring accounts, IAM users, and AWS Organizations for personal developer stacks and prod/staging/dev stacks?

0

Our current setup uses a single AWS account with multiple IAM users.

  1. Each developer has an IAM user and a CloudFormation stack for development purposes.
  2. We have prod/staging/dev stacks, corresponding to those environments.
  3. We use Serverless Framework (which in turn uses CloudFormation) to deploy everything. No manually messing with the console (i.e. IaC).
  4. We deploy using GitHub actions (which runs e.g. serverless deploy --stage=prod).

It's become clear to me that this is probably not the best setup as

  • AWS has per-account limits (e.g. number of S3 buckets) that suggest that it's not intended to have a bucket per employee in a single account and
  • enforcing permissions/security, especially when it comes to the prod stacks, seems difficult with this setup.

What is the best practice for setting up this up in AWS, given that we don't want to compromise on points 1-4 above? An AWS organization, an AWS account per developer, and one AWS account per environment (i.e. prod/staging/dev)?

Topics
DevOpsManagement & GovernanceSecurity, Identity, & ComplianceAWS Well-Architected Framework
Tags
AWS Identity and Access ManagementDevOpsAWS Account ManagementSecurity, Identity, & ComplianceSecurity
Language
English
asked 2 years ago1.5K views
2 Answers
2
Accepted Answer

Hi There

AWS multi-account strategy is the recommended approach which involves organizing your AWS resources across multiple AWS accounts to improve security, cost management, and resource isolation. By creating separate AWS accounts for different business units, environments (e.g., development, staging, production), or specific applications, you can achieve better access control and resource management. The multi-account approach enables you to apply centralized governance and policies, while also allowing for autonomous operations within individual accounts, leading to improved operational efficiency and security.

  1. I would recommend adopting AWS Organizations and IAM Identity Center for a single-signon solution rather than individual IAM users.
  2. You can create Sandbox accounts for devs to experiment in, and workload accounts for each environment with different sets of controls
  3. THis will work fine, you can deploy across accounts by assuming IAM roles
  4. Again this should not be a problem with cross-account IMA Roles

Take a look at the Multi-Account Strategy Whitepaper, and specifically, a starter org layout here: https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/basic-organization.html

Enter image description here

AWS
EXPERT
answered 2 years ago
EXPERT
reviewed 2 years ago
  • tibbe
    2 years ago

    Thanks for your answer! A few follow-up questions:

    • How do we migrate from what we have to this? In particular, we have production workloads (DynamoDB databases, S3 buckets, Lambdas, Route 53 DNS setups) in the current, single account that we don't want to disrupt. Do we keep the current account as the master account when we create an organization and migrate out everything else (dev/staging/developers) into new accounts?
  • Matt Barbieri EXPERT
    2 years ago

    Good question! AWS best practice is to avoid running workloads in the management account. See https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html

    What I would do is:

    1. Create a new Org using AWS Control Tower, this way you get a clean Landing Zone with all of the AWS foundational best practices in place.
    2. Create accounts for the non-prod workloads and migrate them out of the existing account
    3. Invite the existing account to the new org and make it your new Prod account.
  • tibbe
    2 years ago

    Excellent advice. If I may ask one last question: currently we use Route 53 to manage per-developer and per environment domain names that point to the API Gateway e.g. prod.bigcorp.com, staging.bigcorp.com, developer1.bigcorp.com. This can be done without any per-developer console work today using the Serverless Framework Domain Manager plugin (https://www.serverless.com/plugins/serverless-domain-manager). If we have several accounts can they still share the same (root) domain and use an IaC solution like Serverless to have each account manage its own subdomain?

  • Matt Barbieri EXPERT
    2 years ago

    You can create the main hosted zone in a shared account and then delegate subdomains to the individual accounts. heres a good Medium Article that explains, and a Blog Post that explains how to automate this.

0

You've hit the exact pain points that signal it's time to move to a multi-account setup. Here's what I'd recommend:

AWS Organizations with multiple accounts:

Account 1: Management Account

  • Only used for AWS Organizations and consolidated billing
  • Don't deploy anything here
  • Lock down the root user and forget about it

Account 2-4: Environment Accounts

  • Production account (locked down, strict access)
  • Staging account (similar to prod)
  • Development account (where all developers work)

Why this solves your problems:

  • AWS limits are per-account - so each environment gets its own set of limits. Your prod buckets don't compete with dev experiments
  • Security is way easier - you can lock down prod with strict SCPs and prevent accidental deletions/changes. Developers can't accidentally touch prod resources
  • Blast radius is contained - if someone messes up in dev, it doesn't affect staging or prod

For developer access:

  • Ditch IAM users and set up AWS IAM Identity Center (formerly SSO) in your management account
  • Each developer gets federated access with appropriate permissions per account
  • Way cleaner than managing IAM users and their keys

For developer stacks: In the development account, each developer can still have their own CloudFormation stack with proper naming (serverless deploy --stage=john-dev). Since it's a separate account, you don't hit the same limits as prod.

Your CI/CD stays the same: GitHub Actions can still run serverless deploy --stage=prod, but now it assumes a role into the production account. Same workflow, just better isolated.

I wrote a detailed guide that walks through exactly how to structure multiple accounts as you grow, including how to set up proper boundaries between environments.

And if you want to understand how to set up a solid foundation with proper governance (SCPs, Landing Zone, cross-account roles for CI/CD, etc.), that'll help you get it right from the start.

TL;DR: Set up AWS Organizations with separate accounts for management, prod, staging, and dev. Use IAM Identity Center for developer access. Your IaC workflow stays the same, but you get proper isolation and better security.

answered 5 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content