- 최신
- 최다 투표
- 가장 많은 댓글
You usually will use the container option in one of the following two cases:
- You need a function with a package size larger than 250MB unzipped (containers support 10GB)
- You are already using containers in other places and would like to use the same tools you are using for containers
In other cases I would just use the zip file approach.
It also comes down to how you want to manage language runtimes. In AWS Lambda, container image packaged functions are similar to Zip files, but the customer is responsible for more artifacts, including the runtime, in the container image. If you take advantage of container packaging, the shared responsibility model for Lambda shifts, with the customer now being responsible for managing from the base image up. Since container images contain language runtime libraries, using a container image to package Lambda functions prevents Lambda from automatically updating the language runtime.
Can we just simply use Container for all lambda as a default pattern ? Assume a case, the team uses containers for all old services. What will the value/advantage in using zip for new service or refactor the container based app to code-zip ?
Can we just simply use Container for all lambda as a default pattern ? Assume a case, the team uses containers for all old services. What will the value/advantage in using zip for new service or refactor the container based app to code-zip ?
You could use a container for all functions, but note that you don't just take your old code and run it in a container. When running in Lambda you need to include the Lambda handler, which will be invoked when the function is triggered. You will need to move to stateless, etc.
Or your using a version of the runtime AWS doesnt support