The EMR Studio instructions appear to be intended for people to set up the studio in the Organizations management account, which is against AWS best practices. Like, you *really* don't want to do that. @abysinha

The docs recommend that the person setting up EMR Studio also have full permissions to AWS SSO. It think it's likely the case that a security team would not be happy about a data team introducing a new authentication method on their own.
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-admin-role.html

They additionally don't split the AWS SSO permissions, which *have* to be in the Org mgmt acct, from the rest of the EMR permissions, implying they are expecting these actions to be taken in the same account.

And it's a *lot* of permissions. Basically full access to VPC configuration, a bunch of service catalog stuff...not things you just want to hand over in your Org mgmt account. Ever.

Additionally, the automated script the docs recommend that you use to create a Studio does not take an AWS SSO instance id. Instead, it checks with sso-admin.ListInstances, which does not appear to work outside the Org mgmt account. https://github.com/aws-samples/emr-studio-samples/blob/65293e16f232b2e23577d7c8b00322a286bd22dc/create_studio.sh#L28

Not only that, but you don't actually tell EMR the AWS SSO instance id, which is weird. You just tell it to use "SSO auth", and that's that. What happens when AWS SSO supports multiple instances?

So now you've got your EMR Studio in your Org management account, and you have to create a service role for it to access resources. So now you're handing Studio *users* permissions in your mgmt account, or potentially worse, cross-account permissions *from* mgmt into the Org

This is, frankly, a nightmare