תכנuן פריסת ExpressRoute לשימוש עם Microsoft Power Platform

עכשיו כשהחלטת להשתמש ב- ExpressRoute עבור Microsoft Power Platform, חשוב לתכנן את הפריסה כך שתאפשר את הצרכים והסביבה שלך.

דרישות מוקדמות עבור ExpressRoute

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

דרישות מקדימות חיצוניות

ExpressRoute אינו מספק את החיבור הפיזי עצמו; הוא מספק את הקישוריות הפרטית בחיבור פיזי שכבר הוקם. תחילה על ספק קישוריות להגדיר את הקישוריות הפיזית. קיימות מספר דרכים שבהן ניתן ליצור קישוריות זו עם שותפי ExpressRoute קיימים. תיעוד ExpressRoute מספק הסברים מפורטים על האפשרויות ועל השותפים הזמינים כרגע.

כחלק מהתכנון, יהיה עליך לקחת את הדברים הבאים בחשבון:

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

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

  • זמן ההגדרה: במקרים מסוימים יהיה צורך להגדיר חומרה פיזית. יהיה צורך לשלב זמן הגדרה זה בלוח הזמנים של ההטמעה.

  • כישורי תצורה ומשאבים: מרבית מורכבות התצורה טמונה בהגדרת הניתוב הפנימי ברשת שלך. חשוב לוודא שאנשים מיומנים יהיו זמינים לעשות זאת.

דרישות מוקדמות של Microsoft

לאחר הקמת הקישוריות הפיזית, תוכל להמשיך בהגדרת חיבורי ExpressRoute עצמם. לפעולה זו נדרש:

  • מנוי Azure שבו ניתן לספק את מעגלי ExpressRoute ולבצע חיוב.

  • תצורה של מעגלי ExpressRoute בתוך מנוי Azure , המתבצעת באמצעות הכלים של Azure.

תכנון תצורת הניתוב עבור תעבורה של Microsoft Power Platform ברחבי ExpressRoute

בתכנון ניתוב תעבורה של Microsoft Power Platform, יהיה עליך לקחת בחשבון את סוגי התעבורה השונים שתלויים באופן שהגדרת אותם ושהשתמשת בהם ב- Microsoft Power Platform.

כדי להבין כיצד להגדיר את ExpressRoute עבור Microsoft Power Platform, תצטרך לשקול את השימושים והקשרים השונים אל Microsoft Power Platform וממנה, שתלויים בשירותים ובתכונות שבהם אתה משתמש.

תצורת ניתוב

תצורת הניתוב מתבצעת על-ידי ספק הקישוריות או על-ידי הלקוח, בהתאם לסוג החיבור המסופק.

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

  • הנתיב דרך רשת המשנה של הרשת מוגדר עבור ExpressRoute.

    or

  • מעגל הכשל נבחר בהעדפה לחיבור אינטרנט ציבורי ל- Microsoft Power Platform.

לכן, חשוב לזהות אילו רשתות משנה ברשת שלך אמורות להיות היעדים עבור חיבורי ההפעלה הראשיים והבסיסיים של (BGP) ‏Border Gateway Protocol, כדי לוודא שהקידומות של Microsoft Power Platform מעדיפות נתיב זה. אין צורך להגדיר באופן ספציפי את השירותים בכל קצה, מכיוון שתצורה זו נעשית על-ידי פרסום ה- IP של רשתות המשנה/הקידומות באמצעות חיבור זה. כאשר יש בקשה יזומה, אלגוריתם הניתוב רואה את חיבור ה- BGP הישיר כנתיב המועדף עבור התעבורה לרשת המשנה המחוברת למעגל ExpressRoute, ומכוון את התעבורה בדרך זו.

קביעת תצורה של ExpressRoute לבסיסי משתמשים מבוזרים

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

בדוגמה הבאה, החיבור של משתמש שנמצא בסניף מנותב דרך ה- WAN לחיבור מרכז הנתונים של הלקוח ל- ExpressRoute.

תעבורה מסניף הלקוח מחוברת למרכז הנתונים של הלקוח באמצעות WAN.

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

רשת ה- WAN מוגדרת עבור כל מיקום של סניף למרכז הנתונים של הלקוח.

אם החיבור בין הלקוח ל- ExpressRoute גרוע, או שהוא רווי או לא יעיל בכל צורה אחרת, ExpressRoute לא יוכל לפתור זאת מכיוון שבעיות החיבור בהגעה לנקודת הכניסה של ExpressRoute עדיין ישפיעו על חוויית המשתמש. במקרה כזה, כדאי לשקול להשתמש ב- ExpressRoute Direct שמספק לך את היכולת להתחבר ישירות לרשת הכללית של Microsoft.

לסניף אחד יש קישוריות גרועה לרשת WAN בהשוואה לסניפים אחרים.

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

סניף אחד מתחבר ל- Microsoft Cloud Service ללא גישה דרך ExpressRoute.

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

סניף אחד מתחבר ישירות לקצה של השותף.

הגישה של חיבור מיקומי הסניפים למרכז נתונים מרכזי באמצעות WAN והקמת מעגלי ExpressRoute בין הלקוח למרכזי הנתונים של Microsoft היא בדרך כלל עדיפה ומעשית יותר מאשר הניסיון ליצור חיבור ExpressRoute מכל מיקום של סניף. דבר זה יהיה יקר באופן יחסי ומסובך להתקנה ולתחזוקה, אם זה יידרש במיקומים רבים.

גישה חלופית היא לחבר את כל סניפי מרכז הנתונים של הלקוחות דרך אותו IP VPN ולאפשר לספק שירותי ה- IP VPN להתחבר ל- Microsoft במיקום של ה- ExpressRoute.

אם אתה נתקל בקשיים בחיבור WAN מקומי, בדרך כלל עדיף לייעל אותו—באמצעות שיטות כגון השגת רוחב פס נוסף או מיטוב הניתוב—במקום לנסות ליצור חיבור ExpressRoute מכל מיקום.

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

מעגל ExpressRoute נפרד נמצא בשימוש עבור כל מדינה.

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

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

פעולה אחת מחברת באמצעות ExpressRoute, והפעולה השנייה מחברת ישירות דרך האינטרנט.

ExpressRoute (רגיל) מציע קישוריות רק באזור גיאוגרפי ספציפי; ExpressRoute Premium נדרש כדי להציע גישה ממגוום אזורים גיאוגרפיים מנקודת חיבור ExpressRoute אחת. דבר זה יהיה רלוונטי אם למשל ללקוח יש משרדים שנמצאים בארצות הברית ומשרדים באירופה, וכולם משתמשים בסביבה Microsoft Power Platform אחת. אם הדייר Microsoft Power Platform של הלקוח פרוס בארצות הברית, מעגל ה- ExpressRoute שלו באירופה צריך להיות SKU ‏Premium. אם הדייר Microsoft Power Platform שלהם נמצא באירופה, המעגל האמריקני שלהם יצטרך להיות מסוג Premium.

הימנעות מניתוב אסימטרי

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

נקבע ניתוב שגוי, שהוביל ניתוב אסימטרי, והתגובה נדחית על-ידי חומת האש של הלקוח.

זה יכול לקרות אם הרשת המקומית של לקוח קובעת כי הניתוב היעיל ביותר לשירותי הענן של Microsoft הוא ברחבי האינטרנט הציבורי ולא דרך ה- WAN למעגל הפרטי של ExpressRoute. אך אם כתובת ה- IP של הלקוח היא כתובת IP ציבורית או שהיא מתורגמת באמצעות NAT מיפוי לכתובת IP ציבורית המפורסמת באמצעות ExpressRoute, הנתיב היעיל ביותר בחזרה לאותה כתובת IP יהיה ככל הנראה דרך הפעלת BGP ב- ExpressRoute. תוכל להשתמש בכתובות IP NAT שונות בקצה האינטרנט שלך ובקצה ExpressRoute. עם כתובת מקור ייחודית, תעבורה חוזרת תחזור באופן חד משמעי לאותו קצה.

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

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

קישוריות חיצונית מ/אל Microsoft Power Platform

בעת יצירת חיבורים אל Microsoft Power Platform ממיקומי הלקוחות, ישנם מספר סוגי תעבורה שיש לקחת בחשבון. דבר זה יכול להוביל לשני סוגי ישויות עמית, ישות עמית Microsoft ופרטית, וניתן להשתמש באותו מעגל ExpressRoute עבור סוגי ישויות עמית אלו כפי שמוצג בתמונה הבאה.

מבט כולל על קישוריות חיצונית עם Microsoft Power Platform. נעשה שימוש בחיבור ExpressRoute יחיד כדי לאפשר גם תעבורת רשת של ישות עמית Microsoft וגם של ישות עמית פרטית.

ישנם סוגי חיבורים שונים הקיימים בין שירותי Microsoft Power Platform והרשת החיצונית. לדוגמה, קישוריות Exchange Web Services באמצעות סנכרון בצד השרת משתמשת ב- ExpressRoute כדי להעביר תעבורת רשת מרשת של Microsoft לרשת הלקוחות. קישוריות לשירותי אינטרנט משתמשת ב- ExpressRoute הן לתעבורה נכנסת והן לתעבורה יוצאת לרשת של Microsoft. עבור לקוח HTTPS, חיבור ExpressRoute משמש לקבלת גישה מרשת הלקוחות לרשת של Microsoft. התמונה הבאה ממחישה דוגמאות אלה.

דיאגרמה שמציגה סוגי חיבורים שונים הקיימים בין שירותי Microsoft Power Platform והרשת החיצונית.

תעבורה יוצאת (תעבורה משירותי Microsoft Power Platform)

מספר סוגים של תעבורה יוצאת יכולים להגיע ישירות משירותי Microsoft Power Platform לשירותי לקוחות. עבור כל אחד מאלה, חשוב לציין כי שירות הלקוחות חייב לאפשר גישה ציבורית מכתובת IP ציבורית שניתן לפתור באמצעות DNS ציבורי על-ידי שירותי Microsoft Power Platform.

בנוסף, יש לפרסם את כתובת ה- IP הזו ל- Microsoft באמצעות ExpressRoute כך שניתוב הרשת הפנימית בתוך שירותי Microsoft Power Platform ידע לנתב אותו דרך אותו חיבור ExpressRoute.

שירותי Microsoft Power Platform לא יכולים לציין איזה מופע שירות או ארגון לקוחות יכולים להגיש בקשות לאילו כתובות IP. לכן, חשוב להתייחס לבקשות הנכנסות לרשת הארגונית ככאלו שמגיעות מהאינטרנט ולאבטח אותן ככאלה.

הטבלה הבאה מתארת את התעבורה היוצאת משירותי Microsoft Power Platform.

תיאור סוג התעבורה והכיוון סוג ישות העמית מטרה
שירותי אינטרנט HTTPS יוצא משירותי Microsoft Power Platform ישות עמית של Microsoft
פרסם שירותי אינטרנט בכתובות IP ציבוריות הנמצאות בתוך רשתות המשנה המוגדרות באמצעות ExpressRoute
יישומי plug-in מותאמים אישית ופעילויות זרימת עבודה יכולים להגיש בקשות שירותי אינטרנט לשירותים חיצוניים
Exchange Integration: מצב היברידי HTTPS יוצא משירותי Microsoft Power Platform ישות עמית של Microsoft
יש לפרסם שירותי אינטרנט בכתובות IP ציבוריות הנמצאות בתוך רשתות המשנה המוגדרות באמצעות ExpressRoute
בקשות Exchange Web Services מסנכרון בצד השרת עבור פריסה היברידית (שירותי Microsoft Power Platform, ‏Exchange מקומי)
מחברים HTTPS נכנס משירותי Microsoft Power Platform ישות עמית של Microsoft בקשות משירותי Microsoft Power Platform דרך שירות Azure API Management באמצעות מחברים המשתמשים בשער הנתונים המקומי
Azure Relay HTTPS יוצא משירותי Microsoft Power Platform ישות עמית של Microsoft
פרסם שירותי אינטרנט בכתובות IP ציבוריות הנמצאות בתוך רשתות המשנה המוגדרות באמצעות ExpressRoute
קישוריות ישירה בין זרימות הענן וזרימות שולחן העבודה של Power Automate

תעבורה נכנסת (תעבורה אל שירותי Microsoft Power Platform)

התעבורה הנכנסת הבאה אפשרית עבור שירותי Microsoft Power Platform מרשת הלקוחות.

תיאור סוג התעבורה והכיוון סוג ישות העמית מטרה
קישוריות הלקוח HTTPS נכנס אל שירותי Microsoft Power Platform ישות עמית של Microsoft
חיבור אינטרנט ישיר עבור תוכן סטטי המוגש על-ידי רשת אספקת התוכן של Azure
בקשות לקוח עבור ממשקי המשתמש של שירותי Microsoft Power Platform
שירותי אינטרנט HTTPS נכנס אל שירותי Microsoft Power Platform ישות עמית של Microsoft בקשות לשירותי Microsoft Power Platform דרך ממשקי ה- API של שירות האינטרנט (SOAP, Web API). מתוך יישום לקוח סטנדרטי או מתוך יישום מותאם אישית
מחברים HTTPS נכנס אל שירותי Microsoft Power Platform ישות עמית של Microsoft תגובות בחזרה אל שירותי Microsoft Power Platform דרך ה- APIM באמצעות מחברים המשתמשים בשער הנתונים המקומי

קישוריות ענן פנימית בשירותי Microsoft Power Platform

שירותי Microsoft Power Platform משתמשים ומשלבים מספר שירותים מקוונים אחרים של Microsoft המתארחים גם ב- Microsoft 365 וגם ב- Azure.

דיאגרמה שמציגה סוגי חיבורים שונים הקיימים בין שירותי Microsoft Power Platform והרשת הפנימית.

תיאור סוג התעבורה והכיוון מטרה
שילוב של Exchange HTTPS יוצא ל- Microsoft 365 בקשות שירות אינטרנט של Exchange אל Exchange Online מסינכרון בצד השרת
שילוב SharePoint HTTPS יוצא ל- Microsoft 365 בקשות שירות אינטרנט של SharePoint אל Online SharePoint משירותי Microsoft Power Platform
אפיק שירות HTTPS יוצא אל אפיק שירות Azure דחף אירועים אל אפיק שירות Azure כרישום אירועים רגיל או מיישומי plug-in מותאמים אישית ומפעילויות זרימת עבודה
סנכרון נתונים HTTPS נכנס מ- Azure בקשות למעקב אחר שינויים נכנסים לסנכרון שירותי נתונים, כולל חיפוש/מצב לא מקוון/תובנות לקוח
אימות HTTPS יוצא ל- Azure Active Directory (Azure AD) מרבית האימות נעשה באמצעות הפניות פסיביות ואסימוני טענות, אך נתונים מסוימים מסונכרנים עם Azure AD באופן ישיר
זרימות נתונים HTTPS יוצא ל- Azure Data Lake Storage הוא מספק יכולות ניתוח ומאפשר גישה לפתרונות Big Data המשלבים נתונים משירותי Microsoft Power Platform כמו גם ממקורות אחרים, בנוסף לתובנה הנובעת מניתוח.
מחברים HTTPS יוצא אל שירותי Azure PaaS חיבורים לשירותי Azure PaaS שונים
זרימות שולחן עבודה HTTPS יוצא אל Azure Relay קישוריות ישירה בין זרימות הענן וזרימות שולחן העבודה של Power Automate שנוצרו ב- Power Automate למחשב שולחני

הקישוריות עצמה בין שירותים אלה, המתארחים במנויים של Microsoft או של לקוחות Azure, מטופלת על-ידי Microsoft. ExpressRoute אינו חל על חיבורים עם שירותים אלה.

כאשר דוחפים אירועים לאפיק השירות, הקישוריות בין שירותי Microsoft Power Platform ו- Azure מטופלים באופן פנימי. באופן נפרד, הלקוח יכול להגיש בקשות ל- Service Bus כדי לאחזר מידע, וניתן לנהל זאת באמצעות ישות עמית של Microsoft.

קישוריות ענן ציבורית ופרטית של לקוח מ/אל שירותי Microsoft Power Platform

שירותי Microsoft Power Platform מאפשרים גם שילוב ישיר עם משאבי Azure ציבוריים או פרטיים:

  • ממקורות חיצוניים, באמצעות ממשקי API של שירותי אינטרנט של Microsoft Dataverse.

  • למקורות חיצוניים, באמצעות בקשות שהוגשו לשירות אינטרנט.

  • למקורות חיצוניים, באמצעות מחברים.

יש לקחת בחשבון את ההשלכות של זה בניתוב של ExpressRoute.

תיאור סוג התעבורה והכיוון סוג ישות העמית מטרה
פורטלים HTTPS נכנס אל Azure פנימי למרכז הנתונים, למעט תוכן סטטי, המשתמש ברשת אספקת תוכן. (רשת אספקת תוכן אינה נתמכת על-ידי ExpressRoute, כך שתוכן סטטי יעבור ברחבי האינטרנט הציבורי.) ארח שירותים ציבוריים. יתכנו תרחישים שבהם עובדים פנימיים יוכלו לגשת למשאבים אלה, כך שייתכן שתרצה שהתעבורה תעבור דרך ExpressRoute ולא דרך האינטרנט הציבורי
נתיב למידה HTTPS נכנס אל Azure משתמש ברשת אספקת תוכן שאינה נתמכת על-ידי ExpressRoute, כך שתוכן יעבור ברחבי האינטרנט הציבורי האירוח מתבצע בשירות ציבורי מכיוון שהוא אינו מכיל נתונים פרטיים של לקוחות. למטרות חיזוי, יתכנו תרחישים שבהם תרצה לבצע ניתוב באמצעות ExpressRoute
אפיק שירות HTTPS נכנס אל אפיק שירות Azure פנימי למרכז נתונים משוך אירועים מאפיק שירות Azure שמוקמו שם כרישום אירועים רגיל או מיישומי plug-in מותאמים אישית או מפעילויות זרימת עבודה
בקשות שירות אינטרנט נכנס מ- Azure IaaS/PaaS פנימי למרכז נתונים לקוחות יכולים לארח יישומים מותאמים אישית ב- Azure ולהגיש בקשות של שירותי אינטרנט של Microsoft Power Platform
בקשות שירות אינטרנט יוצא ל- IaaS/PaaS של Azure פנימי למרכז נתונים לקוחות יכולים ליישם יישומי plug-in מותאמים אישית ופעילות זרימת עבודה שמגישים בקשות לשירותים המתארחים ב- Azure
זרימות נתונים חיבורי נתונים אל Azure Data Lake Storage פנימי למרכז נתונים מספק יכולות ניתוח ומאפשר גישה לפתרונות Big Data המשלבים נתונים משירותי Microsoft Power Platform כמו גם ממקורות אחרים, בנוסף לתובנה הנובעת מהניתוח.
Azure Data Lake חיבורי נתונים אל Azure Data Lake Storage פנימי למרכז נתונים מספק יכולות ניתוח ומאפשר גישה לפתרונות Big Data המשלבים נתונים משירותי Microsoft Power Platform כמו גם ממקורות אחרים ומהתובנה הנובעת מהניתוח.
Azure SQL חיבורי נתונים לשירותי Azure SQL פנימי למרכז נתונים עם יכולות כגון Export to Data Warehouse, השימוש במופע של Azure SQL להחזקת העתקים של נתוני Microsoft Dataverse לצורכי דיווח או שכפול יגדל. ייתכן שיהיה ערך להגנה על החיבורים למשאבים אלה באמצעות ExpressRoute.

ייתכן שבעתיד יהיו שירותים ציבוריים אחרים המתחברים באופן פנימי למרכז הנתונים כאשר נעשה שימוש ביכולות אחרות של Azure.