Vercel vs AWS
Both host production apps well. The question is not which company is bigger. It is whether your workload fits inside a function that has to finish fast.
The short answer
Choose Vercel when you are shipping a Next.js product and have no platform team; choose AWS when your compute shape or your scale economics have outgrown a managed function host.
Company size is a poor predictor here. We have watched a five-person team need AWS in month three because a background job ran long. We have also watched a funded product stay on Vercel for years, because its work is genuinely request-shaped.
The real question is what your code does. Does it answer a request in under a minute? Or does it hold a connection, run a queue, or process a job that takes longer than that?
Side by side
From each platform's own documentation, checked August 2026.
| Dimension | Vercel | AWS |
|---|---|---|
| What you manage | Git push triggers a build and deploy | You choose and wire the services yourself |
| Function duration | 300s default and max on Hobby; 300s default, 800s max on Pro and Enterprise, with an 1,800s extended maximum in beta | Lambda allows up to 900 seconds (15 minutes) per invocation |
| Request or response size | 4.5 MB documented ceiling, returns 413 beyond it | Payload limits vary by service; EC2 and containers have none of Vercel's shape |
| Long-running processes | Only as Vercel Workflows: a run can pause and resume for months, but every step must fit a function invocation; no process that holds a connection | Native, on EC2, ECS or Fargate |
| Networking into a private VPC | Enterprise only: Secure Compute gives a dedicated VPC with static IPs and peering into your AWS VPC; nothing on Hobby or Pro | Native VPC peering, security groups, private subnets |
| Region control | Functions run in a single region by default | You pick the region per service, and can span several |
| Egress-heavy workloads | Billed per project, harder to forecast at volume | Priced per service, more levers to control it |
| Operational load | Near zero; the platform owns the pipeline | Real; someone owns the account, the VPC, the IAM policy |
- RequestA user asks a question.
- Model callOften the fast part.
- Retrieval or tool useMultiple round trips add up.
- Function ceiling300s, 800s or a beta 1,800s, then a 504.
- Queue, in stepsWorkflows on Vercel or a worker on AWS: the job that actually finishes.
An agent that chains tool calls or a document pipeline that embeds a large file rarely finishes inside a serverless function. That is a queue with steps sized to the function limit, whether Vercel's own Workflows or one on infrastructure you control, not a longer timeout setting.
Vercel
Where it wins
- Preview URLs on every pull request, which turns review into clicking the real thing.
- Zero-maintenance deploy pipeline. Nobody owns build servers or release scripts.
- Next.js features arrive supported first, since the same company builds both.
- Instant rollback, because previous deployments stay addressable.
Where it hurts
- Function duration is capped: 300 seconds on Hobby, up to 800 seconds on Pro and Enterprise, with a beta 1,800-second extension, all documented.
- The 4.5 MB request and response ceiling breaks upload flows built for a normal server.
- Private networking is an Enterprise feature, so on Hobby or Pro reaching a private database or internal service takes extra work.
- Usage-based pricing is hard to forecast before real traffic arrives.
AWS
Where it wins
- Lambda documents up to 900 seconds per invocation, and EC2 or containers have no invocation limit at all.
- Native VPC networking, so a private database or internal API is a normal connection, not a workaround.
- You choose the region per service and can run in several at once.
- Every layer, compute, network, storage, is priced and tuned on its own, which matters once volume is real.
Where it hurts
- Nobody deploys it for you. Someone on the team owns the account, the IAM policy and the pipeline.
- No preview URL per pull request out of the box; you build that yourself or add a tool for it.
- More services means more surface to misconfigure, and a bad security group is a real incident.
- Small projects pay in setup time what they save in ceiling headroom they will never hit.
How to choose
- Choose Vercel if the product is Next.js, the team has no platform staff, and every job answers a request in well under a minute.
- Choose AWS if a job has to hold a connection or run as one process past the function limit, needs a private network into a database or internal service without an Enterprise plan, or needs compute you tune yourself. A queue alone no longer forces the move.
- Choose AWS if egress or compute at your traffic level is the largest line in the hosting bill and you need to tune it directly.
- Choose both if the front end is genuinely request-shaped and the heavy work is not. Vercel serves the app; AWS runs the queue behind an API.
- Choose neither yet if you have no production traffic. Model the actual shape of the workload before picking infrastructure for it.
AI systems that outgrew a request-response shape
Questions teams ask before moving
01Does Vercel get more expensive than AWS at scale?+
Often, yes, once traffic and compute grow. Vercel bills per project on a usage model, with fewer levers to tune than AWS gives you per service. The crossover point depends on your actual traffic and job shape, not a fixed size of company. Model your own numbers before assuming either direction.
02Can we run part of our app on Vercel and part on AWS?+
Yes, and it is the common pattern for AI products. The Next.js front end and any request-shaped API stay on Vercel. Jobs that hold a connection, compute you tune yourself and, below Enterprise, anything needing a private network move to AWS, and the two talk over an API. A queue of function-sized steps can stay on Vercel as a Workflow.
03What is the actual signal that we should move off Vercel?+
A function timing out. Vercel documents this as a 504 with FUNCTION_INVOCATION_TIMEOUT once a job runs past its plan's duration cap. The first time you see that error in production is the signal, not a general sense that the app has grown. If the job splits into function-sized steps, Vercel Workflows is the first thing to try; if it cannot, move.
04How hard is it to move from Vercel to AWS later?+
The Next.js application itself is portable and can be self-hosted or containerized. What does not move so easily is the deploy experience. Preview URLs, instant rollback and zero-maintenance builds are habits your team will have to replace with tooling of your own.
