This project provides various extensions to Micronaut for Amazon Web Services (AWS).

A base AWSClientConfiguration is provided which can be used as a base configuration class for any configuration that needs to configure an AWS SDK client.

For this project, you can find a list of releases (with release notes) here:

Micronaut AWS 2.0.0 contains improvements to ease the creation of Alexa Skills with Micronaut:

Check the Alexa section to learn more.

See the section Breaking Changes to ease into the migration to Micronaut AWS 2.x

Micronaut is verified to run on Amazon Corretto.

To use the AWS SDK v1, add the following dependency:

When working with AWS SDK, you may need to provide a com.amazonaws.auth.AWSCredentialsProvider. To ease that this module provides a utility class: EnvironmentAWSCredentialsProvider.

For example the following snippet show how you may configure a S3 Client if you set two environment variables:

Read about externalized Configuration with property sources in Micronaut.

To use the AWS SDK v2, add the following dependency:

By default, the AWS SDK v2 will pull transitively both the Netty (async) and Apache HTTP (sync) clients. If you wish to use a client based on the JVM’s lightweight URLConnection, you should configure it as explained below.

To use an S3 client, add the following dependency:

Then, the following beans will be created:

And:

The HTTP client, credentials and region will be configured as per described in the SDK v2 documentation.

Additionally, this service accepts the following configuration properties:

To use a DynamoDb client, add the following dependency:

Then, the following beans will be created:

And:

The HTTP client, credentials and region will be configured as per described in the SDK v2 documentation.

To use a SES client, add the following dependency:

Then, the following beans will be created:

And:

The HTTP client, credentials and region will be configured as per described in the SDK v2 documentation.

To use a SNS client, add the following dependency:

Then, the following beans will be created:

And:

The HTTP client, credentials and region will be configured as per described in the SDK v2 documentation.

To use a SQS client, add the following dependency:

Then, the following beans will be created:

And:

The HTTP client, credentials and region will be configured as per described in the SDK v2 documentation.

For advanced configuration options that are not suitable to provide via application.yml, you can declare a BeanCreatedEventListener bean that listens for builder bean creations, and apply any further customisation there:

Since the list of services offered by AWS is huge, you can write your own client support and leverage the foundation classes that support the services supported by Micronaut.

To do so, you would create a @Factory class that would get injected some other beans to do its job.

For example, to create a client for AWS Rekognition:

There are several ways to create Micronaut AWS Lambda functions.

In Micronaut Launch, you can select the feature aws-lambda for applications of type Application or Serverless Function. Those application types have their CLI equivalents commands.

To deploy a AWS Lambda function you have to:

The above decisions influence the type of Micronaut application you choose.

To deploy a Micronaut function to AWS Lambda you have to choose a AWS Lambda Runtime. For Micronaut functions, you select a Java (8 or 11) or custom runtime. To deploy your Micronaut function as a GraalVM Native Image you need to select a custom runtime.

Depending on your application type and runtime, you need different dependencies:

micronaut-function-aws-api-proxy has a transitive dependency to micronaut-function-aws.

The previous set of artifacts have a group id of io.micronaut.aws.

Micronaut CLI or Launch will include the necessary dependencies when you select the aws-lambda feature or both aws-lambda and graalvm features.

AWS Lambda integrates with other AWS services to invoke functions. The Micronaut application type you select depends on the triggers you want to support. To respond to incoming HTTP requests (e.g. AWS Lambda Proxy integrations in API Gateway) you can choose either Application or Serverless Function. For other triggers, such as consuming events from a queue, or run on a schedule you will choose Serverless Function.

On the one hand, if you need to support a single endpoint a Serverless Function gives you a function with less code (which translates to a faster cold startup).

On the other hand, functions written as an application of type Application allows you to code with a more familiar paradigm - Classes annotated with @Controller. That it is possible because, through the micronaut-function-aws-api-proxy dependency, Micronaut integrates with the AWS Serverless Java Container project.

AWS Lambda Function Handler

The aws-lambda-java-core library defines two interfaces for handler methods. When coding your functions with Micronaut you don’t implement those interfaces directly. Instead you extend or use its Micronaut equivalents:

For functions of type Application, use the handler MicronautLambdaHandler.

To resolve that class you need to add the micronaut-function-aws-api-proxy dependency to your build.

For Serverless Functions the decision to use one MicronautRequestHandler or MicronautRequestStreamHandler depends on how you want to handle the input and output types.

To resolve those classes you need to add the micronaut-function-aws dependency to your build.

With MicronautRequestHandler, it is expected that you supply generic types with the input and the output types. If you wish to work with raw streams then subclass MicronautRequestStreamHandler instead.

Instances of Lambdas are added and removed dynamically. When a new instance handles its first request, the response time increases, which is called a cold start. After that request is processed, the instance stays alive (≈10 m) to be reused for subsequent requests.

Lambdas execution have different phases (Initialization, Invocation…​).

During the initialization phase:

The intialization phase has access to more CPU because of that Micronaut starts the application context and eagerly inits singletons during the intialization of the handler class.

GraalVM is a universal virtual machine which allows to compile Java programs to native executables.

The introduction of AWS Lambda custom runtimes enables cold startup improvements for Java applications running in AWS Lambda.

Micronaut’s dependency micronaut-function-aws-custom-runtime eases the creation of AWS Lambda Custom runtime to execute a Micronaut function.

The main API you will interact with is AbstractMicronautLambdaRuntime. An abstract class which you can extend to create your custom runtime mainClass. That class includes the necessary code to perform the Processing Tasks described in the Custom Runtime documentation.

When you generate a project with Micronaut CLI or Micronaut Launch with aws-lambda and graalvm features, the output includes the necessary files to generate a ZIP file to distribute your functions as a GraalVM Native Image executed from a AWS Lambda custom runtime.

Check the step-by-step tutorials to get you started:

The Micronaut’s aws-alexa module simplifies development of Alexa Skills with Java, Kotlin or Groovy.

To create the sample skill described in Amazon Documentation - Develop your first skill with Micronaut’s Alexa you will write the same LaunchRequestHandler, HelloWorldIntent, HelpIntent, CancelandStopHandler, FallbackIntentHandler, SessionEndedRequestHandler handlers.

You will do just one change, you will annotate those handlers with javax.inject.Singleton.

Typically, the next step will be to provide an instance of AlexaSkillConfiguration. The easiest way to do that is to configure the skill id via configuration:

Micronaut’s alexa module provides by default StandardSkillBuilderProvider which creates an SDK instance using the Skills.standard builder. You can provide your own implementation of Micronaut’s SkillBuilderProvider.

For each AlexaSkillConfiguration bean, Micronaut uses the builder provided by [SkillBuilderProvider to create for you a bean of type AlexaSkill for you and wires up the beans of the following types:

Micronaut Alexa ships with a Speech Systhesys Markup Language builder.

To simplify the programming model Micronaut AWS includes a @IntentHandler annotation that can be used on any bean method to make the method an intent handler.

A typical Alexa application written in Micronaut looks like:

Micronaut simplifies hosting a Custom Skill as a Web Service.

The micronaut-aws-webservice is a fork of Amazon Servlet module. It allow you to run your Alexa Skill backend logic in Micronaut applications deployed with a netty or servlet runtimes.

Just by including the dependency:

you get an POST endpoint at /alexa (the route is configurable via alexa.endpoint.path.

You can configure your Skill’s endpoint under Build/Endpoint in the Alexa developer console.

The micronaut-function-aws-alexa module includes support for building deploying an Alexa Skill as a Lambda Function.

As handler specify io.micronaut.function.aws.alexa.AlexaFunction. You don’t need to create a class which extends SkillStreamHandler, AlexaFunction takes care of adding request handlers interceptors etc.

Micronaut’s eases the creation of Flash Briefing Skills.

Your application must expose an endpoint which returns a JSON Array of FlashBriefingItem

You can find the source code of this project in this repository:

https://github.com/micronaut-projects/micronaut-aws