IAM in Service Catalog
If you're wanting to leverage the integrated platform services from AWS you must use them as they were intended to be used otherwise you may end up implementing OAuth/OIDC tokens in the wrong context and make your app much less secure than you had hoped. Also, AWS services must be configured in a way that implements the protocols available at the UW IdP (SAML or OIDC). Some options can be more of an enabler than others but also come at an increase in cost and complexity.
All of these options (SAML or OIDC) require you to register your client ahead of time with UW-IT IAM. If you are using SAML in these options below where its available then normal SP Registry process applies, otherwise contact firstname.lastname@example.org about alpha testing OIDC options.
If you have a simple app (Lambda, Instance Id or IP) and want simple assurance that your end user has authenticated with the UW IdP then use this option. The ALB handles end user authentication using OIDC and then passes to your backend target an http header which includes the OIDC Id token which includes the users netid and any claims that you requested during client registration (UW Groups etc). This can be easily integrated with R53 to enable lambdas as targets without the need for API Gateway. With this kind of architecture you set trust within your VPC between your lambdas and the ALB.
The solution is less expensive than Cognito User Pools (below) and instead uses Cognito Identity Pools. This solution permits direct calls to AWS services based on the IAM policies/roles (using STS) that you define on a per registered SAML or OIDC client basis.
If you are designing a suite of micro-services where you have various applications in front of them, each of which may be calling your micro-services with different authorization scopes then you should use Cognito User Pools with a federated SSO (OIDC or SAML). This enables you to define your own OAuth 2.0 clients using Cognito and then have very tight integration with API Gateway and Lambda's.
In essence, you implement the OIDC protocol, specifically the role of the Relying Party (RP) in a Lambda. You can route http requests to your Lambda using API Gateway or an Application Load Balancer. When doing that they can be set to send all traffic and are really only used to give your Lambda a URL. Optionally, you can use a Custom Lambda Authorizer to protect some of your routes with code that you write. This code could implement the OIDC protocol or provide a light weight authorization layer by looking at claim attributes in an OIDC id token.