AWS API网关自定义授权者意外超时
问题描述：
我在收到来自Custom Authorizer的响应之前定期（每个〜7小时）意外等待时间。AWS API网关自定义授权者意外超时
我的系统：
- API网关终端定制授权
- 谁验证令牌一个lambda（λ-AUTH）
- 谁被称为每隔5分钟由CloudWatch的事件A的λ（拉姆达-test）
的λ-测试调用API网关端点：
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
Cloudwatch metrics of lambda-test duration: a peak every ~7h（峰高改变了，因为我前几天换了超时从2秒至4秒）
对于谁在7时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
如果有人有线索来自哪里这个授权延迟能来，那就太好了！
谢谢您的时间，
在座的各位都对系统的各部分相应的日志：
拉姆达测试：用于API1
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
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
api gateway for api2：
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
的λ-auth的对AP1的电话：
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
λ-AUTH为API2的电话：
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
您的Lambda函数是否在VPC中运行？这*可能*表明你可能在一个子网上（错误）配置与其他子网不同。 –
由自定义授权人调用的lambda-auth正在VPC中运行。 2个子网相同：在eu-central-1a中，subnet1是10.10.3.0 \ 24，而subnet2是10.10.4.0 \ 24。 它在VPC中，因为它需要访问RDS数据库（mysql）。 RDS数据库仅在eu-central-1a中，subnet1和subnet2以及MULTI-AZ = no。 那么，它可能与此有关？我不明白它为什么如此规则...... – Sablier
（安全组（出口和入口）配置合理，所以lambda可以在AZ中加入RDS） – Sablier