🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🤝 धडा 09 — VPC peering: दोन campuses मधला खाजगी corridor

📍 तुम्ही इथे आहात: 12 पैकी धडा 09 · मागचा: lesson-08-dns · पुढचा: lesson-10-transit-gateway

📦 या ब्रँचमध्ये काय आहे

धडे 01–08, आणि campuses मधला पहिला जोड: vpc/demo.py मधले peering() overlap होणाऱ्या ranges नाकारते आणि peering transitive नाही हे दाखवते, त्यासाठी vpc/network.py मधले overlaps() आणि peering_path() वापरते.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळा आणि भागीदार शाळा आपल्या campuses मध्ये एक छप्पर असलेला corridor 🤝 बांधतात. विद्यार्थी थेट पलीकडे चालत जातात, शहराच्या रस्त्यावर कधीच उतरत नाहीत.

तीन नियम:

वेगवेगळे घर नंबर. दोन्ही campuses 10.20.x.x वापरत असतील, तर 10.20.5.5 साठीच्या पत्राला ते कोणत्या बाजूसाठी आहे हे कळूच शकत नाही. तेच नंबर → corridor नाही.
दोन्ही बाजूंना पाट्या. शाळेची पाटी म्हणते "10.30.x.x → corridor". भागीदाराच्या पाटीवरही "10.20.x.x → corridor" असायलाच हवे, नाहीतर उत्तरे कधीच परत येत नाहीत.
मधून चालत जाणे नाही. भागीदाराचाही एका vendor कडे corridor आहे. शाळेतील विद्यार्थिनी भागीदारामधून vendor कडे चालत जाऊ शकत नाही. प्रत्येक जोडीला स्वतःचा corridor लागतो.

🗺️ आकृती

flowchart LR
    school["🏫 school 10.20.0.0/16"]
    partner["🏫 partner 10.30.0.0/16"]
    vendor["🏭 vendor"]
    school <-->|"pcx-1 · routes on both sides"| partner
    partner <-->|"pcx-2"| vendor
    school -.->|"🚫 not transitive"| vendor
    clash["10.20.0.0/16 ↔ 10.20.128.0/17<br/>refused — overlap"]

🗺️ रेखाटलेली आवृत्ती + एक lab: https://school-edh.pages.dev/vpc/lesson-diagrams.html#l09

❓ काय

VPC peering connection (pcx-…) — दोन VPCs मधला खाजगी जोड. Traffic AWS network वरच राहते. Size ठरवायला कोणताही gateway नाही आणि connection साठी स्वतः प्रति तास खर्च नाही (data transfer चा खर्च लागू शकतो, उदाहरणार्थ AZs किंवा Regions दरम्यान).
Requester आणि accepter — एक बाजू विचारते, दुसरी स्वीकारते. वेगवेगळ्या accounts मध्ये आणि वेगवेगळ्या Regions मध्ये चालते.
CIDRs overlap नकोत — ज्यांच्या ranges overlap होतात अशा VPCs मध्ये peering तयार करायला AWS नकार देते.
दोन्ही बाजूंना routes — प्रत्येक VPC च्या route tables मध्ये दुसऱ्याच्या CIDR कडे जाणारा, pcx-… target असलेला route हवा. आणि दोन्ही बाजूंचे security groups त्या traffic ला परवानगी देणारे हवेत (एकाच Region मध्ये, SG rule peered VPC मधल्या SG चा संदर्भ देऊ शकतो).
Transitive नाही — A↔B आणि B↔C असले तरी A↔C मिळत नाही. "edge-to-edge" routing ही नाही: A हा B चा internet gateway, NAT gateway, VPN किंवा gateway endpoint वापरू शकत नाही.
प्रमाण — ज्यांनी सगळ्यांनी एकमेकांशी बोलायला हवे अशा n VPCs ना n·(n−1)/2 peerings लागतात. म्हणूनच धडा 10 आहे.

🤔 का

कारण data share करायलाच हवा असे दोन-तीन VPCs — एक app आणि एक shared-services VPC, दोन teams, एक भागीदार — यांना सोपा आणि मध्ये कोणताही hub नसलेला खाजगी मार्ग हवा असतो. Peering हा सर्वात सोपा मार्ग आहे. त्याच्या मर्यादा (overlap नको, transitive नाही) हीच त्याची सुरक्षितता आहे: तुम्ही जोडलेल्या जोड्यांपलीकडे काहीच पोहोचत नाही.

🔧 कसे (या repo मध्ये)

vpc/demo.py मधले peering() दोन संभाव्य जोड्या overlaps() ने तपासते, मग peering_path(peerings, a, c) विचारते, जे फक्त (a, c) किंवा (c, a) ही जोडी स्वतःच set मध्ये असेल तरच true असते — मधून कोणताही शोध घेतला जात नाही. खालचा snippet "दोन्ही बाजूंना routes" हा नियम दाखवण्यासाठी RouteTable वापरतो.

🧪 करून पाहा

python3 vpc/demo.py peering
python3 - <<'EOF'
import sys; sys.path.insert(0, "vpc"); from network import RouteTable, peering_path, overlaps
school  = RouteTable("rt-school",  "10.20.0.0/16", [("10.30.0.0/16", "pcx-1")])
partner = RouteTable("rt-partner", "10.30.0.0/16")          # forgot the return route
print("school → 10.30.4.7: ", school.lookup("10.30.4.7"))
print("partner → 10.20.48.25:", partner.lookup("10.20.48.25"))
partner.routes.append(("10.20.0.0/16", "pcx-1"))
print("partner → 10.20.48.25:", partner.lookup("10.20.48.25"))
pe = {("school", "partner"), ("partner", "vendor")}
pe.add(("school", "vendor"))                                  # the only fix: a third corridor
print("school → vendor now:", peering_path(pe, "school", "vendor"))
print("default VPCs can peer?", not overlaps("172.31.0.0/16", "172.31.0.0/16"))
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

peering हे छापते:

   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

तुमचा snippet आधी school → 10.30.4.7: ('10.30.0.0/16', 'pcx-1') छापतो, मग partner → 10.20.48.25: (None, None) — उत्तराला घरी परतण्याचा मार्गच नाही — आणि return route नंतर ('10.20.0.0/16', 'pcx-1'). त्यानंतर school → vendor now: True (तिसरे peering) आणि default VPCs can peer? False.

🏁 तुम्ही आत्ताच काय सिद्ध केले

Peering फक्त वेगवेगळ्या ranges आणि दोन्ही बाजूंना routes असतील तरच चालते, आणि ते नेमके दोनच campuses जोडते — कधीच साखळी नाही.

⚠️ नेहमीच्या चुका

route फक्त एकाच बाजूला — requests जातात, उत्तरे टाकून दिली जातात
overlap होणारे VPCs peer करण्याची योजना (प्रत्येक default VPC, प्रत्येक 10.0.0.0/16)
A → B → C चालेल अशी अपेक्षा, किंवा A हा B चा NAT किंवा internet gateway वापरेल अशी अपेक्षा
पलीकडच्या बाजूच्या security groups मध्येही rule हवा हे विसरणे
डझनभर peerings चे असे जाळे जे आता कुणालाच काढता येत नाही

🏭 प्रत्यक्ष वापरात

एकमेकांत जास्त traffic असलेल्या काही VPCs साठी peering सामान्य आहे. मूठभरांपेक्षा जास्त झाले की teams Transit Gateway कडे वळतात.

खऱ्या account वर (AWS CLI आणि credentials लागतात; IDs उदाहरणादाखल आहेत):

aws ec2 create-vpc-peering-connection --vpc-id vpc-0school00000000a \
    --peer-vpc-id vpc-0partner0000000a --peer-owner-id 444455556666 --peer-region ap-south-1
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-0123456789abcdef0   # in the partner account
aws ec2 create-route --route-table-id rtb-0school0000000a --destination-cidr-block 10.30.0.0/16 \
    --vpc-peering-connection-id pcx-0123456789abcdef0
aws ec2 create-route --route-table-id rtb-0partner000000a --destination-cidr-block 10.20.0.0/16 \
    --vpc-peering-connection-id pcx-0123456789abcdef0

⏭️ पुढे

चार campuses ना 6 corridors लागतात; वीस campuses ना 190. आता एका hub ची वेळ — Transit Gateway, जिल्ह्याचे bus station.

git checkout lesson-10-transit-gateway

🤝 Lesson 09 — VPC peering: a private corridor between two campuses

📍 You are here: Lesson 09 of 12 · Previous: lesson-08-dns · Next: lesson-10-transit-gateway

📦 What's in this branch

Lessons 01–08, plus the first link between campuses: peering() in vpc/demo.py refuses overlapping ranges and shows that peering is not transitive, using overlaps() and peering_path() in vpc/network.py.

🧒 Explain like I'm 5

The school and the partner school build a covered corridor 🤝 between their campuses. Pupils walk straight across, never on the city street.

Three rules:

Different house numbers. If both campuses use 10.20.x.x, a letter for 10.20.5.5 cannot know which side it is for. Same numbers → no corridor.
Signs on both sides. The school's sign says "10.30.x.x → the corridor". The partner's sign must say "10.20.x.x → the corridor", or answers never come back.
No walking through. The partner also has a corridor to a vendor. A pupil from the school may not walk through the partner to the vendor. Each pair needs its own corridor.

🗺️ Diagram

flowchart LR
    school["🏫 school 10.20.0.0/16"]
    partner["🏫 partner 10.30.0.0/16"]
    vendor["🏭 vendor"]
    school <-->|"pcx-1 · routes on both sides"| partner
    partner <-->|"pcx-2"| vendor
    school -.->|"🚫 not transitive"| vendor
    clash["10.20.0.0/16 ↔ 10.20.128.0/17<br/>refused — overlap"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/vpc/lesson-diagrams.html#l09

❓ What

VPC peering connection (pcx-…) — a private link between two VPCs. Traffic stays on the AWS network. There is no gateway to size and no hourly charge for the connection itself (data transfer charges can apply, for example between AZs or Regions).
Requester and accepter — one side asks, the other accepts. Works across accounts and across Regions.
No overlapping CIDRs — AWS refuses to create a peering between VPCs whose ranges overlap.
Routes on both sides — each VPC's route tables need a route to the other's CIDR with the pcx-… as target. And the security groups on both sides must allow the traffic (in the same Region, an SG rule can reference an SG in the peered VPC).
Not transitive — A↔B and B↔C does not give A↔C. Also no "edge-to-edge" routing: A cannot use B's internet gateway, NAT gateway, VPN or gateway endpoint.
Scale — n VPCs that must all talk need n·(n−1)/2 peerings. That is why lesson 10 exists.

🤔 Why

Because two or three VPCs that must share data — an app and a shared-services VPC, two teams, a partner — need a private path that is simple and has no hub in the middle. Peering is the simplest one. Its limits (no overlap, not transitive) are also its safety: nothing reaches further than the pairs you wired.

🔧 How (in this repo)

peering() in vpc/demo.py checks two candidate pairs with overlaps(), then asks peering_path(peerings, a, c), which is true only if the pair (a, c) or (c, a) is itself in the set — there is no search through the middle. The snippet below uses RouteTable to show the "routes on both sides" rule.

🧪 Try it

python3 vpc/demo.py peering
python3 - <<'EOF'
import sys; sys.path.insert(0, "vpc"); from network import RouteTable, peering_path, overlaps
school  = RouteTable("rt-school",  "10.20.0.0/16", [("10.30.0.0/16", "pcx-1")])
partner = RouteTable("rt-partner", "10.30.0.0/16")          # forgot the return route
print("school → 10.30.4.7: ", school.lookup("10.30.4.7"))
print("partner → 10.20.48.25:", partner.lookup("10.20.48.25"))
partner.routes.append(("10.20.0.0/16", "pcx-1"))
print("partner → 10.20.48.25:", partner.lookup("10.20.48.25"))
pe = {("school", "partner"), ("partner", "vendor")}
pe.add(("school", "vendor"))                                  # the only fix: a third corridor
print("school → vendor now:", peering_path(pe, "school", "vendor"))
print("default VPCs can peer?", not overlaps("172.31.0.0/16", "172.31.0.0/16"))
EOF

✅ Verify — what you should see

peering prints:

   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

Your snippet prints school → 10.30.4.7: ('10.30.0.0/16', 'pcx-1'), then partner → 10.20.48.25: (None, None) — the answer has no way home — then ('10.20.0.0/16', 'pcx-1') after the return route. Then school → vendor now: True (a third peering) and default VPCs can peer? False.

🏁 What you just proved

A peering works only with different ranges and routes on both sides, and it joins exactly two campuses — never a chain.

⚠️ Common mistakes

the route on one side only — requests leave, replies are dropped
planning to peer VPCs that overlap (every default VPC, every 10.0.0.0/16)
expecting A → B → C to work, or expecting A to use B's NAT or internet gateway
forgetting the security groups on the far side still need a rule
a mesh of dozens of peerings that nobody can draw any more

🏭 In production

Peering is common for a few VPCs with heavy traffic between them. Beyond a handful, teams move to a Transit Gateway.

On a real account (needs the AWS CLI and credentials; IDs are examples):

aws ec2 create-vpc-peering-connection --vpc-id vpc-0school00000000a \
    --peer-vpc-id vpc-0partner0000000a --peer-owner-id 444455556666 --peer-region ap-south-1
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-0123456789abcdef0   # in the partner account
aws ec2 create-route --route-table-id rtb-0school0000000a --destination-cidr-block 10.30.0.0/16 \
    --vpc-peering-connection-id pcx-0123456789abcdef0
aws ec2 create-route --route-table-id rtb-0partner000000a --destination-cidr-block 10.20.0.0/16 \
    --vpc-peering-connection-id pcx-0123456789abcdef0

⏭️ Next

Four campuses need 6 corridors; twenty need 190. Time for a hub — the Transit Gateway, the district bus station.

git checkout lesson-10-transit-gateway

← Previousdns Next →transit gateway

This page is the lesson's README from the lesson-09-peering branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.