Forem: Guillaume Égée

Free dynDNS for your NAS: auto-update DNS with your latest IP

Guillaume Égée — Tue, 12 Mar 2024 12:38:00 +0000

🎉 No more use a costly dynDNS service to update DNS A record when your IP changes!

I've just set up a NAS at home and linked a domain name to my router IP. But one day I could no more access to it, because the router IP changed without any notice!
Fortunately, a lot of dynDNS tools exist, but they are often paid services (even if quite cheap, I acknowledge). Why not building your own free dynDNS?

I created a repository which rely on an AWS CDK stack to update your A record in Amazon Route 53 with an API endpoint. This endpoint can be called by a script whenever your IP changes.

Suppose you host your own NAS server and want to access it at my-server.com you have bought on AWS. You need to add a A record to make my-server.com point to your server public IP. In general, if you rely on an Internet provider to get an IP, you are not guaranteed to have a one static, even if in practice they don't often change (at router reboot for instance). If you want to keep your A record up-to-date when your dynamic IP changes, this project is made for you!

... and it is (almost) free!

Set up the stack

Just follow the installation steps!
You'll need Node.js, an AWS account and a domain name of course!

How it works?

The script installed on your NAS will first call an API to retrieve its current IP, on a frequency defined with a cron job.
If this IP has changed, it will call another API endpoint (protected with an API key this time). An express step functions will then update the record in Route53 if the requested IP is the same as the source IP (the actual IP of the server calling the endpoint).
That's all!

🤑 Estimated cost

The deployed stack uses AWS resources at really low cost, supposing the script is run every hour and the IP changes every day:

Check the IP (every hour)

API Gateway V2: ~ $0.00083 = 31 days x 24h x 1.11/million requests. NB: free tier the first year
Lambda: ~ $0.00126 / month = 31 days x 24h x 1000 milliseconds x $0.0000000017 (architecture ARM, memory: 128 MB, region eu-west-1, Jan. 2024)

Update the IP (every day)

Step Functions: ~ $0.033 / month = 31 days x ($0.000001 (price per request, Jan. 2024) + 1000 milliseconds x 64 MB x \$0.00001667 )
CloudWatch: Free tier = 6 months x 31 days x (2 kB (Step Functions) + 500 B (Lambda)) = 0.5 MB < 5 GB of free tier
API Gateway V1: ~ $0.00003 = 31 x 3.50/million requests. NB: free tier the first year
Route 53 : ~ $0.00001 / month = 31 queries x $0.40 per million queries
CloudFormation : free
IAM: free

TOTAL COST: < $0.5 per year!

NB: you need to add the domain name cost (~$12 per year (depending on the name chosen) + $0.50 per hosted zone per month).

Migrating from API Gateway V2 to V1 to get REST API features

Guillaume Égée — Tue, 13 Feb 2024 17:04:31 +0000

This guide aims to help you migrate a serverless or CloudFormation stack with API Gateway v2 (HTTP API) integrated with lambdas to the same stack using API Gateway v1 (REST API), with a focus on:

Handling API paths constraints
Input and Output serialization (and in particular these breaking changes: JWT authentication, CORS)

AWS REST API has a lot of features that HTTP API do not benefit from: cache at edge, WAF integration, API keys. Even if some features can be circumvented, like using CloudFront for cache at edge, some are not and a migration can be necessary. For a detailed comparison between the two versions, see this guide: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html

💡 TLDR: have a look to this repo for Typescript types, helpers to format API responses and a serverless template with the use of both API versions.

🗜️ API path constraints are different

In REST API, each part of an API path is a resource

In REST API, paths must be defined once, because each path part is a resource. This is not an issue with HTTP API.

If you need to deploy /actions/list and /actions/toggle, you need to deploy 3 ApiGateway Resource, /action, /list and /toggle, one for each path.
If you define /action twice, you will get 409 Conflict "Another resource with the same parent already has this name: actions"

With Serverless framework, it is done for you, except if you deploy different services with a path in common: in this case, you have no choice but to rename it.

Variables in paths are managed differently

Let’s say you have defined two routes /network/{networkId}/actions/list and /network/{userId}/profile in the HTTP API. Even if we can challenge this api path structure, it is possible with HTTP API… but not with REST API, because only one variable path part name is allowed.

In CloudFormation, you should encounter this error: "A sibling ({networkId}) of this resource already has a variable path part -- only one is allowed".

Two options: either rename userId to networkId (if it makes sense 🤔) or change the path!

➡️ Input is different

There are two versions of the input payload, Payload 1.0 and Payload 2.0. For Typescript users, I wrote the payload types, as they are not exposed in AWS SDK.

Handling headers and query strings with multiple values

With API Gateway v2, query strings and headers can have multiple values for the same key. In this case, values are comma-separated in the input object headers or queryStringParameters.

// Payload 1.0 (REST API)
{ 
  ...
  "headers": { "singleValueParam": "value1" },
  "multiValueHeaders": { "multiValueParam": ["value1", "value2"] }
}

// Payload 2.0 (HTTP API)
{ 
  ...
  "headers": { "singleValueParam": "value1", "multiValueParam": "value1,value2" }
}

Authentication is different... and Cognito groups are formatted differently!

If you use a Cognito authorizer, you can find similar keys in both payloads... but they are not the same!

For instance for a user in Cognito groups "group1" and "group2":

// Payload 1.0 (REST API)
{ 
  ...
  "requestContext": { 
    "authorizer": {
      "claims": {
        "cognito:groups": "group1,group2",
        "cognito:username": "bob@example.com",
        "email": "bob@example.com"
      }
    }
   }
}

// Payload 2.0 (HTTP API)
{ 
  ...
  "requestContext": { 
    "authorizer": {
      "jwt": {
        "claims": {
          "cognito:groups": "[group1 group2]",
          "cognito:username": "bob@example.com",
          "email": "bob@example.com"
        }
      }
    }
   }
}

Therefore, Cognito groups must be parsed differently!

Other parameters are not at the same place...

.. but I won't go through other differences, but they are a lot that can be easily found in these types.

🔀 In REST API, CORS are handled at method level

In HTTP API, a global configuration can be set ; in REST API it is at method level.
So when moving to REST API, you need to edit every method to add CORS for preflight requests. And for other requests, you need to update the output of the lambda manually (see next section).

⬇️ Output is different, even if a Lambda integration is chosen

With HTTP API, if no statusCode key is defined, the output payload is automatically stringified to a response body in a HTTP response with status 200 (see documentation)
. This is not the case in REST API, so you need to format your output manually. For an easier migration, you can set up a middleware based on this code, or if you use @middy middleware, based on this code.
These helpers also add CORS headers, as this is not handled by REST API.

Finally, should I move to REST API?

In short, the REST API comes with more features, but is more complex whereas HTTP API is a three-times cheaper and turnkey solution, especially if you use a JWT authentication and need CORS headers. Moving from one API to another is clearly possible, but painful for a big application with multiple services sharing the same API Gateway.

6 guidelines for risk-less data migrations

Guillaume Égée — Wed, 13 Dec 2023 13:25:19 +0000

“The majority of project issues I have seen come from databases, whatever is the technology” said one day one my experienced engineering manager...

This is why I have built 6 guidelines I try to follow when modifying data on tech projects. They are especially helpful when working with databases like DynamoDB with few tooling (no ORM, etc.).

Data is key in business… and it is where it often fails.

Almost every app has a database with more or less structured data. These data items may evolve during app development, with the addition of new fields, changes to field structure, data updates, or removal of fields. These evolutions, often referred to as migrations, are critical as they enable the app to evolve but can also introduce bugs if not executed properly.
A data migration plan is a perfect tool to mitigate the risks of these operations, as it avoids common pitfalls and ensures reliability.

📋️ First thing: have a migration protocol defined

Define a protocol to follow in advance

Define who is responsible of what. You can use a responsibility matrix (RACI)
Define when the migration should be planned
Define what should be done in precise steps (manually deploy a function, trigger a Continuous Deployment workflow, etc.) ?

Follow the protocol

A simple advice... to avoid acting in panic if something goes wrong…

Upgrade the protocol with your learnings

There are often recurring patterns in migrations: making a field non nullable, updating a data type, etc. To capitalize on them, build a list of common migrations with explanations of the best implementation strategy based on past experiences.

↔️ Have a strategy to handle the transition state

Estimate the duration and load (scalability) of the migration process, in all environments

What specific cases should be anticipated in production?
- What differences should be taken into account when estimating the migration sizing (database size, environment configuration)?
- Are there API/database quotas that you should plan for?
Apply a margin for the manual parts (launching the migration, etc.)

Migration strategies

Given that estimation and business concerns, choose between these 2 main strategies:

💥 “Big Bang” Migration

Only one version of a migration set (pieces of data to modify) can exist at application uptime.

Plan a service interruption when data will be unavailable.

✍️ Example of a user-friendly service interruption: during the migration process, the frontend application displays a "maintenance banner", and the backend is programmatically locked, to ensure no side-effect can corrupt data.

✳️ Pros: quicker method, advised when building a project with low risks if some data is lost/corrupted
⚠️ Risks:
- possibly long downtime,
- risk of database throttling (in case of naive parallel read/write implementation for instance)
- more difficult to write migrations with a reliable rollback

🌊 Migration in two (or more) steps

Handle old and new versions inside the migration set.

Data migration and new code deployment must be uncoupled and done in the proper order.
Examples :
- if you remove a column (or a table, etc.), remove the code using this column and then migrate the data
- if you add a column, migrate the data first and then deploy the code using it
- if you update a column, add a new column and, after it has been fulfilled progressively, remove the old column
💡 You can run integration tests with both versions to ensure the application works in both cases
✳️ Pros: reliable method, that is error proof (if the migration fails, the system can continue running without interruption)
⚠️ Risks:
- more complex to develop
- longer to fulfill completely
- risk of maintaining multiple versions over a long period of time.

🔂 Make a plan reproducible in multiple environments

Write idempotent migrations (i.e. a migration can be applied multiple times with the same result)

There are many reasons for needing to re-apply a migration: migration partially completed, stopped or failed, etc.
The migration script should work without any state-full input

✍️ Simple example of idempotent migrations

❌ Bad: if you run the migration twice, the data will be corrupted.

  def perform_migration(item):
      item.count += 1

  def not_idem_potent_migration(new_version):
          perform_migration(item)
          item.version = new_version

✅ Good: even if the migration itself (incrementation) is not idem-potent, it is not possible to run it twice with this migration.

  def idem_potent_migration(new_version: int):
      if (item.version >= new_version):
          return
      else:
          perform_migration(item)
          item.version = new_version

Save the migration scripts

Committing migration scripts ensures the same process can be applied to another environment easily and with known and reproducible steps.
In case of error, it will help understanding what happened.

Test your scenario

Test the migration script (with unit tests) to verify its functionality.
- Check that data items of the migration set are correctly selected
- Check all edge cases
Use dedicated environments to test the migration plan
- Non-production environments can help to find bugs, all the more if data is ISO-prod.
- If it is not possible to test a scenario with production data, you can at least run scripts to check for errors, or run migrations in dry-run

📆 The plan includes communication with stakeholders

Running a migration can have impacts on the underlying business, so it should not remain in the technical sphere, but be shared to stakeholders.

Communicate to business owners and stakeholders

Explicit the risks of the migration and consider their concerns

Stakeholders should be involved in the decision to migrate data, as they know the system and are responsible of it.
They may help find edge cases in the migration, like dependencies to other teams, a specific business case not handled, etc.
✍️❌ Common pitfall: Delete a deprecated column that is still used by another team
✍️✅ Good practice: Continue supporting legacy versions until they are no longer in use, and establish a deadline to cease support.

Choose the right moment to run the migration

✍️❌ Common pitfall: Run a resource-consuming migration during peak hours (example: adding a non-nullable column of a table in PostgreSQL that will lock it).
✍️✅ Good practice: Run a “big bang” migration just after the deployment to reduce the service interruption lead time. Run it during off-peak hours and when a development team is available in case of error.

↩️ A rollback strategy is defined

Backup your data and practice restoring it

If anything goes wrong, you should be able to restore your database to a correct state.

Cloud providers have services dedicated to backups (e.g. AWS Backup if you are using AWS, Actifio on GCP, etc.) and database systems often come with their own backup solution.
Practice restoring your data
Be pragmatic. Can you afford to restore your data?
- Some data items might have been updated during the process
- Is it worth to rollback, if only a few items have an issue?
- What is the risk of a data loss?

Write a “down” migration, as well as the “up” migration… or at least a Plan B

How many times I've heard (or said) "It won't fail, no need of plan B"... and it finally failed ?
I won't go through implementation details here (and a lot of ORMs have dedicated tools for this), the main point is "Don't be overconfident"!

🧱 The plan includes a check that everything is ok in the end

Keep track of migration states with versioning

If possible, save the changes and the version of items during the migration process.
Keep track of migration applications in each environment.
The versions must be strictly increasing (in a specific order relationship) and deterministic to be able to compare versions. For instance, with an incremented integer or a timestamp and a reference to the previous version.

Remove data after complete validation only

Although, this does not guarantee that you will end up with a successful migration after the removal operation, this allows you to detect potential issues you have not forecast and facilitate reverting the changes.

✍️ E.g. only remove ‘address’ after you have correctly added ‘street_name’, ‘city’, ‘postcode’.

Check that everything is ok after the migration

Audit the database after migration
- Use a monitoring system to keep track of new errors.
Not seeing code or monitoring issue do not mean there is no issue ! Check it with business owners.
You can set-up end-to-end tests to avoid regressions.

🌟 What to remember?

These 6 guidelines are just an attempt to sum-up what to care about when applying data migrations. They can also apply to application deployments or whatever operation that introduces a breaking change. But the main learning could also be capitalize on knowledge to avoid reproducing the same mistakes !

Want to share your own tips or tech convictions? Don't hesitate to comment on this post 😉

Deploying Next.js 13 with Amplify CDK

Guillaume Égée — Thu, 12 Jan 2023 12:28:27 +0000

📜 How to deploy a Next.js app step by step with an Amplify CDK construct, avoiding you all the pains.

🐝 TLDR: an example app has just been added in swarmion, so you can now bootstrap a ready-to-use Next.js project!

Next.js is a popular React framework to deploy web apps with advanced features like Server Side Rendering (SSR), Image optimization or Incremental Static Regeneration (ISR). In my last project, I chose this framework notably to ensure a good SEO.

To deploy the app, I had the requirement to use AWS as a cloud-provider, with a limited budget, so neither Vercel (a safe choice, as it is the company which develops Next.js), nor a containerized solution like the managed AWS ECS Fargate service could satisfy my needs. Then, I started with a serverless hosting thanks to the serverless-next project, which provides a serverless plugin or a CDK construct to deploy a Next.js stack. However, this project is no more well-maintained and new Next.js features (like middlewares, etc.) are not supported.

Here comes AWS Amplify which has just announced on November 17th to support Next.js 12 and 13 🎉! Amplify is an AWS service to build and host full-stack applications. It uses serverless services under the hood. I tested it with @mamadoudicko and @alexandreperni4 and we will explain you how to setup a production-ready app!

Introducing Amplify's AWS CDK

AWS CDK, for AWS Cloud Development Kit, is a multi-languages framework for writing infrastructure as code and deploying it through AWS CloudFormation. Our examples will be written in Typescript, but other languages like Python, Java, C# or Go can be used as well.

To deploy with the AWS CDK, you would first need to declare a cdk.json file at the root of your frontend repository. This allows you to tell the AWS CDK where is the entry point of the CDK app, hosting/bin.ts here:

{
  "app": "pnpm ts-node hosting/bin.ts"
}

You need to install these dev dependencies:

pnpm add -D aws-cdk-lib
pnpm add -D @aws-cdk/aws-amplify-alpha
pnpm add -D constructs

You will also need some configuration files to bootstrap the app:

.nvmrc file to define your node version
tsconfig.json TypeScript configuration file, with target version set to "es6" or more

In the hosting folder, you then need to add a bin.ts file to declare the cdk app:

import * as cdk from 'aws-cdk-lib';

import { AmplifyStack } from './stack';

const app = new cdk.App();

new AmplifyStack(app, 'NextJsSampleStack', {
  description: 'Cloudformation stack containing the Amplify configuration',
});

Nothing fancy at this point, the interesting part is in the ./stack.ts configuration file:

import { App } from '@aws-cdk/aws-amplify-alpha';
import { aws_iam, CfnOutput, Stack, StackProps } from 'aws-cdk-lib';
import { BuildSpec } from 'aws-cdk-lib/aws-codebuild';
import { Construct } from 'constructs';

export class AmplifyStack extends Stack {
  constructor(scope: Construct, id: string, props: StackProps) {
    super(scope, id, props);

    // Define Amplify app
    const amplifyApp = new App(this, 'AmplifyAppResource', {
      appName: 'NextJS app',
      description: 'My NextJS APP deployed with Amplify',

      // ⬇️ configuration items to be defined ⬇️
      role,
      sourceCodeProvider,
      buildSpec,
      autoBranchCreation,
      autoBranchDeletion,
      environmentVariables,
      // ⬆️ end of configuration ⬆️
    });

    // Attach your main branch and define the branch settings (see below)
    const mainBranch = amplifyApp.addBranch('main', {
      autoBuild: false, // set to true to automatically build the app on new pushes
      stage: 'PRODUCTION',
    });

    new CfnOutput(this, 'appId', {
      value: amplifyApp.appId,
    });
  }
}

Let’s go through what we need for the different variables within the configuration object.

📖 Step-by-step guide

Define a role to Amplify (`role`)

This is needed to add a custom role that will be assumed by the Amplify resource.

import { ManagedPolicy, Role, ServicePrincipal } from 'aws-cdk-lib/aws-iam';

const role = new Role(this, 'AmplifyRoleWebApp', {
  assumedBy: new ServicePrincipal('amplify.amazonaws.com'),
  description: 'Custom role permitting resources creation from Amplify',
  managedPolicies: [ManagedPolicy.fromAwsManagedPolicyName('AdministratorAccess-Amplify')],
});

Connection to your Github repository (`sourceCodeProvider`)

The sourceCodeProvider configuration allows Amplify to access the source code of your application. To connect a Github repository, you can use the declaration below:

import { GitHubSourceCodeProvider } from '@aws-cdk/aws-amplify-alpha/lib/source-code-providers';
import { SecretValue } from 'aws-cdk-lib';

const sourceCodeProvider = new GitHubSourceCodeProvider({
  // GitHub token should be saved in a secure place, we recommend AWS Secret Manager:
  oauthToken: SecretValue.secretsManager('GITHUB_TOKEN_KEY'), // replace GITHUB_TOKEN_KEY by the name of the Secrets Manager resource storing your GitHub token
  owner: '<user name of the GitHub repository owner>',
  repository: '<name of the Github repository>',
});

To get a Github token, go to your Github account develop settings and generate a personal access token. Amplify will need quite high access rights to your repository as it will need to generate ssh keys to clone the repository.

To store the token in AWS, we recommend to use the AWS Secret Manager service. Be careful to choose a plain text secret (in the AWS console select "Store a new secret", "Other type of secret" and finally "Plaintext"). Choose a key name that matches the key used in the GitHubSourceCodeProvider construct (GITHUB_TOKEN_KEY in this example).

Build settings (`buildSpec`)

Then, you need to define how the app will be built. Below is an example with pnpm package manager:

import { BuildSpec } from 'aws-cdk-lib/aws-codebuild';

import { environmentVariables } from './environmentVariables';

export const buildSpec = BuildSpec.fromObjectToYaml({
  version: '1.0',
  applications: [
    {
      frontend: {
        phases: {
          preBuild: {
            commands: [
              // Install the correct Node version, defined in .nvmrc
              'nvm install',
              'nvm use',
              // Install pnpm
              'corepack enable',
              'corepack prepare pnpm@latest --activate',
              // Avoid memory issues with node
              'export NODE_OPTIONS=--max-old-space-size=8192',
              // Ensure node_modules are correctly included in the build artifacts
              'pnpm install',
            ],
          },
          build: {
            commands: [
              // Allow Next.js to access environment variables
              // See https://docs.aws.amazon.com/amplify/latest/userguide/ssr-environment-variables.html
              `env | grep -E '${Object.keys(environmentVariables).join('|')}' >> .env.production`,
              // Build Next.js app
              'pnpm next build --no-lint',
            ],
          },
        },
        artifacts: {
          baseDirectory: '.next',
          files: ['**/*'],
        },
      },
    },
  ],
});

This example is using pnpm, but you can choose to use any other package manager, such as npm or yarn. A few things to note here :

Setting the --max-old-space-size node option is important to prevent out of memory (OOM) errors while building your application when it reaches a certain size.
To let your server-side code access your environment variables, you have to include them in a .env.production file. This allows you to put secrets known only from your CI environment in the .env.production file created on the fly.
The artifacts section is very important as it configures which files from the build step will be included in the artifacts and thus available at run time.

Auto-deploy when remote branches satisfying a certain name pattern are created

Amplify allow to create a dedicated environment when you push to a branch with a specific name pattern.

import { AutoBranchCreation } from '@aws-cdk/aws-amplify-alpha';

export const autoBranchCreation: AutoBranchCreation = {
  autoBuild: true,
  patterns: ['feature/*'],
  pullRequestPreview: true,
};

You might want to disable the feature in production. For this, simply use undefined instead of this configuration.

💡 Note that this environment can be automatically removed once the branch is deleted if the parameter autoBranchDeletion is set to true.

Configuring environment variables

export const environmentVariables = {
  // https://docs.aws.amazon.com/amplify/latest/userguide/build-settings.html#enable-diff-deploy
  AMPLIFY_DIFF_DEPLOY: 'true',
};

💡 Environment variables can be defined globally or in branch environments.

Setting up a domain

You can add the domain configuration directly in the stack.ts file, to have access to the amplifyApp and mainBranch variables:

const domain = amplifyApp.addDomain('your-domain.com', {
  autoSubdomainCreationPatterns: ['feature/*'],
  enableAutoSubdomain: true,
});

Don't forget to map it with a specific branch by adding the following line:

domain.mapRoot(mainBranch);

💡 If the domain is already defined in AWS Route 53 service, it will be automatically linked to your stack: AWS will add the appropriate DNS records in the hosted zone. Otherwise, you will need to add the records manually in your domain name provider.

Deployment

Almost there! Before being able to detect and deploy Next.js, Amplify needs to be configured with the platform type WEB_COMPUTE. It needs to be done after Amplify app deployment. As there is no option in Cloudformation for now, the best way to do it programmatically is to use a Custom Resource construct:

import { AwsCustomResource, AwsCustomResourcePolicy } from 'aws-cdk-lib/custom-resource';

// Set Amplify platform type to WEB_COMPUTE
new AwsCustomResource(this, 'AmplifySetPlatform', {
  onUpdate: {
    service: 'Amplify',
    action: 'updateApp',
    parameters: {
      appId: amplifyApp.appId,
      platform: 'WEB_COMPUTE',
    },
    physicalResourceId: PhysicalResourceId.of('AmplifyCustomResourceSetPlatform'),
  },
  policy: AwsCustomResourcePolicy.fromSdkCalls({
    resources: [amplifyApp.arn],
  }),
});

💡 This construct is equivalent to a call to AWS SDK, that can also be written with an aws CLI command:

aws amplify update-app --app-id <yourAppID> --platform  WEB_COMPUTE

Finally, to deploy your AWS CDK app, navigate to the folder containing the cdk.json file, then enter the following command:

pnpm cdk bootstrap && pnpm cdk deploy

When the deployment ends successfully, the id of your Amplify app will be printed in your command line interface.

⚠️ This step only deploys an Amplify stack, but it does not build nor deploy the Next.js app yet! To do so, you can either:

Set the autoBuild parameter to true in a branch setting to deploy on GitHub pushes (or other source provider)

Use a webhook as explained below.

Adding a webhook

In many cases, a dedicated CI/CD platform is used to test and deploy an app. Then, the direct GitHub integration that triggers an Amplify build at each push on a particular branch is no more sufficient. So you may want to trigger a deployment directly in a CD step. Amplify allows to trigger a deployment with webhooks. This is not yet configurable through the CDK but you can use the Amplify CLI:

aws amplify create-webhook --app-id <yourAppID> --branch-name <yourBranchName>

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/amplify/create-webhook.html

In your CD, add curl [webhook url].

💡 Alternatively, you can use a Custom Resource construct to create your webhook:

// Create a webhook to use in your proper CI/CD
const webhookCustomResource = new AwsCustomResource(this, 'AmplifyWebhook', {
  onUpdate: {
    service: 'Amplify',
    action: 'createWebhook',
    parameters: {
      appId: amplifyApp.appId,
      branchName: 'main',
    },
    physicalResourceId: PhysicalResourceId.of('AmplifyCustomResourceWebhook'),
  },
  policy: AwsCustomResourcePolicy.fromSdkCalls({
    resources: [`${amplifyApp.arn}/webhooks/*`],
  }),
});

// Outputs the secret deployment webhook
webhookCustomResource.getResponseField('webhook.webhookUrl');

Other interesting features

Other configurations are available: custom response headers, custom rewrites and redirects or even basic authentication to prevent access to any test environment!

📚 Caveats with a monorepo

In a monorepo, additional configuration is required:

Add appRoot property in the build settings, with the frontend directory path.
Ensure node_modules are correctly included in the build. In the context of a monorepo, most package managers will put the node_modules at the root of your repository. A nice workaround, with pnpm, is to set the virtual store directory inside the frontend directory when installing the project: pnpm install --virtual-store-dir [your frontend directory]/node_modules/.pnpm

See swarmion full implementation example.

✨ Conclusion

If you plan to go on a monorepo architecture, you can already use Swarmion to create high scalable serverless application including Next.js latest version by simply running: pnpm create swarmion-app and choosing the Next.js option.

Swarmion will pre-configure all required settings so that your app will smoothly be deployed to amplify.

To complete, there are other Next.js deployment solutions which may be interesting to explore like:

Vercel (Next.js core team): probably the most user friendly infrastructure solution, if you can afford it on your project.
serverless-nextjs: very interesting initiative but seems no longer maintained unfortunately. The resources declared in this library are very similar to the one deployed by Amplify under the hood, which probably made it the cheapest solution around for a while.
OpenNext project which uses the NetJSite SST construct. A promising project, but still a work in progress. This one focuses on the connector between the Next.js framework and the infrastructure, but will not provide the infrastructure as code template.
JetBridge cdk-nextjs construct, another proposal to deploy Next.js with a construct.

Thanks a lot to @mamadoudicko, @alexandreperni4 and @Antoine Apollis who co-wrote this article and tested the setup process in this repository! We also relied a lot on this AWS blog article to build this guide.