You have to use IAM, but if you're feeling particularly rebellious then you can setup one Admin account and one API account with liberal permissions and never touch IAM again. For obvious reasons it wouldn't be recommended...

I know that you said "For obvious reasons it wouldn't be recommended..." but for anyone else reading please do not do this under any circumstances. If any of your applications get compromised the attacker will have full control of your entire AWS account.

Can you please share those tweets? IAM is kind of a critical piece in AWS Security :) What comes to mind is perhaps people recommending to use IAM Roles instead of IAM Users. (which has a lot of benefits, these are temporary credentials and you don't need to pass things as env vars / config files etc, lowers the risk of accidentally pushing creds to source code etc)

lol, I found them but I was wrong, sorry.

They said, they don't use AMIs and not IAM.

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.

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).