כדי להשתמש ב-App Hosting צריך פרויקט שבו מופעלת תוכנית התמחור Firebase Blaze. בתוכנית הזו יש את המגבלות הבאות ללא עלות על מוצרי Google Cloud שמופעל על ידי App Hosting:
| מוצר | תכונה | ללא עלות | מחויב (על שימוש מעבר למגבלות ללא עלות) |
|---|---|---|---|
| App Hosting | רוחב הפס היוצא | 10GB לחודש | 0.15$ לכל GiB שנשמר במטמון 0.20$ לכל GiB שלא מאוחסן במטמון |
| Artifact Registry | אחסון | 0.5GB לחודש | 0.10$ ל-GB לחודש מעל 0.5GB |
| תעבורת נתונים יוצאת (egress) | ללא עלות | רשימה מלאה של מחירי תעבורת נתונים יוצאת מופיעה במאמר בנושא תמחור של Artifact Registry | |
| Cloud Run | CPU | 180,000 שניות vCPU | 0.00002400$ לשנייה של vCPU |
| זיכרון | 360,000 שניות ג'יביבייט | 0.00000250$ לשנייה של ג'יגה-בייט | |
| Requests | 2 מיליון בקשות | 0.40$ למיליון בקשות | |
| Cloud Build | Build-minutes | 2,500 דקות build | 0.006$ לדקה build |
| Cloud Logging | אחסון של רישום ביומן | 50GB לפרויקט לחודש | 0.50$/GiB |
| שמירת נתונים ביומן | ללא עלות למשך 30 ימים | 0.01$ ל-GiB לחודש על יומנים שנשמרים למשך יותר מ-30 יום | |
| Secret Manager | גרסאות סודיות פעילות | 6 גרסאות לחודש | 0.06$ לכל גרסה לכל מיקום |
| פעולות גישה | 10,000 פעולות לחודש | 0.03$ לכל 10,000 פעולות | |
| התראות על רוטציה | 3 רוטציות בחודש | 0.05$ לכל סיבוב | |
| Cloud Storage1 | אחסון רגיל2 | 5GB-חודשים | 0.020$ לכל GB לחודש |
| תפעול ברמה A2 | 5,000 | 0.0050$ לכל 1,000 פעולות | |
| פעולות Class B2 | 50,000 | 0.0004$ לכל 1,000 פעולות | |
| העברת נתונים2 | 100GB מצפון אמריקה לכל יעד של העברת נתונים ב-Google Cloud (לא כולל אוסטרליה וסין) | 0.02$ ל-GB בצפון אמריקה 0.02$ לכל GB באירופה 0.08$ לכל GB באסיה |
הערך 1Cloud Storage משמש רק כשפורסים ממקור מקומי באמצעות ה-CLI של Firebase.
2Cloud Storage המכסות של Always Free חלות על App Hostingקצוות עורפיים ב-US-CENTRAL1 בלבד.
השימוש ללא עלות מצטבר בין הפרויקטים לפי חשבון לחיוב, ומתאפסים מדי חודש. אתם מחויבים רק על שימוש מעבר למגבלות.
חישוב העלויות
החל מ-14 ביוני 2025, תתחילו לצבור עלויות בפרויקט Firebase App Hosting אחרי שתחרגו מההנחות של תוכנית התמחור 'תשלום לפי שימוש' ב-Blaze. נחייב אותך על Firebase App Hosting הפריטים הבאים:
המדד Uncached Outgoing Bandwidth מתייחס לנתונים שמועברים ישירות משרתי המקור של שירות Firebase App Hosting כדי למלא בקשות של משתמשים. שרתי המקור נמצאים בין שירות Cloud Run של הקצה העורפי של App Hosting לבין Cloud CDN. המצב הזה מתרחש כשהתוכן המבוקש עדיין לא מאוחסן במטמון של Cloud CDN (כלומר, הוא לא נמצא במטמון). לכן, שרת המקור צריך לאחזר את הנתונים ולשלוח אותם למשתמש.
יש עלויות בתהליך הזה משתי סיבות עיקריות:
- אכלוס המטמון של Cloud CDN: כשמשתמש מבקש תוכן שלא נשמר במטמון, הוא מפעיל תהליך לאחזור הנתונים האלה משרת המקור ולאחסון עותק במטמון של Cloud CDN לצורך בקשות עתידיות. העברת הנתונים הראשונית מהמקור ל-CDN תורמת לעלות הכוללת.
- העברת נתונים למשתמש הקצה: אחרי שהתוכן זמין (באופן ישיר מהמקור או מה-CDN אחרי מילוי המטמון הראשוני), צריך להעביר אותו למכשיר של משתמש הקצה ביעד המבוקש. העברת הנתונים הזו גם תורמת לעלות.
המדד רוחב פס יוצא שנשמר במטמון מתייחס לנתונים שהועברו ב-GiB מהמטמון של Cloud CDN למכשיר של משתמש הקצה ביעד המבוקש.
במאמר שמירת תוכן האפליקציה במטמון מוסבר איך לבצע אופטימיזציה של הביצועים באמצעות Cloud CDN.
תחויבו גם על השימוש במוצרי Google Cloud שבהם נעשה שימוש בקצה העורפי:
- Cloud Run
- Cloud Build
- Artifact Registry
- Secret Manager
- Cloud Logging
המחירים המדויקים של הפריטים האלה מפורטים בדף התמחור שלנו.
דוגמאות לחיוב
העלות של הפעלת אפליקציית אינטרנט דינמית ב-App Hosting עשויה להשתנות במידה רבה בהתאם לגורמים כמו תנועה, הגדרות זמן ריצה וגודל התגובה. העלויות בדוגמה שלנו מבוססות על הנחות מסוימות לגבי הגורמים האלה.
גודל התנועה והתגובה
אחרי שהאפליקציה תגיע למכסת החינם החודשית, כל ביקור באתר יגרום לעלויות. העלויות האלה לא קבועות, הן תלויות בגורמים כמו מספר הבקשות ברקע שמופעלות בכל ביקור, כוח המחשוב הנדרש ליצירת התגובה וגודל התגובה. חלק מהבקשות פשוט יקרות יותר מאחרות. לדוגמה, סביר להניח שהעלות של הצגת דף עשיר בתמונות או בנתונים מורכבים תהיה גבוהה יותר מהעלות של הצגת קובץ HTML פשוט. באופן דומה, בדרך כלל יקר יותר ליצור דף באופן דינמי בשרת מאשר להציג גרסה שנשמרה במטמון מ-CDN.
כדי לקבל הערכה יעילה של העלויות של האפליקציה, כדאי להביא בחשבון כמה מדדים מרכזיים:
- בקשות לכל ביקור: כמה בקשות נפרדות מופעלות במהלך ביקור של משתמש אופייני? (חשוב לזכור ש'טעינה של דף' אחת כוללת בדרך כלל הרבה בקשות בסיסיות לנכסים כמו תמונות, CSS ו-JavaScript).
- גודל התגובה הממוצע: מהו הגודל הטיפוסי של הנתונים שנשלחים חזרה לכל בקשה?
- זמן אחזור ממוצע לתגובה: כמה זמן לוקח לאפליקציה להגיב לבקשה, בממוצע?
כדי להעריך את הערכים האלה, אפשר לבדוק את יומני הבקשות של האפליקציה במסוף Google Cloud. בחישוב העלויות לדוגמה, הנחנו את הפרטים הבאים:
| מאפייני התנועה | |
|---|---|
| ~בקשות לחיוב לכל ביקור | 10 |
| גודל התגובה הממוצע (KiB) | 400 |
| זמן האחזור הממוצע של התגובה (אלפיות שנייה) | 1000 |
| שיעור ההיטים במטמון | 50% |
הגדרות זמן ריצה
| Cloud Run הגדרות1 | |
|---|---|
| מגבלה על מעבד (vCPU) | 1 |
| מגבלת זיכרון (MiB) | 512 |
| בו-זמניות (בקשות) | 80 |
| minInstances | 0 |
| maxInstances | 100 |
1 אלה ערכי ברירת המחדל ש-App Hosting מספק. כדי לבדוק את ההגדרות של Cloud Run בכל השקות, אפשר לעיין בפרטי הגרסה Cloud Run. בכרטיסייה Rollouts במסוף Firebase, מעבירים את העכבר מעל השקה ובוחרים בתפריט של שלוש הנקודות, ואז בוחרים באפשרות 'View Cloud Run revision'.
הנחות אחרות
| שימוש בפרויקט | |
|---|---|
| שיטת הפריסה | GitHub |
| גרסאות build לחודש | 20 |
| דקות לכל build | 8 |
| שמירת יומנים | פחות מ-30 יום |
| גרסאות של סודות | פחות מ-6 גרסאות |
| גודל התמונה במרשם ה-Artifacts (MB) | 380 |
חשבון לדוגמה
על סמך ההנחות האלה, אפשר להסיק את העלויות הבאות לתרחיש לדוגמה הזה. ברמה של 10,000 ביקורים אין כמעט עלויות, והעלויות המשמעותיות מתחילות לצבור ברמה של מיליון ביקורים, שבה ביקור הוא בקשה לאפליקציה שהמשתמש ביצע.
| SKU | מחיר | היחידה | רמה ללא עלות | שימוש ב-10,000 ביקורים | העלות של 10,000 ביקורים | שימוש ב-1 מיליון ביקורים | העלות של מיליון ביקורים |
|---|---|---|---|---|---|---|---|
| Cloud Run – CPU | $0.00 |
vCPU שנייה | 180,000.00 |
1250 |
$0.00 |
125000 |
$0.00 |
| Cloud Run – זיכרון | $0.00 |
GiB שנייה | 360,000.00 |
625 |
$0.00 |
62500 |
$0.00 |
| Cloud Run – בקשות | 1.6 ש"ח |
בקשות SSR של M | 2.00 |
0.05 |
$0.00 |
5 |
1.20$ |
| Cloud Build – דקות build | $0.01 |
build-minute | 2,500.00 |
160 |
$0.00 |
160 |
$0.00 |
| Artifact Registry – אחסון | $0.10 |
GiB (שנשמר) | 0.50 |
0.6 |
$0.01 |
0.6 |
$0.01 |
| אירוח אפליקציות – רוחב פס יוצא ללא מטמון | 0.80 ש"ח |
GiB | 10 |
2 |
$0.00 |
200 |
39.00$ |
| App Hosting – רוחב פס יוצא שנשמר במטמון | $0.15 |
GiB | 2 |
$0.00 |
200 |
29.25$ |
|
| Secret Manager – גרסאות סודיות פעילות | 0.06$ |
גרסאות | 6.00 |
6.00 |
$0.00 |
6.00 |
$0.00 |
| Secret Manager – פעולות גישה | 0.03$ |
10,000 פעולות | 1.0 |
0.10 |
$0.00 |
5.00 |
0.12$ |
| Secret Manager – התראות על רוטציה | $0.05 |
רוטציות | 3.00 |
0.00 |
$0.00 |
0.00 |
$0.00 |
| Cloud Logging – אחסון ביומן | 0.50$ |
GiB | 50.00 |
0.50 |
$0.00 |
50.00 |
$0.00 |
| Cloud Logging – שמירת נתוני יומנים | $0.01 |
GiB לחודש | 30 ימים | $0.00 |
$0.00 |
||
| סה"כ | 0.01$ |
69.58$ |
חישובים
| מק"ט | Unit | איך מחשבים את השימוש |
|---|---|---|
| Cloud Run – CPU | vCPU שנייה | שניות vCPU = vCPU לכל מכונה * זמן האחזור הממוצע לתגובה לכל בקשה * מספר הביקורים * מספר הבקשות לחיוב לכל ביקור / מספר הבקשות בו-זמנית |
| Cloud Run – זיכרון | GiB שנייה | שניות GiB = GiB לכל מכונה * זמן האחזור הממוצע לתגובה לכל בקשה * מספר הביקורים * מספר הבקשות לחיוב לכל ביקור / מספר הבקשות בו-זמנית |
| Cloud Run – בקשות | בקשות SSR של M | מספר הבקשות ל-SSR במיליוני בקשות = (מספר הביקורים * מספר הבקשות לחיוב לכל ביקור / 1,000,000) * (1 - שיעור ההיטים במטמון) |
| Cloud Build – דקות build | build-minute | build-minutes = מספר הגרסאות המבוססות על ה-build * מספר הדקות לכל build |
| Artifact Registry – אחסון 1 | GiB (שנשמר) | GiB (שנשמר) = 2 * גודל התמונה |
| אירוח אפליקציות – רוחב פס ללא מטמון | GiB | GiB ללא שמירה במטמון= (1 - שיעור ההיטים במטמון) * (# of visits * billed requests per visit * outgoing bandwidth per request) |
| אירוח אפליקציות – רוחב פס שנשמר במטמון | GiB | GiB ששמורים במטמון = שיעור היטים במטמון * (מספר הביקורים * בקשות לחיוב לכל ביקור * רוחב הפס היוצא לכל בקשה) |
1 בדרך כלל תהיה לאפליקציה רק תמונה אחת ב-Artifact Registry, כי אירוח האפליקציות מנקה באופן אוטומטי גרסאות שלא בשימוש. יכול להיות שתראו שתי תמונות בקצרה רק במהלך השקה חדשה.