Firstly, I would like to mention that a scope is a level of access that an app can request to a resource. The scopes are not based on individual users, groups etc, rather they are defined on an app-level.
For example if you have a resource server for photos, it might define two scopes: one for read access to the photos and one for write/delete access. When the app makes an API call to request access and passes an access token, the token will have one or more scopes embedded inside of it.
Secondly, coming to an app itself, an app/app-client (these two terms are used interchangeably) is an entity within a user pool that has permission to call unauthenticated API operations. You can create multiple apps for a user pool. Typically, an app corresponds to the platform of an app. For example, you might create an app for a server-side application, a different Android app and a different iOS app etc. Each app has its own app client ID.
It is in the app client settings, where you define what scopes are allowed. For example - read_product, delete_product etc.
Now, say for example, if a user only had access to your Android platform (android app client) and that app client had only read_product scope allowed in app client settings. Then the User accessing this Android platform (app client) can only get an access token which has the scope read_product allowed. Hence, thereby restricting their access to only the read access to the resource server. Where as you could have another platform (another app client under the same Cognito Userpool) which allows all scopes of the resource server.
Hence, to reiterate, scope is a level of access that an app can request to a resource. It all comes down to the developer to decide what platform (app client) has what scopes allowed (that one will get in access token), and which base of users get the access to which specific platforms (app clients) to exercise the granular restricted access. Please note, that each app client has its own unique ID, hence you can differentiate the app clients/platforms from each other even when they are found to be under the same Cognito Userpool.
Now coming to your query -
"Admin group will have access to all the scopes in the resource server."
This is only true when the app client settings for the specific platform (app client) accessed by the Admin group Users has all the scopes allowed in configuration.
"But I want to restrict certain scopes to users group."
Currently the scope configuration for Cognito is based on app client/platforms not on individual/group level. The end user (on successful authentication) gets the access token vended for the specific platform/app client in consideration to what scopes were actually allowed for that platform/app client.
You should be providing the Admin's platform (app client) access to the Admin Users, while providing a separate platform (another app client under the same cognito userpool) with less permissive allowed scopes access to the other group's Users.
"Can we able to achieve this in cognito user pool ?"
You can create your own OAuth2.0 resource servers, and define custom scopes within them. Custom scopes can then be associated with an app client, and the app client can request those scopes in OAuth2.0 authorization code grant flow, implicit flow, and client credentials flow. Finally, the end user accesses these app clients/platforms which are defined with what scopes they are actually allowed. So the association of scope is on the app-client/platform level with which the end users interact with at the end of the day.
Finally, one last note, all of the above discussed information touches upon the multi tenancy application practices which are mentioned in details here for your reference -
Multi-tenant application best practices - https://docs.aws.amazon.com/cognito/latest/developerguide/multi-tenant-application-best-practices.html
App Client based multi tenancy specifically can be found here - https://docs.aws.amazon.com/cognito/latest/developerguide/application-client-based-multi-tenancy.html
You could implement your own authorization service and call it with the Pre token generation Lambda trigger:
You can use this AWS Lambda trigger to customize an identity token before Amazon Cognito generates it. You can use this trigger to add new claims, update claims, or suppress claims in the identity token.
Cognito User Pool Groups and retrieving IAM from LambdaAccepted Answerasked 5 years ago
Cognito groups- allow admin group to remove a user from a Cognito groupasked 3 months ago
Cognito user pool OIDC federation: Add "acr_values" parameters in OIDC flow requestsasked 2 months ago
RBAC for API Gateway endpoints using Cognito user groupsAccepted Answerasked 10 months ago
Add new user to user pool groups as Adminasked 19 hours ago
unique identities in cognito user poolasked 8 months ago
Mass Import of Users to Cognito User PoolAccepted Answerasked 3 years ago
Move Cognito user pool to another account?asked 5 months ago
Restrict access to the users in groups via scope in cognito user poolAccepted Answerasked 9 months ago
API Gateway: Using a Cognito User Pool authorizer to inject userid and email into requestAccepted Answerasked 2 months ago