Zero Trust architecture with API Gateway, Lambda and Cognito Identity pools

0

Our application uses a custom vue amplify frontend and the main application does the following steps:

  • login towards cognito userpools.
  • With the received idToken you call a Rest API Gateway with a custom autorizer.
  • API Gateway does to request to the lambda microservice.
    • The lambda itself does not have any permissions
    • We do basically a assumerolewithwebidentity
    • and call with those credentials the services we want to use.

The big downside of this approach is the latency we add to the lambda execution. From our ~ estimation it's about 2-300ms for the new cognitoIdentityPoolClient.

Does anyone else have such an architecture? Does it make sense in your opinion?

2 Answers
0

I have some comments: 1)Consider usage of access tokens instead of if tokens as part of sending bearer tokens to api 2) you may want to front api gw with cloudfront https://repost.aws/knowledge-center/api-gateway-cloudfront-distribution to try to mitigate latency 3)it is unclear from your description, but you may want to use a cognito authorizer https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html instead of a custom (lambda) authorizer

profile picture
EXPERT
answered 4 months ago
profile picture
EXPERT
reviewed a month ago
  • Thanks for the reply, I'm looking if I can replace my custom authorizer with the cognito authorizer, but depending on the policy I'm returning there I maybe need to stay on custom authorizer.

    The whole latency issue comes after the api gw within the lambda, e.g. if the lamdba accesses something from a dynamdb or creates a s3 presigned url. I don't get how cloudfront will help here since nothing can be cached anymore.

  • Cloudfront can cache content and response api so it would not even reach the api gateway, nor the backend. If then your issue is about latency on lambda, maybe you should focus on optimixing lambda by tweaking its properties (memory, size), making sure you use gateway/interface vpc endpoints

0

Have you considered provisioning the execution role to the Lambda? If your Lambda is currently calling multiple services or performing multiple pieces of business logic, you would likely want to break the logic of your Lambda down into smaller components. Each with its own specific functionality and execution role that you can map to a user role in your application. Use that user role to determine which Lambda’s a user can call. This does potentially add complexity, you need to maintain user roles and which Lambda they provide access to, but it would remove the added latency. You could look at Amazon Verified Permissions to help reduce the overhead of permissions management.

I think either approach is valid, it just depends on which tradeoffs better align with your requirements.

AWS
answered 4 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions