AWS IAM is interesting in that IAM resources are provisioned within a subscription. You can use IAM as an identity solution, giving everyone a user account and password, but you don't have to. Internally at AWS, we never used IAM users, but instead had an enterprise AD deployment that we used to log in to our computers and internal systems. One of those internal systems kept a list of AWS subscriptions and IAM roles you had access to, and would trade your AD credentials for temporary AWS credentials scoped to a role. It was pretty slick, but it's not inherent to IAM, so you typically need a third party service to do this for you. (At the job I had in between AWS and Microsoft, we used CloudTamer, and before that, we just had to keep track of 20 different username/password pairs.)
AAD on the other hand is a full blown identity platform that incidentally can also be used to log in to Azure. That means it integrates nicely with on-prem AD deployments and, more importantly, lets users log in once and navigate the subscriptions to which their account has been granted access. So it's actually simpler to use if you just need to be able to log in to multiple subscriptions, but you can run into cases where you need to operate on AAD resources in ways that aren't supported through Azure APIs. This primarily comes up if you need to grant a non-Azure permission as part of an Azure deployment. E.g., if you want to give a managed identity permission to read AAD metadata like service principal IDs, you can't do it from within ARM.