2 Answers
When a user assumes a role, that user will be granted access. However, when an EC2 assumes a role any application running on that instance or user logged will use that role and be granted access.
The most common use cases for assigning a role to an EC2 instance are for apps or OS services running on the instance to access AWS services without a login session (no users logged in to the instance). This should be used only when needed and not for all apps running on an instance. If you have apps running on an EC2 instance that support service accounts use them to authenticate against AWS services. That’s a more secure method than assigning roles to an instance.
This is why the policy is important. Consider S3 for example. Maybe you have a role that a user can assume to create and edit buckets that you want a user to assume only in rare circumstances, and you don’t want to give anyone blanket permissions to do this by default with their account. You can create a role, and give certain administrators access to assume this role.
Conversely, if you have an application running in EC2 that you want to be able to write to a certain S3 location, you shouldn’t apply that same role to this EC2 instance. Create a new policy document, providing write access to the specific path within that one S3 bucket only, and apply it to your application. Application permissions are usually very specific and predictable, so the policy should be created as such