当前位置: 首页 > 知识库问答 >
问题:

AWS API网关自定义授权程序意外超时

芮承运
2023-03-14

在收到定制授权人的响应之前,我经常(每~7小时)有意外的等待时间。

我的系统:

  • 具有自定义授权者的API网关终结点
  • 验证令牌的lambda(lambda auth)
  • 每5分钟被cloudwatch事件调用一次的lambda(lambda测试)

lambda测试调用api网关endpoint:

response1 = requests.get(api1, auth=AUTH, timeout=4)
response2 = requests.get(api2, auth=AUTH, timeout=4)

每~7小时,两个请求都会超时,如cloudwatch日志所示:

07:22:11 START RequestId: beabb449-a41d-11e7-8469-93a8731ae2d8 Version: $LATEST
07:22:16 HTTPSConnectionPool(host='<host>', port=443): Read timed out. (read timeout=4)
07:22:20 HTTPSConnectionPool(host='<host>', port=443): Read timed out. (read timeout=4)
07:22:20 END RequestId: beabb449-a41d-11e7-8469-93a8731ae2d8
07:22:20 REPORT RequestId: beabb449-a41d-11e7-8469-93a8731ae2d8 Duration: 8407.03 ms Billed Duration: 8500 ms Memory Size: 128 MB Max Memory Used: 36 MB 

lambda测试持续时间的Cloudwatch指标:每~7小时出现一个峰值(峰值峰值的变化是因为几天前我将超时时间从2秒更改为4秒)

对于07:22:11发生的请求

07:22:11 start lambda-test
07:22:11 try to connect to api1
07:22:12 start authorizer for api1's call
07:22:16 lambda-test: api1 timeout
07:22:16 try to connect to api2
07:22:16 start authorizer for api2's call
07:22:19 start lambda-auth for api1's call
07:22:19 end lambda-auth for api1's call
07:22:19 authorizer sucessfull for api1's call
07:22:19 start lambda-auth for api2's call
07:22:20 end lambda-auth for api2's call
07:22:20 authorizer sucessfull for api2's call
07:22:20 lambda-test: api2 timeout
07:22:20 end lambda-test

如果有人暗示这个授权程序延迟可能来自哪里,那就太好了!

谢谢你抽出时间,

以下是系统各部分的所有相应日志:

lambda试验:

07:22:11 START RequestId: beabb449-a41d-11e7-8469-93a8731ae2d8 Version: $LATEST
07:22:16 HTTPSConnectionPool(host='<host>', port=443): Read timed out. (read timeout=4)
07:22:20 HTTPSConnectionPool(host='<host>', port=443): Read timed out. (read timeout=4)
07:22:20 END RequestId: beabb449-a41d-11e7-8469-93a8731ae2d8
07:22:20 REPORT RequestId: beabb449-a41d-11e7-8469-93a8731ae2d8 Duration: 8407.03 ms Billed Duration: 8500 ms Memory Size: 128 MB Max Memory Used: 36 MB 

api1的api网关:

07:22:12 Starting authorizer: 2szewn for request: bee365d6-a41d-11e7-9709-8d6614596919
07:22:12 Incoming identity: ********************************************************YzNw==
07:22:19 Using valid authorizer policy for principal: ****E_1
07:22:19 Successfully completed authorizer execution
07:22:19 Verifying Usage Plan for request: bee365d6-a41d-11e7-9709-8d6614596919. API Key: API Stage: 41clweydfc/dev
07:22:19 API Key authorized because method 'GET /api1' does not require API Key. Request will not contribute to throttle or quota limits
07:22:19 Usage Plan check succeeded for API Key and API Stage 41clweydfc/dev
07:22:19 Starting execution for request: bee365d6-a41d-11e7-9709-8d6614596919
07:22:19 HTTP Method: GET, Resource Path: /api1
07:22:20 Successfully completed execution
07:22:20 (bee365d6-a41d-11e7-9709-8d6614596919) Method completed with status: 200

api2的api网关:

07:22:16 Starting authorizer: 2szewn for request: c15724e7-a41d-11e7-811a-6dd1376e9475
07:22:16 Incoming identity: ********************************************************YzNw==
07:22:20 Using valid authorizer policy for principal: ****E_1
07:22:20 Successfully completed authorizer execution
07:22:20 Verifying Usage Plan for request: c15724e7-a41d-11e7-811a-6dd1376e9475. API Key: API Stage: 41clweydfc/dev
07:22:20 API Key authorized because method 'GET /api2' does not require API Key. Request will not contribute to throttle or quota limits
07:22:20 Usage Plan check succeeded for API Key and API Stage 41clweydfc/dev
07:22:20 Starting execution for request: c15724e7-a41d-11e7-811a-6dd1376e9475
07:22:20 HTTP Method: GET, Resource Path: /api2
07:22:20 Successfully completed execution
07:22:20 Method completed with status: 200

ap1呼叫的lambda身份验证:

07:22:19 START RequestId: beeadfbb-a41d-11e7-82fd-cf842bd93e85 Version: $LATEST
07:22:19 END RequestId: beeadfbb-a41d-11e7-82fd-cf842bd93e85
07:22:19 REPORT RequestId: beeadfbb-a41d-11e7-82fd-cf842bd93e85 Duration: 195.75 ms Billed Duration: 200 ms Memory Size: 128 MB Max Memory Used: 25 MB 

用于api2的呼叫的lambda-auth:

07:22:19 START RequestId: c15db514-a41d-11e7-88e3-1f6800c6e34e Version: $LATEST
07:22:20 END RequestId: c15db514-a41d-11e7-88e3-1f6800c6e34e
07:22:20 REPORT RequestId: c15db514-a41d-11e7-88e3-1f6800c6e34e Duration: 78.51 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 25 MB 

共有1个答案

公西马鲁
2023-03-14

这可能是由于aws-lambda杀死了VPC,是时候重新弥补了。(参见亚马逊aws论坛)

增加超时时间解决了这个问题。

 类似资料:
  • 我是API网关的新手。我尝试使用“自定义授权程序”。我遵循了下面的文档,并使用了网站提供的示例代码。https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html “令牌类型的lambda授权者”是工作的。 但是... 我对“请求类型”感到困惑,不知道如何将quer

  • Mono Apr 10 09:42:35 UTC 2017:转换后的endpoint请求主体:{“Type”:“Token”,“AuthorizationToken”:“ABC123”,“MethodArn”:“arn:aws:execute-api:ap-southeast-1:007183653813:OHLQXU9P57/null/Get/”}Mono Apr 10 09:42:36 UTC

  • 但是看起来在我的lambda响应和API网关之间发生了一些奇怪的事情, 变量在内部的某个地方被压缩得更低, 而我仍然得到了相同的解析错误, 它会接受其他格式的响应吗?字符串也不起作用。 我还应该尝试什么?我的策略格式错误吗? 我从这些站点获得了两种不同的策略格式- 1。http://docs.aws.amazon.com/apigateway/latest/developerguide/use-c

  • 如何从API网关中的自定义授权器lambda函数获取日志记录?我不想为API启用日志记录。我需要从授权器lambda函数日志记录。我使用了一个python lambda函数,并且在代码中有打印。我想查看云观察日志中的指纹。但在云观察中看不到原木。我也没有错误。我缺少什么? Lambda有execution role role/service-role/mylambdarole。此角色具有写入clo

  • 我已经创建了一个Lambda函数,在我的一个APIendpoint的方法请求上,我将其配置为“自定义身份验证”。当我使用AWS API网关的“test”函数时,我在日志输出中没有看到Lambda函数的任何输出。 我已经部署了API。 然而,有些事情正在发生,因为当我使用配置的自定义域名命中apiendpoint时,我得到了 但是,如果我从该endpoint删除“自定义身份验证”并点击同一endpo

  • 首先,我对AWS很陌生。从非常基本的API网关+Lambda集成开始。下面是我的用例。 > 与API网关创建了一个Lambda代理集成请求,GET请求输出通过查询参数传递的2个数字的相加。现在,如果我访问这个API网关endpoint,我将获得所需的结果。 现在我已经创建了自定义授权器,它反过来是对另一个lambda的调用。因此请求将在到达API网关endpoint之前由授权者lambda验证。在