All posts by Julian Wood

Introducing AWS Lambda response streaming

Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/introducing-aws-lambda-response-streaming/

Today, AWS Lambda is announcing support for response payload streaming. Response streaming is a new invocation pattern that lets functions progressively stream response payloads back to clients.

You can use Lambda response payload streaming to send response data to callers as it becomes available. This can improve performance for web and mobile applications. Response streaming also allows you to build functions that return larger payloads and perform long-running operations while reporting incremental progress.

In traditional request-response models, the response needs to be fully generated and buffered before it is returned to the client. This can delay the time to first byte (TTFB) performance while the client waits for the response to be generated. Web applications are especially sensitive to TTFB and page load performance. Response streaming lets you send partial responses back to the client as they become ready, improving TTFB latency to within milliseconds. For web applications, this can improve visitor experience and search engine rankings.

Other applications may have large payloads, like images, videos, large documents, or database results. Response streaming lets you transfer these payloads back to the client without having to buffer the entire payload in memory. You can use response streaming to send responses larger than Lambda’s 6 MB response payload limit up to a soft limit of 20 MB.

Response streaming currently supports the Node.js 14.x and subsequent managed runtimes. You can also implement response streaming using custom runtimes. You can progressively stream response payloads through Lambda function URLs, including as an Amazon CloudFront origin, along with using the AWS SDK or using Lambda’s invoke API. You can also use Amazon API Gateway and Application Load Balancer to stream larger payloads.

Writing response streaming enabled functions

Writing the handler for response streaming functions differs from typical Node handler patterns. To indicate to the runtime that Lambda should stream your function’s responses, you must wrap your function handler with the streamifyResponse() decorator. This tells the runtime to use the correct stream logic path, allowing the function to stream responses.

This is an example handler with response streaming enabled:

exports.handler = awslambda.streamifyResponse(
    async (event, responseStream, context) => {
        responseStream.setContentType(“text/plain”);
        responseStream.write(“Hello, world!”);
        responseStream.end();
    }
);

The streamifyResponse decorator accepts the following additional parameter, responseStream, besides the default node handler parameters, event, and context.

The new responseStream object provides a stream object that your function can write data to. Data written to this stream is sent immediately to the client. You can optionally set the Content-Type header of the response to pass additional metadata to your client about the contents of the stream.

Writing to the response stream

The responseStream object implements Node’s Writable Stream API. This offers a write() method to write information to the stream. However, we recommend that you use pipeline() wherever possible to write to the stream. This can improve performance, ensuring that a faster readable stream does not overwhelm the writable stream.

An example function using pipeline() showing how you can stream compressed data:

const pipeline = require("util").promisify(require("stream").pipeline);
const zlib = require('zlib');
const { Readable } = require('stream');

exports.gzip = awslambda.streamifyResponse(async (event, responseStream, _context) => {
    // As an example, convert event to a readable stream.
    const requestStream = Readable.from(Buffer.from(JSON.stringify(event)));
    
    await pipeline(requestStream, zlib.createGzip(), responseStream);
});

Ending the response stream

When using the write() method, you must end the stream before the handler returns. Use responseStream.end() to signal that you are not writing any more data to the stream. This is not required if you write to the stream with pipeline().

Reading streamed responses

Response streaming introduces a new InvokeWithResponseStream API. You can read a streamed response from your function via a Lambda function URL or use the AWS SDK to call the new API directly.

Neither API Gateway nor Lambda’s target integration with Application Load Balancer support chunked transfer encoding. It therefore does not support faster TTFB for streamed responses. You can, however, use response streaming with API Gateway to return larger payload responses, up to API Gateway’s 10 MB limit. To implement this, you must configure an HTTP_PROXY integration between your API Gateway and a Lambda function URL, instead of using the LAMBDA_PROXY integration.

You can also configure CloudFront with a function URL as origin. When streaming responses through a function URL and CloudFront, you can have faster TTFB performance and return larger payload sizes.

Using Lambda response streaming with function URLs

You can configure a function URL to invoke your function and stream the raw bytes back to your HTTP client via chunked transfer encoding. You configure the Function URL to use the new InvokeWithResponseStream API by changing the invoke mode of your function URL from the default BUFFERED to RESPONSE_STREAM.

RESPONSE_STREAM enables your function to stream payload results as they become available if you wrap the function with the streamifyResponse() decorator. Lambda invokes your function using the InvokeWithResponseStream API. If InvokeWithResponseStream invokes a function that is not wrapped with streamifyResponse(), Lambda does not stream the response and instead returns a buffered response which is subject to the 6 MB size limit.

Using AWS Serverless Application Model (AWS SAM) or AWS CloudFormation, set the InvokeMode property:

  MyFunctionUrl:
    Type: AWS::Lambda::Url
    Properties:
      TargetFunctionArn: !Ref StreamingFunction
      AuthType: AWS_IAM
      InvokeMode: RESPONSE_STREAM

Using generic HTTP client libraries with function URLs

Each language or framework may use different methods to form an HTTP request and parse a streamed response. Some HTTP client libraries only return the response body after the server closes the connection. These clients do not work with functions that return a response stream. To get the benefit of response streams, use an HTTP client that returns response data incrementally. Many HTTP client libraries already support streamed responses, including the Apache HttpClient for Java, Node’s built-in http client, and Python’s requests and urllib3 packages. Consult the documentation for the HTTP library that you are using.

Example applications

There are a number of example Lambda streaming applications in the Serverless Patterns Collection. They use AWS SAM to build and deploy the resources in your AWS account.

Clone the repository and explore the examples. The README file in each pattern folder contains additional information.

git clone https://github.com/aws-samples/serverless-patterns/ 
cd serverless-patterns

Time to first byte using write()

  1. To show how streaming improves time to first bite, deploy the lambda-streaming-ttfb-write-sam pattern.
  2. cd lambda-streaming-ttfb-write-sam
  3. Use AWS SAM to deploy the resources to your AWS account. Run a guided deployment to set the default parameters for the first deployment.
  4. sam deploy -g --stack-name lambda-streaming-ttfb-write-sam

    For subsequent deployments you can use sam deploy.

  5. Enter a Stack Name and accept the initial defaults.
  6. AWS SAM deploys a Lambda function with streaming support and a function URL.

    AWS SAM deploy --g

    AWS SAM deploy –g

    Once the deployment completes, AWS SAM provides details of the resources.

    AWS SAM resources

    AWS SAM resources

    The AWS SAM output returns a Lambda function URL.

  7. Use curl with your AWS credentials to view the streaming response as the URL uses AWS Identity and Access Management (IAM) for authorization. Replace the URL and Region parameters for your deployment.
curl --request GET https://<url>.lambda-url.<Region>.on.aws/ --user AKIAIOSFODNN7EXAMPLE:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY --aws-sigv4 'aws:amz:<Region>:lambda'

You can see the gradual display of the streamed response.

Using curl to stream response from write () function

Using curl to stream response from write () function

Time to first byte using pipeline()

  1. To try an example using pipeline(), deploy the lambda-streaming-ttfb-pipeline-sam pattern.
  2. cd ..
    cd lambda-streaming-ttfb-pipeline-sam
  3. Use AWS SAM to deploy the resources to your AWS account. Run a guided deployment to set the default parameters for the first deploy.
  4. sam deploy -g --stack-name lambda-streaming-ttfb-pipeline-sam
  5. Enter a Stack Name and accept the initial defaults.
  6. Use curl with your AWS credentials to view the streaming response. Replace the URL and Region parameters for your deployment.
curl --request GET https://<url>.lambda-url.<Region>.on.aws/ --user AKIAIOSFODNN7EXAMPLE:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY --aws-sigv4 'aws:amz:<Region>:lambda'

You can see the pipelined response stream returned.

Using curl to stream response from function

Using curl to stream response from function

Large payloads

  1. To show how streaming enables you to return larger payloads, deploy the lambda-streaming-large-sam application. AWS SAM deploys a Lambda function, which returns a 7 MB PDF file which is larger than Lambda’s non-stream 6 MB response payload limit.
  2. cd ..
    cd lambda-streaming-large-sam
    sam deploy -g --stack-name lambda-streaming-large-sam
  3. The AWS SAM output returns a Lambda function URL. Use curl with your AWS credentials to view the streaming response.
curl --request GET https://<url>.lambda-url.<Region>.on.aws/ --user AKIAIOSFODNN7EXAMPLE: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY --aws-sigv4 'aws:amz:<Region>:lambda' -o SVS401-ri22.pdf -w '%{content_type}'

This downloads the PDF file SVS401-ri22.pdf to your current directory and displays the content type as application/pdf.

You can also use API Gateway to stream a large payload with an HTTP_PROXY integration with a Lambda function URL.

Invoking a function with response streaming using the AWS SDK

You can use the AWS SDK to stream responses directly from the new Lambda InvokeWithResponseStream API. This provides additional functionality such as handling midstream errors. This can be helpful when building, for example, internal microservices. Response streaming is supported with the AWS SDK for Java 2.x, AWS SDK for JavaScript v3, and AWS SDKs for Go version 1 and version 2.

The SDK response returns an event stream that you can read from. The event stream contains two event types. PayloadChunk contains a raw binary buffer with partial response data received by the client. InvokeComplete signals that the function has completed sending data. It also contains additional metadata, such as whether the function encountered an error in the middle of the stream. Errors can include unhandled exceptions thrown by your function code and function timeouts.

Using the AWS SDK for Javascript v3

  1. To see how to use the AWS SDK to stream responses from a function, deploy the lambda-streaming-sdk-sam pattern.
  2. cd ..
    cd lambda-streaming-sdk-sam
    sam deploy -g --stack-name lambda-streaming-sdk-sam
  3. Enter a Stack Name and accept the initial defaults.
  4. AWS SAM deploys three Lambda functions with streaming support.

  • HappyPathFunction: Returns a full stream.
  • MidstreamErrorFunction: Simulates an error midstream.
  • TimeoutFunction: Function times out before stream completes.
  • Run the SDK example application, which invokes each Lambda function and outputs the result.
  • npm install @aws-sdk/client-lambda
    node index.mjs

    You can see each function and how the midstream and timeout errors are returned back to the SDK client.

    Streaming midstream error

    Streaming midstream error

    Streaming timeout error

    Streaming timeout error

    Quotas and pricing

    Streaming responses incur an additional cost for network transfer of the response payload. You are billed based on the number of bytes generated and streamed out of your Lambda function over the first 6 MB. For more information, see Lambda pricing.

    There is an initial maximum response size of 20 MB, which is a soft limit you can increase. There is a maximum bandwidth throughput limit of 16 Mbps (2 MB/s) for streaming functions.

    Conclusion

    Today, AWS Lambda is announcing support for response payload streaming to send partial responses to callers as the responses become available. This can improve performance for web and mobile applications. You can also use response streaming to build functions that return larger payloads and perform long-running operations while reporting incremental progress. Stream partial responses through Lambda function URLs, or using the AWS SDK. Response streaming currently supports the Node.js 14.x and subsequent runtimes, as well as custom runtimes.

    There are a number of example Lambda streaming applications in the Serverless Patterns Collection to explore the functionality.

    Lambda response streaming support is also available through many AWS Lambda Partners such as Datadog, Dynatrace, New Relic, Pulumi and Lumigo.

    For more serverless learning resources, visit Serverless Land.

    Serverless ICYMI Q1 2023

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/serverless-icymi-q1-2023/

    Welcome to the 21st edition of the AWS Serverless ICYMI (in case you missed it) quarterly recap. Every quarter, we share all the most recent product launches, feature enhancements, blog posts, webinars, live streams, and other interesting things that you might have missed!

    ICYMI2023Q1

    In case you missed our last ICYMI, check out what happened last quarter here.

    Artificial intelligence (AI) technologies, ChatGPT, and DALL-E are creating significant interest in the industry at the moment. Find out how to integrate serverless services with ChatGPT and DALL-E to generate unique bedtime stories for children.

    Example notification of a story hosted with Next.js and App Runner

    Example notification of a story hosted with Next.js and App Runner

    Serverless Land is a website maintained by the Serverless Developer Advocate team to help you build serverless applications and includes workshops, code examples, blogs, and videos. There is now enhanced search functionality so you can search across resources, patterns, and video content.

    SLand-search

    ServerlessLand search

    AWS Lambda

    AWS Lambda has improved how concurrency works with Amazon SQS. You can now control the maximum number of concurrent Lambda functions invoked.

    The launch blog post explains the scaling behavior of Lambda using this architectural pattern, challenges this feature helps address, and a demo of maximum concurrency in action.

    Maximum concurrency is set to 10 for the SQS queue.

    Maximum concurrency is set to 10 for the SQS queue.

    AWS Lambda Powertools is an open-source library to help you discover and incorporate serverless best practices more easily. Lambda Powertools for .NET is now generally available and currently focused on three observability features: distributed tracing (Tracer), structured logging (Logger), and asynchronous business and application metrics (Metrics). Powertools is also available for Python, Java, and Typescript/Node.js programming languages.

    To learn more:

    Lambda announced a new feature, runtime management controls, which provide more visibility and control over when Lambda applies runtime updates to your functions. The runtime controls are optional capabilities for advanced customers that require more control over their runtime changes. You can now specify a runtime management configuration for each function with three settings, Automatic (default), Function update, or manual.

    There are three new Amazon CloudWatch metrics for asynchronous Lambda function invocations: AsyncEventsReceived, AsyncEventAge, and AsyncEventsDropped. You can track the asynchronous invocation requests sent to Lambda functions to monitor any delays in processing and take corrective actions if required. The launch blog post explains the new metrics and how to use them to troubleshoot issues.

    Lambda now supports Amazon DocumentDB change streams as an event source. You can use Lambda functions to process new documents, track updates to existing documents, or log deleted documents. You can use any programming language that is supported by Lambda to write your functions.

    There is a helpful blog post suggesting best practices for developing portable Lambda functions that allow you to port your code to containers if you later choose to.

    AWS Step Functions

    AWS Step Functions has expanded its AWS SDK integrations with support for 35 additional AWS services including Amazon EMR Serverless, AWS Clean Rooms, AWS IoT FleetWise, AWS IoT RoboRunner and 31 other AWS services. In addition, Step Functions also added support for 1000+ new API actions from new and existing AWS services such as Amazon DynamoDB and Amazon Athena. For the full list of added services, visit AWS SDK service integrations.

    Amazon EventBridge

    Amazon EventBridge has launched the AWS Controllers for Kubernetes (ACK) for EventBridge and Pipes . This allows you to manage EventBridge resources, such as event buses, rules, and pipes, using the Kubernetes API and resource model (custom resource definitions).

    EventBridge event buses now also support enhanced integration with Service Quotas. Your quota increase requests for limits such as PutEvents transactions-per-second, number of rules, and invocations per second among others will be processed within one business day or faster, enabling you to respond quickly to changes in usage.

    AWS SAM

    The AWS Serverless Application Model (SAM) Command Line Interface (CLI) has added the sam list command. You can now show resources defined in your application, including the endpoints, methods, and stack outputs required to test your deployed application.

    AWS SAM has a preview of sam build support for building and packaging serverless applications developed in Rust. You can use cargo-lambda in the AWS SAM CLI build workflow and AWS SAM Accelerate to iterate on your code changes rapidly in the cloud.

    You can now use AWS SAM connectors as a source resource parameter. Previously, you could only define AWS SAM connectors as a AWS::Serverless::Connector resource. Now you can add the resource attribute on a connector’s source resource, which makes templates more readable and easier to update over time.

    AWS SAM connectors now also support multiple destinations to simplify your permissions. You can now use a single connector between a single source resource and multiple destination resources.

    In October 2022, AWS released OpenID Connect (OIDC) support for AWS SAM Pipelines. This improves your security posture by creating integrations that use short-lived credentials from your CI/CD provider. There is a new blog post on how to implement it.

    Find out how best to build serverless Java applications with the AWS SAM CLI.

    AWS App Runner

    AWS App Runner now supports retrieving secrets and configuration data stored in AWS Secrets Manager and AWS Systems Manager (SSM) Parameter Store in an App Runner service as runtime environment variables.

    AppRunner also now supports incoming requests based on HTTP 1.0 protocol, and has added service level concurrency, CPU and Memory utilization metrics.

    Amazon S3

    Amazon S3 now automatically applies default encryption to all new objects added to S3, at no additional cost and with no impact on performance.

    You can now use an S3 Object Lambda Access Point alias as an origin for your Amazon CloudFront distribution to tailor or customize data to end users. For example, you can resize an image depending on the device that an end user is visiting from.

    S3 has introduced Mountpoint for S3, a high performance open source file client that translates local file system API calls to S3 object API calls like GET and LIST.

    S3 Multi-Region Access Points now support datasets that are replicated across multiple AWS accounts. They provide a single global endpoint for your multi-region applications, and dynamically route S3 requests based on policies that you define. This helps you to more easily implement multi-Region resilience, latency-based routing, and active-passive failover, even when data is stored in multiple accounts.

    Amazon Kinesis

    Amazon Kinesis Data Firehose now supports streaming data delivery to Elastic. This is an easier way to ingest streaming data to Elastic and consume the Elastic Stack (ELK Stack) solutions for enterprise search, observability, and security without having to manage applications or write code.

    Amazon DynamoDB

    Amazon DynamoDB now supports table deletion protection to protect your tables from accidental deletion when performing regular table management operations. You can set the deletion protection property for each table, which is set to disabled by default.

    Amazon SNS

    Amazon SNS now supports AWS X-Ray active tracing to visualize, analyze, and debug application performance. You can now view traces that flow through Amazon SNS topics to destination services, such as Amazon Simple Queue Service, Lambda, and Kinesis Data Firehose, in addition to traversing the application topology in Amazon CloudWatch ServiceLens.

    SNS also now supports setting content-type request headers for HTTPS notifications so applications can receive their notifications in a more predictable format. Topic subscribers can create a DeliveryPolicy that specifies the content-type value that SNS assigns to their HTTPS notifications, such as application/json, application/xml, or text/plain.

    EDA Visuals collection added to Serverless Land

    The Serverless Developer Advocate team has extended Serverless Land and introduced EDA visuals. These are small bite sized visuals to help you understand concept and patterns about event-driven architectures. Find out about batch processing vs. event streaming, commands vs. events, message queues vs. event brokers, and point-to-point messaging. Discover bounded contexts, migrations, idempotency, claims, enrichment and more!

    EDA-visuals

    EDA Visuals

    To learn more:

    Serverless Repos Collection on Serverless Land

    There is also a new section on Serverless Land containing helpful code repositories. You can search for code repos to use for examples, learning or building serverless applications. You can also filter by use-case, runtime, and level.

    Serverless Repos Collection

    Serverless Repos Collection

    Serverless Blog Posts

    January

    Jan 12 – Introducing maximum concurrency of AWS Lambda functions when using Amazon SQS as an event source

    Jan 20 – Processing geospatial IoT data with AWS IoT Core and the Amazon Location Service

    Jan 23 – AWS Lambda: Resilience under-the-hood

    Jan 24 – Introducing AWS Lambda runtime management controls

    Jan 24 – Best practices for working with the Apache Velocity Template Language in Amazon API Gateway

    February

    Feb 6 – Previewing environments using containerized AWS Lambda functions

    Feb 7 – Building ad-hoc consumers for event-driven architectures

    Feb 9 – Implementing architectural patterns with Amazon EventBridge Pipes

    Feb 9 – Securing CI/CD pipelines with AWS SAM Pipelines and OIDC

    Feb 9 – Introducing new asynchronous invocation metrics for AWS Lambda

    Feb 14 – Migrating to token-based authentication for iOS applications with Amazon SNS

    Feb 15 – Implementing reactive progress tracking for AWS Step Functions

    Feb 23 – Developing portable AWS Lambda functions

    Feb 23 – Uploading large objects to Amazon S3 using multipart upload and transfer acceleration

    Feb 28 – Introducing AWS Lambda Powertools for .NET

    March

    Mar 9 – Server-side rendering micro-frontends – UI composer and service discovery

    Mar 9 – Building serverless Java applications with the AWS SAM CLI

    Mar 10 – Managing sessions of anonymous users in WebSocket API-based applications

    Mar 14 –
    Implementing an event-driven serverless story generation application with ChatGPT and DALL-E

    Videos

    Serverless Office Hours – Tues 10AM PT

    Weekly office hours live stream. In each session we talk about a specific topic or technology related to serverless and open it up to helping you with your real serverless challenges and issues. Ask us anything you want about serverless technologies and applications.

    January

    Jan 10 – Building .NET 7 high performance Lambda functions

    Jan 17 – Amazon Managed Workflows for Apache Airflow at Scale

    Jan 24 – Using Terraform with AWS SAM

    Jan 31 – Preparing your serverless architectures for the big day

    February

    Feb 07- Visually design and build serverless applications

    Feb 14 – Multi-tenant serverless SaaS

    Feb 21 – Refactoring to Serverless

    Feb 28 – EDA visually explained

    March

    Mar 07 – Lambda cookbook with Python

    Mar 14 – Succeeding with serverless

    Mar 21 – Lambda Powertools .NET

    Mar 28 – Server-side rendering micro-frontends

    FooBar Serverless YouTube channel

    Marcia Villalba frequently publishes new videos on her popular serverless YouTube channel. You can view all of Marcia’s videos at https://www.youtube.com/c/FooBar_codes.

    January

    Jan 12 – Serverless Badge – A new certification to validate your Serverless Knowledge

    Jan 19 – Step functions Distributed map – Run 10k parallel serverless executions!

    Jan 26 – Step Functions Intrinsic Functions – Do simple data processing directly from the state machines!

    February

    Feb 02 – Unlock the Power of EventBridge Pipes: Integrate Across Platforms with Ease!

    Feb 09 – Amazon EventBridge Pipes: Enrichment and filter of events Demo with AWS SAM

    Feb 16 – AWS App Runner – Deploy your apps from GitHub to Cloud in Record Time

    Feb 23 – AWS App Runner – Demo hosting a Node.js app in the cloud directly from GitHub (AWS CDK)

    March

    Mar 02 – What is Amazon DynamoDB? What are the most important concepts? What are the indexes?

    Mar 09 – Choreography vs Orchestration: Which is Best for Your Distributed Application?

    Mar 16 – DynamoDB Single Table Design: Simplify Your Code and Boost Performance with Table Design Strategies

    Mar 23 – 8 Reasons You Should Choose DynamoDB for Your Next Project and How to Get Started

    Sessions with SAM & Friends

    SAMFiends

    AWS SAM & Friends

    Eric Johnson is exploring how developers are building serverless applications. We spend time talking about AWS SAM as well as others like AWS CDK, Terraform, Wing, and AMPT.

    Feb 16 – What’s new with AWS SAM

    Feb 23 – AWS SAM with AWS CDK

    Mar 02 – AWS SAM and Terraform

    Mar 10 – Live from ServerlessDays ANZ

    Mar 16 – All about AMPT

    Mar 23 – All about Wing

    Mar 30 – SAM Accelerate deep dive

    Still looking for more?

    The Serverless landing page has more information. The Lambda resources page contains case studies, webinars, whitepapers, customer stories, reference architectures, and even more Getting Started tutorials.

    You can also follow the Serverless Developer Advocacy team on Twitter to see the latest news, follow conversations, and interact with the team.

    Introducing AWS Lambda Powertools for .NET

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/introducing-aws-lambda-powertools-for-net/

    This blog post is written by Amir Khairalomoum, Senior Solutions Architect.

    Modern applications are built with modular architectural patterns, serverless operational models, and agile developer processes. They allow you to innovate faster, reduce risk, accelerate time to market, and decrease your total cost of ownership (TCO). A microservices architecture comprises many distributed parts that can introduce complexity to application observability. Modern observability must respond to this complexity, the increased frequency of software deployments, and the short-lived nature of AWS Lambda execution environments.

    The Serverless Applications Lens for the AWS Well-Architected Framework focuses on how to design, deploy, and architect your serverless application workloads in the AWS Cloud. AWS Lambda Powertools for .NET translates some of the best practices defined in the serverless lens into a suite of utilities. You can use these in your application to apply structured logging, distributed tracing, and monitoring of metrics.

    Following the community’s continued adoption of AWS Lambda Powertools for Python, Java, and TypeScript, AWS Lambda Powertools for .NET is now generally available.

    This post shows how to use the new open source Powertools library to implement observability best practices with minimal coding. It walks through getting started, with the provided examples available in the Powertools GitHub repository.

    About Powertools

    Powertools for .NET is a suite of utilities that helps with implementing observability best practices without needing to write additional custom code. It currently supports Lambda functions written in C#, with support for runtime versions .NET 6 and newer. Powertools provides three core utilities:

    • Tracing provides a simpler way to send traces from functions to AWS X-Ray. It provides visibility into function calls, interactions with other AWS services, or external HTTP requests. You can add attributes to traces to allow filtering based on key information. For example, when using the Tracing attribute, it creates a ColdStart annotation. You can easily group and analyze traces to understand the initialization process.
    • Logging provides a custom logger that outputs structured JSON. It allows you to pass in strings or more complex objects, and takes care of serializing the log output. The logger handles common use cases, such as logging the Lambda event payload, and capturing cold start information. This includes appending custom keys to the logger.
    • Metrics simplifies collecting custom metrics from your application, without the need to make synchronous requests to external systems. This functionality allows capturing metrics asynchronously using Amazon CloudWatch Embedded Metric Format (EMF) which reduces latency and cost. This provides convenient functionality for common cases, such as validating metrics against CloudWatch EMF specification and tracking cold starts.

    Getting started

    The following steps explain how to use Powertools to implement structured logging, add custom metrics, and enable tracing with AWS X-Ray. The example application consists of an Amazon API Gateway endpoint, a Lambda function, and an Amazon DynamoDB table. It uses the AWS Serverless Application Model (AWS SAM) to manage the deployment.

    When you send a GET request to the API Gateway endpoint, the Lambda function is invoked. This function calls a location API to find the IP address, stores it in the DynamoDB table, and returns it with a greeting message to the client.

    Example application

    Example application

    The AWS Lambda Powertools for .NET utilities are available as NuGet packages. Each core utility has a separate NuGet package. It allows you to add only the packages you need. This helps to make the Lambda package size smaller, which can improve the performance.

    To implement each of these core utilities in a separate example, use the Globals sections of the AWS SAM template to configure Powertools environment variables and enable active tracing for all Lambda functions and Amazon API Gateway stages.

    Sometimes resources that you declare in an AWS SAM template have common configurations. Instead of duplicating this information in every resource, you can declare them once in the Globals section and let your resources inherit them.

    Logging

    The following steps explain how to implement structured logging in an application. The logging example shows you how to use the logging feature.

    To add the Powertools logging library to your project, install the packages from NuGet gallery, from Visual Studio editor, or by using following .NET CLI command:

    dotnet add package AWS.Lambda.Powertools.Logging

    Use environment variables in the Globals sections of the AWS SAM template to configure the logging library:

      Globals:
        Function:
          Environment:
            Variables:
              POWERTOOLS_SERVICE_NAME: powertools-dotnet-logging-sample
              POWERTOOLS_LOG_LEVEL: Debug
              POWERTOOLS_LOGGER_CASE: SnakeCase

    Decorate the Lambda function handler method with the Logging attribute in the code. This enables the utility and allows you to use the Logger functionality to output structured logs by passing messages as a string. For example:

    [Logging]
    public async Task<APIGatewayProxyResponse> FunctionHandler
             (APIGatewayProxyRequest apigProxyEvent, ILambdaContext context)
    {
      ...
      Logger.LogInformation("Getting ip address from external service");
      var location = await GetCallingIp();
      ...
    }

    Lambda sends the output to Amazon CloudWatch Logs as a JSON-formatted line.

    {
      "cold_start": true,
      "xray_trace_id": "1-621b9125-0a3b544c0244dae940ab3405",
      "function_name": "powertools-dotnet-tracing-sampl-HelloWorldFunction-v0F2GJwy5r1V",
      "function_version": "$LATEST",
      "function_memory_size": 256,
      "function_arn": "arn:aws:lambda:eu-west-2:286043031651:function:powertools-dotnet-tracing-sample-HelloWorldFunction-v0F2GJwy5r1V",
      "function_request_id": "3ad9140b-b156-406e-b314-5ac414fecde1",
      "timestamp": "2022-02-27T14:56:39.2737371Z",
      "level": "Information",
      "service": "powertools-dotnet-sample",
      "name": "AWS.Lambda.Powertools.Logging.Logger",
      "message": "Getting ip address from external service"
    }

    Another common use case, especially when developing new Lambda functions, is to print a log of the event received by the handler. You can achieve this by enabling LogEvent on the Logging attribute. This is disabled by default to prevent potentially leaking sensitive event data into logs.

    [Logging(LogEvent = true)]
    public async Task<APIGatewayProxyResponse> FunctionHandler
             (APIGatewayProxyRequest apigProxyEvent, ILambdaContext context)
    {
      ...
    }

    With logs available as structured JSON, you can perform searches on this structured data using CloudWatch Logs Insights. To search for all logs that were output during a Lambda cold start, and display the key fields in the output, run following query:

    fields coldStart='true'
    | fields @timestamp, function_name, function_version, xray_trace_id
    | sort @timestamp desc
    | limit 20
    CloudWatch Logs Insights query for cold starts

    CloudWatch Logs Insights query for cold starts

    Tracing

    Using the Tracing attribute, you can instruct the library to send traces and metadata from the Lambda function invocation to AWS X-Ray using the AWS X-Ray SDK for .NET. The tracing example shows you how to use the tracing feature.

    When your application makes calls to AWS services, the SDK tracks downstream calls in subsegments. AWS services that support tracing, and resources that you access within those services, appear as downstream nodes on the service map in the X-Ray console.

    You can instrument all of your AWS SDK for .NET clients by calling RegisterXRayForAllServices before you create them.

    public class Function
    {
      private static IDynamoDBContext _dynamoDbContext;
      public Function()
      {
        AWSSDKHandler.RegisterXRayForAllServices();
        ...
      }
      ...
    }

    To add the Powertools tracing library to your project, install the packages from NuGet gallery, from Visual Studio editor, or by using following .NET CLI command:

    dotnet add package AWS.Lambda.Powertools.Tracing

    Use environment variables in the Globals sections of the AWS SAM template to configure the tracing library.

      Globals:
        Function:
          Tracing: Active
          Environment:
            Variables:
              POWERTOOLS_SERVICE_NAME: powertools-dotnet-tracing-sample
              POWERTOOLS_TRACER_CAPTURE_RESPONSE: true
              POWERTOOLS_TRACER_CAPTURE_ERROR: true

    Decorate the Lambda function handler method with the Tracing attribute to enable the utility. To provide more granular details for your traces, you can use the same attribute to capture the invocation of other functions outside of the handler. For example:

    [Tracing]
    public async Task<APIGatewayProxyResponse> FunctionHandler
             (APIGatewayProxyRequest apigProxyEvent, ILambdaContext context)
    {
      ...
      var location = await GetCallingIp().ConfigureAwait(false);
      ...
    }
    
    [Tracing(SegmentName = "Location service")]
    private static async Task<string?> GetCallingIp()
    {
      ...
    }

    Once traffic is flowing, you see a generated service map in the AWS X-Ray console. Decorating the Lambda function handler method, or any other method in the chain with the Tracing attribute, provides an overview of all the traffic flowing through the application.

    AWS X-Ray trace service view

    AWS X-Ray trace service view

    You can also view the individual traces that are generated, along with a waterfall view of the segments and subsegments that comprise your trace. This data can help you pinpoint the root cause of slow operations or errors within your application.

    AWS X-Ray waterfall trace view

    AWS X-Ray waterfall trace view

    You can also filter traces by annotation and create custom service maps with AWS X-Ray Trace groups. In this example, use the filter expression annotation.ColdStart = true to filter traces based on the ColdStart annotation. The Tracing attribute adds these automatically when used within the handler method.

    View trace attributes

    View trace attributes

    Metrics

    CloudWatch offers a number of included metrics to help answer general questions about the application’s throughput, error rate, and resource utilization. However, to understand the behavior of the application better, you should also add custom metrics relevant to your workload.

    The metrics utility creates custom metrics asynchronously by logging metrics to standard output using the Amazon CloudWatch Embedded Metric Format (EMF).

    In the sample application, you want to understand how often your service is calling the location API to identify the IP addresses. The metrics example shows you how to use the metrics feature.

    To add the Powertools metrics library to your project, install the packages from the NuGet gallery, from the Visual Studio editor, or by using the following .NET CLI command:

    dotnet add package AWS.Lambda.Powertools.Metrics

    Use environment variables in the Globals sections of the AWS SAM template to configure the metrics library:

      Globals:
        Function:
          Environment:
            Variables:
              POWERTOOLS_SERVICE_NAME: powertools-dotnet-metrics-sample
              POWERTOOLS_METRICS_NAMESPACE: AWSLambdaPowertools

    To create custom metrics, decorate the Lambda function with the Metrics attribute. This ensures that all metrics are properly serialized and flushed to logs when the function finishes its invocation.

    You can then emit custom metrics by calling AddMetric or push a single metric with a custom namespace, service and dimensions by calling PushSingleMetric. You can also enable the CaptureColdStart on the attribute to automatically create a cold start metric.

    [Metrics(CaptureColdStart = true)]
    public async Task<APIGatewayProxyResponse> FunctionHandler
             (APIGatewayProxyRequest apigProxyEvent, ILambdaContext context)
    {
      ...
      // Add Metric to capture the amount of time
      Metrics.PushSingleMetric(
            metricName: "CallingIP",
            value: 1,
            unit: MetricUnit.Count,
            service: "lambda-powertools-metrics-example",
            defaultDimensions: new Dictionary<string, string>
            {
                { "Metric Type", "Single" }
            });
      ...
    }

    Conclusion

    CloudWatch and AWS X-Ray offer functionality that provides comprehensive observability for your applications. Lambda Powertools .NET is now available in preview. The library helps implement observability when running Lambda functions based on .NET 6 while reducing the amount of custom code.

    It simplifies implementing the observability best practices defined in the Serverless Applications Lens for the AWS Well-Architected Framework for a serverless application and allows you to focus more time on the business logic.

    You can find the full documentation and the source code for Powertools in GitHub. We welcome contributions via pull request, and encourage you to create an issue if you have any feedback for the project. Happy building with AWS Lambda Powertools for .NET.

    For more serverless learning resources, visit Serverless Land.

    Introducing AWS Lambda runtime management controls

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/introducing-aws-lambda-runtime-management-controls/

    This blog post is written by Jonathan Tuliani, Principal Product Manager.

    Today, AWS Lambda is announcing runtime management controls which provide more visibility and control over when Lambda applies runtime updates to your functions. Lambda is also changing how it rolls out automatic runtime updates to your functions. Together, these changes provide more flexibility in how you take advantage of the latest runtime features, performance improvements, and security updates.

    By default, all functions will continue to receive automatic runtime updates. You do not need to change how you use Lambda to continue to benefit from the security and operational simplicity of the managed runtimes Lambda provides. The runtime controls are optional capabilities for advanced customers that require more control over their runtime changes.

    This post explains what new runtime management controls are available and how you can take advantage of this new capability.

    Overview

    For each runtime, Lambda provides a managed execution environment. This includes the underlying Amazon Linux operating system, programming language runtime, and AWS SDKs. Lambda takes on the operational burden of applying patches and security updates to all these components. Customers tell us how much they appreciate being able to deploy a function and leave it, sometimes for years, without having to apply patches. With Lambda, patching ‘just works’, automatically.

    Lambda strives to provide updates which are backward compatible with existing functions. However, as with all software patching, there are rare cases where a patch can expose an underlying issue with an existing function that depends on the previous behavior. For example, consider a bug in one of the runtime OS packages. Applying a patch to fix the bug is the right choice for the vast majority of customers and functions. However, in rare cases, a function may depend on the previous (incorrect) behavior. Customers with critical workloads running in Lambda tell us they would like a way to further mitigate even this slight risk of disruption.

    With the launch of runtime management controls, Lambda now offers three new capabilities. First, Lambda provides visibility into which patch version of a runtime your function is using and when runtime updates are applied. Second, you can optionally synchronize runtime updates with function deployments. This provides you with control over when Lambda applies runtime updates and enables early detection of rare runtime update incompatibilities. Third, in the rare case where a runtime update incompatibility occurs, you can roll back your function to an earlier runtime version. This keeps your function working and minimizes disruption, providing time to remedy the incompatibility before returning to the latest runtime version.

    Runtime identifiers and runtime versions

    Lambda runtimes define the components of the execution environment in which your function code runs. This includes the OS, programming language runtime, environment variables, and certificates. For Python, Node.js and Ruby, the runtime also includes the AWS SDK. Each Lambda runtime has a unique runtime identifier, for example, nodejs18.x, or python3.9. Each runtime identifier represents a distinct major release of the programming language.

    Runtime management controls introduce the concept of Lambda runtime versions. A runtime version is an immutable version of a particular runtime. Each Lambda runtime, such as Node.js 16, or Python 3.9, starts with an initial runtime version. Every time Lambda updates the runtime, it adds a new runtime version to that runtime. These updates cover all runtime components (OS, language runtime, etc.) and therefore use a Lambda-defined numbering scheme, independent of the version numbers used by the programming language. For each runtime version, Lambda also publishes a corresponding base image for customers who package their functions as container images.

    New runtime identifiers represent a major release for the programming language, and sometimes other runtime components, such as the OS or SDK. Lambda cannot guarantee compatibility between runtime identifiers, although most times you can upgrade your functions with little or no modification. You control when you upgrade your functions to a new runtime identifier. In contrast, new runtime versions for the same runtime identifier have a very high level of backward compatibility with existing functions. By default, Lambda automatically applies runtime updates by moving functions from the previous runtime version to a newer runtime version.

    Each runtime version has a version number, and an Amazon Resource Name (ARN). You can view the version in a new platform log line, INIT_START. Lambda emits this log line each time it creates a new execution environment during the cold start initialization process.

    INIT_START Runtime Version: python:3.9.v14	Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I

    INIT_START Runtime Version: python:3.9.v14 Runtime Version ARN: arn:aws:lambda:eu-south-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6I

    Runtime versions improve visibility into managed runtime updates. You can use the INIT_START log line to identify when the function transitions from one runtime version to another. This helps you investigate whether a runtime update might have caused any unexpected behavior of your functions. Changes in behavior caused by runtime updates are very rare. If your function isn’t behaving as expected, by far the most likely cause is an error in the function code or configuration.

    Runtime management modes

    With runtime management controls, you now have more control over when Lambda applies runtime updates to your functions. You can now specify a runtime management configuration for each function. You can set the runtime management configuration independently for $LATEST and each published function version.

    You can specify one of three runtime update modes: auto, function update, or manual. The runtime update mode controls when Lambda updates the function version to a new runtime version. By default, all functions receive runtime updates automatically, the alternatives are for advanced users in specific cases.

    Automatic

    Auto updates are the default, and are the right choice for most customers to ensure that you continue to benefit from runtime version updates. They help minimize your operational overheads by letting Lambda take care of runtime updates.

    While Lambda has always provided automatic runtime updates, this release includes a change to how automatic runtime updates are rolled out. Previously, Lambda applied runtime updates to all functions in each region, following a region-by-region deployment sequence. With this release, functions configured to use the auto runtime update mode now receive runtime updates in two phases. Initially, Lambda only applies a new runtime version to newly created or updated functions. After this initial period is complete, Lambda then applies the runtime update to any remaining functions configured to use the auto runtime update mode.

    This two-phase rollout synchronizes runtime updates with function updates for customers who are actively developing their functions. This makes it easier to detect and respond to any unexpected changes in behavior. For functions not in active development, auto mode continues to provide the operational benefits of fully automatic runtime updates.

    Function update

    In function update mode, Lambda updates your function to the latest available runtime version whenever you change your function code or configuration. This is the same as the first phase of auto mode. The difference is that, in auto mode, there is a second phase when Lambda applies runtime updates to functions which have not been changed. In function update mode, if you do not change a function, it continues to use the current runtime version indefinitely. This means that when using function update mode, you must update your functions regularly to keep their runtimes up-to-date. If you do not update a function regularly, you should use the auto runtime update mode.

    Synchronizing runtime updates with function deployments gives you control over when Lambda applies runtime updates. For example, you can avoid applying updates during business-critical events, such as a product launch or holiday sales.

    When used with CI/CD pipelines, function update mode enables early detection and mitigation in the rare event of a runtime update incompatibility. This is especially effective if you create a new published function version with each deployment. Each published function version captures a static copy of the function code and configuration, so that you can roll back to a previously published function version if required. Using function update mode extends the published function version to also capture the runtime version. This allows you to synchronize rollout and rollback of the entire Lambda execution environment, including function code, configuration, and runtime version.

    Manual

    Consider the rare event that a runtime update is incompatible with one of your functions. With runtime management controls, you can now roll back to an earlier runtime version. This keeps your function working and minimizes disruption, giving you time to remedy the incompatibility before returning to the latest runtime version.

    There are two ways to implement a runtime version rollback. You can use function update mode with a published function version to synchronize the rollback of code, configuration, and runtime version. Or, for functions using the default auto runtime update mode, you can roll back your runtime version by using manual mode.

    The manual runtime update mode provides you with full control over which runtime version your function uses. When enabling manual mode, you must specify the ARN of the runtime version to use, which you can find from the INIT_START log line.

    Lambda does not impose a time limit on how long you can use any particular runtime version. However, AWS strongly recommends using manual mode only for short-term remediation of code incompatibilities. Revert your function back to auto mode as soon as you resolve the issue. Functions using the same runtime version for an extended period may eventually stop working due to, for example, a certificate expiry.

    Using runtime management controls

    You can configure runtime management controls via the Lambda AWS Management Console and AWS Command Line Interface (AWS CLI). You can also use infrastructure as code tools such as AWS CloudFormation and the AWS Serverless Application Model (AWS SAM).

    Console

    From the Lambda console, navigate to a specific function. You can find runtime management controls on the Code tab, in the Runtime settings panel. Expand Runtime management configuration to view the current runtime update mode and runtime version ARN.

    Runtime settings

    Runtime settings

    To change runtime update mode, select Edit runtime management configuration. You can choose between automatic, function update, and manual runtime update modes.

    Edit runtime management configuration (Auto)

    Edit runtime management configuration (Auto)

    In manual mode, you must also specify the runtime version ARN.

    Edit runtime management configuration (Manual)

    Edit runtime management configuration (Manual)

    AWS SAM

    AWS SAM is an open-source framework for building serverless applications. You can specify runtime management settings using the RuntimeManagementConfig property.

    Resources:
      HelloWorldFunction:
        Type: AWS::Serverless::Function
        Properties:
          Handler: lambda_function.handler
          Runtime: python3.9
          RuntimeManagementConfig:
            UpdateOn: Manual
            RuntimeVersionArn: arn:aws:lambda:eu-west-1::runtime:7b620fc2e66107a1046b140b9d320295811af3ad5d4c6a011fad1fa65127e9e6

    AWS CLI

    You can also manage runtime management settings using the AWS CLI. You configure runtime management controls via a dedicated command aws lambda put-runtime-management-config, rather than aws lambda update-function-configuration.

    aws lambda put-runtime-management-config --function-name <function_arn> --update-runtime-on Manual --runtime-version-arn <runtime_version_arn>

    To view the existing runtime management configuration, use aws lambda get-runtime-management-config.

    aws lambda get-runtime-management-config --function-name <function_arn>

    The current runtime version ARN is also returned by aws lambda get-function and aws lambda get-function-configuration.

    Conclusion

    Runtime management controls provide more visibility and flexibility over when and how Lambda applies runtime updates to your functions. You can specify one of three update modes: auto, function update, or manual. These modes allow you to continue to take advantage of Lambda’s automatic patching, synchronize runtime updates with your deployments, and rollback to an earlier runtime version in the rare event that a runtime update negatively impacts your function.

    For more information on runtime management controls, see our documentation page.

    For more serverless learning resources, visit Serverless Land.

    Introducing maximum concurrency of AWS Lambda functions when using Amazon SQS as an event source

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/

    This blog post is written by Solutions Architects John Lee and Jeetendra Vaidya.

    AWS Lambda now provides a way to control the maximum number of concurrent functions invoked by Amazon SQS as an event source. You can use this feature to control the concurrency of Lambda functions processing messages in individual SQS queues.

    This post describes how to set the maximum concurrency of SQS triggers when using SQS as an event source with Lambda. It also provides an overview of the scaling behavior of Lambda using this architectural pattern, challenges this feature helps address, and a demo of the maximum concurrency feature.

    Overview

    Lambda uses an event source mapping to process items from a stream or queue. The event source mapping reads from an event source, such as an SQS queue, optionally filters the messages, batches them, and invokes the mapped Lambda function.

    The scaling behavior for Lambda integration with SQS FIFO queues is simple. A single Lambda function processes batches of messages within a single message group to ensure that messages are processed in order.

    For SQS standard queues, the event source mapping polls the queue to consume incoming messages, starting at five concurrent batches with five functions at a time. As messages are added to the SQS queue, Lambda continues to scale out to meet demand, adding up to 60 functions per minute, up to 1,000 functions, to consume those messages. To learn more about Lambda scaling behavior, read ”Understanding how AWS Lambda scales with Amazon SQS standard queues.”

    Lambda processing standard SQS queues

    Lambda processing standard SQS queues

    Challenges

    When a large number of messages are in the SQS queue, Lambda scales out, adding additional functions to process the messages. The scale out can consume the concurrency quota in the account. To prevent this from happening, you can set reserved concurrency for individual Lambda functions. This ensures that the specified Lambda function can always scale to that much concurrency, but it also cannot exceed this number.

    When the Lambda function concurrency reaches the reserved concurrency limit, the queue configuration specifies the subsequent behavior. The message is returned to the queue and retried based on the redrive policy, expired based on its retention policy, or sent to another SQS dead-letter queue (DLQ). While sending unprocessed messages to a DLQ is a good option to preserve messages, it requires a separate mechanism to inspect and process messages from the DLQ.

    The following example shows a Lambda function reaching its reserved concurrency quota of 10.

    Lambda reaching reserved concurrency of 10.

    Lambda reaching reserved concurrency of 10.

    Maximum Lambda concurrency with SQS as an event source

    The launch of maximum concurrency for SQS as an event source allows you to control Lambda function concurrency per source. You set the maximum concurrency on the event source mapping, not on the Lambda function.

    This event source mapping setting does not change the scaling or batching behavior of Lambda with SQS. You can continue to batch messages with a customized batch size and window. It rather sets a limit on the maximum number of concurrent function invocations per SQS event source. Once Lambda scales and reaches the maximum concurrency configured on the event source, Lambda stops reading more messages from the queue. This feature also provides you with the flexibility to define the maximum concurrency for individual event sources when the Lambda function has multiple event sources.

    Maximum concurrency is set to 10 for the SQS queue.

    Maximum concurrency is set to 10 for the SQS queue.

    This feature can help prevent a Lambda function from consuming all available Lambda concurrency of the account and avoids messages returning to the queue unnecessarily because of Lambda functions being throttled. It provides an easier way to control and consume messages at a desired pace, controlled by the maximum number of concurrent Lambda functions.

    The maximum concurrency setting does not replace the existing reserved concurrency feature. Both serve distinct purposes and the two features can be used together. Maximum concurrency can help prevent overwhelming downstream systems and unnecessary throttled invocations. Reserved concurrency guarantees a maximum number of concurrent instances for the function.

    When used together, the Lambda function can have its own allocated capacity (reserved concurrency), while being able to control the throughput for each event source (maximum concurrency). When using the two features together, you must set the function reserved concurrency higher than the maximum concurrency on the SQS event source mapping to prevent throttling.

    Setting maximum concurrency for SQS as an event source

    You can configure the maximum concurrency for an SQS event source through the AWS Management Console, AWS Command Line Interface (CLI), or infrastructure as code tools such as AWS Serverless Application Model (AWS SAM). The minimum supported value is 2 and the maximum value is 1000. Refer to the Lambda quotas documentation for the latest limits.

    Configuring the maximum concurrency for an SQS trigger in the console

    Configuring the maximum concurrency for an SQS trigger in the console

    You can set the maximum concurrency through the create-event-source-mapping AWS CLI command.

    aws lambda create-event-source-mapping --function-name my-function --ScalingConfig {MaxConcurrency=2} --event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue

    Seeing the maximum concurrency setting in action

    The following demo compares Lambda receiving and processes messages differently when using maximum concurrency compared to reserved concurrency.

    This GitHub repository contains an AWS SAM template that deploys the following resources:

    • ReservedConcurrencyQueue (SQS queue)
    • ReservedConcurrencyDeadLetterQueue (SQS queue)
    • ReservedConcurrencyFunction (Lambda function)
    • MaxConcurrencyQueue (SQS queue)
    • MaxConcurrencyDeadLetterQueue (SQS queue)
    • MaxConcurrencyFunction (Lambda function)
    • CloudWatchDashboard (CloudWatch dashboard)

    The AWS SAM template provisions two sets of identical architectures and an Amazon CloudWatch dashboard to monitor the resources. Each architecture comprises a Lambda function receiving messages from an SQS queue, and a DLQ for the SQS queue.

    The maxReceiveCount is set as 1 for the SQS queues, which sends any returned messages directly to the DLQ. The ReservedConcurrencyFunction has its reserved concurrency set to 5, and the MaxConcurrencyFunction has the maximum concurrency for the SQS event source set to 5.

    Pre-requisites

    Running this demo requires the AWS CLI and the AWS SAM CLI. After installing both CLIs, clone this GitHub repository and navigate to the root of the directory:

    git clone https://github.com/aws-samples/aws-lambda-amazon-sqs-max-concurrency
    cd aws-lambda-amazon-sqs-max-concurrency

    Deploying the AWS SAM template

    1. Build the AWS SAM template with the build command to prepare for deployment to your AWS environment.
    2. sam build
    3. Use the guided deploy command to deploy the resources in your account.
    4. sam deploy --guided
    5. Give the stack a name and accept the remaining default values. Once deployed, you can track the progress through the CLI or by navigating to the AWS CloudFormation page in the AWS Management Console.
    6. Note the queue URLs from the Outputs tab in the AWS SAM CLI, CloudFormation console, or navigate to the SQS console to find the queue URLs.
    The Outputs tab of the launched AWS SAM template provides URLs to CloudWatch dashboard and SQS queues.

    The Outputs tab of the launched AWS SAM template provides URLs to CloudWatch dashboard and SQS queues.

    Running the demo

    The deployed Lambda function code simulates processing by sleeping for 10 seconds before returning a 200 response. This allows the function to reach a high function concurrency number with only a small number of messages.

    To add 25 messages to the Reserved Concurrency queue, run the following commands. Replace <ReservedConcurrencyQueueURL> with your queue URL from the AWS SAM Outputs.

    for i in {1..25}; do aws sqs send-message --queue-url <ReservedConcurrencyQueueURL> --message-body testing; done 

    To add 25 messages to the Maximum Concurrency queue, run the following commands. Replace <MaxConcurrencyQueueURL> with your queue URL from the AWS SAM Outputs.

    for i in {1..25}; do aws sqs send-message --queue-url <MaxConcurrencyQueueURL> --message-body testing; done 

    After sending messages to both queues, navigate to the dashboard URL available in the Outputs tab to view the CloudWatch dashboard.

    Validating results

    Both Lambda functions have the same number of invocations and the same concurrent invocations fixed at 5. The CloudWatch dashboard shows the ReservedConcurrencyFunction experienced throttling and 9 messages, as seen in the top-right metric, were sent to the corresponding DLQ. The MaxConcurrencyFunction did not experience any throttling and messages were not delivered to the DLQ.

    CloudWatch dashboard showing throttling and DLQs.

    CloudWatch dashboard showing throttling and DLQs.

    Clean up

    To remove all the resources created in this demo, use the delete command and follow the prompts:

    sam delete

    Conclusion

    You can now control the maximum number of concurrent functions invoked by SQS as a Lambda event source. This post explains the scaling behavior of Lambda using this architectural pattern, challenges this feature helps address, and a demo of maximum concurrency in action.

    There are no additional charges to use this feature besides the standard SQS and Lambda charges. You can start using maximum concurrency for SQS as an event source with new or existing event source mappings by connecting it with SQS. This feature is available in all Regions where Lambda and SQS are available.

    For more serverless learning resources, visit Serverless Land.

    Introducing payload-based message filtering for Amazon SNS

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/introducing-payload-based-message-filtering-for-amazon-sns/

    This post is written by Prachi Sharma (Software Development Manager, Amazon SNS), Mithun Mallick (Principal Solutions Architect, AWS Integration Services), and Otavio Ferreira (Sr. Software Development Manager, Amazon SNS).

    Amazon Simple Notification Service (SNS) is a messaging service for Application-to-Application (A2A) and Application-to-Person (A2P) communication. The A2A functionality provides high-throughput, push-based, many-to-many messaging between distributed systems, microservices, and event-driven serverless applications. These applications include Amazon Simple Queue Service (SQS), Amazon Kinesis Data Firehose, AWS Lambda, and HTTP/S endpoints. The A2P functionality enables you to communicate with your customers via mobile text messages (SMS), mobile push notifications, and email notifications.

    Today, we’re introducing the payload-based message filtering option of SNS, which augments the existing attribute-based option, enabling you to offload additional filtering logic to SNS and further reduce your application integration costs. For more information, see Amazon SNS Message Filtering.

    Overview

    You use SNS topics to fan out messages from publisher systems to subscriber systems, addressing your application integration needs in a loosely-coupled way. Without message filtering, subscribers receive every message published to the topic, and require custom logic to determine whether an incoming message needs to be processed or filtered out. This results in undifferentiating code, as well as unnecessary infrastructure costs. With message filtering, subscribers set a filter policy to their SNS subscription, describing the characteristics of the messages in which they are interested. Thus, when a message is published to the topic, SNS can verify the incoming message against the subscription filter policy, and only deliver the message to the subscriber upon a match. For more information, see Amazon SNS Subscription Filter Policies.

    However, up until now, the message characteristics that subscribers could express in subscription filter policies were limited to metadata in message attributes. As a result, subscribers could not benefit from message filtering when the messages were published without attributes. Examples of such messages include AWS events published to SNS from 60+ other AWS services, like Amazon Simple Storage Service (S3), Amazon CloudWatch, and Amazon CloudFront. For more information, see Amazon SNS Event Sources.

    The new payload-based message filtering option in SNS empowers subscribers to express their SNS subscription filter policies in terms of the contents of the message. This new capability further enables you to use SNS message filtering for your event-driven architectures (EDA) and cross-account workloads, specifically where subscribers may not be able to influence a given publisher to have its events sent with attributes. With payload-based message filtering, you have a simple, no-code option to further prevent unwanted data from being delivered to and processed by subscriber systems, thereby simplifying the subscribers’ code as well as reducing costs associated with downstream compute infrastructure. This new message filtering option is available across SNS Standard and SNS FIFO topics, for JSON message payloads.

    Applying payload-based filtering in a use case

    Consider an insurance company moving their lead generation platform to a serverless architecture based on microservices, adopting enterprise integration patterns to help them develop and scale these microservices independently. The company offers a variety of insurance types to its customers, including auto and home insurance. The lead generation and processing workflow for each insurance type is different, and entails notifying different backend microservices, each designed to handle a specific type of insurance request.

    Payload filtering example

    Payload filtering example

    The company uses multiple frontend apps to interact with customers and receive leads from them, including a web app, a mobile app, and a call center app. These apps submit the customer-generated leads to an internal lead storage microservice, which then uploads the leads as XML documents to an S3 bucket. Next, the S3 bucket publishes events to an SNS topic to notify that lead documents have been created. Based on the contents of each lead document, the SNS topic forks the workflow by delivering the auto insurance leads to an SQS queue and the home insurance leads to another SQS queue. These SQS queues are respectively polled by the auto insurance and the home insurance lead processing microservices. Each processing microservice applies its business logic to validate the incoming leads.

    The following S3 event, in JSON format, refers to a lead document uploaded with key auto-insurance-2314.xml to the S3 bucket. S3 automatically publishes this event to SNS, which in turn matches the S3 event payload against the filter policy of each subscription in the SNS topic. If the event matches the subscription filter policy, SNS delivers the event to the subscribed SQS queue. Otherwise, SNS filters the event out.

    {
      "Records": [{
        "eventVersion": "2.1",
        "eventSource": "aws:s3",
        "awsRegion": "sa-east-1",
        "eventTime": "2022-11-21T03:41:29.743Z",
        "eventName": "ObjectCreated:Put",
        "userIdentity": {
          "principalId": "AWS:AROAJ7PQSU42LKEHOQNIC:demo-user"
        },
        "requestParameters": {
          "sourceIPAddress": "177.72.241.11"
        },
        "responseElements": {
          "x-amz-request-id": "SQCC55WT60XABW8CF",
          "x-amz-id-2": "FRaO+XDBrXtx0VGU1eb5QaIXH26tlpynsgaoJrtGYAWYRhfVMtq/...dKZ4"
        },
        "s3": {
          "s3SchemaVersion": "1.0",
          "configurationId": "insurance-lead-created",
          "bucket": {
            "name": "insurance-bucket-demo",
            "ownerIdentity": {
              "principalId": "A1ATLOAF34GO2I"
            },
            "arn": "arn:aws:s3:::insurance-bucket-demo"
          },
          "object": {
            "key": "auto-insurance-2314.xml",
            "size": 17,
            "eTag": "1530accf30cab891d759fa3bb8322211",
            "sequencer": "00737AF379B2683D6C"
          }
        }
      }]
    }
    

    To express its interest in auto insurance leads only, the SNS subscription for the auto insurance lead processing microservice sets the following filter policy. Note that, unlike attribute-based policies, payload-based policies support property nesting.

    {
      "Records": {
        "s3": {
          "object": {
            "key": [{
              "prefix": "auto-"
            }]
          }
        },
        "eventName": [{
          "prefix": "ObjectCreated:"
        }]
      }
    }
    

    Likewise, to express its interest in home insurance leads only, the SNS subscription for the home insurance lead processing microservice sets the following filter policy.

    {
      "Records": {
        "s3": {
          "object": {
            "key": [{
              "prefix": "home-"
            }]
          }
        },
        "eventName": [{
          "prefix": "ObjectCreated:"
        }]
      }
    }
    

    Note that each filter policy uses the string prefix matching capability of SNS message filtering. In this use case, this matching capability enables the filter policy to match only the S3 objects whose key property value starts with the insurance type it’s interested in (either auto- or home-). Note as well that each filter policy matches only the S3 events whose eventName property value starts with ObjectCreated, as opposed to ObjectRemoved. For more information, see Amazon S3 Event Notifications.

    Deploying the resources and filter policies

    To deploy the AWS resources for this use case, you need an AWS account with permissions to use SNS, SQS, and S3. On your development machine, install the AWS Serverless Application Model (SAM) Command Line Interface (CLI). You can find the complete SAM template for this use case in the aws-sns-samples repository in GitHub.

    The SAM template has a set of resource definitions, as presented below. The first resource definition creates the SNS topic that receives events from S3.

    InsuranceEventsTopic:
        Type: AWS::SNS::Topic
        Properties:
          TopicName: insurance-events-topic
    

    The next resource definition creates the S3 bucket where the insurance lead documents are stored. This S3 bucket publishes an event to the SNS topic whenever a new lead document is created.

    InsuranceEventsBucket:
        Type: AWS::S3::Bucket
        DeletionPolicy: Retain
        DependsOn: InsuranceEventsTopicPolicy
        Properties:
          BucketName: insurance-doc-events
          NotificationConfiguration:
            TopicConfigurations:
              - Topic: !Ref InsuranceEventsTopic
                Event: 's3:ObjectCreated:*'

    The next resource definitions create the SQS queues to be subscribed to the SNS topic. As presented in the architecture diagram, there’s one queue for auto insurance leads, and another queue for home insurance leads.

    AutoInsuranceEventsQueue:
        Type: AWS::SQS::Queue
        Properties:
          QueueName: auto-insurance-events-queue
          
    HomeInsuranceEventsQueue:
        Type: AWS::SQS::Queue
        Properties:
          QueueName: home-insurance-events-queue

    The next resource definitions create the SNS subscriptions and their respective filter policies. Note that, in addition to setting the FilterPolicy property, you need to set the FilterPolicyScope property to MessageBody in order to enable the new payload-based message filtering option for each subscription. The default value for the FilterPolicyScope property is MessageAttributes.

    AutoInsuranceEventsSubscription:
        Type: AWS::SNS::Subscription
        Properties:
          Protocol: sqs
          Endpoint: !GetAtt AutoInsuranceEventsQueue.Arn
          TopicArn: !Ref InsuranceEventsTopic
          FilterPolicyScope: MessageBody
          FilterPolicy:
            '{"Records":{"s3":{"object":{"key":[{"prefix":"auto-"}]}}
            ,"eventName":[{"prefix":"ObjectCreated:"}]}}'
      
    HomeInsuranceEventsSubscription:
        Type: AWS::SNS::Subscription
        Properties:
          Protocol: sqs
          Endpoint: !GetAtt HomeInsuranceEventsQueue.Arn
          TopicArn: !Ref InsuranceEventsTopic
          FilterPolicyScope: MessageBody
          FilterPolicy:
            '{"Records":{"s3":{"object":{"key":[{"prefix":"home-"}]}}
            ,"eventName":[{"prefix":"ObjectCreated:"}]}}'

    Once you download the full SAM template from GitHub to your local development machine, run the following command in your terminal to build the deployment artifacts.

    sam build –t SNS-Payload-Based-Filtering-SAM.template

    Once SAM has finished building the deployment artifacts, run the following command to deploy the AWS resources and the SNS filter policies. The command guides you through the process of setting deployment preferences, which you can answer based on your requirements. For more information, refer to the SAM Developer Guide.

    sam deploy --guided

    Once SAM has finished deploying the resources, you can start testing the solution in the AWS Management Console.

    Testing the filter policies

    Go the AWS CloudFormation console, choose the stack created by the SAM template, then choose the Outputs tab. Note the name of the S3 bucket created.

    S3 bucket name

    S3 bucket name

    Now switch to the S3 console, and choose the bucket with the corresponding name. Once on the bucket details page, upload a test file whose name starts with the auto- prefix. For example, you can name your test file auto-insurance-7156.xml. The upload triggers an S3 event, typed as ObjectCreated, which is then routed through the SNS topic to the SQS queue that stores auto insurance leads.

    Insurance bucket contents

    Insurance bucket contents

    Now switch to the SQS console, and choose to receive messages for the SQS queue storing an auto insurance lead. Note that the SQS queue for home insurance leads is empty.

    SQS home insurance queue empty

    SQS home insurance queue empty

    If you want to check the filter policy configured, you may switch to the SNS console, choose the SNS topic created by the SAM template, and choose the SNS subscription for auto insurance leads. Once on the subscription details page, you can view the filter policy, in JSON format, alongside the filter policy scope set to “Message body”.

    SNS filter policy

    SNS filter policy

    You may repeat the testing steps above, now with another file whose name starts with the home- prefix, and see how the S3 event is routed through the SNS topic to the SQS queue that stores home insurance leads.

    Monitoring the filtering activity

    CloudWatch provides visibility into your SNS message filtering activity, with dedicated metrics, which also enables you to create alarms. You can use the NumberOfNotifcationsFilteredOut-MessageBody metric to monitor the number of messages filtered out due to payload-based filtering, as opposed to attribute-based filtering. For more information, see Monitoring Amazon SNS topics using CloudWatch.

    Moreover, you can use the NumberOfNotificationsFilteredOut-InvalidMessageBody metric to monitor the number of messages filtered out due to having malformed JSON payloads. You can have these messages with malformed JSON payloads moved to a dead-letter queue (DLQ) for troubleshooting purposes. For more information, see Designing Durable Serverless Applications with DLQ for Amazon SNS.

    Cleaning up

    To delete all the AWS resources that you created as part of this use case, run the following command from the project root directory.

    sam delete

    Conclusion

    In this blog post, we introduce the use of payload-based message filtering for SNS, which provides event routing for JSON-formatted messages. This enables you to write filter policies based on the contents of the messages published to SNS. This also removes the message parsing overhead from your subscriber systems, as well as any custom logic from your publisher systems to move message properties from the payload to the set of attributes. Lastly, payload-based filtering can facilitate your event-driven architectures (EDA) by enabling you to filter events published to SNS from 60+ other AWS event sources.

    For more information, see Amazon SNS Message Filtering, Amazon SNS Event Sources, and Amazon SNS Pricing. For more serverless learning resources, visit Serverless Land.

    Introducing the AWS Lambda Telemetry API

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/introducing-the-aws-lambda-telemetry-api/

    This blog post is written by Anton Aleksandrov, Principal Solution Architect and Shridhar Pandey, Senior Product Manager

    Today AWS is announcing the AWS Lambda Telemetry API. This provides an easier way to receive enhanced function telemetry directly from the Lambda service and send it to custom destinations. Developers and operators can now more easily monitor and observe their Lambda functions using Lambda extensions from their preferred observability tool providers.

    Extensions can use the Lambda Logs API to collect logs generated by the Lambda service and code running in their Lambda function. While the Logs API provides extensions with access to logs, it does not provide a way to collect additional telemetry, such as traces and metrics, which the Lambda service generates during initialization and invocation of your Lambda function.

    Previously, observability tools retrieved traces from AWS X-Ray using the AWS X-Ray API or built their own custom tracing libraries to generate traces during Lambda function invocation. Tools required customers to modify AWS Identity and Access Management (IAM) policies to grant access to the traces from X-Ray. This caused additional complexity for tools to collect traces and metrics from multiple sources and introduced latency in seeing Lambda function traces in observability tool dashboards.

    The Lambda Telemetry API is a new API that enhances the existing Lambda Logs API functionality. With the new Telemetry API, observability tools can receive function and extension logs, and also events, traces, and metrics directly from within the Lambda service. You do not need to install additional tracing libraries. This reduces latency and simplifies access permissions, as the extension does not require additional access to X-Ray.

    Today you can use Telemetry API-enabled extensions to send telemetry data to Coralogix, Datadog, Dynatrace, Lumigo, New Relic, Sedai, Site24x7, Serverless.com, Sumo Logic, Sysdig, Thundra, or your own custom destinations.

    Overview

    To receive logs, extensions subscribe using the new Lambda Telemetry API.

    Lambda Telemetry API

    Lambda Telemetry API

    The Lambda service then streams the telemetry events directly to the extension. The events include platform events, trace spans, function and extension logs, and additional Lambda platform metrics. The extension can then process, filter, and route them to any preferred destination.

    You can add an extension from the tooling provider of your choice to your Lambda function. You can deploy extensions, including ones that use the Telemetry API, as Lambda layers, with the AWS Management Console and AWS Command Line Interface (AWS CLI). You can also use infrastructure as code tools such as AWS CloudFormation, the AWS Serverless Application Model (AWS SAM), Serverless Framework, and Terraform.

    Lambda Extensions from the AWS Partner Network (APN) available at launch

    Today, you can use Lambda extensions that use Telemetry API from the following Lambda partners:

    • The Coralogix AWS Lambda Telemetry Exporter extension now offers improved monitoring and alerting for Lambda functions by further streamlining collection and correlation of logs, metrics, and traces.
    • The Datadog extension further simplifies how you visualize the impact of cold starts, and monitor and alert on latency, duration, and payload size of your Lambda functions by collecting logs, traces, and real-time metrics from your function in a simple and cost-effective way.
    • Dynatrace now provides a simplified observability configuration for AWS Lambda through a seamless integration. The new solution delivers low-latency telemetry, enables monitoring at scale, and helps reduce monitoring costs for your serverless workloads.
    • The Lumigo lambda-log-shipper extension simplifies aggregating and forwarding Lambda logs to third-party tools. It now also makes it easy for you to detect Lambda function timeouts.
    • The New Relic extension now provides a unified observability view for your Lambda functions with insights that help you better understand and optimize the performance of your functions.
    • Sedai now uses the Telemetry API to help you improve the performance and availability of your Lambda functions by gathering insights about your function and providing recommendations for manual and autonomous remediation in a cost-effective manner.
    • The Site24x7 extension now offers new metrics, which enable you to get deeper insights into the different phases of the Lambda function lifecycle, such as initialization and invocation.
    • Serverless.com now uses the Telemetry API to provide real-time performance details for your Lambda function through the Dev Mode feature of their new Serverless Console V.2 offering, which simplifies debugging in the AWS Cloud.
    • Sumo Logic now makes it easier, faster, and more cost-effective for you to get your mission-critical Lambda function telemetry sent directly to Sumo Logic so you could quickly analyze and remediate errors and exceptions.
    • The Sysdig Monitor extension generates and collects real-time metrics directly from the Lambda platform. The simplified instrumentation offers lower latency, reduced MTTR (mean time to resolution) for critical issues, and cost benefits while monitoring your serverless applications.
    • The Thundra extension enables you to export logs, metrics, and events for Lambda execution environment lifecycle events emitted by the Telemetry API to a destination of your choice such as an S3 bucket, a database, or a monitoring backend.

    Seeing example Telemetry API extensions in action

    This demo shows an example of using a telemetry extension to receive telemetry, batch, and send it to a desired destination.

    To set up the example, visit the GitHub repo for the extension implemented in the language of your choice and follow the instructions in the README.md file.

    To configure the batching behavior, which controls when the extension sends the data, set the Lambda environment variable DISPATCH_MIN_BATCH_SIZE. When the extension receives the batch threshold, it POSTs the telemetry events batch to the destination specified in the DISPATCH_POST_URI environment variable.

    You can configure an example DISPATCH_POST_URL for the extension to deliver the telemetry data using https://webhook.site/.

    Lambda environment variables

    Lambda environment variables

    Telemetry events for one invoke may be received and processed during the next invocation. Events for the last invoke may be processed during the SHUTDOWN event.

    Test and invoke the function from the Lambda console, or AWS CLI. You can see that the webhook receives the telemetry data.

    Webhook receiving telemetry data

    Webhook receiving telemetry data

    You can also view the function and extension logs in CloudWatch Logs. The example extension includes verbose logging to understand the extension lifecycle.

    CloudWatch Logs showing extension verbose logging

    Sample Telemetry API events

    When the extension receives telemetry data, each event contains a JSON dictionary with additional information, such as related metrics or trace spans. The following example shows a function initialization event. You can see that the function initializes with on-demand concurrency. The runtime version is Node.js 14, the initialization is successful, and the initialization duration is 123 milliseconds.

    {
      "time": "2022-08-02T12:01:23.521Z",
      "type": "platform.initStart",
      "record": {
        "initializationType": "on-demand",
        "phase":"init",
        "runtimeVersion": "nodejs-14.v3",
        "runtimeVersionArn": "arn"
      }
    }
    
    {
      "time": "2022-08-02T12:01:23.521Z",
      "type": "platform.initRuntimeDone",
      "record": {
        "initializationType": "on-demand",
        "status": "success"
      }
    }
    
    {
      "time": "2022-08-02T12:01:23.521Z",
      "type": "platform.initReport",
      "record": {
        "initializationType": "on-demand",
        "phase":"init",
        "metrics": {
          "durationMs": 123.0,
        }
      }
    }
    

    Function invocation events include the associated requestId and tracing information connecting this invocation with the X-Ray tracing context, and platform spans showing response latency and response duration as well as invocation metrics such as duration in milliseconds.

    {
        "time": "2022-08-02T12:01:23.521Z",
        "type": "platform.start",
        "record": {
          "requestId": "e6b761a9-c52d-415d-b040-7ba94b9452f3",
          "version": "$LATEST",
          "tracing": {
            "spanId": "54565fb41ac79632",
            "type": "X-Amzn-Trace-Id",
            "value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
          }
        }
      }
      
      {
        "time": "2022-08-02T12:01:23.521Z",
        "type": "platform.runtimeDone",
        "record": {
          "requestId": "e6b761a9-c52d-415d-b040-7ba94b9452f3",
          "status": "success",
          "tracing": {
            "spanId": "54565fb41ac79632",
            "type": "X-Amzn-Trace-Id",
            "value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
          },
          "spans": [
            {
              "name": "responseLatency", 
              "start": "2022-08-02T12:01:23.521Z",
              "durationMs": 23.02
            },
            {
              "name": "responseDuration", 
              "start": "2022-08-02T12:01:23.521Z",
              "durationMs": 20
            }
          ],
          "metrics": {
            "durationMs": 200.0,
            "producedBytes": 15
          }
        }
      }
      
      {
        "time": "2022-08-02T12:01:23.521Z",
        "type": "platform.report",
        "record": {
          "requestId": "e6b761a9-c52d-415d-b040-7ba94b9452f3",
          "metrics": {
            "durationMs": 220.0,
            "billedDurationMs": 300,
            "memorySizeMB": 128,
            "maxMemoryUsedMB": 90,
            "initDurationMs": 200.0
          },
          "tracing": {
            "spanId": "54565fb41ac79632",
            "type": "X-Amzn-Trace-Id",
            "value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
          }
        }
      }
    

    Building a Telemetry API extension

    Lambda extensions run as independent processes in the execution environment and continue to run after the function invocation is fully processed. Because extensions run as separate processes, you can write them in a language different from the function code. We recommend implementing extensions using a compiled language as a self-contained binary. This makes the extension compatible with all the supported runtimes.

    Extensions that use the Telemetry API have the following lifecycle.

    Telemetry API lifecycle

    Telemetry API lifecycle

    1. The extension registers itself using the Lambda Extension API and subscribes to receive INVOKE and SHUTDOWN events. With the Telemetry API, the registration response body contains additional information, such as function name, function version, and account ID.
    2. The extensions start a telemetry listener. This is a local HTTP or TCP endpoint. We recommend using HTTP rather than TCP.
    3. The extensions use the Telemetry API to subscribe to desired telemetry event streams.
    4. The Lambda service POSTs telemetry stream data to your telemetry listener. We recommend batching the telemetry data as it arrives to the listener. You can perform any custom processing on this data and send it on to an S3 bucket, other custom destination, or an external observability service.

    See the Telemetry API documentation and sample extensions for additional details.

    The Lambda Telemetry API supersedes the Lambda Logs API. While the Logs API remains fully functional, AWS recommends using the Telemetry API. New functionality is only available with the Extensions API. Extensions can only subscribe to either the Logs or Telemetry API. After subscribing to one of them, any attempt to subscribe to the other returns an error.

    Mapping Telemetry API schema to OpenTelemetry spans

    The Lambda Telemetry API schema is semantically compatible with OpenTelemetry (OTEL). You can use events received from the Telemetry API to build and report OTEL spans. Three Telemetry API lifecycle events represent a single function invocation: start, runtimeDone, and runtimeReport. You should represent this as a single OTEL span. You can add additional details to your spans using information available in runtimeDone events under the event.spans property.

    Mapping of Telemetry API events to OTEL spans is described in the Telemetry API documentation.

    Metrics and pricing

    The Telemetry API introduces new per-invoke metrics to help you understand the impact of extensions on your function’s performance. The metrics are available within the report.runtimeDone event.

    • platform.runtime measures the time taken by the Lambda Runtime to run your function handler code.
    • producedBytes measures the number of bytes returned during the invoke phase.

    There are also two new trace spans available within the report.runtimeDone event:

    • responseLatencyMs measures the time taken by the Runtime to send a response.
    • responseDurationMs measures the time taken by the Runtime to finish sending the response from when it starts streaming it.

    Extensions using Telemetry API, like other extensions, share the same billing model as Lambda functions. When using Lambda functions with extensions, you pay for requests served, and the combined compute time used to run your code and all extensions, in 1-ms increments. To learn more about the billing for extensions, visit the Lambda pricing page.

    Useful links

    Conclusion

    The Lambda Telemetry API allows you to receive enhanced telemetry data more easily using your preferred monitoring and observability tools. The Telemetry API enhances the functionality of the Logs API to receive logs, metrics, and traces directly from the Lambda service. Developers and operators can send telemetry to destinations without custom libraries, with reduced latency, and simplified permissions.

    To see how the Telemetry API works, try the demos in the GitHub repository.

    Build your own extensions using the Telemetry API today, or use extensions provided by the Lambda observability partners.

    For more serverless learning resources, visit Serverless Land.

    Introducing message data protection for Amazon SNS

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/introducing-message-data-protection-for-amazon-sns/

    This post is written by Otavio Ferreira, Senior Software Development Manager, Marc Pinaud, Senior Product Manager, Usman Nisar, Senior Software Engineer, Hardik Vasa, Senior Solutions Architect, and Mithun Mallick, Senior Specialist Solution Architect.

    Today, we are announcing the public preview release of new data protection capabilities for Amazon Simple Notification Service (SNS), message data protection. This is a new way to discover and protect sensitive data in motion at scale, without writing custom code.

    SNS is a fully managed serverless messaging service. It provides topics for push-based, many-to-many pub/sub messaging for decoupling distributed systems, microservices, and event-driven serverless applications. As applications grow, so does the amount of data transmitted and the number of systems sending and receiving data. When moving data between different applications, guardrails can help you comply with data privacy regulations that require you to safeguard sensitive personally identifiable information (PII) or protected health information (PHI).

    With message data protection for SNS, you can scan messages in real time for PII/PHI data and receive audit reports containing scan results. You can also prevent applications from receiving sensitive data by blocking inbound messages to an SNS topic or outbound messages to an SNS subscription. Message data protection for SNS supports a repository of over 25 unique PII/PHI data identifiers. These include people’s names, addresses, social security numbers, credit card numbers, and prescription drug codes.

    These capabilities can help you adhere to a variety of compliance regulations, including HIPAA, FedRAMP, GDPR, and PCI. For more information, including the complete list of supported data identifiers, see message data protection in the SNS Developer Guide.

    Overview

    SNS topics enable you to integrate distributed applications more easily. As applications become more complex, it can become challenging for topic owners to manage the data flowing through their topics. Developers that publish messages to a topic may inadvertently send sensitive data, increasing regulatory risk. Message data protection enables SNS topic owners to protect sensitive application data with built-in, no-code, scalable capabilities.

    To discover and protect data flowing through SNS topics with message data protection, topic owners associate data protection policies to their topics. Within these policies, you can write statements that define which types of sensitive data you want to discover and protect. As part of this, you can define whether you want to act on data flowing inbound to a topic or outbound to a subscription, which AWS accounts or specific AWS Identity and Access Management (AWS IAM) principals the policy is applicable to, and the actions you want to take on the data.

    Message data protection provides two actions to help you protect your data. Auditing, to report on the amount of PII/PHI found, and blocking, to prevent the publishing or delivery of payloads that contain PII/PHI data. Once the data protection policy is set, message data protection uses pattern matching and machine learning models to scan your messages in real time for PII/PHI data identifiers and enforce the data protection policy.

    For auditing, you can choose to send audit reports to Amazon Simple Storage Service (S3) for archival, Amazon Kinesis Data Firehose for analytics, or Amazon CloudWatch for logging and alarming. Message data protection does not interfere with the topic owner’s ability to use message data encryption at rest, nor with the subscriber’s ability to filter out unwanted messages using message filtering.

    Applying message data protection in a use case

    Consider an application that processes a variety of transactions for a set of health clinics, an organization that operates in a regulated environment. Compliance frameworks require that the organization take measures to protect both sensitive health records and financial information.

    Reference architecture

    The application is based on an event-driven serverless architecture. It has a data protection policy attached to the topic to audit for sensitive data and prevent downstream systems from processing certain data types.

    The application publishes an event to an SNS topic every time a patient schedules a visit or sees a doctor at a clinic. The SNS topic fans out the event to two subscribed systems, billing and scheduling. Each system stores events in an Amazon SQS queue, which is processed using an AWS Lambda function.

    Setting a data protection policy to an SNS topic

    You can apply a data protection policy to an SNS topic using the AWS Management Console, the AWS CLI, or the AWS SDKs. You can also use AWS CloudFormation to automate the provisioning of the data protection policy.

    This example uses CloudFormation to provision the infrastructure. You have two options for deploying the resources:

    • Deploy the resources by using the message data protection deploy script within the aws-sns-samples repository in GitHub.
    • Alternatively, use the following four CloudFormation templates in order. Allow time for each stack to complete before deploying the next stack, to create the following resources:

    1. Prerequisites template

    • Two IAM roles with a managed policy that allows access to receive messages from the SNS topic, one for the billing and another for scheduling system, respectively.

    2. Topic owner template

    • SNS topic that delivers events to two distinct systems.
    • A data protection policy that defines both auditing and blocking actions for specific types of PII and PHI.
    • S3 bucket to archive audit findings.
    • CloudWatch log group to monitor audit findings.
    • Kinesis Data Firehose to deliver audit findings to other destinations.

    3. Scheduling subscriber template

    • SQS queue for the Scheduling system.
    • Lambda function for the Scheduling system.

    4. Billing subscriber template

    • SQS queue for the Billing system.
    • Lambda function for the Billing system.

    CloudFormation creates the following data protection policy as part of the topic owner template:

      ClinicSNSTopic:
        Type: 'AWS::SNS::Topic'
        Properties:
          TopicName: SampleClinic
          DataProtectionPolicy:
            Name: data-protection-example-policy
            Description: Policy Description
            Version: 2021-06-01
            Statement:
              - Sid: audit
                DataDirection: Inbound
                Principal:
                 - '*'
                DataIdentifier:
                  - 'arn:aws:dataprotection::aws:data-identifier/Address'
                  - 'arn:aws:dataprotection::aws:data-identifier/AwsSecretKey'
                  - 'arn:aws:dataprotection::aws:data-identifier/DriversLicense-US'
                  - 'arn:aws:dataprotection::aws:data-identifier/EmailAddress'
                  - 'arn:aws:dataprotection::aws:data-identifier/IpAddress'
                  - 'arn:aws:dataprotection::aws:data-identifier/NationalDrugCode-US'
                  - 'arn:aws:dataprotection::aws:data-identifier/PassportNumber-US'
                  - 'arn:aws:dataprotection::aws:data-identifier/Ssn-US'
                Operation:
                  Audit:
                    SampleRate: 99
                    FindingsDestination:
                      CloudWatchLogs:
                        LogGroup: !Ref AuditCWLLogs
                      Firehose:
                        DeliveryStream: !Ref AuditFirehose
                    NoFindingsDestination:
                      S3:
                        Bucket: !Ref AuditS3Bucket
              - Sid: deny-inbound
                DataDirection: Inbound
                Principal:
                  - '*'
                DataIdentifier:
                  - 'arn:aws:dataprotection::aws:data-identifier/PassportNumber-US'
                  - 'arn:aws:dataprotection::aws:data-identifier/Ssn-US'
                Operation:
                  Deny: {}
              - Sid: deny-outbound-billing
                DataDirection: Outbound
                Principal:
                  - !ImportValue "BillingRoleExportDataProtectionDemo"
                DataIdentifier:
                  - 'arn:aws:dataprotection::aws:data-identifier/NationalDrugCode-US'
                Operation:
                  Deny: {}
              - Sid: deny-outbound-scheduling
                DataDirection: Outbound
                Principal:
                  - !ImportValue "SchedulingRoleExportDataProtectionDemo"
                DataIdentifier:
                  - 'arn:aws:dataprotection::aws:data-identifier/Address'
                  - 'arn:aws:dataprotection::aws:data-identifier/CreditCardNumber'
                Operation:
                  Deny: {}

    This data protection policy defines:

    • Metadata about the data protection policy, for example name, description, version, and statement IDs (sid).
    • The first statement (sid: audit) scans inbound messages from all principals for addresses, social security numbers, driver’s license, email addresses, IP addresses, national drug codes, passport numbers, and AWS secret keys.
      • The sampling rate is set to 99% so almost all messages are scanned for the defined PII/PHI.
      • Audit results with findings are delivered to CloudWatch Logs and Kinesis Data Firehose for analytics. Audit results without findings are archived to S3.
    • The second statement (sid: deny-inbound) blocks inbound messages to the topic coming from any principal, if the payload includes either a social security number or passport number.
    • The third statement (sid: deny-outbound-billing) blocks the delivery of messages to subscriptions created by the BillingRole, if the messages include any national drug codes.
    • The fourth statement (sid: deny-outbound-scheduling) blocks the delivery of messages to subscriptions created by the SchedulingRole, if the messages include any credit card numbers or addresses.

    Testing the capabilities

    Test the message data protection capabilities using the following steps:

    1. Publish a message without PII/PHI data to the Clinic Topic. In the CloudWatch console, navigate to the log streams of the respective Lambda functions to confirm that the message is delivered to both subscribers. Both messages are delivered because the payload contains no sensitive data for the data protection policy to deny. The log message looks as follows:
      "This is a demo! received from queue arn:aws:sqs:us-east-1:111222333444:Scheduling-SchedulingQueue"
    2. Publish a message with a social security number (try ‘SSN: 123-12-1234’) to the Clinic Topic. The request is denied, and an audit log is delivered to your CloudWatch Logs log group and Firehose delivery stream.
    3. Navigate to the CloudWatch log console and confirm that the audit log is visible in the /aws/vendedlogs/clinicaudit CloudWatch log group. The following example shows that the data protection policy (sid: deny-inbound) denied the inbound message as the payload contains a US social security number (SSN) between the 5th and the 15th character.
      {
          "messageId": "77ec5f0c-5129-5429-b01d-0457b965c0ac",
          "auditTimestamp": "2022-07-28T01:27:40Z",
          "callerPrincipal": "arn:aws:iam::111222333444:role/Admin",
          "resourceArn": "arn:aws:sns:us-east-1:111222333444:SampleClinic",
          "dataIdentifiers": [
              {
                  "name": "Ssn-US",
                  "count": 1,
                  "detections": [
                      {
                          "start": 5,
                          "end": 15
                      }
                  ]
              }
          ]
      }
      
    4. You can use the CloudWatch metrics, MessageWithFindings and MessageWithNoFindings, to track how frequently PII/PHI data is published to an SNS topic. Here’s an example of what the CloudWatch metric graph looks like as the amount of sensitive data published to a topic varies over time:
      CloudWatch metric graph
    5. Publish a message with an address (try ‘410 Terry Ave N, Seattle 98109, WA’). The request is only delivered to the Billing subscription. The data protection policy (sid: deny-outbound-scheduling) denies the outbound message to the Scheduling subscription as the payload contains an address.
    6. Confirm that the message is only delivered to the Billing Lambda function by navigating to the CloudWatch console and inspecting the logs of the two respective Lambda functions. The CloudWatch log of the Billing Lambda function contains the sensitive message that was delivered to it as it was an authorized subscriber. Here’s an example of what the log contains:410 Terry Ave N, Seattle 98109, WA received from queue arn:aws:sqs:us-east-1:111222333444:Billing-BillingQueue
    7. Publish a message with a drug code (try ‘NDC: 0777-3105-02’). The request is only delivered to the Scheduling subscription. The data protection policy (sid: deny-outbound-billing) denies the outbound message to the Billing subscription as the payload contains a drug code.
    8. Confirm that the message is only delivered to the Scheduling Lambda function by navigating to the CloudWatch console and inspecting the logs of the two respective Lambda functions. The CloudWatch log of the Scheduling Lambda function contains the sensitive message that was delivered to it as it was an authorized subscriber. Here’s an example of what the log contains:
      NDC: 0777-3105-02 received from queue arn:aws:sqs:us-east-1:111222333444:Scheduling-SchedulingQueue

    Cleaning up

    After testing, avoid incurring usage charges by deleting the resources that you created. Navigate to the CloudFormation console and delete the four CloudFormation stacks that you created during the walkthrough. Remember, you must delete all the objects from the S3 bucket before deleting the stack.

    Conclusion

    This post shows how message data protection enables a topic owner to discover and protect sensitive data that is exchanged through SNS topics. The example shows how to create a data protection policy that generates audit reports for sensitive data and blocks messages from delivery to specific subscribers if the payload contains sensitive data.

    Get started with SNS and message data protection by using the AWS Management Console, AWS Command Line Interface (CLI), AWS SDKs, or CloudFormation.

    For more details, see message data protection in the SNS Developer Guide. For information on pricing, see SNS pricing.

    For more serverless learning resources, visit Serverless Land.

    Building AWS Lambda governance and guardrails

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/building-aws-lambda-governance-and-guardrails/

    When building serverless applications using AWS Lambda, there are a number of considerations regarding security, governance, and compliance. This post highlights how Lambda, as a serverless service, simplifies cloud security and compliance so you can concentrate on your business logic. It covers controls that you can implement for your Lambda workloads to ensure that your applications conform to your organizational requirements.

    The Shared Responsibility Model

    The AWS Shared Responsibility Model distinguishes between what AWS is responsible for and what customers are responsible for with cloud workloads. AWS is responsible for “Security of the Cloud” where AWS protects the infrastructure that runs all the services offered in the AWS Cloud. Customers are responsible for “Security in the Cloud”, managing and securing their workloads. When building traditional applications, you take on responsibility for many infrastructure services, including operating systems and network configuration.

    Traditional application shared responsibility

    Traditional application shared responsibility

    One major benefit when building serverless applications is shifting more responsibility to AWS so you can concentrate on your business applications. AWS handles managing and patching the underlying servers, operating systems, and networking as part of running the services.

    Serverless application shared responsibility

    Serverless application shared responsibility

    For Lambda, AWS manages the application platform where your code runs, which includes patching and updating the managed language runtimes. This reduces the attack surface while making cloud security simpler. You are responsible for the security of your code and AWS Identity and Access Management (IAM) to the Lambda service and within your function.

    Lambda is SOCHIPAAPCI, and ISO-compliant. For more information, see Compliance validation for AWS Lambda and the latest Lambda certification and compliance readiness services in scope.

    Lambda isolation

    Lambda functions run in separate isolated AWS accounts that are dedicated to the Lambda service. Lambda invokes your code in a secure and isolated runtime environment within the Lambda service account. A runtime environment is a collection of resources running in a dedicated hardware-virtualized Micro Virtual Machines (MVM) on a Lambda worker node.

    Lambda workers are bare metalEC2 Nitro instances, which are managed and patched by the Lambda service team. They have a maximum lease lifetime of 14 hours to keep the underlying infrastructure secure and fresh. MVMs are created by Firecracker, an open source virtual machine monitor (VMM) that uses Linux’s Kernel-based Virtual Machine (KVM) to create and manage MVMs securely at scale.

    MVMs maintain a strong separation between runtime environments at the virtual machine hardware level, which increases security. Runtime environments are never reused across functions, function versions, or AWS accounts.

    Isolation model for AWS Lambda workers

    Isolation model for AWS Lambda workers

    Network security

    Lambda functions always run inside secure Amazon Virtual Private Cloud (Amazon VPCs) owned by the Lambda service. This gives the Lambda function access to AWS services and the public internet. There is no direct network inbound access to Lambda workers, runtime environments, or Lambda functions. All inbound access to a Lambda function only comes via the Lambda Invoke API, which sends the event object to the function handler.

    You can configure a Lambda function to connect to private subnets in a VPC in your account if necessary, which you can control with IAM condition keys . The Lambda function still runs inside the Lambda service VPC but sends all network traffic through your VPC. Function outbound traffic comes from your own network address space.

    AWS Lambda service VPC with VPC-to-VPC NAT to customer VPC

    AWS Lambda service VPC with VPC-to-VPC NAT to customer VPC

    To give your VPC-connected function access to the internet, route outbound traffic to a NAT gateway in a public subnet. Connecting a function to a public subnet doesn’t give it internet access or a public IP address, as the function is still running in the Lambda service VPC and then routing network traffic into your VPC.

    All internal AWS traffic uses the AWS Global Backbone rather than traversing the internet. You do not need to connect your functions to a VPC to avoid connectivity to AWS services over the internet. VPC connected functions allow you to control and audit outbound network access.

    You can use security groups to control outbound traffic for VPC-connected functions and network ACLs to block access to CIDR IP ranges or ports. VPC endpoints allow you to enable private communications with supported AWS services without internet access.

    You can use VPC Flow Logs to audit traffic going to and from network interfaces in your VPC.

    Runtime environment re-use

    Each runtime environment processes a single request at a time. After Lambda finishes processing the request, the runtime environment is ready to process an additional request for the same function version. For more information on how Lambda manages runtime environments, see Understanding AWS Lambda scaling and throughput.

    Data can persist in the local temporary filesystem path, in globally scoped variables, and in environment variables across subsequent invocations of the same function version. Ensure that you only handle sensitive information within individual invocations of the function by processing it in the function handler, or using local variables. Do not re-use files in the local temporary filesystem to process unencrypted sensitive data. Do not put sensitive or confidential information into Lambda environment variables, tags, or other freeform fields such as Name fields.

    For more Lambda security information, see the Lambda security whitepaper.

    Multiple accounts

    AWS recommends using multiple accounts to isolate your resources because they provide natural boundaries for security, access, and billing. Use AWS Organizations to manage and govern individual member accounts centrally. You can use AWS Control Tower to automate many of the account build steps and apply managed guardrails to govern your environment. These include preventative guardrails to limit actions and detective guardrails to detect and alert on non-compliance resources for remediation.

    Lambda access controls

    Lambda permissions define what a Lambda function can do, and who or what can invoke the function. Consider the following areas when applying access controls to your Lambda functions to ensure least privilege:

    Execution role

    Lambda functions have permission to access other AWS resources using execution roles. This is an AWS principal that the Lambda service assumes which grants permissions using identity policy statements assigned to the role. The Lambda service uses this role to fetch and cache temporary security credentials, which are then available as environment variables during a function’s invocation. It may re-use them across different runtime environments that use the same execution role.

    Ensure that each function has its own unique role with the minimum set of permissions..

    Identity/user policies

    IAM identity policies are attached to IAM users, groups, or roles. These policies allow users or callers to perform operations on Lambda functions. You can restrict who can create functions, or control what functions particular users can manage.

    Resource policies

    Resource policies define what identities have fine-grained inbound access to managed services. For example, you can restrict which Lambda function versions can add events to a specific Amazon EventBridge event bus. You can use resource-based policies on Lambda resources to control what AWS IAM identities and event sources can invoke a specific version or alias of your function. You also use a resource-based policy to allow an AWS service to invoke your function on your behalf. To see which services support resource-based policies, see “AWS services that work with IAM”.

    Attribute-based access control (ABAC)

    With attribute-based access control (ABAC), you can use tags to control access to your Lambda functions. With ABAC, you can scale an access control strategy by setting granular permissions with tags without requiring permissions updates for every new user or resource as your organization scales. You can also use tag policies with AWS Organizations to standardize tags across resources.

    Permissions boundaries

    Permissions boundaries are a way to delegate permission management safely. The boundary places a limit on the maximum permissions that a policy can grant. For example, you can use boundary permissions to limit the scope of the execution role to allow only read access to databases. A builder with permission to manage a function or with write access to the applications code repository cannot escalate the permissions beyond the boundary to allow write access.

    Service control policies

    When using AWS Organizations, you can use Service control policies (SCPs) to manage permissions in your organization. These provide guardrails for what actions IAM users and roles within the organization root or OUs can do. For more information, see the AWS Organizations documentation, which includes example service control policies.

    Code signing

    As you are responsible for the code that runs in your Lambda functions, you can ensure that only trusted code runs by using code signing with the AWS Signer service. AWS Signer digitally signs your code packages and Lambda validates the code package before accepting the deployment, which can be part of your automated software deployment process.

    Auditing Lambda configuration, permissions and access

    You should audit access and permissions regularly to ensure that your workloads are secure. Use the IAM console to view when an IAM role was last used.

    IAM last used

    IAM last used

    IAM access advisor

    Use IAM access advisor on the Access Advisor tab in the IAM console to review when was the last time an AWS service was used from a specific IAM user or role. You can use this to remove IAM policies and access from your IAM roles.

    IAM access advisor

    IAM access advisor

    AWS CloudTrail

    AWS CloudTrail helps you monitor, log, and retain account activity to provide a complete event history of actions across your AWS infrastructure. You can monitor Lambda API actions to ensure that only appropriate actions are made against your Lambda functions. These include CreateFunction, DeleteFunction, CreateEventSourceMapping, AddPermission, UpdateEventSourceMapping,  UpdateFunctionConfiguration, and UpdateFunctionCode.

    AWS CloudTrail

    AWS CloudTrail

    IAM Access Analyzer

    You can validate policies using IAM Access Analyzer, which provides over 100 policy checks with security warnings for overly permissive policies. To learn more about policy checks provided by IAM Access Analyzer, see “IAM Access Analyzer policy validation”.

    You can also generate IAM policies based on access activity from CloudTrail logs, which contain the permissions that the role used in your specified date range.

    IAM Access Analyzer

    IAM Access Analyzer

    AWS Config

    AWS Config provides you with a record of the configuration history of your AWS resources. AWS Config monitors the resource configuration and includes rules to alert when they fall into a non-compliant state.

    For Lambda, you can track and alert on changes to your function configuration, along with the IAM execution role. This allows you to gather Lambda function lifecycle data for potential audit and compliance requirements. For more information, see the Lambda Operators Guide.

    AWS Config includes Lambda managed config rules such as lambda-concurrency-check, lambda-dlq-check, lambda-function-public-access-prohibited, lambda-function-settings-check, and lambda-inside-vpc. You can also write your own rules.

    There are a number of other AWS services to help with security compliance.

    1. AWS Audit Manager: Collect evidence to help you audit your use of cloud services.
    2. Amazon GuardDuty: Detect unexpected and potentially unauthorized activity in your AWS environment.
    3. Amazon Macie: Evaluates your content to identify business-critical or potentially confidential data.
    4. AWS Trusted Advisor: Identify opportunities to improve stability, save money, or help close security gaps.
    5. AWS Security Hub: Provides security checks and recommendations across your organization.

    Conclusion

    Lambda makes cloud security simpler by taking on more responsibility using the AWS Shared Responsibility Model. Lambda implements strict workload security at scale to isolate your code and prevent network intrusion to your functions. This post provides guidance on assessing and implementing best practices and tools for Lambda to improve your security, governance, and compliance controls. These include permissions, access controls, multiple accounts, and code security. Learn how to audit your function permissions, configuration, and access to ensure that your applications conform to your organizational requirements.

    For more serverless learning resources, visit Serverless Land.

    Securely retrieving secrets with AWS Lambda

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/securely-retrieving-secrets-with-aws-lambda/

    AWS Lambda functions often need to access secrets, such as certificates, API keys, or database passwords. Storing secrets outside the function code in an external secrets manager helps to avoid exposing secrets in application source code. Using a secrets manager also allows you to audit and control access, and can help with secret rotation. Do not store secrets in Lambda environment variables, as these are visible to anyone who has access to view function configuration.

    This post highlights some solutions to store secrets securely and retrieve them from within your Lambda functions.

    AWS Partner Network (APN) member Hashicorp provides Vault to secure secrets and application data. Vault allows you to control access to your secrets centrally, across applications, systems, and infrastructure. You can store secrets in Vault and access them from a Lambda function to access a database, for example. The Vault Agent for AWS helps you authenticate with Vault, retrieve the database credentials, and then perform the queries. You can also use the Vault AWS Lambda extension to manage connectivity to Vault.

    AWS Systems Manager Parameter Store enables you to store configuration data securely, including secrets, as parameter values. For information on Parameter Store pricing, see the documentation.

    AWS Secrets Manager allows you to replace hardcoded credentials in your code with an API call to Secrets Manager to retrieve the secret programmatically. You can generate, protect, rotate, manage, and retrieve secrets throughout their lifecycle. By default, Secrets Manager does not write or cache the secret to persistent storage. Secrets Manager supports cross-account access to secrets. For information on Secrets Manager pricing, see the documentation.

    Parameter Store integrates directly with Secrets Manager as a pass-through service for references to Secrets Manager secrets. Use this integration if you prefer using Parameter Store as a consistent solution for calling and referencing secrets across your applications. For more information, see “Referencing AWS Secrets Manager secrets from Parameter Store parameters.”

    For an example application to show Secrets Manager functionality, deploy the example detailed in “How to securely provide database credentials to Lambda functions by using AWS Secrets Manager”.

    When to retrieve secrets

    When Lambda first invokes your function, it creates a runtime environment. It runs the function’s initialization (init) code, which is the code outside the main handler. Lambda then runs the function handler code as the invocation. This receives the event payload and processes your business logic. Subsequent invocations can use the same runtime environment.

    You can retrieve secrets during each function invocation from within your handler code. This ensures that the secret value is always up to date but can lead to increased function duration and cost, as the function calls the secret manager during each invocation. There may also be additional retrieval costs from Secret Manager.

    Retrieving secret during each invocation

    Retrieving secret during each invocation

    You can reduce costs and improve performance by retrieving the secret during the function init process. During subsequent invocations using the same runtime environment, your handler code can use the same secret.

    Retrieving secret during function initialization.

    Retrieving secret during function initialization.

    The Serverless Land pattern example shows how to retrieve a secret during the init phase using Node.js and top-level await.

    If a secret may change between subsequent invocations, ensure that your handler can check for the secret validity and, if necessary, retrieve the secret again.

    Retrieve changed secret during subsequent invocation.

    Retrieve changed secret during subsequent invocation.

    You can also use Lambda extensions to retrieve secrets from Secrets Manager, cache them, and automatically refresh the cache based on a time value. The extension retrieves the secret from Secrets Manager before the init process and makes it available via a local HTTP endpoint. The function then retrieves the secret from the local HTTP endpoint, rather than directly from Secrets Manager, increasing performance. You can also share the extension with multiple functions, which can reduce function code. The extension handles refreshing the cache based on a configurable timeout value. This ensures that the function has the updated value, without handling the refresh in your function code, which increases reliability.

    Using Lambda extensions to cache and refresh secret.

    Using Lambda extensions to cache and refresh secret.

    You can deploy the solution using the steps in Cache secrets using AWS Lambda extensions.

    Lambda Powertools

    Lambda Powertools provides a suite of utilities for Lambda functions to simplify the adoption of serverless best practices. AWS Lambda Powertools for Python and AWS Lambda Powertools for Java both provide a parameters utility that integrates with Secrets Manager.

    from aws_lambda_powertools.utilities import parameters
    def handler(event, context):
        # Retrieve a single secret
        value = parameters.get_secret("my-secret")
    import software.amazon.lambda.powertools.parameters.SecretsProvider;
    import software.amazon.lambda.powertools.parameters.ParamManager;
    
    public class AppWithSecrets implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {
        // Get an instance of the Secrets Provider
        SecretsProvider secretsProvider = ParamManager.getSecretsProvider();
    
        // Retrieve a single secret
        String value = secretsProvider.get("/my/secret");

    Rotating secrets

    You should rotate secrets to prevent the misuse of your secrets. This helps you to replace long-term secrets with short-term ones, which reduces the risk of compromise.

    Secrets Manager has built-in functionality to rotate secrets on demand or according to a schedule. Secrets Manager has native integrations with Amazon RDS, Amazon DocumentDB, and Amazon Redshift, using a Lambda function to manage the rotation process for you. It deploys an AWS CloudFormation stack and populates the function with the Amazon Resource Name (ARN) of the secret. You specify the permissions to rotate the credentials, and how often you want to rotate the secret. You can view and edit Secrets Manager rotation settings in the Secrets Manager console.

    Secrets Manager rotation settings

    Secrets Manager rotation settings

    You can also create your own rotation Lambda function for other services.

    Auditing secrets access

    You should continually review how applications are using your secrets to ensure that the usage is as you expect. You should also log any changes to them so you can investigate any potential issues, and roll back changes if necessary.

    When using Hashicorp Vault, use Audit devices to log all requests and responses to Vault. Audit devices can append logs to a file, write to syslog, or write to a socket.

    Secrets Manager supports logging API calls using AWS CloudTrail. CloudTrail monitors and records all API calls for Secrets Manager as events. This includes calls from code calling the Secrets Manager APIs and access via the Secrets Manager console. CloudTrail data is considered sensitive, so you should use AWS KMS encryption to protect it.

    The CloudTrail event history shows the requests to secretsmanager.amazonaws.com.

    Viewing CloudTrail access to Secrets Manager

    Viewing CloudTrail access to Secrets Manager

    You can use Amazon EventBridge to respond to alerts based on specific operations recorded in CloudTrail. These include secret rotation or deleted secrets. You can also generate an alert if someone tries to use a version of a secret version while it is pending deletion. This may help identify and alert you when an outdated certificate is used.

    Securing secrets

    You must tightly control access to secrets because of their sensitive nature. Create AWS Identity and Access Management (IAM) policies and resource policies to enable minimal access to secrets. You can use role-based, as well as attribute-based, access control. This can prevent credentials from being accidentally used or compromised. For more information, see “Authentication and access control for AWS Secrets Manager”.

    Secrets Manager supports encryption at rest using AWS Key Management Service (AWS KMS) using keys that you manage. Secrets are encrypted in transit using TLS by default, which requires request signing.

    You can access secrets from inside an Amazon Virtual Private Cloud (Amazon VPC) without requiring internet access. Use AWS PrivateLink and configure a Secrets Manager specific VPC endpoint.

    Do not store plaintext secrets in Lambda environment variables. Ensure that you do not embed secrets directly in function code, commit these secrets to code repositories, or log the secret to CloudWatch.

    Conclusion

    Using a secrets manager to store secrets such as certificates, API keys or database passwords helps to avoid exposing secrets in application source code. This post highlights some AWS and third-party solutions, such as Hashicorp Vault, to store secrets securely and retrieve them from within your Lambda functions.

    Secrets Manager is the preferred AWS solution for storing and managing secrets. I explain when to retrieve secrets, including using Lambda extensions to cache secrets, which can reduce cost and improve performance.

    You can use the Lambda Powertools parameters utility, which integrates with Secrets Manager. Rotating secrets reduces the risk of compromise and you can audit secrets using CloudTrail and respond to alerts using EventBridge. I also cover security considerations for controlling access to your secrets.

    For more serverless learning resources, visit Serverless Land.

    Scaling AWS Lambda permissions with Attribute-Based Access Control (ABAC)

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/scaling-aws-lambda-permissions-with-attribute-based-access-control-abac/

    This blog post is written by Chris McPeek, Principal Solutions Architect.

    AWS Lambda now supports attribute-based access control (ABAC), allowing you to control access to Lambda functions within AWS Identity and Access Management (IAM) using tags. With ABAC, you can scale an access control strategy by setting granular permissions with tags without requiring permissions updates for every new user or resource as your organization scales.

    This blog post shows how to use tags for conditional access to Lambda resources. You can control access to Lambda resources using ABAC by using one or more tags within IAM policy conditions. This can help you scale permissions in rapidly growing environments. To learn more about ABAC, see What is ABAC for AWS, and AWS Services that work with IAM.

    Each tag in AWS is a label comprising a user-defined key and value. Customers often use tags with Lambda functions to define keys such as cost center, environment, project, and teams, along with values that map to these keys. This helps with discovery and cost allocation, especially in accounts that may have many Lambda functions. AWS best practices for tagging are included in Tagging AWS resources.

    You can now use these same tags, or create new ones, and use them to grant conditional IAM access to Lambda functions more easily. As projects start and finish, employees move to different teams, and applications grow, maintaining access to resources can become cumbersome. ABAC helps developers and security administrators work together to maintain least privilege access to their resources more effectively by using the same tags on IAM roles and Lambda functions. Security administrators can allow or deny access to Lambda API actions when the IAM role tags match the tags on a Lambda function, ensuring least privilege. As developers add additional Lambda functions to the project, they simply apply the same tag when they create a new Lambda function, which grants the same security credentials.

    ABAC in Lambda

    Using ABAC with Lambda is similar to developing ABAC policies when working with other services. To illustrate how to use ABAC with Lambda, consider a scenario where two new developers join existing projects called Project Falcon and Project Eagle. Project Falcon uses ABAC for authorization using the tag key project-name and value falcon. Project Eagle uses the tag key project-name and value eagle.

    Projects Falcon and Eagle tags

    Projects Falcon and Eagle tags

    The two new developers need access to the Lambda console. The security administrator creates the following policy to allow the developers to list the existing functions that are available using ListFunction. The GetAccountSettings permission allows them to retrieve Lambda-specific information about their account.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
        "Sid": "AllResourcesLambdaNoTags",
        "Effect": "Allow",
        "Action": [
            "lambda:ListFunctions",
            "lambda:GetAccountSettings"
        ],
        "Resource": "*"
        }
    ]
    }
    

    Condition key mappings

    The developers then need access to Lambda actions that are part of their projects. The Lambda actions are API calls such as InvokeFunction or PutFunctionConcurrency (see the following table). IAM condition keys are then used to refine the conditions under which an IAM policy statement applies.

    Lambda supports the existing global context key:

    • "aws:PrincipalTag/${TagKey}": Control what the IAM principal (the person making the request) is allowed to do based on the tags that are attached to their IAM user or role.

    As part of ABAC support, Lambda now supports three additional condition keys:

    • "aws:ResourceTag/${TagKey}": Control access based on the tags that are attached to Lambda functions.
    • "aws:RequestTag/${TagKey}": Require tags to be present in a request, such as when creating a new function.
    • "aws:TagKeys": Control whether specific tag keys can be used in a request.

    For more details on these condition context keys, see AWS global condition context keys.

    When using condition keys in IAM policies, each Lambda API action supports different tagging condition keys. The following table maps each condition key to its Lambda actions.

    Condition keys supported Description Lambda actions
    aws:ResourceTag/${TagKey} Set this tag value to allow or deny user actions on resources with specific tags.
    lambda:AddPermission
    lambda:CreateAlias
    lambda:CreateFunctionUrlConfig
    lambda:DeleteAlias
    lambda:DeleteFunction
    lambda:DeleteFunctionCodeSigningConfig
    lambda:DeleteFunctionConcurrency
    lambda:DeleteFunctionEventInvokeConfig
    lambda:DeleteFunctionUrlConfig
    lambda:DeleteProvisionedConcurrencyConfig
    lambda:DisableReplication
    lambda:EnableReplication
    lambda:GetAlias
    lambda:GetFunction
    lambda:GetFunctionCodeSigningConfig
    lambda:GetFunctionConcurrency
    lambda:GetFunctionConfiguration
    lambda:GetFunctionEventInvokeConfig
    lambda:GetFunctionUrlConfig
    lambda:GetPolicy
    lambda:GetProvisionedConcurrencyConfig
    lambda:InvokeFunction
    lambda:InvokeFunctionUrl
    lambda:ListAliases
    lambda:ListFunctionEventInvokeConfigs
    lambda:ListFunctionUrlConfigs
    lambda:ListProvisionedConcurrencyConfigs
    lambda:ListTags
    lambda:ListVersionsByFunction
    lambda:PublishVersion
    lambda:PutFunctionCodeSigningConfig
    lambda:PutFunctionConcurrency
    lambda:PutFunctionEventInvokeConfig
    lambda:PutProvisionedConcurrencyConfig
    lambda:RemovePermission
    lambda:UpdateAlias
    lambda:UpdateFunctionCode
    lambda:UpdateFunctionConfiguration
    lambda:UpdateFunctionEventInvokeConfig
    lambda:UpdateFunctionUrlConfig
    

    aws:ResourceTag/${TagKey}
    aws:RequestTag/${TagKey}

    aws:TagKeys
    Set this tag value to allow or deny user requests to create a Lambda function. lambda:CreateFunction
    aws:ResourceTag/${TagKey}
    aws:RequestTag/${TagKey}

    aws:TagKeys
    Set this tag value to allow or deny user requests to add or update tags. lambda:TagResource
    aws:ResourceTag/${TagKey}
    aws:TagKeys
    Set this tag value to allow or deny user requests to remove tags. lambda:UntagResource

    Security administrators create conditions that only permit the action if the tag matches between the role and the Lambda function.
    In this example, the policy grants access to all Lambda function API calls when a project-name tag exists and matches on both the developer’s IAM role and the Lambda function.

    {
    "Version": "2012-10-17",
    "Statement": [
        {
        "Sid": "AllActionsLambdaSameProject",
        "Effect": "Allow",
        "Action": [
            "lambda:InvokeFunction",
            "lambda:UpdateFunctionConfiguration",
            "lambda:CreateAlias",
            "lambda:DeleteAlias",
            "lambda:DeleteFunction",
            "lambda:DeleteFunctionConcurrency", 
            "lambda:GetAlias",
            "lambda:GetFunction",
            "lambda:GetFunctionConfiguration",
            "lambda:GetPolicy",
            "lambda:ListAliases", 
            "lambda:ListVersionsByFunction",
            "lambda:PublishVersion",
            "lambda:PutFunctionConcurrency",
            "lambda:UpdateAlias",
            "lambda:UpdateFunctionCode"
        ],
        "Resource": "arn:aws:lambda:*:*:function:*",
        "Condition": {
            "StringEquals": {
            "aws:ResourceTag/project-name": "${aws:PrincipalTag/project-name}"
            }
        }
        }
    ]
    }
    

    In this policy, Resource is wild-carded as "*" for all Lambda functions. The condition limits access to only resources that have the same project-name key and value, without having to list each individual Amazon Resource Name (ARN).

    The security administrator creates an IAM role for each developer’s project, such as falcon-developer-role or eagle-developer-role. Since the policy references both the function tags and the IAM role tags, she can reuse the previous policy and apply it to both of the project roles. Each role should have the tag key project-name with the value set to the project, such as falcon or eagle. The following shows the tags for Project Falcon:

    Tags for Project Falcon

    Tags for Project Falcon

    The developers now have access to the existing Lambda functions in their respective projects. The developer for Project Falcon needs to create additional Lambda functions for only their project. Since the project-name tag also authorizes who can access the function, the developer should not be able to create a function without the correct tags. To enforce this, the security administrator applies a new policy to the developer’s role using the RequestTag condition key to specify that a project-name tag exists:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
        "Sid": "AllowLambdaTagOnCreate",
        "Effect": "Allow",
        "Action": [
            "lambda:CreateFunction",
            “lambda:TagResource”
        ]
        "Resource": "arn:aws:lambda:*:*:function:*",
        "Condition": {
            "StringEquals": {,
                “aws:RequestTag/project-name”: “${aws:PrincipalTag/project-name}”
            },
            "ForAllValues:StringEquals": {
                "aws:TagKeys": [
                     “project-name”
                ]
            }
        }
        }
    ]
    }

    To create the functions, the developer must add the key project-name and value falcon to the tags. Without the tag, the developer cannot create the function.

    Project Falcon tags

    Project Falcon tags

    Because Project Falcon is using ABAC, by tagging the Lambda functions during creation, they did not need to engage the security administrator to add additional ARNs to the IAM policy. This provides flexibility to the developers to support their projects. This also helps scale the security administrators’ function by no longer needing to coordinate which resources need to be added to IAM policies to maintain least privilege access.

    The project must then add a manager who requires read access to projects as long as they are also in the organization labeled birds and cost-center : it.

    Organization and Cost Center tags

    Organization and Cost Center tags

    The security administrator creates a new IAM policy called manager-policy with the following statements:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
        "Sid": "AllActionsLambdaManager",
        "Effect": "Allow",
        "Action": [
            "lambda:GetAlias",
            "lambda:GetFunction",
            "lambda:GetFunctionConfiguration",
            "lambda:GetPolicy",
            "lambda:GetPolicy",
            "lambda:ListAliases", 
            "lambda:ListVersionsByFunction"
        ],
        "Resource": "arn:aws:lambda:*:*:function:*",
        "Condition": {
            "StringEquals": {
                “aws:ResourceTag/organization”: “${aws:PrincipalTag/organization}”,
                “aws:ResourceTag/cost-center”: “$}aws:PrincipalTag/cost-center}”
            }
        }
        }
    ]
    }
    

    The security administrator attaches the policy to the manager’s role along with the tag organization:birds, and cost-center:it. If any of the projects change organization, the manager no longer has access, even if the cost-center remains IT.

    In this policy, the condition ensures both the cost-center and organization tags exist for the function and the values are equal to the tags in the manager’s role. Even if the cost-center tag matches for both the Lambda function and the manager’s role, yet the manager’s organization tag doesn’t match, IAM denies access to the Lambda function. Tags themselves are only a key:value pair with no relationship to other tags. You can use multiple tags, as in this example, to more granularly define Lambda function permissions.

    Conclusion

    You can now use attribute-based access control (ABAC) with Lambda to control access to functions using tags. This allows you to scale your access controls by simplifying the management of permissions while still maintaining least privilege security best practices. Security administrators can coordinate with developers on a tagging strategy and create IAM policies with ABAC condition keys. This then gives freedom to developers to grow their applications by adding tags to functions, without needing a security administrator to update individual IAM policies.

    Attribute-based Access Control (ABAC) for Lambda functions support is also available through many AWS Lambda Partners such as Lumigo, Pulumi and Vertical Relevance.

    For additional documentation on ABAC with Lambda see Attribute-based access control for Lambda.

    Introducing Amazon CodeWhisperer in the AWS Lambda console (In preview)

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/introducing-amazon-codewhisperer-in-the-aws-lambda-console-in-preview/

    This blog post is written by Mark Richman, Senior Solutions Architect.

    Today, AWS is launching a new capability to integrate the Amazon CodeWhisperer experience with the AWS Lambda console code editor.

    Amazon CodeWhisperer is a machine learning (ML)–powered service that helps improve developer productivity. It generates code recommendations based on their code comments written in natural language and code.

    CodeWhisperer is available as part of the AWS toolkit extensions for major IDEs, including JetBrains, Visual Studio Code, and AWS Cloud9, currently supporting Python, Java, and JavaScript. In the Lambda console, CodeWhisperer is available as a native code suggestion feature, which is the focus of this blog post.

    CodeWhisperer is currently available in preview with a waitlist. This blog post explains how to request access to and activate CodeWhisperer for the Lambda console. Once activated, CodeWhisperer can make code recommendations on-demand in the Lambda code editor as you develop your function. During the preview period, developers can use CodeWhisperer at no cost.

    Amazon CodeWhisperer

    Amazon CodeWhisperer

    Lambda is a serverless compute service that runs your code in response to events and automatically manages the underlying compute resources for you. You can trigger Lambda from over 200 AWS services and software as a service (SaaS) applications and only pay for what you use.

    With Lambda, you can build your functions directly in the AWS Management Console and take advantage of CodeWhisperer integration. CodeWhisperer in the Lambda console currently supports functions using the Python and Node.js runtimes.

    When writing AWS Lambda functions in the console, CodeWhisperer analyzes the code and comments, determines which cloud services and public libraries are best suited for the specified task, and recommends a code snippet directly in the source code editor. The code recommendations provided by CodeWhisperer are based on ML models trained on a variety of data sources, including Amazon and open source code. Developers can accept the recommendation or simply continue to write their own code.

    Requesting CodeWhisperer access

    CodeWhisperer integration with Lambda is currently available as a preview only in the N. Virginia (us-east-1) Region. To use CodeWhisperer in the Lambda console, you must first sign up to access the service in preview here or request access directly from within the Lambda console.

    In the AWS Lambda console, under the Code tab, in the Code source editor, select the Tools menu, and Request Amazon CodeWhisperer Access.

    Request CodeWhisperer access in Lambda console

    Request CodeWhisperer access in Lambda console

    You may also request access from the Preferences pane.

    Request CodeWhisperer access in Lambda console preference pane

    Request CodeWhisperer access in Lambda console preference pane

    Selecting either of these options opens the sign-up form.

    CodeWhisperer sign up form

    CodeWhisperer sign up form

    Enter your contact information, including your AWS account ID. This is required to enable the AWS Lambda console integration. You will receive a welcome email from the CodeWhisperer team upon once they approve your request.

    Activating Amazon CodeWhisperer in the Lambda console

    Once AWS enables your preview access, you must turn on the CodeWhisperer integration in the Lambda console, and configure the required permissions.

    From the Tools menu, enable Amazon CodeWhisperer Code Suggestions

    Enable CodeWhisperer code suggestions

    Enable CodeWhisperer code suggestions

    You can also enable code suggestions from the Preferences pane:

    Enable CodeWhisperer code suggestions from Preferences pane

    Enable CodeWhisperer code suggestions from Preferences pane

    The first time you activate CodeWhisperer, you see a pop-up containing terms and conditions for using the service.

    CodeWhisperer Preview Terms

    CodeWhisperer Preview Terms

    Read the terms and conditions and choose Accept to continue.

    AWS Identity and Access Management (IAM) permissions

    For CodeWhisperer to provide recommendations in the Lambda console, you must enable the proper AWS Identity and Access Management (IAM) permissions for either your IAM user or role. In addition to Lambda console editor permissions, you must add the codewhisperer:GenerateRecommendations permission.

    Here is a sample IAM policy that grants a user permission to the Lambda console as well as CodeWhisperer:

    {
      "Version": "2012-10-17",
      "Statement": [{
          "Sid": "LambdaConsolePermissions",
          "Effect": "Allow",
          "Action": [
            "lambda:AddPermission",
            "lambda:CreateEventSourceMapping",
            "lambda:CreateFunction",
            "lambda:DeleteEventSourceMapping",
            "lambda:GetAccountSettings",
            "lambda:GetEventSourceMapping",
            "lambda:GetFunction",
            "lambda:GetFunctionCodeSigningConfig",
            "lambda:GetFunctionConcurrency",
            "lambda:GetFunctionConfiguration",
            "lambda:InvokeFunction",
            "lambda:ListEventSourceMappings",
            "lambda:ListFunctions",
            "lambda:ListTags",
            "lambda:PutFunctionConcurrency",
            "lambda:UpdateEventSourceMapping",
            "iam:AttachRolePolicy",
            "iam:CreatePolicy",
            "iam:CreateRole",
            "iam:GetRole",
            "iam:GetRolePolicy",
            "iam:ListAttachedRolePolicies",
            "iam:ListRolePolicies",
            "iam:ListRoles",
            "iam:PassRole",
            "iam:SimulatePrincipalPolicy"
          ],
          "Resource": "*"
        },
        {
          "Sid": "CodeWhispererPermissions",
          "Effect": "Allow",
          "Action": ["codewhisperer:GenerateRecommendations"],
          "Resource": "*"
        }
      ]
    }

    This example is for illustration only. It is best practice to use IAM policies to grant restrictive permissions to IAM principals to meet least privilege standards.

    Demo

    To activate and work with code suggestions, use the following keyboard shortcuts:

    • Manually fetch a code suggestion: Option+C (macOS), Alt+C (Windows)
    • Accept a suggestion: Tab
    • Reject a suggestion: ESC, Backspace, scroll in any direction, or keep typing and the recommendation automatically disappears.

    Currently, the IDE extensions provide automatic suggestions and can show multiple suggestions. The Lambda console integration requires a manual fetch and shows a single suggestion.

    Here are some common ways to use CodeWhisperer while authoring Lambda functions.

    Single-line code completion

    When typing single lines of code, CodeWhisperer suggests how to complete the line.

    CodeWhisperer single-line completion

    CodeWhisperer single-line completion

    Full function generation

    CodeWhisperer can generate an entire function based on your function signature or code comments. In the following example, a developer has written a function signature for reading a file from Amazon S3. CodeWhisperer then suggests a full implementation of the read_from_s3 method.

    CodeWhisperer full function generation

    CodeWhisperer full function generation

    CodeWhisperer may include import statements as part of its suggestions, as in the previous example. As a best practice to improve performance, manually move these import statements to outside the function handler.

    Generate code from comments

    CodeWhisperer can also generate code from comments. The following example shows how CodeWhisperer generates code to use AWS APIs to upload files to Amazon S3. Write a comment describing the intended functionality and, on the following line, activate the CodeWhisperer suggestions. Given the context from the comment, CodeWhisperer first suggests the function signature code in its recommendation.

    CodeWhisperer generate function signature code from comments

    CodeWhisperer generate function signature code from comments

    After you accept the function signature, CodeWhisperer suggests the rest of the function code.

    CodeWhisperer generate function code from comments

    CodeWhisperer generate function code from comments

    When you accept the suggestion, CodeWhisperer completes the entire code block.

    CodeWhisperer generates code to write to S3.

    CodeWhisperer generates code to write to S3.

    CodeWhisperer can help write code that accesses many other AWS services. In the following example, a code comment indicates that a function is sending a notification using Amazon Simple Notification Service (SNS). Based on this comment, CodeWhisperer suggests a function signature.

    CodeWhisperer function signature for SNS

    CodeWhisperer function signature for SNS

    If you accept the suggested function signature. CodeWhisperer suggest a complete implementation of the send_notification function.

    CodeWhisperer function send notification for SNS

    CodeWhisperer function send notification for SNS

    The same procedure works with Amazon DynamoDB. When writing a code comment indicating that the function is to get an item from a DynamoDB table, CodeWhisperer suggests a function signature.

    CodeWhisperer DynamoDB function signature

    CodeWhisperer DynamoDB function signature

    When accepting the suggestion, CodeWhisperer then suggests a full code snippet to complete the implementation.

    CodeWhisperer DynamoDB code snippet

    CodeWhisperer DynamoDB code snippet

    Once reviewing the suggestion, a common refactoring step in this example would be manually moving the references to the DynamoDB resource and table outside the get_item function.

    CodeWhisperer can also recommend complex algorithm implementations, such as Insertion sort.

    CodeWhisperer insertion sort.

    CodeWhisperer insertion sort.

    As a best practice, always test the code recommendation for completeness and correctness.

    CodeWhisperer not only provides suggested code snippets when integrating with AWS APIs, but can help you implement common programming idioms, including proper error handling.

    Conclusion

    CodeWhisperer is a general purpose, machine learning-powered code generator that provides you with code recommendations in real time. When activated in the Lambda console, CodeWhisperer generates suggestions based on your existing code and comments, helping to accelerate your application development on AWS.

    To get started, visit https://aws.amazon.com/codewhisperer/. Share your feedback with us at [email protected].

    For more serverless learning resources, visit Serverless Land.

    Understanding AWS Lambda scaling and throughput

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/understanding-aws-lambda-scaling-and-throughput/

    AWS Lambda provides a serverless compute service that can scale from a single request to hundreds of thousands per second. When designing your application, especially for high load, it helps to understand how Lambda handles scaling and throughput. There are two components to consider: concurrency and transactions per second.

    Concurrency of a system is the ability to process more than one task simultaneously. You can measure concurrency at a point in time to view how many tasks the system is doing in parallel. The number of transactions a system can process per second is not the same as concurrency, because a transaction can take more or less than a second to process.

    This post shows you how concurrency and transactions per second work within the Lambda lifecycle. It also covers ways to measure, control, and optimize them.

    The Lambda runtime environment

    Lambda invokes your code in a secure and isolated runtime environment. The following shows the lifecycle of requests to a single function.

    First request to invoke your function

    First request to invoke your function

    At the first request to invoke your function, Lambda creates a new runtime environment. It then runs the function’s initialization (init) code, which is the code outside the main handler. Lambda then runs the function handler code as the invocation. This receives the event payload and processes your business logic.

    Each runtime environment processes a single request at a time. While a single runtime environment is processing a request, it cannot process other requests.

    After Lambda finishes processing the request, the runtime environment is ready to process an additional request for the same function. As the initialization code has already run, for request 2, Lambda runs only the function handler code as the invocation.

    Lambda ready to process an additional request for the same function

    Lambda ready to process an additional request for the same function

    If additional requests arrive while processing request 1, Lambda creates new runtime environments. In this example, Lambda creates new runtime environments for requests 2, 3, 4, and 5. It runs the function init and the invocation.

    Lambda creating new runtime environments

    Lambda creating new runtime environments

    When requests arrive, Lambda reuses available runtime environments, and creates new ones if necessary. The following example shows the behavior for additional requests after 1-5.

    Lambda reusing runtime environments

    Lambda reusing runtime environments

    Once request 1 completes, the runtime environment is available to process another request. When request 6 arrives, Lambda re-uses request 1s runtime environment and runs the invocation. This process continues for requests 7 and 8, which reuse the runtime environments from requests 2 and 3. When request 9 arrives, Lambda creates a new runtime environment as there isn’t an existing one available. When request 10 arrives, it reuses the runtime environment freed up after request 4.

    The number of runtime environments determines the concurrency. This is the sum of all concurrent requests for currently running functions at a particular point in time. For a single runtime environment, the number of concurrent requests is 1.

    Single runtime environment concurrent requests

    Single runtime environment concurrent requests

    For the example with requests 1–10, the Lambda function concurrency at particular times is the following:

    Lambda concurrency at particular times

    Lambda concurrency at particular times

    time concurrency
    t1 3
    t2 5
    t3 4
    t4 6
    t5 5
    t6 2

    When the number of requests decreases, Lambda stops unused runtime environments to free up scaling capacity for other functions.

    Invocation duration, concurrency, and transactions per second

    The number of transactions Lambda can process per second is the sum of all invokes for that period. If a function takes 1 second to run, and 10 invocations happen concurrently, Lambda creates 10 runtime environments. In this case, Lambda processes 10 requests per second.

    Lambda transactions per second for 1 second invocation

    Lambda transactions per second for 1 second invocation

    If the function duration is halved to 500 ms, the Lambda concurrency remains 10. However, transactions per second are now 20.

    Lambda transactions per second for 500 ms second invocation

    Lambda transactions per second for 500 ms second invocation

    If the function takes 2 seconds to run, during the initial second, transactions per second is 0. However, averaged over time, transactions per second is 5.

    You can view concurrency using Amazon CloudWatch metrics. Use the metric name ConcurrentExecutions to view concurrent invocations for all or individual functions.

    CloudWatch metrics ConcurrentExecutions

    CloudWatch metrics ConcurrentExecutions

    You can also estimate concurrent requests from the number of requests per unit of time, in this case seconds, and their average duration, using the formula:

    RequestsPerSecond x AvgDurationInSeconds = concurrent requests

    If a Lambda function takes an average 500 ms to run, at 100 requests per second, the number of concurrent requests is 50:

    100 requests/second x 0.5 sec = 50 concurrent requests

    If you half the function duration to 250 ms and the number of requests per second doubles to 200 requests/second, the number of concurrent requests remains the same:

    200 requests/second x 0.250 sec = 50 concurrent requests.

    Reducing a function’s duration can increase the transactions per second that a function can process. For more information on reducing function duration, watch this re:Invent video.

    Scaling quotas

    There are two scaling quotas to consider with concurrency. Account concurrency quota and burst concurrency quota.

    Account concurrency is the maximum concurrency in a particular Region. This is shared across all functions in an account. The default Regional concurrency quota starts at 1,000, which you can increase with a service ticket.

    The burst concurrency quota provides an initial burst of traffic for each function, between 500 and 3000 per minute, depending on the Region.

    After this initial burst, functions can scale by another 500 concurrent invocations per minute for all Regions. If you reach the maximum number of concurrent requests, further requests are throttled.

    For synchronous invocations, Lambda returns a throttling error (429) to the caller, which must retry the request. With asynchronous and event source mapping invokes, Lambda automatically retries the requests. See Error handling and automatic retries in AWS Lambda for more detail.

    A scaling quota example

    The following walks through how account and burst concurrency work for an example application.

    Anticipating handling additional load, the application builders have raised account concurrency to 7,000. There are no other Lambda functions running in this account, so this function can use all available account concurrency.

    Lambda account and burst concurrency

    Lambda account and burst concurrency

    1. 08:59: The application already has a steady stream of requests, using 1,000 concurrent runtime environments. Each Lambda invocation takes 250 ms, so transactions per second are 4,000.
    2. 09:00: There is a large spike in traffic at 5,000 sustained requests. 1000 requests use the existing runtime environments. Lambda uses the 3,000 available burst concurrency to create new environments to handle the additional load. 1,000 requests are throttled as there is not enough burst concurrency to handle all 5,000 requests. Transactions per second are 16,000.
    3. 09:01: Lambda scales by another 500 concurrent invocations per minute. 500 requests are still throttled. The application can now handle 4,500 concurrent requests.
    4. 09:02: Lambda scales by another 500 concurrent invocations per minute. No requests are throttled. The application can now handle all 5,000 requests.
    5. 09:03: The application continues to handle the sustained 5000 requests. The burst concurrency quota rises to 500.
    6. 09:04: The application sees another spike in traffic, this time unexpected. 3,000 new sustained requests arrive, a combination of 8,000 requests. 5,000 requests use the existing runtime environments. Lambda uses the now available burst concurrency of 1,000 to create new environments to handle the additional load. 1,000 requests are throttled as there is not enough burst concurrency. Another 1,000 requests are throttled as the account concurrency quota has been reached.
    7. 09:05: Lambda scales by another 500 concurrent requests. The application can now handle 6,500 requests. 500 requests are throttled as there is not enough burst concurrency. 1,000 requests are still throttled as the account concurrency quota has been reached.
    8. 09:06: Lambda scales by another 500 concurrent requests. The application can now handle 7,000 requests. 1,000 requests are still throttled as the account concurrency quota has been reached.
    9. 09:07: The application continues to handle the sustained 7,000 requests. 1,000 requests are still throttled as the account concurrency quota has been reached. Transactions per second are 28,000.

    Service Quotas is an AWS service that helps you manage your quotas for many AWS services. Along with looking up the values, you can also request a limit increase from the Service Quotas console.

    Service Quotas console

    Service Quotas console

    Reserved concurrency

    You can configure a Reserved concurrency setting for your Lambda functions to allocate a maximum concurrency limit for a function. This assigns part of the account concurrency quota to a specific function. This protects and ensures that a function is not throttled and can always scale up to the reserved concurrency value.

    It can also help protect downstream resources. If a database or external API can only handle 2 concurrent connections, you can ensure Lambda can’t scale beyond 2 concurrent invokes. This ensures Lambda doesn’t overwhelm the downstream service. You can also use reserved concurrency to avoid race conditions to ensure that your function can only run one concurrent invocation at a time.

    Reserved concurrency

    Reserved concurrency

    You can also set the function concurrency to zero, which stops any function invocations and acts as an off-switch. This can be useful to stop Lambda invocations when you have an issue with a downstream resource. It can give you time to fix the issue before removing or increasing the concurrency to allow invocations to continue.

    Provisioned Concurrency

    The function initialization process can introduce latency for your applications. You can reduce this latency by configuring Provisioned Concurrency for a function version or alias. This prepares runtime environments in advance, running the function initialization process, so the function is ready to invoke when needed.

    This is primarily useful for synchronous requests to ensure you have enough concurrency before an expected traffic spike. You can still burst above this using standard concurrency. The following example shows Provisioned Concurrency configured as 10. Lambda runs the init process for 10 functions, and then when requests arrive, immediately runs the invocation.

    Provisioned Concurrency

    Provisioned Concurrency

    You can use Application Auto Scaling to adjust Provisioned Concurrency automatically based on Lambda’s utilization metric.

    Operational metrics

    There are CloudWatch metrics available to monitor your account and function concurrency to ensure that your applications can scale as expected. Monitor function Invocations and Duration to understand throughput. Throttles show throttled invocations.

    ConcurrentExecutions tracks the total number of runtime environments that are processing events. Ensure this doesn’t reach your account concurrency to avoid account throttling. Use the metric for individual functions to see which are using account concurrency, and also ensure reserved concurrency is not too high. For example, a function may have a reserved concurrency of 2000, but is only using 10.

    UnreservedConcurrentExecutions show the number of function invocations without reserved concurrency. This is your available account concurrency buffer.

    Use ProvisionedConcurrencyUtilization to ensure you are not paying for Provisioned Concurrency that you are not using. The metric shows the percentage of allocated Provisioned Concurrency in use.

    ProvisionedConcurrencySpilloverInvocations show function invocations using standard concurrency, above the configured Provisioned Concurrency value. This may show that you need to increase Provisioned Concurrency.

    Conclusion

    Lambda provides a highly scalable compute service. Understanding how Lambda scaling and throughput works can help you design your application, especially for high load.

    This post explains concurrency and transactions per second. It shows how account and burst concurrency quotas work. You can configure reserved concurrency to ensure that your functions can always scale, and also use it to protect downstream resources. Use Provisioned Concurrency to scale up Lambda in advance of invokes.

    For more serverless learning resources, visit Serverless Land.

    Simplifying serverless best practices with AWS Lambda Powertools for TypeScript

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/simplifying-serverless-best-practices-with-aws-lambda-powertools-for-typescript/

    This blog post is written by Sara Gerion, Senior Solutions Architect.

    Development teams must have a shared understanding of the workloads they own and their expected behaviors to deliver business value fast and with confidence. The AWS Well-Architected Framework and its Serverless Lens provide architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the AWS Cloud.

    Developers should design and configure their workloads to emit information about their internal state and current status. This allows engineering teams to ask arbitrary questions about the health of their systems at any time. For example, emitting metrics, logs, and traces with useful contextual information enables situational awareness and allows developers to filter and select only what they need.

    Following such practices reduces the number of bugs, accelerates remediation, and speeds up the application lifecycle into production. They can help mitigate deployment risks, offer more accurate production-readiness assessments and enable more informed decisions to deploy systems and changes.

    AWS Lambda Powertools for TypeScript

    AWS Lambda Powertools provides a suite of utilities for AWS Lambda functions to ease the adoption of serverless best practices. The AWS Hero Yan Cui’s initial implementation of DAZN Lambda Powertools inspired this idea.

    Following the community’s adoption of AWS Lambda Powertools for Python and AWS Lambda Powertools for Java, we are excited to announce the general availability of the AWS Lambda Powertools for TypeScript.

    AWS Lambda Powertools for TypeScript provides a suite of utilities for Node.js runtimes, which you can use in both JavaScript and TypeScript code bases. The library follows a modular approach similar to the AWS SDK v3 for JavaScript. Each utility is installed as standalone NPM package.

    Today, the library is ready for production use with three observability features: distributed tracing (Tracer), structured logging (Logger), and asynchronous business and application metrics (Metrics).

    You can instrument your code with Powertools in three different ways:

    • Manually. It provides the most granular control. It’s the most verbose approach, with the added benefit of no additional dependency and no refactoring to TypeScript Classes.
    • Middy middleware. It is the best choice if your existing code base relies on the Middy middleware engine. Powertools offers compatible Middy middleware to make this integration seamless.
    • Method decorator. Use TypeScript method decorators if you prefer writing your business logic using TypeScript Classes. If you aren’t using Classes, this requires the most significant refactoring.

    The examples in this blog post use the Middy approach. To follow the examples, ensure that middy is installed:

    npm i @middy/core

    Logger

    Logger provides an opinionated logger with output structured as JSON. Its key features include:

    • Capturing key fields from the Lambda context, cold starts, and structure logging output as JSON.
    • Logging Lambda invocation events when instructed (disabled by default).
    • Printing all the logs only for a percentage of invocations via log sampling (disabled by default).
    • Appending additional keys to structured logs at any point in time.
    • Providing a custom log formatter (Bring Your Own Formatter) to output logs in a structure compatible with your organization’s Logging RFC.

    To install, run:

    npm install @aws-lambda-powertools/logger

    Usage example:

    import { Logger, injectLambdaContext } from '@aws-lambda-powertools/logger';
     import middy from '@middy/core';
    
     const logger = new Logger({
        logLevel: 'INFO',
        serviceName: 'shopping-cart-api',
    });
    
     const lambdaHandler = async (): Promise<void> => {
         logger.info('This is an INFO log with some context');
     };
    
     export const handler = middy(lambdaHandler)
         .use(injectLambdaContext(logger));

    In Amazon CloudWatch, the structured log emitted by your application looks like:

    {
         "cold_start": true,
         "function_arn": "arn:aws:lambda:eu-west-1:123456789012:function:shopping-cart-api-lambda-prod-eu-west-1",
         "function_memory_size": 128,
         "function_request_id": "c6af9ac6-7b61-11e6-9a41-93e812345678",
         "function_name": "shopping-cart-api-lambda-prod-eu-west-1",
         "level": "INFO",
         "message": "This is an INFO log with some context",
         "service": "shopping-cart-api",
         "timestamp": "2021-12-12T21:21:08.921Z",
         "xray_trace_id": "abcdef123456abcdef123456abcdef123456"
     }

    Logs generated by Powertools can also be ingested and analyzed by any third-party SaaS vendor that supports JSON.

    Tracer

    Tracer is an opinionated thin wrapper for AWS X-Ray SDK for Node.js.

    Its key features include:

    • Auto-capturing cold start and service name as annotations, and responses or full exceptions as metadata.
    • Automatically tracing HTTP(S) clients and generating segments for each request.
    • Supporting tracing functions via decorators, middleware, and manual instrumentation.
    • Supporting tracing AWS SDK v2 and v3 via AWS X-Ray SDK for Node.js.
    • Auto-disable tracing when not running in the Lambda environment.

    To install, run:

    npm install @aws-lambda-powertools/tracer

    Usage example:

    import { Tracer, captureLambdaHandler } from '@aws-lambda-powertools/tracer';
     import middy from '@middy/core'; 
    
     const tracer = new Tracer({
        serviceName: 'shopping-cart-api'
    });
    
     const lambdaHandler = async (): Promise<void> => {
         /* ... Something happens ... */
     };
    
     export const handler = middy(lambdaHandler)
         .use(captureLambdaHandler(tracer));
    AWS X-Ray segments and subsegments emitted by Powertools

    AWS X-Ray segments and subsegments emitted by Powertools

    Example service map generated with Powertools

    Example service map generated with Powertools

    Metrics

    Metrics create custom metrics asynchronously by logging metrics to standard output following the Amazon CloudWatch Embedded Metric Format (EMF). These metrics can be visualized through CloudWatch dashboards or used to trigger alerts.

    Its key features include:

    • Aggregating up to 100 metrics using a single CloudWatch EMF object (large JSON blob).
    • Validating your metrics against common metric definitions mistakes (for example, metric unit, values, max dimensions, max metrics).
    • Metrics are created asynchronously by the CloudWatch service. You do not need any custom stacks, and there is no impact to Lambda function latency.
    • Creating a one-off metric with different dimensions.

    To install, run:

    npm install @aws-lambda-powertools/metrics

    Usage example:

    import { Metrics, MetricUnits, logMetrics } from '@aws-lambda-powertools/metrics';
     import middy from '@middy/core';
    
     const metrics = new Metrics({
        namespace: 'serverlessAirline', 
        serviceName: 'orders'
    });
    
     const lambdaHandler = async (): Promise<void> => {
         metrics.addMetric('successfulBooking', MetricUnits.Count, 1);
     };
    
     export const handler = middy(lambdaHandler)
         .use(logMetrics(metrics));
    

    In CloudWatch, the custom metric emitted by your application looks like:

    {
         "successfulBooking": 1.0,
         "_aws": {
         "Timestamp": 1592234975665,
         "CloudWatchMetrics": [
             {
             "Namespace": "serverlessAirline",
             "Dimensions": [
                 [
                 "service"
                 ]
             ],
             "Metrics": [
                 {
                 "Name": "successfulBooking",
                 "Unit": "Count"
                 }
             ]
         },
         "service": "orders"
     }
    

    Serverless TypeScript demo application

    The Serverless TypeScript Demo shows how to use Lambda Powertools for TypeScript. You can find instructions on how to deploy and load test this application in the repository.

    Serverless TypeScript Demo architecture

    Serverless TypeScript Demo architecture

    The code for the Get Products Lambda function shows how to use the utilities. The function is instrumented with Logger, Metrics and Tracer to emit observability data.

    // blob/main/src/api/get-products.ts
    import { APIGatewayProxyEvent, APIGatewayProxyResult} from "aws-lambda";
    import { DynamoDbStore } from "../store/dynamodb/dynamodb-store";
    import { ProductStore } from "../store/product-store";
    import { logger, tracer, metrics } from "../powertools/utilities"
    import middy from "@middy/core";
    import { captureLambdaHandler } from '@aws-lambda-powertools/tracer';
    import { injectLambdaContext } from '@aws-lambda-powertools/logger';
    import { logMetrics, MetricUnits } from '@aws-lambda-powertools/metrics';
    
    const store: ProductStore = new DynamoDbStore();
    const lambdaHandler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
    
      logger.appendKeys({
        resource_path: event.requestContext.resourcePath
      });
    
      try {
        const result = await store.getProducts();
    
        logger.info('Products retrieved', { details: { products: result } });
        metrics.addMetric('productsRetrieved', MetricUnits.Count, 1);
    
        return {
          statusCode: 200,
          headers: { "content-type": "application/json" },
          body: `{"products":${JSON.stringify(result)}}`,
        };
      } catch (error) {
          logger.error('Unexpected error occurred while trying to retrieve products', error as Error);
    
          return {
            statusCode: 500,
            headers: { "content-type": "application/json" },
            body: JSON.stringify(error),
          };
      }
    };
    
    const handler = middy(lambdaHandler)
        .use(captureLambdaHandler(tracer))
        .use(logMetrics(metrics, { captureColdStartMetric: true }))
        .use(injectLambdaContext(logger, { clearState: true, logEvent: true }));
    
    export {
      handler
    };
    

    The Logger utility adds useful context to the application logs. Structuring your logs as JSON allows you to search on your structured data using Amazon CloudWatch Logs Insights. This allows you to filter out the information you don’t need.

    For example, use the following query to search for any errors for the serverless-typescript-demo service.

    fields resource_path, message, timestamp
    | filter service = 'serverless-typescript-demo'
    | filter level = 'ERROR'
    | sort @timestamp desc
    | limit 20
    CloudWatch Logs Insights showing errors for the serverless-typescript-demo service.

    CloudWatch Logs Insights showing errors for the serverless-typescript-demo service.

    The Tracer utility adds custom annotations and metadata during the function invocation, which it sends to AWS X-Ray. Annotations allow you to search for and filter traces by business or application contextual information such as product ID, or cold start.

    You can see the duration of the putProduct method and the ColdStart and Service annotations attached to the Lambda handler function.

    putProduct trace view

    putProduct trace view

    The Metrics utility simplifies the creation of complex high-cardinality application data. Including structured data along with your metrics allows you to search or perform additional analysis when needed.

    In this example, you can see how many times per second a product is created, deleted, or queried. You could configure alarms based on the metrics.

    Metrics view

    Metrics view

    Code examples

    You can use Powertools with many Infrastructure as Code or deployment tools. The project contains source code and supporting files for serverless applications that you can deploy with the AWS Cloud Development Kit (AWS CDK) or AWS Serverless Application Model (AWS SAM).

    The AWS CDK lets you build reliable and scalable applications in the cloud with the expressive power of a programming language, including TypeScript. The AWS SAM CLI is that makes it easier to create and manage serverless applications.

    You can use the sample applications provided in the GitHub repository to understand how to use the library quickly and experiment in your own AWS environment.

    Conclusion

    AWS Lambda Powertools for TypeScript can help simplify, accelerate, and scale the adoption of serverless best practices within your team and across your organization.

    The library implements best practices recommended as part of the AWS Well-Architected Framework, without you needing to write much custom code.

    Since the library relieves the operational burden needed to implement these functionalities, you can focus on the features that matter the most, shortening the Software Development Life Cycle and reducing the Time To Market.

    The library helps both individual developers and engineering teams to standardize their organizational best practices. Utilities are designed to be incrementally adoptable for customers at any stage of their serverless journey, from startup to enterprise.

    To get started with AWS Lambda Powertools for TypeScript, see the official documentation. For more serverless learning resources, visit Serverless Land.

    Building a low-code speech “you know” counter using AWS Step Functions

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/building-a-low-code-speech-you-know-counter-using-aws-step-functions/

    This post is written by Doug Toppin, Software Development Engineer, and Kishore Dhamodaran, Solutions Architect.

    In public speaking, filler phrases can distract the audience and reduce the value and impact of what you are telling them. Reviewing recordings of presentations can be helpful to determine whether presenters are using filler phrases. Instead of manually reviewing prior recordings, automation can process media files and perform a speech-to-text function. That text can then be processed to report on the use of filler phrases.

    This blog explains how to use AWS Step Functions, Amazon EventBridge, Amazon Transcribe and Amazon Athena to report on the use of the common phrase “you know” in media files. These services can automate and reduce the time required to find the use of filler phrases.

    Step Functions can automate and chain together multiple activities and other Amazon services. Amazon Transcribe is a speech to text service that uses media files as input and produces textual transcripts from them. Athena is an interactive query service that makes it easier to analyze data in Amazon S3 using standard SQL. Athena enables the use of standard SQL to query data in S3.

    This blog shows a low-code, configuration driven approach to implementing this solution. Low-code means writing little or no custom software to perform a function. Instead, you use a configuration drive approach using service integrations where state machine tasks call AWS services using existing SDKs, APIs, or interfaces. A configuration driven approach in this example is using Step Functions’ Amazon States Language (ASL) to tie actions together rather than writing traditional code. This requires fewer details for data management and error handling combined with a visual user interface for composing the workflow. As the actions and logic are clearly defined with the visual workflow, this reduces maintenance.

    Solution overview

    The following diagram shows the solution architecture.

    SolutionOverview

    Solution Overview

    1. You upload a media file to an Amazon S3 Media bucket.
    2. The media file upload to S3 triggers an EventBridge rule.
    3. The EventBridge rule starts the Step Functions state machine execution.
    4. The state machine invokes Amazon Transcribe to process the media file.
    5. The transcription output file is stored in the Amazon S3 Transcript bucket.
    6. The state machine invokes Athena to query the textual transcript for the filler phrase. This uses the AWS Glue table to describe the format of the transcription results file.
    7. The filler phrase count determined by Athena is returned and stored in the Amazon S3 Results bucket.

    Prerequisites

    1. An AWS account and an AWS user or role with sufficient permissions to create the necessary resources.
    2. Access to the following AWS services: Step Functions, Amazon Transcribe, Athena, and Amazon S3.
    3. Latest version of the AWS Serverless Application Model (AWS SAM) CLI, which helps developers create and manage serverless applications in the AWS Cloud.
    4. Test media files (for example, the Official AWS Podcast).

    Example walkthrough

    1. Clone the GitHub repository to your local machine.
    2. git clone https://github.com/aws-samples/aws-stepfunctions-examples.git
    3. Deploy the resources using AWS SAM. The deploy command processes the AWS SAM template file to create the necessary resources in AWS. Choose you-know as the stack name and the AWS Region that you want to deploy your solution to.
    4. cd aws-stepfunctions-examples/sam/app-low-code-you-know-counter/
      sam deploy --guided

    Use the default parameters or replace with different values if necessary. For example, to get counts of a different filler phrase, replace the FillerPhrase parameter.

    GlueDatabaseYouKnowP Name of the AWS Glue database to create.
    AthenaTableName Name of the AWS Glue table that is used by Athena to query the results.
    FillerPhrase The filler phrase to check.
    AthenaQueryPreparedStatementName Name of the Athena prepared statement used to run SQL queries on.
    AthenaWorkgroup Athena workgroup to use
    AthenaDataCatalog The data source for running the Athena queries
    SAM Deploy

    SAM Deploy

    Running the filler phrase counter

    1. Navigate to the Amazon S3 console and upload an mp3 or mp4 podcast recording to the bucket named bucket-{account number}-{Region}-you-know-media.
    2. Navigate to the Step Functions console. Choose the running state machine, and monitor the execution of the transcription state machine.
    3. State Machine Execution

      State Machine Execution

    4. When the execution completes successfully, select the QueryExecutionSuccess task to examine the output and see the filler phrase count.
    5. State Machine Output

      State Machine Output

    6. Amazon Transcribe produces the transcript text of the media file. You can examine the output in the Results bucket. Using the S3 console, navigate to the bucket, choose the file matching the media file name and use ‘Query with S3 Select’ to view the content.
    7. If the transcription job does not execute, the state machine reports the failure and exits.
    8. State Machine Fail

      State Machine Fail

    Exploring the state machine

    The state machine orchestrates the transcription processing:

    State Machine Explore

    State Machine Explore

    The StartTranscriptionJob task starts the transcription job. The Wait state adds a 60-second delay before checking the status of the transcription job. Until the status of the job changes to FAILED or COMPLETED, the choice state continues.

    When the job successfully completes, the AthenaStartQueryExecutionUsingPreparedStatement task starts the Athena query, and stores the results in the S3 results bucket. The AthenaGetQueryResults task retrieves the count from the resultset.

    The TranscribeMediaBucket holds the media files to be uploaded. The configuration sends the upload notification event to EventBridge:

          
       NotificationConfiguration:
         EventBridgeConfiguration:
           EventBridgeEnabled: true
    	  

    The TranscribeResultsBucket has an associated policy to provide access to Amazon Transcribe. Athena stores the output from the queries performed by the state machine in the AthenaQueryResultsBucket .

    When a media upload occurs, the YouKnowTranscribeStateMachine uses Step Functions’ native event integration to trigger an EventBridge rule. This contains an event object similar to:

    {
      "version": "0",
      "id": "99a0cb40-4b26-7d74-dc59-c837f5346ac6",
      "detail-type": "Object Created",
      "source": "aws.s3",
      "account": "012345678901",
      "time": "2022-05-19T22:21:10Z",
      "region": "us-east-2",
      "resources": [
        "arn:aws:s3:::bucket-012345678901-us-east-2-you-know-media"
      ],
      "detail": {
        "version": "0",
        "bucket": {
          "name": "bucket-012345678901-us-east-2-you-know-media"
        },
        "object": {
          "key": "Podcase_Episode.m4a",
          "size": 202329,
          "etag": "624fce93a981f97d85025e8432e24f48",
          "sequencer": "006286C2D604D7A390"
        },
        "request-id": "B4DA7RD214V1QG3W",
        "requester": "012345678901",
        "source-ip-address": "172.0.0.1",
        "reason": "PutObject"
      }
    }
    

    The state machine allows you to prepare parameters and use the direct SDK integrations to start the transcription job by calling the Amazon Transcribe service’s API. This integration means you don’t have to write custom code to perform this function. The event triggering the state machine execution contains the uploaded media file location.

    
      StartTranscriptionJob:
    	Type: Task
    	Comment: Start a transcribe job on the provided media file
    	Parameters:
    	  Media:
    		MediaFileUri.$: States.Format('s3://{}/{}', $.detail.bucket.name, $.detail.object.key)
    	  TranscriptionJobName.$: "$.detail.object.key"
    	  IdentifyLanguage: true
    	  OutputBucketName: !Ref TranscribeResultsBucket
    	Resource: !Sub 'arn:${AWS::Partition}:states:${AWS::Region}:${AWS::AccountId}:aws-sdk:transcribe:startTranscriptionJob'
    

    The SDK uses aws-sdk:transcribe:getTranscriptionJob to get the status of the job.

    
      GetTranscriptionJob:
    	Type: Task
    	Comment: Retrieve the status of an Amazon Transcribe job
    	Parameters:
    	  TranscriptionJobName.$: "$.TranscriptionJob.TranscriptionJobName"
    	Resource: !Sub 'arn:${AWS::Partition}:states:${AWS::Region}:${AWS::AccountId}:aws-sdk:transcribe:getTranscriptionJob'
    	Next: TranscriptionJobStatus

    The state machine uses a polling loop with a delay to check the status of the transcription job.

    
      TranscriptionJobStatus:
    	Type: Choice
    	Choices:
    	- Variable: "$.TranscriptionJob.TranscriptionJobStatus"
    	  StringEquals: COMPLETED
    	  Next: AthenaStartQueryExecutionUsingPreparedStatement
    	- Variable: "$.TranscriptionJob.TranscriptionJobStatus"
    	  StringEquals: FAILED
    	  Next: Failed
    	Default: Wait

    When the transcription job completes successfully, the filler phrase counting process begins.

    An Athena prepared statement performs the query with the transcription job name as a runtime parameter. The AWS SDK starts the query and the state machine execution pauses, waiting for the results to return before progressing to the next state:

    athena:startQueryExecution.sync

    When the query completes, Step Functions uses the SDK integration to retrieve the results using athena:getQueryResults:

    athena:getQueryResults

    It creates an Athena prepared statement to pass the transcription jobname as a parameter for the query execution:

      ResultsQueryPreparedStatement:
        Type: AWS::Athena::PreparedStatement
        Properties:
          Description: Create a statement that allows the use of a parameter for specifying an Amazon Transcribe job name in the Athena query
          QueryStatement: !Sub >-
            select cardinality(regexp_extract_all(results.transcripts[1].transcript, '${FillerPhrase}')) AS item_count from "${GlueDatabaseYouKnow}"."${AthenaTableName}" where jobname like ?
          StatementName: !Ref AthenaQueryPreparedStatementName
          WorkGroup: !Ref AthenaWorkgroup

    There are several opportunities to enhance this tool. For example, adding support for multiple filler phrases. You could build a larger application to upload media and retrieve the results. You could take advantage of Amazon Transcribe’s real-time transcription API to display the results while a presentation is in progress to provide immediate feedback to the presenter.

    Cleaning up

    1. Navigate to the Amazon Transcribe console. Choose Transcription jobs in the left pane, select the jobs created by this example, and choose Delete.
    2. Cleanup Delete

      Cleanup Delete

    3. Navigate to the S3 console. In the Find buckets by name search bar, enter “you-know”. This shows the list of buckets created for this example. Choose each of the radio buttons next to the bucket individually and choose Empty.
    4. Cleanup S3

      Cleanup S3

    5. Use the following command to delete the stack, and confirm the stack deletion.
    6. sam delete

    Conclusion

    Low-code applications can increase developer efficiency by reducing the amount of custom code required to build solutions. They can also enable non-developer roles to create automation to perform business functions by providing drag-and-drop style user interfaces.

    This post shows how a low-code approach can build a tool chain using AWS services. The example processes media files to produce text transcripts and count the use of filler phrases in those transcripts. It shows how to process EventBridge data and how to invoke Amazon Transcribe and Athena using Step Functions state machines.

    For more serverless learning resources, visit Serverless Land.

    Extending PowerShell on AWS Lambda with other services

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/extending-powershell-on-aws-lambda-with-other-services/

    This post expands on the functionality introduced with the PowerShell custom runtime for AWS Lambda. The previous blog explains how the custom runtime approach makes it easier to run Lambda functions written in PowerShell.

    You can add additional functionality to your PowerShell serverless applications by importing PowerShell modules, which are shareable packages of code. Build your own modules or import from the wide variety of existing vendor modules to manage your infrastructure and applications.

    You can also take advantage of the event-driven nature of Lambda, which allows you to run Lambda functions in response to events. Events can include an object being uploaded to Amazon S3, a message placed on an Amazon SQS queue, a scheduled task using Amazon EventBridge, or an HTTP request from Amazon API Gateway. Lambda functions support event triggers from over 200 AWS services and software as a service (SaaS) applications.

    Adding PowerShell modules

    You can add PowerShell modules from a number of locations. These can include modules from the AWS Tools for PowerShell, from the PowerShell Gallery, or your own custom modules. Lambda functions access these PowerShell modules within specific folders within the Lambda runtime environment.

    You can include PowerShell modules via Lambda layers, within your function code package, or container image. When using .zip archive functions, you can use layers to package and share modules to use with your functions. Layers reduce the size of uploaded deployment archives and can make it faster to deploy your code. You can attach up to five layers to your function, one of which must be the PowerShell custom runtime layer. You can include multiple modules per layer.

    The custom runtime configures PowerShell’s PSModulePath environment variable, which contains the list of folder locations to search to find modules. The runtime searches the folders in the following order:

    1. User supplied modules as part of function package

    You can include PowerShell modules inside the published Lambda function package in a /modules subfolder.

    2. User supplied modules as part of Lambda layers

    You can publish Lambda layers that include PowerShell modules in a /modules subfolder. This allows you to share modules across functions and accounts. Lambda extracts layers to /opt within the Lambda runtime environment so the modules are located in /opt/modules. This is the preferred solution to use modules with multiple functions.

    3. Default/user supplied modules supplied with PowerShell

    You can also include additional default modules and add them within a /modules folder within the PowerShell custom runtime layer.

    For example, the following function includes four Lambda layers. One layer includes the custom runtime. Three additional layers include further PowerShell modules; the AWS Tools for PowerShell, your own custom modules, and third-party modules. You can also include additional modules with your function code.

    Lambda layers

    Lambda layers

    Within your PowerShell code, you can load modules during the function initialization (init) phase. This initializes the modules before the handler function runs, which speeds up subsequent warm-start invocations.

    Adding modules from the AWS Tools for PowerShell

    This post shows how to use the AWS Tools for PowerShell to manage your AWS services and resources. The tools are packaged as a set of PowerShell modules that are built on the functionality exposed by the AWS SDK for .NET. You can follow similar packaging steps to add other modules to your functions.

    The AWS Tools for PowerShell are available as three distinct packages:

    The AWS.Tools package is the preferred modularized version, which allows you to load only the modules for the services you want to use. This reduces package size and function memory usage. The AWS.Tools cmdlets support auto-importing modules without having to call Import-Module first. However, specifically importing the modules during the function init phase is more efficient and can reduce subsequent invoke duration. The AWS.Tools.Common module is required and provides cmdlets for configuration and authentication that are not service specific.

    The accompanying GitHub repository contains the code for the custom runtime, along with a number of example applications. There are also module build instructions for adding a number of common PowerShell modules as Lambda layers, including AWS.Tools.

    Building an event-driven PowerShell function

    The repository contains an example of an event-driven demo application that you can build using serverless services.

    A clothing printing company must manage its t-shirt size and color inventory. The printers store t-shirt orders for each day in a CSV file. The inventory service is one service that must receive the CSV file. It parses the file and, for each order, records the details to manage stock deliveries.

    The stores upload the files to S3. This automatically invokes a PowerShell Lambda function, which is configured to respond to the S3 ObjectCreated event. The Lambda function receives the S3 object location as part of the $LambdaInput event object. It uses the AWS Tools for PowerShell to download the file from S3. It parses the contents and, for each line in the CSV file, sends the individual order details as an event to an EventBridge event bus.

    In this example, there is a single rule to log the event to Amazon CloudWatch Logs to show the received event. However, you could route each order, depending on the order details, to different targets. For example, you can send different color combinations to SQS queues, which the dyeing service can use to order dyes. You could send particular size combinations to another Lambda function that manages cloth orders.

    Example event-driven application

    Example event-driven application

    The previous blog post shows how to use the AWS Serverless Application Model (AWS SAM) to build a Lambda layer, which includes only the AWS.Tools.Common module to run Get-AWSRegion. To build a PowerShell application to process objects from S3 and send events to EventBridge, you can extend this functionality by also including the AWS.Tools.S3 and AWS.Tools.EventBridge modules in a Lambda layer.

    Lambda layers, including S3 and EventBridge

    Lambda layers, including S3 and EventBridge

    Building the AWS Tools for PowerShell layer

    You could choose to add these modules and rebuild the existing layer. However, the example in this post creates a new Lambda layer to show how you can have different layers for different module combinations of AWS.Tools. The example also adds the Lambda layer Amazon Resource Name (ARN) to AWS Systems Manager Parameter Store to track deployed layers. This allows you to reference them more easily in infrastructure as code tools.

    The repository includes build scripts for both Windows and non-Windows developers. Windows does not natively support Makefiles. When using Windows, you can use either Windows Subsystem for Linux (WSL)Docker Desktop, or native PowerShell.

    When using Linux, macOS, WSL, or Docker, the Makefile builds the Lambda layers. After downloading the modules, it also extracts the additional AWS.Tools.S3 and AWS.Tools.EventBridge modules.

    # Download AWSToolsLayer module binaries
    curl -L -o $(ARTIFACTS_DIR)/AWS.Tools.zip https://sdk-for-net.amazonwebservices.com/ps/v4/latest/AWS.Tools.zip
    mkdir -p $(ARTIFACTS_DIR)/modules
    
    # Extract select AWS.Tools modules (AWS.Tools.Common required)
    unzip $(ARTIFACTS_DIR)/AWS.Tools.zip 'AWS.Tools.Common/**/*' -d $(ARTIFACTS_DIR)/modules/
    unzip $(ARTIFACTS_DIR)/AWS.Tools.zip 'AWS.Tools.S3/**/*' -d $(ARTIFACTS_DIR)/modules/
    unzip $(ARTIFACTS_DIR)/AWS.Tools.zip 'AWS.Tools.EventBridge/**/*' -d $(ARTIFACTS_DIR)/modules/

    When using native PowerShell on Windows to build the layer, the build-AWSToolsLayer.ps1 script performs the same file copy functionality as the Makefile. You can use this option for Windows without WSL or Docker.

    ### Extract entire AWS.Tools modules to stage area but only move over select modules
    …
    Move-Item "$PSScriptRoot\stage\AWS.Tools.Common" "$PSScriptRoot\modules\" -Force
    Move-Item "$PSScriptRoot\stage\AWS.Tools.S3" "$PSScriptRoot\modules\" -Force
    Move-Item "$PSScriptRoot\stage\AWS.Tools.EventBridge" "$PSScriptRoot\modules\" -Force

    The Lambda function code imports the required modules in the function init phase.

    Import-Module "AWS.Tools.Common"
    Import-Module "AWS.Tools.S3"
    Import-Module "AWS.Tools.EventBridge"

    For other combinations of AWS.Tools, amend the example build-AWSToolsLayer.ps1 scripts to add the modules you require. You can use a similar download and copy process, or PowerShell’s Save-Module to build layers for modules from other locations.

    Building and deploying the event-driven serverless application

    Follow the instructions in the GitHub repository to build and deploy the application.

    The demo application uses AWS SAM to deploy the following resources:

    1. PowerShell custom runtime.
    2. Additional Lambda layer containing the AWS.Tools.Common, AWS.Tools.S3, and AWS.Tools.EventBridge modules from AWS Tools for PowerShell. The layer ARN is stored in Parameter Store.
    3. S3 bucket to store CSV files.
    4. Lambda function triggered by S3 upload.
    5. Custom EventBridge event bus and rule to send events to CloudWatch Logs.

    Testing the event-driven application

    Use the AWS CLI or AWS Tools for PowerShell to copy the sample CSV file to S3. Replace BUCKET_NAME with your S3 SourceBucket Name from the AWS SAM outputs.

    AWS CLI

    aws s3 cp .\test.csv s3://BUCKET_NAME

    AWS Tools for PowerShell

    Write-S3Object -BucketName BUCKET_NAME -File .\test.csv

    The S3 file copy action generates an S3 notification event. This invokes the PowerShell Lambda function, passing the S3 file location details as part of the function $LambdaInput event object.

    The function downloads the S3 CSV file, parses the contents, and sends the individual lines to EventBridge, which logs the events to CloudWatch Logs.

    Navigate to the CloudWatch Logs group /aws/events/demo-s3-lambda-eventbridge.

    You can see the individual orders logged from the CSV file.

    EventBridge logs showing CSV lines

    EventBridge logs showing CSV lines

    Conclusion

    You can extend PowerShell Lambda applications to provide additional functionality.

    This post shows how to import your own or vendor PowerShell modules and explains how to build Lambda layers for the AWS Tools for PowerShell.

    You can also take advantage of the event-driven nature of Lambda to run Lambda functions in response to events. The demo application shows how a clothing printing company builds a PowerShell serverless application to manage its t-shirt size and color inventory.

    See the accompanying GitHub repository, which contains the code for the custom runtime, along with additional installation options and additional examples.

    Start running PowerShell on Lambda today.

    For more serverless learning resources, visit Serverless Land.

    Introducing the PowerShell custom runtime for AWS Lambda

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/introducing-the-powershell-custom-runtime-for-aws-lambda/

    The new PowerShell custom runtime for AWS Lambda makes it even easier to run Lambda functions written in PowerShell to process events. Using this runtime, you can run native PowerShell code in Lambda without having to compile code, which simplifies deployment and testing. You can also now view PowerShell code in the AWS Management Console, and have more control over function output and logging.

    Lambda has supported running PowerShell since 2018. However, the existing solution uses the .NET Core runtime implementation for PowerShell. It uses the additional AWSLambdaPSCore modules for deployment and publishing, which require compiling the PowerShell code into C# binaries to run on .NET. This adds additional steps to the development process.

    This blog post explains the benefits of using a custom runtime and information about the runtime options. You can deploy and run an example native PowerShell function in Lambda.

    PowerShell custom runtime benefits

    The new custom runtime for PowerShell uses native PowerShell, instead of compiling PowerShell and hosting it on the .NET runtime. Using native PowerShell means the function runtime environment matches a standard PowerShell session, which simplifies the development and testing process.

    You can now also view and edit PowerShell code within the Lambda console’s built-in code editor. You can embed PowerShell code within an AWS CloudFormation template, or other infrastructure as code tools.

    PowerShell code in Lambda console

    PowerShell code in Lambda console

    This custom runtime returns everything placed on the pipeline as the function output, including the output of Write-Output. This gives you more control over the function output, error messages, and logging. With the previous .NET runtime implementation, your function returns only the last output from the PowerShell pipeline.

    Building and packaging the custom runtime

    The custom runtime is based on Lambda’s provided.al2 runtime, which runs in an Amazon Linux environment. This includes AWS credentials from an AWS Identity and Access Management (IAM) role that you manage. You can build and package the runtime as a Lambda layer, or include it in a container image. When packaging as a layer, you can add it to multiple functions, which can simplify deployment.

    The runtime is based on the cross-platform PowerShell Core. This means that you can develop Lambda functions for PowerShell on Windows, Linux, or macOS.

    You can build the custom runtime using a number of tools, including the AWS Command Line Interface (AWS CLI), AWS Tools for PowerShell, or with infrastructure as code tools such as AWS CloudFormation, AWS Serverless Application Model (AWS SAM), Serverless Framework, and AWS Cloud Development Kit (AWS CDK).

    Showing the PowerShell custom runtime in action

    In the following demo, you learn how to deploy the runtime and explore how it works with a PowerShell function.

    The accompanying GitHub repository contains the code for the custom runtime, along with additional installation options and a number of examples.

    This demo application uses AWS SAM to deploy the following resources:

    1. PowerShell custom runtime based on provided.al2 as a Lambda layer.
    2. Additional Lambda layer containing the AWS.Tools.Common module from AWS Tools for PowerShell.
    3. Both layers store their Amazon Resource Names (ARNs) as parameters in AWS Systems Manager Parameter Store which can be referenced in other templates.
    4. Lambda function with three different handler options.

    To build the custom runtime and the AWS Tools for PowerShell layer for this example, AWS SAM uses a Makefile. This downloads the specified version of PowerShell from GitHub and the AWSTools.

    Windows does not natively support Makefiles. When using Windows, you can use either Windows Subsystem for Linux (WSL), Docker Desktop, or native PowerShell.

    Pre-requisites:

    Clone the repository and change into the example directory

    git clone https://github.com/awslabs/aws-lambda-powershell-runtime
    cd examples/demo-runtime-layer-function

    Use one of the following Build options, A, B, C, depending on your operating system and tools.

    A) Build using Linux or WSL

    Build the custom runtime, Lambda layer, and function packages using native Linux or WSL.

    sam build --parallel
    sam build --parallel

    sam build –parallel

    B) Build using Docker

    You can build the custom runtime, Lambda layer, and function packages using Docker. This uses a Linux-based Lambda-like Docker container to build the packages. Use this option for Windows without WSL or as an isolated Mac/Linux build environment.

    sam build --parallel --use-container
    sam build --parallel --use-container

    sam build –parallel –use-container

    C) Build using PowerShell for Windows

    You can use native PowerShell for Windows to download and extract the custom runtime and Lambda layer files. This performs the same file copy functionality as the Makefile. It adds the files to the source folders rather than a build location for subsequent deployment with AWS SAM. Use this option for Windows without WSL or Docker.

    .\build-layers.ps1
    Build layers using PowerShell

    Build layers using PowerShell

    Test the function locally

    Once the build process is complete, you can use AWS SAM to test the function locally.

    sam local invoke

    This uses a Lambda-like environment to run the function locally and returns the function response, which is the result of Get-AWSRegion.

    sam local invoke

    sam local invoke

    Deploying to the AWS Cloud

    Use AWS SAM to deploy the resources to your AWS account. Run a guided deployment to set the default parameters for the first deploy.

    sam deploy -g

    For subsequent deployments you can use sam deploy.

    Enter a Stack Name and accept the remaining initial defaults.

    AWS SAM deploy --g

    AWS SAM deploy –g

    AWS SAM deploys the infrastructure and outputs the details of the resources.

    AWS SAM resources

    AWS SAM resources

    View, edit, and invoke the function in the AWS Management Console

    You can view, edit code, and invoke the Lambda function in the Lambda Console.

    Navigate to the Functions page and choose the function specified in the sam deploy Outputs.

    Using the built-in code editor, you can view the function code.

    This function imports the AWS.Tools.Common module during the init process. The function handler runs and returns the output of Get-AWSRegion.

    To invoke the function, select the Test button and create a test event. For more information on invoking a function with a test event, see the documentation.

    You can see the results in the Execution result pane.

    Lambda console test

    Lambda console test

    You can also view a snippet of the generated Function Logs below the Response. View the full logs in Amazon CloudWatch Logs. You can navigate directly via the Monitor tab.

    Invoke the function using the AWS CLI

    From a command prompt invoke the function. Amend the --function-name and --region values for your function. This should return "StatusCode": 200 for a successful invoke.

    aws lambda invoke --function-name "aws-lambda-powershell-runtime-Function-6W3bn1znmW8G" --region us-east-1 invoke-result

    View the function results which are outputted to invoke-result.

    cat invoke-result
    cat invoke result

    cat invoke result

    Invoke the function using the AWS Tools for PowerShell

    You can invoke the Lambda function using the AWS Tools for PowerShell and capture the response in a variable. The response is available in the Payload property of the $Response object, which can be read using the .NET StreamReader class.

    $Response = Invoke-LMFunction -FunctionName aws-lambda-powershell-runtime-PowerShellFunction-HHdKLkXxnkUn -LogType Tail
    [System.IO.StreamReader]::new($Response.Payload).ReadToEnd()

    This outputs the result of AWS-GetRegion.

    Cleanup

    Use AWS SAM to delete the AWS resources created by this template.

    sam delete

    PowerShell runtime information

    Variables

    The runtime defines the following variables which are made available to the Lambda function.

    1. $LambdaInput: A PSObject that contains the Lambda function input event data.
    2. $LambdaContext: An object that provides methods and properties with information about the invocation, function, and runtime environment. For more information, see the GitHub repository.

    PowerShell module support

    You can include additional PowerShell modules either via a Lambda Layer, or within your function code package, or container image. Using Lambda layers provides a convenient way to package and share modules that you can use with your Lambda functions. Layers reduce the size of uploaded deployment archives and make it faster to deploy your code.

    The PSModulePath environment variable contains a list of folder locations that are searched to find user-supplied modules. This is configured during the runtime initialization. Folders are specified in the following order:

    1. Modules as part of function package in a /modules subfolder.
    2. Modules as part of Lambda layers in a /modules subfolder.
    3. Modules as part of the PowerShell custom runtime layer in a /modules subfolder.

    Lambda handler options

    There are three different Lambda handler formats supported with this runtime.

    <script.ps1>

    You provide a PowerShell script that is the handler. Lambda runs the entire script on each invoke.

    <script.ps1>::<function_name>

    You provide a PowerShell script that includes a PowerShell function name. The PowerShell function name is the handler. The PowerShell runtime dot-sources the specified <script.ps1>. This allows you to run PowerShell code during the function initialization cold start process. Lambda then invokes the PowerShell handler function <function_name>. On subsequent invokes using the same runtime environment, Lambda invokes only the handler function <function_name>.

    Module::<module_name>::<function_name>

    You provide a PowerShell module. You include a PowerShell function as the handler within the module. Add the PowerShell module using a Lambda Layer or by including the module in the Lambda function code package. The PowerShell runtime imports the specified <module_name>. This allows you to run PowerShell code during the module initialization cold start process. Lambda then invokes the PowerShell handler function <function_name> in a similar way to the <script.ps1>::<function_name> handler method.

    Function logging and metrics

    Lambda automatically monitors Lambda functions on your behalf and sends function metrics to Amazon CloudWatch. Your Lambda function comes with a CloudWatch Logs log group and a log stream for each instance of your function. The Lambda runtime environment sends details about each invocation to the log stream, and relays logs and other output from your function’s code. For more information, see the documentation.

    Output from Write-Host, Write-Verbose, Write-Warning, and Write-Error is written to the function log stream. The output from Write-Output is added to the pipeline, which you can use with your function response.

    Error handling

    The runtime can terminate your function because it ran out of time, detected a syntax error, or failed to marshal the response object into JSON.

    Your function code can throw an exception or return an error object. Lambda writes the error to CloudWatch Logs and, for synchronous invocations, also returns the error in the function response output.

    See the documentation on how to view Lambda function invocation errors for the PowerShell runtime using the Lambda console and the AWS CLI.

    Conclusion

    The PowerShell custom runtime for Lambda makes it even easier to run Lambda functions written in PowerShell.

    The custom runtime runs native PowerShell. You can view, and edit your code within the Lambda console. The runtime supports a number of different handler options, and you can include additional PowerShell modules.

    See the accompanying GitHub repository which contains the code for the custom runtime, along with installation options and a number of examples. Start running PowerShell on Lambda today.

    For more serverless learning resources, visit Serverless Land.

    Acknowledgements

    This custom runtime builds on the work of Norm Johanson, Kevin Marquette, Andrew Pearce, Jonathan Nunn, and Afroz Mohammed.

    Choosing the right solution for AWS Lambda external parameters

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/choosing-the-right-solution-for-aws-lambda-external-parameters/

    This post is written by Thomas Moore, Solutions Architect, Serverless.

    When using AWS Lambda to build serverless applications, customers often need to retrieve parameters from an external source at runtime. This allows you to share parameter values across multiple functions or microservices, providing a single source of truth for updates. A common example is retrieving database connection details from an external source and then using the retrieved hostname, user name, and password to connect to the database:

    Lambda function retrieving database credentials from an external source

    Lambda function retrieving database credentials from an external source

    AWS provides a number of options to store parameter data, including AWS Systems Manager Parameter Store, AWS AppConfig, Amazon S3, and Lambda environment variables. This blog explores the different parameter data that you may need to store. I cover considerations for choosing the right parameter solution and how to retrieve and cache parameter data efficiently within the Lambda function execution environment.

    Common use cases

    Common parameter examples include:

    • Securely storing secret data, such as credentials or API keys.
    • Database connection details such as hostname, port, and credentials.
    • Schema data (for example, a structured JSON response).
    • TLS certificate for mTLS or JWT validation.
    • Email template.
    • Tenant configuration in a multitenant system.
    • Details of external AWS resources to communicate with such as an Amazon SQS queue URL, Amazon EventBridge event bus name, or AWS Step Functions ARN.

    Key considerations

    There are a number of key considerations when choosing the right solution for external parameter data.

    1. Cost – how much does it cost to store the data and retrieve it via an API call?
    2. Security – what encryption and fine-grained access control is required?
    3. Performance – what are the retrieval latency requirements?
    4. Data size – how much data is there to store and retrieve?
    5. Update frequency – how often does the parameter change and how does the function handle stale parameters?
    6. Access scope – do multiple functions or services access the parameter?

    These considerations help to determine where to store the parameter data and how often to retrieve it.

    For example, a 4KB parameter that updates hourly and is used by hundreds of functions needs to be optimized for low retrieval costs and high performance. Choosing a solution that supports low-cost API GET requests at a high transaction per second (TPS) would be better than one that supports large data.

    AWS service options

    There are a number of AWS services available to store external parameter data.

    Amazon S3

    S3 is an object storage service offering 99.999999999% (11 9s) of data durability and virtually unlimited scalability at low cost. Objects can be up to 5 TB in size in any format, making S3 a good solution to store larger parameter data.

    Amazon DynamoDB

    Amazon DynamoDB is a fully managed, serverless, key-value NoSQL database designed for single-digit millisecond performance at any scale. Due to the high performance of this service, it’s a great place to store parameters when low retrieval latency is important.

    AWS Secrets Manager

    AWS Secrets Manager makes it easier to rotate, manage, and retrieve secret data. This makes it the ideal place to store sensitive parameters such as passwords and API keys.

    AWS Systems Manager Parameter Store

    Parameter Store provides a centralized store to manage configuration data. This data can be plaintext or encrypted using AWS Key Management Service (KMS). Parameters can be tagged and organized into hierarchies for simpler management. Parameter Store is a good default choice for general-purpose parameters in AWS. The standard version (no additional charge) can store parameters up to 4 KB in size and the advanced version (additional charges apply) up to 8 KB.

    For a code example using Parameter Store for Lambda parameters, see the Serverless Land pattern.

    AWS AppConfig

    AppConfig is a capability of AWS Systems Manager to create, manage, and quickly deploy application configurations. AppConfig allows you to validate changes during roll-outs and automatically roll back, if there is an error. AppConfig deployment strategies help to manage configuration changes safely.

    AppConfig also provides a Lambda extension to retrieve and locally cache configuration data. This results in fewer API calls and reduced function duration, reducing costs.

    AWS Lambda environment variables

    You can store parameter data as Lambda environment variables as part of the function’s version-specific configuration. Lambda environment variables are stored during function creation or updates. You can access these variables directly from your code without needing to contact an external source. Environment variables are ideal for parameter values that don’t need updating regularly and help make function code reusable across different environments. However, unlike the other options, values cannot be accessed centrally by multiple functions or services.

    Lambda execution lifecycle

    It is worth understanding the Lambda execution lifecycle, which has a number of stages. This helps to decide when to handle parameter retrieval within your Lambda code, including cache management.

    Lambda execution lifecycle

    Lambda execution lifecycle

    When a Lambda function is invoked for the first time, or when Lambda is scaling to handle additional requests, an execution environment is created. The first phase in the execution environment’s lifecycle is initialization (Init), during which the code outside the main handler function runs. This is known as a cold start.

    The execution environment can then be re-used for subsequent invocations. This means that the Init phase does not need to run again and only the main handler function code runs. This is known as a warm start.

    An execution environment can only run a single invocation at a time. Concurrent invocations require additional execution environments. When a new execution environment is required, this starts a new Init phase, which runs the cold start process.

    Caching and updates

    Retrieving the parameter during Init

    Retrieving the parameter during Init

    Retrieving the parameter during Init

    As Lambda execution environments are re-used, you can improve the performance and reduce the cost of retrieving an external parameter by caching the value. Writing the value to memory or the Lambda /tmp file system allows it to be available during subsequent invokes in the same execution environment.

    This approach reduces API calls, as they are not made during every invocation. However, this can cause an out-of-date parameter and potentially different values across concurrent execution environments.

    The following Python example shows how to retrieve a Parameter Store value outside the Lambda handler function during the Init phase.

    import boto3
    ssm = boto3.client('ssm', region_name='eu-west-1')
    parameter = ssm.get_parameter(Name='/my/parameter')
    def lambda_handler(event, context):
        # My function code...

    Retrieving the parameter on every invocation

    Retrieving the parameter on every invocation

    Retrieving the parameter on every invocation

    Another option is to retrieve the parameter during every invocation by making the API call inside the handler code. This keeps the value up to date, but can lead to higher retrieval costs and longer function durations due to the added API call during every invocation.

    The following Python example shows this approach:

    import boto3
    ssm = boto3.client('ssm', region_name='eu-west-1')
    def lambda_handler(event, context):
        parameter = ssm.get_parameter(Name='/my/parameter')
        # My function code...

    Using AWS AppConfig Lambda extension

    Using AWS AppConfig Lambda extension

    Using AWS AppConfig Lambda extension

    AppConfig allows you to retrieve and cache values from the service using a Lambda extension. The extension retrieves the values and makes them available via a local HTTP server. The Lambda function then queries the local HTTP server for the value. The AppConfig extension refreshes the values at a configurable poll interval, which defaults to 45 seconds. This improves performance and reduces costs, as the function only needs to make a local HTTP call.

    The following Python code example shows how to access the cached parameters.

    import urllib.request
    def lambda_handler(event, context):
        url = f'http://localhost:2772/applications/application_name/environments/environment_name/configurations/configuration_name'
        config = urllib.request.urlopen(url).read()
        # My function code...

    For caching secret values using a Lambda extension local HTTP cache and AWS Secrets Manager, see the AWS Prescriptive Guidance documentation.

    Using Lambda Powertools for Python or Java

    Lambda Powertools for Python or Lambda Powertools for Java contains utilities to manage parameter caching. You can configure the cache interval, which defaults to 5 seconds. Supported parameter stores include Secrets Manager, AWS Systems Manager Parameter Store, AppConfig, and DynamoDB. You also have the option to bring your own provider. The following example shows the Powertools for Python parameters utility retrieving a single value from Systems Manager Parameter Store.

    from aws_lambda_powertools.utilities import parameters
    def handler(event, context):
        value = parameters.get_parameter("/my/parameter")
        # My function code…

    Security

    Parameter security is a key consideration. You should evaluate encryption at rest, in-transit, private network access, and fine-grained permissions for each external parameter solution based on the use case.

    All services highlighted in this post support server-side encryption at rest, and you can choose to use AWS KMS to manage your own keys. When accessing parameters using the AWS SDK and CLI tools, connections are encrypted in transit using TLS by default. You can force most to use TLS 1.2.

    To access parameters from inside an Amazon Virtual Private Cloud (Amazon VPC) without internet access, you can use AWS PrivateLink and create a VPC endpoint for each service. All the services mentioned in this post support AWS PrivateLink connections.

    Use AWS Identity and Access Management (IAM) policies to manage which users or roles can access specific parameters.

    General guidance

    This blog explores a number of considerations to make when using an external source for Lambda parameters. The correct solution is use-case dependent. There are some general guidelines when selecting an AWS service.

    • For general-purpose low-cost parameters, use AWS Systems Manager Parameter Store.
    • For single function, small parameters, use Lambda environment variables.
    • For secret values that require automatic rotation, use AWS Secrets Manager.
    • When you need a managed cache, use the AWS AppConfig Lambda extension or Lambda Powertools for Python/Java.
    • For items larger than 400 KB, use Amazon S3.
    • When access frequency is high, and low latency is required, use Amazon DynamoDB.

    Conclusion

    External parameters provide a central source of truth across distributed systems, allowing for efficient updates and code reuse. This blog post highlights a number of considerations when using external parameters with Lambda to help you choose the most appropriate solution for your use case.

    Consider how you cache and reuse parameters inside the Lambda execution environment. Doing this correctly can help you reduce costs and improve the performance of your Lambda functions.

    There are a number of services to choose from to store parameter data. These include DynamoDB, S3, Parameter Store, Secrets Manager, AppConfig, and Lambda environment variables. Each comes with a number of advantages, depending on the use case. This blog guidance, along with the AWS documentation and Service Quotas, can help you select the most appropriate service for your workload.

    For more serverless learning resources, visit Serverless Land.

    Implementing mutual TLS for Java-based AWS Lambda functions

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/implementing-mutual-tls-for-java-based-aws-lambda-functions-2/

    This post is written by Dhiraj Mahapatro, Senior Specialist SA, Serverless and Christian Mueller, Principal Solutions Architect

    Modern secure applications establish network connections to other services through HTTPS. This ensures that the application connects to the right party and encrypts the data before sending it over the network.

    You might not want unauthenticated users to connect to your service as a service provider. One solution to this requirement is to use mutual TLS (Transport Layer Security). Mutual TLS (or mTLS) is a common security mechanism that uses client certificates to add an authentication layer. This allows the service provider to verify the client’s identity cryptographically.

    The purpose of mutual TLS in serverless

    mTLS refers to two parties authenticating each other at the same time when establishing a connection. By default, the TLS protocol only proves the identity of the server to a client using X.509 certificates. With mTLS, a client must prove its identity to the server to communicate. This helps support a zero-trust policy to protect against adversaries like man-in-the-middle attacks.

    mTLS is often used in business-to-business (B2B) applications and microservices, where interservice communication needs mutual authentication of parties. In Java, you see the following error when the server expects a certificate, but the client does not provide one:

    PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

    This blog post explains multiple ways to implement a Java-based AWS Lambda function that uses mTLS to authenticate with a third-party internal or external service. The sample application and this post explain the advantages and tradeoffs of each approach.

    The KeyStore and TrustStore in Java

    The TrustStore is used to store certificate public keys from a certificate authority (CA) or trusted servers. A client can verify the public certificate presented by the server in a TLS connection. A KeyStore stores private key and identity certificates that a specific application uses to prove the client’s identity.

    The stores contain opposite certificates. The TrustStore holds the identification certificates that identify others, while the KeyStore holds the identification certificates that identify itself.

    Overview

    To start, you create certificates. For brevity, this sample application uses a script that uses OpenSSL and Java’s keytool for self-signed certificates from a CA. You store the generated keys in Java KeyStore and TrustStore. However, the best practice for creating and maintaining certificates and private CA is to use AWS Certificate Manager and AWS Certificate Manager Private Certificate Authority.

    You can find the details of the script in the README file.

    The following diagram shows the use of KeyStore and TrustStore in the client Lambda function, and the server running on Fargate.

    KeyStore and TrustStore

    KeyStore and TrustStore

    The demo application contains several Lambda functions. The Lambda functions act as clients to services provided by Fargate behind an Amazon Network Load Balancer (NLB) running in a private Amazon VPC. Amazon Route 53 private hosted zones are used to resolve selected hostnames. You attach the Lambda functions to this VPC to resolve the hostnames for the NLB. To learn more, read how AWS Lambda uses Hyperplane elastic network interfaces to work with custom VPC.

    The following examples refer to portions of InfrastructureStack.java and the implementation in the corresponding Lambda functions.

    Providing a client certificate in a Lambda function artifact

    The first option is to provide the KeyStore and TrustStore in a Lambda functions’ .zip artifact. You provide specific Java environment variables within the Lambda configuration to instruct the JVM to load and trust your provided Keystore and TrustStore. The JVM uses these settings instead of the Java Runtime Environment’s (JRE) default settings (use a stronger password for your use case):

    "-Djavax.net.ssl.keyStore=./client_keystore_1.jks -Djavax.net.ssl.keyStorePassword=secret -Djavax.net.ssl.trustStore=./client_truststore.jks -Djavax.net.ssl.trustStorePassword=secret"

    The JRE uses this KeyStore and TrustStore to build a default SSLContext. The HttpClient uses this default SSLContext to create a TLS connection to the backend service running on Fargate.

    The following architecture diagram shows the sample implementation. It consists of an Amazon API Gateway endpoint with a Lambda proxy integration that calls a backend Fargate service running behind an NLB.

    Providing a client certificate in a Lambda function artifact

    Providing a client certificate in a Lambda function artifact

    This is a basic approach for a prototype. However, it has a few shortcomings related to security and separation of duties. The KeyStore contains the private key, and the password is exposed to the source code management (SCM) system, which is a security concern. Also, it is the Lambda function owner’s responsibility to update the certificate before its expiration. You can address these concerns about separation of duties with the following approach.

    Providing the client certificate in a Lambda layer

    In this approach, you separate the responsibility between two entities. The Lambda function owner and the KeyStore and TrustStore owner.

    The KeyStore and TrustStore owner provides the certificates securely to the function developer who may be working in a separate AWS environment. For simplicity, the demo application uses the same AWS account.

    The KeyStore and TrustStore owner achieves this by using AWS Lambda layers. The KeyStore and TrustStore owner packages and uploads the certificates as a Lambda layer and only allows access to authorized functions. The Lambda function owner does not access the KeyStore or manage its lifecycle. The KeyStore and TrustStore owner’s responsibility is to release a new version of this layer when necessary and inform users.

    Providing the client certificate in a Lambda layer

    Providing the client certificate in a Lambda layer

    The KeyStore and TrustStore are extracted under the path /opt as part of including a Lambda layer. The Lambda function can now use the layer as:

    Function lambdaLayerFunction = new Function(this, "LambdaLayerFunction", FunctionProps.builder()
      .functionName("lambda-layer")
      .handler("com.amazon.aws.example.AppClient::handleRequest")
      .runtime(Runtime.JAVA_11)
      .architecture(ARM_64)
      .layers(singletonList(lambdaLayerForService1cert))
      .vpc(vpc)
      .code(Code.fromAsset("../software/2-lambda-using-separate-layer/target/lambda-using-separate-layer.jar"))
      .memorySize(1024)
      .environment(Map.of(
        "BACKEND_SERVICE_1_HOST_NAME", BACKEND_SERVICE_1_HOST_NAME,
        "JAVA_TOOL_OPTIONS", "-Djavax.net.ssl.keyStore=/opt/client_keystore_1.jks -Djavax.net.ssl.keyStorePassword=secret -Djavax.net.ssl.trustStore=/opt/client_truststore.jks -Djavax.net.ssl.trustStorePassword=secret"
      ))
      .timeout(Duration.seconds(10))
      .logRetention(RetentionDays.ONE_WEEK)
      .build());
    

    The KeyStore and TrustStore passwords are still supplied as environment variables and stored in the SCM system, which is against best practices. You can address this with the next approach.

    Storing passwords securely in AWS Systems Manager Parameter Store

    AWS Systems Manager Parameter Store provides secure, hierarchical storage for configuration data and secret management. You can use Parameter Store to store the KeyStore and TrustStore passwords instead of environment variables. The Lambda function uses an IAM policy to access Parameter Store and gets the passwords as a secure string during the Lambda initialization phase.

    With this approach, you build a custom SSLContext after retrieving the KeyStore and TrustStore passwords from the Parameter Store. Once you create SSLContext, provide that to the HttpClient you use to connect with the backend service:

    HttpClient client = HttpClient.newBuilder()
      .version(HttpClient.Version.HTTP_2)
      .connectTimeout(Duration.ofSeconds(5))
      .sslContext(sslContext)
      .build();

    You can also use a VPC interface endpoint for AWS Systems Manager to keep the traffic from your Lambda function to Parameter Store internal to AWS. The following diagram shows the interaction between AWS Lambda and Parameter Store.

    Storing passwords securely in AWS Systems Manager Parameter Store

    Storing passwords securely in AWS Systems Manager Parameter Store

    This approach works for Lambda functions interacting with a single backend service requiring mTLS. However, it is common in a modern microservices architecture to integrate with multiple backend services. Sometimes, these services require a client to assume different identities by using different KeyStores. The next approach explains how to handle the multiple services scenario.

    Providing multiple client certificates in Lambda layers

    You can provide multiple KeyStore and TrustStore pairs within multiple Lambda layers. All layers attached to a function are merged when provisioning the function. Ensure your KeyStore and TrustStore names are unique. A Lambda function can use up to five Lambda layers.

    Similar to the previous approach, you load multiple KeyStores and TrustStores to construct multiple SSLContext objects. You abstract the common logic to create an SSLContext object in another Lambda layer. Now, the Lambda function calling two different backend services uses 3 Lambda layers:

    • Lambda layer for backend service 1 (under /opt)
    • Lambda layer for backend service 2 (under /opt)
    • Lambda layer for the SSL utility that takes the KeyStore, TrustStore, and their passwords to return an SSLContext object

    SSL utility Lambda layer provides the getSSLContext default method in a Java interface. The Lambda function implements this interface. Now, you create a dedicated HTTP client per service.

    The following diagram shows your final architecture:

    Providing multiple client certificates in Lambda layers

    Providing multiple client certificates in Lambda layers

    Prerequisites

    To run the sample application, you need:

    1. CDK v2
    2. Java 11
    3. AWS CLI
    4. Docker
    5. jq

    To build and provision the stack:

    1. Clone the git repository.
    2. git clone https://github.com/aws-samples/serverless-mutual-tls.git
      cd serverless-mutual-tls
    3. Create the two root CA’s, client, and server certificates.
    4. ./scripts/1-create-certificates.sh
    5. Build and package all examples.
    6. ./scripts/2-build_and_package-functions.sh
    7. Provision the AWS infrastructure (make sure that Docker is running).
    8. ./scripts/3-provision-infrastructure.sh

    Verification

    Verify that the API endpoints are working and using mTLS by running these commands from the base directory:

    export API_ENDPOINT=$(cat infrastructure/target/outputs.json | jq -r '.LambdaMutualTLS.apiendpoint')

    To see the error when mTLS is not used in the Lambda function, run:

    curl -i $API_ENDPOINT/lambda-no-mtls

    The preceding curl command responds with an HTTP status code 500 and plain body as:

    PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

    For successful usage of mTLS as shown in the previous use cases, run:

    curl -i $API_ENDPOINT/lambda-only
    curl -i $API_ENDPOINT/lambda-layer
    curl -i $API_ENDPOINT/lambda-parameter-store
    curl -i $API_ENDPOINT/lambda-multiple-certificates

    The last curl command responds with an HTTP status code 200 and body as:

    [
     {"hello": "from backend service 1"}, 
     {"hello": "from backend service 2"}
    ]
    

    Additional security

    You can add additional controls via Java environment variables. Compliance standards like PCI DSS in financial services require customers to exercise more control over the underlying negotiated protocol and ciphers.

    Some of the useful Java environment variables to troubleshoot SSL/TLS connectivity issues in a Lambda function are:

    -Djavax.net.debug=all
    -Djavax.net.debug=ssl,handshake
    -Djavax.net.debug=ssl:handshake:verbose:keymanager:trustmanager
    -Djavax.net.debug=ssl:record:plaintext

    You can enforce a specific minimum version of TLS (for example, v1.3) to meet regulatory requirements:

    -Dhttps.protocols=TLSv1.3

    Alternatively, programmatically construct your SSLContext inside the Lambda function:

    SSLContext sslContext = SSLContext.getInstance("TLSv1.3");

    You can also use the following Java environment variable to limit the use of weak cipher suites or unapproved algorithms, and explicitly provide the supported cipher suites:

    -Dhttps.cipherSuites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

    You achieve the same programmatically with the following code snippet:

    httpClient = HttpClient.newBuilder()
      .version(HttpClient.Version.HTTP_2)
      .connectTimeout(Duration.ofSeconds(5))
      .sslContext(sslContext)
      .sslParameters(new SSLParameters(new String[]{
        "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
        "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
        "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
        ………
      }))
      .build();

    Cleaning up

    The stack creates a custom VPC and other related resources. Clean up after usage to avoid the ongoing cost of running these services. To clean up the infrastructure and the self-generated certificates, run:

    ./scripts/4-delete-certificates.sh
    ./scripts/5-deprovision-infrastructure.sh

    Conclusion

    mTLS in Java using KeyStore and TrustStore is a well-established approach for using client certificates to add an authentication layer. This blog highlights the four approaches that you can take to implement mTLS using Java-based Lambda functions.

    Each approach addresses the separation of concerns required while implementing mTLS with additional security features. Use an approach that suits your needs, organizational security best practices, and enterprise requirements. Refer to the demo application for additional details.

    For more serverless learning resources, visit Serverless Land.

    Migrating AWS Lambda functions to Arm-based AWS Graviton2 processors

    Post Syndicated from Julian Wood original https://aws.amazon.com/blogs/compute/migrating-aws-lambda-functions-to-arm-based-aws-graviton2-processors/

    AWS Lambda now allows you to configure new and existing functions to run on Arm-based AWS Graviton2 processors in addition to x86-based functions. Using this processor architecture option allows you to get up to 34% better price performance. This blog post highlights some considerations when moving from x86 to arm64 as the migration process is code and workload dependent.

    Functions using the Arm architecture benefit from the performance and security built into the Graviton2 processor, which is designed to deliver up to 19% better performance for compute-intensive workloads. Workloads using multithreading and multiprocessing, or performing many I/O operations, can experience lower invocation time, which reduces costs.

    Duration charges, billed with millisecond granularity, are 20 percent lower when compared to current x86 pricing. This also applies to duration charges when using Provisioned Concurrency. Compute Savings Plans supports Lambda functions powered by Graviton2.

    The architecture change does not affect the way your functions are invoked or how they communicate their responses back. Integrations with APIs, services, applications, or tools are not affected by the new architecture and continue to work as before.

    The following runtimes, which use Amazon Linux 2, are supported on Arm:

    • Node.js 12 and 14
    • Python 3.8 and 3.9
    • Java 8 (java8.al2) and 11
    • .NET Core 3.1
    • Ruby 2.7
    • Custom runtime (provided.al2)

    [email protected] does not support Arm as an architecture option.

    You can create and manage Lambda functions powered by Graviton2 processor using the AWS Management Console, AWS Command Line Interface (AWS CLI), AWS CloudFormation, AWS Serverless Application Model (AWS SAM), and AWS Cloud Development Kit (AWS CDK). Support is also available through many AWS Lambda Partners.

    Understanding Graviton2 processors

    AWS Graviton processors are custom built by AWS. Generally, you don’t need to know about the specific Graviton processor architecture, unless your applications can benefit from specific features.

    The Graviton2 processor uses the Neoverse-N1 core and supports Arm V8.2 (include CRC and crypto extensions) plus several other architectural extensions. In particular, Graviton2 supports the Large System Extensions (LSE), which improve locking and synchronization performance across large systems.

    Migrating x86 Lambda functions to arm64

    Many Lambda functions may only need a configuration change to take advantage of the price/performance of Graviton2. Other functions may require repackaging the Lambda function using Arm-specific dependencies, or rebuilding the function binary or container image.

    You may not require an Arm processor on your development machine to create Arm-based functions. You can build, test, package, compile, and deploy Arm Lambda functions on x86 machines using AWS SAM and Docker Desktop. If you have an Arm-based system, such as an Apple M1 Mac, you can natively compile binaries.

    Functions without architecture-specific dependencies or binaries

    If your functions don’t use architecture-specific dependencies or binaries, you can switch from one architecture to the other with a single configuration change. Many functions using interpreted languages such as Node.js and Python, or functions compiled to Java bytecode, can switch without any changes. Ensure you check binaries in dependencies, Lambda layers, and Lambda extensions.

    To switch functions from x86 to arm64, you can change the Architecture within the function runtime settings using the Lambda console.

    Edit AWS Lambda function Architecture

    Edit AWS Lambda function Architecture

    If you want to display or log the processor architecture from within a Lambda function, you can use OS specific calls. For example, Node.js process.arch or Python platform.machine().

    When using the AWS CLI to create a Lambda function, specify the --architectures option. If you do not specify the architecture, the default value is x86-64. For example, to create an arm64 function, specify --architectures arm64.

    aws lambda create-function \
        --function-name MyArmFunction \
        --runtime nodejs14.x \
        --architectures arm64 \
        --memory-size 512 \
        --zip-file fileb://MyArmFunction.zip \
        --handler lambda.handler \
        --role arn:aws:iam::123456789012:role/service-role/MyArmFunction-role
    

    When using AWS SAM or CloudFormation, add or amend the Architectures property within the function configuration.

    MyArmFunction:
      Type: AWS::Lambda::Function
      Properties:
        Runtime: nodejs14.x
        Code: src/
        Architectures:
      	- arm64
        Handler: lambda.handler
        MemorySize: 512

    When initiating an AWS SAM application, you can specify:

    sam init --architecture arm64

    When building Lambda layers, you can specify CompatibleArchitectures.

    MyArmLayer:
      Type: AWS::Lambda::LayerVersion
      Properties:
        ContentUri: layersrc/
        CompatibleArchitectures:
          - arm64
    

    Building function code for Graviton2

    If you have dependencies or binaries in your function packages, you must rebuild the function code for the architecture you want to use. Many packages and dependencies have arm64 equivalent versions. Test your own workloads against arm64 packages to see if your workloads are good migration candidates. Not all workloads show improved performance due to the different processor architecture features.

    For compiled languages like Rust and Go, you can use the provided.al2 custom runtime, which supports Arm. You provide a binary that communicates with the Lambda Runtime API.

    When compiling for Go, set GOARCH to arm.

    GOOS=linux GOARCH=arm go build

    When compiling for Rust, set the target.

    cargo build --release -- target-cpu=neoverse-n1

    The default installation of Python pip on some Linux distributions is out of date (<19.3). To install binary wheel packages released for Graviton, upgrade the pip installation using:

    sudo python3 -m pip install --upgrade pip

    The Arm software ecosystem is continually improving. As a general rule, use later versions of compilers and language runtimes whenever possible. The AWS Graviton Getting Started GitHub repository includes known recent changes to popular packages that improve performance, including ffmpeg, PHP, .Net, PyTorch, and zlib.

    You can use https://pkgs.org/ as a package repository search tool.

    Sometimes code includes architecture specific optimizations. These can include code optimized in assembly using specific instructions for CRC, or enabling a feature that works well on particular architectures. One way to see if any optimizations are missing for arm64 is to search the code for __x86_64__ ifdefs and see if there is corresponding arm64 code included. If not, consider alternative solutions.

    For additional language-specific considerations, see the links within the GitHub repository.

    The Graviton performance runbook is a performance profiling reference by the Graviton to benchmark, debug, and optimize application code.

    Building functions packages as container images

    Functions packaged as container images must be built for the architecture (x86 or arm64) they are going to use. There are arm64 architecture versions of the AWS provided base images for Lambda. To specify a container image for arm64, use the arm64 specific image tag, for example, for Node.js 14:

    • public.ecr.aws/lambda/nodejs:14-arm64
    • public.ecr.aws/lambda/nodejs:latest-arm64
    • public.ecr.aws/lambda/nodejs:14.2021.10.01.16-arm64

    Arm64 Images are also available from Docker Hub.

    You can also use arbitrary Linux base images in addition to the AWS provided Amazon Linux 2 images. Images that support arm64 include Alpine Linux 3.12.7 or later, Debian 10 and 11, Ubuntu 18.04 and 20.04. For more information and details of other supported Linux versions, see Operating systems available for Graviton based instances.

    Migrating a function

    Here is an example of how to migrate a Lambda function from x86 to arm64 and take advantage of newer software versions to improve price and performance. You can follow a similar approach to test your own code.

    I have an existing Lambda function as part of an AWS SAM template configured without an Architectures property, which defaults to x86_64.

      Imagex86Function:
        Type: AWS::Serverless::Function
        Properties:
          CodeUri: src/
          Handler: app.lambda_handler
          Runtime: python3.9

    The Lambda function code performs some compute intensive image manipulation. The code uses a dependency configured with the following version:

    {
      "dependencies": {
        "imagechange": "^1.1.1"
      }
    }

    I duplicate the Lambda function within the AWS SAM template using the same source code and specify arm64 as the Architectures.

      ImageArm64Function:
        Type: AWS::Serverless::Function
        Properties:
          CodeUri: src/
          Handler: app.lambda_handler
          Runtime: python3.9
          Architectures:
            - arm64

    I use AWS SAM to build both Lambda functions. I specify the --use-container flag to build each function within its architecture-specific build container.

    sam build –use-container

    I can use sam local invoke to test the arm64 function locally even on an x86 system.

    AWS SAM local invoke

    AWS SAM local invoke

    I then use sam deploy to deploy the functions to the AWS Cloud.

    The AWS Lambda Power Tuning open-source project runs your functions using different settings to suggest a configuration to minimize costs and maximize performance. The tool allows you to compare two results on the same chart and incorporate arm64-based pricing. This is useful to compare two versions of the same function, one using x86 and the other arm64.

    I compare the performance of the X86 and arm64 Lambda functions and see that the arm64 Lambda function is 12% cheaper to run:

    Compare x86 and arm64 with dependency version 1.1.1

    Compare x86 and arm64 with dependency version 1.1.1

    I then upgrade the package dependency to use version 1.2.1, which has been optimized for arm64 processors.

    {
      "dependencies": {
        "imagechange": "^1.2.1"
      }
    }

    I use sam build and sam deploy to redeploy the updated Lambda functions with the updated dependencies.

    I compare the original x86 function with the updated arm64 function. Using arm64 with a newer dependency code version increases the performance by 30% and reduces the cost by 43%.

    Compare x86 and arm64 with dependency version 1.2.1

    Compare x86 and arm64 with dependency version 1.2.1

    You can use Amazon CloudWatch,to view performance metrics such as duration, using statistics. You can then compare average and p99 duration between the two architectures. Due to the Graviton2 architecture, functions may be able to use less memory. This could allow you to right-size function memory configuration, which also reduces costs.

    Deploying arm64 functions in production

    Once you have confirmed your Lambda function performs successfully on arm64, you can migrate your workloads. You can use function versions and aliases with weighted aliases to control the rollout. Traffic gradually shifts to the arm64 version or rolls back automatically if any specified CloudWatch alarms trigger.

    AWS SAM supports gradual Lambda deployments with a feature called Safe Lambda deployments using AWS CodeDeploy. You can compile package binaries for arm64 using a number of CI/CD systems. AWS CodeBuild supports building Arm based applications natively. CircleCI also has Arm compute resource classes for deployment. GitHub Actions allows you to use self-hosted runners. You can also use AWS SAM within GitHub Actions and other CI/CD pipelines to create arm64 artifacts.

    Conclusion

    Lambda functions using the Arm/Graviton2 architecture provide up to 34 percent price performance improvement. This blog discusses a number of considerations to help you migrate functions to arm64.

    Many functions can migrate seamlessly with a configuration change, others need to be rebuilt to use arm64 packages. I show how to migrate a function and how updating software to newer versions may improve your function performance on arm64. You can test your own functions using the Lambda PowerTuning tool.

    Start migrating your Lambda functions to Arm/Graviton2 today.

    For more serverless learning resources, visit Serverless Land.