Tracing backward AWS Organization CreateAccount API
tl;dr Loosely-coupled services just assume you know your metadata from both directions. Don’t assume you can query for it afterward.
If you started your AWS journey before AWS Organization, you probably manually create your AWS account. Since then, it’s preferred you create the account using AWS Organization control plane because it will enroll your newly created account into the organization. How else would you enjoy your seamless billing integrations. If you examine the documentation for create account, there is an optional parameter RoleName. This is created with the equivalence of AdministratorAccess because its recommend you access your account via AWS IAM and this automated created role allowed Administrator access by the management API.
The documentation makes multiple attempts to remind folks that please leave the default value (OrganizationAccountAccessRole) in for consistency. If you decide to change it, you should keep track of it because you need it to pivot into the account. Let’s pause it here, Why is it necessary to write it down, shouldn’t the management account needs this IAM role for other functionalities?
The DescribeAccount API will tell you the email address, account name, and friendly name of the enrolled member account. Those tuple of email address and account name is sufficient for a password recovery process for the root user of this enrolled member account. Email adderss and account number are required attributes of any AWS account. How about an IAM role? As far as I can tell, you can techincally remove all roles in AWS IAM. It may break many AWS service integration, but the there is interface requirement that says an account must have certain IAM role. Because of that, it’s difficult to maintain a mapping from root management account to the member account regarding which role was specified during account creation. Yes, you can store the initial parameter as a extra attribute in the management account data model; however, if the member account removes it, there is no great mechanism to update the info in the management account.
You may challenge me what about the data model regarding management account knows which enrolled member accounts, and each member account know what is its organization id and its management account id. My reasoning is this information all resides in AWS Organization service. If you were to change IAM service interface to somehow call back to AWS Organization, this expand the failure domain. Should the implementer fail a removal of an IAM role in the event AWS organziation API is not available? What AWS service want to become tier 0?
There is alternative to use event architecture to track the RoleName. If you monitor the organization cloud trail, you can monitor the RoleName parameter pass in during createAccount, and invalidate your cache by monitoring for role deletion via EventBrige. Do remember the nature of eventual consistency for the event architecture.
In addition, AWS ControlTower has been recommended by AWS as the preferred way to create AWS Account. It actually uses a different default value (AWSControlTowerExecution) during createAccount process. .
