अंतिम समीक्षा: मई 2026
SAA-C03 परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
थ्री-टियर ऐप: वेब, ऐप, DB। किसी भी परिस्थिति में DB इंटरनेट से अप्राप्य होना चाहिए।
वेब टियर के लिए पब्लिक सबनेट (ALB)। ऐप और DB टियर के लिए प्राइवेट सबनेट। DB सुरक्षा समूह केवल ऐप-टियर सुरक्षा समूह से ट्रैफ़िक की अनुमति देता है (CIDR रेंज से नहीं)।
क्यों: सबनेट राउटिंग टेबल पहुंच को लागू करते हैं; सिक्योरिटी-ग्रुप-टू-सिक्योरिटी-ग्रुप संदर्भ SG परत पर न्यूनतम-विशेषता को एन्कोड करते हैं और IP परिवर्तनों के बाद भी बने रहते हैं।
EC2 इंस्टेंस को S3 तक पहुंचने की आवश्यकता है। एम्बेडेड क्रेडेंशियल्स से बचें।
IAM रोल इंस्टेंस प्रोफ़ाइल के माध्यम से अटैच किया गया। SDK IMDSv2 से अस्थायी क्रेडेंशियल्स प्राप्त करता है।
क्यों: इंस्टेंस पर लंबे समय तक चलने वाली एक्सेस कुंजियाँ क्रेडेंशियल लीक का नंबर 1 कारण हैं। रोल स्वचालित रूप से घूमते हैं, कभी भी संग्रहीत नहीं होते।
SSRF हमलों को ब्लॉक करें जो EC2 इंस्टेंस मेटाडेटा को पढ़ने का प्रयास करते हैं।
इंस्टेंस लॉन्च पर IMDSv2 (`HttpTokens=required`) लागू करें। IMDSv1 अप्रमाणित अनुरोधों को अस्वीकार करें।
क्यों: IMDSv2 को मेटाडेटा एंडपॉइंट के जवाब देने से पहले PUT के माध्यम से एक सेशन टोकन की आवश्यकता होती है; केवल GET करने वाले SSRF हमलों को ब्लॉक कर दिया जाता है।
अकाउंट A में सर्विस A, अकाउंट B में Lambda को इनवोक करती है। न्यूनतम विशेषाधिकार।
टारगेट Lambda पर रिसोर्स-आधारित पॉलिसी, जो अकाउंट A के रोल प्रिंसिपल को `lambda:InvokeFunction` प्रदान करती है। कॉलर अपनी भूमिका धारण करता है और सीधे इनवोक करता है - कोई रोल चेनिंग की आवश्यकता नहीं है।
क्यों: रिसॉर्स पॉलिसीज सर्विस-फ्रंटेड रिसोर्सेज (Lambda, S3, SNS, SQS, KMS) के लिए सबसे सरल क्रॉस-अकाउंट पैटर्न हैं।
अन्य AWS अकाउंट्स को एक केंद्रीय S3 बकेट में अपलोड करने की आवश्यकता है।
बकेट पॉलिसी जो बाहरी अकाउंट प्रिंसिपल्स को `s3:PutObject` प्रदान करती है। `bucket-owner-full-control` ACL आवश्यकता जोड़ें ताकि बकेट मालिक ऑब्जेक्ट्स पर नियंत्रण बनाए रखे।
क्यों: `bucket-owner-full-control` (या `BucketOwnerEnforced` ऑब्जेक्ट ओनरशिप) के बिना, अपलोड किए गए ऑब्जेक्ट्स राइटर अकाउंट के स्वामित्व में होते हैं।
संगठन में किसी भी S3 बकेट को सार्वजनिक होने से रोकें।
अकाउंट स्तर पर S3 ब्लॉक पब्लिक एक्सेस (और SCPs के माध्यम से ऑर्गनाइजेशन-व्यापी) सक्षम करें। यह बकेट-स्तर की ACLs और नीतियों को ओवरराइड करता है।
क्यों: अकाउंट-स्तर की सेटिंग प्रति-बकेट सेटिंग्स पर जीत जाती है - आकस्मिक गलत कॉन्फ़िगरेशन के खिलाफ बचाव।
डेवलपर्स को IAM भूमिकाएं स्व-सेवा करनी होंगी लेकिन एक परिभाषित अधिकतम-अनुमति सेट से अधिक नहीं दे सकते।
डेवलपर प्रिंसिपल पर परमिशन बाउंड्रीज। प्रभावी अनुमतियां = आइडेंटिटी पॉलिसी ∩ बाउंड्री।
क्यों: SCPs अकाउंट/OU स्तर पर लागू होते हैं; बाउंड्रीज व्यक्तिगत प्रिंसिपल्स को स्कोप करते हैं। प्रत्यायोजित एडमिन पैटर्न के लिए बाउंड्रीज का उपयोग करें।
डेटा-रेसीडेंसी अनुपालन के लिए एक OU को विशिष्ट रीजन्स तक सीमित करें।
ऑर्गनाइजेशंस में सर्विस कंट्रोल पॉलिसी जो किसी भी कार्रवाई से इनकार करती है जहां `aws:RequestedRegion` अनुमत सूची में नहीं है।
क्यों: SCPs एकमात्र तंत्र हैं जो उन कार्यों से इनकार कर सकते हैं जिनकी अनुमति अकाउंट खुद देता है। IAM उस चीज से इनकार नहीं कर सकता जो अकाउंट-रूट प्रदान कर सकता है।
कई AWS अकाउंट्स में वर्कफोर्स सिंगल साइन-ऑन; कॉर्पोरेट IdP के साथ इंटीग्रेट करें।
कॉर्पोरेट IdP के लिए SAML/OIDC फेडरेशन के साथ AWS IAM आइडेंटिटी सेंटर (पूर्व में AWS SSO)। परमिशन सेट्स सदस्य अकाउंट्स में भूमिकाओं से मैप होते हैं।
क्यों: आइडेंटिटी सेंटर प्रामाणिक मल्टी-अकाउंट वर्कफोर्स आइडेंटिटी है। Cognito एप्लिकेशन एंड यूजर्स के लिए है, कर्मचारियों के लिए नहीं।
Cognito यूजर पूल बनाम आइडेंटिटी पूल चुनें।
यूजर पूल = ऐप यूजर्स के लिए साइन-अप / साइन-इन / JWT जारी करना। आइडेंटिटी पूल = अस्थायी AWS क्रेडेंशियल्स के लिए टोकन का आदान-प्रदान करना। अधिकांश ऐप्स दोनों का उपयोग करते हैं: यूजर पूल प्रमाणित करता है, आइडेंटिटी पूल AWS एक्सेस को अधिकृत करता है।
Cognito साइन-इन में कस्टम सत्यापन चरण जोड़ें (उदाहरण के लिए ईमेल डोमेन को अनुमति सूची में जोड़ें)।
Lambda ट्रिगर्स: प्री साइन-अप, प्री ऑथेंटिकेशन, डिफाइन/क्रिएट/वेरिफाई ऑथ चैलेंज। Lambda में मान्य करें या अस्वीकार करें।
कुंजी रोटेशन, डिलीशन और प्रति-कुंजी ऑडिट ट्रेल पर पूर्ण नियंत्रण की आवश्यकता है।
ग्राहक-प्रबंधित KMS कुंजी (CMK)। AWS-प्रबंधित कुंजियाँ (`aws/<service>`) सरल हैं लेकिन कोई कुंजी-नीति नियंत्रण या व्यक्तिगत कुंजी उपयोग में दृश्यता प्रदान नहीं करती हैं।
क्यों: CMKs आपको CloudTrail में प्रति कुंजी पहुंच को स्कोप करने, क्रॉस-अकाउंट उपयोग के लिए कुंजी नीतियां सेट करने और डिलीशन को अक्षम/निर्धारित करने की सुविधा देते हैं।
अकाउंट B को अकाउंट A की CMK से एन्क्रिप्ट किए गए S3 ऑब्जेक्ट्स को डिक्रिप्ट करने की आवश्यकता है।
CMK पर कुंजी नीति अकाउंट B प्रिंसिपल्स को `kms:Decrypt` प्रदान करती है। अकाउंट B के IAM को कुंजी ARN पर `kms:Decrypt` की भी आवश्यकता है। दोनों भाग आवश्यक हैं।
क्यों: KMS क्रॉस-अकाउंट के लिए कुंजी नीति और कॉलर IAM पहचान दोनों पर स्पष्ट अनुमति की आवश्यकता होती है (अधिकांश रिसोर्स नीतियों के विपरीत)।
`us-east-1` में डेटा एन्क्रिप्ट करें; प्रतिकृति के बाद `us-west-2` में फिर से एन्क्रिप्ट किए बिना डिक्रिप्ट करें।
KMS मल्टी-रीजन कुंजी। एक रीजन में प्राइमरी, दूसरे में प्रतिकृति, दोनों समान कुंजी सामग्री और ID के साथ।
क्यों: क्रॉस-रीजन फेलओवर या DR के लिए सिफरटेक्स्ट री-रैप डांस से बचता है।
प्रति-ऑब्जेक्ट KMS API कॉल के बिना बड़ी वस्तुओं को एन्क्रिप्ट करें जिससे लागत बढ़ रही हो।
एनवेलप एन्क्रिप्शन। KMS एक डेटा कुंजी उत्पन्न करता है (एक API कॉल); पेलोड को स्थानीय रूप से एन्क्रिप्ट करने के लिए डेटा कुंजी का उपयोग करें; एन्क्रिप्टेड-डेटा-कुंजी को सिफरटेक्स्ट के साथ स्टोर करें।
क्यों: KMS दर-सीमित है और प्रति अनुरोध मूल्य निर्धारित किया जाता है। एनवेलप पैटर्न कुछ KB से अधिक डेटा को एन्क्रिप्ट करने का प्रामाणिक तरीका है।
Secrets Manager बनाम SSM पैरामीटर स्टोर SecureString चुनें।
स्वचालित रोटेशन, क्रॉस-अकाउंट शेयर, बड़े सीक्रेट्स वाले DB क्रेडेंशियल्स → Secrets Manager। कॉन्फ़िग फ़्लैग, ऐप सेटिंग्स, सरल सीक्रेट्स, सबसे कम लागत → SSM पैरामीटर स्टोर।
क्यों: Secrets Manager में RDS/Aurora/DocumentDB/Redshift के लिए अंतर्निहित रोटेशन लैम्डास हैं; पैरामीटर स्टोर में कोई मूल रोटेशन नहीं है लेकिन स्टैंडर्ड टियर के लिए यह मुफ्त है।
RDS पासवर्ड को हर 30 दिन में स्वचालित रूप से घुमाएं।
प्रबंधित रोटेशन के साथ Secrets Manager। अंतर्निहित लैम्डा टेम्पलेट RDS एंडपॉइंट के खिलाफ एकल-उपयोगकर्ता रोटेशन को संभालता है। ऐप्स कनेक्ट समय पर सीक्रेट प्राप्त करते हैं (कैश किए गए) - कोई ऐप रीडिप्लॉयमेंट नहीं।
वैध स्पाइक्स को ब्लॉक किए बिना लेयर 7 HTTP फ्लड को कम करें।
ALB या CloudFront पर AWS WAF दर-आधारित नियम (उदाहरण के लिए प्रति IP 5 मिनट में 2000 अनुरोध)। ज्ञात-खराब IPs के लिए प्रबंधित नियम समूहों के साथ संयोजन करें।
क्यों: WAF दर नियम प्रति-स्रोत-IP को ट्रैक करते हैं; सीमा पार होने पर स्वतः ब्लॉक होते हैं; विंडो के बाद रिलीज़ होते हैं।
मिशन-क्रिटिकल ऐप को DDoS लागत-सुरक्षा और 24x7 SRT समर्थन की आवश्यकता है।
CloudFront / ALB / NLB / Global Accelerator पर AWS Shield Advanced। इसमें लागत सुरक्षा (हमले के दौरान स्केलिंग खर्च के लिए रिफंड) + शील्ड रिस्पांस टीम एक्सेस शामिल है।
क्यों: शील्ड स्टैंडर्ड स्वचालित और मुफ्त है; एडवांस्ड सुरक्षा और SLA जोड़ता है। CloudFront हमेशा अनुशंसित फ्रंट डोर है।
सुरक्षा समूह बनाम NACL चुनें।
स्टेटफुल, ENI से संलग्न, केवल अनुमति दें → सुरक्षा समूह (डिफ़ॉल्ट)। स्टेटलेस, सबनेट-स्तर, अनुमति दें + स्पष्ट रूप से अस्वीकार करें → NACL। व्यापक अस्वीकार नियमों (IP श्रेणियों को ब्लॉक करें) के लिए NACLs का उपयोग करें; बाकी सब के लिए SGs का उपयोग करें।
क्यों: NACLs इनबाउंड और आउटबाउंड का अलग-अलग मूल्यांकन करते हैं। SGs स्वचालित रूप से वापसी ट्रैफ़िक की अनुमति देते हैं।
प्राइवेट सबनेट में EC2 को NAT निकास लागत के बिना S3/DynamoDB तक पहुंचने की आवश्यकता है।
S3 और DynamoDB के लिए VPC गेटवे एंडपॉइंट। मुफ्त, रूट-टेबल एंट्री, कोई NAT नहीं।
क्यों: गेटवे एंडपॉइंट केवल S3/DynamoDB के लिए हैं। यह NAT डेटा-प्रोसेसिंग शुल्क बचाता है और ट्रैफ़िक को AWS बैकबोन पर रखता है।
प्राइवेट सबनेट को निजी तौर पर AWS सेवा APIs (KMS, Secrets Manager, ECR, आदि) तक पहुंचने की आवश्यकता है।
प्रति सेवा VPC इंटरफेस एंडपॉइंट (PrivateLink)। आपके VPC में ENI, प्रति घंटा + प्रति GB चार्ज किया जाता है।
क्यों: इंटरफ़ेस एंडपॉइंट लगभग हर AWS सेवा के लिए काम करते हैं। सेवा कॉल के लिए NAT निकास को हटाने के लिए उपयोग करें।
SaaS प्रदाता अपनी इन-VPC सेवा को ग्राहक अकाउंट्स को निजी तौर पर उजागर करता है, बिना VPC पीयरिंग या ग्राहक राउटिंग को बनाए रखे।
NLB द्वारा समर्थित AWS PrivateLink एंडपॉइंट सेवा। ग्राहक उपभोग करने के लिए इंटरफेस एंडपॉइंट बनाते हैं।
क्यों: कोई CIDR ओवरलैप चिंता नहीं, कोई पीयरिंग मेशिंग नहीं, एक-तरफ़ा एक्सपोजर (प्रदाता कोई ग्राहक ट्रैफ़िक नहीं देखता)।
हब-एंड-स्पोक टोपोलॉजी में अकाउंट्स और ऑन-प्रेमिसेस में 30+ VPCs को कनेक्ट करें।
AWS Transit Gateway। प्रति VPC एकल अटैचमेंट; रूट टेबल ट्रैफ़िक को सेगमेंट करते हैं।
क्यों: फुल-मेश पीयरिंग को N×(N-1)/2 कनेक्शन की आवश्यकता होती है। TGW रैखिक रूप से स्केल करता है और RAM के माध्यम से क्रॉस-अकाउंट का समर्थन करता है।
हाइब्रिड कनेक्टिविटी जिसे अनुमानित बैंडविड्थ, कम विलंबता और एन्क्रिप्शन की आवश्यकता होती है।
DX (MACsec या IPsec) पर साइट-टू-साइट VPN के साथ Direct Connect। DX अकेला एन्क्रिप्टेड नहीं है; DX पर VPN निजी + एन्क्रिप्टेड + कम-झटका वाला है।
क्यों: इंटरनेट पर प्लेन VPN सस्ता है लेकिन इसमें परिवर्तनशील विलंबता होती है। DX अकेला तेज़ है लेकिन लिंक लेयर पर प्लेनटेक्स्ट है।
VPC फ्लो लॉग्स, DNS, CloudTrail, EKS ऑडिट, S3 डेटा इवेंट्स में निरंतर खतरे का पता लगाना।
Amazon GuardDuty। ऑर्गनाइजेशंस डेलीगेटेड एडमिन के माध्यम से संगठन-व्यापी।
क्यों: प्रबंधित खतरे का पता लगाना। प्रतिक्रिया स्वचालन के लिए Security Hub या EventBridge में निष्कर्ष।
S3 बकेट में PII / PHI का पता लगाएं और वर्गीकृत करें।
Amazon Macie। ML-आधारित संवेदनशील-डेटा खोज, S3-स्कोपेड, Security Hub के साथ इंटीग्रेट होता है।
EC2, ECR इमेज, Lambda फंक्शंस के लिए निरंतर CVE स्कैनिंग।
Amazon Inspector v2। सिस्टम्स मैनेजर एजेंट के माध्यम से संसाधनों का स्वतः पता लगाता है, प्रकाशित CVEs के खिलाफ स्कैन करता है।
GuardDuty, Inspector, Macie, IAM एक्सेस एनालाइजर से निष्कर्षों को एक डैशबोर्ड में एकत्रित करें।
AWS Security Hub। AWS फ़ाउंडेशनल सिक्योरिटी बेस्ट प्रैक्टिसेज और CIS मानकों के साथ CSPM।
यह लागू करें कि सभी EBS वॉल्यूम एन्क्रिप्टेड हों; गैर-अनुपालक संसाधनों को स्वचालित रूप से ठीक करें।
AWS कॉन्फ़िग नियम (प्रबंधित `encrypted-volumes`) + सुधार के लिए सिस्टम्स मैनेजर ऑटोमेशन रनबुक, कॉन्फ़िग सुधार कार्रवाई के माध्यम से ट्रिगर किया गया।
संगठन के सभी अकाउंट्स में एकल छेड़छाड़-रोधी ऑडिट लॉग।
लॉग-फ़ाइल सत्यापन सक्षम के साथ ऑर्गनाइजेशन ट्रेल, केंद्रीय S3 बकेट में लिखा गया जिसमें डिलीट को अस्वीकार करने वाली बकेट पॉलिसी है।
क्यों: संगठन ट्रेल सभी सदस्य अकाउंट्स में स्वतः सक्षम हो जाते हैं (वर्तमान और भविष्य)। सत्यापन हैश यह साबित करते हैं कि लॉग संशोधित नहीं किए गए थे।
कई विभागों को एक साझा S3 बकेट में विभिन्न प्रीफिक्स तक सीमित पहुंच की आवश्यकता है।
S3 एक्सेस पॉइंट्स - प्रत्येक विभाग के लिए एक, प्रत्येक अपनी पहुंच नीति और (वैकल्पिक रूप से) VPC प्रतिबंध के साथ।
क्यों: एक व्यापक बकेट पॉलिसी की तुलना में स्वच्छ; एक्सेस पॉइंट्स के अपने ARN और DNS नाम होते हैं।
PCI DSS कार्यभार - गैर-PCI अकाउंट्स से सख्त अलगाव।
संगठन OU के भीतर एक समर्पित AWS अकाउंट जिसमें सेवा/रीजन पहुंच को प्रतिबंधित करने वाले SCPs हैं। अलग VPC, KMS कुंजियाँ, IAM भूमिकाएँ। निकास निरीक्षण के लिए नेटवर्क फ़ायरवॉल या GWLB।
क्यों: AWS में अकाउंट बाउंड्री सबसे मजबूत ब्लास्ट-रेडियस अलगाव है।
ALB और CloudFront पर `*.example.com` के लिए सार्वजनिक TLS प्रमाणपत्र। स्वचालित रूप से नवीनीकृत करें।
Route 53 में DNS सत्यापन के साथ AWS सर्टिफिकेट मैनेजर (ACM) सार्वजनिक प्रमाणपत्र। समाप्ति से 60 दिन पहले स्वतः-नवीनीकृत होता है।
क्यों: AWS-एकीकृत सेवाओं के साथ उपयोग के लिए मुफ्त। ईमेल सत्यापन काम करता है लेकिन स्वचालन के लिए DNS सत्यापन पसंद किया जाता है।
उत्पादन RDS डेटाबेस जिसमें उप-मिनट फेलओवर हो।
RDS मल्टी-AZ डिप्लॉयमेंट (या मल्टी-AZ DB क्लस्टर)। स्टैंडबाय में सिंक्रोनस प्रतिकृति; DNS एंडपॉइंट स्विच के माध्यम से स्वचालित फेलओवर।
क्यों: मल्टी-AZ HA के लिए है, न कि रीड स्केलिंग के लिए। रीड रेप्लिका रीड्स को स्केल करने के लिए हैं (और एसिंक्रोनस; संभावित लैग)।
नए MySQL/PostgreSQL वर्कलोड के लिए Aurora बनाम RDS चुनें।
उच्च थ्रूपुट, तेज़ फेलओवर, 15 रीड रेप्लिका तक, ग्लोबल डेटाबेस, सर्वरलेस v2 के लिए Aurora। पुराने इंजन (MariaDB, Oracle, SQL Server) या सरल/सस्ते डिप्लॉयमेंट के लिए RDS।
क्यों: Aurora स्टोरेज रेप्लिका में साझा किया जाता है (स्टोरेज से कोई रेप्लिका लैग नहीं)। फेलओवर आमतौर पर 30 सेकंड से कम होता है।
सक्रिय-निष्क्रिय मल्टी-रीजन डेटाबेस जिसमें < 1s प्रतिकृति लैग और < 1 मिनट RTO हो।
Aurora ग्लोबल डेटाबेस। 5 सेकेंडरी रीजन्स तक स्टोरेज-स्तर की प्रतिकृति; आपदा में सेकेंडरी को प्राइमरी में प्रमोट करें।
क्यों: प्रतिकृति समर्पित इन्फ्रास्ट्रक्चर का उपयोग करती है; क्रॉस-रीजन लैग आमतौर पर < 1s होता है। कम-विलंबता वाले स्थानीय रीड्स के लिए दूरस्थ रीजन्स में रीड रेप्लिका।
निष्क्रिय अवधियों के साथ परिवर्तनशील / अप्रत्याशित डेटाबेस लोड।
Aurora Serverless v2। 0.5 ACU की वृद्धि में स्केल करता है; उप-सेकंड स्केल इवेंट; कोई पूर्ण विराम नहीं लेकिन बहुत कम न्यूनतम।
क्यों: v2 स्केल इवेंट्स के दौरान कनेक्शन खुला रखता है (v1 के विपरीत)। प्रति ACU-सेकंड भुगतान करें।
लास्ट-राइटर-विन्स प्रतिकृति के साथ 3+ रीजन्स में सिंगल-डिजिट ms रीड्स + राइट्स।
DynamoDB ग्लोबल टेबल्स। लास्ट-राइटर-विन्स कॉन्फ्लिक्ट रिज़ॉल्यूशन के साथ मल्टी-एक्टिव प्रतिकृति।
क्यों: हर रीजन में सक्रिय-सक्रिय; कोई लीडर नहीं। इसका उपयोग तब करें जब एप्लिकेशन-स्तर की कॉन्फ्लिक्ट सहिष्णुता स्वीकार्य हो।
दुर्घटनाग्रस्त डिलीट के बाद DynamoDB टेबल को पिछले 35 दिनों में एक विशिष्ट बिंदु पर पुनर्प्राप्त करें।
पॉइंट-इन-टाइम रिकवरी (PITR) सक्षम करें। रिस्टोर चुने हुए सेकंड पर एक नई टेबल बनाता है।
प्राइमरी रीजन में ट्रैफ़िक रूट करें; स्वास्थ्य जांच विफल होने पर सेकेंडरी में फेल ओवर करें।
Route 53 फेलओवर राउटिंग पॉलिसी। प्राइमरी एंडपॉइंट पर सक्रिय स्वास्थ्य जांच; प्राइमरी अस्वस्थ होने पर सेकेंडरी रिकॉर्ड सेवा प्रदान करता है।
क्यों: एप्लिकेशन-स्तर की स्वास्थ्य जांच (HTTP पाथ) उन आंशिक विफलताओं को पकड़ लेती है जिन्हें TCP प्रोब मिस करते हैं।
प्रत्येक उपयोगकर्ता को सबसे कम विलंबता वाले स्वस्थ रीजन में भेजें।
Route 53 लेटेंसी-आधारित राउटिंग। प्रत्येक एंडपॉइंट की स्वास्थ्य जांच करें; Route 53 प्रति क्वेरी सबसे कम विलंबता वाला स्वस्थ उत्तर देता है।
कैनरी रोलआउट: 10% v2 को भेजें, 90% v1 को भेजें।
Route 53 वेटेड राउटिंग। एक ही नाम वाले दो रिकॉर्ड, विभिन्न लक्ष्य, वजन 10 और 90।
EC2 इंस्टेंस को इनिशियलाइज़ होने में 3 मिनट लगते हैं; ट्रैफ़िक स्पाइक्स के दौरान स्केल-आउट बहुत धीमा होता है।
ऑटो स्केलिंग वार्म पूल। पूर्व-इनिशियलाइज़्ड इंस्टेंस बंद (सस्ते) रखे जाते हैं जो सेकंडों में शुरू होने के लिए तैयार होते हैं।
क्यों: कोल्ड लॉन्च + बूटस्ट्रैप लंबी पोल है। वार्म पूल उस कार्य को महत्वपूर्ण पाथ से हटा देता है।
स्केल-इन पर, इन-फ़्लाइट कार्य को समाप्त करें और इंस्टेंस समाप्त होने से पहले लॉग्स को बनाए रखें।
`Terminating:Wait` में ऑटो स्केलिंग लाइफ़साइकिल हुक। हुक SNS/EventBridge पर प्रकाशित करता है; हैंडलर ड्रेन को पूरा करता है और `complete-lifecycle-action` को कॉल करता है।
एक गैर-महत्वपूर्ण फ़्लीट पर कंप्यूट लागत में कटौती करें जो रुकावट को सहन करता है।
मिक्सड-इंस्टांसेस पॉलिसी वाला ASG: ऑन-डिमांड पर बेस क्षमता, स्पॉट पर अतिरिक्त क्षमता, विविधीकरण के लिए कई इंस्टेंस प्रकार और AZs।
क्यों: इंस्टेंस प्रकारों में विविधीकरण एकल-पूल की तुलना में स्पॉट रुकावट जोखिम को कम करता है।
ALB बनाम NLB चुनें।
HTTP/HTTPS, पाथ/होस्ट राउटिंग, WAF एकीकरण, OIDC प्रमाणीकरण → ALB। अत्यधिक स्केल पर TCP/UDP/TLS, प्रति AZ स्थिर IP, सबसे कम विलंबता, क्लाइंट स्रोत IP को बनाए रखें → NLB।
VPCs में ट्रैफ़िक निरीक्षण के लिए एक तृतीय-पक्ष सुरक्षा उपकरण फ़्लीट को लाइन में डालें।
Gateway Load Balancer (GWLB) जिसमें उपकरण फ़्लीट को लक्ष्यों के रूप में रखा गया है। GENEVE के माध्यम से ट्रैफ़िक एन्कैप्सुलेटेड; राउटिंग के माध्यम से पारदर्शी सम्मिलन।
जहरीले संदेश हैंडलर्स को विफल करते रहते हैं और फिर से कतार में लग जाते हैं।
SQS डेड-लेटर क्यू। स्रोत क्यू पर `maxReceiveCount` कॉन्फ़िगर करें; संख्या से अधिक संदेश निरीक्षण के लिए DLQ में चले जाते हैं।
प्रति संदेश समूह में सख्त क्रम और ठीक-एक बार प्रसंस्करण।
सामग्री-आधारित डी-डुप्लीकेशन या स्पष्ट `MessageDeduplicationId` के साथ SQS FIFO क्यू। समानांतर क्रमबद्ध समूहों के लिए `MessageGroupId` का उपयोग करें।
क्यों: स्टैंडर्ड SQS कम से कम एक बार होता है जिसमें कोई ऑर्डरिंग गारंटी नहीं होती है। उच्च-थ्रूपुट मोड का उपयोग न करने पर FIFO में कम थ्रूपुट होता है।
एसिंक्रोनस Lambda डाउनस्ट्रीम टाइमआउट पर विफल रहता है - रीप्ले के लिए विफल इवेंट्स को कैप्चर करें।
Lambda डेस्टिनेशंस: विफल गंतव्य को SQS / SNS / EventBridge / एक और Lambda के रूप में कॉन्फ़िगर करें। सफलता गंतव्य भी समर्थित हैं।
क्यों: फ़ंक्शन पर DLQ से स्वच्छ: डेस्टिनेशंस को पूर्ण इवेंट + रिस्पांस पेलोड मिलता है; DLQs को केवल ट्रिगर इवेंट मिलता है।
मल्टी-स्टेप वर्कफ़्लो को एक्सपोनेंशियल बैकऑफ़ और एरर कैच के साथ प्रति-कार्य रीट्राइ की आवश्यकता है।
AWS स्टेप फंक्शंस स्टैंडर्ड वर्कफ़्लो। `IntervalSeconds`, `MaxAttempts`, `BackoffRate` के साथ `Retry` ब्लॉक। `Catch` ब्लॉक विशिष्ट त्रुटियों को रिकवरी स्थिति में रूट करता है।
CloudFront ओरिजिन (S3 या ALB) विफल रहता है - DNS परिवर्तनों के बिना सेकेंडरी ओरिजिन पर फ़ॉल बैक करें।
प्राथमिक + द्वितीयक के साथ CloudFront ओरिजिन समूह। फेलओवर मानदंड (4xx/5xx कोड) कॉन्फ़िगर करें। CloudFront सेकेंडरी के खिलाफ पुनः प्रयास करता है।
एकल रिटेंशन पॉलिसी के साथ EBS, RDS, DynamoDB, EFS, FSx में बैकअप को केंद्रीकृत करें।
टैग द्वारा बैकअप प्लान्स + रिसोर्स सेलेक्शन के साथ AWS Backup। क्रॉस-अकाउंट / क्रॉस-रीजन कॉपी समर्थित। अनुपालन अपरिवर्तनीयता के लिए वॉल्ट लॉक।
रैंसमवेयर-प्रतिरोधी बैकअप: एक एडमिन भी रिटेंशन से पहले डिलीट नहीं कर सकता।
अनुपालन मोड में AWS Backup वॉल्ट लॉक। WORM प्रवर्तन; रूट भी रिटेंशन को छोटा नहीं कर सकता।
RPO/RTO आवश्यकता के अनुसार एक DR पैटर्न चुनें।
बैकअप और पुनर्स्थापना: RPO घंटे, RTO घंटे, सबसे सस्ता। पायलट लाइट: RPO मिनट, RTO 10s मिनट। वार्म स्टैंडबाय: RPO सेकंड, RTO मिनट। मल्टी-साइट सक्रिय-सक्रिय: RPO ~शून्य, RTO सेकंड, सबसे महंगा।
DR के लिए उप-15-मिनट RPO के साथ महत्वपूर्ण बकेट को क्रॉस-रीजन में प्रतिकृति करें।
S3 प्रतिकृति टाइम कंट्रोल (RTC) के साथ S3 क्रॉस-रीजन प्रतिकृति (CRR)। 15 मिनट में 99.99% ऑब्जेक्ट्स।
क्यों: स्टैंडर्ड CRR सर्वोत्तम-प्रयास है। RTC क्लाउडवॉच में एक SLA + प्रतिकृति मेट्रिक्स जोड़ता है।
S3 ऑब्जेक्ट्स को आकस्मिक डिलीट और रैंसमवेयर ओवरराइट से बचाएं।
महत्वपूर्ण बकेट्स पर S3 वर्जनिंग + MFA डिलीट + ऑब्जेक्ट लॉक (गवर्नेंस या अनुपालन मोड) सक्षम करें।
क्यों: वर्जनिंग ओवरराइट्स/डिलीट्स को संरक्षित करती है; ऑब्जेक्ट लॉक रिटेंशन से पहले डिलीट को ब्लॉक करता है; MFA डिलीट स्थायी हटाने के लिए दूसरा कारक जोड़ता है।
ग्लोबल ऐप को दो रीजन्स में जीरो-RTO फेलओवर की आवश्यकता है।
रीजन्स में सक्रिय-सक्रिय: इनग्रेस के लिए ग्लोबल एक्सेलेरेटर या Route 53 लेटेंसी राउटिंग; डेटा के लिए DynamoDB ग्लोबल टेबल्स / Aurora ग्लोबल डेटाबेस; ऑब्जेक्ट स्टोर्स के लिए क्रॉस-रीजन प्रतिकृति।
निकटतम स्वस्थ रीजन में कम झटके के साथ TCP/UDP ट्रैफ़िक; स्थिर एनीकास्ट IP।
AWS ग्लोबल एक्सेलेरेटर। दो एनीकास्ट IP; AWS बैकबोन पर निकटतम एंडपॉइंट पर रूट करता है।
क्यों: गैर-HTTP के लिए Route 53 लेटेंसी से बेहतर। तेज़ फेलओवर (एनीकास्ट) + स्थिर IP अनुमति-सूचीकरण।
Lambda SQS से ऑर्डर प्रोसेस करता है - संदेश दो बार डिलीवर हो सकता है।
आइडempotency: TTL के साथ DynamoDB में अनुरोध हैश स्टोर करें; हर पुनरावृति पर PUT-IfNotExists। या deduplication के साथ FIFO क्यू का उपयोग करें।
स्वैच्छिक पॉड निष्कासन (नोड ड्रेन, क्लस्टर ऑटोस्केलर) एक डिप्लॉयमेंट की सभी रेप्लिका को नीचे ला देते हैं।
Kubernetes PodDisruptionBudget जो `minAvailable` या `maxUnavailable` निर्दिष्ट करता है। क्लस्टर स्वैच्छिक व्यवधानों के दौरान इसका सम्मान करता है।
एक S3 स्टोरेज क्लास चुनें।
बार-बार एक्सेस → Standard। अज्ञात एक्सेस पैटर्न → Intelligent-Tiering। 30+ दिन बाद कभी-कभी एक्सेस → Standard-IA। सिंगल-AZ स्वीकार्य, कभी-कभी एक्सेस → One Zone-IA। आर्काइव, मिलीसेकंड पुनर्प्राप्ति → Glacier Instant। आर्काइव, मिनटों में → Glacier Flexible। आर्काइव, घंटों में, सबसे सस्ता → Glacier Deep Archive।
अप्रत्याशित पैटर्न के साथ मिश्रित-पहुंच बकेट; लागत को स्वतः अनुकूलित करें।
S3 Intelligent-Tiering। एक्सेस की निगरानी करता है; ऑब्जेक्ट्स को टियर (Frequent / Infrequent / Archive Instant / Archive / Deep Archive) में स्वतः स्थानांतरित करता है। कोई पुनर्प्राप्ति शुल्क नहीं।
क्यों: प्रति-ऑब्जेक्ट निगरानी शुल्क बहुत कम है, लेकिन गलत अनुमान लगाने से सस्ता है। अज्ञात पैटर्न के लिए डिफ़ॉल्ट।
इंटरनेट पर बड़ी वस्तुओं (> 100 MB) को मज़बूती से और तेज़ी से अपलोड करें।
S3 मल्टीपार्ट अपलोड (समानांतर भाग) + S3 ट्रांसफर एक्सेलेरेशन (CloudFront एज इनग्रेसन)।
क्यों: समानांतर भाग बैंडविड्थ को संतृप्त करते हैं; ट्रांसफर एक्सेलेरेशन WAN हॉप को AWS बैकबोन पर उतारता है।
EBS वॉल्यूम प्रकार चुनें।
सामान्य-उद्देश्य, डिफ़ॉल्ट → gp3 (3000 बेसलाइन IOPS, 125 MB/s; ट्यूनेबल)। हाई IOPS डेटाबेस → io2 ब्लॉक एक्सप्रेस। बड़े-डेटा अनुक्रमिक थ्रूपुट → st1। कोल्ड आर्काइव → sc1। बूट वॉल्यूम → gp3।
क्यों: gp3 ने IOPS/थ्रूपुट को आकार से अलग कर दिया; समान प्रदर्शन पर gp2 से सस्ता।
कई EC2 इंस्टेंस को एक ही ब्लॉक वॉल्यूम को पढ़ने+लिखने की आवश्यकता है।
io2 / io1 (केवल नाइट्रो इंस्टेंस) के साथ EBS मल्टी-अटैच। एक ही AZ में 16 इंस्टेंस तक समवर्ती अटैच।
क्यों: एप्लिकेशन को राइट्स (क्लस्टर फाइल सिस्टम) को समन्वित करना होगा। साझा फ़ाइल एक्सेस के लिए EFS डिफ़ॉल्ट है; मल्टी-अटैच क्लस्टर्ड DBs के लिए है जिन्हें ब्लॉक की आवश्यकता होती है।
एक साझा फ़ाइल सिस्टम चुनें।
POSIX-अनुरूप Linux NFS, मल्टी-AZ, ऑटो-स्केलिंग → EFS। विंडोज SMB / AD-एकीकृत → FSx for Windows। HPC, Lustre, S3-लिंक्ड → FSx for Lustre। NetApp ONTAP सुविधाएँ (स्नैपशॉट, NetApp टूलिंग) → FSx for ONTAP। ZFS → FSx for OpenZFS।
EFS - थ्रूपुट मोड चुनें।
परिवर्तनशील कार्यभार, आकार के साथ स्केल करता है → Bursting। अनुमानित उच्च थ्रूपुट → Provisioned। बर्स्ट-संवेदनशील लेकिन इलास्टिक खर्च चाहते हैं → Elastic (नई फाइल सिस्टम के लिए डिफ़ॉल्ट, स्वचालित रूप से स्केल करता है)।
ऑन-प्रेमिसेस फ़ाइल/ब्लॉक/टेप बैकअप जो S3 / Glacier के साथ इंटीग्रेट होता है।
AWS स्टोरेज गेटवे: फ़ाइल गेटवे (NFS/SMB → S3), वॉल्यूम गेटवे (iSCSI → S3 + EBS स्नैपशॉट), टेप गेटवे (VTL → Glacier)।
वैश्विक उपयोगकर्ताओं के साथ स्थिर एसेट्स + API प्रतिक्रियाएँ; ओरिजिन लोड कम करें।
उपयुक्त कैश पॉलिसी के साथ CloudFront। स्टैटिक के लिए लंबी TTLs; कैश-कुंजी में केवल आवश्यक हेडर्स/क्वेरी स्ट्रिंग्स शामिल हैं। उच्च-कार्डिनैलिटी ओरिजिन के लिए ओरिजिन शील्ड का उपयोग करें।
क्यों: कैश हिट रेशियो प्रदर्शन और लागत दोनों को प्रभावित करता है। गलत कैश कुंजी (उदाहरण के लिए सभी हेडर्स शामिल करना) हिट रेट को नष्ट कर देती है।
एज पर रिक्वेस्ट/रिस्पांस में हेरफेर करें।
हल्का, व्यूअर-साइड, सब-ms (हेडर रीराइट, रीडायरेक्ट, A/B) → CloudFront फंक्शंस। भारी, Node.js / Python, लंबा कंप्यूट, नेटवर्क एक्सेस → Lambda@Edge।
ElastiCache Redis बनाम Memcached चुनें।
प्रतिकृति, पर्सिस्टेंस, पब/सब, सॉर्टेड सेट्स, मल्टी-AZ फेलओवर → Redis। मल्टी-थ्रेडेड, सरल की/वैल्यू, केवल हॉरिजॉन्टल शार्डिंग → Memcached।
Redis सेशन स्टोर को AZs में ऑटो-फेलओवर के साथ HA की आवश्यकता है।
मल्टी-AZ + स्वचालित फेलओवर सक्षम के साथ Redis प्रतिकृति समूह के लिए ElastiCache। एक AZ में प्राइमरी, अन्य में रेप्लिका।
DynamoDB रीड विलंबता माइक्रोसेकंड से; ऐप में बदलाव किए बिना कैश करें।
DynamoDB एक्सेलेरेटर (DAX)। इन-VPC प्रबंधित कैश; वही DynamoDB SDK; पारदर्शी रीड-थ्रू।
क्यों: ElastiCache को ऐप-स्तर के कैश लॉजिक की आवश्यकता होती है। DAX DynamoDB के लिए ड्रॉप-इन है।
एक कैश रणनीति चुनें।
लेज़ी लोडिंग (कैश मिस → फेच + पॉप्युलेट): सरल, केवल वही कैश करता है जो अनुरोध किया गया है। राइट-थ्रू (अपडेट पर कैश + DB में लिखें): कैश हमेशा ताज़ा रहता है, लेकिन अतिरिक्त राइट्स। TTL: किसी भी पैटर्न पर बाउंडेड स्टेलनेस।
एक कंप्यूट प्लेटफ़ॉर्म चुनें।
15 मिनट से कम इवेंट-चालित, उप-सेकंड स्केल, कोई इंफ्रा नहीं → Lambda। लंबे समय तक चलने वाले कंटेनर, कोई नोड प्रबंधन नहीं → Fargate। कस्टम कर्नेल, GPU, स्थायी स्थिति, सबसे सस्ता स्थायी → EC2।
Lambda Java कोल्ड-स्टार्ट p99 विलंबता को प्रभावित कर रहा है।
Lambda SnapStart (Java, Python, .NET)। इनिशियलाइज़्ड रनटाइम का स्नैपशॉट इनवोक पर पुनर्स्थापित किया गया; कोल्ड स्टार्ट 10 गुना तक तेज़।
अनुमानित बर्स्ट लोड; कोल्ड स्टार्ट अस्वीकार्य।
प्रोविजन्ड कंकुरेन्सी। किसी भी थ्रूपुट पर इनवोक करने के लिए तैयार प्री-वार्म वातावरण। अनुसूचित स्केल-अप के लिए एप्लीकेशन ऑटो स्केलिंग के साथ संयोजन करें।
क्यों: ऑन-डिमांड से अधिक लागत आती है लेकिन कोल्ड स्टार्ट को समाप्त करता है। स्थिर ट्रैफ़िक के लिए आवश्यक नहीं है जहां प्रोविजन्ड-कंकुरेन्सी का उपयोग स्वाभाविक रूप से उच्च रहता है।
API गेटवे प्रकार चुनें।
पूर्ण सुविधा सेट (अनुरोध सत्यापन, परिवर्तन, API कुंजियाँ, उपयोग योजनाएँ) → REST API। कम लागत, कम विलंबता, JWT/OIDC मूल, सरल → HTTP API। वास्तविक समय द्विदिश → WebSocket API।
मोबाइल/वेब ऐप को DynamoDB / Lambda द्वारा समर्थित वास्तविक समय सब्सक्रिप्शन के साथ GraphQL की आवश्यकता है।
AWS AppSync। प्रबंधित GraphQL, WebSocket सब्सक्रिप्शन, Cognito / IAM / Lambda ऑथराइजर के माध्यम से ठीक-दानेदार प्रमाणीकरण।
Kinesis Data Streams बनाम Firehose बनाम Managed Service for Apache Flink बनाम MSK चुनें।
कस्टम उपभोक्ता, एमएस विलंबता, रीप्ले, मल्टी-उपभोक्ता फैन-आउट → डेटा स्ट्रीम्स। बस S3/Redshift/OpenSearch को बफरिंग के साथ डिलीवर करें → Firehose। स्ट्रीम प्रोसेसिंग (विंडो, जॉइन) → Apache Flink के लिए प्रबंधित सेवा। Kafka-संगत → MSK।
Athena क्वेरीज़ टेराबाइट्स को स्कैन करती हैं; लागत / समय अत्यधिक।
क्वेरी प्रेडिकेट (तिथि, रीजन) द्वारा डेटा को पार्टिशन करें। Parquet/ORC कॉलमर प्रारूप में परिवर्तित करें। कैटलॉग राउंड-ट्रिप से बचने के लिए पार्टिशन प्रोजेक्शन का उपयोग करें।
क्यों: Athena प्रति-TB स्कैन के लिए शुल्क लेता है। कॉलमर + पार्टिशनिंग अक्सर लागत को 10-100 गुना कम कर देता है।
बिना लोड किए S3 में Redshift से डेटा क्वेरी करें।
Redshift स्पेक्ट्रम। Glue डेटा कैटलॉग पर बाहरी स्कीमा; स्पेक्ट्रम नोड्स S3 को स्कैन करते हैं और परिणामों को क्लस्टर में वापस स्ट्रीम करते हैं।
DynamoDB क्षमता मोड चुनें।
अप्रत्याशित / स्पाइकी / नए वर्कलोड → ऑन-डिमांड। स्थिर, अनुमानित, गर्म - और लागत-संवेदनशील → ऑटो-स्केलिंग के साथ प्रोविजन्ड। मोड को 24 घंटे में अधिकतम एक बार स्विच करें।
पार्टिशन कुंजी न होने वाले एट्रिब्यूट द्वारा DynamoDB को क्वेरी करें।
विभिन्न पार्टिशन कुंजी पर क्वेरीज़ के लिए ग्लोबल सेकेंडरी इंडेक्स (GSI)। समान पार्टिशन कुंजी पर वैकल्पिक सॉर्ट कुंजी के लिए लोकल सेकेंडरी इंडेक्स (LSI) (LSI को टेबल-बनाने के समय बनाया जाना चाहिए)।
DynamoDB सेशन टेबल अनबाउंडेड बढ़ती है; सेशन 24 घंटे के बाद समाप्त होते हैं।
न्यूमेरिक इपोक एट्रिब्यूट पर DynamoDB TTL। DynamoDB समाप्त हो चुके आइटम्स को एसिंक्रोनस रूप से हटा देता है, कोई राइट क्षमता शुल्क नहीं लिया जाता।
HPC वर्कलोड को सबसे कम संभव इंटर-नोड विलंबता की आवश्यकता है।
क्लस्टर प्लेसमेंट समूह: एक ही AZ में एक ही भौतिक रैक पर इंस्टेंस। 10 Gbps एकल-प्रवाह तक।
क्यों: स्प्रेड प्लेसमेंट → अधिकतम अलगाव (HA); पार्टिशन → बड़े-डेटा (Hadoop, Cassandra); क्लस्टर → सबसे सख्त विलंबता।
एक स्थिर 24x7 फ़्लीट के लिए EC2 खरीद विकल्प चुनें।
कंप्यूट सेविंग्स प्लान (1 वर्ष या 3 वर्ष) - सूची मूल्य से 66% छूट, इंस्टेंस फैमिली, आकार, OS, टैनेंसी, रीजन में लचीला। RIs केवल तभी जब आपको क्षमता आरक्षण की आवश्यकता हो।
क्यों: अधिकांश लागत-केवल उपयोग के मामलों के लिए सेविंग्स प्लान RIs पर हावी होते हैं (अधिक लचीले, समान छूट)।
कंप्यूट सेविंग्स प्लान बनाम EC2 इंस्टेंस सेविंग्स प्लान बनाम SageMaker सेविंग्स प्लान चुनें।
कंप्यूट SP: अधिकतम लचीलापन (EC2, Fargate, Lambda को कवर करता है) - सबसे अच्छा डिफ़ॉल्ट। EC2 इंस्टेंस SP: फैमिली-लॉक्ड, गहरी छूट। SageMaker SP: केवल SageMaker।
सहिष्णु कार्यभार पर लागत बचत के लिए स्पॉट का उपयोग करें।
क्षमता-अनुकूलित आवंटन रणनीति + कई इंस्टेंस प्रकारों के साथ ASG मिक्सड-इंस्टांसेस पॉलिसी के माध्यम से स्पॉट। इंस्टेंस मेटाडेटा के माध्यम से 2-मिनट की रुकावट सूचना को संभालें।
क्यों: क्षमता-अनुकूलित पूल चुनता है जिनकी पुनर्प्राप्ति की संभावना सबसे कम होती है। कई प्रकार पूल जोखिम को विविधीकृत करते हैं।
माइग्रेशन के बाद अप्रयुक्त आरक्षित इंस्टेंस हैं।
आरक्षित इंस्टेंस मार्केटप्लेस (केवल स्टैंडर्ड RIs) पर बेचें। या कनवर्टिबल RIs के माध्यम से एक अलग फैमिली में कनवर्ट करें।
क्यों: कनवर्टिबल RIs स्वैप करने के अधिकार के लिए थोड़ी कम छूट का व्यापार करते हैं।
आर्किटेक्चर को फिर से लिखे बिना कंप्यूट लागत में कटौती करें।
Graviton (ARM64) इंस्टेंस में माइग्रेट करें। कई वर्कलोड के लिए ~20% सस्ता, ~40% बेहतर मूल्य-प्रदर्शन। मल्टी-आर्क कंटेनर इमेज या रीकंपाइल्ड बाइनरीज़ की आवश्यकता है।
Lambda फंक्शंस जहां रनटाइम ARM का समर्थन करता है।
आर्किटेक्चर को `arm64` (Graviton) पर सेट करें। x86 से प्रति एमएस 20% सस्ता, अक्सर तेज़। आर्क-संगत देशी डिप्स की आवश्यकता है।
Lambda लागत बहुत अधिक; रनटाइम CPU-बाउंड।
मेमोरी बढ़ाएँ (जो CPU और नेटवर्क को आनुपातिक रूप से स्केल करता है)। स्वीट स्पॉट खोजने के लिए Lambda पावर ट्यूनिंग (स्टेप फंक्शंस टूल) का उपयोग करें - अक्सर अधिक मेमोरी तेज़ और सस्ती होती है।
लॉग्स और पुराने ऑब्जेक्ट S3 स्टैंडर्ड में जमा होते हैं।
S3 लाइफ़साइकिल नियम: 30 दिन बाद IA में, 90 दिन बाद Glacier Flexible में, 180 दिन बाद Glacier Deep Archive में ट्रांज़िशन करें, रिटेंशन के बाद समाप्त करें। अज्ञात पैटर्न के लिए Intelligent-Tiering के साथ संयोजन करें।
अकाउंट्स में S3 खर्च की कल्पना करें; ऑप्टिमाइज़ेशन उम्मीदवारों को खोजें।
S3 स्टोरेज लेंस। उपयोग, गतिविधि, लागत-बचत सिफारिशों के साथ संगठन-व्यापी डैशबोर्ड। प्रीफिक्स-स्तर के ब्रेकडाउन के लिए एडवांस्ड मेट्रिक्स टियर।
NAT गेटवे डेटा-प्रोसेसिंग शुल्क बिल पर हावी हैं।
AWS-सेवा ट्रैफ़िक को VPC एंडपॉइंट्स से बदलें (S3/DynamoDB के लिए गेटवे; बाकी सब के लिए इंटरफ़ेस)। इंटरनेट निकास की आवश्यकता वाले वर्कलोड को केवल आवश्यक होने पर पब्लिक सबनेट में ले जाएँ।
क्यों: NAT गेटवे AWS-सेवा ट्रैफ़िक के लिए भी प्रति GB संसाधित शुल्क लेता है। एंडपॉइंट उस पाथ को समाप्त करते हैं।
डेटा ट्रांसफर लागत में कटौती करें।
समान-AZ, समान-VPC = मुफ्त। क्रॉस-AZ = $0.01/GB प्रत्येक दिशा। क्रॉस-रीजन = महंगा। इंटरनेट पर निकास = सबसे महंगा लेकिन कैश योग्य सामग्री के लिए CloudFront के माध्यम से मुफ्त। जब भी संभव हो CloudFront के माध्यम से हमेशा निकास करें।
CloudWatch लॉग्स की लागत बढ़ रही है।
स्पष्ट रिटेंशन सेट करें (डिफ़ॉल्ट "कभी समाप्त न करें" है)। पुराने लॉग्स को S3 + Glacier में एक्सपोर्ट करें। केवल गर्म डेटा पर लॉग्स इनसाइट्स का उपयोग करें। एजेंट पर फ़िल्टर करें (उत्पादन में डीबग लॉग न भेजें)।
EC2, ऑटो स्केलिंग ग्रुप्स, EBS, Lambda में सही-साइज़िंग उम्मीदवार खोजें।
AWS कंप्यूट ऑप्टिमाइज़र। CloudWatch मेट्रिक्स + ML पढ़ता है, डाउनसाइज़िंग या फ़ैमिली स्विचिंग की सिफारिश करता है। संगठन-व्यापी ऑप्ट-इन के लिए मुफ्त।
अप्रत्याशित खर्च स्पाइक्स का सक्रिय रूप से पता लगाएं।
AWS कॉस्ट एनोमली डिटेक्शन (कॉस्ट एक्सप्लोरर के भीतर)। प्रति सेवा / लिंक्ड अकाउंट / लागत श्रेणी के लिए ML-आधारित मॉनिटर। SNS / ईमेल के माध्यम से अलर्ट।
एक सैंडबॉक्स अकाउंट में अनियंत्रित खर्च रोकें।
कार्रवाई के साथ AWS बजेट: 80% थ्रेशोल्ड पर, एक SNS नोटिफिकेशन चलाएं; 100% पर, बजेट एक्शन के माध्यम से एक अस्वीकार SCP / IAM पॉलिसी संलग्न करें।
अलग-अलग अकाउंट्स के बिना टीम या उत्पाद द्वारा चार्जबैक।
कॉस्ट आवंटन टैग। बिलिंग कंसोल में उपयोगकर्ता-परिभाषित टैग सक्रिय करें; कॉस्ट एक्सप्लोरर + CUR में प्रदर्शित करें। पहचान विशेषता के लिए `aws:CreatedBy` के साथ संयोजन करें।
देव/टेस्ट EC2 इंस्टेंस 24x7 चलते हैं - केवल 9-से-5 बजे तक उपयोग किए जाते हैं।
AWS इंस्टेंस शेड्यूलर (CloudFormation-डिप्लॉयड Lambda)। इंस्टेंस को शेड्यूल नामों के साथ टैग करें; क्रॉन-जैसा स्टार्ट/स्टॉप चलाता है। या बस देव ASGs पर `aws:autoscaling:scheduledActions`।
क्यों: ऑफ-आवर्स स्टॉप के साथ देव कंप्यूट खर्च पर ~70% की कमी।
देव RDS इंस्टेंस रात/सप्ताहांत में निष्क्रिय।
RDS इंस्टेंस को रोकें (सिंगल-AZ; 7 दिन तक, फिर स्वतः-शुरू होता है)। या न्यूनतम ACU = 0.5 के साथ Aurora Serverless v2 (कोई पूर्ण रोक नहीं, लेकिन निष्क्रिय होने पर न्यूनतम लागत)।
कंटेनर फ़्लीट लागत अनुकूलन।
स्थिर, उच्च उपयोग → EC2 पर ECS (स्पॉट/सेविंग्स प्लान के साथ) - सबसे सस्ता। स्पाइकी / कम समय तक चलने वाला / कोई नोड प्रबंधन नहीं → Fargate। सहिष्णु वर्कलोड के लिए Fargate स्पॉट Fargate से 70% सस्ता है।
S3 / EC2 से इंटरनेट पर निकास कम करें।
CloudFront के साथ सामने लाएं। ओरिजिन → एज ट्रांसफर मुफ्त है; एज → उपयोगकर्ता सीधे EC2/S3 निकास से बड़े पैमाने पर सस्ता है। कम्प्रेशन + उपयुक्त TTLs सक्षम करें।
ऑन-प्रेमिसेस NFS से S3 में 100 TB माइग्रेट करें।
ऑन-प्रेमिसेस पर AWS DataSync एजेंट; S3 में अनुसूचित स्थानांतरण। एन्क्रिप्टेड, अखंडता-जांच, दर-सीमित। 100 TB+ या कम बैंडविड्थ के लिए Snowball Edge।
ऑन-प्रेमिसेस से AWS में > 1 PB ले जाएँ; ऑनलाइन ट्रांसफर के लिए बैंडविड्थ बहुत धीमी है।
AWS स्नो फैमिली। सामान्य के लिए Snowball Edge स्टोरेज ऑप्टिमाइज़्ड (80 TB); 100s TB के लिए समानांतर में कई डिवाइस। स्नोमोबिल सेवानिवृत्त है - पेटाबाइट स्केल के लिए मल्टी-स्नोबॉल का उपयोग करें।
उत्पादन RDS / ElastiCache / OpenSearch / Redshift 24x7 चल रहा है।
प्रबंधित डेटाबेस के लिए आरक्षित इंस्टेंस (इन सेवाओं के लिए कोई सेविंग्स प्लान समकक्ष नहीं)। 1 वर्ष या 3 वर्ष; आंशिक-अग्रिम आमतौर पर सबसे अच्छा NPV होता है।
अकाउंट में त्वरित कम-प्रयास लागत जीत।
AWS विश्वसनीय सलाहकार लागत जांच: निष्क्रिय लोड बैलेंसर, कम उपयोग वाले EC2, अनअटैचड EBS, कम उपयोग वाले RDS, निष्क्रिय Redshift। मुफ्त टियर सीमित; बिजनेस / एंटरप्राइज सपोर्ट के साथ पूर्ण सेट।