Cloud ব্যবহারের পথ — console, CLI, API, account আর খরচের নিরাপত্তা

১ · সব পথ একই দরজায় — cloud-এ সবকিছুই API

আগের পর্বগুলোতে দেখেছি cloud মানে ভাড়ার কম্পিউটার, আর সেগুলো পৃথিবীর নানা region-এ ছড়ানো। কিন্তু একটি সহজ প্রশ্ন বাকি: আপনি সেই ভাড়ার কম্পিউটারের সাথে কথা বলবেন কীভাবে? আপনি তো data center-এ গিয়ে তার লাগাতে পারবেন না।

Cloud ব্যবহারের প্রধান পথ চারটি। এদের পার্থক্য শুধু এটুকুই: অনুরোধটি কে আর কীভাবে তৈরি করছে।

এখানে দুটি শব্দ মনে রাখুন। Control plane হলো cloud-এর ব্যবস্থাপনার অংশ: কোন VM কোথায় বসবে, তার রেকর্ড কী। Data plane হলো যেখানে আসল কাজ চলে: VM-এর ভেতরে আপনার প্রোগ্রাম, disk-এ ডেটা পড়া-লেখা। Control plane সাময়িক বিকল হলে নতুন VM বানানো নাও যেতে পারে, অথচ চলতে থাকা VM প্রায়ই চলতেই থাকে। এই ভাগটি পরে Kubernetes-এও ফিরে আসবে (পর্ব ৪২)।

এবার একটি ক্লিকের পুরো যাত্রা দেখি। নাদিয়া একটি পরীক্ষার VM বানাতে চান। “পরে” চেপে এগোন, আর প্রতিটি ধাপে VM-এর অবস্থা আর বিলের ঘর খেয়াল করুন।

২ · একটি API call-এর ভেতরে — চিঠি, স্বাক্ষর আর ঘড়ি

Cloud API মূলত HTTP অনুরোধ, যার বিস্তারিত আছে HTTP-র পর্বে, আর পথে থাকে TLS-এর সুরক্ষায়। নিচের অনুরোধটি শেখার জন্য বানানো একটি কাল্পনিক provider-এর। কোনো আসল provider-এর ফরম্যাট হুবহু এমন নয়, তবে ধারণা একই।

POST /v1/instances HTTP/1.1
Host: compute.region-a.example-cloud.test
Content-Type: application/json
X-Cloud-Date: 20261030T101500Z
X-Idempotency-Token: demo-0001
Authorization: SIGN-V1 key=AKEXAMPLEKEY, signature=9f2c...e41a

{"name":"demo-vm","size":"small","zone":"zone-a","tags":{"owner":"nadia","env":"test"}}

প্রতিটি লাইনের একটি কাজ আছে। Host-এর ভেতরে region আছে। Body-তে কাঙ্ক্ষিত জিনিস। X-Cloud-Date অনুরোধের সময় জানায়। আর Authorization প্রমাণ করে অনুরোধটি কে পাঠিয়েছে।

Client আর server দুজনের কাছেই একই secret থাকে। Client অনুরোধের গুরুত্বপূর্ণ অংশগুলো (method, path, সময়, body-র hash) জুড়ে secret দিয়ে HMAC হিসাব করে, আর ফলটি পাঠায়। Server একই হিসাব নিজে করে মিলিয়ে দেখে। Secret নিজে কখনো পথে যায় না। Runnable উদাহরণটি একটি খেলনা scheme, কিন্তু তিনটি মূল গুণ দেখায়।

# Signing a request: the secret proves identity but never travels.
# Toy scheme for learning; real providers define their own exact format.
import hashlib, hmac

SECRET = b"fake-secret-for-learning-only"      # stays on the client and the server

def sign(method, path, date, body):
    text = "\n".join([method, path, date, hashlib.sha256(body).hexdigest()])
    return hmac.new(SECRET, text.encode(), hashlib.sha256).hexdigest()

def server_accepts(method, path, date, body, signature, now):
    if abs(now - int(date)) > 300:             # allow a 5-minute clock window
        return "rejected: request too old"
    expected = sign(method, path, date, body)
    same = hmac.compare_digest(expected, signature)
    return "accepted" if same else "rejected: signature mismatch"

body = b'{"name":"demo-vm","size":"small"}'
date = "1000"                                  # simulated clock, in seconds
sig = sign("POST", "/v1/instances", date, body)
print("signature :", sig[:16] + "...")

print("honest    :", server_accepts("POST", "/v1/instances", date, body, sig, 1010))
changed = body.replace(b"small", b"large")     # body altered on the way
print("altered   :", server_accepts("POST", "/v1/instances", date, changed, sig, 1010))
print("old replay:", server_accepts("POST", "/v1/instances", date, body, sig, 2000))

সব provider প্রতিটি অনুরোধে এভাবে স্বাক্ষর করে না। প্রধান ধরন দুটি:

আপনাকে নিজে এসব হিসাব করতে হবে না। CLI আর SDK credential খুঁজে নেয়, অনুরোধ sign করে, অনেক ক্ষেত্রে retry-ও করে। কিন্তু ভেতরের ছবিটি জানা থাকলে SignatureDoesNotMatch বা token expired ধরনের error দেখে আর ঘাবড়াবেন না।

৩ · ঠিকানা — resource, identifier আর region

Cloud-এ VM, disk, network, bucket, সবই একেকটি resource. প্রতিটি resource-এর একটি অনন্য পরিচয় থাকে, ঠিক ডাকের ঠিকানার মতো: বাড়ি, রোড, থানা, জেলা। পুরো ঠিকানা ছাড়া শুধু “৫ নম্বর বাড়ি” বললে চিঠি হারাবে। নিচের তিনটি একই ধরনের ঠিকানা, তিন provider-এর ভাষায়। সব id ভুয়া।

# AWS: ARN (Amazon Resource Name)
arn:aws:ec2:ap-south-1:123456789012:instance/i-0123456789abcdef0

# Azure: resource ID
/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/demo-rg/providers/Microsoft.Compute/virtualMachines/demo-vm

# Google Cloud: resource URL
https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/asia-south1-a/instances/demo-vm

তিনটির ভেতরেই চারটি অংশ খুঁজে পাবেন: কোন সার্ভিস (ec2, Microsoft.Compute, compute), কার জিনিস (account, subscription, project), কোথায় (region বা zone), আর কোনটি (ধরন ও নাম)। Azure-এর উদাহরণে location নেই, কারণ সেখানে অবস্থান resource-এর একটি বৈশিষ্ট্য, ঠিকানার অংশ নয়।

৪ · Account খোলা — প্রথম দিনের নিরাপত্তা

যে email দিয়ে account খোলেন, সেটি সাধারণত সর্বোচ্চ ক্ষমতা পায়। এই পরিচয়টিকে বলে root বা owner account. এটি সব resource মুছতে পারে, বিল বদলাতে পারে, এমনকি account বন্ধ করতে পারে। আর এর ঠিক পরেই চলে আসে প্রতিদিনের সবচেয়ে বড় ভুল: সব কাজ এই account দিয়ে করা।

তিনটির গঠন হুবহু এক নয়, তাই টেবিলটিকে মোটামুটি মিল হিসেবে পড়ুন। নতুন account-এ এই ক্রমে এগোন:

1. আলাদা email আর শক্ত password. Password manager ব্যবহার করুন। মনে রাখবেন, এই email হাতছাড়া হলে account recovery-র পথও হাতছাড়া হয়; তাই email-এও দ্বিতীয় ধাপের যাচাই চালু রাখুন।
2. Root-এ MFA. MFA (Multi-Factor Authentication) মানে password-এর সাথে আরেকটি প্রমাণ: authenticator app বা hardware key. SMS-এর চেয়ে এগুলো নিরাপদ। অনেক provider ধাপে ধাপে MFA বাধ্যতামূলক করছে, তবে নিয়মের অপেক্ষায় না থেকে নিজে চালু করুন। Recovery code কাগজে লিখে নিরাপদ জায়গায় রাখুন।
3. Budget alert, প্রথম resource-এর আগেই। পরের অংশে বিস্তারিত।
4. দৈনন্দিন কাজের আলাদা identity. সীমিত অনুমতি দিন, এটিই least privilege. Root দিয়ে access key বানাবেন না। আসল IAM আসবে পর্ব ৩১-এ।
5. Root বন্ধ করে রাখা। এরপর শুধু সেই কাজে root-এ ঢুকুন, যা অন্য কেউ পারে না, যেমন account বন্ধ করা।

৫ · খরচের নিরাপত্তা — budget alert, free tier আর পরিচ্ছন্নতা

Cloud-এর বিল বিদ্যুৎ বিলের মতো: যতক্ষণ চলবে, ততক্ষণ মিটার ঘুরবে। পার্থক্য হলো ঘরের বাতি জ্বললে চোখে পড়ে, আর region-এর এক কোণে চলতে থাকা একটি VM চোখে পড়ে না।

Budget alert হলো একটি নিয়ম: খরচ বা পূর্বাভাস একটি সীমা ছাড়ালে email বা বার্তা যাবে। দুটি কথা জেনে রাখুন। এক, এটি সাধারণত শুধু সতর্ক করে, খরচ থামায় না। দুই, বিলের তথ্য আসতে কয়েক ঘণ্টা বা তার বেশি দেরি হতে পারে, তাই alert বাস্তবের একটু পেছনে থাকে। সেজন্য প্রকৃত খরচের alert-এর সাথে পূর্বাভাসের alert-ও রাখুন।

Free tier-এর ফাঁদ

Free tier মানে নির্দিষ্ট সীমা পর্যন্ত বিনা খরচে ব্যবহার। শর্তগুলো provider-ভেদে আলাদা, আর সময়ের সাথে বদলায়; লেখার সময়ে যা ঠিক, পরে নাও থাকতে পারে। তাই সবসময় provider-এর বর্তমান পাতা দেখুন। সাধারণ ফাঁদগুলো হলো:

• সীমার বাইরে গেলে সাধারণ দর। একটি নির্দিষ্ট আকারের VM বিনা খরচে হলেও পরের আকারটি নাও হতে পারে।
• মেয়াদ শেষ। কিছু সুবিধা বা credit নির্দিষ্ট সময় পরে ফুরায়। মেয়াদ শেষে resource মুছে যায় না, হয় বিল আসে নয়তো সেটি বন্ধ হয়; provider-এর নিয়ম দেখে নিন।
• লুকানো সঙ্গী। VM-এর সাথে disk, public IP, snapshot, log, NAT gateway বা load balancer-এর খরচ থাকতে পারে।
• Data transfer. Cloud থেকে বাইরে ডেটা পাঠানোর খরচ অনেকের হিসাবে থাকে না (পর্ব ৭২)।

Stop করা আর Delete করা এক নয়

এবার একটি ভুলের পুরো মাস দেখি। রাফি মাসে প্রায় $১২ খরচের একটি ছোট lab চালান, budget $৩০। এখানে সব দর ধরে নেওয়া গোল সংখ্যা, আসল নয়: VM ঘণ্টায় $০.১০, ৯০ GB disk প্রতি GB-মাসে $০.১০, public IP ঘণ্টায় $০.০০৫। অর্থাৎ VM দিনে $২.৪০, disk দিনে $০.৩০, IP দিনে $০.১২; মোট দিনে $২.৮২ বাড়তি।

এই হিসাবটি নিজে চালিয়ে দেখুন। প্রতিদিনের খরচ থেকে প্রোগ্রামটি মোট খরচ, গত ৭ দিনের গড় আর মাস-শেষের পূর্বাভাস বের করে। সূত্রটি সরল: পূর্বাভাস = এ পর্যন্ত খরচ + (গত ৭ দিনের গড় × বাকি দিন)।

// Budget alerts from daily spend. All prices are assumed round numbers, not real ones.
const BUDGET = 30, MONTH = 30;
const NORMAL = 0.40;                      // $ per day, the planned small lab
const LEAK = 2.40 + 0.30 + 0.12;          // forgotten VM + disk + public IP, from day 9
const daily = Array.from({ length: MONTH }, (_, i) => NORMAL + (i + 1 >= 9 ? LEAK : 0));

const fired = new Set();
function alarm(day, key, text) {
  if (fired.has(key)) return;
  fired.add(key);
  console.log(`  >> day ${day}: ALERT ${text}`);
}

let spent = 0;
console.log('day  spent  avg7  forecast');
for (let day = 1; day <= MONTH; day++) {
  spent += daily[day - 1];
  const last7 = daily.slice(Math.max(0, day - 7), day);
  const avg7 = last7.reduce((a, b) => a + b, 0) / last7.length;
  const forecast = spent + avg7 * (MONTH - day);        // spent so far + remaining days
  if ([8, 9, 10, 12, 15, 17, 30].includes(day))
    console.log(String(day).padStart(3), spent.toFixed(2).padStart(6),
      avg7.toFixed(2).padStart(5), forecast.toFixed(2).padStart(8));
  if (forecast > BUDGET) alarm(day, 'forecast', `forecast $${forecast.toFixed(2)} > budget $${BUDGET}`);
  for (const pct of [50, 80, 100])
    if (spent >= BUDGET * pct / 100) alarm(day, pct, `actual spend reached ${pct}% ($${spent.toFixed(2)})`);
}
console.log(`planned month: $${(NORMAL * MONTH).toFixed(2)} | with the leak: $${spent.toFixed(2)}`);

প্রথম দিন থেকেই tag

Tag হলো resource-এর গায়ে লাগানো key-value লেবেল, যেমন owner=rafi, env=test, expires=2026-11-05. গুদামঘরে প্রতিটি বস্তায় মালিকের নাম লেখা থাকলে যেমন পরে খুঁজতে সহজ হয়, এটিও তেমন। Tag থাকলে আপনি “এই resource কার, আদৌ দরকার কি না” এক কমান্ডে বের করতে পারেন, আর বিল ভাগ করে দেখতে পারেন। ছোট্ট একটি নিয়ম রাখুন: owner আর env ছাড়া কিছু বানাবেন না, আর পরীক্ষার resource-এ expires তারিখ দিন। পরে tag বসানো অনেক কঠিন, কারণ তখন কেউ মনে রাখে না কোনটি কার। Google Cloud-এ এই লেবেলের নাম সাধারণত label; সেখানে “tag” শব্দটির অন্য অর্থও আছে। Governance আর FinOps-এ এর বিস্তার দেখবেন পর্ব ৩৫ ও ৭৩-এ।

পরিচ্ছন্নতার অভ্যাস: পরীক্ষা শুরু করার আগেই ঠিক করুন কীভাবে শেষ করবেন। একটি group বা project-এর ভেতরে সব বানান, যাতে এক কাজে সব মোছা যায়। শেষে তিনটি জায়গা মিলিয়ে দেখুন: resource-এর তালিকা, সব region, আর পরদিনের বিল।

৬ · চাবি — long-lived key বনাম short-lived credential

CLI বা script চালাতে একটি প্রমাণ লাগে। ধরন দুটি। এখানে শুধু প্রথম পরিচয়; গভীর আলোচনা পর্ব ৩১-এ।

তাই সাধারণ নিয়ম: মানুষের কাজে SSO বা aws sso login, az login, gcloud auth login ধরনের login-ভিত্তিক সাময়িক credential; cloud-এর ভেতরের VM বা function-এ attached role বা managed identity; আর pipeline-এ OIDC (পর্ব ৬১)। স্থায়ী key একেবারে না পারলে তবেই, আর তখনো কম অনুমতি দিয়ে। Secret সংরক্ষণের সঠিক পথ পর্ব ৩৩-এ।

Key সবচেয়ে বেশি ফাঁস হয় খুব সাধারণ ভুলে: Git-এ commit করা .env ফাইল, screenshot, ব্লগের উদাহরণ, chat-এর বার্তা, বা AI-কে পেস্ট করা কোড। এর প্রতিরোধ আছে Git-এর নিরাপত্তার পর্বে। ফাঁস হয়ে গেলে কী করবেন, সেটি শান্ত মাথায় আগেই জেনে রাখুন। নিচের ঘটনাটি কাল্পনিক, আর পুরোটাই প্রতিরক্ষার দিক থেকে।

৭ · API-র সাথে ভদ্র ব্যবহার — pagination, rate limit, retry আর idempotency

Script লিখলে আপনি আর ক্লিক করা মানুষ নন, একটি দ্রুত প্রোগ্রাম। তখন চারটি বিষয় না জানলে এমন bug হয়, যা ছোট পরীক্ষায় ধরা পড়ে না কিন্তু production-এ ঠিকই কামড়ায়।

Pagination: প্রথম পাতাই সব নয়

List API একবারে সব ফেরত দেয় না, এক “পাতা” দেয়, সাথে পরের পাতার চিহ্ন (nextToken বা তার মতো কিছু)। একে বলে pagination. রেলের লম্বা সময়সূচির বইয়ের মতো: প্রথম পাতায় ট্রেন না পেলে ট্রেনটি নেই, তা নয়। Token খালি হওয়া পর্যন্ত পড়ে যেতে হয়। CLI অনেক ক্ষেত্রে নিজে সব পাতা পড়ে, কিন্তু SDK-তে আপনাকে paginator ব্যবহার করতে হতে পারে। প্রথম পাতা গুনে “মোট ১০০০টি resource” বলা একটি ক্লাসিক bug.

Rate limit: দরজায় ভিড়

একজন গ্রাহক যেন অন্যদের আটকে না দেন, তাই API একটি সীমা রাখে; একে rate limit বা throttling বলে। সীমা ছাড়ালে সাধারণত HTTP 429 Too Many Requests বা provider-এর নিজের throttling error আসে, কখনো Retry-After header সহ। সীমার সংখ্যা provider আর API-ভেদে আলাদা।

Retry: কখন আবার চেষ্টা করবেন

Network-এ ব্যর্থতা স্বাভাবিক ঘটনা। তবে সব ব্যর্থতা retry-র যোগ্য নয়।

অপেক্ষার সঠিক নিয়ম exponential backoff: প্রতিবার অপেক্ষা দ্বিগুণ, একটি সর্বোচ্চ সীমা পর্যন্ত। সাথে jitter: সেই অপেক্ষায় এলোমেলোভাবে কম-বেশি করা। সূত্র (full jitter): wait = random(0, min(cap, base × 2^n)). Jitter কেন লাগে? ঈদের আগে টিকিট কাউন্টার ১০টায় খুললে সবাই একসাথে ঝাঁপিয়ে পড়ে। সবাইকে ১০:১০-এ আবার আসতে বললে ভিড় শুধু সরে যায়, কমে না। এই একসাথে হামলাকে thundering herd বলে। নিচের সিমুলেটরে ৩০টি client একসাথে সীমায় ধাক্কা খায়; server প্রতি slot-এ (১০০ ms) মাত্র ৪টি অনুরোধ নিতে পারে।

// 30 clients all hit a rate limit together. Server: 4 requests per slot (1 slot = 100 ms).
function mulberry32(a) {
  return () => { a |= 0; a = a + 0x6D2B79F5 | 0;
    let t = Math.imul(a ^ a >>> 15, 1 | a);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
    return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const CLIENTS = 30, CAP = 4, BASE = 4, MAX_WAIT = 64;   // BASE, MAX_WAIT in slots
const expWait = n => Math.min(MAX_WAIT, BASE * 2 ** n);

function simulate(name, waitFor) {
  const rng = mulberry32(42);
  let queue = Array.from({ length: CLIENTS }, () => ({ at: 0, tries: 0 }));
  let calls = 0, retryPeak = 0, rejected = 0, finish = 0;
  for (let t = 0; queue.length > 0; t++) {
    const now = queue.filter(c => c.at === t);
    queue = queue.filter(c => c.at !== t);
    calls += now.length;
    if (t > 0) retryPeak = Math.max(retryPeak, now.length);
    now.forEach((c, i) => {
      if (i < CAP) { finish = t; return; }        // served
      rejected++;                                 // HTTP 429, try again later
      c.at = t + Math.max(1, waitFor(c.tries++, rng));
      queue.push(c);
    });
  }
  console.log(name.padEnd(26), String(calls).padStart(5), String(rejected).padStart(8),
    String(retryPeak).padStart(9), String(finish).padStart(7));
}
console.log('strategy                   calls rejected retryPeak  finish');
simulate('fixed wait, 4 slots', () => 4);
simulate('exponential', n => expWait(n));
simulate('exponential + full jitter', (n, rng) => Math.floor(rng() * (expWait(n) + 1)));

Idempotency: একবার চাইলে একটিই

সবচেয়ে সূক্ষ্ম সমস্যাটি এখানে। আপনি VM তৈরির অনুরোধ পাঠালেন, উত্তর এলো না। VM কি তৈরি হয়েছে? জানেন না। অনুরোধ হারিয়ে থাকতে পারে, আবার উত্তর-ও হারিয়ে থাকতে পারে। আবার পাঠালে দুটি VM আর দ্বিগুণ বিল হতে পারে। না পাঠালে হয়তো একটিও নেই।

সমাধান idempotency: একই কাজ বারবার করলেও ফল একবার করার সমান। কীভাবে? Client একটি অনন্য idempotency token বানিয়ে অনুরোধে পাঠায়, আর retry-তে একই token পাঠায়। Server token চিনে আগের ফলটিই ফেরত দেয়। মোবাইল ওয়ালেটে টাকা পাঠাতে গিয়ে নেটওয়ার্ক চলে গেলে কি আবার পাঠাবেন? ব্যবস্থাটি যদি প্রতিটি লেনদেনের একটি নম্বর মনে রাখে, তবে একই নম্বরে দ্বিতীয়বার টাকা কাটা হবে না; ধারণাটি এমনই।

নিচের খেলনা API-তে create, list আর delete আছে, memory-তেই চলে। Token-এর কাজ আর pagination দুটোই এখানে দেখা যাবে।

// Toy in-memory cloud API: Create, List (pagination), Delete, idempotency token.
const db = new Map();      // id -> resource
const seen = new Map();    // token -> id it already created
let nextId = 1;
function api(action, p = {}) {
  if (action === 'Create') {
    if (p.token && seen.has(p.token)) return { id: seen.get(p.token), replay: true };
    const id = 'vm-' + String(nextId++).padStart(4, '0');
    db.set(id, { id, name: p.name });
    if (p.token) seen.set(p.token, id);
    return { id, replay: false };
  }
  if (action === 'List') {
    const ids = [...db.keys()].sort().filter(i => !p.after || i > p.after);
    const page = ids.slice(0, p.limit);
    return { items: page, next: ids.length > p.limit ? page[page.length - 1] : null };
  }
  if (action === 'Delete') return db.delete(p.id) ? { ok: true } : { error: 'NotFound' };
}
// 1) The first reply was lost; the client sends the same request again.
const a = api('Create', { name: 'web', token: 'tok-A' }), b = api('Create', { name: 'web', token: 'tok-A' });
console.log('with token   :', a.id, '| retry ->', b.id, 'replay =', b.replay);
const c = api('Create', { name: 'web' }), d = api('Create', { name: 'web' });
console.log('without token:', c.id, '| retry ->', d.id, '(a duplicate VM!)');
// 2) Five more VMs, then read everything, 3 per page.
for (let i = 0; i < 5; i++) api('Create', { name: 'batch' + i });
let after = null, pageNo = 0, total = 0;
do {
  const r = api('List', { limit: 3, after });
  console.log('page', ++pageNo, r.items.join(' '), '| next =', r.next);
  total += r.items.length; after = r.next;
} while (after);
console.log('total VMs =', total, '| first page alone showed only 3');
// 3) Delete twice: the end state is the same, the second reply differs.
console.log(api('Delete', { id: 'vm-0002' }), api('Delete', { id: 'vm-0002' }));

HTTP-তে GET, PUT, DELETE সংজ্ঞায় idempotent, POST নয়। তাই নতুন কিছু বানানোর POST-এ token সবচেয়ে জরুরি। একই ধারণা পর্ব ৫১-তে IaC-তে আর পর্ব ৭১-এ serverless-এ ফিরে আসবে। Retry-র ঝুঁকির গভীর আলোচনা আছে System Design-এর resilience patterns পর্বে।

৮ · তিন provider-এ একই কাজ — CLI পাশাপাশি

ধারণা একই, শুধু ভাষা আলাদা। নিচের উদাহরণগুলো চালানোর জন্য নয়, পড়ে তুলনা করার জন্য। সব id ভুয়া। সত্যিই চালালে টাকা খরচ হতে পারে, আর region, image, size-এর নাম সময়ের সাথে বদলায়; provider-এর বর্তমান ডকুমেন্টেশন দেখে নিন। প্রতিটি ট্যাবে তিনটি কাজ আছে: tag-সহ VM তৈরি, tag দিয়ে তালিকা, আর পরিষ্কার।

# Create (client-token makes a retry safe)
aws ec2 run-instances \
  --region ap-south-1 \
  --image-id ami-0123456789abcdef0 \
  --instance-type t3.micro \
  --subnet-id subnet-0123456789abcdef0 \
  --client-token demo-0001 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=owner,Value=nadia},{Key=env,Value=test}]'

# List by tag
aws ec2 describe-instances --region ap-south-1 \
  --filters "Name=tag:env,Values=test" \
  --query "Reservations[].Instances[].[InstanceId,State.Name]" \
  --output table

# Clean up
aws ec2 terminate-instances --region ap-south-1 \
  --instance-ids i-0123456789abcdef0

# Everything goes into one resource group
az group create --name demo-rg --location centralindia

# Create
az vm create \
  --resource-group demo-rg \
  --name demo-vm \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --tags owner=nadia env=test

# List
az vm list --resource-group demo-rg --output table

# Clean up: the whole group, with its disk, NIC and IP
az group delete --name demo-rg --yes

# Create (Google Cloud calls these labels)
gcloud compute instances create demo-vm \
  --project=example-project-123456 \
  --zone=asia-south1-a \
  --machine-type=e2-micro \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud \
  --labels=owner=nadia,env=test

# List by label
gcloud compute instances list \
  --project=example-project-123456 \
  --filter="labels.env=test"

# Clean up
gcloud compute instances delete demo-vm \
  --project=example-project-123456 \
  --zone=asia-south1-a --quiet

লক্ষ করুন, AWS-এর উদাহরণে --client-token সরাসরি আছে। Azure-এ VM-এর নামই পরিচয়, একই নামে একই অনুরোধ আবার পাঠালে নতুন VM হওয়ার বদলে আগেরটিকেই মিলিয়ে দেখা হয়। Google Cloud Compute API-তে এর সমতুল্য একটি requestId আছে। Provider তিনটি, সমস্যা একটিই।

৯ · AI-এর যুগে cloud কমান্ড — যাচাই না করে চালাবেন না

AI খুব দ্রুত CLI কমান্ড আর script লিখে দেয়। কিন্তু cloud-এ একটি ভুল কমান্ড শুধু error দেয় না; টাকা খরচ করে, ডেটা মোছে, বা দরজা খোলা রেখে দেয়। আর AI জানে না আপনার account-এ কী আছে।

AI-এর দেওয়া cloud কমান্ড চালানোর আগে — চেকলিস্ট

• প্রতিটি flag --help বা সরকারি ডকুমেন্টে দেখে নিয়েছি
• কোন account আর কোন region-এ চালাচ্ছি তা নিশ্চিত করেছি
• সম্ভব হলে dry-run বা plan চালিয়ে পরিবর্তন পড়েছি
• অনুমতি, খোলা port আর public access আলাদাভাবে মিলিয়ে দেখেছি
• Budget alert চালু আছে, আর resource-এ owner ও env tag আছে
• মুছে ফেলার কমান্ড আগেই জানি, আর চালানোর পরে তালিকা মিলিয়ে দেখব
• Prompt-এ কোনো আসল secret পেস্ট করিনি