Lambda: Support for Lambda Structured Logging and Apple container

Server
1

The last two releases bring two additional capabilities

  1. JSON Structured Logging
  2. Use Apple container for cross compilation

JSON Structured Logging

JSON structured logging lets CloudWatch capture your Lambda logs as searchable key-value pairs instead of plain text, making it significantly easier to filter, query, and debug in production. It also enables you to attach metadata and contextual information (like request IDs or error codes) to each log entry, which is essential for automated analysis at scale. This is especially relevant since Lambda Managed Instances only support JSON log format — so this release brings the Swift runtime in line with that requirement.

Example of log entry:

{
    "message": "Server started and listening",
    "requestId": "N\/A",
    "level": "INFO",
    "timestamp": "2026-02-24T18:43:11.688Z",
    "metadata": {
        "port": "7000",
        "host": "\"127.0.0.1\""
    },
    "traceId": "N\/A",
    "file": "AWSLambdaRuntime\/Lambda+LocalServer.swift",
    "function": "withLocalServer(host:port:invocationEndpoint:eventLoopGroup:logger:_:)",
    "line": 168
}

There is nothing to change in your code to activate JSON Structured logging, this is a configuration at the function level either in the console, your IaC code, or the CLI when you create or update a function. Behind the scene, the Lambda service sets AWS_LAMBDA_LOG_FORMAT=JSON. Similarly, you can control the log level directly from the console or your IaC code.

We added an example in Examples/JSONLogging:

      LoggingConfig:
        LogFormat: JSON
        ApplicationLogLevel: DEBUG
        SystemLogLevel: INFO

The old behaviour of text-based logging and verbosity control through the LOG_LEVEL environment variable is preserved. This is a purely additive change.

Learn more about Lambda Structured Logging in the doc: Configuring JSON and plain text log formats - AWS Lambda

Support Apple Container on macOS

We added experimental support for cross compilation with Apple container, as a replacement for Docker. On macOS, you can configure the archive plugin to work with container with the new --conatiner-cli command line argument:

swift package --disable-sandbox \
              --allow-network-connections docker \
              archive \
              --container-cli container

A couple of things to note:

  1. docker is the default. There is no change in existing behaviour.
  2. container CLI uses macOS' XPC to communicate with the container server. This requires to disable the SPM sandbox entirely
  3. Due to a small issue on SPM, you have to specify both --disable-sandbox and --allow-network-connections docker (specified in Package.swift). The issue is already fixed but we were too late to land it in Swift 6.3. I hope it will land in a follow up release soon after 6.3.

Acknowledgements

I'd like to thank @manojmahapatra and @benrosen78 for their contributions on these two new capabilities.

What's Changed

SemVer Minor

SemVer Patch

Other Changes

Full Changelog: https://github.com/awslabs/swift-aws-lambda-runtime/compare/2.7.0...2.8.0

3 Likes
2

Thank you very much, this is going to make dealing with logs a lot easier.

Not 100% related but also thanks for the SSOCredentialProvider you recently contributed to Soto. That's also going to make it easier to run our different environments locally by relying on the SSO credentials and not having to switch between AWS accounts manually.

1 Like
3

Thank you for the message!

Indeed, I contributed to add a LoginCredentialProvider and SSOCredentialProvider on Soto-Core.

This allows Swift applications to pickup credentials and to refresh them on machines configured with AWS Identity Center (aws sso login) or where you use the new aws login CLI to acquire temporary credentials based on your web session.

I use these in my command line tools

1 Like