AWS global infrastructure: Regions, Availability Zones, Local Zones, Wavelength Zones, edge locations आणि Outposts

By Ravindra Bagale, trainer · LinkedIn · Last updated: 8 October 2026

1. AWS global infrastructure: सहा भाग

का. तुमची website users च्या जवळ पाहिजे, एखाद्या building मध्ये problem आला तरी चालू राहिली पाहिजे, आणि कधी कधी एकाच देशात किंवा एखाद्या company च्या building मध्येच राहिली पाहिजे. एकच मोठं data center हे सगळं करू शकत नाही. म्हणून AWS वेगवेगळ्या प्रकारच्या जागा बनवतं, प्रत्येक एका कामासाठी.

काय. Board वर आपण सहा भाग लिहिले:

1. Regions: मोठे भाग (उदा. Mumbai), जिथे AWS ची मुख्य data centers असतात.
2. Availability Zones (AZs): एका Region मधले data centers चे वेगवेगळे गट.
3. Local Zones: मोठ्या शहरांच्या आत, users च्या जवळ छोट्या AWS sites.
4. Wavelength Zones: telecom company च्या network मध्ये ठेवलेले AWS servers, mobile users च्या जवळ.
5. Edge locations: खूप शहरांमधल्या छोट्या AWS sites, ज्या तुमच्या files च्या copies ठेवतात (हेच CDN, Amazon CloudFront).
6. Outposts: तुमच्याच company च्या building मध्ये बसवलेलं AWS चं hardware.

आज हे किती मोठं आहे? हे AWS ने स्वतः publish केलेले numbers आहेत. दर वर्षी वाढतात, म्हणून नेहमी AWS चं live Global Infrastructure page बघा:

2. Region, Availability Zone आणि data center

का. Server launch करण्याआधी AWS तुम्हाला दोन प्रश्न विचारतं: कोणता Region, आणि कोणता AZ. म्हणून प्रत्येक शब्दाचा नक्की अर्थ माहीत पाहिजे.

काय. मोठ्याकडून छोट्याकडे, तीन levels:

1. Data center म्हणजे servers ने भरलेली एक building, स्वतःची power, cooling आणि network असलेली.
2. Availability Zone (AZ) म्हणजे एक किंवा जास्त data centers, redundant power, networking आणि connectivity सकट.
3. Region म्हणजे अनेक AZs असलेला एक geographic भाग. AWS प्रत्येक Region कमीत कमी तीन AZs ने design करतं.

एका Region चे AZs कुठे असतात?

1. एका Region चे सगळे AZs एकाच metro area मध्ये असतात.
2. ते एकमेकांपासून बरेच km लांब असतात, म्हणजे एखादा local problem सगळ्यांना एकदम लागत नाही.
3. पण सगळे एकमेकांपासून साधारण 100 km (60 miles) च्या आत असतात, म्हणून खूप fast बोलू शकतात.
4. ते AWS च्या स्वतःच्या redundant, high-bandwidth, low-latency fibre ने जोडलेले असतात, satellite किंवा mobile towers ने नाही. AZs मधलं traffic encrypted असतं.

India चं उदाहरण (आकडेमोड).

1. Mumbai Region: 3 AZs, आणि प्रत्येक AZ मध्ये कमीत कमी 1 data center, म्हणजे कमीत कमी 3 data centers.
2. Hyderabad Region: 3 AZs, म्हणजे कमीत कमी 3 data centers.
3. India मध्ये एकूण: 3 + 3 = 6 AZs, 2 Regions मध्ये.
4. Mumbai चे तिन्ही AZs Mumbai area मध्येच आहेत. Hyderabad चे तिन्ही AZs Hyderabad area मध्येच आहेत.
5. AWS नक्की पत्ता किंवा buildings चा नक्की आकडा publish करत नाही. हे security साठी.

3. एक AZ म्हणजे एकापेक्षा जास्त data centers का: जमिनीची गोष्ट

का. Students विचारतात: AZ म्हणजे "एक data center" असेल, तर AWS "एक किंवा जास्त data centers" असं का म्हणतं? उत्तर आहे जमीन.

काय. Board वरची गोष्ट (समजा numbers):

1. समजा एका मोठ्या data center ला 50 एकर जमीन लागते.
2. Metro च्या एका भागात AWS ला 50 एकरचा एक plot मिळतो. तिथे ते एक data center बांधतं. तो AZ = 1 data center.
3. Metro च्या गर्दीच्या भागात 50 एकरचा एकही plot मोकळा नाही. AWS ला एकमेकांच्या जवळ 25 एकरचे दोन plots मिळतात.
4. ते दोन छोटी data centers बांधतं, आणि दोन्ही एकाच AZ च्या नावाखाली ठेवतं.
5. एकूण जमीन तेवढीच: 25 + 25 = 50 एकर. Capacity साधारण तेवढीच. फक्त buildings ची संख्या बदलली.
6. तुमच्यासाठी काहीच बदलत नाही. तुम्ही AZ निवडता, उदा. ap-south-1b. त्या AZ मधल्या कोणत्या building मध्ये तुमचा server चालेल, ते AWS ठरवतं.

उदाहरण. समजा Mumbai Region असा दिसतो:

तिन्ही AZs, आणि चारही buildings, Mumbai metro area च्या आतच आहेत. हे एकरचे आकडे फक्त शिकण्यासाठी आहेत; AWS ते publish करत नाही.

4. Disasters, आणि servers कमीत कमी दोन AZs मध्ये का

का. Data center म्हणजे शेवटी एक building. आग, पूर, भूकंप किंवा मोठा power failure झाला तर एक building बंद पडू शकते. तुमचा एकुलता एक server त्याच building मध्ये असेल, तर तुमची website बंद.

काय. AZs वेगळे असल्यामुळे, एका AZ मधल्या disaster चा बाकीच्यांना साधारण धक्का लागत नाही. म्हणून servers कमीत कमी दोन AZs मध्ये पसरवायचे, आणि पुढे एक load balancer ठेवायचा जो त्यांची health check करतो.

Failover कसं होतं (board वरचे arrows):

1. Users requests load balancer कडे पाठवतात.
2. Load balancer काही requests AZ a मधल्या servers कडे आणि काही AZ b मधल्या servers कडे पाठवतो.
3. समजा AZ a मध्ये आग लागली. तिथले servers उत्तर देणं बंद करतात.
4. त्या servers चे load balancer चे health checks fail होतात.
5. काही checks fail झाले की (किती वेळाने check करायचं ते तुम्ही ठरवता, उदा. दर 10 किंवा 30 seconds), तो AZ a कडे requests पाठवणं बंद करतो आणि सगळं AZ b कडे पाठवतो.
6. Users website वापरत राहतात. एखादी request slow होईल किंवा retry लागेल, पण site चालू राहते.

उदाहरणं: किती capacity उरते?

AWS काय promise करतं (EC2 SLA). EC2 चं AWS चं service level agreement हीच idea आकड्यांत दाखवतं:

1. एक single EC2 instance: 99.5% monthly uptime commitment.
2. एका Region मध्ये दोन किंवा जास्त AZs मध्ये चालणारं EC2: 99.99% monthly uptime commitment.
3. 30 दिवसांच्या महिन्यात 30 × 24 × 60 = 43,200 minutes असतात.
4. 99.5% म्हणजे महिन्यात 43,200 × 0.005 = 216 minutes (3 तास 36 minutes) downtime चालतो.
5. 99.99% म्हणजे महिन्यात 43,200 × 0.0001 = 4.32 minutes.
6. Servers तेच, फक्त AZs मध्ये पसरवले, आणि promise 50 पट मजबूत.

5. Regions एकमेकांपासून वेगळे का

का. एका Region मध्ये काही बिघडलं, तर ते पूर्ण जगभर पसरायला नको, जसा आजार एकाच भागात थांबवतात तसं.

काय.

1. प्रत्येक Region physically वेगळा आणि बाकीच्या Regions पासून independent असतो.
2. Mumbai Region मधला problem Mumbai Region मध्येच राहतो. Singapore, Tokyo आणि बाकी चालूच राहतात.
3. तुमचा data तुम्ही निवडलेल्या Region मध्येच राहतो. AWS स्वतःहून तो दुसऱ्या Region मध्ये copy करत नाही.
4. तरी Regions AWS global network ने जोडलेले असतात, म्हणून तुम्ही ठरवलं तर त्यांच्यात data copy करू शकता (उदा. database किंवा S3 bucket replicate करणं).

उदाहरण.

1. Website A फक्त Mumbai मध्ये चालते. पूर्ण Mumbai Region ला मोठा problem आला, तर website A बंद.
2. Website B Mumbai मध्ये चालते, आणि Singapore (ap-southeast-1) मध्ये एक copy तयार ठेवते.
3. Mumbai ला problem आला, तर website B आपले users Singapore कडे वळवते.
4. Website B चा खर्च जास्त (दोन copies), पण पूर्ण Region चा problem आला तरी ती वाचते. तुमच्या business ला हे लागतं का, ते तुम्ही ठरवायचं.

6. Restricted Regions: China आणि AWS GovCloud (US)

का. काही Regions normal AWS account मधून वापरता येत नाहीत. ते कायदे आणि compliance च्या नियमांसाठी आहेत.

काय. दोन गट:

China Regions.

1. हे Chinese कायद्यानुसार वेगळे चालवले जातात.
2. Beijing Region एक local company, Sinnet, चालवते. Ningxia Region NWCD चालवते.
3. यासाठी AWS (China) account लागतं. तुमच्या normal AWS account ला हे Regions दिसत नाहीत, आणि China account ला normal Regions दिसत नाहीत.

AWS GovCloud (US).

1. दोन isolated US Regions, US soil वर US citizens चालवतात.
2. Root account holder ची US person म्हणून screening होते.
3. हे US government च्या compliance programmes (उदा. FedRAMP High) आणि sensitive, controlled government data साठी आहेत.

Board वरचं drawing: governments ना shared hardware ची काळजी का. AWS मध्ये एक मोठा physical server (host) अनेक virtual servers मध्ये कापला जातो:

1. समजा एका host कडे 1,000 GB storage आणि 500 GB RAM आहे.
2. तुम्ही भाड्याने घेतलेल्या प्रत्येक virtual server ला, समजा, 4 GB RAM आणि 8 GB disk मिळते.
3. RAM नुसार: 500 ÷ 4 = 125 virtual servers. Disk नुसार: 1,000 ÷ 8 = 125 virtual servers.
4. म्हणजे साधारण 125 customers एकच physical machine share करू शकतात (खरा host स्वतःसाठी थोडं ठेवतो).
5. AWS virtual servers एकमेकांपासून strongly isolated ठेवतं. तरी काही governments चे नियम वेगळे Regions, खास staff आणि खास audits मागतात. म्हणून GovCloud आहे.

7. Default Regions आणि opt-in Regions

का. नवीन AWS account उघडलं की काही Regions Region list मध्ये दिसतात आणि काही दिसत नाहीत. Students ना वाटतं ते बिघडलेत किंवा block आहेत. ते फक्त default ने बंद असतात.

काय. नियम (AWS कडून):

1. 20 March 2019 च्या आधी launch झालेले Regions default ने enabled असतात. पहिल्या दिवसापासून वापरता येतात, आणि disable करता येत नाहीत.
2. 20 March 2019 नंतर launch झालेले Regions opt-in Regions आहेत. ते प्रत्येक account साठी default ने disabled असतात.
3. Disabled opt-in Region तुम्ही enable करेपर्यंत console च्या Region list मध्ये दिसत नाही.
4. Enable करणं free आहे. तिथे जे बनवाल त्याचेच पैसे लागतात.

Default ने enabled (17):

Opt-in, default ने disabled (17):

उदाहरण: मोजणी.

1. Normal AWS account ला AWS च्या Regions table मध्ये 17 default + 17 opt-in = 34 Regions दिसतात.
2. Mumbai default Region आहे, म्हणून पहिल्या दिवसापासून तिथे launch करता येतं.
3. Hyderabad opt-in Region आहे, म्हणून आधी enable करावा लागतो.
4. India मधून sign up केलं, तर तुमच्या contact address पासून Hyderabad Mumbai पेक्षा जवळ असेल तर AWS तो जवळचा opt-in Region enable करायला सुचवू शकतं.

Opt-in Region enable कसा करायचा (console):

1. Root user म्हणून, किंवा Regions enable करायची permission असलेल्या IAM user ने sign in करा.
2. वर उजवीकडे तुमच्या account name वर click करा.
3. Account वर click करा. हे Billing and Cost Management मधलं Account page उघडतं.
4. खाली AWS Regions section पर्यंत scroll करा.
5. Region निवडा, उदा. Asia Pacific (Hyderabad), आणि Enable वर click करा.
6. Enable region ने confirm करा.
7. थांबा. साधारण काही minutes लागतात, कधी कधी काही तास, कारण AWS तुमचे IAM users आणि credentials त्या Region मध्ये copy करतं.
8. Status Enabled दिसला की तो Region वर उजवीकडच्या Region list मध्ये दिसायला लागतो.

8. Region codes, आणि शहरांची नावं का नाहीत

का. शहरांची नावं बदलतात. Programs ना बदल आवडत नाही.

काय. समजा AWS ने Region चं नाव "bombay" ठेवलं असतं:

1. हजारो companies Region चं नाव त्यांच्या Python, Java आणि Node.js programs, scripts आणि settings files मध्ये लिहितात.
2. शहराचं नाव Mumbai झालं. AWS ने Region चं नावपण बदललं असतं, तर हे सगळे programs एकाच दिवशी तुटले असते.
3. म्हणून AWS एक fixed code वापरतं जो कधीच बदलत नाही: ap-south-1. Display name "Mumbai" असू शकतं, पण programs code वापरतात.

Region code कसा वाचायचा:

1. Area: ap = Asia Pacific, us = United States, eu = Europe, ca = Canada, sa = South America, af = Africa, me = Middle East, il = Israel, mx = Mexico.
2. त्या area मधली direction (दिशा): south, southeast, northeast, east, west, north, central.
3. Number: त्या दिशेतला पहिला Region 1, दुसरा 2, असं.

उदाहरणं:

Program मध्ये असं दिसतं: region = "ap-south-1". त्याऐवजी शहराचं नाव लिहिलं तर AWS tools ना कळणार नाही.

9. AZ codes, आणि एका Region मध्ये किती AZs

का. Server launch करताना तुम्ही एक subnet निवडता, आणि प्रत्येक subnet नेमका एका AZ मध्ये असतो. म्हणून AZ codes रोज वाचावे लागणार.

काय. AZ code = Region code + एक letter.

1. Mumbai Region ap-south-1 मध्ये 3 AZs आहेत.
2. त्यांचे codes ap-south-1a, ap-south-1b आणि ap-south-1c.
3. N. Virginia us-east-1 मध्ये 6 AZs: us-east-1a ते us-east-1f.

किती AZs? (आजचं AWS चं Regions table)

N. Virginia मध्ये एवढे AZs का?

1. जिथे demand वाढते तिथे AWS Region मध्ये AZs वाढवतं.
2. us-east-1 हा AWS चा सगळ्यात जुना Region आहे, आणि तो वाढत वाढत 6 AZs पर्यंत गेलाय.

उदाहरण: Mumbai मध्ये high-availability website चं planning.

1. Mumbai मध्ये 3 AZs आहेत.
2. High availability साठी कमीत कमी 2 लागतात, म्हणून ap-south-1a आणि ap-south-1b निवडा.
3. प्रत्येक AZ मध्ये एक subnet बनवा.
4. प्रत्येक subnet मध्ये 2 web servers launch करा: एकूण 4 servers.
5. एक AZ fail झाला, तर 4 पैकी 2 servers (50%) site चालू ठेवतात, section 4 सारखं.

10. Region कसा निवडायचा

का. तुमचा server users पासून किती लांब, कोणत्या services मिळणार, data कायद्याने कुठे राहणार, आणि किती पैसे लागणार, हे सगळं Region ठरवतो.

काय. या चार गोष्टी, याच क्रमाने तपासा:

1. Users पासून अंतर. जास्तीत जास्त users च्या जवळचा Region निवडा. India मधले users: Mumbai किंवा Hyderabad. ज्या client चे users US मध्ये आहेत: US Region, उदा. us-east-1.
2. कायदा आणि data चे नियम. काही data एका देशाच्या आतच ठेवावा लागतो. त्या देशातला Region निवडा.
3. Services. नवीन AWS services पहिल्या दिवशी सगळ्या Regions मध्ये येत नाहीत. तुम्हाला लागणारं तुमच्या Region मध्ये आहे का ते बघा.
4. Price. Region नुसार prices बदलतात. AWS pricing page वर compare करा; अंदाज लावू नका.

उदाहरण.

1. Pune च्या एका coaching institute ची website; सगळे students महाराष्ट्रात. Mumbai ap-south-1 निवडा.
2. US मधले customers असलेलं online shop. US Region निवडा, उदा. N. Virginia us-east-1.
3. Customer data India मध्येच ठेवायचा आणि Mumbai पासून लांब दुसरी copy हवी अशी company. Main Region Mumbai, आणि copy साठी Hyderabad ap-south-2 (आधी enable करा).

Console कोणत्या Region मध्ये उघडतो? Console तुमच्या default Region मध्ये (console settings मध्ये set करता येतो) किंवा शेवटी वापरलेल्या Region मध्ये उघडतो. तो तुमच्या GPS वरून Region निवडत नाही.

11. Local Zones

का. Region ची मोठी data centers साधारण शहराच्या मध्यभागापासून बाहेर असतात, जिथे मोठी जमीन मिळते. शहराच्या कडेचे IT parks डोळ्यासमोर आणा, जसे Pune च्या कडेला Hinjewadi किंवा Kharadi. बहुतेक websites साठी हे चालतं. पण काही users ना उत्तर खरंच fast पाहिजे, आणि प्रत्येक km उशीर वाढवतो.

काय. Local Zone म्हणजे मोठ्या शहराच्या आत किंवा जवळ, users च्या जवळ ठेवलेली एक छोटी AWS site.

1. तो एका parent Region चा विस्तार असतो. उदा. Delhi Local Zone Mumbai Region चा आहे.
2. तिथे तुम्ही स्वतःचे servers चालवू शकता: EC2, EBS volumes, VPC subnets, load balancers, आणि आणखी काही services.
3. तो AWS च्या स्वतःच्या high-bandwidth network ने परत parent Region ला जोडलेला असतो, म्हणून तुमचा बाकीचा setup Region मध्येच राहू शकतो.
4. AWS म्हणतं Local Zones अशा applications साठी आहेत ज्यांना users पर्यंत single-digit millisecond latency लागते.
5. Prices प्रत्येक Local Zone नुसार ठरतात. Pricing page बघा; Region एवढेच असतील असं धरू नका.

कोण वापरतं? ज्यांच्यासाठी काही milliseconds महत्त्वाचे: real-time multiplayer games, live media आणि video editing, आणि stock traders.

India मधले Local Zones (आजची AWS ची list):

Local Zone चं नाव कसं वाचायचं: us-west-2-lax-1a = parent Region us-west-2 (Oregon), location lax (Los Angeles), group 1, zone a.

उदाहरण (समजा numbers).

1. Delhi मधला एक trading app user. Mumbai Region मधल्या server कडे प्रत्येक request ला जाऊन-येऊन, समजा, 30 ms लागतात.
2. तीच request Delhi Local Zone मधल्या server कडे, समजा, 3 ms घेते.
3. एक screen एकामागून एक 10 requests करते.
4. Region: 10 × 30 = 300 ms. Local Zone: 10 × 3 = 30 ms.
5. Normal website साठी 300 ms चालतात. Trader साठी, जो fast तो जिंकतो.

12. Wavelength Zones

का. Mobile users ना fast serve करणं सगळ्यात अवघड. तुमच्या phone ची request tower कडे जाते, मग telecom company च्या network मधून, मग internet वर, मग AWS Region पर्यंत. प्रत्येक step उशीर वाढवते. AWS server telecom network च्या आतच बसला तर?

काय. Wavelength Zone म्हणजे telecom company च्या data center मध्ये, त्यांच्या mobile (5G) network च्या edge ला ठेवलेलं AWS compute आणि storage.

1. त्या telecom company च्या network वरचे phones आधी public internet वर न जाता तुमच्या server पर्यंत पोहोचतात.
2. त्यामुळे उशीर अगदी काही milliseconds वर येतो.
3. Local Zone सारखाच, हापण एका parent Region चा विस्तार असतो.
4. तिथे EC2 instances, EBS volumes आणि subnets चालवता येतात.
5. उपयोग: multiplayer games, कमी delay असलेला live video, AR/VR, edge वर video वरचं machine learning, connected cars.

ते कुठे आहेत? आजच्या AWS च्या Wavelength list मध्ये Verizon (USA), KDDI (Japan), Bell (Canada), BT (UK), Orange (Morocco) आणि Sonatel (Senegal) असे partners आहेत. Zone चं नाव असं दिसतं: us-east-1-wl1-nyc-wlz-1 (parent Region us-east-1, New York City). आजच्या AWS च्या list मध्ये India मध्ये एकही Wavelength Zone नाही.

उदाहरण (समजा hops).

1. Wavelength शिवाय: phone → tower → telecom network → internet → AWS Region. समजा 12 network hops.
2. Wavelength सकट: phone → tower → telecom network → Wavelength Zone. समजा 4 hops.
3. Hops कमी म्हणजे वाट कमी. Live game मध्ये समोरच्या player ला तुमची move लवकर दिसते.

Local Zone, Wavelength Zone, edge location: शेजारी शेजारी

13. Latency चा problem: अंतर आणि वाट बघणं

का. Slow apps users सोडून देतात. पहिली screen यायला खूप वेळ लागला, तर ते competitor चं app उघडतात.

काय. Board वरचं उदाहरण. App चा server Mumbai Region मध्ये आहे. एक user app उघडतो आणि 1 MB चा photo load करतो.

आकडेमोड सोपी व्हावी म्हणून board वर आपण एक साधा class चा number वापरला:

1 MB, 100 km प्रवास = 100 ms. (फक्त शिकवण्यासाठीचा number, खालची real-world note बघा.)

उदाहरण 1: Pune मधला user, Mumbai पासून साधारण 150 km.

1. 150 km ÷ 100 km = 1.5.
2. 1.5 × 100 ms = प्रत्येक image ला 150 ms.
3. हे fast आहे. कोणाला जाणवत पण नाही.

उदाहरण 2: Delhi मधला user, Mumbai पासून साधारण 2,000 km.

1. 2,000 km ÷ 100 km = 20.
2. 20 × 100 ms = 2,000 ms = प्रत्येक image ला 2 seconds.
3. Photo app च्या पहिल्या screen वर, समजा, 7 images असतात (stories, profile photo, posts).
4. 7 × 2 s = screen तयार व्हायला 14 seconds.
5. Users ना हे 1 ते 2 seconds मध्ये हवं असतं. 14 seconds पर्यंत ते निघून गेलेले असतात.

14. Edge locations आणि CDN (Amazon CloudFront)

का. प्रत्येक शहरात पूर्ण Region बांधता येत नाही. पण लोकप्रिय files च्या copies खूप शहरांमध्ये ठेवता येतात. यालाच CDN (Content Delivery Network) म्हणतात. AWS चं CDN म्हणजे Amazon CloudFront, आणि ते जिथे copies ठेवतं त्या जागा म्हणजे edge locations.

काय.

1. Edge locations म्हणजे खूप मोठ्या शहरांमधल्या छोट्या AWS sites.
2. त्या AWS चालवतं. Edge location मध्ये तुम्ही स्वतःचा EC2 server launch करू शकत नाही.
3. तुम्ही त्या CloudFront मधून वापरता: तुमचा खरा server (origin) कुठे आहे ते CloudFront ला सांगता, आणि CloudFront प्रत्येक user च्या जवळच्या edge वरून तुमच्या files देतं.
4. AWS 750+ CloudFront Points of Presence publish करतं, 50+ देशांमधल्या 100+ शहरांमध्ये, आणि 15 Regional edge caches.
5. India मध्ये CloudFront Points of Presence ची list Bengaluru, Chennai, Hyderabad, Kolkata, Mumbai, New Delhi आणि Pune अशी आहे.
6. Edge locations AWS Regions ना AWS global network backbone ने जोडलेली असतात: AWS चं स्वतःचं private fibre, public internet नाही.

कसं. Delhi ची गोष्ट, step by step (class चे numbers):

1. Delhi मधला एक user app उघडतो. Image ची request Delhi edge location कडे जाते, Mumbai कडे नाही.
2. Edge आपला cache बघतं. ही image Delhi मध्ये आधी कधी मागितलीच नाही. हा miss आहे.
3. Edge ही image Mumbai मधल्या origin कडून, AWS च्या private backbone वरून आणतं.
4. Edge एक copy ठेवतं (cache करतं) आणि image user ला पाठवतं.
5. या पहिल्या user ला Mumbai पर्यंतच्या प्रवासाची वाट बघावी लागतेच. Board वर आपण त्या पहिल्या image साठी साधारण 700 ms ते 1 s असा अंदाज केला. Private backbone वर public internet पेक्षा कमी hops असतात, म्हणून हे 2 s पेक्षा fast.
6. आता Delhi पासून साधारण 150 km वरचा Agra मधला मित्र तीच post उघडतो. Request Delhi edge कडे जाते.
7. Image आधीच तिथे आहे. हा hit आहे. Mumbai पर्यंत जायचं नाही.
8. Class चं गणित: 150 km → प्रत्येक image ला 150 ms. 7 images × 150 ms = 1,050 ms, म्हणजे साधारण 1.1 seconds, 14 seconds ऐवजी.

Public internet vs AWS backbone. Public internet म्हणजे शहरातली bus: खूप stops (hops), tower to tower. AWS backbone म्हणजे expressway वरची स्वतःची गाडी: stops कमी, रस्ता मोकळा.

उदाहरण 2: origin चं किती काम वाचतं.

1. समजा एक image एका दिवसात Delhi edge वरून 1,000 वेळा मागितली गेली.
2. फक्त पहिली request miss. बाकीच्या 999 hits.
3. Mumbai मधल्या origin ला 1,000 ऐवजी फक्त 1 request serve करावी लागली.
4. Hit ratio = 999 ÷ 1,000 = 99.9%.

15. Edge मधून upload

का. एका student ने विचारलं: download जवळच्या edge वरून येतो, तर upload पण internet पार करून main server कडे जाण्याऐवजी edge मधून जाऊ शकतो का?

काय. हो.

1. तुमचा upload जवळच्या edge location मध्ये शिरतो.
2. तिथून तो public internet ऐवजी AWS backbone वरून origin पर्यंत जातो.
3. CloudFront uploads (HTTP PUT आणि POST) तुमच्या origin पर्यंत पोहोचवू शकतं.
4. S3 साठी S3 Transfer Acceleration लांबच्या bucket मध्ये upload fast करायला CloudFront edge locations वापरतं.

उदाहरण.

1. Pune मधला user N. Virginia (us-east-1) मधल्या bucket मध्ये 100 MB चा video upload करतो.
2. Edge शिवाय: upload पूर्ण public internet पार करतो. खूप stops असलेल्या public bus सारखं.
3. Edge सकट: upload जवळच्या Indian edge location मध्ये (Pune किंवा Mumbai) शिरतो, मग AWS backbone वरून N. Virginia ला जातो. Expressway पकडल्यासारखं.

16. Edge काय ठेवतं, आणि काय delete करतं

का. Edge location छोटं असतं. प्रत्येक website ची प्रत्येक file कायम ठेवू शकत नाही. म्हणून काय ठेवायचं ते त्याला ठरवावं लागतं.

काय. नियम 1: आधी मागणी, मग साठा (pull, push नाही). Edge ला प्रत्येक file आधीच मिळत नाही. Users मागेपर्यंत ते थांबतं.

नियम 2: जागा कमी, म्हणून सगळ्यात आधी least recently used जातं (LRU).

1. समजा एका edge मध्ये फक्त 4 videos ची जागा आहे (खरी edges खूप मोठी असतात; हे शिकण्यासाठी).
2. Users या क्रमाने मागतात: A, B, C, D. चारही misses. आता edge मध्ये A, B, C, D आहेत.
3. कोणीतरी परत A मागतो. Hit. आता A हा most recently used.
4. कोणीतरी E मागतो. Miss. Edge भरलंय, म्हणून ते least recently used video delete करतं. तो म्हणजे B.
5. आता edge मध्ये A, C, D, E आहेत.
6. नंतर कोणी B मागितला, तर तो परत miss, आणि edge B परत origin वरून आणतं.

नियम 3: प्रत्येक copy ला expiry time असतो. Website चा मालक copy किती वेळ परत वापरता येईल ते ठरवतो, उदा. reel साठी "समजा 14 दिवस". त्यानंतर edge परत origin कडे विचारतं.

CDN domain. मोठी apps images आणि videos अनेकदा वेगळ्या CDN domain वरून देतात.

1. Main domain (समजा example.com) ची request origin servers कडे जाते.
2. CDN domain (समजा mycdn.net, किंवा d111111abcdef8.cloudfront.net सारखा CloudFront domain) ची request जवळच्या edge location कडे जाते.

17. Browser DevTools मध्ये CDN स्वतः बघा

का. माझ्यावर विश्वास ठेवायची गरज नाही. कोणतीही मोठी website उघडा, तिचं CDN तुम्हाला स्वतःच्या डोळ्यांनी दिसेल.

कसं (laptop वर Firefox किंवा Chrome):

1. एखादी मोठी website उघडा. Class मध्ये आपण उदाहरण म्हणून instagram.com चं login page बघितलं.
2. DevTools उघडायला F12 दाबा.
3. Network tab वर click करा, मग Images filter.
4. Page reload करा.
5. Domain column बघा. Class मध्ये images static.cdninstagram.com वरून येत होत्या, म्हणजे main domain नाही, वेगळा CDN domain.
6. एका image च्या row वर click करा, मग Headers → Response headers बघा.
7. cache-control शोधा. Class मध्ये तो असा होता: public, max-age=31536000, immutable.

उदाहरण: max-age चे दिवस करा.

1. max-age seconds मध्ये असतो.
2. एक दिवस = 60 × 60 × 24 = 86,400 seconds.
3. 31,536,000 ÷ 86,400 = 365 दिवस.
4. म्हणजे browser ही image पूर्ण एक वर्ष परत न विचारता वापरू शकतो. immutable म्हणजे या address वरची file कधीच बदलत नाही; नवीन version ला नवीन address मिळतो.

max-age चा अर्थ काय, आणि काय नाही.

1. Copy किती वेळ परत वापरायची ते तो browsers आणि caches ना सांगतो.
2. CDN चं edge file किती वेळ ठेवतं याचा तो पुरावा नाही. जागा लागली तर edge ती LRU ने आधीच delete करू शकतं.

ही website फक्त तुमच्या browser मध्ये काय दिसतं याचं उदाहरण आहे; ती company तिचे servers कसे चालवते याबद्दलचं हे विधान नाही.

18. AWS Outposts

का. काही companies ना AWS services (EC2, RDS, S3) हव्या असतात, पण काही data किंवा systems स्वतःच्याच building मध्ये ठेवाव्या लागतात. कारणं: data-residency किंवा compliance चे नियम, site वरच्या machines पर्यंत अगदी कमी latency, किंवा local data processing. समजा उदाहरण: एक bank जिला काही sensitive data स्वतःच्या data center मध्येच ठेवावा लागतो.

काय. AWS Outposts AWS चं स्वतःचं hardware तुमच्या building मध्ये आणतं.

1. AWS तुमच्या data center मध्ये AWS च्या मालकीचे racks किंवा servers आणून बसवतं. (Racks standard 42U racks असतात; Outposts servers 1U किंवा 2U.)
2. Hardware AWS चालवतं, monitor करतं आणि सांभाळतं.
3. तुम्ही तेच AWS console, APIs आणि tools वापरता: EC2 instances, EBS volumes, आणि racks वर S3, RDS आणि आणखी.
4. Outpost वर ठेवलेला data तुमच्या building मध्येच राहतो.
5. Outpost हा एका AZ आणि त्याच्या parent Region चा विस्तार असतो. त्याला त्या Region पर्यंत network connection लागतं, त्याला service link म्हणतात.

Board वरचे numbers: durability आणि availability. Board वर आपण "11 nines" लिहिलं. ते नेमकं काय आहे:

1. Amazon S3 (S3 Standard) objects च्या वर्षभरातल्या 99.999999999% (11 nines) durability साठी design केलेलं आहे. Durability = तुमची file हरवत नाही.
2. S3 Standard 99.99% availability साठी design केलेलं आहे. Availability = file आत्ता लगेच मिळू शकते.
3. हे S3 चे design numbers आहेत, प्रत्येक AWS service चं promise नाही. बाकीच्या services चे आपापले numbers असतात.

उदाहरण: 11 nines म्हणजे काय.

1. 10,000,000 objects (1 कोटी) ठेवा. वर्षाला अपेक्षित loss = 10,000,000 × 0.00000000001 = 0.0001 objects.
2. म्हणजे सरासरी 10,000 वर्षांत एक object हरवतो.
3. 1,000,000,000 objects (100 कोटी) ठेवा. अपेक्षित loss = वर्षाला 0.01 objects, म्हणजे सरासरी 100 वर्षांत एक object.

उदाहरण: 99.99% availability म्हणजे काय.

1. एक वर्ष = 365 × 24 × 60 = 525,600 minutes.
2. त्याचे 0.01% = 525,600 × 0.0001 = वर्षाला 52.56 minutes, जेव्हा ते मिळू शकणार नाही.
3. तुमच्या स्वतःच्या website चा uptime मात्र तुमच्या design वर ठरतो: एका AZ मधला एक server अनेक AZs मधल्या servers पेक्षा खूप कमकुवत (section 4).

19. सहाही एकत्र

20. Homework: घरी करून बघा

Recap

समजलं का? आज रात्री DevTools test करून बघा. उद्या laptop घेऊन या, practical सुरू करू. हळूहळू कळेल.

Ravindra Bagale, trainer: linkedin.com/in/ravindra-bagale. एकरचे आकडे, hops, "समजा" म्हटलेले latency numbers आणि "100 km ला 100 ms" हा नियम शिकण्यासाठीचे class numbers आहेत. AWS चे आकडे AWS च्याच pages वरून घेतले आहेत आणि ते वारंवार बदलतात, म्हणून live AWS pages बघा. Instagram फक्त तुमच्या browser मध्ये काय दिसतं याचं उदाहरण म्हणून आलं आहे.