Cloud-এর ভৌগোলিক কাঠামো — region, availability zone, edge আর data residency

১ · Cloud মেঘে থাকে না — region, zone আর ভবন

“Cloud” শব্দটি শুনলে মনে হয়, জিনিসটি আকাশে ভাসছে। আসলে এটি মাটির ওপর দাঁড়ানো বিশাল ভবন, যেখানে সারি সারি সার্ভার, জেনারেটর, ব্যাটারি আর ঠান্ডা রাখার যন্ত্র চলে। আপনি যখন একটি VM চালু করেন, তখন provider জিজ্ঞেস করে, “কোথায়?” এই প্রশ্নের উত্তরই ঠিক করে দেয় আপনার অ্যাপ কত দ্রুত সাড়া দেবে, বিল কত হবে, কোন আইন খাটবে, আর একটি ভবনে আগুন লাগলে আপনার ব্যবসা বাঁচবে কি না।

তিনটি স্তর ছবিতে দেখা যাক। খেয়াল করুন, ব্যবহারকারীর সবচেয়ে কাছে যে ঘাঁটি, সেটি region-এর ভেতরে নয়, বাইরে।

এক লাইনে সংজ্ঞা: Region হলো একটি ভৌগোলিক এলাকায় provider-এর স্বাধীন স্থাপনা। Availability zone (সংক্ষেপে AZ) হলো region-এর ভেতরের একটি বিচ্ছিন্ন অংশ, যাতে এক বা একাধিক data center থাকতে পারে। কিন্তু প্রতিটি provider একই নাম একই অর্থে ব্যবহার করে না। লেখার সময়ের নামগুলো এমন, আর এগুলো বদলাতে পারে:

Zone-এর নাম আর আসল জায়গা এক নয়

একটি ছোট ফাঁদ আছে। AWS-এ ap-south-1a নামটি আপনার account-এ যে ভৌত zone বোঝায়, অন্য account-এ অন্য zone বোঝাতে পারে। এভাবে provider সব গ্রাহককে একই “a” zone-এ জড়ো হতে দেয় না। দুই account-এর মধ্যে আসল zone মেলাতে হলে zone ID দেখতে হয়, যেমন aps1-az1. Azure-এও logical zone আর ভৌত zone-এর map subscription-ভেদে আলাদা হতে পারে।

# উদাহরণ (এখানে চলবে না; AWS CLI আর account লাগবে)
aws ec2 describe-availability-zones --region ap-south-1 \
  --query 'AvailabilityZones[].[ZoneName,ZoneId]' --output text

# নমুনা আউটপুট — account-ভেদে মিল আলাদা হতে পারে
ap-south-1a   aps1-az1
ap-south-1b   aps1-az3
ap-south-1c   aps1-az2

২ · Availability zone-এর আসল অর্থ — isolation কী, কী নয়

Zone-এর মূল কথাটি একটি শব্দে: isolation, মানে বিচ্ছিন্নতা। এখানে প্রশ্নটি হলো, কোন ঘটনা এক zone পেরিয়ে অন্য zone-এ যেতে পারবে না? প্রকৌশলীরা এই সীমাকে বলেন failure domain. একটি ব্যর্থতা কতদূর ছড়ায়, তাকে বলে blast radius.

AWS তার নথিতে বলে, একই region-এর AZ-গুলো এত দূরে রাখা হয় যাতে correlated ব্যর্থতার ঝুঁকি কমে, আবার এত কাছে রাখা হয় যাতে synchronous replication চলে। তাদের দেওয়া সীমা প্রায় ১০০ km এর মধ্যে। এখানে একটি প্রকৌশলের টানাপোড়েন লুকিয়ে আছে। Zone বেশি দূরে হলে একই বন্যা বা ভূমিকম্প দুটিকে ধরবে না, কিন্তু delay বাড়বে। বেশি কাছে হলে delay কমবে, কিন্তু একসাথে ক্ষতির ঝুঁকি বাড়বে।

Zone কী থেকে বাঁচায় না, সেটিও জানা দরকার। Zone বিচ্ছিন্ন হলেও region-এর কিছু জিনিস ভাগ করা থাকে: একই সফটওয়্যার, একই deployment প্রক্রিয়া, একই control plane, একই শহরের ঝড়। আপনার নিজের অ্যাপের ভুল, ডেটা মুছে ফেলা বা ভুল configuration তো সব zone-এ একসাথে পৌঁছে যায়। Replication ভুলটিকেও দ্রুত কপি করে। এজন্য multi-AZ backup-এর বিকল্প নয়।

৩ · Edge location আর local zone — region-এর বাইরের ছোট ঘাঁটি

Region সংখ্যায় কম, কিন্তু ব্যবহারকারী সব জায়গায়। এই ফাঁক পূরণ করে দুটি জিনিস। এদের কাজ আলাদা, তাই গুলিয়ে ফেলবেন না।

একটি বিষয় মনে রাখুন। Edge শুধু পড়ার কাজ বা cache করা জিনিসে সবচেয়ে কার্যকর। ব্যাংকের ব্যালান্সের মতো লেখা-নির্ভর কাজকে শেষ পর্যন্ত region-এর database-এ যেতেই হয়। Cache-এর ভেতরের কৌশল জানতে দেখুন System Design-এর CDN পর্ব আর Web caching ও CDN.

৪ · আলোর গতির দেয়াল — দূরত্ব থেকে delay-এর হিসাব

কোনো সার্ভারই আলোর চেয়ে দ্রুত উত্তর পাঠাতে পারে না। শূন্যে আলোর গতি সেকেন্ডে প্রায় ৩ লাখ km. কাচের fibre-এ সে ধীর হয়ে যায়, গতি হয় প্রায় দুই-তৃতীয়াংশ, মানে সেকেন্ডে ২ লাখ km. তাই মনে রাখার মতো একটি সংখ্যা:

এই সময়টিকে বলে propagation delay. আসল latency এর চেয়ে বেশি হয়, কারণ router-এর প্রক্রিয়া, ভিড়ে queue আর পথের ঘোরাঘুরি যোগ হয়। তবুও এই হিসাব অত্যন্ত কাজের, কারণ এটি একটি নিচের সীমা দেয়। “এর চেয়ে কম সম্ভব নয়” জানলে অনেক নকশার ভুল আগেই ধরা পড়ে। পুরো delay-এর ভাগগুলো পড়তে পারেন Computer Networks-এর delay ও throughput পর্বে।

এবার সংখ্যাগুলো ধাপে ধাপে দেখি। ধরে নিই একটি দূরের region-এর মোট fibre পথ ১৫,০০০ km, বাড়ির সংযোগ থেকে ISP পর্যন্ত একমুখী ৫ ms, সার্ভারের কাজ ২০ ms. এগুলো সবই হিসাবের জন্য ধরে নেওয়া মান, কোনো মাপা ফল নয়।

এবার নিজে হিসাব করে দেখুন। নিচের estimator-এ ঢাকা থেকে কয়েকটি শহরের সরল রেখার দূরত্ব বের করা হয়েছে, তারপর ধরে নেওয়া হয়েছে কেবলের পথ তার ১.৫ গুণ। PATH_FACTOR বা SERVER_MS বদলে আবার চালান।

// Fibre round-trip estimator: physics floor only, not a measured ping.
const FIBRE_KM_PER_MS = 200;   // light in glass, about 2/3 of c
const PATH_FACTOR = 1.5;       // ASSUMPTION: cable path / straight line
const ROUND_TRIPS = 3;         // TCP + TLS 1.3 + HTTP request
const SERVER_MS = 20;          // ASSUMPTION: time inside the app
const dhaka = [23.81, 90.41];
const cities = [               // approximate city coordinates
  ["Mumbai", 19.08, 72.88], ["Singapore", 1.35, 103.82],
  ["Tokyo", 35.68, 139.69], ["Frankfurt", 50.11, 8.68],
  ["N. Virginia", 39.04, -77.49],
];
function greatCircleKm(a, b) {  // haversine formula, earth radius 6371 km
  const rad = (d) => d * Math.PI / 180;
  const dLat = rad(b[0] - a[0]), dLon = rad(b[1] - a[1]);
  const h = Math.sin(dLat / 2) ** 2 +
    Math.cos(rad(a[0])) * Math.cos(rad(b[0])) * Math.sin(dLon / 2) ** 2;
  return 2 * 6371 * Math.asin(Math.sqrt(h));
}
console.log("city         line_km  path_km  rtt_ms  first_response_ms");
for (const [name, lat, lon] of cities) {
  const line = greatCircleKm(dhaka, [lat, lon]);
  const path = line * PATH_FACTOR;
  const rtt = 2 * path / FIBRE_KM_PER_MS;
  const first = ROUND_TRIPS * rtt + SERVER_MS;
  console.log(name.padEnd(12), line.toFixed(0).padStart(7), path.toFixed(0).padStart(8),
    rtt.toFixed(1).padStart(7), first.toFixed(0).padStart(11));
}
for (const budget of [2, 5, 10]) {     // how far can synchronous replication reach?
  const km = budget * FIBRE_KM_PER_MS / 2;
  console.log("RTT budget " + budget + " ms -> fibre path at most " + km + " km");
}

city         line_km  path_km  rtt_ms  first_response_ms
Mumbai          1887     2831    28.3         105
Singapore       2885     4328    43.3         150
Tokyo           4884     7326    73.3         240
Frankfurt       7426    11140   111.4         354
N. Virginia    12914    19371   193.7         601
RTT budget 2 ms -> fibre path at most 200 km
RTT budget 5 ms -> fibre path at most 500 km
RTT budget 10 ms -> fibre path at most 1000 km

৫ · Region বেছে নেওয়া — বাংলাদেশের ব্যবহারকারীর চোখে

“সবচেয়ে কাছের region নিন” কথাটি অর্ধেক সত্য। Region বেছে নিতে পাঁচটি প্রশ্নের উত্তর লাগে, আর এগুলোর গুরুত্ব অ্যাপ অনুযায়ী বদলায়।

লক্ষ্য করুন, প্রথম দুটি প্রশ্ন আসলে ওজনের প্রশ্নই নয়। আইন না মানলে অন্য কোনো সুবিধা দিয়ে তা পূরণ হয় না। তাই আগে এগুলো দিয়ে ছেঁকে নিন, তারপর বাকি region-গুলোকে নম্বর দিন।

বাংলাদেশ থেকে বাস্তব ছবি

লেখার সময় আমাদের জানামতে AWS, Azure বা Google Cloud-এর কোনোটির পূর্ণ public region বাংলাদেশের ভেতরে নেই। এটি বদলাতে পারে, তাই provider-এর সর্বশেষ মানচিত্র দেখে নিন। ফলে অনেক দল ভারত বা সিঙ্গাপুরের region বিবেচনা করে, যেমন Mumbai বা Singapore. দেশের ভেতরের data center বা স্থানীয় hosting-ও একটি পথ, বিশেষ করে ডেটার নিয়ম কড়া হলে। তখন managed সার্ভিসের সংখ্যা কম হতে পারে, আর zone-এর মতো বিচ্ছিন্নতার নকশা আপনাকেই যাচাই করতে হবে।

কোনো provider-এর edge বা local zone ঢাকায় আছে কি না, তা-ও সর্বশেষ তালিকায় দেখবেন। আর একটি কথা: আপনার ব্যবহারকারী যদি বেশিরভাগ বিদেশে থাকেন, তবে “বাংলাদেশের কাছে” বিষয়টিই অর্থহীন। Region ঠিক হয় ব্যবহারকারী আর ডেটা যেখানে, সেখান থেকে; কোম্পানির অফিস যেখানে, সেখান থেকে নয়।

নিচের picker-এ সব region আর সংখ্যা কাল্পনিক। উদ্দেশ্য হলো পদ্ধতিটি দেখা। দুই ধরনের কাজের ওজন আলাদা বলে ফলও আলাদা আসবে।

// Region picker: hard rules first, weighted score second.
// All regions and numbers are FICTIONAL; use your own measurements.
const regions = [
  { name: "Local-E", rttMs: 15, cost: 130, services: 3, dr: 3, dataOk: true, hasNeeded: false },
  { name: "Near-A", rttMs: 40, cost: 112, services: 7, dr: 6, dataOk: true, hasNeeded: true },
  { name: "Near-B", rttMs: 70, cost: 100, services: 9, dr: 8, dataOk: true, hasNeeded: true },
  { name: "Far-C", rttMs: 180, cost: 85, services: 10, dr: 9, dataOk: true, hasNeeded: true },
  { name: "Far-D", rttMs: 210, cost: 80, services: 10, dr: 9, dataOk: false, hasNeeded: true },
];
const profiles = {
  "shop (people wait)": { latency: 0.45, cost: 0.20, services: 0.15, dr: 0.20 },
  "nightly batch": { latency: 0.05, cost: 0.60, services: 0.20, dr: 0.15 },
};
const ok = regions.filter((r) => r.dataOk && r.hasNeeded);       // hard filter
for (const r of regions) if (!ok.includes(r))
  console.log("rejected " + r.name + ": " + (r.dataOk ? "needed service missing" : "data rule fails"));
function scale(v, list) {       // lower is better: best = 10, worst = 0
  const lo = Math.min(...list), hi = Math.max(...list);
  return hi === lo ? 10 : 10 * (hi - v) / (hi - lo);
}
const rtts = ok.map((r) => r.rttMs), costs = ok.map((r) => r.cost);
for (const [label, w] of Object.entries(profiles)) {
  const rows = ok.map((r) => ({
    name: r.name,
    score: w.latency * scale(r.rttMs, rtts) + w.cost * scale(r.cost, costs) +
      w.services * r.services + w.dr * r.dr,
  })).sort((a, b) => b.score - a.score);
  console.log(label + ": " + rows.map((r) => r.name + " " + r.score.toFixed(2)).join("  "));
}

rejected Local-E: needed service missing
rejected Far-D: data rule fails
shop (people wait): Near-B 7.37  Near-A 6.75  Far-C 5.30
nightly batch: Far-C 9.35  Near-B 6.06  Near-A 2.80

৬ · Availability-র অঙ্ক — গুণ আর 1 − (1 − a)ⁿ

Availability মানে মোট সময়ের কত অংশ সেবা চালু আছে। 99.9% শুনতে দারুণ, কিন্তু আসল অনুভূতি পাওয়া যায় downtime-এ হিসাব করলে। মান ধরা হলো ৩০ দিনে মাস, ৩৬৫ দিনে বছর:

এবার দুটি সূত্র। ধরুন একটি রেলপথে কয়েকটি সেতু পরপর আছে। ট্রেন পার হতে সব কটি সেতু ঠিক থাকতে হবে। এটি series. আর নদী পারের দুটি ঘাট পাশাপাশি থাকলে, একটি বন্ধ হলেও অন্যটি দিয়ে লঞ্চ চলবে। এটি parallel.

এক এক করে অংশ যোগ করলে সংখ্যা কেমন বদলায়, দেখুন। এখানে প্রতিটি মান ধরে নেওয়া, কোনো provider-এর SLA নয়। Load balancer 99.99%, একটি VM 99.5%, একটি database কপি 99.9%, আর shared অংশ 99.95%.

নিচের composer-এ আপনি নিজের নকশা বসাতে পারেন। প্রতিটি স্তরের জন্য [নাম, একটি কপির availability, কপির সংখ্যা]। beta মানে হলো, একটি কপির ব্যর্থতার কত ভাগ এমন কারণে হয় যা সব কপিকে একসাথে ফেলে দেয়।

// Availability composer: copies in a tier, tiers in series, plus correlation.
const MONTH_MIN = 30 * 24 * 60, YEAR_MIN = 365 * 24 * 60;
const designs = {   // [name, availability of one copy, copies]
  "one AZ": [["dns", 0.9999, 1], ["lb", 0.9999, 1], ["app", 0.995, 1], ["db", 0.999, 1]],
  "multi-AZ": [["dns", 0.9999, 1], ["lb", 0.9999, 1], ["app", 0.995, 3], ["db", 0.999, 2]],
};
// beta = share of one copy's failures that take all copies down together
function tier(a, n, beta) {
  const u = 1 - a;
  return n === 1 ? a : 1 - (beta * u + ((1 - beta) * u) ** n);
}
function compose(tiers, beta) {
  return tiers.reduce((all, [, a, n]) => all * tier(a, n, beta), 1);
}
function show(label, a) {
  const m = ((1 - a) * MONTH_MIN).toFixed(1), y = ((1 - a) * YEAR_MIN / 60).toFixed(2);
  console.log(label.padEnd(24), ((a * 100).toFixed(5) + "%").padStart(10),
    (m + " min/mo").padStart(14), (y + " h/yr").padStart(11));
}
for (const [name, tiers] of Object.entries(designs)) {
  for (const [t, a, n] of tiers)
    console.log("  " + name + " / " + t + " x" + n + " = " + (tier(a, n, 0) * 100).toFixed(6) + "%");
  show(name + ", independent", compose(tiers, 0));
}
for (const beta of [0.01, 0.05, 0.10])
  show("multi-AZ, beta " + beta.toFixed(2), compose(designs["multi-AZ"], beta));
const region = 0.9995;     // a whole-region event hits every AZ at once
const failover = 0.9999;   // the switch between two regions can fail too
const oneRegion = compose(designs["multi-AZ"], 0) * region;
show("multi-AZ in one region", oneRegion);
show("two regions + failover", (1 - (1 - oneRegion) ** 2) * failover);

  one AZ / dns x1 = 99.990000%
  one AZ / lb x1 = 99.990000%
  one AZ / app x1 = 99.500000%
  one AZ / db x1 = 99.900000%
one AZ, independent       99.38062%   267.6 min/mo  54.26 h/yr
  multi-AZ / dns x1 = 99.990000%
  multi-AZ / lb x1 = 99.990000%
  multi-AZ / app x3 = 99.999988%
  multi-AZ / db x2 = 99.999900%
multi-AZ, independent     99.97989%     8.7 min/mo   1.76 h/yr
multi-AZ, beta 0.01       99.97389%    11.3 min/mo   2.29 h/yr
multi-AZ, beta 0.05       99.94991%    21.6 min/mo   4.39 h/yr
multi-AZ, beta 0.10       99.91993%    34.6 min/mo   7.01 h/yr
multi-AZ in one region    99.92990%    30.3 min/mo   6.14 h/yr
two regions + failover    99.98995%     4.3 min/mo   0.88 h/yr

৭ · স্বাধীনতার অনুমান যখন ভাঙে — correlated failure আর একটি বাস্তব ঘটনা

Parallel সূত্রে দুটি 99.9% কপি মিলে 99.9999% হয়। হিসাবটি ঠিক, যদি কপি দুটি কোনো কিছুই ভাগ না করে। কিন্তু বাস্তবে এক কারণে একসাথে বিকল হওয়া, মানে correlated failure, প্রায়ই ঘটে। বিয়েবাড়িতে দুটি বড় ডেকচি রান্না করছে, একটি পুড়ে গেলেও অন্যটি আছে। কিন্তু দুটিতেই যদি একই পচা মাংস দেওয়া হয়, দুই ডেকচিই নষ্ট।

এর সাধারণ উৎসগুলো: একই সময়ে একই ভুল configuration ছড়ানো, একই software bug, একই certificate-এর মেয়াদ শেষ হওয়া, একই shared control plane, একই ভবন বা একই বিদ্যুৎ-উৎস, আর zone পেরোনোর পরে অতিরিক্ত ভিড়ে বাকিদেরও পড়ে যাওয়া।

কেস: Amazon S3-এর ফেব্রুয়ারি ২০১৭-এর ঘটনা

AWS-এর প্রকাশিত post-event summary অনুযায়ী, ২৮ ফেব্রুয়ারি ২০১৭ তারিখে Northern Virginia (us-east-1) region-এ একজন অনুমোদিত কর্মী billing-এর ধীর গতির সমস্যা খুঁজতে একটি কমান্ড চালান, আর একটি ভুল ইনপুটে উদ্দেশ্যের চেয়ে বেশি সার্ভার সরে যায়। এতে S3-এর দুটি গুরুত্বপূর্ণ অংশ, index আর placement subsystem, পুরো restart করতে হয়। সারাংশে বলা হয়েছিল, বড় region-গুলোতে এগুলো বহু বছর পুরো restart করা হয়নি। ফলে সেবা ফিরতে কয়েক ঘণ্টা লাগে।

S3-এর ওপর নির্ভরশীল আরও সার্ভিস, যেমন নতুন EC2 চালু করা আর Lambda, তখন প্রভাবিত হয়। সবচেয়ে শিক্ষণীয় অংশ: AWS-এর status dashboard-এর পরিচালনাও S3-এর ওপর নির্ভর করত, তাই শুরুর দিকে dashboard ঠিকমতো আপডেট করা যায়নি।

Provider-দের ক্ষেত্রেও এর পরে আরও ঘটনা হয়েছে। মার্চ ২০২১-এ OVHcloud-এর Strasbourg-এর একটি ভবনে আগুন লাগে, আর পাশাপাশি থাকা স্থাপনাও ক্ষতিগ্রস্ত হয়। Google Cloud-এর নিজের রিপোর্ট অনুযায়ী, এপ্রিল ২০২৩-এ Paris-এর europe-west9 region-এর একটি data center-এ পানির পাইপের ফুটো আর পরে আগুনের ঘটনায় শুধু একটি zone নয়, সাময়িকভাবে একাধিক zone প্রভাবিত হয়। এক zone-এর ক্ষতি সারতে অনেক বেশি সময় লাগে। একে “বিচ্ছিন্নতা ব্যর্থ” বলে না ভেবে বরং মনে রাখুন: বিচ্ছিন্নতা একটি সম্ভাবনা কমায়, শূন্য করে না।

৮ · Multi-AZ বনাম multi-region — কতটা, আর কী দামে

প্রথমে একটি zone-এর বিপর্যয়ে দুটি নকশার আচরণ পাশাপাশি দেখুন। ধরে নেওয়া ঘটনা: AZ-a-তে ৩ ঘণ্টার জন্য বিদ্যুৎ বিপর্যয়। একটি zone-এর নকশায় সব VM আর database AZ-a-তেই আছে। Multi-AZ নকশায় AZ-a আর AZ-b-তে ২টি করে মোট ৪টি VM, database primary AZ-a-তে আর synchronous standby AZ-b-তে। সব সময় হিসাবের জন্য ধরে নেওয়া, আসল সময় সেটিংস আর provider-ভেদে আলাদা।

Region পেরোলে কী বদলায়

Zone-এর মধ্যে কয়েক ms-এ যা সহজ, region পেরোলে তা ব্যয়বহুল হয়ে পড়ে। সবচেয়ে বড় কারণটি sync আর async-এর পুরোনো হিসাব, যা System Design-এর replication পর্বে বিস্তারিত আছে। এক লাইনে: synchronous হলে প্রতিটি লেখা অন্য কপির উত্তর পর্যন্ত অপেক্ষা করে, আর asynchronous হলে আগে “হয়েছে” বলে পরে পাঠায়।

এজন্যই প্রচলিত নকশা হলো: region-এর ভেতরে zone-গুলোর মধ্যে synchronous, region পেরিয়ে asynchronous. এর কোনো ধরাবাঁধা সীমা নেই, তবে ওপরের হিসাবে RTT ৫ ms মানে fibre পথ ৫০০ km. এর বাইরে sync রাখতে চাইলে প্রতিটি লেখায় বড় দাম গুনতে হবে।

Multi-region-এর দুটি সাধারণ ধরন আছে। Active-passive-এ একটি region চলে, অন্যটি প্রস্তুত থাকে; সহজ, কিন্তু failover কখনো পরীক্ষা না করলে দরকারের সময় নাও চলতে পারে। Active-active-এ দুটিই traffic নেয়; এতে ক্ষমতা নিয়মিত যাচাই হয়, কিন্তু ডেটার সংঘাত আর consistency সামলাতে হয়। সিদ্ধান্তের পুরো ধাপ আর চারটি DR কৌশল আসবে পর্ব ২৪ · Backup আর disaster recovery-তে, আর গভীর আলোচনা আছে System Design-এর disaster recovery পর্বে।

৯ · Data residency বনাম sovereignty — ডেটার ঠিকানা আর ডেটার আইন

তিনটি শব্দ প্রায়ই একসাথে ব্যবহার হয়, কিন্তু অর্থ আলাদা।

তাই “ডেটা দেশে আছে” বললে কাজ শেষ হয় না। Backup, log, support-এর সুবিধা, পাশের region-এ replication, এমনকি global সার্ভিসের metadata কোথায় যাচ্ছে, সব দেখতে হয়। এনক্রিপশন আর নিজের নিয়ন্ত্রণে থাকা চাবি (পর্ব ৩৩) কিছু ঝুঁকি কমায়, কিন্তু আইনের প্রশ্ন পুরোপুরি মেটায় না।

বাংলাদেশের প্রসঙ্গ

এই অংশটি আইনি পরামর্শ নয়, আর নিয়ম দ্রুত বদলাচ্ছে। সরকারের আইন-ওয়েবসাইট bdlaws.minlaw.gov.bd অনুযায়ী, ২০২৫ সালের অধ্যাদেশের জায়গায় এখন ব্যক্তিগত উপাত্ত সুরক্ষা আইন, ২০২৬ (২০২৬ সনের ৬৩ নং আইন) আর জাতীয় উপাত্ত ব্যবস্থাপনা আইন, ২০২৬ (২০২৬ সনের ৮০ নং আইন) আছে। দুটিরই তারিখ ১০ এপ্রিল ২০২৬। প্রথম আইনটিতে উপাত্তের শ্রেণিবিভাগ আর দেশের বাইরে স্থানান্তরের শর্তের বিধান আছে, তবে কিছু ধারা পরে কার্যকর হওয়ার কথা, আর প্রবিধানেও বিস্তারিত আসতে পারে। তাই এখানে কোনো বিধান উদ্ধৃত করছি না; কোন ডেটার জন্য কী প্রযোজ্য, তা মূল লেখায় দেখুন।

ব্যাংক, আর্থিক প্রতিষ্ঠান, টেলিকম আর সরকারি কাজে খাতভিত্তিক নির্দেশনাও প্রযোজ্য হতে পারে, যেমন Bangladesh Bank-এর নির্দেশনা। করণীয় একটাই: সরকারের প্রকাশিত মূল লেখা পড়া, আর compliance বা আইনজীবীর সাথে কথা বলা। AI-এর মুখের কথায় কখনো এই সিদ্ধান্ত নেবেন না। Region বেছে নেওয়ার আগে একটি ছোট তালিকা বানান: কোন ডেটা আছে, কোন শ্রেণির, কার, কোথায় যাচ্ছে।

১০ · AI-এর যুগে region আর availability-র নকশা যাচাই

AI “high availability” নকশা দ্রুত লিখে দিতে পারে, আর সেখানে 99.999%-এর মতো সংখ্যাও বসিয়ে দিতে পারে। কিন্তু সে আপনার ব্যবহারকারী, আইন বা বিল দেখে না। সাধারণ ভুলগুলো চিনে রাখুন।

AI-এর নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Availability-র হিসাব নিজে আবার করেছি, প্রতিটি অনুমান লেখা আছে
• Shared dependency (DNS, IAM, deployment, control plane) series-এ বসিয়েছি
• Region আর সার্ভিস আছে কি না provider-এর নথিতে দেখেছি, আসল latency নিজে মেপেছি
• Multi-AZ বা multi-region-এর বাড়তি খরচ হিসাব করেছি, budget alert রেখেছি
• terraform plan বা --dry-run পড়েছি, আর throwaway পরিবেশে পরীক্ষা করেছি
• Failover-এর মহড়া দিয়েছি, শুধু কাগজে লিখিনি
• ডেটার আইনের প্রশ্ন সরকারি মূল লেখা আর compliance-এর সাথে মিলিয়েছি