Cloud আসলে কী এবং AWS কীভাবে টাকা নেয়

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

• cloud computing আসলে কী, আর একটা কোম্পানি নিজের data center চালানো ছেড়ে দিলে কী কী বদলে যায়, বুঝিয়ে বলতে পারবে।
• cloud computing-এর পাঁচটা বৈশিষ্ট্য আর AWS-এর বলা ছয়টা সুবিধার নাম বলতে পারবে, আর পরীক্ষার প্রশ্নের শব্দ দেখে কোনটার কথা হচ্ছে ধরতে পারবে।
• IaaS, PaaS, FaaS আর SaaS আলাদা করে চিনতে পারবে, প্রতিটার একটা করে AWS service-এর উদাহরণসহ, আর বলতে পারবে কোনটায় কোন স্তর তোমাকে নিজে চালাতে হয়।
• কোনো পরিস্থিতিতে public, private না hybrid cloud, সেটা বেছে নিতে পারবে।
• shared responsibility model দিয়ে যেকোনো নিরাপত্তার কাজ AWS আর customer-এর মধ্যে ভাগ করতে পারবে, EC2, RDS, Lambda আর S3-এর জন্য আলাদা করে।
• AWS কীসের জন্য টাকা নেয় (compute, storage, data transfer out) বলতে পারবে, CapEx বনাম OpEx আর TCO বোঝাতে পারবে, আর একটা ছোট bill নিজে হিসাব করতে পারবে।

#Cloud আসার আগে: নিজের server নিজে চালানো

ধরো ২০০৫ সাল। একটা কোম্পানি online দোকান খুলতে চায়। প্রথম ক্রেতা আসার আগেই তাকে এতগুলো কাজ সারতে হবে:

1. কতটা capacity লাগবে, আন্দাজ করা, তাও কয়েক বছর আগে থেকেই, সবচেয়ে ব্যস্ত দিনটার কথা ভেবে।
2. hardware কেনা: server, disk, switch, firewall। হাজার হাজার ডলার, সব আগেই নগদে।
3. রাখার জায়গা খোঁজা: একটা server room, নয়তো কোনো data center-এ ভাড়া নেওয়া rack। সঙ্গে বিদ্যুৎ, বিদ্যুৎ চলে গেলে বিকল্প ব্যবস্থা, ঠান্ডা রাখার ব্যবস্থা, পাহারা।
4. অপেক্ষা করা: order দেওয়া, জিনিস আসা, rack-এ বসানো, তার জোড়া, install করা। সপ্তাহ, এমনকি মাসও লেগে যায়।
5. তারপর সারাজীবন চালিয়ে যাওয়া: নষ্ট disk বদলানো, firmware-এ patch, কয়েক বছর পরপর মেশিন বদলানো, রাতে পাহারা দেওয়ার জন্য লোক রাখা।

এই পদ্ধতিকে বলে on-premises (মুখে মুখে "on-prem")। মানে যন্ত্রপাতি কোম্পানির নিজের, নিজের ভবনে বা ভাড়া করা জায়গায়, চালায়ও নিজেরা। এটা কাজ করে, আজও অনেক প্রতিষ্ঠান কিছু system এভাবেই চালায়। কিন্তু এর তিনটা বড় সমস্যা আছে:

• আন্দাজ সবসময় ভুল হয়। capacity কম হলে সবচেয়ে ভালো দিনটাতেই site বসে যায়। বেশি হলে দামি মেশিন বছরের বেশির ভাগ সময় অলস পড়ে থাকে।
• খুব ধীর। নতুন project-এ একটা লাইন code লেখার আগেই hardware-এর জন্য কয়েক সপ্তাহ বসে থাকতে হয়।
• বেশির ভাগ কাজ তোমার আসল ব্যবসা না। disk বদলানো বা এসি সারানো দিয়ে তো তোমার দোকান প্রতিযোগীর চেয়ে ভালো হয়ে যায় না।

#Cloud computing আসলে কী

AWS-এর সংজ্ঞাটা এরকম: cloud computing হলো internet-এর মাধ্যমে, যখন দরকার তখন, IT resource পাওয়া, আর যতটুকু ব্যবহার ততটুকুর দাম (pay-as-you-go)। নিজে data center আর server কিনে, মালিক হয়ে, রক্ষণাবেক্ষণ করার বদলে তুমি AWS-এর মতো কোনো provider-এর কাছ থেকে compute, storage, database সহ আরও অনেক service দরকারমতো নিয়ে নাও।

provider-এর কিন্তু data center আছে, সত্যিকারের মেশিনও আছে। পার্থক্য হলো মালিক কে, চালায় কে, আর টাকা দাও কীভাবে। provider বিশাল বিশাল data center বানায়, সবাই মিলে ব্যবহার করে। তুমি তার ছোট ছোট টুকরা ভাড়া নাও: সেকেন্ড ধরে, gigabyte ধরে, বা request ধরে।

#পাঁচটা বৈশিষ্ট্য

NIST (আমেরিকার National Institute of Standards and Technology)-এর একটা সংজ্ঞা সবাই ব্যবহার করে। সেই অনুযায়ী কোনো service-কে "cloud" বলা যায়, যদি তার এই পাঁচটা বৈশিষ্ট্য থাকে:

এই টেবিলের দুটো শব্দ AWS-এ আর পরীক্ষায় সব জায়গায় পাবে:

• Scalability: resource বাড়িয়ে (বড় মেশিন বা বেশি মেশিন) বেশি ভার সামলানোর ক্ষমতা।
• Elasticity: এমন scalability, যেটা নিজে থেকেই, আর দুই দিকেই হয়। চাহিদা বাড়লে capacity বাড়ে, কমলে আবার কমে, আর যা সরিয়ে দিলে তার টাকাও আর দিতে হয় না।

animation-টা elasticity যে দুটো সমস্যা মেটায় সেটা দেখায়। সেলের দিনে on-premises দোকান বসে যায়, কারণ তার কাছে তিনটা server-ই সব। ফাঁকা রাতে সে এমন server-এর টাকা দিচ্ছে যেগুলো কিছুই করছে না। cloud-এর দিক কয়েক মিনিটে instance বাড়িয়ে নেয়, ভিড় শেষে সরিয়ে দেয়। আর hardware নষ্ট হলে বাড়তি যন্ত্র AWS-এর আছে ঠিকই, কিন্তু দোকান online থাকবে তখনই, যখন তোমার design-এ একটার বেশি instance আছে।

#Cloud-এর ছয়টা সুবিধা

cloud-এ গেলে কী লাভ, AWS সেটা ছয়টা সুবিধা হিসেবে বলে। পরীক্ষায় এগুলো বারবার আসে, তবে বেশির ভাগ সময় ছদ্মবেশে।

#AWS কী

Amazon Web Services (AWS) হলো Amazon-এর cloud provider। server আর আরও শত শত service দেয়, যেগুলো দরকারমতো ব্যবহার করা যায় আর সহজেই বাড়ানো যায়। ছোট্ট একটা ইতিহাস জানলে বুঝবে AWS কেন এমন:

• ২০০০-এর দশকের শুরুতে Amazon-এর নিজের engineer-রা ভেতরের কাজের জন্য একটা সবার-ব্যবহারযোগ্য infrastructure বানায়, যাতে প্রতিটা project-এ টিমগুলোকে একই server আর database বারবার বানাতে না হয়। ওরা বুঝতে পারে, infrastructure ভালোভাবে চালানো Amazon-এর একটা বড় শক্তি, আর অন্য কোম্পানিরাও এর জন্য টাকা দেবে।
• ২০০৪: প্রথম public service, একটা message queue (SQS, অধ্যায় ১৩-তে পড়বে), beta হিসেবে চালু হয়।
• ২০০৬: AWS নতুন করে চালু হয় S3 (storage, মার্চে) আর EC2 (virtual server, আগস্টে) নিয়ে। আজও প্রায় সব কিছুর ভিত্তি এই দুটোই।
• ২০০৭: আমেরিকার বাইরে প্রথম resource, ইউরোপে। এখন মানুষ থাকে এমন প্রতিটা মহাদেশে AWS-এর Region আছে (লেসন ১.২)।

AWS সবচেয়ে বড় cloud provider। ২০২৪ সালে এর আয় ১০০ বিলিয়ন ডলার ছাড়িয়েছে, আর এক দশকেরও বেশি সময় ধরে বাজারে এক নম্বরে, Microsoft Azure আর Google Cloud-এর আগে। সব আকারের কোম্পানি এর ওপর চলে: Amazon.com নিজে, Netflix, ব্যাংক, সরকারি প্রতিষ্ঠান, start-up, game studio।

সাধারণত যে কাজে লাগে: কোম্পানির IT আর অফিসের ভেতরের system, backup আর storage, big data analytics, website, mobile আর social app, game, machine learning, high-performance computing। এই course-এ service-গুলো আসবে যে ক্রমে তোমার দরকার সেই ক্রমে, যে ক্রমে চালু হয়েছিল সেই ক্রমে না।

#Service model: IaaS, PaaS, FaaS আর SaaS

"Cloud" কোনো একটা product না। provider-রা stack-এর কম-বেশি অংশ দেয়: একদম খালি virtual machine থেকে শুরু করে পুরো তৈরি software পর্যন্ত। কোন model বেছে নিলে সেটাই ঠিক করে কতটা তুমি নিজে চালাবে আর কতটা provider তোমার হয়ে চালাবে।

IaaS-এর সবচেয়ে পরিষ্কার উদাহরণটা নোটেই আছে: EC2 হলো AWS-এর virtual server। তোমার নিজের কম্পিউটারের মতোই এর CPU, RAM, storage আর operating system (Linux বা Windows) আছে, কিন্তু সেটা আসলে বসে আছে AWS-এর data center-এ, আর তুমি সেটা কেনো না, ভাড়া নাও। তুমি পাচ্ছ শুধু মেশিনটা, তার ওপরে আর কিছু না, তাই EC2 হলো IaaS।

#Deployment model: public, private, hybrid

service model-এর বাইরে আরেকটা প্রশ্ন আছে: cloud-টা কোথায় চলে আর কে কে মিলে ব্যবহার করে।

আরও দুটো শব্দ সামনে পাবে:

• Multi-cloud: একাধিক public provider (যেমন AWS আর Azure) একসাথে ব্যবহার। এটা মূলত ব্যবসার সিদ্ধান্ত, দর কষাকষির জোর বা কিনে নেওয়া অন্য কোম্পানির system-এর কারণে। ঝামেলা বাড়ায়, আর পরীক্ষায় খুব কমই সঠিক উত্তর হয়।
• তোমার ভবনেই AWS: AWS Outposts-এর মতো service তোমার নিজের data center-এ AWS-এর চালানো rack বসিয়ে দেয়। যেসব কাজে on-prem system-এর সাথে খুব কম latency লাগে বা data জায়গাতেই রাখতে হয়, সেখানে কাজে লাগে, আর API থাকে AWS-এর মতোই। (Outposts নিয়ে অধ্যায় ২৫-এ।)

#Shared responsibility model

AWS-এ গেলে নিরাপত্তা অন্য কারও মাথাব্যথা হয়ে যায় না। দায়িত্বটা ভাগ হয়ে যায়। AWS ভাগটা এক কথায় বলে:

• AWS-এর দায়িত্ব cloud-এর নিরাপত্তা: যে infrastructure-এর ওপর সব AWS service চলে। মানে ভবন, ভেতরে কে ঢুকবে, বিদ্যুৎ, ঠান্ডা রাখা, hardware, সারা বিশ্বের network, আর service-গুলো চালানোর software (যেমন EC2-এর নিচের hypervisor)।
• তোমার দায়িত্ব cloud-এর ভেতরের নিরাপত্তা: cloud-এ তুমি যা রাখো আর যেভাবে সাজাও, সব। তোমার data, কে সেটা পাবে (IAM, অধ্যায় ২), তোমার network rule (security group আর network ACL, লেসন ৩.৫), encryption-এর সিদ্ধান্ত, আর service ভেদে operating system আর application।

#Service বদলালে সীমারেখাও সরে

service যত বেশি কাজ তোমার হয়ে করে, stack-এর তত বেশি অংশ AWS নিজের ঘাড়ে নেয়। তবে তোমার data আর access-এর setting সবসময় তোমার কাছেই থাকে।

কিছু control-কে বলে shared control, কারণ দুই পক্ষই নিজের নিজের স্তরে এর একটা করে অংশ করে:

• Patch management: AWS patch দেয় infrastructure-এ; তুমি দাও তোমার guest OS আর application-এ।
• Configuration management: AWS নিজের device সাজায়; তুমি সাজাও তোমার OS, database আর application।
• Awareness and training: AWS নিজের লোকদের প্রশিক্ষণ দেয়; তুমি দাও তোমার লোকদের।

আর কিছু হলো inherited control: তুমি কিছু না করেই AWS থেকে পেয়ে যাও, যেমন data center-এর ভৌত আর পরিবেশগত সুরক্ষা। auditor-রা এগুলোর জন্য AWS-এর report-ই মেনে নেয় (report নামাও AWS Artifact থেকে, AWS-এর compliance report-এর self-service portal)।

#বাস্তবে কোথায় গোলমাল হয়

cloud-এর প্রায় সব বিখ্যাত ফাঁসের ঘটনা ঘটেছে সীমারেখার customer-এর দিকে:

• একটা S3 bucket public করে দেওয়া, ভেতরে গোপন file। S3 ঠিক তাই করেছে যা policy বলেছে। (এখন নতুন bucket-এ default-এই public access বন্ধ থাকে আর object encrypt হয়, কিন্তু মানুষ চাইলে সেটা বন্ধ করে দিতে পারে।)
• SSH বা database-এর port 0.0.0.0/0-এর জন্য খোলা, কয়েক মিনিটেই bot-রা খুঁজে পায়।
• patch না দেওয়া EC2 instance, যেখানে জানা দুর্বলতাওয়ালা পুরনো web server চলছে।
• access key GitHub-এ push করে ফেলা, তারপর কেউ সেটা দিয়ে ভুক্তভোগীর টাকায় crypto-mining instance চালায় (long-term key কীভাবে এড়াবে, অধ্যায় ২ আর লেসন ১.৩-এ)।
• দুর্বল admin password-ওয়ালা database, যেটা internet থেকে পৌঁছানো যায়।

নোটে একই নিয়মের একটা ছোট উদাহরণ আছে: NAT instance (লেসন ৩.৪) আসলে একটা সাধারণ EC2 instance, তাই এর scaling, OS patch আর high availability তোমার কাজ। আর NAT gateway চালায় AWS। managed service বেছে নিলে কাজের একটা অংশ সীমারেখা পেরিয়ে AWS-এর দিকে চলে যায়।

#AWS কীভাবে টাকা নেয়

AWS-এ প্রায় সবকিছুর দাম pay as you go: আগে কিছু দিতে হয় না, default-এ কোনো লম্বা চুক্তি নেই, ব্যবহার থামালে টাকা দেওয়াও থামে। প্রায় প্রতিটা bill-এর পেছনে তিনটা জিনিস:

1. Compute: তোমার resource কতক্ষণ চলল, আর কত বড়। EC2-এর Linux instance bill হয় সেকেন্ড ধরে (কমপক্ষে এক মিনিট); Lambda bill হয় প্রতি request আর প্রতি millisecond চলার সময় ধরে, memory অনুযায়ী।
2. Storage: কতটা data রাখলে আর কতদিন, সাধারণত প্রতি GB-মাস ধরে। S3, EBS volume, snapshot, backup সবই এর মধ্যে। কিছু না চললেও storage-এর bill চলতেই থাকে।
3. Data transfer out: AWS থেকে internet-এ বা এক Region থেকে আরেক Region-এ যাওয়া data-র দাম GB প্রতি। internet থেকে ভেতরে আসা data ফ্রি।

দাম Region ভেদে আলাদা, সময়ের সাথে বদলায়ও; কোনো সংখ্যার ওপর ভরসা করার আগে pricing page বা AWS Pricing Calculator দেখে নিও।

#AWS দাম কমানোর তিনটা উপায় দেয়

1. Pay as you go: default উপায়। নতুন, হঠাৎ ওঠানামা করা বা অল্পদিনের কাজের জন্য সবচেয়ে ভালো।
2. কথা দিলে সাশ্রয়: এক বা তিন বছর একটা নির্দিষ্ট পরিমাণ ব্যবহারের কথা দাও (Savings Plans, Reserved Instances), On-Demand-এর চেয়ে প্রায় ৭২% পর্যন্ত কম দাম। লেসন ৪.৪-এ বিস্তারিত।
3. বেশি ব্যবহারে কম দাম: ধাপে ধাপে দাম, পরিমাণ যত বাড়ে প্রতি ইউনিটের দাম তত কমে (যেমন data transfer out আর S3 storage-এ বেশি পরিমাণে GB প্রতি দাম কমে যায়)।

#CapEx, OpEx আর মোট খরচ (TCO)

একটা server-এর দামের সাথে একটা instance-এর ঘণ্টার দাম মেলানো ঠিক তুলনা না। TCO (total cost of ownership) একটা system-এর পুরো জীবনে আসলে যত খরচ হয়, সব গোনে:

• On-premises: hardware, software license, data center-এর জায়গা, বিদ্যুৎ আর ঠান্ডা রাখা, network সংযোগ, বাড়তি যন্ত্রাংশ, চালানোর লোকজন, আর peak-এর জন্য কিনে রাখা অলস capacity-র দাম।
• Cloud: service-এর দাম, data transfer, support plan, design আর চালানোর লোকজন, আর migration-এর খরচ।

অনেক সময় TCO-তে cloud জেতে, কারণ অলস capacity আর data center-এর লোকবলের খরচ উধাও হয়ে যায়। আবার সবসময় জেতে না: বিশাল, একদম স্থির একটা কাজ, যার hardware-এর দাম আগেই উঠে গেছে, সেটা on-premises-এ সস্তা হতে পারে। Solutions Architect-এর কাজ হলো হিসাবটা করা, ধরে নেওয়া না।

#Economies of scale

AWS server, disk, network-এর যন্ত্র আর বিদ্যুৎ কেনে এমন পরিমাণে, যা কোনো একক customer-এর পক্ষে সম্ভব না। নিজের hardware নিজেই design করে (যেমন Nitro system আর Graviton processor), আর প্রচুর automation দিয়ে চালায়। এতে প্রতি ইউনিটের খরচ কমে। ২০০৬ থেকে AWS এই সাশ্রয়ের একটা অংশ একশোবারেরও বেশি দাম কমিয়ে customer-দের ফেরত দিয়েছে। এটাই "বিশাল economies of scale-এর সুবিধা"।

#System design-এ cloud

এই লেসনের ধারণাগুলো AWS-এ system design করার ধরনটাই বদলে দেয়:

• ব্যর্থতার কথা ভেবে design করো। AWS-এও hardware নষ্ট হয়। hardware ঠিক করে AWS; user টের পাবে কি না, সেটা ঠিক করে তোমার design। একের বেশি কপি চালাও, একের বেশি Availability Zone-এ (লেসন ১.২), load balancer-এর পেছনে (অধ্যায় ৬)।
• server-কে বদলযোগ্য ভাবো। নতুন instance যেহেতু একটা API call দূরে, নষ্ট বা পুরনো server সারানোর বদলে বদলে ফেলো। golden AMI আর launch template (লেসন ৪.৩) এই কাজটাকে রোজকার ব্যাপার বানিয়ে দেয়।
• চাহিদার সাথে বাড়াও-কমাও। elasticity কাজে লাগাও: instance-এর জন্য Auto Scaling, নিজে থেকে বাড়ে-কমে এমন serverless service, আর অলস জিনিস বন্ধ রাখা (রাতে development environment)।
• খরচকে design-এর অংশ বানাও। data transfer, অলস resource আর ভুলে যাওয়া storage, এগুলো architecture-এরই সিদ্ধান্ত। নিরাপদ হলে অনবরত কথা বলা অংশগুলো একই AZ-এ রাখো, download দাও CDN দিয়ে (অধ্যায় ১১), আর resource-এ tag দাও যাতে বোঝা যায় কে কত খরচ করছে।
• মানানসই হলে managed service বেছে নাও। প্রতিটা managed service shared responsibility-র সীমারেখার একটা অংশ AWS-এর দিকে সরিয়ে দেয়: patch দেওয়ার server কমে, রাত ৩টায় ভাঙার জিনিসও কমে।
• Well-Architected Framework চেনো। ভালো cloud design-এর জন্য AWS-এর নির্দেশনা ছয়টা স্তম্ভের ওপর দাঁড়িয়ে: operational excellence, security, reliability, performance efficiency, cost optimization আর sustainability। অধ্যায় ২৬-এ এগুলো ধরে ধরে দেখবে; এই course-এর প্রতিটা অধ্যায়ই এগুলো ছুঁয়ে যায়।

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

#AWS Pricing Calculator দিয়ে একটা ছোট bill আন্দাজ করো

1. Calculator খোলো

   calculator.aws-এ যাও (account লাগে না), তারপর Create estimate বেছে নাও।

2. একটা ছোট web server যোগ করো

   Amazon EC2 যোগ করো, Region US East (N. Virginia), একটা Linux t3.micro, মাসে ৭৩০ ঘণ্টা চলবে (সবসময় চালু), সঙ্গে ২০ GB-র একটা gp3 EBS volume।

3. Storage আর traffic যোগ করো

   Amazon S3 Standard যোগ করো, ৫০ GB রাখা থাকবে; আর EC2-এর entry-তে internet-এ data transfer out দাও মাসে ২০০ GB।

4. ফলাফল পড়ো

   দেখো কোন লাইনটা সবচেয়ে বড়। তারপর instance-এর ঘণ্টা বদলে ২০০ করো (শুধু অফিসের সময়), দেখো compute-এর লাইন কতটা কমে, অথচ storage-এর লাইন একটুও নড়ে না। ওই পার্থক্যটাই হাতে-কলমে pay-as-you-go।

#কাঁচা price list দেখো

AWS প্রতিটা দাম machine-এ পড়ার মতো file হিসেবে প্রকাশ করে। এই command সেই service-গুলোর তালিকা দেখায়, যাদের price list আছে:

curl -s https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/index.json | head -c 600

CLI ঠিকমতো ব্যবহার করবে লেসন ১.৩-এ; aws pricing get-products একই data filter দিয়ে পড়ে।

#হাতে-কলমে TCO-র হিসাব

একটা কোম্পানির পরিকল্পনা: ৪টা server, প্রতিটা $6,000, ৩ বছর পরপর বদলাতে হবে। সঙ্গে rack-এর জায়গা আর বিদ্যুতের জন্য মাসে $300, আর একজন engineer-এর সময়ের চার ভাগের এক ভাগ, মাসে $2,000 ধরে। হিসাব: $24,000 / ৩৬ মাস ≈ $667 + $300 + $500 ≈ মাসে $1,467, server ব্যস্ত থাকুক বা না থাকুক। এবার calculator-এ সমান চারটা instance-এর দাম দেখো, শুধু দরকারের সময় চালিয়ে, তারপর তুলনা করো। শেষে নিজেকে জিজ্ঞেস করো, দুই দিকেই এই তুলনায় কী কী বাদ পড়ে গেল।

#সারসংক্ষেপ

মূল কথা

• Cloud computing মানে internet দিয়ে, দরকারের সময়, IT resource পাওয়া, আর যতটুকু ব্যবহার ততটুকুর দাম। hardware-এর মালিক আর চালক provider; তুমি তার টুকরা ভাড়া নাও।
• পাঁচটা বৈশিষ্ট্য: on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service। Elasticity মানে চাহিদা বাড়লে-কমলে capacity নিজে থেকেই তার পিছু নেয়।
• AWS-এর ছয়টা সুবিধা: নির্দিষ্টের বদলে পরিবর্তনশীল খরচ, economies of scale, capacity আন্দাজ বন্ধ, গতি আর চটপটে ভাব, data center চালানোর ঝামেলা নেই, কয়েক মিনিটে সারা বিশ্বে।
• IaaS (EC2): OS থেকে ওপরে তুমি চালাও। PaaS (Beanstalk, RDS): code আর data তোমার। FaaS (Lambda): তুমি চালাও একটা function। SaaS (Gmail, Rekognition): তোমার শুধু data আর user।
• Public, private, hybrid: hybrid on-premises আর public cloud-কে জোড়া লাগায়; কিছু data জায়গাতেই রাখতে হলে এটাই উত্তর।
• Shared responsibility: AWS দেখে cloud-এর নিরাপত্তা (ভবন, hardware, network, hypervisor); তুমি দেখো cloud-এর ভেতরের নিরাপত্তা (data, IAM, network rule, encryption, আর EC2-এর OS)। service যত managed, AWS তত বেশি নেয়, কিন্তু তোমার data আর permission সবসময় তোমার।
• AWS টাকা নেয় compute, storage আর data transfer out-এর জন্য। ভেতরে আসা data ফ্রি; প্রতি মাসে বাইরে যাওয়া প্রথম ১০০ GB ফ্রি; এক AZ থেকে আরেক AZ-এ প্রতি দিকে GB প্রতি প্রায় $0.01।
• CapEx হলো নিজের সম্পদের জন্য আগেই টাকা দেওয়া; OpEx হলো চলতে চলতে দেওয়া। গায়ের দাম না, তুলনা করো TCO দিয়ে। instance বন্ধ করার পরও storage, IP আর কিছু managed resource-এর bill চলে: আগে budget সেট করো (লেসন ১.৪)।

নিজেকে যাচাই করো: cloud কী আর AWS কীভাবে টাকা নেয়৩০টি প্রশ্ন