Stickiness, Cross-Zone, TLS/SNI আর Deregistration Delay

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

• Sticky session (session affinity) কী সেটা বুঝিয়ে বলতে, ALB-তে duration-based আর application-based cookie সেট করতে, আর NLB, GWLB, CLB কীভাবে stickiness করে তা জানতে।
• Sticky server মারা গেলে user-এর cart কেন তবুও হারায় (session ID বনাম session data) সেটা ব্যাখ্যা করতে, আর ElastiCache বা DynamoDB দিয়ে আসল সমাধান করতে।
• Cross-zone load balancing চালু আর বন্ধ থাকলে প্রতিটা target কত ভাগ traffic পায় তা হিসাব করতে, আর প্রতিটা load balancer type-এর default আর খরচ জানতে।
• SSL বনাম TLS, certificate, public CA আর ACM বুঝিয়ে বলতে, আর TLS termination, re-encryption আর NLB passthrough-এর মধ্যে ঠিকটা বেছে নিতে।
• HTTPS listener সাজাতে: default certificate, certificate list আর security policy; আর SNI কীভাবে প্রতিটা domain-এর জন্য ঠিক certificate বাছে তা বোঝাতে।
• Scale-in, deployment আর লম্বা request-এর জন্য deregistration delay (connection draining) আর slow start ঠিক করতে।
• এই চারটা feature নিয়ে পরীক্ষার প্রতিটা প্রশ্নের ধরন চিনে ফেলতে।

#প্রতিটা load balancer-এ যে চারটা feature লাগেই

লেসন ৬.২ আর ৬.৩-এ আমরা load balancer বানিয়েছি: listener, rule, target group, health check। এই লেসনে চারটা setting, যেগুলো ঠিক করে আসল traffic এলে load balancer কেমন আচরণ করবে:

#Sticky session (session affinity)

#একজন user প্রতিবার আলাদা server-এ কেন গিয়ে পড়ে

Default-এ load balancer প্রতিটা request আলাদা করে route করে। ALB প্রতি request-এ round robin (বা least outstanding requests) চালায়, তাই একজন user-এর click-গুলো সব target-এ ছড়িয়ে যায়। সাধারণত এটাই চাই, যদি না application user-এর state একটা server-এর memory-তে রেখে দেয়: shopping cart, login session, অর্ধেক পূরণ করা form।

তখন প্রথম click গেল web-1-এ, সে shirt-টা নিজের RAM-এ রাখল; দ্বিতীয় click গেল web-2-তে, যে shirt-এর কথা জানেই না। User দেখে জিনিস একবার আসে, একবার উধাও হয়, বা বারবার login করতে বলে।

Sticky session (আরেক নাম session affinity) load balancer-কে দিয়ে একজন client-এর সব request কিছু সময়ের জন্য একই target-এ পাঠায়।

#ALB কীভাবে client-কে আটকে রাখে: cookie

ALB কোন target বেছেছিল, সেটা মনে রাখে browser-কে দেওয়া একটা cookie-তে। Stickiness চালু হয় target group ধরে, আর দুই ধরনের মধ্যে একটা বাছতে হয়:

আরও কয়েকটা জানার মতো জিনিস:

• Load balancer-এর cookie একটা ঘুরতে থাকা key দিয়ে encrypted। ভেতরে থাকে একটা target-এর দিকে ইশারা, কখনো user-এর data না, আর তুমি সেটা পড়তে বা বদলাতে পারো না।
• প্রতিটা request-এ ALB cookie-র মেয়াদ আবার নতুন করে দেয়, তাই সক্রিয় user আটকেই থাকে; duration-এর চেয়ে বেশি সময় চুপ থাকলে user নতুন target পায়।
• Cross-origin (CORS) request-এর জন্য ALB AWSALBCORS নামে আরেকটা cookie-ও বসায়, SameSite=None; Secure সহ, যাতে browser অন্য site থেকে আসা call-এও সেটা পাঠায়।
• সংরক্ষিত নাম: application-এর cookie-র নাম AWSALB, AWSALBAPP বা AWSALBTG দিয়ে শুরু হতে পারবে না। (AWSALBTG লাগে target group-এ আটকে রাখার জন্য, যখন একটা listener rule কয়েকটা weighted target group-এ traffic পাঠায়; এটা সেট হয় rule-এ, আর weighted forwarding লেসন ৬.৩-এ আছে।)
• Client-কে cookie নিতে হবে। যে client cookie ফেলে দেয়, সে প্রতিবার নতুন করে route হয়।
• Sticky target যদি unhealthy, deregister হচ্ছে বা নেই, ALB cookie-র কথা শোনে না, একটা healthy target বাছে আর cookie আপডেট করে দেয়। User তখন থেকে সেখানে আটকে যায়।
• WebSocket connection স্বভাবতই sticky: upgrade হওয়ার পর পুরো connection একটা target-এই থাকে।
• সীমাবদ্ধতা: target group-এ cross-zone বন্ধ থাকলে, weighted random routing algorithm-এ, বা weighted target group-এ application-based cookie দিলে stickiness চলে না।

#NLB, GWLB আর CLB-তে stickiness

Slide-এ লেখা stickiness “CLB, ALB আর NLB-তে চলে”, কথাটা ঠিক, তবে নিজের হাতে মেয়াদ ঠিক করা cookie আছে শুধু CLB আর ALB-তে। NLB-র কোনো cookie নেই, duration-ও নেই: সে client-এর IP-র hash করে।

#Session ID বনাম session data: server মারা গেলে cart কেন তবুও হারায়

প্রায় সবাই এই জায়গায় গুলিয়ে ফেলে: “Cookie তো user-এর browser-এ আছে, তাহলে server নষ্ট হলে cart হারাবে কেন?”

উত্তর: session ID আর session data দুটো আলাদা জিনিস, থাকে দুটো আলাদা জায়গায়।

1. Cookie-তে কী থাকে: শুধু session ID

   Load balancer browser-কে যে cookie দেয়, তাতে থাকে একটা টোকেন, মোটামুটি এমন: “এই user web-1-এর”। এতে shirt আর প্যান্ট থাকে না। এটা রেস্টুরেন্টের টোকেন, এর বেশি কিছু না।

2. Server-এ কী থাকে: session data

   আসল cart (২টা shirt, ১টা প্যান্ট) লেখা থাকে web-1-এর RAM-এ (বা তার local disk-এ)। Stickiness কাজ করে user-কে সেই একটাই জায়গায় ফেরত পাঠিয়ে, যেখানে data আছে।

3. স্বাভাবিক অবস্থা

   User shirt যোগ করল; web-1 সেটা RAM-এ রাখল; load balancer cookie দিল। User প্যান্ট যোগ করল; browser cookie দেখাল; load balancer request পাঠাল web-1-এ; web-1 memory-র shirt আর নতুন প্যান্ট মিলিয়ে cart আপডেট করল।

4. web-1 crash করল বা terminate হলো

   RAM মুছে গেল, সাথে cart-ও। পরের request-এ তখনো cookie যাচ্ছে, যাতে লেখা “web-1”। Load balancer দেখে web-1 মৃত, তাই বাধ্য হয়ে web-2 বাছে।

5. web-2 এই user-কে কখনো দেখেনি

   web-2 নিজের memory-তে খোঁজে, কিছু পায় না, আর উত্তর দেয়: “Your cart is empty।” Sticky session-এ session data একটা server-এর ভেতরে আটকা থাকে। Server মরলে data-ও মরে।

#আসল সমাধান: session data server-এর বাইরে রাখো

Cart যদি web-1-এর RAM-এ না রেখে একটা শেয়ার করা, বাইরের store-এ লেখা হয়, তাহলে কোন server মরল বা পরের request কোন server-এ গেল তাতে কিছু যায় আসে না। সব server একই data পড়ে।

এতে web tier হয়ে যায় stateless: server crash করুক, Auto Scaling terminate করুক, বা deployment-এ বদলানো হোক, traffic তবুও সমানভাবে ছড়ায়। State বাইরে চলে গেলে stickiness আর লাগেই না।

#Stickiness-এর অসুবিধা

• অসমান load। ব্যস্ত target-এ আটকে থাকা user-রা সেখানেই থেকে যায়। Scale-out-এর পর নতুন instance পায় শুধু নতুন user, পুরনোগুলো চাপেই থাকে। Duration যত লম্বা, তত খারাপ; ৭ দিনের cookie পুরো fleet-কে এক সপ্তাহ অসমান রেখে দিতে পারে।
• Session হারানো। ওপরে দেখলে: stickiness state বাঁচায় না, শুধু সমস্যাটা ঢেকে রাখে যতক্ষণ না কোনো target নষ্ট হয়, scale in হয় বা বদলানো হয়।
• NLB-তে NAT-এর গরম জায়গা: একটা অফিস বা একটা mobile operator-এর NAT এক IP থেকে হাজার user একটা target-এ পাঠায়।
• Feature কমে যায়: ALB-তে cross-zone বন্ধ থাকলে, weighted random routing-এ, বা NLB-র TLS listener-এ stickiness নেই।

#Cross-zone load balancing

#Traffic target পর্যন্ত কীভাবে যায়: DNS, node, target

Load balancer-এ একটা AZ চালু করলে ELB সেই AZ-এ একটা load balancer node বসায়। তারপর traffic যায় দুই ধাপে:

১. Client → node। Load balancer-এর DNS name resolve হয় তার node-গুলোর IP address-এ, প্রতিটা চালু AZ-এ একটা, ৬০ সেকেন্ডের TTL সহ। Client-রা এর মধ্যে থেকে বাছে, তাই অনেক client মিলিয়ে প্রতিটা node সমান ভাগ পায়: দুই AZ হলে ৫০/৫০, তিন AZ হলে তিন ভাগের এক ভাগ করে। প্রতিটা node-এর পেছনে কয়টা target আছে, DNS তা জানে না।

২. Node → target। প্রতিটা node একটা target বাছে। কোন কোন target থেকে বাছতে পারবে, সেটা ঠিক করে cross-zone load balancing:

• চালু: সব চালু AZ-এর প্রতিটা registered target।
• বন্ধ: শুধু নিজের AZ-এর target।

#হিসাব করে দেখি: এক AZ-এ ২টা, অন্যটায় ৮টা target

Note-এর উদাহরণ: AZ a-তে ২টা instance, AZ b-তে ৮টা। DNS প্রতিটা node-এ পাঠায় ৫০% traffic।

Cross-zone বন্ধ থাকলে AZ a-র দুটো instance-এর ওপর প্রচণ্ড চাপ, আর AZ b-র আটটা প্রায় বসে থাকে। চালু করলে load balancer AZ-এর সীমানা দেখে না, দশটার মধ্যে traffic সমান ভাগ করে দেয়।

সাধারণ নিয়মটা এমন, ধরো healthy target আছে এমন AZ kটা, এক AZ-এ target nটা, আর মোট target Nটা:

• বন্ধ: প্রতিটা target পায় (১ ÷ k) ÷ n।
• চালু: প্রতিটা target পায় ১ ÷ N।
• চালু থাকলে কতটা traffic AZ পার হয়: প্রতিটা node নিজের AZ-এর target-গুলোর ভাগটুকুই নিজের কাছে রাখে, গড়ে (k − ১) ÷ k ভাগ request অন্য AZ-এ যায়: দুই AZ-এ অর্ধেক, তিন AZ-এ তিন ভাগের দুই ভাগ। NLB বা GWLB ঠিক এই traffic-এর জন্যই inter-AZ data transfer-এর টাকা দেয়।

#প্রতিটা load balancer type-এর default আর খরচ

Note-এ দুটো জিনিস ঠিক করে নিতে হবে: NLB-র “এক্সট্রা চার্জ” feature-এর কোনো ফি না, বরং যে byte-গুলো AZ পার হয় তার সাধারণ inter-AZ data transfer খরচ; আর ALB-র cross-zone load balancer পর্যায়ে সবসময় চালু হলেও target group ধরে বন্ধ করা যায় (২০২২-এর শেষ থেকে)। Slide-এর table দুটো বিষয়েই হালনাগাদ।

#কখন বন্ধ রাখবে?

Traffic নিজের AZ-এ রাখার সত্যিকারের কিছু সুবিধা আছে, AWS নিজেই সেগুলো লিখে রেখেছে:

• NLB বা GWLB-তে inter-AZ data-র খরচ নেই।
• Zonal isolation: এক AZ-এর সমস্যা (একটা খারাপ deployment, আধা-নষ্ট কোনো জিনিস) অন্য AZ-এর target-এ ছড়ায় না।
• Latency একটু কম।

বদলে capacity-র হিসাবটা তোমাকে রাখতে হয়। Cross-zone বন্ধ থাকলে:

• প্রতিটা AZ-এ তার ভাগ সামলানোর মতো যথেষ্ট target থাকতে হবে, আর AZ-গুলোতে target-এর সংখ্যা কাছাকাছি হওয়া উচিত (AZ জুড়ে সমানভাবে ছড়ানো Auto Scaling group এটা নিজেই করে, লেসন ৬.৫);
• কোনো AZ-এর সব target unhealthy হলে load balancer ওই node-এর IP DNS থেকে সরিয়ে দেয় (DNS failover), আর বাকি AZ-গুলো সব traffic নেয়;
• Load balancer-এর পেছনের সব target group-এর একই AZ ব্যবহার করা উচিত: কোনো target group-এর জন্য target-হীন AZ unhealthy ধরা হয়, আর খালি AZ-এ ঢোকা request-এ ALB 503 দেয়;
• ALB target group-এ sticky session আর Lambda target চলে না।

প্রতিটা AZ-এ সমান capacity নিশ্চিত করতে না পারলে AWS-এর পরামর্শ: cross-zone চালুই রাখো।

#Load balancer-এ TLS

#SSL নাকি TLS?

SSL (Secure Sockets Layer) হলো web traffic encrypt করার আদি protocol। SSL-এর সব version-ই আজ ভাঙা আর বন্ধ। TLS (Transport Layer Security) তার আধুনিক উত্তরসূরি; এখনকার version TLS 1.2 আর TLS 1.3। আজকের প্রতিটা “HTTPS” padlock আসলে TLS, তবু অভ্যাসে মানুষ এখনো “SSL certificate” বলে, আর AWS-এর নিজের setting-এও ELBSecurityPolicy বা “SSL certificate”-এর মতো নাম রয়ে গেছে। পরীক্ষার প্রশ্নে “SSL” পড়লে “TLS” ধরে নাও।

Client আর load balancer-এর মাঝের encryption-কে বলে in-flight (বা in-transit) encryption। এতে পথের মাঝে কেউ traffic পড়তে বা বদলাতে পারে না।

#Certificate, public CA আর ACM

Load balancer নিজের পরিচয় প্রমাণ করে একটা X.509 certificate (TLS server certificate) দিয়ে। এতে থাকে কোন কোন domain name-এর জন্য এটা বৈধ, একটা public key, একটা মেয়াদ, আর একটা certificate authority (CA)-র সই। মিলিয়ে থাকা private key server-এর কাছে গোপন থাকে। Browser certificate বিশ্বাস করে তখনই, যখন user যা লিখেছে তার সাথে নাম মেলে, মেয়াদ শেষ হয়নি, আর browser-এর বিশ্বস্ত তালিকার কোনো CA সই করেছে।

• Public CA (Let’s Encrypt, GoDaddy, Comodo/Sectigo আরও অনেকে) এমন certificate দেয় যা browser বিশ্বাস করে। Certificate-এর মেয়াদ ফুরায়, তাই renew করতে হয়। পুরো industry মেয়াদ ছোট করছে: ১৫ মার্চ ২০২৬ থেকে public certificate সর্বোচ্চ ২০০ দিন বৈধ থাকতে পারে।
• AWS Certificate Manager (ACM) হলো AWS-এর পথ:
  • Integrated service-এ (ELB, CloudFront, API Gateway) ব্যবহার করলে public certificate ফ্রি।
  • Domain তোমার, এটা প্রমাণ করো DNS validation দিয়ে (একটা CNAME record, Route 53-এ নিজে থেকেই বানিয়ে দেয়) বা email দিয়ে।
  • DNS validation record যতদিন থাকে, ACM নিজের certificate নিজে থেকেই renew করে, আর load balancer-এ আবার বসিয়ে দেয়।
  • Private key কখনো AWS-এর বাইরে যায় না: সাধারণ ACM certificate download করা বা EC2 instance-এ বসানো যায় না।
  • Import করা certificate (বাইরের CA থেকে কিনে ACM-এ import) চলে, কিন্তু ACM সেটা renew করতে পারে না: মেয়াদ ফুরানোর আগে তোমাকেই renew করে আবার import করতে হয়। ACM EventBridge-এ expiry event পাঠায়, আর একটা AWS Config rule মেয়াদ ফুরিয়ে আসা certificate ধরিয়ে দিতে পারে।
  • ACM certificate Regional: ALB-র certificate থাকতে হবে ALB-র Region-এ; CloudFront-এর certificate থাকতে হবে us-east-1-এ।
  • Certificate IAM-এও upload করা যায় (পুরনো পথ, ACM নেই এমন Region-এ এখনো লাগে)।

পাশের কথা (২০২৫–২৬): ACM-এর public certificate এখন ১৯৮ দিনের মেয়াদে দেওয়া হয় (আগে ছিল ৩৯৫ দিন), আর মেয়াদ শেষের ৪৫ দিন আগে নিজে থেকেই renew হয়, তাই ACM-এর দেওয়া certificate ব্যবহার করলে তোমার কিছুই বদলায় না। ACM এখন exportable public certificate-ও দেয় (টাকা লাগে, প্রতি domain name-এ প্রায় $7), যার private key download করে EC2 বা নিজের data center-এর server-এ বসানো যায়। পরীক্ষা এখনো ধরে নেয়: “ACM certificate export করা যায় না; instance-এর নিজের certificate লাগলে import করো বা নিজে সামলাও”।

#কোথায় decrypt করবে: termination, re-encryption নাকি passthrough

• Re-encryption-এ target-এর নিজের certificate লাগে, কিন্তু ALB target-এর certificate যাচাই করে না, তাই self-signed হলেও চলে।
• Termination-এর পর ALB X-Forwarded-Proto: https (আর client-এর IP সহ X-Forwarded-For) জুড়ে দেয়, যাতে application বোঝে user কীভাবে connect করেছিল।
• Passthrough ছাড়াই ALB client-এর সাথে mutual TLS (mTLS) করতে পারে, একটা trust store দিয়ে client certificate যাচাই করে।

#HTTPS listener: default certificate, certificate list, security policy

ALB-র HTTPS listener-এ (বা NLB-র TLS listener-এ) TLS-এর তিনটা setting থাকে:

আজকের security policy default:

• Console থেকে বানানো listener পায় ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09: শুধু TLS 1.3 আর 1.2, বাছাই করা শক্ত cipher, আর post-quantum key exchange।
• CLI, CloudFormation বা CDK দিয়ে policy না বলে বানালে পায় পুরনো ELBSecurityPolicy-2016-08, যেটা এখনো TLS 1.0 আর 1.1 মেনে নেয়। তাই template-এ আধুনিক policy-র নাম স্পষ্ট করে লিখো।
• শুধু TLS 1.0 বোঝে এমন পুরনো device-কে যদি connect করতেই হয়, TLS 1.0 আছে এমন policy লাগাও। Slide-এর “পুরনো SSL/TLS version চালানোর জন্য security policy” কথাটার মানে এটাই।

#Classic Load Balancer: একটাই certificate

CLB (v1) প্রতি listener-এ একটা certificate নেয়, SNI নেই। CLB-তে আলাদা certificate দিয়ে কয়েকটা domain চালাতে হলে লাগে প্রতি domain-এ একটা CLB (বা এমন একটা certificate যার Subject Alternative Name-এ সব নাম আছে)। ALB আর NLB (v2) এক listener-এ অনেক certificate নেয়, SNI দিয়ে।

#SNI (Server Name Indication)

#SNI কোন সমস্যার সমাধান

ধরো একটা load balancer চালাচ্ছে www.cats.com আর **www.dogs.com**। TLS handshake হয় কোনো HTTP পাঠানোর আগে, তাই connection আসার সময় server তখনো Host header পড়তে পারে না। User কোন site চায় সে জানে না, তাই কোন certificate দেখাবে তাও জানে না। SNI-এর আগে সে সবসময় একটাই দেখাত: dogs.com-এর visitor পেত cats.com-এর certificate, আর browser লাল রঙে “Not secure” warning দেখাত।

পুরনো সমাধান ছিল প্রতিটা HTTPS site-এর জন্য একটা করে IP address, মানে প্রতি site-এ একটা করে load balancer। খরচের ব্যাপার, আর IPv4 address-ও কম।

#SNI কীভাবে কাজ করে

SNI হলো TLS-এর একটা extension। Handshake-এর একদম প্রথম message, ClientHello-তে browser খোলাখুলি লিখে দেয় সে কোন hostname চায়: “আমি www.dogs.com-এর জন্য এসেছি”। Server সেটা পড়ে মিলে যাওয়া certificate দিয়ে উত্তর দেয়।

ALB-তে বাছাইটা চলে এভাবে:

১. Client SNI দিয়ে একটা hostname পাঠায়।

২. List-এ ঠিক একটা certificate যদি মেলে (common name বা Subject Alternative Name দিয়ে, wildcard সহ), ALB সেটাই নেয়।

৩. কয়েকটা মিললে ALB সেগুলোর মধ্যে client যেটা সবচেয়ে ভালো সামলাতে পারে সেটা বাছে (RSA-র আগে elliptic-curve key, তারপর মেয়াদ না-ফুরানো, শক্ত hash, লম্বা key)।

৪. Client SNI না পাঠালে বা কিছুই না মিললে ALB দেয় default certificate, যার মানে সাধারণত client-এর কাছে name mismatch error।

SNI শুধু certificate বাছে। Request কোন target group-এ যাবে, সেটা decrypt হওয়ার পর listener rule (সাধারণত একটা host-header rule) ঠিক করে।

#কারা SNI সমর্থন করে

• ALB: হ্যাঁ, প্রতি HTTPS listener-এ অনেক certificate।
• NLB: হ্যাঁ, প্রতি TLS listener-এ অনেক certificate।
• CloudFront: হ্যাঁ (SNI এর default আর ফ্রি; প্রতি distribution-এ আলাদা IP নিলে বাড়তি টাকা)।
• CLB: না, প্রতি listener-এ একটা certificate।

গত ১৫ বছরে বানানো প্রায় প্রতিটা client-ই SNI পাঠায়। যারা পাঠায় না, তারা খুব পুরনো browser আর operating system, পুরনো Java আর Python library, আর কিছু embedded device।

আরেকটা কথা: SNI-এর hostname খোলা অবস্থায় যায়, তাই network-এ যে নজর রাখছে সে দেখতে পায় তুমি কোন site-এ যাচ্ছ, যদিও সেখানে কী করছ তা না। নতুন Encrypted Client Hello extension এটা লুকায়, তবে এখনো খুব প্রচলিত না, আর পরীক্ষায়ও নেই।

#Deregistration delay (connection draining)

#একটা target সরানোর সময় কী হয়

Target group থেকে একটা target চলে যায় যখন Auto Scaling scale in করে, যখন deployment সেটা বদলায়, বা যখন তুমি নিজে deregister করো। Load balancer সেটাকে সাথে সাথে লাথি মেরে বের করে দেয় না:

1. Draining শুরু

   Target draining অবস্থায় যায়। Load balancer তাকে নতুন request পাঠানো বন্ধ করে; সব নতুন request যায় অন্য target-গুলোতে।

2. চলমান request শেষ হয়

   যে request-গুলো target-এ আগে থেকেই চলছিল, সেগুলোকে শেষ করতে দেওয়া হয়, সর্বোচ্চ deregistration delay পর্যন্ত।

3. শেষ

   Target-এ যখন চলমান কোনো request বা খোলা connection থাকে না, ALB পুরো delay অপেক্ষা না করে আগেই deregistration শেষ করে দেয়। না হলে delay ফুরালে target হয় unused, আর তখনো খোলা connection বন্ধ করে দেওয়া হয় (client পায় 5xx error)। Target যদি Auto Scaling group-এর হয়, Auto Scaling instance terminate করার আগে এটার জন্য অপেক্ষা করে।

NLB-র বাড়তি কথা: QUIC traffic-এ সবসময় ৩০০ সেকেন্ড; deregistration_delay.connection_termination.enabled attribute delay শেষে বাকি connection বন্ধ করে দেয় (না হলে অলস কিন্তু খোলা TCP connection traffic পেতেই থাকতে পারে); NLB-তে AWS অন্তত ১২০ সেকেন্ড দিতে বলে।

#মানটা কত দেবে

• ছোট request (millisecond-এ উত্তর দেওয়া API): ৩০ সেকেন্ডের মতো কম মানই যথেষ্ট। লম্বা delay শুধু scale-in আর deployment ধীর করে।
• লম্বা request (upload, report, video processing): delay দাও সবচেয়ে লম্বা request-এর চেয়ে বেশি, নইলে শেষটুকু কেটে যায়।
• অনেকক্ষণ খোলা থাকা connection (WebSocket, long polling, কখনো অলস না হওয়া HTTP keep-alive): এগুলো কখনো “শেষ” হয় না, তাই drain সবসময় পুরো delay পর্যন্ত চলে। App-কে এমন বানাও যাতে থামতে বলা হলে (SIGTERM পেলে) connection বন্ধ করে দেয়, তখন client অন্য জায়গায় আবার connect করে।
• ০ মানে কোনো draining নেই: চলমান request হারিয়ে যায়। শুধু test-এ বা সাথে সাথে আবার চেষ্টা করা যায় এমন stateless traffic-এ এটা দাও।

#Slow start mode (ALB)

Draining বাঁচায় চলে যাওয়া target-কে। Slow start বাঁচায় নতুন আসা target-কে। ঠান্ডা cache বা এখনো গরম না হওয়া runtime-এর নতুন instance health check পাস করামাত্র পুরো ভাগ পেলে ভেঙে পড়তে পারে।

• Slow start চালু থাকলে নতুন healthy target-এর ভাগ slow start duration ধরে সমান হারে বাড়ে: ৩০ থেকে ৯০০ সেকেন্ড (default ০, মানে বন্ধ)।
• এটা ALB target group-এর setting, আর চলে শুধু round robin algorithm-এ, least outstanding requests বা weighted random-এ না।
• Slow start চালু করার সময় যে target আগে থেকেই ছিল সে slow start-এ ঢোকে না, আর নতুন register হওয়া target তখনই ঢোকে যখন অন্তত আরেকটা healthy target slow start-এর বাইরে আছে।

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

• আগে stateless web tier। Session রাখো ElastiCache বা DynamoDB-তে, ফাইল S3 বা EFS-এ। তাহলে stickiness লাগে না, scale-in নিরাপদ, আর যেকোনো target যেকোনো request সামলাতে পারে। Stickiness রাখো শুধু বদলানো যায় না এমন legacy application-এর জন্য, ছোট duration দিয়ে।
• ALB-তে cross-zone চালুই রাখো। NLB-তে চালু করো যখন AZ জুড়ে target অসমান, বা inter-AZ data-র বিলের চেয়ে সমান load বেশি জরুরি; বন্ধ রাখো যখন zonal isolation চাও আর Auto Scaling দিয়ে target সমানভাবে ছড়িয়ে রাখো।
• Default হিসেবে ACM certificate দিয়ে load balancer-এ TLS terminate করো; compliance প্রতিটা hop-এ encryption চাইলে HTTPS target group যোগ করো; NLB passthrough নাও শুধু তখন, যখন load balancer-কে কখনোই decrypt করতে দেওয়া যাবে না। আধুনিক security policy নাও, আর সব domain একটা listener-এ SNI দিয়ে রাখো।
• Draining-কে request-এর দৈর্ঘ্যের সাথে মেলাও: API-তে ৩০ সেকেন্ড, upload service-এ সবচেয়ে লম্বা upload-এর চেয়ে বেশি, আর গরম হতে সময় লাগা instance-এর জন্য slow start যোগ করো।
• Metric-এ চোখ রাখো: target ধরে RequestCount (stickiness বা cross-zone থেকে অসমতা), HTTPCode_ELB_5XX_Count (draining খুব ছোট, খালি AZ), আর import করা certificate-এর ACM expiry।

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

# Variables: your target group, listener and load balancer
TG=arn:aws:elasticloadbalancing:us-east-1:111122223333:targetgroup/web/0123456789abcdef
LISTENER=arn:aws:elasticloadbalancing:us-east-1:111122223333:listener/app/web-alb/50dc6c495c0c9188/f2f7dc8efc522ab2
NLB=arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/net/tcp-nlb/1234567890abcdef

# 1. Duration-based stickiness for one hour
aws elbv2 modify-target-group-attributes --target-group-arn $TG --attributes \
  Key=stickiness.enabled,Value=true Key=stickiness.type,Value=lb_cookie \
  Key=stickiness.lb_cookie.duration_seconds,Value=3600

#    ...or application-based stickiness that follows the app's app_session cookie
aws elbv2 modify-target-group-attributes --target-group-arn $TG --attributes \
  Key=stickiness.enabled,Value=true Key=stickiness.type,Value=app_cookie \
  Key=stickiness.app_cookie.cookie_name,Value=app_session \
  Key=stickiness.app_cookie.duration_seconds,Value=86400

# 2. See the cookie: the response carries AWSALB and AWSALBCORS
curl -sI https://www.shop.example/ | grep -i set-cookie

# 3. Cross-zone: turn it on for an NLB (inter-AZ data charges apply)...
aws elbv2 modify-load-balancer-attributes --load-balancer-arn $NLB \
  --attributes Key=load_balancing.cross_zone.enabled,Value=true
#    ...or turn it off for one ALB target group
aws elbv2 modify-target-group-attributes --target-group-arn $TG \
  --attributes Key=load_balancing.cross_zone.enabled,Value=false

# 4. A free ACM certificate with DNS validation
aws acm request-certificate --domain-name www.dogs.example \
  --subject-alternative-names dogs.example --validation-method DNS
aws acm describe-certificate --certificate-arn $CERT \
  --query "Certificate.[Status,RenewalEligibility,NotAfter]"

# 5. HTTPS listener: default certificate + modern security policy, then SNI certificates
aws elbv2 modify-listener --listener-arn $LISTENER \
  --certificates CertificateArn=$CATS_CERT \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09
aws elbv2 add-listener-certificates --listener-arn $LISTENER \
  --certificates CertificateArn=$DOGS_CERT
aws elbv2 describe-listener-certificates --listener-arn $LISTENER

# 6. Watch SNI choose the certificate (and the default one when SNI is missing)
openssl s_client -connect web-alb-123456.us-east-1.elb.amazonaws.com:443 \
  -servername www.dogs.example </dev/null 2>/dev/null | openssl x509 -noout -subject
openssl s_client -connect web-alb-123456.us-east-1.elb.amazonaws.com:443 \
  -noservername </dev/null 2>/dev/null | openssl x509 -noout -subject

# 7. Draining: 30 s for a short-request API, and slow start of 2 minutes
aws elbv2 modify-target-group-attributes --target-group-arn $TG --attributes \
  Key=deregistration_delay.timeout_seconds,Value=30 \
  Key=slow_start.duration_seconds,Value=120

# 8. Deregister a target and watch it drain
aws elbv2 deregister-targets --target-group-arn $TG --targets Id=i-0abc1234def567890
aws elbv2 describe-target-health --target-group-arn $TG \
  --query "TargetHealthDescriptions[].[Target.Id,TargetHealth.State]"   # draining → unused

#সারসংক্ষেপ

মূল কথাগুলো

• Sticky session একজন client-কে একই target-এ পাঠায়। ALB: duration-based cookie AWSALB বা application-based (তোমার cookie + AWSALBAPP), target group ধরে, duration ১ সেকেন্ড থেকে ৭ দিন, default ১ দিন; AWSALB, AWSALBAPP, AWSALBTG দিয়ে শুরু হওয়া নাম সংরক্ষিত। CLB: AWSELB। NLB: source IP, cookie নেই। GWLB: flow hashing।
• Cookie-তে থাকে শুধু session ID; session data থাকে server-এর RAM-এ। ওই server মরলে cart-ও মরে। আসল সমাধান বাইরের session store, ElastiCache বা DynamoDB, যাতে tier stateless হয় আর stickiness লাগে না।
• Stickiness ভারসাম্য নষ্ট করে (লম্বা duration আর NAT-এ আরও বেশি), আর ALB-তে cross-zone বন্ধ থাকলে বা weighted random routing-এ চলে না।
• Cross-zone: DNS node-গুলোর মধ্যে traffic সমান ভাগ করে; cross-zone বন্ধ থাকলে প্রতিটা node শুধু নিজের AZ-এর target নেয় (২ + ৮ target → ২৫% বনাম ৬.২৫%), চালু থাকলে প্রতিটা target সমান ভাগ পায় (প্রত্যেকে ১০%)।
• ALB: load balancer পর্যায়ে সবসময় চালু, ফ্রি, target group ধরে বন্ধ করা যায়। NLB / GWLB: default-এ বন্ধ, চালু করলে inter-AZ data-র খরচ। CLB: console-এ চালু, API/CLI-তে বন্ধ, ফ্রি।
• TLS SSL-এর জায়গা নিয়েছে; certificate আসে public CA বা ACM থেকে (ফ্রি public certificate, নিজে থেকে renew, private key AWS-এই থাকে; import করা certificate renew হয় না; CloudFront-এর জন্য us-east-1)।
• Load balancer-এ termination CPU বাঁচায়; re-encryption (HTTPS target group) প্রতিটা hop encrypted রাখে; NLB TCP passthrough decrypt-এর কাজ target-কে দেয়।
• HTTPS listener-এ থাকে একটা default certificate, ঐচ্ছিক certificate list (default-এ প্রতি ALB-তে ২৫টা) আর একটা security policy (TLS version আর cipher; পুরনো client-এর জন্য পুরনো policy)।
• SNI: client ClientHello-তে hostname লিখে দেয়, load balancer মিলে যাওয়া certificate বাছে। ALB, NLB আর CloudFront পারে; CLB পারে না (একটা certificate)। SNI নেই বা মেলেনি → default certificate।
• Deregistration delay (CLB: connection draining): default ৩০০ সেকেন্ড, ০–৩৬০০ সেকেন্ড, target group ধরে। Draining target নতুন request পায় না, চলমানগুলো শেষ হয়। Scale-in-এ request হারালে বাড়াও; ছোট request আর দ্রুত deployment-এর জন্য কমাও। Slow start (৩০–৯০০ সেকেন্ড) নতুন ALB target-কে ধীরে ধীরে পুরো ভাগে তোলে।

নিজেকে যাচাই করো: stickiness, cross-zone, TLS/SNI আর draining৩০টি প্রশ্ন