Ein Kunde rief mich an einem Montagmorgen vor einem Jahr an. Keine Nachricht. Ein Telefonanruf. Das ist nie ein gutes Zeichen. Er hatte eine Next.js-Marketingwebseite auf Vercels Pro-Plan am Donnerstag vorher deployt, eine Produkteinführung übers Wochenende durchgeführt und wachte zu einer 340-Dollar-Rechnung in seinem Postfach auf. Die Website lief großartig. Der Traffic ist in die Höhe geschossen. Und Vercel hatte jedes Gigabyte Daten, das ihre Server verließ, stillschweigend abgerechnet. Er hatte keine Ausgaberobergrenze gesetzt. Keine Benachrichtigung konfiguriert. Nichts.
Dieser Anruf ist der Grund, warum ich jetzt vor jedem Production-Deployment mit jedem Kunden zwanzig Minuten Vercel-Abrechnungshygiene durchgehe.
Hier ist, was du über Vercels Bandbreitenabrechnung wissen musst, warum es Leute überrumpelt und was du wirklich dagegen tun kannst.
---
Was „Egress" bei Vercel wirklich bedeutet
Egress ist Daten, die aus Vercels Netzwerk zum Endnutzer übertragen werden. Jedes Bild, jedes JavaScript-Bundle, jede API-Response, jede Font-Datei. Wenn es ihre Edge verlässt und einen Browser erreicht, zählt es.out of Vercel's network to the end user. Every image, every JavaScript bundle, every API response, every font file. If it leaves their edge and hits a browser, it counts.
Im Hobby-Plan bekommst du 100GB Bandbreite pro Monat, inklusive. Bei Pro sind es 1TB. Klingt nach viel. Aber hier ist der Haken: Wenn du große Bilder auslieferst, Server-Side Rendering auf Seiten mit großen JSON-Payloads machst, oder deine App einen plötzlichen Traffic-Spike bekommt, kannst du 1TB schneller überschreiten, als du denkst. Vercel berechnet $0,15 pro GB Überschuss bei Pro, Stand jetzt (immer ihre aktuelle Pricing-Seite checken, weil das sich ändert).their current pricing page because this moves).
Also 500GB über deinem Limit sind $75. Nicht katastrophal. Aber ein viraler Moment, ein verpfuschtes Image-Optimierungssetup oder ein Scraper, der deine API-Routes hammert? Das können tausende sein.
Warum das die Leute überrascht
Das Ding ist, lokale Entwicklung gibt dir null Hinweise. Du buildest schnell, deployest schnell, alles fühlt sich gut an. Vercels Dashboard zeigt Bandbreitennutzung, aber es schreit dich nicht an. Wenn du nicht proaktiv einen Billing-Alert eingerichtet hast, erfährst du davon, wenn die Rechnung ankommt.
---
Die Configs, die deine Rechnung am ehesten ruinieren
Ich habe viele Deployments bei Seahawk auditiert. Es gibt vier Übeltäter, die ich immer wieder sehe.
1. Unoptimierte Bilder, die next/image umgehen
next/image ist wirklich gut in dem, was es tut. Es ändert Größe, konvertiert zu WebP und cached. Aber ich habe Projekte gesehen, wo Entwickler Bilder direkt aus einem <img>-Tag zogen, der auf Bilder in voller Auflösung in einem S3-Bucket zeigte, proxiert durch eine Vercel API-Route. Jeder Request zog eine 4MB-JPEG durch Vercels Netzwerk statt einer 200KB-WebP von einer CDN-Edge. Multiplizier das mit 50.000 Page Views und rechne selbst. is genuinely good at what it does. It resizes, converts to WebP, and caches. But I've seen projects where developers were pulling images straight from an <img> tag pointing at full-resolution files in an S3 bucket, proxied through a Vercel API route. Every request was pulling a 4MB JPEG through Vercel's network instead of a 200KB WebP from a CDN edge. Multiply that by 50,000 page views and do the maths.
Verwende next/image immer mit einer korrekten remotePatterns-Konfiguration. Wenn die Bildquelle extern ist, stelle sicher, dass sie den CDN-Cache nutzt und nicht über deine serverlosen Funktionen läuft.next/image with a proper remotePatterns config. If the image source is external, make sure it's hitting the CDN cache and not making a round trip through your serverless functions.
2. API-Routen, die große Datenmengen zurückgeben
2021 baute ich einen E-Commerce-Produktkatalog für einen britischen Einzelhändler. Ihre API-Route holte eine Produktliste aus ihrer Datenbank und gab das gesamte Produktobjekt zurück, inklusive Feldern, die das Frontend nie nutzte. Beschreibungen, interne SKU-Notizen, Variantendaten – alles. Jede Antwort war etwa 80 KB groß statt der benötigten 12 KB.entire product object, including fields the front end never used. Description, internal SKU notes, variant metadata, the lot. Each response was around 80KB instead of the 12KB it needed to be.
Kürze deine API-Antworten. Gib nur die Felder zurück, die der Client tatsächlich verbraucht. Wenn du etwas wie Prisma nutzt, verwende select, um zu begrenzen, was du abrufst. Wenn du eine API von Drittanbietern verwendest, transformiere und reduziere die Payload, bevor du sie weitergibst.select to limit what you pull. If you're using a third-party API, transform and slim the payload before sending it downstream.
3. ISR mit kurzen Revalidierungsfenstern auf stark frequentierten Routen
Incremental Static Regeneration ist in der Theorie brilliant. In der Praxis: Wenn du revalidate: 30 auf einer Seite setzt, die 10.000 Treffer pro Minute bekommt, cachst du immer noch korrekt. Aber wenn du revalidate: 1 setzt, weil du Echtzeitaktualisierungen wolltest und vergessen hast, es zu ändern... machst du im Grunde SSR mit zusätzlichen Schritten und bezahlst für den Egress bei jedem Cache-Miss.revalidate: 30 on a page that gets 10,000 hits per minute, you're still caching correctly. But if you set it to revalidate: 1 because you wanted near-real-time updates and forgot to change it... you're basically doing SSR with extra steps and paying for the egress on every near-miss cache response.
Sei gezielt bei deinen Revalidierungsfenstern. Die meisten Inhalte müssen nicht jede Sekunde revalidiert werden.
4. Serverlose Funktionen ohne Caching-Header
Dieser Punkt ist subtil. Wenn deine serverlose Funktion keine Cache-Control-Header enthält (oder Vercels s-maxage / stale-while-revalidate-Kombination), wird die Antwort nicht am Edge gecacht. Jede Anfrage trifft die Funktion und durchläuft die vollständige Reisenfolge. Du verlierst den CDN-Vorteil komplett und bezahlst Egress bei jeder einzelnen Antwort.Cache-Control header (or Vercel's s-maxage / stale-while-revalidate combo), the response is not cached at the edge. Every request hits the function and travels the full round trip. You lose the CDN benefit entirely and pay egress on every single response.
`` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 `` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 ``
Allein dieser Header hat Kunden echtes Geld gespart. Ohne Spaß. Vercels eigene Caching-Dokumentation erklärt das Header-Verhalten ausführlich. Lies sie einmal richtig durch.Vercel's own caching docs explain the header behaviour in detail. Read them once properly.
---
Billing Alerts einrichten (bevor du sie brauchst)
Das sollte Schritt eins sein, bevor ein Production Deploy. Nicht Schritt sieben.
- Gehe zu deinen Vercel Team Settings.
- Unter Billing findest du Spend Management.Billing , find Spend Management.
- Setze ein Spend Limit (harte Obergrenze, bei der Vercel Anfragen nicht mehr bearbeitet) oder einen Notification Threshold (sanfte Benachrichtigung, eine E-Mail wenn du eine bestimmte Summe erreichst).spend limit (hard cap, where Vercel stops serving requests after the limit) or a notification threshold (soft alert, emails you when you hit a number).
- Ich würde empfehlen, eine Benachrichtigung bei 50% dessen zu setzen, was du als schmerzhaft erachten würdest, und ein hartes Limit bei etwa 120% deiner erwarteten monatlichen Rechnung.
Das Hard Cap ist ein zweischneidiges Schwert. Wenn du es erreichst, geht deine Website down. Also überleg dir das gut. Für eine Marketing-Website? Okay, begrenzen sie hart. Für eine SaaS mit zahlenden Nutzern? Setze großzügige Benachrichtigungen und beobachte das Dashboard stattdessen.
---
Die schwere Last anderswo unterbringen
Vercel ist kein CDN für statische Assets. Ich meine, es hat ein CDN, aber du zahlst pro Gigabyte dafür. Bei großen Mengen statischer Assets solltest du sie woanders lagern, wo es günstiger ist.
Ich leite große Mediendateien seit etwa achtzehn Monaten über Cloudflare R2. R2 hat keine Egress-Gebühren. Du zahlst für Speicher und Operationen, nicht für die Daten, die hinausgehen. Für bildlastige Seiten ist das eine ernsthafte Ersparnis. Ein Client von mir betreibt eine Fotografie-Portfolio-Plattform und zahlte etwa 180 Dollar pro Monat für Vercel Egress. Wir haben alle hochauflösenden Bilder und Gallery-Assets zu R2 verschoben, die Thumbnails über next/image laufen lassen, und die Vercel-Rechnung ist auf unter 40 Dollar gefallen.Cloudflare R2 for about eighteen months now. R2 has zero egress fees. You pay for storage and operations, not for the data going out. For image-heavy sites this is a serious saving. A client of mine runs a photography portfolio platform and was paying around $180/month in Vercel egress. We moved all the full-res images and gallery assets to R2, kept the thumbnails going through next/image, and the Vercel bill dropped to under $40.
Alternativen, die es zu kennen lohnt:
- Cloudflare Pages für statische Deployments, wo du Vercels Edge-Features nicht brauchst. Großzügiger kostenloser Plan, keine Egress-Gebühren. for static deployments where you don't need Vercel's edge features. Generous free tier, no egress fees.
- AWS CloudFront vor S3, wenn du bereits im AWS-Ökosystem bist. Die Transferkosten sind bei größerem Volumen niedriger als Vercels Überschussgebühren. in front of S3 if you're already in the AWS ecosystem. Transfer costs are lower than Vercel's overage rates at scale.
- BunnyCDN ist günstig und schnell für reine Asset-Lieferung. Ich habe es bei einigen High-Traffic-Migrationen von WordPress zu Next.js eingesetzt, wo das Asset-Volumen groß war. is cheap and fast for pure asset delivery. I've used it on a few high-traffic WordPress-to-Next.js migrations where the asset volume was large.
Der Punkt ist: Vercel ist der richtige Ort, um deine Next.js-Anwendungslogik auszuführen. Es ist nicht immer der richtige Ort, um deine Gigabytes an Mediendaten zu servieren.
---
Nutzung in Echtzeit überwachen
Überprüfe dein Dashboard nicht erst am Ende des Monats. So kam mein Kunde dazu, mich an einem Montag anzurufen.
Ein paar Dinge, die ich tatsächlich nutze:
- Vercel Analytics gibt dir seitenbezogene Daten und ist nützlich, um zu erkennen, welche Routes den meisten Traffic generieren (und damit den meisten Egress). gives you page-level data and is useful for spotting which routes are generating the most traffic (and therefore the most egress).
- Axiom integriert sich sauber mit Vercels Log Drains und lässt dich die Request-Größe über die Zeit abfragen. Ich habe damit Ende 2022 angefangen und es war bei größeren Projekten nützlich, um Traffic-Spitzen mit Egress-Sprüngen zu korrelieren. integrates cleanly with Vercel's log drains and lets you query request size over time. I started using it in late 2022 and it's been useful on bigger projects for correlating traffic spikes with egress jumps.
- Richte einen einfachen Cron ein (Vercel hat jetzt natives Cron-Support), der ihre API aufruft und einen Slack-Channel anschreibt, wenn die Bandbreite einen Schwellwert überschreitet. Ich habe eine schlanke Version davon für die Infrastruktur von Seahawk gebaut. Dauert zwei Stunden, spart viel Angst.
Die Vercel REST API stellt Deployment- und Nutzungsdaten bereit. Es ist nicht die eleganteste API der Welt, aber sie tut, was du für einfache Alerting brauchst.Vercel REST API exposes deployment and usage data. It's not the most elegant API in the world but it does what you need for basic alerting.
---
Die Architektur-Entscheidung, über die niemand spricht
Hier ist etwas, das ich nicht oft diskutiert sehe: manchmal ist Vercel nicht die richtige Default-Wahl.
Wenn dein Projekt eine statische Marketing-Site ohne echte dynamische Funktionalität ist, brauchst du Vercel nicht. Cloudflare Pages oder Netlify's kostenloses Tier werden den Job machen ohne Egress-Bedenken. Du "verschwendest" Vercel nicht, du hast einfach nicht das richtige Werkzeug für die Workload.
Umgekehrt: Wenn du eine richtige Next.js-App mit Edge Middleware, Server Components und API Routes baust, die echte Arbeit verrichten, dann lohnt sich die Zahlung für Vercel. Die Developer Experience ist wirklich ausgezeichnet und das Edge-Netzwerk ist schnell. Nur musst du es von Anfang an richtig architektieren.
Der Fehler, den ich früh in meiner Karriere gemacht habe (um 2016, bevor Vercel überhaupt existierte, damals als ich noch Deployment auf Heroku und Netlify herausfand), war, die Deployment-Plattform als kostenloses Anhängsel zu behandeln. Die Plattformwahl prägt dein Kostenprofil genauso wie deine Datenbankwahl. Nimm es ernst.
---
FAQ
Fallen auf dem Hobby-Plan Egress-Gebühren an, wenn ich über 100GB gehe?
Nein. Beim Hobby-Plan berechnet Vercel keine Überschreitungsgebühren; sie drosseln oder unterbrechen das Deployment, sobald du das Limit erreichst. Beides ist nicht ideal, aber du bekommst keine überraschende Rechnung. Die überraschenden Rechnungen entstehen bei Pro und Enterprise, wo die Nutzung über die enthaltene Menge hinaus gemessen wird.
Wird Vercels Bildoptimierung bei der Egress mitgezählt?
Ja. Optimierte Bilder, die über next/image bereitgestellt werden, zählen immer noch zur Egress. Die Ersparnis liegt in der Dateigröße: Du stellst ein 180KB WebP bereit statt eines 3MB JPEG, also ist die Egress pro Bild viel niedriger. Die Optimierung selbst ist das, was die Kosten senkt, nicht irgendeine spezielle Ausnahmeregelung.next/image still count as egress. The saving is in file size: you're serving a 180KB WebP instead of a 3MB JPEG, so the egress per image is much lower. The optimisation itself is what reduces the cost, not some special exemption.
Kann ich ein Custom CDN vor Vercel nutzen, um die Egress zu reduzieren?
Du kannst Cloudflares Proxy vor dein Vercel-Deployment setzen. Cloudflare cached Responses an seinem Edge, was bedeutet, dass Anfragen, die Cloudflares Cache treffen, gar nicht erst Vercel erreichen. Das kann sowohl die Egress als auch die Function Invocations erheblich reduzieren. Es gibt einige Vorbehalte bei Preview Deployments und Header-Verarbeitung, aber für Production ist das ein häufiger und legitimer Ansatz. Cloudflares Dokumentation zum Proxying behandelt das Setup.Cloudflare's documentation on proxying covers the setup.
Was ist die größte einzelne Ursache für unerwartete Vercel-Rechnungen?
Nach meiner Erfahrung: Bildbearbeitung. Entweder werden Bilder in voller Auflösung ohne Optimierung bereitgestellt, oder Bildoptimierungsrouten werden bei jeder Anfrage ohne angemessenes Caching aufgerufen. Kümmere dich zuerst um deine Bild-Pipeline, alles andere kommt danach.
Benachrichtigt dich Vercel automatisch, wenn die Nutzung in die Höhe schnellt?
Nicht standardmäßig. Du musst es konfigurieren. Es gibt keine sofort einsatzbereite Warnung, die sagt „du hast 80% deiner Bandbreite verbraucht." Das ist die Lücke. Stelle deine Ausgabenschwellen am gleichen Tag ein, an dem du deinen Produktionsdeployment einrichtest. Nicht später.
---
Vercel ist eine großartige Plattform. Ich nutze sie, Seahawk nutzt sie, und ich werde sie weiterhin für die richtigen Projekte empfehlen. Aber es ist ein abgerechneter Service, der auf echter Infrastruktur läuft, und die Preise spiegeln das wider. Die Entwickler, die durch überraschende Rechnungen zu Schaden kommen, sind fast immer diejenigen, die es wie ein kostenloses CDN behandelt haben und sich nie die Abrechnungseinstellungen angesehen haben. Fünf Minuten Konfiguration beim Deployment sparen dir einen sehr unangenehmen Anruf am Montagmorgen.