如何将AWS API Gateway的aws_request_id传递给SQS触发的Lambda函数

最优方案是使用SQS原生的**消息属性（Message Attributes）**传递API Gateway的request_id这类元数据，不需要侵入业务消息体，符合AWS服务设计规范。

1. 调整API Gateway侧SQS消息发送逻辑 #

调用send_message接口时，将aws_request_id放到MessageAttributes参数中，业务消息体不需要做任何修改：

import json

msg_body = [你的业务数据]
response = queue.send_message(
    MessageBody=json.dumps(msg_body),
    # 新增消息属性传递元数据
    MessageAttributes={
        'apigw_request_id': {
            'StringValue': context.aws_request_id,
            'DataType': 'String'
        }
    },
    MessageGroupId=msg_group_id,
    MessageDeduplicationId=msg_deduplication_id
)

2. 调整SQS Lambda侧读取逻辑 #

消息属性会直接包含在Lambda event的Records字段中，不需要解析业务消息体即可获取：

import json
import logging

log = logging.getLogger()

def my_sqs_handler(event, context):
    records = event.get('Records', [])
    for record in records:
        log.info('Processing SQS message: %s', record['messageId'])
        # 正常解析业务消息体，和元数据完全解耦
        body = json.loads(record.get('body', '{}'))
        # 直接从record的消息属性中取request_id
        apigw_request_id = record['messageAttributes']['apigw_request_id']['stringValue']
        log.info('API Gateway request-id: %s', apigw_request_id)
        # 后续业务逻辑
        ...

方案优势 #

• 元数据和业务数据完全解耦，不会污染业务消息结构，后续调整元数据传递规则不需要修改业务消息的解析逻辑
• 符合SQS的设计规范，消息属性是AWS官方指定的元数据存储位置
• 支持直接基于消息属性做SQS消息过滤，不需要额外解析消息体，成本更低、性能更好
• 对于FIFO队列，消息属性不会参与消息去重计算，不影响原有队列的分组、去重规则

补充说明：不存在直接将上游上下文嵌入SQS Lambda的event/context对象的机制，因为Lambda的context是运行时生成的独立上下文，跨服务的自定义上下文必须通过中间传递介质（SQS消息）携带，消息属性是当前最优的传递方式。

内容的提问来源于stack exchange，提问作者Gatmando