Ravindra BagaleCourses & study guides English

AWS मध्ये ALB vs NLB vs Gateway Load Balancer

By , trainer LinkedIn Last updated:

एक load balancer, त्याचे target groups आणि health checks आता एक region चालू ठेवतात (Health checks: who gets no traffic). हा chapter जास्त रुंद आणि जास्त खोल जातो. रुंद: Route 53 routing policies प्रत्येक user ला योग्य region कडे कसं पाठवतात. खोल: AWS चे चार load balancer types कोणते, OSI layers मुळे ALB आणि NLB मधला फरक कसा कळतो, chat आणि calls ना photo feed पेक्षा वेगळी connections का लागतात, push notifications phone पर्यंत कसे पोचतात, आणि HTTPS end-to-end encryption च्या तुलनेत काय सुरक्षित ठेवतं. शेवटी तुम्ही load balancer निवडून त्या निवडीचं कारण सांगू शकाल.

या class मध्ये काय शिकणार

  • प्रत्येक region ला एक load balancer, आणि समोर Route 53
  • Route 53 routing policies: geolocation, geoproximity, latency, weighted, IP-based
  • चार load balancer types
  • OSI layers, 7 पासून 1 पर्यंत
  • ALB (layer 7) vs NLB (layer 4)
  • TCP vs UDP
  • Long-lived vs short connections
  • ALB, NLB की Gateway Load Balancer निवडणे
  • Pull vs push, आणि push notifications कसे चालतात
  • Gateway Load Balancer आणि Classic Load Balancer
  • HTTPS vs end-to-end encryption

1. एक region पुरत नाही

का: load balancer एकाच region मध्ये काम करतो. Mumbai चा ALB दुसऱ्या region मधला server register करू शकत नाही.

समजा app दोन regions मध्ये चालतो, Mumbai (ap-south-1) आणि Hyderabad (ap-south-2):

  1. प्रत्येक region ला स्वतःचा load balancer, target groups आणि servers.
  2. Users तरीही एकच नाव type करतात, example.com.
  3. Route 53 त्या नावाचं उत्तर एका region च्या load balancer ने देतो. कुठला ते routing policy ठरवते.
  4. एखादा region health check fail झाला तर Route 53 त्याचं नाव देणं थांबवतो.
प्रत्येक region ला एक load balancer, समोर Route53 Users: example.com Route 53 routing policy region निवडते Mumbai · ap-south-1 Load balancer EC2 · EC2 · EC2 Hyderabad · ap-south-2 Load balancer EC2 · EC2 · EC2

Figure 1. Users example.com type करतात; Route 53 Mumbai (ap-south-1) किंवा Hyderabad (ap-south-2) च्या load balancer ने उत्तर देतो, प्रत्येकाचे स्वतःचे target groups आणि servers.

या layout बद्दल आणखी: One app, multiple regions आणि One domain name, many regions, many load balancers.

2. Route 53 routing policies

प्रत्येक policy "या user ला कुठला region?" याचं उत्तर वेगळ्या पद्धतीने देते:

  1. Geolocation: user च्या country किंवा state प्रमाणे. समजा एखादा show फक्त India मध्ये stream करायची परवानगी आहे: India मधल्या users ना Indian region, बाकी सगळ्यांना "not available" site.
  2. Geoproximity: user आणि प्रत्येक region मधल्या अंतराप्रमाणे, सोबत bias जो set करून region कडे जास्त किंवा कमी users ओढता येतात.
  3. Latency: त्या user साठी सगळ्यात कमी मोजलेला network delay असलेल्या region कडे. सगळ्यात fast म्हणजे नेहमी सगळ्यात जवळचा नाही.
  4. Weighted: तुम्ही ठरवलेल्या percentages प्रमाणे वाटणी.
  5. IP-based: user च्या IP range (CIDR) प्रमाणे, उदा. एका internet provider च्या range मधले सगळे users एका region कडे.
  6. Route 53 मध्ये simple (एकच उत्तर) आणि failover (primary, आणि primary unhealthy असेल तेव्हाच वापरला जाणारा standby) पण आहेत.

Weighted, worked example. समजा आपण Instagram आहोत आणि एक नवीन feature एका region मध्ये ready आहे:

  1. Record A (जुनं, stable version): weight 80.
  2. Record B (नवीन feature असलेला region): weight 20.
  3. B चा वाटा = 20 / (80 + 20) = DNS उत्तरांपैकी 20%.
  4. Errors वाढले तर B 0 करा. सगळं ठीक असेल तर 50/50, मग 0/100.

Classroom line

Big companies don't take this risk.

Route 53 routing policies: प्रत्येक region कसानिवडते Geolocation user च्या country किंवा state प्रमाणे समजा show फक्त India साठी licensed Geoproximity अंतराप्रमाणे, तुम्ही ठरवलेल्या bias सोबत bias region कडे जास्त users ओढतो Latency त्या user साठी सगळ्यात कमी मोजलेला delay fast म्हणजे नेहमी जवळचा नाही Weighted तुम्ही ठरवलेल्या weights प्रमाणे वाटणी समजा 80 stable / 20 नवीन feature weight 80: 80% उत्तरं · 20% IP-based user च्या IP range (CIDR) प्रमाणे उदा. एका provider ची range

Figure 2. Geolocation: country किंवा state प्रमाणे. Geoproximity: अंतराप्रमाणे, bias सोबत. Latency: सगळ्यात कमी मोजलेला delay. Weighted: समजा 80% stable version ला आणि 20% नवीन ला. IP-based: user च्या CIDR प्रमाणे.

एका target group च्या आत server निवडणं ही वेगळी setting: Routing policy.

3. चार load balancer types

  1. Application Load Balancer (ALB): layer 7. HTTP आणि HTTPS वाचतो: path, host, headers, cookies.
  2. Network Load Balancer (NLB): layer 4. TCP आणि UDP connections पुढे पाठवतो, खूप fast, प्रत्येक AZ मध्ये static IP सोबत.
  3. Gateway Load Balancer (GWLB): layer 3. Firewalls सारख्या security appliances वर traffic वाटतो (section 10).
  4. Classic Load Balancer (CLB): मागची generation. जुन्या setups साठी ठेवलाय; नवीन कामात ALB किंवा NLB.

Classroom line

We don't use the Classic Load Balancer now.

Layer 7, 4, 3: हे numbers OSI model मधून येतात. Layers समजले की types मधला फरक पण समजतो.

4. OSI layers

का: Dell laptop, HP laptop, phone आणि server, सगळे वेगवेगळ्या companies चे, एकमेकांना समजले पाहिजेत. OSI model म्हणजे सगळ्यांचे common rules, सात layers मध्ये. Data पाठवताना तो layer 7 पासून layer 1 पर्यंत खाली जातो; घेणारा तो 1 पासून परत 7 पर्यंत उघडतो.

Classroom line

Remember the OSI layers?

  1. Layer 7, Application: app जो protocol बोलतो तो: HTTP/HTTPS, SMTP, IMAP, POP3.
  2. Layer 6, Presentation: data चा format: encoding, compression, encryption (TLS).
  3. Layer 5, Session: दोन बाजूंमधलं संभाषण उघडणं, चालू ठेवणं आणि बंद करणं.
  4. Layer 4, Transport: TCP किंवा UDP, आणि ports. Data numbered तुकड्यांमध्ये, म्हणजे segments मध्ये, वाटतो.
  5. Layer 3, Network: source आणि destination IP addresses. Routers हा layer वाचतात, आणि content encrypted असला तरी हा दिसतो.
  6. Layer 2, Data link: MAC addresses; वाटेतल्या पुढच्या device ला frame (उदा. तुमचा router).
  7. Layer 1, Physical: cable वरचा किंवा Wi-Fi radio वरचा प्रत्यक्ष signal.

Classroom line

Who handles this? The browser does.

तुम्ही उघडता त्या प्रत्येक page साठी हे सगळं तुमचा browser आणि operating system करतात.

Worked example: किती segments? Normal Ethernet किंवा Wi-Fi path वर एक TCP segment साधारण 1,460 bytes पर्यंत data नेतो. समजा तुम्ही 10 MB ची file upload करता:

  1. 10 MB = 10 × 1,024 × 1,024 = 10,485,760 bytes.
  2. 10,485,760 / 1,460 ≈ 7,182 segments, प्रत्येकाला sequence number.
  3. घेणारा त्या numbers वरून ते परत क्रमाने लावतो.
OSI layers: data खाली जातो, मग परत वर 7 Application HTTP / HTTPS, SMTP, IMAP, POP3   ALB इथे काम करतो (layer 7) 6 Presentation format, compression, encryption (TLS) 5 Session संभाषण उघडणे, ठेवणे, बंद करणे 4 Transport TCP / UDP, ports, numbered segments   NLB इथे काम करतो (layer 4) 3 Network source आणि destination IP   GWLB इथे काम करतो (layer 3) 2 Data link MAC addresses, पुढच्या hop ला frame 1 Physical cable signal, Wi-Fi radio 1. पाठवताना: प्रत्येक layer स्वतःचा भाग जोडतो, 7 पासून 1 पर्यंत. 2. Layer 4: समजा 10 MB file → 1,460 bytes चे साधारण 7,182 numberedsegments. 3. घेताना: server 1 पासून परत 7 पर्यंत उघडतो.

Figure 3. Animation: request layers मधून खाली जाते: 7 HTTP, 6 TLS encryption, 5 session, 4 ports सोबत TCP segments, 3 IP addresses, 2 MAC frame, 1 signal; server ती 1 पासून 7 पर्यंत उघडतो. ALB layer 7 वर, NLB layer 4 वर, GWLB layer 3 वर काम करतो.

5. ALB vs NLB

ALB, layer 7:

  1. HTTP request उघडून path, host, headers आणि cookies वाचतो.
  2. म्हणून /reels* आणि /upload* वेगवेगळ्या target groups कडे route करू शकतो.
  3. प्रत्येक request साठी target निवडतो (default round robin); cookie ने sticky sessions.

NLB, layer 4:

  1. HTTP वाचत नाही. फक्त protocol, IP addresses आणि ports बघतो.
  2. प्रत्येक connection साठी target निवडतो, protocol + source IP आणि port + destination IP आणि port यांच्या hash वरून. त्या connection चा प्रत्येक packet त्याच target ला जातो.
  3. त्याच user चं नवीन connection दुसऱ्या target वर जाऊ शकतं. तो user एकाच server वर हवा असेल तर source IP stickiness चालू करा.
  4. HTTP उघडत नसल्यामुळे delay खूप कमी आणि खूप जास्त connections handle करतो. प्रत्येक AZ ला static IP देतो, आणि TLS पण terminate करू शकतो.
  5. NLB च्या मागे Nginx सारखा web server HTTP स्वतः वाचतो.

Source-IP stickiness चालू असेल तर एका user ची connections एकत्र राहतात:

Classroom line

All requests go to that same server.

Classroom line

Got the difference between the two? They ask this in interviews.

ALB request वाचतो; NLB फक्त connection बघतो ALB: layer 7 GET /reels/123 HTTP/1.1 Host: example.com Cookie: AWSALB=... • path, host, headers, cookies वाचतो • /reels* → tg-reels, /upload* → tg-upload • प्रत्येक request ला target (round robin) • cookie ने sticky sessions • HTTP / HTTPS, WebSockets साठी NLB: layer 4 TCP  203.0.113.5:51514 →  10.0.1.10:443 (content वाचत नाही) • फक्त protocol, IPs आणि ports बघतो • प्रत्येक connection ला target (flow hash) • optional source IP stickiness • प्रत्येक AZ ला static IP, TLS terminate करू शकतो • TCP / UDP, खूप कमी delay

Figure 4. Layer 7 वरचा ALB path, host, headers आणि cookies वाचतो, /reels* आणि /upload* route करतो, आणि प्रत्येक request साठी target निवडतो. Layer 4 वरचा NLB फक्त protocol, IPs आणि ports बघतो, flow hash ने प्रत्येक connection साठी target निवडतो, आणि ते connection त्याच्यावरच ठेवतो.

प्रत्येकाचे details: Application Load Balancer आणि Network Load Balancer.

6. TCP vs UDP

Layer 4 वर दोन मुख्य protocols आहेत.

TCP:

  1. आधी connection उघडतो.
  2. घेणारा जे मिळालं त्याची acknowledgement देतो.
  3. हरवलेले segments परत पाठवले जातात, आणि सगळं क्रमाने पोचतं.
  4. Chats, web pages आणि files साठी, जिथे प्रत्येक byte पोचायलाच हवा.

Classroom line

There's a catch there too: acknowledgements.

UDP:

  1. Connection set-up नाही, acknowledgements नाहीत, परत पाठवणं नाही.
  2. Voice आणि video calls साठी. उशिरा पोचलेला audio चा तुकडा काही कामाचा नाही; त्याच्यासाठी पूर्ण call थांबण्यापेक्षा तो सोडून देणं बरं.

Classroom line

That would be a big mess.

TCP वरचा live call प्रत्येक वेळी एक तुकडा हरवून परत पाठवला की अडकेल.

Acknowledgements चं रोजचं उदाहरण: WhatsApp ticks. समजा आपण WhatsApp आहोत:

  1. Clock: message अजून server पर्यंत पोचला नाही.
  2. एक tick: server ला मिळाला.
  3. दोन ticks: दुसऱ्या phone वर deliver झाला.
  4. Blue ticks: वाचला.
  5. या receipts app TCP च्या वर बनवतो. TCP ची स्वतःची acknowledgements खाली, प्रत्येक segment साठी चालू असतात, आणि ती तुम्हाला कधी दिसत नाहीत.
TCP vs UDP, आणि WhatsApp ticks खरं म्हणजे काय TCP • आधी connection • पोचलेल्याची acknowledgement • हरवलेले segments परत, क्रमाने chats, web pages, files UDP • acknowledgement नाही • परत पाठवणं नाही: उशिराचा audio निरुपयोगी • अडकलेल्या call पेक्षा छोटा gap बरा live voice आणि video calls WhatsApp ticks: TCP च्या वर बनवलेल्या app-levelreceipts ◷ अजून server वर नाही ✓ server ला मिळाला ✓✓ phone वर delivered ✓✓ वाचला (blue)

Figure 5. TCP: connection, acknowledgements, हरवलेले segments परत, क्रमाने; chats, pages आणि files साठी. UDP: acknowledgement नाही, परत पाठवणं नाही; live voice आणि video साठी. WhatsApp ticks (clock, एक tick, दोन ticks, blue) म्हणजे TCP च्या वर बनवलेल्या app-level receipts.

7. Long-lived vs short connections

समजा आपण WhatsApp आहोत.

  1. प्रत्येक उघडा app server शी सतत एक connection ठेवतो.
  2. Messages पाठवल्या पाठवल्या दोन्ही बाजूंनी त्यावरून जातात.
  3. एक server ठराविकच open connections धरू शकतो, म्हणून connections ची संख्या बघून planning करायचं.

समजा आपण Instagram आहोत.

  1. App connection उघडतो, feed मागतो, उत्तर घेतो आणि एक-दोन seconds मध्ये बंद करतो.
  2. तोच server तासाला खूप जास्त users serve करतो, कारण फक्त scroll करताना कोणी connection धरून ठेवत नाही.
Long-lived connections vs short requests Phone 1 · Phone 2 · Phone 3 · Phone 4 ⇅ Server 4 open connections समजा आपण WhatsApp आहोत: प्रत्येक phone एक connection उघडं ठेवतो;messages लगेच दोन्ही बाजूंनी. Server किती open connections धरू शकतो त्यावर planning. Phone GET /feed · 200 OK, close Server एका वेळी 1 request समजा आपण Instagram आहोत: उघडा, विचारा, उत्तर घ्या, एक-दोन secondsमध्ये बंद. तोच server तासाला खूप जास्त users serve करतो.

Figure 6. Animation: समजा आपण WhatsApp आहोत, जिथे प्रत्येक phone एक connection उघडं ठेवतो आणि messages दोन्ही बाजूंनी जातात; समजा आपण Instagram आहोत, जिथे प्रत्येक request उघडते, उत्तर घेते आणि बंद होते, म्हणून server पुढच्या user साठी मोकळा.

8. ALB, NLB की Gateway Load Balancer निवडणे

Classroom line

If your traffic is HTTP or HTTPS, use the Application Load Balancer.

  1. HTTP/HTTPS वरच्या websites आणि APIs → ALB. Path आणि host rules, cookie stickiness. HTTPS वर WebSockets ने chat पण ALB वर चालतो.
  2. Raw TCP किंवा UDP → NLB. Game servers, voice, custom chat protocols, devices साठी MQTT.
  3. Partners allow-list करू शकतील असा fixed IP address, किंवा खूप कमी delay सोबत प्रचंड throughput → NLB.
  4. आधी firewall appliances मधून जायलाच हवं असं traffic → Gateway Load Balancer.
  5. Classic → फक्त अजून न हलवलेल्या जुन्या setups मध्ये.
कुठला load balancer? Traffic पासून सुरुवात करा HTTP किंवा HTTPS website किंवा API(WebSockets पण)? → ALB Raw TCP किंवा UDP: games, voice,MQTT, custom chat? → NLB Allow-list साठी fixed IP, किंवा प्रचंडthroughput? → NLB आधी firewall appliances मधून जायलाच हवं? → Gateway LB अजून न हलवलेला जुना setup? → Classic

Figure 7. HTTP किंवा HTTPS, WebSockets सकट: ALB. Raw TCP किंवा UDP, static IP, किंवा प्रचंड throughput: NLB. Firewall appliances ने तपासायलाच हवं असं traffic: Gateway Load Balancer. Classic: फक्त जुने setups.

हाच निर्णय table मध्ये: Which load balancer to use.

9. Pull vs push, आणि push notifications

  1. Pull: app विचारतो. समजा आपण Instagram आहोत: तुम्ही app उघडलं की तो server कडे feed मागतो.
  2. Push: काही नवीन असेल तेव्हा server पाठवतो. समजा आपण WhatsApp आहोत: नवीन message तुम्ही न मागता येतो.

प्रत्येक app ला सतत विचारू का देऊ नये? दिवसभर डझनभर apps poll करत राहिले तर battery आणि data संपेल. म्हणून phone Google (FCM, Android) किंवा Apple (APNs, iOS) शी एकच long-lived connection ठेवतो, आणि सगळे apps ते share करतात.

Push notification कसा पोचतो:

  1. App install झाल्यावर तो FCM किंवा APNs कडे register होतो आणि त्याला device token मिळतो. Phone app ला त्याच्या app ID ने ओळखतो, उदा. com.instagram.android.
  2. App तो token स्वतःच्या server ला पाठवतो, जो तो user सोबत store करतो.
  3. समजा आपण Instagram आहोत आणि कोणी तुमचा photo like केला: आपला server token आणि छोटा message Google किंवा Apple ला पाठवतो.
  4. Google किंवा Apple तो phone च्या उघड्या connection वरून push करतात, app बंद असला तरी.
  5. Payload छोटा, साधारण 4 KB. Photo किंवा video S3 सारख्या storage मध्ये राहतो, आणि notification मध्ये फक्त link किंवा ID जातो.
  6. AWS वर SNS mobile push तुमच्यासाठी FCM आणि APNs ला पाठवू शकतो, alarm emails साठी वापरलेलाच SNS.
Push notification phone पर्यंत कसा पोचतो Phone com.instagram.android एक open connection 1. App FCM/APNs कडे register होऊन device token घेतो आणि server लापाठवतो. token · app स्वतःचा devicetoken app server ला पाठवतो App server समजा: Instagram · tokens store करतो 2. कोणी photo like केला: server token आणि छोटा message Google/Appleला पाठवतो. token + msg · ≤ ~4 KB FCM / APNs Google / Apple 3. Google/Apple तो open connection वरून push करतात, app बंद असला तरी.मोठ्या files: S3 ची link. push Phone

Figure 8. Animation: app FCM किंवा APNs कडे register होऊन device token घेतो, आणि तो app server ला पाठवतो; काही नवीन असेल तेव्हा app server token आणि छोटा message (जास्तीत जास्त साधारण 4 KB) Google किंवा Apple ला पाठवतो, जे तो phone च्या एकाच उघड्या connection वरून push करतात.

10. Gateway Load Balancer, आणि Classic Load Balancer

Gateway Load Balancer का: काही companies ना येणारं सगळं traffic app पर्यंत पोचायच्या आधी third-party next-generation firewalls ने तपासायलाच लागतं.

  1. Internet वरचं traffic आधी Gateway Load Balancer कडे जातं.
  2. तो layer 3 वर काम करत, ते traffic firewall appliances च्या group वर वाटतो.
  3. वाईट traffic, उदा. junk requests चा पूर, तिथेच drop होतं.
  4. स्वच्छ traffic पुढे तुमच्या ALB आणि app कडे जातं.
  5. म्हणून app tier junk साठी scale होत नाही, आणि त्याचे पैसे लागत नाहीत.
Gateway Load Balancer: आधी तपासणी, मग app Internet Gateway LB layer 3 Firewall appliances firewall 1 · firewall 2 · firewall 3 junk: drop ALB app · app · app फक्त स्वच्छ traffic app पर्यंत, म्हणून junk साठी scale नाही.

Figure 9. Internet traffic Gateway Load Balancer कडे जातं, जो ते firewall appliances वर वाटतो; वाईट traffic तिथेच drop होतं आणि फक्त स्वच्छ traffic ALB आणि app servers पर्यंत पोचतं.

Classic Load Balancer हा original, मागच्या generation चा load balancer. जुन्या accounts मध्ये अजून चालतो कारण चालू system migrate करण्यात risk असतो; नवीन set-ups मध्ये ALB किंवा NLB.

Classroom line

If it's running, don't touch it.

आणखी: Gateway Load Balancer आणि Classic Load Balancer.

11. HTTPS vs end-to-end encryption

HTTPS:

  1. Data browser आणि load balancer किंवा Nginx यांच्या मध्ये encrypted असतो.
  2. वाटेत कोणीच (Wi-Fi, ISP) तो वाचू शकत नाही.
  3. Server तो decrypt करतो, म्हणजे company चा server तो वाचू शकतो. तुमची order किंवा post process करायला त्याला ते लागतंच.

End-to-end encryption (समजा आपण WhatsApp आहोत):

  1. Message पाठवणाऱ्याच्या phone वरच encrypt होतो.
  2. Decrypt करायची key फक्त घेणाऱ्याच्या phone कडे असते.
  3. मधले servers फक्त तो पुढे पाठवतात आणि तो वाचू शकत नाहीत.
HTTPS vs end-to-end encryption HTTPS Browser रस्त्यात encrypted Load balancer / Nginx App server decrypted: server वाचू शकतो End-to-end पाठवणाऱ्याचा phone encrypt करतो WhatsApp servers फक्त पुढे पाठवतात: वाचू शकत नाहीत घेणाऱ्याचा phone फक्त तोच decrypt करतो

Figure 10. HTTPS: browser पासून load balancer किंवा Nginx पर्यंत encrypted, तिथे server decrypt करतो आणि वाचू शकतो. End-to-end: पाठवणाऱ्याच्या phone वर encrypt आणि फक्त घेणाऱ्याच्या phone वर decrypt; मधले servers फक्त पुढे पाठवतात.

12. Internet-facing आणि internal load balancers

  1. Internet-facing: public subnets मध्ये, public DNS name सोबत. Users त्याच्यातून web tier पर्यंत येतात.
  2. Internal: private subnets मध्ये, फक्त VPC च्या आत reachable. Web tier त्याच्यातून app tier ला call करतो.
  3. म्हणून three-tier app मध्ये दोन load balancers: internet → internet-facing LB → web tier → internal LB → app tier.

Details आणि security groups: Internet-facing and internal load balancers.

13. Console मध्ये बनवा

Part A: Route 53 मध्ये weighted routing (समजा Mumbai मध्ये एक आणि Hyderabad मध्ये एक ALB आधीच आहे)

  1. Route 53 > Hosted zones, example.com उघडा, Create record.
  2. Record name: रिकामं (root) किंवा www; type A; Alias चालू; route traffic to Alias to Application and Classic Load Balancer, region ap-south-1, Mumbai चा ALB निवडा.
  3. Routing policy Weighted, weight 80, record ID mumbai.
  4. Add another record: तेच नाव आणि type, ap-south-2 मधल्या Hyderabad ALB ला Alias, weight 20, record ID hyderabad.
  5. दोन्हींवर Evaluate target health चालू करा, म्हणजे unhealthy region वगळला जाईल. Create records.

Part B: Network Load Balancer

  1. EC2 > Target groups > Create target group, type Instances, protocol TCP, port 80, नाव tg-tcp. Web servers register करा.
  2. Load balancers > Create load balancer > Network Load Balancer, Internet-facing, वेगवेगळ्या AZs मधले दोन public subnets.
  3. Listener TCP:80 → tg-tcp. Create load balancer.
  4. NLB चं DNS name browser मध्ये उघडा. Nginx उत्तर देतो, कारण HTTP Nginx वाचतो, NLB नाही.
  5. Optional: tg-tcp > Attributes मध्ये Stickiness (source IP) चालू करा.

14. काही चुकलं तर

  1. Weighted records असूनही सगळे एकाच region मध्ये: clients TTL भर DNS उत्तर cache करतात; वाटणी खूप users मध्ये दिसते, एका laptop वर नाही.
  2. Region बंद आहे तरी users तिकडे जातात: त्याच्या record वर Evaluate target health बंद आहे.
  3. NLB वर path rules नाहीत: NLB HTTP वाचत नाही. Path किंवा host routing साठी ALB वापरा.
  4. NLB targets unhealthy: target security group ने traffic port आणि health check, NLB किंवा clients कडून, allow करायला हवं.
  5. मोठ्या image सोबतचा push notification fail होतो: payload limit साधारण 4 KB. त्याऐवजी S3 मधल्या image ची link पाठवा.

Ravindra Bagale's Tip

निवड protocol पासून सुरू करा. HTTP किंवा HTTPS: जवळजवळ नेहमी ALB. TCP किंवा UDP वरचं बाकी काही, किंवा fixed IP: NLB. Firewall appliances: Gateway Load Balancer. आणि नवीन version weighted records ने release करा, आधी 80/20, म्हणजे खराब release फक्त थोड्याच users ना दिसेल.

15. संपूर्ण class एका page वर

  1. Load balancer एकाच region ला serve करतो; अनेक regions साठी प्रत्येकी एक load balancer आणि समोर Route 53.
  2. Route 53 policies: geolocation, geoproximity (bias), latency, weighted (समजा 80/20), IP-based; सोबत simple आणि failover.
  3. चार types: ALB (layer 7), NLB (layer 4), Gateway (layer 3, appliances), Classic (मागची generation).
  4. OSI: 7 application, 6 presentation, 5 session, 4 transport, 3 network, 2 data link, 1 physical.
  5. 10 MB file ≈ साधारण 1,460 bytes चे 7,182 TCP segments.
  6. ALB: path, host, headers, cookies वाचतो; प्रत्येक request. NLB: protocol, IP, port; flow hash ने प्रत्येक connection; optional source-IP stickiness; static IP; TLS.
  7. TCP: acknowledged, परत पाठवणं, क्रमाने. UDP: यातलं काहीच नाही, live calls साठी. WhatsApp ticks म्हणजे TCP च्या वरच्या app receipts.
  8. WhatsApp सारखे apps connection उघडं ठेवतात; Instagram सारख्या requests छोट्या.
  9. Pull = app विचारतो; push = server पाठवतो, FCM/APNs मधून device token सोबत; payload साधारण 4 KB.
  10. HTTPS: server data वाचू शकतो. End-to-end: फक्त घेणाऱ्याचा phone.

16. घरी करून बघा

घरी करून बघा

Task 1: कागदावर

  1. Weighted records 90 आणि 10: प्रत्येकाला DNS उत्तरांचा किती वाटा? आणि 3 आणि 1 असेल तर?
  2. 2 MB file ला 1,460-byte चे किती segments लागतात (2 MB = 2,097,152 bytes)?
  3. प्रत्येकासाठी ALB, NLB की Gateway LB निवडा: shopping website; UDP वरचा multiplayer game; सगळं traffic firewall appliance मधून जायलाच हवं; partner ला allow-list करायला fixed IP हवा.

Task 2: console मध्ये

  1. तुमच्या web servers समोर TCP:80 listener सोबत NLB ठेवा आणि त्याचं DNS name उघडा.
  2. Route 53 मध्ये domain असेल तर दोन load balancers कडे दोन weighted Alias records (80/20) बनवा.

Task 3: clean up

  1. बनवलेले records, NLB आणि tg-tcp delete करा. Load balancers असेपर्यंत दर तासाला bill लागतं.

Recap

थोडक्यात

  1. Route 53 region निवडतो; load balancer server निवडतो.
  2. ALB layer 7 वर HTTP वाचतो; NLB layer 4 वर TCP/UDP पुढे पाठवतो; Gateway LB layer 3 वर firewalls ना traffic देतो.
  3. पोचायलाच हवं त्यासाठी TCP, वेळेवर पोचायला हवं त्यासाठी UDP.
  4. Push FCM/APNs मधून छोट्या payload ने; मोठ्या files link ने.
  5. HTTPS रस्ता सुरक्षित ठेवतं; end-to-end message घेणाऱ्याशिवाय सगळ्यांपासून सुरक्षित ठेवतं.

सराव Tasks

या scenario बद्दल

Milan Furniture हा मिलान मधला फर्निचर व्यवसाय आहे. Giulia Rossi त्यांचं IT व cloud काम पाहतात. त्यांचे पैसे EUR मध्ये मोजले जातात आणि AWS resources eu-south-1 Region मध्ये चालतात. खालच्या tasks मध्ये तुम्ही या lesson मध्ये शिकलेलं वापरून त्यांची खरी कामं करता. सगळी नावं, account IDs, IP addresses व numbers सरावासाठी काल्पनिक आहेत.

0 / 12

सोपं /16 मध्ये किती addresses?

का: VPC size ठरवायला ही संख्या लागते.

काय करायचं: Milan Furniture चा VPC 10.167.0.0/16. एकूण किती IP addresses?

कसं करायचं:
  1. Task मधले numbers लिहून घ्या.
  2. कागदावर step by step काढा.
  3. Box मध्ये फक्त final उत्तर लिहा.
  4. Check answer दाबा.

मध्यम Server साठी पहिला usable IP

का: पहिले 4 addresses AWS राखतो.

काय करायचं: AWS वर 10.167.20.0/24 मध्ये server ला मिळणारा पहिला IP?

कसं करायचं:
  1. Task मधले numbers लिहून घ्या.
  2. कागदावर step by step काढा.
  3. Box मध्ये फक्त final उत्तर लिहा.
  4. Check answer दाबा.

मध्यम VPC router address शोधा

का: AWS router साठी base+1 राखतो.

काय करायचं: 10.167.4.0/24 मध्ये VPC router साठी AWS कोणता address राखतो?

कसं करायचं:
  1. Task मधले numbers लिहून घ्या.
  2. कागदावर step by step काढा.
  3. Box मध्ये फक्त final उत्तर लिहा.
  4. Check answer दाबा.

मध्यम AWS /24 subnet मधले usable IPs

का: AWS प्रत्येक subnet मध्ये 5 addresses राखून ठेवतो.

काय करायचं: AWS वर 10.167.1.0/24 subnet मध्ये Milan Furniture servers साठी किती addresses वापरू शकतो?

कसं करायचं:
  1. Task मधले numbers लिहून घ्या.
  2. कागदावर step by step काढा.
  3. Box मध्ये फक्त final उत्तर लिहा.
  4. Check answer दाबा.

मध्यम /28 मधले usable IPs

का: /28 हा सर्वात लहान AWS subnet.

काय करायचं: AWS वर 10.167.9.0/28 subnet. किती usable IPs?

कसं करायचं:
  1. Task मधले numbers लिहून घ्या.
  2. कागदावर step by step काढा.
  3. Box मध्ये फक्त final उत्तर लिहा.
  4. Check answer दाबा.

मध्यम एका AZ मध्ये subnet बनवा

का: Subnets VPC range वाटतात व प्रत्येक एकाच AZ मध्ये असतो.

काय करायचं: vpc-01541f2c2fdeadbee मध्ये eu-south-1a मध्ये 10.5.1.0/24 subnet बनवा.

कसं करायचं:
  1. Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
  2. aws लिहा, मग service चं नाव, मग operation (action शब्द).
  3. प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
  4. Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

मध्यम Target health तपासा

का: Targets unhealthy असल्यास site 502/503 errors दाखवते.

काय करायचं: arn:aws:elasticloadbalancing:eu-south-1:126154182628:targetgroup/milanfurniture-tg/6d0ecf831eec9f09 मधल्या targets चं health दाखवा.

कसं करायचं:
  1. Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
  2. aws लिहा, मग service चं नाव, मग operation (action शब्द).
  3. प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
  4. Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

अवघड /26 ची range

का: Range माहीत असल्यास subnets overlap होत नाहीत.

काय करायचं: 10.167.3.64/26 चा पहिला व शेवटचा address लिहा.

कसं करायचं:
  1. Task मधले numbers लिहून घ्या.
  2. कागदावर step by step काढा.
  3. Box मध्ये फक्त final उत्तर लिहा.
  4. Check answer दाबा.

अवघड सर्वात लहान prefix निवडा

का: योग्य size मुळे address space वाचतो.

काय करायचं: AWS वर subnet मध्ये 100 servers हवेत. बसणारा सर्वात मोठा prefix number? उदा. /25.

कसं करायचं:
  1. Task मधले numbers लिहून घ्या.
  2. कागदावर step by step काढा.
  3. Box मध्ये फक्त final उत्तर लिहा.
  4. Check answer दाबा.

अवघड /24 चे दोन भाग

का: Public व private subnets एक block वाटून घेतात.

काय करायचं: 10.167.8.0/24 चे दोन समान subnets करा. दोन्ही CIDRs comma ने लिहा.

कसं करायचं:
  1. Task मधले numbers लिहून घ्या.
  2. कागदावर step by step काढा.
  3. Box मध्ये फक्त final उत्तर लिहा.
  4. Check answer दाबा.

अवघड Application Load Balancer बनवा

का: High availability साठी ALB ला वेगवेगळ्या AZs मधले किमान दोन subnets लागतात.

काय करायचं: milanfurniture-alb नावाचा ALB subnets subnet-02a1541c2a2cbb1 व subnet-0a1541c2a2cbb2 मध्ये security group sg-0261541b262b4c3b2 सह बनवा.

कसं करायचं:
  1. Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
  2. aws लिहा, मग service चं नाव, मग operation (action शब्द).
  3. प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
  4. Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

अवघड HTTP listener जोडा

का: Listener port वर traffic स्वीकारतो व target group कडे पाठवतो.

काय करायचं: Load balancer arn:aws:elasticloadbalancing:eu-south-1:126154182628:loadbalancer/app/milanfurniture-alb/50dc6c495c0c9188 वर port 80 चा HTTP listener बनवा जो arn:aws:elasticloadbalancing:eu-south-1:126154182628:targetgroup/milanfurniture-tg/6d0ecf831eec9f09 कडे forward करेल.

कसं करायचं:
  1. Task वाचा आणि ते कोणत्या AWS service बद्दल आहे ते ठरवा.
  2. aws लिहा, मग service चं नाव, मग operation (action शब्द).
  3. प्रत्येक आवश्यक flag (--name) व त्यापुढे task मधली value लिहा.
  4. Flags कोणत्याही क्रमाने चालतात. Check answer दाबा.

सगळे सराव tasks Task Hub मध्ये पाहा →

झटपट उजळणी cards

हा lesson दोन मिनिटांत revise करा. Cards phone वर save करा किंवा PNG download करा. प्रत्येक card वरचा QR त्याचा lesson उघडतो.

तुलना card: TCP vs UDP. TCP: Connection करून पाठवतो. Data क्रमाने पोहोचतो. UDP: Connection नाही. फक्त packets पाठवतो.
तुलना: TCP vs UDP · PNG download करा
तुलना card: ALB vs NLB. ALB: Application Load Balancer. Web requests वाचतो (HTTP/HTTPS, layer 7). NLB: Network Load Balancer. TCP/UDP न वाचता पुढे पाठवतो (layer 4).
तुलना: ALB vs NLB · PNG download करा
तुलना card: Short connection vs Long-lived connection. Short connection: उघडतं, एक उत्तर घेतं, बंद होतं. Long-lived connection: मिनिटं किंवा तास उघडं राहतं.
तुलना: Short connection vs Long-lived connection · PNG download करा
तुलना card: Pull vs Push. Pull: App सारखं server ला विचारतो: काही नवीन? Push: काही घडलं की server स्वतः पाठवतो.
तुलना: Pull vs Push · PNG download करा
तुलना card: HTTPS ends at the LB vs End-to-end encryption. HTTPS ends at the LB: User ते load balancer encrypted; LB ते servers साधं HTTP. End-to-end encryption: Server पर्यंत पूर्ण encrypted.
तुलना: HTTPS ends at the LB vs End-to-end encryption · PNG download करा
उजळणी card: Route 53 routing policies. जगभरातल्या users ना त्यांच्यासाठी best Region मिळायला हवा. Routing policy DNS कोणतं उत्तर देईल ते ठरवते: latency, geolocation, geoproximity, weighted, IP-based. प्रत्येक Region ला एक load balancer; Route 53 records प्रत्येकाकडे. Weighted: 90% जुनं version, 10% नवीन.
उजळणी card: Route 53 routing policies · PNG download करा
उजळणी card: OSI layers. "Layer 4" आणि "layer 7" ठरवतात कोणता load balancer निवडायचा. 7 layers: 7 Application, 6 Presentation, 5 Session, 4 Transport, 3 Network, 2 Data link, 1 Physical. प्रत्येक tool त्याच्या layer शी जोडा. HTTP = 7, TCP/UDP = 4, IP = 3.
उजळणी card: OSI layers · PNG download करा
उजळणी card: चार load balancer types. चुकीचा type म्हणजे पैसे जास्त किंवा app तुटतं. ALB (layer 7, HTTP), NLB (layer 4, TCP/UDP), Gateway LB (firewalls), Classic (जुना). Web apps: ALB. Games आणि खूप speed: NLB. Security appliances: GWLB. /api ते api-tg ला ALB path rules लागतात.
उजळणी card: चार load balancer types · PNG download करा
मुलाखत card: Route 53 मध्ये latency vs geolocation routing?. Latency सगळ्यात fast Region निवडतो; geolocation user च्या देशानुसार. Speed vs data कायदे किंवा भाषा सारखे rules. India users › geolocation ने Mumbai, Singapore fast असला तरी.
मुलाखत card: Route 53 मध्ये latency vs geolocation routing? · PNG download करा
मुलाखत card: DNS ने 10% users नवीन version कडे कसे पाठवता?. Route 53 weighted records: जुन्याला 90, नवीनला 10. सगळ्यांआधी थोड्या users वर release test. एकाच नावाच्या दोन records वर weights 90 आणि 10.
मुलाखत card: DNS ने 10% users नवीन version कडे कसे पाठवता? · PNG download करा
मुलाखत card: Layer 7 load balancer ला काय दिसतं जे layer 4 ला नाही?. URL paths, hosts, headers आणि cookies. म्हणून /api आणि /images वेगवेगळ्या servers कडे route करू शकतो. Layer 4 ला फक्त IPs आणि ports दिसतात.
मुलाखत card: Layer 7 load balancer ला काय दिसतं जे layer 4 ला नाही? · PNG download करा

अजून cards: Ravi Sir's Cards.