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

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

🚌 धडा 10 — Transit Gateway: जिल्ह्याचे bus station

📍 तुम्ही इथे आहात: 12 पैकी धडा 10 · मागचा: lesson-09-peering · पुढचा: lesson-11-troubleshooting

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

धडे 01–09, आणि hub: vpc/demo.py मधले tgw() prod, dev, shared आणि office-vpn यांना एकाच Transit Gateway ला attach करते, आणि एक TGW route table कोण कोणापर्यंत पोहोचू शकेल ते ठरवते — vpc/network.py मधल्या tgw_path() सह.

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

जिल्ह्यात अनेक शाळा आणि एक कार्यालय आहे. प्रत्येक जोडीमध्ये corridor बांधायचा म्हणजे खूपच जास्त corridors. म्हणून जिल्हा मधोमध एक bus station 🚌 बांधतो.

प्रत्येक campus station पर्यंत एकच रस्ता बांधतो — एक attachment. कार्यालयही एका VPN रस्त्याने जोडले जाते.

Station वर प्रत्येक रस्त्याचे स्वतःचे वेळापत्रक असते — TGW route table. Prod शाळेच्या वेळापत्रकात shared कडे आणि कार्यालयाकडे buses आहेत. Dev शाळेच्या वेळापत्रकात फक्त shared कडे bus आहे. त्यामुळे dev च्या विद्यार्थिनी shared ग्रंथालयापर्यंत पोहोचू शकतात, पण prod शाळेपर्यंत कधीच नाही — तिथे bus च नाही.

Bus एकाच दिशेने जाते. उत्तर परत यायचे असेल तर दुसऱ्या शाळेच्या वेळापत्रकातही परतीची bus हवी.

🗺️ आकृती

flowchart TB
    tgw["🚌 Transit Gateway"]
    prod["🏫 prod"] --- tgw
    dev["🏫 dev"] --- tgw
    shared["📚 shared"] --- tgw
    vpn["🏢 office-vpn"] --- tgw
    t1["timetable prod: shared · office-vpn"]
    t2["timetable dev: shared"]
    tgw -.-> t1
    tgw -.-> t2
    dev -.->|"🚫 no bus"| prod

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

❓ काय

Transit Gateway (TGW) — networks attach करता येणारा region मधला router. तो hub आहे: n VPCs ना n attachments लागतात, n·(n−1)/2 peerings नाहीत.
Attachments — एक VPC (TGW च्या network interfaces साठी तुम्ही प्रत्येक AZ मधला एक subnet निवडता), एक Site-to-Site VPN, Direct Connect (Direct Connect gateway मधून), दुसऱ्या TGW कडे peering (उदाहरणार्थ दुसऱ्या Region मध्ये), आणि SD-WAN appliances साठी Connect attachments.
TGW route tables — प्रत्येक attachment एका TGW route table शी associate असते (त्या attachment कडून येणाऱ्या traffic साठी वापरली जाणारी table). Table मध्ये routes attachments कडून propagation ने किंवा static routes म्हणून येतात. वेगवेगळ्या tables मुळे segmentation मिळते: dev आणि prod station share करतात पण वेळापत्रक नाही.
VPC मध्येही routes — traffic station कडे पाठवण्यासाठी प्रत्येक VPC च्या स्वतःच्या route tables मध्ये route हवा (उदाहरणार्थ 10.0.0.0/8 → tgw-…).
Transitive — peering च्या उलट, वेळापत्रके परवानगी देत असतील तर office VPN TGW मधून prod पर्यंत पोहोचू शकते.
खर्च — प्रति attachment-hour आणि प्रति processed GB (अनेक Regions मध्ये साधारण $0.05 प्रति attachment-hour आणि $0.02 प्रति GB — Transit Gateway pricing page तपासा). दोन VPCs मधला मोठा traffic peering वरून स्वस्त पडू शकतो.

🤔 का

कारण खऱ्या कंपन्यांकडे अनेक VPCs असतात — प्रत्येक team साठी, प्रत्येक environment साठी, प्रत्येक account साठी — शिवाय offices आणि data centres. वेळापत्रके असलेला hub म्हणजे कोण बोलू शकेल हे सांगण्याची एक जागा, आणि office जोडण्याची एक जागा.

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

vpc/network.py मधले tgw_path(attachments, route_table, a, c) फक्त तेव्हाच true असते जेव्हा दोघेही attached असतात आणि c हा a च्या route table मध्ये असतो. vpc/demo.py मधले tgw() चार प्रश्न विचारते आणि peerings विरुद्ध attachments मोजते. या model मध्ये प्रत्येक attachment ला एक table आहे आणि ते एकच दिशा तपासते; परतीची दिशा का महत्त्वाची हे snippet दाखवतो.

🧪 करून पाहा

python3 vpc/demo.py tgw
python3 - <<'EOF'
import sys; sys.path.insert(0, "vpc"); from network import tgw_path
att = {"prod", "dev", "shared", "office-vpn"}
rt = {"prod": ["shared", "office-vpn"], "dev": ["shared"], "shared": ["prod", "dev"], "office-vpn": ["prod"]}
print("dev → prod:", tgw_path(att, rt, "dev", "prod"))
rt["dev"].append("prod")                                     # someone widens dev's TGW route table
print("dev → prod after the change:", tgw_path(att, rt, "dev", "prod"), "· prod → dev:", tgw_path(att, rt, "prod", "dev"))
print("not attached:", tgw_path(att, {"sandbox": ["shared"]}, "sandbox", "shared"))
for n in (4, 10, 20):
    print(f"{n} VPCs: peering {n*(n-1)//2} links · TGW {n} attachments")
EOF

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

tgw हे छापते:

   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

तुमचा snippet आधी dev → prod: False छापतो, मग dev → prod after the change: True · prod → dev: False — request ला bus आहे, उत्तराला नाही, त्यामुळे AWS मध्ये connection तरीही अपयशी ठरेल. त्यानंतर not attached: False, आणि 4 VPCs: peering 6 links · TGW 4 attachments, 10 VPCs: peering 45 links · TGW 10 attachments, 20 VPCs: peering 190 links · TGW 20 attachments.

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

Hub n·(n−1)/2 corridors चे n रस्ते करतो, आणि त्याच्या route tables — दोन्ही दिशांनी — प्रत्यक्षात कोण बोलू शकेल ते ठरवतात.

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

default "सगळे associate आणि propagate करा" चालू ठेवणे — प्रत्येक VPC प्रत्येक दुसऱ्या VPC पर्यंत पोहोचू शकतो
TGW route फक्त एकाच दिशेने जोडणे
TGW कडे निर्देश करणारी VPC च्या स्वतःच्या route table मधली entry विसरणे
फक्त एकाच AZ चा subnet attach करणे — इतर AZs मधल्या instances चा मार्ग तुटतो
त्या दोन VPCs मधले peering स्वस्त पडत असताना प्रचंड, सततचा traffic TGW मधून पाठवणे

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

एक सामान्य रचना: प्रत्येक Region मध्ये एक TGW, AWS RAM ने accounts मध्ये share केलेला; एक prod table, एक nonprod table आणि एक shared table; office VPN किंवा Direct Connect वर; firewalls साठी inspection VPCs.

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

aws ec2 create-transit-gateway --description school-hub \
    --options DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable
aws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id tgw-0123456789abcdef0 \
    --vpc-id vpc-0dev000000000000a --subnet-ids subnet-0a subnet-0b subnet-0c
aws ec2 create-transit-gateway-route-table --transit-gateway-id tgw-0123456789abcdef0
aws ec2 associate-transit-gateway-route-table --transit-gateway-route-table-id tgw-rtb-0dev00000000000a \
    --transit-gateway-attachment-id tgw-attach-0dev0000000000a
aws ec2 enable-transit-gateway-route-table-propagation --transit-gateway-route-table-id tgw-rtb-0dev00000000000a \
    --transit-gateway-attachment-id tgw-attach-0shared00000000a
aws ec2 create-route --route-table-id rtb-0dev000000000000a --destination-cidr-block 10.0.0.0/8 \
    --transit-gateway-id tgw-0123456789abcdef0

⏭️ पुढे

Campus आता अनेक प्रकारे जोडलेला आहे — म्हणजे packet हरवण्याच्या अनेक जागा. Flow logs आणि Reachability Analyzer: A ला B पर्यंत का पोहोचता येत नाही?

git checkout lesson-11-troubleshooting

🚌 Lesson 10 — Transit Gateway: the district bus station

📍 You are here: Lesson 10 of 12 · Previous: lesson-09-peering · Next: lesson-11-troubleshooting

📦 What's in this branch

Lessons 01–09, plus the hub: tgw() in vpc/demo.py attaches prod, dev, shared and office-vpn to one Transit Gateway, and a TGW route table decides who may reach whom — with tgw_path() in vpc/network.py.

🧒 Explain like I'm 5

The district has many schools and one office. Building a corridor between every pair is too many corridors. So the district builds a bus station 🚌 in the middle.

Every campus builds one road to the station — an attachment. The office joins too, by a VPN road.

At the station, each road has its own timetable — the TGW route table. The prod school's timetable has buses to shared and to the office. The dev school's timetable has a bus to shared only. So dev pupils can reach the shared library, but never the prod school — there is simply no bus.

A bus goes one way. For an answer to come back, the other school's timetable needs a bus back too.

🗺️ Diagram

flowchart TB
    tgw["🚌 Transit Gateway"]
    prod["🏫 prod"] --- tgw
    dev["🏫 dev"] --- tgw
    shared["📚 shared"] --- tgw
    vpn["🏢 office-vpn"] --- tgw
    t1["timetable prod: shared · office-vpn"]
    t2["timetable dev: shared"]
    tgw -.-> t1
    tgw -.-> t2
    dev -.->|"🚫 no bus"| prod

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

❓ What

Transit Gateway (TGW) — a regional router you attach networks to. It is a hub: n VPCs need n attachments, not n·(n−1)/2 peerings.
Attachments — a VPC (you pick one subnet per AZ for the TGW's network interfaces), a Site-to-Site VPN, Direct Connect (through a Direct Connect gateway), a peering to another TGW (for example in another Region), and Connect attachments for SD-WAN appliances.
TGW route tables — each attachment is associated with one TGW route table (the table used for traffic arriving from that attachment). Routes get into a table by propagation from attachments or as static routes. Separate tables give segmentation: dev and prod share the station but not a timetable.
Routes in the VPC too — each VPC's own route tables need a route (for example 10.0.0.0/8 → tgw-…) to send traffic to the station.
Transitive — unlike peering, the office VPN can reach prod through the TGW, if the timetables allow it.
Cost — charged per attachment-hour and per GB processed (approximately $0.05 per attachment-hour and $0.02 per GB in many Regions — check the Transit Gateway pricing page). Heavy flows between two VPCs can be cheaper over a peering.

🤔 Why

Because real companies have many VPCs — per team, per environment, per account — plus offices and data centres. A hub with timetables is one place to say who may talk, and one place to connect the office.

🔧 How (in this repo)

tgw_path(attachments, route_table, a, c) in vpc/network.py is true only if both are attached and c is in a's route table. tgw() in vpc/demo.py asks four questions and counts peerings vs attachments. The model has one table per attachment and checks one direction; the snippet shows why the return direction matters.

🧪 Try it

python3 vpc/demo.py tgw
python3 - <<'EOF'
import sys; sys.path.insert(0, "vpc"); from network import tgw_path
att = {"prod", "dev", "shared", "office-vpn"}
rt = {"prod": ["shared", "office-vpn"], "dev": ["shared"], "shared": ["prod", "dev"], "office-vpn": ["prod"]}
print("dev → prod:", tgw_path(att, rt, "dev", "prod"))
rt["dev"].append("prod")                                     # someone widens dev's TGW route table
print("dev → prod after the change:", tgw_path(att, rt, "dev", "prod"), "· prod → dev:", tgw_path(att, rt, "prod", "dev"))
print("not attached:", tgw_path(att, {"sandbox": ["shared"]}, "sandbox", "shared"))
for n in (4, 10, 20):
    print(f"{n} VPCs: peering {n*(n-1)//2} links · TGW {n} attachments")
EOF

✅ Verify — what you should see

tgw prints:

   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

Your snippet prints dev → prod: False, then dev → prod after the change: True · prod → dev: False — the request has a bus, the reply does not, so in AWS the connection would still fail. Then not attached: False, and 4 VPCs: peering 6 links · TGW 4 attachments, 10 VPCs: peering 45 links · TGW 10 attachments, 20 VPCs: peering 190 links · TGW 20 attachments.

🏁 What you just proved

A hub turns n·(n−1)/2 corridors into n roads, and its route tables — in both directions — decide who may actually talk.

⚠️ Common mistakes

leaving the default "associate and propagate everything" on — every VPC can reach every other
adding the TGW route in one direction only
forgetting the VPC's own route table entry pointing to the TGW
attaching only one AZ's subnet — instances in other AZs lose the path
sending huge steady flows through the TGW when a peering between those two VPCs costs less

🏭 In production

A common shape: one TGW per Region, shared across accounts with AWS RAM; a prod table, a nonprod table and a shared table; the office on VPN or Direct Connect; inspection VPCs for firewalls.

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

aws ec2 create-transit-gateway --description school-hub \
    --options DefaultRouteTableAssociation=disable,DefaultRouteTablePropagation=disable
aws ec2 create-transit-gateway-vpc-attachment --transit-gateway-id tgw-0123456789abcdef0 \
    --vpc-id vpc-0dev000000000000a --subnet-ids subnet-0a subnet-0b subnet-0c
aws ec2 create-transit-gateway-route-table --transit-gateway-id tgw-0123456789abcdef0
aws ec2 associate-transit-gateway-route-table --transit-gateway-route-table-id tgw-rtb-0dev00000000000a \
    --transit-gateway-attachment-id tgw-attach-0dev0000000000a
aws ec2 enable-transit-gateway-route-table-propagation --transit-gateway-route-table-id tgw-rtb-0dev00000000000a \
    --transit-gateway-attachment-id tgw-attach-0shared00000000a
aws ec2 create-route --route-table-id rtb-0dev000000000000a --destination-cidr-block 10.0.0.0/8 \
    --transit-gateway-id tgw-0123456789abcdef0

⏭️ Next

The campus is connected in many ways now — which means many places for a packet to get lost. Flow logs and Reachability Analyzer: why can't A reach B?

git checkout lesson-11-troubleshooting

← Previouspeering Next →troubleshooting

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