- 最新
- 投票最多
- 评论最多
Hi there!
Both, the 30 sec timeout limit and 6mb payload size are hard limits in Lambda.
However, as a part of workaround, I would suggest a workaround around the same wherein you can process payloads that are over this 6MB limit.
== OPTION 1 ==
Instead of sending a huge payload directly to the Lambda function, you can upload the payload as an object to an S3 bucket, And then use the “Bucket Name” and “Object Name” to fetch the payload larger than 6 MB from s3 while executing the Lambda function using AWS SDKs to GET object from the bucket. This will allow the function to read the payload from the S3 object and process the data.
In case of sending out a response payload with size larger than 6 MB, I would recommend you to store the payload in S3 bucket and then pass the pre-signed URL generated for that payload stored inside S3 bucket to the end user/client in order to download the payload directly from S3 Bucket. For more details around the same please refer this documentation link below [1].
I would also like to share that on checking further around this, I found that there is an active feature request and is in the Lambda Service Team’s consideration (regarding the 6mb payload limit).
== OPTION 2 ==
As for alternatives to the Lambda Service, where you can have more control over the underlying environment, could be AWS Fargate.
AWS Fargate - a serverless version where containers are run on AWS-managed servers which you don't have to pay for - instead you pay for compute time [2].
Therefore as per your requirement, you can use ECS Fargate as an alternative. With AWS Fargate, you don't need to manage servers, handle capacity planning, or isolate container workloads for security. Fargate handles the infrastructure management aspects of your workload for you. You can schedule the placement of your containers across your cluster based on your resource needs, isolation policies, and availability requirements.
Hope this helps!
Ahmad
[1] https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html
Hi,
To overcome Api GW limit, you can look at Application Load Balancer. You can increase timeout response from 60s to 4000s https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#connection-idle-timeout
As per lambda, you can evaluate Fargate to move your workload there. More details here: https://ecsworkshop.com/introduction/ecs_basics/fargate/.
Hope it helps!
相关内容
AWS 官方已更新 1 年前- AWS 官方已更新 6 个月前
- AWS 官方已更新 10 个月前
- AWS 官方已更新 7 个月前
Thank you Ahmad! I considered option 1 but thought it wouldn't fit well, seems (like you said) more like a workaround then a proper solution. Fargate seems interesting, but I would still be bound to the 30s from api gateway. I think I even might be better off hosting an api on a docker container / ec2 right?
Hi again,
You are right, API Gateway 30s timeout is indeed a hard limit. To overcome this:
You could invoke your backend asynchronously [1]. This will mean that your backend will return a response to API Gateway straight away which will avoid timeout, and your backend can execute for longer than 29 seconds. In your backend you would return HTTP code 202 which means that the request has been accepted for processing, but the processing has not been completed. In the client you can implement polling logic to check the status of the backend.
As for hosting the API on a container/EC2, this could certainly work, and would provide you with complete control over your environment configurations, if this is your use case.
[1] https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-invoke-lambda/