In the ever-evolving world of web development, deploying applications has become increasingly complex. However, with the rise of serverless architectures and powerful cloud platforms like Amazon Web Services (AWS), the process of deploying and scaling applications has become more streamlined and efficient than ever before. In this article, we will explore how to leverage AWS Lambda Web Adapter, Terraform, and AWS Lambda in combination with CloudFront to deploy a simple Next.js application. ## Setting up NextJS app for standalone deployment To create a new Next.js project, run the following command in your terminal: {` npx create-next-app@latest yarn create next-app pnpm create next-app `} Once the project is set up, you'll need to make a couple of modifications in the `next.config.js` file to prepare the application for standalone deployment and utilize static files from a CDN. Open the `next.config.js` file and add the following code: {` const nextConfig = { output: 'standalone', assetPrefix: 'https://', // other code } `} By setting `output` to `standalone`, Next.js can automatically create a standalone folder that copies only the necessary files for a production deployment, including select files in *node_modules*. The `assetPrefix` property should be set to the URL of your desired CDN. By doing so, your Next.js app will utilize the CDN to serve static files, resulting in improved performance and faster load times for your users. Remember to replace `` with the actual URL of your CDN. Once you've made these changes, your Next.js application will be ready for deployment using AWS Lambda and a CDN. ## Provisioning infrastructure with Terraform To deploy the Next.js app, we need to provision specific infrastructure components like a Lambda function with an API Gateway for the server, as well as a CloudFront distribution to handle static files. In this guide, we will focus on packaging the code as a zip file and utilizing it in a Lambda function. If you prefer using a Docker image, please refer to the [official documentation for detailed instructions](https://github.com/awslabs/aws-lambda-web-adapter#lambda-functions-packaged-as-docker-images-or-oci-images). Before we begin, make sure you have Terraform and the AWS CLI installed. If you haven't already, you can follow the links below to install them: - [Install Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) - [Install AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) and [add your AWS credentials](https://docs.aws.amazon.com/cli/latest/reference/configure/index.html) Now, let's set up the necessary Terraform files. Create a new folder named `nextjs-lambda/` in the root directory of your application, and place the following files inside: ```bash nextjs-lambda ├── api_gw.tf ├── cloudfront.tf ├── deploy.sh ├── domain.tf ├── lambda.tf ├── main.tf ├── output.tf ├── run.sh ├── s3_bucket.tf ├── terraform.tfvars ├── terraform.tfvars.example └── variables.tf ``` These files contain the Terraform configurations needed to provision the required AWS resources. The `main.tf` file acts as the entry point for Terraform, and the other files define specific resources like API Gateway, CloudFront, Lambda function, and more. ### Main Sets up the providers and remote state management in `main.tf`. Here, the state is managed using S3 and Dynamodb. You can configure it to use other state management methods as well. {` terraform { backend "s3" { bucket = "" key = "" region = "" dynamodb_table = "tf-state-lock" encrypt = true } required_providers { aws = { source = "hashicorp/aws" version = "5.5.0" } archive = { source = "hashicorp/archive" version = "2.4.0" } } required_version = "~> 1.5.1" } # Configure the AWS Provider provider "aws" { region = "us-east-1" } `} ### Lambda The `lambda.tf` file is responsible for declaring the Lambda function, its policy, and CloudWatch logs. It utilizes the `archive_file` module to create a zip file of the Next.js package. {` # tflint-ignore: terraform_unused_declarations data "archive_file" "lambda" { type = "zip" # path to nextjs app root folder source_dir = "\${path.module}/../.next/standalone/" output_path = "lambda_function_payload.zip" } resource "aws_lambda_function" "nextjs" { filename = "lambda_function_payload.zip" function_name = var.LAMBDA_FUNCTION_NAME role = aws_iam_role.iam_for_lambda.arn handler = "run.sh" memory_size = var.memory_size package_type = "Zip" runtime = var.NodeRuntime timeout = var.timeout architectures = ["x86_64"] layers = ["arn:aws:lambda:\${var.REGION}:753240598075:layer:LambdaAdapterLayerX86:16"] environment { variables = { AWS_LAMBDA_EXEC_WRAPPER = var.AWS_LAMBDA_EXEC_WRAPPER AWS_LWA_ENABLE_COMPRESSION : true RUST_LOG : "info" PORT : var.PORT } } } data "aws_iam_policy_document" "assume_role" { statement { effect = "Allow" principals { type = "Service" identifiers = ["lambda.amazonaws.com"] } actions = ["sts:AssumeRole"] } } resource "aws_iam_role" "iam_for_lambda" { name = "iam_for_lambda_nextjs" assume_role_policy = data.aws_iam_policy_document.assume_role.json } resource "aws_cloudwatch_log_group" "nextjs_log" { name = "/aws/lambda/\${var.LAMBDA_FUNCTION_NAME}" retention_in_days = 7 } # See also the following AWS managed policy: AWSLambdaBasicExecutionRole data "aws_iam_policy_document" "lambda_nextjs_logging" { statement { effect = "Allow" actions = [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", ] resources = ["arn:aws:logs:*:*:*"] } } resource "aws_iam_policy" "lambda_logging" { name = "lambda_nextjs_logging" path = "/" description = "IAM policy for logging from a lambda" policy = data.aws_iam_policy_document.lambda_nextjs_logging.json } resource "aws_iam_role_policy_attachment" "lambda_logs" { role = aws_iam_role.iam_for_lambda.name policy_arn = aws_iam_policy.lambda_logging.arn } `} - The Lambda handler in the code utilizes the **`run.sh`** bash script to initialize the server. - To make this entire setup work, we rely on the **Lambda Web Adapter layer**. The layer is available in different architectures, and further details can be found in the [official documentation](https://github.com/awslabs/aws-lambda-web-adapter). - Additionally, you need to configure the Lambda environment variable `AWS_LAMBDA_EXEC_WRAPPER` to `/opt/bootstrap`. In the above example, this value is passed as a Terraform variable. ### API Gateway API Gateway enables us to invoke Lambda functions using a custom domain. In this example, Terraform is used to set up an HTTP API Gateway and grant it permission to invoke Lambda. {` resource "aws_apigatewayv2_api" "httpAPI" { name = var.DOMAIN_NAME protocol_type = "HTTP" target = aws_lambda_function.nextjs.arn } resource "aws_lambda_permission" "apigw" { action = "lambda:InvokeFunction" function_name = aws_lambda_function.nextjs.arn principal = "apigateway.amazonaws.com" # The /* part allows invocation from any stage, method and resource path # within API Gateway. source_arn = "\${aws_apigatewayv2_api.httpAPI.execution_arn}/*/*" } `} ### S3 Bucket This section sets up a private S3 bucket and grants permission to access its contents via CloudFront. {` resource "aws_s3_bucket" "cdn_bucket" { bucket = var.CDN_URL force_destroy = true tags = { Name = "Nextjs CDN Bucket" } } resource "aws_s3_bucket_ownership_controls" "bucket_ownership" { bucket = aws_s3_bucket.cdn_bucket.id rule { object_ownership = "BucketOwnerPreferred" } } resource "aws_s3_bucket_acl" "cdn_bucket_acl" { depends_on = [aws_s3_bucket_ownership_controls.bucket_ownership] bucket = aws_s3_bucket.cdn_bucket.id acl = "private" } resource "aws_s3_bucket_policy" "cloudfront_bucket_policy" { bucket = aws_s3_bucket.cdn_bucket.id policy = data.aws_iam_policy_document.s3_bucket_policy.json } data "aws_iam_policy_document" "s3_bucket_policy" { statement { effect = "Allow" principals { type = "Service" identifiers = ["cloudfront.amazonaws.com"] } actions = [ "s3:GetObject", ] resources = [ "\${aws_s3_bucket.cdn_bucket.arn}/*", ] condition { test = "ForAnyValue:StringEquals" variable = "AWS:SourceArn" values = [aws_cloudfront_distribution.s3_distribution.arn] } } } `} ### CloudFront CloudFront distribution is created with the S3 bucket as the source. Managed policies and other essential configurations are defined. Origin Access Control (OAC) is used to access the S3 bucket content. {` resource "aws_cloudfront_origin_access_control" "s3_bucket_oac" { name = "\${var.CDN_URL}_oac" description = "OAC policy for \${var.CDN_URL}" origin_access_control_origin_type = "s3" signing_behavior = "always" signing_protocol = "sigv4" } data "aws_cloudfront_cache_policy" "CachingOptimized" { name = "Managed-CachingOptimized" } data "aws_cloudfront_response_headers_policy" "CORS_With_Preflight" { name = "Managed-CORS-With-Preflight" } resource "aws_cloudfront_distribution" "s3_distribution" { origin { domain_name = aws_s3_bucket.cdn_bucket.bucket_domain_name origin_access_control_id = aws_cloudfront_origin_access_control.s3_bucket_oac.id origin_id = var.CDN_URL } enabled = true is_ipv6_enabled = true comment = "nextjs-cdn" price_class = "PriceClass_All" wait_for_deployment = false aliases = [var.CDN_URL] viewer_certificate { acm_certificate_arn = var.CERTIFICATE_ARN minimum_protocol_version = "TLSv1.2_2021" ssl_support_method = "sni-only" } default_cache_behavior { allowed_methods = ["GET", "HEAD", "OPTIONS"] cached_methods = ["GET", "HEAD"] target_origin_id = var.CDN_URL cache_policy_id = data.aws_cloudfront_cache_policy.CachingOptimized.id viewer_protocol_policy = "redirect-to-https" response_headers_policy_id = data.aws_cloudfront_response_headers_policy.CORS_With_Preflight.id compress = true } restrictions { geo_restriction { restriction_type = "none" locations = [] } } } `} ### Domain This section is responsible for creating and assigning custom domains for API Gateway and CloudFront distribution. It utilizes an existing Hosted Zone and SSL Certificate. For API Gateway, a custom domain is mapped to the HTTP API gateway with the default stage. {` resource "aws_apigatewayv2_domain_name" "api_gw_domain" { domain_name = var.DOMAIN_NAME domain_name_configuration { certificate_arn = var.CERTIFICATE_ARN endpoint_type = "REGIONAL" security_policy = "TLS_1_2" } } data "aws_route53_zone" "HostedZoneID" { name = var.HOSTED_ZONE_DOMAIN private_zone = false } resource "aws_route53_record" "application_domain" { name = aws_apigatewayv2_domain_name.api_gw_domain.domain_name type = "A" zone_id = data.aws_route53_zone.HostedZoneID.zone_id alias { name = aws_apigatewayv2_domain_name.api_gw_domain.domain_name_configuration[0].target_domain_name zone_id = aws_apigatewayv2_domain_name.api_gw_domain.domain_name_configuration[0].hosted_zone_id evaluate_target_health = false } } resource "aws_route53_record" "cloudfront_domain" { name = var.CDN_URL type = "A" zone_id = data.aws_route53_zone.HostedZoneID.zone_id alias { name = aws_cloudfront_distribution.s3_distribution.domain_name zone_id = aws_cloudfront_distribution.s3_distribution.hosted_zone_id evaluate_target_health = false } } resource "aws_apigatewayv2_api_mapping" "api_gw_domain_mapping" { api_id = aws_apigatewayv2_api.httpAPI.id domain_name = aws_apigatewayv2_domain_name.api_gw_domain.id stage = "$default" } `} ### Variables All the variables used in this Terraform module: {` variable "memory_size" { type = number default = 512 } variable "NodeRuntime" { type = string default = "nodejs18.x" } variable "timeout" { type = number default = 10 } variable "LAMBDA_FUNCTION_NAME" { type = string default = "Nextjs-app" } variable "AWS_LAMBDA_EXEC_WRAPPER" { type = string default = "/opt/bootstrap" } variable "PORT" { type = number default = 8000 } variable "REGION" { type = string sensitive = true } variable "DOMAIN_NAME" { type = string } variable "CERTIFICATE_ARN" { type = string } variable "HOSTED_ZONE_DOMAIN" { type = string } variable "CDN_URL" { type = string } `} ### `terraform.tfvars` The `terraform.tfvars` file is used to store variable values for the Terraform configuration. You can create it based on the provided `terraform.tfvars.example` file and fill in the necessary values. {` REGION = "" DOMAIN_NAME = "" CERTIFICATE_ARN = "" HOSTED_ZONE_DOMAIN = "" CDN_URL = "" PORT = "" LAMBDA_FUNCTION_NAME = "" `} ### Output (optional) Returns the CDN domain and API Gateway domain {` output "cloudfront_domain_name" { value = aws_route53_record.cloudfront_domain.name } output "application_domain" { value = aws_route53_record.application_domain.name } `} With the infrastructure provisioning files in place, we are ready to move on to the next steps of deploying the Next.js app using AWS Lambda and CloudFront. ## Deploy Script Add a `run.sh` bash script to the `nextjs-lambda/` folder, which will serve as the entry point to run the app after deployment. {` #!/bin/bash [ ! -d '/tmp/cache' ] && mkdir -p /tmp/cache exec node server.js `} In addition, include another bash script called `deploy.sh` that packages files, provisions the infrastructure, and uploads static files to S3. Remember to update the `CDN_NAME` variable (which must match the one used for infrastructure). Ensure that these bash scripts have execution permissions. {` #! /usr/bin/bash set -e # stop execution if anything fails # Add cdn domain address CDN_DOMAIN="" LAMBDA_FUNCTION_NAME="" if [ "$1" = 0 ]; then echo "No arguments provided. Please provide 'deploy' or 'sync' as an argument." exit 1 fi if [ "$1" != "deploy" ] && [ "$1" != "sync" ]; then echo "Invalid argument. Please provide 'deploy' or 'sync' as an argument." exit 1 fi # get the absolute file path SOURCE=\${BASH_SOURCE[0]} while [ -L "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink DIR=$( cd -P "$( dirname "$SOURCE" )" >/dev/null 2>&1 && pwd ) SOURCE=$(readlink "$SOURCE") [[ $SOURCE != /* ]] && SOURCE=$DIR/$SOURCE # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located done DIR=$( cd -P "$( dirname "$SOURCE" )" >/dev/null 2>&1 && pwd ) file_dir_name=$(basename "$DIR") cd $(dirname "$DIR") echo "Installing node modules" npm i echo "Building nextjs application" npm run build # Package files for deployment echo "packaging files" cp -r public/. .next/standalone/public cp $file_dir_name/run.sh .next/standalone/ if [ "$1" = "deploy" ]; then echo "Running deploy command..." echo "provisioning infrastructure" cd $file_dir_name/ if [ ! -d ".terraform" ] then echo "Terraform has not been initialized. Initializing now..." terraform init else echo "Terraform is already initialized" fi terraform validate terraform apply -auto-approve elif [ "$1" = "sync" ]; then echo "Running sync command..." cd .next/standalone/ zip -r -q lambda_function_payload.zip . echo "This might take a while..." aws lambda update-function-code --function-name $LAMBDA_FUNCTION_NAME --zip-file fileb://lambda_function_payload.zip 1> /dev/null if [ $? -eq 0 ] then echo "Command executed successfully, continuing to next section." else echo "There was an error in executing the command." fi rm -rf lambda_function_payload.zip cd $DIR fi # move to application folder and sync static files to CDN echo "syncing static files to S3" cd ../ # sync static files to S3 + Cloudfront aws s3 cp .next/static/ s3://$CDN_DOMAIN/_next/static/ --recursive `} To deploy the app, execute the `deploy.sh` bash script with argument `deploy`. {` ./deploy.sh deploy `} Note that even after the deployment is complete, it may take some time for the CloudFront deployment to finish. To just sync files to Lambda and S3, execute the `deploy.sh` bash script with argument `sync`. {` ./deploy.sh sync `} To destroy the deployment, navigate to the `nextjs-lambda/` folder and run: {` terraform destroy `} Remember to add this to the `.gitignore` file before committing any changes to Git. {` ### Terraform ### # Local .terraform directories **/.terraform/* # .tfstate files *.tfstate *.tfstate.* # Crash log files crash.log crash.*.log # Exclude all .tfvars files, which are likely to contain sensitive data, such as # password, private keys, and other secrets. These should not be part of version # control as they are data points which are potentially sensitive and subject # to change depending on the environment. *.tfvars *.tfvars.json # Ignore override files as they are usually used to override resources locally and so # are not checked in override.tf override.tf.json *_override.tf *_override.tf.json # Include override files you do wish to add to version control using negated pattern # !example_override.tf # Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan # example: *tfplan* # Ignore CLI configuration files .terraformrc terraform.rc lambda_function_payload.zip `} You can find the code and an example in this [GitHub repository](https://github.com/annleefores/nextjs-lambda) #### Reference:

- [AWS Lambda Web Adapter - GitHub](https://github.com/awslabs/aws-lambda-web-adapter) - [Deploy Next JS v13.x to AWS Lambda using aws-lambda-web-adapter](https://medium.com/@jake-smith/deploy-next-js-v13-x-to-aws-lambda-using-aws-lambda-web-adapter-dd5308d75848)