AWS Summit Recap: What’s new for Lambda, Cloudformation and more

AWS hosts regular summits all around the world, this week I visited the one in Amsterdam. These are really nice to join, first because they’re free, and second because they are very much focussed on teaching you things you didn’t know you could do with AWS.
In this post, I’ll shortly recap some things I learned. Of course I could only visit a couple of the talks, most of which discussed serverless AWS services like Lambda and DynamoDB.

Lambda performance

In one of the talks, a blog focused on lambda performance was shared. I didn’t read all the posts, but the first one I clicked is really useful. In Node.js lambdas, instead of requiring the whole AWS SDK, you can require only the parts you need and that way improve the cold start time of your lambda by a lot. You can read more here.
Another interesting way to improve your lambda package size and cold start time is to use webpack to compile your lambda. You can then for example apply tree shaking to lose unused code from dependencies.
AWS shared that they are looking into a fix for long cold start times for lambdas running in VPC’s. Currently, it can take a couple of seconds for a lambda to be started when running in a VPC. If you’re using lambda’s to serve some kind of content to customers, a couple of seconds is quite painful. Unfortunately they didn’t share a timeline for the fix, but it’s really good to know they are working on it.

Lambda layers

Lambda layers has already been there for some time now, but I still want to highlight it because it’s quite powerful. It allows you to package a layer consisting of some files, for example libraries or binaries that your lambda depends on. Your lambda can then build on top of that layer, using anything from the layer it might need. The setup is very similar to the way Docker containers are built up, where every command creates a new layer.
Similar to Docker this allows you to create base Lambda images. You can use layers provided by third parties if you want. With custom runtime support, this means that you’ll be able to find a prebuilt layer that will add the runtime for just about any popular language.

Cloudformation goodies

With Cloudformation macro’s, you can greatly reduce the amount of boilerplate Cloudformation you need to write. This is in essence what SAM (Serverless Application Model) already does for Lambda/DynamoDB/ApiGateway. I’ve noticed that most of the Cloudformation I write is very much the same, sometimes tweaking one or two properties. Reusing a base resource config that is known to be aligned with best practices and security guidelines seems like a really good idea as well.
As an alternative for yaml/json Cloudformation, AWS CDK allows specifying your infrastructure as javascript/typescript, Java or .NET. This way, you can specify your own constructs (like serverless functions, loadbalancers, etc.) and use them in your stack easily. To me this sounds like Cloudformation on steroids. The flexibility that this gives is hard to achieve with yaml or json. Be sure to take a look at the examples if you’re interested.

Example applications

AWS has a great catalog of example repo’s. Next to general advice like the well architected framework, these sample applications are really useful to see what solutions are possible and common. An interesting example application was demoed that consists of quite an extensive infrastructure, linking several data stores together. This specific example links a couple of services together, including DynamoDB, Elasticsearch, Elasticache and Neptune, to create a basic ecommerce platform.

Conclusion

AWS keeps evolving, and these summits are a great way to stay up to date on the latest additions. To highlight that, most of the things I learned were added in the last 6 months. If you’re using or are planning to use AWS in any way, I highly recommend visiting a summit near you when you get the chance.

Link: https://dev.to/raoulmeyer/aws-summit-recap-what-s-new-for-lambda-cloudformation-and-more-4la