NextJS is the most popular React Framework on the planet. Familiarity and the sheer amount of educational content available for NextJS make it almost a default for small teams when starting a new project. There are many reasons you may want to host your Next.js application on AWS. Vercel, the company behind the open-source Next.js framework, offers application hosting with an unmatched developer experience. It is not a good fit for every project; concerns about vendor lock-in, costs at scale, and enterprise infrastructure requirements are driving an accelerating migration toward alternative hosting and frameworks.
For CTOs and engineering leaders evaluating hosting options, the decision extends far beyond simple cost comparisons. The choice impacts development velocity, operational complexity, security posture, and long-term architectural flexibility. Teams finding themselves constrained by Vercel’s pricing model, needing private database access, or requiring integration with existing AWS infrastructure face a complex landscape of deployment alternatives, each with distinct trade-offs that aren’t immediately obvious.
This analysis examines three approaches to running Next.js applications on AWS:
- Elastic Compute Cloud (EC2) / Elastic Container Service (ECS) / Elastic Kubernetes Service (EKS)
- AWS Amplify
- Lambda (SST/OpenNext)
We’ll explore how each option compares to Vercel’s hosting across dimensions that matter for business decisions: cost predictability, infrastructure control, security capabilities, and operational overhead (including developer productivity).
The goal isn’t to prescribe a universal solution; there isn’t one. Instead, this guide provides the knowledge needed to make an informed decision based on your organization’s specific constraints, growth trajectory, and technical capabilities. Whether you’re a startup hitting Vercel’s cost ceiling or an enterprise requiring private networking, understanding these options will help you choose the approach that aligns with your priorities and resources.
How Next.js Runs on Vercel
On Vercel, your Next.js application automatically deploys as a combination of serverless functions and static assets.
Edge Runtime
Vercel offers two execution environments. A Node.js runtime for full compatibility and an Edge Runtime for maximum performance. Edge functions run globally by default and are deployed to the regions closest to users to minimize latency. They use a lightweight runtime built on the V8 engine, providing virtually no cold starts and significantly faster execution than traditional serverless functions.
Automatic Infrastructure Scaling
Vercel handles the complex orchestration between static assets served from their CDN, serverless functions for dynamic content, and edge functions for middleware. They automatically determine the optimal deployment strategy for each route in your application, seamlessly handling transitions among static, server-rendered, and incrementally regenerated pages.
What You Lose When Moving Away
The migration from Vercel to AWS requires abandoning several platform-specific advantages.
Automatic Optimizations
Vercel’s automatic image, font, and script optimization requires manual configuration and third-party services. The seamless integration that “just works” on Vercel becomes a collection of services requiring individual setup and maintenance.
ISR Complexity
Incremental Static Regeneration works seamlessly on Vercel’s global edge cache but requires complex orchestration with S3, DynamoDB, and SQS on AWS. The automatic cache invalidation and global replication that happens transparently on Vercel could become a significant implementation challenge.
Edge Runtime Limitations
Vercel’s Edge Runtime compatibility doesn’t translate directly to other platforms. Middleware designed for Vercel’s edge environment may require significant refactoring for AWS Lambda or other serverless platforms.
Observability Gap
The integrated monitoring, error reporting, and performance analytics built into Vercel require assembling multiple third-party services (Sentry, DataDog, CloudWatch) when self-hosting, often at higher complexity and cost.
Option 1: EC2 / ECS / EKS
Architecture overview
The standalone server approach deploys Next.js applications in persistent runtime environments. A Node.js server is started to handle requests for static assets, SSR pages, and API routes. You can scale your applications horizontally or vertically and can configure external systems to offload and cache static content.
AWS offers several services for deploying long-running Node.js applications. The most common options for running a standalone Next.js server in AWS are ECS, EKS, and EC2. ECS and EKS are container orchestration services used by many organizations to run workloads at scale. EC2 is AWS’s lower-level virtual machine offering. ECS offers a gentler learning curve than EKS for teams new to container orchestration.
AWS Fargate is a serverless compute engine that can supply the compute for your Next.js application, orchestrated with ECS or EKS. Using Fargate shifts the responsibility for maintenance and security updates of your underlying virtual machines away from your team at a small additional cost.
How it differs from Vercel
Middleware
Vercel: Middleware runs in the Edge Runtime across a global CDN, providing low-latency execution close to users but with significant API limitations (no Node.js APIs, restricted npm packages).
Standalone Server: Middleware executes within your Next.js server using either the Edge Runtime (default) or full Node.js runtime. While you lose the global distribution advantage, you gain access to complete Node.js APIs and the ability to use npm packages that require the full Node.js runtime. This tradeoff often simplifies authentication middleware, database connections, and complex business logic that would be impossible in Vercel’s edge environment.
Image Optimization
Vercel: Automatic global image transformation and optimization happen at the CDN level with zero configuration.
Standalone Server: You must install the sharp dependency for production-grade image processing. Without it, Next.js falls back to slower, memory-intensive processing designed only for development. Many teams implement custom image optimization pipelines or integrate with services like Cloudinary for global delivery and transformation.
Caching Behavior
Vercel: Intelligent caching across their global edge network with automatic invalidation and ISR support.
Standalone Server: By default, Next.js uses the local filesystem cache, which can cause problems with multiple server instances because each instance has its own cache. You’ll need to configure custom cache handlers using Redis, DynamoDB, or other shared storage solutions to maintain consistency across multiple instances of your application.
Tradeoffs
Always-On Costs
Standalone servers incur 24/7 compute costs regardless of traffic. A basic ECS Fargate deployment costs approximately $50-100 per month for minimal resources, while equivalent EC2 instances with reserved pricing can reduce this to $20-40 per month. These fixed costs make standalone servers expensive for low-traffic applications but increasingly cost-effective as usage grows.
Scaling Economics
While serverless costs scale linearly with usage (sometimes exponentially during traffic spikes), standalone servers provide predictable monthly costs. You pay for allocated capacity rather than actual usage, making budgeting simpler but requiring expertise in capacity planning.
Scaling Characteristics
ECS and EKS provide sophisticated autoscaling based on CPU, memory, or custom metrics. However, scaling decisions happen over minutes rather than the milliseconds of serverless environments. This requires careful capacity planning and load testing to handle traffic spikes without over-provisioning resources.
Cold Start Elimination
Unlike serverless functions that experience cold starts, standalone servers maintain warm processes, providing consistent response times. This advantage becomes particularly valuable for applications requiring sub-100ms response times or complex initialization procedures.
Deployment Complexity
Moving away from Vercel will require establishing CI/CD pipelines, container registries, and deployment automation. Tools like AWS CodePipeline, GitHub Actions, or GitLab CI can recreate similar deployment experiences, but require initial setup and ongoing maintenance.
Infrastructure Monitoring
You’ll need to monitor server health, resource utilization, and application performance across multiple layers. This operational overhead is significant but provides complete visibility into your application’s behavior.
Security Responsibility
Standalone servers require security hardening, patch management, and compliance monitoring that managed platforms handle automatically. This responsibility extends across the container image supply chain, host operating system (unless using Fargate), and network configuration.
When to choose ECS / EKS / EC2
Internal Developer Platform Supported
If your organization provides a useful abstraction over AWS or your team already has AWS expertise, the significant resource and experience requirements of this choice may not be a concern.
Predictable High Volume Traffic
If your application receives predictable high-volume traffic, then the cost savings potential of reserved long-running compute may offset the implementation and operational engineering resource costs.
Security and Compliance Requirements
Organizations requiring specific regulatory compliance, custom security policies, or integration with existing enterprise security infrastructure gain the control necessary to meet these requirements. This level of infrastructure ownership may be impossible to achieve in Vercel’s managed environment.
When to avoid ECS / EKS / EC2
You are new to AWS
Running Next.js on container orchestration platforms requires competency across multiple domains simultaneously. Beyond learning AWS fundamentals (IAM, VPCs, security groups, CloudWatch), teams must understand containerization (Dockerfiles, image registries, container networking) and orchestration concepts (task definitions, services, load balancer target groups, health checks). Each layer introduces its own failure modes and debugging workflows.
Vercel abstracts away concerns that become your responsibility in a container environment: SSL certificate management, DNS configuration, blue-green deployments, secret rotation, log aggregation, and capacity planning. Teams accustomed to git push deployments often underestimate the operational surface area they’re accepting. The first production incident requiring you to trace an issue across CloudWatch logs, container health checks, ALB target group status, and ECS task state can be a jarring introduction to distributed systems debugging.
The other options in this guide (Amplify and SST/OpenNext) provide gentler on-ramps. Both abstract away orchestration complexity while still running within your AWS account. Teams can build AWS familiarity incrementally through these managed approaches before graduating to container orchestration if their requirements eventually demand it.
You Want Low Complexity or Cost Preview Environments
Allocating compute 24/7 for each preview environment can consume a significant portion of smaller companies’ infrastructure budgets, depending on team size and development workflows. Every preview environment requires its own running containers, load balancer listeners, and potentially database resources. The deployment pipelines and infrastructure supporting this all need to be designed, implemented, tested, and monitored.
Option 2: AWS Amplify
Architecture overview
AWS Amplify is a managed service that abstracts away infrastructure complexity. When you deploy a Next.js application to Amplify, the platform automatically detects your framework and provisions the necessary AWS infrastructure behind the scenes, creating a serverless deployment without requiring deep AWS expertise.
Amplify utilizes multiple AWS services to replicate Vercel’s functionality
- S3 buckets store static assets
- CloudFront provides global CDN distribution
- Lambda functions power server-side rendering and API routes
- CloudWatch handles logging and monitoring.
The platform automatically creates IAM roles and policies, configures security groups, and manages deployment pipelines.
Amplify’s CI/CD pipeline automatically triggers on Git commits, executes your build commands in isolated environments and deploys across AWS’s global infrastructure. The process typically takes 2-3 minutes and includes automatic SSL certificate provisioning, custom domain configuration, and preview deployments for feature branches.
What AWS Does Behind the Scenes
Understanding Amplify’s architecture reveals both its strengths and limitations. The platform essentially creates a simplified AWS deployment that mirrors many of Vercel’s features while maintaining compatibility with the broader AWS ecosystem.
For SSR Next.js applications, Amplify creates AWS Lambda functions to handle dynamic rendering and API routes. These functions run in Amazon’s managed environment with automatic scaling, but unlike Vercel’s edge functions, they typically execute from a single AWS region (though you can configure multi-region deployments). The platform automatically installs dependencies, such as sharp for image optimization, eliminating the manual configuration steps required in self-hosted deployments.
Static assets are distributed via CloudFront with intelligent caching headers, while dynamic content is served through Lambda functions integrated with the CDN.
Server-side logs automatically flow to Amazon CloudWatch, providing deep integration with AWS’s monitoring ecosystem. This offers more detailed observability than many competitors but requires familiarity with AWS tooling to leverage the insights fully.
How it differs from Vercel
Developer Experience Comparison
Amplify provides a similar developer-focused experience to Vercel, but with AWS’s characteristic complexity lurking beneath the surface. While basic deployments remain simple, advanced configurations require navigating AWS concepts such as IAM roles, CloudFormation stacks, and service limits. Amplify’s learning curve is steeper than Vercel’s, though shallower than managing raw AWS services.
Cost Structure Advantages
Amplify’s pricing model typically proves more cost-effective at scale than Vercel’s usage-based billing. Instead of metering every edge request and function invocation separately, Amplify charges for underlying AWS services (Lambda execution time, CloudFront data transfer, S3 storage) at AWS rates. For high-traffic applications, this can result in 40-60% cost savings compared to Vercel’s equivalent functionality.
In February of 2025, Vercel released Fluid Compute, which they claim has helped thousands of early adopters “reduce compute costs by up to 85%.” The primary cost reduction is due to billing for actual compute consumed, not the entire compute runtime. It isn’t easy to compare costs to Amplify, since the savings depend on how much your backend is waiting for input/output and how much processing it performs.
Enterprise Integration Benefits
Unlike Vercel’s managed environment, Amplify applications run within your AWS account, enabling integration with existing security policies and compliance frameworks. This architectural difference allows enterprise teams to maintain security standards while benefiting from managed deployment pipelines.
Tradeoffs
Despite Amplify’s managed convenience, several significant limitations differentiate it from both Vercel and self-hosted AWS deployments.
VPC and Private Database Access
Amplify’s most significant restriction is the inability to deploy Next.js applications with VPC access. This means your application cannot securely connect to private RDS instances, ElastiCache clusters, or other AWS resources that require a VPC for network connectivity. For many enterprise applications, this single limitation eliminates Amplify as a viable option.
On-Demand Incremental Static Regeneration
Amplify currently lacks on-demand ISR support. This means you can not remotely trigger an incremental regeneration.
Edge Runtime Limitations
Amplify doesn’t offer direct equivalents to Vercel’s Edge Functions or Edge Config. Middleware and dynamic logic execute in standard Lambda functions rather than at edge locations, which can increase latency for globally distributed applications.
When to choose Amplify
AWS Ecosystem Integration
Your organization already uses AWS services and wants unified billing, security policies, and support contracts. The ability to leverage existing AWS expertise and infrastructure makes Amplify’s learning curve manageable.
Cost-Conscious Scaling
Applications expecting significant traffic growth benefit from AWS’s more predictable pricing model. Unlike Vercel’s multi-dimensional metering, Amplify costs scale more linearly with actual resource consumption.
Enterprise Security Requirements
Organizations requiring specific compliance standards, audit trails, or
security configurations that managed platforms cannot provide. Amplify runs in your AWS account, enabling custom security policies and integration with existing enterprise tools.
Simplified AWS Adoption
Teams wanting AWS benefits without deep cloud expertise. Amplify provides a gentler introduction to AWS services while maintaining migration paths to more complex architectures.
When to avoid Amplify
Private Database Requirements
Any application requiring secure, private database connections. The VPC limitation is architectural and unlikely to be resolved without fundamental platform changes.
Vercel Feature Dependencies
Applications heavily utilizing Vercel-specific features like Edge Config, Edge Functions, or advanced ISR patterns. These capabilities have no direct Amplify equivalents.
Complex Routing Needs
Applications with extensive redirect requirements, complex rewriting rules, or advanced middleware logic may hit Amplify’s configuration limitations.
The decision ultimately depends on weighing infrastructure control and cost predictability against developer experience and feature completeness. Amplify serves as an effective middle ground for organizations committed to AWS infrastructure but seeking managed deployment simplicity for smaller teams, provided they can work within its architectural constraints.
Option 3: Lambda (SST/OpenNext)
Architecture overview
SST is a framework for deploying applications and infrastructure. It leverages OpenNext to deploy Next.js applications to AWS. OpenNext is a build transformation tool that repackages standalone Next.js build output for serverless platforms.
SST v3 uses Pulumi behind the scenes but presents a developer-friendly TypeScript API through its component system. A single TypeScript file defines your entire infrastructure using familiar programming patterns rather than cloud-specific abstractions or domain-specific languages. The framework supports over 150 providers, allowing you to mix AWS services with other platforms.
SST’s Next.js component automatically handles OpenNext configuration and deployment. It detects your Next.js application structure, manages OpenNext version compatibility, provisions the necessary AWS infrastructure (Lambda functions, S3 buckets, CloudFront distributions), and handles resource linking so your application can securely access other AWS services without hardcoding credentials.
AWS Infrastructure Under the Hood
Understanding the AWS architecture that SST creates reveals both the power and complexity of the OpenNext approach. The deployment typically provisions 15-25 AWS resources working together to replicate Vercel’s functionality.
S3 buckets store static assets and serve as the origin for a CloudFront distribution, providing global CDN caching with intelligent cache policies optimized for Next.js patterns. Lambda functions handle server-side rendering with automatic horizontal scaling, while additional Lambda functions manage ISR background processing, image optimization, and custom middleware logic.
CloudFront integrates with Lambda@Edge for request routing decisions, S3 serves pre-rendered static pages and assets, DynamoDB manages ISR cache metadata and invalidation tracking, SQS queues coordinate background revalidation processes, and IAM roles provide least-privilege access between services. CloudWatch automatically collects logs and metrics from all Lambda functions.
How it differs from Vercel
Cold Starts vs. Edge Performance
Vercel’s Edge Runtime provides near-zero cold starts globally. SST/OpenNext uses standard Lambda functions, which have cold starts (typically 200-500ms for Node.js). Provisioned concurrency can mitigate this but adds cost.
ISR Implementation
Vercel handles ISR transparently across their global edge cache. SST/OpenNext replicates this using DynamoDB for cache metadata and SQS for background revalidation.
Image Optimization
Vercel and SST both use Lambda based image optimization, but Vercel’s is globally distributed at the edge. SST’s image optimization Lambda runs in a single region by default.
Tradeoffs
Cold Start Latency
Lambda functions experience cold starts when no warm instances are available. For Next.js SSR routes, this typically adds 200-500 ms to the first request after a period of inactivity. Provisioned concurrency can eliminate cold starts, but adds fixed monthly costs that reduce the serverless cost advantage. Applications requiring consistent sub-100 ms response times may find this latency unacceptable.
Dependency Chain Complexity
Your production application depends on multiple layers remaining compatible: Next.js releases new features and occasionally changes internal behavior, OpenNext must adapt its build transformation to match, SST must update its component to work with new OpenNext versions, and AWS services evolve their own APIs and behaviors. A breaking change at any layer can block upgrades or cause subtle production issues. This creates upgrade friction that managed platforms handle transparently.
Debugging Across Boundaries
When issues occur, determining the root cause requires understanding multiple systems. A failed request might stem from your Next.js code, OpenNext’s build transformation, SST’s infrastructure provisioning, Lambda’s execution environment, CloudFront’s caching behavior, or IAM permission boundaries. Each layer has its own logging, error patterns, and debugging tools. Teams accustomed to Vercel’s integrated error reporting often underestimate this operational surface area.
Regional Execution Model
Unlike Vercel’s global edge network, SST deploys Lambda functions to a single AWS region by default. Users geographically distant from your chosen region experience higher latency for SSR pages and API routes. Multi-region deployments are possible but require additional configuration and increase infrastructure complexity.
AWS Account Variations
Identical SST configurations can behave differently across AWS accounts. Service quotas, organizational SCPs, regional service availability, and account age all affect deployment behavior. Issues like Lambda functions returning empty responses, CloudFront cache inconsistencies, or IAM permission edge cases create environment-specific problems that are difficult to reproduce and debug.
When to choose SST
Private Network Requirements
Applications requiring secure connections to private databases, caches, or internal services. Unlike Amplify, SST can deploy Lambda functions inside a VPC, enabling connections to RDS instances, ElastiCache clusters, and other resources that require private network access. If your application needs both serverless scaling and private networking, SST may be your only managed option on AWS.
Variable or Unpredictable Traffic
Applications with significant traffic variability benefit from Lambda’s pay-per-request model. Marketing sites with campaign-driven spikes or new products with uncertain demand avoid paying for idle capacity. The ability to scale to zero makes SST particularly cost-effective for applications that receive little traffic outside peak periods.
Preview Environment Requirements
Teams needing isolated preview environments for every pull request. Since Lambda scales to zero, preview environments cost almost nothing when not actively being tested. This contrasts sharply with ECS deployments where each preview environment requires always-on containers, load balancer listeners, and associated infrastructure costs.
Infrastructure as Code Priority
Organizations that want infrastructure defined, versioned, and reviewed alongside application code. SST’s TypeScript configuration integrates naturally with existing development workflows. Infrastructure changes go through pull request reviews, enabling the same collaboration patterns used for application code. This approach prevents configuration drift and creates an audit trail of infrastructure evolution.
Vercel Migration with Behavior Parity
Teams migrating from Vercel who want to minimize behavioral differences. OpenNext explicitly aims to replicate Vercel’s Next.js behavior on AWS. While not perfect, this focus on compatibility reduces the surprises teams encounter compared to building custom ECS deployments or adapting to Amplify’s implementation differences.
When to avoid SST
Limited DevOps Capacity
Small teams without dedicated DevOps expertise or time to invest in infrastructure management. While SST abstracts significant complexity, production issues still require understanding Lambda execution, CloudFront caching, IAM permissions, and distributed systems debugging. Teams expecting Vercel-level operational simplicity will find the gap significant.
Latency-Sensitive Applications
Applications where consistent sub-100ms response times are critical. Cold starts, single-region deployment, and the additional network hops through CloudFront and Lambda add latency compared to Vercel’s globally distributed edge runtime. While provisioned concurrency and multi-region deployments can mitigate these issues, they add cost and complexity.
Stability Over Features
Organizations prioritizing long-term stability over access to the latest Next.js features. The OpenNext project must continuously adapt to Next.js changes, and new features may take weeks or months to receive full support. Teams running business-critical applications may prefer the stability of a standalone server deployment where Next.js runs in its intended Node.js environment without build transformation.
Simple Deployment Needs
Applications that do not require VPC access, complex AWS integrations, or fine-grained infrastructure control. If Amplify meets your requirements, its simpler operational model and direct AWS support make it a more pragmatic choice. SST’s additional flexibility comes with additional responsibility.
Conclusion
The Next.js deployment landscape presents organizations with both significant opportunities and strategic considerations. Vercel’s tight integration with Next.js delivers an exceptional developer experience, setting the standard for deployment simplicity and framework optimization. However, as organizations grow, factors such as escalating costs, vendor lock-in concerns, and enterprise infrastructure requirements are increasingly driving interest in self-hosted alternatives.
Key Takeaways for Decision Makers
- No Universal Solution Exists: Each deployment approach represents distinct trade-offs between developer velocity, operational complexity, cost predictability, and infrastructure control. The optimal choice depends entirely on your organization’s current constraints, growth trajectory, and technical capabilities.
- Cost Considerations Are Complex: Simple price-per-GB comparisons miss the complete picture. Factor in operational overhead, debugging complexity, team training costs, and migration expenses. The cheapest infrastructure option often becomes expensive when total cost of ownership includes engineering time and productivity impacts.
- Security Requirements Drive Decisions: For enterprises requiring private database access, Amplify is immediately eliminated regardless of other factors. Vercel’s Enterprise tier does offer Secure Compute for VPC connectivity, but organizations evaluating AWS alternatives have often already ruled out Vercel due to cost, contractual, or strategic concerns.
- Team Capabilities Matter More Than Technology: Underestimating operational complexity leads to production issues and hidden costs that often exceed managed platform premiums. Honestly assess your team’s DevOps expertise before committing to self-hosted solutions.
- Migration Is Possible But Complex: Moving away from Vercel requires careful planning and systematic execution, but it’s entirely feasible with proper preparation. The technical migration is often straightforward; the operational changes and team adaptation typically require more time and attention than initially expected.
Moving from Vercel to AWS adds complexity in exchange for increased flexibility and potential cost savings. I hope this guide helps you understand where the increased complexity might exist for your team.
