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

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

🏢 धडा 04 — प्रत्येक AZ ला एक फाटक

📍 तुम्ही इथे आहात: 8 पैकी धडा 04 · मागे: lesson-03-gateway-vs-instance · पुढे: lesson-05-elastic-ips

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

धडे 01–03, आणि टिकाऊ रचना: प्रत्येक Availability Zone मध्ये एक NAT gateway, आणि प्रत्येक AZ ची private route table त्याच AZ मधील NAT कडे निर्देश करते. nat/demo.py मधील peraz() दोन्ही रचनांमध्ये एक AZ बंद पाडून पाहते.

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

शाळेच्या तीन इमारती आहेत 🏢🏢🏢: A, B आणि C. प्रत्येकीची स्वतःची वीज आहे.

आराखडा 1: फक्त इमारत A ला फाटक आहे. B आणि C मधील विद्यार्थिनी मैदान ओलांडून A च्या फाटकाकडे जातात. मग A ची वीज जाते. प्रत्येक इमारतीतील प्रत्येक विद्यार्थिनी आत अडकते — आणि मैदान ओलांडण्याच्या लांबच्या चालीत रोज वेळही जात होता.

आराखडा 2: प्रत्येक इमारतीला स्वतःचे फाटक आणि स्वतःचा रखवालदार आहे. A ची वीज जाते. A मधील विद्यार्थिनी अडकतात (त्यांची इमारत तशीही अंधारात आहे). B आणि C मधील विद्यार्थिनी नेहमीप्रमाणे आपापल्या फाटकांतून बाहेर जातात.

AWS या इमारतींना Availability Zones म्हणते. मैदान ओलांडून जाणे म्हणजे cross-AZ traffic, आणि त्याची किंमत मोजावी लागते.

🗺️ आकृती

flowchart TB
    subgraph A["🏢 AZ a 💥"]
      pa["private-a"] --> na["nat-a"]
    end
    subgraph B["🏢 AZ b"]
      pb["private-b"] --> nb["nat-b"]
    end
    subgraph C["🏢 AZ c"]
      pc["private-c"] --> nc["nat-c"]
    end
    na -.->|"1 down with its AZ"| x["🚫"]
    nb -->|"2 still out"| net["🌐 internet"]
    nc -->|"2 still out"| net

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/nat/lesson-diagrams.html#l04

❓ काय

NAT gateway एकाच AZ मध्ये राहतो — तो एका subnet मध्ये तयार होतो, आणि subnet एकाच AZ मध्ये असते. AWS त्याला फक्त त्या AZ च्या आत redundant बनवते.
प्रत्येक AZ ला एक — तुम्ही वापरत असलेल्या प्रत्येक AZ च्या public subnet मध्ये NAT gateway तयार करा.
प्रत्येक AZ ची route table — प्रत्येक AZ च्या private subnets ना त्यांची स्वतःची route table द्या: private-a: 0.0.0.0/0 → nat-a, private-b: 0.0.0.0/0 → nat-b, private-c: 0.0.0.0/0 → nat-c. एकच shared private route table हे करू शकत नाही — ती फक्त एकाच NAT चे नाव लिहू शकते.
Blast radius — प्रत्येक AZ ला एक NAT असेल तर AZ बंद पडल्याचा परिणाम फक्त त्याच AZ वर होतो, ज्याचे स्वतःचे servers तसेही गेलेले असतात. एकच shared NAT असेल तर त्याचा AZ बंद पडला की प्रत्येक AZ तुटतो.
Cross-AZ data — एकच shared NAT असेल तर इतर AZs मधील प्रत्येक byte AZs ओलांडतो आणि NAT च्या स्वतःच्या per-GB fee च्या वर cross-AZ data transfer charge भरतो.
देवाणघेवाण — तीन NATs म्हणजे तीन तासाचे charges. Dev आणि test साठी एकच shared NAT ही नेहमीची, स्वीकारार्ह बचत आहे.

🤔 का

कारण AZs खरोखर बंद पडतात — वीज, cooling, network — आणि multi-AZ apps अशाच बांधल्या जातात की एखादा AZ गेला तरी चालेल. एकच shared NAT, multi-AZ रचना जो single point of failure काढण्यासाठी होती, तोच गुपचूप परत आणतो: AZ b आणि c मधील app servers टिकतात, पण ते payment API पर्यंत पोहोचू शकत नाहीत.

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

nat/gateway.py मधील route_for() "हे private subnet कोणता NAT वापरते?" याचे उत्तर देते — प्रत्येक AZ ला एक असलेल्या रचनेत nat_by_az[az], किंवा तुम्ही दिला तर shared. reachable() सांगते की तो NAT up आहे का. nat/demo.py मधील peraz() nat-a बंद करते आणि दोन्ही रचनांमध्ये तिन्ही AZs तपासते.

🧪 करून पाहा

python3 nat/demo.py peraz
python3 - <<'EOF'
import sys; sys.path.insert(0, "nat"); from gateway import NatGateway, route_for, reachable, monthly_cost
gws = {n: NatGateway(n, [ip], az) for n, ip, az in (("nat-a", "13.232.10.20", "a"), ("nat-b", "13.232.10.21", "b"), ("nat-c", "13.232.10.22", "c"))}
by_az = {"a": "nat-a", "b": "nat-b", "c": "nat-c"}
print("routes per AZ:", [route_for(az, by_az) for az in "abc"], "· shared:", [route_for(az, by_az, "nat-a") for az in "abc"])
gws["nat-b"].up = False
print("nat-b down, one per AZ :", [az for az in "abc" if reachable(az, by_az, gws)])
print("nat-b down, shared nat-a:", [az for az in "abc" if reachable(az, by_az, gws, "nat-a")])
print("hours only: 3 NATs", monthly_cost(3, 0), "· 1 NAT", monthly_cost(1, 0))
EOF

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

peraz हे 💥 AZ a goes down (nat-a with it) छापते, मग private-b: one-per-AZ → ✅ · one shared nat-a → 🚫 cut off (आणि private-c साठीही तसेच). तुमचा snippet हे छापतो:

routes per AZ: ['nat-a', 'nat-b', 'nat-c'] · shared: ['nat-a', 'nat-a', 'nat-a']
nat-b down, one per AZ : ['a', 'c']
nat-b down, shared nat-a: ['a', 'b', 'c']
hours only: 3 NATs 98.55 · 1 NAT 32.85

तिसरी ओळ नीट वाचा. AZ b बंद पडतो तेव्हा shared रचना ठीक दिसते — फाटक AZ a मध्ये आहे. Shared रचना रोज बिघडलेली नसते; ती त्याच दिवशी बिघडते ज्या दिवशी बंद पडणारा AZ फाटक असलेलाच असतो. कोणता AZ बंद पडेल हे तुम्ही निवडू शकत नाही. शेवटची ओळ म्हणजे सुरक्षिततेची किंमत: एका ऐवजी तीन तासाचे मीटर (उदाहरण किमती, कोणत्याही GB आधी).

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

प्रत्येक AZ ला एक NAT असेल तर AZ चा बिघाड त्या AZ च्या आतच राहतो; एकच shared NAT असेल तर ते नशिबावर अवलंबून असते — आणि सुरक्षित रचनेसाठी दोन जास्तीचे तासाचे charges लागतात.

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

tutorial मधून copy केलेली, सगळ्या AZs साठी एकच private route table — ती फक्त एकाच NAT कडे निर्देश करू शकते
तीन NAT gateways तयार केले, पण copy-paste मुळे प्रत्येक route table nat-a कडेच निर्देश करते
AZ a मधील NAT gateway "तात्पुरता" AZ b ला सेवा देतो — आणि मागोमाग येणारे cross-AZ bill
नंतर जोडलेल्या नव्या AZ ला सुद्धा स्वतःचा NAT आणि route table लागते हे विसरणे

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

खऱ्या account वर — प्रत्येक AZ साठी एक NAT gateway आणि एक private route यासाठी Terraform:

locals { azs = ["a", "b", "c"] }

resource "aws_eip" "nat" {
  for_each = toset(local.azs)
  domain   = "vpc"
}

resource "aws_nat_gateway" "this" {
  for_each      = toset(local.azs)
  allocation_id = aws_eip.nat[each.key].id
  subnet_id     = aws_subnet.public[each.key].id
  tags          = { Name = "nat-${each.key}" }
}

resource "aws_route" "private_default" {
  for_each               = toset(local.azs)
  route_table_id         = aws_route_table.private[each.key].id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.this[each.key].id
}

प्रत्येक private route table त्याच्याच AZ मधील NAT कडे निर्देश करते हे तपासा:

aws ec2 describe-route-tables --filters Name=vpc-id,Values=vpc-0abc --query 'RouteTables[].[RouteTableId,Associations[0].SubnetId,Routes[?DestinationCidrBlock==`0.0.0.0/0`].NatGatewayId|[0]]' --output table
aws ec2 describe-nat-gateways --filter Name=vpc-id,Values=vpc-0abc --query 'NatGateways[].[NatGatewayId,SubnetId]' --output table

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: "एक AZ गेला तर काय होते?" हा प्रत्येक architecture review मधील पहिला प्रश्न असतो. Egress साठी बरोबर उत्तर आहे "प्रत्येक AZ चा स्वतःचा NAT आहे; आपण तो AZ गमावतो, बाकी काही नाही".

⏭️ पुढे

बाहेर जाणारी प्रत्येक फेरी फाटकाचा पत्ता घेऊन बाहेर पडते. Partners त्या पत्त्यावर विश्वास ठेवू शकतात — पण त्यांनी फक्त त्यावरच विश्वास ठेवावा का? Elastic IPs आणि allow-listing.

git checkout lesson-05-elastic-ips

🏢 Lesson 04 — One gate per AZ

📍 You are here: Lesson 04 of 8 · Previous: lesson-03-gateway-vs-instance · Next: lesson-05-elastic-ips

📦 What's in this branch

Lessons 01–03, plus the resilient design: one NAT gateway in each Availability Zone, and each AZ's private route table pointing at the NAT in the same AZ. peraz() in nat/demo.py fails one AZ under both designs.

🧒 Explain like I'm 5

The school has three buildings 🏢🏢🏢: A, B and C. Each has its own power.

Plan 1: only building A has a gate. Pupils in B and C walk across the yard to A's gate. Then A has a power cut. Every pupil in every building is stuck inside — and the long walk across the yard cost time every day too.

Plan 2: each building has its own gate with its own guard. A has a power cut. Pupils in A are stuck (their building is dark anyway). Pupils in B and C walk out of their own gates as usual.

AWS calls the buildings Availability Zones. The walk across the yard is cross-AZ traffic, and it has a price.

🗺️ Diagram

flowchart TB
    subgraph A["🏢 AZ a 💥"]
      pa["private-a"] --> na["nat-a"]
    end
    subgraph B["🏢 AZ b"]
      pb["private-b"] --> nb["nat-b"]
    end
    subgraph C["🏢 AZ c"]
      pc["private-c"] --> nc["nat-c"]
    end
    na -.->|"1 down with its AZ"| x["🚫"]
    nb -->|"2 still out"| net["🌐 internet"]
    nc -->|"2 still out"| net

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

❓ What

A NAT gateway lives in one AZ — it is created in one subnet, and a subnet is in one AZ. AWS makes it redundant inside that AZ only.
One per AZ — create a NAT gateway in the public subnet of each AZ you use.
Route tables per AZ — give each AZ's private subnets their own route table: private-a: 0.0.0.0/0 → nat-a, private-b: 0.0.0.0/0 → nat-b, private-c: 0.0.0.0/0 → nat-c. One shared private route table cannot do this — it can only name one NAT.
Blast radius — with one NAT per AZ, an AZ failure only affects that AZ, which has lost its own servers anyway. With one shared NAT, the failure of its AZ cuts off every AZ.
Cross-AZ data — with one shared NAT, every byte from the other AZs crosses AZs and pays a cross-AZ data transfer charge on top of the NAT's own per-GB fee.
The trade — three NATs means three hourly charges. For dev and test, one shared NAT is a common, acceptable saving.

🤔 Why

Because AZs do fail — power, cooling, network — and multi-AZ apps are built so that one AZ can go away. A single shared NAT quietly brings back the single point of failure that the multi-AZ design was meant to remove: the app servers in AZ b and c survive, but they can no longer reach the payment API.

🔧 How (in this repo)

route_for() in nat/gateway.py answers "which NAT does this private subnet use?" — nat_by_az[az] in the one-per-AZ design, or shared if you pass one. reachable() says whether that NAT is up. peraz() in nat/demo.py sets nat-a down and checks all three AZs under both designs.

🧪 Try it

python3 nat/demo.py peraz
python3 - <<'EOF'
import sys; sys.path.insert(0, "nat"); from gateway import NatGateway, route_for, reachable, monthly_cost
gws = {n: NatGateway(n, [ip], az) for n, ip, az in (("nat-a", "13.232.10.20", "a"), ("nat-b", "13.232.10.21", "b"), ("nat-c", "13.232.10.22", "c"))}
by_az = {"a": "nat-a", "b": "nat-b", "c": "nat-c"}
print("routes per AZ:", [route_for(az, by_az) for az in "abc"], "· shared:", [route_for(az, by_az, "nat-a") for az in "abc"])
gws["nat-b"].up = False
print("nat-b down, one per AZ :", [az for az in "abc" if reachable(az, by_az, gws)])
print("nat-b down, shared nat-a:", [az for az in "abc" if reachable(az, by_az, gws, "nat-a")])
print("hours only: 3 NATs", monthly_cost(3, 0), "· 1 NAT", monthly_cost(1, 0))
EOF

✅ Verify — what you should see

peraz prints 💥 AZ a goes down (nat-a with it), then private-b: one-per-AZ → ✅ · one shared nat-a → 🚫 cut off (and the same for private-c). Your snippet prints:

routes per AZ: ['nat-a', 'nat-b', 'nat-c'] · shared: ['nat-a', 'nat-a', 'nat-a']
nat-b down, one per AZ : ['a', 'c']
nat-b down, shared nat-a: ['a', 'b', 'c']
hours only: 3 NATs 98.55 · 1 NAT 32.85

Read the third line carefully. When AZ b fails, the shared design looks fine — the gate is in AZ a. The shared design is not broken every day; it is broken on the day the failing AZ is the one holding the gate. You cannot choose which AZ fails. The last line is the price of safety: three hourly meters instead of one (example prices, before any GB).

🏁 What you just proved

With one NAT per AZ, an AZ failure stays inside that AZ; with one shared NAT, it depends on luck — and the safe design costs two extra hourly charges.

⚠️ Common mistakes

one private route table for all AZs, copied from a tutorial — it can only point at one NAT
three NAT gateways created, but every route table pointing at nat-a by copy-paste
a NAT gateway in AZ a serving AZ b "temporarily" — and the cross-AZ bill that follows
forgetting that a new AZ added later needs its own NAT and route table too

🏭 In production

On a real account — Terraform for one NAT gateway and one private route per AZ:

locals { azs = ["a", "b", "c"] }

resource "aws_eip" "nat" {
  for_each = toset(local.azs)
  domain   = "vpc"
}

resource "aws_nat_gateway" "this" {
  for_each      = toset(local.azs)
  allocation_id = aws_eip.nat[each.key].id
  subnet_id     = aws_subnet.public[each.key].id
  tags          = { Name = "nat-${each.key}" }
}

resource "aws_route" "private_default" {
  for_each               = toset(local.azs)
  route_table_id         = aws_route_table.private[each.key].id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.this[each.key].id
}

Check that every private route table points at a NAT in its own AZ:

aws ec2 describe-route-tables --filters Name=vpc-id,Values=vpc-0abc --query 'RouteTables[].[RouteTableId,Associations[0].SubnetId,Routes[?DestinationCidrBlock==`0.0.0.0/0`].NatGatewayId|[0]]' --output table
aws ec2 describe-nat-gateways --filter Name=vpc-id,Values=vpc-0abc --query 'NatGateways[].[NatGatewayId,SubnetId]' --output table

🏭 Why this matters in production: "what happens when one AZ goes away?" is the first question in every architecture review. For egress, the correct answer is "each AZ has its own NAT; we lose that AZ and nothing else".

⏭️ Next

Every trip out leaves with the gate's address on it. Partners can trust that address — but should they trust only that? Elastic IPs and allow-listing.

git checkout lesson-05-elastic-ips

← Previousgateway vs instance Next →elastic ips

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