AWS vs Vercel vs Fly.io in 2026: Real Hosting Costs at Scale

The AWS vs Vercel vs Fly.io cost question almost never has a single right answer — it has a right answer for your traffic shape and team size. Pick Vercel and you buy developer velocity at a premium that gets brutal past a few hundred GB of bandwidth; pick raw AWS and you buy the cheapest unit economics along with a pager rotation you now have to staff. Get it wrong and the failure mode is predictable: a surprise five-figure invoice after a launch spike, or a two-week outage postmortem because nobody on a three-person team actually understood the VPC.

This piece models the real monthly bill on each platform at 10K, 100K, and 1M monthly active users (MAU), shows the cost levers that actually move the number, and gives you a migration runbook for the day you outgrow your first pick.

Cost & latency snapshot (the number you came for)

Bottom line at a glance (pricing quoted July 2026 from each provider's public rate cards — clouds change pricing, re-check before you commit):

• 10K MAU: Vercel ~$20–60/mo, Fly.io ~$25–70/mo, AWS ~$40–120/mo. At this scale the difference is a rounding error against one engineer-hour, so optimize for velocity, not cents.
• 100K MAU: Vercel ~$350–900/mo, Fly.io ~$180–450/mo, AWS ~$220–600/mo. The gap opens up. Vercel's bandwidth and function-invocation pricing starts to bite.
• 1M MAU: Vercel ~$3,000–9,000+/mo, Fly.io ~$900–2,500/mo, AWS ~$1,200–4,000/mo (before Savings Plans / committed-use discounts, which can cut 30–50%).

The ranges are wide on purpose — your egress volume and how compute-heavy your requests are will swing the bill 3–5x. The methodology and assumptions behind these numbers are in the sections below. Treat them as a model to plug your own numbers into, not a quote.

How each platform actually bills you

You cannot compare these three by staring at a per-hour price, because they don't sell the same unit. The mistake founders make is comparing a Vercel Pro seat to an EC2 instance. They're not the same product.

Vercel: bandwidth + invocations + seats

Vercel is a managed platform on top of AWS and Cloudflare. You pay for included resources on a plan tier (Hobby, Pro, Enterprise), then overages on bandwidth, function invocations, function duration (GB-hours), edge requests, and image optimizations. Per the Vercel pricing docs, the Pro plan bundles a baseline of usage and meters everything above it. The trap is that a viral spike bills as overage instantly — there is no cap unless you set spend controls.

Fly.io: machines you rent by the second

Fly.io sells Firecracker microVMs ("Machines") priced by CPU/RAM per second, plus persistent volumes, plus outbound bandwidth. You scale by adding machines in regions, and you can auto-stop idle machines so you pay near-zero when nobody is hitting them. The Fly.io pricing docs lay out the per-second machine rates and regional bandwidth tiers. It behaves like a lightweight VPS fleet with a global anycast network in front.

AWS: 200 services, 200 meters

AWS is not one product; it's a parts bin. A typical web app bill is EC2 or Fargate (compute) + RDS or Aurora (database) + an ALB (load balancer, billed per hour and per LCU) + CloudFront (CDN) + data transfer out. The EC2 pricing page and on-demand rate card are your starting point, but the line item that surprises everyone is egress: data transfer out to the internet runs roughly $0.09/GB after the first free tier, and cross-AZ traffic is billed too.

The single biggest driver of the AWS vs Vercel vs Fly.io cost difference at scale is egress. A media-heavy app pushing 10 TB/month of bandwidth pays for that bandwidth on every platform — but the per-GB rate and what's bundled differs by an order of magnitude.

Modeled bills at 10K, 100K, and 1M MAU

Here are the assumptions so you can adjust them. Workload: a Next.js app with an API and a Postgres database. Traffic model: each MAU generates ~30 requests/month, average response 50 KB, plus ~200 KB/month of static/media per user. That yields roughly 6 GB egress at 10K MAU, 60 GB at 100K, and 600 GB at 1M — deliberately conservative for a text-and-UI app. A media-heavy or video app can be 10–50x higher, and the bill scales with it.

Read the pattern, not the exact digits. AWS carries a fixed floor (an ALB alone is ~$16–25/mo before traffic, RDS has a minimum instance) that makes it the most expensive option for tiny apps. Vercel is cheapest to start and most expensive to scale for bandwidth-heavy workloads. Fly.io tends to be the flattest curve because you rent compute at close to cost and its bandwidth is cheaper than AWS egress in most regions.

The cost levers that actually move the bill

Before you switch platforms to save money, pull these levers on the one you already run. Most "we have to leave Vercel" decisions are really "we never turned on caching."

• Cache aggressively at the edge. Every request served from CDN cache is an egress cost you pay once, not per user. On Vercel this is a Cache-Control header; on AWS it's CloudFront TTLs; on Fly.io it's your own cache layer or a fronting CDN.
• Kill idle compute. Fly.io's auto_stop_machines and AWS Fargate scale-to-low, or Lambda for spiky endpoints, stop you from paying for 3am silence.
• Commit for discounts once traffic is predictable. AWS Savings Plans and Compute Savings Plans cut 30–50% off on-demand for a 1- or 3-year commit. Don't commit until your baseline is stable — you'll over-provision.
• Right-size the database. RDS/Aurora is frequently the biggest line item. A read replica plus caching beats vertically scaling the primary for read-heavy apps.
• Watch egress paths. Cross-AZ chatter and NAT Gateway data processing are silent AWS killers — a NAT Gateway bills per-GB processed on top of its hourly rate.

For the deeper trade-off between paying per-request versus paying for always-on machines, our Kubernetes vs serverless cost breakdown models the crossover point in detail.

The migration runbook (Vercel → Fly.io or AWS)

The typical path is: launch on Vercel, hit a bandwidth or function-duration wall around 100K–500K MAU, then move the expensive workloads off. You rarely move everything — you move the parts Vercel meters most punishingly and keep the frontend where DX is best.

A minimal Fly.io deploy for the API tier you're offloading:

# fly.toml — auto-stop idle machines so you pay near-zero at night
app = "my-api"
primary_region = "iad"

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = "stop"
  auto_start_machines = true
  min_machines_running = 1

[[vm]]
  size = "shared-cpu-1x"
  memory = "512mb"

# ship it
fly launch --no-deploy
fly secrets set DATABASE_URL=postgres://...
fly deploy
fly scale count 2 --region iad,fra   # add a second region when latency demands it

If AWS is the target, define the compute in Terraform so the rollback is a terraform destroy, not a manual console cleanup:

resource "aws_ecs_service" "api" {
  name            = "api"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.api.arn
  desired_count   = 2
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.private_subnets
    assign_public_ip = false
  }
}

Rollback plan: keep the Vercel deployment live and weighted at 100% in DNS during migration. Cut traffic to the new backend behind a feature flag or a weighted DNS record (Route 53 weighted routing), verify error rates and p95 latency for 24 hours, then shift the weight. If the new tier misbehaves, flip the weight back to Vercel — no redeploy, blast radius is one DNS TTL. Never migrate the database and the compute in the same change window; move compute first, pointing at the existing DB, then move the DB.

Security posture across the three

Cost and security trade against each other here. Vercel and Fly.io hand you sane defaults (managed TLS, DDoS absorption, no VPC to misconfigure) — you're paying partly for not having a public S3 bucket incident. AWS gives you every knob, which means you own every misconfiguration.

• Vercel/Fly.io: HTTPS is on by default, secrets are managed, and the attack surface you control is mostly your own code. The risk is over-trusting the platform boundary and leaking secrets in build logs or environment variables exposed to the client bundle.
• AWS: you own IAM, security groups, VPC routing, and encryption-at-rest config. The failure mode is an over-permissive IAM role or a security group open to 0.0.0.0/0. Enforce least-privilege and run a scanner before launch — our cloud security checklist covers the audit steps.

Whatever you pick, put secrets in the platform's secret store (never in the repo), scope database access to private networking, and log egress so a compromised container can't quietly exfiltrate data. If you're handling payments or PII, the compliance surface (SOC 2, PCI) is smaller on managed platforms — one more hidden cost lever in AWS's column.

Head-to-head comparison

When NOT to use each

Don't use Vercel when you're bandwidth- or compute-heavy at scale (video, large media, long-running jobs) — the overage model makes you the product. It's also wrong for non-frontend backends where you're not using its framework integrations; you're paying a premium for features you don't touch.

Don't use Fly.io when you need a deep managed-services ecosystem (managed Kafka, dozens of first-party databases, fine-grained compliance attestations) — you'll end up bolting those on yourself. It's also not the pick if your team has zero appetite for thinking about regions and machines.

Don't use raw AWS if you're a team of one to three with a payload that fits comfortably on a managed platform. The rule of thumb: reach for AWS (and only then consider Kubernetes) when you have at least one engineer whose job includes infrastructure and a workload that a PaaS meters punishingly — not before. A small team on AWS spends its scarce hours babysitting a VPC instead of shipping. See our Vercel vs Cloudflare cost comparison if edge-first is your actual constraint.

The call

Start on Vercel or Fly.io. If your app is frontend-led and you value shipping speed over unit economics, Vercel until the bandwidth bill hurts. If you want the flattest cost curve and don't mind thinking in machines, Fly.io from day one. Move expensive workloads to AWS when — and only when — you have the traffic to justify committed-use discounts and a person to own the platform. The most expensive mistake isn't picking the "wrong" host; it's picking AWS too early and drowning a two-person team in undifferentiated ops.

Next step: before you migrate anything, model your own egress and compute numbers into the table above — then read our SaaS guide to cutting your cloud bill to pull the caching and right-sizing levers first.