उच्च-प्रदर्शन और लागत-अनुकूलित परिदृश्य
कैशिंग रणनीतियों, डेटा लेक क्वेरी अनुकूलन, Reserved और Spot के बीच समझौतों तथा रीड रेप्लिका आर्किटेक्चर पर परिदृश्य प्रश्नों के उत्तर दीजिए।
उच्च-प्रदर्शन और लागत-अनुकूलित परिदृश्य, CoddyKit पर AWS Solutions Architect का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह AWS Solutions Architect सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। AWS Solutions Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
परिदृश्य 1: डेटाबेस लोड घटाने के लिए कैशिंग
परिदृश्य: एक समाचार वेबसाइट का RDS MySQL डेटाबेस ऐसे article content के लिए 90% रीड ट्रैफ़िक संभालता है, जो अधिकतम प्रति घंटे एक बार बदलता है। डेटाबेस CPU का औसत उपयोग 80% है, लागत बढ़ रही है और प्रत्येक क्वेरी में 200ms लगते हैं। समाधान: ElastiCache Redis cluster को RDS के सामने lazy loading (cache-aside) पैटर्न के साथ जोड़ें। एप्लिकेशन पहले cache जाँचता है—cache hit होने पर cached article को <1ms में लौटाएँ। cache miss होने पर RDS से क्वेरी करें, परिणाम लौटाएँ और उसे 1 घंटे के TTL के साथ cache में लिखें। अपेक्षित परिणाम: 90% cache hit rate, RDS CPU घटकर 20% से कम और cached responses की देरी घटकर 5ms से कम हो जाएगी।
import boto3, json
elasticache = boto3.client('elasticache')
redis_client = None # assume redis-py client connected to ElastiCache endpoint
def get_article(article_id):
cache_key = 'article:' + str(article_id)
# Check cache first
cached = redis_client.get(cache_key)
if cached:
return json.loads(cached) # cache hit: <1ms
# Cache miss: query RDS
article = rds_query('SELECT * FROM articles WHERE id = %s', article_id)
# Write to cache with 1-hour TTL
redis_client.setex(cache_key, 3600, json.dumps(article))
return articleपरिदृश्य 2: स्थिर asset वितरण के लिए CloudFront
परिदृश्य: Asia Pacific के उपयोगकर्ताओं को us-east-1 में EC2 पर होस्ट किए गए वेब एप्लिकेशन को लोड करने में 2–4 सेकंड लगते हैं। एप्लिकेशन बड़े स्थिर assets (images, JS, CSS) प्रदान करता है। समाधान: ALB के सामने एक CloudFront distribution रखें। /static/* path के लिए लंबे TTL (जैसे, 1 सप्ताह) वाला cache behaviour कॉन्फ़िगर करें, ताकि स्थिर files Asia के उपयोगकर्ताओं के पास स्थित CloudFront edge locations पर cache हो जाएँ। Dynamic API requests caching को TTL=0 के साथ bypass करें। एशियाई उपयोगकर्ता us-east-1 तक round trip की प्रतीक्षा करने के बजाय Singapore या Tokyo edge location से स्थिर assets को 100ms से कम समय में लोड कर पाएँगे।
# CloudFront origin for ALB + separate behaviour for static assets
aws cloudfront create-distribution --distribution-config '{
'Origins': {
'Quantity': 1,
'Items': [{
'Id': 'alb-origin',
'DomainName': 'my-alb.us-east-1.elb.amazonaws.com',
'CustomOriginConfig': {"HTTPSPort": 443, "OriginProtocolPolicy": "https-only"}
}]
},
'CacheBehaviors': {
'Quantity': 1,
'Items': [{
'PathPattern': '/static/*',
'DefaultTTL': 604800,
'MaxTTL': 604800
}]
},
'DefaultCacheBehavior': {"DefaultTTL": 0}
}'परिदृश्य 3: Compute Optimizer के साथ सही आकार निर्धारण
परिदृश्य: एक कंपनी के पास 500 EC2 इंस्टेंस हैं, जिनमें से कई 3 वर्ष पहले बड़े instance types के साथ बनाए गए थे। उनका AWS बिल अधिक है, लेकिन उन्हें पता नहीं है कि कौन-से इंस्टेंस आवश्यकता से अधिक बड़े हैं। समाधान: AWS Compute Optimizer सक्षम करें (यह निःशुल्क है और CloudWatch metrics के 14 दिनों के डेटा का उपयोग करता है)। Compute Optimizer प्रत्येक इंस्टेंस के वास्तविक CPU, memory, network और disk उपयोग का विश्लेषण करके सही आकार निर्धारण की recommendations देता है। 8% औसत CPU पर चल रहे t3.xlarge को घटाकर t3.small करने की recommendation दी जाएगी। 500 इंस्टेंस पर recommendations लागू करने से सामान्यतः EC2 लागत 20–40% कम हो जाती है।
# Enable Compute Optimizer at account level
aws compute-optimizer update-enrollment-status \
--status Active
# Get EC2 instance recommendations
aws compute-optimizer get-ec2-instance-recommendations \
--filters Name=Finding,Values=OVER_PROVISIONED \
--query 'instanceRecommendations[*].{Instance: instanceArn, Current: currentInstanceType, Recommended: recommendationOptions[0].instanceType}' \
--output tableपरिदृश्य 4: Batch प्रोसेसिंग के लिए Spot Instances
परिदृश्य: एक genomics कंपनी हर रात ऐसे batch jobs चलाती है, जिनमें 8 घंटे लगते हैं और बाधित होने पर जिन्हें फिर से चलाया जा सकता है। इन jobs के लिए EC2 On-Demand की लागत प्रति माह $10,000 है। समाधान: batch processing fleet के लिए EC2 Spot Instances का उपयोग करें। Spot Instances अप्रयुक्त EC2 क्षमता हैं, जो 90% तक की छूट पर उपलब्ध होती हैं। रुकावट-सहिष्णु batch jobs के लिए AWS Batch का उपयोग करें, जो विफल Spot jobs को स्वचालित रूप से queue में फिर डालता है और मिश्रित fleet (Spot + न्यूनतम On-Demand fallback) का उपयोग करता है। अपेक्षित बचत: compute लागत में 70–90% की कमी—$10,000 से घटकर $1,000–3,000 प्रति माह।
# AWS Batch compute environment with Spot instances
aws batch create-compute-environment \
--compute-environment-name spot-genomics \
--type MANAGED \
--state ENABLED \
--compute-resources '{
"type": "SPOT",
"bidPercentage": 60,
"minvCpus": 0,
"maxvCpus": 256,
"instanceTypes": ["optimal"],
"subnets": ["subnet-1a", "subnet-1b"],
"securityGroupIds": ["sg-batch"],
"instanceRole": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
"spotIamFleetRole": "arn:aws:iam::123456789012:role/AmazonEC2SpotFleetRole"
}' \
--service-role arn:aws:iam::123456789012:role/AWSBatchServiceRoleपरिदृश्य 5: परिवर्तनीय ट्रैफ़िक के लिए DynamoDB On-Demand
परिदृश्य: एक gaming leaderboard, provisioned throughput के साथ DynamoDB का उपयोग करता है। गेम लॉन्च के दौरान ट्रैफ़िक 50 गुना बढ़ जाता है और table requests को throttle करती है। लॉन्च के बीच ट्रैफ़िक लगभग शून्य रहता है—provisioned capacity व्यर्थ जाती है। समाधान: DynamoDB को On-Demand capacity mode पर बदलें। On-Demand बिना मैन्युअल capacity planning के किसी भी throughput तक तुरंत स्केल होता है और provisioned unit के बजाय प्रत्येक request के लिए शुल्क लेता है। आप केवल अपने द्वारा की गई requests के लिए भुगतान करते हैं—लॉन्च के बीच निष्क्रिय capacity की कोई लागत नहीं होती। On-Demand, प्रति-request थोड़ी अधिक लागत के बदले निश्चित रूप से no-throttle और शून्य capacity management प्रदान करता है।
# Switch existing DynamoDB table to On-Demand mode
aws dynamodb update-table \
--table-name Leaderboard \
--billing-mode PAY_PER_REQUEST
# Verify the change
aws dynamodb describe-table \
--table-name Leaderboard \
--query 'Table.BillingModeSummary.BillingMode'परिदृश्य 6: S3 Intelligent-Tiering द्वारा अनिश्चित पहुँच
परिदृश्य: एक कंपनी S3 Standard में उपयोगकर्ताओं द्वारा बनाई गई लाखों छवियाँ संग्रहीत करती है। पहुँच के पैटर्न का पूर्वानुमान नहीं लगाया जा सकता — कुछ छवियों को प्रतिदिन देखा जाता है, जबकि कुछ को महीनों तक नहीं देखा जाता। कंपनी जीवनचक्र नीतियों को मैन्युअल रूप से प्रबंधित किए बिना भंडारण लागत कम करना चाहती है। समाधान: S3 Intelligent-Tiering का उपयोग करें। यह पहुँच के पैटर्न के आधार पर वस्तुओं को अलग-अलग स्तरों के बीच स्वचालित रूप से स्थानांतरित करता है: Frequent Access (Standard), Infrequent Access (30+ दिनों से एक्सेस नहीं किया गया), Archive Instant Access (90+ दिन), और Archive Access (90+ दिन, opt-in)। Intelligent-Tiering के भीतर पुनर्प्राप्ति शुल्क नहीं लगता। निगरानी शुल्क प्रति माह प्रति 1,000 वस्तुओं पर $0.0025 है — बड़े डेटासेट के लिए यह नगण्य है।
# Move objects to Intelligent-Tiering via lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
--bucket user-images-bucket \
--lifecycle-configuration '{
"Rules": [{
"ID": "AutoTier",
"Status": "Enabled",
"Filter": {},
"Transitions": [{
"Days": 0,
"StorageClass": "INTELLIGENT_TIERING"
}]
}]
}'परिदृश्य 7: Athena बनाम Redshift का समझौता
परिदृश्य: एक startup S3 data lake तालिकाओं पर क्वेरी चलाना चाहता है। वह प्रति सप्ताह लगभग 10 ad hoc क्वेरी चलाता है। एक विक्रेता dc2.large क्लस्टर वाला Amazon Redshift प्रस्तावित करता है। startup के लिए समाधान: Amazon Athena से शुरुआत करें — बुनियादी ढाँचे की लागत शून्य है और केवल स्कैन किए गए डेटा के लिए भुगतान करना होता है (~$5/TB)। अच्छी तरह विभाजित Parquet डेटा पर प्रति सप्ताह 10 क्वेरी की लागत $5/माह से कम हो सकती है। Redshift dc2.large की लगातार लागत लगभग $180/माह है। Redshift तभी किफायती बनता है जब क्वेरी समवर्तीता अधिक हो (50+ क्वेरी/दिन) या एक सेकंड से कम प्रतिक्रिया आवश्यक हो। कीवर्ड 'ad hoc, infrequent' स्पष्ट रूप से Athena की ओर संकेत करता है।
# Athena cost estimate for 10 queries/week:
# Assume each query scans 5 GB of Parquet data
# 10 queries x 5 GB = 50 GB / week = 200 GB / month
# Athena cost: 200 GB x $0.005/GB = $1.00 / month
#
# Redshift dc2.large cost: $0.25/hr x 24hr x 30days = $180/month
#
# For 10 queries/week -> Athena saves $179/month
# Breakeven: when queries scan >36 TB/month or concurrency >50/day -> use Redshiftपरिदृश्य 8: EBS वॉल्यूम प्रकार का चयन
परिदृश्य: एक रिलेशनल डेटाबेस सर्वर को लगातार कम विलंबता के साथ 64,000 IOPS की आवश्यकता है। वर्तमान gp3 EBS वॉल्यूम अपनी IOPS सीमा तक पहुँच रहा है। समाधान: io2 Block Express में अपग्रेड करें (यह I/O-गहन डेटाबेस के लिए बनाया गया EBS वॉल्यूम प्रकार है)। io2 Block Express प्रति वॉल्यूम 256,000 IOPS तक और एक मिलीसेकंड से कम विलंबता का समर्थन करता है। यह gp3 से महँगा है ($0.125/GB + $0.065/provisioned IOPS/माह), लेकिन 64,000+ IOPS की आवश्यकता पूरी करने वाला एकमात्र EBS विकल्प है। ऐसे डेटाबेस वर्कलोड के लिए जहाँ विलंबता अत्यंत महत्वपूर्ण है और gp3 की 16,000 IOPS सीमा अपर्याप्त है, io2 ही एकमात्र व्यावहारिक EBS विकल्प है।
# Create io2 Block Express volume with 64,000 IOPS
aws ec2 create-volume \
--volume-type io2 \
--size 500 \
--iops 64000 \
--availability-zone us-east-1a \
--encrypted
# EBS volume type IOPS limits summary:
# gp3: up to 16,000 IOPS (default 3,000, configurable)
# io1: up to 64,000 IOPS (on Nitro instances)
# io2 Block Express: up to 256,000 IOPS
# st1 (throughput HDD): no IOPS focus, max 500 MB/s throughput
# sc1 (cold HDD): lowest cost, 250 MB/s max, rarely accessed dataपरिदृश्य 9: स्थिर वर्कलोड के लिए Reserved Instances
परिदृश्य: एक कंपनी उत्पादन एप्लिकेशन के लिए 20 r6i.4xlarge EC2 Instance लगातार चलाती है और उसे उम्मीद है कि 3 वर्षों तक आवश्यकताओं में कोई बदलाव नहीं होगा। इन Instance के लिए उसका वर्तमान On-Demand खर्च $80,000/वर्ष है। समाधान: अधिकतम छूट के लिए 3-year Standard Reserved Instances (या Compute Savings Plans) खरीदें और All Upfront भुगतान करें। Standard Reserved Instances, On-Demand की तुलना में 72% तक की छूट देते हैं। Instance 24/7 चलते हैं और वर्कलोड पूर्वानुमानित है — यह Reserved Instances के लिए आदर्श प्रोफ़ाइल है। अपेक्षित लागत में कमी: $80,000 × 0.72 = $22,400/वर्ष, जबकि On-Demand पर $80,000/वर्ष — यानी $57,600/वर्ष की बचत।
# Reserved Instance purchase decision matrix:
# On-Demand: No commitment, highest price, any workload
# 1-yr RI (All Up): 40% discount, 1-yr commitment, specific instance type
# 3-yr RI (All Up): 60-72% discount, 3-yr commitment, best for stable workloads
# Compute Savings Plan: 66% max discount, flexible instance family/size/Region
# EC2 Spot: 90% discount, interruptible, batch/stateless only
#
# Rule: if usage > 70% of the time for >1 year -> buy RI or Savings Plan
# Rule: if usage < 50% -> stick with On-Demand
# Rule: if usage pattern is steady 3yr -> 3yr RI All Upfront maximises savingsपरिदृश्य 10: परिवर्तनीय ट्रैफ़िक के लिए Lambda बनाम EC2 लागत
परिदृश्य: एक कंपनी $8/माह की लागत वाले t3.micro EC2 Instance पर REST API चलाती है। API को प्रति माह 1 मिलियन अनुरोध मिलते हैं और प्रत्येक अनुरोध को संसाधित होने में 100ms लगते हैं। टीम पूछती है कि क्या Lambda अधिक सस्ता होगा। विश्लेषण: Lambda का मूल्य निर्धारण: 1,000,000 अनुरोध × $0.0000002 = $0.20 (अनुरोध लागत) + 1,000,000 × 0.1s × 128MB मेमोरी × दर = ~$1.67 (Compute लागत) = ~$1.87/माह। इस कम-ट्रैफ़िक API के लिए Lambda, EC2 से सस्ता है। जब ट्रैफ़िक लगभग 40 मिलियन अनुरोध/माह से अधिक हो जाता है, तब EC2 सस्ता हो जाता है। प्रत्येक वर्कलोड के लिए ब्रेक-ईवन पता करने हेतु Lambda Cost Calculator का उपयोग करें।
# Lambda vs EC2 cost rough break-even calculation:
# Lambda costs: $0.20 per 1M requests + $0.0000166667 per GB-second
# At 128 MB memory, 100ms duration:
# GB-seconds per request = 0.128 GB x 0.1s = 0.0128 GB-s
# Cost per request = $0.0000166667 x 0.0128 = $0.000000213 compute
# + $0.0000002 request fee = $0.000000413 total per request
#
# EC2 t3.micro: $0.0104/hr x 720 hrs = $7.49/month
# Break-even: $7.49 / $0.000000413 = ~18 million requests/month
# Below 18M requests/month -> Lambda cheaper
# Above 18M requests/month -> EC2 cheaper (if utilisation is high)परिदृश्य 11: डायनेमिक API के लिए Global Accelerator
परिदृश्य: यूरोप, US और एशिया के उपयोगकर्ताओं को सेवा देने वाली एक वैश्विक API में असंगत विलंबता होती है, क्योंकि ट्रैफ़िक का मार्ग अनिश्चित इंटरनेट पथों से होकर गुजरता है। CloudFront पर विचार किया गया, लेकिन API प्रतिक्रियाएँ डायनेमिक हैं (कैश नहीं की जा सकतीं)। समाधान: AWS Global Accelerator का उपयोग करें। यह वैश्विक स्तर पर दो स्थिर anycast IP addresses उपलब्ध कराता है। उपयोगकर्ता का ट्रैफ़िक निकटतम AWS edge location पर AWS के वैश्विक backbone में प्रवेश करता है और AWS के निजी नेटवर्क से होकर लक्ष्य Region में origin तक पहुँचता है — इस तरह सार्वजनिक इंटरनेट के भीड़भाड़ वाले middle-mile से बचा जाता है। Global Accelerator डायनेमिक API की प्रतिक्रिया का समय 20-60% तक बेहतर करता है और किसी Region Endpoint के अस्वस्थ होने पर तुरंत failover उपलब्ध कराता है।
# Create a Global Accelerator for an ALB
aws globalaccelerator create-accelerator \
--name my-api-accelerator \
--ip-address-type IPV4 \
--enabled
# Add a listener and endpoint group pointing to ALB
aws globalaccelerator create-listener \
--accelerator-arn arn:aws:globalaccelerator::123:accelerator/abc \
--protocol TCP \
--port-ranges '[{"FromPort": 443, "ToPort": 443}]'
# Endpoint group in us-east-1 with ALB
aws globalaccelerator create-endpoint-group \
--listener-arn arn:aws:globalaccelerator::123:listener/xyz \
--endpoint-group-region us-east-1 \
--endpoint-configurations '[{"EndpointId": "arn:aws:elasticloadbalancing:...", "Weight": 100}]'त्वरित जाँच
इस lesson में पढ़ी गई AWS Solutions Architect (SAA-C03) अवधारणाओं की अपनी समझ जाँचें।
lesson का पुनरावलोकन
इस lesson में आपने इन परिदृश्यों का अभ्यास किया: RDS CPU को 80% से 20% तक कम करने के लिए ElastiCache lazy loading, batch job की लागत में 70-90% बचत के लिए Spot Instances और AWS Batch, कम बार होने वाली ad hoc क्वेरी के लिए Athena बनाम उच्च-समवर्ती analytics के लिए Redshift, और पुनर्प्राप्ति शुल्क के बिना अनिश्चित पहुँच पैटर्न के लिए S3 Intelligent-Tiering। इसके बाद अंतिम capstone है: आपकी तैयारी मापने के लिए समय-सीमित mixed-domain mini exam।
एआई शिक्षक के साथ AWS Solutions Architect सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 30
- पाठ
- 120
अक्सर पूछे जाने वाले प्रश्न
क्या “उच्च-प्रदर्शन और लागत-अनुकूलित परिदृश्य” पाठ निःशुल्क है?
हाँ — AWS Solutions Architect अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “उच्च-प्रदर्शन और लागत-अनुकूलित परिदृश्य” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। AWS Solutions Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“उच्च-प्रदर्शन और लागत-अनुकूलित परिदृश्य” में मैं क्या सीखूँगा?
कैशिंग रणनीतियों, डेटा लेक क्वेरी अनुकूलन, Reserved और Spot के बीच समझौतों तथा रीड रेप्लिका आर्किटेक्चर पर परिदृश्य प्रश्नों के उत्तर दीजिए। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ AWS Solutions Architect का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या AWS Solutions Architect शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर AWS Solutions Architect शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।
“उच्च-प्रदर्शन और लागत-अनुकूलित परिदृश्य” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस AWS Solutions Architect पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर AWS Solutions Architect पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- सुरक्षित आर्किटेक्चर परिदृश्य
- लचीले और उच्च-उपलब्धता वाले आर्किटेक्चर परिदृश्य
- उच्च-प्रदर्शन और लागत-अनुकूलित परिदृश्य
- मिश्रित डोमेन की पूर्ण-लंबाई लघु परीक्षा