אמ;לק

כולנו מריצים שרתים, דאטהבייסים וקונטיינרים בענן, אבל לא תמיד עוצרים להבין את ״הקרקע״ שעליה הכל יושב. הפוסט הזה מפרק לגורמים את ההיררכיה התשתיתית של שני העננים הגדולים, AWS ו-Azure. נסביר מה ההבדל בין Region ל-Availability Zone, מה המקבילה של VPC בעולם של Azure, ואיך כל החלקים מתחברים יחד - מהרמה הארגונית הגלובלית ועד ל-Subnet הבודד שבו חי השרת שלכם. הבנה זו היא הבסיס לבניית מערכות עמידות, מאובטחות וחסכוניות.

---

רקע: למה זה בכלל צריך לעניין אותנו?

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

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

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

---

המבנה ההיררכי: AWS מול Azure

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

שכבה 1: ניהול מרכזי (Organization / Management Group)

זוהי שכבת המטרייה, המאפשרת לחברה לנהל מדיניות, חיובים והרשאות על פני מספר סביבות עבודה.

Organizations ב-AWS

• מה זה? קונטיינר-על המאגד תחתיו מספר חשבונות AWS. הוא מאפשר חיוב מרוכז (Consolidated Billing) ואכיפת מדיניות אבטחה גורפת (Service Control Policies - SCPs).

• למה זה חשוב? בארגון גדול, לכל צוות או סביבה (production, dev, staging) יש חשבון נפרד. ה-Organization הוא הכלי של ה-CISO וה-FinOps לוודא שאף אחד לא פותח בטעות מכרה ביטקוין על חשבון החברה, או מפעיל שירותים באזורים שאסורים מבחינת רגולציה.

Management Gropup ב-Azure

• מה זה? המקבילה כמעט זהה של Azure. ה-Management Groups יכול להכיל תחתיו מספר Subscriptions (חשבונות Azure), ואף לקנן Management Groups אחרים.

• למה זה חשוב? בדיוק כמו ב-AWS, שהו כלי הממשל המרכזי. ניתן להחיל Azure Policy ו- Role Based Access Control (RBAC) ברמה זו, והם ייאכפו כלפי מטה על כל ה-Subscriptions.

שכבה 2: יחידת הבסיס (Account / Subscription)

זוהי היחידה הבסיסית של בידוד משאבים, חיוב וזהויות

Account ב-AWS

• מה זה? מיכל לוגי נפרד לחלוטין שמכיל את כל המשאבים שלכם. חשבון אחד מבודד לחלוטין ממשאבים בחשבון אחר, אלא אם מגדירים גישה מפורשת ביניהם (למשל באמצעות IAM Roles)

Subscription ב-Azure

• מה זה? המקבילה של Account. כל המשאבים ב-Azure נוצרים תחת Subscription, והוא מהווה את גבול החיוב והניהול העיקרי.

הבדל קטן וחשוב: ב-Azure, ישנה שכבת ארגון נוספת בתוך ה-Subscription שנקראת Resource Group. כל משאב ב-Azure (מכונה וירטואלית, בסיס נתונים וכו׳) חייב להשתייך ל-Resource Group אחד בדיוק. זהו מיכל לוגי שמקל מאוד על ניהול מחזור החיים של קבוצת משאבים שקשורים זה לזה (למשל, כל המשאבים של אפליקציה מסוימת). ב-AWS אין חובה כזאת, אם כי נהוג להשתמש ב-Tags למטרה דומה.

שכבה 3: אזור גיאוגרפי (Region)

כאן אנחנו יורדים מהעולם הלוגי לעולם הפיזי.

Region ב-AWS

• מה זה? אזור גיאוגרפי מבודד בעולם המכיל מספר מרכזי נתונים. דוגמאות: us-east-1 (צפון וירג׳יניה), eu-central-1 (פרנקפורט), me-south-1 (בחריין).

• מהות הבידוד: תקלה קטסטרופלית ב-Region אחד (כמו רעידת אדמה או הפסקת חשמל אזורית) לא אמורה להשפיע על זמינות השירותים ב-Region אחר.

Region ב-Azure

• מה זה? המונח והקונספט זהים. דוגמאות: North Europe (אירלנד), Israel Central

• Region Pairs: פיצ׳ר ייחודי לאז׳ור. כמעט לכל Region ב-Azure יש ״אח תאום״ באותה טריטוריה גיאופוליטית (למשל North Europe ו-West Europe הם זוג). Azure מבצעת עדכוני פלטפורמה ותחזוקה באופן סדרתי (קודם באחד, אחר כך בשני) ואמפשרת מנגנוני התאוששות מאסון (DR) פשוטים יותר בין זוגות אלו.

שכבה 4: מתחמי דאטה סנטרים (Availability Zones - AZ)

זוהי אבן הבניין של עמידות (High Availability) בתוך אזור גיאוגרפי אחד.

• מה זה? מרכז נתונים (או קבוצה של מרכזי נתונים) בתוך Region, בעל תשתית חשמל, קירור ורשת עצמאית לחלוטין. ה-AZs בתוך אותו Region מחוברים ביניהם ברשתות מהירות עם Latency נמוך מאוד (אלפיות שנייה בודדות).

• למה זה קריטי? אם אתם רוצים שהשירות שלכם ימשיך לעבוד גם אם דאטה סנטר שלם ״עולה באש״, אתם מריצים את המשאבים שלכם (למשל, שרתי EC2 או VMs) על פני מספר AZs. אם us-east-1a נופל, התעבורה תעבור אוטומטית לשרתים שלכם ב- us-east-1b.

שכבה 5: הרשת הפרטית (VPC / VNet)

זוהי הרשת הפרטית המבודדת שלכם בענן, ה״דאטה סנטר הווירטואלי״ שלכם.

Virtual Network Cloud (VPC) ב-AWS

• מה זה? רשת לוגית מבודדת שאתם מגדירים בתוך Region ספציפי. אתם שולטים במרחב כתובת ה-IP, ב-Subnets, ב-Routing וב-Gateways.

• היקף: VPC הוא משאב שחי ברמת ה-Region, אבל הוא יכול (וצריך) להשתרע על פני מספר Availability Zones שונים בתוך אותו Region.

Virtual Network (VNet) ב-Azure

• מה זה? המקבילה הזהה כמעט לחלוטין ל-VPC. רשת וירטואלית פרטית ומבודדת בתוך ה-Region, שבה אתם מגדירים את ה-Subnets וכללי התעבורה

• היקף: בדיוק כמו VPC, גם VNet הוא משאב אזורי (Region) שיכול להכיל Subnets מ-AZs שונים באותו ה-Region.

שכבה 6: מקטע רשת (Subnet)

החלוקה הפנימית של הרשת שלכם, הקושרת בין הרשת הלוגית למיקום הפיזי.

• מה זה? מקטע (טווח כתובות IP) מתוך ה VPC/VNet שלכם.

• החוק הכי חשוב: כל Subnet משויך ל-AZ אחד בלבד. זוהי הנקודה שבה ההיררכיה מתחברת. כשאתם מציבים משאב (כמו מכונת EC2) בתוך Subnet מסוים, אתם בעצם קובעים באיזה AZ פיזי הוא ירוץ.

• דוגמה קלאסית: מגדירים Public Subnet (עם גישה לאינטרנט דרך Internet Gateway) עבור שרתי ה-Web, ו-Private Subnet (ללא גישה ישירה מהאינטרנט) עבור בסיסי הנתונים. כדי להשיג HA, יוצרים זוג כזה של Subnets בכל AZ שבו רוצים לפעול.

שכבה 7: המשאב (Resource)

היחידה האטומית, הסיבה שלשמה התכנסנו.

• מה זה? מכונת EC2/VM, בסיס נתונים של RDS, חשבון S3, פונקציית למבדה וכו׳.

• המיקום שלו: כל משאב בעל הקשר רשתי ״נשתל״ בתוך Subnet, וכך מיקומו נקבע: הוא נמצא ב- Subnet X, ששייך ל-AZ Y, שחלק מ- VPC/VNet Z ב- Region W, תחת Account/Subscription V המנוהל על ידי Organization/Management Group U.

---

טבלה מסכמת: AWS vs. Azure

---

הערות חשובות מהשטח

• עלות תעבורה בין AZs: גם ב-AWS וגם ב-Azure, תעבורה בתוך AZ יחיד היא לרוב בחינם. תעבורה בין AZs באותו Region עולה כסף (בדרך כלל 0.01$ לכל GB). ארכיטקטורה ״פטפטנית״ מדי בין AZs יכולה לייצר חשבון לא צפוי.

• לא כל Region של Azure תומך ב-AZs: זה נשמע מוזר, אבל ישנם עדדין Regions ותיקים ב-Azure שאין להם תמיכה ב-Availability Zones. אם High Availability היא דרישה קריטית, ודאו שאתם בוחרים Region שתומך בכך.

• המיפוי של שמות ה-AZs ב-AWS: אם בחשבון ה-AWS שלכם אתם עובדים עם AZ בשם us-east-1a, ובחשבון אחר שלכם מופיע אותו השם בדיוק - אין שום ערובה שמדובר באותו מרכז נתונים פיזי. אמזון מבצעת מיפוי אקראי של האותיות (a, b, c ...) לכל חשבון בנפרד כדי לפזר עומסים בצורה טובה יותר. הפתרון הוא להשתמש תמיד ב-AZ ID (לדוגמה use1-az1). המזהה הזה הוא קבוע בין כל החשבונות ותמיד יצביע על אותו מתקן פיזי. ב-Azure בעיה זו לא קיימת, השמות (1, 2, 3) הם עקביים.

• תכנון ל-DR: הקונספט של Region Paris ב-Azure מפשט תרחישי התאוששות מאסון (Disaster Recovery). ב-AWS, תצטרכו לבנות לוגיקה דומה בעצמכם על ידי בחירת Region מתאים לגיבוי.

---

סיכום והצעדים הבאים

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

• באיזה Region אני צריך להיות כדי להיות קרוב למשתמשים ולעמוד ברגולציה?

• על פני כמה AZs אני צריך לפזר את השירות כדי להבטיח עמידות?

• האם המשאב הזה צריך להיות ב-Subet ציבורי או פרטי?

• באיזה Account/Subscription ו-Resource Group המשאב הזה צריך לחיות כדי שהניהול והחיוב יהיו נכונים?

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

רוצים להעמיק?

• AWS Infrastructure

• Azure Global Infrastructure

• Azure Reliability

• AWS Well-Architected Framework