Multiple prod accounts guidance

[mtb-xt]

Hi team,

We're using the Cloud Posse reference architecture and following the standard naming convention {namespace}-{tenant}-{environment}-{stage}-{name}-{attributes}.

We now research a situation if we need to onboard multiple production AWS accounts, one per customer. I'm looking for guidance on how best to model this in line with your framework.

Specifically:

• Should we name the accounts like ns-plat-gbl-prod_customer1?
• Or is the tenant label intended for this use case, resulting in something like ns-plat-customer1-euc1-prod?

More generally:

• What’s your recommended approach for managing per-customer accounts within the same OU (e.g., plat)?
• How should we configure accounts and SSO components when these accounts are customer-isolated?

Thanks!

[Benbentwo]

We've handled multiple customer accounts in various ways.

The first is to create an OU per customer, with each customer having its own SDLC, so you'd have customer1-dev customer1-staging and customer1-prod. This can be quite overkill if your customers don't need a full development lifecycle.

Org
| - OU: Customer-A
|----| - Dev
|----| - Staging
|----| - Prod
...

{namespace}-customerA-{environment}-{stage}-{name}-{attributes} (tenant is now customerName for these accounts)

---

Another way is by inverting the SDLC into OUs. You'd have a prod OU and a Staging OU with customer tenants between them. Each cutomer could be it's own tenant within the OUs of dev/staging/prod

Org
| - OU: Prod
|----| - Customer-A
|----| - Customer-B
| - OU: Staging
|----| - Customer-A
|----| - Customer-B
...

Here your tenant can be set to the customer still
{namespace}-customerA-{environment}-prod-{name}-{attributes} for a nice logical grouping

---

Perhaps the most common way that I've seen is you create an OU for customers specifically. Then you deploy all of your customer accounts there.

Org
| - OU: Plat
|----| - Dev
|----| - Staging
|----| - Prod
| - OU: Customers
|----| - Customer-A
|----| - Customer-B
...

---

Really, this all comes down to how you want to structure your AWS accounts, and then how do you want to name your resources in regards to what is a tenant.

Typically, a tenant represents an OU, but that's just a pattern that we've set before. It really comes down to what works for you, and when you're structuring these AWS accounts, the other thing to consider is SSO—and how you sign into those SSO permissions and accounts. Who has access to what logical groupings, and what customers or what accounts or OUs do team members have access to?

[mtb-xt]

Really, this all comes down to how you want to structure your AWS accounts, and then how do you want to name your resources in regards to what is a tenant.

Typically, a tenant represents an OU, but that's just a pattern that we've set before. It really comes down to what works for you, and when you're structuring these AWS accounts, the other thing to consider is SSO—and how you sign into those SSO permissions and accounts. Who has access to what logical groupings, and what customers or what accounts or OUs do team members have access to?

We just want the simplest possible way to have "1 isolated account per customer", to further isolate them from each other. We still keep all core and plat-dev\stage accounts as they are.

The SSO also remains the same as prod - devops have one set of privileges, dev - other. We are trying to follow the requirements set to us, while not breaking or changing the layout of cloudposse refarch too much. What would you recommend in this case?

[j4zzcat]

This approach works well for us.
Your experience may vary depending on how much you choose to deviate from the default structure :-)

.
├── aux
│   └── public
├── core
│   ├── artifacts
│   ├── audit
│   ├── auto
│   ├── backup
│   ├── identity
│   ├── network
│   ├── root
│   └── security
├── dev
│   ├── dev
│   ├── sandbox
│   └── testing
└── prod
    ├── generic
    ├── saas
    ├── customer-1
    ├── customer-2
    ...
    └── customer-N

[mtb-xt]

This approach works well for us. Your experience may vary depending on how much you choose to deviate from the default structure :-)

└── prod
    ├── generic
    ├── saas
    ├── customer-1
    ├── customer-2
    ...
    └── customer-N

How do you deal with the dash in customer-1? Or you are not calling them literal 'customer-1`? :)

[petabook]

No, we're calling them by name.

[GabisCampana]

Hi @mtb-xt

Just following up here as there hasn’t been any activity on this thread for about six months.

A clear recommendation has emerged that meets the original requirement.
Unless there are new constraints or edge cases to explore, I believe this discussion can be safely closed.

Thanks to everyone who contributed their insights and examples.