STANDARD BEHAVIOUR
There should be a single Authorization Server (AS) that your apps talk to. Partitioning users can be done for advanced purposes, such as multi-tenancy or storing Personally Identifiable Information (PII) in different databases per region.
Q1
A Cognito user pool is an entire Authorization Server - I would aim to use only one if possible, since this will keep the code in your apps simple.
If you have to proceed with a single app using multiple user pools, aim to get the API client to send you a hint that enables you to know which one is being used - perhaps via a value in a custom header during API requests:
- x-mycompany-user-region: EU
- x-mycompany-partner-id: ABC
This will enable you to implement a basic kind of content based routing. This type of header is only for routing and should be ot be used for security.
It is also possible to put a reverse proxy in front of Cognito to do this type of job - see this Curity article for details on this type of approach, where claims are used to route requests.
Q2
Yes - use access tokens containing or referencing scopes and claims. Note that Cognito may not allow you to customize access token JWT contents.
A way to get custom claims can be to send the access token to the user info endpoint, then cache results in the authorizer, as you seem to be doing. If it helps, see also this code of mine.
Q3
An ID token is a digitally verifiable assertion given to a UI as proof of authentication. It should not be used for authorization in APIs. It may be that Cognito has better support for customizing ID tokens - but it is not correct in OAuth terms (eg expiry is too long / no support for scopes).