This pretty much covers the basics of how to create IAM groups and users, and how to assign policies to them. Here are some of the IAM tips and gotchas that we've run into over the years:

• Users can exist in more than one group. Use this to your advantage.
• Groups, however, cannot exist within other groups.
• Users can have more than one set of API keys. This is necessary when they need to perform key rotation.
• You can (and should) define a strong password policy for your IAM users.
• The PowerUserAccess policy is good, but it does not allow IAM access. At first, this might not seem to be a problem; however, if you are bound by this policy, you will encounter issues when running CloudFormation stacks that create IAM roles for EC2 instances, for example.
• IAM is a global service, meaning that users and groups are global, not region-specific. By default, a user can use AWS services in any region.
• EC2 key pairs are region-specific, and not specific to an IAM user. In other words, IAM users don't have SSH keys associated with them.
• Your IAM username and password (and access keys) won't provide you with SSH or RDP (short for Remote Desktop Protocol) access to running instances. Credentials for these services are managed separately.
• You can assign up to 10 policies to a group or user.
• You should also enable multi-factor authentication (MFA) on IAM user accounts for added security. This is used primarily for accessing the web console, but you can also configure your policies so that MFA will be required for API calls, too. You can choose between hardware and software tokens. A good rule of thumb is to use software tokens for IAM users, and hardware tokens for root logins.