Wann würdest du eine IAM Role statt eines IAM User einsetzen?

Nimm fast immer Rollen. Eine Rolle liefert kurzlebige Credentials, die ein Service, ein Workload oder ein föderierter Mensch bei Bedarf assumed, es gibt also keinen statischen Key, der leaken oder rotiert werden müsste. IAM User bedeuten langlebige Access Keys, und die sollten auf Systeme beschränkt bleiben, die wirklich nicht föderieren können. Für Menschen nimmst du Single Sign-on mit Role Assumption, für CI-Systeme OIDC-Federation, die ein Job-Token gegen eine Rolle tauscht.

Mein Default sind Rollen für alles, weil die Credentials temporär und on demand ausgestellt sind, es liegt also nichts in einer Config-Datei herum und wartet darauf, in ein Repository committet zu werden. Ein Workload in der Cloud bekommt eine Rolle an Instanz, Task oder Function gehängt und holt sich die Credentials vom Metadata Service. Ein Mensch kommt über Single Sign-on dahin und assumed eine Rolle für eine Session mit Ablaufzeit. Eine Build-Pipeline außerhalb der Cloud nutzt Identity Federation, der Job legt also ein signiertes Token seines Providers vor und tauscht es gegen eine eng geschnittene Rolle, die Minuten hält. Genau das hat bei uns den letzten Satz statischer Keys eliminiert. IAM User behalte ich für die wirklich sturen Fälle, meistens eine alte Drittanbieter-Integration, die nur Key und Secret versteht, und die werden auf eine Aktion auf einer Ressource zugeschnitten, planmäßig rotiert und überwacht. Wenn ich einen Account übernehme, ziehe ich als eine der ersten Aktionen den Credential Report und suche nach Keys, die Jahre alt und immer noch aktiv sind.