Best practice for stacks folder to support dual AWS accounts (main + secure) per environment

[trungie]

We’re using the reference architecture with tenant plat and the four standard environments (dev, staging, sandbox, prod). To enforce stricter separation, we need to introduce two AWS accounts per environment—named main and secure—resulting in these eight accounts:

• dev-main
• dev-secure
• staging-main
• staging-secure
• sandbox-main
• sandbox-secure
• prod-main
• prod-secure

Our questions:

1. How would you recommend structuring the stacks/orgs/plat/stacks directory to accommodate this dual-account model? Flat vs. nested (e.g. stacks/orgs/plat/dev/main vs. stacks/orgs/plat/dev-main)?
2. How do you recommend we name our stacks? (e.g. plat-gbl-devmain or plat-gbl-dev-main)
3. Any pitfalls or gotchas when scaling from one account to two per environment?

[trungie]

I would like to suggest an answer to my own question which is we will create a new tenant named "secure" which will follow the existing atmos naming convention for stacks.

[milldr]

You have a few options that depend on your use case and requirements.

1 - Use the existing account architecture

First you could reuse the same accounts. I know you said you need a higher level of separation, but I'll explain this option for reference.

With this design, you could create a new YAML file within your stacks file structure. This would be consistent with other "layers" for each stage and would enforce the same SCP and access per stage for the new resource groups. You could define a common mixin or attributes for all deployments inside these new files. This would create a logical boundary but no physical boundary for the new resources.

That would look something like this:

stacks/orgs/acme/plat/dev/
  main.yaml
  secure.yaml

stacks/orgs/acme/plat/prod/
  main.yaml
  secure.yaml 

2 - Create a new account for main and secure

You could also create a new account for main and other for secure. This way you create a physical boundary between resources in new these new accounts and can apply independent policies and controls to the new accounts.

I would recommend putting those in the core tenant, since they sound like management related accounts to me. That could look like this:

stacks/orgs
└── acme
    ├── core
    │   ├── artifacts
    │   ├── audit
    │   ├── auto
    │   ├── dns
    │   ├── identity
    │   ├── main #<---- new account
    │   ├── network
    │   ├── root
    │   ├── secure #<---- new account
    │   └── security
    └── plat
        ├── dev
        ├── prod
        ├── sandbox
        └── staging

3 - Create a new tenant for main and secure

If you need a main and secure account per stage and you a physical boundary, then I'd recommend creating a new tenant for each.

That could look like this:

stacks/orgs
└── acme
    ├── core
    ├── plat
    │   ├── dev
    │   ├── prod
    │   ├── sandbox
    │   └── staging
    ├── main
    │   ├── dev
    │   ├── prod
    │   ├── sandbox
    │   └── staging
    └── secure
        ├── dev
        ├── prod
        ├── sandbox
        └── staging

This would require the most overhead to set up and manage but creates the strongest physical boundary. You would manage a separate stage for each tenant and map each to a stage in the plat tenant. Plus if you add additional tenants in the future beyond plat, you could map the same stages to this tenant.

This is what you suggested, and I agree is the best choice for your use case from what I understand.

[milldr]

How would you recommend structuring the stacks/orgs/plat/stacks directory to accommodate this dual-account model? Flat vs. nested (e.g. stacks/orgs/plat/dev/main vs. stacks/orgs/plat/dev-main)?

I would recommend structuring the directory like this, if using the new tenant approach:

stacks/orgs
└── acme
    ├── core
    ├── plat
    │   ├── dev
    │   ├── prod
    │   ├── sandbox
    │   └── staging
    ├── main
    │   ├── dev
    │   ├── prod
    │   ├── sandbox
    │   └── staging
    └── secure
        ├── dev
        ├── prod
        ├── sandbox
        └── staging

How do you recommend we name our stacks? (e.g. plat-gbl-devmain or plat-gbl-dev-main)

With the new tenant approach, the tenant would be main or secure, and the stage would be sandbox, dev, staging, or prod. Therefore, the stacks would be:

main-gbl-dev
main-gbl-prod
...
secure-gbl-dev
secure-gbl-prod

Any pitfalls or gotchas when scaling from one account to two per environment?

The only really pitfall is the overhead to set it up. You would need to set up SCP / controls and policies for the new tenants, set up cross-account roles (aws-team-roles), and connect the network. In particular connecting transit gateway can be expensive, so if private network connectivity is required, it's worth considering cost.

[trungie]

The only really pitfall is the overhead to set it up. You would need to set up SCP / controls and policies for the new tenants, set up cross-account roles (aws-team-roles), and connect the network. In particular connecting transit gateway can be expensive, so if private network connectivity is required, it's worth considering cost.

Fortunately, docs that walk through the setup process! Linking them here in case others find this question useful:

• https://docs.cloudposse.com/layers/accounts/tutorials/how-to-add-a-new-organizational-unit/
• https://docs.cloudposse.com/layers/accounts/tutorials/how-to-create-and-setup-aws-accounts/