Skip to content

0006: Migration of Organizational Resources out of adgem AWS Account

STATUS

[Declined]

CONTEXT

The adgem account in AWS currently holds "workload" resources. It also holds "organization management" resources. This mixing of resources that aren't related to each other is making certain actions we want to take more difficult and complicated than need be. Specifically, our aws-application-account-bootstrap is being deployed from the main adgem account, which prevents any Stacks from being deployed to the main adgem account as a part of a StackSet.

In a Conversation Nick and I had about this, he described what he envisioned for the third considered option, and challenged me to look for a specific scenario where the team would require making these updates before we naturally move those resources over to new, non-root accounts via offer-api and offerwall-ui.

He envisions that we'll create the offere-api and offerwall-ui projects in Workload OU Accounts, and eventually retire the services/resources in the main adgem account. He believes there's no immediate need for this, and I agree.

If we moved this stuff over now, we'd be creating all this manual work for us, and we'd still have to retire those services soon anyway.

Originally, I thought we needed these updates specifically to facilitate the addition of the OIDC Stack in the adgem account, but now I realize it's unnecessary. Any new functionality that will need the OIDC account stuff setup can be setup in a new account with proper Workload OU privileges.

Considered Options

  • Move all adgem workload resources to a new account that will be its permanent home in the Workloads OU. Keep organization resources in the account they're already in. Eventually, rename/move resources to a new account that more accurately describes the nature of the resources held inside of it.
  • Move all organization resources to a new account that will be its permanent home under the Root OU. Keep adgem workload resources in the account they're already in. Move adgem account from the Root OU to the Workloads OU.
  • Leave accounts as is. Make new adgem workload resources in new domain-specific accounts when appropriate, and eventually, we can retire the adgem workload resources in the main root account.

DECISION

Declined effort. We will leave the accounts as is for now. We will make new adgem workload resources in new domain-specific accounts when appropriate, and eventually, we can retire the adgem workload resources in the main root account.

CONSEQUENCES

None

Risks

Moving the adgem workload resources to a new account may cause some unintended side effects that could harm availability. Moving the adgem root account to the Workloads OU may cause some unintended side effects, though less than moving the workload resources to a new account, I think.

NOTES

What are the Workload resources, and what are the Organizational resources in the adgem Root account?

Why do we need to do this? - AWS describes keeping workload resources in a specific account under a Workloads OU as a best practice - AWS describes keep delegating responsibilities to that account separately from the management account for decentralization as a best practice - Having the AdGem resources in an account under the Root OU and keeping the management resources along with them (such as the Org StackSet) prevents us from using those features to their maximum capability

Why do we need to do this now? We have concluded that it is not necessary to do this now to facilitate the update CDK infrastructure setup

What is our target state? AdGem resources should be isolated into their own domain-specific account under the Workloads OU Organization Management resources should be isolated into their own account under the Root OU

What are we doing now? - We're housing those resources in the same account, which muddies the water a bit considering these accounts are supposed to be separated by domain. - To use OIDC in the adgem account, we're manually creating Roles/Permissions/Policies for each use-case instead of through CDK like we do for Workload accounts

References

Here is a reference in the AWS Organizations documentation describing best practices for the management account. It describes avoiding deploying workloads to management accounts, and delegating responsibilities outside of the management account for decentralization. AWS Organizations Best Practices - PR #15: ADR-0006: AdGem AWS Account Resources Migration - PR #21: feat(mkdocs): capability to build a static site of the docs using mkdocs - PR #127: docs: backfill PR reference links for existing ADRs

Original Author

Dakota Washok

Approval date

Approved by

Appendix