Für App Hosting ist ein Projekt mit dem Blaze-Preismodell (Pay as you go) erforderlich. Bei diesem Preismodell gelten für Ihr Projekt die folgenden kostenlosen Limits für die 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 im Cache gespeichertes GiB 0,20 $ pro nicht im Cache gespeichertes 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 |
| Arbeitsspeicher | 360.000 GiB-Sekunden | 0,00000250 $ pro GiB-Sekunde | |
| Anfragen | 2 Mio. Anfragen | 0,40 $/Million Anfragen | |
| Cloud Build | Build-Minuten | 2.500 Build-Minuten | 0,006 $ pro Build-Minute |
| Cloud Logging | Logging-Speicher | 50 GiB/Projekt/Monat | 0,50 $/GiB |
| Aufbewahrung von Logs | 30 Tage lang kostenlos | 0,01 $ pro GiB und 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,020 $ 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 Ziel für die Datenübertragung in Google Cloud (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 verwendet, wenn Sie mit der Firebase-Befehlszeile aus einer lokalen Quelle bereitstellen oder ein komprimiertes Archiv in der Firebase-Console hochladen.
2Cloud Storage „Immer kostenlos“-Kontingente 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 in Rechnung gestellt, die über die Limits hinausgeht.
Kosten berechnen
Für Ihr Projekt „Firebase App Hosting“ fallen Kosten an, sobald Sie die kostenlosen Kontingente des Blaze-Preismodells (Pay as you go) überschreiten. Die folgenden Firebase App Hosting-Positionen werden Ihnen in Rechnung gestellt:
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 Cloud CDN. Dies geschieht, wenn der angeforderte Inhalt noch nicht im Cloud CDN-Cache gespeichert ist (d. h. er ist nicht im Cache gespeichert). Folglich 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 Übertragung von Daten vom Ursprung zum CDN trägt zu den Gesamtkosten bei.
- Daten an den Endnutzer übertragen: Sobald der Inhalt verfügbar ist (entweder direkt vom Ursprung oder vom CDN nach der ersten Cache-Befüllung), muss er an das Gerät des Endnutzers am angeforderten Ziel übertragen werden. Diese Datenübertragung trägt ebenfalls zu den Kosten bei.
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.
Informationen zur Optimierung der Leistung mit Cloud CDN finden Sie unter Anwendungsinhalte im Cache speichern.
Außerdem wird Ihnen 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
- Cloud Storage
Die genauen Preispunkte für diese Positionen finden Sie auf unserer Preisseite.
Beispiele für die Abrechnung
Die Kosten für die Ausführung einer dynamischen Webanwendung in 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 Ihre Anwendung das monatliche kostenlose Kontingent erreicht hat, fallen für jeden Besuch Ihrer Website Kosten an. Diese Kosten sind nicht fest, sondern hängen von Faktoren wie der Anzahl der Hintergrundanfragen, die durch jeden Besuch ausgelöst werden, der Rechenleistung, die zum Erstellen der Antwort erforderlich ist, und der Antwortgröße ab. Einige Anfragen sind einfach teurer als andere. Beispielsweise ist die Bereitstellung einer Seite mit vielen Bildern oder komplexen Daten wahrscheinlich teurer als die einer einfachen HTML-Datei. Ähnlich verhält es sich mit der dynamischen Generierung einer Seite auf dem Server. Diese ist in der Regel teurer als die Bereitstellung einer im Cache gespeicherten Version über ein CDN.
Um die Kosten Ihrer Anwendung effektiv zu schätzen, sollten Sie einige wichtige Messwerte berücksichtigen:
- Anfragen pro Besuch: Wie viele einzelne Anfragen löst ein typischer Nutzerbesuch aus? (Denken Sie daran, dass ein „Seitenaufbau“ 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 im Durchschnitt, bis Ihre Anwendung auf eine Anfrage antwortet?
Sie können diese Werte schätzen, indem Sie die Anfrageprotokolle Ihrer Anwendung in der Google Cloud-Konsole prüfen. Bei unseren Beispielkostenberechnungen wird Folgendes angenommen:
| Traffic-Eigenschaften | |
|---|---|
| ~Abgerechnete Anfragen pro 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 |
| Nebenläufigkeit (Anfragen) | 80 |
| minInstances | 0 |
| maxInstances | 100 |
1 Dies sind die von App Hosting bereitgestellten Standardwerte. Sie können die Cloud Run-Konfiguration für jeden Roll-out prüfen, indem Sie die Cloud Run-Überarbeitungsdetails aufrufen. Bewegen Sie den Mauszeiger auf dem Tab Roll-outs in der Firebase-Konsole auf einen Roll-out, wählen Sie das Dreipunkt-Menü und dann „Cloud Run-Überarbeitung ansehen“ aus.
Weitere Annahmen
| Projektnutzung | |
|---|---|
| Bereitstellungsmethode | GitHub |
| Builds pro Monat | 20 |
| Minuten pro Build | 8 |
| Logaufbewahrung | < 30 Tage |
| Secret-Versionen | < 6 Versionen |
| Artifact Registry-Image-Größe (MB) | 380 |
Beispielrechnung
Mit diesen Annahmen können wir die folgenden Kosten für dieses Beispielszenario hochrechnen. Bei 10.000 Besuchen fallen praktisch keine Kosten an. Erst ab 1.000.000 Besuchen entstehen nennenswerte Kosten. Ein Besuch ist eine Anfrage an Ihre Anwendung, die von einem Nutzer initiiert wird.
| SKU | Preis | Einheit | Kostenlose Stufe | Nutzung von 10.000 Besuchen | Kosten für 10.000 Besuche | Nutzung von 1 Mio. Besuchen | Kosten für 1 Mio. Besuche |
|---|---|---|---|---|---|---|---|
| Cloud Run – CPU | 0,00 $ |
vCPU-Sekunde | 180.000,00 |
1250 |
0,00 $ |
2 Millionen Euro |
0,00 $ |
| Cloud Run – Memory | 0,00 $ |
GiB-Sekunde | 360.000,00 |
625 |
0,00 $ |
62500 |
0,00 $ |
| Cloud Run – Anfragen | 0,40 $ |
Mio. SSR-Anfragen | 2,00 |
0,05 |
0,00 $ |
5 |
1,20 $ |
| Cloud Build – Build-Minuten | 0,006 $ |
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 – Nicht im Cache gespeicherte ausgehende Bandbreite | 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 $ |
|
| Secrets 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 – Rotationsbenachrichtigungen | 0,05 $ |
Drehungen | 3,00 |
0,00 |
0,00 $ |
0,00 |
0,00 $ |
| Cloud Logging – Logging-Speicher | 0,50 $ |
GiB | 50,00 |
0,50 |
0,00 $ |
50,00 |
0,00 $ |
| Cloud Logging – Logging-Aufbewahrung | 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 * abgerechnete Anfragen pro Besuch / Anzahl der gleichzeitigen Anfragen |
| Cloud Run – Memory | GiB-Sekunde | GiB-Sekunden = GiB pro Instanz * durchschnittliche Antwortlatenz pro Anfrage * Anzahl der Besuche * abgerechnete Anfragen pro Besuch / Anzahl der gleichzeitigen Anfragen |
| Cloud Run – Anfragen | Mio. SSR-Anfragen | Mio. SSR-Anfragen = (# Besuche * abgerechnete Anfragen pro Besuch / 1 Mio.) * (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 * Image-Größe |
| App Hosting – nicht im Cache gespeicherte Bandbreite | GiB | Nicht im Cache gespeicherte GiB= (1 – Cache-Trefferquote) × (Anzahl der Besuche × abgerechnete Anfragen pro Besuch × ausgehende Bandbreite pro Anfrage) |
| App Hosting – im Cache gespeicherte Bandbreite | GiB | Im Cache gespeicherte GiB = Cache-Trefferrate * (Anzahl der Besuche * abgerechnete Anfragen pro Besuch * ausgehende Bandbreite pro Anfrage) |
1 App Hosting bereinigt automatisch ältere Images in Artifact Registry und behält Images aus erfolgreichen Builds der letzten 14 Tage bei. Dabei werden immer mindestens die fünf letzten erfolgreichen Builds sowie der Live-Build beibehalten. Weitere Informationen finden Sie unter Build-Bereinigungsrichtlinie.