Overview

• Next.js website resource is a purpose-built resource for deploying Next.js app using AWS Lambda (or AWS Lambda@Edge).
• On the background, it creates multiple different AWS resources required to run your Next.js website as efficiently as possible.

Copy
resources:
  web:
    type: nextjs-web
    properties:
      appDirectory: ./

Under the hood

• Stacktape uses open-source project OpenNEXT to build your Next.js application so that it is runnable in AWS Lambda function.
• On the background Stacktape creates following resources to host your Next.js app:

For more information refer to OpenNext docs.

Using edge

You can use Lambda@Edge by specifying useEdgeLambda property.

Copy
resources:
  web:
    type: nextjs-web
    properties:
      appDirectory: ./
      useEdgeLambda: true

Using warmer

You can specify amount of warm instances you want warmer to keep. By default, warmer is disabled.

Copy
resources:
  web:
    type: nextjs-web
    properties:
      appDirectory: ./
      warmServerInstances: 5

Using firewall

You can use web-app-firewall resource to protect your Next.js application from common web exploits that could affect application availability, compromise security, or consume excessive resources.

Copy
resources:
  web:
    type: nextjs-web
    properties:
      appDirectory: ./
      useFirewall: waf

  waf:
    type: web-app-firewall
    properties:
      scope: cdn

Environment variables

Injects environment variables into server function.

Copy
resources:
  web:
    type: nextjs-web
    properties:
      appDirectory: ./
      environment:
        - name: STATIC_ENV_VAR
          value: my-env-var
        - name: DYNAMICALLY_SET_ENV_VAR
          value: $MyCustomDirective('input-for-my-directive')
        - name: DB_HOST
          value: $ResourceParam('myDatabase', 'host')
        - name: DB_PASSWORD
          value: $Secret('dbSecret.password')

Custom domain names

Copy
resources:
  web:
    type: nextjs-web
    properties:
      appDirectory: ./
      customDomains:
        - domainName: mydomain.com

Accessing other resources

• For most of the AWS resources, resource-to-resource communication is not allowed by default. This helps to enforce security and resource isolation. Access must be explicitly granted using IAM (Identity and Access Management) permissions.

• Access control of Relational Databases is not managed by IAM. These resources are not "cloud-native" by design and have their own access control mechanism (connection string with username and password). They are accessible by default, and you don't need to grant any extra IAM permissions. You can further restrict the access to your relational databases by configuring their access control mode.

• Stacktape automatically handles IAM permissions for the underlying AWS services that it creates (i.e. granting web services permission to write logs to Cloudwatch, allowing web services to communicate with their event source and many others).

If your compute resource (nextjs server function) needs to communicate with other infrastructure components, you need to add permissions manually. You can do this in 2 ways:

Using connectTo

• List of resource names or AWS services that the nextjs server function will be able to access (basic IAM permissions will be granted automatically). Granted permissions differ based on the resource.
• Works only for resources managed by Stacktape in resources section (not arbitrary Cloudformation resources)
• This is useful if you don't want to deal with IAM permissions yourself. Handling permissions using raw IAM role statements can be cumbersome, time-consuming and error-prone. Moreover, when using connectTo property, Stacktape automatically injects information about resource you are connecting to as environment variables into your function.

Copy
resources:
  web:
    type: nextjs-web
    properties:
      appDirectory: ./
      connectTo:
        - myDatabase

  myDatabase:
    type: relational-database
    properties:
      engine:
        type: aurora-postgresql
        properties:
          instances:
            - instanceSize: db.t4g.medium

Using iamRoleStatements

• List of raw IAM role statement objects. These will be appended to the nextjs server function's role.
• Allows you to set granular control over your nextjs server function's permissions.
• Can be used to give access to any Cloudformation resource

Copy
resources:
  web:
    type: nextjs-web
    properties:
      appDirectory: ./
      iamRoleStatements:
        - Resource:
            - $CfResourceParam('NotificationTopic', 'Arn')
          Effect: 'Allow'
          Action:
            - 'sns:Publish'

cloudformationResources:
  NotificationTopic:
    Type: AWS::SNS::Topic

Known issues

Bundle size

Next will incorrectly trace dev dependencies to be included in the output node_modules, which will significantly increase the lambda bundle. For example, the @swc/core-* binary is ~33MB!

Add this to your next.config.js to help minimize the lambda bundle size

Copy
outputFileTracingExcludes: {
      '*': [
        '@swc/core',
        'esbuild',
        'uglify-js',
        'watchpack',
        'webassemblyjs',
        'sharp'
      ],
    },

Fetch behavior for ISR.

Only for next@13.5.1+

If you use ISR and fetch in your app, you may encounter a bug that makes your revalidate values inconsistent. The issue is that it revalidates using the lowest revalidate of all fetch calls in your page, regardless of their individual values. To fix this bug, you need to modify the fetch function in your root layout component with the following code snippet:

Copy
export default function RootLayout() {
  const asyncStorage = require("next/dist/client/components/static-generation-async-storage.external");
  //@ts-ignore
  const staticStore = (fetch as any).__nextGetStaticStore?.() || asyncStorage.staticGenerationAsyncStorage;
  const store = staticStore.getStore();
  store.isOnDemandRevalidate = store.isOnDemandRevalidate && !(process.env.OPEN_NEXT_ISR === "true");
  return <>...</>;
}

Pricing

All of the resources used in the overall architecture are pay-per-use.

Breakdown of costs:

CloudFront

CloudFront is used as CDN for caching responses and data in edge locations.

CloudFront pricing:

• ~ $0.085 per GB outgoing traffic to the internet (1 TB of data transfer out to the internet per month is free)
• ~ $0.0085 per 10,000 HTTPS requests (10,000,000 HTTPS Requests per month are free)

For exact prices, refer to AWS docs

AWS Lambda

The prices differ depending on whether you are using regional AWS Lambda or Lambda@Edge.

Regional AWS Lambda:

• ~ $0.0000000167 per millisecond of execution (with default memory setting of 1024)
• $0,2 per million executions

Lambda@Edge:

• ~ $0.00000005001 per millisecond of execution (with default memory setting of 1024)
• *$0,6 per million executions

For exact prices, refer to AWS docs

S3 storage

S3 bucket (file storage) is used for storing static content, fetch cache (when using AppRouter) and for ISR (when using PageRouter).

ISR (PageRouter) - In standalone mode, Next.js prebuilds the ISR cache during the build process. At runtime, NextServer expects this cache locally on the server. This is not possible in the Lambda environment due to its serverless nature. In a Lambda environment, the cache needs to be housed centrally in a location accessible by all server Lambda function instances. S3 serves as this central location.

Fetch cache (AppRouter) - Similar with ISR. Since Lambda execution environments are not durable, the fetch cache is stored in S3 bucket. The fetch function by default in next is cached and will be written to S3. You can disable the fetch cache by setting cache to no-store in the fetch options.

• Each get request to the cache will result in at least 1 GetObject to the S3 bucket.
• Each set request to the cache will result in 1 PutObject into S3 bucket.

Prices for S3 requests:

• GetObject - ~ $0.0004 per 1,000 requests
• PutObject - ~ $0.005 per 1,000 requests

For exact prices, refer to AWS docs

DynamoDB

The DynamoDB table is used to store Next.js cache tags.

• Each revalidateTag request will result in 1 Query in DynamoDB and a PutItem for each path associated with the tag. PutItem requests are grouped in batches of 25 using BatchWriteItem request.
• Each get request will result in 1 Query in DynamoDB
• Each set request will result in 1 Query in DynamoDB and a PutItem for each tag associated with the path not present in DynamoDB. PutItem requests are grouped in batches of 25 using BatchWriteItem request.

Prices for DynamoDB requests:

• Query - $0.25 per 1,000,000 read request units
• BatchWriteItem - $1.25 per 1,000,000 write request units

For exact prices, refer to AWS docs

Example pricing

Assumptions

Let's assume you have a website with 300k visitors a month:

• Page Views per Visitor: Each visitor views an average of 3 pages per visit.
• Static and Dynamic Content: Assuming that 50% of page views are served from the cache without hitting the server directly, thanks to the effective use of a CDN.
• API Calls per Page: Each dynamic page view results in an average of 2 API calls to the server for fetching dynamic content or data.

Which means:

• Total Page Views per Month: 300,000 visitors * 3 pages/visitor = 900,000 page views
• Page Views Hitting the Server (50% not served from cache): 900,000 page views * 50% = 450,000 page views
• Total API Calls: 450,000 server-hitting page views * 2 API calls/page = 900,000 API calls

Total Server Requests: 450,000 + 900,000 = 1,350,000 requests per month

Calculations

CloudFront Costs

• Data Transfer: 900 GB total (300,000 visitors * 3 pages/visitor * 1 MB/page), with the first 1 TB free.

  • $0 for data transfer as it's within the free tier.

• HTTPS Requests: 1.35 million requests (300,000 visitors * 3 pages/visitor * 1.5 requests/page). The first 10 million requests are free, so $0 for HTTPS requests.

AWS Lambda Costs (Regional)

• Execution Cost: With a 50% cache hit rate, 675,000 requests to Lambda (1.35 million * 50%).

  • 675,000 * $0.2 / 1,000,000 = $0.135

• Compute Cost:

  • 675,000 * 100 ms * $0.0000000167 = $1.12725

S3 Storage Costs

• GetObject and PutObject: Assuming 675,000 Lambda requests interact with S3:
  • GetObject: 675,000 * $0.0004 / 1,000 = $0.27
  • PutObject: 675,000 * $0.005 / 1,000 = $3.375

DynamoDB Costs

Given each Lambda request triggers 1 Query and 1 BatchWriteItem:

• Total DynamoDB Operations: 675,000 of each type.

• Query Cost:

  • 675,000 * $0.25 / 1,000,000 = $0.16875

• BatchWriteItem Cost:

  • 675,000 * $1.25 / 1,000,000 = $0.84375

Total Monthly Cost Estimate

• CloudFront: within free tier limits for data transfer and HTTPS requests = $0
• AWS Lambda (Regional): $0.135 (executions) + $1.12725 (compute) = $1.26225
• S3 Storage: $0.27 (GetObject) + $3.375 (PutObject) = $3.645
• DynamoDB: $0.16875 (Query) + $0.84375 (BatchWriteItem) = $1.0125

Total: $0 (CloudFront) + $1.26225 (Lambda) + $3.645 (S3) + $1.0125 (DynamoDB) = **$5.92 per month**

API reference