अंतिम समीक्षा: मई 2026
AZ-104 परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
उपयोगकर्ता विशेषताओं (उदाहरण के लिए, विभाग) के आधार पर सुरक्षा समूह सदस्यता को स्वचालित रूप से प्रबंधित करें।
एक Microsoft Entra ID सुरक्षा समूह को "Dynamic User" सदस्यता प्रकार के साथ कॉन्फ़िगर करें और एक विशेषता-आधारित नियम परिभाषित करें।
क्यों: विशेषता-आधारित नियम उपयोगकर्ता जीवनचक्र परिवर्तनों के लिए चल रहे मैनुअल प्रशासन को समाप्त करते हैं। Entra ID P1/P2 की आवश्यकता है।
एकल प्रबंधन बिंदु से कई सब्सक्रिप्शन में सुसंगत शासन (नीतियां, RBAC) लागू करें।
एक प्रबंधन समूह बनाएँ, सब्सक्रिप्शन को उसके तहत रखें, और प्रबंधन समूह दायरे में नीतियों या RBAC भूमिकाओं को असाइन करें।
क्यों: नीतियां और भूमिका असाइनमेंट सभी चाइल्ड सब्सक्रिप्शन द्वारा इनहेरिट किए जाते हैं, जिससे केंद्रीकृत और सुसंगत शासन सक्षम होता है।
पूरे सब्सक्रिप्शन में अनधिकृत Azure क्षेत्रों में संसाधन परिनियोजन को रोकें।
सब्सक्रिप्शन दायरे में `Deny` प्रभाव के साथ अंतर्निर्मित "Allowed locations" Azure Policy असाइन करें।
क्यों: नीति निवारक शासन प्रदान करती है। RBAC कार्यों को नियंत्रित करता है, परिनियोजन स्थानों को नहीं। Resource Locks संशोधन/हटाने को रोकते हैं, नए परिनियोजन को नहीं।
VMs को प्रबंधित करने की अनुमति दें, लेकिन अंतर्निहित वर्चुअल नेटवर्क या उपयोगकर्ता पहुँच को नहीं।
रिसोर्स समूह या VM दायरे में अंतर्निर्मित "Virtual Machine Contributor" भूमिका असाइन करें।
क्यों: यह भूमिका व्यापक Contributor या Owner अधिकारों को दिए बिना विशिष्ट VM प्रबंधन अनुमतियाँ (स्टार्ट, स्टॉप, रीइमेज) प्रदान करती है।
जब उपयोगकर्ता कॉर्पोरेट नेटवर्क के बाहर से विशिष्ट क्लाउड ऐप्स (जैसे, Azure portal) तक पहुँचते हैं तो MFA की आवश्यकता होती है।
कॉर्पोरेट IPs के लिए "Named Location" को अपवर्जन शर्त के रूप में और MFA को ग्रांट कंट्रोल के रूप में एक Conditional Access नीति बनाएँ।
क्यों: एक विश्वसनीय स्थान को बाहर करना कॉर्पोरेट नेटवर्क पर MFA को बायपास करने की कुंजी है, जबकि इसे हर जगह लागू किया जाता है।
महत्वपूर्ण संसाधनों को हटाने से रोकें, यहां तक कि Owner भूमिका वाले प्रशासकों द्वारा भी।
संसाधन या उसके संसाधन समूह पर `CanNotDelete` या `ReadOnly` संसाधन लॉक लागू करें।
क्यों: Resource locks सभी उपयोगकर्ताओं पर लागू होते हैं, उनकी RBAC भूमिका की परवाह किए बिना, आकस्मिक विलोपन के खिलाफ सबसे मजबूत सुरक्षा प्रदान करते हैं।
Azure Policy द्वारा पहचाने गए मौजूदा गैर-अनुपालन वाले संसाधनों को स्वचालित रूप से ठीक करें (उदाहरण के लिए, एक लापता टैग जोड़ें)।
`Modify` या `DeployIfNotExists` प्रभावों वाली नीतियों के लिए, नीति असाइनमेंट के लिए एक रेमेडिएशन कार्य बनाएँ।
क्यों: रेमेडिएशन कार्य सभी मौजूदा गैर-अनुपालन वाले संसाधनों पर नीति की सुधारात्मक कार्रवाई को ट्रिगर करते हैं, एक वातावरण को अनुपालन में लाने की प्रक्रिया को स्वचालित करते हैं।
विभाग, परियोजना, या व्यावसायिक इकाई द्वारा Azure लागतों पर रिपोर्ट करें।
सभी संसाधनों पर एक सुसंगत टैग (जैसे, "CostCenter") लागू करें। उस टैग द्वारा लागतों को फ़िल्टर और समूहबद्ध करने के लिए Azure Cost Management का उपयोग करें।
क्यों: टैग विभिन्न संसाधन समूहों और सब्सक्रिप्शन में कस्टम लागत आवंटन और रिपोर्टिंग के लिए प्राथमिक तंत्र हैं।
प्रशासकों को केवल तभी विशेषाधिकार प्राप्त भूमिकाएँ प्रदान करें जब आवश्यकता हो, सीमित समय के लिए, और अनुमोदन वर्कफ़्लो के साथ।
Microsoft Entra Privileged Identity Management (PIM) का उपयोग करें। उपयोगकर्ताओं को भूमिकाओं के लिए योग्य बनाएँ और सक्रियण आवश्यकताओं को कॉन्फ़िगर करें।
क्यों: PIM Just-In-Time (JIT) पहुँच लागू करता है, स्थायी विशेषाधिकार प्राप्त खातों के जोखिम को कम करता है और एक पूर्ण ऑडिट ट्रेल प्रदान करता है।
बाहरी भागीदारों को उनके स्वयं के कॉर्पोरेट क्रेडेंशियल्स का उपयोग करके Azure संसाधनों तक पहुँच प्रदान करें।
अपने टेनेंट में भागीदारों को अतिथि उपयोगकर्ताओं के रूप में आमंत्रित करने के लिए Microsoft Entra B2B सहयोग का उपयोग करें।
क्यों: B2B आपके टेनेंट में नए क्रेडेंशियल्स बनाने और प्रबंधित करने से बचाता है; भागीदार प्रमाणीकरण के लिए अपने मौजूदा पहचान प्रदाता का उपयोग करते हैं।
लंबे समय तक चलने वाले डेटा (जैसे, अनुपालन अभिलेखागार) के लिए स्टोरेज लागत को कम करें, जिसे शायद ही कभी एक्सेस किया जाता है लेकिन बनाए रखना आवश्यक है।
ब्लॉब्स को Hot/Cool से Archive टियर में स्वचालित रूप से स्थानांतरित करने के लिए एक blob lifecycle management policy का उपयोग करें।
क्यों: Archive टियर की स्टोरेज लागत सबसे कम होती है। Lifecycle नियम blob की आयु या अंतिम पहुँच समय के आधार पर टियरिंग प्रक्रिया को स्वचालित करते हैं।
प्राथमिक क्षेत्र आउटेज के दौरान एक सेकेंडरी क्षेत्र से स्टोरेज डेटा तक रीड-एक्सेस सुनिश्चित करें।
स्टोरेज अकाउंट को Read-Access Geo-Redundant Storage (RA-GRS) या RA-GZRS के साथ कॉन्फ़िगर करें।
क्यों: Standard GRS/GZRS डेटा को प्रतिकृत करता है लेकिन फ़ेलओवर होने तक सेकेंडरी तक रीड एक्सेस की अनुमति नहीं देता है। निरंतर रीड एक्सेस के लिए "RA" उपसर्ग आवश्यक है।
एक विशिष्ट कंटेनर के लिए Shared Access Signature (SAS) टोकन के एक सेट को तुरंत रद्द करने की क्षमता।
कंटेनर पर एक संग्रहीत पहुँच नीति के आधार पर SAS टोकन बनाएँ। रद्द करने के लिए, नीति को संशोधित या हटाएँ।
क्यों: संग्रहीत पहुँच नीति को संशोधित करने से उससे जुड़े सभी SAS टोकन तुरंत अमान्य हो जाते हैं, जिससे एक केंद्रीकृत रद्दीकरण तंत्र प्रदान होता है।
स्थानीय डिस्क स्थान के उपयोग को कम करते हुए एक ऑन-प्रिमाइसेस फ़ाइल सर्वर को एक Azure फ़ाइल शेयर के साथ सिंक्रनाइज़ करें।
Azure File Sync को परिनियोजित करें और सर्वर एंडपॉइंट पर क्लाउड टियरिंग सक्षम करें।
क्यों: क्लाउड टियरिंग केवल बार-बार एक्सेस की गई ("हॉट") फ़ाइलों को स्थानीय रूप से कैश में रखता है, जबकि कम उपयोग की गई फ़ाइलें Azure में टियर की जाती हैं, जो स्थानीय सर्वर पर स्टब के रूप में दिखाई देती हैं।
स्टोरेज अकाउंट तक नेटवर्क पहुँच को विशिष्ट VNet सबनेट और सार्वजनिक IP पतों तक सीमित करें।
स्टोरेज अकाउंट फ़ायरवॉल सक्षम करें। सबनेट के लिए वर्चुअल नेटवर्क नियम और सार्वजनिक IPs के लिए IP एड्रेस नियम जोड़ें।
क्यों: स्टोरेज फ़ायरवॉल स्टोरेज अकाउंट के सार्वजनिक एंडपॉइंट पर सीधे नेटवर्क-स्तरीय पहुँच नियंत्रण प्रदान करता है, अन्य सभी ट्रैफ़िक को ब्लॉक करता है।
निर्दिष्ट अवधि के लिए रिकवरी की अनुमति देकर ब्लॉब्स को आकस्मिक विलोपन से बचाएं।
स्टोरेज अकाउंट पर blob soft delete सक्षम करें और रिटेंशन अवधि (जैसे, 14 दिन) कॉन्फ़िगर करें।
क्यों: Soft delete कॉन्फ़िगर की गई अवधि के लिए हटाए गए ब्लॉब्स को बरकरार रखता है, जिससे साधारण अनडिलीशन की अनुमति मिलती है। यह आकस्मिक डेटा हानि के खिलाफ रक्षा की पहली पंक्ति है।
एक निश्चित अवधि के लिए डेटा को गैर-मिटाने योग्य, गैर-संशोधन योग्य (WORM) स्थिति में संग्रहीत करने के लिए अनुपालन आवश्यकताओं को पूरा करें।
एक blob कंटेनर पर एक समय-आधारित रिटेंशन नीति कॉन्फ़िगर करें और नीति को लॉक करें।
क्यों: एक लॉक की गई समय-आधारित रिटेंशन नीति ब्लॉब्स को अपरिवर्तनीय बनाती है, रिटेंशन अवधि समाप्त होने तक किसी भी व्यक्ति (प्रशासकों सहित) द्वारा विलोपन या संशोधन को रोकती है।
जब नेटवर्क बैंडविड्थ सीमित हो तो एक बहुत बड़े डेटासेट (जैसे, 50+ TB) को Azure Blob Storage में माइग्रेट करें।
एक ऑफलाइन ट्रांसफर के लिए Azure Data Box भौतिक उपकरण का उपयोग करें।
क्यों: बड़े डेटासेट के लिए, एक भौतिक उपकरण भेजना धीमी या संतृप्त नेटवर्क कनेक्शन पर डेटा स्थानांतरित करने की तुलना में काफी तेज होता है।
VMs के लिए 99.99% SLA प्राप्त करें और एक क्षेत्र के भीतर एकल डेटासेंटर विफलता के खिलाफ एक एप्लिकेशन को सुरक्षित करें।
एक ही क्षेत्र के भीतर विभिन्न Availability Zones में कई VM इंस्टेंस परिनियोजित करें।
क्यों: Availability Zones भौतिक रूप से अलग डेटासेंटर हैं। Availability Sets केवल एक ही डेटासेंटर (99.95% SLA) के भीतर रैक-स्तरीय विफलताओं से बचाते हैं।
पूर्ण रिलीज़ से पहले, शून्य डाउनटाइम के साथ लाइव प्रोडक्शन ट्रैफ़िक के साथ एक नया एप्लिकेशन संस्करण परिनियोजित और परीक्षण करें।
एक App Service डिप्लॉयमेंट स्लॉट का उपयोग करें। स्लॉट में परिनियोजित करें, परीक्षण करें, फिर एक स्वैप करें। वैकल्पिक रूप से कैनरी टेस्टिंग के लिए ट्रैफ़िक राउटिंग का उपयोग करें।
क्यों: स्लॉट एक पूर्ण स्टेजिंग वातावरण प्रदान करते हैं। स्वैप ऑपरेशन ट्रैफ़िक का लगभग तात्कालिक रीडायरेक्ट है, जो शून्य डाउनटाइम सुनिश्चित करता है।
न्यूनतम लागत और कोई इंफ्रास्ट्रक्चर प्रबंधन के साथ, एक शेड्यूल पर एक अल्पकालिक, कंटेनरयुक्त बैच जॉब चलाएँ।
Azure Container Instances (ACI) का उपयोग करें।
क्यों: ACI प्रति-सेकंड बिलिंग और कोई क्लस्टर प्रबंधन ओवरहेड प्रदान करता है, जिससे यह छिटपुट या अल्पकालिक कंटेनर वर्कलोड के लिए सबसे लागत प्रभावी विकल्प बन जाता है।
अनुमानित दैनिक पीक (जैसे, व्यावसायिक घंटे) वाले वर्कलोड को स्वतः स्केल करें, साथ ही अप्रत्याशित स्पाइक्स को भी संभालें।
VM Scale Set ऑटोस्केल को शेड्यूल-आधारित नियमों और मेट्रिक-आधारित नियमों दोनों के साथ कॉन्फ़िगर करें।
क्यों: सक्रिय (शेड्यूल) और प्रतिक्रियात्मक (मेट्रिक) स्केलिंग का संयोजन प्रदर्शन (पीक से पहले तैयार) और लागत दक्षता (निष्क्रिय होने पर स्केल डाउन) का सबसे अच्छा संतुलन प्रदान करता है।
Azure Kubernetes Service (AKS) क्लस्टर के लिए कंटेनर इमेज को भेद्यता स्कैनिंग के साथ एक निजी रजिस्ट्री में सुरक्षित रूप से संग्रहीत करें।
Azure Container Registry (ACR) Premium SKU का उपयोग करें और एक Managed Identity का उपयोग करके इसे AKS के साथ एकीकृत करें।
क्यों: ACR Azure में सह-स्थित एक निजी रजिस्ट्री प्रदान करता है। Premium SKU में भेद्यता स्कैनिंग शामिल है। Managed identity AKS से ACR तक सुरक्षित, क्रेडेंशियल-लेस प्रमाणीकरण प्रदान करता है।
एप्लिकेशन डाउनटाइम के बिना सभी VMSS इंस्टेंस पर एक OS या एप्लिकेशन अपडेट करें।
VMSS मॉडल (जैसे, नया इमेज संस्करण) अपडेट करें और एक Rolling अपग्रेड नीति का उपयोग करें।
क्यों: Rolling नीति कॉन्फ़िगर करने योग्य बैचों में इंस्टेंस को अपडेट करती है, यह सुनिश्चित करती है कि अपडेट प्रक्रिया के दौरान ट्रैफ़िक को सेवा देने के लिए इंस्टेंस का एक उपसमूह हमेशा उपलब्ध रहे।
एक मल्टी-कंटेनर एप्लिकेशन (जैसे, ऐप + लॉगिंग साइडकार) को परिनियोजित करें जिसे नेटवर्क और स्टोरेज साझा करना होगा, बिना पूर्ण ऑर्केस्ट्रेटर के।
कंटेनरों को एक एकल Azure Container Instances (ACI) कंटेनर समूह में परिनियोजित करें।
क्यों: एक कंटेनर समूह कई कंटेनरों को सह-स्थित करता है, एक लोकलहोस्ट नेटवर्क और वॉल्यूम साझा करता है, Kubernetes की जटिलता के बिना साइडकार पैटर्न के लिए एकदम सही है।
VM के OS या डेटा डिस्क का आकार परिनियोजन के बाद बढ़ाएँ।
VM को डीएलोकेट करें, Azure में डिस्क संसाधन का आकार बदलें, VM को स्टार्ट करें, फिर गेस्ट OS के अंदर पार्टीशन का विस्तार करें।
क्यों: Azure डिस्क का आकार बदलने से केवल अधिक स्थान आवंटित होता है। गेस्ट OS को अपने फ़ाइल सिस्टम पार्टीशन का विस्तार करके उस नए स्थान का उपयोग करने के लिए निर्देशित किया जाना चाहिए।
एप्लिकेशन में क्रेडेंशियल संग्रहीत किए बिना एक App Service को Azure Key Vault से रहस्यों तक सुरक्षित रूप से पहुँचने की अनुमति दें।
App Service पर एक सिस्टम-असाइन की गई Managed Identity सक्षम करें और उस पहचान को Key Vault रहस्यों पर `Get` और `List` अनुमतियाँ प्रदान करें।
क्यों: Managed identity एक क्रेडेंशियल-लेस प्रमाणीकरण तंत्र प्रदान करती है। एप्लिकेशन Key Vault के लिए स्वचालित रूप से एक एक्सेस टोकन प्राप्त कर सकता है, जिससे रहस्यों का प्रबंधन समाप्त हो जाता है।
एक बड़े, जटिल इंफ्रास्ट्रक्चर-एज़-कोड परिनियोजन को छोटे, पुन: प्रयोज्य और रखरखाव योग्य घटकों में व्यवस्थित करें।
परिनियोजन को Bicep मॉड्यूल में रिफैक्टर करें, जिसमें प्रत्येक मॉड्यूल एक तार्किक इकाई (जैसे, नेटवर्किंग, कंप्यूट) का प्रतिनिधित्व करता है, और उन्हें एक मुख्य Bicep फ़ाइल से ऑर्केस्ट्रेट करें।
क्यों: मॉड्यूल कोड के पुन: उपयोग को बढ़ावा देते हैं, पठनीयता में सुधार करते हैं, और जटिल इंफ्रास्ट्रक्चर परिनियोजन के प्रबंधन को सरल बनाते हैं।
एक VNet के भीतर एप्लिकेशन टियर (वेब, ऐप, डेटा) को अलग करें, गैर-आसन्न टियर के बीच सीधे संचार को रोकें।
प्रत्येक टियर के लिए एक अलग सबनेट का उपयोग करें और ट्रैफ़िक प्रवाह को नियंत्रित करने के लिए प्रत्येक सबनेट पर Network Security Groups (NSGs) लागू करें।
क्यों: NSG स्रोत/गंतव्य IP श्रेणियों (सबनेट), पोर्ट और प्रोटोकॉल के आधार पर बारीक, स्टेटफुल फ़िल्टरिंग की अनुमति देते हैं, जिससे नेटवर्क माइक्रो-सेगमेंटेशन सक्षम होता है।
Microsoft बैकबोन नेटवर्क पर दो VNets को विभिन्न Azure क्षेत्रों में निजी तौर पर कनेक्ट करें।
दो VNets के बीच Global VNet Peering कॉन्फ़िगर करें।
क्यों: Global Peering एक VNet-to-VNet VPN कनेक्शन की तुलना में सरल, कम-विलंबता और उच्च-बैंडविड्थ वाला है। ट्रैफ़िक निजी Microsoft नेटवर्क पर रहता है।
VNet-A Hub-VNet से पीयर किया गया है, और Spoke-VNet भी Hub-VNet से पीयर किया गया है। VNet-A में VMs Spoke-VNet में VMs तक नहीं पहुँच सकते।
इसका कारण यह है कि VNet पीयरिंग गैर-संक्रमणीय है। संचार सक्षम करने के लिए, VNet-A और Spoke-VNet को सीधे पीयर करें या Hub में एक NVA का उपयोग करें।
क्यों: पीयरिंग एक डेज़ी-चेन नहीं बनाती है। प्रत्येक VNet को सीधे कनेक्ट होना चाहिए ताकि संचार हो सके, जब तक कि Network Virtual Appliance के माध्यम से राउटिंग कॉन्फ़िगर न हो।
सार्वजनिक इंटरनेट पर एक ऑन-प्रिमाइसेस नेटवर्क से Azure VNet तक एक स्थायी, एन्क्रिप्टेड IPsec टनल स्थापित करें।
VNet में एक Azure VPN Gateway परिनियोजित करें और एक Site-to-Site (S2S) कनेक्शन कॉन्फ़िगर करें।
क्यों: यह एक एकल ऑन-प्रिमाइसेस साइट और Azure VNet के बीच हाइब्रिड कनेक्टिविटी के लिए मानक, सुरक्षित और विश्वसनीय समाधान है।
एक Azure Load Balancer अस्वस्थ बैकएंड VM को ट्रैफ़िक भेजता रहता है, जिससे एप्लिकेशन टाइमआउट होता है।
लोड बैलेंसर पर एक हेल्थ प्रोब कॉन्फ़िगर करें जो बैकएंड VMs पर एप्लिकेशन के स्वास्थ्य की सटीक जाँच करता है।
क्यों: लोड बैलेंसर अस्वस्थ इंस्टेंस का पता लगाने के लिए पूरी तरह से हेल्थ प्रोब पर निर्भर करता है। सही ढंग से कॉन्फ़िगर किए गए प्रोब के बिना, यह ट्रैफ़िक रोटेशन से विफल VMs को हटा नहीं सकता है।
URL पथ के आधार पर HTTP/S ट्रैफ़िक को विभिन्न बैकएंड सर्वर पूल में रूट करें (जैसे, /images/* बनाम /api/*)।
पाथ-आधारित राउटिंग नियमों के साथ Azure Application Gateway का उपयोग करें।
क्यों: Application Gateway एक Layer 7 लोड बैलेंसर है जो HTTP अनुरोधों का निरीक्षण करता है और URL पथों के आधार पर राउटिंग निर्णय ले सकता है। एक मानक Azure Load Balancer Layer 4 है और ऐसा नहीं कर सकता।
कस्टम DNS सर्वर वाले VNet में VMs एक Azure Private DNS Zone में होस्टनाम को हल नहीं कर सकते।
कस्टम DNS सर्वर को निजी ज़ोन के लिए प्रश्नों को Azure-प्रदत्त DNS रिजॉल्वर IP (168.63.129.16) पर सशर्त रूप से फॉरवर्ड करने के लिए कॉन्फ़िगर करें।
क्यों: जब एक कस्टम DNS सर्वर का उपयोग किया जाता है, तो यह Azure के आंतरिक DNS को बायपास करता है। कस्टम सर्वर को Azure DNS पर अनुरोधों को फॉरवर्ड करके Azure-विशिष्ट ज़ोन को कैसे हल किया जाए, यह सिखाया जाना चाहिए।
स्पोक VNets से सभी इंटरनेट-बाउंड ट्रैफ़िक को हब VNet में एक केंद्रीय Azure Firewall द्वारा निरीक्षण के लिए बाध्य करें।
स्पोक सबनेट पर User-Defined Route (UDR) के साथ एक Route Table लागू करें। UDR फ़ायरवॉल के निजी IP को इंगित करने वाला एक डिफ़ॉल्ट मार्ग (0.0.0.0/0) है।
क्यों: एक UDR इंटरनेट के लिए Azure के डिफ़ॉल्ट सिस्टम मार्ग को ओवरराइड करता है, जिससे आप सुरक्षा निरीक्षण के लिए egress ट्रैफ़िक प्रवाह को नियंत्रित और केंद्रीकृत कर सकते हैं।
सार्वजनिक IP पते वाले VMs को सुरक्षित RDP/SSH पहुँच प्रदान करें, बिना VPN कॉन्फ़िगर किए।
VNet में एक समर्पित सबनेट (AzureBastionSubnet) में Azure Bastion परिनियोजित करें।
क्यों: Bastion एक प्रबंधित जंप बॉक्स सेवा प्रदान करता है, जो TLS पर Azure पोर्टल के माध्यम से सुरक्षित प्रशासनिक पहुँच की अनुमति देता है, जिससे VMs पर सार्वजनिक IP एक्सपोज़र समाप्त हो जाता है।
यह सुनिश्चित करें कि एक VM और एक PaaS सेवा (जैसे, Azure SQL) के बीच ट्रैफ़िक निजी नेटवर्क पर रहता है और PaaS सेवा सार्वजनिक रूप से पहुँच योग्य नहीं है।
VM के VNet में PaaS सेवा के लिए एक Private Endpoint बनाएँ और PaaS सेवा पर सार्वजनिक नेटवर्क पहुँच अक्षम करें।
क्यों: एक Private Endpoint PaaS सेवा को आपके VNet के भीतर एक निजी IP देता है, जबकि सार्वजनिक पहुँच को अक्षम करने से यह सुनिश्चित होता है कि यह केवल उस निजी IP के माध्यम से पहुँच योग्य है।
सबसे कम संभावित विलंबता सुनिश्चित करने के लिए वैश्विक उपयोगकर्ताओं को निकटतम क्षेत्रीय एप्लिकेशन एंडपॉइंट पर रूट करें।
"Performance" राउटिंग विधि के साथ Azure Traffic Manager का उपयोग करें।
क्यों: Performance राउटिंग विधि DNS का उपयोग ग्राहकों को उनके स्थान से सबसे कम नेटवर्क विलंबता वाले एंडपॉइंट पर निर्देशित करने के लिए करती है।
जब एक संसाधन मेट्रिक (जैसे, VM CPU प्रतिशत) एक निर्धारित अवधि के लिए एक सीमा से अधिक हो जाता है, तो एक अधिसूचना (ईमेल, SMS, वेबहुक) भेजें।
Azure Monitor में एक Metric Alert नियम बनाएँ और इसे एक Action Group से लिंक करें जो अधिसूचना कार्रवाई को परिभाषित करता है।
क्यों: यह मानक पैटर्न है। अलर्ट नियम शर्त (क्या/कब) को परिभाषित करता है, और एक्शन समूह परिणामी अधिसूचना (कौन/कैसे) को परिभाषित करता है।
यह निर्धारित करें कि दो VMs के बीच ट्रैफ़िक एक विशिष्ट Network Security Group (NSG) नियम द्वारा ब्लॉक किया जा रहा है या नहीं।
Azure Network Watcher में IP Flow Verify टूल का उपयोग करें।
क्यों: IP Flow Verify एक पैकेट प्रवाह का अनुकरण करता है और स्पष्ट रूप से रिपोर्ट करता है कि कौन सा NSG और नियम ट्रैफ़िक को अनुमति दे रहा है या अस्वीकार कर रहा है, जिससे यह NSG संघर्षों के निवारण के लिए निश्चित उपकरण बन जाता है।
एप्लिकेशन संगति और दीर्घकालिक प्रतिधारण के साथ Azure VMs के लिए निर्धारित, नीति-आधारित बैकअप कॉन्फ़िगर करें।
एक Recovery Services vault बनाएँ, एक बैकअप नीति (शेड्यूल, प्रतिधारण) परिभाषित करें, और लक्ष्य VMs के लिए बैकअप सक्षम करें।
क्यों: Recovery Services vault Azure Backup के लिए केंद्रीय प्रबंधन इकाई है। यह बैकअप डेटा को सुरक्षित रूप से संग्रहीत करता है और सभी बैकअप और पुनर्स्थापना संचालन का प्रबंधन करता है।
कई सब्सक्रिप्शन में VMs के प्रदर्शन (CPU, मेमोरी, डिस्क, नेटवर्क) की निगरानी के लिए एक केंद्रीकृत डैशबोर्ड बनाएँ।
एक केंद्रीय Log Analytics workspace परिनियोजित करें और सभी लक्ष्य VMs के लिए VM Insights सक्षम करें, उन्हें वर्कस्पेस की ओर इंगित करें।
क्यों: VM Insights प्रदर्शन डेटा एकत्र और समेकित करता है, प्री-बिल्ट वर्कबुक और सब्सक्रिप्शन में एक समेकित "एट-स्केल" प्रदर्शन दृश्य प्रदान करता है।
कम उपयोग किए गए Azure संसाधनों और लागत बचत के अवसरों (जैसे, VM राइट-साइजिंग) की सक्रिय रूप से पहचान करें।
Azure Advisor में लागत सिफारिशों की नियमित रूप से समीक्षा करें।
क्यों: Azure Advisor स्वचालित रूप से संसाधन उपयोग का विश्लेषण करता है और अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता के बिना लागत बचत के लिए कार्रवाई योग्य, व्यक्तिगत सिफारिशें प्रदान करता है।
आपदा रिकवरी क्षमता प्रदान करने के लिए Azure VMs को एक प्राथमिक क्षेत्र से एक सेकेंडरी क्षेत्र में प्रतिकृत करें।
Azure Site Recovery का उपयोग करें। एक Recovery Services vault बनाएँ और लक्ष्य क्षेत्र में VMs के लिए प्रतिकृति सक्षम करें।
क्यों: ASR Azure क्षेत्रों के बीच VM प्रतिकृति, फ़ेलओवर परीक्षण, और फ़ेलओवर/फ़ेलबैक को ऑर्केस्ट्रेट करने के लिए मूल Azure सेवा है।
लागत को अनुकूलित करने के लिए एक ही Log Analytics workspace के भीतर सुरक्षा लॉग और प्रदर्शन लॉग के लिए विभिन्न डेटा प्रतिधारण अवधियाँ सेट करें।
एक वर्कस्पेस-स्तरीय डिफ़ॉल्ट प्रतिधारण सेट करें और फिर व्यक्तिगत तालिका स्तर पर एक लंबी प्रतिधारण अवधि कॉन्फ़िगर करें (उदाहरण के लिए, SecurityEvent तालिका के लिए)।
क्यों: प्रति-तालिका प्रतिधारण आपको विशिष्ट डेटा के लिए दीर्घकालिक अनुपालन आवश्यकताओं को पूरा करने की अनुमति देता है, जबकि कम महत्वपूर्ण, उच्च-मात्रा वाले डेटा के लिए स्टोरेज लागत को कम करता है।