EBS Volume Type, Multi-Attach আর Encryption

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

• IOPS, throughput আর latency কী, তা বুঝিয়ে বলতে পারবে, আর I/O size জানা থাকলে একটা থেকে আরেকটা হিসাব করে বের করতে পারবে।
• এখনকার ছয়টা EBS volume type (gp3, gp2, io2 Block Express, io1, st1, sc1) তাদের আসল সীমাসহ চিনবে, আর কোনগুলো boot volume হতে পারে তা বলতে পারবে।
• gp2-র burst bucket কীভাবে কাজ করে তা বোঝাতে পারবে, ছোট একটা gp2 volume কতক্ষণ burst করতে পারে তা হিসাব করতে পারবে, আর gp3 কেন এই ঝামেলা মিটিয়ে দেয় তা বলতে পারবে।
• কখন volume না, বরং instance নিজেই বাধা হয়ে দাঁড়ায় (EBS-optimised bandwidth), সেটা ধরতে পারবে।
• পরীক্ষার scenario পড়ে ঠিক volume type বেছে নিতে পারবে, আর ২০২৫-এ পরীক্ষার কোন পুরনো নিয়মটা বদলে গেছে তা জানবে।
• Multi-Attach ঠিকভাবে ব্যবহার করতে পারবে: শুধু io1/io2, একটাই AZ, সর্বোচ্চ ১৬টা Nitro instance, আর cluster-aware file system।
• EBS encryption কী কী রক্ষা করে, KMS-এর envelope encryption কীভাবে চলে, পুরনো একটা volume কীভাবে encrypt করতে হয়, আর encrypted snapshot অন্য account-এর সাথে কীভাবে share করতে হয়, সব বুঝিয়ে বলতে পারবে।

#এক ধরনের disk দিয়ে কেন সব কাজ চলে না

লেসন ৫.১-এ দেখেছ, EBS volume হলো network দিয়ে লাগানো একটা disk, যেটা একটা Availability Zone-এ থাকে আর একটা instance-এ attach হয়। volume বানাতে গেলে দ্বিতীয় যে প্রশ্নটার মুখোমুখি হবে, এই লেসন সেটা নিয়েই: কোন volume type নেব?

একেক workload disk-কে একেকভাবে খাটায়:

• একটা database disk-এর এখানে-ওখানে ছড়ানো হাজার হাজার ছোট টুকরো (8 বা 16 KiB-এর page) পড়ে আর লেখে, আর প্রতিটার জন্য user বসে থাকে। তার দরকার প্রতি সেকেন্ডে অনেক operation আর কম latency।
• একটা log processing বা data warehouse-এর job বিশাল বিশাল ফাইল শুরু থেকে শেষ পর্যন্ত টানা পড়ে যায়। আলাদা আলাদা operation নিয়ে তার মাথাব্যথা নেই; তার চাই প্রতি সেকেন্ডে অনেক megabyte।
• পুরনো data-র একটা archive মাসে একবার পড়া হয়। তার শুধু সস্তা হলেই চলে।

একটা disk তিনটাতেই সেরা হতে পারে না। তাই EBS দুই রকম type দেয়: operation-এর জন্য বানানো SSD আর টানা স্রোতের মতো data পড়ার জন্য বানানো HDD, দামেও আকাশ-পাতাল তফাত।

#IOPS, throughput আর latency

#disk-কে বোঝার তিনটা সংখ্যা

EBS I/O size মাপে KiB-তে আর throughput মাপে MiB/s-এ (1 MiB = 1,024 KiB)। SSD volume-এ AWS প্রতি 256 KiB বা তার কম-কে একটা I/O operation ধরে; এর চেয়ে বড় I/O কয়েকটা operation হিসেবে গোনা হয়। HDD volume-এ প্রতি 1 MiB বা তার কম-কে একটা operation ধরা হয়।

#তিনটাকে বাঁধে যে সূত্র

Throughput (MiB/s) = IOPS × I/O size (KiB) ÷ 1,024

প্রতিটা volume-এর একসাথে দুটো ছাদ থাকে, একটা IOPS-এর, একটা throughput-এর; যেটায় আগে মাথা ঠেকে, সেটাই তোমার সীমা।

দ্বিতীয় সারিটাই সবচেয়ে বেশি চমকে দেয়: volume-এর “৩,০০০ IOPS আছে”, অথচ বড় I/O-তে সে দেয় ২,০০০, কারণ throughput-এর ছাদটা আগে এসে যায়। gp3-এ এর সমাধান হলো আরও throughput provision করা, আরও IOPS না।

#Latency আর queue depth

একটা application আসলে কত IOPS কাজে লাগাতে পারবে, সেটা latency-র ওপরও নির্ভর করে, আর একসাথে কতগুলো I/O সে ঝুলিয়ে রাখে তার ওপর, যাকে বলে queue depth:

IOPS ≈ queue depth ÷ latency (সেকেন্ডে)

• একটা single-threaded program যে প্রতিটা write শেষ হওয়ার জন্য অপেক্ষা করে (queue depth ১), সে ১ ms latency-র volume-এ বড়জোর ১ ÷ ০.০০১ = ১,০০০ IOPS পাবে, তুমি যত IOPS-ই provision করো না কেন।
• latency ০.৫ ms হলে (io2 Block Express) একই program পৌঁছায় প্রায় ২,০০০ IOPS-এ।
• ১ ms latency-তে ১৬,০০০ provision করা IOPS পুরো ব্যবহার করতে হলে application-কে একসাথে প্রায় ১৬টা I/O চালু রাখতে হবে।

এজন্যই database-এর transaction log, যে একটা রেকর্ড লিখে তারপর অপেক্ষা করে, বেশি IOPS-এর চেয়ে কম latency থেকে বেশি লাভবান হয়। CloudWatch-এ এই queue দেখা যায় VolumeQueueLength নামে।

#Random বনাম sequential: SSD বনাম HDD

• SSD-তে কোনো নড়াচড়া করা যন্ত্রাংশ নেই। block ১ পড়তে যতক্ষণ, block ৯০,০০,০০০ পড়তেও ততক্ষণ, তাই ছোট random I/O-তে সে দারুণ: IOPS বেশি, latency কম।
• HDD-তে ঘুরন্ত platter আর নড়তে থাকা একটা head আছে। প্রতিবার নতুন জায়গায় লাফ দিতে seek-এর সময় লাগে, তাই random I/O ধীর। কিন্তু লম্বা sequential অংশ পড়া খুব দক্ষ, তাই টানা স্রোতের মতো কাজে HDD টাকা প্রতি ভালো throughput দেয়।

EBS এটাকেই দুই পরিবারে ভাগ করেছে: SSD type-গুলোর পরিচয় মূলত IOPS দিয়ে, HDD type-গুলোর পরিচয় throughput দিয়ে।

#SSD পরিবার

#gp2: size যত বড়, performance তত বেশি

gp2 হলো পুরনো General Purpose SSD। এর performance size-এর সাথে বাঁধা:

• Baseline: প্রতি GiB-তে ৩ IOPS, কমপক্ষে ১০০ IOPS (৩৩.৩৩ GiB বা তার ছোট volume-এ) আর বড়জোর ১৬,০০০ IOPS (৫,৩৩৪ GiB-এ গিয়ে পৌঁছায়)।
• Throughput: ১৭০ GiB বা তার ছোট volume-এ 128 MiB/s পর্যন্ত, ৩৩৪ GiB থেকে 250 MiB/s পর্যন্ত।
• Size: 1 GiB থেকে 16 TiB। latency কয়েক millisecond।

ছোট volume তো তাহলে ভয়ানক ধীর হতো, তাই ১ TiB-এর ছোট gp2 volume একটা credit bucket খরচ করে ৩,০০০ IOPS পর্যন্ত burst করতে পারে:

1. প্রতিটা volume শুরু করে ৫৪ লাখ I/O credit-এ ভরা bucket নিয়ে (যাতে boot দ্রুত হয়)।
2. volume যখন তার baseline-এর কম কাজ করে, তখন সে baseline-এর হারে credit জমায় (প্রতি GiB-তে প্রতি সেকেন্ডে ৩টা), ৫৪ লাখ পর্যন্ত।
3. baseline-এর বেশি কাজ করলে প্রতি সেকেন্ডে খরচ করে (burst IOPS − baseline IOPS) পরিমাণ credit।
4. bucket খালি হলে volume নেমে যায় তার baseline-এ। কিছু ভাঙে না, শুধু ধীর হয়ে যায়।

Burst কতক্ষণ চলবে = credit balance ÷ (burst IOPS − baseline IOPS)

এই কারণেই ছোট gp2 volume ফুরিয়ে যায়: ১০০ GiB-এর একটা database volume ব্যস্ত সময় শুরু হলে আধা ঘণ্টা উড়ে চলে, তারপর নেমে যায় ৩০০ IOPS-এ, মানে দশ ভাগের এক ভাগ গতিতে, আর load কয়েক ঘণ্টা না কমা পর্যন্ত ওখানেই পড়ে থাকে। CloudWatch-এ বাকি credit দেখা যায় BurstBalance নামে (শতকরা হিসেবে)। আগের দিনের সমাধান ছিল শুধু IOPS পাওয়ার জন্য volume বড় করা, মানে যে storage লাগবে না তার জন্যও টাকা গোনা।

#gp3: এখনকার default General Purpose SSD

gp3 size আর গতির বাঁধনটা কেটে দেয়:

• size যা-ই হোক, প্রতিটা volume-এ baseline ৩,০০০ IOPS আর 125 MiB/s, দামের মধ্যেই ধরা। কোনো credit নেই, কোনো burst নেই: যতটা provision করা, সারাক্ষণ ততটাই দেয়।
• size থেকে আলাদা করে IOPS আর throughput বাড়ানো যায়: ৮০,০০০ IOPS পর্যন্ত (প্রতি GiB-তে বড়জোর ৫০০ IOPS, তাই ৮০,০০০-এর জন্য অন্তত ১৬০ GiB লাগে) আর 2,000 MiB/s পর্যন্ত (প্রতি provision করা IOPS-এ বড়জোর 0.25 MiB/s, তাই 2,000 MiB/s-এর জন্য অন্তত ৮,০০০ IOPS লাগে)।
• Size: 1 GiB থেকে 64 TiB। latency কয়েক millisecond, durability ৯৯.৮–৯৯.৯%।
• প্রতি GiB-তে gp2-র চেয়ে প্রায় ২০% সস্তা। console এখন default হিসেবে gp3-ই দেখায়।

এই সীমাগুলো বাড়ানো হয়েছে ২০২৫-এর সেপ্টেম্বরে। তার আগে gp3 থেমে যেত ১৬,০০০ IOPS, 1,000 MiB/s আর 16 TiB-এ, আর পরীক্ষার অনেক প্রশ্ন আর নোট এখনো সেই পুরনো সংখ্যাই ব্যবহার করে।

#io1 আর io2 Block Express: Provisioned IOPS SSD

Provisioned IOPS volume সেইসব workload-এর জন্য, যেখানে storage-এর performance হতে হবে বেশি, স্থির আর আগে থেকে জানা। তুমি ঠিক করে দাও কত IOPS চাও, আর সেটার টাকা দাও।

• ২০২৫-এর এপ্রিল থেকে সব io2 volume-ই io2 Block Express; আলাদা “পুরনো io2” বলে আর কিছু নেই।
• সবচেয়ে বড় সংখ্যাগুলো পেতে Nitro-ভিত্তিক instance লাগে। অন্য instance type ৬৪,০০০ IOPS পর্যন্ত provision করা volume লাগাতে পারে, কিন্তু পায় বড়জোর ৩২,০০০।
• একই IOPS-দামে io2 io1-এর চেয়ে বেশি durability আর প্রতি GiB-তে বেশি IOPS দেয়, তাই নতুন volume-এর জন্য AWS io1-এর বদলে io2 নিতে বলে।

কখন gp3-এর বদলে io2 লাগবে?

• একটা volume-এ ৮০,০০০ IOPS বা 2,000 MiB/s-এর বেশি দরকার হলে।
• সবসময় sub-millisecond latency দরকার হলে (gp3-এ latency কয়েক millisecond)।
• mission-critical data-র জন্য ৯৯.৯৯৯% durability দরকার হলে (বড় Oracle বা SQL Server database)।
• Multi-Attach দরকার হলে।

#HDD পরিবার: st1 আর sc1

• দুটোই gp2-র মতো একটা throughput credit bucket ব্যবহার করে, শুধু হিসাবটা MiB/s-এ। ভরা bucket-এ পুরো volume একবার scan করার মতো credit থাকে।
• একটা হিসাব করে দেখি: 5 TiB-এর st1 volume শুরু থেকে শেষ পর্যন্ত 500 MiB/s-এ পড়তে লাগে ৫ × ১০,৪৮,৫৭৬ MiB ÷ ৫০০ MiB/s ≈ ১০,৪৮৬ সেকেন্ড, মানে প্রায় ২.৯ ঘণ্টা। একই scan sc1-এ 250 MiB/s-এ লাগে প্রায় ৫.৮ ঘণ্টা।
• HDD-তে ছোট random I/O মানেই সর্বনাশ: 1 MiB বা তার কম প্রতিটা I/O-কে পুরো 1 MiB-এর credit ধরা হয় (sequential I/O আগে জোড়া লাগিয়ে 1 MiB-এর block বানানো হয়, random I/O-কে তা করা যায় না)। st1-এ 4 KiB করে random read করা একটা database সেকেন্ডে বড়জোর ৫০০টার মতো operation পায়, মানে কাজের data মাত্র 2 MiB/s।
• sc1 “ঠান্ডা”, কিন্তু archive না: এটাও একটা block device, mount করে পড়তে হয়। আসল archive-এর জন্য S3 Glacier-এর storage class আছে (S3-এর অধ্যায়ে)।

#কোন type boot volume হতে পারে?

boot (root) volume-এ থাকে operating system, যে চালু হওয়ার সময় এলোমেলোভাবে অনেক ছোট ছোট ফাইল পড়ে: এটা SSD-র কাজ।

• Boot হয়: gp3, gp2, io2, io1 (আর পুরনো প্রজন্মের magnetic standard type)।
• Boot হয় না: st1, sc1, আর Multi-Attach চালু করা যেকোনো volume।

#instance হলো পাইপের অর্ধেক

EBS volume তার instance-এর সাথে কথা বলে network দিয়ে, instance-এর নিজস্ব EBS bandwidth ধরে (এখনকার instance type-গুলো default-ভাবেই EBS-optimised, বাড়তি খরচ ছাড়া, তাই storage-এর traffic application-এর traffic-এর সাথে ঠেলাঠেলি করে না)। এই bandwidth instance type ঠিক করে দেয়, আর এর নিজেরও IOPS আর throughput-এর সীমা আছে।

তুমি পাবে দুটোর মধ্যে যেটা কম:

আসল performance = min(volume-এর সীমা, instance-এর EBS সীমা)

একটা instance পরিবারের আসল সংখ্যা (m7i; IOPS মাপা 16 KiB I/O-তে, throughput 128 KiB I/O-তে):

তাহলে ৬৪,০০০ IOPS-এর একটা io2 volume m7i.large-এ লাগালে, instance-এর নিজের burst ফুরানোর পর সে চলবে প্রায় ৩,৬০০ IOPS-এ। টাকা দিয়েছ ৬৪,০০০ provisioned IOPS-এর, পাচ্ছ তার আঠারো ভাগের এক ভাগ। সমাধান হলো বড় instance (বা যে পরিবারের EBS bandwidth বেশি), দ্রুততর volume না। আরও খেয়াল রাখো: একটা instance-এ কয়েকটা volume থাকলে তারা সবাই ওই instance-এর সীমাটা ভাগাভাগি করে।

#কোন volume type বেছে নেবে

#সিদ্ধান্তের টেবিল

#খরচ কত: একটা হিসাব কষে দেখি

AWS-এর নিজের pricing-এর উদাহরণগুলোতে এই হার ব্যবহার হয় (Region ভেদে বদলায়): gp2 প্রতি GB-মাসে $0.10; gp3 প্রতি GB-মাসে $0.08, সাথে ৩,০০০-এর ওপরে প্রতি IOPS-মাসে $0.005; io2 প্রতি GB-মাসে $0.125, সাথে প্রতি IOPS-মাসে $0.065 (প্রথম ৩২,০০০ পর্যন্ত); st1 $0.045; sc1 $0.015।

একটা database-এর লাগবে 1,000 GiB জায়গা আর সারাক্ষণ ১০,০০০ IOPS:

workload-এর যদি এমন কিছু না লাগে যা শুধু io2 দেয় (latency, durability, Multi-Attach, ৮০,০০০-এর বেশি IOPS), তাহলে gp3-ই জেতে।

#পরে মত বদলালে: Elastic Volumes

প্রথম দিনেই নিখুঁত হতে হবে, এমন না। Elastic Volumes দিয়ে (modify-volume, লেসন ৫.১-এ আছে) তুমি volume-এর type, size, IOPS আর throughput বদলাতে পারো, volume attach অবস্থায় আর ব্যবহার চলাকালেই, যেমন কোনো downtime ছাড়াই gp2 → gp3। সীমাগুলো মনে রাখো: size শুধু বাড়ানো যায়, তারপর file system-টা নিজেকে বাড়াতে হয়, আর একই volume আবার বদলানোর আগে আগের বদলটা শেষ হওয়া পর্যন্ত (আর কমপক্ষে ৬ ঘণ্টা) অপেক্ষা করতে হয়। st1 আর sc1 125 GiB-এর ছোট হতে পারে না, তাই ছোট একটা volume না বাড়িয়ে ওদের কোনোটায় যেতে পারবে না।

#Multi-Attach: একটা volume, কয়েকটা instance

সাধারণত একটা EBS volume একবারে একটাই instance-এ লাগানো থাকে। Multi-Attach দিয়ে একটা volume একসাথে কয়েকটা instance-এ লাগানো যায়, আর প্রত্যেকে পুরোপুরি পড়তে আর লিখতে পারে। এটা সেইসব clustered application-এর জন্য, যাদের একটা block device ভাগ করে নিতেই হয়, যেমন shared storage-ওয়ালা database cluster, বা একটা failover জোড়া যেখানে একজন পড়ে গেলে আরেকজনকে মুহূর্তেই একই disk ধরে ফেলতে হয়।

#নিয়মগুলো

• শুধু io1 আর io2 (Provisioned IOPS SSD)। gp2, gp3, st1 বা sc1 না। Windows instance-এ চলে শুধু io2।
• একই Availability Zone: volume আর প্রতিটা instance-কে volume-এর AZ-এই থাকতে হবে।
• সর্বোচ্চ ১৬টা instance, সবগুলোকে Nitro System-এর ওপর বানানো হতে হবে।
• boot volume হয় না, আর instance launch-এর সময় Multi-Attach চালু করা যায় না। এটা চালু করতে হয় volume বানানোর সময়, বা পরে volume খোলা (detached) অবস্থায়।
• instance-গুলো volume-এর provision করা IOPS ভাগাভাগি করে; CloudWatch-এর metric সবগুলো মিলিয়ে একসাথে দেখায়।
• io1/io2-র দামের বাইরে বাড়তি কোনো খরচ নেই।
• EBS-এর স্তরে volume-এ সমস্যা হলে লাগানো সব instance একসাথে সেটা হারায়, তাই Multi-Attach data-র দ্বিতীয় কপির বিকল্প না।

#file system কেন এত গুরুত্বপূর্ণ

Multi-Attach শুধু কাঁচা block ভাগ করে, এর বেশি কিছু না। কে কী লিখবে, EBS সেটার কোনো সমন্বয় করে না। ext4 আর XFS-এর মতো সাধারণ file system ধরে নেয় সে-ই একমাত্র লেখক: প্রত্যেক instance file system-এর metadata (কোন block খালি, কোন ফাইলের কোন block) নিজের memory-তে cache করে রাখে।

দুটো instance-এ ext4 হলে কী হয়:

1. instance A দেখল block ৫,০০০ খালি, সেখানে a.log লিখল। খালি block-এর তালিকা সে বদলাল শুধু নিজের cache-এ।
2. instance B-র cache পুরনো, সেও দেখল block ৫,০০০ খালি, আর সেখানে b.log লিখে দিল।
3. দুজনেই নিজেদের metadata disk-এ লিখল। একজন আরেকজনের রেকর্ড মুছে দিল। ফল: নিঃশব্দে data নষ্ট, ফাইলের ভেতর জগাখিচুড়ি, আর ক্ষতিগ্রস্ত file system।

সমাধান হলো একটা cluster-aware file system, যেমন GFS2 বা OCFS2, যেগুলো একটা distributed lock manager চালায়, যাতে একই metadata একবারে একটাই node বদলায়; নয়তো এমন application, যে কাঁচা block device নিজেই সামলায় আর নিজের লেখার ক্রম নিজেই ঠিক রাখে। io1/io2 Multi-Attach volume I/O fencing-এর জন্য NVMe reservations-ও সমর্থন করে: কোনো node বিকল হয়ে গেলেও যদি লেখার চেষ্টা করে, cluster তাকে আটকে দিতে পারে।

#EBS encryption

#কী কী encrypt হয়

একটা encrypted EBS volume বানিয়ে instance-এ লাগালে এই সবকিছু encrypt হয়:

• volume-এর ভেতরের data at rest।
• instance আর volume-এর মধ্যে যাতায়াত করা সব data (EBS-এর network পথে data in transit)।
• volume থেকে নেওয়া সব snapshot।
• সেই snapshot থেকে বানানো সব volume।

encryption হয় তোমার instance যে server-এ চলছে সেখানেই, Nitro hardware-এ, AES-256 দিয়ে। তোমার operating system একটা সাধারণ disk-ই দেখে; কিছু install করতে হয় না, application-এ কিছু বদলাতে হয় না। IOPS আর latency-তে প্রভাব প্রায় নেই, আর এখনকার সব instance type এটা সমর্থন করে। একই instance-এ encrypted আর unencrypted volume একসাথে লাগানো যায়।

যা এটা ঢাকে না: তোমার application network দিয়ে অন্য কোথাও যে data পাঠায় (তার জন্য TLS লাগবে), আর application data পড়ে memory-তে নেওয়ার পরের অবস্থা।

#KMS key: AWS managed নাকি customer managed

EBS AWS KMS-এর key ব্যবহার করে:

#কীভাবে কাজ করে: data key দিয়ে envelope encryption

EBS তোমার disk-এর data KMS-এ পাঠায় না। সে ব্যবহার করে envelope encryption:

1. encrypted volume বানানোর সময় EC2 KMS-এর কাছে একটা নতুন data key চায় (একে DEK-ও বলে; API-টা GenerateDataKeyWithoutPlaintext)। KMS একটা অনন্য data key বানায়, তোমার KMS key দিয়ে সেটাকে encrypt করে, আর ফেরত দেয় শুধু encrypted কপিটা। EBS সেই encrypted data key volume-এর metadata-র সাথে রেখে দেয়।
2. volume attach করার সময় EC2 KMS-কে data key decrypt করে দিতে বলে (CreateGrant, তারপর Decrypt)। IAM আর key policy যাচাই হয় ঠিক এই মুহূর্তে।
3. KMS plaintext data key পাঠায় host-এর Nitro hardware-এ। volume যতক্ষণ লাগানো, key-টা থাকে শুধু ওই hardware-এর memory-তে, আর প্রতিটা block encrypt-decrypt করে।
4. volume-এর snapshot, আর একই KMS key দিয়ে সেই snapshot থেকে বানানো নতুন volume, এই data key-ই আবার ব্যবহার করে।

শেষ কথাটা সত্যিই এভাবে ঘটে: KMS key disable করলে আগে থেকে লাগানো volume চলতে থাকে, কারণ data key আগেই Nitro hardware-এ আছে। কিন্তু volume detach করার পর key আবার ব্যবহারযোগ্য না হওয়া পর্যন্ত সেটা আর attach করা যায় না।

#Encryption by default

EBS encryption by default হলো account-এর একটা setting, যেটা প্রতি Region-এ আলাদা। এটা চালু করলে:

• ওই Region-এ প্রতিটা নতুন volume আর প্রতিটা snapshot copy encrypt হয়, default key দিয়ে (aws/ebs, বা modify-ebs-default-kms-key-id দিয়ে বেছে নেওয়া customer managed key)।
• unencrypted snapshot থেকে বানানো volume-ও encrypt হয়।
• আগে থেকে থাকা volume আর snapshot বদলায় না।
• ওই Region-এ কোনো একটা volume-কে আলাদা করে বাদ দেওয়া যায় না।

কেউ যেন ভুলে না যায়, তা নিশ্চিত করার সবচেয়ে সহজ উপায় এটাই, আর যেসব feature-এ encrypted root লাগে, যেমন hibernation (লেসন ৪.৫), সেগুলোর শর্তও এতে পূরণ হয়।

#আগে থেকে থাকা unencrypted volume encrypt করা

চালু একটা volume বা snapshot-এ encryption সরাসরি চালু করা যায় না। পথটা যায় snapshot-এর ভেতর দিয়ে:

1. ১. unencrypted volume-এর snapshot নাও

   create-snapshot। source-এর মতোই snapshot-টা unencrypted।

2. ২. encryption চালু করে snapshot copy করো

   copy-snapshot --encrypted --kms-key-id …। copy-টা encrypted। (শর্টকাট: copy না করে unencrypted snapshot থেকে সরাসরি create-volume --encrypted দিয়েও encrypted volume বানানো যায়।)

3. ৩. encrypted snapshot থেকে নতুন volume বানাও

   create-volume, instance যে AZ-এ আছে সেখানেই। encrypted snapshot থেকে বানানো প্রতিটা volume encrypted হয়।

4. ৪. volume বদলে দাও

   instance stop করো (root volume হলে) বা file system unmount করো (data volume হলে), পুরনো volume খুলে ফেলো, নতুনটা একই device name দিয়ে লাগাও, তারপর আবার start বা mount করো। data ঠিক আছে কিনা দেখে পুরনো volume আর unencrypted snapshot মুছে দাও।

একই snapshot-copy কৌশলে encrypted volume-এর KMS key-ও বদলানো যায় (অন্য key দিয়ে copy করো)। নতুন key-তে copy মানে পুরো copy, incremental না, তাই snapshot storage-এর খরচ বাড়ে।

ফেরার পথ নেই: encrypted volume বা snapshot থেকে encryption সরানো যায় না, আর encrypted snapshot থেকে বানানো প্রতিটা volume বা copy encrypted হয়। unencrypted data লাগলে operating system-এর স্তরে ফাইলগুলো নতুন একটা unencrypted volume-এ copy করতে হবে।

#encrypted snapshot অন্য account-এর সাথে share করা

• AWS managed key aws/ebs দিয়ে encrypt করা snapshot share করা যায় না: অন্য account ওই key কখনোই ব্যবহার করতে পারে না।
• share করতে হলে snapshot-কে customer managed key দিয়ে encrypt করা থাকতে হবে। না থাকলে আগে copy করে customer managed key দিয়ে আবার encrypt করো।
• snapshot share করো (modify-snapshot-attribute … --user-ids) আর key policy-তে অন্য account-কে অনুমতি দাও (যেমন kms:DescribeKey, kms:CreateGrant, kms:Decrypt, kms:ReEncrypt*, kms:GenerateDataKey*)।
• যে account পাচ্ছে তার জন্য ভালো অভ্যাস: shared snapshot copy করে নিজের key দিয়ে আবার encrypt করে নেওয়া, যাতে আর তোমার key-এর ওপর নির্ভর করতে না হয়।
• encrypted snapshot কখনো public করা যায় না। snapshot আর KMS key দুটোই Region-ভিত্তিক: অন্য Region-এ ব্যবহার করতে চাইলে ওই Region-এর একটা key দিয়ে snapshot-টা সেখানে copy করো।

#কোথায় কী গোলমাল হয়

#System design-এ কীভাবে কাজে লাগে

• boot আর সাধারণ data volume-এর জন্য ধরে নাও gp3: size ঠিক করো data অনুযায়ী, IOPS আর throughput ঠিক করো workload অনুযায়ী। পুরনো gp2 volume খুঁজে বের করো; gp3-এ সরানো চালু অবস্থাতেই করা যায়, আর খরচও কমে।
• EC2-তে নিজে চালানো database: বেশিরভাগের জন্য gp3, আর latency, durability বা ৮০,০০০-এর বেশি IOPS জরুরি হলে io2 Block Express। EBS bandwidth-এর কথা মাথায় রেখে instance-এর size-ও ঠিক করো। managed RDS-এর নিচেও এই একই volume type-গুলো থাকে।
• EC2-তে big data (Hadoop, Kafka, log pipeline): যে বড় sequential data টিকে থাকতে হবে তার জন্য st1, আর scratch বা shuffle-এর জায়গার জন্য instance store।
• একটা volume-এ না কুলালে: operating system-এর ভেতরে RAID 0 দিয়ে কয়েকটা volume stripe করা যায়, তাতে IOPS আর throughput যোগ হয় (তবে instance-এর সীমা ছাড়িয়ে না)। EBS-এ RAID 5/6 নিতে মানা, কারণ parity লিখতে গিয়ে IOPS খেয়ে ফেলে; EBS তো এমনিতেই প্রতিটা volume তার AZ-এর ভেতরে replicate করে রাখে।
• High availability: Multi-Attach clustered software-কে সাহায্য করে একটা AZ-এর ভেতরে; AZ-ই বিকল হলে এটা বাঁচাতে পারে না। তার জন্য application-এর স্তরে replicate করো (অন্য AZ-এ database replica) বা multi-AZ service নাও।
• নিরাপত্তার ভিত্তি: যে যে Region ব্যবহার করো, সবগুলোতে encryption by default চালু করো (প্রায়ই পুরো organisation জুড়ে বাধ্যতামূলক করা হয়), আর যেখানে key policy, cross-account share বা access তুলে নেওয়ার ক্ষমতা লাগবে, সেখানে customer managed key ব্যবহার করো।

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

# 1. Create a gp3 volume with more IOPS and throughput than the baseline, encrypted
aws ec2 create-volume --availability-zone us-east-1a --volume-type gp3 \
  --size 200 --iops 12000 --throughput 500 --encrypted \
  --tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=db-data}]'

# 2. An io2 Block Express volume with Multi-Attach (attach it to Nitro instances in us-east-1a)
aws ec2 create-volume --availability-zone us-east-1a --volume-type io2 \
  --size 500 --iops 50000 --multi-attach-enabled
aws ec2 attach-volume --volume-id $VOL --instance-id $NODE1 --device /dev/sdf
aws ec2 attach-volume --volume-id $VOL --instance-id $NODE2 --device /dev/sdf

# 3. Try Multi-Attach on gp3: rejected (only io1/io2 support it)
aws ec2 create-volume --availability-zone us-east-1a --volume-type gp3 --size 50 --multi-attach-enabled

# 4. Move an old gp2 volume to gp3 live, then watch the modification
aws ec2 modify-volume --volume-id $OLD_GP2 --volume-type gp3 --iops 6000 --throughput 250
aws ec2 describe-volumes-modifications --volume-ids $OLD_GP2

# 5. Watch a gp2 volume's credits (percent) in CloudWatch
aws cloudwatch get-metric-statistics --namespace AWS/EBS --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=$OLD_GP2 --statistics Minimum \
  --start-time 2026-10-24T00:00:00Z --end-time 2026-10-25T00:00:00Z --period 300

# 6. Check the instance's EBS limits (baseline and maximum IOPS / throughput)
aws ec2 describe-instance-types --instance-types m7i.large m7i.8xlarge \
  --query "InstanceTypes[].[InstanceType,EbsInfo.EbsOptimizedInfo.BaselineIops,EbsInfo.EbsOptimizedInfo.MaximumIops,EbsInfo.EbsOptimizedInfo.BaselineThroughputInMBps]"

# 7. Encryption by default in this Region, and its key
aws ec2 enable-ebs-encryption-by-default
aws ec2 get-ebs-encryption-by-default
aws ec2 get-ebs-default-kms-key-id

# 8. Encrypt an existing unencrypted volume
SNAP=$(aws ec2 create-snapshot --volume-id $PLAIN_VOL --query SnapshotId --output text)
aws ec2 wait snapshot-completed --snapshot-ids $SNAP
ENC=$(aws ec2 copy-snapshot --source-region us-east-1 --source-snapshot-id $SNAP \
  --encrypted --kms-key-id alias/app-ebs --query SnapshotId --output text)
aws ec2 wait snapshot-completed --snapshot-ids $ENC
NEW=$(aws ec2 create-volume --snapshot-id $ENC --availability-zone us-east-1a \
  --volume-type gp3 --query VolumeId --output text)
aws ec2 stop-instances --instance-ids $ID            # if it is the root volume
aws ec2 detach-volume --volume-id $PLAIN_VOL
aws ec2 attach-volume --volume-id $NEW --instance-id $ID --device /dev/xvda
aws ec2 start-instances --instance-ids $ID

# 9. Share an encrypted snapshot (customer managed key) with another account
aws ec2 modify-snapshot-attribute --snapshot-id $ENC --attribute createVolumePermission \
  --operation-type add --user-ids 111122223333
# ...and add account 111122223333 to the key policy of alias/app-ebs.

#সারসংক্ষেপ

মূল কথাগুলো

• Throughput = IOPS × I/O size। প্রতিটা volume-এর একটা IOPS-এর ছাদ আর একটা throughput-এর ছাদ আছে; যেটায় আগে ঠেকে সেটাই সীমা। একটা application কত IOPS কাজে লাগাতে পারবে, তা ঠিক করে latency আর queue depth।
• gp2: প্রতি GiB-তে ৩ IOPS (১০০ থেকে ১৬,০০০); ১ TiB-এর ছোট volume ৫৪ লাখ credit-এর bucket খরচ করে ৩,০০০ IOPS-এ burst করে; ১০০ GiB-এর volume প্রায় ৩৩ মিনিট burst করে, তারপর ৩০০ IOPS-এ নেমে যায়।
• gp3 (default): যেকোনো size-এ ৩,০০০ IOPS আর 125 MiB/s দামের মধ্যে; size থেকে আলাদা করে ৮০,০০০ IOPS আর 2,000 MiB/s পর্যন্ত provision করা যায়; 64 TiB পর্যন্ত; credit নেই; gp2-র চেয়ে প্রায় ২০% সস্তা।
• io2 Block Express: ২,৫৬,০০০ IOPS পর্যন্ত, প্রতি GiB-তে ১,০০০ IOPS, 4,000 MiB/s, 64 TiB, sub-millisecond latency, ৯৯.৯৯৯% durability। io1 পুরনো সংস্করণ (৬৪,০০০ IOPS, ৫০:১)। দুটোই Multi-Attach পারে।
• st1 (big data, log, data warehouse, 500 MiB/s পর্যন্ত) আর sc1 (ঠান্ডা data, সবচেয়ে সস্তা, 250 MiB/s পর্যন্ত): HDD, কমপক্ষে 125 GiB, boot হয় না, ছোট random I/O-তে অচল।
• Boot volume: gp3, gp2, io2, io1। st1, sc1 বা Multi-Attach volume না।
• আসল performance = min(volume, instance-এর EBS bandwidth): ছোট instance-এ দ্রুত volume লাগালেও সে ধীরই থাকে।
• Multi-Attach: শুধু io1/io2, একই AZ, সর্বোচ্চ ১৬টা Nitro instance, boot volume না, লাগবে cluster-aware file system (GFS2, OCFS2); ext4/XFS হলে data নষ্ট হবে।
• Encryption: data at rest, instance পর্যন্ত data in transit, snapshot, আর snapshot থেকে বানানো volume; KMS-এর পাহারায় থাকা data key দিয়ে Nitro hardware-এ AES-256; performance-এ প্রভাব প্রায় নেই; encryption by default প্রতি Region-এ।
• পুরনো volume encrypt করার পথ: snapshot → encrypted copy → নতুন volume → বদলে দাও। unencrypted-এ ফেরার পথ নেই। encrypted snapshot share করা যায় শুধু customer managed key আর key policy দিয়ে; aws/ebs share হয় না।

নিজেকে যাচাই করো: EBS volume type, Multi-Attach আর encryption৩০টি প্রশ্ন