IAM in Service Catalog
For teams or individuals that are creating an AWS account at the UW there are some essential first steps that you should take. This guide assumes your account is a DLT account and that you have recieved an email from DLT saying your account is now ready for use.
Send an email to firstname.lastname@example.org. Provide your AWS account number and start with something simple like $50. Once your monthly bill hits $50 you will get a notification. Do this now because forgetting to do so can lead to overspending and not knowing for a few months until the actual bill arrives in your UW budget.
Immediately upon recieving root credentials and on your very first login you MUST enable Cloud Trail for every region. Simply use the search at the top of the console and enable it using the UI it provides. Cloud Trail logs every AWS API call, so all actions done in the AWS console will be logged. You are dead in the water if ever having to deal with an incident response (security breach, account comprise etc) with Cloud Trail disabled. Cloud Trail is your audit log for all activities done by those whom are granted access.
You goal should be to stop using the root account ASAP and enable MFA on the root account.
You MUST enable UW SSO integration (with opt in 2FA) for AWS Console access vs. using AWS IAM users for AWS Console access. As of May 2018, UW-IT IAM enabled opt in 2fa. There is now no reason to continue the use of AWS IAM users for AWS Console activities for those UW people authorized for UW's 2FA service. You now can have a comprehensive solution for Authentication and Authorization into the AWS Console and have that access control managed with UW Groups to AWS IAM Roles.
Once you have completed the above SSO with 2fa setup for your AWS account administrator(s) it's time to stop using the root account and create a stronger password for the root account. It's also time to think strategicly about how you will use your AWS account. There is no right or wrong architecture and this depends on your team size.
Once you have had a conversation with your team about how your account will be used you should now expand your use of UW Groups and AWS IAM Roles. The following are suggested practicies you may want to adopt.
You will want some governance around this from day 1. It's very difficult to unwrap a complex structure of haphazardly built AWS IAM Roles, Policies, Groups and Users. Think about who will need access to the IAM console and what actions they will need to perform. For even larger deployments you may want to consider a multi account architecture to segment your environments (keep in mind DLT is the AWS Organization account for the UW vs. a UW entity or yourself being the Organization account). Regardless, map AWS IAM Roles to UW Groups using the UW SSO guide.
Do you have an audit or security team? If so, maybe a role for both of them will suffice and that role could have limited policies to Read everything but no privlages beyond that (write, delete etc). Is there a developer team? Maybe multiple developer teams?
AWS IAM is a very robust feature and can have as granular role based access control as you want. The key thing to remember is for AWS Console access and use, AWS documentation infers that those console actions are being performed by an AWS IAM User. That is not the case if you have enabled UW SSO. AWS Console access is actually granted to a UW SSO authenticated user and that user is given access based on the AWS IAM Policies attached to the mapped AWS IAM Role. Ideally you would want to limit the use of AWS IAM Users to service accounts within or connecting to AWS.