python - 使用 python 请求模块在 AWS lambda 中进行 API post 调用时遇到问题

Question

在我的 lambda 执行函数开始时连接到必要的 AWS 资源后，我有一个 lambda_handler 函数，如下所示:

def lambda_handler(event, context, dst):

    bucket = event['Records'][0]['s3']['bucket']['name']
    key = urllib.unquote_plus(event['Records'][0]['s3']['object']['key'].encode('utf8'))
    print('Bucket: %s' % bucket)
    print('Object key: %s' % key)

    crm_file_name = key.split('/')[-1]
    crm_query = make_crm_db_query(crm_file_name)
    cur = conn.cursor()
    status = cur.execute(crm_query)

    if status == 1:
        details = cur.fetchone()
        opportunity_id = details[0]

        tmp = dst.get_key('%s/%s' % (opportunity_id, crm_file_name))
        print('starting API request...')
        s = requests.Session()
        r = s.post('http://link/to/endpoint/',\
            files={'pdf': tmp}, data={'opportunity_id': opportunity_id})
        print(r)
        print(r.content)
    else:
        print('not the right file type')

在我的开发环境中，这会返回以下内容，表明发布成功:

starting API request...
<Response [201]>
{"opportunity_id":253,"pdf":"https://s3.storage.asset.com:443/253/253___PDF.pdf?Signature=[CONFIDENTIAL STUFF HERE ;)]"}

但是在 AWS Cloud Watch 日志中，进程在尝试执行发布请求时挂起。这是一个日志示例:

starting API request...
END RequestId: beedb0c4-ce07-11e6-a715-53b3bd8edccc
REPORT RequestId: beedb0c4-ce07-11e6-a715-53b3bd8edccc  Duration: 30002.89 ms   Billed Duration: 30000 ms Memory Size: 128 MB   Max Memory Used: 22 MB  
2016-12-29T20:46:24.356Z beedb0c4-ce07-11e6-a715-53b3bd8edccc Task timed out after 30.00 seconds 

S3 存储桶、API 端点和 RDS 都属于同一个 VPC。该过程在开发中有效，但在生产中挂起。关于如何调试这个的任何指示？

我检查了this post这表示与外部互联网资源的连接需要 NAT 网关，但我们的 API 端点在同一 VPC 内的 EC2 实例上运行。 AWS 是否认为我们仍在尝试建立外部连接，因为我们正在处理 API 调用？我该如何调试？

Answer 1

我遇到了同样的timeout problem ，原因如下。

AWS document :

When you add VPC configuration to a Lambda function, it can only access resources in that VPC. If a Lambda function needs to access both VPC resources and the public Internet, the VPC needs to have a Network Address Translation (NAT) instance inside the VPC.

Mark B 的评论是正确的。

我建议你可以关注这个 blog构建 NAT。