Region, Availability Zone ও Edge Location

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

• AWS বাস্তবে কীভাবে সাজানো, বুঝিয়ে বলতে পারবে: data centre, Availability Zone, Region, আর এদের সামনে বসানো edge network।
• একটা Region code, একটা Availability Zone-এর নাম আর একটা AZ ID পড়তে পারবে, আর বলতে পারবে তোমার account-এর us-east-1a কেন আমার account-এর us-east-1a না-ও হতে পারে।
• নতুন application-এর জন্য Region বেছে নিতে পারবে, এই ক্রমে: নিয়মকানুন, latency, service আছে কি না, দাম।
• কোনো service বা resource global, regional, নাকি একটা Availability Zone-এ বাঁধা, তা বলতে পারবে, আর কিছু ভাঙলে এর মানে কী দাঁড়ায় সেটাও।
• কখন Local Zone, Wavelength Zone বা Outposts-ই আসল উত্তর, চিনতে পারবে।
• এমন application ডিজাইন করতে পারবে যেটা একটা data centre, একটা পুরো Availability Zone, এমনকি পুরো একটা Region হারালেও টিকে থাকে।

#AWS দেখতে কেমন, সেটা জানা কেন জরুরি

লেসন ১.১-এ দেখেছ, cloud মানে আসলে অন্য কারও কম্পিউটার, ঘণ্টা হিসেবে ভাড়া নেওয়া। এই লেসনে পরের প্রশ্নটার উত্তর: সেই কম্পিউটারগুলো আছে কোথায়, আর সাজানো কীভাবে?

তিনটা কারণে এটা জানা দরকার:

1. বিপদ। disk নষ্ট হয়, বিদ্যুৎ যায়, রাস্তা খুঁড়তে গিয়ে fibre কেটে যায়, বন্যার পানি ভবনে ঢোকে। AWS এমনভাবে সাজানো যে প্রতিটা বিপদ একটা নির্দিষ্ট মাপের বাক্সের ভেতরেই আটকে থাকে। বাক্সগুলো চিনলে তুমি জানবে application-এর কপিগুলো কোথায় রাখতে হবে।
2. গতি। fibre-এর ভেতর দিয়ে আলোর ১,০০০ km যেতে লাগে প্রায় 5 ms। পৃথিবীর অন্য প্রান্তের server হলে প্রতিটা round trip-এ যোগ হয় একশো-দুশো millisecond, আর CPU যত বাড়াও, এটা কমবে না। তুমি কোথায় চালাচ্ছ, তার ওপরই নির্ভর করে user-এর কাছে site কতটা দ্রুত লাগবে।
3. আইন আর টাকা। অনেক দেশ আর অনেক ব্যবসার নিয়মে বলা থাকে মানুষের ব্যক্তিগত বা আর্থিক data কোথায় রাখা যাবে। আবার একই server-এর দাম জায়গাভেদে আলাদা।

AWS-এর উত্তর হলো চার স্তরের একটা সাজানো কাঠামো:

#Region

Region হলো পৃথিবীর একটা জায়গা, যেখানে AWS এক গুচ্ছ Availability Zone চালায়। অক্টোবর ২০২৬-এ AWS-এর হিসাবে আছে ৩৯টা Region আর ১২৪টা Availability Zone, আরও কয়েকটা ঘোষণা করা আছে (সৌদি আরব আর চিলি তার মধ্যে)। সংখ্যাটা প্রতি বছর বাড়ে, তাই মুখস্থ না করে দরকার হলে global infrastructure page দেখে নিয়ো; পরীক্ষায় কখনো সংখ্যা জিজ্ঞেস করে না।

৩৯টার সবগুলো কিন্তু সাধারণ account-এর জন্য খোলা না:

• সাধারণ একটা AWS account দিয়ে ব্যবহার করা যায় ৩৪টা commercial Region।
• AWS GovCloud (US)-এ আছে আমেরিকার সরকারি কাজের জন্য দুটো Region, যেখানে ঢুকতে আলাদা GovCloud account লাগে।
• চীনের দুটো Region (Beijing আর Ningxia) চালায় সেখানকার স্থানীয় অংশীদার, এর জন্যও আলাদা account লাগে।
• AWS European Sovereign Cloud (প্রথম Region জার্মানির Brandenburg-এ, জানুয়ারি ২০২৬ থেকে) বাকি সব Region থেকে বাস্তবেও আলাদা, পরিচালনাতেও আলাদা। এটা বানানো হয়েছে এমন ইউরোপীয় গ্রাহকদের জন্য, যাদের data-র ওপর নিজের দেশের নিয়ন্ত্রণ নিয়ে খুব কড়া নিয়ম।

এই আলাদা আলাদা দলগুলোকে বলে partition। resource, account বা login এক partition থেকে আরেক partition-এ যায় না।

#Region code

প্রতিটা Region-এর একটা পুরো নাম আছে, আর একটা code। code-টাই তুমি সারাক্ষণ লিখবে:

ধাঁচটা হলো এলাকা – দিক – সংখ্যা: ap (Asia Pacific), south, 1। সংখ্যাটা শুধু গোনে ওই এলাকায় কয়টা Region খোলা হলো; ap-south-2 মানে স্রেফ “দক্ষিণ Asia Pacific”-এ AWS-এর খোলা দ্বিতীয় Region, ap-south-1-এর backup না।

#আগে থেকে চালু Region আর opt-in Region

২০ মার্চ ২০১৯-এর পরে খোলা Region নতুন account-এ শুরুতে বন্ধ থাকে। সেখানে কিছু বানানোর আগে Region-টা চালু (enable) করে নিতে হয়, account setting থেকে বা Global View console থেকে। Hong Kong, Hyderabad, Jakarta, Melbourne, Milan, Bahrain, সংযুক্ত আরব আমিরাত, Tel Aviv, Cape Town আর একেবারে নতুনগুলো, সবই opt-in। আর পুরনো ১৭টা Region, যেমন us-east-1, ap-south-1, ap-southeast-1, প্রথম দিন থেকেই চালু।

এ কারণেই “সব Region”-এর ওপর loop চালানো কোনো script মাঝে মাঝে authorisation error দেয়: Region-টা আছে ঠিকই, কিন্তু ওই account-এ চালু করা হয়নি।

#তুমি যে Region বাছো, data সেখানেই থাকে

Region একটা data-র সীমানাও। তুমি যখন eu-central-1-এর একটা S3 bucket-এ কোনো object রাখো, AWS সেটা ওই Region-এই রাখে। হারিয়ে না যাওয়ার জন্য Region-এর ভেতরের Availability Zone-গুলোতে কপি হয় ঠিকই, কিন্তু Region-এর বাইরে যায় কেবল তখনই, যখন তুমি (বা তোমার সেট করা কোনো service) সেটা পাঠাও: অন্য Region-এ replication, একটা backup কপি, বা কোনো user যখন সেটা download করে।

এই নিশ্চয়তার জন্যই data residency-র নিয়ম মানতে Region-ই ঠিক হাতিয়ার, যেমন ইউরোপীয় ইউনিয়নের GDPR, বা কোনো কেন্দ্রীয় ব্যাংকের নিয়ম যে গ্রাহকের data দেশের ভেতরেই রাখতে হবে।

#Availability Zone

Availability Zone হলো এক বা একাধিক আলাদা data centre, যাদের বিদ্যুৎ, network আর সংযোগের একাধিক ব্যবস্থা আছে। একটা Region-এর AZ-গুলো:

• বাস্তবে আলাদা: একটা থেকে আরেকটা অনেক কিলোমিটার দূরে, যাতে একটা বন্যা, আগুন, ঝড় বা grid বিকল হওয়া দুটো AZ-কে একসঙ্গে না ছোঁয়; তবু সবগুলো একে অপরের ১০০ km (৬০ মাইল)-এর মধ্যে;
• স্বাধীন: বিদ্যুতের উৎস, ঠান্ডা রাখার ব্যবস্থা আর network-এর পথ, সব আলাদা;
• জোড়া উচ্চ গতির, কম latency-র, পুরোপুরি redundant private fibre দিয়ে। এতটাই দ্রুত যে synchronous replication করা যায় (user-কে “সেভ হয়েছে” বলার আগেই দুটো AZ-এ লেখা হয়ে যায়), সাধারণত round trip লাগে এক অঙ্কের millisecond।

একটা Region-এ AZ থাকে কমপক্ষে তিনটা (us-east-1-এ ছয়টা)। প্রতিটা AZ-এর নাম হয় Region-এর code-এর সঙ্গে একটা অক্ষর জুড়ে: ap-southeast-2a, ap-southeast-2b, ap-southeast-2c।

#AZ-এর নাম আর AZ ID

এবার এমন একটা খুঁটিনাটি, যেটায় সত্যিকারের অনেক দল ধরা খায়। সবচেয়ে পুরনো Region-গুলোতে AWS প্রতিটা account-এর জন্য অক্ষরগুলো এলোমেলো করে দিয়েছিল: তোমার us-east-1a আর আমার us-east-1a হতে পারে দুটো আলাদা আসল AZ। কারণটা সহজ: সবাই তালিকার প্রথমটা, মানে “a” বেছে নেয়; এলোমেলো না করলে সবাই একই ভবনে গিয়ে ভিড় করত।

আলাদা account-এ একই আসল জায়গার কথা বলতে হলে ব্যবহার করো AZ ID, যেমন use1-az1 বা aps1-az2। একটা AZ ID সব account-এ একই আসল AZ-কেই বোঝায়।

• এলোমেলো নামের ঝামেলা শুধু নভেম্বর ২০২৫-এর আগে খোলা account-এ, নয়টা পুরনো Region-এ: N. Virginia, N. California, Oregon, Singapore, Sydney, Tokyo, Ireland, São Paulo আর GovCloud (US-West)। নভেম্বর ২০১২-র পরে চালু হওয়া সব Region-এ সবার জন্য তালিকা একই, আর নভেম্বর ২০২৫ থেকে খোলা account-এও তাই।
• কোন নাম কোন ID, দেখতে পারো aws ec2 describe-availability-zones দিয়ে (এটা ZoneName আর ZoneId দুটোই দেখায়), EC2 dashboard-এ, অথবা instance-এর ভেতর থেকে metadata service-এর placement/availability-zone-id পথে (লেসন ৪.৩)।

এটা কখন দরকার পড়ে? যখনই দুটো account-কে মিলিয়ে চলতে হয়: অন্য account-এর সঙ্গে subnet share করা, cross-AZ খরচ এড়াতে কোনো partner-এর database-এর পাশেই নিজের application বসানো, এক account-এ রিজার্ভ করা capacity অন্য account-এর server-এর সঙ্গে মেলানো। সবসময় মেলাবে AZ ID, নাম কখনো না।

#Region কীভাবে বাছবে

প্রতিটা নতুন application-এর জন্যই তোমাকে একটা Region বাছতে হবে। চারটা প্রশ্ন করো, ঠিক এই ক্রমে, কারণ প্রথম প্রশ্নটাই বাকি সব উত্তর বাতিল করে দিতে পারে:

1. ১. নিয়মকানুন: data কোথায় রাখার অনুমতি আছে?

   আইন, নিয়ন্ত্রক সংস্থা, চুক্তি বা গ্রাহকের নিজের নীতিতে বলা থাকতে পারে, data থাকতে হবে একটা নির্দিষ্ট দেশে বা কয়েকটা দেশের মধ্যে। তাহলে শুধু সেখানকার Region-ই বিবেচনায় আসবে, অন্য কোনো Region বেশি দ্রুত বা সস্তা হলেও। এটা পছন্দ-অপছন্দের ব্যাপার না, এটা একটা কড়া ছাঁকনি।

2. ২. Latency: user-রা কোথায়?

   যেগুলো টিকে গেল, তার মধ্যে বেশির ভাগ user-এর সবচেয়ে কাছেরটা বাছো (ম্যাপের দূরত্ব না, network-এর দূরত্ব)। Dhaka থেকে Mumbai, Hyderabad বা Singapore-এ round trip সাধারণত মোটামুটি 30–70 ms, কিন্তু N. Virginia-তে 200 ms-এরও অনেক বেশি। যে web page একবারে কয়েক ডজন request পাঠায়, তার জন্য এই পার্থক্য কয়েক সেকেন্ডের।

3. ৩. Service: যা যা লাগবে, সব কি সেখানে আছে?

   নতুন service আর নতুন feature একসঙ্গে সব Region-এ আসে না; অনেকগুলো শুরু হয় us-east-1-এ, তারপর কয়েক মাস ধরে বাকিগুলোতে ছড়ায়। তুমি যে service আর feature-এর ওপর নির্ভর করছ, তার প্রতিটা AWS services by Region তালিকায় মিলিয়ে নাও, instance type-ও (কোনো GPU type হয়তো হাতে গোনা কয়েকটা Region-এই আছে)।

4. ৪. দাম: সেখানে খরচ কত?

   Region ভেদে দাম আলাদা, একই instance-এর দাম কখনো কখনো 20–50 % পর্যন্ত বেশি-কম। N. Virginia আর Ohio সবচেয়ে সস্তাগুলোর মধ্যে; São Paulo আর কিছু নতুন Region সবচেয়ে দামিগুলোর মধ্যে। প্রতিটা service-এর pricing page-এ Region ধরে দাম দেওয়া থাকে।

দুটো ছোট বিষয় মাঝে মাঝে সমান-সমান অবস্থায় সিদ্ধান্ত বদলে দেয়: Region-টা opt-in কি না (একটু বেশি সেটআপ), আর সেখানে কয়টা AZ আছে (কিছু ডিজাইনে তিনটার বেশি লাগে)।

#Edge location আর AWS-এর বিশ্বজোড়া network

Region সংখ্যায় কম, একটা থেকে আরেকটা অনেক দূরে: বেশির ভাগ দেশেই কোনো Region নেই। সব জায়গায় user-এর কাছে পৌঁছাতে AWS শত শত শহরে point of presence (PoP)-ও চালায়: অক্টোবর ২০২৬-এ ৭৫০-এর বেশি PoP আর ১৫টা regional edge cache, ১০০-র বেশি শহরে।

edge location-এ তুমি নিজে কোনো server চালু করো না। সেখানে যে service-গুলো চলে, তাদের মাধ্যমেই এগুলো ব্যবহার করো। CloudFront নিয়ে বিস্তারিত Chapter 11-এ; এখানে শুধু মূল ধারণাটা দরকার:

#আরও কাছে: Local Zone, Wavelength আর Outposts

কখনো কখনো সবচেয়ে কাছের Region-ও অনেক দূরে, অথবা data একটা নির্দিষ্ট ভবনের বাইরেই নেওয়া যাবে না। এমন অবস্থায় একটা Region-কে বাইরের দিকে টেনে বড় করার তিনটা উপায় আছে AWS-এর। প্রতিটাই একটা parent Region-এর সঙ্গে বাঁধা, আর চালানো হয় সেখান থেকেই।

তিনটাই parent Region-এর একটা VPC-কে বাড়িয়ে নেয়। Local Zone-এ চালানো তোমার instance-গুলো ব্যবহার করে parent Region-এরই IAM, console আর API।

#parent Region-এর সঙ্গে সংযোগ কেটে গেলে কী হয়

Local Zone, Wavelength Zone আর বিশেষ করে Outposts তাদের control plane-এর জন্য (launch করা, বদলানো, নজর রাখা) parent Region-এর সঙ্গে network সংযোগের ওপর নির্ভর করে। সেই সংযোগ বন্ধ হলে:

• যে instance আগে থেকেই চলছে, সেগুলো চলতেই থাকে, স্থানীয় traffic-ও চলতে থাকে;
• কিন্তু resource launch, stop বা বদলানো যায় না, আর যে service-গুলোর Region লাগে (নতুন session-এর জন্য IAM যাচাই, CloudWatch-এ তথ্য পাঠানো), সেগুলো দেরি করে বা কাজ করে না।

তাই Outpost-এর বেলায় service link-কে ধরা হয় অত্যন্ত জরুরি অবকাঠামো হিসেবে, একাধিক সংযোগ দিয়ে বানানো হয়, আর Outpost-এর মাপ এমন রাখা হয় যাতে বাড়তি capacity আগে থেকেই চালু থাকে।

#Global, regional নাকি zonal: প্রতিটা service-এর scope

AWS-এর প্রতিটা service আর প্রতিটা resource তিনটা scope-এর কোনো একটায় থাকে। scope জানলে বোঝা যায় জিনিসটা কোথায় ব্যবহার করা যাবে, কোনো বিপদে সেটা হারাবে কি না, আর অন্য কোথাও একটা কপি রাখতে হবে কি না।

পরীক্ষা যে খুঁটিনাটিগুলো পছন্দ করে:

• S3-কে console-এ global মনে হয়, আর bucket-এর নাম সারা পৃথিবীতে একটাই হতে হয় (একটাই global namespace), কিন্তু প্রতিটা bucket একটা Region-এ বানানো, data-ও থাকে সেখানেই।
• EBS volume লাগানো যায় শুধু একই AZ-এর instance-এ। সরাতে চাইলে snapshot নাও (snapshot regional), তারপর অন্য AZ-এ সেখান থেকে নতুন volume বানাও (Chapter 5)।
• AMI regional; অন্য Region-এ ব্যবহার করতে হলে কপি করতে হয় (লেসন ৪.৩)। VPC regional; subnet থাকে একটা AZ-এ (লেসন ৩.২)।
• “Global” service-এরও একটা বাড়ি আছে। এদের control plane প্রায়ই চলে us-east-1-এ। এ কারণেই CloudFront-এর TLS certificate চাইতে হয় us-east-1-এ, আর CloudFront-এর WAF rule-ও বানাতে হয় সেখানে। প্রতিদিনের কাজ (sign in, permission যাচাই, DNS-এর উত্তর) অবশ্য সব জায়গা থেকেই চলে।

#প্রতিটা স্তরে বিপদের জন্য ডিজাইন

এবার টুকরোগুলো জোড়া লাগাও। কাঠামোর প্রতিটা স্তর একটা failure domain: এমন একটা অংশ, যেটা একসঙ্গে পুরোটাই বিকল হতে পারে। ভালো ডিজাইন কপিগুলো রাখে আলাদা আলাদা failure domain-এ।

#Multi-AZ: স্বাভাবিক মান

production-এর যেকোনো জিনিস কমপক্ষে দুটো AZ-এ চালাও (তিনটা হলে আরও ভালো)। পরীক্ষায় একেই বলে high availability:

• load balancer-এর পেছনে দুই বা তার বেশি AZ-এ web আর app server, সামলাবে একটা Auto Scaling group, যেটা ভালো AZ-এ বদলি server চালু করে দেয় (Chapter 6);
• এমন একটা database, যার synchronous standby আছে দ্বিতীয় AZ-এ (Multi-AZ, Chapter 7);
• প্রতিটা AZ-এ একটা করে NAT gateway, যাতে একটা AZ হারালে বাকিরা internet থেকে বিচ্ছিন্ন না হয় (লেসন ৩.৪)।

একটা instance বা একটা AZ-এর ডিজাইন কখনোই highly available না, instance যত বড়ই হোক।

high availability মানে কিন্তু “কখনোই বন্ধ হবে না” না। এর মানে, কোনো একটা বিপদ (একটা server, একটা ভবন, একটা AZ) service থামাতে পারবে না, আর সেরে ওঠা হবে নিজে নিজে, দ্রুত। এক Region-এর ভেতরের কোনো কিছুই সেই Region হারানোর পরে টিকে থাকার কথা দিতে পারে না।

#Static stability: দরকারের আগেই capacity হাতে রাখো

বড় কোনো AZ বিপদের সময় হাজার হাজার গ্রাহক একই মুহূর্তে বাকি AZ-গুলোতে বদলি server চালু করতে চায়। তখন launch করা (এটা control plane-এর কাজ) ধীর হয়ে যেতে পারে বা আটকে যেতে পারে। কিন্তু যে server চলছে আর যে traffic যাচ্ছে (data plane), সেগুলো ঠিকই চলতে থাকে।

তাই মজবুত ডিজাইন হলো statically stable: একটা AZ হারিয়ে গেলেও বাকি AZ-গুলোতে পুরো চাপ সামলানোর মতো capacity আগে থেকেই চালু থাকে। তিনটা AZ থাকলে প্রতিটা চালাও তার capacity-র মোটামুটি দুই-তৃতীয়াংশের বেশি না; দুটো AZ হলে প্রতিটাকেই একা পুরো চাপ নেওয়ার মতো হতে হবে। প্রতিটা AZ-এ capacity রিজার্ভ করে রাখাও (লেসন ৪.৪) এটা নিশ্চিত করার আরেকটা উপায়।

#Multi-Region: যখন একটা Region যথেষ্ট না

দ্বিতীয় Region-এ সত্যিকারের টাকা আর ঝামেলা দুটোই লাগে: দ্বিগুণ infrastructure, data replication, আর কোন Region-টা প্রধান থাকবে তার পরিকল্পনা। এটা নাও যখন:

• ব্যবসাকে পুরো Region জুড়ে কোনো বিপদেও টিকে থাকতে হবে (disaster recovery-র কড়া শর্ত);
• user-রা নানা মহাদেশে ছড়িয়ে, আর সবখানেই কম latency দরকার;
• data রাখতে হবে কয়েকটা দেশে, প্রতিটা দেশের data তার নিজের Region-এ।

এর জন্য যা যা লাগে, সেগুলো কোর্সের পরের দিকে আসবে: Route 53-এর health check আর failover routing (Chapter 8), S3 cross-Region replication (Chapter 10), Aurora Global Database আর DynamoDB global table (Chapter 7 আর 15), আর backup-and-restore থেকে active-active পর্যন্ত disaster recovery-র কৌশল (Chapter 23)।

#এক জায়গা থেকে আরেক জায়গায় data পাঠানো বিনামূল্যে না

একই AZ-এর ভেতরে private address দিয়ে data পাঠানো বিনামূল্যে। একই Region-এর দুই AZ-এর মধ্যে সাধারণত খরচ প্রতি দিকে প্রতি GB-তে $0.01, আর দুই Region-এর মধ্যে তার চেয়েও বেশি (প্রায়ই প্রতি GB-তে $0.02-এর মতো)। internet থেকে ভেতরে আসা data বিনামূল্যে; internet-এ বাইরে যাওয়া data-র জন্য টাকা লাগে। তবুও default হিসেবে Multi-AZ-ই ঠিক, শুধু মনে রেখো, যে ডিজাইনে AZ-এর মধ্যে হাজার হাজার ছোট ছোট call আসা-যাওয়া করে, সেটা bill-এ চমকে দিতে পারে। আগেভাগে এটা কীভাবে ধরবে, দেখাবে লেসন ১.৪।

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

# 1. Regions your account can use right now, and their opt-in status
aws ec2 describe-regions --all-regions \
  --query "Regions[].{Region:RegionName,Status:OptInStatus}" --output table
aws account get-region-opt-status --region-name ap-south-2

# 2. AZ names and AZ IDs in a Region: compare the ZoneId with a colleague’s account
aws ec2 describe-availability-zones --region ap-south-1 \
  --query "AvailabilityZones[].{Name:ZoneName,Id:ZoneId,State:State}" --output table

# 3. Local Zones and Wavelength Zones attached to a Region (opt-in status too)
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones \
  --query "AvailabilityZones[?ZoneType!='availability-zone'].{Name:ZoneName,Type:ZoneType,Group:GroupName,OptIn:OptInStatus}" \
  --output table

# 4. Is a service offered in a Region? (public parameters published by AWS)
aws ssm get-parameters-by-path --region us-east-1 \
  --path /aws/service/global-infrastructure/regions/ap-south-1/services \
  --query "Parameters[].Value" --output text | tr '\t' '\n' | sort | head -40

# 5. Rough latency from your machine to a few Regions (TCP connect time in seconds)
for r in ap-south-1 ap-southeast-1 eu-central-1 us-east-1; do
  printf "%-16s " $r
  curl -o /dev/null -s -w "%{time_connect}\n" https://ec2.$r.amazonaws.com
done

# 6. From inside an EC2 instance: which AZ name and which physical AZ ID am I in?
TOKEN=$(curl -sX PUT http://169.254.169.254/latest/api/token -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone; echo
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone-id; echo

সব Region, AZ আর edge location একটা ম্যাপে দেখতে খোলো infrastructure.aws। আর কোন Region-এ, কোন service-এ এই মুহূর্তে কী ঘটছে, দেখতে console-এর AWS Health Dashboard খোলো।

#সারকথা

মূল কথাগুলো

• AWS সাজানো কয়েক স্তরে: data centre → Availability Zone (এক বা একাধিক data centre, আলাদা, একে অপরের ১০০ km-এর মধ্যে, কম latency-র fibre-এ জোড়া) → Region (কমপক্ষে তিনটা AZ) → সঙ্গে ৭৫০-এর বেশি PoP আর ১৫টা regional edge cache নিয়ে একটা edge network।
• অক্টোবর ২০২৬-এ: ৩৯টা Region, ১২৪টা AZ। সাধারণ account দেখে ৩৪টা commercial Region; GovCloud (US), চীন আর European Sovereign Cloud আলাদা partition। ২০ মার্চ ২০১৯-এর পরে খোলা Region opt-in।
• Region code দেখতে ap-south-1-এর মতো; AZ-এর নামে একটা অক্ষর যোগ হয় (ap-south-1a)। নয়টা পুরনো Region-এ, নভেম্বর ২০২৫-এর আগে খোলা account-এ অক্ষরগুলো account ধরে এলোমেলো: এক account-এর সঙ্গে আরেক account মেলাতে AZ ID (aps1-az1) দেখো।
• Region বাছো এই ক্রমে: আগে নিয়মকানুন, তারপর latency, তারপর service আছে কি না, শেষে দাম। তুমি যে Region-এ রাখো, data সেখানেই থাকে।
• Global: IAM, Route 53, CloudFront, CloudFront-এ লাগানো WAF, Global Accelerator, Organizations। Regional: VPC, S3 bucket (নাম global), AMI, বেশির ভাগ service। Zonal: EC2 instance, EBS volume, subnet, NAT gateway।
• Local Zone (Region নেই এমন শহর), Wavelength (5G network) আর Outposts (তোমার নিজের ভবন) একটা parent Region-কে বাড়িয়ে নেয়; parent-এর সঙ্গে সংযোগ কাটলে চলতে থাকা কাজ টিকে যায়, কিন্তু পরিচালনা আটকে যায়।
• production চলে Multi-AZ-এ (এটাই “high availability”), সম্ভব হলে statically stable করে; দ্বিতীয় Region লাগে পুরো Region জুড়ে বিপদ, সারা পৃথিবীতে কম latency বা কয়েক দেশের data-র নিয়মের জন্য। AZ পেরোনো আর Region পেরোনো traffic-এ টাকা লাগে।

নিজেকে যাচাই করো: Region, Availability Zone আর edge৩০টি প্রশ্ন