Migrating Next.js Landing Page Projects from Vercel to AWS

Introduction

My team manages multiple landing page projects, including around 100,000 pages. Vercel initially served us well, especially with its preview URL feature for rapid feedback and built-in Next.js support to start development quickly. However, many of you may have seen this famous tweet about the surprising Vercel cost.

My team experienced a similar moment: our monthly costs jumped from ~$2,000 to ~$3,500 due to a single server error happening in one day. This led us to migrate to AWS ECS, a decision that significantly improved performance and cost efficiency.

What Did We Migrate?

To help understand the changes, here is a simplified version of our system diagram before and after migration:

Before migration, we had multiple Vercel projects routed by a Lambda@Edge function, which added significant complexity to our infrastructure.

After migration, we used the same ECS cluster to host API applications and multiple landing page projects. Server-to-server communication benefited from AWS’s private network, improving performance.

What We Gained from Migration

Cost Efficiency and Predictability

Our Vercel costs (primarily from function invocations and durations) dropped from ~$2,000 to ~$500 after moving to ECS. CloudFront costs remained relatively unchanged, but the migration eliminated unexpected spikes, ensuring a better night’s sleep!

Additional savings were achieved by using:

• ECS: ARM architecture, ECS on EC2, and cost-saving plans.
• CloudFront: CloudFront Security Bundles.

To retain the preview URL feature, we implemented it using GitHub Actions and CloudFormation.

Simplified System Complexity

Before migration, caching was a major pain point. With at least three layers - Redis for API responses, Vercel’s cache, and CloudFront—cache invalidation was often challenging. Vercel’s cache, in particular, required complete rebuilds and redeployments to clear.

After the migration:

• Full control of cache invalidation: Using on-demand revalidation, we can easily invalidate page-level cache.
• Simpler CloudFront Configuration: No need for additional Lambda@Edge functions or to integrate Vercel with CloudFront.
• Reduced Terraform Overhead: Managing multiple Vercel projects became unnecessary.

Improved Performance

Hosting on ECS yielded significant performance improvements, boosting our SEO rankings in Google Search Console:

Enhanced Observability

We already had a robust observability setup for ECS, including logs, metrics, and tracing. After the migration, landing page projects aligned seamlessly with this observability framework, providing consistent insights into our systems. This made troubleshooting and performance optimization much easier.

Conclusion

This migration validated our decision and provided a stable foundation for future growth. For teams facing similar challenges with scaling and costs, carefully evaluating infrastructure needs can reveal that sometimes, traditional approaches offer the most innovative solutions.

Looking ahead, we plan to migrate our entire service, including landing page projects, to Kubernetes. This will further unify our infrastructure, improve scalability, and provide even greater flexibility in managing our workloads.