By Version

AWS Lambda

La extensión quarkus-amazon-lambda le permite utilizar Quarkus para construir sus AWS Lambdas. Tus lambdas pueden utilizar anotaciones de inyección de CDI o Spring y otras facilidades de Quarkus según las necesites.

Quarkus lambdas can be deployed using the Amazon Java Runtime, or you can build a native executable and use Amazon’s Custom Runtime if you want a smaller memory footprint and faster cold boot startup time.

Quarkus’s integration with lambdas also supports Quarkus’s Live Coding development cycle. You can bring up your Quarkus lambda project in dev or test mode and code on your project live.

Prerequisites

To complete this guide, you need:

Roughly 30 minutes
An IDE
JDK 11+ installed with JAVA_HOME configured appropriately
Apache Maven 3.9.5
Optionally the Quarkus CLI if you want to use it
Optionally Mandrel or GraalVM installed and configured appropriately if you want to build a native executable (or Docker if you use a native container build)
An Amazon AWS account
AWS CLI
AWS SAM CLI, for local testing

For Gradle projects please see below, or for further reference consult the guide in the Gradle setup page.

Getting Started

This guide walks you through generating an example Java project via a maven archetype and deploying it to AWS.

Installing AWS bits

Instalar todos los bits de AWS es probablemente lo más difícil de esta guía. Asegúrate de seguir todos los pasos para instalar AWS CLI.

Creating the Maven Deployment Project

Create the Quarkus AWS Lambda maven project using our Maven Archetype.

mvn archetype:generate \
       -DarchetypeGroupId=io.quarkus \
       -DarchetypeArtifactId=quarkus-amazon-lambda-archetype \
       -DarchetypeVersion=3.6.0

If you prefer to use Gradle, you can quickly and easily generate a Gradle project via code.quarkus.io adding the quarkus-amazon-lambda extension as a dependency.

Copy the build.gradle, gradle.properties and settings.gradle into the above-generated Maven archetype project, to follow along with this guide.

Execute: gradle wrapper to set up the gradle wrapper (recommended).

For full Gradle details, see the Gradle build section below.

Choose Your Lambda

The quarkus-amazon-lambda extension scans your project for a class that directly implements the Amazon RequestHandler<?, ?> or RequestStreamHandler interface. It must find a class in your project that implements this interface, or it will throw a build time failure. If it finds more than one handler class, a build time exception will also be thrown.

A veces, sin embargo, puedes tener unas cuantas lambdas relacionadas que comparten código y crear múltiples módulos de maven es una sobrecarga que no quieres hacer. La extensión quarkus-amazon-lambda te permite agrupar múltiples lambdas en un proyecto y utilizar la configuración o una variable de entorno para elegir el manejador que quieres desplegar.

El proyecto generado tiene tres lambdas dentro de él. Dos que implementan la interfaz RequestHandler<?, ?>, y una que implementa la interfaz RequestStreamHandler. Una que se usa y dos que no se usan. Si abres src/main/resources/application.properties verás esto:

quarkus.lambda.handler=test

The quarkus.lambda.handler property tells Quarkus which lambda handler to deploy. This can be overridden with an environment variable too.

If you look at the three generated handler classes in the project, you’ll see that they are @Named differently.

@Named("test")
public class TestLambda implements RequestHandler<InputObject, OutputObject> {
}

@Named("unused")
public class UnusedLambda implements RequestHandler<InputObject, OutputObject> {
}

@Named("stream")
public class StreamLambda implements RequestStreamHandler {
}

El nombre CDI de la clase manejadora debe coincidir con el valor especificado en la propiedad quarkus.lambda.handler.

Deploy to AWS Lambda Java Runtime

Hay algunos pasos para conseguir que su lambda se ejecute en AWS. El proyecto maven generado contiene un script útil para crear, actualizar, eliminar e invocar sus lambdas para implementaciones puramente Java y nativas.

Build and Deploy

Build the project:

CLI

quarkus build

Maven

./mvnw install

Gradle

./gradlew build

This will compile and package your code.

Create an Execution Role

Consulte la Guía de inicio para implementar un lambda con AWS CLI. Específicamente, asegúrese de haber creado un Execution Role. Tendrá que definir una variable de entorno LAMBDA_ROLE_ARN en su perfil o ventana de consola, alternativamente, puede editar el script manage.sh que es generado por la construcción y poner el valor del rol directamente allí:

LAMBDA_ROLE_ARN="arn:aws:iam::1234567890:role/lambda-role"

Extra Build Generated Files

After you run the build, there are a few extra files generated by the quarkus-amazon-lambda extension. These files are in the build directory: target/ for maven, build/ for gradle.

function.zip - lambda deployment file
manage.sh - wrapper around aws lambda cli calls
bootstrap-example.sh - example bootstrap script for native deployments
sam.jvm.yaml - (optional) for use with sam cli and local testing
sam.native.yaml - (optional) for use with sam cli and native local testing

Create the function

El script target/manage.sh es para administrar su lambda utilizando el tiempo de ejecución de AWS Lambda Java. Este script se proporciona sólo para su comodidad. Examine la salida del script manage.sh si desea saber qué comandos de aws se ejecutan para crear, eliminar y actualizar sus lambdas.

manage.sh supports four operation: create, delete, update, and invoke.

To verify your setup, that you have the AWS CLI installed, executed aws configure for the AWS access keys, and set up the LAMBDA_ROLE_ARN environment variable (as described above), please execute manage.sh without any parameters. A usage statement will be printed to guide you accordingly.

If using Gradle, the path to the binaries in the manage.sh must be changed from target to build

Para ver la declaración usage, y validar la configuración de AWS:

sh target/manage.sh

Puede crear su función utilizando el siguiente comando, create :

sh target/manage.sh create

or if you do not have LAMBDA_ROLE_ARN already defined in this shell:

LAMBDA_ROLE_ARN="arn:aws:iam::1234567890:role/lambda-role" sh target/manage.sh create

No cambie el switch del manejador. Esto debe ser codificado en io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest. Este manejador arranca Quarkus y envuelve su manejador real para que la inyección pueda ser realizada.

Si hay algún problema en la creación de la función, debe borrarla con la función delete antes de volver a ejecutar el comando create.

sh target/manage.sh delete

Commands may also be stacked:

sh target/manage.sh delete create

Invoke the Lambda

Use the invoke command to invoke your function.

sh target/manage.sh invoke

The example lambda takes input passed in via the --payload switch which points to a json file in the root directory of the project.

The lambda can also be invoked locally with the SAM CLI like this:

sam local invoke --template target/sam.jvm.yaml --event payload.json

If you are working with your native image build, simply replace the template name with the native version:

sam local invoke --template target/sam.native.yaml --event payload.json

Update the Lambda

Puedes actualizar el código Java como creas conveniente. Una vez que hayas reconstruido, puedes volver a desplegar tu lambda ejecutando el comando update.

sh target/manage.sh update

Deploy to AWS Lambda Custom (native) Runtime

If you want a lower memory footprint and faster initialization times for your lambda, you can compile your Java code to a native executable. Just make sure to rebuild your project with the -Dnative switch.

For Linux hosts, execute:

CLI

quarkus build --native

Maven

./mvnw install -Dnative

Gradle

./gradlew build -Dquarkus.package.type=native

Si estás construyendo en un sistema que no es Linux, tendrás que pasar también una propiedad que indique a Quarkus que utilice una construcción docker, ya que Amazon Lambda requiere binarios linux. Puedes hacerlo pasando esta propiedad a tu construcción: -Dquarkus.native.container-build=true. Sin embargo, esto requiere que tengas Docker instalado localmente.

CLI

quarkus build --native --no-tests -Dquarkus.native.container-build=true
# The --no-tests flag is required only on Windows and macOS.

Maven

./mvnw install -Dnative -DskipTests -Dquarkus.native.container-build=true

Gradle

./gradlew build -Dquarkus.package.type=native -Dquarkus.native.container-build=true

Cualquiera de estos comandos compilará y creará una imagen ejecutable nativa. También genera un archivo zip target/function.zip. Este archivo zip contiene su imagen ejecutable nativa renombrada a bootstrap. Este es un requisito del tiempo de ejecución personalizado (proporcionado) de AWS Lambda.

Las instrucciones son exactamente las mismas que las anteriores con un cambio: tendrá que añadir native como primer parámetro del script manage.sh:

sh target/manage.sh native create

Como en el caso anterior, los comandos se pueden apilar. El único requisito es que native sea el primer parámetro si desea trabajar con construcciones de imágenes nativas. El script se encargará del resto de los detalles necesarios para gestionar sus despliegues de funciones de imagen nativa.

Examine the output of the manage.sh script if you want to learn what aws commands are executed to create, delete, and update your lambdas.

One thing to note about the create command for native is that the aws lambda create-function call must set a specific environment variable:

--environment 'Variables={DISABLE_SIGNAL_HANDLERS=true}'

Examine the POM and Gradle build

No hay nada especial en el POM, aparte de la inclusión de la extensión quarkus-amazon-lambda como dependencia. La extensión genera automáticamente todo lo que puedas necesitar para tu despliegue de lambda.

In previous versions of this extension, you had to set up your pom or gradle to zip up your executable for native deployments, but this is not the case anymore.

Construcción de Gradle

Similarly, for Gradle projects, you also just have to add the quarkus-amazon-lambda dependency. The extension automatically generates everything you might need for your lambda deployment.

Example Gradle dependencies:

dependencies {
    implementation enforcedPlatform("${quarkusPlatformGroupId}:${quarkusPlatformArtifactId}:${quarkusPlatformVersion}")
    implementation 'io.quarkus:quarkus-resteasy'
    implementation 'io.quarkus:quarkus-amazon-lambda'

    testImplementation 'io.quarkus:quarkus-junit5'
    testImplementation 'io.rest-assured:rest-assured'
}

Live Coding and Unit/Integration Testing

To mirror the AWS Lambda environment as closely as possible in a dev environment, the Quarkus AWS Lambda extension boots up a mock AWS Lambda event server in Quarkus Dev and Test mode. This mock event server simulates a true AWS Lambda environment.

Mientras se ejecuta en el modo de desarrollo de Quarkus, puede alimentar los eventos haciendo un POST HTTP a http://localhost:8080. El servidor de eventos falso recibirá los eventos y su lambda será invocado. Puedes realizar codificación en vivo en tu lambda y los cambios se recompilarán automáticamente y estarán disponibles en la siguiente invocación que hagas. Aquí tienes un ejemplo:

CLI

quarkus dev

Maven

./mvnw quarkus:dev

Gradle

./gradlew --console=plain quarkusDev

$ curl -d "{\"name\":\"John\"}" -X POST http://localhost:8080

For your unit tests, you can also invoke on the mock event server using any HTTP client you want. Here’s an example using rest-assured. Quarkus starts up a separate Mock Event server under port 8081. The default port for Rest Assured is automatically set to 8081 by Quarkus, so you can invoke on this endpoint.

import org.junit.jupiter.api.Test;

import io.quarkus.test.junit.QuarkusTest;

import static io.restassured.RestAssured.given;
import static org.hamcrest.CoreMatchers.containsString;

@QuarkusTest
public class LambdaHandlerTest {

    @Test
    public void testSimpleLambdaSuccess() throws Exception {
        Person in = new Person();
        in.setName("Stu");
        given()
                .contentType("application/json")
                .accept("application/json")
                .body(in)
                .when()
                .post()
                .then()
                .statusCode(200)
                .body(containsString("Hello Stu"));
    }
}

The mock event server is also started for @QuarkusIntegrationTest tests so will work with native binaries too. All this provides similar functionality to the SAM CLI local testing, without the overhead of Docker.

Finally, if port 8080 or port 8081 is not available on your computer, you can modify the dev and test mode ports with application.properties

quarkus.lambda.mock-event-server.dev-port=8082
quarkus.lambda.mock-event-server.test-port=8083

A port value of zero will result in a randomly assigned port.

To turn off the mock event server:

quarkus.lambda.mock-event-server.enabled=false

Testing with the SAM CLI

If you do not want to use the mock event server, you can test your lambdas with SAM CLI.

La AWS SAM CLI le permite ejecutar sus lambdas localmente en su portátil en un entorno de Lambda simulado. Esto requiere la instalación de docker. Este es un enfoque opcional en caso de que decidas aprovecharlo. De lo contrario, la integración de Quarkus JUnit debería ser suficiente para la mayoría de sus necesidades.

A starter template has been generated for both JVM and native execution modes.

Ejecute el siguiente comando CLI de SAM para probar localmente su función lambda, pasando el parámetro apropiado de SAM template. El parámetro event toma cualquier archivo JSON, en este caso el ejemplo payload.json.

If using Gradle, the path to the binaries in the YAML templates must be changed from target to build

sam local invoke --template target/sam.jvm.yaml --event payload.json

La imagen nativa también puede probarse localmente utilizando la plantilla sam.native.yaml:

sam local invoke --template target/sam.native.yaml --event payload.json

Modifying `function.zip`

There are times when you may have to add some additions to the function.zip lambda deployment that is generated by the build. To do this, create a zip.jvm or zip.native directory within src/main. Create zip.jvm/ if you are doing a pure Java lambda. zip.native/ if you are doing a native deployment.

Any you files and directories you create under your zip directory will be included within function.zip

Custom `bootstrap` script

Hay veces que puedes querer establecer unas propiedades específicas del sistema u otros argumentos cuando lambda invoca tu despliegue lambda nativo de quarkus. Si incluyes un archivo de script bootstrap dentro de zip.native, la extensión quarkus renombrará automáticamente el ejecutable a runner dentro de function.zip y establecerá el modo unix del script bootstrap a ejecutable.

El ejecutable nativo debe ser referenciado como runner si incluye un script personalizado de bootstrap.

The extension generates an example script within target/bootstrap-example.sh.

Tracing with AWS XRay and GraalVM

If you are building native images, and want to use AWS X-Ray Tracing with your lambda you will need to include quarkus-amazon-lambda-xray as a dependency in your pom. The AWS X-Ray library is not fully compatible with GraalVM, so we had to do some integration work to make this work.

Además, recuerde habilitar el parámetro de rastreo de AWS X-Ray en manage.sh, en la función cmd_create(). Esto también se puede configurar en la consola de administración de AWS.

    --tracing-config Mode=Active

For the sam template files, add the following to the YAML function Properties.

    Tracing: Active

AWS X-Ray añade muchas clases a su distribución, asegúrese de que está utilizando al menos el tamaño de memoria de 256 MB de AWS Lambda. Esto se establece explícitamente en manage.sh cmd_create() . Aunque la imagen nativa siempre puede utilizar una configuración de memoria más baja, se recomienda mantener la misma configuración, especialmente para ayudar a comparar el rendimiento.

Using HTTPS or SSL/TLS

If your code makes HTTPS calls (e.g. to a microservice, to an AWS service), you will need to add configuration to the native image, as GraalVM will only include the dependencies when explicitly declared. Quarkus, by default enables this functionality on extensions that implicitly require it. For further information, please consult the Quarkus SSL guide

Open src/main/resources/application.properties and add the following line to enable SSL in your native image.

quarkus.ssl.native=true

Using the AWS Java SDK v2

Quarkus ahora tiene extensiones para DynamoDB, S3, SNS y SQS (más en camino). Por favor, consulte estas guías sobre cómo utilizar los diversos servicios de AWS con Quarkus, en lugar de cablear manualmente como se indica a continuación.

With minimal integration, it is possible to leverage the AWS Java SDK v2, which can be used to invoke services such as SQS, SNS, S3 and DynamoDB.

For native image, however, the URL Connection client must be preferred over the Apache HTTP Client when using synchronous mode, due to issues in the GraalVM compilation (at present).

Añade quarkus-jaxb como dependencia en tu archivo Maven pom.xml, o Gradle build.gradle.

You must also force your AWS service client for SQS, SNS, S3 et al., to use the URL Connection client, which connects to AWS services over HTTPS, hence the inclusion of the SSL enabled property, as described in the Using HTTPS or SSL/TLS section above.

// select the appropriate client, in this case SQS, and
// insert your region, instead of XXXX, which also improves startup time over the default client
  client = SqsClient.builder().region(Region.XXXX).httpClient(software.amazon.awssdk.http.urlconnection.UrlConnectionHttpClient.builder().build()).build();

For Maven, add the following to your pom.xml.

    <properties>
        <aws.sdk2.version>2.10.69</aws.sdk2.version>
    </properties>

    <dependencyManagement>
        <dependencies>

            <dependency>
                <groupId>software.amazon.awssdk</groupId>
                <artifactId>bom</artifactId>
                <version>${aws.sdk2.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

        </dependencies>
    </dependencyManagement>
    <dependencies>

        <dependency>
            <groupId>software.amazon.awssdk</groupId>
            <artifactId>url-connection-client</artifactId>
        </dependency>

        <dependency>
            <groupId>software.amazon.awssdk</groupId>
            <artifactId>apache-client</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>commons-logging</groupId>
                    <artifactId>commons-logging</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>software.amazon.awssdk</groupId>
            <!-- sqs/sns/s3 etc -->
            <artifactId>sqs</artifactId>
            <exclusions>
                <!-- exclude the apache-client and netty client -->
                <exclusion>
                    <groupId>software.amazon.awssdk</groupId>
                    <artifactId>apache-client</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>software.amazon.awssdk</groupId>
                    <artifactId>netty-nio-client</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>commons-logging</groupId>
                    <artifactId>commons-logging</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.jboss.logging</groupId>
            <artifactId>commons-logging-jboss-logging</artifactId>
        </dependency>
    </dependencies>

si ves java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty o un error SSL similar, debido al estado actual de GraalVM, hay algo de trabajo adicional para agrupar el function.zip, como se indica a continuación. Para más información, por favor vea la Guía de SSL nativa de Quarkus.

Additional requirements for client SSL

The native executable requires some additional steps to enable client SSL that S3 and other AWS libraries need.

A custom bootstrap script
libsunec.so must be added to function.zip
cacerts must be added to function.zip

To do this, first create a directory src/main/zip.native/ with your build. Next create a shell script file called bootstrap within src/main/zip.native/, like below. An example is created automatically in your build folder (target or build), called bootstrap-example.sh

#!/usr/bin/env bash

./runner -Djava.library.path=./ -Djavax.net.ssl.trustStore=./cacerts

Additional set -Djavax.net.ssl.trustStorePassword=changeit if your cacerts file is password protected.

Next you must copy some files from your GraalVM distribution into src/main/zip.native/.

GraalVM versions can have different paths for these files whether you are using the Java 8 or 11 version. Adjust accordingly.

cp $GRAALVM_HOME/lib/libsunec.so $PROJECT_DIR/src/main/zip.native/
cp $GRAALVM_HOME/lib/security/cacerts $PROJECT_DIR/src/main/zip.native/

Now when you run the native build all these files will be included within function.zip

If you are using a Docker image to build, then you must extract these files from this image.

To extract the required ssl, you must start up a Docker container in the background, and attach to that container to copy the artifacts.

First, let’s start the GraalVM container, noting the container id output.

docker run -it -d --entrypoint bash quay.io/quarkus/ubi-quarkus-mandrel-builder-image:jdk-21

# This will output a container id, like 6304eea6179522aff69acb38eca90bedfd4b970a5475aa37ccda3585bc2abdde
# Note this value as we will need it for the commands below

First, libsunec.so, the C library used for the SSL implementation:

docker cp {container-id-from-above}:/opt/graalvm/lib/libsunec.so src/main/zip.native/

Second, cacerts, the certificate store. You may need to periodically obtain an updated copy, also.

docker cp {container-id-from-above}:/opt/graalvm/lib/security/cacerts src/main/zip.native/

Your final archive will look like this:

jar tvf target/function.zip

    bootstrap
    runner
    cacerts
    libsunec.so

Deploy to AWS Lambda using a Container Image

AWS Lambda supports creating your lambdas by referencing container images rather than uploading ZIP files. This can have some benefits such as bypassing the size limit of the uploaded ZIP files. You can define lambda functions for both native builds and regular JVM builds.

JVM container image

Para una distribución regular de JVM necesitas basar tu imagen en las imágenes base oficiales de AWS Java. A continuación se muestra un ejemplo de un archivo Docker que crearía una imagen de contenedor de su proyecto Quarkus Lambda. Asume que mvn package ha sido ejecutado y los binarios están disponibles en el directorio target/:

FROM  public.ecr.aws/lambda/java:11

ADD target/my-service-0.0.1-SNAPSHOT-runner.jar /var/task/lib/my-service.jar
ADD target/lib/  /var/task/lib/

CMD ["io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest"]

Native executable container image

To create a lambda container image that uses the native executable we’ll need to do things a little differently. In this case, we won’t need to use the java:11 base image from AWS, but instead we’ll use a special image that assumes that the runtime environment for the lambda is provided. The example below creates such a container. It assumes that a Maven build has been executed (such as mvn package -Dnative=true) and has generated the native binary into the target/ directory. The binary needs to be named bootstrap and be placed in /var/runtime/:

FROM  public.ecr.aws/lambda/provided

ADD target/my-service-0.0.1-SNAPSHOT-runner /var/runtime/bootstrap
RUN chmod ugo+x /var/runtime/bootstrap

CMD ["io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest"]

Deploying a container image lambda

A continuación, puede ver cómo las imágenes de contenedor creadas anteriormente pueden construirse e implementarse en AWS utilizando las herramientas de línea de comandos docker y aws. Estas instrucciones funcionan tanto para imágenes de contenedor nativas como jvm y asumen que la herramienta de línea de comandos aws ha sido iniciada.

Build the Docker image

# Assuming we are located in the root directory of the project and created a Dockerfile there
docker build .
   [output omitted]
    => exporting to image                    0.0s
    => => exporting layers                   0.0s
    => => writing image sha256:[SOME SHA]    0.0s

Create an ECR repository in the users AWS account

aws ecr create-repository --repository-name my/test/quarkus-lambda

Tag the image using your ECR registry information

docker tag [SOME SHA] [YOUR AWS ACCOUNT ID].dkr.ecr.[YOUR AWS ACCOUNT REGION].amazonaws.com/my/test/quarkus-lambda:v1

Log Docker into your ECR registry and push the Docker image to it

aws ecr get-login-password --region region | docker login --username AWS --password-stdin [YOUR AWS ACCOUNT ID].dkr.ecr.[YOUR AWS ACCOUNT REGION].amazonaws.com
docker push [YOUR AWS ACCOUNT ID].dkr.ecr.[YOUR AWS ACCOUNT REGION].amazonaws.com/my/test/quarkus-lambda:v1

Create the AWS lambda function with the AWS CLI tool

Asegúrate de que haces referencia a la imagen que has subido previamente (se supone que existe un rol que puede ser utilizado para ejecutar la lambda). Ten en cuenta que no es improbable que para la función lambda de JVM, el límite de memoria por defecto de 128Mb no sea suficiente para ejecutar la función. En ese caso, puede aumentar el límite de memoria al crear la función proporcionando el parámetro --memory-size 256 a su comando aws lambda create-function. También puede ajustar la función en la consola de AWS después de haberla creado.

aws lambda create-function --function-name my-test-quarkus-lambda-function --package-type Image --code ImageUri=[YOUR AWS ACCOUNT ID].dkr.ecr.[YOUR AWS ACCOUNT REGION].amazonaws.com/my/test/quarkus-lambda:v1 --role arn:aws:iam::[YOUR AWS ACCOUNT ID]:role/[SOME ROLE]

Now you can use the AWS console to view and test your new lambda function.

Amazon Alexa Integration

To use Alexa with Quarkus native, you need to use the Quarkus Amazon Alexa extension hosted at the Quarkiverse Hub.

<dependency>
    <groupId>io.quarkiverse.alexa</groupId>
    <artifactId>quarkus-amazon-alexa</artifactId>
    <version>${quarkus-amazon-alexa.version}</version> (1)
</dependency>

1	Define the latest version of the extension in your POM file.

Create your Alexa handler, as normal, by sub-classing the abstract com.amazon.ask.SkillStreamHandler, and add your request handler implementation.

That’s all there is to it!

SnapStart

To optimize your application for Lambda SnapStart, check the SnapStart Configuration Documentation.

AWS Lambda

Prerequisites

Getting Started

Installing AWS bits

Creating the Maven Deployment Project

Choose Your Lambda

Deploy to AWS Lambda Java Runtime

Build and Deploy

Create an Execution Role

Extra Build Generated Files

Create the function

Invoke the Lambda

Update the Lambda

Deploy to AWS Lambda Custom (native) Runtime

Examine the POM and Gradle build

Construcción de Gradle

Live Coding and Unit/Integration Testing

Testing with the SAM CLI

Modifying `function.zip`

Custom `bootstrap` script

Tracing with AWS XRay and GraalVM

Using HTTPS or SSL/TLS

Using the AWS Java SDK v2

Additional requirements for client SSL

Deploy to AWS Lambda using a Container Image

JVM container image

Native executable container image

Deploying a container image lambda

Build the Docker image

Create an ECR repository in the users AWS account

Tag the image using your ECR registry information

Log Docker into your ECR registry and push the Docker image to it

Create the AWS lambda function with the AWS CLI tool

Amazon Alexa Integration

SnapStart

Related content

On the same extensions

On the same topics

AWS Lambda

Prerequisites

Getting Started

Installing AWS bits

Creating the Maven Deployment Project

Choose Your Lambda

Deploy to AWS Lambda Java Runtime

Build and Deploy

Create an Execution Role

Extra Build Generated Files

Create the function

Invoke the Lambda

Update the Lambda

Deploy to AWS Lambda Custom (native) Runtime

Examine the POM and Gradle build

Construcción de Gradle

Live Coding and Unit/Integration Testing

Testing with the SAM CLI

Modifying function.zip

Custom bootstrap script

Tracing with AWS XRay and GraalVM

Using HTTPS or SSL/TLS

Using the AWS Java SDK v2

Additional requirements for client SSL

Deploy to AWS Lambda using a Container Image

JVM container image

Native executable container image

Deploying a container image lambda

Build the Docker image

Create an ECR repository in the users AWS account

Tag the image using your ECR registry information

Log Docker into your ECR registry and push the Docker image to it

Create the AWS lambda function with the AWS CLI tool

Amazon Alexa Integration

SnapStart

Related content

On the same extensions

On the same topics

Modifying `function.zip`

Custom `bootstrap` script