ALB, NLB, GWLB আর Target Group

এই লেসন শেষে তুমি যা পারবে

• Elastic Load Balancing-এর চার ধরনের load balancer network-এর কোন layer-এ কাজ করে, আর প্রত্যেকে একটা packet-এর কতটুকু দেখতে পায়, তা বলতে পারবে।
• path, host, header, method, query string আর source IP দেখে ALB-এর listener rule বানাতে পারবে, priority দিয়ে সেগুলো সাজাতে পারবে, আর ঠিক action বেছে নিতে পারবে: forward (weighted canary আর blue/green-সহ), redirect, fixed response বা authenticate।
• ALB-এর পেছনের application কেন client-এর বদলে ALB-এর address দেখে, তা বোঝাতে পারবে, আর X-Forwarded-For, X-Forwarded-Proto আর X-Forwarded-Port কাজে লাগাতে পারবে।
• TCP, UDP আর TLS-এর জন্য NLB ব্যবহার করতে পারবে: প্রতি AZ-এ static IP, Elastic IP, client IP preservation, security group, target হিসেবে ALB, আর PrivateLink।
• GENEVE, GWLB endpoint আর route table দিয়ে GWLB কীভাবে third-party appliance-এর একটা fleet-কে traffic-এর পথে বসিয়ে দেয়, আর একটা appliance নষ্ট হলে কী হয়, তা বোঝাতে পারবে।
• target group সাজাতে পারবে: protocol, port, target type (instance, on-premises-সহ IP, Lambda, ALB), health check আর attribute।
• ঘণ্টার ভাড়া আর capacity unit থেকে load balancer-এর বিল আন্দাজ করতে পারবে, আর পরীক্ষার যেকোনো scenario পড়ে ঠিক load balancer বেছে নিতে পারবে।

#তিনটা load balancer, তিনটা layer

লেসন ৬.২-এ দেখেছ প্রতিটা Elastic Load Balancer কী করে: একটা স্থির প্রবেশপথ, health check, আর কয়েকটা Availability Zone-এর healthy target-দের মধ্যে traffic ভাগ করে দেওয়া। AWS চার ধরনের load balancer দেয়, আর এদের আসল পার্থক্য হলো প্রতিটা packet-এর কত গভীরে এরা তাকায়।

ALB, NLB আর GWLB হলো এখনকার প্রজন্ম, তিনটাই একই elbv2 API দিয়ে চালানো হয়, আর তিনটাই traffic পাঠায় target group-এ। CLB আগের প্রজন্মের: প্রতি application-এ একটা করে load balancer, target group নেই, content দেখে routing নেই। এই লেসনে সে আসবে শুধু তুলনার টেবিলে।

#Application Load Balancer (layer 7)

#সে কী বোঝে

ALB একটা পুরোদস্তুর HTTP proxy। সে client-এর connection নেয়, listener HTTPS হলে HTTPS খুলে নেয় (certificate আর SNI লেসন ৬.৪-এ), request পড়ে, কোথায় যাবে ঠিক করে, তারপর বেছে নেওয়া target-এর সাথে নিজের একটা connection খোলে।

• client-এর দিক থেকে HTTP/1.1 আর HTTP/2; target-এর সাথে default-এ HTTP/1.1, আর target group-এর protocol version বললে HTTP/2 বা gRPC (gRPC-র জন্য HTTPS listener লাগে)।
• WebSockets নিজে থেকেই চলে: ALB connection upgrade করে খোলা রাখে।
• ALB-এর নিজের একটা security group থাকতেই হয়, আর target-গুলো শুধু ওই group থেকে traffic নেবে, এটাই নিয়ম (লেসন ৬.২)।
• এর একটা স্থির DNS name আছে, যেমন web-alb-1234567890.us-east-1.elb.amazonaws.com, কিন্তু কোনো স্থির IP নেই। এ নিয়ে নিচে বিস্তারিত।
• এতে AWS WAF লাগানো যায়, অন্য কোনো ধরনের ELB-তে যায় না।

#Listener আর rule

listener মানে ALB কোন protocol আর port-এ traffic নেবে, যেমন HTTPS 443। প্রতিটা listener-এর একটা rule-এর তালিকা থাকে। প্রতিটা rule-এর থাকে একটা priority, এক বা একাধিক condition, আর এক বা একাধিক action।

rule কীভাবে মেলানো হয়:

1. ছোট priority নম্বর আগে

   rule দেখা হয় priority অনুযায়ী, 1 সবার আগে, 50,000 পর্যন্ত। যে rule প্রথম মিলে যায়, সে-ই জেতে, পরের কোনো rule আর দেখাই হয় না। ছোট নম্বরে বসানো একটা ঢালাও rule তার পরের সব নির্দিষ্ট rule-কে আড়াল করে দেয়।

2. একটা rule-এর সব condition মিলতে হবে

   host-header api.example.com আর path-pattern /users* দুটো নিয়ে একটা rule মিলবে শুধু তখনই, যখন দুটোই সত্যি। আবার একটা condition-এর ভেতরে তিনটা পর্যন্ত মান রাখা যায়, তার যেকোনো একটা মিললেই চলে (/users* অথবা /accounts*)। পুরো rule-এ সব মিলিয়ে পাঁচটা পর্যন্ত মান রাখা যায়।

3. বাকি সব ধরে default rule

   প্রতিটা listener-এ ঠিক একটা default rule থাকে। এর কোনো condition নেই, সবসময় সবার শেষে দেখা হয়, আর মুছে ফেলা যায় না। কিছুই না মেলা traffic-এর কী হবে, সেটা ঠিক করে এর action: সাধারণত মূল একটা target group-এ forward, কখনো একটা fixed 404।

default-এ একটা ALB-এ ১০০টা rule রাখা যায় (default rule বাদে); দরকার হলে quota বাড়ানো যায়।

#Action

প্রতিটা rule শেষ হয় ঠিক একটা routing action দিয়ে, আর HTTPS rule-এ তার আগে একটা authentication action বসানো যায়।

কয়েকটা খুঁটিনাটি যেগুলো কাজে লাগে:

• weight দিয়ে ভাগ হয় ALB-এর ভেতরেই, তাই traffic সরাতে কয়েক সেকেন্ড লাগে, DNS cache শেষ হওয়ার অপেক্ষা নেই, weighted DNS record-এ যেটা থাকে।
• weight দেওয়া কোনো target group যদি খালি বা পুরোপুরি unhealthy হয়, ALB অন্যগুলোতে সরিয়ে নেয় না: ওই ভাগের request-গুলো ব্যর্থ হয়। তাই canary-র metric-এ নজর রাখো।
• canary চলার সময় একজন ইউজারকে একই version-এ রাখতে চাইলে forward action-এ target group stickiness চালু করো (cookie-র খুঁটিনাটি লেসন ৬.৪-এ)।
• ২০২৫ থেকে rule-এ transform-ও রাখা যায়, যেটা forward করার আগে host header বা URL বদলে লেখে। জেনে রাখা ভালো; পরীক্ষা এখনো ওপরের পুরনো action-গুলোই আশা করে।

#Application কী দেখে: X-Forwarded header

ALB client-এর connection নিজের কাছে শেষ করে নতুন একটা খোলে, তাই target-এর socket-এ দেখা যায় ALB-এর private IP, client-এরটা না। আসল তথ্যগুলো ALB পাঠায় তিনটা request header-এ:

log, কোন দেশ থেকে এল আর rate limit-এর জন্য X-Forwarded-For ব্যবহার করো, আর ঠিকঠাক link বানাতে বা HTTPS-এ redirect লাগবে কি না বুঝতে X-Forwarded-Proto। client নিজেও একটা বানানো X-Forwarded-For পাঠাতে পারে; ALB যে address আসলে দেখেছে সেটা জোড়ে একদম শেষে, তাই ডানদিকের শেষ entry-টাই বিশ্বাস করো।

#Microservice আর container

ALB আসার আগে প্রতিটা application-এর জন্য আলাদা একটা Classic Load Balancer লাগত। path আর host rule-সহ একটা ALB কয়েক ডজন service-এর সামনে বসতে পারে, প্রত্যেকে নিজের target group-এ, নিজের health check নিয়ে। এজন্যই পরীক্ষায় ALB-এর সাথে microservice আর container শব্দ দুটো জোড়া থাকে।

Amazon ECS-এ (EC2-এর ওপর container) bridge network mode-এ host port 0 দিলে Docker প্রতিটা task-কে একটা random উঁচু port দেয়, তাই একই container-এর কয়েকটা কপি একটা instance-এই চলতে পারে। ECS প্রতিটা task-কে target group-এ register করে instance আর ওই port মিলিয়ে, আর ALB নিজে থেকেই ঠিক port-এ traffic পাঠায়। এর নাম dynamic port mapping। একটা নিয়ম মনে রাখো: instance-এর security group-এ ALB-এর security group থেকে পুরো ephemeral port range খুলতে হবে, শুধু port 80 না, নইলে task-গুলো health check-এ fail করবে। আর awsvpc network mode-এ (Fargate-এ সবসময়) প্রতিটা task নিজের একটা network interface পায়, তখন register হয় IP address দিয়ে।

#স্থির DNS name, স্থির IP না

অনেক practice test-এ একটা প্রশ্ন আসে: “Application Load Balancer আর Classic Load Balancer-এর একটা static ____ থাকে: IPv4 address, IPv6 address, DNS name, নাকি Elastic IP?” উত্তর হলো DNS name।

ALB একটা মেশিন না। AWS প্রতিটা চালু AZ-এ load balancer node চালায়, আর traffic বাড়লে-কমলে সেগুলো যোগ করে, সরায় বা বদলে দেয়। প্রতিবার বদলের সাথে নতুন IP address আসতে পারে, তাই ALB বা CLB-এর IP স্থির থাকবে, এমন কথা AWS কখনো দেয় না। load balancer যতদিন আছে, ততদিন যেটা একই থাকে সেটা তার DNS name, যেটা সবসময় তখনকার node-গুলোর IP-তে resolve হয়।

• নিজের domain ব্যবহার করতে চাইলে load balancer-এর DNS name-এর দিকে একটা Route 53 Alias record বানাও। Alias zone apex-এ (example.com) কাজ করে, যেখানে CNAME দেওয়া যায় না, আর AWS resource-এর দিকে Alias query-র জন্য Route 53 টাকা নেয় না। www.example.com-এর মতো subdomain-এ CNAME-ও চলে, তবু Alias-ই ভালো।
• ALB-এর এখনকার IP কখনো A record-এ, client-এর configuration-এ বা partner-এর firewall-এ লিখে রেখো না। একদিন সেটা বদলাবেই।
• কোনো partner-এর যদি সত্যিই একটা HTTP application-এর জন্য স্থির IP লাগে, তাহলে ALB-এর সামনে একটা NLB বসাও, অথবা তার সামনে AWS Global Accelerator (দুটো static anycast IP)।

#Network Load Balancer (layer 4)

#সে কী করে

NLB এগিয়ে দেয় TCP, UDP আর TLS (সাথে একই port-এ TCP_UDP, আর ২০২৫-এর শেষ থেকে passthrough mode-এ QUIC)। সে কখনো HTTP পড়ে না, শুধু address আর port দেখে, flow-এর hash দিয়ে একটা target বেছে নিয়ে packet এগিয়ে দেয়। এজন্য সে:

• খুব দ্রুত: প্রতি সেকেন্ডে লাখ লাখ request, খুব কম latency, আর হঠাৎ চাপ এলেও আগে থেকে warm-up করাতে হয় না।
• যেকোনো protocol-এ চলে: database, IoT device-এর protocol, game server, VoIP, নিজেদের বানানো binary protocol।
• লম্বা connection-এ সমস্যা নেই: একটা TCP connection বা UDP flow পুরো সময় একটা target-এই থাকে।

নোটে চিরচেনা ভাগটা দেওয়া আছে। TCP সেই traffic-এর জন্য, যেটা পুরোপুরি আর ঠিক ক্রমে পৌঁছাতেই হবে: database, login, বেশিরভাগ web traffic। UDP সেই traffic-এর জন্য, যেখানে প্রতিটা packet-এর চেয়ে গতি বেশি জরুরি: live voice (VoIP), real-time video, আর multiplayer game-এর দ্রুত বদলাতে থাকা অবস্থা। অনেক game দুটোই ব্যবহার করে: চলাফেরার জন্য UDP, login, chat আর কেনাকাটার জন্য TCP।

#Static IP আর Elastic IP

NLB-এর প্রতিটা চালু AZ-এ একটা node থাকে, আর load balancer যতদিন আছে, প্রতিটা node ততদিন একটা IP address পায় যেটা বদলায় না।

• internet-facing NLB প্রতিটা subnet-এ তোমার নিজের Elastic IP নিতে পারে (বানানোর সময় ঠিক করতে হয়), তাই address-গুলো তোমার মালিকানায় থাকে, কাগজে লিখে রাখা যায়।
• internal NLB প্রতিটা subnet থেকে তোমার পছন্দের একটা private IP নিতে পারে।
• DNS name তখনও থাকে, আর সেটা এই স্থির IP-গুলোতেই resolve হয়।

প্রশ্নে যখনই “static IP”, “Elastic IP” বা “client তার firewall-এ load balancer-এর IP allowlist করবে” দেখবে, উত্তর এটাই।

#Client IP preservation

TCP বা UDP listener-এ NLB দ্বিতীয় কোনো connection খোলে না, তাই target client-এর আসল address দেখতে পায়। তবে default-টা নির্ভর করে target type আর protocol-এর ওপর:

উল্টো দিকটা হলো: client-এর IP থেকে গেলে target-এর security group-কে client-দের address allow করতে হবে (অথবা নিচে বলা NLB-এর security group-কে), শুধু VPC-র range না।

#Target আর health check

একটা NLB target group-এ থাকতে পারে:

• Instance (instance ID দিয়ে),
• IP address (private range, VPN বা Direct Connect দিয়ে on-premises, আর peered VPC-সহ),
• একটা Application Load Balancer (target type alb), যেটা ALB-কে static IP দেয় আর PrivateLink-এর পেছনে বসায়। ALB-কে একই VPC-তে থাকতে হবে, target group-এর protocol TCP, আর তার port ALB-এর কোনো listener-এর port-এর সাথে মিলতে হবে।

health check হয় TCP, HTTP বা HTTPS দিয়ে, কখনো UDP দিয়ে না। UDP service হলে instance-এ ছোট একটা TCP বা HTTP health endpoint চালাও। পারলে HTTP check-ই দাও: TCP check শুধু প্রমাণ করে port খোলা আছে, application ঠিকমতো কাজ করছে কি না তা না। ২০২৫-এর নভেম্বর থেকে NLB-এর forward action-ও ALB-এর মতো weighted target group নিতে পারে।

#Security group: ঐচ্ছিক, তবে বানানোর সময়েই ঠিক করতে হয়

২০২৩-এর আগস্ট থেকে NLB-এও ALB-এর মতো security group লাগানো যায়। এগুলো ঐচ্ছিক, তবে একটা ফাঁদ আছে: এগুলো যোগ করা যায় শুধু NLB বানানোর সময়। security group ছাড়া বানানো NLB-এ পরে আর কখনো দেওয়া যায় না; নতুন একটা NLB বানাতে হয়। আর অন্তত একটা দিয়ে বানালে পরে ইচ্ছামতো বদলানো যায়। NLB-এ security group থাকলে target-গুলো সেটাকেই source হিসেবে দিতে পারে, ঠিক লেসন ৬.২-এর ALB-এর কায়দায়। health check outbound rule মেনে চলে।

#PrivateLink endpoint service

কোনো service অন্য VPC বা অন্য AWS account-কে private-ভাবে দিতে চাইলে, peering ছাড়া আর internet ছাড়া, সেটাকে VPC endpoint service (AWS PrivateLink) হিসেবে প্রকাশ করতে হয়। service-এর দিকে সামনে একটা Network Load Balancer থাকতেই হয় (appliance-এর বেলায় Gateway Load Balancer)। ব্যবহারকারীরা নিজেদের VPC-তে একটা interface endpoint বানায়, আর সেটা দিয়ে তোমার NLB-এ পৌঁছায়। path rule-সহ HTTP application হলে NLB → ALB ব্যবহার করো।

#Gateway Load Balancer (layer 3)

#কেন এটা লাগে

অনেক কোম্পানির নিয়ম হলো প্রতিটা packet একটা firewall বা intrusion prevention product-এর ভেতর দিয়ে যেতেই হবে, যেটা তারা আগে থেকেই বিশ্বাস করে (Palo Alto Networks, Cisco, Fortinet, Check Point আরও অনেকে), AWS-এ virtual machine হিসেবে। হাতে হাতে এটা করা কঠিন: appliance-গুলোকে বড়-ছোট হতে হবে, নষ্ট একটাকে পাশ কাটাতে হবে, আর একটা কথোপকথনের দুই দিকের traffic-কেই একই appliance-এর ভেতর দিয়ে যেতে হবে।

Gateway Load Balancer দুটো কাজ একসাথে করে:

1. একটা transparent network gateway: ঢোকা আর বের হওয়ার একটাই পথ, যেটার ভেতর দিয়ে traffic route করা হয়। সে source বা destination address বদলায় না; application টেরই পায় না যে সে আছে।
2. appliance fleet-এর জন্য একটা load balancer: healthy appliance-দের মধ্যে flow ভাগ করে দেয়, আর প্রতিটা flow-কে একটা appliance-এ বেঁধে রাখে।

#Traffic কীভাবে চলে

1. route table traffic পাঠায় GWLB endpoint-এ

   GWLB appliance-গুলোর সাথে থাকে একটা security (provider) VPC-তে। প্রতিটা application VPC-তে তুমি একটা GWLB endpoint বানাও, মানে Gateway Load Balancer type-এর একটা PrivateLink endpoint, তার নিজের subnet-এ। route table একে next hop বানায়: internet gateway-এর edge route table app subnet-এর traffic পাঠায় endpoint-এ, আর app subnet-এর route table 0.0.0.0/0 পাঠায় endpoint-এ।

2. GENEVE দিয়ে একটা appliance-এ

   GWLB সব port-এর সব IP packet শোনে; বেছে নেওয়ার মতো কোনো listener protocol বা port নেই। flow-এর hash দিয়ে (default-এ 5-tuple, নয়তো 3-tuple বা 2-tuple) সে একটা appliance বেছে নেয়, আর আসল packet-টা না বদলে UDP port 6081-এ GENEVE-এর ভেতরে মুড়ে দেয়। appliance-এর security group-এ GWLB থেকে UDP 6081 খোলা থাকতে হবে, আর appliance-কে GENEVE বুঝতে হবে।

3. পরীক্ষা, তারপর একই পথে ফেরত

   appliance ভেতরের packet পরীক্ষা করে, তারপর হয় ফেলে দেয়, নয়তো GENEVE-এ মুড়ে GWLB-কে ফেরত দেয়। GWLB সেটা endpoint-এ ফেরত দেয়, আর routing সেটাকে আসল গন্তব্যে পৌঁছে দেয়। উত্তরও endpoint হয়ে আবার আসে, আর hash সেটাকে একই appliance-এ পাঠায়, তাই stateful inspection দুই দিকই দেখতে পায়।

আরও কিছু জানা দরকারি তথ্য:

• Target type: instance আর IP। Health check: TCP, HTTP বা HTTPS।
• GWLB-এর নিজের কোনো security group নেই, AWS WAF-ও নেই।
• cross-zone load balancing default-এ বন্ধ।
• GWLB 8,500 byte পর্যন্ত packet নেয়; GENEVE ৬৮ byte যোগ করে, তাই appliance-এর MTU অন্তত 8,568 হতে হবে। সে packet ভাঙে না (fragment করে না), Path MTU Discovery-ও সমর্থন করে না।
• অলস flow বন্ধ হয় TCP-তে ৩৫০ সেকেন্ড পরে (৬০ থেকে ৬,০০০-এর মধ্যে বদলানো যায়), অন্য protocol-এ ১২০ সেকেন্ড পরে।
• একটা appliance নষ্ট হলে নতুন flow যায় শুধু healthy appliance-এ। চলতে থাকা flow default-এ (no_rebalance) নষ্টটাতেই যেতে থাকে, আর timeout না হওয়া পর্যন্ত হারায়; target failover rebalance করলে সেগুলোও নতুন করে hash হয়, অথবা no_rebalance রেখে TCP reset চালু করো, যাতে client তাড়াতাড়ি নতুন করে যুক্ত হয়।
• Transit Gateway-র সাথে (appliance mode) একটা কেন্দ্রীয় inspection VPC-র একটা GWLB অনেকগুলো VPC-র traffic পরীক্ষা করতে পারে; সেই design আসবে networking chapter-এ।
• AWS Network Firewall হলো AWS-এর নিজের managed firewall। প্রশ্নে যদি third-party appliance-এর কথা না থাকে, শুধু inspection চায়, তাহলে Network Firewall সহজ উত্তর হতে পারে।

#Classic Load Balancer, এক লাইনে

CLB (লেসন ৬.২) সাধারণ TCP, SSL, HTTP আর HTTPS সামলায়, এর DNS name স্থির, target group নেই। AWS বলে ALB বা NLB-তে চলে যেতে; পরীক্ষায় এটা প্রায় সবসময় ভুল উত্তর, নয়তো “পুরনো পদ্ধতি”।

#Target group

target group হলো listener rule যে গন্তব্যগুলোতে traffic পাঠায় তাদের তালিকা, সাথে তাদের পরীক্ষা করার নিয়ম। load balancer traffic নেয় আর পথ ঠিক করে; target group বলে দেয় কে সেটা পাবে আর তারা healthy কি না। (নোটে বলা আছে load balancer “নিজে কোনো traffic প্রসেস করে না”; আরও ঠিক করে বললে, ALB প্রতিটা request ঠিকই প্রসেস করে route করে, কিন্তু আসল কাজটা করে group-এর target-গুলো।)

#Target group-এ কী কী ঠিক করো

যে নিয়মগুলো প্রশ্নে আসে:

• একটা target অনেকগুলো target group-এ থাকতে পারে, একই বা আলাদা port-এ। একটা instance tg-web-এ port 80-এ website চালাতে পারে, আবার tg-admin-এ 8080-এ একটা admin app।
• একটা target group একটাই load balancer-এর।
• Auto Scaling group তার সাথে জোড়া target group-এ নিজের instance-গুলো নিজেই register আর deregister করে (লেসন ৬.৫)।
• প্রতিটা target healthy না unhealthy, সেটা দেখা যায় EC2 console-এর Target groups পাতায়, instance-এর পাতায় না। একটা instance EC2-তে “running” আর target group-এ “unhealthy”, দুটোই একসাথে হতে পারে।

#কোন load balancer কোন target type নেয়

ECS task আলাদা কোনো type না: সেগুলো register হয় instance হিসেবে (bridge mode, dynamic port) বা ip হিসেবে (awsvpc mode, Fargate)।

#খরচ কত

এখনকার প্রজন্মের প্রতিটা load balancer-এর খরচ ঘণ্টার ভাড়া আর capacity unit। প্রতি ঘণ্টায় AWS কয়েকটা মাপ নেয়, আর বিল করে শুধু যেটা সবচেয়ে বেশি সেটার। লেখার সময়ের us-east-1-এর দাম:

প্রতিটা GWLB endpoint-এর বিল আলাদা, PrivateLink-এর হিসাবে: প্রতি AZ-এ ঘণ্টায় $0.01, সাথে প্রতি GB $0.0035।

হিসাব করে দেখি (ALB)। ব্যস্ত একটা ঘণ্টায় একটা ALB পেল সেকেন্ডে ৫০টা নতুন connection, ৯,০০০টা চালু connection, ২.৫ GB data প্রসেস, আর সেকেন্ডে ২০০টা request, যার প্রতিটা ১৫টা rule পার হয়।

• নতুন connection: 50 ÷ 25 = 2 LCU
• চালু connection: 9,000 ÷ 3,000 = 3 LCU
• প্রসেস করা byte: 2.5 ÷ 1 = 2.5 LCU
• rule evaluation: 200 × (15 − 10 ফ্রি) = সেকেন্ডে 1,000 ÷ 1,000 = 1 LCU

সবচেয়ে বেশি হলো 3 LCU। ওই ঘণ্টার খরচ $0.0225 + 3 × $0.008 = $0.0465। পুরো মাস (৭৩০ ঘণ্টা) এই হারে চললে: প্রায় $33.95।

#তুলনা আর বেছে নেওয়া

#কোথায় কী ভুল হয়

#System design-এ এগুলো কীভাবে আসে

• সাধারণ public web application: Route 53 Alias → ALB (AWS WAF, HTTPS, HTTP → HTTPS redirect-সহ) → প্রতি service-এ একটা Auto Scaling group। HTTP-র যেকোনো কিছুর জন্য এটাই আদর্শ design।
• container-এ microservice: একটা ALB, প্রতি service-এ একটা target group, path আর host rule, আর ECS task-গুলোকে dynamic port-এ বা IP দিয়ে register করে।
• gaming, IoT আর real-time media: UDP বা TCP listener আর Elastic IP-সহ NLB, সারা দুনিয়ার খেলোয়াড়দের জন্য অনেক সময় সাথে Global Accelerator।
• allowlist-ওয়ালা business-to-business API: Elastic IP-সহ NLB → routing আর WAF-এর জন্য ALB।
• অন্য AWS account-এর কাছে বিক্রি করা SaaS: PrivateLink endpoint service হিসেবে NLB; customer-রা নিজেদের VPC থেকে যুক্ত হয়, কিছুই public-এ খোলা থাকে না।
• hybrid migration: একটা ALB, যার কিছু target group AWS-এ আর একটা ip target group এখনো on-premises-এ থাকা server-এর দিকে; service সরার সাথে সাথে weight সরাও।
• নিয়মে বাঁধা traffic-এর inspection: কেন্দ্রীয় একটা security VPC-তে third-party firewall-এর fleet-সহ GWLB, আর প্রতিটা application VPC-তে GWLB endpoint আর route table।

#নিজে করে দেখো

# 1. ALB with path-based routing (two services and a default)
for TG in tg-users tg-search tg-web; do
  aws elbv2 create-target-group --name $TG --protocol HTTP --port 80 --vpc-id $VPC \
    --target-type instance --health-check-path /health
done
aws elbv2 register-targets --target-group-arn $TG_USERS --targets Id=i-0abc1234 Id=i-0def5678

ALB=$(aws elbv2 create-load-balancer --name web-alb --type application \
  --scheme internet-facing --subnets $SUBNET_A $SUBNET_B --security-groups $SG_ALB \
  --query "LoadBalancers[0].LoadBalancerArn" --output text)
LISTENER=$(aws elbv2 create-listener --load-balancer-arn $ALB --protocol HTTP --port 80 \
  --default-actions Type=forward,TargetGroupArn=$TG_WEB \
  --query "Listeners[0].ListenerArn" --output text)

aws elbv2 create-rule --listener-arn $LISTENER --priority 10 \
  --conditions Field=path-pattern,Values='/users*' \
  --actions Type=forward,TargetGroupArn=$TG_USERS
aws elbv2 create-rule --listener-arn $LISTENER --priority 20 \
  --conditions Field=host-header,Values=search.example.com \
  --actions Type=forward,TargetGroupArn=$TG_SEARCH
aws elbv2 describe-rules --listener-arn $LISTENER \
  --query "Rules[].[Priority,Conditions[0].Field,Actions[0].Type]" --output table

# 2. Canary: 90% to v1, 10% to v2 on the /users rule
aws elbv2 modify-rule --rule-arn $RULE_USERS --actions '[{"Type":"forward","ForwardConfig":{
  "TargetGroups":[{"TargetGroupArn":"'$TG_USERS'","Weight":90},
                  {"TargetGroupArn":"'$TG_BETA'","Weight":10}]}}]'

# 3. Fixed response for a blocked range
aws elbv2 create-rule --listener-arn $LISTENER --priority 5 \
  --conditions Field=source-ip,SourceIpConfig='{Values=["203.0.113.0/24"]}' \
  --actions Type=fixed-response,FixedResponseConfig='{StatusCode=403,ContentType=text/plain,MessageBody=blocked}'

# 4. On-premises server as an IP target (outside the VPC → AvailabilityZone=all)
aws elbv2 create-target-group --name tg-legacy --protocol HTTPS --port 443 \
  --target-type ip --vpc-id $VPC
aws elbv2 register-targets --target-group-arn $TG_LEGACY \
  --targets Id=10.20.0.15,AvailabilityZone=all

# 5. Internet-facing NLB with your own Elastic IPs and a security group (only possible now!)
NLB=$(aws elbv2 create-load-balancer --name game-nlb --type network \
  --subnet-mappings SubnetId=$SUBNET_A,AllocationId=$EIP_A SubnetId=$SUBNET_B,AllocationId=$EIP_B \
  --security-groups $SG_NLB --query "LoadBalancers[0].LoadBalancerArn" --output text)
aws elbv2 create-target-group --name tg-game --protocol UDP --port 7777 --vpc-id $VPC \
  --health-check-protocol HTTP --health-check-port 8080 --health-check-path /health
dig +short game-nlb-0123456789.elb.us-east-1.amazonaws.com    # always the same two IPs

# 6. NLB in front of the ALB (static IPs + path rules)
aws elbv2 create-target-group --name tg-alb --target-type alb --protocol TCP --port 80 --vpc-id $VPC
aws elbv2 register-targets --target-group-arn $TG_ALB --targets Id=$ALB

# 7. GWLB with an appliance fleet and an endpoint in the app VPC
GWLB=$(aws elbv2 create-load-balancer --name fw-gwlb --type gateway \
  --subnets $SEC_SUBNET_A $SEC_SUBNET_B --query "LoadBalancers[0].LoadBalancerArn" --output text)
aws elbv2 create-target-group --name tg-fw --protocol GENEVE --port 6081 --vpc-id $SEC_VPC \
  --health-check-protocol TCP --health-check-port 80
aws elbv2 create-listener --load-balancer-arn $GWLB --default-actions Type=forward,TargetGroupArn=$TG_FW
aws ec2 create-vpc-endpoint-service-configuration --gateway-load-balancer-arns $GWLB \
  --no-acceptance-required
aws ec2 create-vpc-endpoint --vpc-endpoint-type GatewayLoadBalancer --service-name $SVC_NAME \
  --vpc-id $APP_VPC --subnet-ids $ENDPOINT_SUBNET
aws ec2 create-route --route-table-id $APP_SUBNET_RT --destination-cidr-block 0.0.0.0/0 \
  --vpc-endpoint-id $GWLBE

# 8. Who is healthy, and why not?
aws elbv2 describe-target-health --target-group-arn $TG_USERS \
  --query "TargetHealthDescriptions[].[Target.Id,Target.Port,TargetHealth.State,TargetHealth.Reason]"

#সারসংক্ষেপ

মূল কথাগুলো

• ALB = layer 7 (HTTP, HTTPS, HTTP/2, gRPC, WebSockets)। NLB = layer 4 (TCP, UDP, TLS)। GWLB = layer 3 (সব IP packet, appliance-এ GENEVE)। CLB = পুরনো।
• ALB-এর listener rule: path (case-sensitive), host, header, method, query string, source IP দেখে condition; ছোট priority নম্বর জেতে; একটা rule-এর সব condition মিলতে হয়; বাকি সব ধরে default rule।
• ALB-এর action: forward (canary আর blue/green-এর জন্য পাঁচটা পর্যন্ত weighted target group), redirect (HTTP → HTTPS), fixed-response, Cognito বা OIDC দিয়ে authenticate।
• ALB-এর পেছনে app দেখে ALB-এর IP; client থাকে X-Forwarded-For-এ (সাথে X-Forwarded-Proto আর X-Forwarded-Port)।
• ALB আর CLB-এর DNS name স্থির, IP না: Route 53 Alias record দাও, IP কখনো না।
• microservice আর container-এ ALB মানায়: একটা ALB, অনেক target group, ECS dynamic port mapping (ALB-এর security group থেকে ephemeral range খোলো)।
• NLB: প্রতি সেকেন্ডে লাখ লাখ request, প্রতি AZ-এ একটা static IP (Elastic IP দেওয়া যায়), client-এর IP অক্ষত, target instance / IP / ALB, health check TCP/HTTP/HTTPS, security group শুধু বানানোর সময়, PrivateLink endpoint service-এর সামনে।
• GWLB: third-party firewall, IDS/IPS, DPI-র জন্য transparent gateway আর load balancer একসাথে; UDP 6081-এ GENEVE; GWLB endpoint আর দুই দিকের route table; নতুন flow-এর বেলায় নষ্ট appliance বাদ পড়ে।
• Target group: target type বানানোর সময়ই ঠিক; health check প্রতি group-এ; একটা target অনেক group-এ; IP target হতে হবে private (VPN/Direct Connect দিয়ে on-premises); Lambda শুধু ALB-এ।
• দাম = ঘণ্টার ভাড়া + capacity unit-এর সবচেয়ে বড় মাপ (LCU, NLCU, GLCU)।

নিজেকে যাচাই করো: ALB, NLB, GWLB আর target group৩০টি প্রশ্ন