¿Cuándo usarías un rol de IAM en lugar de un usuario de IAM?

Usa roles casi siempre. Un rol proporciona credenciales de vida corta que un servicio, una carga de trabajo o una persona federada asume bajo demanda, así que no hay ninguna clave estática que filtrar o rotar. Los usuarios de IAM implican claves de acceso de vida larga, que deberían limitarse a sistemas que genuinamente no pueden federarse. Para personas, usa single sign on con asunción de rol; para sistemas de CI, usa federación OIDC para intercambiar el token del job por un rol.

Mi opción por defecto son roles para todo, porque las credenciales son temporales y se emiten bajo demanda, así que no hay nada en un fichero de configuración esperando a que lo suban a un repositorio. Una carga de trabajo en la nube recibe un rol asociado a la instancia, la tarea o la función y recoge las credenciales del servicio de metadatos. Una persona llega ahí a través de single sign on, asumiendo un rol para una sesión con caducidad. Un pipeline de build fuera de la nube usa federación de identidad, así que el job presenta un token firmado de su proveedor y lo intercambia por un rol acotado que dura minutos. Eso último eliminó el último conjunto de claves estáticas que teníamos. Los usuarios de IAM los reservo para los casos genuinamente tercos, normalmente una integración vieja de un tercero que solo sabe recibir una clave y un secreto, y esos se acotan a una acción sobre un recurso, se rotan de forma periódica y se monitorizan. Cuando heredo una cuenta, una de las primeras cosas que hago es sacar el credential report y cazar claves que tienen años y siguen activas.