שיטות מומלצות לשימוש ב-Cloud DNS

במסמך הזה מוסבר על השיטות המומלצות לשימוש באזורים פרטיים, בהעברת DNS ובארכיטקטורות הפניה ל-DNS היברידי.

קל יותר לאנשים ולאפליקציות להשתמש במערכת שמות הדומיין (DNS) כדי לפנות לאפליקציות ולשירותים, כי קל יותר לזכור שם והוא גמיש יותר מכתובות IP. בסביבה היברידית שכוללת פלטפורמות מקומיות ופלטפורמת ענן אחת או יותר, לעיתים קרובות צריך לגשת לרשומות DNS של משאבים פנימיים בסביבות שונות. באופן מסורתי, רשומות DNS מקומיות מנוהלות באופן ידני באמצעות שרת DNS סמכותי, כמו BIND בסביבות UNIX/Linux או Active Directory בסביבות Microsoft Windows.

במסמך הזה מפורטות שיטות מומלצות להעברת בקשות DNS פרטיות בין סביבות, כדי לוודא שאפשר לפנות לשירותים גם מסביבות מקומיות וגם מתוך Cloud de Confiance.

עקרונות כלליים

מידע על מושגי DNS ב- Cloud de Confiance

כשמשתמשים ב-DNS ב- Cloud de Confiance, חשוב להבין את המערכות והשירותים השונים שזמינים ב- Cloud de Confianceלפתרון בעיות ב-DNS ולשמות דומיין: Cloud de Confiance

• ‫Internal DNS הוא שירות שיוצר באופן אוטומטי שמות DNS למכונות וירטואליות ולמאזני עומסים פנימיים ב-Compute Engine.
• ‫Cloud DNS הוא שירות שמספק תחום DNS עם זמינות גבוהה וזמן אחזור נמוך. הוא יכול לשמש כשרת DNS סמכותי לאזורים פרטיים שגלויים רק בתוך הרשת שלכם.
• ‫שירות מנוהל ל-Microsoft Active Directory הוא שירות מוקשח עם זמינות גבוהה שמפעיל את Microsoft Active Directory, כולל בקר דומיין.

זיהוי בעלי עניין, כלים ותהליכים

כשחושבים על בניית אסטרטגיה ל-DNS בסביבה היברידית, חשוב להכיר את הארכיטקטורה הנוכחית וליצור קשר עם כל בעלי העניין. צריך לבצע את הפעולות הבאות:

• מזהים את האדמין של שרתי ה-DNS הארגוניים של הארגון ויוצרים איתו קשר. אפשר לבקש מהם מידע על ההגדרות שנדרשות כדי למפות את ההגדרה המקומית לארכיטקטורה מתאימה ב-Cloud de Confiance. מידע על שיטות לגישה לרשומות DNS זמין במאמר שימוש בהעברה מותנית לגישה לרשומות DNS מתוך רשת מקומית.Cloud de Confiance
• כדאי להכיר את תוכנת ה-DNS הנוכחית ולזהות את שמות הדומיינים שמשמשים לשימוש פרטי בארגון.
• מזהים אנשי קשר בצוות הרשת שיכולים לוודא שהתעבורה לשרתי Cloud DNS מנותבת בצורה נכונה.
• מומלץ להכיר את אסטרטגיית הקישוריות ההיברידית שלכם ואת הדפוסים והשיטות של סביבות היברידיות ומרובות עננים (multi-cloud).

שיטות מומלצות לשימוש באזורים פרטיים ב-Cloud DNS

באזורים פרטיים מתארחות רשומות DNS שגלויות רק בתוך הארגון.

שימוש באוטומציה לניהול אזורים פרטיים בפרויקט המארח של VPC משותף

אם אתם משתמשים ברשתות VPC משותפות בארגון, אתם צריכים לארח את כל האזורים הפרטיים ב-Cloud DNS בפרויקט המארח. לכל הפרויקטים של השירות יש גישה אוטומטית לרשומות באזורים פרטיים שמצורפים לרשת ה-VPC המשותפת. אפשר גם להגדיר את האזור בפרויקט שירות באמצעות קישור בין פרויקטים.

באיור 3 מוצג איך אזורים פרטיים מתארחים ברשת VPC משותפת.

אם רוצים שהצוותים יגדירו רשומות DNS משלהם, מומלץ להפוך את יצירת רשומות ה-DNS לאוטומטית. לדוגמה, אפשר ליצור אפליקציית אינטרנט או API פנימי שבהם משתמשים מגדירים רשומות DNS משלהם בדומיינים משניים ספציפיים. האפליקציה בודקת שהרשומות עומדות בכללים של הארגון.

אפשרות אחרת היא לשמור את הגדרות ה-DNS במאגר המקורות של הקוד כמו Cloud Source Repositories, בצורה של תיאורים של Terraform או Cloud Deployment Manager, ולאשר בקשות משיכה מצוותים.

בשני המקרים, חשבון שירות עם התפקיד אדמין DNS ב-IAM בפרויקט המארח יכול לפרוס את השינויים באופן אוטומטי אחרי שהם אושרו.

הגדרת תפקידי IAM לפי העיקרון של הרשאות מינימליות

כדאי להשתמש בעקרון האבטחה של הרשאות מינימליות כדי לתת את הזכות לשנות רשומות DNS רק לאנשים בארגון שצריכים לבצע את המשימה הזו. מומלץ להימנע משימוש בתפקידים בסיסיים כי הם עשויים לתת גישה למשאבים מעבר לאלה שהמשתמש צריך. ‫Cloud DNS מציע תפקידים והרשאות שמאפשרים לכם לתת גישת קריאה וכתיבה שספציפית ל-DNS.

שיטות מומלצות לשימוש באזורי העברה של DNS ובמדיניות שרתים

‫Cloud DNS מציע אזורי העברה של DNS ומדיניות של שרתי DNS כדי לאפשר חיפושים של שמות DNS בין הסביבה המקומית לסביבת Cloud de Confiance . יש כמה אפשרויות להגדרת העברת DNS. בקטע הבא מפורטות שיטות מומלצות להגדרת DNS היברידי. השיטות המומלצות האלה מוסברות בדוגמאות לארכיטקטורות של DNS היברידי.

שימוש באזורי העברה כדי לשלוח שאילתות לשרתים מקומיים

כדי לוודא שאפשר לשלוח שאילתות לרשומות DNS בסביבה המקומית, צריך להגדיר אזור העברה לדומיין שבו משתמשים בסביבה המקומית למשאבים של החברה (למשל corp.example.com). הגישה הזו עדיפה על שימוש במדיניות DNS שמאפשרת שרת שמות חלופי. הוא שומר על הגישה לשמות DNS פנימיים של Compute Engine, וכתובות IP חיצוניות עדיין מפוענחות ללא קפיצה נוספת דרך שרת שמות מקומי.

זרימת התנועה שמשתמשת בהגדרה הזו מוצגת בארכיטקטורות לדוגמה של DNS היברידי.

משתמשים בשרתי שמות חלופיים רק אם צריך לנטר או לסנן את כל תעבורת ה-DNS במקום, ואם רישום ביומן של שרת DNS פרטי לא עונה על הדרישות שלכם.

שימוש במדיניות שרת DNS כדי לאפשר שאילתות משרתים מקומיים

כדי לאפשר למארחים מקומיים לשלוח שאילתות לרשומות DNS שמתארחות בתחומים פרטיים של Cloud DNS (לדוגמה, gcp.example.com), צריך ליצור מדיניות של שרת DNS באמצעות העברת DNS נכנסת. העברת DNS נכנסת מאפשרת למערכת לשלוח שאילתות לכל האזורים הפרטיים בפרויקט, וגם לכתובות IP של DNS פנימי ולאזורים מקושרים.

זרימת התנועה שמשתמשת בהגדרה הזו מוצגת בארכיטקטורות לדוגמה של DNS היברידי.

פותחים את חומות האש Cloud de Confiance המקומיות כדי לאפשר תנועת DNS

כדי לוודא שתנועת ה-DNS לא מסוננת בשום מקום בתוך רשת ה-VPC או בסביבה המקומית, צריך לבצע את הפעולות הבאות:

• מוודאים שחומת האש המקומית מעבירה שאילתות מ-Cloud DNS. ‫Cloud DNS שולח שאילתות מטווח כתובות ה-IP‏ 177.222.82.0/25. מערכת ה-DNS משתמשת ביציאת UDP‏ 53 או ביציאת TCP‏ 53, בהתאם לגודל הבקשה או התשובה.

• מוודאים ששרת ה-DNS לא חוסם שאילתות. אם שרת ה-DNS המקומי שלכם מקבל בקשות רק מכתובות IP ספציפיות, ודאו שטווח כתובות ה-IP 177.222.82.0/25 נכלל.

• מוודאים שהתנועה יכולה לזרום מהשרתים המקומיים לכתובות ה-IP להעברה. במכונות Cloud Router, מוסיפים מסלול מותאם אישית לפרסום לטווח כתובות ה-IP‏ 177.222.82.0/25 ברשת ה-VPC לסביבה המקומית.

שימוש בהעברה מותנית כדי לגשת לרשומות DNS משרת מקומי

ב-Cloud DNS, כדי לגשת לרשומות פרטיות שמתארחות בשרתי DNS ארגוניים מקומיים, אפשר להשתמש רק בתחומי העברה. עם זאת, בהתאם לתוכנת שרת ה-DNS שבה אתם משתמשים, יכול להיות שיהיו לכם כמה אפשרויות לגישה לרשומות ה-DNS ב- Cloud de Confiance מתוך המיקום המקומי. בכל מקרה, הגישה לרשומות מתבצעת באמצעות העברת DNS נכנסת:

• העברה מותנית. שימוש בהעברה מותנית פירושו ששרת ה-DNS של החברה מעביר בקשות לאזורים ספציפיים או לתת-דומיינים לכתובות ה-IP של ההעברה ב- Cloud de Confiance. אנחנו ממליצים על הגישה הזו כי היא הכי פשוטה ומאפשרת לכם לעקוב באופן מרכזי אחרי כל בקשות ה-DNS בשרתי ה-DNS של החברה.

• הענקת הרשאות. אם האזור הפרטי ב- Cloud de Confiance הוא תת-דומיין של האזור שבו אתם משתמשים בפריסה מקומית, אתם יכולים גם להקצות את תת-הדומיין הזה לשרת השמותCloud de Confiance על ידי הגדרת רשומות NS באזור. כשמשתמשים בהגדרה הזו, לקוחות יכולים לתקשר ישירות עם כתובות ה-IP להעברה ב-Cloud de Confiance , לכן חשוב לוודא שחומת האש מעבירה את הבקשות האלה.

• העברות אזורים. ‫Cloud DNS לא תומך בהעברות של אזורים, ולכן אי אפשר להשתמש בהעברות של אזורים כדי לסנכרן רשומות DNS עם שרתי DNS מקומיים.

שימוש בקישור בין רשתות שכנות (peering) ב-DNS כדי להגדיר העברה של תעבורת נתונים יוצאת לכמה רשתות VPC

כדי להגדיר העברה יוצאת לאותם שרתי DNS לכמה רשתות VPC, צריך להשתמש בקישור בין רשתות שכנות (peering) ב-DNS. אין תמיכה בהגדרת העברת תעבורה יוצאת לכמה רשתות VPC באופן עצמאי או באמצעות קישור בין רשתות VPC שכנות (peering) מהסיבות הבאות:

• ‫Cloud de Confiance מקבל תגובות משרתי ה-DNS שלך רק אם הן מנותבות לרשת ה-VPC שממנה נוצרה השאילתה. עם זאת, לכל השאילתות מרשת VPC יש את אותו טווח כתובות IP‏ 177.222.82.0/25 כמקור. לכן, אי אפשר לנתב את התשובות בצורה נכונה אלא אם יש לכם סביבות נפרדות בפריסה מקומית.
• העברה יוצאת לא יכולה לעבור דרך חיבור של קישור בין רשתות VPC שכנות. לדוגמה, אם רשת VPC A מוגדרת עם Cloud VPN או Cloud Interconnect, רשת VPC B לא יכולה להשתמש בחיבור VPC Network Peering שלה לרשת VPC A כדי לשלוח שאילתות DNS לשרתי ה-DNS המקומיים.

מומלץ להגדיר רשת VPC אחת לשליחת שאילתות לשרתי שמות מקומיים באמצעות העברה של תנועה יוצאת. לאחר מכן, רשתות VPC נוספות יכולות לשלוח שאילתות לשרתי השמות המקומיים על ידי טירגוט רשת ה-VPC המיועדת באמצעות אזור DNS של רשתות VPC מקושרות. השאילתות שלהם יועברו לשרתי שמות מקומיים בהתאם לסדר ההמרות של השמות ברשת ה-VPC שצוינה. ההגדרה הזו מוצגת בארכיטקטורות לדוגמה ל-DNS היברידי.

הסבר על ההבדל בין קישור DNS לבין קישור רשתות VPC

קישור בין רשתות VPC שכנות (peering) הוא לא אותו דבר כמו קישור DNS שכנות (peering). קישור (peering) בין רשתות VPC שכנות מאפשר למכונות וירטואליות (VM) בפרויקטים שונים להגיע אחת לשנייה, אבל הוא לא משנה את פתרון השמות. המשאבים בכל רשת VPC עדיין פועלים לפי סדר ההחלטה שלהם.

לעומת זאת, באמצעות DNS peering, אפשר לאפשר העברה של בקשות לאזורים ספציפיים לרשת VPC אחרת. כך אפשר להעביר בקשות לסביבות שונות של Cloud de Confiance , בלי קשר לשאלה אם רשתות ה-VPC מקושרות זו לזו.

גם קישור בין רשתות VPC שכנות (peering) וקישור בין שרתי DNS שכנים (peering) מוגדרים בצורה שונה. בקישור בין רשתות VPC שכנות, שתי רשתות ה-VPC צריכות להגדיר קשר קישור לרשת ה-VPC השנייה. הפירינג הופך אוטומטית לדו-כיווני.

קישור DNS מעביר בקשות DNS בכיוון אחד ולא דורש יחסים דו-כיווניים בין רשתות VPC. רשת VPC שמכונה רשת הצרכן של DNS מבצעת חיפושים של אזור קישור ב-Cloud DNS ברשת VPC אחרת, שמכונה רשת הספק של DNS. משתמשים עם הרשאת IAM‏ dns.networks.targetWithPeeringZone בפרויקט של רשת היצרן יכולים ליצור שיוך DNS בין רשתות הצרכן והיצרן. כדי להגדיר DNS peering מרשת VPC של צרכן, צריך את תפקיד ה-DNS peer בפרויקט המארח של רשת ה-VPC של הספק.

אם משתמשים בשמות שנוצרו אוטומטית, צריך להשתמש ב-DNS Peering לאזורים פנימיים

אם אתם משתמשים בשמות שנוצרו אוטומטית למכונות וירטואליות שנוצרו על ידי שירות ה-DNS הפנימי, אתם יכולים להשתמש ב-DNS Peering כדי להעביר את אזורי projectname.internal לפרויקטים אחרים. כפי שמוצג באיור 5, אפשר לקבץ את כל האזורים בפרויקט מרכז כדי להפוך אותם לנגישים מהרשת המקומית..internal

אם נתקלים בבעיות, אפשר להיעזר במדריך לפתרון בעיות

המדריך לפתרון בעיות ב-Cloud DNS כולל הוראות לפתרון שגיאות נפוצות שאתם עשויים להיתקל בהן כשאתם מגדירים את Cloud DNS.

דוגמאות לארכיטקטורות DNS היברידיות

בקטע הזה מפורטות כמה ארכיטקטורות לדוגמה לתרחישים נפוצים שבהם נעשה שימוש באזורים פרטיים של Cloud DNS בסביבה היברידית. בכל מקרה, המשאבים המקומיים ורשומות המשאבים והאזורים של Cloud de Confiance מנוהלים בסביבה. כל הרשומות זמינות לשליחת שאילתות גם ממארחים מקומיים וגם ממארחי Cloud de Confiance .

משתמשים בארכיטקטורת ההפניה שמתאימה לעיצוב רשת ה-VPC:

• ארכיטקטורה היברידית באמצעות רשת VPC משותפת אחת: נעשה שימוש ברשת VPC אחת שמחוברת לסביבות מקומיות או יוצאת מהן.

• ארכיטקטורה היברידית באמצעות כמה רשתות VPC נפרדות: חיבור של כמה רשתות VPC לסביבות מקומיות באמצעות מנהרות VPN שונות או צירופי VLAN, ושיתוף אותה תשתית DNS מקומית.

• ארכיטקטורה היברידית באמצעות רשת VPC מרכזית שמחוברת לרשתות VPC מסוג spoke: נעשה שימוש בקישור בין רשתות VPC שכנות (peering) כדי לחבר רשת VPC מרכזית לכמה רשתות VPC מסוג spoke עצמאיות.

בכל מקרה, הסביבה המקומית מחוברת לרשתות ה-VPC באמצעות מנהרת Cloud VPN אחת או יותר, או באמצעות חיבורי Dedicated Interconnect או Partner Interconnect. Cloud de Confiance לא משנה באיזו שיטת חיבור משתמשים לכל רשת VPC.

ארכיטקטורה היברידית באמצעות רשת VPC משותפת אחת

תרחיש השימוש הנפוץ ביותר הוא רשת VPC משותפת אחת שמחוברת לסביבה המקומית, כמו שמוצג באיור 6.

כדי להגדיר את הארכיטקטורה הזו:

1. מגדירים את שרתי ה-DNS המקומיים כשרתי DNS סמכותיים עבור corp.example.com.
2. מגדירים אזור פרטי סמכותי (לדוגמה, gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת, ומגדירים את כל הרשומות של המשאבים באזור הזה.
3. מגדירים מדיניות של שרת DNS בפרויקט המארח של רשת ה-VPC המשותף כדי לאפשר העברת DNS נכנסת.
4. מגדירים אזור העברה של DNS שמעביר את corp.example.com לשרתי ה-DNS המקומיים. צריך לתת לרשת ה-VPC המשותפת הרשאה לשלוח שאילתות לאזור ההעברה.
5. מגדירים העברה אל gcp.example.com בשרתי ה-DNS המקומיים, כך שההעברה תפנה לכתובת IP של מעביר לדואר נכנס ברשת ה-VPC המשותפת.
6. מוודאים שתנועת ה-DNS מותרת בחומת האש המקומית.
7. במקרים של Cloud Router, מוסיפים נתיב מותאם אישית שמוכרז לטווח 177.222.82.0/25 לסביבה המקומית.

ארכיטקטורה היברידית באמצעות כמה רשתות VPC נפרדות

אפשרות נוספת לארכיטקטורות היברידיות היא להשתמש בכמה רשתות VPC נפרדות. רשתות ה-VPC האלה בסביבתCloud de Confiance לא מקושרות זו לזו באמצעות קישור בין רשתות VPC שכנות. כל רשתות ה-VPC משתמשות במנהרות Cloud VPN נפרדות או בקבצים מצורפים של VLAN כדי להתחבר לסביבות המקומיות שלכם.

כפי שמוצג באיור 7, תרחיש שימוש אופייני בארכיטקטורה הזו הוא כשקיימות סביבות ייצור ופיתוח נפרדות שלא מתקשרות ביניהן, אבל הן חולקות שרתי DNS.

כדי להגדיר את הארכיטקטורה הזו:

1. מגדירים את שרתי ה-DNS המקומיים כשרתי DNS סמכותיים עבור corp.example.com.
2. מגדירים אזור פרטי (לדוגמה, prod.gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת של הייצור, ומגדירים את כל הרשומות של המשאבים באזור הזה.
3. מגדירים תחום פרטי (לדוגמה, dev.gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת לפיתוח, ומגדירים את כל הרשומות של המשאבים בתחום הזה.
4. מגדירים מדיניות של שרת DNS בפרויקט המארח עבור רשת ה-VPC המשותפת של הסביבה הפרודקשן, ומאפשרים העברת DNS נכנסת.
5. ברשת ה-VPC המשותפת של סביבת הייצור, מגדירים תחום DNS להעברת corp.example.com לשרתי ה-DNS המקומיים.
6. מגדירים אזור DNS שכנות (peering) מרשת ה-VPC המשותפת של הפיתוח לרשת ה-VPC המשותפת של הייצור עבור prod.gcp.example.com.
7. מגדירים אזור DNS שכנות (peering) מרשת ה-VPC המשותפת של סביבת הייצור לרשת ה-VPC המשותפת של סביבת הפיתוח עבור dev.gcp.example.com.
8. כדי להגדיר העברה נכנסת, צריך להקצות את הפתרון של gcp.example.com. לכתובות ה-IP הווירטואליות של העברה נכנסת ב-Cloud DNS בשרתי השמות המקומיים.
9. מוודאים שחומת האש מאפשרת תנועת DNS גם בחומות אש מקומיות וגם בחומות אש שלCloud de Confiance .
10. במקרים של Cloud Router, מוסיפים נתיב מותאם אישית לפרסום עבור טווח כתובות ה-IP‏ 177.222.82.0/25 ברשת ה-VPC המשותפת בסביבת הייצור, לסביבה המקומית.

ארכיטקטורה היברידית שמשתמשת ברשת VPC מרכזית שמחוברת לרשתות VPC מסוג spoke

אפשרות נוספת היא להשתמש ב-Cloud Interconnect או ב-Cloud VPN כדי לחבר את התשתית המקומית לרשת VPC מרכזית. כפי שמוצג באיור 8, אפשר להשתמש בקישור בין רשתות VPC שכנות (peering) כדי לקשר רשת VPC עם כמה רשתות VPC מסוג spoke. כל רשת VPC מסוג spoke מארחת תחומים פרטיים משלה ב-Cloud DNS. מסלולים בהתאמה אישית בקישור בין רשתות שכנות (peering) של VPC, יחד עם פרסום של מסלול בהתאמה אישית ב-Cloud Router, מאפשרים החלפה מלאה של מסלולים וקישוריות בין רשתות מקומיות לבין כל רשתות ה-VPC המקושרות. קישור DNS פועל במקביל לחיבורים של קישור בין רשתות VPC שכנות כדי לאפשר רזולוציית שמות בין סביבות.

התרשים הבא מציג את הארכיטקטורה הזו.

כדי להגדיר את הארכיטקטורה הזו:

1. מגדירים את שרתי ה-DNS המקומיים כשרתי DNS סמכותיים עבור corp.example.com.
2. מגדירים אזור פרטי (לדוגמה, projectX.gcp.example.com) ב-Cloud DNS לכל רשת VPC מסוג spoke, ומגדירים את כל הרשומות של המשאבים באזור הזה.
3. מגדירים מדיניות שרת DNS בפרויקט הרכזת עבור רשת ה-VPC של הרכזת כדי לאפשר העברת DNS נכנסת.
4. ברשת ה-VPC של הרכזת, יוצרים אזור DNS פרטי בשביל corp.example.com ומגדירים העברה יוצאת לשרתי ה-DNS המקומיים.
5. מגדירים אזור DNS של רשתות שכנות מרשת ה-VPC המרכזית לכל רשת VPC מסוג spoke עבור projectX.gcp.example.com.
6. מגדירים אזור DNS של רשתות שכנות מכל רשת VPC מסוג Spoke לרשת VPC מסוג Hub עבור example.com.
7. מגדירים העברה אל gcp.example.com בשרתי ה-DNS המקומיים כדי להפנות לכתובת IP של מעביר נתונים נכנס ברשת ה-VPC של הרכזת.
8. מוודאים שחומת האש מאפשרת תנועת DNS גם בחומות אש מקומיות וגם בחומות אש שלCloud de Confiance .
9. במכונות Cloud Router, מוסיפים נתיב מותאם אישית שמוכרז לטווח כתובות ה-IP‏ 177.222.82.0/25 ברשת ה-VPC של הרכזת לסביבה המקומית.
10. (אופציונלי) אם אתם משתמשים גם בשמות DNS פנימיים שנוצרו באופן אוטומטי, צריך לבצע peering בין כל אזור פרויקט מסוג spoke (לדוגמה, spoke-project-x.internal) לבין פרויקט ה-hub, ולהעביר את כל השאילתות לגבי .internal מתוך המערכות המקומיות.

המאמרים הבאים

• כדי למצוא פתרונות לבעיות נפוצות שאתם עשויים להיתקל בהן במהלך השימוש ב-Cloud DNS, אפשר לעיין במאמר בנושא פתרון בעיות.
• כדי לקבל הנחיות לגבי גישה להגדרה היברידית שמשתמשת ב- Cloud de Confianceוהטמעה שלה, אפשר לעיין במדריך הפתרונות בנושא תבניות ושיטות מומלצות לפתרונות היברידיים ומרובי-עננים.
• לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.