The Problem
Next.js is the dominant React framework and AWS is the dominant cloud platform, but getting them to play nicely together is still harder than it should be. Vercel makes deployment trivial, but many companies need (or want) to run on AWS for compliance, cost, or integration reasons.
After deploying Next.js to AWS for dozens of clients, here is what we have learned about each approach.
Option 1: AWS Amplify Hosting
Best for: Marketing sites, blogs, simple apps without complex backend requirements.
Amplify Hosting has gotten significantly better. It supports App Router, server components, and ISR. Deployments are git-push simple.
Pros:
- Zero config deployment from a Git repo
- Built-in CI/CD, preview branches, custom domains
- Serverless - you pay for what you use
- Managed SSL and CDN
Cons:
- Cold starts on server-rendered routes can be noticeable
- Limited control over the underlying infrastructure
- Debugging build failures can be opaque
- Some Next.js features lag behind Vercel support
Our take: Great for getting started fast. We use it for client marketing sites and internal tools. Not ideal for high-traffic apps where you need fine-grained control over caching and compute.
Option 2: ECS Fargate with CloudFront
Best for: Production SaaS applications that need reliability, scalability, and full control.
This is our default recommendation for serious production apps. You run Next.js as a Docker container on ECS Fargate, put CloudFront in front for caching and edge distribution, and use ALB for load balancing.
Pros:
- Full control over the runtime environment
- No cold starts - containers are always warm
- Easy to add sidecar containers (logging, monitoring, etc.)
- Scales horizontally with predictable performance
- Works with existing VPC, security groups, and IAM policies
Cons:
- More infrastructure to manage (we use Terraform for everything)
- Base cost even at zero traffic (~$30-50/month minimum)
- You own the deployment pipeline
Our take: This is what we deploy for 80% of our SaaS clients. The operational overhead is minimal once the infrastructure is templated, and the reliability and performance are worth it.
Option 3: Lambda@Edge / CloudFront Functions
Best for: Static-heavy sites that need occasional server-side logic at the edge.
Pros:
- True edge computing - low latency globally
- Pay-per-request pricing
- No servers to manage
Cons:
- Cold starts are real and painful for complex apps
- Lambda@Edge has strict size and timeout limits
- Debugging is significantly harder
- Not all Next.js features work cleanly
Our take: We rarely recommend this for full Next.js apps. It works for specific use cases like A/B testing at the edge or geolocation-based routing, but trying to run a full Next.js app on Lambda@Edge is fighting the platform.
Our Standard Stack
For most clients, we deploy:
- ECS Fargate running the Next.js Docker container
- CloudFront for CDN and caching
- ALB for load balancing and health checks
- ECR for container registry
- CodePipeline or GitHub Actions for CI/CD
- Terraform for all infrastructure as code
- CloudWatch for logs and metrics
The entire stack is templated. We can spin up a new environment in under an hour.
The One Thing Everyone Gets Wrong
Caching. Most teams either cache nothing (slow and expensive) or cache everything (stale data and bugs). The right approach is:
- Static assets get long cache TTLs with content hashing
- Server-rendered pages get short TTLs (60-300 seconds) with stale-while-revalidate
- API routes are not cached at the CDN level unless explicitly designed for it
- Use CloudFront cache policies - do not rely on Next.js headers alone
Get this right and your AWS bill drops by 30-50% while your site gets faster. For a deeper dive on reducing your cloud spend, check out our AWS Cost Optimization guide.
If you are running Next.js on AWS and fighting performance or cost issues, reach out - or learn more about our AWS cloud consulting and migration service. We have probably seen your exact problem before.