ক্লাউড কম্পিউটিং — IaaS, PaaS আর SaaS

১ · জেনারেটর নয়, বিদ্যুতের লাইন — ক্লাউড কম্পিউটিং কী

লোডশেডিংয়ের দিনে অনেক দোকান আর কারখানা নিজের জেনারেটর চালাত। জেনারেটর কিনতে অনেক টাকা, তেল কিনতে হয়, মিস্ত্রি রাখতে হয়, নষ্ট হলে সারাতে হয়। আর জেনারেটরের ক্ষমতা নির্দিষ্ট — বিয়ের অনুষ্ঠানে হঠাৎ বেশি বাতি লাগলে কুলায় না, আবার রাতে দোকান বন্ধ থাকলেও কেনার টাকাটা আটকে থাকে। বিদ্যুতের লাইনে এসব ঝামেলা নেই: সুইচ টিপলেই বিদ্যুৎ, মিটারে যতটুকু খরচ ততটুকু বিল, আর বিদ্যুৎকেন্দ্র চালানোর দায় অন্য কারও।

কম্পিউটিংয়েও একই পরিবর্তন ঘটেছে। একটি প্রতিষ্ঠান আগে নিজের অফিসে সার্ভার কিনে রাখত — নিজের ঘর, নিজের এসি, নিজের IT কর্মী। একে বলে on-premise (নিজের প্রাঙ্গণে)। এখন বেশিরভাগ নতুন প্রতিষ্ঠান সেই সার্ভার ভাড়া নেয় ইন্টারনেট দিয়ে — এটাই ক্লাউড কম্পিউটিং.

পর্ব ১৪-এ আপনি ক্লাউডকে দেখেছেন ব্যবহারকারীর চোখে — Google Drive-এ ফাইল রাখা, একসাথে Docs-এ লেখা। এই পর্বে আমরা যাব পর্দার পেছনে: যে প্রতিষ্ঠান অ্যাপ বা ওয়েবসাইট চালায়, সে ক্লাউড থেকে ঠিক কী ভাড়া নেয়, কীভাবে নেয়, আর কোথায় সাবধান থাকতে হয়। পর্ব ৩৪-এ দেখেছেন ওয়েবসাইট হোস্টিং; সেই হোস্টিং-ও আজ বেশিরভাগ ক্ষেত্রে কোনো ক্লাউডের ওপর চলে।

আনুষ্ঠানিক সংজ্ঞা — NIST

সবচেয়ে বেশি উদ্ধৃত সংজ্ঞাটি দিয়েছে যুক্তরাষ্ট্রের মান-নির্ধারণী সংস্থা NIST (National Institute of Standards and Technology), ২০১১ সালে প্রকাশিত একটি ছোট নথিতে (SP 800-145). এর সারকথা: ক্লাউড কম্পিউটিং এমন একটি মডেল, যেখানে কনফিগার করা যায় এমন কম্পিউটিং সম্পদের (নেটওয়ার্ক, সার্ভার, স্টোরেজ, অ্যাপ্লিকেশন, সেবা) একটি ভাগ করা ভান্ডারে নেটওয়ার্ক দিয়ে সুবিধামতো, চাহিদামাফিক প্রবেশ করা যায়, আর ন্যূনতম ব্যবস্থাপনা-ঝামেলায় দ্রুত সেগুলো নেওয়া ও ছেড়ে দেওয়া যায়। NIST এই মডেলকে সাজিয়েছে ৫টি বৈশিষ্ট্য, ৩টি সার্ভিস মডেল আর ৪টি deployment মডেলে — এই পর্বের কাঠামোও তাই।

২ · কোনটা ক্লাউড, কোনটা নয় — পাঁচ বৈশিষ্ট্য

অন্যের সার্ভারে কিছু রাখলেই কি ক্লাউড? না। ধরুন একটি কোম্পানি একটি ডেটা সেন্টারে নিজের একটি সার্ভার রেখে দিল, আর সেটি বদলাতে হলে ইমেইল করে এক সপ্তাহ অপেক্ষা করতে হয় — সেটা ভাড়া করা জায়গা, ক্লাউড নয়। NIST-এর পাঁচটি বৈশিষ্ট্য দিয়ে যাচাই করুন:

ভান্ডার ভাগ করার এই ধারণার একটি প্রযুক্তিগত নাম আছে — multi-tenancy: একই ভৌত সার্ভারে অনেক গ্রাহকের কাজ চলে, কিন্তু প্রত্যেকে দেয়াল দিয়ে আলাদা, একই ফ্ল্যাট-বাড়ির আলাদা ফ্ল্যাটের মতো। ভাগাভাগি থেকেই ক্লাউডের দাম কম আসে — আবার ভাগাভাগির কারণেই নিরাপত্তার দেয়াল মজবুত হওয়া এত জরুরি।

৩ · পিৎজা দিয়ে বোঝা — IaaS, PaaS আর SaaS

ক্লাউডে আপনি কতটুকু ভাড়া নেবেন, তার তিনটি প্রধান স্তর আছে। সবচেয়ে সহজে বোঝা যায় একটি পরিচিত উপমায় (IBM-এর এক প্রকৌশলীর জনপ্রিয় করা “pizza as a service”). ধরুন আজ রাতে বাসায় পিৎজা খাবেন। চারটি উপায়:

তিন মডেল, একে একে

এর বাইরে আরেকটি নতুন ধাপ: serverless বা FaaS (Function as a Service) — আপনি শুধু একটি ছোট ফাংশন লেখেন, কোনো ঘটনা ঘটলে (যেমন কেউ ছবি আপলোড করলে) সেটি কয়েক মিলিসেকেন্ড থেকে কয়েক সেকেন্ড চলে, আর বিল হয় শুধু সেই চলার সময়ের; উদাহরণ AWS Lambda (২০১৪)। “serverless” মানে সার্ভার নেই তা নয় — সার্ভার আছে, শুধু আপনাকে তা দেখতে বা সামলাতে হয় না।

এবার মূল প্রশ্ন: প্রতিটি মডেলে কোন স্তরের দায়িত্ব কার? নিচের stepper-এ নিচ থেকে ওপরে সাজানো স্তরগুলো দেখুন — প্রতি ধাপে কয়েকটি স্তর আপনার হাত থেকে প্রোভাইডারের হাতে চলে যায়:

৪ · কার ক্লাউড, কোথায় — deployment মডেল

সার্ভিস মডেল বলে “কী ভাড়া নিচ্ছেন”; deployment মডেল বলে “ক্লাউডটি কার, কারা ভাগ করে”। বাসস্থানের উপমায়: হোটেলের রুম (সবার জন্য খোলা), নিজের বাড়ি (শুধু আপনার), নিজের বাড়ি আর দরকারে হোটেল (মিশ্র)।

সার্ভিস মডেল আর deployment মডেল আলাদা প্রশ্নের উত্তর, তাই এরা মিলেমিশে চলে: “public cloud-এ PaaS”, “private cloud-এ IaaS” — দুটোই হতে পারে। বাস্তবে কীভাবে বাছবেন, তিনটি পরিস্থিতিতে দেখুন:

৫ · ক্লাউডের ভিত্তি — virtualization, ডেটা সেন্টার, region আর zone

Virtualization আর container — এক যন্ত্রে অনেক ভাড়াটে

পর্ব ২৬-এ দেখেছেন, hypervisor একটি ভৌত কম্পিউটারকে কয়েকটি virtual machine-এ ভাগ করে, আর container আরও হালকা ভাগ — একই kernel ভাগ করে আলাদা আলাদা অ্যাপের খাঁচা। ক্লাউড দাঁড়িয়ে আছে ঠিক এর ওপর। আপনি যখন AWS-এ “একটি সার্ভার চালু করো” চাপেন, কেউ দৌড়ে গিয়ে নতুন যন্ত্র বসায় না; hypervisor একটি চলমান বিশাল সার্ভারের এক টুকরো আপনার নামে ভাগ করে দেয় — তাই এক মিনিটের মধ্যে সার্ভার হাতে পান। এটাই resource pooling আর elasticity-র প্রযুক্তিগত রহস্য। অনেক container একসাথে চালানো আর সামলানোর জন্য আছে Kubernetes-এর মতো টুল (Google-এর ভেতরের অভিজ্ঞতা থেকে ২০১৪ সালে open source হয়)।

ডেটা সেন্টার — ক্লাউডের আসল ঠিকানা

ক্লাউড আকাশে থাকে না; থাকে ডেটা সেন্টার নামের বিশাল দালানে — তাকের পর তাকে হাজার হাজার সার্ভার, দ্বিগুণ বিদ্যুৎ-লাইন, ব্যাটারি আর জেনারেটর, বিশাল শীতলীকরণ-ব্যবস্থা, কয়েকটি আলাদা পথে আসা ফাইবার লাইন, আর কড়া পাহারা। নকশার মূলমন্ত্র redundancy — যেকোনো জিনিসের অন্তত একটি বাড়তি বিকল্প, যাতে একটি নষ্ট হলে আরেকটি সাথে সাথে কাজ ধরে।

Region আর availability zone

বড় প্রোভাইডাররা সারা বিশ্বে ডেটা সেন্টারগুলো সাজায় দুই স্তরে:

• Region: একটি ভৌগোলিক এলাকা — যেমন মুম্বাই, সিঙ্গাপুর, ফ্রাঙ্কফুর্ট, বা AWS-এর বহুল ব্যবহৃত us-east-1 (যুক্তরাষ্ট্রের ভার্জিনিয়া)। ব্যবহারকারীর কাছের region বাছলে latency কমে, আর ডেটা কোন দেশের আইনের অধীনে থাকবে, তা-ও region ঠিক করে।
• Availability zone (AZ): একটি region-এর ভেতরে কয়েকটি আলাদা ডেটা সেন্টার-গুচ্ছ, প্রতিটির নিজস্ব বিদ্যুৎ, ঠান্ডা রাখা আর নেটওয়ার্ক, একে অপরের থেকে কয়েক কিলোমিটার দূরে — যাতে আগুন বা বন্যায় একটি গেলেও অন্যটি থাকে — কিন্তু এত কাছে যে দ্রুত তথ্য আদান-প্রদান করা যায়।

তাই গুরুত্বপূর্ণ সেবা একাধিক AZ-এ ছড়িয়ে চালানো হয়, সামনে থাকে একটি load balancer, যে আসা অনুরোধগুলো সুস্থ সার্ভারগুলোর মধ্যে ভাগ করে দেয়। একটি AZ বিকল হলে কী হয়, দেখুন:

সবুজ কম্পিউটিং — ক্লাউডের বিদ্যুৎ-বিল

ডেটা সেন্টার বিপুল বিদ্যুৎ খায়, আর সার্ভারের তাপ সরাতে লাগে আরও বিদ্যুৎ আর পানি। AI-এর প্রশিক্ষণে হাজার হাজার GPU একসাথে চলায় এই চাহিদা দ্রুত বাড়ছে। দক্ষতা মাপার একটি প্রচলিত সংখ্যা PUE — মোট বিদ্যুৎ ÷ শুধু কম্পিউটারের বিদ্যুৎ; ১-এর যত কাছে, তত কম অপচয়। অনেক ছোট অফিসের আধা-ফাঁকা সার্ভারের তুলনায় বড় ডেটা সেন্টারে যন্ত্র বেশি ব্যস্ত থাকে আর শীতলীকরণ বেশি দক্ষ — তাই একই কাজ সাধারণত কম শক্তিতে হয়। Green computing-এর লক্ষ্য এটাই: কম বিদ্যুৎ, নবায়নযোগ্য শক্তি, যন্ত্রের দীর্ঘ জীবন আর দায়িত্বশীল ই-বর্জ্য ব্যবস্থাপনা। আপনার দিক থেকে সহজতম সবুজ পদক্ষেপ: যে ক্লাউড সার্ভার কাজে লাগছে না, সেটি বন্ধ করা — টাকা আর বিদ্যুৎ দুটোই বাঁচে।

৬ · Scalability আর elasticity — ফলাফলের দিনে ওয়েবসাইট টিকবে তো?

SSC বা HSC-র ফল প্রকাশের দিনটির কথা ভাবুন। সারা বছর শিক্ষা বোর্ডের ফলাফলের ওয়েবসাইটে ভিড় সামান্য। কিন্তু ফল প্রকাশের মুহূর্তে লক্ষ লক্ষ শিক্ষার্থী আর অভিভাবক একসাথে রোল নম্বর লেখেন — ভিড় হঠাৎ কয়েকশো গুণ। অনেকেরই অভিজ্ঞতা আছে: পাতা ঘুরছে তো ঘুরছেই। দুটি শব্দ এখানে আলাদা করে বোঝা দরকার:

• Scalability: চাহিদা বাড়লে সম্পদ বাড়িয়ে বেশি কাজ সামলানোর ক্ষমতা। দুই রকম — vertical (একটি সার্ভারকেই বড় করা: বেশি RAM, বেশি core) আর horizontal (একই রকম আরও সার্ভার যোগ করা)। ক্লাউডে horizontal পথই বেশি জনপ্রিয়, কারণ এর কার্যত কোনো সীমা নেই।
• Elasticity: সেই বাড়ানো-কমানো দ্রুত আর নিজে থেকে হওয়া — ভিড় এলে বাড়ে, চলে গেলে কমে, আর বিলও সেই অনুযায়ী। রাবারের মতো টানলে বাড়ে, ছাড়লে আগের মাপে।

নিজে চালিয়ে দেখুন — খরচ আর ভিড়ের সিমুলেটর

নিচের কোড ওপরের দিনটিই হিসাব করে — সকাল ৯টা থেকে সন্ধ্যা ৬টা পর্যন্ত প্রতি ঘণ্টার ভিড় ধরে তিনটি পরিকল্পনা তুলনা করে। খরচ-একক কাল্পনিক, কোনো প্রোভাইডারের আসল দাম নয়।

const traffic = [2, 3, 5, 48, 60, 35, 14, 6, 3, 2]; // হাজার অনুরোধ/ঘণ্টা, 09:00 থেকে 18:00
const perServer = 10;                               // একটি সার্ভার ঘণ্টায় 10 হাজার সামলায়
function plan(title, serversFor) {
  let cost = 0, failed = 0;
  const used = traffic.map(t => {
    const s = serversFor(t);                        // এই ঘণ্টায় কয়টি সার্ভার চালু
    failed += Math.max(0, t - s * perServer);       // জায়গা না পেয়ে ফিরে যাওয়া অনুরোধ
    cost += s;                                      // 1 সার্ভার × 1 ঘণ্টা = 1 cost unit
    return s;
  });
  console.log(`${title}\n  servers/hour: ${used.join(' ')}\n  cost = ${cost} units, failed = ${failed}k requests`);
}
plan('Fixed, 3 servers', () => 3);
plan('Fixed, 6 servers', () => 6);
plan('Auto-scaling', t => Math.max(1, Math.ceil(t / perServer)));

দাম কীভাবে ধরা হয় — মূল্য-মডেল

নির্দিষ্ট দাম প্রোভাইডার, region আর সময়ভেদে বদলায়, তাই এখানে শুধু ধরনগুলো:

• Pay-as-you-go (on-demand): সেকেন্ড বা ঘণ্টা ধরে যতটুকু চালালেন, ততটুকু বিল; কোনো চুক্তি নেই। সবচেয়ে নমনীয়, প্রতি ঘণ্টায় সবচেয়ে দামি।
• Reserved বা committed use: এক বা তিন বছর নির্দিষ্ট পরিমাণ ব্যবহারের প্রতিশ্রুতি দিলে বড় ছাড় — সারাবছর চলা স্থির কাজের জন্য ভালো।
• Spot বা preemptible: প্রোভাইডারের অব্যবহৃত যন্ত্র অনেক কম দামে, কিন্তু প্রোভাইডার দরকার হলে অল্প নোটিশে ফেরত নিতে পারে — থামলে ক্ষতি নেই এমন কাজের জন্য।
• Free tier: নতুনদের জন্য সীমিত পরিমাণ বিনা মূল্যে — শেখা আর পরীক্ষার জন্য চমৎকার, কিন্তু সীমা পেরোলেই বিল শুরু।

হিসাবের ভাষায়, ক্লাউড বড় এককালীন বিনিয়োগকে (CapEx — সার্ভার কেনা) মাসে মাসে চলতি খরচে (OpEx — ভাড়া) বদলে দেয়। নতুন প্রতিষ্ঠানের জন্য এটি আশীর্বাদ; কিন্তু বছরের পর বছর একই পরিমাণ যন্ত্র চালালে ভাড়ার মোট খরচ কেনার চেয়ে বেশিও হতে পারে।

৭ · সুবিধা, অসুবিধা আর নিরাপত্তার ভাগাভাগি

বিভ্রাট নিয়ে একটু বলি। AWS-এর us-east-1 region-এ একাধিকবার বড় সমস্যা হয়েছে, আর প্রতিবার বিশ্বজুড়ে নানা পরিচিত অ্যাপ আর ওয়েবসাইট একসাথে আটকে গেছে — কারণ বহু প্রতিষ্ঠান একই region-এর ওপর নির্ভর করত। শিক্ষাটি প্রোভাইডার-নির্বিশেষে একই: ক্লাউড নিজে থেকে নির্ভরযোগ্য হয় না; একাধিক zone, দরকারে একাধিক region, আর নিয়মিত পরীক্ষা করা ব্যাকআপ দিয়ে নির্ভরযোগ্যতা নকশা করতে হয়। প্রোভাইডারের প্রতিশ্রুতি লেখা থাকে SLA-তে — যেমন “মাসে ৯৯.৯৯% সময় চালু” — না রাখতে পারলে সাধারণত বিলে কিছু ছাড় দেয়, কিন্তু আপনার ব্যবসার ক্ষতি পূরণ করে না।

Shared responsibility model — নিরাপত্তা কার দায়িত্বে

ক্লাউড-নিরাপত্তার সবচেয়ে জরুরি ধারণা: shared responsibility model. AWS-এর ভাষায় সহজ সূত্র — প্রোভাইডার দায়ী ক্লাউড-এর নিরাপত্তায়, আর গ্রাহক দায়ী ক্লাউড-এর ভেতরে রাখা জিনিসের নিরাপত্তায়। ভাড়া বাসার মতো: বাড়িওয়ালা মূল ফটক, দেয়াল আর সিঁড়ি দেখেন; কিন্তু আপনার ফ্ল্যাটের দরজায় তালা দেওয়া, চাবি কাকে দেবেন — আপনার কাজ।

বাস্তবে ক্লাউডে ডেটা ফাঁসের বড় অংশ ঘটে প্রোভাইডারের দুর্বলতায় নয়, গ্রাহকের ভুল সেটিংসে। সবচেয়ে পরিচিত উদাহরণ: অনলাইন ফাইল-ভান্ডার (storage bucket) ভুল করে “public” রেখে দেওয়া — তখন লিংক জানা যে কেউ ভেতরের ফাইল দেখতে পারে। প্রতিরক্ষার অভ্যাস সহজ: ডিফল্ট “private” রাখা, প্রত্যেককে শুধু কাজের জন্য যতটুকু দরকার ততটুকু অনুমতি (least privilege), প্রোভাইডারের নিরাপত্তা-পরামর্শ ড্যাশবোর্ড নিয়মিত দেখা, আর মূল অ্যাকাউন্টে 2FA. পাসওয়ার্ড, 2FA আর সাধারণ সাইবার নিরাপত্তার পুরো আলোচনা পাবেন পর্ব ৪৩-এ।

৮ · বাংলাদেশে ক্লাউড, ক্যারিয়ার আর ক্লাউডের প্রান্তে

বাংলাদেশের প্রেক্ষাপট

সরকারি সেবার ডেটা রাখতে বাংলাদেশ কম্পিউটার কাউন্সিল (BCC)-এর অধীনে গাজীপুরের কালিয়াকৈরে একটি জাতীয় ডেটা সেন্টার গড়ে তোলা হয়েছে; এর আগে থেকে ঢাকাতেও BCC-র ডেটা সেন্টার চালু ছিল। বিভিন্ন সরকারি ই-সেবা (পর্ব ১৫) এ ধরনের অবকাঠামোর ওপর চলে, আর সরকারি দপ্তরগুলোর জন্য ক্লাউড-ধরনের সেবাও দেওয়া হয় — এক অর্থে এটি community বা government cloud-এর উদাহরণ। এর পাশাপাশি দেশে কয়েকটি বেসরকারি ডেটা সেন্টার আর স্থানীয় ক্লাউড-সেবা প্রতিষ্ঠান আছে, যারা দেশের ভেতরে ডেটা রাখতে চাওয়া প্রতিষ্ঠানকে সার্ভার আর স্টোরেজ ভাড়া দেয়।

অন্যদিকে দেশের বেশিরভাগ স্টার্টআপ, ই-কমার্স আর মোবাইল অ্যাপ সরাসরি বৈশ্বিক public cloud ব্যবহার করে — প্রায়ই প্রতিবেশী দেশের region (যেমন সিঙ্গাপুর বা মুম্বাই), কারণ সেখান থেকে বাংলাদেশে latency কম আর সেবার পরিসর বিশাল। কোন ডেটা দেশে রাখতেই হবে আর কোনটি বাইরে রাখা যায় — এই প্রশ্নটি নীতি আর আইনের, আর বিশ্বজুড়েই এ নিয়ে আলোচনা চলছে (ভাবনার প্রশ্ন ৫)।

ক্যারিয়ার — cloud আর DevOps

ক্লাউড-দক্ষতা আজ IT-র সবচেয়ে চাহিদাসম্পন্ন দক্ষতাগুলোর একটি। প্রধান ভূমিকাগুলো: cloud engineer (অবকাঠামো নকশা ও পরিচালনা), DevOps engineer (কোড লেখা থেকে চালু করা পর্যন্ত পুরো পথ স্বয়ংক্রিয় করা), SRE (site reliability — সেবা যেন না থামে), cloud security বিশেষজ্ঞ, আর FinOps (ক্লাউডের খরচ নিয়ন্ত্রণ)। বড় প্রোভাইডারদের নিজস্ব সার্টিফিকেশন আছে, শুরুর স্তরেরগুলো এই পর্বের ধারণাগুলো দিয়েই শুরু হয়। ভিত্তি হিসেবে লাগবে Linux আর কমান্ড লাইন (পর্ব ২৯), নেটওয়ার্কিং (পর্ব ৩২–৩৩) আর অন্তত একটি প্রোগ্রামিং ভাষা। ফ্রিল্যান্সিংয়েও ক্লাউড সেটআপের কাজ প্রচুর (পর্ব ৪৮)।

ক্লাউডের প্রান্তে — edge computing আর IoT

সব কাজ দূরের ডেটা সেন্টারে পাঠানো সবসময় ভালো নয় — চালকবিহীন গাড়ি বা কারখানার যন্ত্র মিলিসেকেন্ডে সিদ্ধান্ত চায়। তাই কিছু হিসাব ব্যবহারকারীর কাছেই, “প্রান্তে” করা হয় — edge computing; আর লক্ষ লক্ষ সেন্সর-যন্ত্র (IoT) প্রান্তে ছেঁকে নিয়ে দরকারি ডেটাটুকু ক্লাউডে পাঠায়। IoT-র বিস্তারিত পর্ব ৪৬-এ।

৯ · AI-এর যুগে — AI নিজেই ক্লাউড সেবা

আপনি যখন কোনো AI চ্যাটবট-কে প্রশ্ন করেন, উত্তরটি আপনার ফোনে তৈরি হয় না — তৈরি হয় দূরের ডেটা সেন্টারে হাজার হাজার GPU-তে। অর্থাৎ বেশিরভাগ AI সেবা আসলে SaaS, আর ডেভেলপাররা AI ব্যবহার করেন ক্লাউডের API দিয়ে, যেখানে বিল হয় ব্যবহার অনুযায়ী (প্রায়ই প্রতি হাজার বা লাখ শব্দাংশ ধরে)। নিজের AI মডেল প্রশিক্ষণ দিতে চাইলে ঘণ্টা ধরে GPU ভাড়া নেওয়া যায় — IaaS. তাই ক্লাউডের সব শিক্ষা AI-এ খাটে: খরচ নীরবে বাড়ে, আর আপনি AI-কে যে লেখা বা ফাইল দেন, তা প্রোভাইডারের সার্ভারে যায় — গ্রাহকের ব্যক্তিগত তথ্য, অফিসের গোপন নথি দেওয়ার আগে প্রতিষ্ঠানের নীতি দেখুন।

AI আবার ক্লাউড নকশায় সহকারী হিসেবেও দারুণ: “৫০০ জন ব্যবহারকারীর একটি অ্যাপের জন্য AWS-এ architecture বানাও” বললে কয়েক সেকেন্ডে একটি নকশা পাবেন। কিন্তু AI প্রায়ই প্রয়োজনের চেয়ে বড় (আর দামি) নকশা দেয়, পুরোনো সেবার নাম বা দাম বলে, আর উদাহরণ-কোডে সুবিধার জন্য storage “public” বা সব port খোলা রেখে দিতে পারে। নিচের prompt-টি এসব ঝুঁকি মাথায় রেখে লেখা:

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

• প্রতিটি সেবার নাম আর মূল্য প্রোভাইডারের অফিসিয়াল ওয়েবসাইট বা pricing calculator-এ মিলিয়েছি
• চালু করার আগে বাজেট-সতর্কবার্তা চালু করেছি, আর পরীক্ষা শেষে অব্যবহৃত সম্পদ মুছেছি
• কোনো storage bucket বা ডেটাবেস ইন্টারনেটে সবার জন্য খোলা নেই — প্রোভাইডারের নিরাপত্তা-পরামর্শ ড্যাশবোর্ডে দেখেছি
• AI-এর দেওয়া কোডে কোনো পাসওয়ার্ড বা API key সরাসরি লেখা নেই
• ডেটা কোন region-এ থাকবে বেছেছি, আর ব্যক্তিগত তথ্যের আইনগত শর্ত দেখেছি
• AI-কে কোনো গোপন বা ব্যক্তিগত তথ্য দিইনি, যা প্রতিষ্ঠানের নীতিতে নিষেধ