I think the usual part of AWS IAM is simple. You develop your app, it uses a Lambda role or an ECS task role, and you keep adding permissions to the role as needed. When you query a new table in DynamoDB, your app won't work until you add the missing permission. You always add those permissions to the CDK/CloudFormation definition of the role, so that the role works in any AWS account the app is deployed to. CDK actually handles most of this automatically, as you define the relationships between your cloud resources.
The more complicated stuff starts happening when you have many services that need to access each other's resources directly. Then you need to think a bit more about the architecture and how you expose resource names, managed policies and roles between services. It's no longer just simple role definitions within the CloudFormation stack, but you have to pass around account identifiers, regions and resource ARNs in the configuration.
The more complicated stuff starts happening when you have many services that need to access each other's resources directly. Then you need to think a bit more about the architecture and how you expose resource names, managed policies and roles between services. It's no longer just simple role definitions within the CloudFormation stack, but you have to pass around account identifiers, regions and resource ARNs in the configuration.