Storage Class আর Lifecycle Rule

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

• durability আর availability-র পার্থক্য বোঝাতে, আর একটা AZ বসে গেলে Standard, One Zone-IA আর Express One Zone-এর data-র কী হয় তা বলতে।
• S3-এর প্রতিটা storage class (Standard, Intelligent-Tiering, Standard-IA, One Zone-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive, Express One Zone) তার দাম, retrieval fee, minimum storage duration আর minimum billable size সহ বর্ণনা করতে।
• archive করা object restore করতে, Expedited, Standard আর Bulk retrieval-এর মধ্যে বেছে নিতে, আর কখন provisioned capacity লাগে তা জানতে।
• retrieval fee, minimum duration-এর চার্জ আর ১২৮ KB-এর minimum ধরে একটা class-এর আসল খরচ হিসাব করতে।
• lifecycle rule সাজাতে: transition, expiration, noncurrent version, delete marker আর অসমাপ্ত multipart upload, prefix, tag বা size দিয়ে বেছে; আর কত দিন পর সরাবে তা ঠিক করতে Storage Class Analysis ব্যবহার করতে।

#S3-এ কেন একটার বেশি storage class

#একই বাইট, আলাদা প্রয়োজন

লেসন ১০.১-এ তুমি যত object upload করেছ, সব গিয়ে পড়েছে S3 Standard-এ, এটাই default। Standard দ্রুত, প্রায় সবসময় পাওয়া যায়, কোনো বাড়তি fee নেই; প্রতিদিন যে data লাগে তার জন্য এটাই ঠিক। কিন্তু একটা সত্যিকারের প্রতিষ্ঠান কী কী রাখে, একবার ভাবো:

• একটা হাসপাতাল আইনের কারণে প্রতিটা scan ৭ বছর রাখে, অথচ একটা scan প্রথম মাসে কয়েকবার দেখা হয়, আর এক বছর পর প্রায় কখনোই না;
• একটা খবরের site ১৫ বছরের ছবি রাখে; এই সপ্তাহের ছবি লাখ লাখ বার খোলা হয়, আর ২০১২ সালের একটা ছবি খোলা হয় কেবল যখন কোনো editor “দশ বছর আগে” ধরনের খবর লেখেন;
• একটা ব্যাংক নিয়ন্ত্রক সংস্থার জন্য web server-এর log এক বছর রাখে, আর পড়ে শুধু কোনো incident বা audit-এর সময়;
• একটা machine learning দল একই training file দিনে হাজারবার পড়ে, আর প্রতিটা millisecond বাঁচাতে চায়।

এই সবকিছুর জন্য Standard-এর দাম দেওয়া অপচয়, আর ML দলের জন্য Standard সবচেয়ে দ্রুত বিকল্পও না। তাই S3 দেয় নানা storage class: একই API, একই bucket, একই 11 nines durability, কিন্তু চারটা জিনিসের মধ্যে আলাদা আলাদা দর-কষাকষি:

1. Storage-এর দাম, প্রতি GB প্রতি মাসে।
2. পড়ার খরচ: যত GB পড়বে তার fee (retrieval fee), আর প্রতিটা request-এর দাম।
3. পড়তে কত সময়: millisecond, নাকি restore করার পর কয়েক মিনিট থেকে কয়েক ঘণ্টা।
4. শর্ত: কমপক্ষে কতদিন রাখতে হবে (minimum storage duration) আর object যত ছোটই হোক কমপক্ষে কত সাইজের টাকা দিতে হবে (minimum billable size)।

Storage যত সস্তা, পড়তে তত বেশি খরচ, আর তত বেশি দিন রাখার বাধ্যবাধকতা। Class বাছাই মানে প্রতিটা data এই বক্ররেখার কোথায় বসবে সেটা ঠিক করা, আর data পুরোনো হতে থাকলে lifecycle rule তাকে রেখা ধরে নিচে নামিয়ে দেয়।

প্রতিটা object-এর নিজস্ব storage class থাকে। Upload করার সময় তুমি সেটা ঠিক করে দিতে পারো (CLI-তে --storage-class, API-তে x-amz-storage-class header), পরে object copy করে বদলাতে পারো, অথবা lifecycle rule বা Intelligent-Tiering-কে বদলাতে দিতে পারো। একই bucket-এ সব class-এর object পাশাপাশি থাকতে পারে।

#Durability আর availability

শব্দ দুটো শুনতে কাছাকাছি, আর পরীক্ষায় ঠিক এটারই সুযোগ নেওয়া হয়।

#Durability: data কি টিকে থাকবে?

Durability মাপে একটা object হারিয়ে যাওয়ার সম্ভাবনা। S3-এর প্রতিটা storage class বছরে 99.999999999% (11 nines) durability-র জন্য design করা। AWS নিজেই উদাহরণ দেয়: ১ কোটি (10,000,000) object রাখলে গড়ে প্রতি ১০,০০০ বছরে একটা object হারানোর আশঙ্কা। অঙ্কটা এরকম: প্রতি object-এ বছরে হারানোর হার 10⁻¹¹ × 10⁷টা object = বছরে 10⁻⁴টা object, অর্থাৎ ১০,০০০ বছরে একটা।

S3 এখানে পৌঁছায় তিনভাবে: প্রতিটা object অনেকগুলো device-এ redundant ভাবে রাখে, checksum দিয়ে সারাক্ষণ রাখা data যাচাই করে, আর কোনো কপি নষ্ট হলে আবার বানিয়ে নেয়। একটা AZ-এ থাকা class দুটো বাদে বাকি সব class-এ ওই device-গুলো ছড়ানো থাকে কমপক্ষে তিনটা Availability Zone জুড়ে (লেসন ১.২), তাই পুরো একটা AZ হারালেও object টিকে যায়।

#Availability: এই মুহূর্তে কি data পাওয়া যাবে?

Availability মাপে কত শতাংশ সময় request সফল হয়। ভেতরের ক্ষণিকের কোনো সমস্যায় একটা request 500 বা 503 error দিয়ে ব্যর্থ হতে পারে, অথচ object পুরোপুরি নিরাপদ; AWS SDK নিজে থেকেই আবার চেষ্টা করে। Availability class ভেদে আলাদা:

Design-এর সংখ্যাটা হলো system কীসের জন্য বানানো; SLA হলো তার চেয়ে কম একটা সংখ্যা, যেটা না মানলে AWS service credit দেয়।

#যে class-গুলো একটাই AZ-এ থাকে

One Zone-IA আর Express One Zone তাদের data রাখে মাত্র একটা AZ-এ। ওই AZ-এর ভেতরে data এখনো কয়েকটা device-এ redundant ভাবে থাকে, তাই device নষ্ট হওয়ার বিপরীতে design durability এখনো 11 nines। কিন্তু আগুন, বন্যা বা ভূমিকম্পে AZ-টাই ধ্বংস হলে data শেষ, আর AZ যতক্ষণ বসে থাকে ততক্ষণ data পাওয়াও যায় না। এজন্যই AWS One Zone-IA-র পরামর্শ দেয় শুধু এমন data-র জন্য যা আবার বানানো যায়: thumbnail, transcode করা কপি, backup-এর দ্বিতীয় কপি, বা Cross-Region Replication দিয়ে বানানো replica (লেসন ১০.৪)।

#একটা একটা করে storage class

#S3 Standard: ব্যবহারে থাকা data-র default

• 99.99% availability, কমপক্ষে তিনটা AZ-এ data, millisecond-এ access, বেশি throughput।
• কোনো retrieval fee নেই, minimum duration নেই, minimum size নেই। টাকা দাও শুধু storage-এর (us-east-1-এ প্রথম ৫০ TB-র জন্য মাসে GB-প্রতি $0.023, তার বেশি হলে একটু কম) আর request-এর (প্রতি ১,০০০ PUT-এ $0.005, প্রতি ১,০০০ GET-এ $0.0004)।
• ঘনঘন পড়া হয় এমন সবকিছুর জন্য: website আর mobile app-এর content, content distribution, প্রতিদিন data ঘাঁটে এমন big data analytics, game-এর asset, আর প্রায় যেকোনো data-র প্রথম কয়েক সপ্তাহ।

Slide-এ আরও বলা আছে, Standard একসাথে দুটো facility হারানো সহ্য করার মতো করে বানানো; “AZ জুড়ে redundant” কথাটারই পুরোনো রূপ এটা।

#Standard-IA আর One Zone-IA: কম পড়া হয়, কিন্তু লাগলে সাথে সাথে

“IA” মানে infrequent access: যে data কালেভদ্রে পড়া হয়, হয়তো মাসে একবার বা তারও কম, কিন্তু যখন লাগে তখন millisecond-এ ফেরত চাই।

• Storage: Standard-IA মাসে GB-প্রতি $0.0125 (Standard-এর চেয়ে প্রায় ৪৬% কম), One Zone-IA $0.01 (প্রায় ৫৭% কম)।
• Retrieval fee: যত GB পড়বে প্রতি GB-তে $0.01, সাথে request-এর দামও বেশি (প্রতি ১,০০০ PUT-এ $0.01, প্রতি ১,০০০ GET-এ $0.001)।
• Minimum storage duration: ৩০ দিন। ১০ দিন পর object মুছলে, overwrite করলে বা অন্য class-এ সরালেও ৩০ দিনের টাকাই দিতে হবে।
• Minimum billable size: ১২৮ KB। ২০ KB-এর object-এর bill হবে ১২৮ KB ধরে।
• Availability: Standard-IA 99.9%, কমপক্ষে তিনটা AZ জুড়ে; One Zone-IA 99.5%, একটাই AZ-এ।

Standard-IA নাও backup, disaster recovery-র কপি, আর এমন পুরোনো data-র জন্য যার আর কোনো কপি নেই (যেমন প্রথম মাস পেরোনো ব্যাংকের মাসিক statement)। One Zone-IA নাও এমন data-র জন্য যা আবার বানানো সস্তা বা অন্য কোথাও আছে: thumbnail, on-premises backup-এর দ্বিতীয় কপি, replica।

IA কখন সস্তা? প্রতি GB-তে Standard-IA মাসে $0.0105 বাঁচায়, আর প্রতিবার পড়লে $0.01 খরচ করায়। তাই গড়ে প্রতিটা GB মাসে মোটামুটি একবারের কম পড়া হলে IA জেতে। প্রতিদিন পড়লে IA-র খরচ Standard-এর কয়েক গুণ হয়ে যায়।

#Glacier Instant Retrieval: archive-এর দাম, millisecond-এ access

S3 Glacier Instant Retrieval (২০২১ সালে এসেছে) এমন data-র জন্য যা কদাচিৎ পড়া হয়, মোটামুটি তিন মাসে একবার, কিন্তু যখন লাগে সাথে সাথে খুলতে হয়: এক বছর পেরোনো medical image, পুরোনো খবরের ছবি, user-দের upload করা এমন content যা আর কেউ দেখে না।

• Storage মাসে GB-প্রতি $0.004, Standard-এর চেয়ে প্রায় ৮৩% কম।
• Retrieval GB-প্রতি $0.03, Standard-IA-র তিনগুণ, আর প্রতি ১,০০০ GET-এ $0.01।
• Minimum duration ৯০ দিন, minimum billable size ১২৮ KB।
• সাধারণ GET দিয়েই millisecond-এ access, 99.9% availability, কমপক্ষে তিনটা AZ। কোনো restore ধাপ নেই।

#Glacier Flexible Retrieval: আগে restore, তারপর পড়া

S3 Glacier Flexible Retrieval (আগে নাম ছিল শুধু S3 Glacier; API-তে নাম এখনো GLACIER) এমন archive-এর জন্য যা বছরে একবার-এর মতো পড়া হয়, আর কয়েক মিনিট বা কয়েক ঘণ্টা অপেক্ষা করলে সমস্যা নেই: পুরোনো backup, শেষ হয়ে যাওয়া project, media-র master file।

• Storage মাসে GB-প্রতি $0.0036।
• Minimum duration ৯০ দিন। Object-এর কোনো minimum size নেই, কিন্তু archive করা প্রতিটা object-এর সাথে ৪০ KB বাড়তি যোগ হয়: ৮ KB নাম আর metadata, Standard-এর দামে (যাতে archive করা object-ও সাথে সাথে list করা যায়), আর ৩২ KB index, Glacier-এর দামে।
• সরাসরি পড়া যায় না: আগে একটা অস্থায়ী কপি restore করতে হয়, তিনটা retrieval option-এর একটা দিয়ে:

#Glacier Deep Archive: AWS-এর সবচেয়ে সস্তা storage

S3 Glacier Deep Archive এমন data-র জন্য যা বছরের পর বছর রাখবে, হয়তো কখনো পড়বেই না: compliance-এর record, এক বছর পেরোনো হাসপাতালের ৭ বছরের scan, ব্যাংকের ১০ বছরের লেনদেনের archive, tape library-র বদলি।

• Storage মাসে GB-প্রতি $0.00099: মানে মাসে TB-প্রতি প্রায় ১ ডলার, Standard-এর চেয়ে ২৩ গুণ সস্তা।
• Minimum duration ১৮০ দিন, সাথে object-প্রতি সেই একই ৪০ KB বাড়তি।
• Restore option: Standard ১২ ঘণ্টার মধ্যে (GB-প্রতি $0.02) আর Bulk ৪৮ ঘণ্টার মধ্যে (GB-প্রতি $0.0025)। Expedited বলে কিছু নেই।

#Archive করা object restore করা

Glacier Flexible Retrieval আর Deep Archive-এর object (আর Intelligent-Tiering-এর ঐচ্ছিক archive tier-গুলোর object-ও) এখনো S3 object: listing-এ তাদের key, size আর metadata দেখা যায়। কিন্তু GET করলে আসে 403, সাথে error code InvalidObjectState। পড়তে চাইলে:

1. একটা restore request পাঠাও (aws s3api restore-object), সাথে বলে দাও কোন retrieval tier আর অস্থায়ী কপিটা কত দিন রাখবে।
2. S3 202 দিয়ে কাজটা নেয় আর শুরু করে। একটা object-এর জন্য একবারে একটাই restore চলে। Bucket-এ s3:ObjectRestore:Post আর s3:ObjectRestore:Completed-এর event notification চালু থাকলে (লেসন ১০.৭) শুরু আর শেষ হওয়ার খবর তোমার কাছে চলে আসে, বারবার head-object দিয়ে খোঁজ নিতে হয় না।
3. কপি তৈরি হলে কপির মেয়াদ থাকা পর্যন্ত GET কাজ করে। এই সময়টায় তুমি টাকা দাও দুটোরই: archive করা object আর অস্থায়ী কপি, কপির দাম Standard-এর হারে।
4. Object-এর storage class বদলায় না। স্থায়ীভাবে ফিরিয়ে আনতে চাইলে, restore করা কপি থাকতে থাকতেই নতুন storage class দিয়ে object-টা নিজের ওপর copy করো।

বড় বা জরুরি restore-এর জন্য দুটো বাড়তি জিনিস:

• Provisioned capacity। On-demand Expedited retrieval তখনই নেওয়া হয় যখন capacity খালি থাকে; ভিড়ের সময় এটা 503 দিয়ে ব্যর্থ হয়। মাসিক fee দিয়ে কেনা provisioned capacity-র প্রতিটা unit নিশ্চিত করে প্রতি ৫ মিনিটে কমপক্ষে ৩টা Expedited retrieval আর ৩০০ MB/s পর্যন্ত গতি; কিনতে হয় সেই account-কে, যে request পাঠায়। জরুরি restore যদি তোমার পরিকল্পনারই অংশ হয়, তখন এটা কেনো; আর যদি প্রায়ই সাথে সাথে access লাগে, তাহলে বরং Glacier Instant Retrieval নাও।
• S3 Batch Operations (লেসন ১০.৭ আর ১০.১২) একটা job দিয়েই লাখ লাখ object-এর restore শুরু করে দেয়, account-এর পুরো restore request rate (সেকেন্ডে ১,০০০) কাজে লাগায়, আর Glacier Flexible Retrieval থেকে এর Standard restore সাধারণত কয়েক মিনিটের মধ্যেই শুরু হয়। খুব বড় data set restore হয় account-প্রতি দিনে ১–২ PB পর্যন্ত গতিতে।

#Intelligent-Tiering: যখন জানো না data কতটা পড়া হবে

S3 Intelligent-Tiering একটাই storage class, যার ভেতরে কয়েকটা access tier। প্রতিটা object শেষ কবে পড়া হয়েছে S3 সেটা দেখে, আর নিজে থেকেই tier বদলে দেয়:

এটা কোথায় আলাদা:

• কোনো retrieval fee নেই, tier বদলানোরও কোনো চার্জ নেই। স্বয়ংক্রিয় যেকোনো tier থেকে একবার পড়লেই object সোজা Frequent Access-এ ফিরে যায়। ঐচ্ছিক archive tier থেকে Standard আর Bulk restore-ও বিনামূল্যে।
• Monitoring আর automation fee: মাসে প্রতি ১,০০০ object-এ $0.0025।
• Minimum storage duration নেই, minimum billable size-ও নেই। তবে ১২৮ KB-এর ছোট object-এ নজরদারি হয় না, এগুলো কখনো Frequent Access tier ছেড়ে নামে না (monitoring fee-ও লাগে না)।
• দুটো archive tier default-এ বন্ধ। Bucket-এ একটা Intelligent-Tiering configuration দিয়ে চালু করতে হয় (চাইলে prefix বা tag দিয়ে বেছে), আর শুধু সেই data-র জন্য যার জন্য তোমার application অপেক্ষা করতে পারে, কারণ ওখান থেকে পড়তে restore লাগে।
• Design করা availability 99.9%, data কমপক্ষে তিনটা AZ-এ।

Notes-এ লেখা আছে Intelligent-Tiering “AI ব্যবহার করে user-এর অভ্যাস শেখে”। আসলে ব্যাপারটা এর চেয়ে সহজ আর অনুমানযোগ্য: শেষবার পড়ার পর কত দিন গেল, তার ওপর একটা বাঁধা নিয়ম। কিছুই ভবিষ্যদ্বাণী করা হয় না।

কখন নেবে: যখনই access-এর ধরন অজানা, অনিশ্চিত বা বদলায়: অনেক দল মিলে ব্যবহার করে এমন data lake, user-দের upload, ইতিহাস নেই এমন নতুন product। কখন নেবে না: যে data-র ধরন তুমি জানো (৩০ দিন পর আর কখনো পড়া হয় না এমন log-এর জন্য lifecycle rule সস্তা, কারণ তাতে monitoring fee নেই), আর খুব ছোট ছোট object-এ ভরা bucket।

#S3 Express One Zone: সবচেয়ে দ্রুত class

S3 Express One Zone (নভেম্বর ২০২৩-এ এসেছে) বানানো হয়েছে S3-এর পক্ষে সম্ভব সবচেয়ে কম latency-র জন্য: নিয়মিত এক অঙ্কের millisecond-এ access, Standard-এর চেয়ে ১০ গুণ পর্যন্ত দ্রুত, আর সেকেন্ডে কয়েক লাখ request।

বাকি সব class থেকে এটা কোথায় আলাদা:

• এটা থাকে অন্য ধরনের bucket-এ, যার নাম directory bucket, আর সেটা বানাতে হয় তোমার বেছে নেওয়া একটা AZ-এ। নামের শেষে থাকে AZ ID, যেমন ml-train--use1-az4--x-s3। Storage class সবসময় EXPRESS_ONEZONE।
• তোমার compute (EC2, ECS, EKS, SageMaker training job) রাখো একই AZ-এ, যাতে data AZ পেরিয়ে যেতে না হয়। প্রতিটা request-এর ঝামেলা কমাতে authentication চলে স্বল্পমেয়াদি session দিয়ে (CreateSession)।
• 99.95% availability আর 11 nines design durability, তবে একটাই AZ-এর ভেতরে: AZ-এ বিপর্যয় হলে data হারায়, ঠিক One Zone-IA-র মতো।
• দামের হিসাব উল্টে যায়: storage সবচেয়ে দামি, মাসে GB-প্রতি $0.11 (Standard-এর প্রায় ৫ গুণ), অথচ request অনেক সস্তা (প্রতি ১,০০০ PUT-এ $0.00113, প্রতি ১,০০০ GET-এ $0.00003), সাথে GB-প্রতি সামান্য upload ($0.0032) আর retrieval ($0.0006) চার্জ। এটা লাভজনক খুব ঘনঘন পড়া গরম data-র জন্য, data জমিয়ে রাখার জন্য না।
• Minimum duration বা size নেই। Directory bucket-এ lifecycle rule object expire করতে আর multipart upload পরিষ্কার করতে পারে, কিন্তু অন্য class-এ transition করতে পারে না।

কোথায় কাজে লাগে: একই file বারবার পড়ে এমন machine learning training, Athena বা Spark দিয়ে interactive analytics, financial modelling, media processing, HPC-র scratch জায়গা। চেনা নকশাটা হলো: মূল data থাকে Standard বা Intelligent-Tiering-এ, আর job-এর জন্য দরকারি অংশটা Express One Zone-এ copy করে নেওয়া হয়।

#Class-গুলো পাশাপাশি

#পুরো তুলনার টেবিল

#us-east-1-এর দাম (অক্টোবর ২০২৬)

দাম বদলায়, Region ভেদেও আলাদা; পরীক্ষায় কখনো ঠিক সংখ্যা জিজ্ঞেস করে না, কিন্তু ক্রমটা জানতেই হবে: Standard থেকে Deep Archive-এর দিকে storage সস্তা হতে থাকে, আর retrieval-এর খরচ, retrieval-এর সময় আর minimum duration বাড়তে থাকে।

#বাস্তবে minimum duration আর minimum size

এই দুটো নিয়ম স্বল্পস্থায়ী বা ছোট data-র উত্তর চুপচাপ বদলে দেয়:

• Minimum duration। ১ TB Glacier Instant Retrieval-এ রেখে ১০ দিন পর মুছে দিলে টাকা দিতে হবে ৯০ দিনের: $0.004 × 1,024 × 3 ≈ $12.29, যা ১০ দিন Standard-এ রাখার ($0.023 × 1,024 × 10/30 ≈ $7.85) চেয়েও বেশি। মুছে ফেলা, overwrite করা বা অন্য class-এ transition করা, তিনভাবে আগে বেরোলেই বাকি দিনগুলোর আনুপাতিক চার্জ লাগে।
• Minimum size। ১৬ KB-এর ১ কোটি object মানে আসলে ১৫৩ GB data। Standard-এ: 153 × $0.023 ≈ মাসে $3.51। Standard-IA-তে প্রতিটার bill ১২৮ KB ধরে, তাই 1,221 GB × $0.0125 ≈ মাসে $15.26: Standard-এর চার গুণেরও বেশি।
• Archive-এর বাড়তি অংশ। ওই একই ১ কোটি object Deep Archive-এ রাখলে 1 কোটি × 40 KB ≈ ৩৮১ GB বাড়তি যোগ হয়, যার ৭৬ GB Standard-এর দামে। Archive করার আগে ছোট file-গুলো বড় archive-এ (tar বা zip) বেঁধে নাও।
• Request-এর খরচ। ওই ১ কোটি object Deep Archive-এ সরাতে transition request-এই লাগে 10,000 × $0.05 = $500, অথচ সেখানে data রাখতে মাসে খরচ প্রায় ১৫ সেন্ট। ছোট object-এ request fee-ই আসল খরচ।

#এক class থেকে আরেক class-এ সরানো

#Object-এর class বদলানোর উপায়

• Upload-এর সময়: aws s3 cp report.pdf s3://bucket/ --storage-class STANDARD_IA। General purpose bucket-এ সরাসরি যেকোনো class-এ upload করা যায়, Glacier class-গুলোতেও, কোনো অপেক্ষা ছাড়া।
• Copy করে: object-টা নিজের ওপর (বা নতুন key-তে) নতুন storage class দিয়ে copy করো: aws s3api copy-object … --storage-class GLACIER_IR। আরও গরম class-এ ওপরে তোলার এটাই একমাত্র উপায়, আর archive করা object হলে আগে restore লাগে।
• Lifecycle rule দিয়ে: সাধারণ পথ, স্বয়ংক্রিয়, prefix, tag বা size ধরে।
• Intelligent-Tiering দিয়ে: ওই একটা class-এর ভেতরে, তার tier-গুলোর মধ্যে।
• S3 Batch Operations দিয়ে: আগে থেকে থাকা লাখ লাখ object একটা job-এ নতুন class দিয়ে copy (লেসন ১০.১২)।

#ঝরনার মতো নিচে নামা

Lifecycle rule object-কে শুধু নিচের দিকে নামায়, গরম থেকে ঠান্ডা class-এর দিকে, এই ক্রমে: Standard → Standard-IA → Intelligent-Tiering → One Zone-IA → Glacier Instant Retrieval → Glacier Flexible Retrieval → Glacier Deep Archive। তবে নিচের দিকের সব জোড়া চলে না: One Zone-IA নামতে পারে শুধু Glacier Flexible Retrieval বা Deep Archive-এ, আর Intelligent-Tiering-এর object যেতে পারে শুধু তার এখনকার tier-এর সাথে মানানসই class-এ। Deep Archive থেকে lifecycle দিয়ে কিছুই বের হয় না। Express One Zone এই ঝরনার মধ্যেই নেই।

#সম্প্রতি যে নিয়মগুলো বদলেছে

• Standard-IA আর One Zone-IA-র আগের ৩০ দিনের অপেক্ষা উঠে গেছে (জুলাই ২০২৬)। বহু বছর ধরে lifecycle rule কোনো object-কে Standard-IA বা One Zone-IA-তে সরাতে পারত না যতক্ষণ না তার বয়স কমপক্ষে ৩০ দিন হয়; notes আর অনেক পরীক্ষার প্রশ্নে এখনো তাই লেখা। ১৬ জুলাই ২০২৬ থেকে rule এই class-গুলোতে transition করাতে পারে ০ দিন থেকেই। যেটা বদলায়নি: IA-তে ঢোকার পর ৩০ দিনের minimum storage duration। পরীক্ষায় কোনো প্রশ্ন যদি “Standard-IA-তে সরানোর আগে Standard-এ ৩০ দিন রাখতেই হবে” নিয়মের ওপর দাঁড়িয়ে থাকে, তাহলে ওই নিয়ম মাথায় রেখেই উত্তর দাও; বাস্তবের design-এ এখন অপেক্ষাটা বাদ দিতে পারো।
• ছোট object যেখানে আছে সেখানেই থাকে (সেপ্টেম্বর ২০২৪)। Lifecycle rule default-এ ১২৮ KB-এর ছোট object কোনো class-এই transition করে না, কারণ প্রতিটা transition একটা পয়সার request, যা বাঁচানোর চেয়ে বেশি খরচ করে। তবু সরাতে চাইলে object size filter (ObjectSizeGreaterThan বা ObjectSizeLessThan) যোগ করো। ছোট object সরাসরি Standard-IA-তে upload করা এখনো যায়; শুধু bill হয় ১২৮ KB ধরে।

#Lifecycle rule

#একটা rule কী দিয়ে বানানো

একটা bucket-এ একটাই lifecycle configuration থাকে, তাতে ১,০০০টা পর্যন্ত rule। প্রতিটা rule-এ থাকে:

• একটা ID আর একটা status (Enabled বা Disabled);
• একটা filter: পুরো bucket, একটা prefix (logs/), এক বা একাধিক tag (Department=Finance), object size-এর একটা সীমা, বা এগুলোর মিশ্রণ (AND দিয়ে জোড়া);
• এক বা একাধিক action, প্রতিটার সাথে কত দিন পর (বা কোন তারিখে)।

Action-গুলো:

পরিষ্কার করার দুটো action (expired delete marker আর অসমাপ্ত multipart upload) tag দিয়ে filter করা rule-এ ব্যবহার করা যায় না।

#S3 কীভাবে দিন গোনে আর bill করে

• দিন গোনা হয় object তৈরির সময় (তার last-modified সময়) থেকে, অথবা একটা version যখন noncurrent হলো তখন থেকে, আর পরের মাঝরাত UTC পর্যন্ত পূর্ণ করে নেওয়া হয়। ১৫ জানুয়ারি সকাল ১০:৩০-এ তৈরি object-এ ৩ দিনের rule থাকলে তার সময় আসে ১৯ জানুয়ারি ০০:০০ UTC-তে।
• Rule চলে asynchronously, মানে নির্ধারিত দিনের একটু পরে object সরতে বা মুছতে পারে। কিন্তু bill চলে rule অনুযায়ী, দেরি অনুযায়ী না: Glacier-এ transition-এর bill নতুন দামে শুরু হয় নির্ধারিত দিন থেকেই, আর expire হওয়ার তারিখের পর object-এর storage-এর জন্য কোনো টাকা লাগে না।
• Rule-গুলো একে অপরের ওপর পড়লে চিরতরে মুছে ফেলা transition-এর ওপরে জেতে, transition জেতে delete marker বানানোর ওপরে, আর Glacier Flexible Retrieval আর কোনো IA class-এর মধ্যে S3 বেছে নেয় সস্তা Glacier Flexible Retrieval-কে।
• একটা rule কোনো class-এর minimum duration শেষ হওয়ার আগে object বের করতে পারে না। একই rule-এ ৪ দিনে Glacier Instant Retrieval আর ২০ দিনে Deep Archive দিলে S3 rule-টা নেবে না; দ্বিতীয় transition হতে হবে ৯৪তম দিন বা তার পরে। দুটো আলাদা rule দিলে S3 মেনে নেয়, কিন্তু তখন বাকি minimum duration-এর চার্জ দিতে হয়।
• প্রতিটা transition একটা পয়সার request (Standard-IA-তে প্রতি ১,০০০-এ $0.01 থেকে Deep Archive-এ প্রতি ১,০০০-এ $0.05), আর expiration বিনামূল্যে।

#অসমাপ্ত multipart upload

বড় upload পাঠানো হয় টুকরো টুকরো করে (multipart upload, লেসন ১০.১২)। Client মাঝপথে বন্ধ হয়ে গেলে, আর upload-টা শেষ বা বাতিল কোনোটাই না করলে, যে part-গুলো পাঠানো হয়েছিল সেগুলো জমা থাকে আর তার টাকাও কাটে, অথচ সেগুলো কোনো object না, সাধারণ listing-এ দেখাও যায় না। বড় upload আসে এমন bucket-এ চুপচাপ টেরাবাইটের পর টেরাবাইট জমে যেতে পারে। সমাধান একটা AbortIncompleteMultipartUpload rule, সাধারণত ৭ দিন পর। Expiration rule এগুলো সরায় না।

#Versioned bucket

Versioning চালু থাকলে (লেসন ১০.৪) object “মুছলে” শুধু একটা delete marker বসে, আর প্রতিবার overwrite করলে পুরোনো version রয়ে যায়। Noncurrent version-এর rule না থাকলে bucket চিরকাল সব version রেখে দেয়, আর bill শুধু বাড়তেই থাকে। Versioned bucket-এর একটা সাধারণ rule:

• noncurrent version N দিন পর সস্তা class-এ সরাও;
• M দিন পর noncurrent version expire করো (ধরো শেষ ৩টা রেখে);
• expired object delete marker সরিয়ে দাও।

#পরীক্ষার দুটো পরিস্থিতি

1. Profile-এর ছবি আর thumbnail

   EC2-এ চলা একটা application, S3-এ upload হওয়া profile ছবির thumbnail বানায়। Thumbnail আবার বানানো যায়, আর রাখতে হয় মাত্র ৬০ দিন। মূল ছবি ৬০ দিন পর্যন্ত সাথে সাথে পেতে হবে; তারপর user ৬ ঘণ্টা পর্যন্ত অপেক্ষা করতে পারে।

   Design: মূল ছবি Standard-এ রাখো, সাথে একটা lifecycle rule যা ৬০ দিন পর এগুলোকে Glacier Flexible Retrieval-এ সরায় (Standard restore-এ ৩–৫ ঘণ্টা, ৬ ঘণ্টার সীমার ভেতরে)। Thumbnail রাখো One Zone-IA-তে (আবার বানানো যায়, তাই একটা AZ যথেষ্ট), সাথে একটা rule যা ৬০ দিন পর এগুলো expire করে। দুটো prefix (source/ আর thumbs/) বা tag ব্যবহার করো, যাতে প্রতিটা rule শুধু নিজের object-এ লাগে।

2. মুছে ফেলা object ফেরত: ৩০ দিন সাথে সাথে, এক বছর ৪৮ ঘণ্টার মধ্যে

   একটা প্রতিষ্ঠানের নিয়ম: মুছে ফেলা S3 object ৩০ দিন পর্যন্ত সাথে সাথে ফেরত আনা যেতে হবে, আর ৩৬৫ দিন পর্যন্ত ৪৮ ঘণ্টার মধ্যে।

   Design: versioning চালু করো, তাহলে মুছলে শুধু একটা delete marker বসে আর object-টা noncurrent version হয়ে থেকে যায়। প্রথম ৩০ দিন noncurrent version এমন জায়গায় রাখো যেখান থেকে সাথে সাথে পড়া যায় (Standard, বা Standard-IA), তারপর ৩০ দিন পর noncurrent version-গুলো Glacier Deep Archive-এ সরাও (Bulk restore ৪৮ ঘণ্টার মধ্যে), আর ৩৬৫ দিন পর noncurrent version expire করো।

#Storage Class Analysis

Standard-IA-তে সরানোর আগে rule কত দিন অপেক্ষা করবে? আন্দাজে বলা ঝুঁকির: খুব আগে সরালে retrieval fee সঞ্চয় খেয়ে ফেলে, খুব দেরিতে সরালে storage-এ বেশি টাকা যায়। S3 Analytics-এর Storage Class Analysis তোমার হয়ে এটা মেপে দেয়।

• পুরো bucket-এ চালু করা যায়, অথবা prefix আর/অথবা tag দিয়ে একদল object-এ (bucket-প্রতি ১,০০০টা filter পর্যন্ত)।
• এটা দেখে Standard-এ থাকা ১২৮ KB-এর বড় object-গুলো, বয়স অনুযায়ী ভাগ করে (০–১৪ দিন, ১৫–২৯, ৩০–৪৪ … ৭৩০+), আর মাপে প্রতিটা বয়সের দল থেকে কতটা data পড়া হলো।
• প্রথম data দেখা যায় ২৪ থেকে ৪৮ ঘণ্টা পর, কিন্তু পরামর্শ দেওয়ার আগে ৩০ দিন বা তার বেশি নজর রাখতে হয়, আর পরামর্শটা প্রতিদিন হালনাগাদ হয়।
• পরামর্শ দেয় শুধু Standard → Standard-IA-র জন্য। One Zone-IA, Glacier class বা Intelligent-Tiering নিয়ে কিছু বলে না।
• প্রতিদিনের একটা CSV report একটা bucket-এ (একই Region, যেকোনো account) export করা যায়, spreadsheet বা Amazon Quick-এ খোলা যায়।
• খরচ: মাসে প্রতি ১০ লাখ object নজরদারিতে $0.10।

Lifecycle rule লেখা বা ঠিকঠাক করার প্রথম ধাপ হিসেবে এটা ব্যবহার করো। পুরো প্রতিষ্ঠান জুড়ে storage আর activity দেখতে চাইলে বরং S3 Storage Lens (লেসন ১০.৭)।

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

• গরম data-য় IA। একটা দল “টাকা বাঁচাতে” একটা dashboard-এর data Standard-IA-তে সরাল; dashboard প্রতি ঘণ্টায় সবটা পড়ে, আর retrieval fee-তে bill তিনগুণ হয়ে গেল। IA লাভজনক কেবল মাসে GB-প্রতি একবারের কম পড়া হলে।
• এখনই লাগবে এমন data Glacier-এ। Glacier Flexible Retrieval-এ archive করা log দরকার পড়ল রাত ২টার এক outage-এ: GET দিল 403, আর restore-এ লাগবে কয়েক ঘণ্টা। শুধু তাই archive করো যার জন্য অপেক্ষা চলে, নইলে Glacier Instant Retrieval নাও।
• আগেভাগে মুছে ফেলা। একটা test pipeline অস্থায়ী file Glacier Instant Retrieval-এ লেখে আর প্রতিদিন মুছে দেয়; প্রতিটা file-এর bill হয় ৯০ দিনের।
• লাখ লাখ খুব ছোট file। ছোট object IA আর Glacier-এর ছাড় পায় না (১২৮ KB minimum, ৪০ KB বাড়তি, transition-এ object-প্রতি fee), আর Intelligent-Tiering-এ কখনো নড়েও না।
• ভুলে যাওয়া multipart part। ব্যর্থ upload-এর টেরাবাইট-ভর্তি অদৃশ্য part; সমাধান একটাই lifecycle rule।
• চিরকাল সব version। Versioning চালু, noncurrent-এর কোনো rule নেই: প্রতিটা overwrite রয়ে যায় আর টাকা কাটে। Storage Lens dashboard-এ noncurrent byte মাসের পর মাস বাড়তেই থাকে।
• ভুল prefix expire করা rule। Versioning ছাড়া bucket-এ lifecycle expiration স্থায়ী। একটা rule আগে ছোট একটা prefix-এ পরখ করো, আর গুরুত্বপূর্ণ data-র জন্য নিরাপত্তা জাল হিসেবে versioning সাথে noncurrent expiration রাখো।
• একমাত্র কপি One Zone-এ। ২০% বাঁচাতে একটা দল গ্রাহকদের মূল কাগজপত্র One Zone-IA-তে রাখল; একটা AZ-এর সমস্যায় সেগুলো পাওয়া গেল না, আর বিপর্যয় হলে চিরতরে হারাত।

#System design-এ storage class

• দামের তালিকা না, access pattern দিয়ে শুরু করো। প্রতিটা data set-এর জন্য লিখে ফেলো: প্রথম সপ্তাহে, প্রথম মাসে, প্রথম বছরে কত ঘনঘন পড়া হয়, কত দ্রুত ফেরত লাগে, আবার বানানো যায় কি না, আর আইন কতদিন রাখতে বলে। Class আর lifecycle rule এই উত্তরগুলো থেকেই বেরিয়ে আসে।
• ৭ বছর রাখতে হয় এমন হাসপাতালের scan: ৩০ দিন Standard (ডাক্তাররা পড়েন), ৩৬৫তম দিন পর্যন্ত Standard-IA (ফলো-আপ ভিজিট), তারপর Glacier Deep Archive (আইনি সংরক্ষণ, ১২ ঘণ্টায় restore চলে), আর ২,৫৫৫ দিন পর expire। ফলো-আপ কখন হবে হাসপাতাল আগে থেকে বলতে না পারলে, Deep Archive Access tier চালু করা Intelligent-Tiering একই কাজ নিজে থেকে করে। Record-এ কেউ হাত দিতে পারবে না এমন নিশ্চয়তা লাগলে Object Lock যোগ করো (লেসন ১০.৯)।
• একটা খবরের site-এর ছবির archive: Standard → Standard-IA → Glacier Instant Retrieval, কারণ কোনো খবর লিঙ্ক করলে ১০ বছরের পুরোনো ছবিও সাথে সাথে খুলতে হবে। Thumbnail One Zone-IA-তে, কারণ আবার বানানো যায়।
• Backup আর disaster recovery: মূল backup Standard-IA-তে, পুরোনো backup Glacier Flexible বা Deep Archive-এ। অন্য Region-এর replica (লেসন ১০.৪) সরাসরি সস্তা class-এ যেতে পারে, প্রায়ই One Zone-IA বা Glacier-এ, কারণ মূল কপি তো source-এই। Backup কৌশল আর RPO/RTO নিয়ে বিস্তারিত অধ্যায় ২৩-এ।
• Data lake আর অনেকের shared bucket: অনেক দল অনিশ্চিতভাবে পড়লে default storage class হিসেবে Intelligent-Tiering, আর Athena (লেসন ১৭.১) সেখানেই query চালায়।
• ML আর analytics-এর scratch জায়গা: compute-এর সাথে একই AZ-এ Express One Zone, Standard থেকে ভরা, আর job শেষ হলে lifecycle rule দিয়ে expire।
• প্রতিটা bucket-এ: একটা AbortIncompleteMultipartUpload rule, আর যেখানে versioning চালু সেখানে noncurrent version-এর rule।

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

নির্দিষ্ট class দিয়ে upload করো, তারপর যাচাই করো:

aws s3 cp scan-0001.dcm s3://hospital-scans-example/2026/ --storage-class STANDARD_IA
aws s3api head-object --bucket hospital-scans-example --key 2026/scan-0001.dcm \
  --query StorageClass

একটা logs prefix, একটা versioned prefix আর multipart পরিষ্কারের জন্য lifecycle configuration, lifecycle.json নামে রাখো:

{
  "Rules": [
    {
      "ID": "logs-tiering",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 }
    },
    {
      "ID": "old-versions",
      "Status": "Enabled",
      "Filter": { "Prefix": "contracts/" },
      "NoncurrentVersionTransitions": [
        { "NoncurrentDays": 30, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "NoncurrentVersionExpiration": { "NoncurrentDays": 365, "NewerNoncurrentVersions": 3 },
      "Expiration": { "ExpiredObjectDeleteMarker": true }
    },
    {
      "ID": "abort-mpu",
      "Status": "Enabled",
      "Filter": {},
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration --bucket hospital-scans-example \
  --lifecycle-configuration file://lifecycle.json
aws s3api get-bucket-lifecycle-configuration --bucket hospital-scans-example

# ভুলে যাওয়া multipart upload খুঁজে বের করো
aws s3api list-multipart-uploads --bucket hospital-scans-example

Archive করা একটা object restore করো আর অবস্থা দেখো:

aws s3api restore-object --bucket hospital-scans-example --key logs/2025-01-15.gz \
  --restore-request '{"Days":2,"GlacierJobParameters":{"Tier":"Bulk"}}'
aws s3api head-object --bucket hospital-scans-example --key logs/2025-01-15.gz \
  --query Restore      # কপি তৈরি না হওয়া পর্যন্ত "ongoing-request=\"true\""

Intelligent-Tiering-এর archive tier চালু করো, আর একটা prefix-এ Storage Class Analysis:

aws s3api put-bucket-intelligent-tiering-configuration --bucket shop-media-example \
  --id archive-old-invoices --intelligent-tiering-configuration '{
    "Id": "archive-old-invoices", "Status": "Enabled",
    "Filter": { "Prefix": "invoices/" },
    "Tierings": [ { "Days": 180, "AccessTier": "ARCHIVE_ACCESS" },
                  { "Days": 365, "AccessTier": "DEEP_ARCHIVE_ACCESS" } ] }'

aws s3api put-bucket-analytics-configuration --bucket shop-media-example \
  --id photos-analysis --analytics-configuration '{
    "Id": "photos-analysis", "Filter": { "Prefix": "photos/" },
    "StorageClassAnalysis": { "DataExport": { "OutputSchemaVersion": "V_1",
      "Destination": { "S3BucketDestination": { "Format": "CSV",
        "Bucket": "arn:aws:s3:::analytics-reports-example", "Prefix": "sca/" } } } } }'

একটা AZ-এ Express One Zone-এর directory bucket বানাও:

aws s3api create-bucket --bucket ml-train--use1-az4--x-s3 --region us-east-1 \
  --create-bucket-configuration \
  'Location={Type=AvailabilityZone,Name=use1-az4},Bucket={DataRedundancy=SingleAvailabilityZone,Type=Directory}'

#সারসংক্ষেপ

মূল কথাগুলো

• Durability (data টিকবে কি?) প্রতিটা class-এ 11 nines; availability (এখন পাওয়া যাবে কি?) আলাদা: Standard 99.99%, IA class আর Glacier Instant 99.9%, One Zone-IA 99.5%, Express One Zone 99.95%।
• One Zone-IA আর Express One Zone থাকে একটা AZ-এ: design durability একই, কিন্তু AZ ধ্বংস হলে data শেষ। শুধু আবার বানানো যায় এমন data-র জন্য।
• Standard: গরম data, কোনো বাড়তি fee নেই। Standard-IA / One Zone-IA: মাসে একবার বা তারও কম পড়া, ms access, retrieval fee, ৩০ দিন minimum, ১২৮ KB minimum size।
• Glacier Instant Retrieval: তিন মাসে একবার পড়া, ms access, ৯০ দিন। Glacier Flexible Retrieval: আগে restore, Expedited ১–৫ মিনিট, Standard ৩–৫ ঘণ্টা, Bulk ৫–১২ ঘণ্টা (ফ্রি), ৯০ দিন। Deep Archive: সবচেয়ে সস্তা (মাসে TB-প্রতি ~$1), Standard ≤১২ ঘণ্টা, Bulk ≤৪৮ ঘণ্টা, Expedited নেই, ১৮০ দিন।
• Restore N দিনের জন্য একটা অস্থায়ী কপি বানায় (দাম Standard-এর হারে); class বদলায় না। Provisioned capacity Expedited retrieval নিশ্চিত করে।
• Intelligent-Tiering: অজানা বা বদলানো pattern, retrieval fee নেই, সামান্য monitoring fee, ৩০ আর ৯০ দিনে tier বদল, সাথে ঐচ্ছিক archive tier; ১২৮ KB-এর ছোট object Frequent-এই থাকে। নিয়মভিত্তিক, AI না।
• Express One Zone: একটা AZ-এ directory bucket, এক অঙ্কের ms, ১০ গুণ দ্রুত, request সস্তা কিন্তু storage দামি; ML training আর HPC।
• Lifecycle rule: transition, expiration, noncurrent version, expired delete marker, অসমাপ্ত multipart upload বাতিল; prefix, tag, size দিয়ে filter; শুধু নিচের দিকে (ঝরনা)। জুলাই ২০২৬ থেকে IA-তে transition ০ দিন থেকেই; default-এ ১২৮ KB-এর ছোট object transition হয় না।
• Storage Class Analysis: ৩০+ দিন নজর রেখে Standard → Standard-IA-র পরামর্শ, প্রতিদিন CSV export।

নিজেকে যাচাই করো: Storage class আর lifecycle৩১টি প্রশ্ন