Cognito authentication on ALB

SSL Offloading and Cognito Authentication at ALB A: Since NLB B cannot handle SSL termination or Cognito authentication, the best approach is to handle both SSL offloading and Cognito authentication at ALB A (in VPC A), then forward the traffic to NLB B.

Here’s how you can achieve this:

SSL Offloading at ALB A:

ALB A will terminate the SSL connection from the client, decrypt the traffic, and forward the HTTP requests to NLB B using a non-SSL connection (HTTP). Cognito Authentication at ALB A:

ALB A can be configured to integrate with Amazon Cognito for user authentication. This is done by setting up Cognito User Pools in the ALB's authentication configuration.

ALB will authenticate the incoming requests using Cognito before forwarding them to NLB B. Since ALB operates at Layer 7, it can handle Cognito authentication seamlessly.

Forward Traffic to NLB B:

After SSL offloading and Cognito authentication, ALB A can forward the traffic to NLB B over HTTP (since the SSL has been offloaded).

NLB B's Role: NLB B just forwards the traffic (now HTTP) to your targets (EC2 instances, containers, etc.) in VPC B.

Option 1 (SSL offloading at ALB A and Cognito authentication at NLB B): Not possible, since NLB B cannot handle HTTP-based authentication like Cognito. Option 2 (SSL offloading and Cognito authentication at NLB B): Not possible, since NLB does not support SSL offloading or HTTP/S-based authentication.

The best solution is to offload SSL and perform Cognito authentication at ALB A, and then forward the traffic to NLB B over HTTP.

Stacking the ALBs isn't a good design, and I'm not sure if it could even be made to work. The second ALB performing the Cognito authentication would have to send the user to Cognito to be authenticated, and Cognito would need to redirect the user to the ALB with the authentication token. This involves the ALB and Cognito referring to each other by DNS name, and the standard design is that a single ALB is configured to use a single Cognito user pool. With a second ALB doing the authentication, the redirect to Cognito would come from the second ALB, while the user would be connected to the first ALB. It might be possible to get it to work, if both ALBs are aware of the same HTTP Host header, but it would be an obscure and complex setup at best.

I'd advise preferring the standard AWS design, with a single ALB performing the Cognito authentication and either facing the users directly or, if it's internet-facing, placing the ALB behind a CloudFront distribution. Having a CloudFront distribution between the user and ALB is supported when properly configured (https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#cloudfront-requirements), but note that the connection over which the ALB receives the request that is to be authenticated against Cognito must be encrypted, received via an HTTPS listener. The ALB won't allow cleartext, unencrypted HTTP requests to be authenticated against Cognito. I would think the application team having an ACM-issued certificate on their ALB shouldn't be hard to manage, because ACM will take care of the heavy lifting related to TLS.