Top 12 Serverless Announcements from re:Invent 2022

Published on December 6, 2022
Contents

re:Invent 2022, the annual AWS conference in Las Vegas, is now behind us. I did not attend in person, but that gave me time to consolidate this list of top new serverless features while everyone else is sleeping off the intense 5-day conference. And I envy them just a little.

pre:Invent

”pre:Invent” is a few weeks before the actual conference. You can always see an increased number of features and improvements releases in that period.

Here are my favorite picks.

🔑 Multiple MFA devices in IAM

(announcement post)

Finally.

You could already set up Multi-Factor Authentication for IAM users and the account root user. But until now, you were limited to 1 MFA device only. This was not perfect. If the device is lost or destroyed, you could get blocked from the account.

But it’s no issue anymore. Now you can assign up to 8 MFA devices, which can be a:

  • virtual MFA device – like the Authy app
  • FIDO security key – such as YubiKey
  • hardware TOTP token

If you don’t have MFA enabled yet, especially for your AWS account root user – it’s about time. Virtual MFA is easy and free to set up. On the other hand, FIDO is more secure, although it requires having a security key. Good news – you may be eligible for a free YubiKey from AWS if you are from the US.

Yes, this is not serverless per se, but it’s too important to omit.

🏃‍♂️ Lambda Node.js 18 runtime

(announcement post)

18.x is the currently active LTS version of Node.js. As every version, it comes with various new features and improvements. One of the most significant is the Fetch API, bringing the well-known fetch() function from the browsers to the backend, eliminating the need for third-party packages to make HTTP requests (or at least to make them easily). While still experimental, the Fetch API is available by default in Node 18.

But, maybe even more importantly, Node.js 18.x Lambda runtime comes with AWS SDK v3 included. That replaces AWS SDK v2, which was available in the previous runtime versions. Now, while using the new SDK v3, you can omit it from your code bundle to reduce its size since the SDK is already available in the runtime. That’s not my favorite practice, but I know many folks are doing so.

However, there are reports of increased cold starts with Node 18 runtime versus Node 16. Hopefully, the Lambda team will improve this soon.

If you are using the AWS JS SDK v3, the best way to mock it for unit tests is to use the aws-sdk-client-mock library.

⏰ EventBridge Scheduler

(announcement post)

The new capability of the EventBridge allows scheduling tasks to execute. But wait, we already had CloudWatch Events, later transformed into EventBridge scheduled rules. So what’s new here, you may ask?

Well, the new EventBridge Scheduler is much more powerful. For instance, it integrates with hundreds of AWS services, allowing you to make thousands of API calls directly without a Lambda function.

But the most distinct feature is one-time schedules. Until now, setting up singular actions to be executed in the future involved architecture patterns with DynamoDB and TTL or periodic status checking. Now, you can offload this to the EventBridge.

The Scheduler comes with a soft limit of 1 million scheduled tasks, high-throughput, and configurable time windows for distributing the load. The only drawback is that the one-time tasks are not automatically deleted and count into the scheduled tasks limit. However, the responsible team is working on improving it soon.

📨 EventBridge suffix, case-insensitive, and OR matching

(announcement post)

Continuing with EventBridge, content-based event filtering has new capabilities. Now you can filter by a suffix – this was a highly requested feature, with one use-case being filtering S3 object events by the file extension. There is also a new equals-ignore-case condition and an $or directive to match if any of the provided conditions match.

See the documentation for the description of all filters.

🚀 AppSync JavaScript Resolvers

(announcement post)

This was the top-voted, long-awaited request for AppSync.

Resolvers are code snippets that integrate between AppSync and other services. They are used to prepare the request and parse the response. Until now, you had to write them in VTL (Apache Velocity Templates) – a format beloved by developers. If they would not love it, why would they spend so much time writing VTLs, right?

JavaScript Resolvers are the new default in AppSync. However, they come with several limitations:

Thus even in JavaScript, they are still AppSync Resolvers. Their role is to prepare payloads the AppSync will pass on. They are not a replacement for Lambda functions for more complex operations.

Still, this is a great improvement. With JavaScript, writing and testing Resolvers will be much easier. And, of course, you can use TypeScript and transpile it to JS!

🧩 Cross-account access in Step Functions

(announcement post)

Step Functions Task steps can now assume provided IAM roles and access resources on other AWS accounts directly.

Until now, to access another account, you needed a Lambda function that would assume a cross-account role. Now you just provide the role ARN in the Task definition, and Step Function assumes it. This way, you can make any API call to any service on a different account (with a role that gives you access to it, of course).

re:Invent

Of course, the biggest announcements were on the re:Invent itself.

🚰 EventBridge Pipes

(announcement post)

EventBridge Pipes are here to make your Lambdas obsolete.

Pipes are triggered by events from various sources, just like Lambda functions. Then you can filter, enrich and transform the incoming events. Finally, you send them to a target.

That flow describes a lot of Lambda functions I wrote. With Pipes, it’s simple, low-code, reliable, and effective.

At the moment of the initial release, Pipes support DynamoDB Streams, Kinesis Streams, SQS, MSK, and MQ as event sources. You can use Lambdas, Step Functions, or API calls for enriching events. Finally, Pipes can send events to 15 target destinations, including EventBridge buses, APIs, Kinesis Streams, Kinesis Firehose, SNS, SQS, Step Functions, Lambdas, and more.

And all those features cost just $0.40 per million invocations (after filtering!). For comparison, it’s the same price as for the SQS requests. Furthermore, you can optimize it by batching the input events.

🪣 Step Functions Distributed Map

(announcement post)

Step Functions are great for data processing. But there is a limited size of the payload you can pass between the next steps, as well as limited parallelism that affects the performance for larger jobs. This makes processing files still very dependent on Lambda functions.

Well, no more.

The new flavor of the Map state, the Distributed Map, is here to orchestrate large-scale processing jobs directly in the Step Functions, focusing on S3 files. It can read a JSON or CSV file from S3 and iterate over individual records. Or, even better, it can list files from the S3 location on its own and iterate over them. Then, for processing the records or files, it starts separate child workflows with up to 10,000 parallel executions. And to optimize the work, it can process in batches (with a single child workflow getting multiple records/files as input).

🫰 Lambda SnapStart for Java

(announcement post)

Java is known for long cold starts on Lambda. And even though I say cold starts are not a big problem in most cases, I mean it when the initialization takes 0.5-1 second. With Java, it’s often above 5 seconds, which is a whole different story.

Probably that’s why AWS decided to tackle the issue, starting with Java first. With the new SnapStart feature, the function initialization happens during the deployment. Then the disk and memory state of the initialized environment are cached. So when you invoke the function, the environment is restored from the cache in under 200 ms.

I’m unlikely to write any Lambda function in Java. However, I’m hoping the SnapStart will also become available on other runtimes. If (or when) it comes to Python and Docker, it will be a game changer for serverless Machine Learning solutions, which also suffer from long cold starts.

🕵️‍♂️ Inspector support for Lambda

(announcement post)

Amazon Inspector is a service that scans software libraries against known security vulnerabilities. It does not require installing any additional dependencies or agents. And after EC2 and ECR, it now supports Lambda functions.

You just enable the Inspector in the AWS Console. Then it automatically and continuously scans all the Lambda functions on the account.

How much does security costs? $0.30/Lambda/month.

Should you enable it right away on the production account? Probably yes, unless you already have dependency vulnerabilities scanning in place (like GitHub Dependabot or Snyk).

no:Invent

Unfortunately, there were some disappointments as well.

💸 OpenSearch “Serverless”

One of the promises of serverless is no-use, no-pay pricing. AWS themselves said it multiple times in the past.

But this year, AWS decided to break that promise. In my opinion – for marketing purposes, because “serverless” is trending now.

So after MSK “Serverless”, Aurora “Serverless” v2, and Neptune “Serverless”, now we got OpenSearch “Serverless”.

The problem with all of them? They do not scale down to zero. Therefore, you will pay a minimum fee for created instances, even if not used at all.

How much? Almost $700/month for the OpenSearch “Serverless”.

Why is that a problem? I’m glad you ask. I wrote about this after the Aurora “Serverless” v2 release.

And don’t get me wrong. The auto-scaling offer of all those services is a wonderful thing. I also understand it’s not easy to make a database that will scale down to zero and then scale up to handle incoming requests with no additional latency. My only problem lies in the misleading naming.

🏅 No Serverless Specialty Certificate

Despite all the marketing around the serverless, there is still no Serverless Specialty AWS certificate. While the serverless solutions are part of the Associate and Professional certificate exams, they make up only about 10% of the questions. A certificate that proves knowledge of modern, serverless architectures and solutions without EC2 machines and complex network routing is something the community eagerly awaits.

But we got a consolidation prize – a Serverless Learning Path in the AWS Skill Builder. It’s a free, self-paced, online course where you can earn a badge on completion.

Notable mentions

There were many, many more releases this year on the re:Invent, around the serverless and not.

You can now manage your AWS Organization through CloudFormation, including creating accounts, organizational units, and policies. It’s one of those things you are surprised were not already possible. However, I will stick to the OrgFormation for my own accounts, as it offers additional features like deploying stacks and performing custom logic across the organization.

AWS Glue, a service I’m not a big fan of personally, announced version 4.0 and several new capabilities.

SageMaker, already bloated with features, got at least a dozen more.

Application Composer is a new visual tool for designing serverless applications. After the Step Functions Workflow Studio, it’s another drag-and-drop solution suggesting that AWS wants to improve on the Developer Experience field. However, I doubt I will use it myself. I don’t believe in a drag-and-drop application design. And it integrates with SAM for IaC while I’m on the team CDK.

However, I’m looking forward to learning more about Amazon Verified Permissions, which is now in a closed preview. From my understanding, it will allow you to offload application permission management to AWS. I’ll definitely give it a try.

Direction of serverless

AWS Lambda is no longer a necessary element of serverless applications. More and more solutions can exclusively rely on low-code services like AppSync with its direct integrations (now connected with JavaScript), EventBridge (now with Pipes), or Step Functions (now with built-in file processing). If Lambda functions are used, their role is reduced.

And that’s a great thing.

Code is a liability.

By moving the standard and repeatable tasks to the platform, we can innovate faster. There is less code to write, test, and maintain. Less code also means a lower risk of bugs.

And that’s the idea of serverless. Fewer things for us, developers, to manage. More focus on what matters for the business.

Sessions recordings

AWS re:Invent is not only about exciting new launches. It’s also a lot of tech sessions.

Sure, some talks are just brand marketing. But many technical presentations are given by the best people in the industry who built the solutions you are using. Those sessions are on all levels of advancement.

Their recordings are available on this lengthy playlist (over 440 videos at this moment!): AWS re:Invent 2022 sessions.

Category: AWS
Tags: cloud event-bridge lambda reinvent serverless