It’s that time of the year again as re:Invent is almost upon us
Here is a list of the serverless-related announcements so far that you should know about.
Importing resources into CloudFormation was worse than pulling teeth. It was one of the biggest and most common pain points for AWS customers.
It’s great to see CloudFormation finally get some love and this is by far my favorite pre:invent announcement this year.
This is a big change to Lambda’s logging behaviour and I have mixed feelings about this.
Firstly, Lambda can now emit log messages in JSON format. This is useful for organizations that are not practising structured logging already. But there are limitations to keep in mind.
1. The sys logs use
time for its timestamps, but application logs use
timestamp. So when you process log messages, make sure you handle this inconsistency accordingly.
2. If you’re writing structured logs, then these get captured into the
message field as a string. e.g.
This is apparently a language-specific behaviour (thanks to Maciej Radzikowski for reporting this).
3. The log level setting is a constant. There is no support for debug log sampling.
In practice, if you’re writing structured logs already then you don’t need to use the new JSON logging feature.
You should also consider using the AWS Lambda Powertools. Amongst other things, it supports sampling debug logs. So you can save on CloudWatch costs by not logging at the debug level in production. But you can still sample debug logs from a percentage of invocations. Hopefully, it will give you enough debug logs to troubleshoot issues that actually arise.
Secondly, this announcement also gives you the ability to override the default log group for Lambda. This opens the door for you to use a single log group for multiple functions.
This makes it much easier for users of CloudWatch Logs and CloudWatch Logs Insights.
An important detail to note is that — when a custom log group is configured, the log stream names would include the function name. This makes it possible for you to identify the function where the log message came from.
At the time of writing, the Serverless Framework doesn’t support these new features. So I created a plugin called serverless-logging config for anyone who wants to try it out in their application.
enableJson: true # [Optional] if enabled, set the LogFormat to JSON
logGroupName: my-logs # [Required] all functions will send logs this log group
applicationLogLevel: INFO # [Optional] valid values are DEBUG, ERROR, FATAL, INFO, TRACE and WARN
systemLogLevel: INFO # [Optional] valid values are DEBUG, INFO and WARN
I have no mixed feelings about this. It’s awesome!
Lambda’s burst concurrency limit is no longer a hard limit and can be raised with a support ticket.
Just to be clear, it was possible to raise this before. But AWS didn’t advertise it as a raisable limit, and instead, it was something that you had to ask through your technical account manager on a case-by-case basis.
Besides adding support for Node.js 20.x and Java 21, the Lambda team also released a blog post to talk about how they manage runtimes.
CloudFront has added a KeyValueStore for CloudFront Functions. It’s worth noting that while it has some use cases, it’s not a “database at the edge” solution.
CloudFront Functions can read from the key-value store, but it can’t update or insert anything. You need to use the AWS SDK to modify data in the key-value store, which CloudFront Functions cannot.
Also, CloudFront Functions are limited in what they can do. They can change the origin but can’t respond to the caller directly. So the key-value store does not open the door to building APIs on the edge.
The main use cases are for separating code and configuration for CloudFront Functions. It’s useful for performing A/B tests, maintenance modes, redirect tables, etc.
You can put the static configuration data in the key-value store and CloudFront Functions would have fast access to its data.
You can now set an Archive Policy (up to 365 days) on SNS FIFO topics and replay messages in a given period to a specific subscription.
ps. The 365-day limit is not a hard limit and can be raised with a support ticket.
At long last, Kinesis supports resource policies. This makes it easy to process Kinesis events with a Lambda function in another account.
Prior to this change, you had to first assume a role in the account where the Kinesis stream resides.
A common use case that can benefit from this is when you ship CloudWatch Logs through a Kinesis stream. With this, you can centralize the log processing and log forwarding in a central account.
But it’s worth mentioning that, this was already possible through CloudWatch Logs Destinations. Which lets you forward CloudWatch Logs to Kinesis in another account and/or a different region. Aidan Steele wrote a detailed post on this topic, which you should read here.
I mean, this is just so cool!
This is a good quality-of-life improvement and should make debugging much easier.
This is another solid quality-of-life improvement from EventBridge.
These new metrics give you more visibility into what’s going on in your event-driven architecture, including failures and throttles.
My favourites are the new
IngestiontoInvocationStartLatency metrics. They make it easier to understand the end-to-end performance of your event processing system.
These metrics are provided out-of-the-box, so there are no extra costs involved.
You could already do prefix and suffix filtering, but this lets you do middle-of-the-string wildcards. It’s useful for filtering on S3 files for instance, with patterns such as “dir/*.png”.
The Lambda team made scaling faster for SQS and Kafka.
With these scaling changes, you need to be mindful of downstream systems. Remember, not everything can scale as much and as quickly as our Lambda functions.
Well, it’s 2023, it’s better late than never.
Why? Because using CodeBuild with containers is super slow.
Why is it slow? Because Aidan Steele found a vulnerability in the way containers are reused in CodeBuild.
Can’t fault them for choosing security over performance.
Possibly related to the upcoming IPv4 charges.
OK, so that’s a list of the biggest serverless-related announcements that we’ve had leading up to re:Invent 2023.
Unfortunately, I won’t be at the event this year, but I’ll be keeping a close eye on it like most of you.
For those of you attending re:Invent in person, have fun and enjoy a great week in Vegas!