Solución:
Next.js SSR + marco sin servidor + AWS Lambda
Para implementar su aplicación Next.js SSR, en lugar de seguir un enfoque tradicional de administrar y ejecutar una instancia AWS EC2 completa que sigue funcionando las 24 horas, los 7 días de la semana. En realidad, existe un enfoque más moderno y rentable que utiliza AWS lambda y el marco Serverless.
P. ¿Qué es AWS lambda?
AWS Lambda le permite ejecutar código sin aprovisionar ni administrar servidores. Solo paga por el tiempo de cálculo que consume.
P. ¿Qué es el marco sin servidor?
Serverless Framework Open Source le permite desarrollar aplicaciones con arquitecturas sin servidor e implementarlas con AWS Lambda, Azure Functions, Google CloudFunctions y más.
P. ¿Qué es Serverless-Next.js?
Este es un componente sin servidor creado solo para implementar la aplicación Next.js. Además, cualquiera de sus activos en las carpetas estáticas o públicas se cargan en S3 y se sirven desde CloudFront automáticamente, así que creo que esto es exactamente lo que está buscando. A continuación se muestra la arquitectura que explica cómo sirve su aplicación al usuario.
Si es nuevo en el marco sin servidor, le sugeriré que siga un curso gratuito de la comunidad sin servidor llamado Serverless para desarrolladores frontend
Si desea intentar implementar rápidamente su aplicación next.js, vea este tutorial Next.js y Lambda @ Edge con componentes sin servidor, que es parte del curso mencionado anteriormente.
NextJS + Serverless actualmente se implementa en Lambda Edge, que es no gratuito. No disfruta del nivel gratuito de Lambda (no [email protected]).
Si tiene un sitio web de poco tráfico, le recomendaría que lo implemente con Vercel.com, que utiliza Lambda (red AWS) en el backend.
Su versión hobby es gratuita y ofrece un generoso tráfico e invocación gratuitos. comparable a la capa AWS Lambda Free.
La implementación de una aplicación NextJS es tan fácil como cargarla en la implementación automática de Github + Vercel con la integración de GitHub. No necesita preocuparse por S3, el alojamiento o sus archivos estáticos, todo se aloja en Vercel en el momento en que ingresa a Github. Solo necesitas concentrarte en el desarrollo.
Cuando sus requisitos aumentan (pasa el paquete Hobby y pasa el paquete Pro), entonces se vuelve más rentable implementarlo en [email protected]
Para entonces, todo lo que necesita hacer es cambiar su dominio.
Módulo AWS Next.js Terraform
Creamos un módulo Terraform de código abierto como una alternativa de menor costo al marco Serverless para este caso de uso. En lugar de depender solo de [email protected] para todas las operaciones de SSR que utilizamos [email protected] solo para enrutamiento (como algún tipo de proxy inverso) y luego redirigir la solicitud internamente a través de API Gateway a un Lambda regional.
Dado que utilizamos CloudFront como proxy inverso, también podemos dividir la mayoría de las solicitudes de archivos estáticos entre _next/static/* para css, js, etc. y sírvelos directamente por S3 sin tocar el [email protected] proxy en absoluto.
Entonces, el costo por solicitud es diferente por ruta:
-
Solicitudes de activos estáticos: css, js, imágenes
Solo se aplican los costos de CloudFront y S3 (para errores de CloudFront)
-
Solicitudes de HTML: Rutas HTML previamente renderizadas o Rutas que necesitan renderización del lado del servidor (SSR)
Costos de Cloudfront, [email protected] (Proxy, medido en pasos de 50ms) se aplica.
-
Reescribir rutas que sirvan HTML pre-renderizado
Se aplican costos para S3.
-
Rutas que utilizan la representación del lado del servidor (SSR)
Se aplican los costos de HTTP API-Gateway y Lambda regional (SSR, medido en pasos de 1 ms).
-
Los costos totales suelen estar muy por debajo de 0,50 $ / mes para unos pocos miles de solicitudes con este modelo, al tiempo que se tiene un sitio de servicio rápido con tecnología de almacenamiento en caché de borde de CloudFront.
Encuentre más información sobre el repositorio de GitHub: https://github.com/dealmore/terraform-aws-next-js