Routing Policy

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

• Route 53-এ “routing” মানে আসলে কী, সেটা বোঝাতে: DNS উত্তরে কোন record যাবে সেটা বাছাই করা, traffic বয়ে নেওয়া কখনোই না।
• আটটা routing policy-র প্রত্যেকটা কীভাবে সিদ্ধান্ত নেয়, health check নিয়ে কী করে, আর তার সীমা কী, সেটা বলতে: simple, weighted, latency, failover, geolocation, geoproximity, IP-based আর multi-value answer।
• Weighted-এর ভাগ আর geoproximity-র bias সহ দূরত্ব হিসাব করতে, আর কোনো endpoint নষ্ট হলে কে কোন উত্তর পাবে আগেই বলে দিতে।
• Latency, geolocation আর geoproximity আলাদা করে চিনতে, আর কেন একজন user তবুও “ভুল” জায়গায় যেতে পারে (resolver-এর অবস্থান, EDNS Client Subnet, caching) সেটা ব্যাখ্যা করতে।
• Alias record বা Traffic Flow দিয়ে একাধিক policy জুড়ে tree বানাতে, আর একটা policy record-এর দাম কত সেটা জানতে।
• পরীক্ষার প্রতিটা keyword-কে ঠিক policy-র সাথে মেলাতে: blue/green, active-passive DR, lowest latency, EU compliance, bias, load balancer ছাড়া একাধিক সুস্থ IP।

#Route 53-এ “routing” মানে কী

#Route 53 প্রশ্নের উত্তর দেয়; traffic বয় না

এখানে routing শব্দটা একটু বিভ্রান্তিকর। Load balancer traffic route করে: প্রতিটা request তার ভেতর দিয়ে যায়। Route 53 কিন্তু তোমার user-দের traffic কখনো দেখেই না। সে শুধু DNS-এর প্রশ্নের উত্তর দেয়, যেমন “www.example.com-এর address কী?”। Client উত্তর পেয়ে গেলে সরাসরি ওই address-এ connect করে, আর cache করা উত্তরের মেয়াদ (TTL, লেসন ৮.১) না ফুরানো পর্যন্ত Route 53-এর আর কোনো ভূমিকাই থাকে না।

তাই routing policy আসলে ঠিক করে, একটা নির্দিষ্ট query-র উত্তরে Route 53 কোন record, বা কোন value-গুলো রাখবে। একই নামের জন্য একই মুহূর্তে আলাদা আলাদা user আলাদা উত্তর পেতে পারে, policy যেমন বলে।

Browser থেকে resolver হয়ে authoritative name server পর্যন্ত একটা lookup কীভাবে যায়, সেটা ঝালিয়ে নিতে চাইলে System Design-এর DNS লেসনটা পড়ে নাও। ওই লেসন যেখানে শেষ, এই লেসন সেখান থেকে শুরু: authoritative server-এ, যেটা তোমার zone-এর জন্য হলো Route 53।

#Record-এর group, Record ID আর health check

Simple routing ছাড়া বাকি সব policy কাজ করে একই নাম আর একই type-এর একদল record নিয়ে, যেমন www.example.com-এর তিনটা A record। Group-এর প্রতিটা record-এ থাকে:

• routing policy আর তার setting (একটা weight, একটা Region, একটা location, primary না secondary…);
• একটা Record ID (console-এ এই নাম; API-তে বলে set identifier), যেটা দিয়ে record-গুলোকে আলাদা করে চেনা যায়;
• চাইলে একটা health check, আর alias record হলে Evaluate target health।

এক group-এর সব record-কে একই policy মানতে হয়: একই নাম আর type-এর জন্য একটা weighted আর একটা latency record মেশানো যায় না। আলাদা আলাদা নামে আলাদা policy চলে, আর policy দিয়ে tree-ও বানানো যায় (এই লেসনের পরের দিকে)।

Health check কীভাবে কাজ করে (কে check করে, কত ঘন ঘন, ১৮%-এর নিয়ম, private resource কীভাবে check হয়), সেটা লেসন ৮.৪-এর বিষয়। আপাতত তিনটা নিয়ম মনে রাখো, যেগুলো সব policy-তে খাটে:

1. Route 53 endpoint-গুলো সারাক্ষণ পেছনে বসে check করে, query আসার মুহূর্তে না।
2. যে record-এ health check নেই, তাকে সবসময় সুস্থ ধরা হয়।
3. Group-এর সব record অসুস্থ হলে Route 53 সবগুলোকেই সুস্থ ধরে উত্তর দেয় (“fail open”), কারণ হয়তো-কাজ-করবে এমন একটা উত্তর কোনো উত্তর না থাকার চেয়ে ভালো।

#এক নজরে আটটা policy

#Simple routing

Simple হলো সাধারণ DNS, Route 53-এর বাড়তি কোনো বুদ্ধি নেই। একটা নাম আর type-এর জন্য তুমি একটাই record বানাও; একই নাম আর type-এর দ্বিতীয় simple record বানানো যায় না।

• Record-এ থাকতে পারে একটা value (সাধারণত তাই: একটা web server, একটা Elastic IP), অথবা কয়েকটা value, যেমন তিনটা IP address।
• কয়েকটা value থাকলে Route 53 প্রতিবার সবগুলোই, এলোমেলো ক্রমে ফেরত দেয়। সে নিজে একটা বেছে দেয় না। Client (তার resolver library বা browser) এর মধ্যে একটা নেয়, সাধারণত প্রথমটা, তাই traffic মোটামুটি এলোমেলোভাবে ছড়িয়ে যায়।
• কোনো health check নেই। মরা server-এর address-ও দিব্যি বিলি হতে থাকে।
• Simple alias record দেখাতে পারে মাত্র একটা AWS resource (একটা load balancer, একটা CloudFront distribution), অথবা একই zone-এর অন্য একটা record (লেসন ৮.২)।

একটা resource-এর জন্য simple routing একদম ঠিক, আর এমন কিছুর জন্যও, যার পেছনে নিজস্ব load balancer আছে এবং সে নিজেই health সামলায়। কয়েকটা address আর health check, দুটোই লাগলে ব্যবহার করো multi-value answer; লেসনের শেষ দিকে simple-এর পাশাপাশি সেটা দেখবে।

#Weighted routing

#সূত্রটা

Weighted routing প্রতিটা record-এ উত্তরের একটা ঠিক করা ভাগ পাঠায়। প্রতিটা record পায় একটা weight, ০ থেকে ২৫৫-এর মধ্যে একটা পূর্ণসংখ্যা, আর Route 53 এলোমেলোভাবে একটা record বাছে এই সম্ভাবনায়:

একটা record-এর ভাগ = তার weight ÷ group-এর সব record-এর weight-এর যোগফল

• Weight হলো আপেক্ষিক, যোগফল ১০০ হতেই হবে না। ৭০, ২০, ১০ দিলে ৭০%, ২০%, ১০%; ৩, ১, ১ দিলে ৬০%, ২০%, ২০%; ১ আর ২৫৫ দিলে ১/২৫৬ আর ২৫৫/২৫৬।
• Weight ০ দিলে ওই record আর উত্তরে আসে না, অথচ record-টা পরের জন্য রয়ে যায়।
• সব weight ০ হলে Route 53 চুপ হয়ে যায় না; প্রতিটা record সমান সম্ভাবনায় ফেরত দেয়।
• Group-এর সব record-এর নাম আর type এক হতে হবে, আর প্রত্যেকের আলাদা Record ID লাগবে। TTL-ও এক রাখা উচিত (console-এ আলাদা TTL দিলে Route 53 শেষেরটাই সবার ওপর বসিয়ে দেয়)।

#Weight আর health check

Group-এর প্রতিটা record-এ health check লাগাও। তাহলে:

• অসুস্থ record বাদ পড়ে, আর তার ভাগ সুস্থ record-গুলোর মধ্যে তাদের weight-এর অনুপাতে ভাগ হয়ে যায়। ৭০/২০/১০-এর মধ্যে ২০ অসুস্থ হলে ভাগ দাঁড়ায় ৭০/৮০ = ৮৭.৫% আর ১০/৮০ = ১২.৫%।
• Route 53 প্রথমে দেখে শুধু non-zero weight-এর record। সব non-zero record অসুস্থ হলে তবেই সে সুস্থ একটা weight ০ record দিয়ে উত্তর দেয়। তাই weight ০ record মরা জিনিস না, চুপচাপ বসে থাকা একটা standby: সেটাকে এমন কিছুর দিকে রাখো যা কাজ করে।
• সবকিছু অসুস্থ হলে Route 53 সব record-কে সুস্থ ধরে, আর weight যেমন দেওয়া তেমনই খাটায়।

#Weighted routing কোথায় কাজে লাগে

• Blue/green deployment: পুরনো (blue) আর নতুন (green) stack পাশাপাশি চালাও; weight সরাও ১০০/০ → ৯০/১০ → ০/১০০; গোলমাল হলে আবার আগের মতো করে দিলেই rollback।
• Canary release আর A/B testing: উত্তরের ১–১০% নতুন version-এ পাঠাও, তারপর error rate বা conversion তুলনা করো।
• Load ভাগ করা: কয়েকটা Region বা account-এর মধ্যে নির্দিষ্ট অনুপাতে, যেমন বড় fleet-এর দিকে ২:১।

মনে রেখো, ভাগটা হয় প্রতি DNS উত্তরে: যে resolver green-এর উত্তর cache করল, সে TTL জুড়ে তার সব user-কে green-এই পাঠায়। TTL ৬০ সেকেন্ড আর resolver অনেক হলে আসল ভাগ weight-এর কাছাকাছিই আসে; একটা বড় অফিসের একটাই resolver হলে ভাগটা এলোমেলো হতে পারে।

#Latency-based routing

#দূরত্ব না, সবচেয়ে কম latency

যে যে Region-এ application চালাচ্ছ, প্রতিটা Region-এর জন্য একটা latency record বানাও (একটা নাম আর type-এর জন্য এক Region-এ একটার বেশি latency record Route 53 নেয় না)। Query এলে Route 53 দেখে সময় ধরে মাপা latency-র হিসাব: user-দের network থেকে AWS Region পর্যন্ত, তারপর যে Region এই user-কে সবচেয়ে কম latency দেয়, তার record দিয়ে উত্তর দেয়।

• ব্যাপারটা network-এর পথ নিয়ে, মানচিত্র নিয়ে না। সমুদ্রের নিচের cable আর peering-এর কারণে দূরের Region-ও দ্রুত হতে পারে। ঢাকার একজন user হয়তো Mumbai না পেয়ে Singapore পাবে।
• সে বাছে শুধু তুমি যে Region-গুলোর record বানিয়েছ তাদের মধ্য থেকে। তুমি যদি শুধু us-east-1 আর ap-southeast-1 থেকে চালাও, জার্মানির একজন user যাবে US-এ, কারণ Singapore-এর চেয়ে Atlantic পার হওয়া দ্রুত। এটা কোনো bug না।
• Internet বদলালে মাপও বদলায়, তাই এই সপ্তাহে যে Singapore-এ গেল, পরের সপ্তাহে সে Mumbai-তে যেতে পারে।
• হিসাবটা AWS Region-এর। Endpoint যদি তোমার নিজের data centre-এ থাকে, আসল latency অনেক আলাদা হতে পারে, এমনকি সেটা কোনো Region-এর একই শহরে হলেও।

#Health check থাকলে নিজেই failover করে

Health check লাগাও (অথবা load balancer-এর দিকে alias record আর Evaluate target health)। সবচেয়ে কম latency-র Region অসুস্থ হলে Route 53 উত্তর দেয় তার পরের সবচেয়ে কম latency-র সুস্থ Region দিয়ে। এজন্যই multi-Region active-active design-এর ভিত্তি সাধারণত latency routing।

#Failover routing (active-passive)

#Primary আর secondary

Failover routing-এ একই নাম আর type-এর ঠিক দুটো record থাকে: একটা primary, একটা secondary।

• Primary সুস্থ থাকলে প্রতিটা query পায় primary। Secondary চুপচাপ (passive): কিছুই পায় না।
• Primary অসুস্থ হলে প্রতিটা নতুন query পায় secondary: সাধারণত আরেকটা Region-এ disaster recovery (DR)-এর কপি, অথবা S3 website bucket-এ রাখা একটা static “একটু পরেই ফিরছি” page।
• Primary আবার সুস্থ হলে Route 53 নিজে থেকেই তার কাছে ফিরে যায় (failback)।

#Health check: কোন record-এ লাগবে?

• Primary-তে health check লাগবেই (অথবা load balancer-এর alias হলে Evaluate target health)। Console-এ health check ছাড়াই primary save করা যায়, কিন্তু health check ছাড়া record সবসময় সুস্থ, ফলে failover কখনো হবেই না। এজন্যই slide আর পরীক্ষা বলে primary-তে health check mandatory।
• Secondary-তে এটা ঐচ্ছিক। না থাকলে primary অসুস্থ হলেই Route 53 সবসময় secondary দিয়ে উত্তর দেয়, secondary-ও বন্ধ থাকলেও। থাকলে, আর দুটোই অসুস্থ হলে, Route 53 উত্তর দেয় primary দিয়ে।
• ছোট TTL রাখো (৬০ সেকেন্ড বা কম): যারা primary cache করে রেখেছে, TTL না ফুরানো পর্যন্ত তারা সেটাতেই চেষ্টা করতে থাকে।

Private hosted zone-এও failover চলে; Route 53-এর health checker-রা বসে internet-এ, তাই private endpoint check করা হয় একটা CloudWatch alarm দিয়ে (লেসন ৮.৪)। CloudWatch হলো AWS-এর monitoring service, পরে এর আলাদা chapter আছে।

#Geolocation routing

#User কোথায়, সেটা দেখে routing

Geolocation উত্তর দেয় query কোথা থেকে আসছে সেটা দেখে। তুমি location ধরে record বানাও:

• একটা continent (Europe, Asia, North America…),
• একটা দেশ (Bangladesh, Germany…),
• United States-এর একটা state (একমাত্র দেশ, যার state ধরে বাছাই করা যায়),
• আর বাকি সবার জন্য একটা Default record।

Location একটার ওপর আরেকটা পড়লে সবচেয়ে নির্দিষ্টটা জেতে: US state, তারপর দেশ, তারপর continent, তারপর Default। ফলে পুরো Asia-কে Singapore-এ পাঠাতে পারো, শুধু বাংলাদেশকে বাদ দিয়ে, যেটা যাবে Mumbai-তে।

#না মিললে আর Default না থাকলে, উত্তরই নেই

Route 53 query-র IP address থেকে একটা location বের করে। কোনো record না মিললে আর Default record-ও না থাকলে Route 53 দেয় no answer: status NOERROR, কিন্তু record শূন্য। ওই user-এর জন্য সাইট খোলেই না। কিছু IP address-এর অবস্থান একদমই বের করা যায় না, তাই সাত continent-এর record থাকলেও এটা ঘটতে পারে। সবসময় একটা Default record বানাও।

#Health check: বড় এলাকায় নেমে আসা

Health check থাকলে, মেলা record অসুস্থ হলে Route 53 চেষ্টা করে তার চেয়ে বড় এলাকার record: state থেকে United States, তারপর North America, তারপর Default, যতক্ষণ না একটা সুস্থ record পায়। সবগুলোই অসুস্থ হলে সবচেয়ে নির্দিষ্টটা দিয়েই উত্তর দেয়।

#Geolocation কোথায় কাজে লাগে

• ভাষা অনুযায়ী content: বাংলাদেশের জন্য বাংলা, জার্মানির জন্য জার্মান।
• Content-এর অধিকার: যে দেশগুলোতে distribution-এর অধিকার আছে, শুধু সেখানেই একটা video catalogue দেখাও।
• Compliance: EU-র user-দের সেবা দিতে হবে EU-র ভেতরের server থেকেই।
• আগে থেকে জানা load ভাগ: প্রতিটা location সবসময় একই endpoint-এ যায়, তাই হিসাব রাখা সহজ।

#Geoproximity routing আর bias

#আগে দূরত্ব, তারপর পাল্লায় একটু চাপ

Geoproximity routing করে user আর প্রতিটা resource-এর মধ্যের ভৌগোলিক দূরত্ব দেখে। কিছু না বদলালে প্রত্যেক user যায় সবচেয়ে কাছের resource-এ। প্রতিটা record বলে দেয় তার resource কোথায়:

• AWS resource হলে একটা AWS Region (অথবা একটা Local Zone group),
• অন্য কিছু হলে, যেমন তোমার নিজের data centre, একটা latitude আর longitude।

এর বিশেষ জিনিসটা হলো bias। এটা দিয়ে একটা resource-এর দিকে traffic পাঠানো এলাকাটা বড় বা ছোট করা যায়:

• positive bias, +১ থেকে +৯৯: এলাকা বড় হয়, পাশের এলাকাগুলো ছোট হয়, এই resource-এ বেশি traffic আসে;
• negative bias, −১ থেকে −৯৯: এলাকা ছোট হয়, পাশের এলাকাগুলো বড় হয়, কম traffic আসে।

Route 53 এটা খাটায় একটা সূত্র দিয়ে:

bias সহ দূরত্ব = আসল দূরত্ব × (১ − bias ÷ ১০০)

Bias +৫০ দিলে Route 53 দূরত্বকে অর্ধেক ধরে; −৫০ দিলে দেড় গুণ। যার bias সহ দূরত্ব সবচেয়ে কম, সে জেতে।

Slider সরাও আর দেখো ঢাকার user কখন Region বদলায়:

Bias সীমানা সরায়, আর সীমানার কাছে অনেক user থাকতে পারে। AWS-এর নিজের উদাহরণ: Dallas, Austin আর San Antonio-র user-রা N. Virginia আর Oregon থেকে প্রায় সমান দূরে, তাই একটু bias বদলালেই একসাথে অনেক traffic সরে যেতে পারে। Bias বদলাও অল্প অল্প করে, আর load-এর দিকে চোখ রাখো। Health check থাকলে অসুস্থ resource বাদ পড়ে, আর user যায় সবচেয়ে কাছের সুস্থ resource-এ। একই নাম আর type-এ সর্বোচ্চ ৩০টা geoproximity record থাকতে পারে।

#Latency, geolocation আর geoproximity পাশাপাশি

তিনটাই কোনো না কোনোভাবে user-এর অবস্থান দেখে, আর পরীক্ষা ইচ্ছা করেই এদের গুলিয়ে দেয়।

#IP-based routing

Geolocation আর latency কাজ করে Route 53-এর নিজের জোগাড় করা location data দিয়ে। IP-based routing কাজ করে তোমার জানা তথ্য দিয়ে: তোমার user-রা কোন network থেকে আসে। তুমি address range-গুলো upload করো, আর বলে দাও কোনটা কোথায় যাবে:

• CIDR block হলো একটা range, যেমন 198.51.100.0/24;
• CIDR location হলো block-এর একটা নাম দেওয়া list, যেমন isp-a = [198.51.100.0/24, 2001:db8::/32]; block-গুলো পাশাপাশি হতে হবে না, আর একটা location-এ IPv4 আর IPv6 দুই ধরনের block-ই থাকতে পারে;
• CIDR collection হলো location-গুলোর একটা নাম দেওয়া, বারবার ব্যবহার করা যায় এমন set।

প্রতিটা IP-based record একটা collection-এর একটা location-কে দেখায়; একই নাম আর type-এর সব record-কে একই collection ব্যবহার করতে হয়। Default location “*”-এর একটা record বাকি সব address ধরে, যারা কোনো block-এ পড়ে না; সেটা না থাকলে না-মেলা user কোনো উত্তর পায় না। Block হতে পারে IPv4-এ /১ থেকে /২৪ আর IPv6-এ /১ থেকে /৪৮। Default quota হলো প্রতি account-এ ৫টা collection আর প্রতি collection-এ ১,০০০টা block।

ক্লাসিক ব্যবহার: তুমি জানো একটা নির্দিষ্ট ISP-এর গ্রাহকরা একটা Region-এ সস্তায় বা দ্রুত পৌঁছায়, তাই ওই ISP-এর range সেখানে পাঠাও, performance বাড়াতে বা network transit-এর খরচ কমাতে। আরেকটা ব্যবহার হলো, যেসব network-এর location data ভুল, সেখানে geolocation-কে override করা। Private hosted zone-এ IP-based routing ব্যবহার করা যায় না।

#Multi-value answer routing

#এক উত্তরে কয়েকটা সুস্থ address

সাধারণ উত্তরে সাধারণত একটা address থাকে। Multi-value answer-এ তুমি প্রতিটা resource-এর জন্য একটা record বানাও (প্রত্যেকটার নিজের Record ID, আর সাধারণত নিজের health check), আর Route 53 প্রতিটা query-র উত্তর দেয় সর্বোচ্চ আটটা সুস্থ record দিয়ে, এলোমেলোভাবে বেছে। Client একটা নেয়, আর সেটা কাজ না করলে একই উত্তরের আরেকটা চেষ্টা করতে পারে।

• সুস্থ record আটটা বা কম হলে প্রতিটা উত্তরে সবগুলোই থাকে।
• যে record-এ health check নেই, তাকে সবসময় সুস্থ ধরা হয়।
• সব record অসুস্থ হলে Route 53 তবুও তাদের সর্বোচ্চ আটটা ফেরত দেয় (fail open)।
• একই নাম আর type-এ সর্বোচ্চ ১০০টা multi-value record থাকতে পারে; multi-value record alias হতে পারে না, আর NS ও CNAME ছাড়া যেকোনো type চলে।

#Simple routing-এর সাথে পার্থক্য কোথায়

Simple routing-ও কয়েকটা IP address দিতে পারে, কিন্তু সে “বোকা”: কখনো যাচাই করে না, তাই মরা server-এর address-ও বাকিদের সাথে বিলি হয়ে যায়, আর কিছু user error পায়। Multi-value “চালাক”: উত্তর দেওয়ার আগে যাদের health check fail করছে, তাদের address বাদ দিয়ে দেয়।

#তবুও routing কেন “ভুল” হতে পারে

অবস্থান দেখে কাজ করা সব policy (geolocation, geoproximity, IP-based, latency) নির্ভর করে Route 53 কোন address দেখছে তার ওপর, আর সেটা সাধারণত user-এর না।

• Query Route 53-এ আসে user-এর DNS resolver থেকে (ISP-এর, অফিসের, বা কোনো public resolver), user-এর device থেকে না। Resolver যদি EDNS Client Subnet সমর্থন করে, যেটা EDNS0 extension-গুলোর একটা, তাহলে সে user-এর address-এর একটা ছোট করা অংশ (যেমন প্রথম ২৪ bit) জুড়ে দেয়, আর Route 53 সেটাই ব্যবহার করে। না করলে Route 53 ব্যবহার করে resolver-এর নিজের address।
• ফলে ঢাকার একজন user, যার অফিস সব DNS পাঠায় Singapore-এর একটা resolver দিয়ে, অথবা যে EDNS Client Subnet ছাড়া কোনো public resolver ব্যবহার করে, তাকে ধরা হতে পারে Singapore-এর user, এমনকি US-এর user।
• Caching দেরি বাড়ায়: resolver একটা উত্তর তার TTL পর্যন্ত রেখে দেয়, তাই weight, bias বা health বদলালে সেটা প্রতিটা resolver-এর কাছে পৌঁছায় তার cache-এর কপির মেয়াদ ফুরালে। কিছু client আবার উত্তর দরকারের চেয়ে বেশিক্ষণ ধরে রাখে।
• Private hosted zone-এ EDNS Client Subnet নেই; সেখানে geolocation আর latency-র সিদ্ধান্তে Route 53 ব্যবহার করে VPC-র resolver যে Region-এ আছে সেটা।

কোনো user যখন বলে “আমি জার্মানিতে, অথচ US-এর সাইট পাচ্ছি”, record দেখার আগে তার resolver দেখো।

#Policy জোড়া দেওয়া: tree আর Traffic Flow

আসল system-এ প্রায়ই দুটো সিদ্ধান্ত লাগে: “প্রত্যেক user-কে সবচেয়ে দ্রুত Region-এ পাঠাও, আর প্রতিটা Region-এর ভেতরে blue/green ভাগ করো”, অথবা “প্রতিটা Region-এর ভেতরে একটা standby-তে failover করো”। Route 53-এ policy-র ভেতরে policy বসানো (nest) যায়।

হাতে, alias record দিয়ে। একটা alias record একই hosted zone-এর অন্য একটা record-কে দেখাতে পারে (লেসন ৮.২)। তাই tree-টা নিচ থেকে ওপরে বানাও:

1. প্রতিটা Region-এ নিচের ধাপের group বানাও, যেমন weighted record us.www.example.com (blue ৯০, green ১০) আর failover record eu.www.example.com (primary আর secondary)।
2. ওপরে www.example.com-এর জন্য latency alias record বানাও: us-east-1-এর record দেখাবে us.www.example.com, eu-central-1-এরটা eu.www.example.com, দুটোতেই Evaluate target health = Yes।
3. এখন কোনো শাখার সব record অসুস্থ হলে পুরো শাখাটাই অসুস্থ ধরা হয়, আর Route 53 user-কে পরের সেরা শাখায় সরিয়ে দেয়।

Traffic Flow দিয়ে। Route 53 Traffic Flow হলো ঠিক এই ধরনের tree বানানোর visual editor: rule (latency, weighted, failover, geolocation, geoproximity, IP-based, multi-value) আর endpoint টেনে এনে একটা diagram বানাও।

• ফলাফল হলো একটা traffic policy, version সহ জমা থাকে (একটা policy-তে সর্বোচ্চ ১,০০০টা), তাই আগের অবস্থায় ফিরে যাওয়া যায়।
• একটা policy version কোনো hosted zone-এর একটা নামে লাগালে তৈরি হয় একটা policy record। একই policy অনেক নামে আর অনেক hosted zone-এ লাগানো যায়, তাই বড় কোনো সেটআপ জুড়ে সব জায়গায় একই নিয়ম থাকে।
• দাম: প্রতিটা policy record মাসে $৫০ (মাসের ভগ্নাংশে ভাগ করে)। Default quota হলো প্রতি account-এ ৫০টা traffic policy আর ৫টা policy record। এক-দুটো সাধারণ সেটআপের জন্য সাধারণ record অনেক সস্তা।

#নিজে প্রতিটা policy চালিয়ে দেখো

একটা policy বেছে নাও, endpoint বন্ধ করো, weight বা bias বদলাও, Default record বন্ধ করে দাও, তারপর পাঁচটা শহর থেকে query পাঠাও:

#পরীক্ষার keyword → policy

#খরচ কত

Route 53 টাকা নেয় প্রতি দশ লাখ (million) query হিসেবে, আর হার নির্ভর করে policy-র ওপর (us-east-1-এর list price, মাসের প্রথম একশো কোটি query):

প্রথম ২৫টা hosted zone-এর প্রতিটা মাসে $০.৫০। লম্বা TTL query কমায়, তাই খরচও কমায়, তবে বদলগুলো দেরিতে পৌঁছায়।

#System design-এ routing policy

• প্রতিটা record-এর পেছনে একটা load balancer রাখো। Route 53 বাছে Region; Region-এর ভেতরের ALB বা NLB request ভাগ করে আর instance-এর health সামলায়। Load balancer-এর দিকে alias record দাও, Evaluate target health সহ।
• Global active-active: দুই বা তার বেশি Region জুড়ে health check সহ latency record (অথবা traffic সরাতে চাইলে geoproximity); প্রতিটা Region-কে আরেক Region-এর user-দের সামলানোর মতো বড় রাখতে হবে।
• Global active-passive: failover record, secondary আরেক Region-এ, data সেখানে replicate করা (লেসন ৭.৩-এর Aurora Global Database; S3 replication আসবে পরের এক chapter-এ), আর ছোট TTL।
• Release: blue/green আর canary-র জন্য weighted record, আর প্রতি request-এ মাপা ভাগ চাইলে সাথে ALB-র নিজের weighted target group (লেসন ৬.৩)।
• নিরাপত্তা জালটা সবসময় রাখো: geolocation-এ Default record, IP-based-এ “*” record, আর যেকোনো record যা নষ্ট হতে পারে তাতে health check।
• TTL ছোট রাখো (৬০ সেকেন্ড বা কম), যেসব record-এর উত্তর health check বা weight-এর কারণে বদলাতে পারে।
• DNS-এর সীমা মনে রাখো: উত্তর cache হয়, আর resolver-এর অবস্থান আন্দাজ মাত্র। মুহূর্তের মধ্যে failover বা ঢোকার জন্য ঠিক করা কয়েকটা IP লাগলে পরের ধাপ AWS Global Accelerator (পরের এক chapter-এ)।

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

Command-গুলোতে example.com-এর জন্য বানানো একটা কাল্পনিক hosted zone Z0EXAMPLE12345 ব্যবহার করা হয়েছে।

# 1. Weighted: two records, same name and type, different Record IDs (set identifiers)
cat > weighted.json <<'EOF'
{ "Changes": [
  { "Action": "UPSERT", "ResourceRecordSet": {
      "Name": "www.example.com", "Type": "A", "SetIdentifier": "blue",
      "Weight": 90, "TTL": 60, "HealthCheckId": "11111111-aaaa-bbbb-cccc-000000000001",
      "ResourceRecords": [{ "Value": "192.0.2.10" }] } },
  { "Action": "UPSERT", "ResourceRecordSet": {
      "Name": "www.example.com", "Type": "A", "SetIdentifier": "green",
      "Weight": 10, "TTL": 60, "HealthCheckId": "11111111-aaaa-bbbb-cccc-000000000002",
      "ResourceRecords": [{ "Value": "192.0.2.20" }] } }
] }
EOF
aws route53 change-resource-record-sets --hosted-zone-id Z0EXAMPLE12345 --change-batch file://weighted.json

# 2. Other policies only change the routing fields of each record:
#    "Region": "ap-southeast-1"                                   latency
#    "Failover": "PRIMARY" | "SECONDARY"                          failover
#    "GeoLocation": { "ContinentCode": "EU" }                     geolocation (or CountryCode / SubdivisionCode)
#    "GeoLocation": { "CountryCode": "*" }                        geolocation Default record
#    "GeoProximityLocation": { "AWSRegion": "ap-southeast-1", "Bias": 50 }   geoproximity
#    "GeoProximityLocation": { "Coordinates": { "Latitude": "23.81", "Longitude": "90.41" } }
#    "CidrRoutingConfig": { "CollectionId": "<id>", "LocationName": "isp-a" }   IP-based
#    "MultiValueAnswer": true                                     multi-value answer

# 3. IP-based: create a CIDR collection with one location
aws route53 create-cidr-collection --name customers --caller-reference customers-2026-10
aws route53 change-cidr-collection --id <collection-id> --changes \
  'Action=PUT,LocationName=isp-a,CidrList=198.51.100.0/24'

# 4. Ask Route 53 what it would answer for a given resolver and client subnet
aws route53 test-dns-answer --hosted-zone-id Z0EXAMPLE12345 \
  --record-name www.example.com --record-type A \
  --resolver-ip 198.51.100.53 --edns0-client-subnet-ip 203.0.113.0 --edns0-client-subnet-mask 24

# 5. List the records and their routing settings
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLE12345 \
  --query "ResourceRecordSets[?Name=='www.example.com.']"

Authoritative server-কে সরাসরি জিজ্ঞেস করো (zone-এর NS record থেকে একটা name server নাও):

# Several weighted answers in a row: mostly blue, sometimes green
for i in 1 2 3 4 5; do dig +short www.example.com @ns-123.awsdns-45.com; done

# Pretend to be a user in another network with EDNS Client Subnet
dig +short www.example.com @ns-123.awsdns-45.com +subnet=203.0.113.0/24

# On Windows
nslookup www.example.com ns-123.awsdns-45.com

Authoritative server-কে জিজ্ঞেস করলে resolver-এর cache এড়িয়ে যাওয়া যায়, তাই policy-কে সরাসরি সিদ্ধান্ত নিতে দেখবে। নিজের সাধারণ resolver দিয়ে জিজ্ঞেস করলে TTL শেষ না হওয়া পর্যন্ত একই উত্তর বারবার দেখবে।

#সারাংশ

মূল কথাগুলো

• Route 53-এ routing মানে DNS উত্তরে কোন record যাবে সেটা বাছাই। DNS কখনো traffic বয় না; client সরাসরি উত্তরের address-এ connect করে। এক policy-র record-গুলোর নাম আর type এক, আর প্রত্যেকের একটা Record ID (set identifier)।
• Health check: যে record-এ নেই, সে সবসময় সুস্থ; সব অসুস্থ হলে Route 53 এমনভাবে উত্তর দেয় যেন সবাই সুস্থ। বিস্তারিত লেসন ৮.৪-এ।
• Simple: একটা record, এক বা অনেক value, সবগুলো এলোমেলো ক্রমে আসে, client বাছে; alias → একটাই target; health check নেই।
• Weighted: ভাগ = weight ÷ মোট, weight ০–২৫৫, যোগফল ১০০ হতে হবে না; weight ০ = traffic নেই; সব ০ = সমান; সুস্থদের মধ্যে weight অনুযায়ী আবার ভাগ; weight ০ record উত্তর দেয় শুধু সব non-zero অসুস্থ হলে। Blue/green, canary।
• Latency: user থেকে AWS Region পর্যন্ত মাপা latency, দূরত্ব না (জার্মানি → US সম্ভব); প্রতি Region-এ একটা record; health check থাকলে পরের সেরা Region-এ failover।
• Failover: active-passive; primary-তে health check লাগবেই; secondary-তে ঐচ্ছিক (না থাকলে secondary সবসময় ফেরত আসে); দুটোই অসুস্থ → primary; নিজে থেকেই failback; ছোট TTL।
• Geolocation: continent, দেশ, US state; সবচেয়ে নির্দিষ্টটা জেতে; Default record, নাহলে উত্তর নেই; অসুস্থ হলে বড় এলাকায় নেমে আসে। Compliance, ভাষা, content-এর অধিকার।
• Geoproximity: user আর resource-এর দূরত্ব; bias −৯৯…+৯৯, bias সহ দূরত্ব = দূরত্ব × (১ − bias ÷ ১০০); AWS Region, Local Zone group বা latitude/longitude। জানুয়ারি ২০২৪ থেকে Traffic Flow লাগে না; মানচিত্রটা এখনো Traffic Flow-ই আঁকে।
• IP-based: CIDR block → location → collection; default “*” record; ISP ধরে routing; private hosted zone-এ চলে না।
• Multi-value: এলোমেলোভাবে সর্বোচ্চ ৮টা সুস্থ record, health check সহ, alias না, ELB-র বিকল্প না।
• Resolver যখন user-কে আড়াল করে (EDNS Client Subnet নেই), অবস্থান ভুল হতে পারে; caching প্রতিটা বদলকে দেরি করায়।
• Policy জোড়া দাও অন্য record-এর দিকে alias record দিয়ে (Evaluate target health), অথবা version সহ Traffic Flow policy দিয়ে; প্রতিটা policy record-এর দাম মাসে $৫০।

নিজেকে যাচাই করো: Route 53-এর routing policy৩০টি প্রশ্ন