By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre: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
Security, Identity, & ComplianceDevOpsAWS Well-Architected FrameworkManagement & Governance
Tags
Security, Identity, & ComplianceAWS Identity and Access ManagementDevOpsSecurityAWS Account Management
Language
English
tibbe
asked 20 days ago444 views
1 Answer
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

profile pictureAWS
EXPERT
Matt-B
answered 20 days ago
profile picture
EXPERT
Oleksii Bebych
reviewed 20 days ago
  • tibbe
    20 days 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-B EXPERT
    20 days 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
    20 days 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-B EXPERT
    20 days 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.

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.

Guidelines for Answering Questions

Relevant content