解决大请求负载限制：替换Lambda、规避API Gateway的可行方案

一、采用Fargate绕过API Gateway #

• 部署Fargate服务时，直接通过**Application Load Balancer（ALB）**对外暴露端点。ALB默认请求体限制为1MB，但可通过配置将上限提升至400MB，完全满足20MB的请求需求。
• 架构可调整为：Client → ALB → Fargate（替代原Lambda）；若需保留GraphQL Router，可调整为Client → ALB → GraphQL Router → Fargate，直接跳过全局及子服务层的API Gateway。
• Fargate本身无请求体大小硬限制，只要ALB配置到位，即可处理20MB请求。

二、其他无请求大小限制的计算实例选项 #

• EC2实例：直接在EC2上部署服务，搭配调整好请求限制的ALB使用。EC2本身对请求体大小无限制，完全由部署的服务框架和负载均衡配置决定，灵活性最高。
• ECS EC2启动类型：与Fargate逻辑类似，但使用自主管理的EC2集群，同样搭配ALB调整请求限制，适合需要自定义实例配置的场景。
• AWS App Runner：全托管应用服务，默认支持最大1GB的请求体大小，无需手动配置负载均衡，直接部署服务即可，运维成本低于EC2，比Fargate更省心。

三、关键注意事项 #

• 无论选用哪种方案，都需确保服务框架（如GraphQL处理服务）支持接收20MB请求体，需对应调整框架的请求大小限制（比如Express设置limit参数、FastAPI调整max_upload_size）。
• 若必须保留原有GraphQL Router，需确保Router到后端计算服务的链路也支持20MB请求，避免中间环节出现新的限制。

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