AWS मधले तुमचे स्वतःचे खाजगी नेटवर्क, शाळेच्या campus च्या रूपात शिकवलेले: घरांचे क्रमांक, वेगवेगळ्या इमारतींमधल्या wings, corridor च्या पाट्या, मुख्य दरवाजा, पाहुण्यांच्या याद्या आणि दारावरचे पहारेकरी, बोगदे, फोनबुक (दूरध्वनी पुस्तिका) आणि bus station. प्रत्येक धडा ही शाळेची एक गोष्ट आहे — हाताने काढलेल्या आकृतीसह आणि एका lab सह — आणि campus repo मध्येच आहे: शुद्ध Python मधले VPC चे शिकवण्यासाठीचे मॉडेल (vpc/network.py, शून्य dependencies) जे subnets आखते, routes शोधते आणि एक packet desk पासून desk पर्यंत चालवून दाखवते.
🔢 CIDR🧱 subnets आणि AZs🪪 5 राखीव IPs🪧 route tables🚪 internet gateway🧍 SG विरुद्ध NACL🚇 endpoints🤝 peering🚌 Transit Gateway🔎 flow logs
🏫 भाग 1 — CAMPUS (1–6)
तुमचा स्वतःचा कुंपण घातलेला campus का 🏫
घरांचे क्रमांक आणि wings 🔢🧱
corridor च्या पाट्या आणि मुख्य दरवाजा 🪧🚪
पाहुण्यांच्या याद्या आणि wing चे दार 🧍
🌐 भाग 2 — campuses जोडणे (7–12)
AWS services कडे जाणारे खाजगी बोगदे 🚇
campus चे फोनबुक 📒
corridors आणि bus station 🤝🚌
अडथळा शोधणे, टिकाऊ बांधणी 🔎🏗️
# the 60-second wow — every lesson's campus, live:
git clone https://github.com/BaluRaut/learn-vpc-school.git && cd learn-vpc-school
python3 vpc/demo.py # 12 lessons: plans, routes and packet walks
python3 vpc/test_vpc.py # 12 checks across the lessons
तुम्हाला काय दिसायला हवे (छाटलेले — यश असे दिसते):
═══ why ═══
── a VPC is the school's own fenced campus inside the AWS city: your addresses, your wings, your gates
10.20.0.0/16 → 65,536 addresses · one region · wings (subnets) live in one AZ each
the default VPC (172.31.0.0/16, every subnet public) is for trying things — real work gets its own campus
═══ cidr ═══
── CIDR: the /number says how many leading bits are fixed — fewer fixed bits, more addresses
10.20.0.0/16 65,536 addresses
10.20.0.0/20 4,096 addresses
10.20.0.0/24 256 addresses
10.20.0.0/28 16 addresses
10.0.0.0/16 vs the office network 10.0.0.0/16: OVERLAPS — pick another range
10.0.128.0/17 vs the office network 10.0.0.0/16: OVERLAPS — pick another range
10.20.0.0/16 vs the office network 10.0.0.0/16: no overlap → safe to connect later
choose a range that will never collide with the office, other VPCs or partners — you cannot change it easily
═══ subnets ═══
── three tiers × three AZs, each /20 carved from 10.20.0.0/16
public ap-south-1a 10.20.0.0/20 4,091 usable
public ap-south-1b 10.20.16.0/20 4,091 usable
public ap-south-1c 10.20.32.0/20 4,091 usable
app ap-south-1a 10.20.48.0/20 4,091 usable
app ap-south-1b 10.20.64.0/20 4,091 usable
app ap-south-1c 10.20.80.0/20 4,091 usable
data ap-south-1a 10.20.96.0/20 4,091 usable
data ap-south-1b 10.20.112.0/20 4,091 usable
data ap-south-1c 10.20.128.0/20 4,091 usable
── in EVERY subnet AWS keeps 5 addresses — 10.20.0.0/24: 10.20.0.0, 10.20.0.1, 10.20.0.2, 10.20.0.3, 10.20.0.255
so a /24 gives 251 usable addresses, not 256 · a /28 (the smallest) gives 11
═══ routes ═══
── the corridor sign: the MOST SPECIFIC route that matches wins; 'local' is always there
→ 10.20.96.15 matches 10.20.0.0/16 → local
→ 10.30.4.7 matches 10.30.0.0/16 → pcx-partner
→ 52.219.40.10 matches pl-s3 → vpce-s3
→ 93.184.216.34 matches 0.0.0.0/0 → nat-a
═══ igw ═══
── a subnet is 'public' only because its route table sends 0.0.0.0/0 to the internet gateway
web → internet :443 ✅ 🧍 sg-web out ✓ · 🚦 acl-open rule 100 ALLOW · 🪧 rt-public: 0.0.0.0/0 → igw-school · 🚪 leaves the subnet via igw-school
db → internet :443 🚫 🧍 sg-db out ✓ · 🚦 acl-data rule 110 ALLOW · 🪧 no route → dropped
and the desk also needs a public IP (or an Elastic IP) — the gate needs an address to write back to
═══ guards ═══
── inside the campus: the wing door (NACL, stateless) and the desk's guest list (security group, stateful)
web → 10.20.48.25:8080 ✅
🧍 sg-web out ✓
🚦 acl-open rule 100 ALLOW
🪧 rt-public: 10.20.0.0/16 → local
🚦 acl-open rule 100 ALLOW (destination subnet, in)
🧍 sg-app in ✓
app → 10.20.96.15:5432 ✅
🧍 sg-app out ✓
🚦 acl-open rule 100 ALLOW
🪧 rt-private-a: 10.20.0.0/16 → local
🚦 acl-data rule 100 ALLOW (destination subnet, in)
🧍 sg-db in ✓
web → 10.20.96.15:5432 🚫
🧍 sg-web out ✓
🚦 acl-open rule 100 ALLOW
🪧 rt-public: 10.20.0.0/16 → local
🚦 acl-data rule 110 ALLOW (destination subnet, in)
⛔ sg-db in — not on the guest list
═══ endpoints ═══
── reaching S3 from a private wing: through the NAT (paid per GB) or a gateway endpoint (free, never leaves AWS)
rt-private-a → S3 52.219.40.10 via pl-s3 → vpce-s3
rt-data → S3 52.219.40.10 via pl-s3 → vpce-s3
gateway endpoints: S3 and DynamoDB, a route-table entry · interface endpoints (PrivateLink): an ENI with a
private IP in your subnet for many other services (SQS, ECR, Secrets Manager…), billed per hour + per GB
═══ dns ═══
── every VPC has a resolver at base + 2 = 10.20.0.2 (and 169.254.169.253); enableDnsSupport + enableDnsHostnames on
db.school.internal → 10.20.96.15
app.school.internal → 10.20.48.25
db.school.internal (from the partner VPC) → no answer — private zone not associated with that VPC
a private hosted zone answers only inside the VPCs it is associated with
═══ peering ═══
── peering joins two campuses with a private corridor — no overlap allowed, and it is NOT transitive
10.20.0.0/16 ↔ 10.30.0.0/16: possible
10.20.0.0/16 ↔ 10.20.128.0/17: refused — the ranges overlap
school → partner: ✅ peered
partner → vendor: ✅ peered
school → vendor: 🚫 no — school↔partner and partner↔vendor does not give school↔vendor
both sides also need routes to each other's CIDR through the peering connection
═══ tgw ═══
── a Transit Gateway is the district bus station: every VPC attaches once, route tables decide who may talk
prod → shared ✅
dev → shared ✅
dev → prod 🚫 kept apart by the TGW route table
office-vpn → prod ✅
4 VPCs with peering need 6 corridors (n·(n−1)/2); with a TGW, 4 attachments
═══ troubleshoot ═══
── VPC flow logs: one line per conversation — source, destination, ports, and ACCEPT or REJECT
10.20.48.25 → 10.20.96.15 :5432 ACCEPT
10.20.0.10 → 10.20.96.15 :5432 REJECT
198.51.100.9 → 10.20.0.10 :22 REJECT
── why is web → db :5432 rejected? walk it like Reachability Analyzer:
🧍 sg-web out ✓
🚦 acl-open rule 100 ALLOW
🪧 rt-public: 10.20.0.0/16 → local
🚦 acl-data rule 110 ALLOW (destination subnet, in)
⛔ sg-db in — not on the guest list
═══ design ═══
── a production campus: 3 AZs × (public · app · data), one NAT per AZ, S3 + DynamoDB gateway endpoints, flow logs on
9 subnets use 36,864 of 65,536 addresses — 28,672 left for growth (EKS pods eat addresses fast)
public: load balancers + NAT only · app: desks, no public IPs · data: databases, no route to the internet at all
✅ done — the campus answered every lesson
🎒 धडा 01 आधी: तुम्हाला फक्त Python 3 लागेल — बाकी काही नाही; AWS account नको, SDK नको. Lab हे VPC चे शिकवण्यासाठीचे मॉडेल आहे — खऱ्या account मध्ये VPC Reachability Analyzer आणि flow logs "A ला B पर्यंत का पोहोचता येत नाही?" याचे उत्तर देतात. चांगले शेजारी: NAT school (ज्या फाटकातून private wings बाहेर जातात), Networking school (IP, TCP, DNS अगदी पायापासून) आणि EC2 school (या wings मध्ये राहणारे desks).
एक git branch = एक कल्पना; branch 04 मध्ये धडे 01–04 आहेत. प्रत्येक plan, route आणि packet walk vpc/network.py मधूनच येतो — AWS account ची गरज नाही.
1
🏫 VPC का
AWS शहरातला शाळेचा स्वतःचा कुंपण घातलेला campus — तुमचे पत्ते, तुमच्या wings, तुमची दारे; तुम्ही मार्ग बांधल्याशिवाय आत काहीही येत नाही.lesson-01-why-vpcधडा वाचा →आकृती पहा ↗
2
🔢 CIDR आणि IP पत्ते
campus साठी घरांचे क्रमांक — /16, /20 आणि /24 चा अर्थ, private ranges, आणि range कधीच overlap का होऊ नये.lesson-02-cidr-ipsधडा वाचा →आकृती पहा ↗
3
🧱 Subnets आणि AZs
campus च्या wings, प्रत्येक एका इमारतीत — प्रत्येक AZ साठी range कापा; AWS प्रत्येक subnet मधले 5 पत्ते स्वतःकडे ठेवते.lesson-03-subnets-azsधडा वाचा →आकृती पहा ↗
4
🪧 Route tables
corridor च्या पाट्या — सर्वात नेमका (most specific) route जिंकतो, 'local' नेहमी असतो, प्रत्येक wing साठी एक table.lesson-04-route-tablesधडा वाचा →आकृती पहा ↗
5
🚪 Internet gateway आणि public subnets
मुख्य दरवाजा — subnet public असतो तो फक्त त्याचा route 0.0.0.0/0 → igw सांगतो म्हणून, आणि desk कडे public IP असतो म्हणून.lesson-05-igw-publicधडा वाचा →आकृती पहा ↗
6
🧍 Security groups विरुद्ध NACLs
desk ची पाहुण्यांची यादी (stateful) आणि wing चे दार (stateless, क्रमांक असलेले) — एक packet दोन्हींमधून चालवून पाहा.lesson-06-sg-vs-naclधडा वाचा →आकृती पहा ↗
🌐 भाग 2 — campuses जोडणे (धडे 7–12)
खऱ्या नेटवर्क्सना काय लागते: internet ऐवजी endpoints, DNS, peering, Transit Gateway hub, troubleshooting आणि production layout.
7
🚇 VPC endpoints
AWS services कडे जाणारा खाजगी बोगदा — S3/DynamoDB साठी gateway endpoints (मोफत), बाकीच्यांसाठी interface endpoints (PrivateLink).lesson-07-endpointsधडा वाचा →आकृती पहा ↗
8
📒 VPC मधले DNS
campus चे फोनबुक — base+2 वरचा resolver, private hosted zones, आणि फक्त आतच चालणारी नावे.lesson-08-dnsधडा वाचा →आकृती पहा ↗
9
🤝 VPC peering
दोन campuses मधला खाजगी corridor — overlap नको, दोन्ही बाजूंना routes, आणि तो transitive नाही (NOT transitive).lesson-09-peeringधडा वाचा →आकृती पहा ↗
10
🚌 Transit Gateway
जिल्ह्याचे bus station — प्रत्येक VPC आणि office एकदाच attach होतात; कोण कोणाशी बोलू शकतो हे TGW route tables ठरवतात.lesson-10-transit-gatewayधडा वाचा →आकृती पहा ↗
11
🔎 Flow logs आणि Reachability Analyzer
A ला B पर्यंत का पोहोचता येत नाही? — flow logs वाचा, मार्ग hop by hop चालून पाहा, नेमका अडथळा ओळखा.lesson-11-troubleshootingधडा वाचा →आकृती पहा ↗
12
🏗️ Production VPC design
टिकण्यासाठी बांधलेला campus — 3 AZs × public/app/data, प्रत्येक AZ मध्ये एक NAT, endpoints, flow logs, वाढीसाठी जागा.lesson-12-production-designधडा वाचा →आकृती पहा ↗
🗣️ हे मोठ्याने समजावून सांगा — धडा 12 नंतर: (1) /24 subnet मध्ये 256 नव्हे तर 251 वापरण्याजोगे पत्ते का मिळतात? (2) subnet ला "public" काय बनवते — आणि desk पर्यंत पोहोचता यावे म्हणून त्याला आणखी काय लागते? (3) security group ने port 5432 ला परवानगी दिली तरी connection अयशस्वी होते — कोणत्या stateless गोष्टीत rule कमी असू शकतो? (4) peering वापरून school ला partner मार्गे vendor पर्यंत का पोहोचता येत नाही? (5) private subnet NAT शिवाय S3 पर्यंत कसे पोहोचते? (6) web → db :5432 hop by hop चालून पाहा आणि अडथळा ओळखा.
प्रत्येक धडा एका क्रमांकित बॉक्स-आणि-बाण आकृतीत — स्वतंत्र पानावरही.
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 पत्ते मोजतो आणि त्याचा आढावा घेतो
