I had a good time at AWS re:Invent 2017 last week, despite being sick as a dog for most of it. Though I caught fewer sessions than I would have liked, the ones I did attend on serverless topics were top notch. Here are some links to my favorites:
ARC401 – Serverless Architectural Patterns and Best Practices
- Serverless foundations
- Web applications
- Data Lakes
- Stream processing
- Operations automation (e.g., Tailor, for automating AWS account creation)
- Excellent review of best practices and new features in Lambda
SRV401 – Become a Serverless Black Belt: Optimizing Your Serverless Applications
- Optimization Katas
- Lean Functions
- Eventful Invocations
- Coordinated Calls
- Serviceful Operations
- Cold start issues in Lambda
- Instrumenting Lambda with XRay
- Resource allocation
- Concurrency vs. latency
- Compelling customer story from ACloudGuru’s VP of Engineering on going 100% serverless
SRV305 – What’s New in Serverless
- Announced Serverless Application Repository
- Reviewed new Lambda console
- Reviewed new Lambda features
- Reviewed Cloud9 IDE
- Reviewed XRay tracing for Lambda
- New API Gateway features
- Compelling customer story from FICO’s VP of Engineering
When using SNS pub/sub components, a common integration pattern is to use Lambda to process SNS messages. This can include the use of data blobs as the SNS payload for doing file processing, data transformations, and archiving data in S3 among other things. SNS messages have a large payload limit of 256KB per message, but I recently ran into a situation where I could not reliably deliver messages that were sized well under that limit.
As it turns out, when Lambda is consuming your SNS large payloads in events, you hit a limit within Lambda that is exactly half of the SNS payload limit. For Event (asynchronous) invocations in Lambda, there is a 128KB payload limit. So, if your SNS messages are not being processed by Lambda, check the size of the messages and verify that they are below 128KB. This was a confusing problem until I looked at the CloudWatch console for SNS message deliveries and noticed the errors there.
I have been meaning to put together a Lambda function to create an AMI from a custom EC2 instance. It’s a pretty typical scenario, but I haven’t taken the time to roll my own. Recently, I ran across an article on StackOverflow which provides a CloudFormation template that:
- constructs an EC2 image,
- creates a Lambda execution role for AMI building,
- creates a Lambda function for constructing an AMI, and
- uses a custom resource to make an AMI from the instance via the Lambda function.
So, I modified both the template and Lambda function to make it a little more generic and reusable. Also, I fixed a logic error in a the original Lambda. Finally, I wanted to customize the name of both the image and AMI, so I created an InstanceName parameter. The only other parameter for the CF template is InstanceType, which I defaulted to t2.micro. Add your desired instance types to the list in that parameter’s AllowedValues attribute. The base AMI for the instance is a region-specific Amazon Linux image. Once the stack is deployed, simply update the template with your userdata changes to create new custom AMI’s. It’s a very helpful tool to have in your CloudFormation toolbox.
The template is available from my aws-mojo repo on GitHub in both JSON and YAML formats.