This naming scheme works, but it still seems suboptimal. I should never, under any circumstance, receive email intended for the root user of an account that is subordinate to an organization. If someone manages to create a password associated with that user or otherwise authenticate as that user, that is a security failure. Conversely, I should be able to assume the “role” of that account’s root user from the organization’s management account regardless of IAM policy inside that account. And the scare quotes are intentional: no role should need to exist inside the sub-account for this to work — it should not be possible to lock myself out of a sub-account by any manipulation of that sub-account’s IAM configuration.