Amazon Cognito user pool group roles to grant s3 access based on each group

I have a question regarding creating a generic role with policies that uses a variable identifying the Cognito user group.

Since it's hard to understand from the statement above, here is an example of what I want to achieve. Currently I manage my users using Cognito. These users can be added to "groups", and each group has a folder in my s3 bucket. Each user can be part of 0:n groups, and each group has exactly one folder in s3.

From what I have seem, I could achieve that by creating a different IAM Role for each group, with the permission for the specific folder, but since the number of groups can become large very quickly, I'm afraid the quota of IAM Roles would be exceeded pretty fast. That's when I learned about using one generic IAM Role that changes based on the user, you can check that here. In this link I can see that I can could have one folder in my s3 bucket for each user, by using ${cognito-identity.amazonaws.com:sub} in the IAM Role. Is there any way to achieve this same behaviour for a user group, instead of only one user?

Example:

• Group 1: User 1, User 2
• Group 2: User 2, User 3

Folder 1:

• User 1, 2 has access to files

Folder 2:

• User 2, 3 has access to files

Possible solutions I thought that I consider not viable or not ideal:

• Create one folder on s3 for each user and upload each file on the folder of each user who has access. Problem: a lot of duplicate files, unnecessary complication for handling the same files in different places.
• Create one folder on s3 for each user group and files would be uploaded to the respective group folder in s3. Problem: Creating one IAM Role for each group isn't viable, since we have a limit of how many roles can be created per aws account.
• Create a custom backend to handle which user has access to each file, get the s3 file and return to the user. Problem: Unnecessary additional request that will affect the time to get the file.
• Create a custom backend to return a signed url if the user has access to the requested file. Problem: Unnecessary additional request and potential vulnerability by creating an url public (even if it's only valid for a period of time)