AWS vs GCP vs Azure: संगठन पदानुक्रम, IAM, और कुंजी प्रबंधन, आमने-सामने

यदि आप पहले से ही एक क्लाउड के शासन मॉडल को जानते हैं, तो आप अन्य दो के 80% को जानते हैं — अवधारणाएँ समान हैं और केवल शब्दावली बदल जाती है। हर क्लाउड आपको कुछ भी वास्तविक शिप करने से पहले उन्हीं तीन सवालों का जवाब देने पर मजबूर करता है: मैं अपने खातों को कैसे व्यवस्थित करूँ, किसे क्या करने की अनुमति है, और मेरी एन्क्रिप्शन कुंजियाँ कैसे बनाई और नियंत्रित की जाती हैं? यह पोस्ट AWS, Google Cloud और Azure को एक-दूसरे पर मैप करती है, एक समय में एक परत, और उन चार जगहों को इंगित करती है जहाँ सादृश्य चुपचाप टूट जाता है।

वे चार परतें — पदानुक्रम, गार्डरेल्स, पहचान और कुंजी प्रबंधन — प्रत्येक क्लाउड आर्किटेक्चर और सुरक्षा परीक्षा की रीढ़ भी हैं। तो वही अध्ययन जो आपको क्रॉस-क्लाउड भ्रम के एक सप्ताह से बचाता है, वह एक सर्टिफिकेशन के पाठ्यक्रम का अधिकांश हिस्सा है। प्रत्येक परत को गहराई से समझने के लिए सर्टिफिकेशन के लिंक अंत में दिए गए हैं।

हर क्लाउड जिन तीन समस्याओं को हल करता है

मार्केटिंग को हटा दें तो हर शासन चर्चा तीन परतों का एक ढेर है:

• संरचना (Structure) — कंटेनरों का एक नेस्टेड सेट (संगठन → समूहन → वर्कलोड बाउंड्री) ताकि आप परिवेशों को अलग कर सकें, गार्डरेल्स लागू कर सकें और बिल को विभाजित कर सकें।
• पहचान और अनुमतियाँ (Identity and permissions) — कौन से प्रिंसिपल कौन सी क्रियाएँ किन रिसोर्स पर कर सकते हैं, साथ ही वह सीमा जो यह निर्धारित करती है कि कोई भी अनुदान क्या दे सकता है।
• कुंजी प्रबंधन (Key management) — क्रिप्टोग्राफिक कुंजियाँ कहाँ रहती हैं, कौन उनका उपयोग कर सकता है, और कौन उनका प्रशासन कर सकता है — दो अलग-अलग सवाल जिन्हें लोग लगातार भ्रमित करते हैं।

अधिकांश इंजीनियर उस क्लाउड में टुकड़ों को सूचीबद्ध कर सकते हैं जिसे वे सबसे अच्छी तरह जानते हैं। मुश्किल हिस्सा पूरी तस्वीर है: वे परतें जिन्हें भूलना आसान है, और प्रत्येक टुकड़ा अन्य दो क्लाउड में कैसे अनुवादित होता है।

परत 1 — रिसोर्स पदानुक्रम

प्रत्येक क्लाउड में एक शीर्ष-स्तरीय organization node, एक वैकल्पिक middle grouping layer होता है जिसे आप विभागों या परिवेशों के लिए नेस्ट करते हैं, और एक workload boundary जो बिलिंग और ब्लास्ट रेडियस की इकाई के रूप में भी कार्य करता है। सभी तीनों में उच्च स्तर पर निर्धारित पॉलिसी नीचे की ओर प्रवाहित होती हैं।

• Org root — AWS: एक Organization जिसमें एक management account होता है। GCP: organization node। Azure: tenant root management group, जिसे एक Microsoft Entra tenant द्वारा समर्थित किया जाता है।
• Grouping container (नेस्ट करने योग्य) — AWS: Organizational Unit (OU)। GCP: folder। Azure: management group।
• Workload और billing boundary — AWS: account। GCP: project। Azure: subscription।
• बाउंड्री के अंदर रिसोर्स समूहन — AWS: कोई नहीं (tags, या प्रति-अकाउंट)। GCP: कोई नहीं — project ही कंटेनर है। Azure: resource group, जो अनिवार्य है; हर रिसोर्स ठीक एक में रहता है।

पहला वास्तविक अंतर यहीं छिपा है। AWS में अकाउंट एक कठिन दीवार है — ब्लास्ट रेडियस की डिफ़ॉल्ट इकाई — यही कारण है कि बड़े AWS एस्टेट दर्जनों या सैकड़ों अकाउंट चलाते हैं। GCP में प्रोजेक्ट एक साथ दो काम करता है: यह समूहन इकाई और बिलिंग/आइसोलेशन इकाई दोनों है, इसलिए कोई अलग "resource group" अवधारणा नहीं है। Azure एक चौथा स्तर जोड़ता है जिसकी अन्य लोगों में कमी है — resource group — जो subscription के तहत एक लाइफसाइकल कंटेनर के रूप में बैठता है जिसे आप एक इकाई के रूप में तैनात और हटाते हैं।

परत 2 — निवारक गार्डरेल्स (अनुमति सीमा)

किसी को कुछ भी देने से पहले, प्रत्येक क्लाउड आपको एक नोड के नीचे क्या अनुमतियाँ कभी मौजूद हो सकती हैं, उस पर एक ऊपरी सीमा निर्धारित करने देता है — एक ऐसी सीमा जिसे कोई भी व्यक्तिगत अनुदान भेद नहीं सकता। यह एक्सेस देने जैसा नहीं है; यह "आप कभी नहीं कर सकते, संगठन-व्यापी" परत है।

• प्रिंसिपलों के करने की क्षमता पर सीमा — AWS: Service Control Policy (SCP)। GCP: Organization Policy कंस्ट्रेंट्स के साथ IAM डिनाई पॉलिसी। Azure: Azure Policy।
• कौन एक रिसोर्स को छू सकता है, उस पर सीमा — AWS: Resource Control Policy (RCP)। GCP: रिसोर्स पर IAM अलाऊ/डिनाई पॉलिसी। Azure: Azure Policy के साथ डिनाई असाइनमेंट।
• सेवा कॉन्फ़िगरेशन लागू करना — AWS: डिक्लेरेटिव पॉलिसी। GCP: Organization Policy कंस्ट्रेंट्स। Azure: Azure Policy (deny / audit / deployIfNotExists)।

AWS ने इस काम को दो भागों में बांटा। SCPs प्रिंसिपल-केंद्रित होते हैं ("हमारे लोग X नहीं कर सकते") और नए RCPs रिसोर्स-केंद्रित होते हैं ("कोई भी — यहां तक कि एक बाहरी अकाउंट भी — इस S3 बकेट, KMS कुंजी, या रोल को छू नहीं सकता, जब तक वे हमारे संगठन में न हों")। एक साथ उपयोग किए जाने पर वे उन अंतरालों को बंद कर देते हैं जिन्हें कोई भी अकेला कवर नहीं कर सकता। फंदा: AWS और GCP में एक SCP या Org Policy कभी भी कुछ भी अनुदान नहीं देता — यह केवल घटाता है। Azure अलग तरीके से वायर्ड है, RBAC (अनुमतियों) को Azure Policy (अनुपालन और कॉन्फ़िगरेशन) से स्पष्ट रूप से अलग करता है, इसलिए गार्डरेल का काम अधिकतर Azure Policy का होता है जबकि "कौन क्या कर सकता है" पूरी तरह से RBAC का होता है।

परत 3 — पहचान और अनुमतियाँ

प्रत्येक क्लाउड एक अनुदान को उसी ट्रिपल के रूप में व्यक्त करता है — एक प्रिंसिपल, एक रोल (अनुमतियों का एक बंडल), और एक स्कोप — लेकिन टुकड़ों को अलग-अलग तरीके से इकट्ठा करता है।

• पहचान डायरेक्टरी — AWS: IAM के साथ IAM Identity Center (SSO)। GCP: Cloud Identity / Google Workspace के साथ IAM। Azure: Microsoft Entra ID।
• अनुमति बंडल ("रोल") — AWS: एक IAM पॉलिसी, प्रबंधित या इनलाइन। GCP: एक IAM रोल — बेसिक, पूर्वनिर्धारित, या कस्टम। Azure: एक RBAC रोल परिभाषा, अंतर्निर्मित या कस्टम।
• अनुदान स्वयं — AWS: एक उपयोगकर्ता, समूह, या रोल से जुड़ी पॉलिसी। GCP: एक रिसोर्स पर IAM बाइंडिंग (सदस्य + रोल, वैकल्पिक रूप से एक कंडीशन)। Azure: एक रोल असाइनमेंट (प्रिंसिपल + रोल + स्कोप)।
• कंडीशन और स्पष्ट डिनाई — AWS: IAM कंडीशन कीज और स्पष्ट Deny। GCP: IAM कंडीशन और डिनाई पॉलिसी। Azure: RBAC कंडीशन और डिनाई असाइनमेंट।

सबसे गहरा अंतर यह है कि अनुदान कहाँ रहता है। AWS में आप अधिकतर पॉलिसी को पहचान से जोड़ते हैं — एक रोल या उपयोगकर्ता से — और अनुमति उनके साथ यात्रा करती है। GCP में अलाऊ पॉलिसी रिसोर्स से जुड़ती है: आप प्रिंसिपल P को रिसोर्स X पर रोल R प्रदान करते हैं, और यह पदानुक्रम में नीचे की ओर इनहेरिट होती है। Azure का रोल असाइनमेंट GCP के बाइंडिंग जैसा है लेकिन मैनेजमेंट-ग्रुप → सब्सक्रिप्शन → रिसोर्स-ग्रुप → रिसोर्स चेन में एक स्कोप से जुड़ता है। "AWS = पहचान-संलग्न, GCP और Azure = रिसोर्स/स्कोप-संलग्न" को आत्मसात करें और बहुत सारा क्रॉस-क्लाउड भ्रम गायब हो जाएगा।

परत 3b — वर्कलोड पहचान (वह हिस्सा जिसे लोग भूल जाते हैं)

मनुष्य ही एकमात्र प्रिंसिपल नहीं हैं। आपके कोड को भी एक पहचान की आवश्यकता होती है, और इसे सही करना लीस्ट प्रिविलेज पर एकमात्र सबसे बड़ा लीवर है। हर जगह सुनहरा नियम: कभी भी लंबे समय तक चलने वाली स्टैटिक कुंजियाँ शिप न करें — इसके बजाय वर्कलोड से एक प्रबंधित पहचान संलग्न करें।

• चल रहे वर्कलोड के लिए पहचान — AWS: एक IAM रोल, इंस्टेंस प्रोफाइल, टास्क रोल, या OIDC के माध्यम से माना गया। GCP: रिसोर्स से जुड़ा एक सर्विस अकाउंट। Azure: एक प्रबंधित पहचान, सिस्टम- या उपयोगकर्ता-असाइन किया गया।
• ऐप / गैर-मानवीय प्रिंसिपल — AWS: IAM रोल। GCP: सर्विस अकाउंट। Azure: सर्विस प्रिंसिपल।
• क्लाउड के बाहर से कीलेस ट्रस्ट — AWS: OIDC/SAML फेडरेशन के साथ IAM रोल। GCP: Workload Identity Federation। Azure: workload identity federation।

नामकरण ओवरलैप देखें जो सभी को भ्रमित करता है: AWS में एक "IAM रोल" एक वर्कलोड पहचान है जिसे आप मानते हैं, जबकि GCP और Azure में एक "रोल" केवल एक अनुमति बंडल है — पहचान एक सर्विस अकाउंट या प्रबंधित पहचान है। एक ही शब्द, दो अलग-अलग काम। GCP सर्विस-अकाउंट कुंजियाँ और Azure सर्विस-प्रिंसिपल सीक्रेट्स अभी भी मौजूद हैं, लेकिन दोनों क्लाउड अब अपनी परिधि के बाहर चलने वाली किसी भी चीज़ के लिए कीलेस फेडरेशन की ओर कड़ी मेहनत कर रहे हैं।

परत 4 — कुंजी प्रबंधन

अंत में, एन्क्रिप्शन। प्रत्येक क्लाउड में एक प्रबंधित कुंजी सेवा होती है, कुंजियों को एक छोटे पदानुक्रम में व्यवस्थित करता है, और — महत्वपूर्ण रूप से — एक कुंजी का उपयोग करना (एन्क्रिप्ट/डिक्रिप्ट) को एक कुंजी का प्रबंधन करना (रोटेट, डिसेबल, पॉलिसी सेट करना) से अलग करता है।

• सेवा — AWS: KMS, समर्पित हार्डवेयर के लिए CloudHSM के साथ। GCP: Cloud KMS, साथ ही Cloud HSM / बाहरी। Azure: Key Vault, समर्पित हार्डवेयर के लिए Managed HSM के साथ।
• कुंजी संगठन — AWS: KMS कुंजियाँ (CMKs), एलियास, मल्टी-रीजन कुंजियाँ। GCP: की रिंग → की → की वर्जन। Azure: वॉल्ट → की / सीक्रेट / सर्टिफिकेट।
• एक्सेस कंट्रोल — AWS: की पॉलिसी + ग्रांट्स + IAM (सभी तीनों का संयोजन)। GCP: प्रोजेक्ट, की-रिंग, या की स्तर पर Cloud KMS IAM बाइंडिंग। Azure: डिफ़ॉल्ट रूप से RBAC, या लीगेसी प्रति-वॉल्ट एक्सेस पॉलिसी; Managed HSM अपने स्थानीय RBAC का उपयोग करता है।
• उपयोग बनाम प्रबंधन विभाजन — AWS: एन्क्रिप्ट/डिक्रिप्ट क्रियाएँ बनाम की-एडमिन क्रियाएँ। GCP: cryptoKeyEncrypterDecrypter बनाम admin रोल। Azure: "Crypto User" बनाम "Crypto Officer"-स्टाइल रोल।

एक वर्तमान पेचीदगी जिसे जानना महत्वपूर्ण है: हाल के API वर्जन पर नए Key Vaults के लिए, Azure RBAC अब डिफ़ॉल्ट एक्सेस मॉडल है, और पुरानी प्रति-वॉल्ट एक्सेस पॉलिसी लीगेसी पाथ हैं — जो अंततः Key Vault को इस बात से संरेखित करती है कि Azure का बाकी हिस्सा अनुमतियाँ कैसे करता है। AWS अलग रहता है: एक KMS कुंजी की की पॉलिसी आधिकारिक होती है और IAM से स्वतंत्र रूप से एक्सेस प्रदान कर सकती है, इसलिए एक क्लासिक AWS फुट-गन IAM को संपादित करके खुद को एक कुंजी से बाहर करना है जबकि की पॉलिसी को भूल जाना। GCP में, KMS एक्सेस बाकी सब की तरह सामान्य IAM है।

जहाँ मानसिक मॉडल टूट जाता है

एक स्वच्छ मानचित्रण खतरनाक है यदि आप इस पर बहुत शाब्दिक रूप से भरोसा करते हैं। चार जगहें जहां सादृश्य लीक करता है:

• "IAM role" का मतलब दो अलग-अलग चीजें हैं। AWS में यह एक अज्यूमेबल पहचान है; GCP और Azure में एक "रोल" केवल एक अनुमति सेट है, जिसमें पहचान को अलग रखा जाता है। इसका शब्दशः अनुवाद कभी न करें।
• AWS अनुमतियों को पहचानों से जोड़ता है; GCP और Azure उन्हें रिसोर्स और स्कोप से जोड़ते हैं। जब आप क्लाउड बदलते हैं तो आपकी "एक्सेस का ऑडिट करने के लिए मुझे कहाँ देखना चाहिए?" की प्रवृत्ति को पलटना पड़ता है।
• अकाउंट, प्रोजेक्ट, और सब्सक्रिप्शन एक ही ब्लास्ट रेडियस नहीं हैं। एक AWS अकाउंट एक मजबूत दीवार है; एक GCP प्रोजेक्ट एक में दीवार, बिल और समूहन है; एक Azure सब्सक्रिप्शन अधिकतर एक बिलिंग और स्केल बाउंड्री है, जिसमें रिसोर्स ग्रुप रोजमर्रा का लाइफसाइकल संभालता है।
• गार्डरेल्स घटाते हैं, ग्रांट्स जोड़ते हैं — सिवाय इसके कि Azure कामों को विभाजित करता है। SCPs और Org Policy केवल अनुमतियों को सीमित करते हैं; Azure पॉलिसी के माध्यम से सीमाएं लगाता है और RBAC के माध्यम से अनुदान देता है जो दो अलग-अलग सिस्टम हैं।

तीनों के पीछे का सिद्धांत समान है: लीस्ट प्रिविलेज, संरचना द्वारा लागू किया गया। गार्डरेल्स को ऊँचा रखें (org, OU, folder, management group), संकीर्ण रूप से अनुदान दें और स्टैटिक कुंजियों के बजाय भूमिकाओं को प्राथमिकता दें, और "कुंजी का उपयोग कर सकते हैं" को "कुंजी का प्रबंधन कर सकते हैं" से अलग रखें। क्लाउड में नाम बदलते हैं; अनुशासन नहीं बदलता।

व्यावहारिक निष्कर्ष

• पहले वर्कलोड से पहले पदानुक्रम डिज़ाइन करें। बाद में खातों, प्रोजेक्ट्स, या सब्सक्रिप्शन्स को रेट्रोफिट करना हर क्लाउड में मुश्किल होता है।
• सीमाएँ ऊँची निर्धारित करें, अनुदान कम दें। शीर्ष पर SCP/RCP, Org Policy, या Azure Policy; सबसे संकीर्ण दायरे में विशिष्ट भूमिकाएँ जो काम करती हैं।
• प्रबंधित पहचानों को डिफ़ॉल्ट करें। AWS पर IAM रोल, GCP पर सर्विस अकाउंट, Azure पर प्रबंधित पहचान — और क्लाउड सीमा पार करने वाली किसी भी चीज़ के लिए कीलेस फेडरेशन।
• कुंजी प्रशासन को विशेषाधिकार प्राप्त मानें। एन्क्रिप्ट/डिक्रिप्ट को रोटेट/डिसेबल/सेट-पॉलिसी से अलग करें, और AWS पर हमेशा की पॉलिसी की जाँच करें, केवल IAM की नहीं।
• यदि आप Terraform या OpenTofu का उपयोग करते हैं, तो ये प्रिमिटिव ही हैं जिन्हें आप कोडिफ़ाई करेंगे — aws_organizations_*, google_folder, azurerm_management_group, और उनके नीचे के IAM/RBAC और KMS रिसोर्स।

प्रत्येक परत को, प्रति क्लाउड, गहराई से समझें

प्रत्येक क्लाउड के आर्किटेक्चर और सुरक्षा सर्टिफिकेशन रिसोर्स पदानुक्रम, IAM/RBAC, और कुंजी प्रबंधन पर आधारित हैं। यदि आप वास्तविक परीक्षा प्रश्नों के साथ उनका अभ्यास करना चाहते हैं, तो CertLabPro में प्रत्येक के लिए एक ट्रैक है:

• AWS — पदानुक्रम और IAM के लिए Solutions Architect Associate (SAA-C03), और SCPs, RCPs, और KMS के लिए Security Specialty (SCS-C03)। AWS में नए हैं? Cloud Practitioner (CLF-C02) से शुरू करें।
• Google Cloud — संगठन, फोल्डर, प्रोजेक्ट्स, और IAM के लिए Professional Cloud Architect, और IAM डिनाई पॉलिसी, Org Policy, और Cloud KMS के लिए Professional Cloud Security Engineer।
• Azure — मैनेजमेंट ग्रुप्स और गवर्नेंस के लिए Solutions Architect Expert (AZ-305), और RBAC, Azure Policy, और Key Vault के लिए Security Engineer (AZ-500)। Azure में नए हैं? Azure Fundamentals (AZ-900) से शुरू करें।

निचली रेखा

AWS, Google Cloud और Azure उतने अलग नहीं हैं जितना उनके डॉक्स उन्हें महसूस कराते हैं। प्रत्येक आपको खातों को व्यवस्थित करने के लिए एक पदानुक्रम, प्रिंसिपल-रोल-स्कोप पर निर्मित एक पहचान मॉडल, एक गार्डरेल परत जो अनुमतियों की अधिकतम सीमा निर्धारित करती है, और एक कुंजी सेवा प्रदान करता है जो कुंजियों का उपयोग करने को उनके प्रशासन से अलग करती है। चार परतों को एक बार सीखें और क्रॉस-क्लाउड अनुवाद अधिकतर शब्दावली है — और उन चार जगहों को सीखें जहाँ सादृश्य लीक करता है, और आप उन गलतियों से बचेंगे जिन्हें शब्दावली छुपाती है। वे बुनियादी बातें ठीक वही हैं जिनके लिए CertLabPro के प्रश्न बैंक सभी तीनों क्लाउड में अभ्यास करने के लिए बनाए गए हैं।