Not possible to nest similar structures

[npvisual]

Description

I was trying to nest several tenant organizational units that would follow the same construct (same Prod and Staging OUs with accounts in them) in the following way :

• Root
  • Tenants
    • Tenant-A
      • Prod
      • Staging
    • Tenant-B
      • Prod
      • Staging
    • ...

However the way the org stack is built, there's already a construct with the same name, so the pipeline build will fail :

[Container] 2022/08/04 19:33:33 Running command npx cdk synth

47 | There is already a Construct with name 'Staging' in AwsOrganizationsStack [orgStack]
48 | Subprocess exited with error 1

The way we've gotten around that is by creating construct names that are built upon their parent's name (so in this case something like tenantA-prod.

Is this something that could be supported to allow for nesting and multiple accounts per tenant per environment ?

[npvisual]

Additional note : I can get past the issue above by qualifying the account names with the tenant's name, instead of Prod or Staging. So for example :

...
            {
                name: 'acme',
                accounts: [
                    {
                        name: 'qa-acme',
                        type: AccountType.STAGE,
                        stageName: 'staging',
                        stageOrder: 1,
                        hostedServices: ['ALL'],
                    },
                    {
                        name: 'acme',
                        type: AccountType.STAGE,
                        stageName: 'prod',
                        stageOrder: 2,
                        hostedServices: ['ALL']
                    }
                ]
            },
...

However the current implementation of RootDNS.createStageSubZone will not allow for the same stageName in an organization with multiple tenants (or constructs) as described above.

And because it is used to build the subzone name we're a little more constrained in what's possible to change it to.

[flochaz]

@npvisual , indeed , bootstrap kit was not design with this use case in mind. But before going further, how many tenant are you expecting to manage ?

[npvisual]

@npvisual , indeed , bootstrap kit was not design with this use case in mind. But before going further, how many tenant are you expecting to manage ?

Currently lower than 10 but the solution we're looking at should be able to grow to 100s (or possibly 1,000s).

[npvisual]

@flochaz : note however that the "multi-account tenancy" can be seen under a different angle (not necessarily through the SaaS lens). For example, we'd like to use the following structure for our developer environments :

• Root
  • SDLC
    • joe
      • dev
      • staging
    • jen
      • dev
      • staging
    • dave
      • dev
        ...

This allows us to isolate dev (and possibly staging envt to test the rollout of some features) and therefore limit blast radius of any "mistake". It also allows us to give more access to AWS services and monitor cost per dev a lot more closely.

It follows a similar structure to the "multi-account tenancy" described above with similar goals in mind, but for internal purposes by considering each developer as "tenant".