Do you recognize this view when looking into your CloudWatch log groups? Each AWS Lambda function has an associated CloudWatch log group. However, there is no cleanup process available as soon as a relationship between a CloudWatch log group and Lambda function expires. In that case it’s necessary to remove these old log groups manually. In this post I’ll show you an easy way to always have a clean set of CloudWatch log groups by automatically removing old log groups.
On the 7th of September, I gave a talk at Atlas Camp 2018 in Barcelona. You can watch it here on YouTube. It was my first time on a bigger stage and about 80-100 people listened to my words – amazing! With this blog post I want to say thanks to all who helped me achieving this and share some lessons learned with you.
A CloudFormation stack evolves over time and usually costs increase as well. You’ll probably not only have one stack, but instead have at least a production and a development stack. Even one development stack per developer might be common. This means the total costs increase even more. In order to prevent this, you might want to shut down CloudFormation stack resources over night to save costs. A neat way is to use AWS Lambda functions for this. You schedule them to execute after and before a regular working day to shut down or start up the stack resources. This blog post describes the steps to accomplish such a setup to decrease costs for developer stacks.
Recently, a question on stackoverflow.com popped up which asked for different environments with AWS CloudFormation. Here, I want to present my answer and give some more information about this topic. The code for this blog post can be found in my GitHub repository where I also have some more CloudFormation examples.
If you use AWS for your private website, tools or just for testing new things, you will get to the point where you’re not sure how much money your resources cost you. AWS has a small tool for that: AWS Budgets. With this tool you can keep your AWS budget under control and get notified if it exceeds your limit.
AWS Lambda is actually made to be used by implementing small functions which can be started quickly. So your code artifact should be as small as possible for a fast startup time. However, in the Java world there are nice frameworks like Jersey and Spring which can help you writing code for an API a lot! Unfortunately these frameworks can take up to a few MB and blow up your artifact, but you might have your reasons to use them in AWS Lambda, e.g. because you’re migrating an existing project to AWS Lambda. So let’s see, how you can use Jersey and Spring together in AWS Lambda! The code can be found in my GitHub repository lambda-jersey-spring-example.
Recently, I came across a limit which I haven’t known before: CloudFormation just allows a maximum size of 51,200 bytes per template. If you have ever reached this limit, you might have encountered this error message:
[YOUR_TEMPLATE_CODE] at 'templateBody' failed to satisfy constraint: Member must have length less than or equal to 51200
So, what are the possible solutions to reduce a CloudFormation template size? In my opinion, there are two relatively easy solutions to overcome this problem: using a preprocessor and/or using AWS::Include.
Today I want to show you three starter projects for AWS Lambda using CloudFormation and SAM – Serverless Application Model. I always like if I have some boilerplate code and can get started quickly without copying code or project structures from an existing (and mature) project. Therefore I thought it’s good to have them in one repository. You can find them on GitHub. The projects can be used for NodeJS and Java. Also one project contains both: usage of Java and NodeJS Lambdas in one CloudFormation template.
This year I’ve started working with Amazon Web Services (AWS) and most notably AWS Lambda. It’s awesome what Amazon is providing here! It’s cheap, easy to start with when using SAM – Serverless Application Model and easy to integrate with other services. But there are also downsides (which were also discussed a lot on HN). Just to name a few: a) logging is a mess, b) debugging is not possible at all or c) CPU power only comes with more memory. Though I can’t change b) and c), I could do something for a). Furthermore it was also a pain for me to update the Lambda code quickly, because I am using CloudFormation. A CloudFormation update takes a lot of time and summed up to 2:30 min for every update in my case – not acceptable for just changing one line of code. Therefore I decided to write some small CLI tools to overcome the logging problem and code updates with AWS Lambda.
A few years ago, Amazon Web Services (AWS) launched it’s new service AWS Lambda. Since its start the service is generating more and more interest for the whole world of serverless computing. I’ve also started using it this year and today I want to share 5 things with you what I think is important when developing such functions.