Versioning আর Replication

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

• S3 Versioning কীসের হাত থেকে বাঁচায়, একটা bucket-এর versioning-এর তিনটা অবস্থা কী কী, আর কেন এর মধ্যে “disable” বলে কিছু নেই, সেটা বোঝাতে।
• Enabled আর suspended bucket-এ PUT, GET আর DELETE ঠিক কী করে, আগেই বলে দিতে: version ID, null version, delete marker, 404 বনাম 405, আর চিরতরে delete।
• মুছে যাওয়া বা overwrite হয়ে যাওয়া object ফিরিয়ে আনতে, আর version জমিয়ে রাখার খরচ আন্দাজ করতে।
• Versioning-এর ওপরে MFA Delete কী যোগ করে, কে এটা চালু করতে পারে, আর কখন Object Lock-ই ভালো উত্তর, সেটা বলতে।
• Cross-Region আর Same-Region Replication সাজাতে: শর্তগুলো, IAM role, অন্য account-এ কপি, আর একটা rule কী filter করতে আর কী বদলাতে পারে।
• ঠিক কোনটা replicate হয় আর কোনটা হয় না (আগের object, delete marker, version delete, encrypt করা আর archive করা object, replica), সেটা নিখুঁতভাবে বলতে, আর প্রতিটা ফাঁক সঠিক feature দিয়ে বন্ধ করতে: Batch Replication, delete marker replication, KMS setting, আরেকটা rule বা RTC।

#Object-এর পুরনো কপি কেন রাখব?

#Overwrite আর delete মুহূর্তেই হয়, ফেরত আসে না

লেসন ১০.১-এ দেখেছ, S3-এ একটা object চেনা যায় তার key দিয়ে। একই key দিয়ে নতুন file upload করলে পুরনোটা বদলে যায়। Key delete করলে সেটা উধাও। Versioning ছাড়া bucket-এ দুটো কাজই হয় কয়েক মিলিসেকেন্ডে, আর কোনো recycle bin নেই।

বাস্তবে এটা বড় সমস্যা, কারণ বেশিরভাগ data হারায় disk নষ্ট হয়ে না (S3 তো এগারোটা নয়-এর durability-র জন্য বানানো), হারায় কোনো মানুষ বা program ভুল কাজ করে বলে:

• একটা deployment script আসল catalog.json-এর ওপর একটা ফাঁকা file বসিয়ে দিল;
• নতুন এক intern ভুল prefix-এ aws s3 rm --recursive চালিয়ে দিল;
• ফাঁস হওয়া access key হাতে পেয়ে ransomware সব file এনক্রিপ্ট করা আবর্জনা দিয়ে overwrite করল;
• ছবি ছোট করার একটা program-এর bug আসল ছবির ওপর নষ্ট thumbnail লিখে দিল।

S3 Versioning এর সমাধান করে প্রতিটা object-এর প্রতিটা version রেখে দিয়ে। Overwrite করলে ওপরে একটা নতুন version বসে; delete করলে ওপরে একটা marker বসে। পুরনো data নিচে থেকে যায়, যতক্ষণ না তুমি ইচ্ছে করে সরাও।

#Versioning হলো bucket-এর একটা setting

Versioning চালু হয় পুরো bucket-এর জন্য, আলাদা কোনো object বা prefix-এর জন্য না। একবার চালু হলে প্রতিটা key-তেই খাটে। Slides একে best practice বলে, আর যে bucket-এ এমন data আছে যা সহজে আবার বানানো যায় না (customer-এর upload, document, configuration, backup), সেখানে কথাটা একদম সত্যি।

#Version কীভাবে কাজ করে

#Bucket-এর তিনটা অবস্থা

একটা bucket সবসময় এই তিন অবস্থার যেকোনো একটায় থাকে:

Notes মূল নিয়মটার ওপর জোর দিয়েছে: একবার versioning চালু করলে আর কখনো পুরোপুরি বন্ধ করা যায় না। Bucket শুধু enabled আর suspended-এর মধ্যে আসা-যাওয়া করতে পারে। Unversioned-এ ফেরার কোনো রাস্তা নেই; সত্যিই দরকার হলে নতুন একটা bucket বানিয়ে current object-গুলো সেখানে copy করতে হয়।

#প্রতিটা overwrite মানে নতুন একটা version

Versioning চালু থাকলে:

1. কোনো key-তে প্রতিটা PUT, POST বা copy একটা নতুন version বানায়, যার নিজের version ID থাকে; ID-টা ফেরত আসে x-amz-version-id response header-এ।
2. সবচেয়ে নতুনটা হলো current version। বাকি পুরনোগুলো noncurrent version।
3. সাধারণ GET (version ID ছাড়া) current version দেয়। GET … ?versionId=… দিলে জমা থাকা যেকোনো version পাওয়া যায়।
4. কোনো version জায়গায় বসে বদলানো হয় না। এমনকি “আগের অবস্থায় ফেরা”-ও হয় পুরনো version-কে ওপরে copy করে, তাতে আরও একটা version তৈরি হয়।

Slides-এ version আঁকা আছে ১, ২, ৩ করে। ওটা শুধু বোঝানোর ছবি। আসল version ID হলো S3-এর বানানো, সর্বোচ্চ ১,০২৪ byte-এর একটা অস্বচ্ছ string, যেমন 3HL4kqtJlcpXroDTDmJ.rmSpXd3dIbrHY। তুমি এটা বাছতে পারো না, পড়ে ক্রমও বুঝতে পারো না; S3 নতুন থেকে পুরনো ক্রমে version-গুলো list করে।

#Versioning-এর আগের object-এর version ID হয় null

Versioning চালু করার সময় bucket-এ আগে থেকেই object থাকলে সেগুলো নতুন করে লেখা হয় না। ওদের version ID থাকে null। এদের কোনোটা পরে overwrite করলে পুরনো data noncurrent null version হিসেবে থেকে যায়, আর নতুন upload পায় আসল ID। Slides-ও একই কথা বলে: versioning চালুর আগে যে file version করা ছিল না, তার version null।

#Versioning-এর খরচ

S3 প্রতিটা version-কে পুরো একটা object হিসেবে বিল করে। শুধু পার্থক্যটুকু জমা হয় না। ৫ MB-এর একটা report যদি ৩০ দিন ধরে প্রতি ঘণ্টায় overwrite হয়, তাহলে ৭২০টা version জমে, প্রায় ৩.৫ GB, আর সবটার দাম লাগে storage class অনুযায়ী। সাথে PUT request-এর খরচ যোগ করো; ব্যস্ত একটা key-তে versioning-এর খরচ current data-র চেয়ে অনেক বেশি হয়ে যেতে পারে।

সমাধান versioning এড়ানো না, বরং noncurrent version-এর জন্য lifecycle rule দিয়ে সামলানো (লেসন ১০.৫): যেমন ৩০ দিন পর noncurrent version সস্তা class-এ সরাও আর ৯০ দিন পর মুছে দাও, অথবা শুধু শেষ পাঁচটা রাখো। নিচে কোনো version নেই এমন expired object delete marker-ও lifecycle পরিষ্কার করতে পারে।

প্রতিটা কাজ নিজে করে দেখো। নির্দিষ্ট version-এর button-গুলোর জন্য স্তূপের একটা সারিতে click করে version বেছে নাও।

#Versioned bucket-এ delete করা

#সাধারণ delete একটা delete marker বসায়

Version ID ছাড়া DELETE (console-এর Delete button, aws s3 rm আর বেশিরভাগ SDK call যা পাঠায়) versioned bucket-এ আসলে কিছুই মোছে না। S3 একটা delete marker বানায়: object-এর key আর নিজের version ID সহ একটা জায়গা-ধরা চিহ্ন, যার ভেতরে কোনো data নেই। Marker-টাই current version হয়ে যায়। এরপর থেকে:

• সাধারণ GET বা HEAD দিলে আসে 404 Not Found, সাথে header x-amz-delete-marker: true;
• সাধারণ listing-এ (ListObjectsV2, aws s3 ls) key-টা দেখা যায় না;
• নিচের version-গুলো অক্ষত, version ID দিয়ে পড়াও যায়, আর বিলও আসতে থাকে।

Delete marker-এর খরচ প্রায় শূন্য: এর size হলো key name-এর দৈর্ঘ্য, থাকে S3 Standard-এ। যে key-এর current version আগেই marker, সেটা আবার delete করলে S3 শুধু আরেকটা marker বসায়।

#Marker মুছে ফিরিয়ে আনো

Undelete করতে marker-টাকেই সরাও: version-গুলো list করো (aws s3api list-object-versions, বা console-এ Show versions), তারপর marker-টা তার version ID দিয়ে delete করো। নিচের version আবার current হয়ে যায়, কোনো কপি বা নতুন version ছাড়াই। Notes সহজ করে বলেছে: ফিরিয়ে আনতে delete marker-টাকেই delete করো।

Overwrite হয়ে যাওয়া object-এ সরানোর মতো কোনো marker নেই। সেখানে ভালো version-টা ওপরে copy করো (source-এ ?versionId= দিয়ে copy-object), অথবা খারাপ নতুন version-গুলো ID ধরে মুছে দাও।

#Version ID দিয়ে delete মানে চিরতরে

Version ID সহ DELETE ঠিক ওই version-টা চিরতরে মুছে ফেলে। কোনো marker বসে না, ফেরানোর কোনো উপায়ও নেই। Versioned bucket-এ সত্যিকারের জায়গা খালি করার এটাই একমাত্র পথ (noncurrent version-এর lifecycle expiration নিজে থেকে এই কাজটাই করে)।

দুটো status code সহজেই গুলিয়ে যায়:

চিরতরে delete যেহেতু ধ্বংসাত্মক, তাই এর permission আলাদা: s3:DeleteObjectVersion, যা s3:DeleteObject থেকে ভিন্ন। Application-কে শুধু s3:DeleteObject দিলে সে object লুকাতে পারবে, কিন্তু ইতিহাস কখনো নষ্ট করতে পারবে না।

#Versioning suspend করা

Suspend করলে নতুন version জমা বন্ধ হয়, কিন্তু আগে থেকে থাকা প্রতিটা version রয়ে যায় (slides-ও এটার ওপর জোর দিয়েছে)। Suspended bucket-এ:

• PUT object রাখে version ID null দিয়ে। ওই key-তে আগে থেকেই null version থাকলে সেটা বদলে যায়, তার data হারায়। আসল ID-ওয়ালা version-গুলো অক্ষত।
• ID ছাড়া DELETE null version-টা (থাকলে) মুছে দেয়, আর null version ID-ওয়ালা একটা delete marker বসায়।
• GET আগের মতোই current version দেয়, তার ID যা-ই হোক, আর যেকোনো পুরনো version ID দিয়ে এখনো পড়া যায়।

মানে suspended bucket-এ প্রতিটা key আচরণ করে জমে থাকা একটা ইতিহাসের ওপর বসানো unversioned object-এর মতো। Suspend করলে আগের version-এর খরচ এক পয়সাও কমে না; কমে শুধু ওগুলো মুছলে (হাতে বা lifecycle দিয়ে)।

যে bucket কোনো replication rule-এর source, তার versioning suspend করা যায় না: replication configuration না সরানো পর্যন্ত S3 error দেয়। আর destination-এ suspend করলে replication ব্যর্থ হতে থাকে।

#Version পাহারা দেওয়া: MFA Delete, আর তার পরের ধাপ

Versioning রক্ষা করে সাধারণ delete আর overwrite-এর ভুল থেকে। কিন্তু যে identity-র version মোছার অনুমতি আছে, তাকে এটা থামায় না: s3:DeleteObjectVersion থাকা কোনো মানুষ, বা তার key হাতে পাওয়া হামলাকারী, একটা একটা করে সব version মুছে ফেলতে পারে। ঠিক এই কারণেই notes-এর exam trick versioning-এর সাথে MFA Delete-কে জুড়ে দিয়েছে।

একটু আগাম ঝলক (লেসন ২.৩-এ পরিচয় হয়েছিল; পুরোটা আছে লেসন ১০.৯-এ):

• MFA Delete চালু থাকলে দুটো কাজে request-এর সাথে root user-এর MFA device-এর code লাগে: কোনো object version চিরতরে মোছা আর versioning-এর অবস্থা বদলানো (suspend করা)।
• Versioning চালু করা, version list করা আর সাধারণ delete (marker বসানো)-এ MFA লাগে না।
• এটা চালু বা বন্ধ করতে পারে শুধু bucket-মালিক account-এর root user, তাও শুধু CLI, SDK বা API দিয়ে, console-এ কখনো না। Versioning enabled থাকতে হবে।

#Replication: আরেকটা bucket-এ নিজে থেকে কপি

#CRR আর SRR

S3 Replication একটা source bucket থেকে এক বা একাধিক destination bucket-এ object copy করে, লেখা হওয়ার পরে, নিজে থেকে আর অ্যাসিঙ্ক্রোনাসভাবে। এর দুই রকম, feature একটাই, শুধু destination-এর Region আলাদা:

• Cross-Region Replication (CRR): destination অন্য Region-এ।
• Same-Region Replication (SRR): destination একই Region-এ।

Bucket-গুলো একই বা ভিন্ন AWS account-এর হতে পারে।

#কী কী লাগবে

Slides আর notes মূল জিনিসগুলো বলেছে; এখানে পুরো তালিকা:

1. Source আর প্রতিটা destination-এ versioning চালু। Replication কাজ করে version ধরে। (আর replication সাজানো থাকা অবস্থায় source-এর versioning suspend করা যায় না।)
2. একটা IAM role, যেটা S3 assume করে (এর trust policy-তে service s3.amazonaws.com-এর নাম থাকে)। এর অনুমতি লাগে source থেকে version পড়ার (s3:GetReplicationConfiguration, s3:ListBucket, s3:GetObjectVersionForReplication, s3:GetObjectVersionAcl, s3:GetObjectVersionTagging) আর destination-এ লেখার (s3:ReplicateObject, s3:ReplicateDelete, s3:ReplicateTags)। যে rule বানায়, তার ওই role-এর জন্য iam:PassRole লাগে (role দেখেছ লেসন ২.৪-এ)।
3. Source bucket-এ একটা replication configuration: role, সাথে এক বা একাধিক rule।
4. শুধু cross-account হলে: destination account একটা bucket policy যোগ করে, যা source account-এর role-কে সেখানে replicate করার অনুমতি দেয়। চাইলে rule replica-র মালিক বদলে destination account করে দিতে পারে (Object Ownership যদি bucket owner enforced হয়, লেসন ১০.২, তাহলে destination এমনিতেই replica-র মালিক)। Destination কোনো Requester Pays bucket হতে পারবে না।
5. Source-এ Object Lock থাকলে destination-এও থাকতে হবে।

প্রতিটা rule বেছে নেয়:

• পরিধি: পুরো bucket, একটা prefix, কিছু tag, বা prefix আর tag একসাথে;
• একটা destination bucket (কয়েকটা rule কয়েকটা destination-এ যেতে পারে, তাই এক source অনেক দিকে ছড়াতে পারে);
• চাইলে replica-র জন্য আলাদা storage class (যেমন সস্তা backup কপির জন্য Standard-IA বা Glacier Deep Archive);
• একটা priority, rule-গুলো একটার ঘাড়ে আরেকটা পড়লে কাজে লাগে;
• নিচে আলোচনা করা option-গুলো: delete marker replication, KMS-encrypted object, replica modification sync, Replication Time Control।

#Replica দেখতে কেমন

Replica-র key, version ID, metadata, tag, ACL আর Object Lock retention source version-এর মতোই। প্রতিটা object head-object-এ একটা replication status দেখায়: source-এ PENDING বা COMPLETED (অথবা FAILED), আর কপিতে REPLICA। বেশিরভাগ object কয়েক সেকেন্ড থেকে কয়েক মিনিটে replicate হয়; বড় object-এ বেশি সময় লাগতে পারে। Destination-এর lifecycle rule বয়স গোনে আসল তৈরির সময় থেকে, replica পৌঁছানোর সময় থেকে না।

#শুধু নতুন object: বাকিগুলোর জন্য Batch Replication

Notes আর slides একমত: replication চালু করার পর শুধু নতুন object replicate হয়। Bucket-এ আগে থেকে থাকা object যেখানে ছিল সেখানেই থাকে।

ওগুলো copy করতে S3 Batch Replication ব্যবহার করো: এটা একটা S3 Batch Operations job (লেসন ১০.৭), যা তোমার বিদ্যমান rule ধরেই object replicate করে। নতুন rule save করার সাথে সাথেই console এটা বানানোর প্রস্তাব দেয়। Batch Replication copy করে:

• rule-এর আগে লেখা আগের object;
• যেসব object-এর replication ব্যর্থ হয়েছিল (আগে কারণটা ঠিক করো, যেমন বাদ পড়া KMS permission);
• যেগুলো আগেই অন্য destination-এ replicate হয়েছে, যখন তুমি নতুন destination যোগ করো বা বদলাও;
• যেসব object নিজেই অন্য rule-এর বানানো replica।

Notes-এর exam trick: পুরনো data সিঙ্ক করতে সবসময় S3 Batch Replication খুঁজবে। Batch Operations আর একসাথে বিপুল data সরানোর অন্য উপায়গুলোর তুলনা আছে লেসন ১০.১২-এও।

#Delete: destination-এ কী পৌঁছায়

Notes বলে delete marker replicate হয় না। এখনকার rule-এ এটাই default, কিন্তু এটা একটা option, আর slides দুটো অবস্থাই দেখায়:

• Delete marker (সাধারণ delete): replicate হয় না, যদি না rule-এ delete marker replication চালু করো। Tag-ভিত্তিক rule-এ এটা চালানো যায় না। Filter element ছাড়া পুরনো “V1” configuration user-এর delete marker replicate করে।
• Version ID সহ delete (চিরতরে delete): setting যা-ই হোক, কখনো replicate হয় না। Source-এ ক্ষতিকর বা ভুল করে চিরতরে delete কপিতে পৌঁছাতে পারে না।
• Lifecycle-এর কাজ: কখনো replicate হয় না। প্রতিটা bucket-এ lifecycle আলাদা করে সাজাও।

Delete marker replication বাছো উদ্দেশ্য দেখে। Active-active জোড়ায়, যেখানে user দুই Region থেকেই পড়ে, এটা চালু রাখো যাতে মোছা object সব জায়গা থেকেই উধাও হয়। Backup কপির বেলায় বন্ধ রাখো, যাতে source-এর ভুলের delete কপিতে না ছড়ায়।

#শিকল চলে না

Replication এক ধাপ থেকে পরের ধাপে গড়ায় না। Bucket A যদি B-তে replicate করে, আর bucket B করে C-তে, তাহলে A-তে তৈরি object B-তে পৌঁছায় কিন্তু C-তে কখনো না, কারণ default-এ S3 এমন object replicate করে না যেটা নিজেই একটা replica।

Notes-এর exam trick সমাধানও বলে দেয়: A-এর data B আর C দুই জায়গাতেই লাগলে A-তেই দুটো rule বানাও, A → B আর A → C। আরও দুটো খুঁটিনাটি:

• B → C rule নষ্ট না: সরাসরি B-তে upload হওয়া object ঠিকই C-তে replicate হয়।
• B-তে আগে থেকে বসে থাকা replica copy করতে Batch Replication replica-ও replicate করতে পারে।

#Encrypt করা object

KMS key Region-ভিত্তিক, তাই source Region-এর key দিয়ে অন্য Region-এর replica encrypt করা যায় না। Cross-account SSE-KMS replication-এ লাগে একটা customer managed key, যার key policy source account-কে ব্যবহারের অনুমতি দেয়; AWS managed key ভাগ করা যায় না। প্রতিটা replicated SSE-KMS object দুই দিকেই KMS request খরচ করে, তাই KMS request quota-র দিকে নজর রাখো: সেকেন্ডে ১,০০০ object replicate করলে সেকেন্ডে প্রায় ২,০০০ KMS request লাগে।

Destination bucket-এ default encryption থাকলে আর source object unencrypted হলে replica destination-এর default দিয়ে encrypt হয়, আর তার ETag source-এর ETag-এর সাথে মেলে না।

#আর কী কী replicate হয় না

• Glacier Flexible Retrieval, Glacier Deep Archive আর Intelligent-Tiering-এর archive tier-এর object। আগে replicate, পরে archive (লেসন ১০.৫)।
• Bucket-স্তরের setting: bucket policy, lifecycle, notification, CORS। প্রতিটা bucket নিজেরটা রাখে।
• যে object bucket-মালিক পড়তে পারে না (অন্য account-এর মালিকানার object, ACL permission ছাড়া; এখন ACL default-এ বন্ধ বলে বিরল)।
• Tag-ভিত্তিক rule-এ upload-এর পরে tag দেওয়া object (Batch Replication এগুলো copy করে)।

যেকোনো মিশ্রণ checker দিয়ে যাচাই করো:

#Replication Time Control

সাধারণ replication-এ সময়ের কোনো নিশ্চয়তা নেই: বেশিরভাগ object কয়েক সেকেন্ডে পৌঁছায়, কিন্তু জমে থাকা কাজ বা বড় object-এ ঘণ্টাও লাগতে পারে। S3 Replication Time Control (RTC) হলো rule-এর একটা option, যেটা:

• এমনভাবে বানানো যে ৯৯.৯৯% নতুন object ১৫ মিনিটের মধ্যে replicate হয়, বেশিরভাগ কয়েক সেকেন্ডে, আর পেছনে আছে একটা SLA (কোনো billing মাসে ৯৯.৯%-এর কম object ১৫ মিনিটে replicate হলে service credit);
• CloudWatch-এ replication metric চালু করে: কত byte আর কয়টা operation বাকি, সর্বোচ্চ কত দেরি, কয়টা ব্যর্থ (RTC ছাড়াও metric আলাদা করে চালু করা যায়);
• কোনো object ১৫ মিনিটের সীমা পার করলে, আর দেরিতে replicate হলে, S3 event notification পাঠায় SNS, SQS বা Lambda-তে।

RTC-র জন্য প্রতি GB বাড়তি টাকা লাগে। তুমি S3-এর request-rate নির্দেশিকা বা replication-এর default ১ Gbps transfer quota ছাড়িয়ে গেলে ওই সময়টুকুতে SLA খাটে না। পরীক্ষায় সংকেত হলো কপির ওপর কোনো সময়সীমা: “১৫ মিনিটের মধ্যে replicate”, “অনুমানযোগ্য replication সময়”, “compliance-এর জন্য কপির নিশ্চিত RPO চাই”।

#দুই দিকে replication আর replica modification sync

দুই দিকেই rule বসাতে পারো (A → B আর B → A), active-active জোড়ার জন্য। যেকোনো bucket-এ লেখা নতুন object অন্যটায় হাজির হয়, আর S3 replica-কে আবার ফেরত পাঠায় না। Default-এ replica-র metadata-য় করা বদল (tag, ACL, Object Lock setting) replica-তেই থেকে যায়। Replica modification sync ওই metadata বদল source-এ ফেরত replicate করে, যাতে দুই দিক হুবহু এক থাকে। S3 Multi-Region Access Points-ও failover-এর জন্য এই দুই দিকের replication ব্যবহার করে (লেসন ১০.৯)।

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

• “Replication চালু, কিন্তু পুরনো file কখনো পৌঁছায়নি।” Live replication শুধু নতুন লেখা copy করে। Batch Replication চালাও।
• কিছু নতুন object destination-এ নেই। Object-এর replication status দেখো: FAILED সাধারণত মানে role-এর কোনো permission নেই, destination-এর bucket policy (cross-account) role-কে অনুমতি দেয়নি, বা KMS permission বাদ পড়েছে। Opt-in ছাড়া SSE-KMS object চুপচাপ বাদ পড়ে। সরাসরি Glacier Flexible বা Deep Archive-এ রাখা object বাদ পড়ে।
• Source-এ মোছা file destination-এ রয়ে গেছে। হয় delete marker replication বন্ধ (default), নয়তো ওগুলো ছিল চিরতরে version delete, যা কখনো replicate হয় না।
• ভুল করে মোছা একটা file দুই Region থেকেই উধাও। Delete marker replication চালু ছিল। ফিরিয়ে আনতে প্রতিটা bucket-এ marker মুছে দাও; data এখনো আছে।
• নষ্ট একটা upload দুই bucket-এই ভালো file-কে বদলে দিয়েছে। ভালো লেখার মতোই খারাপ লেখাও replication বিশ্বস্তভাবে copy করে। Destination-এর versioning পুরনো version রেখে দেয়; replication নিজে কোনো backup না।
• “Versioning suspend করতে পারছি না।” Bucket-টা replication-এর source (আগে rule সরাও), অথবা MFA Delete চালু (root-এর MFA code লাগবে)।
• Versioning চালুর পর বিল দ্বিগুণ। কোনো application একই key বারবার overwrite করছে। Noncurrent version expiration যোগ করো।
• হাজার হাজার delete marker-এ listing ধীর। কোনো tool লুপে key মুছে আবার বানিয়েছে। Lifecycle দিয়ে expired delete marker পরিষ্কার করো।

#System design-এ versioning আর replication

• যেখানে দরকার, সেখানে আগে versioning। মানুষের ভুলের বিরুদ্ধে এটাই সবচেয়ে সস্তা বিমা, আর replication, Object Lock, MFA Delete সবই এর ওপর দাঁড়িয়ে। প্রথম দিন থেকেই এর সাথে noncurrent version-এর lifecycle rule জুড়ে দাও।
• Replication availability আর অবস্থানের জন্য, ইতিহাসের জন্য না। এটা ভুলও copy করে। ইতিহাস দেয় versioning (আর Object Lock); replication দেয় দ্বিতীয় একটা জায়গা। ভালো disaster-recovery কপিতে দুটোই থাকে: versioned destination, delete marker replication বন্ধ, আর সম্ভব হলে আলাদা administrator-দের অধীনে অন্য account-এ।
• কোন বিপদের ভয়, সেটা দেখে CRR বা SRR বাছো। Region বিভ্রাট বা নিয়ন্ত্রকের দূরত্বের নিয়ম → CRR। Account বেহাত হওয়া, log এক জায়গায় আনা, data-residency বা test কপি → SRR (সস্তা: Region-এর বাইরে transfer নেই)।
• Recovery point objective। সাধারণ CRR যতটা পারে ততটা দ্রুত recovery point দেয়; RTC দেয় ১৫ মিনিটের এমন একটা, যা চুক্তিতে লেখা যায়। Disaster recovery-র কৌশল নিয়ে আলাদা chapter আছে (chapter ২৩)।
• Latency। CRR অন্য Region-এর user-দের কাছে data রাখে, তবে সারা দুনিয়ার user-দের সেবা দিতে সাধারণত S3 Multi-Region Access Points বা CloudFront (chapter ১১) ভালো উপায়।
• খরচের হিসাব। CRR-এ খরচ: Region-এর বাইরে প্রতি GB transfer, প্রতিটা replicated object-এ একটা PUT, destination-এর storage, আর চালু থাকলে RTC। Backup কপি সরাসরি সস্তা storage class-এ replicate করলে অনেক টাকা বাঁচে।

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

AWS CLI দিয়ে, দুটো ভিন্ন Region-এ দুটো bucket (নামগুলো উদাহরণ; bucket-এর নাম সারা দুনিয়ায় অনন্য, তাই নিজের নাম বাছো):

# 1. Versioning on both buckets
aws s3api create-bucket --bucket scans-example --region ap-south-1 \
  --create-bucket-configuration LocationConstraint=ap-south-1
aws s3api create-bucket --bucket scans-dr-example --region ap-southeast-1 \
  --create-bucket-configuration LocationConstraint=ap-southeast-1
aws s3api put-bucket-versioning --bucket scans-example --versioning-configuration Status=Enabled
aws s3api put-bucket-versioning --bucket scans-dr-example --versioning-configuration Status=Enabled
aws s3api get-bucket-versioning --bucket scans-example

# 2. Play with versions
echo "v1" > menu.txt && aws s3 cp menu.txt s3://scans-example/menu.txt
echo "v2" > menu.txt && aws s3 cp menu.txt s3://scans-example/menu.txt
aws s3api list-object-versions --bucket scans-example --prefix menu.txt
aws s3 rm s3://scans-example/menu.txt                    # adds a delete marker
aws s3api head-object --bucket scans-example --key menu.txt   # 404
aws s3api list-object-versions --bucket scans-example --prefix menu.txt \
  --query 'DeleteMarkers[].{Id:VersionId,Latest:IsLatest}'
aws s3api delete-object --bucket scans-example --key menu.txt --version-id <marker-id>   # undelete
aws s3api get-object --bucket scans-example --key menu.txt --version-id <old-id> old.txt  # read an old version

Replication role (s3.amazonaws.com-এর জন্য trust policy) আর একটা rule:

aws iam create-role --role-name s3-replication-role \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"s3.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
aws iam put-role-policy --role-name s3-replication-role --policy-name replicate \
  --policy-document file://replication-permissions.json

replication.json, পুরো bucket-এর জন্য একটা rule, delete marker replication বন্ধ আর RTC চালু:

{
  "Role": "arn:aws:iam::111122223333:role/s3-replication-role",
  "Rules": [
    {
      "ID": "scans-to-singapore",
      "Status": "Enabled",
      "Priority": 1,
      "Filter": {},
      "DeleteMarkerReplication": { "Status": "Disabled" },
      "Destination": {
        "Bucket": "arn:aws:s3:::scans-dr-example",
        "StorageClass": "STANDARD_IA",
        "ReplicationTime": { "Status": "Enabled", "Time": { "Minutes": 15 } },
        "Metrics": { "Status": "Enabled", "EventThreshold": { "Minutes": 15 } }
      }
    }
  ]
}

aws s3api put-bucket-replication --bucket scans-example \
  --replication-configuration file://replication.json
aws s3 cp scan-0420.dcm s3://scans-example/
aws s3api head-object --bucket scans-example --key scan-0420.dcm --query ReplicationStatus     # PENDING, then COMPLETED
aws s3api head-object --bucket scans-dr-example --key scan-0420.dcm --query ReplicationStatus  # REPLICA

# Suspending versioning on the source now fails while the rule exists
aws s3api put-bucket-versioning --bucket scans-example --versioning-configuration Status=Suspended

MFA Delete (শুধু root user-এর credential দিয়ে, শুধু CLI-তে; বিস্তারিত লেসন ১০.৯-এ):

aws s3api put-bucket-versioning --bucket scans-example \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::111122223333:mfa/root-account-mfa-device 123456"

#সারসংক্ষেপ

মূল কথা

• Versioning bucket-এর একটা setting, যা প্রতিটা object-এর প্রতিটা version রেখে দেয়। অবস্থা: unversioned (default), enabled, suspended; একবার চালু হলে আর কখনো বন্ধ হয় না, শুধু suspend হয়।
• প্রতিটা লেখা নতুন version ID পায়; সবচেয়ে নতুনটা current, পুরনোগুলো noncurrent। Versioning-এর আগের object-এর ID null। প্রতিটা version-এর পুরো বিল আসে: noncurrent version-এর lifecycle rule ব্যবহার করো।
• সাধারণ DELETE → একটা delete marker current হয় (GET → 404, x-amz-delete-marker: true)। ফিরিয়ে আনা = marker delete করা। Version ID সহ DELETE = চিরতরে, কোনো marker নেই। ID দিয়ে marker GET → 405।
• Suspended: নতুন লেখা ID null পায় আর আগের null version-কে বদলে দেয়; পুরনো version রয়ে যায়।
• MFA Delete: version চিরতরে মুছতে বা versioning-এর অবস্থা বদলাতে root-এর MFA code লাগে; শুধু root, শুধু CLI/API (লেসন ১০.৯)। Ransomware আর WORM-এর জন্য Object Lock।
• CRR (অন্য Region) আর SRR (একই Region), অ্যাসিঙ্ক্রোনাস, একই বা ভিন্ন account। লাগে দুই bucket-এ versioning আর একটা IAM role; cross-account-এ destination-এর bucket policy।
• শুধু নতুন object replicate হয়; আগের, ব্যর্থ, আগেই অন্যত্র replicate হওয়া object আর replica সামলায় Batch Replication।
• Delete marker: ইচ্ছাধীন (delete marker replication, tag rule-এ না)। Version delete: কখনো replicate হয় না। Lifecycle-এর কাজ: কখনো না।
• শিকল চলে না: A → B → C দিয়ে A-এর object C-তে যায় না; A → B আর A → C দাও।
• SSE-KMS object-এর জন্য opt-in, destination Region-এর key আর KMS permission লাগে; SSE-S3 আর SSE-C default-এই replicate হয়; Glacier Flexible / Deep Archive-এর object replicate হয় না।
• RTC: ১৫ মিনিট (নকশায় ৯৯.৯৯%, SLA ৯৯.৯%-এ), metric আর event, বাড়তি খরচ। দুই দিকের metadata-র জন্য replica modification sync।

নিজেকে যাচাই করো: Versioning আর Replication৩০টি প্রশ্ন