अंतिम समीक्षा: मई 2026
SAP-C02 परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
पहले दिन से सुसंगत गार्डरेल, लॉगिंग और पहचान के साथ 100+ अकाउंट AWS एस्टेट स्थापित करें।
लैंडिंग ज़ोन के रूप में AWS Control Tower। अकाउंट फ़ैक्टरी अकाउंट्स को प्रावधान करती है; अनिवार्य + दृढ़ता से अनुशंसित गार्डरेल बेसलाइन लागू करते हैं; केंद्रीकृत लॉग संग्रह + ऑडिट अकाउंट्स स्वचालित रूप से बनाए जाते हैं।
क्यों: Control Tower अच्छी तरह से आर्किटेक्टेड मल्टी-अकाउंट पैटर्न को कोडित करता है। अकेले Organizations के माध्यम से स्क्रैच से निर्माण करने पर वही प्लंबिंग मैन्युअल रूप से दोहराई जाती है।
सभी अकाउंट्स में Control Tower डिफ़ॉल्ट से परे कस्टम गार्डरेल और संसाधनों को जोड़ने की आवश्यकता है।
Customizations for AWS Control Tower (CfCT)। CloudFormation टेम्प्लेट + SCPs की पाइपलाइन को StackSets के माध्यम से OUs में परिनियोजित किया गया।
क्यों: CfCT अपने लाइफ़साइकिल को तोड़े बिना Control Tower का विस्तार करता है। कस्टम Config नियम, सुरक्षा बेसलाइन, नेटवर्किंग - सभी संस्करण-नियंत्रित और दोबारा चलाने योग्य हैं।
15 मिनट से कम समय में 300 अकाउंट्स में S3 KMS एन्क्रिप्शन लागू करें + गैर-अनुरूप बकेट को स्वचालित रूप से ठीक करें।
प्रतिनिधायित प्रशासक के माध्यम से AWS Config संगठन-व्यापी कॉन्फ़ॉर्मेन्स पैक। स्वचालित-सुधार के लिए Config नियम + SSM Automation दस्तावेज़।
क्यों: कॉन्फ़ॉर्मेन्स पैक एक अकाउंट से पूरे संगठन में Config नियम + सुधार परिनियोजित करते हैं। प्रति-अकाउंट Lambda या केवल SCP दृष्टिकोण या तो वास्तविक समय का पता लगाने या सुधार को चूक जाते हैं।
सभी अकाउंट्स में 7 साल तक रखे गए CloudTrail लॉग्स को छेड़छाड़-प्रूफ करें; केवल सुरक्षा टीम पढ़ सकती है।
एक समर्पित लॉगिंग अकाउंट S3 बकेट में डिलीवर करने वाला Organization trail। 7 साल के प्रतिधारण के साथ Compliance मोड में Object Lock। सुरक्षा IAM भूमिकाओं तक बकेट एक्सेस को प्रतिबंधित करने वाला SCP।
क्यों: Compliance-mode Object Lock रूट द्वारा भी विलोपन को रोकता है। Org trail सभी अकाउंट्स से स्वचालित रूप से एकत्र करता है। समर्पित लॉगिंग अकाउंट ब्लास्ट त्रिज्या को अलग करता है।
SAML के माध्यम से कॉर्पोरेट AD में 150 अकाउंट्स को फेडरेट करें; AD समूह द्वारा अनुमतियाँ असाइन करें।
बाहरी SAML 2.0 IdP के साथ IAM Identity Center। SCIM प्रावधान के माध्यम से AD समूहों में मैप किए गए परमिशन सेट। समूहों के माध्यम से अकाउंट असाइनमेंट।
क्यों: Identity Center सभी संगठन अकाउंट्स में फेडरेशन को केंद्रीकृत करता है। परमिशन सेट अकाउंट्स में दोबारा उपयोग किए जा सकते हैं; SCIM उपयोगकर्ता/समूह स्थिति को सिंक में रखता है।
उपयोगकर्ता के लागत केंद्र के साथ टैग किए गए संसाधनों तक पहुंच प्रदान करें, हजारों उपयोगकर्ताओं तक स्केलिंग करें।
Identity Center में विशेषता-आधारित एक्सेस कंट्रोल (ABAC)। SAML के माध्यम से AD विशेषताओं को पास करें; परमिशन सेट `aws:ResourceTag/CostCenter` के विरुद्ध `aws:PrincipalTag/CostCenter` को संदर्भित करते हैं।
क्यों: ABAC प्रति-उपयोगकर्ता नीति परिवर्तनों के बिना स्केल करता है। एक नया लागत केंद्र जोड़ना सिर्फ एक टैग है - कोई IAM पुनर्लेखन नहीं।
CI/CD अकाउंट 50 वर्कलोड अकाउंट्स में CloudFormation चलाने के लिए एक डिप्लॉयमेंट भूमिका ग्रहण करता है।
प्रत्येक वर्कलोड अकाउंट के लिए IAM भूमिका जिसमें CI/CD अकाउंट प्रिंसिपल की अनुमति देने वाली ट्रस्ट पॉलिसी हो। CI/CD STS AssumeRole के माध्यम से ग्रहण करता है। यदि कोई 3rd-पार्टी टूल शुरू करता है तो बाहरी ID का उपयोग करें।
क्यों: बाहरी ID भ्रमित डिप्टी समस्या को रोकती है। भूमिका श्रृंखला सत्र को 1 घंटे पर हार्ड-कैप करती है, भले ही भूमिका अधिक समय की अनुमति देती हो।
केंद्रीय नेटवर्क टीम VPC का मालिक है; 30 स्पोक अकाउंट्स साझा सबनेट्स में वर्कलोड परिनियोजित करते हैं।
AWS RAM सबनेट्स को प्रतिभागी अकाउंट्स में साझा करता है। प्रतिभागी VPC का मालिक हुए बिना संसाधनों को लॉन्च करते हैं; केंद्रीय टीम रूट टेबल + NAT नियंत्रण बनाए रखती है।
क्यों: साझा VPCs प्रति-अकाउंट VPC के प्रसार + डुप्लिकेट IPAM को समाप्त करते हैं। प्रतिभागी VPC को हटा या रूटिंग बदल नहीं सकते।
5 क्षेत्रों + ऑन-प्रिमाइसेस में VPCs को नियतात्मक रूटिंग और केंद्रीय निरीक्षण के साथ कनेक्ट करें।
प्रत्येक क्षेत्र में Transit Gateway। इंटर-रीजन के लिए TGW पीयरिंग। TGW रूट टेबल्स के माध्यम से पहुंचने वाले उपकरणों के साथ निरीक्षण VPC।
क्यों: TGW पीयरिंग इंटर-रीजन VPN/पीयरिंग के पूर्ण मेष से बचाता है। प्रति-अटैचमेंट रूट टेबल्स सुरक्षा को दूसरों को तोड़े बिना विशिष्ट प्रवाह का निरीक्षण करने देते हैं।
TGW पीयरिंग से परे - नीति-संचालित रूटिंग के साथ क्षेत्रों + शाखा साइटों पर एक वैश्विक निजी नेटवर्क बनाएं।
AWS Cloud WAN। JSON में कोर नेटवर्क नीति घोषणात्मक रूप से सेगमेंट, क्षेत्र, अटैचमेंट, साझाकरण को परिभाषित करती है।
क्यों: Cloud WAN हब-ऑफ़-हब्स TGW डिज़ाइन को एक एकल प्रबंधित वैश्विक बैकबोन से बदलता है। सेगमेंट क्षेत्रों में तार्किक अलगाव प्रदान करते हैं।
ऑन-प्रिमाइसेस DC को लिंक-विफलता लचीलेपन और कोई इंटरनेट एक्सपोजर के साथ AWS से 10 Gbps लिंक की आवश्यकता है।
अलग DX स्थानों पर दो Direct Connect कनेक्शन। प्रत्येक एक निजी VIF के साथ जो एक Direct Connect Gateway → TGW पर समाप्त होता है। कनेक्शनों के बीच BGP फेलओवर।
क्यों: सिंगल DX विफलता का एक एकल बिंदु है। विभिन्न DX स्थान साइट-व्यापी आउटेज से बचाते हैं। DX Gateway एक VIF को कई क्षेत्रों/VPCs तक पहुंचने देता है।
प्राथमिक के रूप में Direct Connect लिंक; स्वचालित VPN फेलओवर की आवश्यकता है।
DX गेटवे के समान TGW से जुड़ा Site-to-Site VPN। AWS DX BGP रूट्स को प्राथमिकता देता है; जब DX BGP हट जाता है तो VPN नियंत्रण लेता है।
क्यों: BGP रूट प्राथमिकता फेलओवर को स्वचालित बनाती है। पूर्व-प्रावधानित VPN आउटेज के दौरान प्रावधान देरी से बचाता है।
नियामक को Direct Connect पर ऑन-प्रिमाइसेस और AWS के बीच लेयर-2 एन्क्रिप्शन की आवश्यकता है।
एक समर्पित 10 Gbps या 100 Gbps कनेक्शन पर MACsec के साथ Direct Connect। दोनों सिरों पर पूर्व-साझा कुंजी कॉन्फ़िगर की गई।
क्यों: IPsec लेयर 3 पर चलता है; MACsec लेयर 2 लाइन-रेट पर एन्क्रिप्ट करता है, नियामकों को संतुष्ट करता है जो भौतिक-लिंक एन्क्रिप्शन अनिवार्य करते हैं।
VPCs के बीच पूर्व-पश्चिम ट्रैफ़िक को स्टेटफुल निरीक्षण पास करना चाहिए।
AWS Network Firewall के साथ केंद्रीकृत निरीक्षण VPC। TGW रूट टेबल्स क्रॉस-VPC ट्रैफ़िक को गंतव्य तक पहुंचने से पहले फ़ायरवॉल VPC के माध्यम से निर्देशित करते हैं।
क्यों: Network Firewall स्टेटफुल निरीक्षण के लिए प्रबंधित Suricata-नियम इंजन है। केंद्रीकरण प्रति-VPC फ़ायरवॉल के प्रसार से बचाता है।
संगठन में हर अकाउंट में स्वचालित रूप से एक बेसलाइन WAF + Network Firewall कॉन्फ़िग लागू करें।
प्रतिनिधायित प्रशासक के साथ AWS Firewall Manager। WAF, Shield Advanced, Network Firewall, सुरक्षा समूहों के लिए नीतियां संगठन-व्यापी लागू होती हैं।
क्यों: Firewall Manager नए संसाधनों से स्वचालित रूप से नीतियों को जोड़ता है। इसके बिना, अकाउंट्स जोड़े जाने पर प्रत्येक अकाउंट बेसलाइन से भटक जाता है।
एक ही कंसोल में 100+ अकाउंट्स से Security Hub फाइंडिंग्स को केंद्रीकृत करें।
Security Hub प्रतिनिधायित प्रशासक। एग्रीगेशन क्षेत्र सभी सदस्य अकाउंट्स + सभी सक्षम क्षेत्रों से फाइंडिंग्स को एक कंसोल में एकत्र करता है।
क्यों: एग्रीगेशन के बिना, फाइंडिंग्स प्रति-अकाउंट/क्षेत्र रहती हैं। प्रतिनिधायित प्रशासक सुरक्षा संचालन के लिए प्रबंधन अकाउंट का उपयोग करने से बचाता है।
केंद्रीय निगरानी और प्रति-अकाउंट बिलिंग दृश्यता के साथ पूरे संगठन में GuardDuty सक्षम करें।
प्रतिनिधायित प्रशासक के साथ GuardDuty। org एकीकरण के माध्यम से नए अकाउंट्स पर स्वचालित-सक्षम करें। फाइंडिंग्स को एडमिन अकाउंट में एकत्रित किया गया।
क्यों: स्वचालित-सक्षम नव-निर्मित अकाउंट्स पर अंतराल को बंद करता है जो अन्यथा अन-निगरानी में होंगे।
200 अकाउंट्स में सभी S3 बकेट में निरंतर PII खोज।
प्रतिनिधायित प्रशासक के साथ Macie। Org-व्यापी स्वचालित-सक्षम। एकीकृत समीक्षा के लिए फाइंडिंग्स Security Hub में प्रवाहित होती हैं।
क्यों: Macie स्पष्ट सेटअप के बिना अकाउंट्स में पढ़ नहीं सकता। संगठन-स्तर का कॉन्फ़िगरेशन सुनिश्चित करता है कि प्रत्येक बकेट दायरे में है।
GuardDuty फाइंडिंग की जांच CloudTrail + VPC Flow Logs को अकाउंट्स में सहसंबंधित करके करें।
एक समर्पित सुरक्षा अकाउंट में Amazon Detective प्रतिनिधायित प्रशासक। सदस्य अकाउंट्स व्यवहार ग्राफ में योगदान करते हैं।
क्यों: Detective VPC Flow Logs, CloudTrail, GuardDuty से व्यवहार ग्राफ को स्वचालित रूप से बनाता है। प्रतिनिधायित प्रशासक (प्रबंधन नहीं) AWS सर्वोत्तम अभ्यास का पालन करता है।
पता लगाएं कि संगठन में कोई भी संसाधन बाहरी अकाउंट के साथ कब साझा किया जाता है।
IAM Access Analyzer संगठन को ट्रस्ट के ज़ोन के रूप में, सुरक्षा अकाउंट को प्रतिनिधायित किया गया। S3, IAM भूमिकाओं, KMS कुंजियों, Lambda, SQS, Secrets में क्रॉस-अकाउंट एक्सेस पर फाइंडिंग्स।
क्यों: Access Analyzer औपचारिक सत्यापन का उपयोग करता है, न कि पैटर्न मिलान का। Org-स्तर का ट्रस्ट ज़ोन सहोदर अकाउंट्स को विश्वसनीय मानता है।
विभिन्न वर्कलोड पैटर्न वाले 50 अकाउंट्स में Savings Plan के उपयोग को अधिकतम करें।
Organizations में Savings Plans + RI साझाकरण सक्षम के साथ समेकित बिलिंग। भुगतानकर्ता अकाउंट में खरीदे गए प्लान पूरे संगठन में साझा किए जाते हैं।
क्यों: साझाकरण उपयोग को पूल करता है ताकि एक अकाउंट में अप्रयुक्त क्षमता दूसरे में मांग को ऑफसेट कर सके। लागत-आवंटन अलगाव के लिए ही साझाकरण अक्षम करें।
ऐप टीमों को IAM व्यवस्थापक अधिकारों के बिना अनुमोदित बुनियादी ढाँचा (VPCs, RDS) स्व-सेवा करने दें।
AWS Service Catalog पोर्टफ़ोलियो। बाधाओं के साथ पूर्व-अनुमोदित CloudFormation उत्पाद। Organizations के माध्यम से अकाउंट्स में पोर्टफ़ोलियो साझा करें।
क्यों: गार्डरेल वाली स्व-सेवा प्रदान करता है। बाधा नीतियां जटिलता (उदाहरण प्रकार, टैग) को छिपाती हैं जबकि उत्पाद लॉन्च करने के लिए IAM दायरे को ले जाते हैं।
संगठन में `CostCenter` और `Environment` टैग्स को लगातार लागू करें।
OUs से जुड़ी Organizations टैग नीतियां। अनुमत मान + कैपिटलाइज़ेशन परिभाषित करें। प्रवर्तन के लिए Config नियम `required-tags` के साथ संयोजित करें।
क्यों: टैग नीतियां मान्य करती हैं; Config नियम गैर-अनुपालन का पता लगाते हैं। SCPs टैग रहित संसाधन निर्माण को अस्वीकार कर सकते हैं।
सदस्य अकाउंट्स में रूट-उपयोगकर्ता कार्यों को रोकें (अनुपालन आवश्यकता)।
SCP किसी भी कार्रवाई को अस्वीकार कर रहा है जब `aws:PrincipalArn` `arn:aws:iam::*:root` से मेल खाता है।
क्यों: SCPs रूट पर भी लागू होते हैं। IAM रूट को अस्वीकार नहीं कर सकता। अकाउंट रिकवरी को छोड़कर रूट कार्यों की कभी आवश्यकता नहीं होनी चाहिए।
संगत प्रतिधारण के साथ सभी अकाउंट्स में AWS Backup प्लान्स को अनिवार्य करें।
OUs से जुड़ी Organizations बैकअप नीतियां। प्लान्स + चयन मानदंड परिभाषित करें; दायरे में आने वाले संसाधनों पर स्वचालित रूप से लागू करें।
क्यों: प्रति-अकाउंट Backup प्लान का डुप्लिकेशन विचलन का कारण बनता है। Org नीतियां सत्य के एक स्रोत को लागू करती हैं।
प्रत्येक NAT Gateway के साथ 100+ VPCs लागत को बढ़ा रहे हैं। एक ही निकास बिंदु चाहते हैं।
NAT Gateway के साथ केंद्रीकृत निकास VPC। स्पोक VPCs रूट 0.0.0.0/0 → TGW → निकास VPC → NAT।
क्यों: 100 के बजाय एक NAT लागत को नाटकीय रूप से कम करता है। TGW क्रॉस-रीजन डेटा ट्रांसफर नियम लागू होते हैं, इसलिए इंटर-रीजन ट्रैफ़िक के लिए सावधानीपूर्वक डिज़ाइन करें।
VPC में EC2 को ऑन-प्रिमाइसेस होस्टनामों को हल करने की आवश्यकता है; ऑन-प्रिमाइसेस को VPC निजी DNS को हल करना चाहिए।
Route 53 Resolver इनबाउंड + आउटबाउंड एंडपॉइंट्स। फ़ॉरवर्डिंग नियम `corp.local` प्रश्नों को ऑन-प्रिमाइसेस पर भेजते हैं; ऑन-प्रिमाइसेस DNS `*.compute.internal` को इनबाउंड एंडपॉइंट पर फॉरवर्ड करता है।
क्यों: Resolver एंडपॉइंट्स दो AZs में HA ENIs हैं। सशर्त फ़ॉरवर्डिंग DNS को इंटरनेट पर उजागर किए बिना द्वि-दिशात्मक रिज़ॉल्यूशन देता है।
आंतरिक सेवाओं को अकाउंट्स में कई VPCs से DNS हल करने योग्य होने की आवश्यकता है।
क्रॉस-अकाउंट VPC एसोसिएशन के माध्यम से कई अकाउंट्स से VPCs के साथ संबद्ध Route 53 निजी होस्टेड ज़ोन।
क्यों: क्रॉस-अकाउंट एसोसिएशन के माध्यम से साझा किया गया एक PHZ प्रति-VPC डुप्लिकेट से बेहतर है जो भटक जाते हैं।
Windows वर्कलोड्स को ऑन-प्रिमाइसेस फ़ॉरेस्ट के लिए ट्रस्ट के साथ पूर्ण AD की आवश्यकता है।
AWS Managed Microsoft AD। DX/VPN पर ऑन-प्रिमाइसेस AD के साथ दो-तरफ़ा फ़ॉरेस्ट ट्रस्ट स्थापित करें।
क्यों: Managed AD वास्तविक Microsoft AD है (दो AZs में DCs, स्कीमा एक्स्टेंसिबल)। AD Connector केवल प्रॉक्सी करता है; Simple AD में ट्रस्ट सपोर्ट की कमी है।
AWS में ऐप्स को पहचानों को दोहराए बिना मौजूदा ऑन-प्रिमाइसेस AD के विरुद्ध प्रमाणित करने की आवश्यकता है।
AD Connector। DX/VPN पर VPC से ऑन-प्रिमाइसेस AD तक प्रॉक्सी के रूप में कार्य करता है।
क्यों: कोई डायरेक्टरी डेटा ऑन-प्रिमाइसेस नहीं छोड़ता; प्रमाणीकरण अनुरोध पास होते हैं। लेटेंसी लिंक पर निर्भर करती है।
लेटेंसी-संवेदनशील वर्कलोड को एक विशिष्ट डेटा सेंटर में चलना चाहिए लेकिन AWS APIs के माध्यम से प्रबंधित किया जाना चाहिए।
AWS Outposts रैक/सर्वर। समान AWS APIs (EC2, EBS, ECS, EKS, RDS उपसमूह) ऑन-प्रिमाइसेस पर चलते हैं। एक पैरेंट रीजन से कनेक्ट होता है।
क्यों: ऑन-प्रिमाइसेस सिस्टमों के लिए उप-मिलीसेकंड स्थानीय लेटेंसी या डेटा रेजीडेंसी के लिए जहां Local Zones कवर नहीं करते हैं। सिंगल-AZ - HA के लिए दो Outposts को जोड़ें।
एक मेट्रो में अंतिम उपयोगकर्ताओं के लिए लेटेंसी कम करें जो पैरेंट रीजन से दूर है।
AWS Local Zones। कंप्यूट, स्टोरेज को जनसंख्या केंद्रों के करीब परिनियोजित करें; कंट्रोल प्लेन के लिए डेटा प्लेन को पैरेंट रीजन में वापस रूट किया गया।
क्यों: Local Zones प्रमुख शहरों के पास EC2/EBS/RDS/ELB को होस्ट करते हैं। जब पूर्ण DC स्वामित्व की आवश्यकता नहीं होती है तो Outposts की तुलना में सस्ता होता है।
एप्लिकेशन को 5G पर मोबाइल उपयोगकर्ताओं के लिए एकल-अंक-मिलीसेकंड लेटेंसी की आवश्यकता है।
कैरियर 5G नेटवर्कों में AWS Wavelength Zones। EC2/EBS को कैरियर एज पर परिनियोजित करें; ट्रैफ़िक मोबाइल प्रदाता के नेटवर्क पर रहता है।
क्यों: AR/VR, वास्तविक समय अनुमान, गेमिंग जैसे 5G उपयोग मामलों के लिए सार्वजनिक-इंटरनेट हॉप को पूरी तरह से समाप्त करता है।
अनुपालन ऑडिटर को संगठन में प्रत्येक संसाधन की वर्तमान कॉन्फ़िग की आवश्यकता है।
ऑडिट अकाउंट में AWS Config एग्रीगेटर, सभी क्षेत्रों में पूरे संगठन के लिए स्कोप किया गया।
क्यों: Config एग्रीगेटर रीड-ओनली संगठन-व्यापी दृश्य है। एग्रीगेटर सदस्य अकाउंट्स में Config को सक्षम नहीं करते हैं - वह अलग है।
50 अकाउंट्स से CloudWatch Logs को SIEM इनजेशन के लिए एक S3 संग्रह में लैंड करने की आवश्यकता है।
प्रत्येक अकाउंट में सदस्यता फ़िल्टर → क्रॉस-अकाउंट Kinesis Data Stream / Firehose → लॉगिंग अकाउंट में S3।
क्यों: सदस्यता फ़िल्टर लॉग समूहों को वास्तविक समय में पुश करने की अनुमति देते हैं। Firehose बैचिंग, संपीड़न, S3 विभाजन को संभालता है।
SOC 2, PCI, HIPAA के लिए साक्ष्य रिपोर्ट लगातार पूरे संगठन में उत्पन्न करें।
AWS Audit Manager। पूर्व-निर्मित फ्रेमवर्क नियंत्रणों को AWS साक्ष्य (Config, CloudTrail, Security Hub) से मैप करते हैं। सुरक्षा अकाउंट में प्रतिनिधायित प्रशासक।
क्यों: Audit Manager प्रति नियंत्रण साक्ष्य को स्वचालित रूप से एकत्र करता है। प्रति ऑडिट चक्र सैकड़ों घंटों के मैन्युअल स्क्रीनशॉट संग्रह को बचाता है।
संगठन में प्रत्येक मौजूदा + भविष्य के अकाउंट में एक बेसलाइन IAM भूमिका परिनियोजित करें।
सेवा-प्रबंधित अनुमतियों + नए अकाउंट्स पर स्वचालित-परिनियोजन के साथ CloudFormation StackSets। पूरे संगठन या विशिष्ट OUs को लक्षित करें।
क्यों: स्व-प्रबंधित StackSets को प्रत्येक अकाउंट में IAM की आवश्यकता होती है। सेवा-प्रबंधित संगठन अनुमतियों का लाभ उठाता है और Organizations के लिए डिफ़ॉल्ट है।
StackSets चलाने के महीनों बाद, संदेह है कि मैन्युअल परिवर्तनों के कारण विचलन हुआ है।
StackSet पर विचलन का पता लगाना शुरू करें। संसाधनों को संशोधित किए बिना प्रति-स्टैक-उदाहरण परिणामों की समीक्षा करें।
क्यों: विचलन का पता लगाना लाइव संसाधन कॉन्फ़िग की तुलना टेम्प्लेट से करता है। विचलन को "ठीक" करने के लिए StackSets को फिर से परिनियोजित करने से अनपेक्षित परिवर्तन हो सकते हैं।
परिवर्तनीय, बर्स्टी डेटाबेस वर्कलोड - क्षमता की जरूरतें मिनटों के भीतर 10 गुना बढ़ जाती हैं।
Aurora Serverless v2। न्यूनतम/अधिकतम ACU सेट करें; Aurora कनेक्शन ड्रॉप के बिना सेकंड में स्केल करता है।
क्यों: v2 मौजूदा इंस्टेंस में क्षमता जोड़कर स्केल करता है - कोई फेलओवर नहीं। प्रोविज़ंड Aurora इतनी तेज़ी से स्केल नहीं कर सकता; Serverless v1 धीरे-धीरे स्केल करता है और कनेक्शन को रोक देता है।
क्रॉस-रीजन DB फेलओवर के लिए <1s RPO और <1min RTO के साथ ग्लोबल ऐप।
Aurora Global Database। स्टोरेज-आधारित प्रतिकृति, विशिष्ट प्रतिकृति अंतराल <1s। सेकंड में सेकेंडरी को बढ़ावा दें।
क्यों: ग्लोबल DB पेज भेजता है, ट्रांजैक्शन नहीं - उप-सेकंड क्रॉस-रीजन। तार्किक प्रतिकृति के माध्यम से क्रॉस-रीजन रीड प्रतिकृतियां इससे मेल नहीं खा सकतीं।
एक पूर्ण कॉपी के लिए भुगतान किए बिना परीक्षण के लिए एक प्रोडक्शन डेटाबेस को दोहराएं।
Aurora क्लोनिंग। कॉपी-ऑन-राइट - प्रारंभिक क्लोन मुफ्त है; केवल बदले हुए पेज बिल किए जाते हैं।
क्यों: क्लोन पॉइंट-इन-टाइम, इंस्टेंट, आइसोलेटेड होते हैं। स्नैपशॉट+पुनर्स्थापना में घंटे लगते हैं और तुरंत पूर्ण स्टोरेज का बिल आता है।
मिनटों में एक तार्किक त्रुटि (प्रोड में DROP TABLE) से उबरें, घंटों में नहीं।
Aurora MySQL Backtrack। बैकअप से पुनर्स्थापित किए बिना क्लस्टर को अपनी जगह पर एक पिछले बिंदु पर वापस ले जाता है।
क्यों: Backtrack अपनी जगह पर और तेज़ है। PITR पुनर्स्थापना एक नया क्लस्टर बनाती है - धीमा और ऐप कटओवर की आवश्यकता होती है।
बड़ी मेमोरी वाले विशिष्ट रीडर इंस्टेंस को रिपोर्टिंग क्वेरीज़ रूट करें।
Aurora कस्टम एंडपॉइंट्स। रीडर्स के एक उपसमूह (बड़े वाले) को इंगित करने वाला एंडपॉइंट परिभाषित करें।
क्यों: डिफ़ॉल्ट रीडर एंडपॉइंट सभी रीडर्स को राउंड-रॉबिन करता है। कस्टम एंडपॉइंट्स वर्कलोड प्रकार द्वारा क्लस्टर को विभाजित करते हैं।
DynamoDB टेबल में हॉट पार्टिशन स्पाइक्स कुछ रीड्स/राइट्स को थ्रॉटल करते हैं।
ऑटो-स्केलिंग + एडेप्टिव क्षमता (स्वचालित) के साथ प्रोविज़ंड। यदि एक ही कुंजी हॉटस्पॉट है तो पार्टिशन कुंजी को फिर से डिज़ाइन करें।
क्यों: एडेप्टिव क्षमता बिना किसी कार्रवाई के पार्टिशनों में थ्रूपुट को पुनर्वितरित करती है। लेकिन अगर एक कुंजी हॉट है, तो केवल स्कीमा रीडिज़ाइन (कंपोजिट कुंजी, राइट शार्डिंग) मदद करता है।
हर DynamoDB राइट पर साइड-इफ़ेक्ट - सर्च इंडेक्सिंग के लिए OpenSearch पर पुश करें।
DynamoDB Streams + Lambda ट्रिगर। Lambda स्ट्रीम रिकॉर्ड्स को बैच करता है और OpenSearch पर लिखता है।
क्यों: स्ट्रीम 24 घंटे के लिए आइटम-स्तर के परिवर्तनों को कैप्चर करते हैं। नेटिव ट्रिगर मॉडल - लंबी प्रतिधारण/विश्लेषण के लिए Kinesis Data Streams एडाप्टर मौजूद है।
कई DynamoDB आइटमों में दो-चरण राइट को एटॉमिक होना चाहिए।
TransactWriteItems / TransactGetItems। 100 आइटम तक ACID सेमांटिक्स।
क्यों: नेटिव ट्रांजैक्शन वितरित-सागा जटिलता से बचते हैं। लागत प्रति आइटम सामान्य क्षमता का 2x है - केवल तभी उपयोग करें जब एटॉमिकिटी की आवश्यकता हो।
एक स्व-होस्टेड MongoDB क्लस्टर को API को संरक्षित करते हुए एक प्रबंधित सेवा में माइग्रेट करें।
Amazon DocumentDB। MongoDB-संगत API। माइग्रेशन के लिए mongodump/mongorestore या DMS का उपयोग करें।
क्यों: DocumentDB MongoDB 4.0/5.0 (अधिकांश ऑपरेटर, सभी नहीं) के साथ API-संगत है। कमिट करने से पहले ड्राइवर/फीचर संगतता सत्यापित करें।
सिफारिश इंजन को 100M नोड्स के एक सोशल ग्राफ को पार करने की आवश्यकता है।
Amazon Neptune। प्रॉपर्टी ग्राफ (Gremlin) या RDF (SPARQL)।
क्यों: उद्देश्य-निर्मित ग्राफ DB। DynamoDB या RDS में रिश्तों को मॉडल करना संभव है लेकिन क्वेरी प्रदर्शन हॉप गहराई के साथ घटता है।
IoT फ्लीट प्रति सेकंड 10M टाइम्ससीरीज़ डेटापॉइंट्स उत्सर्जित करता है जिसमें मिश्रित-फ़्रीक्वेंसी प्रतिधारण होता है।
Amazon Timestream। मेमोरी स्टोर (हाल का), मैग्नेटिक स्टोर (ऐतिहासिक) - स्वचालित टियरिंग।
क्यों: उद्देश्य-निर्मित टाइम्ससीरीज़ - DynamoDB/RDS स्केलिंग इस दर पर लागत prohibitive है। बिल्ट-इन प्रतिधारण टियरिंग स्टोरेज लागत को कम करता है।
बैंकिंग लेज़र को हर रिकॉर्ड परिवर्तन के क्रिप्टोग्राफिक सत्यापन की आवश्यकता है।
Amazon QLDB। अपरिवर्तनीय, क्रिप्टोग्राफिक रूप से सत्यापन योग्य जर्नल। सबूतों के लिए SHA-256 डाइजेस्ट निर्यात का उपयोग करें।
क्यों: QLDB उद्देश्य-निर्मित लेज़र है। DynamoDB Streams परिवर्तन इतिहास देते हैं लेकिन कोई बिल्ट-इन क्रिप्टोग्राफिक चेनिंग नहीं।
अप्रत्याशित पीक और हैंड्स-ऑफ संचालन के साथ लॉग एनालिटिक्स वर्कलोड।
Amazon OpenSearch Serverless। डिकपल्ड कंप्यूट/स्टोरेज; ऑटो-स्केल्स OCUs।
क्यों: कोई क्लस्टर साइज़िंग या शार्ड प्रबंधन नहीं। अनुमानित, निरंतर वर्कलोड के लिए, प्रोविज़ंड डोमेन सस्ते होते हैं।
इलास्टिक कंप्यूट और टीमों के बीच डेटा साझाकरण के साथ पेटाबाइट-स्केल एनालिटिक्स।
प्रबंधित स्टोरेज के साथ Redshift RA3 नोड्स। क्रॉस-क्लस्टर डेटा साझाकरण (कोई कॉपी नहीं)।
क्यों: RA3 कंप्यूट को स्टोरेज से अलग करता है - प्रत्येक को स्वतंत्र रूप से स्केल करें। डेटा साझाकरण टीमों के क्लस्टर के बीच ETL को समाप्त करता है।
मौजूदा Redshift क्लस्टर + S3 डेटा लेक - Redshift से S3 को क्वेरी करें, या Athena का उपयोग करें?
Redshift Spectrum जब क्लस्टर टेबल और S3 डेटा के बीच जॉइन की आवश्यकता होती है। Athena जब केवल S3 पर पूरी तरह से सर्वरलेस एड-हॉक की आवश्यकता होती है।
क्यों: Spectrum Redshift कंप्यूट के माध्यम से S3 क्वेरीज़ चलाता है। Athena प्रति TB स्कैन पर भुगतान करता है। जहां प्रमुख डेटा रहता है उसके अनुसार चुनें।
विभिन्न टीमों को एक ही Glue Catalog टेबल्स पर विभिन्न पंक्ति/कॉलम दृश्यता की आवश्यकता है।
पंक्ति-स्तर + कॉलम-स्तर + सेल-स्तर फ़िल्टर के साथ AWS Lake Formation। LF टैग के माध्यम से अनुदान दें।
क्यों: IAM/S3 नीतियां पंक्ति-स्तर नहीं कर सकतीं। Lake Formation Glue Catalog मेटाडेटा + Athena/Redshift Spectrum/EMR उपभोक्ताओं के माध्यम से फाइन-ग्रेन्ड एक्सेस लागू करता है।
डेली Glue जॉब इंक्रीमेंटल डेटा को प्रोसेस करता है; कल की फ़ाइलों को फिर से प्रोसेस नहीं करना चाहिए।
Glue जॉब बुकमार्क्स। प्रोसेस किए गए S3 कीज़ / DB पंक्तियों को ट्रैक करें; अंतिम सफल चेकपॉइंट से फिर से शुरू करें।
क्यों: बुकमार्क्स मैन्युअल स्थिति ट्रैकिंग के बिना डुप्लिकेट प्रोसेसिंग से बचते हैं। पूर्ण-प्रक्रिया रन के लिए अक्षम करें।
इवेंट स्ट्रीमिंग के लिए प्रबंधित Kafka बनाम Kinesis Data Streams चुनें।
मौजूदा Kafka क्लाइंट/इकोसिस्टम होने पर MSK। AWS इंटीग्रेशन (Lambda ट्रिगर, Firehose, KCL) और सर्वरलेस विकल्प के लिए Kinesis।
क्यों: दोनों रीप्ले के साथ स्थायी रूप से स्ट्रीम करते हैं। MSK Kafka API और इकोसिस्टम को संरक्षित करता है; Kinesis छोटे स्ट्रीम के लिए कम लागत पर आता है और मूल रूप से एकीकृत होता है।
परिवर्तनीय Kafka थ्रूपुट; हैंड्स-ऑफ क्लस्टर प्रबंधन चाहते हैं।
MSK Serverless। ऑटो-स्केल्स पार्टिशन और थ्रूपुट; प्रति पार्टिशन + डेटा भुगतान करें।
क्यों: कोई ब्रोकर साइज़िंग नहीं। निरंतर उच्च थ्रूपुट के लिए, प्रोविज़ंड MSK सस्ता है।
SQS → फ़िल्टर → Step Functions को ग्लू Lambda लिखे बिना कनेक्ट करें।
EventBridge Pipes। स्रोत → वैकल्पिक फ़िल्टर → वैकल्पिक संवर्धन → लक्ष्य।
क्यों: एक विशिष्ट Lambda-एज़-ग्लू को बदल देता है। कोड, लागत और परिचालन सतह को कम करता है।
स्रोत से फिर से उत्सर्जित किए बिना एक नए उपभोक्ता के माध्यम से पिछले सप्ताह के इवेंट्स को फिर से चलाएं।
EventBridge संग्रह + रीप्ले। संग्रह मिलान किए गए इवेंट्स को कैप्चर करता है; उन्हें बाद में एक लक्ष्य पर फिर से चलाएं।
क्यों: बिल्ट-इन रीप्ले एक अलग इवेंट स्टोर की आवश्यकता से बचाता है। घटना रिकवरी और नए उपभोक्ताओं को ऑनबोर्ड करने के लिए उपयोगी।
सैकड़ों प्रोड्यूसर इवेंट्स उत्सर्जित करते हैं; उपभोक्ताओं को टाइप किए गए बाइंडिंग की आवश्यकता होती है।
स्वचालित-खोज के साथ EventBridge Schema Registry। स्ट्रॉन्गली-टाइप्ड कोड बाइंडिंग (Java, Python, TypeScript) उत्पन्न करें।
क्यों: खोज देखे गए इवेंट्स से स्कीमा सीखती है। बाइंडिंग संकलन-समय सुरक्षा प्रदान करते हैं।
उच्च-मात्रा लघु वर्कफ़्लो (>100k/सेकंड) का उप-सेकंड-बिलित ऑर्केस्ट्रेशन।
Step Functions Express वर्कफ़्लो। प्रति-निष्पादन-एमएस बिलिंग; अधिकतम 5 मिनट।
क्यों: मानक वर्कफ़्लो टिकाऊ + इतिहास-ट्रैक किए गए होते हैं, प्रति स्थिति संक्रमण बिल किए जाते हैं। एक्सप्रेस कम अवधि के प्रवाह पर लागत के लिए ऑडिट ट्रेल का व्यापार करता है।
एक Step Function के माध्यम से समानांतर में 10M S3 ऑब्जेक्ट्स को प्रोसेस करें।
Distributed Map स्टेट। 10,000 समानांतर तक समवर्ती चाइल्ड निष्पादन; S3 से सीधे स्रोत पढ़ता है।
क्यों: इनलाइन मैप 40 समानांतर पर सीमित है। Distributed Map सेवा कोटा को प्रभावित किए बिना S3-बकेट-साइज़ नौकरियों तक स्केल करता है।
FIFO कतार को >300 संदेश/सेकंड की आवश्यकता है।
उच्च-थ्रूपुट मोड सक्षम के साथ SQS FIFO। प्रति API प्रति क्षेत्र 70k msg/sec तक; `MessageGroupId` द्वारा विभाजन।
क्यों: मानक FIFO बैचिंग के बिना 300 msg/sec पर सीमित है। उच्च-थ्रूपुट मोड समूह ID द्वारा क्रमबद्धता को विभाजित करता है।
कई उपभोक्ताओं को एक ही Kinesis स्ट्रीम पर पूर्ण रीड थ्रूपुट की आवश्यकता होती है।
Enhanced Fan-Out (EFO)। प्रत्येक उपभोक्ता को HTTP/2 पुश के माध्यम से एक समर्पित 2 MB/s/shard पाइप मिलता है।
क्यों: डिफ़ॉल्ट पोलिंग 2 MB/s/shard सीमा को उपभोक्ताओं में साझा करता है। EFO उच्च लागत पर विवाद को समाप्त करता है।
S3 में Firehose; डेटा लेक क्वेरीज़ बहुत अधिक स्कैन करती हैं क्योंकि विभाजन इंजेशन समय से होता है, इवेंट समय से नहीं।
Firehose डायनेमिक विभाजन। JSON से इवेंट-टाइम / टेनेंट ID निकालें; S3 उपसर्ग `year=YYYY/month=MM/tenant=X/` पर लिखें।
क्यों: Athena/Spectrum इवेंट समय पर विभाजन प्रूनिंग स्कैन लागत और लेटेंसी को कम करता है।
मोबाइल/वेब क्लाइंट को वास्तविक समय अपडेट और चयनात्मक फ़ील्ड फ़ेचिंग की आवश्यकता है।
AWS AppSync (GraphQL) सब्सक्रिप्शन के साथ। WebSocket-समर्थित।
क्यों: GraphQL क्लाइंट केवल अनुरोधित फ़ील्ड्स को फ़ेच करते हैं और डेल्टास की सदस्यता लेते हैं। REST/HTTP API Gateway ओवर-फ़ेच और पोलिंग को मजबूर करता है।
आंतरिक API सार्वजनिक इंटरनेट से पहुंच योग्य नहीं होना चाहिए।
इंटरफ़ेस VPC एंडपॉइंट के माध्यम से API Gateway निजी एंडपॉइंट। संसाधन नीति विशिष्ट VPCs तक प्रतिबंधित करती है।
क्यों: निजी APIs केवल VPC + कनेक्टेड नेटवर्कों से पहुंच योग्य होते हैं। सार्वजनिक APIs को सुरक्षित होने के लिए WAF + auth की आवश्यकता होती है।
S3 ओरिजिन को लॉक डाउन करें ताकि केवल CloudFront ही उसे पढ़ सके।
Origin Access Control (OAC)। पुराने OAI को बदलता है; SSE-KMS और सभी S3 सुविधाओं का समर्थन करता है।
क्यों: OAI SSE-KMS ऑब्जेक्ट्स का समर्थन नहीं करता है। AWS सभी नए डिस्ट्रीब्यूशन के लिए OAC की सिफारिश करता है।
S3 में विशिष्ट सशुल्क वीडियो तक पहुंच को समय-सीमित करें।
CloudFront साइन्ड URLs (प्रति-URL) या साइन्ड कुकीज़ (कई URLs)। विश्वसनीय कुंजी समूह अनुरोधों पर हस्ताक्षर करता है।
क्यों: प्री-साइन्ड S3 URLs CloudFront कैशिंग को बायपास करते हैं। CloudFront साइन्ड URLs एज पर कैश करते हैं और एक्सेस को प्रतिबंधित करते हैं।
हल्का व्यूअर-अनुरोध परिवर्तन: हेडर पुनर्लेखन, रीडायरेक्ट, A/B रूटिंग।
CloudFront Functions। JS, उप-मिलीसेकंड, सभी एज POPs।
क्यों: Lambda@Edge क्षेत्रीय एज पर पूर्ण Node/Python है - भारी और महंगा। सरल हेरफेर के लिए Functions 10 गुना सस्ते होते हैं।
मजबूत अलगाव के साथ EKS में अविश्वसनीय मल्टी-टेनेंट वर्कलोड चलाएं।
EKS Fargate प्रति-पॉड अलगाव। प्रत्येक पॉड एक समर्पित माइक्रो-VM में चलता है।
क्यों: प्रबंधित नोड समूह कर्नेल साझा करते हैं - विशेषाधिकार वृद्धि किरायेदारों को पार करती है। Fargate कर्नेल अलगाव EKS में सबसे मजबूत है।
EKS क्लस्टर ऑटोस्केलिंग लेटेंसी बहुत धीमी; नोड समूहों का इंस्टेंस प्रकार का प्रसार।
Karpenter। प्रावधानकर्ता लंबित पॉड आवश्यकताओं के आधार पर जस्ट-इन-टाइम इंस्टेंस प्रकार चुनता है।
क्यों: Cluster Autoscaler पूर्व-परिभाषित ASGs को स्केल करता है, धीमा और सीमित। Karpenter सेकंड में मनमाने EC2 को विविधीकरण के साथ स्केल करता है।
EKS पॉड को कम से कम विशेषाधिकार IAM की आवश्यकता है (नोड-इंस्टेंस भूमिका साझाकरण से बचें)।
OIDC प्रदाता के माध्यम से Service Accounts (IRSA) के लिए IAM भूमिकाएं। भूमिका ARN के साथ ServiceAccount को एनोटेट करें।
क्यों: EKS Pod Identity नया विकल्प है - सरल ट्रस्ट मॉडल। IRSA परिपक्व है और क्षेत्रों में काम करता है।
ECS-on-EC2 कार्य प्रारंभ स्केल-आउट के दौरान 5-7 मिनट लगते हैं - <60s की आवश्यकता है।
CapacityProviderReservation` पर प्रबंधित स्केलिंग लक्ष्य ~80% के साथ ECS Capacity Provider। निष्क्रिय बफर बनाए रखें।
क्यों: आरक्षित बफर का मतलब है कि नए कार्य तत्काल मौजूदा क्षमता पर उतरते हैं जबकि ASG प्रतिस्थापन लॉन्च करता है।
Lambda SQS द्वारा ट्रिगर होता है लेकिन केवल 5% संदेश मेल खाते हैं - व्यर्थ इनवोकेशन।
फ़िल्टर मानदंडों के साथ इवेंट स्रोत मैपिंग। Lambda केवल मिलान किए गए संदेशों के लिए ही आह्वान किया जाता है।
क्यों: प्री-Lambda फ़िल्टर अप्रासंगिक संदेशों पर प्रति-इनवोकेशन लागत से बचाता है। SQS, Kinesis, DynamoDB, MQ, Kafka पर फ़िल्टरिंग समर्थित है।
प्रोडक्शन ऐप को कम परिचालन ओवरहेड के साथ एक LLM एंडपॉइंट की आवश्यकता है।
प्रबंधित फ़ाउंडेशन मॉडल (Claude, Llama, Titan) के लिए Amazon Bedrock। SageMaker केवल तभी जब आपको कस्टम मॉडल या ओपन-वेट्स को कसकर ट्यून करने की आवश्यकता हो।
क्यों: Bedrock केवल API है - कोई इंफ्रा नहीं। SageMaker पूर्ण ML प्लेटफ़ॉर्म है - तब चुनें जब आप प्रशिक्षण/फ़ाइन-ट्यूनिंग लाइफ़साइकिल के मालिक हों।
मॉडल को प्रशिक्षित किए बिना दृष्टि / NLP के लिए प्रबंधित AI चुनें।
Rekognition (छवि/वीडियो लेबल, चेहरे, सामग्री मॉडरेशन)। Comprehend (भावना, संस्थाएं, भाषाएं, PII डिटेक्शन)। Translate। Polly। Transcribe।
क्यों: पूर्व-प्रशिक्षित AWS AI सेवाएं सामान्य कार्यों के लिए पूरे ML लाइफ़साइकिल को छोड़ देती हैं। SageMaker का उपयोग केवल तभी करें जब ऑफ़-द-शेल्फ़ फिट न हो।
वेब ऐप ईमेल/पासवर्ड + Google + Apple + SAML एंटरप्राइज़ SSO का समर्थन करता है।
होस्टेड UI के साथ Cognito User Pool। OIDC + SAML IdPs कॉन्फ़िगर करें। ऐप Cognito JWT प्राप्त करता है।
क्यों: User Pool IdPs को एक टोकन में एकत्रित करता है। Identity Pool केवल AWS क्रेडेंशियल्स के लिए टोकन बदलता है - AWS API एक्सेस के लिए, auth के लिए नहीं।
दो क्षेत्रों में एक ही कुंजी पर एक साथ राइट्स के साथ DynamoDB Global Tables।
टाइमस्टैंप द्वारा लास्ट-राइटर-विंस। एप्लिकेशन आइडम्पोटेंट राइट्स डिज़ाइन करता है या क्षेत्रों द्वारा राइट्स को विभाजित करता है।
क्यों: GT प्रतिकृति एसिंक मल्टी-मास्टर है। संघर्ष समाधान टाइमस्टैंप-आधारित है - ऐप्स को अंततः संगतता को सहन करना चाहिए।
संगठन में EC2 फ्लीट ओवर-प्रावधानित; स्वचालित राइट-साइज़िंग सिफारिशों की आवश्यकता है।
Org स्तर पर AWS Compute Optimizer सक्षम। उपयोग खिड़कियों के विरुद्ध सिफारिशों की समीक्षा करें; ट्रैकिंग के लिए S3 में निर्यात करें।
क्यों: Compute Optimizer CloudWatch मेट्रिक्स पर ML का उपयोग करता है। मैन्युअल राइट-साइज़िंग वर्कलोड-आकार संकेतों को चूक जाता है।
महीने के अंत में नहीं, घंटों के भीतर अप्रत्याशित लागत स्पाइक्स पकड़ें।
AWS Cost Anomaly Detection। ML प्रति-सेवा / प्रति-अकाउंट खर्च की निगरानी करता है; जब थ्रेशोल्ड भंग होता है तो SNS / ईमेल के माध्यम से अलर्ट करता है।
क्यों: बजट नियोजित थ्रेशोल्ड पर फायर होते हैं। विसंगति का पता लगाना अनबजटेड खर्च (समझौता की गई कुंजी, भगोड़ा प्रशिक्षण कार्य) को दिनों/सप्ताह पहले पकड़ लेता है।
जब अकाउंट मासिक बजट का 100% हिट करता है, तो गैर-आवश्यक संसाधनों को स्वचालित रूप से रोकें।
AWS Budget क्रियाएं। प्रतिबंधात्मक IAM नीति लागू करें + गैर-आवश्यक EC2/RDS को रोकने के लिए SNS के माध्यम से Lambda को ट्रिगर करें।
क्यों: बजट क्रियाएं "केवल अलर्ट" से "लागू करें" में बदल जाती हैं। अनबजटेड खर्च को पकड़ने के लिए Cost Anomaly Detection के साथ जोड़ें।
S3 लागत अनुकूलन अवसरों में संगठन-व्यापी दृश्यता।
उन्नत मेट्रिक्स + संगठन-व्यापी दायरे के साथ S3 Storage Lens। कोल्ड-टियर उम्मीदवारों, IT-टियर अवसरों, छोड़े गए मल्टीपार्ट अपलोड्स को सतह पर लाता है।
क्यों: फ्री टियर बेसिक मेट्रिक्स को कवर करता है; उन्नत टियर प्रतिकृति, गतिविधि, अनुकूलन सिफारिशें दिखाता है। ऑडिट/सुरक्षा अकाउंट में केंद्रीकृत।
डिलीट ऑपरेशनों के बावजूद S3 बिल बढ़ता रहता है।
लाइफसाइकिल नियम 7 दिनों के बाद `incomplete multipart uploads` को रद्द करता है। `s3api list-multipart-uploads` के साथ निरीक्षण करें।
क्यों: विफल अपलोड ऐसे हिस्से छोड़ देते हैं जो स्टोरेज के रूप में बिल होते हैं लेकिन कंसोल सूची में अदृश्य होते हैं। सामान्य लागत-रिसाव।
कोल्ड आर्काइव डेटा प्रति तिमाही में अधिकतम एक बार एक्सेस किया जाता है।
S3 Glacier Flexible Retrieval (1-12 घंटे पुनर्स्थापित)। "कभी एक्सेस नहीं किया गया" के लिए Deep Archive (12 घंटे पुनर्प्राप्ति, सबसे कम लागत) का उपयोग करें।
क्यों: Standard-IA मिली-सेकंड एक्सेस रखता है; Glacier टियर ~80-95% लागत कटौती के लिए एक्सेस समय का व्यापार करते हैं।
S3 + DynamoDB ट्रैफ़िक के लिए NAT Gateway निकास लागत कम करें।
S3 + DynamoDB (मुफ्त) के लिए Gateway VPC एंडपॉइंट्स। एंडपॉइंट के माध्यम से ट्रैफ़िक रूट करें, NAT को बायपास करें।
क्यों: NAT प्रति-GB शुल्क लेता है; Gateway एंडपॉइंट्स मुफ्त हैं। अन्य AWS सेवाओं के लिए, इंटरफ़ेस एंडपॉइंट्स लागत को कम करते हैं लेकिन समाप्त नहीं करते हैं।
AZs में वर्कलोड चैटटी; डेटा-ट्रांसफर लागत बिल पर हावी है।
माइक्रोसेर्विसेस को एक ही AZ में सह-स्थापित करें जहाँ संभव हो। AZ-एफ़िनिटी रूटिंग के साथ VPC Lattice या सर्विस मेश का उपयोग करें।
क्यों: क्रॉस-AZ प्रत्येक दिशा में $0.01/GB है। पैमाने पर माइक्रोसेवा चैटटर जुड़ जाता है। लागत के लिए कुछ HA का व्यापार करें जहाँ 99.95% पर्याप्त है।
इंटरनेट पर निकास ट्रैफ़िक सबसे बड़ा लाइन आइटम है।
CloudFront के साथ सब कुछ सामने रखें। CloudFront-टू-इंटरनेट निकास सीधा EC2/ALB निकास से सस्ता है।
क्यों: CloudFront निकास मूल्य निर्धारण टियर किया गया है और क्षेत्रीय निकास से काफी कम है। कैशिंग ओरिजिन निकास को और कम करती है।
Compute Savings Plan बनाम EC2 Instance Savings Plan बनाम Reserved Instances के बीच चुनें।
Compute SP: सबसे लचीला (कोई भी क्षेत्र, परिवार, OS) - थोड़ा कम छूट। EC2 Instance SP: परिवार-लॉक किया गया क्षेत्र - गहरी छूट। RI: क्षमता आरक्षण की आवश्यकता वाले दुर्लभ मामले।
क्यों: Compute SP Lambda + Fargate + EC2 को कवर करता है। RIs केवल तभी SPs को हराते हैं जब क्षमता आरक्षण मायने रखता है; अधिकांश मामलों में SPs जीतते हैं।
स्टेटलेस बैच फ्लीट Spot पर चलता है - व्यवधान दर बहुत अधिक है।
कई इंस्टेंस प्रकार + AZs में क्षमता-अनुकूलित रणनीति के साथ Spot Fleet।
क्यों: सबसे कम कीमत की रणनीति एक ही पूल पर केंद्रित होती है - उच्च व्यवधान। क्षमता-अनुकूलित गहरी उपलब्ध क्षमता वाले पूल चुनता है।
पुनर्लेखन के बिना स्टेटलेस वेब टियर पर कंप्यूट लागत को ~20% कम करें।
Graviton (ARM) में माइग्रेट करें - `c7g`, `m7g`, Lambda ARM, Aurora Graviton। संकलित बाइनरीज़ के लिए संगतता परीक्षण।
क्यों: Graviton अधिकांश वर्कलोड के लिए ~20% बेहतर मूल्य-प्रदर्शन प्रदान करता है। Java/Python/Node "बस काम करते हैं"; नेटिव कोड को फिर से संकलित करने की आवश्यकता हो सकती है।
एक लंबी चलने वाली लेकिन व्यवधान-सहिष्णु Fargate सेवा की लागत-कटौती करें।
क्षमता प्रदाता रणनीति के माध्यम से Fargate Spot। HA कार्यों के लिए Spot + ऑन-डिमांड मिलाएं।
क्यों: Fargate Spot ~70% सस्ता। समाप्ति से पहले कार्य को 2 मिनट की चेतावनी मिलती है - अनुग्रहपूर्ण ड्रेन के साथ जोड़ें।
CloudWatch Logs स्टोरेज लागत महीने-दर-महीने बढ़ रही है।
प्रति लॉग समूह प्रतिधारण सेट करें (डिफ़ॉल्ट हमेशा के लिए है)। लंबी अवधि के लिए, S3 में निर्यात करें + CW में हटा दें। Logs Infrequent Access क्लास का उपयोग करें।
क्यों: CW Logs की लागत $0.03/GB इंजेशन + स्टोरेज हमेशा के लिए है। S3 Standard-IA $0.0125/GB पर अभिलेखीय पहुंच के लिए सस्ता है।
सेवाओं में एकीकृत ऑब्ज़र्वेबिलिटी के साथ खंडित निगरानी को बदलें।
सेवा मानचित्र के लिए CloudWatch ServiceLens; ट्रेसेस के लिए X-Ray; एड-हॉक के लिए CloudWatch Logs Insights; ECS/EKS के लिए Container Insights; ब्राउज़र के लिए RUM; कैनरीज़ के लिए Synthetics।
क्यों: AWS-नेटिव स्टैक प्रति-होस्ट एजेंटों से बचाता है। पोर्टेबिलिटी के लिए OpenTelemetry SDK के साथ जोड़ें।
5 अकाउंट्स में सेवाओं में एक अनुरोध का पता लगाएं।
X-Ray क्रॉस-अकाउंट ऑब्ज़र्वेबिलिटी। स्रोत अकाउंट्स OAM के माध्यम से केंद्रीय निगरानी अकाउंट के साथ ट्रेसेस साझा करते हैं।
क्यों: OAM के बिना, ट्रेसेस प्रति अकाउंट खंडित होते हैं। क्रॉस-अकाउंट एग्रीगेशन अनुरोध पथ दृश्य को केंद्रीकृत करता है।
एक CloudWatch कंसोल में कई अकाउंट्स से मेट्रिक्स + लॉग्स + ट्रेसेस देखें।
CloudWatch Observability Access Manager (OAM)। स्रोत अकाउंट्स सिंक + लिंक के माध्यम से एक निगरानी अकाउंट से लिंक करते हैं।
क्यों: OAM कैनोनिकल मल्टी-अकाउंट ऑब्ज़र्वेबिलिटी फैब्रिक है। प्रति-अकाउंट कंसोल कूदने को समाप्त करता है।
Aurora क्लस्टर धीमापन - प्रतीक्षा इवेंट द्वारा शीर्ष SQL को इंगित करें।
क्लस्टर पर Performance Insights सक्षम। क्वेरी लॉग डंप के बिना लोड + प्रतीक्षा विश्लेषण द्वारा शीर्ष SQL।
क्यों: PI कम ओवरहेड के साथ प्रतीक्षा इवेंट्स को सैंपल करता है। CloudWatch मेट्रिक्स आपको बताते हैं कि कुछ धीमा है, PI आपको बताता है कि क्या।
अलार्म थ्रेशोल्ड लिखे बिना DynamoDB / RDS / Lambda / ECS में विसंगतियों का स्वचालित रूप से पता लगाएं।
Amazon DevOps Guru। परिचालन मेट्रिक्स + सहसंबंधित इवेंट्स पर ML-आधारित विसंगति का पता लगाना।
क्यों: स्टैटिक थ्रेशोल्ड दुर्लभ मोड को चूक जाते हैं। DevOps Guru बेसलाइन सीखता है और सामान्य से विचलन पर अलर्ट करता है।
प्रति-इंस्टेंस स्क्रिप्ट के बिना एक शेड्यूल पर 5,000 EC2 इंस्टेंस को पैच करें।
पैच बेसलाइन + रखरखाव विंडोज़ के साथ SSM Patch Manager। टैग-आधारित लक्ष्यीकरण; N दिनों के बाद सुरक्षा पैच को स्वचालित रूप से अनुमोदित करें।
क्यों: Patch Manager पूरे पैच लाइफ़साइकिल को केंद्रीकृत करता है। स्व-प्रबंधित स्क्रिप्ट भटक जाती हैं और नए इंस्टेंस को चूक जाती हैं।
मानवीय अनुमोदन के बिना Config नियम विफलताओं (जैसे, खुला SG) को स्वचालित रूप से ठीक करें।
Config सुधार कार्रवाई SSM Automation दस्तावेज़ को लागू करना। पूर्व-निर्मित `AWS-DisablePublicAccessForSecurityGroup` आदि।
क्यों: Config पता लगाता है; SSM Automation कार्य करता है। SNS → मानव → टिकट की तुलना में तंग लूप।
AMI/कंटेनर-छवि गोल्डन पाइपलाइन प्रतिलिपि प्रस्तुत करने योग्य और पैच-वर्तमान होनी चाहिए।
EC2 Image Builder पाइपलाइन। स्रोत AMI → रेसिपी (घटक) → परीक्षण → क्षेत्रों/अकाउंट्स में वितरित करें।
क्यों: एड-हॉक Packer स्क्रिप्ट्स को प्रबंधित लाइफ़साइकिल से बदलता है। मासिक पैच ताज़ा करने के लिए पुनर्निर्माण शेड्यूल करें।
EC2 + ECR छवियों + Lambda में निरंतर CVE स्कैनिंग।
संगठन-व्यापी सक्षम के साथ Amazon Inspector v2। फाइंडिंग्स Security Hub में प्रवाहित होती हैं।
क्यों: Inspector v2 EC2 + कंटेनर छवियों + Lambda निर्भरताओं को एक सेवा में कवर करता है। पैमाने पर मैन्युअल CVE मिलान असंभव है।
सत्यापित करें कि एक मल्टी-टियर ऐप 1-घंटे RTO / 15-मिनट RPO को पूरा कर सकता है।
AWS Resilience Hub। नीति परिभाषित करें → ऐप का मूल्यांकन करें → सिफारिशें + स्वचालित रनबुक।
क्यों: Resilience Hub ठोस परीक्षणों के साथ RTO/RPO दावों को औपचारिक बनाता है। मैन्युअल DR रनबुक भटक जाते हैं।
परीक्षण करें कि ऑटो-स्केलिंग और फेलओवर वास्तविक विफलताओं के तहत काम करते हैं, न कि अनुमानित विफलताओं के तहत।
AWS Fault Injection Service (FIS)। टेम्पलेटेड प्रयोग - इंस्टेंस को मारें, APIs को थ्रॉटल करें, लेटेंसी इंजेक्ट करें। गेम डेज़ के दौरान चलाएं।
क्यों: सेवा के रूप में Chaos-engineering। वास्तविक विफलता नाजुक धारणाओं को उजागर करती है; रनबुक पढ़ना नहीं करता है।
मल्टी-रीजन फेलओवर - स्वचालित तैयारी जांच + जोनल निकासी।
Route 53 Application Recovery Controller। सेल-आधारित फेलओवर के लिए तैयारी जांच + रूटिंग नियंत्रण।
क्यों: सादे Route 53 स्वास्थ्य जांच एंडपॉइंट्स का मूल्यांकन करती हैं। ARC स्पष्ट, ऑडिटेड फेलओवर के लिए सक्रिय/स्टैंडबाय कंट्रोल प्लेन जोड़ता है।
रोलबैक क्षमता के साथ RDS प्रमुख संस्करण अपग्रेड करें।
RDS Blue/Green Deployments। नए संस्करण के साथ ग्रीन क्लोन स्पिन अप करें; बिनलॉग फिर से चलाएं; <1 मिनट में स्विच करें।
क्यों: इन-प्लेस प्रमुख अपग्रेड अपरिवर्तनीय है। Blue/Green कटओवर सफल होने तक पुराने DB को लाइव रखता है।
स्वचालित-रोलबैक के साथ खराब डिप्लॉयमेंट के ब्लास्ट त्रिज्या को कम करें।
Canary कॉन्फ़िग (जैसे, `CodeDeployDefault.ECSCanary10Percent5Minutes`) के साथ CodeDeploy। CloudWatch अलार्म रोलबैक को ट्रिगर करता है।
क्यों: Canary 5 मिनट के लिए 10% तक टूट-फूट को नियंत्रित करता है। एक साथ सब कुछ अधिकतम ब्लास्ट; रोलिंग फैलता है लेकिन कोई ट्रैफ़िक-आधारित गेट नहीं।
Lambda फ़ंक्शंस मेमोरी पर ओवर-प्रावधानित हैं।
Lambda के लिए Compute Optimizer। इनवोकेशन प्रोफाइल से मेमोरी-ट्यूनिंग सिफारिशें।
क्यों: AWS Lambda Power Tuning स्टेट मशीन वैकल्पिक है - Compute Optimizer हैंड्स-ऑफ है।
देखी गई CloudTrail गतिविधि से कम से कम विशेषाधिकार IAM नीति उत्पन्न करें।
IAM Access Analyzer नीति जनरेशन। भूमिका के लिए CloudTrail का विश्लेषण करता है; केवल उपयोग की गई क्रियाओं की एक नीति उत्सर्जित करता है।
क्यों: `iam:Get*` आदि को मैन्युअल रूप से पीसने से बेहतर। उत्पन्न नीति को प्रारंभिक बिंदु के रूप में उपयोग करें, फिर समीक्षा करें।
EC2 से RDS तक कनेक्शन विफल हो रहा है - पैकेट कैप्चर के बिना क्यों पता लगाएं।
VPC Reachability Analyzer। रूट टेबल्स, SGs, NACLs, NAT, पीयरिंग का स्टैटिक विश्लेषण। ब्लॉकर वापस करता है।
क्यों: tcpdump से तेज़। विशिष्ट कॉन्फ़िग (कौन सा SG नियम, कौन सा NACL अस्वीकार) की पहचान करता है।
ऑडिट करें कि इंटरनेट से आंतरिक संसाधनों तक कौन से पथ पहुंच सकते हैं।
VPC Network Access Analyzer। स्कोप एक्सप्रेशन निषिद्ध पथों का वर्णन करते हैं (जैसे, इंटरनेट → DB टियर)। मिलान करने वाले पथ वापस करता है।
क्यों: Reachability Analyzer पॉइंट-टू-पॉइंट है; Network Access Analyzer स्कोप-व्यापी अनुपालन है।
संगठन में लागत पर त्वरित जीत।
Trusted Advisor लागत-अनुकूलन जांच (Business/Enterprise Support की आवश्यकता है)। निष्क्रिय ELBs, कम-उपयोग EC2, अप्रयुक्त EIPs, RI उपयोग।
क्यों: TA का मुफ्त टियर सीमित है; Business+ सभी जांचों को अनलॉक करता है। प्रतिनिधायित प्रशासक के साथ Org दृश्य एकत्रित फाइंडिंग्स दिखाता है।
Lambda → RDS कनेक्शन तूफान DB कनेक्शन को समाप्त करते हैं।
RDS Proxy। Lambda और RDS/Aurora के बीच कनेक्शन पूलिंग। फेलओवर तेज़ (~66% कमी)।
क्यों: Lambda समवर्तीता सबसे खराब स्थिति में प्रति इनवोकेशन एक कनेक्शन बनाती है। प्रॉक्सी एक छोटे पूल पर मल्टीप्लेक्स करता है।
ओरिजिन पर लॉन्ग-टेल सामग्री कैश मिस दर बहुत अधिक - ओरिजिन लोड के तहत।
ओरिजिन के पास एक क्षेत्र में CloudFront Origin Shield। ओरिजिन हिट करने से पहले किनारों पर अनुरोधों को डी-डुप्लिकेट करता है।
क्यों: Origin Shield के बिना प्रत्येक POP स्वतंत्र रूप से ओरिजिन से चूक जाता है। Shield ओरिजिन हिट दर को ~70% कम करता है।
न्यूनतम डाउनटाइम के साथ 200 ऑन-प्रिमाइसेस सर्वर को EC2 में लिफ्ट-एंड-शिफ्ट करें।
AWS Application Migration Service (MGN)। निरंतर ब्लॉक-स्तर प्रतिकृति; मिनटों में प्रति सर्वर कट ओवर करें।
क्यों: MGN AWS-अनुशंसित रीहोस्ट टूल है (SMS + CloudEndure को बदला)। प्रति-सर्वर कट ओवर वेव-आधारित माइग्रेशन को सक्षम बनाता है।
न्यूनतम डाउनटाइम के साथ ऑन-प्रिमाइसेस Oracle को Aurora PostgreSQL में माइग्रेट करें।
स्कीमा + प्रक्रिया पुनर्लेखन के लिए Schema Conversion Tool (SCT)। पूर्ण-लोड + CDC के लिए AWS DMS।
क्यों: SCT कोड को संबोधित करता है; DMS डेटा को संबोधित करता है। CDC कटओवर तक स्रोत को सिंक में रखता है।
सभी ऑन-प्रिमाइसेस डेटाबेस खोजें और माइग्रेशन जटिलता का आकलन करें।
AWS DMS Fleet Advisor। बड़े पैमाने पर विषम फ्लीट का इन्वेंट्री + आकलन करें।
क्यों: Fleet Advisor DMS नौकरियों को लॉन्च करने से पहले खोज + साइज़िंग को एक वर्कफ़्लो में समेकित करता है।
माइग्रेशन रणनीति के लिए 500 ऐप्स को वर्गीकृत करें।
सेवन Rs फ्रेमवर्क: Retire (सेवामुक्त करें), Retain (ऑन-प्रिमाइसेस रखें), Relocate (VMware Cloud लिफ्ट), Rehost (MGN), Replatform (स्व-प्रबंधित DB के बजाय RDS), Repurchase (ड्रॉप और SaaS), Refactor (माइक्रोसेर्विसेस)।
क्यों: बड़े पोर्टफोलियो सभी 7 को मिलाते हैं। प्रति ऐप शुरुआती मैपिंग एक-आकार-सभी-के-लिए माइग्रेशन ऋण से बचाती है।
तरंगों को शुरू करने से पहले निर्भरताओं के साथ माइग्रेशन इन्वेंट्री बनाएं।
AWS Application Discovery Service। एजेंटलेस (vCenter स्कैन) या एजेंट-आधारित (प्रति-सर्वर)। निर्भरता मानचित्र आउटपुट करता है।
क्यों: निर्भरता मैपिंग के बिना, वेव-प्लानिंग तंग युग्मन को चूक जाती है। डिस्कवरी उन्हें स्वचालित रूप से सतह पर लाती है।
MGN, DMS, Refactor Spaces में 100s की इन-फ़्लाइट सर्वर + DB माइग्रेशन को ट्रैक करें।
एकल कंसोल के रूप में AWS Migration Hub। MGN, DMS, Refactor Spaces से स्थिति को एकत्रित करता है।
क्यों: प्रति-टूल कंसोल स्थिति को खंडित करते हैं। Migration Hub समेकित करता है और पोर्टफोलियो रिपोर्टिंग का समर्थन करता है।
कोई उपयोगी WAN बैंडविड्थ न होने वाले दूरस्थ साइट से 100 TB डेटा ले जाएं।
AWS Snowball Edge Storage Optimized। डिवाइस को शिप करें, स्थानीय रूप से कॉपी करें, AWS को वापस करें। >80 TB के लिए समानांतर में कई डिवाइस।
क्यों: Snowmobile (45 PB) एक्सबाइट के लिए है; Snowcone (8 TB) छोटे के लिए। Edge पेटाबाइट-स्केल वर्कहॉर्स है।
ऑन-प्रिमाइसेस NFS → S3 में बैंडविड्थ कैप्स के साथ निरंतर डेटा प्रतिकृति।
AWS DataSync एजेंट। शेड्यूल किए गए कार्य; प्रति-कार्य बैंडविड्थ थ्रॉटल; अखंडता के लिए सत्यापित मोड।
क्यों: DataSync उद्देश्य-निर्मित है और WAN पर स्व-प्रबंधित rsync से 10 गुना तेज़ है। Snowball ऑफ़लाइन है; DataSync ऑनलाइन है।
ऑन-प्रिमाइसेस ऐप NFS/SMB की अपेक्षा करता है लेकिन डेटा S3 में लैंड होना चाहिए।
Storage Gateway में File Gateway। लोकल कैश + S3 बैकएंड; S3 API के माध्यम से भी ऑब्जेक्ट पहुंच योग्य।
क्यों: Volume Gateway iSCSI को उजागर करता है; Tape Gateway VTL का अनुकरण करता है। File Gateway NAS-टू-S3 ब्रिज है।
VMware-भारी शॉप AWS-साइड क्षमता चाहती है बिना vSphere/NSX को फिर से टूल किए।
AWS पर VMware Cloud। बेयर-मेटल AWS होस्ट पर समान vSphere स्टैक। लाइव माइग्रेशन के लिए HCX का उपयोग करें।
क्यों: परिचालन टूलिंग को संरक्षित करता है। रिफैक्टर से पहले ब्रिज करें। बाद में, धीरे-धीरे नेटिव AWS सेवाओं में रिप्लेटफॉर्म करें।
पुनर्लेखन के बिना विरासत Java/.NET मोनोलिथ्स को कंटेनराइज़ करें।
AWS App2Container CLI। चल रहे ऐप का निरीक्षण करता है, कंटेनर कलाकृतियों + ECS/EKS मैनिफ़ेस्ट उत्पन्न करता है।
क्यों: A2C रनटाइम कॉन्फ़िग (पर्यावरण, पोर्ट, निर्भरताएं) को एक काम करने वाली छवि में कैप्चर करता है। मैन्युअल कंटेनराइज़ेशन गैर-स्पष्ट निर्भरताओं को चूक जाता है।
COBOL मेनफ़्रेम आधुनिकीकरण - Java माइक्रोसेर्विसेस में परिवर्तित करें।
Blu Age (रिफैक्टर) या Micro Focus (रिप्लेटफॉर्म) के साथ AWS Mainframe Modernization सेवा। रनटाइम अनुकरण के लिए सहिष्णुता के आधार पर चुनें।
क्यों: रिफैक्टर क्लाउड-नेटिव पैटर्न को अनलॉक करता है; रिप्लेटफॉर्म तेज़ है लेकिन मेनफ़्रेम का अनुकरण करता है। दोनों मेनफ़्रेम लाइसेंस लागत को कम करते हैं।
विकास को फ्रीज किए बिना 18 महीनों में एक मोनोलिथ को डीकंपोज़ करें।
Strangler Fig पैटर्न। API Gateway/ALB के साथ मोनोलिथ को सामने रखें; विशिष्ट एंडपॉइंट्स को नए माइक्रोसेर्विसेस में रूट करें जैसे कि वे तराशे गए हैं।
क्यों: बिग-बैंग रीराइट्स आमतौर पर विफल होते हैं। Strangler रूट द्वारा कटओवर को डिकपल करता है, संक्रमण के दौरान मोनोलिथ को कार्यात्मक रखता है।
रूटीनिंग प्लेन का मालिक हुए बिना धीरे-धीरे माइक्रोसेर्विसेस निकालना चाहते हैं।
AWS Migration Hub Refactor Spaces। API Gateway + VPCs पर प्रबंधित एप्लिकेशन/रूट/सेवा अमूर्तन।
क्यों: Strangler Fig के प्लंबिंग को लिखने से बचाता है। वृद्धिशील निष्कर्षण के लिए पूर्व-निर्मित रूटिंग + VPC कनेक्टिविटी।
EC2 पर स्व-प्रबंधित PostgreSQL → प्रबंधित ऑप्स के लिए RDS।
CDC के साथ कटओवर के लिए DMS। RDS Custom का उपयोग केवल तभी करें जब आपको OS एक्सेस या विक्रेता-विशिष्ट एक्सटेंशन की आवश्यकता हो।
क्यों: RDS बैकअप/पैच/HA को संभालता है। RDS Custom विरासत की जरूरतों के लिए एस्केप हैच है लेकिन ऑप्स बोझ को फिर से प्रस्तुत करता है।
प्रदर्शन + लागत के लिए RDS MySQL से Aurora MySQL में जाएं।
RDS से Aurora रीड रेप्लिका, फिर प्रमोट करें। या DMS शून्य-डाउनटाइम के लिए जब संस्करण भिन्नताएं मायने रखती हैं।
क्यों: रीड-रेप्लिका पथ इंजन में सबसे सरल है। DMS संस्करण भिन्नताओं और विषम चालों को संभालता है।
एंटरप्राइज़ AWS माइग्रेशन फंडिंग + सर्वोत्तम-अभ्यास फ्रेमवर्क चाहता है।
AWS Migration Acceleration Program (MAP)। चरण: Assess (MRA), Mobilize (MAP पार्टनर + टूलिंग), Migrate & Modernize।
क्यों: MAP फंडिंग और संरचित कार्यप्रणाली को अनलॉक करता है। MAP को छोड़ना दोनों को चूक जाता है।
कार्यकारी प्रायोजक के लिए पूर्व-माइग्रेशन लागत अनुमान।
AWS Pricing Calculator (डिज़ाइन किया गया कॉन्फ़िग) + Migration Evaluator (ऑन-प्रिमाइसेस इन्वेंट्री से डेटा-संचालित)।
क्यों: Pricing Calculator "व्हाट-इफ" मूल्य निर्धारण देता है। Migration Evaluator वास्तविक बचत को प्रोजेक्ट करने के लिए vSphere/Hyper-V डेटा को इनजेस्ट करता है।
स्व-होस्टेड SFTP सर्वर को सेवामुक्त करें; विक्रेता भागीदारों को SFTP का उपयोग जारी रखने की आवश्यकता है।
S3 या EFS द्वारा समर्थित AWS Transfer Family (SFTP/FTPS/FTP)।
क्यों: प्रबंधित प्रोटोकॉल सेवा। IAM-मैप किए गए उपयोगकर्ता; केवल VPC एंडपॉइंट्स। EC2 SSH डेमन्स चलाने से बचता है।
AD एकीकरण के साथ Windows फ़ाइल शेयर को लिफ्ट-एंड-शिफ्ट करें।
Amazon FSx for Windows File Server। AD-जॉइन्ड; SMB; ऑन-प्रिमाइसेस से ऑनलाइन सिंक के लिए DataSync; थोक के लिए Snowball।
क्यों: FSx for Windows AD-नेटिव लैंडिंग ज़ोन है। EFS केवल Linux-ओनली है; S3 में SMB सेमांटिक्स की कमी है।
सभी NetApp सुविधाओं (स्नैपशॉट, FlexClone) को रखते हुए NetApp ONTAP वर्कलोड को माइग्रेट करें।
Amazon FSx for NetApp ONTAP। नेटिव ONTAP APIs; मल्टी-प्रोटोकॉल NFS+SMB; ऑन-प्रिमाइसेस से SnapMirror प्रतिकृति।
क्यों: अन्य FSx फ्लेवर ONTAP-विशिष्ट सुविधाओं को उजागर नहीं करते हैं। बैकअप/प्रतिकृति को फिर से आर्किटेक्ट किए बिना NetApp को लिफ्ट-एंड-शिफ्ट करें।
DNS-आधारित कटओवर DNS-कैश स्ट्रैगलर्स का जोखिम उठाता है।
CloudFront / ALB / Global Accelerator के पीछे कटओवर। सार्वजनिक DNS बदले बिना बैकएंड स्विच करें।
क्यों: कैश TTL का सम्मान करते हैं लेकिन क्लाइंट/फ़ायरवॉल आक्रामक रूप से कैश करते हैं। स्थिर सार्वजनिक पता DNS स्ट्रैगलर्स से बचाता है।
जोखिम नियंत्रण के लिए ऑन-प्रिमाइसेस से AWS तक धीरे-धीरे ट्रैफ़िक माइग्रेशन।
Route 53 वेटेड रूटिंग। 1% → AWS से शुरू करें, धीरे-धीरे बढ़ाएं। स्वचालित फेलबैक के लिए स्वास्थ्य जांच।
क्यों: वेटेड रूटिंग DNS लेयर पर कैनरी-स्टाइल माइग्रेशन को सक्षम बनाता है। ARC उच्च-दांव कट के लिए स्पष्ट गेट्स जोड़ता है।
माइग्रेट किए गए वर्कलोड में Windows / Oracle / SQL Server BYOL लाइसेंस ट्रैक करें।
AWS License Manager। नियम परिभाषित करें; लॉन्च पर लागू करें; RAM के माध्यम से पूरे संगठन में साझा करें।
क्यों: BYOL गैर-अनुपालन महंगा है। License Manager आकस्मिक ओवर-डिप्लॉयमेंट को रोकता है।
माइग्रेशन के बाद, देव/परीक्षण RDS इंस्टेंस रात भर ओवर-प्रावधानित होते हैं।
देव/परीक्षण को कम न्यूनतम ACU के साथ Aurora Serverless v2 में माइग्रेट करें। निष्क्रिय होने पर स्वचालित रूप से स्केल डाउन करें।
क्यों: इंस्टेंस शेड्यूलर जटिलता के बिना रात की निष्क्रिय लागत बचाता है।
माइग्रेशन के दौरान EKS के समान उपकरणों के साथ ऑन-प्रिमाइसेस पर Kubernetes चलाएं।
ऑन-प्रिमाइसेस हार्डवेयर पर EKS Anywhere। समान Kubernetes संस्करण + ECR + AWS Outposts एकीकरण।
क्यों: सुसंगत कंट्रोल प्लेन ऑपरेटर कौशल विचलन को कम करता है। EKS में बाद में माइग्रेशन एक वर्कलोड चाल है, न कि टूलिंग पुनर्लेखन।