भाग 1: campus (teal, 1–6) · भाग 2: campuses जोडणे (blue, 7–12). प्रत्येक आकृती खऱ्या lab मधून काढली आहे — vpc/demo.py जे पत्ते, routes आणि packet walks छापतो ते — आणि प्रत्येकीखाली एक lab आहे जिथे तुम्ही स्वतः plan करता, route करता आणि packets चालवून पाहता. वर्तुळातील क्रमांकांचे अनुसरण करा 1 → 2 → 3.
1 🏫 VPC का
AWS शहरातला शाळेचा स्वतःचा कुंपण घातलेला campus — तुमचे पत्ते, तुमच्या wings, तुमची दारे; तुम्ही मार्ग बांधल्याशिवाय आत काहीही येत नाही.
🧒 सोप्या शब्दांत
एका मोठ्या शहरात अनेक शाळा असतात. आपली शाळा स्वतःच्या campus भोवती कुंपण घालते आणि प्रत्येक खोलीला स्वतःचा नंबर देते. शाळेने दरवाजा बांधल्याशिवाय रस्त्यावरून कोणीही आत येत नाही. AWS मध्ये त्या कुंपण घातलेल्या campus ला VPC म्हणतात.
📖 नवे शब्दVPC — AWS मधील तुमचे स्वतःचे खाजगी network, शाळेच्या कुंपण घातलेल्या campus सारखेregion — AWS चे एक शहर, जसे Mumbai मधील ap-south-1; VPC एका region मध्ये असतोdefault VPC — आधीच बनवलेला campus जिथे प्रत्येक wing public असतो; प्रयोगासाठी ठीक, खऱ्या कामासाठी नाहीIP address — network वरील एका desk चा नंबर, जसे 10.20.0.10
⏪ आधी
सर्व servers एकाच सामायिक सपाट network वर, किंवा प्रत्येक subnet public असलेला default VPC: स्वतःचे कुंपण नव्हतेच.
💡 काय
VPC म्हणजे AWS शहरातील शाळेचा स्वतःचा कुंपण घातलेला campus: तुमचे पत्ते, तुमच्या wings, आणि तुम्ही बांधलेले दरवाजेच.
⚙️ कसे
Campus आहे एका region मधील 10.20.0.0/16: 65,536 पत्ते, तर default VPC 172.31.0.0/16 फक्त प्रयोग करून पाहण्यासाठी.
🎯 का
तुम्ही मार्ग बांधल्याशिवाय काहीही आत येत नाही की बाहेर जात नाही, म्हणून प्रत्येक उघडा मार्ग हा तुमचा जाणूनबुजून घेतलेला निर्णय असतो.
🚀 पुढे
पुढचा धडा campus ला घरांचे नंबर देतो: /16, /20 आणि /24 चा अर्थ काय, आणि ranges कधीच overlap का होऊ नयेत.
🧪 इथे करून पाहा — campus साठी range निवडा, मग अनोळखी व्यक्तीला desk पर्यंत पोहोचायला काय लागते ते पाहा
campus साठी घरांचे क्रमांक — /16, /20 आणि /24 चा अर्थ, private ranges, आणि range कधीच overlap का होऊ नये.
🧒 सोप्या शब्दांत
रस्त्यावरील प्रत्येक घराला नंबर लागतो, आणि campus ला नंबरांची पूर्ण range लागते. शेवटचा /16 सांगतो की नंबरचा किती भाग ठरलेला आहे; बाकी खोल्यांसाठी मोकळा. Slash नंतरचा आकडा लहान तर खोल्या जास्त. दोन campuses नी तेच नंबर निवडले, तर ते जोडल्यावर पत्रे हरवतात.
📖 नवे शब्दCIDR — पत्त्यांची range लिहिण्याची पद्धत, जसे 10.20.0.0/16/16 — पहिले 16 bits ठरलेले, म्हणून 65,536 पत्त्यांना जागा उरतेprivate range — फक्त आतल्या networks साठी राखलेले नंबर, जसे 10.x.x.xoverlap — दोन ranges मध्ये काही नंबर सारखे, म्हणून त्या नीट जोडता येत नाहीत
⏪ आधी
अंदाजाने पत्ते निवडणे तोपर्यंतच चालले, जोपर्यंत दोन networks जोडले गेले नाहीत आणि दोघांनी वेगळ्या खोल्यांसाठी 10.0.0.0/16 वापरलेले निघाले.
💡 काय
CIDR म्हणजे घरांच्या नंबरांची योजना: /number सांगतो की सुरुवातीचे किती bits ठरलेले आहेत; कमी bits ठरलेले, तर जास्त पत्ते.
⚙️ कसे
10.20.0.0/16 मध्ये 65,536, /20 मध्ये 4,096, /24 मध्ये 256 आणि /28 मध्ये 16; 10.0.0.0/16 office शी overlap होतो, 10.20.0.0/16 होत नाही.
🎯 का
Office, इतर VPCs किंवा partners शी कधीच न भिडणारी range नंतर जोडता येते, आणि ती नंतर बदलणे अवघड असते.
🚀 पुढे
पुढचा धडा campus चे wings मध्ये भाग करतो: प्रत्येक Availability Zone साठी subnets, आणि प्रत्येकात AWS ठेवून घेतो ते 5 पत्ते.
🧪 इथे करून पाहा — /prefix सरकवा — fixed bits, आकार आणि 5 राखीव पत्ते पाहा; मग overlap तपासा
campus च्या wings, प्रत्येक एका इमारतीत — प्रत्येक AZ साठी range कापा; AWS प्रत्येक subnet मधले 5 पत्ते स्वतःकडे ठेवते.
🧒 सोप्या शब्दांत
Campus चे wings मध्ये भाग केले जातात: दरवाजाजवळचा public wing, app wing आणि data wing. प्रत्येक wing एकाच इमारतीत असतो, आणि एका इमारतीची वीज गेली तर म्हणून आपण wings तीन इमारतींमध्ये बनवतो. प्रत्येक wing मधील पाच खोली-नंबर कार्यालय स्वतःसाठी ठेवते, म्हणून 256 खोल्यांच्या wing मध्ये विद्यार्थ्यांसाठी 251 उरतात.
📖 नवे शब्दsubnet — campus चा एक wing, 10.20.48.0/20 सारखी छोटी rangeAvailability Zone — region मधील स्वतःची वीज आणि cooling असलेली एक वेगळी इमारतreserved addresses — AWS प्रत्येक subnet मध्ये ठेवतो ते 5 नंबर: .0, .1, .2, .3 आणि शेवटचाtier — स्वतःचा wing असलेला app चा एक थर: public, app किंवा data
⏪ आधी
एकाच मोठ्या सपाट network मध्ये web, app आणि database एकाच इमारतीत शेजारी होते, म्हणून एक बिघाड किंवा चूक सगळ्यांना लागत असे.
💡 काय
Subnet म्हणजे campus चा एक wing, जो नेमक्या एका AZ मध्ये असतो; प्रत्येक subnet मधील 5 पत्ते AWS स्वतःसाठी ठेवतो.
⚙️ कसे
public-a म्हणजे 10.20.0.0/20, app-a 10.20.48.0/20, data-a 10.20.96.0/20; /24 मधून .0 .1 .2 .3 .255 जातात, 251 उरतात.
🎯 का
तीन AZs मध्ये तीन tiers म्हणजे एक इमारत अंधारात गेली तरी उरलेल्या दोन सेवा देत राहतात, आणि प्रत्येक tier वेगळा राहतो.
🚀 पुढे
पुढचा धडा corridor च्या पाट्या लावतो: route tables, जिथे सर्वात नेमका route जिंकतो आणि local नेहमी असतो.
🧪 इथे करून पाहा — plan_subnets() प्रमाणे VPC कोरा: प्रत्येक (tier, AZ) साठी एक block, क्रमाने
corridor च्या पाट्या — सर्वात नेमका (most specific) route जिंकतो, 'local' नेहमी असतो, प्रत्येक wing साठी एक table.
🧒 सोप्या शब्दांत
प्रत्येक corridor च्या कोपऱ्यावर एक पाटी असते. '10.20 ने सुरू होणाऱ्या खोल्या: आतच राहा.' 'ग्रंथालयाची पुस्तके: बोगद्याने जा.' 'बाकी सगळे: दरवाजाकडे जा.' दोन पाट्या जुळल्या तर सर्वात नेमकी पाटी पाळायची. प्रत्येक wing ची स्वतःची पाट्यांची जोडी असते.
📖 नवे शब्दroute table — wing साठी पाट्यांची यादी: कोणती पत्ता-range कोणत्या पुढच्या थांब्याकडे जातेlocal route — campus च्या स्वतःच्या range चे traffic आतच ठेवणारी पाटी; ती नेहमी असतेlongest prefix match — अनेक पाट्या जुळल्या तर सर्वात नेमकी पाटी जिंकते0.0.0.0/0 — कोणताही पत्ता जुळणारी 'बाकी सगळे' पाटी
⏪ आधी
Corridors मध्ये पाट्या नसत्या तर wing मधून निघालेल्या packet ला कळले नसते की पत्ता शेजारी आहे, partner कडे आहे की बाहेर.
💡 काय
Route table म्हणजे wing साठी corridor ची पाटी: जुळणाऱ्यांपैकी सर्वात नेमका route जिंकतो, आणि 'local' नेहमी असतो.
मुख्य दरवाजा — subnet public असतो तो फक्त त्याचा route 0.0.0.0/0 → igw सांगतो म्हणून, आणि desk कडे public IP असतो म्हणून.
🧒 सोप्या शब्दांत
Campus ला रस्त्याकडे एकच मुख्य दरवाजा असतो. ज्या wing च्या पाटीवर 'बाकी सगळे मुख्य दरवाजाकडे' लिहिले असेल, तोच wing public म्हणवतो. Web desk कडे ती पाटी आणि स्वतःचा रस्त्यावरचा पत्ता आहे, म्हणून तो जगाशी बोलू शकतो. Data wing कडे अशी पाटी नाही, म्हणून त्याची रस्त्याकडची पत्रे सरळ टाकून दिली जातात.
📖 नवे शब्दinternet gateway — internet कडे जाणारा campus चा मुख्य दरवाजा, जसे igw-schoolpublic subnet — ज्याचा route table 0.0.0.0/0 internet gateway कडे पाठवतो असा wingprivate subnet — internet gateway कडे route नसलेला wingElastic IP — तुम्ही स्वतःकडे ठेवून desk ला जोडता असा कायमचा public पत्ता
⏪ आधी
लोक नावावरून subnet ला public म्हणत, आणि मग तिथला server internet पर्यंत का पोहोचत नाही याचे आश्चर्य करत.
💡 काय
Internet gateway म्हणजे मुख्य दरवाजा; subnet public असतो तो फक्त त्याचा route 0.0.0.0/0 त्याच्याकडे पाठवतो म्हणून.
⚙️ कसे
web → internet :443 हे rt-public च्या 0.0.0.0/0 → igw-school ने बाहेर जाते; db → internet :443 ला route च नाही, म्हणून drop.
🎯 का
Public म्हणजे route आणि public IP किंवा Elastic IP, म्हणून databases ना तो route कधीच न दिल्याने ते आपोआप पोहोचण्याबाहेर राहतात.
🚀 पुढे
पुढचा धडा रक्षक आणतो: प्रत्येक desk वरची security group ची पाहुण्यांची यादी आणि प्रत्येक wing च्या दारावरचा क्रमांकित NACL.
🧪 इथे करून पाहा — desk ला internet वर पाठवा (93.184.216.34 :443) — route, मुख्य दरवाजा किंवा public IP काढून टाका
desk ची पाहुण्यांची यादी (stateful) आणि wing चे दार (stateless, क्रमांक असलेले) — एक packet दोन्हींमधून चालवून पाहा.
🧒 सोप्या शब्दांत
प्रत्येक wing च्या दारावर क्रमांकित नियमांचा कागद घेतलेला रक्षक असतो; तो आत येणाऱ्या आणि बाहेर जाणाऱ्या सगळ्यांना तपासतो आणि कोणालाच लक्षात ठेवत नाही. प्रत्येक desk ची स्वतःची पाहुण्यांची यादी असते: पाहुण्याला आत घेतले की त्याचे उत्तर आपोआप बाहेर जाऊ दिले जाते. Web desk database कडे गेला, wing चे दार पार केले, पण database desk च्या यादीत नव्हता.
📖 नवे शब्दsecurity group — desk ची पाहुण्यांची यादी: फक्त allow नियम, आणि उत्तरे आपोआप परत जाऊ दिली जातातNACL — wing च्या दाराचा क्रमांकित नियमांचा कागद, सर्वात लहान नंबर आधी, allow किंवा denystateful — संवाद लक्षात ठेवतो, म्हणून उत्तरासाठी वेगळा नियम लागत नाहीstateless — काहीच लक्षात ठेवत नाही, म्हणून उत्तरांसाठी स्वतःचा नियम लागतोephemeral ports — ज्यांवरून उत्तरे परत येतात ते ports 1024-65535
⏪ आधी
फक्त routes असताना कोणताही desk कोणत्याही port वर कोणत्याही desk पर्यंत पोहोचू शकत असे, म्हणून बिघडलेला web server database शी बोलू शकत असे.
💡 काय
Security group म्हणजे desk ची stateful, फक्त allow असलेली पाहुण्यांची यादी; NACL म्हणजे wing चे दार: stateless, क्रमांकित नियम.
⚙️ कसे
app → db:5432 पुढे जाते; web → db:5432 acl-data rule 110 पार करते पण sg-db वर थांबते, जिथे फक्त 10.20.48.0/20 आहे.
🎯 का
SG उत्तरे आपोआप लक्षात ठेवतो; NACL ठेवत नाही, म्हणून परतीच्या traffic साठी त्याला ports 1024-65535 उघडे लागतात.
🚀 पुढे
पुढचा धडा AWS services पर्यंत खाजगी बोगदा खणतो: VPC endpoints, म्हणजे private wings internet शिवाय S3 पर्यंत पोहोचतात.
🧪 इथे करून पाहा — एक packet दोन्ही पहारेकऱ्यांतून चालवा — rules चालू-बंद करा आणि अडथळा ओळखा
AWS services कडे जाणारा खाजगी बोगदा — S3/DynamoDB साठी gateway endpoints (मोफत), बाकीच्यांसाठी interface endpoints (PrivateLink).
🧒 सोप्या शब्दांत
Data wing ला शहराच्या ग्रंथालयातून, म्हणजे S3 मधून, पुस्तके हवी आहेत. मुख्य दरवाजा आणि रस्त्याने गेले तर प्रत्येक पिशवीला पैसे लागतात आणि अनोळखी लोक भेटतात. म्हणून शाळा थेट ग्रंथालयापर्यंत खाजगी बोगदा खणते. S3 आणि DynamoDB चा बोगदा मोफत; इतर services चे बोगदे प्रति तास आणि प्रति पिशवी थोडे पैसे घेतात.
📖 नवे शब्दVPC endpoint — internet शिवाय VPC मधून AWS service पर्यंतचा खाजगी बोगदाgateway endpoint — S3 किंवा DynamoDB साठी मोफत route-table entry, जसे pl-s3 → vpce-s3interface endpoint — तुमच्या subnet मध्ये private IP असलेले network card, प्रति तास आणि प्रति GB बिलprefix list — पत्ता-ranges ची नाव असलेली यादी, जसे S3 चे सगळे पत्ते
⏪ आधी
Private wing S3 पर्यंत फक्त NAT आणि internet मार्गे पोहोचत असे, आणि AWS बाहेर जाण्याची गरजच नसलेल्या data साठी प्रति GB पैसे भरत असे.
💡 काय
Endpoint म्हणजे AWS service पर्यंतचा खाजगी बोगदा: S3 आणि DynamoDB साठी gateway endpoints, बाकीच्यांसाठी interface endpoints.
⚙️ कसे
rt-private-a आणि rt-data दोन्ही S3 52.219.40.10 ला pl-s3 → vpce-s3 मार्गे पाठवतात, म्हणून data-a internet route शिवाय S3 गाठतो.
🎯 का
Gateway endpoints मोफत असतात आणि AWS बाहेर जात नाहीत; interface endpoints ना प्रति तास आणि प्रति GB खर्च, पण ते SQS, ECR वगैरे गाठतात.
🚀 पुढे
पुढचा धडा campus ची phone book उघडतो: 10.20.0.2 वरचा VPC resolver आणि फक्त आतच चालणारी नावे.
🧪 इथे करून पाहा — private wing मधून S3 traffic पाठवा — बोगद्यातून किंवा NAT मधून
campus चे फोनबुक — base+2 वरचा resolver, private hosted zones, आणि फक्त आतच चालणारी नावे.
🧒 सोप्या शब्दांत
Database desk चा नंबर 10.20.96.15 आहे हे कोणाच्याच लक्षात राहत नाही. Campus ची phone book त्याला db.school.internal म्हणून ओळखते. Phone book 10.20.0.2 या खोलीत असते, आणि ती फक्त आपल्या campus मधूनच आलेल्या calls ना उत्तर देते. Partner शाळेने तेच नाव विचारले तर उत्तर मिळत नाही.
📖 नवे शब्दDNS — नावाचे IP address मध्ये रूपांतर करणारी phone bookRoute 53 Resolver — base + 2 वरची VPC ची अंगभूत phone book, इथे 10.20.0.2private hosted zone — school.internal सारख्या नावांची phone book, जी फक्त जोडलेल्या VPCs मध्येच उत्तर देतेenableDnsHostnames — desks ना DNS नावे देणारे VPC चे switch
⏪ आधी
Apps च्या config मध्ये 10.20.96.15 सारखे थेट IPs असत, म्हणून database हलवला की प्रत्येक app बदलून पुन्हा deploy करावे लागे.
💡 काय
DNS म्हणजे campus ची phone book: resolver base + 2 वर असतो, आणि private hosted zone फक्त त्याच्याशी जोडलेल्या VPCs मध्येच उत्तर देते.
⚙️ कसे
Resolver आहे 10.20.0.2: db.school.internal → 10.20.96.15, पण partner VPC मधून त्याच नावाला उत्तरच मिळत नाही.
🎯 का
Apps पत्ते नाही तर नावे वापरतात, म्हणून desk हलू शकतो, आणि आतली नावे बाहेरच्या जगात कधीच पोहोचत नाहीत.
🚀 पुढे
पुढचा धडा दोन campuses खाजगी corridor ने जोडतो: VPC peering, आणि ते transitive का नाही.
🧪 इथे करून पाहा — campus च्या फोनबुकला नाव विचारा — school VPC मधून किंवा partner VPC मधून
दोन campuses मधला खाजगी corridor — overlap नको, दोन्ही बाजूंना routes, आणि तो transitive नाही (NOT transitive).
🧒 सोप्या शब्दांत
आपली शाळा partner शाळेपर्यंत खाजगी corridor बांधते, आणि partner vendor पर्यंत एक बांधतो. याचा अर्थ आपले विद्यार्थी partner च्या इमारतीतून vendor कडे जाऊ शकतात असा नाही. प्रत्येक corridor फक्त त्याच्या दोन टोकांवरच्या शाळाच जोडतो, आणि दोन्ही बाजूंनी त्याच्याकडे जाणाऱ्या पाट्या लावाव्या लागतात. दोन्ही शाळांचे घरांचे नंबरही वेगळे हवेत.
📖 नवे शब्दVPC peering — नेमक्या दोन VPCs मधील खाजगी जोड, जसे pcx-partnernot transitive — A↔B आणि B↔C असले तरी A↔C मिळत नाही; प्रत्येक जोडीला स्वतःचा जोड लागतोoverlapping CIDR — दोन्ही VPCs तेच नंबर वापरतात; मग peering नाकारले जातेpcx — peering connection च्या ID ची सुरुवात, route target म्हणून वापरतात
⏪ आधी
दोन teams चे VPCs फक्त public internet वरून बोलू शकत, दोन्ही बाजूंना public IPs आणि उघड्या दरवाजांसह.
💡 काय
Peering म्हणजे दोन campuses मधील खाजगी corridor: ranges overlap होऊ नयेत, दोन्ही बाजू routes जोडतात, आणि ते transitive नाही.
⚙️ कसे
10.20.0.0/16 ↔ 10.30.0.0/16 चालते; school→partner आणि partner→vendor peered आहेत, तरीही school → vendor नाकारले जाते.
🎯 का
Traffic AWS network वरच राहते, चालवायला कोणताही gateway नाही, आणि campuses ची प्रत्येक जोडी फक्त जाणूनबुजूनच जोडली जाते.
🚀 पुढे
पुढचा धडा अनेक corridors ऐवजी एक bus station आणतो: Transit Gateway, जिथे प्रत्येक VPC एकदाच attach होतो.
🧪 इथे करून पाहा — campuses मध्ये corridors मागवा, मग कोण कोणापर्यंत पोहोचतो ते तपासा (हे transitive नाही)
जिल्ह्याचे bus station — प्रत्येक VPC आणि office एकदाच attach होतात; कोण कोणाशी बोलू शकतो हे TGW route tables ठरवतात.
🧒 सोप्या शब्दांत
चार शाळा असतील तर प्रत्येक जोडीमध्ये corridors बांधायला सहा corridors लागतात. त्याऐवजी जिल्हा एक bus station बांधतो, आणि प्रत्येक शाळा त्याला एकदाच जोडली जाते. स्थानकाचे वेळापत्रक ठरवते की कोण कुठे जाऊ शकतो: dev चे विद्यार्थी shared ग्रंथालयापर्यंत जाऊ शकतात, पण prod शाळेपर्यंत कधीच नाही.
📖 नवे शब्दTransit Gateway — अनेक VPCs आणि VPNs जोडले जातात असे region मधील केंद्रattachment — Transit Gateway ला जोडलेला एक VPC किंवा VPN, प्रति तास बिलTGW route table — कोणते attachment कोणापर्यंत पोहोचू शकते ते ठरवणारे वेळापत्रकhub and spoke — एक केंद्र, आणि प्रत्येक network त्यालाच जोडलेले, एकमेकांना नाही
⏪ आधी
प्रत्येक VPC ला प्रत्येकाशी peering केले तर संख्या वेगाने वाढते: 4 VPCs ना 6 corridors, आणि प्रत्येक नवा VPC सगळ्यांशी corridor मागतो.
💡 काय
Transit Gateway म्हणजे जिल्ह्याचे bus station: प्रत्येक VPC आणि office VPN एकदाच attach होतात, आणि TGW route tables कोण बोलेल ते ठरवतात.
⚙️ कसे
prod → shared आणि dev → shared पुढे जातात, office-vpn → prod जाते, पण dev → prod ला TGW route table वेगळे ठेवते.
🎯 का
n·(n−1)/2 corridors ऐवजी प्रत्येक VPC ला एक attachment; खर्च प्रति attachment-hour आणि प्रति GB, आणि नियंत्रणाची एकच जागा मिळते.
🚀 पुढे
पुढचा धडा रोजच्या प्रश्नाचे उत्तर देतो, A पर्यंत B का पोहोचत नाही, flow logs आणि मार्गाच्या hop-by-hop तपासणीने.
🧪 इथे करून पाहा — TGW route table संपादित करा — कोण कोणाकडे प्रवास करू शकतो — आणि demo प्रवास तपासा
A ला B पर्यंत का पोहोचता येत नाही? — flow logs वाचा, मार्ग hop by hop चालून पाहा, नेमका अडथळा ओळखा.
🧒 सोप्या शब्दांत
Web desk म्हणतो की तो database पर्यंत पोहोचू शकत नाही. अंदाज लावण्याऐवजी आपण दरवाजाची डायरी वाचतो: प्रत्येक भेटीची एक ओळ, ACCEPT किंवा REJECT अशी. मग आपण एकेक रक्षक करत मार्ग चालतो. Desk ची यादी ठीक, wing चे दार ठीक, पाटी ठीक, आणि database desk च्या पाहुण्यांच्या यादीने नाही म्हटले.
📖 नवे शब्दflow logs — प्रत्येक संवादाची डायरीतील ओळ: source, destination, port, ACCEPT किंवा REJECTREJECT — security group किंवा NACL ने traffic अडवले असा flow-log मधील शिक्काReachability Analyzer — A पासून B पर्यंतचा मार्ग तपासून अडथळा सांगणारे AWS toolhop — मार्गावरील एक पायरी: रक्षक, पाटी किंवा दरवाजा
⏪ आधी
अयशस्वी connection फक्त timeout होत असे, आणि teams अंदाज करत, काहीतरी चालेपर्यंत वाटेल ते नियम उघडत.
💡 काय
Flow logs प्रत्येक संवादाची ACCEPT किंवा REJECT सह एक ओळ लिहितात; Reachability Analyzer मार्ग तपासून नेमका अडथळा सांगतो.
⚙️ कसे
10.20.0.10 → 10.20.96.15:5432 REJECT; तपासणी sg-web, acl-open, rt-public आणि acl-data पार करते, आणि sg-db in वर थांबते.
🎯 का
पुन्हा सुरक्षितपणे बंद करता न येणारी दारे उघडण्याऐवजी तुम्ही नेमक्या एका रक्षकाचा नेमका एक नियम दुरुस्त करता.
🚀 पुढे
पुढचा धडा सगळे एकत्र करतो: 3 AZs, तीन tiers, प्रत्येक AZ ला NAT आणि वाढीसाठी जागा असलेला production campus.
🧪 इथे करून पाहा — flow-log ची ओळ load करा (किंवा तुमची स्वतःची paste करा), तिची fields वाचा, मग अडथळा शोधण्यासाठी ती तपासत जा
टिकण्यासाठी बांधलेला campus — 3 AZs × public/app/data, प्रत्येक AZ मध्ये एक NAT, endpoints, flow logs, वाढीसाठी जागा.
🧒 सोप्या शब्दांत
टिकण्यासाठी बांधलेल्या campus मध्ये तीन इमारती असतात, प्रत्येकीत public wing, app wing आणि data wing. प्रत्येक इमारतीचा बाहेर जाण्याचा स्वतःचा मार्ग असतो, म्हणून एका ठिकाणच्या आगीत बाकीचे अडकत नाहीत. ग्रंथालयापर्यंत बोगदे, प्रत्येक भेटीची डायरी, आणि येणाऱ्या नव्या वर्गांसाठी अनेक खोली-नंबर रिकामे ठेवलेले.
📖 नवे शब्दNAT gateway — private wings ना internet पर्यंत जाण्याचा बाहेरचा मार्ग; प्रत्येक AZ ला एकmulti-AZ — एक बिघाड झेलता यावा म्हणून तेच wings अनेक इमारतींमध्येheadroom — वाढीसाठी राखलेले न वापरलेले पत्ते, जसे 65,536 पैकी 28,672data tier — databases साठीचा wing, ज्याला internet कडे route च नाही
⏪ आधी
एकेक दुरुस्ती करत वाढलेल्या networks मध्ये शेवटी NAT एकाच AZ मध्ये, endpoints नाहीत, logs नाहीत आणि पत्तेही उरलेले नाहीत.
💡 काय
Production campus म्हणजे 3 AZs × public, app आणि data wings, प्रत्येक AZ ला एक NAT, S3 आणि DynamoDB endpoints, आणि flow logs चालू.
⚙️ कसे
9 subnets 65,536 पैकी 36,864 पत्ते वापरतात, वाढीसाठी 28,672 उरतात; data wings ना internet कडे route च नाही.
🎯 का
एक AZ बंद पडला तरी बाकीचे तुटत नाहीत, databases पोहोचण्याबाहेर राहतात, आणि EKS pods पुन्हा numbering न करता वाढू शकतात.
🚀 पुढे
पुढे बाहेर जाण्याच्या मार्गासाठी NAT school, मुख्य प्रवेशद्वारासाठी API Gateway school, आणि pods साठी EKS networking कडे जा.
🧪 इथे करून पाहा — production campus design करा — planner पत्ते मोजतो आणि त्याचा आढावा घेतो