Azure למהנדסי AWS: כיצד האינסטינקטים שלך מ-AWS מתורגמים (והיכן הם נשברים)

אם אתה שולט היטב ב-AWS וכעת מביט ב-Azure, החדשות הטובות הן שכ-80% מהאינסטינקטים שלך עוברים באופן ישיר: קיימת היררכיה לארגון דברים, דרך מבוססת תפקידים למתן גישה, סיפור OIDC עבור CI ללא מפתחות, וריקוד אתחול של "הפעלת ה-backend של המצב שלך מ'אפס'". החדשות הרעות הן 20% הנותרים — והם מרוכזים בכמה נקודות עמוסות תעבורה שבהן עשיית הדבר ה-AWSי מייצרת סירוב מבלבל במקום שגיאה ברורה. פוסט זה הוא שכבת התרגום: אותן משימות שאתה עושה ב-AWS, מבוצעות ב-Azure, עם הקריאה למלכודות.

הגרסה הקצרה, אם תקרא רק פסקה אחת: ל-AWS יש למעשה מישור הרשאות אחד (IAM), ל-Azure יש שלושה שאינם מתקשרים זה עם זה; חשבונות AWS הם מנויי Azure אך החיוב מתקיים במקום אחר לחלוטין; ו-Azure מוסיפה מיכל חובה (resource group) של-AWS אין מקבילה אמיתית עבורו. כל מה שלמטה מרחיב את אלה.

השינוי הגדול ביותר: מישור הרשאות אחד הופך לשלושה

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

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

הכלל שיציל אותך: כאשר Azure מסרבת למשהו ש"אמור" לעבוד, שאל קודם כל "לאיזה מישור אני מדבר?" — ואז בדוק את התפקידים של אותו מישור. רוב הסירובים המסתוריים (לא יכול לקרוא מנוי, לא יכול לרשום management groups, לא יכול לראות חיובים) אינם הרשאה חסרה בתוך מישור — אלא אתה מדבר למישור הלא נכון לחלוטין.

מישור 1 — תפקידי Entra ID directory (זהות)

מישור זה מנהל אובייקטי directory: משתמשים, קבוצות, service principals / app registrations, ‏Conditional Access, מדיניות MFA, רישיונות. הוא אינו מנהל את המשאבים שאתה פורס.

• תפקידים כאן הם דברים כמו Global Administrator, User Administrator, Application Administrator. הם מוקצים ומוערכים ב-Entra ID ומוצגים באמצעות ה-Microsoft Graph API.
• Global Administrator הוא אל של directory, לא אל של משאבים. זה מכשיל את כולם: Global Admin יכול לנהל באושר כל משתמש ואפליקציה בארגון ועדיין לקבל כשל אימות בניסיון אפילו לקרוא מנוי. האנלוגיה הקרובה ביותר ל-AWS היא "האדם שמנהל את IAM Identity Center ואת ה-directory עצמו" — אבל היא לא מושלמת, בדיוק מכיוון ש-AWS מאחדת ניהול directory עם הרשאת משאבים ו-Azure מסרבת לכך.

מישור 2 — Azure RBAC (משאבים)

זהו המישור שבו תחיה, וזה שה-Terraform provider ‏azurerm מניע. הוא מנהל כל דבר שאתה פורס: מכונות וירטואליות (VMs), רשתות וירטואליות, אחסון, AKS, וכדומה.

• הענקה היא שלישייה: (principal, role definition, scope), כאשר scope הוא צומת בשרשרת root → management group → subscription → resource group → resource, והיא יורשת כלפי מטה. תפקידים מובנים הם Owner, Contributor, Reader, בתוספת כל הגדרות תפקיד מותאמות אישית שאתה כותב.
• הנה המלכודת עבור מוחות של AWS: אין מדיניות המצורפת לזהות. ב-AWS אתה מצרף מדיניות למשתמש או תפקיד וההרשאה עוברת עם הזהות. ב-Azure, מודל של role-at-a-scope הוא המודל היחיד. הצורה המנטלית הקרובה ביותר ל-AWS היא "מדיניות IAM המצורפת ל-Organizations OU" — ההענקה חיה על צומת העץ, לא על ה-principal.
• הגשר המאושר היחיד בין מישורים 1 ו-2 הוא מהלך שבירת-זכוכית מכוון: Global Administrator יכול להחליף את "Access management for Azure resources" (פעולת elevateAccess) כדי להעניק לעצמו User Access Administrator ב-root scope. זה רועש, הפיך, ולא ברירת מחדל — אתה משתמש בזה פעם אחת במהלך האתחול כדי להקצות לעצמך Owner ב-tenant root, שבעקבות כך יורש לכל מנוי.

מישור 3 — חיוב / מסחר (כסף)

מישור זה מנהל חשבונות חיוב, פרופילי חיוב, קטעי חשבוניות, אמצעי תשלום — ובאופן קריטי, יצירת מנויים.

• יש לו סט תפקידים משלו (Billing account owner, Billing profile owner, Azure subscription creator, …), המוענקים בתוך חשבון החיוב ומאוחסנים במערכת החיוב. תפקידים אלה אינם מופיעים ב-az role assignment list או בלהבי התפקידים של Entra. הם עולם נפרד לחלוטין.
• אתה יכול להיתקל בקיר הזה משני הכיוונים. זכויות זהות + משאבים מקסימליות (Global Admin + User Access Administrator ב-root + Owner ב-root management group) עדיין יניבו לך רשימה ריקה מ-az billing account list וללא יכולת ליצור מנוי. לעומת זאת, בעל חיוב יכול להעניק זכויות חיוב בלחיצה אחת.
• החלק הערמומי ביותר: החיוב מוגש באמצעות כתובות URL של REST הנראות כמו ARM (Microsoft.Billing/...), כך שזה נראה כמו מישור המשאבים — אבל האימות מוערך מול תפקידי חיוב. אותה דלת, שומר סף אחר.

תוצאה קונקרטית ש-AWS מעולם לא מכריחה אותך לחשוב עליה: האם אתה יכול ליצור מנויים באופן פרוגרמטי בכלל תלוי בסוג הסכם החיוב שלך. חשבונות pay-as-you-go / web-direct מדור קודם יכולים ליצור מנויים ידנית בלבד בפורטל, על ידי הזהות המקורית של ההרשמה — בעלות זו אינה ניתנת להענקה כלל. הסכם הלקוח המודרני תומך ב-API ליצירת מנויים (עם מכסות קמעונאיות על חשבונות בשירות עצמי — קומץ מנויים בסך הכל, ומגבלת קצב ליום), והסכמי ארגוניים/שותפים מרימים את המכסות. ב-AWS, ‏CreateAccount פשוט עובד מחשבון הניהול; ב-Azure, "האם אני יכול ליצור חשבון זה עם קוד?" היא שאלה במישור החיוב שאתה צריך לענות עליה קודם. זו הסיבה שאחוזות Azure רבות מתייחסות למנויים כאל מיובאים ל-Terraform, ולא נוצרים על ידו לעולם.

כיצד המישורים מצטלבים בפועל

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

• יצירת משתמש, קבוצה או app registration ← Entra בלבד.
• פריסת VM / VNet / storage account ← משאבים (Azure RBAC) בלבד.
• יצירת מנוי ← billing יוצר אותו, הוא משתכן ב-Entra tenant, והוא הופך ל-Azure RBAC scope. שלושה מישורים לפעולה אחת.
• ייצוא directory audit logs ל-Log Analytics workspace ← Entra (מקור) בתוספת משאבים (יעד).
• Terraform azurerm לעומת azuread ← ה-resource API לעומת ה-Graph API — נקודות קצה שונות, קהלי אסימונים שונים.

הנקודה האחרונה הזו נושאת נגיסה תפעולית אמיתית: כניסה בודדת מייצרת אסימונים נפרדים לכל קהל (אחד עבור מנהל המשאבים, אחד עבור Graph, אחד עבור Key Vault). אסימון שנוצר עבור API של מישור אחד חסר ערך באחר. אם הכלים שלך תופסים רק אחד, מחצית מה-Terraform שלך יקבל באופן מסתורי 401.

"Entra ID", "tenant", ו-"directory" הם (לרוב) אותו הדבר

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

• Entra ID הוא ה-מוצר — שירות הזהויות. עד 2023 הוא היה Azure Active Directory (Azure AD / AAD), והשם הישן נמצא בכל מקום: ה-Terraform provider ‏azuread, קודי שגיאה AADSTS…, "AAD auth" בתיעוד. אותו הדבר.
• tenant הוא המופע הייעודי של הארגון שלך ל-Entra ID — המיכל וגבול האמון/בידוד, המזוהה על ידי GUID ודומיין ראשי. משתמשים, קבוצות, אפליקציות, Conditional Access ורישיונות חיים כולם לכל tenant ואינם חוצים tenants.
• directory הוא התוכן של tenant — מסד הנתונים של אובייקטי זהות. tenant אחד שווה ל-directory אחד, ולכן אנשים משתמשים במילים באופן חופף; כפתור "Switch directory" בפורטל למעשה מחליף tenants.

הכללים הבאים הם המקום שבו האנלוגיה ל-AWS הופכת רופפת:

1. מנוי משתכן ב-tenant אחד בדיוק. אותו tenant הוא תחום האימות שלו ומספק את ה-principals של ה-RBAC שלו. (מנויים ניתנים להעברה בין tenants; חיוב הוא אסוציאציה נפרדת.)
2. ארגון אחד יכול להחזיק ב-tenants רבים. דפוס נפוץ הוא tenant ייצור נעול בתוספת tenant sandbox מבודד לחלוטין — עולמות זהות נפרדים שבהם שום דבר שאתה עושה באחד לא יכול לגעת באחר. אין מקבילה ב-AWS ל"יקום זהויות שני, נפרד לחלוטין תחת אותה חברה."
3. למשתמשים יש tenant ביתי אחד ויכולים להיות אורחים (B2B) elsewhere. אורח מקבל ID אובייקט מקומי ב-guest tenant תוך שמירה על זהות ה-בית שלו. ל-AWS אין מושג מדרגה ראשונה של "משתמש אורח מ-directory של ארגון אחר".

האנלוגיה הרופפת ביותר ב-AWS: tenant הוא בערך "AWS Organization הממוזג עם ה-Identity Center directory שלו" — אלא שמנויים מתחברים ל-tenant רק לצורך זהות, בעוד תשלום מתחבר לחשבון חיוב, ואורחים חוצי ארגון הם מושג מקורי.

Resource groups: המיכל שאין ל-AWS

resource group (RG) הוא מיכל חובה בתוך מנוי — כל משאב בודד חי בדיוק באחד. זהו החלק שאין לו מקבילה ב-AWS (‏"resource groups" ב-AWS הם רק שאילתות תגים שמורות; התעלם מהתנגשות השמות).

RG הוא ארבעה דברים בו זמנית:

• RBAC scope — הענק Reader על RG אחד והגבלת גישה בדיוק ל-workload הזה.
• policy scope — צרף כללי ממשל ברמת ה-RG.
• lifecycle unit — מחק את ה-RG וכל מה שבתוכו נמחק איתו.
• cost boundary — פריט שורה טבעי עבור הוצאות.

התבנית האידיומטית היא RG אחד לכל workload (לעתים קרובות לכל region), כך ש-RG הופך ל"תיקיה עבור אפליקציה זו ב-region זה". ל-RG יש location, אך זה רק אומר היכן ה-metadata שלו נמצא — המשאבים שלו יכולים לשבת ב-regions אחרים, לכן אל תתמקד יתר על המידה ב-RG location.

Resource IDs נושאים קונטקסט, ולכן שמות לא חייבים

לכל משאב Azure יש Resource ID מלא כמו /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/containerApps/<name>. ה-subscription וה-RG עוברים עם כל רשומת לוג, אירוע ביקורת, וקריאת API — אותה עבודה ש-account ו-region של ARN עושים ב-AWS.

תוצאת מתן השמות היא ההפך מההרגל שלך ב-AWS. ב-AWS השם הוא לרוב ה-קונטקסט היחיד שאתה מקבל, ולכן אתה דוחס הכל לתוכו. ב-Azure, שמות צריכים להשמיט את מה שה-scope כבר מקודד: cluster בשם aks-quest בתוך rg-quest בתוך מנוי qa כבר מפורש באופן מלא, ואותם שמות RG/משאב יכולים לחזור בבטחה על פני מנויי dev/qa/prod. רק סוגי משאבים גלובליים ייחודיים (storage accounts, container registries, Key Vaults) מכריחים org/env/region בחזרה לשם — ואלה מגיעים עם מגבלות אורך ותווים קפדניות, ולכן אתה רואה שמות מכווצים כמו stcwtfstateplatformcus.

(סיומת cus זו אינה מומצאת, אגב — זהו קוד הגיאוגרפיה של מיקרוסופט עבור Central US, מאותה טבלה רשמית שבה Azure משתמשת לבניית private-endpoint DNS zones. eus/eus2 הם East US ו-East US 2. לימוד טבלת קודי הגיאוגרפיה מוקדם משתלם.)

המפה המהירה של AWS → Azure

שמור את זה לידך בחודש הראשון:

• Organization ← Entra tenant בתוספת management groups. זהות (ה-tenant) ומבנה (management groups) הם דברים נפרדים ב-Azure, לא אחד.
• Account ← subscription. משתכן ב-tenant עבור זהות; מחויב על ידי חשבון חיוב נפרד.
• SCP (guardrail) ← Azure Policy ב-management-group scope — עם השפעות עשירות יותר מאשר deny-only (audit, deny, modify, deployIfNotExists).
• IAM role/policy ← RBAC role assignment — ‏(principal, role, scope). זכור: אין מדיניות המצורפת לזהות.
• Root-account superpowers ← מפוצל לשלושה: Global Admin (זהות) + elevateAccess (משאבים) + billing owner (כסף). אין principal יחיד שמתחיל עם שלושתם.
• Organizations CreateAccount ← ה-subscription aliases API + billing scope — ורק בסוגי הסכמי חיוב המאפשרים זאת.
• IRSA (IAM Roles for Service Accounts) ← workload identity federation — אותו רעיון של OIDC.
• Tag-based grouping ← ה-resource group — מבני וחובה, לא שאילתת תגים.
• ARN ביומנים ← ה-Resource ID (עמודת _ResourceId) — הקשר ה-scope מובנה, לא מקודד בשם.

אתחול מצב Terraform, מתורגם

הנה מקום שבו ה-runbook שלך ב-AWS כמעט עובד, ואז נשבר בשלב האפס.

אתחול ה-AWS שאתה מכיר: הפעלת backend של מצב "מקרקעית" (cold-start) בחשבון הניהול (מצב מקומי, ואז העברת ה-backend לתוכו), שמירת מצב ה-backends לכל OU באותו backend שורש, ויצירת חשבונות חברים באמצעות ה-backends שלהם. הקבוע שגורם לכך להיות נקי הוא שאתה תמיד יכול לבצע אתחול מחשבון השורש, מכיוון שהוא תמיד קיים ויכול להחזיק S3 bucket.

Azure שוברת את הקבוע הזה מהיווצרות. האובייקט שתמיד קיים הוא ה-tenant — אבל tenant לא יכול להחזיק משאבים. storage accounts חיים במנויים, ומנויים נולדים ממישור החיוב. לכן "חשבון השורש" של Azure הוא כל מנוי שתמנה כשורש, ואתה צריך למנות אחד באופן מודע. בפועל, רוב ה-tenants מקבלים מנוי אחד בהרשמה, כך שהמקבילה לרוב נשמרת: AWS נותנת לך management account, ‏Azure נותנת לך מנוי ראשון.

הזרימה המתורגמת, כאשר מנויים כבר קיימים (המקרה הנפוץ):

1. אתחול "מקרקעית" אחד, פעם אחת: פרוס את ה-state backend לתוך ה-subscription ה-ראשי הייעודי שלך עם state מקומי, ואז init -migrate-state לתוכו.
2. backends לכל subscription, מצב מאוחסן ב-backend הראשי: רכיב ה-backend של כל subscription נוסף מצמיד את ה-state שלו ל-backend הראשי, כך שהקמתם היא apply רגיל — אין יותר cold-starts.
3. כל דבר אחר בכל subscription משתמש ב-backend משלו של אותו subscription.

מאפס מוחלט (יצירת מנויים באמצעות קוד), הסדר נכפה — subscription ראשי ראשון, backend ראשי שני — מכיוון ש-backend הוא storage account ו-storage account זקוק ל-subscription כדי לחיות בו. שימו לב לקמט אחד של "ביצה ותרנגולת": ה-provider ‏azurerm עצמו דורש subscription context, כך שעם אפס מנויים אתה יוצר את ה-subscription הראשון הזה בקריאה אימפרטיבית (ה-CLI או ה-provider ‏azapi), ואז מייבא אותו ל-Terraform לאחר מכן.

והנה המקום שבו Azure באמת פשוטה יותר מזיכרון השריר של AWS: backend ב-root בתוספת משאבים בחבר לא דורש אף אחד ממנגנוני האמון של AWS מסוג hub-and-spoke — אין role_arn של backend, אין assume_role של provider, אין מדיניות אמון דו-צדדית. Owner ב-management group הראשי של ה-tenant יורש לכל subscription, כך שאסימון אחד עובד בכל ה-tenant; ה-provider "קופץ" בין subscriptions על ידי הגדרת subscription_id פשוטה; וה-backend הוא פשוט גישת blob במישור הנתונים המאושרת על ידי הענקת Storage Blob Data Contributor. חציית subscriptions היא פרמטר, לא משא ומתן על אמון. (תחמיר את זה בהמשך עם custom roles, ‏PIM, וזהויות CI ייעודיות — אבל גם אז מדובר ב-role assignments ב-scopes, לעולם לא ב-handshake של trust-policy.) אם אתה רוצה להעמיק בקידוד אחד מהצדדים, הבחינה HashiCorp Terraform Authoring & Operations Pro בנויה סביב דפוסי state ו-provider אלה בדיוק.

ארבעת המקומות שבהם האינסטינקטים שלך מ-AWS יטרידו אותך באופן פעיל

אם תשכח הכל, זכור את אלה:

1. "אדמין" אינו גלובלי. Global Administrator הוא רק זהותי; הוא לא יכול לקרוא מנוי עד שמישהו יעניק לו תפקיד משאב. אין principal "שורש" יחיד.
2. הרשאות נצמדות ל-scopes, לא לזהויות. הפסק לחפש את המדיניות על המשתמש — חפש את ה-role assignment על ה-management group, subscription, resource group, או resource.
3. חיוב הוא יקום נפרד ממשאבים. "אני יכול לפרוס כל דבר" לא אומר לך כלום על "אני יכול ליצור מנוי". מישור שונה, תפקידים שונים, בלתי נראה ל-az role assignment list.
4. ה-resource group נושא משקל. זה לא תג — זהו RBAC scope, policy scope, ו-delete boundary. תכנן את פריסת ה-RG שלך בכוונה.

אילו הסמכות מתרגלות כל צד

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

בצד של AWS (הידע שאתה מתרגם ממנו):

• AWS Certified Cloud Practitioner (CLF-C02) — יסודות החשבונות, IAM ו-Organizations.
• AWS Certified Solutions Architect – Associate (SAA-C03) — IAM, מבנה ריבוי חשבונות וארכיטקטורת ליבה.
• AWS Certified Solutions Architect – Professional (SAP-C02) — Organizations מרובי חשבונות, SCPs וגישה בין חשבונות בקנה מידה.
• AWS Certified Security – Specialty (SCS-C03) — עומק IAM, ‏SCPs וניהול מפתחות.

בצד של Azure (הידע שאתה מתרגם אליו):

• Microsoft Certified: Azure Fundamentals (AZ-900) — tenants, subscriptions, resource groups ויסודות ה-RBAC.
• Microsoft Certified: Azure Administrator Associate (AZ-104) — המישור היומיומי: RBAC, resource groups, subscriptions ויסודות Entra.
• Microsoft Certified: Azure Solutions Architect Expert (AZ-305) — management groups, ממשל ועיצוב landing-zone.
• Microsoft Certified: Azure Security Engineer Associate (AZ-500) — Entra ID, ‏RBAC, ‏Azure Policy, ‏Conditional Access ו-Key Vault.

נתיב פרגמטי אם אתה מוסמך AWS היום: התחל ב-AZ-900 כדי למפות את אוצר המילים, ואז קפוץ ל-AZ-104 (שחי במישור המשאבים שבו תשתמש הכי הרבה), והוסף AZ-305 או AZ-500 בהתאם לשאלה אם עבודתך נוטה לארכיטקטורה או לאבטחה.

השורה התחתונה

Azure אינו קשה יותר מ-AWS — הוא מחולק באופן שונה. AWS מאחדת את סמכות הזהות, המשאבים והחיוב למישור אחד ומעניקה לך management account שיכול לעשות הכל. Azure מפרידה בין שלושת הדברים האלה בכוונה, מה שמרגיש כמו חיכוך ביום הראשון וכמו גבולות נקיים עד לחודש השלישי. תרגם את המושגים פעם אחת — מישור אחד הופך לשלושה, חשבונות הופכים למנויים המחויבים במקום אחר, מדיניות נצמדת ל-scopes במקום לזהויות, וה-resource group הוא מבנה אמיתי — והשאר הוא אוצר מילים. תרגל זאת עם ההסמכות שלעיל, והחלקים שהרגישו כמו סירובים שרירותיים יתחילו להיקרא כעיצוב קוהרנטי ומכוון.