You have the ability to set a “permission boundary” this is essentially an additional IAM policy that defines the maximum permission an IAM user or role can get, while your identity-based policy defines what the user can actually do. For example if you have an IAM permission boundary that states the user can access all of S3 and EC2 and the user has IAM administrator permissions applied, then they are limited to EC2 and S3 because that’s what the permission boundary defines.
The permission boundary cannot be applied to a group or an organization SCP either. It is specific to a specific user or role. A good use case is if you have developers who want to ability to change their permissions as needed, but you want to be able to define what is accessible and set a concrete boundary. Everything not listed per the permission boundary is explicitly denied regardless of Identity-based policy, SCP OU, resource-policy, etc.
Remember, if it is not listed as allowed there will be an implicit deny in place. For example, if you define that all S3 access is allowed via a permission boundary you have the ability to also incorporate a deny that specifies that access is not permitted to a specific bucket and any IAM user or role assigned that permission boundary will not be able to access that bucket despite the fact they have full S3 access. It is important to keep in mind with IAM, everything stacks together. What a user is able to do is defined by all active policies including Identify-based, SCP OU, resource-based, permission boundaries, etc. If a permission is allowed in all of the policies associated with that user then they are able to perform the action.
Another good use case is if you want to define boundaries for a particular user in a group or OU without adjusting permissions for the entire OU or group.