5 common pain points with AWS Lambda

# 5 common pain points with AWS Lambda ## Starting without a framework One of the biggest mistakes made when creating a serverless architecture using AWS Lambda is writing functions without a framework. There are multiple frameworks available to deploy and wire up Lambda functions to the events which will be triggering them. These frameworks handle the deployment of individual Lambda functions, setup of API Gateway to pass through HTTP events or a Cloudwatch Scheduled Event to trigger a Lambda on a cron-job. … ## Large bundle sizes When starting out with AWS Lambda large bundle sizes aren’t typically a problem, however when your architecture grows and you start to amass a large number of Lambda functions max bundle size starts to become an issue. There is a default deployment size limit of 50MB. To get around this you can utilise webpack to bundle each entrypoint/Lambda into its own file. Another added benefit of individual bundling is faster deployment and spin up of individual functions meaning you can update and deploy just a single function instead of the entire architecture. … ## API Gateway rejects your response It’s possible for API Gateway to return an error 502 Bad Gateway, which states that the response the Gateway received from your Lambda is malformed. The biggest cause for this that I encountered when getting started with AWS Lambda is the requirement to return a string as the body of the request. It’s a good idea to create helper functions to format your responses and add any extra appropriate headers like CORS.