Vercel to AWS migration: the bill at which it pays to move.

Why is Vercel so expensive as you grow?

Mostly seats, function memory and add-ons, not bandwidth. Those are the lines that push the Vercel cost per month up as a team grows.

Bandwidth used to be the scary line. With Flat Rate CDN it mostly isn't for a normal web app: 50 TB a month for $20 is in line with CloudFront's own $15 flat-rate plan. The growth now comes from these, roughly in the order we'd check them:

• Seats. $20 per deploying engineer: fifteen is $300 a month before a single request. AWS has no seat charge.
• Provisioned Memory. CPU billing pauses while a function waits on the database or an AI model, but memory keeps billing for as long as the instance is alive. Slow upstream calls show up here, not under CPU.
• Middleware that runs on everything. Vercel's docs warn that Middleware can incur Fast Origin Transfer twice for one function request. A matcher that skips static files and images is the fix.
• Image transformations. Billed on every cache miss and stale image, so many sizes and short TTLs multiply them.
• ISR writes. A write happens only when the page output changes. A timestamp or a random value in the page means every revalidation is a paid write.
• Add-ons. SAML SSO is $300 a month, a HIPAA BAA $350, Static IPs $100 per project, Password Protection $20 per project, a Preview Deployment Suffix $100. Extra custom environments are $50 a month per pack of five, beyond the one each project includes.
• Region and tier jumps. Function and CDN prices vary by region; São Paulo Active CPU is $0.221 an hour against $0.128 in iad1. Crossing a Flat Rate tier boundary moves the CDN line from $20 to $100 to $300.

Fix these before you price a migration. If the bill drops enough that moving stops being worth it, that's a good outcome.

What happened in the Vercel security breach, and what should you do?

According to Vercel's own bulletin, in April 2026 Vercel found unauthorized access to some of its internal systems; its first update is dated 19 April. The attack started with a compromise of Context.ai, a third-party AI tool used by a Vercel employee. The attacker took over that employee's Google Workspace account, then their Vercel account, and moved through internal systems. They enumerated and decrypted environment variables that were not marked as sensitive for a limited set of customers, and Vercel later found a small number of additional affected accounts. Vercel says no npm packages it publishes were compromised. It marked remediation complete and closed the incident on 16 October 2026.

Vercel's advice to customers: rotate non-sensitive environment variables first, mark secrets as sensitive, turn on MFA, review activity logs and recent deployments, set Deployment Protection to at least Standard, and rotate bypass tokens. It also notes that deleting your projects or account doesn't remove the risk.

Our view: do that rotation now whether or not you move, because a migration doesn't un-leak a key. On its own a vendor breach isn't a reason to move: AWS is only safer if secrets live in Secrets Manager or Parameter Store behind tight IAM. If a customer's security questionnaire asks, that's where SOC 2 infrastructure on AWS starts.

How to migrate from Vercel to AWS, step 1: write down everything Vercel does for you.

Moving from Vercel to AWS takes six steps: an inventory, the AWS build, deploys and previews, a parallel week, the DNS cutover and a rollback plan. This first one is the step people skip.

Migrations go wrong on what the platform did quietly. Get the list from the project:

• vercel.json and next.config.js: rewrites, redirects, headers, image domains, cron schedules, function regions and memory.
• vercel env pull for each environment. Mark the secrets, and rotate them as you copy them.
• Routes that set runtime = "edge", the middleware or proxy file and its matcher, ISR routes and anything calling revalidatePath or revalidateTag.
• Every storage product and integration (Blob, Edge Config, Marketplace databases, analytics), who bills it, and where it moves.
• Domains, and whether they use Vercel's nameservers. This matters in step 5.
• Webhooks, OAuth redirect URLs and partner allowlists pointing at *.vercel.app or relying on Vercel Static IPs.

If the app was generated in Lovable, Replit or Bolt, do the security checks in taking a vibe-coded app to production before you move it.

Step 3: rebuild the deploy flow your team is used to.

Engineers shouldn't notice this step: merge to main and production updates, open a pull request and a preview link appears.

1. Build once. One image (or one OpenNext bundle) per commit, tagged with the commit SHA, promoted from preview to staging to production without rebuilding.
2. Previews. A workflow that deploys the PR to pr-123.preview.example.com, posts the link, and deletes it when the PR closes. Put previews behind a password or SSO; Vercel previews had Deployment Protection, and yours should too.
3. Rollback. A workflow input that redeploys a previous SHA.
4. Secrets. GitHub Actions reaches AWS through OIDC and a role, never long-lived keys.

Builds now run on your CI minutes instead of Vercel's build minutes. Price them before you assume they're free.

Step 4: run both for a week before DNS moves.

Most Vercel apps keep their data elsewhere (Postgres, Supabase, a separate API), so unlike a Heroku migration there is usually no database to move. That makes it possible to run AWS and Vercel side by side against the same data:

• Serve staging from AWS for a week. Check every route type: static, SSR, ISR, API routes, Server Actions, images, redirects.
• Compare Cache-Control headers on ISR and dynamic pages between the two, so CloudFront caches what it should and nothing else.
• Load test the AWS side at twice your peak.
• Check that cron jobs run once, not twice. Disable them on one side before the switch.

If you are also moving a database off a hosted provider, that is the hard part and needs its own plan; our Supabase to AWS page covers the Postgres side.

Step 5: the DNS cutover, planned to the minute.

1. A week before: request an ACM certificate in us-east-1 (CloudFront only uses ACM certificates from that Region) and validate it with DNS. Add the domains to the distribution as alternate names.
2. If your domain uses Vercel's nameservers: Vercel creates the apex and first-level subdomain records automatically, so they may not appear as records you added. Move DNS to Route 53 first, recreate every record (mail, TXT, subdomains) and let it settle while traffic still goes to Vercel.
3. Two days before: lower the TTL on the records you'll change to 60 seconds.
4. Test without DNS: curl --resolve the real hostname to CloudFront; check the certificate, redirects and a sign-in.
5. At cutover: point the record at the CloudFront distribution. Use a Route 53 alias for the apex domain, or your provider's ALIAS or flattening.

Leave the domain attached to the Vercel project until the rollback window closes.

Step 6: the rollback plan, written before the night.

• The trigger. Agreed in advance: error rate above a set level, or a broken sign-in or checkout, for more than a set number of minutes.
• The steps. Point DNS back at Vercel. With a 60-second TTL that's minutes. Re-enable Vercel cron jobs if you disabled them.
• The data question. Small, because both sides share the database. Check uploads written to S3 during the AWS window.

Keep the Vercel project deployable for two weeks after cutover, and downgrade only after that. In the first week, run through the production readiness checklist and read the first days of the AWS bill line by line; what AWS costs a startup shows the lines that usually surprise. A migration rollback plan isn't a recovery plan; once you're on AWS, write a disaster recovery plan for AWS too.

When should you stay on Vercel?

When the bill is small, nobody wants to own infrastructure, or a high bill has one fixable cause.

We'd tell you to stay, on a call, if any of these is true:

• The bill is under a few hundred dollars a month. Profile A pays $40; no AWS setup beats that once someone has to look after it.
• Nobody wants to own infrastructure, and you don't want to pay someone to. That is what Vercel sells.
• The bill is high because of one fixable thing from section 03. Fix it and look again in three months.