The best pre:invent serverless announcements you may have missed

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.

CloudFormation imports get easier

Here’s the official announcement.

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.

Lambda adds JSON logging and custom log groups

Here’s the official announcement.

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.

{ 
  "timestamp": "2023–11–16T21:06:11.993Z", 
  "level": "INFO", 
  "requestId": "bd6e762b-9eeb-4a83-aa41-bd070fe5f765", 
  "message": "{\"level\":\"DEBUG\",\"message\":\"test\"}"
}

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.

service: my-service

plugins:
  - serverless-logging-config

custom:
  serverless-logging-config:
    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

Step Functions support restart from failure

Here’s the official announcement.

I have no mixed feelings about this. It’s awesome!

Lambda’s burst concurrency limit can now be raised

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.

New Lambda runtimes

Here’s the official announcement for Node.js 20 support.

Here’s the official announcement for Java 21 support.

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 adds a key-value store for CloudFront Functions

Here’s the official announcement.

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.

SNS FIFO adds archive capability

Here’s the official announcement.

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.

Kinesis supports cross-account access

Here’s the official announcement.

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.

CodeWhisperer comes to the Command Line

Here’s the official announcement.

I mean, this is just so cool!

Unfortunately, it’s for MacOS only. Why MacOS only? Because this is an AWS-fied version of fig.io which AWS acquired a while back. (thanks to Brad Knowles for reminding us about that!)

EventBridge Pipes adds logging support

Here’s the official announcement.

This is a good quality-of-life improvement and should make debugging much easier.

EventBridge adds 22 new metrics

Here’s the official announcement.

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 PutEventsLatency and 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.

EventBridge supports wildcard filters

Here’s the official announcement.

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”.

Faster scaling for Lambda

The Lambda team made scaling faster for SQS and Kafka.

Here’s the official announcement for SQS scaling.

Here’s the official announcement for Kafka scaling.

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.

SQS supports JSON protocol

Here’s the official announcement.

Well, it’s 2023, it’s better late than never.

CodeBuild supports Lambda

Here’s the official announcement.

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.

Lambda supports IPv6 for outbound connections in VPC

Here’s the official announcement.

Possibly related to the upcoming IPv4 charges.

Bring on re:Invent 2023!

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!