Serverless roundup at AWS re:Invent 2022

Home Blog Serverless roundup at AWS re:Invent 2022

AWS re:Invent was back and BIG last week in Las Vegas. Approximately 50,000 AWS customers and partners got together in Las Vegas to learn, talk shop, and maybe attend a couple of parties here and there. Not only did Lumigo have a booth, but our own Saar Tochner, R&D Team Lead and AWS Community Builder gave a well-received talk on Lambda extensions. 

With many announcements spanning new features and improvements to the myriad of cloud services that AWS offers, the common theme seemed to be all about building resilient applications and running them efficiently. Below are the new announcements that stood out to us and we’ll try to give you some context and insight into what these announcements can mean/do for you.

Super-cool but limited for now: AWS Lambda SnapStart

AWS has made a lot of strides in recent years to reduce cold start delays on Lambda functions, but some runtimes—especially Java-based functions that use frameworks like Springboot, Quarkus, or Micronaut—can still suffer multi-second slowdowns because of all the components they have to load and integrate.

Currently only for Lambdas using the Corretto (java11) runtime, the new optional SnapStart functionality runs an optimization process that creates an immutable, encrypted snapshot of the container after the initialization is complete. This allows future invocations of the function to launch from effectively a warm start instead of a cold one.

If you’re not running Java on Lambda, this won’t help you… yet. But it is encouraging for the potential expansion to other languages and other frameworks.

As launch partners for this new feature, Lumigo immediately supports SnapStart and users can check on functions running with SnapStart directly inside the Lumigo platform. 

For more, read AWS Serverless Hero Yan Cui’s blog post on it.

Harness the power of observability

Debug serverless apps in the only observability platfrom that’s purpose-built for them.

Visualize architectures with AWS Application Composer

Screencap credit: Amazon Web Services

AWS Application Composer visualizes serverless architectures. Import existing CloudFormation or Serverless Architecture Model (SAM) infrastructure-as-code (IaC) templates and you’ll get a visual layout you can edit or you start a diagram from scratch.

Edit properties of individual items, arrange as needed, and then export to CloudFormation or SAM templates to easily deploy the services as visualized.

AWS Step Functions might seem very similar due to both having visual composition models. Step Functions are a low-code way to model and orchestrate functional operations in an application. Application Composer works at a higher level and can be used to integrate Step Functions as part of a larger architecture.

Application Composer is in public preview which means it could have bugs and could change, so don’t bet your entire production infrastructure on it. But if you’re trying to quickly prototype an architecture and have a minute to debug if you run into an issue, it’s worth giving it a try.

Amazon CloudWatch Logs data protection helps keep customers and certifications safe

Screencap credit: Amazon Web Services

Lumigo makes use of your CloudWatch Logs as one set of signals to help us trace and monitor your serverless applications. If you leak sensitive info into your logs, it can pose risks to both your customers and your security certifications.

The CloudWatch Logs data protection feature uses machine learning and other signals to mask credentials, personal health information, device identifiers, personally identifiable information, and financial information on ingestion. This means it won’t go back and mask old logs, but can be enabled going forward. 

The masking is encrypted, and customers can decrypt their masked CloudWatch Logs information. Decryption requires a permission in the IAM role being used, is specified per request, and is done between retrieving the log data and returning it to the requester, not in the log files themselves.

If you’re trying to determine if an error is being caused by a malformed account number, a developer with the proper permissions can identify the log entry associated with the error in your Lumigo interface, then run an AWS CLI command to retrieve the logged data with the data unmasked. Just remember, the developer’s access to, storage of, and disposal of the unmasked information still needs to be governed by your security best practices. By default, Lumigo also applies secret masking to prevent critical values from being displayed and republished. 

Also in this vein, automated data discovery was announced for Amazon Macie. Use this service to easily scan your S3 buckets for potentially sensitive data. With optimized sampling rates and the ability to select from over 100 managed sensitive data types, the cost of scanning a collection of S3 buckets is significantly reduced vs. scanning every byte of every bucket.

Cross-Account observability tracks the CloudWatch logs of multiple accounts in one place

Something a number of people asked about at our booth was how to get telemetry when you have dozens or even hundreds of accounts. Something exciting at re:Invent was Cross-Account Observability.

Cross-Account Observability uses a centralized “monitoring account” to collect data from numerous “source accounts.” Source accounts are specified by account ID, AWS Organizations path, or organization ID. 

Multiple monitoring accounts can be created for specific subsets of your data. For example, rather than giving everyone access to an account with visibility across the organization, provide individual business units with monitoring accounts restricted to just the source accounts they own.

Monitoring accounts are region-specific, so if your architecture is multi-region, you’ll need to configure Cross-Account Observability in each region.

For more details on how to get started, check out Danilo Poccia’s AWS blog post on Amazon CloudWatch Cross-Account Observability.

Harness the power of observability

Debug serverless apps in the only observability platfrom that’s purpose-built for them.

Amazon Inspector expands to AWS Lambda

Screencap credit: Amazon Web Services

Amazon Inspector’s vulnerability scans for EC2 instances and ECR container images are now available for AWS Lambda functions and Lambda layers. This expands the variety of mixed workloads it’s able to scan.

As a native AWS service, you do not need to regularly update or patch vulnerability signatures. Amazon takes care of training and updating the scanner which you enable per account or per organization.

This roll-out covers Lambdas written in Java, NodeJS, and Python, and individual Lambda functions can be excluded using tagging. Lambdas are scanned upon deployment, updated deployment, and when relevant CVEs are published.

AWS is offering a 15-day free trial of Amazon Inspector (if you’re new to it). Because many Lambda functions use third-party libraries from npm, pip, etc., it’s a perfect opportunity to do a quick audit of your Lambda, EC2, and ECR image inventory not just for your code, but the code your code is using.

More cool things they announced at re:Invent

Go try out some of these cool new services/options today and if you have something you want to share about them, reach out to us on Twitter, LinkedIn, or Facebook.