রিজিয়ন হলো পৃথিবীর একটি নির্দিষ্ট ভৌগোলিক এলাকা (যেমন: উত্তর ভার্জিনিয়া, মুম্বাই বা টোকিও)। প্রতিটি রিজিয়ন একে অপরের থেকে সম্পূর্ণ আলাদা থাকে।
একটি রিজিয়নের ভেতরে থাকা এক বা একাধিক বিচ্ছিন্ন ডেটা সেন্টারকে বলা হয় Availability Zone। প্রতিটি জোনের নিজস্ব পাওয়ার, কুলিং এবং নেটওয়ার্কিং ব্যবস্থা থাকে।
এগুলো রিজিয়ন বা AZ-এর মতো বড় ডেটা সেন্টার নয়, বরং এগুলো ছোট ছোট সার্ভিস পয়েন্ট যা সারা বিশ্বের প্রধান শহরগুলোতে ছড়িয়ে আছে। এটি মূলত AWS-এর CDN (Content Delivery Network) যেটাকে Amazon CloudFront বলা হয়, তার জন্য কাজ করে।
একটি রিকোয়েস্ট ইউজার থেকে মেইন সার্ভার পর্যন্ত কীভাবে পৌঁছায়, তার ধাপগুলো নিচে দেওয়া হলো:
| ধাপ (Step) | অবস্থান ও প্রক্রিয়া (Process) | বর্ণনা (Description) |
|---|---|---|
| ১. User | আপনার ল্যাপটপ/মোবাইল | ইউজার কোনো ওয়েবসাইট বা ডাটার জন্য রিকোয়েস্ট পাঠায়। |
| ২. Edge Location | ইউজারের সবথেকে কাছের পয়েন্ট | এখানে চেক করা হয় ডাটা Cache করা আছে কি না। ✅ Cache Hit: এখান থেকেই ডাটা ফিরে যায়। ❌ Cache Miss: পরবর্তী ধাপে যায়। |
| ৩. Regional Cache | বড় ইন্টারমিডিয়েট স্টোরেজ | (ঐচ্ছিক) যদি Edge-এ না থাকে, তবে আঞ্চলিক ক্যাশ মেমোরিতে খোঁজা হয়। |
| ৪. AWS Region | মেইন জিওগ্রাফিক্যাল এরিয়া | রিকোয়েস্টটি মূল ক্লাউড রিজিয়নে প্রবেশ করে। |
| ৫. Availability Zone | নির্দিষ্ট ডেটা সেন্টার (AZ) | রিজিয়নের ভেতরে থাকা ফিজিক্যাল ডেটা সেন্টারে পৌঁছায়। |
| ৬. Main Server/DB | মেইন অ্যাপ্লিকেশন ও ডাটাবেস | আপনার কোড যেখানে রান করছে; এখান থেকে ফাইনাল ডাটা প্রসেস হয়। |
প্রো-টিপ: ওয়েবসাইট সুপার ফাস্ট করার জন্য CDN (Content Delivery Network) ব্যবহার করা হয়, যা এই Edge Location-কে কাজে লাগিয়ে কন্টেন্ট সার্ভ করে।
এটি অনেকটা “কাঁচা বাজার করে আনা”-র মতো। আপনি দোকান থেকে ময়দা, চিজ, সস কিনে আনলেন, কিন্তু রান্নাটা আপনাকেই করতে হবে।
সহজ কথা: ক্লাউড কোম্পানি আপনাকে শুধু ভার্চুয়াল কম্পিউটার (RAM, CPU, Hard Drive) এবং নেটওয়ার্ক দিবে।
আপনার কাজ: এই কম্পিউটারে কোন অপারেটিং সিস্টেম (Windows বা Linux) চলবে, কী সফটওয়্যার ইন্সটল হবে, সিকিউরিটি কেমন হবে—সব আপনাকে ঠিক করতে হবে।
AWS উদাহরণ: EC2 (Elastic Compute Cloud)। এটি একটি খালি কম্পিউটারের মতো।
এটি অনেকটা “পিৎজা হোম ডেলিভারি”-র মতো। আপনার নিজের রান্না করার দরকার নেই, ওভেন বা গ্যাসেরও দরকার নেই। শুধু অর্ডার দিবেন আর টেবিল সাজিয়ে খাবেন।
সহজ কথা: এখানে আপনাকে কোনো সার্ভার বা অপারেটিং সিস্টেম মেইনটেইন করতে হয় না। আপনি শুধু আপনার তৈরি করা কোড (Code) আপলোড করবেন, বাকি সব ক্লাউড নিজে সামলাবে।
আপনার কাজ: শুধু কোড লেখা এবং ডাটা ম্যানেজ করা।
AWS উদাহরণ: AWS Elastic Beanstalk। আপনি কোড দিলে এটি নিজে থেকেই সার্ভার রেডি করে রান করে দেয়।
এটি হলো “রেস্টুরেন্টে গিয়ে পিৎজা খাওয়া”-র মতো। আপনার রান্নার চিন্তা নেই, টেবিল পরিষ্কার করারও চিন্তা নেই। শুধু যাবেন, খাবেন আর বিল দিয়ে চলে আসবেন।
সহজ কথা: এটি একটি তৈরি করা সফটওয়্যার যা আপনি ইন্টারনেটের মাধ্যমে ব্যবহার করেন। আপনাকে কিছুই ইন্সটল বা কোড করতে হয় না।
আপনার কাজ: শুধু সফটওয়্যারটি ব্যবহার করা।
উদাহরণ: Gmail, Netflix, Facebook, বা AWS-এর ক্ষেত্রে Amazon Chime বা AWS SES।
IAM-এর ৪টি প্রধান পিলার বা ‘Under-the-hood’ মেকানিক্স সহজভাবে দেওয়া হলো:
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::my-photo-bucket"
}
উদাহরণ: আপনার একটি সার্ভার (EC2) আছে যেটিকে S3 থেকে ছবি ডাউনলোড করতে হবে। আপনি সার্ভারের ভেতর আপনার পাসওয়ার্ড লিখে রাখবেন না (সেটা রিস্কি)। বরং আপনি একটি Role বানাবেন এবং সার্ভারকে বলবেন, “তুমি এই রোলে ছদ্মবেশ ধরো এবং কাজ শেষ করো।”
রুট ইউজার হলো অ্যাকাউন্টের মালিক, যার কাছে বিলিং এবং অ্যাকাউন্ট ডিলিট করার ক্ষমতা থাকে। রুট ইউজারকে কোনো পলিসি দিয়ে আটকানো যায় না। অন্যদিকে, IAM Administrator হলো একজন ইউজার যাকে অ্যাডমিন ক্ষমতা দেওয়া হয়েছে, কিন্তু তাকে চাইলে অন্য কেউ বা রুট ইউজার ব্লক করতে পারে।
এটি ক্লাউড সিকিউরিটির মূল মন্ত্র। এর মানে হলো, একজন ইউজারকে ঠিক ততটুকুই পারমিশন দেওয়া যতটুকু তার কাজের জন্য প্রয়োজন। যেমন: যদি কেউ শুধু ফাইল পড়তে চায়, তাকে ReadOnly এক্সেস দিতে হবে, FullAccess নয়।
User হলো একজন নির্দিষ্ট ব্যক্তি বা পার্মানেন্ট এনটিটি যার নির্দিষ্ট পাসওয়ার্ড বা কি (key) থাকে। আর Role হলো অস্থায়ী (Temporary)। যখন কোনো সার্ভিস (যেমন EC2) অন্য কোনো সার্ভিসকে (যেমন S3) কল করতে চায়, তখন আমরা Role ব্যবহার করি কারণ এটি বেশি সিকিউর এবং এতে কোনো পাসওয়ার্ড হার্ডকোড করে রাখতে হয় না।
সাথে সাথে AWS কনসোলে গিয়ে ওই Access Key-টিকে Deactivate বা Delete করতে হবে। এরপর একটি নতুন কি জেনারেট করতে হবে।
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation",
"s3:ListBucket",
"s3:GetObject",
"s3:PutObject"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"s3:DeleteObject",
"s3:DeleteBucket"
],
"Resource": "*"
}
]
}
Version: এটি AWS-এর পলিসি ল্যাঙ্গুয়েজ ভার্সন।
Effect: Allow: এখানে আমরা আরিফকে কিছু ক্ষমতা দিচ্ছি।:
ListAllMyBuckets: সে দেখতে পারবে আপনার অ্যাকাউন্টে কয়টি বাকেট আছে।
GetObject: সে ফাইল ডাউনলোড বা ওপেন করতে পারবে।
PutObject: সে নতুন ফাইল আপলোড করতে পারবে।
DeleteObject ও DeleteBucket: আমরা সরাসরি বলে দিলাম, সে যেন ভুলেও কিছু Delete করতে না পারে।
যদি আরিফের গ্রুপে ‘Allow’ থাকেও, এই ‘Deny’ থাকা মানে সে আর ডিলিট করতে পারবে না। (Explicit Deny always wins!)
“এর ৩টি প্রধান কারণ থাকতে পারে:
Missing ListBucket Permission: অনেক সময় ফাইল আপলোড করার আগে কনসোল চেক করে ওই বাকেটটি আছে কি না। ListBucket পারমিশন না থাকলে সে বাকেটের ভেতরেই ঢুকতে পারবে না।
KMS Encryption: যদি বাকেটটি এনক্রিপ্টেড থাকে, তবে আরিফের কাছে ওই ডাটা এনক্রিপ্ট করার (KMS Key) পারমিশনও থাকতে হবে।
S3 Bucket Policy: IAM-এ পারমিশন থাকলেও, যদি ওই নির্দিষ্ট S3 বাকেটের নিজস্ব Bucket Policy-তে আরিফকে ব্লক করা থাকে, তবে সে এক্সেস পাবে না।”
IAM Role: এটি কোনো নির্দিষ্ট ব্যক্তির জন্য নয়। এটি একটি অস্থায়ী (Temporary) সত্তা। যখন কোনো সার্ভিস (যেমন EC2) বা বাইরের কোনো ইউজারকে সাময়িকভাবে কোনো পারমিশন দিতে হয়, তখন Role ব্যবহার করা হয়। রোলের কোনো পাসওয়ার্ড থাকে না, এটি ‘Sts:AssumeRole’ মেকানিজম ব্যবহার করে।
দুইটি উপায়ে করা যায়:
"Least Privilege" বলতে কী বোঝেন এবং এটি কীভাবে ইমপ্লিমেন্ট করবেন?'Full Access' না দিয়ে কাস্টম JSON পলিসি তৈরি করব এবং নির্দিষ্ট API Action (যেমন শুধু s3:GetObject) এলাউ করব।Access Key-টিকে Deactivate বা Rotate করব যাতে সেটা দিয়ে আর কাজ না হয়।CloudTrail লগ চেক করব যে ওই লিক হওয়া কি (key) দিয়ে কোনো অবৈধ কাজ করা হয়েছে কি না।'Dev-Group' বানিয়ে সেখানে পলিসি দেওয়া অনেক বেশি Scalable। এতে ভুলের সম্ভাবনা কমে এবং নতুন কেউ জয়েন করলে দ্রুত এক্সেস দেওয়া যায়।