解决AWS API Gateway+Lambda容器部署超30秒冷启动问题

问题背景 #

通过Docker容器部署搭配API Gateway的Lambda函数时，首次请求触发的冷启动耗时过长，直接超出API Gateway的30秒响应限制，导致请求失败。本地使用sam local start-api测试无异常，已尝试将Lambda内存提升至3008MB，但问题未解决。

技术栈 #

• FastAPI
• Mangum
• API Gateway
• AWS Lambda
• AWS SAM（部署工具）

配置文件 #

SAM部署模板 #

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  demo

Resources:
  AppFunction:
    Type: AWS::Serverless::Function
    Properties:
      Timeout: 118
      MemorySize: 3008
      CodeUri: app/
      PackageType: Image
      Events:
        ApiEvent:
          Properties:
              RestApiId:
                  Ref: FastapiExampleGateway
              Path: /{proxy+}
              Method: ANY
              Auth:
                ApiKeyRequired: true
          Type: Api
    Metadata:
      Dockerfile: Dockerfile
      DockerContext: .
      
  FastapiExampleGateway:
    Type: AWS::Serverless::Api
    Properties:
        StageName: prod
        OpenApiVersion: '3.0.0'
        # Timeout: 30
    Auth:
      ApiKeyRequired: true
      UsagePlan:
        CreateUsagePlan: PER_API
        UsagePlanName: GatewayAuthorization

Outputs:
  Api:
    Description: "API Gateway endpoint URL for Prod stage for App function"
    Value: !Sub "https://${FastapiExampleGateway}.execute-api.${AWS::Region}.amazonaws.com/Prod/"

依赖清单 #

jsonschema==4.16.0
numpy==1.23.3
pandas==1.5.0
pandas-gbq==0.17.8
fastapi==0.87.0
uvicorn==0.19.0
PyYAML==6.0
SQLAlchemy==1.4.41
pymongo==4.3.2
google-api-core==2.10.1
google-auth==2.11.0
google-auth-oauthlib==0.5.3
google-cloud-bigquery==3.3.2
google-cloud-bigquery-storage==2.16.0
google-cloud-core==2.3.2
google-crc32c==1.5.0
google-resumable-media==2.3.3
googleapis-common-protos==1.56.4
mangum==0.11.0

Dockerfile #

FROM public.ecr.aws/lambda/python:3.9

WORKDIR /code

RUN pip install pip --upgrade

COPY ./api/requirements.txt /code/api/requirements.txt

RUN pip install --no-cache-dir -r /code/api/requirements.txt

COPY ./api /code/api

EXPOSE 7777

CMD ["api.main.handler"]

ENV PYTHONPATH "${PYTHONPATH}:/code/"

生成镜像大小为250MB。

问题排查与解决方案 #

Mangum本身并非冷启动慢的核心原因，问题通常出在镜像体积、依赖加载效率、Lambda初始化逻辑等环节，以下是针对性优化方案：

1. 优化Lambda初始化逻辑 #

确保FastAPI实例、路由注册等初始化操作放在Lambda handler函数之外的全局作用域，冷启动时仅执行一次，而非每次请求都重新初始化：

# api/main.py
from fastapi import FastAPI
from mangum import Mangum

# 全局初始化，冷启动阶段执行
app = FastAPI()

@app.get("/")
def read_root():
    return {"Hello": "World"}

# 最后初始化Mangum handler
handler = Mangum(app)

2. 压缩Docker镜像体积 #

使用多阶段构建减少镜像冗余，改用更轻量的slim基础镜像：

# 构建阶段：安装依赖
FROM public.ecr.aws/lambda/python:3.9 AS builder

WORKDIR /code
RUN pip install --upgrade pip
COPY ./api/requirements.txt .
# 将依赖安装到单独目录，便于后续复制
RUN pip install --no-cache-dir -r requirements.txt -t /opt/python/lib/python3.9/site-packages/

# 运行阶段：仅保留必要文件
FROM public.ecr.aws/lambda/python:3.9-slim

WORKDIR /code
# 复制构建好的依赖
COPY --from=builder /opt/python/lib/python3.9/site-packages/ /opt/python/lib/python3.9/site-packages/
COPY ./api /code/api

ENV PYTHONPATH "${PYTHONPATH}:/code/"
CMD ["api.main.handler"]

3. 启用Lambda SnapStart #

SnapStart通过预初始化函数并创建快照，冷启动时直接加载快照，可大幅缩短启动时间。修改SAM模板中AppFunction的配置：

AppFunction:
  Type: AWS::Serverless::Function
  Properties:
    Timeout: 118
    MemorySize: 3008
    CodeUri: app/
    PackageType: Image
    # 添加SnapStart配置
    SnapStart:
      ApplyOn: PublishedVersions
    # 其他属性保持不变

注意：启用后需要发布函数版本，并确保API Gateway指向该版本/别名。

4. 精简依赖与优化导入 #

• 移除不必要的依赖：比如numpy、pandas这类大型数据处理库，若业务非必需可直接删除；
• 升级Mangum版本：当前使用的0.11.0版本较旧，升级至最新稳定版（如0.17.x）可获得性能优化；
• 延迟非核心依赖导入：将非启动必需的依赖（如数据库客户端）延迟到第一次请求时导入，减少冷启动阶段的加载时间。

5. 定位耗时瓶颈 #

通过CloudWatch日志或代码埋点，精准定位冷启动中的耗时环节：

# api/main.py
import logging
import time

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# 记录依赖导入耗时
start = time.time()
from fastapi import FastAPI
logger.info(f"FastAPI导入耗时: {time.time() - start:.2f}s")

start = time.time()
import pandas
logger.info(f"pandas导入耗时: {time.time() - start:.2f}s")

# 记录应用初始化耗时
start = time.time()
app = FastAPI()
logger.info(f"FastAPI实例初始化耗时: {time.time() - start:.2f}s")

handler = Mangum(app)

查看CloudWatch中的REPORT日志，重点关注Init Duration字段，结合自定义日志定位问题。

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