मार्गदर्शिका

कस्टम स्क्रिप्टिंग के बिना विफल ECS Fargate डिप्लॉयमेंट के लिए स्वचालित रोलबैक।

→ECS सर्विस पर रोलबैक के साथ ECS डिप्लॉयमेंट सर्किट ब्रेकर सक्षम करें।

क्यों: नेटिव ECS सुविधा जो नए कार्यों के स्थिर होने में विफल होने पर स्वचालित रूप से रोलबैक करती है। कस्टम CodeBuild पोलिंग या जटिल CodeDeploy सेटअप की तुलना में सबसे कम ऑपरेशनल ओवरहेड।

संदर्भ↗

प्राथमिक रीजन में डिप्लॉय करें, स्वचालित परीक्षणों से मान्य करें, फिर अन्य रीजनों में समानांतर डिप्लॉय करें।

→अनुक्रमिक चरणों के साथ एक एकल CodePipeline का उपयोग करें: (1) रीजन A डिप्लॉय करें, (2) एक CodeBuild परीक्षण चरण जो सत्यापन चलाता है, (3) रीजनों B और C के लिए एक समानांतर डिप्लॉय चरण।

क्यों: CodeBuild एक स्वचालित, प्रोग्रामेटिक गेट के रूप में कार्य करता है। स्टेप फंक्शन्स के साथ कई पाइपलाइन ऑर्केस्ट्रेट करने की तुलना में एक सिंगल पाइपलाइन सरल है।

CodeDeploy लाइफसाइकिल हुक में एक लंबे समय तक चलने वाली सत्यापन स्क्रिप्ट समय से पहले डिप्लॉयमेंट की सफलता का कारण बनती है।

→`AppSpec.yml` फ़ाइल में विशिष्ट लाइफसाइकिल हुक स्क्रिप्ट के लिए `timeout` प्रॉपर्टी बढ़ाएँ।

क्यों: टाइमआउट AppSpec फ़ाइल में प्रति-हुक कॉन्फ़िगर किया जाता है, न कि डिप्लॉयमेंट समूह स्तर पर। यह सुनिश्चित करता है कि सत्यापन स्क्रिप्ट के पास पूरा होने के लिए पर्याप्त समय हो।

हर रन पर निर्भरताओं और इमेज लेयर्स को फिर से डाउनलोड करने के कारण होने वाले धीमे CodeBuild Docker इमेज बिल्ड को तेज़ करें।

→CodeBuild प्रोजेक्ट कॉन्फ़िग में, `LOCAL_DOCKER_LAYER_CACHE` सक्षम करें और निर्भरता निर्देशिकाओं (जैसे, `.m2`, `node_modules`) के लिए एक S3 कैश कॉन्फ़िगर करें।

क्यों: सीधे धीमेपन के दोनों स्रोतों को संबोधित करता है। Docker लेयर कैशिंग अपरिवर्तित इमेज लेयर्स का पुन: उपयोग करती है; S3 कैशिंग डाउनलोड की गई एप्लिकेशन निर्भरताओं का पुन: उपयोग करती है।

स्वचालित, मीट्रिक-आधारित रोलबैक के साथ एक Lambda फ़ंक्शन के लिए कैनरी डिप्लॉयमेंट लागू करें।

→`DeploymentPreference` (उदाहरण के लिए, प्रकार `Canary10Percent5Minutes`) के साथ AWS SAM का उपयोग करें। रोलबैक ट्रिगर के रूप में `Errors` मीट्रिक पर एक CloudWatch अलार्म जोड़ें।

क्यों: SAM, Lambda के लिए CodeDeploy के साथ नेटिव रूप से एकीकृत होता है, कस्टम स्क्रिप्ट के बिना उपनाम ट्रैफ़िक शिफ्टिंग, मॉनिटरिंग और रोलबैक को स्वचालित करता है।

संदर्भ↗

Account A में एक CodePipeline के लिए IAM को कॉन्फ़िगर करें ताकि Account B में रिसोर्स डिप्लॉय किए जा सकें।

→पाइपलाइन भूमिका (खाता A) एक एक्शन भूमिका (खाता B) मानती है। B में एक्शन भूमिका पाइपलाइन भूमिका पर भरोसा करती है और उसके पास डिप्लॉय अनुमतियाँ होती हैं। A में S3 आर्टिफैक्ट बकेट और KMS कुंजी में B में एक्शन भूमिका को पहुंच प्रदान करने वाली संसाधन नीतियां होनी चाहिए।

क्यों: यह मानक, सुरक्षित क्रॉस-अकाउंट एक्सेस पैटर्न है: कार्यों के लिए भूमिका ग्रहण, डेटा एक्सेस के लिए संसाधन-आधारित नीतियां।

EKS के लिए एक GitOps वर्कफ़्लो लागू करें जहाँ क्लस्टर स्थिति Git रिपॉजिटरी के साथ स्वचालित रूप से और लगातार मेल खाती है।

→EKS क्लस्टर में एक GitOps कंट्रोलर (जैसे, Flux, ArgoCD) डिप्लॉय करें। इसे Git रिपॉजिटरी की निगरानी करने और परिवर्तनों को लागू/मेल खाने के लिए कॉन्फ़िगर करें।

क्यों: यह मानक "पुल-आधारित" GitOps पैटर्न है। इन-क्लस्टर कंट्रोलर निरंतर सुलह और ड्रिफ्ट डिटेक्शन को संभालता है, जो GitOps का मूल सिद्धांत है।

एक केंद्रीय टूलिंग खाते में एक CodeBuild प्रोजेक्ट को अलग-अलग वर्कलोड खातों में EKS क्लस्टर में Kubernetes मैनिफेस्ट डिप्लॉय करने की अनुमति दें।

→प्रत्येक वर्कलोड खाते में, CodeBuild भूमिका द्वारा विश्वसनीय एक क्रॉस-अकाउंट IAM भूमिका बनाएँ। इस नई भूमिका को EKS क्लस्टर के `aws-auth` ConfigMap में एक Kubernetes RBAC समूह में मैप करें। CodeBuild स्क्रिप्ट `kubectl` चलाने से पहले भूमिका ग्रहण करती है।

क्यों: यह क्रॉस-अकाउंट EKS एक्सेस के लिए मानक, सुरक्षित पैटर्न है। यह इस उद्देश्य के लिए एक समर्पित, विश्वसनीय भूमिका बनाकर न्यूनतम विशेषाधिकार का पालन करता है।

शून्य या लगभग शून्य डाउनटाइम के साथ एक जटिल RDS PostgreSQL या MySQL स्कीमा माइग्रेशन करें।

→Amazon RDS Blue/Green डिप्लॉयमेंट्स सुविधा का उपयोग करें। एक सिंक्रनाइज़्ड स्टेजिंग (ग्रीन) वातावरण बनाएँ, उस पर स्कीमा परिवर्तन लागू करें, और फिर उसे उत्पादन में बढ़ावा देने के लिए स्विच ओवर करें।

क्यों: यह सुरक्षित, शून्य-डाउनटाइम RDS अपडेट के लिए विशेष रूप से निर्मित, प्रबंधित सेवा है। यह क्लोनिंग, सिंक्रनाइज़ेशन, और बिल्ट-इन गार्डरेल के साथ एक तेज़ (< 1 मिनट) स्विचओवर को संभालता है।

एक सिंगल-पेज एप्लिकेशन (SPA) का एक नया संस्करण S3/CloudFront पर डिप्लॉय करें और सुनिश्चित करें कि उपयोगकर्ताओं को न्यूनतम कैश अमान्यकरण लागत के साथ तुरंत नया संस्करण प्राप्त हो।

→एसेट फ़ाइल नामों के लिए सामग्री-आधारित हैशिंग का उपयोग करें (जैसे, `app.a1b2c3d4.js`)। नए एसेट्स डिप्लॉय करने के बाद, CloudFront डिस्ट्रीब्यूशन में केवल `index.html` फ़ाइल को अमान्य करें।

क्यों: हैश किए गए फ़ाइल नाम अद्वितीय होते हैं, इसलिए CloudFront उन्हें नए ऑब्जेक्ट के रूप में मानता है और उन्हें मूल से प्राप्त करता है, कैश को बायपास करता है। केवल एकल प्रवेश बिंदु फ़ाइल (`index.html`) को अमान्य करने की आवश्यकता होती है, जो वाइल्डकार्ड (`/*`) अमान्यकरण की तुलना में काफी सस्ता है।

एक AWS CDK एप्लिकेशन के लिए एक CI/CD पाइपलाइन लागू करें जो पाइपलाइन की अपनी परिभाषा बदलने पर स्वचालित रूप से खुद को अपडेट करती है।

→CDK Pipelines कंस्ट्रक्ट (`pipelines.CodePipeline`) का उपयोग करें। यह कंस्ट्रक्ट एक पाइपलाइन बनाता है जिसमें डिफ़ॉल्ट रूप से एक `SelfMutate` चरण शामिल होता है।

क्यों: CDK Pipelines इस पैटर्न के लिए विशेष रूप से निर्मित एक उच्च-स्तरीय कंस्ट्रक्ट है। `SelfMutate` चरण सुनिश्चित करता है कि एप्लिकेशन परिवर्तनों को डिप्लॉय करने से पहले पाइपलाइन हमेशा कोड से नवीनतम परिभाषा को दर्शाती है।

एक नया एप्लिकेशन संस्करण डिप्लॉय करें जिसके लिए शून्य डाउनटाइम के साथ पिछड़े-संगत डेटाबेस स्कीमा परिवर्तन (जैसे, नए कॉलम जोड़ना) की आवश्यकता होती है।

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

क्यों: यह पैटर्न डेटाबेस और एप्लिकेशन डिप्लॉयमेंट को अलग करता है, यह सुनिश्चित करता है कि डेटाबेस स्थिति हमेशा पुराने और नए दोनों एप्लिकेशन संस्करणों के साथ संगत हो, जिससे शून्य-डाउनटाइम रोलआउट सक्षम हो सके।

विशिष्ट उपयोगकर्ता खंडों के लिए एक नई सुविधा को धीरे-धीरे रोल आउट करें और A/B परीक्षण का उपयोग करके व्यावसायिक मेट्रिक्स (जैसे, रूपांतरण दर) पर प्रभाव को मापें।

→Amazon CloudWatch Evidently का उपयोग करें। कई विविधताओं के साथ एक सुविधा बनाएँ, रोलआउट प्रतिशत को नियंत्रित करने के लिए एक लॉन्च, और परिभाषित मेट्रिक्स पर सांख्यिकीय प्रभाव को मापने के लिए एक प्रयोग।

क्यों: Evidently फीचर फ़्लैगिंग और A/B प्रयोग के लिए एक विशेष रूप से निर्मित सेवा है, जो न केवल रोलआउट तंत्र बल्कि प्रभाव को मापने के लिए सांख्यिकीय विश्लेषण इंजन भी प्रदान करती है।

एक AWS Organization में लॉन्च के समय सभी EC2 इंस्टेंस पर अनिवार्य टैग लागू करें।

→एक Service Control Policy (SCP) का उपयोग करें जो `ec2:RunInstances` को तब तक अस्वीकार करता है जब तक कि अनुरोध में आवश्यक टैग कुंजी मौजूद न हों।

क्यों: नॉन-कम्प्लाइंट रिसोर्स को बनने से रोकने वाला निवारक नियंत्रण। सभी खातों पर लागू होता है और स्थानीय IAM नीतियों द्वारा ओवरराइड नहीं किया जा सकता।

संदर्भ↗

कई खातों में एप्लिकेशन द्वारा उपयोग किए जाने वाले रहस्य (जैसे, DB क्रेडेंशियल) को बिना डाउनटाइम के प्रबंधित और घुमाएँ।

→स्वचालित रोटेशन सक्षम के साथ AWS Secrets Manager का उपयोग करें। रहस्य पर संसाधन-आधारित नीतियों का उपयोग करके क्रॉस-अकाउंट पहुंच प्रदान करें।

क्यों: Secrets Manager शून्य-डाउनटाइम रोटेशन रणनीतियों (उपयोगकर्ताओं को वैकल्पिक करना) का समर्थन करता है और सुरक्षित, नेटिव क्रॉस-अकाउंट साझाकरण प्रदान करता है।

Control Tower Account Factory के माध्यम से बनाए गए नए खातों में स्वचालित रूप से बेसलाइन सुरक्षा संसाधन डिप्लॉय करें।

→EventBridge के माध्यम से Control Tower लाइफसाइकिल इवेंट `CreateManagedAccount` का उपयोग करें ताकि एक Lambda फ़ंक्शन को ट्रिगर किया जा सके जो एक CloudFormation StackSet को डिप्लॉय करता है। वैकल्पिक रूप से, Customizations for AWS Control Tower (CfCT) का उपयोग करें।

क्यों: इवेंट-ड्रिवन ऑटोमेशन खाता बनाने के बाद मैन्युअल हस्तक्षेप के बिना कंट्रोल टॉवर बेसलाइन का विस्तार करने के लिए मानक, स्केलेबल पैटर्न है।

बिना इंटरनेट एक्सेस वाले निजी सबनेट में EC2 इंस्टेंस तक SSM Session Manager एक्सेस सक्षम करें।

→VPC में `ssm`, `ssmmessages`, और `ec2messages` सेवाओं के लिए VPC इंटरफ़ेस एंडपॉइंट (PrivateLink द्वारा संचालित) बनाएँ।

क्यों: VPC एंडपॉइंट SSM एजेंट को AWS नेटवर्क के भीतर पूरी तरह से सेवा के साथ संवाद करने की अनुमति देते हैं, NAT या इंटरनेट गेटवे की आवश्यकता के बिना सबसे सुरक्षित एक्सेस पैटर्न प्रदान करते हैं।

लंबे समय तक प्रतिधारण के साथ लॉग को केंद्रीकृत करें और उन्हें हटाए जाने या संशोधित होने से बचाएँ, यहां तक ​​कि प्रशासकों द्वारा भी।

→कंप्लायंस मोड में S3 Object Lock के साथ एक S3 बकेट में लॉग स्टोर करें। CloudTrail लॉग फ़ाइल अखंडता सत्यापन सक्षम करें।

क्यों: ऑब्जेक्ट लॉक (कंप्लायंस मोड) WORM सुरक्षा प्रदान करता है जिसे रूट अकाउंट भी बायपास नहीं कर सकता। लॉग फ़ाइल अखंडता सत्यापन डिलीवरी के बाद छेड़छाड़ के लिए एक क्रिप्टोग्राफिक जाँच प्रदान करता है।

डेवलपर्स को पूर्ण AWS सेवा अनुमतियाँ दिए बिना पूर्व-अनुमोदित इन्फ्रास्ट्रक्चर पैटर्न को प्रावधान करने का एक स्व-सेवा तरीका प्रदान करें।

→AWS Service Catalog का उपयोग करें। अनुमोदित उत्पादों (CloudFormation टेम्प्लेट द्वारा परिभाषित) का एक पोर्टफोलियो बनाएँ। लॉन्च बाधाओं का उपयोग करें ताकि सर्विस कैटलॉग प्लेटफॉर्म टीम द्वारा प्रबंधित एक विशेषाधिकार प्राप्त IAM भूमिका का उपयोग करके संसाधनों का प्रावधान करे।

क्यों: सर्विस कैटलॉग IT सेवाओं के क्यूरेटेड कैटलॉग बनाने के लिए विशेष रूप से निर्मित AWS सेवा है। लॉन्च बाधाएं प्रमुख शासन सुविधा हैं, जो डेवलपर्स को अंतर्निहित अनुमतियों के बिना जटिल इन्फ्रास्ट्रक्चर को प्रावधान करने की अनुमति देती हैं।

ECS कार्यों के रूप में चलने वाले विभिन्न माइक्रोसर्विसेज को सुरक्षित रूप से अद्वितीय रहस्य प्रदान करें, यह सुनिश्चित करते हुए कि प्रत्येक सेवा केवल अपने स्वयं के रहस्यों तक पहुंच सकती है।

→प्रत्येक सेवा के लिए अलग AWS Secrets Manager रहस्य बनाएँ। ECS कार्य परिभाषा में, कंटेनर परिभाषा के `secrets` प्रॉपर्टी में रहस्य ARNs को संदर्भित करें। कार्य निष्पादन IAM भूमिका नीति को केवल उस सेवा के विशिष्ट रहस्य ARN पर `secretsmanager:GetSecretValue` की अनुमति देने के लिए स्कोप करें।

क्यों: यह कई परतों पर न्यूनतम विशेषाधिकार के सिद्धांत को लागू करता है: रहस्य स्वयं, IAM नीति, और ECS कार्य परिभाषा। रहस्य रनटाइम पर सुरक्षित रूप से इंजेक्ट किए जाते हैं।

एक GitHub Actions वर्कफ़्लो को लंबे समय तक चलने वाले क्रेडेंशियल संग्रहीत किए बिना AWS तक सुरक्षित रूप से पहुंचने की अनुमति दें।

→GitHub के लिए एक IAM OIDC पहचान प्रदाता कॉन्फ़िगर करें। एक ट्रस्ट नीति के साथ एक IAM भूमिका बनाएँ जो फेडरेटेड प्रिंसिपल को विशिष्ट GitHub संगठन, रिपॉजिटरी और ब्रांच तक सीमित करती है। भूमिका ग्रहण करने के लिए OIDC के साथ `aws-actions/configure-aws-credentials` एक्शन का उपयोग करें।

क्यों: OIDC फेडरेशन सबसे सुरक्षित तरीका है, जो एक विशिष्ट वर्कफ़्लो रन तक सीमित अल्पकालिक क्रेडेंशियल प्रदान करता है, जिससे लंबे समय तक चलने वाले क्रेडेंशियल जोखिम का खतरा समाप्त हो जाता है।

एक AWS Organization में सभी IAM नीतियों की लगातार निगरानी करें ताकि बाहरी संस्थाओं के साथ साझा किए गए संसाधनों की पहचान की जा सके और उनके बारे में अलर्ट किया जा सके।

→संगठन को विश्वास के क्षेत्र के रूप में परिभाषित करते हुए, संगठन स्तर पर IAM Access Analyzer सक्षम करें। नई खोजों को कैप्चर करने और सूचनाओं को ट्रिगर करने के लिए EventBridge का उपयोग करें।

क्यों: IAM Access Analyzer विशेष रूप से स्वचालित तर्क का उपयोग करके बाहरी रूप से साझा किए गए संसाधनों को खोजने के लिए बनाया गया है। इसे संगठन स्तर पर चलाने से कस्टम स्क्रिप्टिंग के बिना एक सतत, केंद्रीकृत दृश्य प्राप्त होता है।

मोनोलिथिक या नेस्टेड स्टैक आर्किटेक्चर में विफल CloudFormation अपडेट के ब्लास्ट रेडियस को कम करें।

→क्रॉस-स्टैक रेफरेंस (CloudFormation Exports/Fn::ImportValue) का उपयोग करके आर्किटेक्चर को स्वतंत्र स्टैक में विघटित करें।

क्यों: एक स्टैक (उदाहरण के लिए, डेटाबेस) में विफलता अन्य सफलतापूर्वक अपडेट किए गए स्टैक (उदाहरण के लिए, नेटवर्किंग) के रोलबैक को ट्रिगर नहीं करेगी, जिससे विफलता डोमेन अलग हो जाएंगे।

उत्पादन और गैर-उत्पादन वातावरण के लिए अलग-अलग शेड्यूल के साथ क्रॉस-अकाउंट पैचिंग को केंद्रीय रूप से प्रबंधित करें।

→कस्टम पैच बेसलाइन, प्रत्येक वातावरण के लिए अलग रखरखाव विंडो, और केंद्रीकृत अनुपालन रिपोर्टिंग के लिए Systems Manager Explorer के साथ AWS Systems Manager Patch Manager का उपयोग करें।

क्यों: सभी आवश्यकताओं का नेटिव रूप से समर्थन करता है: कस्टम पैच परिभाषाएँ, रखरखाव विंडो के माध्यम से लचीली शेड्यूलिंग, और Explorer के माध्यम से क्रॉस-अकाउंट दृश्यता।

CloudFormation StackSet अपडेट निष्पादित करने से पहले सभी लक्ष्य खातों में इन्फ्रास्ट्रक्चर परिवर्तनों का पूर्वावलोकन करें।

→निष्पादन से पहले StackSet ऑपरेशन के लिए एक CloudFormation चेंज सेट बनाएँ और उसकी समीक्षा करें।

क्यों: चेंज सेट, स्टैक अपडेट द्वारा किए जाने वाले सटीक संसाधन परिवर्तनों (जोड़ें, संशोधित करें, हटाएँ) का पूर्वावलोकन करने के लिए नेटिव CloudFormation तंत्र हैं।

सुनिश्चित करें कि CloudFormation स्टैक निर्माण के साथ आगे बढ़ने से पहले एक EC2 इंस्टेंस की UserData स्क्रिप्ट के सफलतापूर्वक पूरा होने का इंतजार करता है।

→EC2 इंस्टेंस रिसोर्स में `ResourceSignal` के साथ एक `CreationPolicy` जोड़ें। सफल समापन पर UserData से `cfn-signal` हेल्पर स्क्रिप्ट को कॉल करें।

क्यों: यह एक संसाधन पर कॉन्फ़िगरेशन स्क्रिप्ट के साथ समन्वय स्थापित करने के लिए नेटिव CloudFormation तंत्र है। टाइमआउट के भीतर सिग्नल करने में विफलता स्वचालित रूप से स्टैक रोलबैक को ट्रिगर करती है।

पता लगाएँ कि कब मैन्युअल रूप से किए गए, आउट-ऑफ-बैंड परिवर्तनों के कारण डिप्लॉय किए गए संसाधन उनकी CloudFormation टेम्पलेट परिभाषा से भिन्न होते हैं।

→स्टैक पर CloudFormation ड्रिफ्ट डिटेक्शन को समय-समय पर चलाएँ। निरंतर पहचान के लिए, `cloudformation-stack-drift-detection-check` AWS Config नियम का उपयोग करें।

क्यों: ड्रिफ्ट डिटेक्शन, एक स्टैक के टेम्पलेट की उसके संसाधनों की वास्तविक स्थिति से तुलना करने के लिए नेटिव सुविधा है। Config नियम का उपयोग इस जाँच को स्वचालित करता है।

CloudFormation स्टैक ऑपरेशंस के माध्यम से आकस्मिक विलोपन या प्रतिस्थापन से स्टेटफुल रिसोर्स (जैसे, एक S3 बकेट या RDS डेटाबेस) को सुरक्षित रखें।

→रिसोर्स पर, `DeletionPolicy: Retain` (या RDS के लिए `Snapshot`) सेट करें। स्टैक पर, `TerminationProtection` सक्षम करें। एक `StackPolicy` लागू करें जो महत्वपूर्ण रिसोर्स पर `Update:Replace` और `Update:Delete` कार्यों को अस्वीकार करता है।

क्यों: गहराई में रक्षा प्रदान करता है: टर्मिनेशन प्रोटेक्शन स्टैक विलोपन को रोकता है, DeletionPolicy स्टैक हटा दिए जाने पर रिसोर्स को संरक्षित करता है, और स्टैक नीति विनाशकारी अपडेट को रोकती है।

एक CloudFormation StackSet को एक जटिल, स्व-प्रबंधित IAM भूमिका मॉडल से AWS Organization के लिए एक सरल अनुमति मॉडल में माइग्रेट करें।

→StackSet को सेवा-प्रबंधित अनुमतियों का उपयोग करने के लिए अपडेट करें।

क्यों: सेवा-प्रबंधित अनुमतियाँ ऑर्गेनाइजेशंस के विश्वसनीय एक्सेस का लाभ उठाती हैं, जिससे प्रत्येक लक्ष्य खाते में IAM भूमिकाएँ बनाने और प्रबंधित करने की आवश्यकता समाप्त हो जाती है। यह लक्षित OUs में जोड़े गए नए खातों में स्वचालित डिप्लॉयमेंट को भी सक्षम बनाता है।

एक CloudFormation कस्टम रिसोर्स को एक ऐसे कार्य को प्रबंधित करने की आवश्यकता है जिसमें 15 मिनट के Lambda फ़ंक्शन टाइमआउट से अधिक समय लगता है।

→कस्टम रिसोर्स के Lambda फ़ंक्शन से एक AWS Step Functions स्टेट मशीन को ट्रिगर करें। स्टेट मशीन वेट स्टेट्स या टास्क टोकन पैटर्न का उपयोग करके लंबे समय तक चलने वाले कार्य को संभालती है और प्रतिक्रिया को CloudFormation के S3 प्रीसाइन्ड URL पर वापस भेजती है।

क्यों: स्टेप फंक्शन्स को लंबे समय तक चलने वाले, मल्टी-स्टेप वर्कफ़्लो को ऑर्केस्ट्रेट करने के लिए डिज़ाइन किया गया है, जो CloudFormation के साथ एकीकरण बनाए रखते हुए Lambda टाइमआउट सीमा को प्रभावी ढंग से बायपास करता है।

एक पूरे AWS CDK एप्लिकेशन में एक नीति (जैसे, सभी S3 बकेट में संस्करण होना चाहिए) को केंद्रीय रूप से लागू करें, भले ही डेवलपर्स अपने संसाधनों को कैसे परिभाषित करें।

→एक CDK पहलू बनाएँ जो `IAspect` इंटरफ़ेस को लागू करता है। यह पहलू एप्लिकेशन ट्री में सभी कंस्ट्रक्ट्स का दौरा करता है, सभी S3 बकेट कंस्ट्रक्ट्स को ढूंढता है, और आवश्यक कॉन्फ़िगरेशन लागू करता है या यदि यह अनुपस्थित है तो एक सत्यापन त्रुटि जोड़ता है।

क्यों: पहलू क्रॉस-कटिंग चिंताओं को लागू करने और व्यक्तिगत कंस्ट्रक्ट्स को संशोधित किए बिना नीति-एज़-कोड सत्यापन को केंद्रीय रूप से लागू करने के लिए आधिकारिक CDK पैटर्न हैं।

स्वचालित ऑपरेशंस, जैसे SSM मेंटेनेंस विंडोज के माध्यम से पैचिंग, को विशिष्ट, बदलते समय अवधियों (जैसे, एक त्रैमासिक वित्तीय ब्लैकआउट) के दौरान चलने से रोकें।

→ब्लैकआउट अवधियों को "बंद" के रूप में चिह्नित करने वाले इवेंट्स को परिभाषित करने के लिए SSM चेंज कैलेंडर का उपयोग करें। चेंज कैलेंडर को मेंटेनेंस विंडो से संबद्ध करें।

क्यों: चेंज कैलेंडर ऑटोमेशन के लिए एक गेट के रूप में कार्य करता है। यह मेंटेनेंस विंडो शेड्यूल में मैन्युअल परिवर्तनों की आवश्यकता के बिना "बंद" अवधियों के दौरान निष्पादन को स्वचालित रूप से ब्लॉक करता है, जिससे गतिशील ब्लैकआउट अवधियों के प्रबंधन के लिए यह अत्यधिक कुशल हो जाता है।

EC2 इंस्टेंस के बेड़े में एक कस्टम सॉफ़्टवेयर पैकेज (जैसे, एक मॉनिटरिंग एजेंट) की स्थापना और संस्करण को केंद्रीय रूप से प्रबंधित करें।

→SSM Distributor का उपयोग करके सॉफ़्टवेयर को पैकेज करें। SSM State Manager का उपयोग करके एक एसोसिएशन बनाएँ जो Distributor पैकेज को सभी लक्षित इंस्टेंस पर लागू करता है।

क्यों: Distributor पैकेज लाइफसाइकिल (संस्करणों सहित) का प्रबंधन करता है। State Manager सुनिश्चित करता है कि वांछित स्थिति (जैसे, "एजेंट का संस्करण 1.2 स्थापित है") लगातार लागू होती है, स्वचालित रूप से ड्रिफ्ट को ठीक करती है और नए इंस्टेंस को कॉन्फ़िगर करती है।

रीजनों में एक Aurora डेटाबेस और एप्लिकेशन टियर के लिए कम RPO (< 1 मिनट) और RTO (< 5 मिनट) आपदा रिकवरी।

→सब-सेकंड डेटाबेस प्रतिकृति के लिए एक Aurora Global Database का उपयोग करें। ऐप टियर के लिए, एक "वार्म स्टैंडबाय" का उपयोग करें जिसमें Auto Scaling समूह को 0 वांछित क्षमता पर सेट किया गया हो, जिसे फेलओवर पर ऑटोमेशन के माध्यम से बढ़ाया जा सके।

क्यों: Aurora Global Database सब-सेकंड RPO और < 1-मिनट RTO प्रदान करता है। वार्म स्टैंडबाय ऐप टियर लागत प्रभावी है जबकि अभी भी एक तेज़ RTO को पूरा करता है।

लंबे बूटस्ट्रैप/इनिशियलाइज़ेशन समय वाले इंस्टेंस के लिए Auto Scaling समूह के स्केल-आउट समय को कम करें।

→निर्भरताओं के साथ एक प्री-बेक्ड "गोल्डन AMI" बनाएँ। इंस्टेंस को पूर्व-आरंभिक रखने के लिए Auto Scaling समूह पर एक वार्म पूल कॉन्फ़िगर करें।

क्यों: एक गोल्डन AMI बूटस्ट्रैप समय को कम करता है। एक वार्म पूल लॉन्च समय (स्टार्ट बनाम लॉन्च) को कम करता है। साथ में, वे एक नए इंस्टेंस के ट्रैफ़िक को सेवा देने के लिए तैयार होने के समय को नाटकीय रूप से कम करते हैं।

एक ECS सेवा अपने कार्य गणना को बढ़ाती है, लेकिन अंतर्निहित EC2 क्लस्टर की क्षमता समाप्त होने के कारण नए कार्यों को नहीं रख पाती है।

→EC2 Auto Scaling समूह और ECS क्लस्टर के साथ एक क्षमता प्रदाता को संबद्ध करके ECS क्लस्टर Auto Scaling सक्षम करें।

क्यों: क्षमता प्रदाता ECS सेवा स्केलिंग को EC2 इंस्टेंस स्केलिंग से जोड़ते हैं। जब अपर्याप्त क्लस्टर संसाधनों के कारण कार्य रखने में विफल होते हैं, तो क्षमता प्रदाता स्वचालित रूप से EC2 ASG को स्केल आउट करता है।

एक SQS क्यू में संदेशों की संख्या के आधार पर EC2 वर्कर इंस्टेंस के बेड़े को गतिशील रूप से स्केल करें।

→कस्टम मीट्रिक पर आधारित एक लक्ष्य ट्रैकिंग Auto Scaling नीति का उपयोग करें: `ApproximateNumberOfMessagesVisible` / `GroupInServiceInstances` (यानी, प्रति इंस्टेंस बैकलॉग)।

क्यों: यह SQS-आधारित स्केलिंग के लिए अनुशंसित पैटर्न है। यह एक लक्ष्य समय के भीतर बैकलॉग को संसाधित करने के लिए पर्याप्त श्रमिक बनाए रखता है, क्यू गहराई के साथ कुशलता से स्केलिंग करता है।

स्टेटफुल एप्लिकेशन के लिए EBS वॉल्यूम के एप्लिकेशन-कंसिस्टेंट (केवल क्रैश-कंसिस्टेंट नहीं) स्नैपशॉट बनाएँ।

→एक बैकअप योजना के साथ AWS Backup का उपयोग करें। योजना में, एप्लिकेशन को शांत करने के लिए (या विंडोज के लिए VSS सक्षम करें) प्री-स्नैपशॉट स्क्रिप्ट निष्पादित करने के लिए Systems Manager Run Command का उपयोग करें।

क्यों: AWS Backup पूरी प्रक्रिया को ऑर्केस्ट्रेट करता है। स्नैपशॉट से पहले एप्लिकेशन को शांत करना (I/O बफर को डिस्क पर फ्लश करना) डेटा अखंडता और एक पुनर्प्राप्त करने योग्य एप्लिकेशन स्थिति सुनिश्चित करता है।

सुनिश्चित करें कि एक EventBridge नियम से महत्वपूर्ण इवेंट्स तब खो न जाएं जब एक लक्ष्य सेवा (जैसे, Lambda) अस्थायी रूप से अनुपलब्ध या थ्रॉटल हो।

→EventBridge नियम लक्ष्य पर, एक पुनः प्रयास नीति (उदाहरण के लिए, 24 घंटे की अधिकतम आयु) और एक SQS क्यू का उपयोग करके एक डेड-लेटर क्यू (DLQ) कॉन्फ़िगर करें।

क्यों: पुनः प्रयास नीति क्षणिक विफलताओं को स्वचालित रूप से संभालती है। DLQ एक अंतिम सुरक्षा जाल के रूप में कार्य करता है, उन घटनाओं को कैप्चर करता है जो सभी पुनः प्रयासों को समाप्त कर देती हैं ताकि उन्हें बाद में फिर से संसाधित किया जा सके, जिससे डेटा हानि को रोका जा सके।

विशिष्ट लॉग पैटर्न पर वास्तविक समय अलर्ट ट्रिगर करें और अधिसूचना में प्रासंगिक जानकारी (जैसे, आसपास की लॉग लाइनें) शामिल करें।

→मिलान करने वाले लॉग इवेंट्स को Lambda फ़ंक्शन में स्ट्रीम करने के लिए एक CloudWatch Logs सब्सक्रिप्शन फ़िल्टर का उपयोग करें। Lambda फ़ंक्शन एक विस्तृत अधिसूचना (जैसे, SNS या Chime को) को प्रारूपित और भेजता है।

क्यों: सब्सक्रिप्शन फ़िल्टर वास्तविक समय इवेंट स्ट्रीमिंग प्रदान करते हैं। Lambda कस्टम लॉजिक को संदर्भ निकालने और प्रारूपित करने की अनुमति देता है, जो सरल मीट्रिक फ़िल्टर नहीं कर सकते।

एक वितरित, माइक्रोसर्विसेज-आधारित एप्लिकेशन में लेटेंसी बॉटलनेक की पहचान करें।

→प्रवेश बिंदुओं (जैसे, API Gateway, ALB) और कंप्यूट (जैसे, Lambda, ECS) पर AWS X-Ray ट्रेसिंग सक्षम करें। डाउनस्ट्रीम कॉल के लिए X-Ray SDK का उपयोग करें। सर्विस मैप और ट्रेसेस का विश्लेषण करें।

क्यों: X-Ray वितरित ट्रेसिंग के लिए विशेष रूप से निर्मित AWS सेवा है। सर्विस मैप कॉल चेन को विज़ुअलाइज़ करता है और उच्च लेटेंसी और त्रुटि दरों वाली सेवाओं को हाइलाइट करता है।

अलर्ट शोर को कम करने के लिए एक मल्टी-टियर एप्लिकेशन के संयुक्त स्वास्थ्य का प्रतिनिधित्व करने वाला एक एकल, उच्च-स्तरीय अलार्म बनाएँ।

→प्रत्येक टियर (जैसे, ALB 5xx दर, ऐप CPU, RDS कनेक्शन) के लिए व्यक्तिगत CloudWatch अलार्म बनाएँ। फिर, उन्हें OR लॉजिक के साथ एक CloudWatch कंपोजिट अलार्म का उपयोग करके संयोजित करें।

क्यों: कंपोजिट अलार्म को कई अंतर्निहित अलार्म की स्थिति के आधार पर एक एकल, तार्किक अलार्म बनाकर अलार्म शोर को कम करने के लिए डिज़ाइन किया गया है।

जटिल SQL क्वेरीज़ (जोड़ों सहित) के साथ पेटबाइट्स लॉग का विश्लेषण करें और उन्हें लागत-प्रभावी तरीके से वर्षों तक बनाए रखें।

→Kinesis Data Firehose के माध्यम से Amazon S3 पर लॉग स्ट्रीम करें। AWS Glue के साथ डेटा को कैटलॉग करें। Amazon Athena के साथ क्वेरी करें। दीर्घकालिक प्रतिधारण के लिए डेटा को Glacier/Deep Archive में ट्रांज़िशन करने के लिए S3 Lifecycle नीतियों का उपयोग करें।

क्यों: यह मानक सर्वरलेस डेटा लेक आर्किटेक्चर है। Athena S3 डेटा पर शक्तिशाली SQL क्षमताएं प्रदान करता है, और S3/Glacier सबसे लागत प्रभावी दीर्घकालिक भंडारण प्रदान करता है।

अनुमानित चक्रीय पैटर्न (जैसे, दैनिक/साप्ताहिक स्पाइक्स) वाले मीट्रिक की निगरानी करें और पैटर्न से वास्तविक विचलन पर ही अलार्म ट्रिगर करें।

→मीट्रिक पर CloudWatch एनोमली डिटेक्शन कॉन्फ़िगर करें। एक अलार्म बनाएँ जो तब ट्रिगर होता है जब मीट्रिक मान मॉडल के अपेक्षित बैंड से बाहर चला जाता है।

क्यों: एनोमली डिटेक्शन मीट्रिक के सामान्य पैटर्न को सीखने के लिए मशीन लर्निंग का उपयोग करता है, एक गतिशील थ्रेशोल्ड बैंड बनाता है जो चक्रों के अनुकूल होता है। यह अनुमानित स्पाइक्स से गलत पॉजिटिव को कम करता है और सिग्नल-टू-नॉइज़ अनुपात में सुधार करता है।

EKS या ECS पर वर्कलोड के लिए कंटेनर-स्तर CPU, मेमोरी, डिस्क, और नेटवर्क मेट्रिक्स में व्यापक दृश्यता प्राप्त करें, बिना तीसरे पक्ष के टूल स्थापित और प्रबंधित किए।

→EKS/ECS क्लस्टर के लिए Amazon CloudWatch Container Insights सक्षम करें।

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

अंतिम-उपयोगकर्ताओं के दृष्टिकोण से एक इंटरनेट-फेसिंग एप्लिकेशन की उपलब्धता और प्रदर्शन की निगरानी करें, ISP-स्तर और भौगोलिक नेटवर्क समस्याओं की पहचान करें।

→एप्लिकेशन के लिए Amazon CloudWatch Internet Monitor सक्षम करें।

क्यों: इंटरनेट मॉनिटर AWS ग्लोबल नेटवर्क डेटा का लाभ उठाता है ताकि इंटरनेट मौसम में दृश्यता प्रदान की जा सके जो आपके अंतिम-उपयोगकर्ताओं को प्रभावित करता है, आपके AWS वातावरण के बाहर समस्याओं का निदान करने में मदद करता है।

वेब एप्लिकेशन के वास्तविक-उपयोगकर्ता अनुभव को पेज लोड समय, जावास्क्रिप्ट त्रुटियों और अन्य क्लाइंट-साइड प्रदर्शन मेट्रिक्स को एकत्र करके मापें।

→वेब एप्लिकेशन में CloudWatch RUM (Real User Monitoring) जावास्क्रिप्ट स्निपेट को एकीकृत करें।

क्यों: RUM एक प्रबंधित सेवा है जो सीधे उपयोगकर्ता ब्राउज़र से क्लाइंट-साइड प्रदर्शन और त्रुटि डेटा एकत्र करती है, सिंथेटिक परीक्षणों के बिना वास्तविक-उपयोगकर्ता अनुभव में सच्ची अंतर्दृष्टि प्रदान करती है।

उच्च रिज़ॉल्यूशन और आयामों के साथ एक AWS Lambda फ़ंक्शन से कस्टम एप्लिकेशन मेट्रिक्स उत्सर्जित करें, बिना सीधे CloudWatch API कॉल की लेटेंसी और लागत जोड़े।

→मानक आउटपुट पर विशेष रूप से संरचित JSON लिखकर CloudWatch एम्बेडेड मीट्रिक प्रारूप (EMF) का उपयोग करें। एक क्लाइंट लाइब्रेरी इसे सरल बना सकती है।

क्यों: CloudWatch Logs स्वचालित रूप से और अतुल्यकालिक रूप से EMF लॉग प्रविष्टियों से मेट्रिक्स निकालता है, जिससे Lambda फ़ंक्शन में कोई अतिरिक्त विलंबता नहीं होती है और PutMetricData API कॉल से बचकर लागत कम होती है।

AWS Config द्वारा पता लगाए गए अनएन्क्रिप्टेड EBS वॉल्यूम को स्वचालित रूप से ठीक करें, प्रक्रिया के दौरान डेटा निरंतरता सुनिश्चित करते हुए।

→Systems Manager Automation दस्तावेज़ के साथ AWS Config ऑटो-रेमेडिएशन का उपयोग करें। रनबुक इंस्टेंस को रोकता है, वॉल्यूम की एक एन्क्रिप्टेड प्रति बनाता है, वॉल्यूम स्वैप करता है, और इंस्टेंस को पुनरारंभ करता है।

क्यों: SSM ऑटोमेशन एक मजबूत, मल्टी-स्टेप, ऑडिटेबल वर्कफ़्लो प्रदान करता है। एन्क्रिप्टेड कॉपी बनाने से पहले डेटा-कंसिस्टेंट स्नैपशॉट सुनिश्चित करने के लिए इंस्टेंस को रोकना महत्वपूर्ण है।

स्वचालित स्टॉप स्थितियों के साथ नियंत्रित कैओस इंजीनियरिंग प्रयोग (जैसे, नेटवर्क लेटेंसी इंजेक्ट करना) चलाएँ ताकि उत्पादन पर प्रभाव को रोका जा सके।

→एक प्रयोग टेम्पलेट के साथ AWS Fault Injection Simulator (FIS) का उपयोग करें। प्रमुख एप्लिकेशन मेट्रिक्स की निगरानी करने वाले CloudWatch अलार्म के आधार पर स्टॉप स्थितियाँ परिभाषित करें।

क्यों: FIS कैओस इंजीनियरिंग के लिए विशेष रूप से निर्मित AWS सेवा है, जो सुरक्षा गार्डरेल (स्टॉप स्थितियाँ) और नियंत्रित फ़ॉल्ट इंजेक्शन कार्यों की एक कैटलॉग प्रदान करती है।

एक CloudFormation स्टैक `UPDATE_ROLLBACK_FAILED` स्थिति में फँसा हुआ है क्योंकि एक विफल अपडेट के दौरान एक संसाधन हटा दिया गया था या बदल दिया गया था, जिससे एक साफ रोलबैक रुक गया।

→`ContinueUpdateRollback` API एक्शन का उपयोग करें, `ResourcesToSkip` पैरामीटर में समस्याग्रस्त संसाधन की तार्किक ID निर्दिष्ट करें।

क्यों: यह रोलबैक को पूरा करने के लिए मानक रिकवरी प्रक्रिया है, CloudFormation को उस संसाधन को अनदेखा करने के लिए कहकर जिसे वह अब प्रबंधित नहीं कर सकता, स्टैक को एक स्थिर स्थिति में वापस लाते हुए।

महत्वपूर्ण सुरक्षा घटनाओं, जैसे कि रूट अकाउंट लॉगिन, IAM नीति परिवर्तन, या सुरक्षा समूह संशोधनों के घटित होने के कुछ ही मिनटों के भीतर सूचनाएँ प्राप्त करें।

→विशिष्ट CloudTrail प्रबंधन इवेंट पैटर्न से मेल खाने वाले Amazon EventBridge नियम बनाएँ और उन्हें अधिसूचना के लिए एक SNS विषय पर रूट करें।

क्यों: EventBridge लगभग वास्तविक समय में CloudTrail प्रबंधन इवेंट प्राप्त करता है, जो पोलिंग या लॉग-आधारित विधियों की तुलना में इवेंट-ड्रिवन सुरक्षा अलर्टिंग के लिए सबसे कम विलंबता प्रदान करता है।

एक उच्च-ट्रैफिक Lambda फ़ंक्शन को थ्रॉटल किया जा रहा है और जब यह स्केल करता है तो RDS डेटाबेस कनेक्शन को भी समाप्त कर रहा है।

→एक Lambda समवर्ती निष्पादन सीमा वृद्धि का अनुरोध करें। Lambda फ़ंक्शंस और RDS डेटाबेस के बीच Amazon RDS Proxy लागू करें।

क्यों: बढ़ी हुई समवर्तीता थ्रॉटलिंग को हल करती है। RDS Proxy सर्वरलेस एप्लिकेशन के लिए आवश्यक है, क्योंकि यह डेटाबेस कनेक्शन को पूल करता है और पुन: उपयोग करता है, जिससे बड़ी संख्या में क्षणिक कनेक्शनों से डेटाबेस को अभिभूत होने से रोका जा सके।

रीजनों के बीच स्वचालित DNS फेलओवर लागू करें और विफल रीजन के लिए एक स्वचालित रिकवरी रनबुक को ट्रिगर करें।

→संबंधित स्वास्थ्य जाँचों के साथ Route 53 फेलओवर रूटिंग का उपयोग करें। एक EventBridge नियम बनाएँ जो Route 53 स्वास्थ्य जाँच स्थिति परिवर्तन इवेंट को कैप्चर करता है और एक Systems Manager Automation रनबुक को ट्रिगर करता है।

क्यों: यह आर्किटेक्चर एक पूर्ण लचीलापन पैटर्न के लिए स्वचालित ट्रैफ़िक फेलओवर (Route 53) को इवेंट-ड्रिवन, स्वचालित घटना प्रतिक्रिया (EventBridge + SSM ऑटोमेशन) के साथ जोड़ता है।

एक RDS डेटाबेस को स्टोरेज से बाहर होने और एप्लिकेशन आउटेज का कारण बनने से रोकें।

→अधिकतम स्टोरेज थ्रेशोल्ड सेट करके RDS स्टोरेज ऑटोस्केलिंग सक्षम करें। एक द्वितीयक नियंत्रण के रूप में, `FreeStorageSpace` मीट्रिक पर एक CloudWatch अलार्म बनाएँ।

क्यों: स्टोरेज ऑटोस्केलिंग एक सक्रिय, प्रबंधित सुविधा है जो स्वचालित रूप से आवंटित स्टोरेज को बढ़ाती है। CloudWatch अलार्म निगरानी और अलर्टिंग के लिए एक सुरक्षा जाल प्रदान करता है।

उपभोक्ता में एक अस्थायी बग के कारण गलत तरीके से संसाधित किए गए इवेंट्स के एक बैच को फिर से संसाधित करने की आवश्यकता है।

→इवेंट बस पर पहले से एक EventBridge आर्काइव कॉन्फ़िगर करें। बग ठीक होने के बाद, घटना के विशिष्ट समय विंडो से इवेंट्स को फिर से भेजने के लिए एक रीप्ले बनाएँ।

क्यों: आर्काइव और रीप्ले ऐतिहासिक इवेंट्स को संग्रहीत और पुन: संसाधित करने के लिए नेटिव EventBridge सुविधा है, जो क्षणिक प्रसंस्करण विफलताओं से रिकवरी के लिए महत्वपूर्ण है।

पूरी घटना प्रतिक्रिया प्रक्रिया को स्वचालित करें: एक घटना बनाएँ, ऑन-कॉल टीम को संलग्न करें, एक चैट चैनल खोलें, और जब एक महत्वपूर्ण अलार्म बजता है तो एक सुधार रनबुक निष्पादित करें।

→एक SSM इंसिडेंट मैनेजर प्रतिक्रिया योजना बनाएँ जो सभी जुड़ाव और सुधार चरणों को परिभाषित करती है। CloudWatch अलार्म को इस प्रतिक्रिया योजना को उसके एक्शन के रूप में ट्रिगर करने के लिए कॉन्फ़िगर करें।

क्यों: प्रतिक्रिया योजनाएँ घटना प्रतिक्रिया के सभी पहलुओं को ऑर्केस्ट्रेट करने के लिए एक एकल, सुसंगत कॉन्फ़िगरेशन प्रदान करती हैं, मैन्युअल प्रयास को कम करती हैं और सुसंगत प्रक्रियाओं को सुनिश्चित करती हैं।