[t4nkd]

IAM is going to be "required" for the root account, though, shutting that away is a good practice.

In lieu of IAM you can use federated access from an identity provider like Okta. That will lease a role which can then adopt other roles (even across accounts). Okta is integrated with a more formal IT system like Active Directory and then all your accesses and identity can be managed by them. I think this is the AWS side doc for the setup https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...

I also know Nike does something very similar and shared about it here https://github.com/Nike-Inc/gimme-aws-creds including the Okta side documentation.

[zxcvbn4038]

Now I understand - you are talking about IAM users versus assumed roles, instance roles, and the like. Definitely a best practice to utilize those over IAM users but you never get away from IAM entirely, its the corner stone of all access control within AWS. Difference is that with assumed roles and similar you get short lived credentials that need to be renewed periodically (usually behind the scenes) whereas IAM user credentials exist until you remove them (though best practice is to rotate them periodically.) There are some instances where you can't get away from them easily - remote access to S3 buckets is a biggie, even though I can get assumed role credentials through my identity provider, I've yet to find an S3 client (besides the cli) that can utilize them. Access to SES for applications that need raw SMTP credentials from an IAM user. My CDN can make requests to S3 buckets with AWS v2 signatures, that needs IAM user credentials also (though the actual policy is limited to the buckets with public content and only getting known objects, no listing).