Forem: RedRobot.dev

Deploy Next.js using Amplify & AWS CDK

RedRobot.dev — Mon, 25 Nov 2024 19:00:00 +0000

In this guide, we'll dive into the process of deploying a Next.js application using AWS CDK (Cloud Development Kit) and Amplify Gen 2. We'll explore how these powerful tools can be combined to create a seamless, serverless deployment pipeline for your Next.js projects. You'll learn how to leverage AWS CDK's infrastructure-as-code capabilities to define your cloud resources, while harnessing Amplify's built-in support for Next.js to simplify hosting and continuous deployment. By the end of this journey, you'll have a robust understanding of how to create scalable, easily maintainable Next.js deployments on AWS.

Original Post

redrobot.dev

In this comprehensive guide, we'll explore the process of deploying a Next.js application using AWS CDK (Cloud Development Kit) and Amplify Gen 2. We'll demonstrate how these tools can be combined to create a seamless, serverless deployment pipeline for your Next.js projects. You'll learn to harness AWS CDK's infrastructure-as-code capabilities to define and manage your cloud resources efficiently, while leveraging Amplify's specialized support for Next.js to streamline hosting and enable continuous deployment. By the end of this tutorial, you'll have gained a robust understanding of how to deploy your Next.js app to AWS.

Here is the github repo

AWS Amplify

AWS Amplify is a comprehensive service designed to simplify full-stack application development and deployment on AWS. It provides a unified, streamlined developer experience by abstracting away the complexity of managing multiple AWS services. Amplify leverages a suite of powerful AWS tools including S3, API Gateway, CodeBuild, Cognito, and Lambda, enabling developers to create robust infrastructure supporting their required features without needing deep expertise in cloud architecture.

One of Amplify's key strengths is its dedicated UI libraries for popular frameworks such as React, Next.js, Angular, and Vue, facilitating faster integration and development. The core concept behind Amplify is elegantly simple: using only TypeScript code, developers can express their app's data model, business logic, authentication, and authorization rules. Amplify then automatically configures the appropriate cloud resources, eliminating the need to manually stitch together underlying AWS services. This approach positions Amplify as a comprehensive, end-to-end full-stack development framework.

Amplify Gen 2 represents AWS's latest effort to further streamline the development process for full-stack applications. It builds upon the foundations of the original Amplify, offering enhanced features and improved performance. This new generation aims to make it even easier for developers to harness the power of AWS services, reducing the learning curve and allowing teams to focus more on building innovative applications rather than managing infrastructure. With Amplify Gen 2, AWS continues to bridge the gap between development and operations, empowering developers to create sophisticated, scalable applications with greater efficiency and less complexity.

Topics Covered in this guide

In this tutorial, we'll walk through the process of deploying and updating a Next.js application using AWS CDK and Amplify. We'll cover the entire workflow from initial development to automated deployment. Here's what we'll accomplish:

Create a Next.js application: We'll start by building a starter Next.js app that utilizes both Server-Side Rendering (SSR) and Static Site Generation (SSG) capabilities.
Version control with GitHub: We'll push our frontend code to a GitHub repository, setting the stage for continuous integration and deployment.
AWS CDK and Amplify setup: Using AWS CDK and Amplify libraries, we'll create an Amplify project that specifies the build steps and connects to our GitHub repository. This step will demonstrate how to define your cloud infrastructure as code.
Initial deployment: We'll trigger an initial deployment to test our setup and ensure everything is working correctly.
Implement and deploy changes: Finally, we'll make updates to our frontend, push these changes to GitHub, and observe how Amplify automatically detects and deploys these updates, showcasing the power of continuous deployment.

Prerequisites

An AWS account
Node.js and npm installed
AWS cli and cdk setup and configured
Basic knowledge in Javascript and Typescript

Github Project

Open up Github, create a new repo and name it nextjs-aws-amplify. See this repo as an example:
https://github.com/ababakanian/nextjs-aws-amplify

Pull the code locally (replace the username with yours)

git clone git@github.com:<your-user-name>/nextjs-aws-amplify.git

Get an access token

In addition, lets create an access token in github. Go to the Github Personal access token page page and click on Generate new token (classic)

select a name for the access token and from teh select scopes list select the repo option. Scroll down and click on Generate token.

Copy the generate token and lets add it to an env file.

cd nextjs-aws-amplify
touch .env

open the .env file and add a variable for the github token in the env file.
So your .env file should look this this.

GITHUB_ACCESS_TOKEN=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

Note: Do no copy this value, this is not going to work for you as it belongs to our repo and also it's been deleted.

Add the .env file to your .gitignore list, touch .env and then open the file and add .env.

Create a Next.js Project

Make sure you are in the nextjs-aws-amplify folder, then create a NextJS project. Open a terminal and type:

npx create-next-app@latest

enter frontend for the app name. Then you will be presented with several options, choose the options as you
see here:

Need to install the following packages:
create-next-app@14.2.5
Ok to proceed? (y) y

✔ What is your project named? … test-frontend
✔ Would you like to use TypeScript? … No / **Yes**
✔ Would you like to use ESLint? … No / **Yes**
✔ Would you like to use Tailwind CSS? … No / **Yes**
✔ Would you like to use `src/` directory? … No / **Yes**
✔ Would you like to use App Router? (recommended) … No / **Yes**
✔ Would you like to customize the default import alias (@/*)? … **No** / Yes

We will come back and modify the frontend code later. However, lets push this code to github and get the github config info.

git add .
git commit -m "initial commit, added frontend nextjs"
git push origin main

create a .nvmrc file and add the value nodejs.

echo "v20.11.1" > .nvmrc

Create AWS CDK

By leveraging an IaC system like AWS cdk, you can automate and replicate all the setup and configuration work typically done through the console. This approach significantly speeds up your website deployment process.

Initialize a new CDK project, make sure you are in the top level nextjs-aws-amplify folder created earlier. Then create an infrastructure folder and initialize it with cdk code.

mkdir infrastructure && cd infrastructure
cdk init app --language typescript

If you haven't setup cdk yet, visit [AWS CDK Getting started (https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html)

Install the amplify library

npm i @aws-cdk/aws-amplify-alpha@2.39.1-alpha.0 --save

Note: At the time of writing this post the library is in alpha stage. Check the npm page here to see if the version has left the alpha stage.

Install supporting libraries:

npm i dotenv --save

Create a file named in lib named lib/amplify-gen-stack.ts with the following content:

import * as amplify from "@aws-cdk/aws-amplify-alpha"

import { Construct } from "constructs"
import { CfnOutput, SecretValue, Stack, StackProps } from "aws-cdk-lib"
import { BuildSpec } from "aws-cdk-lib/aws-codebuild"
import { ManagedPolicy, Role, ServicePrincipal } from "aws-cdk-lib/aws-iam"
import { CfnApp, CfnBranch } from "aws-cdk-lib/aws-amplify"

export interface AmplifyStackProps extends StackProps {
  githubOauthToken: SecretValue
  repoOwner: string
  repoName: string
  domain: string
}

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

    const amplifyApp = new amplify.App(this, "AmplifyAppResource", {
      appName: props.repoName,
      description: "Nextjs frontend",
      role: new Role(this, "AmplifyRoleWebApp", {
        assumedBy: new ServicePrincipal("amplify.amazonaws.com"),
        managedPolicies: [
          ManagedPolicy.fromAwsManagedPolicyName("AdministratorAccess-Amplify"),
        ],
      }),
      sourceCodeProvider: new amplify.GitHubSourceCodeProvider({
        oauthToken: props.githubOauthToken,
        owner: props.repoOwner,
        repository: props.repoName,
      }),
      buildSpec: BuildSpec.fromObjectToYaml({
        version: "1.0",
        applications: [
          {
            appRoot: "frontend",
            frontend: {
              phases: {
                preBuild: {
                  commands: [
                    "nvm install",
                    "nvm use",
                    "export NODE_OPTIONS=--max-old-space-size=8192",
                    "npm install",
                  ],
                },
                build: {
                  commands: ["npm run build"],
                },
              },
              artifacts: {
                baseDirectory: ".next",
                files: ["**/*"],
              },
            },
          },
        ],
      }),
    })

    const cfnApp = amplifyApp.node.defaultChild as CfnApp
    cfnApp.platform = "WEB_COMPUTE"

    const mainBranch = amplifyApp.addBranch("main", {
      autoBuild: true,
      stage: "PRODUCTION",
    })

    const domain = amplifyApp.addDomain(props.domain, {
      enableAutoSubdomain: true,
    })
    domain.mapRoot(mainBranch)
    domain.mapSubDomain(mainBranch, "www")

    const cfnBranch = mainBranch.node.defaultChild as CfnBranch
    cfnBranch.framework = "Next.js - SSR"

    new CfnOutput(this, "AmplifyAppURL", {
      value: `https://main.${amplifyApp.defaultDomain}`,
      description: "Amplify App URL",
    })
  }
}

The amplify.App construct has two main parts, the source code repo configuration and the build instructions.
We define the code repo location using

sourceCodeProvider: new amplify.GitHubSourceCodeProvider({
  oauthToken: props.githubOauthToken,
  owner: props.repoOwner,
  repository: props.repoName,
})

and we define the build and artifacts information:

buildSpec: BuildSpec.fromObjectToYaml({
    version: "1.0",
    applications: [
      {
        appRoot: "frontend",
        frontend: {
          phases: {
            preBuild: {
              commands: [
                "nvm install",
                "nvm use",
                "export NODE_OPTIONS=--max-old-space-size=8192",
                "npm install",
              ],
            },
            build: {
              commands: ["npm run build"],
            },
          },
          artifacts: {
            baseDirectory: ".next",
            files: ["**/*"],
          },
        },
      },
    ],
  }),
})

essentially we are installing node, and installing all the node packages in the prebuild step. Then we run npm run build to build the nextjs app.
The artifacts section specifies where our external files will be located.

To learn more check the AWS cdk Documentation

Lets use the stack in our bin/infrastructure.ts file:

#!/usr/bin/env node
import "source-map-support/register"
import * as cdk from "aws-cdk-lib"
import * as dotenv from "dotenv"
import { AmplifyStack } from "../lib/amplify-gen-stack"

dotenv.config({ path: "../.env" })

const {
  AWS_ACCOUNT_ID,
  AWS_REGION,
  DOMAIN,
  GITHUB_ACCESS_TOKEN,
  GITHUB_REPO_OWNER,
  GITHUB_REPO_NAME,
} = process.env

if (
  !AWS_ACCOUNT_ID ||
  !AWS_REGION ||
  !GITHUB_ACCESS_TOKEN ||
  !GITHUB_REPO_OWNER ||
  !GITHUB_REPO_NAME ||
  !DOMAIN
) {
  console.error("check .env file")
  throw new Error("check .env file")
}

const app = new cdk.App()
new AmplifyStack(app, "AmplifyStack", {
  githubOauthToken: cdk.SecretValue.unsafePlainText(GITHUB_ACCESS_TOKEN),
  repoOwner: GITHUB_REPO_OWNER,
  repoName: GITHUB_REPO_NAME,
  domain: DOMAIN,
  env: {
    account: AWS_ACCOUNT_ID,
    region: AWS_REGION,
  },
})

add the remaining variable to the .env file we created earlier:

AWS_ACCOUNT_ID=AWS account number
AWS_REGION=your deployment region
DOMAIN=your domain name
GITHUB_REPO_OWNER=the github repo owner
GITHUB_REPO_NAME=the repo name
GITHUB_ACCESS_TOKEN=the github access token

so your data should look something like this;

AWS_ACCOUNT_ID="975421487117"
AWS_REGION="us-east-1"
DOMAIN=redrobotexample.com
GITHUB_ACCESS_TOKEN=ghp_KGu0GbvmdOiFNUzK6mGGFRBxBMM3rc1sTq0C
GITHUB_REPO_OWNER=redrobotdev
GITHUB_REPO_NAME=nextjs-aws-amplify

now deploy the stack, make sure you are in the infrastructure folder then call deploy.

cd infrastructure
cdk deploy

Once deployment, you will see the following message in the console

AmplifyStack: creating CloudFormation changeset...

 ✅  AmplifyStack

✨  Deployment time: 51.82s

Outputs:
AmplifyStack.AmplifyAppURL = https://main.dqsf8v3g3qb5.amplifyapp.com
Stack ARN:
arn:aws:cloudformation:us-east-1:975050147627:stack/AmplifyStack/3e7e4c70-58c9-11ef-bff5-121072f7c15f

✨  Total time: 56.97s

Deploy the Application

So we have successfully created an Amplify project, we need to go to teh AWS console and start a deployment.
Go to the AWS Console page, and open the AWS Amplify service page. You should see the nextjs-aws-amplify, project listed.

Click on the project and if you see a Migrate to Github app message, ignore it by clicking Remind me later.

Click on the main branch

Then click on the Run job button

Wait until the Deployments is done

Once deployed, the box should go green, and the status should say deployed

visit the domain name and you should see the Nextjs page.

Update the frontend

Amplify has CI/CD integrated into it's system, so we can make changes to our frontend and push our changed directly to github. Amplify will get notified of a recent push, and it will automatically pull the code, build and redeploy it.

Lets first install shadcn in our frontend. make sure you have traversed into the frontend folder cd frontend.

npx shadcn-ui@latest init

then install the card and button components

npx shadcn-ui@latest add card button

Open the file from the same frontend folder /src/app/page.tsx:

import Image from "next/image"
import Link from "next/link"

export default function Home() {
  return (
    <main className="flex min-h-screen flex-col space-y-4 items-center p-24">
      <Image
        className="relative dark:drop-shadow-[0_0_0.3rem_#ffffff70] dark:invert"
        src="/next.svg"
        alt="Next.js Logo"
        width={180}
        height={37}
        priority
      />
      <Link href="/invoice" className="underline">
        Invoice
      </Link>
    </main>
  )
}

Lets create a new folder named invoice and page.tsx so you have the path nextjs-aws-amplify/src/app/invoice/page.tsx. Paste the following content in there:

export const dynamic = "force-dynamic"
import React from "react"
import { Card, CardContent, CardHeader, CardTitle } from "@/components/ui/card"
import { Button } from "@/components/ui/button"
import Link from "next/link"

export default async function FinancePage() {
  const income = Math.floor(Math.random() * 100000) + 50000 // Random income between 50,000 and 150,000
  const profit = Math.floor(Math.random() * (income * 0.3)) // Random profit up to 30% of income

  return (
    <div className="container mx-auto p-4">
      <h1 className="text-2xl font-bold mb-4">Financial Dashboard</h1>
      <Link href="/">
        <Button className="mb-4">Home</Button>
      </Link>
      <div className="grid grid-cols-1 md:grid-cols-2 gap-4">
        <Card>
          <CardHeader>
            <CardTitle>Income</CardTitle>
          </CardHeader>
          <CardContent>
            <p className="text-3xl font-bold">${income.toLocaleString()}</p>
          </CardContent>
        </Card>
        <Card>
          <CardHeader>
            <CardTitle>Profit</CardTitle>
          </CardHeader>
          <CardContent>
            <p className="text-3xl font-bold">${profit.toLocaleString()}</p>
          </CardContent>
        </Card>
      </div>
    </div>
  )
}

commit and push the changes

git add .
git commit -m "added the invoice page"
git push origin main

from the AWS console/Amplify Service page you will see a new deployment has started. Make sure the deployment goes through fine and refresh the website to see the affected changes.
Verify the changes has taken affect and you can see the invoice page.

Note: The home page is a Static page so it's not showcasing the power of amplify serverless nextjs deployment. Go to the invoice page and refresh the page and you will notice on each refresh the values changes. This page is Server Side Rendered and demonstrates the server side rendering capability of Next.js.

Conclusion

In this short guide, we've walked through the process of deploying a simple Next.js page using AWS CDK and Amplify Gen 2. We've covered everything from setting up a Next.js project and managing it with GitHub, to creating an AWS CDK stack for Amplify deployment, and finally implementing and automatically deploying updates. By leveraging the power of AWS CDK's infrastructure-as-code capabilities and Amplify's streamlined deployment pipeline, we've demonstrated how to create a scalable, easily maintainable Next.js application on AWS. This approach not only simplifies the deployment process but also enables continuous integration and deployment, allowing developers to focus more on building innovative features rather than managing infrastructure.

Interested in learning more?

If you are interested in creating a project from scratch using AWS CDK and serverless technologies, you can check out the course linked below. In this course, we go over each service in detail, explaining what they do, and actually create a dynamic application with user login and authentication.

Serverless Fullstack with AWS/CDK/NextJS & Typescript

Next.js Deployment using ECS with Fargate

RedRobot.dev — Mon, 18 Nov 2024 19:00:00 +0000

In this post, we'll explore how to deploy a Next.js application to AWS using Elastic Container Service (ECS). We'll cover two approaches: first, using the AWS Management Console, and then using AWS CDK (Cloud Development Kit). Throughout this process, you'll gain a comprehensive understanding of ECS and its key concepts.

Original Post

redrobot.dev

Elastic Container Services

Amazon Elastic Container Service (ECS) is a powerful container orchestration service that simplifies the process of deploying, managing, and scaling containerized applications. With ECS, you can upload your Docker image and run it in a highly scalable, high-performance, and resilient environment that automatically handles load balancing and auto-scaling for you.
ECS integrates seamlessly with other AWS services such as Application Load Balancer (ALB) and Virtual Private Cloud (VPC) to provide the scalability and load balancing capabilities your application requires. As a comprehensive container orchestration solution, ECS offers the following key features:

Auto-scaling: Automatically adjusts the number of containers based on demand
Load balancing: Distributes incoming traffic across multiple containers
IAM integration: Manages access control and permissions
Networking: Provides flexible networking options through VPC integration
Logging: Offers built-in logging capabilities for easy troubleshooting
Monitoring: Enables real-time monitoring of your containerized applications

This robust set of features makes ECS an excellent choice for running and scaling Docker containers on AWS, providing you with a reliable and efficient platform for your containerized applications.

Before diving into ECS, it's important to understand two key concepts:

Virtual Private Cloud (VPC): If you're not familiar with VPC, we recommend reading our "AWS Virtual Private Network Explained" post. This will provide you with the necessary background information to effectively use ECS.
Containerization: To use ECS, we need to containerize our Next.js application using Docker. If you're new to Docker and containers, our "Next.js Containerization" post explains what containers are and how to containerize and run a Next.js app.

Additionally, it's worth noting that an Application Load Balancer (ALB) is typically used when you have more than one task and need to route packets for high-availability deployments. The ALB distributes incoming application traffic across multiple targets, such as EC2 instances, in multiple Availability Zones.

Architecture

This is the typical ECS deployment, and in this post we will be creating the following architecture.

Don't worry if this architecture seems complex at first glance—we'll guide you through creating it without delving into low-level details. Here's a simplified overview of how it works:

Clients send HTML page requests through the Internet Gateway.
These requests are received by an Application Load Balancer (ALB).
The ALB forwards the requests to one of the Next.js tasks.
These tasks are managed by AWS Fargate and Elastic Container Service (ECS).
During deployment, the Next.js image is loaded from Elastic Container Registry (ECR).

This setup ensures efficient distribution of incoming traffic and seamless management of your containerized Next.js application.

Using Console

Upload image to AWS

First step is to build and upload our container image to AWS ECR or the Elastic Container Registry.

Follow the steps described here to build and run a docker container of a Next.js application.

To verify you have correctly built the image, run the following command and verify you see a similar output

$ docker image ls
REPOSITORY                  TAG       IMAGE ID       CREATED      SIZE
nextjs-frontend             latest    f42f21949703   4 days ago   738MB

Create a Register in the ECR console. Open the AWS Console and go to the ECS service page. From the left panel, click Repositories, then create Create repository.

Select private for the visibility settings, and type in nextjs-frontend for the repository name.

Now lets upload the image to ECR, first you need to get an authentication token for each registry. run this to do that:

replace the two "<region>" and the one "<aws_account_id>" values with yours.

aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<region>.amazonaws.com

so it should look something like this:

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 975050147627.dkr.ecr.us-east-1.amazonaws.com

then tag your local image, with the name of the remote repository name, replace the command with the correct region and account id:

docker tag nextjs-frontend <aws_account_id>.dkr.ecr.<region>.amazonaws.com/nextjs-frontend:lastest

so something like this:

docker tag nextjs-frontend 975050147627.dkr.ecr.us-east-1.amazonaws.com/nextjs-frontend:lastest

to verify run docker image ls and you should see a secondary image with the name you entered above.

to finally push your image run:

docker push <aws_account_id>.dkr.ecr.<region>.amazonaws.com/nextjs-frontend:lastest

so something like this:

docker push 975050147627.dkr.ecr.us-east-1.amazonaws.com/nextjs-frontend:lastest

once pushed, you should see the following output:

The push refers to repository [975050147627.dkr.ecr.us-east-1.amazonaws.com/nextjs-frontend]
947f16d41eae: Pushed
df7925d45941: Pushed
f0d00ab152e9: Pushed
5e60551565b3: Pushed
f7561880256e: Pushed
60fb86bbe6c7: Pushed
dc01ec349cf7: Pushed
f87675c73d4d: Pushed
28576ee1ff32: Pushed
daa732f7b271: Pushed
7cc8f366b357: Pushed
78561cef0761: Pushed
latest: digest: sha256:4143d5b35602520f3f22b84cd3e15b90c6bbe1d315a44ad7b19a93791eb41266 size: 2821

You can read the "Pushing a Docker image to an Amazon ECR private repository" article from AWS for more detailed explanation or if you are having trouble with the steps.

Defining a VPC

Follow the instructions in AWS Virtual Private Network Explained to create a default VPC using the VPC and more option. Name your vpc something like nextjs-vpc. By the end you should have a VPC with two AZ's, with one public and one private subnet per AZ, with 3 routing tables, one connected to a IG and two isolating the private subnets, and we don't need a VPC endpoint for this.

If you are new to Virtual Private Cloud (VPC) read AWS Virtual Private Network Explained and follow the instructions. IF you are familair with VPC, create a VPC and use the "VPC and more" option to create a default VPC. Name your VPC something descriptive, such as "nextjs-vpc".

After completing these steps, your VPC should have the following configuration:

Two Availability Zones (AZs)
One public subnet and one private subnet per AZ
Three routing tables, One connected to an Internet Gateway (IG), Two isolating the private subnets
No VPC endpoint (not needed for this setup)

This configuration provides a secure and scalable network foundation for your ECS deployment.

Defining a Task Definition

To prepare your application to run on Amazon ECS, you need to create a task definition.
Task definitions specify various parameters for your application such as:

Containers to use (up to a maximum of 10 that form your application)
Launch type to use (such as Fargate or EC2)
Inbound ports that need to be opened for your application
Data volumes to be used with the containers in the task
Additional launch type-specific parameters

Task definitions act as a blueprint for your application, defining how it should run within ECS. They allow you to specify resource requirements, network configurations, and other crucial settings that determine how your containerized application will operate.

Here is an example of a task definition containing a single container that runs an NGINX web server using the
the Fargate launch type.

{
    "family": "webserver",
    "containerDefinitions": [
        {
            "name": "web",
            "image": "nginx",
            "memory": "100",
            "cpu": "99"
        }
    ],
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "networkMode": "awsvpc",
    "memory": "512",
    "cpu": "256"
}

Lets define a task definition. Go the ECS Service page, from the left panel select Task definition.

Click on the Create new task definition, then select the Create new task definition so we can explore some of the properties.

Note: One of the reason why it's important to know how to use the AWS console is to explore properties and options surrounding services and also learning how to debug the configuration settings.

For the Task definition family enter a name such as nextjs-frontend-task.
The next section is the Infrastructure requirements section. For this section select AWS Fargate for the Launch type.

Select Linux/x86_64 for the operating system/architecture.
For the Task size select, a CPU size of 0.5vCPU and 1GB for the Memory size.
Set the Task role to None.

AWS Fargate is a serverless compute engine for containers that works with Amazon ECS. It offers several key advantages:

Serverless Operation: Fargate allows you to run containers without managing servers or clusters.
Simplified Management: You no longer need to provision, configure, or scale clusters of virtual machines to run your containers.
Reduced Complexity: Fargate eliminates the need to:

Choose server types
Decide when to scale your clusters
Optimize cluster packing

Focus on Applications: With infrastructure management handled by Fargate, you can concentrate on designing and building your applications.

In essence, Fargate abstracts away much of the underlying infrastructure complexity, allowing you to deploy and run containerized applications more easily and efficiently on Amazon ECS.

For the Container - 1 section, specify something like nextjs-frontend for the name, and the Image URI is the ECR docker image URI that we used earlier. So it should be something like this:

<aws_account_id>.dkr.ecr.<region>.amazonaws.com/nextjs-frontend:lastest

you can find this URL from the ECR Service page, by clicking on the Repository, and the nextjs-frontend image name. The following page will be displayed with the URI value in the Details section. Copy the value by clicking on the double square icon:

Then add the value to the Image URI value of the ECS page.
For the Port mappings specify port 3000 as that is our default Next.js port number.

Don't specify anything for the Resource allocation limits.

Explore the remaining optional configurations, but don't change any settings.
Click Create to finish.

Create Cluster

A Logical grouping of tasks or services.
The services can include, EC2 launch types, containers, capacity providers, fargate launch types.
What is it for?

A regional grouping of one or more container instances where you can run task requests.
Each account receives a default cluster the first time you use the Amazon ECS service,
but you may also create other clusters. Clusters may contain more than one instance
type simultaneously.

Now lets create a cluster, from the left panel click Clusters, then click on Create cluster.
In the cluster create view, specify the cluster name nextjs-frontend-cluster and select AWS Fargate (serverless) for the infrastructure.

Click Create to finish.

Create Task

So we have our Task Definition, our cluster now we need to create a task. First, lets create a single task and run it, then check to verify the container is working. Then we

Click on the cluster created in the last step nextjs-frontend-cluster

Select the Tasks tab on the bottom, and click on Run new task.
In the Create view go to the Deployment configuration section

for the Family value, specify the task definition we specified earlier and set the number of desired tasks to 1.

In the Networking section, select the VPC nextjs-vpc created in the first part.
Clear the current subnet select, and from the new list, select to add the two public subnets.

For the security group, create a new group and set port 3000 to be opened. You can name the security group port-3000 for easy reading.

Leave the Public IP enabled.

Click Create and in the next screen, wait until the Last status value changes to Running. Once Ready, click on the Task to view the details

From the task details view, in the Networking tab, copy the public IP

Open a new tab, and paste the IP, appending the port number :3000 at the end.
You should see the Next.js landing page

We verified that our Task definition works and that if we deploy a task, the page loads and works fine.
Now select the task from the cluster details view, and click Stop to destroy the task. In the next step we are going to create a service that will automatically create multiple tasks.

Create Service with a Load Balancer

Now that we verified that the task is working, we can move on and create a service. A Service defines or encapsulates multiple tasks and it's typically created with a load balancer to route requests to different tasks. In addition to encapsulating tasks, the Service has a scheduler which maintains a desired count of tasks, so if a task fails and exits, or the health check is not responding, it will launch a new task and route traffic to the new task.

To create a Service, go to the Cluster details view and select the Services tab this time instead of the Tasks tab.
Click Create and you will see a similar view to the Task creation page.

Scroll down to the Deployment configuration section and make sure the Application type is Service. For the Family select the same task as before nextjs-frontend-task, and set the service name to nextjs-frontend-service. The set the Desired tasks count to 2.

In the Networking section, select the VPC nextjs-vpc created in the first part. Clear the current subnet select, and from the new list, select the two public subnets. Also make sure to add the port-3000 and port-80 to the security group. Also turn on the Public IP option if not already enabled.

We can stop here and click Create, but there is no point for a Service without a load balancer, especially for tasks that are not accessible.
Scroll down to the Load balancing optional section.

For the Load balancer type select Application load balancer. The container, should get automatically populated with nextjs-frontend 3000:3000. Under the application load balancer. Select the Create a new load balancer and for the load balancer name Type in nextjsalb. On the bottom, where it says listener make sure that create new listener options is selected and the port is set to 80 with the protocol as HTTP. And for the target group, make sure the create new target group is selected and leave all values as is. The protocol should say HTTP And the health check protocol should say also HTTP with the health check path set to by default to "/".

Click create. This will take a bit longer since it's creating several resources.
Once done, open the clusters services tab select the service we just created, it should have the name nextjs-frontend-service. Then on the top, select the configure and networking tab And scroll down to the network configurations section. On the right side of that section you will see a DNS value. You can click on open address or copy the address and paste it in a new tab.

If you follow the instructions correctly, you will see the Nextjs default page load. The difference between this method and the method of deploying one task is that now we have a load balancer that is listening on port 80 and it is routing traffic to two separate tasks or containers that are running our nextjs app, and it will use A routing strategy to forward traffic to either task.

Using AWS CDK

By leveraging IaC, you can automate and replicate all the setup and configuration work typically done through the console. This approach significantly speeds up your website deployment process.

Lets automate all of the steps we took using AWS CDK, which is an IaC or Infrastructure as code framework. All the steps we performed manually it can be automated and also we can add logic as well so based on some condition, ie if it's a production deployment we can add a few other steps vs if it's a test deployment we can skip a few other steps.

Prerequisites

An AWS account
Node.js and npm installed
AWS cli and cdk setup and configured
Basic knowledge in Javascript and Typescript

Setup, Code and Deploy

Initialize a new CDK project:

mkdir temp-project && cd temp-project
mkdir infrastructure && cd infrastructure
cdk init app --language typescript

Replace the content of the file lib/infrastructure-stack.ts with:

import * as cdk from "aws-cdk-lib"
import * as ecs from "aws-cdk-lib/aws-ecs"
import { Construct } from "constructs"
import { IpAddresses, Vpc } from "aws-cdk-lib/aws-ec2"
import { ApplicationLoadBalancedFargateService } from "aws-cdk-lib/aws-ecs-patterns"
import { ApplicationProtocol } from "aws-cdk-lib/aws-elasticloadbalancingv2"

export class InfrastructureStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)
    const vpc = new Vpc(this, `${id}-vpc`, {
      vpcName: `${id}-vpc`,
      ipAddresses: IpAddresses.cidr("10.0.0.0/16"),
      maxAzs: 2,
    })

    const cluster = new ecs.Cluster(this, `${id}-cluster`, {
      clusterName: `${id}-cluster`,
      vpc,
    })

    const fargateService = new ApplicationLoadBalancedFargateService(
      this,
      `${id}-fargate`,
      {
        serviceName: `${id}-fargate-service`,
        loadBalancerName: `${id}-fargate-lba`,
        cluster,
        cpu: 512,
        memoryLimitMiB: 1024,
        protocol: ApplicationProtocol.HTTP,
        desiredCount: 1,
        publicLoadBalancer: true,
        taskImageOptions: {
          image: ecs.ContainerImage.fromAsset("../nextjs-frontend"),
          containerName: `${id}-container`,
          containerPort: 3000,
        },
      }
    )

    // Output the load balancer URL
    new cdk.CfnOutput(this, `${id}-url`, {
      value: fargateService.loadBalancer.loadBalancerDnsName,
    })
  }
}

now deploy the stack

cdk deploy

Once deployment, you will see a message in the console that has the load balancers DNS name. Copy paste the value and paste it in a browser and you should see the same Next.js landing page.
And to destroy all the resources just run

cdk destroy

And enter y to confirm you want to delete. And that is it! all resource will been destroyed according to the dependency tree CDK keeps track of.

Conclusion

This guide has walked through the process of deploying a Next.js application to AWS using Elastic Container Service (ECS), demonstrating both manual deployment via the AWS Console and automated deployment using AWS CDK. By containerizing the Next.js app and leveraging ECS, developers can create a scalable, high-performance infrastructure that takes advantage of features like auto-scaling and load balancing. The manual process provides a deep understanding of the components involved - from ECR for image storage to task definitions, clusters, and services - while the CDK approach showcases how Infrastructure as Code can streamline and automate the entire deployment process. Whether you choose the hands-on console method or the efficient CDK route, this guide equips you with the knowledge to deploy and manage containerized Next.js applications on AWS, setting the foundation for robust, cloud-native web applications.

Interested in learning more?

Serverless Fullstack with AWS/CDK/NextJS & Typescript

Resources

AWS official ECS workshop has a great walkthrough
https://ecsworkshop.com/introduction/ecs_basics/

A Beginners Guide to AWS (VPS) Virtual Private Cloud

RedRobot.dev — Mon, 11 Nov 2024 19:00:00 +0000

In this tutorial based guide we will go over what VPC is, why it exists, and when and why should you consider using it in your cloud architecture.

Original Post

redrobot.dev

Virtual Private cloud

AWS VPC (Amazon Virtual Private Cloud) is one of the key networking service provided by AWS. VPC allows you to create an isolated section of the AWS cloud where you can launch resources in a defined virtual network.

VPC creates a separation between your resources and other Amazon resources. You can control if outside traffic should flow into your VPC using an Internet Gateway.

VPC mainly provide security for your infrastructure. They provide a layer of network isolation, allowing you to control access to your resources and protect them from unauthorized access.

Also you can customize your network using VPC, by controlling the network traffic paths, optimize data transfers to reduce cost and organize resources for better management.

In this post we will create a VPC using AWS console, go over routing tables, internet gateway and finally recreate the network structure using AWS CDK.

Use Case 1: A 3-tier Architecture

Let's take the following example: We are tasked to create a Saas (Software as a Service) application that has a web interface giving users the capability to select a list of countries, cities, days of week and a button to generate weather video sequence similar to what you see in news broadcasts.

At minimum, such a system would require to have the following components:

REST API to handle video render requests
storage to hold videos
video rendering engine
frontend application that users can input the country, city and days and request for a video

The block diagram would look something like this:

Using VPC, we can organize and secure our component by placing them into different areas of the network. So for our example, the user facing services (REST API, frontend), would need to go into the public subnet where users would need to access it, and the rest inside private networks.

REST API (public subnet)
frontend application (public subnet)
render engine, storage, database (private subnet)

Here is a typical VPC structure,with a public and a private subnet and other components which we can ignore for now. The public subnet has access to the internet via an internet gateway and the private subnet doesn't. However, the devices or IP's located in both the private and public can access each other.

organizing our components into network segments would look like this:

Important
This example is not entirely accurate, it's meant to convey the idea.

Use Case 2: Remote Company

The second example we'll explore is a scenario where a company hosts its infrastructure on AWS. In this case, remote workers need to access company resources such as Jira, Jenkins, Confluence, Database and other internal tools. To achieve this securely, they would need to VPN into a VPC. Once connected, they gain access to all the company resources within that VPC.
Implementing VPN Access
To enable this setup, you would need to create an AWS Client VPN endpoint and configure VPN access to your VPC. This allows remote workers to securely connect to the company's network.

This VPN method can also be used to access internal resources like databases when you need to perform specific queries or maintenance requiring direct access. However, it's important to note that this approach should be used cautiously, as it can pose security risks if not properly managed. For small teams and applications, though, it can be a convenient and practical solution.

There are several ways to establish connectivity with your VPC:

AWS Direct Connect: Ideal for connecting an on-premises data center or large database to an AWS VPC. This provides a dedicated, private connection.
Site-to-Site VPN: Useful when you need a constant connection between your company's network and a VPC. This creates an encrypted tunnel between your on-premises network and AWS.
AWS Client VPN: This is the solution for remote workers who need to VPN into the VPC and access company resources from various locations.

We won't delve deeper into this use case, as it's primarily an IT infrastructure solution for companies rather than a typical setup for software hosting or Software as a Service (SaaS) applications. However, understanding these options is valuable for comprehensive cloud architecture knowledge.

Creating a VPC

Using console

Open the AWS Console and go to the VPC page.

Click VPCs or the Your VPCs button from the left side, to view the VPC. The other buttons are all related to VPC, it's broken down into categories for organization sake. So when you create a VPC, you can also create subnets which will list those in the Subnet section as well.

Click on the first VPC line from the list if you have many.

Note: If you are just starting off, you should only see one VPC which is the default VPC created along when you first create your AWS account.

Warning: Switch your region, and you should see separate VPC's exist for each of your regions. If you don't want to mess up any existing stack or resources, select another region from the top, typically a region that you won't normally be using.

Click on Create VPC from the top. You should see the Create VPC page showing up.

Select VPC and more, and you should see the following diagram on the right side:

With this option a typical VPC will be created, so lets describe what is being created for us.

Subnets

In the subnets section, it shows there are two Availability Zone (AZ) us-east-1a and us-east-1b.

Note: If your region is different, it would say something like your-region-1a, your-region-1b, your-region-1c or something similar.

An AZ is one or more discrete data centers with redundant power networking, and connectivity in an AWS Region. So it's better to deploy your instance in such a way it gets replicated in multiple AZs, in case if something goes wrong in one data center - that way your application is highly available and more robust.

You can reduce or increase the number of zones used in this setup from the left panel Number of Availability Zones (AZs) section. You can pick how many zones you want to add, or click customize AZs to specify which zones you want to create subnets in.

There are two subnets per each AZ, a private and public subnet.
The Blue icon means private and the Green one means public.

You can also control the number of public and private subnets you want per zone by changing the values for Number of public subnets and Number of private subnets.

Note: If your change the number of AZ's the value or options for the public and private subnet count changes as well. Meaning if you select 1 AZ, then the options for the public subnets will change to 0 and 1.

Route tables

The next box shows the Route tables.

Route tables conceptually are the very similar to the routing tables that are common networking routers. A routing table is set of rules, that determines how packets get redirected when traveling over an Internet Protocol (IP) stack.

So if you mouse over the first entry you will see this connection:

You will see that our two public subnets use the first routing table, and the other two private subnets each have their own route table. The blue line shows that the public route table is also connected to a igw or an internet gateway.

We will go over the details of these route table in the next section but just understand that when packets travel between subnets, they first lookup the routing table to see which interface they have to go to. If a packet is targeting an outside IP like Google DNS (8.8.8.8), the routing table would direct the packet to an internet gateway. If the packet is targeting a database that is located in the private subnet (192.168.0.100), it will redirect the packet internally to the server that is running the database.

Network Connections

The last section is the Network connections that right now there are two options:

The first item is an internet gateway which allows traffic from and to the internet to be reachable to hosts belonging to this subnet.

The second item is an VPC endpoint which allows your internal services to communicate with other AWS services like S3, DynamoDB, SQS, SNS, RDS, SageMaker and etc without the traffic leaving the Amazon network. This option is favorable to have since it reduces latency and cost.

On the bottom of the page click Create VPC to create the VPC.
After the VPC is created, rename the newly created vpc to something you would remember like test-vpc.

Testing our VPC with EC2 Instances

To test our VPC, lets launch two EC2 instance and place one in the public subnet, and the other in the private subnet on our newly created VPC. We are going to verify to make sure we cannot connect to the EC2 machine in the private subnet, but can connect to the one in the public subnet. We also want to make sure we can connect to the EC2 machine in the private subnet from the public EC2 machine.

Lets start creating our EC2 instances. Open a new tab to AWS Console, and bring up the Amazon EC2 dashboard. Create a new instance by clicking the “Launch Instance” button.

Create an instance named Public Linux Machine and select the default Amazon Linux based systems so we can SSH into each machine.

Important: Make sure to select a key pair or create a new one, and use the same for both machines.

Note: If you are not familiar with EC2 instance creation and would like to learn more, visit the official docs here for more info.

Under the Network Settings, click Edit and then choose test-vpc for the VPC value. Then from the subnets select a public one and enable the Auto-assign public IP.

For the Security group name, set test-vpc-linux-machine-sg and open SSH and HTTP ports. See the screenshot for a better idea:

Create another one using similar configuration, except name the instance Private Linux Machine, select the same key pair for this instance.
Under the Network Settings, select the same VPC test-vpc, but instead of the public subnet, select the private subnet.
For the security groups, select Select existing security group then from the list select text-vpc-linux-machine-sg.

Click on launch instance to create the instance, then click View Instances. You should see two instance like so:

Lets try to connect to both EC2 machine using the terminal.
To be certain that you are connecting to the right machine, right click on the machine, select connect and go to the ssh tab. In the end of the view, copy the ssh command, it should look like this.

Public Linux Machine:

ssh -i "test-ec2-key.pem" ec2-user@ec2-44-192-99-181.compute-1.amazonaws.com

Private Linux Machine:

ssh -i "test-ec2-key.pem" ec2-user@ec2-34-239-251-67.compute-1.amazonaws.com

You will notice that you will not (and shouldn't) be able to connect to the second machine since it's in a private network.

Before doing that we need to copy the PEM file to the public EC2 instance.
This will copy the pem file so we can use it to SSH into the private ec2 machine.

scp -i "test-ec2-key.pem" test-ec2-key.pem ec2-user@ec2-3-230-118-6.compute-1.amazonaws.com:.

You need to find the private address of the other EC2. We can do that by selecting the EC2 from the EC2 dashboard and reading the private IP address.

Now ssh back to the public machine,

ssh -i "test-ec2-key.pem" ec2-user@ec2-44-192-99-181.compute-1.amazonaws.com

and from within the EC2 instance, ssh into the private EC2 instance using the private IP address.

ssh -i "test-ec2-key.pem" 10.0.135.0

You should be able to connect to the machine - verify you have SSH'ed into a new device by running ifconfig and viewing the IP address.

Important: Make sure to delete all resources once you are done testing out. First delete all the EC2 instances, then delete the VPC.

Using AWS CDK

By leveraging IaC, you can automate and replicate all the setup and configuration work typically done through the console. This approach significantly speeds up your website deployment process.

Lets automate all of the steps we took using AWS CDK, which is an IaC or Infrastructure as code framework. All the steps we performed manually it can be automated and also we can add logic as well so based on some condition, ie if it's a production deployment we can add a few other steps
vs if it's a test deployment we can skip a few other steps.

Prerequisites

An AWS account
Node.js and npm installed
AWS cli and cdk setup and configured
Basic knowledge in Javascript and Typescript

Setup, Code and Deploy

Initialize a new CDK project:

mkdir temp-project && cd temp-project
mkdir infrastructure && cd infrastructure
cdk init app --language typescript

Replace the content of the file lib/infrastructure-stack.ts with:

import * as cdk from "aws-cdk-lib"
import { Construct } from "constructs"
import { SubnetType, IpAddresses, Vpc } from "aws-cdk-lib/aws-ec2"

export class InfrastructureStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)
    const vpc = new Vpc(this, `${id}-vpc`, {
      vpcName: `${id}-vpc`,
      ipAddresses: IpAddresses.cidr("10.0.0.0/16"),
      maxAzs: 2,
      createInternetGateway: true,
      subnetConfiguration: [
        {
          cidrMask: 24,
          name: "Public",
          subnetType: SubnetType.PUBLIC,
        },
        {
          cidrMask: 24,
          name: "Private",
          subnetType: SubnetType.PRIVATE_ISOLATED,
        },
      ],
    })
  }
}

now deploy the stack

cdk deploy

Once deployment open AWS console, and go to the VPC page. You will see we have our VPC created with one small difference. The two public subnet will each have their own route table, where the one we created using console created one route table.
And to destroy all the resources just run

cdk destroy

And enter y to confirm you want to delete. And that is it! all resource will been destroyed according to the dependency tree CDK keeps track of.

Interested in learning more?

If you are interested in creating a project from scratch using AWS CDK, and serverless, you can checkout the class linked below, where we go over in details explain what each service does, and actually create a dynamic
application with user login and authentication.

Serverless Fullstack with AWS/CDK/NextJS & Typescript

Conclusion

We've explored what VPC is, its key components like subnets and route tables, and walked through practical examples of creating a VPC both manually via the AWS Console and programmatically using AWS CDK.

By leveraging VPCs, you can effectively isolate your resources, control network traffic, and organize your architecture for optimal performance and security. Whether you're building a multi-tier application or setting up a remote work environment, understanding and utilizing VPCs is crucial for creating robust and secure cloud solutions.

In the future posts, we will be utilizing VPC and ECS, to create a container based deployment.

Next.js containerization using Docker

RedRobot.dev — Mon, 04 Nov 2024 19:00:00 +0000

In this post, we'll explore how to containerize a Next.js application using Docker. We'll start with a real-world scenario to illustrate why containerization is valuable for modern web applications. Then, we'll explain what containers are, why this technology exists, and its benefits compared to traditional deployment methods. Finally, we'll walk through the process of containerizing a Next.js app step-by-step, giving you practical experience with this essential technology. By the end, you'll understand both the how and why of using containers for Next.js applications.

*Original Post
*

redrobot.dev

Example Scenario

Let's take the following example: We are tasked to create a Saas (Software as a Service) application that has a web interface giving users the capability to select a list of countries, cities, days of week and generate a weather video sequence similar to what you see in news broadcasts.

At minimum, such a system would require to have the following components:

REST API to handle video render requests
storage to hold videos
video rendering engine
frontend application that users can input the country, city and days and request for a video

The block diagram would look something like this:

We could develop the whole application using a single language like TS, JS, C++, C#, Rust or Go, ending up with a single executable that handles everything for us, but this is not a good solution for a SaaS application.

This is referred to as a monolith architecture where in certain cases like a desktop application it is desirable. However, in our case since it's a server-based SaaS application it is better to break down our application into smaller self contained components. This has several benefits:

Much easier to break down tasks and assign to different engineers
Easier to test component in isolation, using mock input and output
Easier to scale horizontally, so lets say in the future our user base grows and we need to handle larger traffic - we can easy duplicate an instance of the Rendering engine, add a load balancer in front so we can handle larger client requests.

This solution is referred to as microservice architecture.

The Problem

So how would we go about and making this self contained components? Let's make it simple and only look at the frontend which is the topic of this post.

We can make an executable of the Next.js process using something like [Nexe (https://github.com/nexe/nexe) and run that on the destination server along with the other executables. But this solution has problems:

the executable might not have bundled all the necessary 3rd libraries, say the libc lib that a package requires, and this could lead to missing dependencies when running hte executable on a destination server.
the executable created or developed on one operating system, might not work on other operating system out of the box and will require extra work to make it intra operative
the libraries included in the executable bundle might conflict with other software installed on the server
there are other issues such as maintenance complexity, security issues and difficulty auditing, hard to patch issues, loss of flexibility and so forth

As you can tell, this would be a nightmare to manage. Writing good and clean code is great, but if your solution is not future-proof and easy to fix, then it doesn't matter if your code is good or high quality. Imagine creating a factory with machines where it takes months to fix a machine; the whole factory is shut down with no products being produced.

The Solution

One approach would be to create a virtual machine (VM) and install Next.js along with Node and all of the required libraries - and then load that onto the server. This would be a good solution as the VM is isolated from the server, and in fact, we can do the same for the rest of the components like the database, rendering engine, and other elements.

However, there is one major downside to VMs - they consume a lot of resources. Virtual machines run a full operating system with their own kernel and drivers, requiring dedicated CPU and memory allocations.

This is where containers come in. Containers are similar to VMs; however, they do not run a full operating system. Instead, they share the host operating system's kernel and resources.

Containers

Similar to virtual machines, containers are isolated environments that allow you to group applications and configurations into a single unit and run your application. Containers are more lightweight and efficient compared to VMs, making them an attractive option for deploying and scaling applications.

We are going to containerize a basic Next.js application to demonstrate the process.

Containerization refers to the process of packaging an application into a container or more accurately a container image, so we can run it using docker.

Docker

Docker is one of the most popular containerization technologies and in this post we will be using Docker to create a container that hosts a Next.js application.

Containerizing a Next.js Application

Lets containerize a Next.js application using Docker. If you don't have docker installed, install it from here https://www.docker.com/. Following the instructions provided on the website for your operating system.

Open up a terminal and create the Next.js frontend app by running:

npx create-next-app@latest

Enter frontend for the app name, and then press enter for all prompts until it finishes creating the Next.js app.

update the next.config.mjs file and add the following line

const nextConfig = {
  output: 'standalone'
}

this will automatically create a standalone folder that copies only the necessary files for a production deployment. This change in the Next.js config is required in order to get the outputs we need for a production build.

Next, in the newly created frontend folder we will create a file named Dockerfile with the content of this link there.

Dockerfile example from Vercel

Here are the commands to create the file:

cd frontend
curl https://raw.githubusercontent.com/vercel/next.js/canary/examples/with-docker/Dockerfile -o Dockerfile

So what is this file for?

Dockerfile

The file we just downloaded contains instructions that tell Docker how to build a container image. An image is essentially a blueprint that holds all your code, third-party libraries, OS-related data, and other necessary components in a single package.

When you execute that image using Docker, you create a running instance of that image, which is referred to as a container. You can create multiple containers from a single image.

Lets take a look into the file we just downloaded:

FROM node:18-alpine AS base

# Install dependencies only when needed
FROM base AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app

# Install dependencies based on the preferred package manager
COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* ./
RUN  npm ci
...

Each line in the Dockerfile is a command, similar to how you would run a basic Linux command. If you would run mkdir /app in a Unix terminal, in the Dockerfile you would write RUN mkdir /app.

The top line FROM node:18-alpine AS base tells Docker which base image to use for building your container. In this case, it's using Node.js version 18 on an Alpine Linux distribution. Docker will fetch this image if it's not in your local cache. This is analogous to choosing an operating system for a VM, but it's more lightweight.
The line RUN apk add --no-cache libc6-compat is installing a specific compatibility package for libc inside the image. This is indeed better suited for the production output of Next.js. If we do this in an environment that has other applications depending on libc, it might cause problems.
The line RUN npm ci installs all the Next.js project dependencies, as you would normally do for a freshly cloned Next.js app. The ci command is used instead of install for more reproducible builds.
The following lines, are building and copying the Next.js outputs to a working path.

RUN npm run build
COPY /app/.next/standalone ./
COPY /app/.next/static ./.next/static

And finally the last few lines expose port 3000 and starts the Next.js process:

EXPOSE 3000
CMD HOSTNAME="0.0.0.0" node server.js

We are skipping most of the details here. The idea is to give you an overview of what is occurring in this Dockerfile. If you like to learn more about Dockerfile and how to create your own, checkout this official guide from Docker:

Guide to creating Dockerfile

and the reference docs for all Dockerfile commands:

Dockerfile Reference

We can now build our image, from inside the frontend folder run:

docker build -t nextjs-frontend .

This is going to build a docker image named nextjs-frontend.

Make sure you are running the docker service, otherwise the command will fail

you can check to see if the image is in your local registry by running:

docker image ls

lets run our our newly created image. By running the image, we are creating a container effectively. Execute the following command:

docker run -p 4000:3000 nextjs-frontend

this command starts the docker image, and maps the internal port 3000 to 4000. So now if you open your browser and go to http://localhost:4000/ you will see the next.js page.

Run CTRL + C to stop the container. Alternatively you can run the container in the background or detached mode by passing the -d argument:

docker run -d -p 4000:3000 nextjs-frontend

Then to view any detached running container run:

docker ps

and the output should look like:

CONTAINER ID   IMAGE                       COMMAND                  CREATED         STATUS         PORTS                    NAMES
955c54690c9d   nextjs--frontend            "docker-entrypoint.s…"   4 seconds ago   Up 4 seconds   0.0.0.0:4000->3000/tcp   great_hamilton

To stop the container from running, take a note of the name and then run:

docker stop great_hamilton

Alternatives to Docker

White Docker is the most popular tool for containerization, other containerization technologies exist. Here are some of the popular ones:

LXC (Linux Containers): A lightweight virtualization which is OS-level and allows you to create and run multiple isolated Linux virtual environments (VE) on a single control host. LXC is better suited for experienced users.
LXD (Linux Daemon): it's a extension of LXC that aims to provide a better user experience. LXD is more user-friendly and it is similar to hypervisors like VMWare or KVM, but it's lighter on resources and doesn't require virtualization overhead.
containerd: A container runtime that's used by Docker but can also be used independently.
Kubernetes (k8s): While primarily an orchestration platform, it includes its own container runtime interface.
OpenVZ: Primarily used for server virtualization on Linux.
Windows Containers: Microsoft's native containerization technology for Windows.

Conclusion

Containerization, particularly using Docker, offers a powerful solution for deploying and managing complex applications like our Next.js frontend. Throughout this post, we've explored the challenges of deploying microservices and the advantages that containerization brings to the table.
We've learned that:

Containerization provides a middle ground between monolithic applications and resource-heavy virtual machines.
Docker allows us to package our Next.js application along with all its dependencies into a portable, consistent environment.
The process involves creating a Dockerfile, which serves as a blueprint for building our container image.
With a few simple commands, we can build, run, and manage our containerized Next.js application.

By containerizing our Next.js frontend, we've created a scalable, portable, and easily manageable component of our larger microservices architecture. This approach not only simplifies deployment but also enhances our ability to develop, test, and scale our application efficiently.

As we move forward in the world of modern web development, understanding and utilizing containerization technologies like Docker becomes increasingly crucial. Whether you're working on a small project or a large-scale SaaS application, the principles and practices we've discussed here will serve as a solid foundation for your containerization journey.
Remember, while Docker is the most popular containerization tool, alternatives exist, and the field is constantly evolving. Stay curious, keep learning, and happy containerizing!

Serverless Option

I‘ve developed a comprehensive Udemy course Serverless Fullstack with AWS/CDK/NextJS & Typescript that guides you through building a Serverless Single Page Application (SPA) from the ground up using AWS, AWS CDK, AWS SDK, Next.js and all written in TypeScript.

Next.js on AWS: Deployment Strategies

RedRobot.dev — Mon, 28 Oct 2024 18:00:00 +0000

In this post we will explore the primary methods for deploying a Next.js app to AWS, discussing the pros and cons of each method.
Before proceeding, it's beneficial to know some of the core Next.js concepts such as SSR, SSG, Hybrid, Hydration and difference between SPA and MPA. If you're unsure what these are, you can learn more by reading the Next.js docs.

Original Post

redrobot.dev

Strategies

In this section, we'll discuss all major deployment strategies for Next.js and the key points to consider when selecting a deployment method in the context of AWS. We'll also highlight potential pitfalls and important points that may seem trivial but become significant in practice. Here are the list of strategies:

(SSG + SPA) Static File Hosting
(SSG + SSR + SPA) Containerization
1. on EC2
2. on ECS
(SSG + SSR + SPA) Serverless
1. Amplify Gen 1
2. Amplify Gen 2
3. SST
4. OpenNext

Pure static generated website

SSG stands for Static Site Generation, which essentially means the content of the website is generated at build time.
This strategy focuses on generating static pages during the build or deployment stage of your Next.js application.

This method is contingent on knowing all the necessary data for constructing the pages at build or deployment time. This approach, pre-renders pages to static HTML, which can then be efficiently served to users. It's ideal for content that doesn't change frequently and when you can predict all possible page routes at build time.

At the end, you will have a folder with all the files generated, including the css, javascript and all other assets.

With the content generated, you can host the files in any regular HTML server for example nginx, apache http server, etc.

When you should deploy your website using SSG?

There are two scenarios where this approach is suitable:

If you are developing a SPA (Single Page Application), with all the rendering and data fetching done on the client side (browser).
If the website content is available at build time, even if it's in a database, and the content is under your control and not added, updated, or deleted by third-party users.

When not to use SSG?

If your website requires multi-user support such as user registration and login functionality, or the ability for users to add or modify content like blog posts or shopping carts and etc — you're dealing with dynamic content. These are scenarios where data is created and modified externally, and the rate and timing of such content changes are not under your direct control.

This is referred to Dynamic content, which essentially means the content can change after the website is built and deployed.

How to deploy

For a detail step-by-step guide on how to deploy your Next.js app using this strategy checkout the blog post static website deployment.

SSR or Server Side rendering

Server-side rendering (SSR) generates content on each request, and this strategy is primarily used for cases where the content is dynamic. And with this usually there is a form of content source (usually a database) available to the server to access and generate pages. In this approach:

Data is fetched and collected on the server for each incoming request
The server then generates the complete HTML page using this data
The fully rendered page is sent to the client

For deploying server-side rendered Next.js applications, there are several approaches:

Containerization: which means creating a Docker image of the Next.js app and running it on EC2 (Elastic Compute Cloud) or ECS (Elastic Container Service). The ECS approach offers greater flexibility and scalability, but it also requires more configuration as it has more "moving parts".
Segmented Deployment: This method requires breaking down the Next.js app output into static and dynamic segments and deploying each type of content to appropriate resources such as S3 and Lambda. While this approach optimizes resource usage, it is more complex to set up manually as it requires a deeper understanding of Next.js internals.

When you should deploy your website using SSR?

This method of deployment is particularly useful when:

Content needs to be up-to-date with each page load as data is dynamic or user-specific.
SEO optimization is essential - This method works much better for SEO as search engines can easily index the fully rendered content, unlike with SPA applications.
Page load time need to be fast - This approach can actually decrease page load time, especially in cases where the client browser is not very powerful. By leveraging the server to render pages, you offload processing from the client.
In certain cases, this method would load the page faster, particularly if the database hosting the dynamic data is close to the server generating the pages.
For security-critical cases where you have important content that you don't want to send over the wire or share with the world, server-side rendering offers a more secure environment instead of exposing data and IDs.

When not to use SSR?

While Server-Side Rendering (SSR) in Next.js offers a balance between dynamic content and performance, leveraging caching strategies and optimized rendering processes, it's important to note that it can be more resource-intensive than static generation. The server must process each request individually, potentially leading to higher server loads, increased costs, and slightly longer response times compared to serving pre-generated static pages.

Server-Side Rendering (SSR) requires running a process to render pages dynamically, which incurs additional costs. Therefore, it's best avoided if your content is static. SSR also introduces complexity with components like reverse proxies, databases, and various frontends' (admin and client-side). This complexity not only expands the potential attack surface but also increases development and maintenance costs. While SSR offers significant flexibility, these factors should be carefully weighed when considering its implementation. The decision to use SSR should be based on a thorough evaluation of your specific needs and resources.

Important
Choose your deployment strategy carefully based on your specific use case. For instance, if you have a blog website where you plan to update content yourself infrequently, there's no need for Server-Side Rendering (SSR). Instead, you can create a Static Site Generated (SSG) application with your content hosted locally. This approach is more efficient and cost-effective for websites with primarily static content that doesn't require frequent real-time updates.

Hybrid SSG + SSR + SPA

In the majority of cases, your website or app will likely contain a mix of dynamic and statically generated content, and may even include Single Page Application (SPA) elements. A good example is an e-commerce website:

The landing page might be static
The products page could be dynamic
The admin interface might be an SPA

For such mixed-content scenarios, you'll typically run Next.js in production mode. In this mode, Next.js:

Serves static files directly from directories
Renders dynamic pages on-demand
Caches data to optimize file serving

This process can be broken down into two main stages:

Deployment Stage: Where pages are built and prepared
Live Mode: Where the Next.js process is running, serving content, and managing caching and dynamic generation as needed

This approach allows for optimal performance and flexibility, catering to the varied content types within a single application. It leverages the strengths of static content for speed and dynamic rendering for up-to-date information, all within the Next.js framework.

Next.js provides mechanism to optimize serving static and dynamic by separating static and dynamic content into different parts however you will still be running the Next.js process to host the static content which increasing CPU time and cost. It might be better to leverage Segmented Deployment options for these types of websites.

AWS Deployment Options

1. Static File Hosting

Cloudfront + S3

This method is suitable for SSG website that host static content or SPA apps. Deploying a Next.js app using CloudFront and S3 offers a robust and scalable solution for static site hosting.

The benefits of this method are:

excellent performance due to CloudFront's edge locations,
high scalability
cost-effectiveness for serving static content

As mentioned This method has limitations - It's primarily suitable for static exports, which may not support all Next.js features, particularly those requiring server-side rendering.

For deployment, mainly we need to utilize CloudFront as a Content Delivery Network (CDN), Route 53 for Domain Name System (DNS) management, AWS Certificate Manager for SSL certificate generation and management, and S3 buckets for storing and hosting the static content of your website. This approach creates a robust, scalable architecture where:

CloudFront distributes your content globally, reducing latency for users
Route 53 manages your domain and directs traffic to CloudFront
Certificate Manager ensures secure HTTPS connections
S3 acts as the origin server, storing your static files

For step-by-step guide on how to deploy such an app see static website deployment.

2. Containerization

EC2

This method comprises of creating an EC2 instance, it's simple and familiar as it's a VM so you will have full control over the server environment, customizable resources (CPU, RAM, storage), you can scale vertically by adding a more powerful instance and switching over the route forwarding, and flexibility to install and configure additional software, and it's low cost specially for high-traffic applications.

However, it requires higher complexity in setup and maintenance, you have to manually handle scaling and load balancing setup, and updating security patches and as far as cost it's might be more expensive to run for low traffic websites.

This would typically involve installing a reverse proxy (Nginx), a node process manager like (PM2) and then finally the node application.

ECS

Deploying a Next.js app using Amazon ECS offers several advantages, including simplified container orchestration, easier scaling and load balancing, improved resource utilization, consistent deployments across environments, and seamless integration with other AWS services.
However, it also comes with some drawbacks. These include a learning curve for container concepts and ECS specifics, potentially higher costs compared to EC2 for small-scale applications, less direct control over the underlying infrastructure, complexity in managing stateful applications, and possible performance overhead due to containerization. Despite these challenges, ECS can be an excellent choice for teams looking to leverage the benefits of containerization and streamlined deployment processes, especially as applications grow in scale and complexity.

As illustrated in the diagram, this method involves more services and careful configuration. It's important to note that the associated costs can be higher, particularly if the setup is not optimized. Therefore, careful planning and monitoring are essential to ensure cost-effectiveness while leveraging the advantages of containerization.

If you are interested in learning more checkout the following post "Next.js Deployment using ECS with Fargate" where we guide you through step-by-step describing how to achieve this.

3. Serverless

The serverless architecture for all of the mentioned solutions here will be similar to what this diagram shows:

However each have their own additional components, some are proprietary and some open source. The diagram represent in high level what the Serverless option would look like.

AWS Amplify Gen 1

Deploying Next.js using AWS Amplify offers a mix of advantages and potential drawbacks.

On the positive side, Amplify provides easy setup, integrated AWS services, automatic CI/CD pipelines, serverless architecture, and built-in hosting with CDN capabilities. With Amplify, you can point to your Next.js app from the console and it's up and running.

However, there is no direct CDK integration - you are sort of tied into the Amplify eco system and for teams requiring maximum control over their AWS architecture might find this abstraction layer constraining. The choice to use Amplify ultimately depends on the specific needs and circumstances of the project.

AWS Amplify Gen 2

Amplify Gen 2 represents a significant evolution from its predecessor, offering several key improvements tailored to modern web development needs. Unlike Gen 1, which primarily used Amazon S3 and CloudFront for hosting static sites, Gen 2 leverages AWS Lambda@Edge and CloudFront to provide a more flexible serverless architecture. This shift enables full server-side rendering (SSR) support, a feature that was limited in Gen 1. Gen 2 delivers enhanced performance and scalability, particularly for dynamic content, thanks to its serverless foundation. It also offers faster deployments, especially for incremental updates, and improved support for advanced frameworks like Next.js, including features such as API routes.

A notable advantage of Gen 2 is its direct CDK support, allowing developers to seamlessly extend or connect their Next.js deployments with existing architecture. While Gen 1 was more straightforward for simple static sites, Gen 2 provides an improved developer experience for full-stack applications, offering greater customization options and tighter integration with other AWS services. Although Gen 2 may have different cost implications compared to Gen 1's potentially lower costs for simple static sites, it can be more cost-effective for dynamic applications due to its serverless nature. Overall, Amplify Gen 2 is designed to better support the complexities of modern web applications, offering developers more power and flexibility in building and deploying sophisticated, scalable web solutions.

If you are interested in learning more checkout the following post "Next.js Deploying using AWS CDK & Amplify" where we guide you through a step-by-step process describing how deploy a SSR-enabled Next.js app using Amplify Gen 2.

SST

Similar to Amplify, SST (Serverless Stack Toolkit) is another interesting option for deploying Next.js applications, particularly if you're looking to leverage AWS services more directly. In addition to supporting Next.js app deployment, SST offers other abstractions that makes it easy to create a full app faster compared to writing CDK from scratch yourself.

SST uses AWS CDK under the hood, giving you the ability to define your infrastructure as code.

To deploy a Next.js app using SST, you create an SST project using npx create-sst@latest and then configure the NextJs app using using regular CDK syntax:

import { NextjsSite, SSTConfig } from "sst/constructs"

export default {
  config(_input) {
    return {
      name: "my-next-app",
      region: "us-east-1",
    }
  },
  stacks(app) {
    app.stack(function Site({ stack }) {
      const site = new NextjsSite(stack, "site")
      stack.addOutputs({
        SiteUrl: site.url,
      })
    })
  },
} satisfies SSTConfig

Critical
Merging this into your own CDK code is not easy and it's error prone. While SST is much closer to what we want, since it used AWS CDK however - it has it's own eco system build on top of AWS CDK which forces you to use it.

OpenNext

OpenNext is a CDK (Cloud Development Kit) library that facilitates easy integration directly into your CDK project. This approach is particularly desirable in scenarios where:

Your company's entire infrastructure is managed using CDK
You aim to maintain uniformity across your infrastructure code

By using OpenNext, you can keep all of your infrastructure code, including your Next.js deployment configuration, within the same project. This consistency can lead to several benefits:

Simplified management: All infrastructure code is in one place
Easier version control: Changes to both application and infrastructure can be tracked together
Streamlined deployment processes: You can use the same deployment pipeline for both your application and infrastructure

This method is especially advantageous for organizations that prioritize a cohesive and standardized approach to infrastructure management across all their projects and services.

We will be using cdk-nextjs-standalone which is a package that is built on top of OpenNext.

OpenNext takes the Next.js build output and converts it into packages that can be deployed across a variety of environments. Natively OpenNext has support for AWS Lambda and classic Node Server. It also offer partial support for the edge runtime in Cloudflare Workers.

Here is a wrapper construct that encapsulated cdk-nextjs-standalone (it's good practice to always create wrappers around 3rd party code).

import { CfnOutput, StackProps } from "aws-cdk-lib"
import { Construct } from "constructs"
import * as acm from "aws-cdk-lib/aws-certificatemanager"
import * as route53 from "aws-cdk-lib/aws-route53"
import { Nextjs } from "cdk-nextjs-standalone"

export interface NextJsServerlessDeploymentProps extends StackProps {
  nextJsRootPath: string
  domain: string
  webUrl: string
  hostedZone: route53.IHostedZone
  certificate: acm.Certificate
}

export class NextJsServerlessDeployment extends Construct {
  constructor(
    scope: Construct,
    id: string,
    {
      nextJsRootPath,
      domain,
      webUrl,
      hostedZone,
      certificate,
    }: NextJsServerlessDeploymentProps
  ) {
    super(scope, id)

    const nextjs = new Nextjs(this, "Nextjs", {
      nextjsPath: nextJsRootPath, // relative path from your project root to NextJS
      domainProps: {
        domainName: domain,
        certificate,
        hostedZone,
      },
    })

    new CfnOutput(this, "CloudFrontDistributionDomain", {
      value: nextjs.distribution.distributionDomain,
    })
  }
}

And this is how you would use it

import * as cdk from "aws-cdk-lib"
import { Construct } from "constructs"
import { CertificateWrapper, NextJsServerlessDeployment } from "../constructs"
import { getConfig } from "../helpers"

export class MainServiceStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)
    const config = getConfig()
    const domain = config.domain
    const webUrl = `${config.webSubdomain}.${domain}`

    const cw = new CertificateWrapper(this, "certificateWrapper", {
      domain,
      webUrl,
    })

    new NextJsServerlessDeployment(this, "dynamicWebsiteDeploy", {
      nextJsRootPath: "../frontend",
      domain,
      webUrl,
      hostedZone: cw.zone,
      certificate: cw.certificate,
    })
  }
}

None AWS options

Vercel

Using Vercel to deploy a Next.js app is much easier and streamlined, and reportedly runs faster than compared to the alternatives listed here. Vercel is the company behind Next.js and their platform is optimized for it. To upload you NextJs app to Vercel, it's as easy as creating a new project, pointing to your git repo where it holds the NextJs code
and Vercel will deploy everything for you.

Conclusion

In conclusion, deploying a Next.js application to AWS offers a variety of strategies, each with its own strengths and considerations. From static file hosting using CloudFront and S3 for simple static sites, to containerization on EC2 or ECS for more complex applications, to serverless options like AWS Amplify Gen 2, SST, and OpenNext for scalable and flexible deployments, developers have a wide range of choices.

The selection of the most appropriate deployment method depends on factors such as the application's complexity, scalability requirements, budget constraints, and the development team's expertise. While AWS provides robust solutions, it's worth noting that alternatives like Vercel offer streamlined deployment processes optimized specifically for Next.js.

How do you choose the method?

When choosing a deployment method for your Next.js application, consider your specific needs and constraints:

For static content: If your pages are not dynamic, opt for a static deployment method. It's fast, cost-effective, and easily scalable using services like AWS S3 and CloudFront.
For dynamic content outside AWS: If your content is dynamic and you're not committed to AWS, Vercel offers an optimized, streamlined deployment experience specifically designed for Next.js.
For dynamic content within AWS: If you're already invested in AWS infrastructure and have dynamic content, your main choices are between container-based (EC2/ECS) or serverless solutions.

a. For maximum control: Choose EC2 or ECS. EC2 provides full control over the server environment, while ECS offers container orchestration with improved scalability. ECS, in particular, provides high availability but may come at a higher cost.

b. For simplified management: Opt for serverless solutions like Amplify Gen 2. It's AWS's officially supported method for Next.js deployments, offering a balance between ease of use and performance. It's particularly suitable for projects that don't require extensive customization of the underlying infrastructure. Also you can extend it with your existing CDK infrastructure so it's a good choice for startups.

Consider scalability: Serverless options like Amplify Gen 2 offer automatic scaling, while EC2/ECS solutions require more manual configuration but can be optimized for high-traffic scenarios.
Factor in team expertise: EC2/ECS deployments require more in-depth AWS knowledge, while Amplify Gen 2 has a gentler learning curve. Amplify Gen 2 also has developer sandboxes which allows multiple developer experiment with and working on the code simultaneously.

Interested in learning more?

If you are new AWS and would like to get started using and learning it the right way (using AWS CDK as IaC) - check out our Udemy class

Serverless Fullstack with AWS/CDK/NextJS & Typescript.

Deploy a static (Next.js) website to AWS using AWS CDK & AWS console

RedRobot.dev — Mon, 21 Oct 2024 18:00:00 +0000

Deploying a static website to AWS can be achieved by AWS S3 (Storage Service), AWS CloudFront (CDN Service), Route 53 (DNS Server) and Certificate Manager.

In this post we will guide you through deploying a static website on AWS using two methods. First, we'll cover the step-by-step process using the AWS Console which requires no coding skills. Then, we'll explore a more efficient approach using AWS's Infrastructure as Code (IaC) framework, the Cloud Development Kit (CDK).

We will simply uploading the HTML/JS/CSS content of our website to an S3 bucket and add a AWS CloudFront to host the bucket data, and finally create a certificate and configure DNS to route the domain requests to the CloudFront record.

Original Post

redrobot.dev

This approach offers several advantages in specific scenarios:

Website loads very fast since it's all pre-build HTML files
No need for a server side process to run to generate pages
Static websites are much less prone to hacks, wordpress is notorious for this issue. This is ideal for business who need a simple website with few functions.

The static website can be a traditional multi-page site or a Single Page Application (SPA). SPAs load a single HTML page and dynamically update content as users interact with the app. To determine if an SPA suits your needs, consider factors like user experience, performance requirements, and development complexity.

Topics Covered in This Guide

Create a NextJS static website
Deploy the website using AWS console, then destroy it
Redeploy the website using AWS CDK and then destroy it

Create a NextJs Webpage

First, lets create a NextJS project. Open a terminal and type:

mkdir frontend & cd frontend
npx create-next-app@latest

then you will be presented with several options, choose the options as you see in the page here:

Need to install the following packages:
create-next-app@14.2.5
Ok to proceed? (y) y

✔ What is your project named? … test-frontend
✔ Would you like to use TypeScript? … No / Yes
✔ Would you like to use ESLint? … No / Yes
✔ Would you like to use Tailwind CSS? … No / Yes
✔ Would you like to use `src/` directory? … No / Yes
✔ Would you like to use App Router? (recommended) … No / Yes
✔ Would you like to customize the default import alias (@/*)? … No / Yes
Creating a new Next.js app in /Users/~/tmp_frontend/test-frontend.

open the project in and editor or directly open the next.config.mjs file and set the output value to export, and set the distDir to dist:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "export",
  distDir: "dist",
}

export default nextConfig

then open the terminal and go into the directory where NextJs code resides. Then run

npm run build

you should see the following text after building:

  ▲ Next.js 14.2.5

   Creating an optimized production build ...
 ✓ Compiled successfully
 ✓ Linting and checking validity of types
 ✓ Collecting page data
 ✓ Generating static pages (5/5)
 ✓ Collecting build traces
 ✓ Finalizing page optimization

Route (app)                              Size     First Load JS
┌ ○ /                                    5.25 kB        92.4 kB
└ ○ /_not-found                          871 B            88 kB
+ First Load JS shared by all            87.1 kB
  ├ chunks/23-bc0704c1190bca24.js        31.6 kB
  ├ chunks/fd9d1056-2821b0f0cabcd8bd.js  53.6 kB
  └ other shared chunks (total)          1.86 kB


○  (Static)  pre-rendered as static content

this will generate a static version of the pages, you can actually do a quick text and run a webserver locally and server these files using live-server.

If you don't have live-server install the package globally via npm i live-server -g

Traverse inside the dist folder and run live-server.

cd dist
live-server .

if browser doesn't open up automatically, open a browser and go to http://127.0.0.1:8080/, then test the website make sure it runs. You should see this page in your browser:

Important:
Although a basic HTML, CSS, and JavaScript website would have worked, we chose NextJs for their efficiency. Despite seeming more complex for this example, this approach actually simplified development, reduced setup time, and offered advantages like automated builds, type checking and etc.

Deploying Website using AWS Console

This section covers deploying the website using the AWS Console. While not the recommended method, it's might be useful for understanding core concepts. Also
this method doesn't require you to know any coding knowledge.

Prerequisites

An AWS account

Configure the S3 bucket

Open a browser and go to the AWS console, and login.

Navigate to the Amazon S3 Service.

Click on the Create New Bucket option.
In the Create Bucket page, under General configuration, select General purpose from the bucket options.
Name your bucket something that you will remember, I have named it "temp-console-website", you could name it the same things to make following steps easier.

Note:
The name is crucial to remember, as we'll use it again when specifying the bucket Resource value in the next section. This ensures correct resource linking in later steps.

In the Object Ownership section, select ACLs disabled.
In the Block Public Access settings for this bucket section, uncheck the Block all pubic access, and make sure all the other four checkboxes have been unchecked as well. You will notice a yellow alert box popping up with the following message:

Turning off block all public access might result in this bucket and the objects within becoming public

Select or check the I acknowledge that the current settings might result in this bucket and the objects within becoming public box.
In the Bucket Versioning select Disable versioning.
everything else should be set to default, select Create bucket
This is an optional step, but to make things simple for us at the end where we need to destroy all resource, add a tag. Scroll down to the Tags section and add a tag by click on edit, and adding a new tag with the key value of temp-project.

Upload the files to S3

Select the newly created bucket from the bucket list page. If you set the name to be "temp-console-website" then that will show up in the list.
Click on the Upload button
Select add files, then select all the files in the dist folder from the NextJs folder, and then click the Upload button to upload all the files. a progress bar will be displayed showing the upload progression. Once upload to the next step.
Go to the Properties tab, then scroll down to the Static website hosting section and click Edit.
Under the Static website hosting section select Enable.
For the Hosting type select Host a static website
There is an input field under Index document, enter index.html in that field.
enter error.html for the Error document but this is optional.
Click Save changes
Go into the Permissions tab
Scroll down until you see the Bucket Policy section. Click on the Edit button, then paste the following policy in there

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": "*",
          "Action": "s3:GetObject",
          "Resource": "arn:aws:s3:::temp-console-website/*"
        }
      ]
    }

Click Save changes

The "temp-console-website" is the name I chose, if you have chosen a different name, then replace this value in the JSON object.

We've completed the S3 configuration. To view the website directly from S3, go to the Properties tab and scroll to Static website hosting. At the bottom, you'll find a URL under "Bucket website endpoint". The URL should look similar to this:

http://temp-console-website.s3-website-us-east-1.amazonaws.com

you should see the same NextJs page we saw when we ran locally.

Configuring DNS

In this section we will configure to point a domain name to this CloudFront distribution or our website.
If you already have a domain you purchased from a third party domain provider like GoDaddy, Namecheap,
Google domain etc you have to login and change some of the settings.

We will be moving back and forth between DNS, CloudFront and Certificate Manager in order to get this configured

First lets add the domain to AWS Route 53. Route 53 is a DNS service provided by Amazon. Lets add our domain. For this example I have a test domain named redrobotexample.com. This is a domain I use to try and test different applications.

Go to the Route 53 page:

Click on the Get started button, and you will be presented with the following view:

Select the Create hosted zones option and click Get started
In the Domain name field enter your domain name, ie redrobotexample.com, and then click Create hosted zone. Once done you will be presented with this page:

Expand the Hosted zone details area by clicking on the triangle next to it. you will be presented with a few details. From that list, you need to copy the Name servers value and paste them in your 3rd party domain provider DNS provider. In your 3rd party domain provider, find where you can define custom dns servers and paste the values, which should look like this:

ns-2042.awsdns-63.co.uk
ns-1452.awsdns-53.org
ns-543.awsdns-03.net
ns-92.awsdns-11.com

For example, in namecheap this is the section where you define custom DNS values:

Scroll down to the Tags section and add a tag and select the temp-project value.

Creating a Certificates

Open a new tab or browser windows, and go to the AWS Certificate Manager or (ACM)
Click on Request certificate
In the next page select Request a public certificate
In the next page, for the Fully qualified domain name enter your domain name, ie redrobotexample.com in our example
In the same section click on add another name for the certificate and enter the same domain but add the the www subdomain to it. So for our example it would be www.redrobotexample.com then click Request
In the next page, scroll down to where it says Domains, you will notice two CNAME values are presented - these need to be added ro your DNS entry so AWS certificate Manager can verify that the domain belongs to us. S we need to add those to the Route 53 entries and we can do that by clicking on the Create records in Route 53 in that same view (you can do this manually but AWS made things simple for us)
In the next page, since we have been using the same domain name for our DNS values, AWS will filter the right DNS entries for us to select.

Click the Create Records in Route53

In the other tab, that has the Route 53 page open, verify the two new Route53 entries have been added to the record list
After this, we need to wait for the status of this certificate to change from "pending validation" to validated. In the Certificate Manager page, check the value of Status. Once the status changes to "Issued" move to the next step.
Scroll down to the Tags section and add a tag by click on edit, and adding a new tag with the key value of temp-project.

Configuring CloudFront

We have defined our DNS records and created our certificates, we would like to update the page so it points to a domain instead of the S3 generated URL. For that we need to setup a AWS CloudFront entry. CloudFront is a CDN service provided by AWS.

Go to the AWS CloudFront page

Then click on the Create a CloudFront Distribution, the Create distribution page will show up
In the Origin domain field or dropdown, click on the field and the dropdown list will appear. From that list select the S3 entry we created in the last part. If you picked the same name from this guide, it should look something like this:

temp-console-website.s3.us-east-1.amazonaws.com
A pop should be displayed that says "This S3 bucket has static web hosting enabled. If you plan to use this distribution as a website, we recommend using the S3 website endpoint rather than the bucket endpoint." Click on the Use website endpoint button to do this.
In the Web Application Firewall (WAF) section, select Do not enable security protections
Do not change any of the other configurations, we will come back here to update the config once we define our domain and certificates but for now, go ahead and click Create distribution.
Once distribution is done, you can copy the URL value under Distribution domain name and paste it in the browser. the value should look like something like this d1wzzsoxu6i44i.cloudfront.net You should see the same page now as before
In the Custom SSL certificate - optional field, select the certificate we just created.
In the Alternative Domain names, add your domain name with and without the www subdomain, so essentially we are adding two values. In this example it would be:
```
redrobotexample.com
www.redrobotexample.com
```

It might be easier to open a secondary tab, and go to the CloudFront page and
check the name to make sure the value is the correct one.

Scroll down to the Tags section and add a tag
by click on edit, and adding a new tag with the key value of temp-project.
click on Create records

Updating DNS

The last step is to update our DNS to point to the CloudFront CDN. With the certificates and CDN in place, we can add a record in our Route53 to our CloudFront dist.

In the same Route 53 page, under the Records section click on Create record.
For the Record Type select A - Route TRaffic to an IPv4 address
Enable the Alias toggle
For the Route traffic to select the Alias to CloudFront Distribution
and then on the bottom selector, select the CloudFront distribution we created in the last step.

you can do the same once more but add the www subdomain as well.

We are done with out configuration, If you followed the steps exactly as described you should be able to go to your domain, (in our case redrobotexample.com) and view your website.

Destroying all resources

As you can see, the steps involved to get this up and running are tedious, and error prone and most importantly not repeatable. You will also notice that destroying these resources suffer from the same problem as we have to manually go to each service and destroy individual services.

Before doing thing using IaC, lets delete/destroy all the created resources.

Go to the Resource groups page
Click Create resource group
Select the Tag based
Under the Grouping criteria enter temp project in the tag field
Click Create group
Then after creation, select the group
On the group's detail you will see each resource listed.

The order of the resource might be different for you, so lets go over each resource by type and describe how to completely destroy them - the order which you need to destroy resource is important since we have created dependencies between resources.

Open the Route 53 resource on a new tab or window.
Check the 3 Record that have the record Type A and the two CNAME's. DO NOT DELETE the NS and SOA records.
close the tab, now open the CloudFront resource in a new tab
Remember the distribution name, and go into the Distribution list view and select that item and click Disable
Once Disabled, then click Delete

If the Delete option isn't available, it means that CloudFront is still propagating your change to the edge locations. Wait until the new timestamp appears under the Last modified column

Close the tab, now open the S3 resource
Select all files from the list and click Delete
A new page is presented, which will ask for your confirmation, enter the text permanently delete in the bottom text box then click Delete objects
Once deleted, click on the Buckets item to view the list of Buckets
Select the bucket (should be named temp-console-website) and click Delete
A similar confirmation page is shown, enter the bucket name in the text field to confirm bucket deletion and click Delete bucket
Close the tab, now open the certificate manager view
Click on the Delete. In the confirmation pop-up enter delete and then Delete again.
close the tab, verify that all resource have been deleted from the resource group view
If no other resource is left continue to the next section.

At the end of the next section you will see that destroying resources is a single command.

AWS Architecture

The AWS architecture of the network we just created looks like this.

we can show the traffic flow using the following UML diagram

Using AWS CDK

By leveraging IaC, you can automate and replicate all the setup and configuration work typically done through the console. This approach significantly speeds up your website deployment process. It allows you to maintain both your website structure and content in code, enabling quick redeployment when you need to add a blog post or change content.

A key advantage of this method is its elimination of the need for a database to store and retrieve website content, or a server to render it. Instead, your entire site can be managed and updated directly through code. This approach simplifies maintenance, reduces costs, and improves scalability and performance and you can use a code subversion system like git to track all changes including the content.

Lets automate all of the steps we took using AWS CDK, which is an IaC or Infrastructure as code framework.
All the steps we performed manually it can be automated and also we can add logic as well so based on some condition, ie if it's a production deployment we can add a few other steps vs if it's a test deployment we can skip a few other steps.

Prerequisites

An AWS account
Node.js and npm installed
AWS cli and cdk setup and configured
Basic knowledge in Javascript and Typescript

Setup, Code and Deploy

Initialize a new CDK project:

mkdir temp-project && cd temp-project
mkdir infrastructure && cd infrastructure
cdk init app --language typescript

in addition, move the frontend folder we created from the first section of the guide into temp-project folder.

Replace the content of the file lib/infrastructure-stack.ts with:

import * as cdk from "aws-cdk-lib"
import { Construct } from "constructs"
import * as route53 from "aws-cdk-lib/aws-route53"
import * as acm from "aws-cdk-lib/aws-certificatemanager"
import * as s3 from "aws-cdk-lib/aws-s3"
import * as s3deploy from "aws-cdk-lib/aws-s3-deployment"
import * as cloudfront from "aws-cdk-lib/aws-cloudfront"
import * as route53Targets from "aws-cdk-lib/aws-route53-targets"

export class InfrastrucureStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)
    const domain = "redrobotexample.com"
    const subdomain = `www.${domain}`

    // fetch route53 zone
    const zone = route53.HostedZone.fromLookup(this, "zone", {
      domainName: domain,
    })

    // this will create a certificate
    const certificate = new acm.Certificate(this, "certificate", {
      domainName: domain,
      subjectAlternativeNames: [domain, subdomain],
      validation: acm.CertificateValidation.fromDns(zone),
    })

    // viewer certificate
    const viewerCertificate = cloudfront.ViewerCertificate.fromAcmCertificate(
      certificate,
      {
        aliases: [domain, subdomain],
      }
    )

    // bucket where website dist will reside
    const bucket = new s3.Bucket(this, "WebsiteBucket", {
      websiteIndexDocument: "index.html",
      websiteErrorDocument: "404.html",
      publicReadAccess: true,
      blockPublicAccess: {
        blockPublicAcls: false,
        blockPublicPolicy: false,
        ignorePublicAcls: false,
        restrictPublicBuckets: false,
      },
      removalPolicy: cdk.RemovalPolicy.DESTROY,
      autoDeleteObjects: true,
    })

    const distro = new cloudfront.CloudFrontWebDistribution(
      this,
      "WebsiteCloudfrontDist",
      {
        viewerCertificate,
        originConfigs: [
          {
            s3OriginSource: {
              s3BucketSource: bucket,
            },
            behaviors: [
              {
                isDefaultBehavior: true,
              },
            ],
          },
        ],
      }
    )

    // s3 construct to deploy the website dist content
    new s3deploy.BucketDeployment(this, "WebsiteDeploy", {
      destinationBucket: bucket,
      sources: [s3deploy.Source.asset("../frontend/dist")],
      distribution: distro,
      distributionPaths: ["/*"],
      memoryLimit: 512,
    })

    new route53.ARecord(this, "route53Domain", {
      zone,
      recordName: domain,
      target: route53.RecordTarget.fromAlias(
        new route53Targets.CloudFrontTarget(distro)
      ),
    })

    new route53.ARecord(this, "route53FullUrl", {
      zone,
      recordName: "www",
      target: route53.RecordTarget.fromAlias(
        new route53Targets.CloudFrontTarget(distro)
      ),
    })
  }
}

now deploy the stack

cdk deploy

you will get a list of resource that AWS CDK will create based on our code
which is listed as such:

Once deployment open the browser and go to the domain and view the page. That is it!
And to destroy all the resources just run

cdk destroy

And enter y to confirm you want to delete. And that is it! all resource will been destroyed according to the dependency tree CDK keeps track of.

As you can see, this method requires more knowledge but triumphs the manual method for all cases.

Interested in learning more?

If you are interested in taking this to the next level, checkout our Serverless fundamentals class at where we go over in details explain what each service does, and actually create a dynamic application with user login and authentication.

Serverless Fullstack with AWS/CDK/NextJS & Typescript

Conclusion

Using CDK to deploy a static website to S3 provides a streamlined, code-based approach to infrastructure management. This method allows for version control, easy updates, and integration into CI/CD pipelines.

This is by no means a production configuration, This is the bare minimum config you need to upload your site - but for most small or medium sized business or personal websites, this solution is ideal.

What is Serverless? An example based explanation

RedRobot.dev — Fri, 05 Jul 2024 19:59:25 +0000

tl;dr (short version)

Serverless is a cloud technology that allows you to focus more on your software application logic, rather than on the deployment or maintenance of servers hosting your application. This leaves more time to improve your application, test it thoroughly, and add new functions.

The alternative to serverless is server-oriented deployment, which has its pros and cons. In general, if you have an application that needs to be accessed by the public via the internet, serverless is a good option, especially if you are in the beginning phase of application development.

Deep Dive

Take the following Typescript/Javascript code as an example:

import {
  fetchCustomerActiveProject,
  fetchCustomerActiveProject,
  fetchInvoice,
  generateInvoicePDF,
} from "../api"

export function generateCustomerInvoice(customerId: string) {
  const activeProject = fetchCustomerActiveProject(customerId)
  const invoice = fetchInvoice(activeProject.id)
  const pdfGenResult = generateInvoicePDF(invoice)

  if (!pdfGenResult.success) {
    throw new Error(pdfGenResult.error)
  }

  return pdfGenResult.filepath
}

Nothing fancy here, the function accepts a customer’s ID and then generates a PDF of the invoice. We are not interested in the low-level details; assume the function works correctly.

So we want to call this function from our web, mobile, or desktop application — i.e., by clicking on a download PDF button and triggering this call. Take this UI as an example — user click on the download file icon next to the invoice and the function would be called (or triggered).

How can we achieve this?

The usual way or the “non-serverless way” to do this is by running something like an Express Node.js app (maybe proxied via an Nginx server), that has a route like so:

/api/generateInvoice?customerId=75612312

And the code would be something like this:

const express = require("express")
const app = express()
const port = 3000
const { generateCustomerInvoice } = require("api")

// Middleware to parse JSON bodies
app.use(express.json())

// Route to generate invoice
app.get("/api/generateInvoice", (req, res) => {
  const customerId = req.query.customerId

  if (!customerId) {
    return res.status(400).json({ error: "Customer ID is required" })
  }

  const invoice = generateCustomerInvoice(customerId)
  res.json(invoice)
})

// Start the server
app.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`)
})

And to run this in a production environment, you would have to manually provision a computer or a virtual machine (it can be Docker as well) and host this there.

So the steps involved in deploying this would be the following:

Create a virtual machine (specify RAM, Storage, CPU Cores and Speed)
Install Node.js
Install Express
transfer the code inside that machine
run it
monitor it

in theory sounds easy enough, but in real world —not so much.

What are the issue with this solution?

Here it comes — once you do all that (after deploying your code), you have the following responsibilities:

Manage updating the operating system to make sure no vulnerabilities exist. This meaning keeping up to date with issues, patching your kernel etc
Make sure you set up the firewall correctly so it’s secure and no one can access the machine. For this case, the firewall configuration is going to be easy but for larger and more complex application — managing IPTables requires a lot of reading
In case of traffic spikes, increase the machine resources or create a secondary one and use a load balancer. But after the spikes, you have to undo that and go back to a single server
Leave the machine running at all times, even if the invoice creation function would only be called once in a while — so you’re wasting CPU resources, electricity, and money.
In case something goes wrong — e.g., PC runs out of memory and crashes — you have to monitor the machine, restart it, and recover it.

All of this for just this simple function — imagine adding a database to this system or a caching system etc, now you have to monitor more stuff. This is precious time you have to spend supporting your function — where instead you could be updating your app or improve it.

This is where serverless comes in.

Serverless

Serverless solves all of the mentioned problems by giving you the tools to simply upload your function to the serverless provider of your choice, specify the API route that would call this function, and that’s it.

Technically speaking, “Serverless” is a misnomer, because you are very much still using a server, BUT you are not manually provisioning and managing the server. If you really want to name it properly, it should’ve been called something like “3rd Party Managed Servers” instead, but I think “Serverless” is a more marketable term.

Serverless will manage updating any underlying OS it’s running on, firewall, scale up when traffic spikes and scale down when there is no traffic, and handle all server related issues.

...
it’s a perfect solution for startups and proof of concept projects, as it reduces the time needed to fix and manage the supporting servers — so you have more time to work on application logic
...

So to define Serverless formally, it is a cloud-native computing model, (meaning it is feature that is only available on 3rd party cloud services like AWS, Cloudflare, fly.io, etc), which allows you to build and run applications and services without having to manage infrastructure.

Why not use Serverless?

As mentioned in the last sentence, serverless is a cloud-native solution, so if you plan on hosting your application on a private intranet — let’s say, a company that has local servers like a military-based company, or somewhere with slow or no internet connection — then serverless is not the right solution for you.

Second, the pricing model is not deterministic — if you are not careful with your lambda configuration, and let’s say a DDoS attack happens, it will incur a large amount of charges. Or if you get unexpected high traffic without any monetization strategy, the same issue will occur.

Thirdly, my experience with serverless has been slow — the development process is very slow since you have to push your changes to the provider to test out the functions, whereas if you develop locally, like in a Docker environment, it would be much faster. In order to speed up your dev process, you actually have to become a better defensive coder to move faster developing code.

Sample Psudo Code

This example demonstrates using AWS, AWS CDK, and TypeScript to create a sample codebase that automatically:

Provisions serverless resources on AWS
Uploads the Lambda function code
Creates an API route to invoke the function

This is the main entry point of the code

const config = getConfig()

// cdk starting point
new SampleAppStack(app, "RedRobot", {
  env: {
    account: config.awsAccountId,
    region: config.awsRegion,
  },
})

this is the SampleAppStack call which create the lambda and REST resources (API Gateway)

import * as cdk from "aws-cdk-lib"
import { Construct } from "constructs"
import * as lambdaNodeJs from "aws-cdk-lib/aws-lambda-nodejs"
import * as lambda from "aws-cdk-lib/aws-lambda"
import * as apigateway from "aws-cdk-lib/aws-apigateway"

export class SampleAppStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props)

    // create lambda
    const lambdaPdfGen = new lambdaNodeJs.NodejsFunction(
      scope,
      "pdfGenerator",
      {
        entry: "../../lambda/pdfGenerator",
        handler: "index",
        runtime: lambda.Runtime.NODEJS_20_X,
      }
    )

    // top level api gateway construct
    const restApi = new apigateway.RestApi(this, "restApi", {})
    const apiResource = restApi.root.addResource("/api/generatePDF")

    // attach the lamba PDF generator call to the rest api get call
    apiResource.addMethod("GET", new apigateway.LambdaIntegration(lambdaPdfGen))
  }
}

and this is the lambda function

// lambda/pdfGenerator
import * as lambda from "aws-lambda";

import {
    fetchCustomerActiveProject,
    fetchCustomerActiveProject,
    fetchInvoice,
    generateInvoicePDF,
    parseCustomerId
} from '../api'

export const generateCustomerInvoiceLambda: lambda.APIGatewayProxyHandler =
  async function (event: lambda.APIGatewayProxyEvent, context: lambda.Context) {
    try {

      const { customerId } = parseCustomerId(event.body);
      const activeProject = fetchCustomerActiveProject(customerId);
      const invoice = fetchInvoice(activeProject.id);
      const pdfGenResult = generateInvoicePDF(invoice);

      if(!pdfGenResult.success) {
        throw new Error(pdfGenResult.error);
      }

      return {
        ...
        body: {
            filepath: pdfGenResult.filepath
        },
      };

    } catch (e: any) {
       ...
    }
  };

This code is all you need to get started, eliminating the need for manual resource creation mentioned in the server section.

An important point to note: We used AWS's Infrastructure as Code (IaC) framework, CDK, to write the infrastructure code. We could have done the same for the server-oriented code mentioned earlier, but it would have been more complex, involving writing a Dockerfile, using a service like Fargate to upload and host the Docker image, and etc.
The IaC code shown here isn't strictly a component of serverless architecture. However, since serverless involves heavily utilizing AWS services, not using an IaC framework would make working with serverless very difficult. If you're interested in learning more about IaC, refer to the end of the document.

Should I care about this as a Business owner?

This version of the passage is well-written and clear. The improvements you've made have addressed the issues in the original text. Here's the passage with minor refinements:
As a business owner, it's crucial to understand these technologies, particularly if your web application is central to your operations.
It's equally important to recognize when serverless isn't the best choice. Depending on your specific requirements, serverless might be costlier compared to alternatives like a Kubernetes deployment solution.
Consider a scenario where your business develops software for parsing and managing legal documents. In this case, you might opt for a container-based infrastructure instead of serverless due to the critical nature of the data being parsed and stored. This approach preserves the flexibility to deploy your code on-premises, which is especially valuable when dealing with sensitive data that cannot be hosted on public cloud infrastructure.

Do you want to learn Serverless?

I‘ve developed a comprehensive Udemy course that guides you through building a Serverless Single Page Application (SPA) from the ground up using AWS, AWS CDK, AWS SDK, Next.js and TypeScript, explaining key concepts as you progress through the class. Prerequisites are limited to basic JavaScript and React knowledge.

Serverless Fullstack with AWS/CDK/NextJS & Typescript.

Check out https://redrobot.dev/ if you need help with a project, consultation or training.