Decision guide
AWS comes up in almost every infrastructure conversation — either because the team already has an account, because an enterprise customer requires it, or because someone read that "real" products run there. All three reasons can be valid. None of them automatically mean you should start with ECS, EKS, and a dozen managed services.
We run production on AWS, Vercel, and Cloudflare — depending on the product. The choice is not which vendor wins on social media. It is which combination gives you the least responsibility for what you actually need to deliver this month.
TL;DR
Key takeaways
- AWS makes sense when compliance, networking, data placement, or an existing cloud mandate dictates the choice.
- For many Next.js products, Vercel or Cloudflare is faster to operate with less platform work.
- Hybrid is normal: frontend on the edge, database and heavy jobs on AWS — not everything in one box.
- The hidden cost is operational competence: IAM, VPC, patching, and alert noise must be owned by someone.
- Portability beats perfect architecture: keep the app deployable in multiple places until constraints are real.
What AWS is actually good at
AWS is strongest when you need control: specific region, private networks, KMS, dedicated databases, queues, batch jobs, or integration with an existing VPC and on-prem via Direct Connect. It is the infrastructure large organisations already have competence in and contracts around.
Managed services like RDS Postgres, SQS, S3, and Lambda cover many SaaS needs without running Kubernetes — if you accept AWS-specific APIs and learn IAM properly. Container platforms (ECS, EKS) make sense when you have many services, existing Docker workflows, or a team already operating K8s.
What AWS does not automatically solve is productivity for frontend teams. Next.js deploy, preview environments, and edge caching you can get faster elsewhere. Putting the entire product on AWS "because it scales" without concrete scaling requirements is often buying a whole department you have not hired yet.
AWS, Vercel, or Cloudflare — when what
Left is the situation — right is what we typically recommend as a starting point.
Your situation
Enterprise customer or contract requires AWS and a specific region
Typical recommendation
AWS — accept the complexity and document the architecture early.
Your situation
The product is Next.js with auth, marketing, and app in the same repo
Typical recommendation
Vercel or Cloudflare for frontend; AWS for data and jobs if needed.
Your situation
You already have a DevOps team operating AWS daily
Typical recommendation
AWS — use existing competence instead of introducing a new platform.
Your situation
You are two developers who need to reach production within weeks
Typical recommendation
Avoid EKS. Choose a managed platform (Vercel/Cloudflare + managed Postgres) first.
Your situation
Heavy background jobs, file processing, or long queues dominate
Typical recommendation
AWS (Lambda, SQS, ECS) — the edge is for request/response, not everything.
Your situation
You want to be able to switch host without a rewrite
Typical recommendation
Keep the app portable; use AWS only where a constraint forces you — not as default.
The hybrid model most teams end up with
The setup we see most often in production is split: public pages and app shell on Vercel or Cloudflare for preview deploys, CDN, and low friction; database on RDS, Neon, Supabase, or equivalent; async work on SQS plus workers when there are reports, imports, or webhooks that must not block HTTP.
That requires clear boundaries: which env vars exist where, how secrets rotate, and how you log across systems. It is more integration than pure AWS — but less than building your own PaaS on top of EC2.
If you start hybrid, document it as a deliberate decision with a trigger for "move more to AWS" — e.g. data residency requirements, traffic patterns, or a customer already paying for dedicated infra. Without a trigger, hybrid ends up as permanent complexity without benefit.
Before you standardise on AWS
If you cannot say yes to most of these points, it is too early — or the wrong vendor.
- We can name a concrete constraint (compliance, region, existing VPC) — not just "scalability".
- There is a person or team that owns IAM, backup, alerts, and cost overview monthly.
- We have drawn network and data flow: what is public, what is in private subnets, where Postgres lives.
- We know how we deploy — not just how we clicked in the console once.
- There is a plan for staging that resembles production without costing the same as production.
- Exit or multi-cloud has been considered: what is AWS-specific, and what is portable standards?
Questions we get again and again
How do you choose between AWS and Vercel?
By constraints: long jobs, private networking, compliance, or a heavy backend often pull toward AWS. Fast Next.js delivery with low ops friction pulls toward Vercel. We compare total cost of ownership — including operational time and risk — not the hype around raw compute.
Should we use Terraform from day one?
When more than one person touches infra, yes — or an equivalent IaC tool you will own. Click-ops in the console scales poorly and is hard to review in due diligence. For an early spike it can wait; for production with customer data it should be in place before go-live.
Can we run Next.js on AWS?
Yes — via container, Amplify, or OpenNext-like patterns. The question is whether you get enough out of it versus Vercel/Cloudflare to justify the extra operations. We choose based on team and constraints, not on what is possible.
What about serverless vs. containers?
Lambda fits event-driven work with short runs. Containers fit steady HTTP, longer processes, and existing Docker images. Many products use both. Start with what matches your dominant workload — do not mix two compute models without reason.
How do we avoid vendor lock-in on AWS?
Use portable layers where it is cheap: Postgres, S3-compatible APIs where possible, standard OAuth, and avoid AWS-only features in the application core until you need them. Lock-in is often acceptable when the constraint is real — just take it as a deliberate decision.
Unsure about your cloud choice?
Let us match stack to your constraints — not to a diagram.
We will go through product, team, and compliance and recommend AWS, hybrid, or a simpler path — even when the answer is not AWS.