Für App Hosting ist ein Projekt mit aktiviertem Firebase-Tarif „Blaze“ erforderlich. Für diesen Tarif gelten die folgenden kostenlosen Limits für Google Cloud-Produkte, die von App Hosting aufgerufen werden:
| Produkt | Funktion | Keine Kosten | In Rechnung gestellt (für die Nutzung über die kostenlosen Limits hinaus) |
|---|---|---|---|
| App Hosting | Ausgehende Bandbreite | 10 GiB / Monat | 0,15 $ pro GiB im Cache 0,20 $ pro nicht im Cache befindlichem GiB |
| Artifact Registry | Speicher | 0,5 GB / Monat | 0,10 $ pro GB und Monat für mehr als 0,5 GB |
| Ausgehender Traffic | Keine Kosten | Eine vollständige Liste der Preise für ausgehenden Traffic finden Sie unter „Artifact Registry – Preise“. | |
| Cloud Run | CPU | 180.000 vCPU-Sekunden | 0,00002400 $ pro vCPU-Sekunde |
| Speicher | 360.000 GiB-Sekunden | 0,00000250 $ pro GiB-Sekunde | |
| Anfragen | 2 Mio. Anfragen | 0,40 $ pro Million Anfragen | |
| Cloud Build | Build-Minuten | 2.500 Build-Minuten | 0,006 $ / Build-Minute |
| Cloud Logging | Logging-Speicher | 50 GiB / Projekt / Monat | 0,50 $/GiB |
| Aufbewahrungsdauer von Protokollen | 30 Tage lang kostenlos | 0,01 $ / GiB / Monat für Logs, die länger als 30 Tage aufbewahrt werden | |
| Secret Manager | Aktive Secret-Versionen | 6 Versionen pro Monat | 0,06 $ pro Version und Standort |
| Zugriffsvorgänge | 10.000 Vorgänge pro Monat | 0,03 $ pro 10.000 Vorgänge | |
| Benachrichtigungen zur Rotation | 3 Rotationen pro Monat | 0,05 $ pro Rotation | |
| Cloud Storage1 | Standard Storage2 | 5 GB/Monat | 0,02 $ pro GB und Monat |
| Vorgänge der Klasse A2 | 5.000 | 0,0050 $ pro 1.000 Vorgänge | |
| Vorgänge der Klasse B2 | 50.000 | 0,0004 $ pro 1.000 Vorgänge | |
| Datenübertragung2 | 100 GB von Nordamerika an jedes Google Cloud-Ziel für die Datenübertragung (außer Australien und China) | 0,02 $ pro GB für Nordamerika 0,02 $ pro GB für Europa 0,08 $ pro GB für Asien |
1Cloud Storage wird nur bei der Bereitstellung aus einer lokalen Quelle mit der Firebase-Befehlszeile verwendet.
2Cloud Storage Die Kontingente „Immer kostenlos“ gelten nur für App Hosting-Backends in US-CENTRAL1.
Die kostenlose Nutzung wird projektübergreifend nach Rechnungskonto zusammengefasst und jeden Monat zurückgesetzt. Ihnen wird nur die Nutzung über die Limits hinaus in Rechnung gestellt.
Kosten berechnen
Ab dem 14. Juni 2025 fallen für Ihr Firebase App Hosting-Projekt Kosten an, sobald Sie die im Blaze-Tarif (Pay as you go) festgelegten Limits überschreiten. Ihnen werden die folgenden Firebase App Hosting-Positionen in Rechnung gestellt:
Die nicht im Cache gespeicherte ausgehende Bandbreite bezieht sich auf die Daten, die direkt von den Ursprungsservern des Firebase App Hosting-Dienstes übertragen werden, um Nutzeranfragen zu erfüllen. Ursprungsserver befinden sich zwischen dem Cloud Run-Dienst eines App Hosting-Backends und dem Cloud CDN. Das passiert, wenn der angeforderte Inhalt noch nicht im Cloud CDN-Cache gespeichert ist. Daher muss der Ursprungsserver die Daten abrufen und an den Nutzer senden.
Für diesen Vorgang fallen aus zwei Hauptgründen Kosten an:
- Cloud CDN-Caches füllen:Wenn ein Nutzer nicht im Cache gespeicherte Inhalte anfordert, wird ein Prozess ausgelöst, um diese Daten vom Ursprungsserver abzurufen und eine Kopie für zukünftige Anfragen im Cloud CDN-Cache zu speichern. Diese anfängliche Datenübertragung vom Ursprung zum CDN trägt zu den Gesamtkosten bei.
- Daten an den Endnutzer übertragen:Sobald die Inhalte verfügbar sind (entweder direkt vom Ursprung oder vom CDN nach der Erstbefüllung des Caches), müssen sie an das Gerät des Endnutzers am angeforderten Ziel übertragen werden. Diese Datenübertragung trägt ebenfalls zu den Kosten bei.
Die ausgehende Bandbreite im Cache bezieht sich auf die Daten, die in Gibibyte von den Caches von Cloud CDN an das Gerät des Endnutzers am angeforderten Ziel übertragen werden.
Unter App-Inhalte im Cache speichern finden Sie eine Anleitung zur Leistungsoptimierung mit Cloud CDN.
Außerdem werden Ihnen die Kosten für die Nutzung der zugrunde liegenden Google Cloud-Produkte in Rechnung gestellt, die Ihr Backend verwendet:
- Cloud Run
- Cloud Build
- Artifact Registry
- Secret Manager
- Cloud Logging
Die genauen Preise für diese Werbebuchungen finden Sie auf unserer Preisseite.
Beispiele für die Abrechnung
Die Kosten für die Ausführung einer dynamischen Webanwendung auf App Hosting können je nach Faktoren wie Traffic, Laufzeiteinstellungen und Antwortgröße stark variieren. Die Kosten in unserem Beispiel basieren auf bestimmten Annahmen zu diesen Faktoren.
Traffic und Antwortgröße
Sobald das kostenlose Kontingent Ihrer App aufgebraucht ist, fallen für jeden Besuch Ihrer Website Kosten an. Diese Kosten sind nicht festgelegt, sondern hängen von Faktoren wie der Anzahl der Hintergrundanfragen ab, die durch jeden Besuch ausgelöst werden, der Rechenleistung, die zum Erstellen der Antwort erforderlich ist, und der Antwortgröße. Einige Anfragen sind einfach teurer als andere. So ist es beispielsweise wahrscheinlicher, dass das Bereitstellen einer Seite mit vielen Bildern oder komplexen Daten mehr kostet als das einer einfachen HTML-Datei. Ebenso ist es in der Regel teurer, eine Seite dynamisch auf dem Server zu generieren, als eine gecachte Version aus einem CDN bereitzustellen.
Um die Kosten Ihrer App effektiv zu schätzen, sollten Sie einige wichtige Messwerte berücksichtigen:
- Anfragen pro Besuch: Wie viele einzelne Anfragen werden bei einem typischen Nutzerbesuch ausgelöst? Denken Sie daran, dass ein „Seitenladevorgang“ in der Regel viele zugrunde liegende Anfragen für Assets wie Bilder, CSS und JavaScript umfasst.
- Durchschnittliche Antwortgröße: Wie groß sind die Daten, die für jede Anfrage zurückgesendet werden?
- Durchschnittliche Antwortlatenz: Wie lange dauert es durchschnittlich, bis Ihre App auf eine Anfrage reagiert?
Sie können diese Werte schätzen, indem Sie die Anfrageprotokolle Ihrer App in der Google Cloud Console prüfen. Bei den Beispielkostenberechnungen gehen wir von Folgendem aus:
| Zugriffsmerkmale | |
|---|---|
| ~Abgerechnete Anfragen pro einzelnem Besuch | 10 |
| Durchschnittliche Antwortgröße (KiB) | 400 |
| Durchschnittliche Antwortlatenz (ms) | 1000 |
| Cache-Trefferquote | 50 % |
Laufzeiteinstellungen
| Cloud Run Einstellungen1 | |
|---|---|
| CPU-Limit (vCPU) | 1 |
| Arbeitsspeicherlimit (MiB) | 512 |
| Gleichzeitigkeit (Anfragen) | 80 |
| minInstances | 0 |
| maxInstances | 100 |
1 Dies sind die Standardwerte von App Hosting. Sie können die Cloud Run-Konfiguration für jedes Roll-out prüfen, indem Sie sich die Details der Version Cloud Run ansehen. Bewegen Sie den Mauszeiger in der Firebase Console auf dem Tab Roll-outs auf ein Roll-out, klicken Sie auf das Dreipunkt-Menü und wählen Sie „Cloud Run-Version ansehen“ aus.
Weitere Annahmen
| Projektnutzung | |
|---|---|
| Bereitstellungsmethode | GitHub |
| Builds pro Monat | 20 |
| Minuten pro Build | 8 |
| Protokollaufbewahrung | < 30 Tage |
| Secret-Versionen | < 6 Versionen |
| Größe des Artifact Registry-Images (MB) | 380 |
Beispielrechnung
Anhand dieser Annahmen können wir die folgenden Kosten für dieses Beispielszenario extrapolieren. Bei 10.000 Besuchen fallen praktisch keine Kosten an. Erst ab einer Million Besuche entstehen nennenswerte Kosten. Ein Besuch ist eine von einem Nutzer initiierte Anfrage an Ihre App.
| SKU | Preis | Einheit | Kostenlose Stufe | Nutzung bei 10.000 Besuchen | Kosten für 10.000 Besuche | Nutzung bei 1 Million Besuchen | Kosten für 1 Million Besuche |
|---|---|---|---|---|---|---|---|
| Cloud Run – CPU | 0,00 $ |
vCPU-Sekunde | 180.000,00 |
1250 |
0,00 $ |
2 Millionen Euro |
0,00 $ |
| Cloud Run – Arbeitsspeicher | 0,00 $ |
GiB/Sekunde | 360.000,00 |
625 |
0,00 $ |
62500 |
0,00 $ |
| Cloud Run – Anfragen | 0,40 $ |
M-SSR-Anfragen | 2,00 |
0,05 |
0,00 $ |
5 |
1,20 $ |
| Cloud Build – Build-Minuten | 0,01 $ |
build-minute | 2.500,00 |
160 |
0,00 $ |
160 |
0,00 $ |
| Artifact Registry – Speicher | 0,10 $ |
GiB (gespeichert) | 0,50 |
0,6 |
0,01 $ |
0,6 |
0,01 $ |
| App Hosting – Ausgehende Bandbreite ohne Cache | 0,20 $ |
GiB | 10 |
2 |
0,00 $ |
200 |
39,00 $ |
| App Hosting – Ausgehende Bandbreite im Cache | 0,15 $ |
GiB | 2 |
0,00 $ |
200 |
29,25 $ |
|
| Secret Manager – Aktive Secret-Versionen | 0,06 $ |
Versionen | 6,00 |
6,00 |
0,00 $ |
6,00 |
0,00 $ |
| Secret Manager – Zugriffsvorgänge | 0,03 $ |
10.000 Vorgänge | 1.0 |
0,10 |
0,00 $ |
5,00 |
0,12 $ |
| Secret Manager – Benachrichtigungen zur Rotation | 0,05 $ |
Rotationen | 3,00 |
0,00 |
0,00 $ |
0,00 |
0,00 $ |
| Cloud Logging – Speicher für Protokolle | 0,50 $ |
GiB | 50,00 |
0,50 |
0,00 $ |
50,00 |
0,00 $ |
| Cloud Logging – Aufbewahrungsdauer von Protokollen | 0,01 $ |
GiB / Monat | 30 Tage | 0,00 $ |
0,00 $ |
||
| Summe | 0,01 $ |
69,58$ |
Berechnungen
| SKU | Einheit | Nutzung berechnen |
|---|---|---|
| Cloud Run – CPU | vCPU-Sekunde | vCPU-Sekunden = vCPU pro Instanz * durchschnittliche Antwortlatenz pro Anfrage * Anzahl der Besuche * in Rechnung gestellte Anfragen pro Besuch ÷ Anzahl der gleichzeitigen Anfragen |
| Cloud Run – Arbeitsspeicher | GiB/Sekunde | GiB-Sekunden = GiB pro Instanz * durchschnittliche Antwortlatenz pro Anfrage * Anzahl der Besuche * in Rechnung gestellte Anfragen pro Besuch ÷ Anzahl der gleichzeitigen Anfragen |
| Cloud Run – Anfragen | M-SSR-Anfragen | Mio. SSR-Anfragen = (Anzahl der Besuche * in Rechnung gestellte Anfragen pro Besuch ÷ 1 Million) * (1 – Cache-Trefferquote) |
| Cloud Build – Build-Minuten | build-minute | Build-Minuten = Anzahl der Builds × Minuten pro Build |
| Artifact Registry – Speicher 1 | GiB (gespeichert) | GiB (gespeichert) = 2 × Bildgröße |
| App Hosting – nicht im Cache gespeicherte Bandbreite | GiB | Nicht im Cache gespeicherte GiB= (1 – Cache-Trefferrate) × (Anzahl der Besuche × in Rechnung gestellte Anfragen pro Besuch × ausgehende Bandbreite pro Anfrage) |
| App Hosting – im Cache gespeicherte Bandbreite | GiB | Im Cache gespeicherte GiB = Cache-Trefferrate × (Anzahl der Besuche × in Rechnung gestellte Anfragen pro Besuch × ausgehende Bandbreite pro Anfrage) |
1 Normalerweise hat Ihre App nur ein Image in der Artifact Registry, da nicht verwendete Versionen automatisch vom App-Hosting bereinigt werden. Möglicherweise werden nur bei einem neuen Roll-out kurz zwei Bilder angezeigt.