AWS API網關自定義授權者意外超時

Question

我在收到來自Custom Authorizer的響應之前定期（每個〜7小時）意外等待時間。

我的系統：

• 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 

Answer 1

這可能是由於VPC由AWS-拉姆達和殺時間再次補充。 （cf. amazon aws forums）

增加超時解決了問題。