AWS इंजीनियरों के लिए Azure: आपके AWS सिद्धांत कैसे लागू होते हैं (और कहाँ विफल होते हैं)

यदि आप AWS में पारंगत हैं और अब Azure की ओर देख रहे हैं, तो अच्छी खबर यह है कि आपकी लगभग 80% आदतें सीधे स्थानांतरित हो जाती हैं: चीजों को व्यवस्थित करने के लिए एक पदानुक्रम है, एक्सेस देने का एक रोल-आधारित तरीका है, कीलेस CI के लिए एक OIDC कहानी है, और "आपकी स्टेट बैकएंड को कोल्ड-स्टार्ट" करने का एक बूटस्ट्रैप तरीका है। बुरी खबर अन्य 20% है — और यह कुछ ऐसे उच्च-ट्रैफिक स्थानों पर केंद्रित है जहाँ AWS वाला काम करने से स्पष्ट त्रुटि के बजाय भ्रमित करने वाला डिनायल मिलता है। यह पोस्ट अनुवाद परत है: वही काम जो आप AWS में करते हैं, Azure में किए गए, जिसमें आने वाली बाधाओं को बताया गया है।

संक्षिप्त संस्करण, यदि आप केवल एक पैराग्राफ पढ़ते हैं: AWS में अनिवार्य रूप से एक ही परमिशन प्लेन (IAM) है, Azure में तीन हैं जो आपस में बात नहीं करते; AWS अकाउंट्स Azure subscriptions हैं लेकिन बिलिंग पूरी तरह से कहीं और रहती है; और Azure एक अनिवार्य कंटेनर (resource group) जोड़ता है जिसका AWS में कोई वास्तविक समकक्ष नहीं है। नीचे सब कुछ इन्हीं को विस्तृत करता है।

सबसे बड़ा बदलाव: एक परमिशन प्लेन तीन हो जाते हैं

AWS में, IAM प्रभावी रूप से पूरी कहानी है। एक सेवा यह नियंत्रित करती है कि आपकी पहचान कौन हैं, वे रिसोर्सेज के साथ क्या कर सकते हैं, और — Organizations के माध्यम से — अकाउंट्स कैसे बनाए और समूहित किए जाते हैं। परमिशनें इस तरह से आपस में घुल-मिल जाती हैं कि शायद आप उनके चले जाने तक ध्यान भी नहीं देते।

Azure जानबूझकर उस एकल प्लेन को तीन अलग-अलग प्लेनों में विभाजित करता है, जिसमें तीन रोल सिस्टम, तीन ग्रांट मैकेनिज्म और लगभग कोई स्वचालित ब्लीड-थ्रू नहीं होता है। एक प्लेन में सर्वशक्तिमान होने से आपको दूसरों में कुछ भी नहीं मिलता है। यह आत्मसात करने वाली सबसे महत्वपूर्ण बात है, क्योंकि यह लगभग हर "लेकिन मैं एक एडमिन हूँ, यह क्यों डिनाई किया गया?" क्षण का स्रोत है।

जो नियम आपको बचाता है: जब Azure किसी ऐसी चीज़ को डिनाई करता है जो "काम" करनी चाहिए, तो पहले पूछें "मैं किस प्लेन से बात कर रहा हूँ?" — फिर उस प्लेन के रोल जांचें। अधिकांश रहस्यमय डिनायल (subscription पढ़ नहीं सकता, management groups लिस्ट नहीं कर सकता, billing देख नहीं सकता) किसी प्लेन के भीतर एक लापता परमिशन नहीं होते — वे पूरी तरह से गलत प्लेन से बात करने के कारण होते हैं।

प्लेन 1 — Entra ID directory roles (पहचान)

यह प्लेन directory objects को नियंत्रित करता है: users, groups, service principals / app registrations, Conditional Access, MFA policy, licenses। यह आपके द्वारा डिप्लॉय किए गए रिसोर्सेज को नियंत्रित नहीं करता है।

• यहाँ के रोल Global Administrator, User Administrator, Application Administrator जैसे होते हैं। इन्हें Entra ID में असाइन और मूल्यांकित किया जाता है और Microsoft Graph API के माध्यम से सामने लाया जाता है।
• Global Administrator एक directory god है, न कि resource god। यह हर किसी को भ्रमित करता है: एक Global Admin संगठन में हर user और app को खुशी-खुशी मैनेज कर सकता है और फिर भी केवल एक subscription को पढ़ने का प्रयास करते समय एक ऑथराइजेशन विफलता प्राप्त कर सकता है। सबसे करीबी AWS सादृश्य "वह व्यक्ति जो IAM Identity Center और स्वयं directory का प्रशासन करता है" है — लेकिन यह अपूर्ण है, ठीक इसी कारण से कि AWS directory administration को resource authorization के साथ जोड़ता है और Azure ऐसा करने से मना करता है।

प्लेन 2 — Azure RBAC (रिसोर्सेज)

यह वह प्लेन है जिसमें आप काम करेंगे, और यही वह है जिसे azurerm Terraform provider चलाता है। यह आपके द्वारा डिप्लॉय किए जाने वाले हर चीज को नियंत्रित करता है: VMs, virtual networks, storage, AKS, और इसी तरह।

• एक ग्रांट एक ट्रिपल होता है: (principal, role definition, scope), जहाँ scope चेन root → management group → subscription → resource group → resource में एक नोड है, और यह नीचे की ओर इनहेरिट होता है। बिल्ट-इन रोल Owner, Contributor, Reader हैं, साथ ही आपके द्वारा लिखी गई कोई भी कस्टम role definition।
• AWS दिमाग वालों के लिए यहाँ एक जाल है: कोई identity-attached policies नहीं होतीं। AWS में आप एक policy किसी user या role से अटैच करते हैं और परमिशन identity के साथ यात्रा करती है। Azure में, role-at-a-scope एकमात्र मॉडल है। सबसे करीबी AWS मानसिक आकार "एक IAM policy जो Organizations OU से अटैच है" है — ग्रांट ट्री नोड पर रहती है, principal पर नहीं।
• प्लेन 1 और 2 के बीच एक स्वीकृत पुल एक जानबूझकर break-glass कदम है: एक Global Administrator "Access management for Azure resources" (elevateAccess ऑपरेशन) को टॉगल करके खुद को User Access Administrator at the root scope प्रदान कर सकता है। यह स्पष्ट, प्रतिवर्ती और डिफॉल्ट नहीं है — आप इसे बूटस्ट्रैप के दौरान एक बार उपयोग करते हैं ताकि खुद को tenant root पर Owner असाइन कर सकें, जो बाद में हर subscription में इनहेरिट हो जाता है।

प्लेन 3 — बिलिंग / कॉमर्स (पैसा)

यह प्लेन billing accounts, billing profiles, invoice sections, payment methods — और, महत्वपूर्ण रूप से, subscription creation को नियंत्रित करता है।

• इसके अपने रोल सेट हैं (Billing account owner, Billing profile owner, Azure subscription creator, …), जो billing account के अंदर प्रदान किए जाते हैं और billing system में संग्रहीत होते हैं। ये रोल az role assignment list या Entra role blades में दिखाई नहीं देते। वे पूरी तरह से एक अलग दुनिया हैं।
• आप दोनों दिशाओं से इस बाधा का सामना कर सकते हैं। अधिकतम identity + resource rights (Global Admin + User Access Administrator at root + Owner at the root management group) होने पर भी आपको az billing account list से एक खाली सूची मिलेगी और subscription बनाने की कोई क्षमता नहीं होगी। इसके विपरीत, एक billing owner एक क्लिक से billing rights प्रदान कर सकता है।
• सबसे मुश्किल हिस्सा: बिलिंग ARM-जैसे REST URLs (Microsoft.Billing/...) के माध्यम से सेवा दी जाती है, इसलिए यह resource plane जैसा दिखता है — लेकिन ऑथराइजेशन billing roles के विरुद्ध मूल्यांकित होता है। दरवाज़ा एक ही है, बाउंसर्स अलग।

एक ठोस परिणाम जिसके बारे में AWS आपको कभी सोचने पर मजबूर नहीं करता: क्या आप प्रोग्रामेटिक रूप से subscriptions बना सकते हैं, यह पूरी तरह से आपके billing agreement type पर निर्भर करता है। लेगेसी pay-as-you-go / web-direct अकाउंट्स केवल पोर्टल में मैन्युअल रूप से, मूल साइनअप identity द्वारा subscriptions बना सकते हैं — वह ओनरशिप भी ग्रांटेबल नहीं है। आधुनिक Customer Agreement एक subscription-creation API का समर्थन करता है (self-serve अकाउंट्स पर रिटेल कैप के साथ — कुल कुछ ही subscriptions, और प्रति दिन एक रेट लिमिट), और enterprise/partner एग्रीमेंट्स कैप को हटा देते हैं। AWS में, CreateAccount management account से बस काम करता है; Azure में, "क्या मैं इस अकाउंट को कोड के साथ बना सकता हूँ?" एक billing-plane सवाल है जिसका जवाब आपको पहले देना होगा। इसीलिए कई Azure एस्टेट्स subscriptions को Terraform में इम्पोर्टेड मानते हैं, कभी इसके द्वारा बनाया गया नहीं।

व्यवहार में प्लेन कैसे प्रतिच्छेद करते हैं

अधिकांश कार्य केवल एक प्लेन को छूते हैं, और कुछ कई को फैलाते हैं — यही कारण है कि विभाजन मायने रखता है:

• एक user, group, या app registration बनाएँ → केवल Entra।
• एक VM / VNet / storage account डिप्लॉय करें → केवल resources (Azure RBAC)।
• एक subscription बनाएँ → billing इसे बनाता है, यह एक Entra tenant में होम होता है, और यह एक Azure RBAC scope बन जाता है। एक कार्रवाई के लिए तीन प्लेन।
• directory audit logs को एक Log Analytics workspace में निर्यात करें → Entra (स्रोत) प्लस resources (गंतव्य)।
• Terraform azurerm बनाम azuread → resource API बनाम Graph API — विभिन्न एंडपॉइंट्स, विभिन्न token audiences।

उस अंतिम बिंदु का एक वास्तविक परिचालन प्रभाव है: एक सिंगल लॉगिन प्रति audience अलग-अलग token बनाता है (एक resource manager के लिए, एक Graph के लिए, एक Key Vault के लिए)। एक प्लेन के API के लिए बनाया गया token दूसरे के लिए बेकार है। यदि आपकी टूलिंग केवल एक को पकड़ती है, तो आपका आधा Terraform रहस्यमय ढंग से 401 हो जाएगा।

"Entra ID," "tenant," और "directory" (ज्यादातर) एक ही चीज़ हैं

विभिन्न कोणों से देखी गई एक वस्तु के लिए तीन शब्द, साथ ही आपको भ्रमित करने के लिए एक नाम परिवर्तन:

• Entra ID उत्पाद है — identity service। 2023 तक यह Azure Active Directory (Azure AD / AAD) था, और पुराना नाम हर जगह है: azuread Terraform provider, AADSTS… एरर कोड, docs में "AAD auth"। वही चीज़।
• एक tenant Entra ID का आपके संगठन का समर्पित इंस्टेंस है — कंटेनर और trust/isolation बाउंड्री, एक GUID और एक primary domain द्वारा पहचाना जाता है। Users, groups, apps, Conditional Access, और licenses सभी प्रति tenant रहते हैं और tenants को पार नहीं करते।
• directory एक tenant की सामग्री है — identity objects का डेटाबेस। एक tenant एक directory के बराबर होता है, इसलिए लोग शब्दों का परस्पर उपयोग करते हैं; पोर्टल का "Switch directory" बटन वास्तव में tenants को स्विच करता है।

निम्नलिखित नियम हैं जहाँ AWS सादृश्य ढीला पड़ जाता है:

1. एक subscription ठीक एक tenant में होम होता है। वह tenant उसका ऑथेंटिकेशन realm है और उसके RBAC principals की आपूर्ति करता है। (Subscriptions को tenants के बीच स्थानांतरित किया जा सकता है; billing एक अलग एसोसिएशन है।)
2. एक संगठन कई tenants का मालिक हो सकता है। एक सामान्य पैटर्न एक लॉक-डाउन production tenant प्लस एक पूरी तरह से अलग sandbox tenant है — अलग-अलग identity worlds जहाँ आप एक में जो भी करते हैं वह दूसरे को छू नहीं सकता। "एक ही कंपनी के तहत एक दूसरा, पूरी तरह से अलग identity universe" का AWS में कोई समकक्ष नहीं है।
3. Users का एक home tenant होता है और वे कहीं और guests (B2B) हो सकते हैं। एक guest को guest tenant में एक लोकल object ID मिलती है, जबकि वे अपनी home identity रखते हैं। AWS में "किसी अन्य संगठन की directory से एक guest user" की कोई प्रथम-श्रेणी की धारणा नहीं है।

सबसे ढीला AWS सादृश्य: एक tenant मोटे तौर पर "एक AWS Organization है जो अपने Identity Center directory के साथ जुड़ा हुआ है" — सिवाय इसके कि subscriptions केवल identity के लिए एक tenant से जुड़ते हैं, जबकि payment एक billing account से जुड़ता है, और cross-org guests एक native अवधारणा हैं।

Resource groups: वह कंटेनर जो AWS में नहीं है

एक resource group (RG) एक subscription के अंदर एक अनिवार्य कंटेनर है — प्रत्येक एकल resource ठीक एक में रहता है। यह वह हिस्सा है जिसका AWS में कोई समकक्ष नहीं है (AWS "resource groups" केवल सहेजी गई tag queries हैं; नाम के टकराव को अनदेखा करें)।

एक RG एक साथ चार चीजें है:

• एक RBAC scope — एक RG पर Reader ग्रांट करें और आपने ठीक उसी वर्कलोड तक एक्सेस को सीमित कर दिया है।
• एक policy scope — RG स्तर पर governance rules संलग्न करें।
• एक lifecycle unit — RG को हटा दें और उसमें मौजूद सब कुछ उसके साथ चला जाता है।
• एक cost boundary — खर्च के लिए एक प्राकृतिक लाइन आइटम।

मुहावरेदार पैटर्न प्रति वर्कलोड (अक्सर प्रति region) एक RG है, इसलिए एक RG "इस region में इस ऐप के लिए फोल्डर" बन जाता है। एक RG का एक location होता है, लेकिन वह केवल यह बताता है कि इसका metadata कहाँ रहता है — इसके resources अन्य regions में रह सकते हैं, इसलिए RG location पर बहुत अधिक जोर न दें।

Resource IDs संदर्भ ले जाते हैं, इसलिए नामों को ऐसा करने की आवश्यकता नहीं है

प्रत्येक Azure resource में एक पूर्ण Resource ID होता है जैसे /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/containerApps/<name>। subscription और RG हर log record, audit event, और API कॉल के साथ यात्रा करते हैं — वही काम जो एक ARN का account और region AWS में करते हैं।

नामकरण का परिणाम आपकी AWS आदत के विपरीत है। AWS में नाम अक्सर एकमात्र संदर्भ होता है जो आपको मिलता है, इसलिए आप सब कुछ इसमें भर देते हैं। Azure में, नामों को उस चीज़ को छोड़ देना चाहिए जिसे scope पहले से ही एन्कोड करता है: qa subscription के अंदर rg-quest के अंदर aks-quest नाम का एक क्लस्टर पहले से ही पूरी तरह से डिसएंबिगुएटेड है, और वही RG/resource नाम dev/qa/prod subscriptions में सुरक्षित रूप से दोहराए जा सकते हैं। केवल globally unique resource types (storage accounts, container registries, Key Vaults) ही org/env/region को वापस नाम में मजबूर करते हैं — और वे सख्त लंबाई और वर्ण सीमाओं के साथ आते हैं, यही कारण है कि आप stcwtfstateplatformcus जैसे छोटे नाम देखते हैं।

(वह cus प्रत्यय, वैसे, गढ़ा नहीं गया है — यह सेंट्रल यूएस के लिए माइक्रोसॉफ्ट का अपना geo-code है, उसी आधिकारिक टेबल से जिसका उपयोग Azure private-endpoint DNS zones बनाने के लिए करता है। eus/eus2 ईस्ट यूएस और ईस्ट यूएस 2 हैं। geo-code टेबल को जल्दी सीखने से लाभ होता है।)

AWS → Azure त्वरित मानचित्र

पहले महीने के लिए इसे अपने पास रखें:

• Organization → एक Entra tenant और management groups। Identity (tenant) और structure (management groups) Azure में अलग-अलग चीजें हैं, एक नहीं।
• Account → subscription। Identity के लिए एक tenant में होम होता है; एक अलग billing account द्वारा बिल किया जाता है।
• SCP (guardrail) → एक management-group scope पर Azure Policy — केवल deny से अधिक समृद्ध प्रभावों के साथ (audit, deny, modify, deployIfNotExists)।
• IAM role/policy → RBAC role assignment — (principal, role, scope)। याद रखें: कोई identity-attached policies नहीं होतीं।
• Root-account superpowers → तीन तरह से विभाजित: Global Admin (identity) + elevateAccess (resources) + billing owner (पैसा)। कोई भी अकेला principal तीनों के साथ शुरू नहीं होता।
• Organizations CreateAccount → subscription aliases API + एक billing scope — और केवल उन billing agreement types पर जो इसकी अनुमति देते हैं।
• IRSA (IAM Roles for Service Accounts) → workload identity federation — वही OIDC विचार।
• Tag-based grouping → resource group — संरचनात्मक और अनिवार्य, एक tag query नहीं।
• logs में ARN → Resource ID (_ResourceId कॉलम) — scope context संरचित है, नाम-एन्कोडेड नहीं।

Terraform state को बूटस्ट्रैप करना, अनुवादित

यह एक ऐसी जगह है जहाँ आपकी AWS runbook लगभग काम करती है, फिर स्टेप जीरो पर टूट जाती है।

AWS बूटस्ट्रैप जिसे आप जानते हैं: management account में एक state backend को कोल्ड-स्टार्ट करें (लोकल स्टेट, फिर बैकएंड को खुद में माइग्रेट करें), per-OU बैकएंड्स की स्टेट को उस root backend में रखें, और अपने खुद के बैकएंड्स का उपयोग करके member accounts बनाएँ। वह इनवेरिएंट जो इसे साफ बनाता है वह यह है कि आप हमेशा root account से बूटस्ट्रैप कर सकते हैं, क्योंकि यह हमेशा मौजूद रहता है और एक S3 bucket रख सकता है।

Azure उत्पत्ति पर उस इनवेरिएंट को तोड़ता है। हमेशा मौजूद रहने वाली वस्तु tenant है — लेकिन एक tenant resources को धारण नहीं कर सकता। Storage accounts subscriptions में रहते हैं, और subscriptions billing plane से पैदा होती हैं। तो Azure का "root account" जो भी subscription आप root के रूप में ताज पहनाते हैं वह है, और आपको सचेत रूप से एक को ताज पहनाना होगा। व्यवहार में अधिकांश tenants को साइनअप पर एक subscription मिलता है, इसलिए समानता अधिकतर बनी रहती है: AWS आपको एक management account देता है, Azure आपको एक पहला subscription देता है।

अनुवादित प्रवाह, जब subscriptions पहले से मौजूद हों (सामान्य स्थिति):

1. एक कोल्ड-स्टार्ट, हमेशा के लिए: अपने designated root subscription में लोकल स्टेट के साथ state backend को डिप्लॉय करें, फिर init -migrate-state को उसमें चलाएं।
2. Per-subscription backends, state stored in the root backend: प्रत्येक अतिरिक्त subscription का backend component अपनी स्वयं की स्टेट को root backend से पिन करता है, इसलिए उन्हें खड़ा करना एक सामान्य अप्लाई है — कोई और कोल्ड-स्टार्ट नहीं।
3. प्रत्येक subscription में बाकी सब कुछ उस subscription के अपने backend का उपयोग करता है।

बिल्कुल शुरुआत से (कोड के साथ subscriptions बनाना), क्रम मजबूर है — root subscription पहले, root backend दूसरा — क्योंकि एक backend एक storage account है और एक storage account को रहने के लिए एक subscription की आवश्यकता होती है। एक चिकन-और-अंडे की गुत्थी पर ध्यान दें: azurerm provider स्वयं एक subscription context की मांग करता है, इसलिए शून्य subscriptions के साथ आप उस पहले subscription को एक imperative कॉल (CLI या azapi provider) के साथ बनाते हैं, फिर बाद में इसे Terraform में इम्पोर्ट करते हैं।

और यहाँ Azure वास्तव में AWS की आदत की तुलना में सरल है: backend-in-root प्लस resources-in-member को AWS की hub-and-spoke trust machinery में से किसी की भी आवश्यकता नहीं होती — कोई backend role_arn नहीं, कोई provider assume_role नहीं, कोई दो-तरफा trust policies नहीं। tenant root management group में Owner हर subscription में इनहेरिट होता है, इसलिए एक token tenant-व्यापी काम करता है; provider subscription_id सेट करके subscriptions के बीच "होप" करता है; और backend केवल Storage Blob Data Contributor ग्रांट द्वारा अधिकृत data-plane blob एक्सेस है। Cross-subscription एक पैरामीटर है, न कि एक trust negotiation। (आप इसे बाद में कस्टम roles, PIM, और dedicated CI identities के साथ कसेंगे — लेकिन तब भी यह scopes पर role assignments है, कभी भी trust-policy handshake नहीं।) यदि आप किसी भी तरफ से कोडिफाइंग में गहराई से जाना चाहते हैं, तो HashiCorp Terraform Authoring & Operations Pro परीक्षा ठीक इन्हीं state और provider पैटर्न्स के इर्द-गिर्द बनाई गई है।

वे चार जगहें जहाँ आपकी AWS आदतें आपको सक्रिय रूप से गुमराह करेंगी

यदि आप बाकी सब भूल जाते हैं, तो इन्हें याद रखें:

1. "एडमिन" ग्लोबल नहीं है। Global Administrator केवल identity-only है; जब तक कोई उसे resource role प्रदान नहीं करता, तब तक वह एक subscription को पढ़ नहीं सकता। कोई एकल "root" principal नहीं है।
2. परमिशन scopes से जुड़ती हैं, identities से नहीं। user पर policy की तलाश करना बंद करें — management group, subscription, resource group, या resource पर role assignment की तलाश करें।
3. बिलिंग resources से एक अलग ब्रह्मांड है। "मैं कुछ भी डिप्लॉय कर सकता हूँ" आपको "मैं एक subscription बना सकता हूँ" के बारे में कुछ नहीं बताता। अलग प्लेन, अलग roles, az role assignment list के लिए अदृश्य।
4. Resource group लोड-बियरिंग है। यह एक tag नहीं है — यह एक RBAC scope, एक policy scope, और एक delete boundary है। अपने RG लेआउट को उद्देश्यपूर्ण तरीके से डिज़ाइन करें।

कौन से सर्टिफिकेशन्स प्रत्येक पक्ष को प्रशिक्षित करते हैं

Cloud governance — hierarchy, identity, guardrails, और state — दोनों क्लाउड्स पर आर्किटेक्चर और एडमिनिस्ट्रेशन परीक्षाओं की रीढ़ हैं, इसलिए उनके लिए पढ़ाई करना उपरोक्त अवधारणाओं को याद रखने का सबसे तेज़ तरीका भी है। यदि आपके पास पहले से ही AWS क्रेडेंशियल है, तो उसी पंक्ति में Azure वाला आपका अगला स्वाभाविक कदम है।

AWS पक्ष पर (वह ज्ञान जिससे आप अनुवाद कर रहे हैं):

• AWS Certified Cloud Practitioner (CLF-C02) — accounts, IAM, और Organizations की नींव।
• AWS Certified Solutions Architect – Associate (SAA-C03) — IAM, multi-account structure, और core architecture।
• AWS Certified Solutions Architect – Professional (SAP-C02) — multi-account Organizations, SCPs, और बड़े पैमाने पर cross-account एक्सेस।
• AWS Certified Security – Specialty (SCS-C03) — IAM depth, SCPs, और key management।

Azure पक्ष पर (वह ज्ञान जिसमें आप अनुवाद कर रहे हैं):

• Microsoft Certified: Azure Fundamentals (AZ-900) — tenants, subscriptions, resource groups, और RBAC के मूल सिद्धांत।
• Microsoft Certified: Azure Administrator Associate (AZ-104) — दिन-प्रतिदिन का प्लेन: RBAC, resource groups, subscriptions, और Entra basics।
• Microsoft Certified: Azure Solutions Architect Expert (AZ-305) — management groups, governance, और landing-zone design।
• Microsoft Certified: Azure Security Engineer Associate (AZ-500) — Entra ID, RBAC, Azure Policy, Conditional Access, और Key Vault।

यदि आप आज AWS-certified हैं तो एक व्यावहारिक मार्ग: AZ-900 से शुरू करें ताकि शब्दावली को मैप कर सकें, फिर AZ-104 पर जाएँ (जो resource plane में रहता है जिसका आप सबसे अधिक उपयोग करेंगे), और AZ-305 या AZ-500 जोड़ें, यह इस बात पर निर्भर करता है कि आपका काम आर्किटेक्चर की ओर झुकता है या सुरक्षा की ओर।

निष्कर्ष

Azure AWS से कठिन नहीं है — यह अलग तरह से फैक्टर किया गया है। AWS identity, resource, और billing authority को एक प्लेन में समेट देता है और आपको एक management account देता है जो सब कुछ कर सकता है। Azure जानबूझकर उन तीन चिंताओं को अलग करता है, जो पहले दिन घर्षण जैसा महसूस होता है और तीसरे महीने तक साफ सीमाओं जैसा लगता है। अवधारणाओं का एक बार अनुवाद करें — एक प्लेन तीन बन जाता है, अकाउंट्स कहीं और बिल किए गए subscriptions बन जाते हैं, policies identities के बजाय scopes से जुड़ती हैं, और resource group वास्तविक संरचना है — और बाकी शब्दावली है। ऊपर दिए गए certs के साथ इसका अभ्यास करें, और जो हिस्से मनमाने ढंग से डिनायल जैसे लगते थे, वे एक सुसंगत, जानबूझकर किए गए डिज़ाइन के रूप में पढ़ना शुरू हो जाएंगे।