Object storage চালানো — bucket, versioning, lifecycle, storage class আর presigned URL

১ · Bucket, region আর key — “folder” আসলে নেই

পর্ব ২০-এ (Object, block আর file storage) দেখা হয়েছে কোন কাজে object storage মানায়। এবার প্রশ্ন বদলাল: এটি চালাবেন কীভাবে? ধরুন একটি কাল্পনিক অনলাইন বাজার অ্যাপ। তাতে পণ্যের ছবি, ক্রেতার invoice, প্রতিদিনের log আর database backup জমে। ভুল setting দিলে হয় বিল ফুলে ওঠে, নয় ডেটা ফাঁস হয়, নয় ফাইল চিরতরে হারায়। এই পর্ব সেই তিন বিপদের হাত থেকে বাঁচার হাতের কাজ।

গঠনের দিক থেকে object storage সরল। একটি bucket হলো ডেটা রাখার বড় পাত্র। প্রতিটি ফাইল একটি object, আর তার ঠিকানা একটি key. সব কাজ হয় HTTP API-তে: PUT, GET, DELETE, LIST.

Bucket-এর নাম আর region

• নামটি সাধারণত সবার মধ্যে একক। S3-তে সাধারণ bucket-এর নাম ঐতিহ্যগতভাবে পুরো provider জুড়ে একক, ৩ থেকে ৬৩ অক্ষরের, ছোট হাতের অক্ষর, সংখ্যা আর হাইফেনে তৈরি। নামটি URL-এ বসে, তাই গোপন কিছু নামে রাখবেন না। ডট ব্যবহার করলে TLS certificate মেলাতে ঝামেলা হয়, তাই এড়ানো ভালো। নিয়ম provider-ভেদে আলাদা ও বদলায়।
• Azure-এ এক ধাপ বেশি। সেখানে storage account-এর ভেতরে container, তার ভেতরে blob. Account-এর নামটি একক হতে হয়।
• Region পরে বদলানো যায় না। Bucket একটি region-এ তৈরি হয় (কোথাও dual-region বা multi-region বিকল্পও আছে)। অন্য region-এ নিতে চাইলে নতুন bucket বানিয়ে কপি করতে হয়। তাই ব্যবহারকারী, compute আর আইনের দিক দেখে শুরুতেই বাছুন। পর্ব ৫-এর data residency-র কথা এখানে খাটে।

# উদাহরণ: চালানোর জন্য নয়। আসল cloud-এ চালালে খরচ হতে পারে।
aws s3 mb s3://example-bucket --region ap-southeast-1
aws s3 cp app.log s3://example-bucket/logs/2026/05/app.log
aws s3 ls s3://example-bucket/logs/2026/
aws s3api list-objects-v2 --bucket example-bucket \
    --prefix logs/2026/ --delimiter /

# নমুনা আউটপুট — version-ভেদে আলাদা হতে পারে
$ aws s3 ls s3://example-bucket/logs/2026/
                           PRE 04/
                           PRE 05/

PRE 05/ কোনো আসল folder নয়। এর নাম prefix. আপনি --prefix দিয়ে বললেন কোন লেখা দিয়ে শুরু হওয়া key চান, আর --delimiter / দিয়ে বললেন পরের / পর্যন্ত অংশকে এক দলে গুটিয়ে দেখাতে। Object না থাকলে “folder”-ও থাকে না। Key-র নিচের ব্যবহারিক ফলগুলো মনে রাখুন:

• Rename নেই: সাধারণ bucket-এ “নাম বদল” মানে নতুন key-তে কপি, তারপর পুরোনোটি মোছা। লাখো object-এর “folder rename” তাই লাখো অনুরোধ।
• তালিকা পাতায় পাতায় আসে: S3-তে এক পাতায় সর্বোচ্চ ১,০০০ key, ক্রম key-র বাইট অনুসারে। কোটি object-এর পুরো LIST ধীর ও খরচের, তাই তারিখভিত্তিক prefix রাখা ভালো: logs/2026/05/.
• Key-তে গোপন তথ্য নয়: ফোন নম্বর বা জাতীয় পরিচয়পত্রের নম্বর key-তে বসালে তা log আর URL-এ ছড়ায়। uploads/u42/9f3a.jpg-এর মতো অর্থহীন নাম নিরাপদ।

S3-compatible মানে কতটা compatible?

Amazon S3 (২০০৬)-এর API এত ছড়িয়েছে যে অনেকে একই API দেন। একে বলে S3-compatible storage: নিজের server-এ চালানোর জন্য MinIO বা Ceph RGW, আর সেবা হিসেবে Cloudflare R2, Backblaze B2 ইত্যাদি। একই CLI বা SDK-তে শুধু endpoint বদলালেই অনেক কাজ চলে: aws s3 ls --endpoint-url https://storage.example.com. তবে “compatible” মানে সব feature নয়। Lifecycle, object lock, event বা replication-এর আচরণ আলাদা হতে পারে, আর লাইসেন্স ও দামের শর্তও বদলায়। ব্যবহারের আগে নিজের দরকারি প্রতিটি কাজ পরীক্ষা করে দেখুন।

২ · Object-এর ভেতরে — metadata, ETag আর multipart upload

একটি object মানে শুধু বাইট নয়। সাথে থাকে metadata: আকার, শেষ বদলের সময়, Content-Type, Cache-Control আর আপনার নিজের দেওয়া key-value. Metadata আলাদা করে বদলানো যায় না; object নিজের ওপর কপি করে নতুন metadata বসাতে হয়।

{
  "LastModified": "2026-05-01T00:10:12+00:00",
  "ContentLength": 1024,
  "ETag": "\"9b2cf535f27731c974343645a3985328\"",
  "ContentType": "text/plain",
  "Metadata": { "app": "bazar-api" }
}

এটি নমুনা উত্তর, version-ভেদে আলাদা হতে পারে। Content-Type ভুল হলে browser ছবি না দেখিয়ে ডাউনলোড করতে পারে, আর user-এর পাঠানো ফাইলকে HTML হিসেবে দেখালে নিরাপত্তার ঝুঁকি তৈরি হয়। তাই upload-এর সময় এটি নিজে ঠিক করে দিন।

ETag হলো object-এর একটি পরিচয়-চিহ্ন, যা বিষয়বস্তু বদলালে বদলায়। Cache যাচাই আর “মাঝখানে কেউ বদলেছে কি না” ধরার কাজে লাগে। সাবধান: একে সবসময় MD5 ভাববেন না। S3-তে সাধারণ একক PUT-এ প্রায়ই এটি MD5, কিন্তু KMS encryption বা multipart upload-এ নয়। Multipart-এর ETag-এর শেষে -3-এর মতো part-সংখ্যা থাকে। অখণ্ডতা যাচাইয়ের জন্য আলাদা checksum feature ব্যবহার করুন।

Multipart upload: বড় ফাইল ভেঙে পাঠানো

৫০ GB-র একটি backup একবারে পাঠাচ্ছেন। ৪৯ GB যাওয়ার পর সংযোগ কাটল। একক PUT-এ আবার শূন্য থেকে শুরু। Multipart upload-এ ফাইল টুকরো হয়, টুকরোগুলো একসাথেও যেতে পারে, আর ব্যর্থ টুকরোটিই শুধু আবার পাঠাতে হয়। বিয়েবাড়ির ক্যাটারিংয়ের মতো: সব খাবার এক ডেকচিতে না এনে আলাদা হাঁড়িতে আনা হয়, এক হাঁড়ি পড়ে গেলে শুধু সেটিই আবার রাঁধতে হয়।

লেখার সময়ে S3-তে part সর্বনিম্ন 5 MiB (শেষটি বাদে), আর part-সংখ্যা সর্বোচ্চ ১০,০০০. একক PUT-এর সীমা 5 GiB. সীমাগুলো provider-ভেদে আলাদা ও বদলায়। নিচে 250 MiB-র একটি ফাইল, part-এর আকার 100 MiB.

লিখেই কি পড়া যায়? Consistency

S3 ২০২০ সালের ডিসেম্বর থেকে সব PUT, DELETE আর LIST-এ শক্তিশালী read-after-write consistency দেয়, বাড়তি খরচ ছাড়া। অর্থাৎ PUT সফল হওয়ার পর যেকোনো client GET বা LIST করলে নতুন অবস্থাই পায়। Azure Blob আর Google Cloud Storage-ও object-এর ক্ষেত্রে শক্তিশালী consistency-র কথা বলে। অন্য S3-compatible সেবায় নিজে নিশ্চিত হোন। তিনটি সীমা মনে রাখুন: একই key-তে একসাথে দুটি PUT হলে শেষেরটি জেতে; CDN-এর cache পুরোনো কপি দেখাতে পারে; আর bucket-এর setting বদলের প্রভাব ছড়াতে কিছু সময় লাগতে পারে।

৩ · Versioning — মুছলেও মোছে না

রান্নাঘরের রেসিপি খাতার কথা ভাবুন। কেউ পুরোনো রেসিপি ছিঁড়ে ফেললে আর ফেরত আসে না। ভালো নিয়ম হলো পাতা না ছিঁড়ে নতুন পাতায় নতুন রেসিপি লেখা, আর বাতিল করতে হলে পাতার ওপর “বাতিল” স্টিকার লাগানো। স্টিকার তুললেই রেসিপি ফেরত। Versioning ঠিক এই নিয়ম, আর সেই স্টিকারের নাম delete marker.

S3-তে bucket-এর তিন অবস্থা: unversioned, enabled আর suspended. একবার চালু করলে আর unversioned-এ ফেরা যায় না, শুধু suspend করা যায়। চালু থাকলে প্রতিটি PUT একটি নতুন version বানায়। আগেরটি হয়ে যায় noncurrent version. আর version ID ছাড়া DELETE কিছুই মোছে না, শুধু সবার ওপরে একটি marker বসায়।

# উদাহরণ: চালানোর জন্য নয়
aws s3api put-bucket-versioning --bucket example-bucket \
    --versioning-configuration Status=Enabled
aws s3api list-object-versions --bucket example-bucket \
    --prefix reports/may.csv
aws s3api delete-object --bucket example-bucket \
    --key reports/may.csv --version-id EXAMPLEVERSIONID

নিচের সিমুলেটরে আরও একটি পরিস্থিতি আছে: ভুল ফাইল ওপরে বসেছে, তাই marker তুললেও ভালো ফাইল ফেরে না। তখন পুরোনো version-কে ওপরে কপি করতে হয়।

// A versioned bucket: PUT, DELETE with a delete marker, and two ways to restore.
class Bucket {
  constructor() { this.rows = []; this.n = 0; }       // rows[0] = newest
  put(key, mb) { const id = "v" + ++this.n;
    this.rows.unshift({ key, id, mb }); return "PUT -> " + id; }
  del(key, id) {
    if (id) { this.rows = this.rows.filter(r => r.id !== id);
      return "DELETE version " + id + " (permanent)"; }
    const dm = "DM" + ++this.n;
    this.rows.unshift({ key, id: dm, mb: 0, marker: true });
    return "DELETE -> marker " + dm; }
  copyBack(key, id) { const old = this.rows.find(r => r.id === id);
    return "COPY " + id + " on top: " + this.put(key, old.mb); }
  get(key) { const cur = this.rows.find(r => r.key === key);
    return !cur || cur.marker ? "404" : "200 " + cur.id; }
  mb() { return this.rows.reduce((s, r) => s + r.mb, 0); }
  show(key, msg) { const ids = this.rows.map(r => r.id).join(" ");
    console.log(msg.padEnd(32) + " | GET " + this.get(key).padEnd(6) +
      " | " + String(this.mb()).padStart(2) + " MB | " + ids); }
}
const b = new Bucket(), k = "reports/may.csv";
b.show(k, b.put(k, 10));          // good report
b.show(k, b.put(k, 12));          // a wrong file overwrites it
b.show(k, b.del(k));              // someone deletes it
b.show(k, b.del(k, "DM3"));       // restore 1: remove the marker
b.show(k, b.copyBack(k, "v1"));   // restore 2: copy the good version on top
b.show(k, b.del(k, "v2"));        // really remove the wrong file

PUT -> v1                        | GET 200 v1 | 10 MB | v1
PUT -> v2                        | GET 200 v2 | 22 MB | v2 v1
DELETE -> marker DM3             | GET 404    | 22 MB | DM3 v2 v1
DELETE version DM3 (permanent)   | GET 200 v2 | 22 MB | v2 v1
COPY v1 on top: PUT -> v4        | GET 200 v4 | 32 MB | v4 v2 v1
DELETE version v2 (permanent)    | GET 200 v4 | 20 MB | v4 v1

৪ · Storage class — গরম তাক থেকে দূরের গুদাম

মুদি দোকানে যা রোজ বিক্রি হয়, তা হাতের কাছের তাকে থাকে। মাসে একবার লাগে এমন মাল থাকে পেছনের ঘরে। আর বছরের পুরোনো হিসাবের খাতা চলে যায় দূরের গুদামে। ভাড়া কমে, কিন্তু আনতে সময় আর লোক লাগে। Storage class এই একই হিসাব। ডেটা যত ঠান্ডা ধাপে যায়, জমার দাম তত কমে, কিন্তু পড়ার খরচ আর শর্ত তত বাড়ে।

এটি লেখার সময়ের সাধারণ চিত্র, এবং class আর সীমা বদলায়। শেষ সারিটি খেয়াল করুন: একই “archive” নামে অপেক্ষা ঘণ্টাও হতে পারে, ms-ও হতে পারে। তাই নাম নয়, শর্ত পড়ুন। S3-র Intelligent-Tiering-এর মতো স্বয়ংক্রিয় class-ও আছে, যা ব্যবহার দেখে নিজেই ধাপ বদলায়, বিনিময়ে object-প্রতি নজরদারি ফি নেয়।

তিনটি ফি, যা সস্তা দামের আড়ালে থাকে

• Retrieval fee: পড়ার সময় প্রতি GB-তে retrieval fee. এর ওপরে cloud-এর বাইরে পাঠালে egress আলাদা।
• Minimum duration: ন্যূনতম জমার সময়-এর আগে মুছলে বা সরালে বাকি দিনের ভাড়াও দিতে হয়।
• Request fee: ধাপ বদলানো প্রতি object-এর একটি অনুরোধ। আকার নয়, সংখ্যাই এখানে দাম ঠিক করে। কিছু class ছোট object-কেও একটি ন্যূনতম আকার ধরে বিল করে, যেমন S3 Standard-IA-তে 128 KB.

হিসাব ১, ন্যূনতম সময়ের ফাঁদ: 1,000 GB cool ধাপে রেখে ১০ দিন পরে মুছলেন। ৩০ দিনের ভাড়া দিতে হবে: 1,000 × $0.010 = $10.00. Hot-এ ১০ দিনের ভাড়া হতো 1,000 × $0.020 × 10/30 = $6.67. অর্থাৎ “সস্তা” ধাপ এখানে বেশি দামি। সমতা আসে d দিনে, যেখানে 1,000 × 0.020 × d/30 = 10, অর্থাৎ d = ১৫ দিন। ডেটা ১৫ দিনের কম থাকলে এই দামে hot-ই সস্তা।

হিসাব ২, কতটা পড়লে লাভ নেই: প্রতি মাসে ডেটার f অংশ পড়লে প্রতি GB-র মাসিক খরচ হয় জমার দাম + f × পড়ার দাম। Hot-এর সাথে সমান ধরলে cool-এ 0.020 = 0.010 + 0.01f, তাই f = ১ (১০০%). Cold-এ 0.020 = 0.004 + 0.03f, তাই f ≈ ০.৫৩৩. Archive-এ 0.020 = 0.001 + 0.06f, তাই f ≈ ০.৩১৭. মাসে ডেটার প্রায় এক-তৃতীয়াংশ পড়লেই archive-এর সুবিধা শেষ। এই হিসাবে অপেক্ষার সময়, request আর egress ধরা হয়নি।

৫ · Lifecycle rule — নিজে নিজে নামানো আর মোছা

লক্ষ লক্ষ object হাতে সরানো সম্ভব নয়। Lifecycle rule হলো bucket-এর ওপর লেখা নিয়ম: এই prefix-এর object এত দিন পরে ওই ধাপে যাবে, এত দিন পরে মুছবে। নিচের JSON একটি সম্পূর্ণ নিয়ম। প্রতিটি অংশের কাজ আলাদা।

{
  "Rules": [
    {
      "ID": "logs-tiering",
      "Filter": {
        "Prefix": "logs/"
      },
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 365
      },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 30
      },
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    }
  ]
}

# উদাহরণ: চালানোর জন্য নয়
aws s3api put-bucket-lifecycle-configuration --bucket example-bucket \
    --lifecycle-configuration file://lifecycle.json

Lifecycle তাৎক্ষণিক নয়। নিয়ম সাধারণত দিনে একবারের মতো ঘুরে কাজ করে, তাই কয়েক ঘণ্টা বা দিনের দেরি স্বাভাবিক। মুছে ফেলার নিয়ম প্রথমে একটি ছোট prefix-এ পরীক্ষা করুন, কারণ ভুল prefix মানে চুপচাপ ডেটা হারানো।

১২ মাসের বিল: তিনটি পরিকল্পনা

ধরুন প্রতি মাসে 100 GB log আসে, আর ৭ মাস বয়সে মুছে যায়। দশম মাসে একটি অডিটে পঞ্চম মাসের ব্যাচ থেকে 20 GB পড়তে হলো। তিন পরিকল্পনা তুলনা করি। Log ছোট ফাইলে থাকলে কী হয়, সেটিও দেখুন। সব দাম ধরে নেওয়া, মাস ৩০ দিনের।

// 12 months of logs: 100 GB arrives each month and is deleted at age 7 months.
// ALL prices are ASSUMED: $/GB-month, $/GB read, $/1000 objects moved in.
const T = {
  hot:     { store: 0.020, read: 0.00, move: 0.00, min: 0 },
  cool:    { store: 0.010, read: 0.01, move: 0.01, min: 1 },
  cold:    { store: 0.004, read: 0.03, move: 0.03, min: 3 },
  archive: { store: 0.001, read: 0.06, move: 0.05, min: 6 } };
const GB = 100, OBJ_MB = 1, AUDIT = { month: 10, batch: 5, gb: 20 };
const objects = GB * 1000 / OBJ_MB;          // objects in one month of logs

function bill(plan) {                        // plan = [[tier, months], ...]
  const c = { store: 0, move: 0, read: 0, early: 0 }, byMonth = [];
  const sum = () => c.store + c.move + c.read + c.early;
  for (let m = 1; m <= 12; m++) {
    const before = sum();
    for (let k = 1; k <= m; k++) {           // k = month this batch arrived
      const age = m - k; let from = 0;
      for (const [name, stay] of plan) {
        const t = T[name];
        if (age === from && from > 0) c.move += objects / 1000 * t.move;
        if (age >= from && age < from + stay) {
          c.store += GB * t.store;
          if (m === AUDIT.month && k === AUDIT.batch) c.read += AUDIT.gb * t.read; }
        if (age === from + stay) c.early += GB * t.store * Math.max(0, t.min - stay);
        from += stay; } }
    byMonth.push((sum() - before).toFixed(1)); }
  console.log(`  store ${c.store.toFixed(2)}, move ${c.move.toFixed(2)}, read ${c.read.toFixed(2)}, early ${c.early.toFixed(2)} = $${sum().toFixed(2)}`);
  console.log("  monthly: " + byMonth.join(" ")); }

console.log(`${objects} objects a month, ${OBJ_MB} MB each`);
for (const [name, plan] of [["A all hot", [["hot", 7]]],
  ["B hot-cool-cold", [["hot", 1], ["cool", 2], ["cold", 4]]],
  ["C hot-cool-archive", [["hot", 1], ["cool", 2], ["archive", 4]]]]) {
  console.log(name); bill(plan); }

100000 objects a month, 1 MB each
A all hot
  store 126.00, move 0.00, read 0.00, early 0.00 = $126.00
  monthly: 2.0 4.0 6.0 8.0 10.0 12.0 14.0 14.0 14.0 14.0 14.0 14.0
B hot-cool-cold
  store 57.00, move 38.00, read 0.60, early 0.00 = $95.60
  monthly: 2.0 4.0 5.0 8.4 8.8 9.2 9.6 9.6 9.6 10.2 9.6 9.6
C hot-cool-archive
  store 48.00, move 56.00, read 1.20, early 1.00 = $106.20
  monthly: 2.0 4.0 5.0 10.1 10.2 10.3 10.4 10.6 10.6 11.8 10.6 10.6

৬ · কে ঢুকতে পারে — block public access, policy আর ACL

Object storage-এর সবচেয়ে পরিচিত দুর্ঘটনা হলো ভুলে public হয়ে থাকা bucket. প্রতিরক্ষার প্রথম স্তর একটি সুইচ। Block public access অন্য সব setting-এর ওপরে বসে, আর public করে এমন policy বা ACL-কে আটকে বা উপেক্ষা করে। S3-তে এটি ২০১৮ সালে আসে, আর ২০২৩ সালের এপ্রিল থেকে নতুন bucket-এ এটি ডিফল্টভাবে চালু, ACL-ও ডিফল্টভাবে বন্ধ। Azure-এ storage account-স্তরে public access বন্ধ রাখার setting, আর Google Cloud Storage-এ public access prevention একই কাজ করে। Account বা organization স্তরে চালু রাখলে একটি ভুল bucket setting ডেটা ফাঁস করতে পারে না।

একই account-এ IAM বা bucket policy-র যেকোনো একটিতে allow থাকলেই সাধারণত যথেষ্ট, কিন্তু কোথাও স্পষ্ট deny থাকলে সেটিই জেতে। অন্য account থেকে এলে দুই দিকেই allow লাগে। পুরো মূল্যায়নের ক্রম পর্ব ৩২-এ আসবে। নিচের policy-টি TLS ছাড়া সব অনুরোধ নাকচ করে। Deny এখানে নিরাপদ, কারণ এটি কাউকে নতুন অনুমতি দেয় না।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyWithoutTLS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

ডিফল্ট encryption-ও মনে রাখুন। S3 ২০২৩ সালের জানুয়ারি থেকে নতুন object নিজে থেকেই encrypt করে, তবে এটি public access ঠেকায় না: অনুমতি থাকলে ডেটা decrypt হয়েই আসে। কার হাতে key থাকবে, সেই আলোচনা পর্ব ৩৩-এ।

৭ · Presigned URL — চাবি না দিয়ে একটি টিকিট

ক্রেতা নিজের invoice ডাউনলোড করবেন। Bucket public করা যাবে না। আবার অ্যাপ server দিয়ে ফাইল টানলে তার memory, network আর সময় আটকে থাকে। সমাধান presigned URL: আপনার server নিজের credential দিয়ে একটি URL সই করে দেয়, যা একটি নির্দিষ্ট কাজ একটি নির্দিষ্ট সময় পর্যন্ত করতে পারে।

কৌশলটি পর্ব ৬-এর signed request-এর মতোই। URL-এর ভেতরেই স্বাক্ষর আর মেয়াদ থাকে। Storage একই হিসাব আবার করে মিলিয়ে দেখে। নিচের toy model-এ আসল format নেই, কিন্তু HMAC-এর যুক্তিটি আসল। ঘড়ি আর key দুটোই নকল।

# A toy presigned URL. Real formats differ (AWS SigV4, Azure SAS, Google V4).
import hashlib, hmac
from urllib.parse import urlsplit, parse_qs

KEY = b"fake-signing-key-for-learning"          # never leaves the app server
NOW = 1_000_000                                 # simulated clock, in seconds

def sig(method, path, expires):
    text = f"{method}\n{path}\n{expires}"
    return hmac.new(KEY, text.encode(), hashlib.sha256).hexdigest()

def presign(method, path, ttl, now):
    exp = now + ttl
    return f"https://storage.example.com{path}?exp={exp}&sig={sig(method, path, exp)}"

def storage_check(method, url, now):            # the storage side knows KEY too
    u = urlsplit(url)
    q = parse_qs(u.query)
    exp, given = int(q["exp"][0]), q["sig"][0]
    if not hmac.compare_digest(sig(method, u.path, exp), given):
        return "403 SignatureDoesNotMatch"
    return "200 OK" if now <= exp else "403 Request has expired"

url = presign("GET", "/example-bucket/reports/may.csv", 300, NOW)
print(url.split("?")[0])
print("?" + url.split("?")[1][:34] + "...")
print("in time   :", storage_check("GET", url, NOW + 10))
print("too late  :", storage_check("GET", url, NOW + 301))
print("other verb:", storage_check("DELETE", url, NOW + 10))
print("other file:", storage_check("GET", url.replace("may", "june"), NOW + 10))
print("longer exp:", storage_check("GET", url.replace("exp=1000300", "exp=1999999"), NOW + 10))

https://storage.example.com/example-bucket/reports/may.csv
?exp=1000300&sig=f47efa9fda62b93f07...
in time   : 200 OK
too late  : 403 Request has expired
other verb: 403 SignatureDoesNotMatch
other file: 403 SignatureDoesNotMatch
longer exp: 403 SignatureDoesNotMatch

# উদাহরণ: চালানোর জন্য নয় (boto3 লাগে, আর আসল credential)
import boto3
s3 = boto3.client("s3")
url = s3.generate_presigned_url(
    "put_object",
    Params={"Bucket": "example-bucket", "Key": "uploads/u42/9f3a.jpg",
            "ContentType": "image/jpeg"},
    ExpiresIn=300,
)

ডাউনলোডের জন্য CLI-তে আছে aws s3 presign s3://example-bucket/reports/may.csv --expires-in 300. Azure-এ একই ধারণার নাম SAS, Google-এ signed URL. Browser থেকে সরাসরি upload হলে bucket-এ CORS নিয়মও লাগে, কারণ অন্য domain-এর দিকে browser অনুরোধ পাঠাতে অনুমতি চায়:

{
  "CORSRules": [
    {
      "AllowedOrigins": [
        "https://app.example.com"
      ],
      "AllowedMethods": [
        "PUT"
      ],
      "AllowedHeaders": [
        "Content-Type"
      ],
      "MaxAgeSeconds": 300
    }
  ]
}

৮ · Website, event আর replication

Static website, CDN-এর পেছনে

HTML, CSS, JS আর ছবি বানানোই থাকলে server লাগে না। Bucket থেকেই static website hosting করা যায়। তবে bucket সরাসরি খোলা না রেখে সামনে CDN বসানোই ভালো পথ: HTTPS, নিজের domain, cache আর কম egress একসাথে মেলে। Bucket private থাকে, আর শুধু CDN-কে পড়ার অনুমতি দেওয়া হয়। AWS-এ একে বলে origin access control; অন্য provider-এ নিজস্ব ব্যবস্থা আছে। CDN-এর পুরো গল্প পর্ব ৩০-এ।

# উদাহরণ: চালানোর জন্য নয়
# নামে hash আছে এমন ফাইল বদলায় না, তাই লম্বা cache
aws s3 cp dist/assets/ s3://example-bucket/assets/ --recursive \
    --cache-control "public,max-age=31536000,immutable"
# index.html প্রতিবার যাচাই হবে
aws s3 cp dist/index.html s3://example-bucket/index.html \
    --cache-control "no-cache"

Event notification: ফাইল এলেই কাজ শুরু

Event notification মানে object তৈরি বা মোছা হলে storage নিজেই একটি বার্তা পাঠায়: queue, serverless function বা event bus-এ। Polling করে বারবার LIST করতে হয় না। তিনটি বাস্তব সতর্কতা: বার্তা at-least-once আসে, তাই একই event দুবারও আসতে পারে, ক্রমও উল্টাতে পারে, আর আপনার কোডে idempotency থাকতে হবে। Function যদি ফল একই bucket-এর একই prefix-এ লেখে, নিজেকেই বারবার ডেকে বিল ফুলিয়ে দিতে পারে; তাই uploads/ থেকে পড়ে thumbs/-এ লিখুন, আর event-এ prefix filter দিন। পর্ব ৬৯ আর ৭০-এ এর বিস্তার আছে।

Replication: অন্য region-এ কপি

Cross-region replication প্রতিটি নতুন object অন্য region-এর bucket-এ কপি করে। এটি region-ব্যাপী বিপর্যয়, কম latency আর আইনি কারণে কাজে লাগে। S3-তে দুই পাশেই versioning লাগে, কপি হয় asynchronous ভাবে, আর চালুর আগের object নিজে থেকে যায় না; তার জন্য আলাদা batch কাজ লাগে। অর্থাৎ RPO শূন্য নয়। খরচ দ্বিগুণ জমা আর region-পারাপারের ডেটা ফি। Delete marker কপি হবে কি না সেটিও setting, আর version-ID দিয়ে মোছা সাধারণত কপি হয় না। Google-এর dual-region bucket আর Azure-এর geo-redundant storage একই লক্ষ্যে ভিন্ন পথ। মনে রাখুন, ভুল ডেটা বা ভুল DELETE-ও কপি হয়ে যেতে পারে, তাই replication backup-এর বিকল্প নয়। পর্ব ২৪-এ এই হিসাব আছে।

৯ · Object lock — ransomware-এর বিরুদ্ধে শেষ দেয়াল

কল্পনা করুন, ransomware বা চুরি যাওয়া একটি শক্তিশালী credential দিয়ে কেউ আপনার backup মুছে দিতে বা বিকৃত করতে চায়। Versioning এখানে যথেষ্ট নয়, কারণ যার DeleteObjectVersion-এর অধিকার আছে, সে পুরোনো version-ও মুছতে পারে, lifecycle বদলাতে পারে। দরকার এমন কপি, যা নিজের অধিকারেও মোছা যায় না।

Object lock সেই ব্যবস্থা। একে বলে WORM: একবার লিখুন, বহুবার পড়ুন। জমির দলিল রেজিস্ট্রি অফিসে তোলার মতো: আপনার মালিকানা থাকলেও বালাম বই থেকে পাতা ছেঁড়ার উপায় নেই। S3-তে এর জন্য versioning লাগে, আর নিয়ম এমন:

# উদাহরণ: চালানোর জন্য নয়। আগে Governance-এ পরীক্ষা করুন।
aws s3api put-object-lock-configuration --bucket example-bucket \
    --object-lock-configuration '{"ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"GOVERNANCE","Days":30}}}'

Azure-এ immutable storage আর Google-এ bucket lock বা retention lock একই ধারণা। একটি ভালো প্রতিরক্ষা-নকশা এমন: backup আলাদা account-এ, উৎস account-এর credential সেখানে শুধু লিখতে পারে, মুছতে পারে না; সেখানে object lock চালু; replication-এ কপি অন্য region-এ; আর নিয়মিত restore পরীক্ষা। শেষেরটি বাদ দিলে বাকি সব আশা মাত্র।

১০ · AI-এর যুগে object storage

“S3-তে ছবি দেখাতে পারছি না” বলে AI-কে জিজ্ঞেস করলে সে প্রায়ই সবচেয়ে দ্রুত সমাধান দেয়, আর সেটিই সবচেয়ে বিপজ্জনক: bucket public করা। AI-এর লেখা কনফিগারেশন চলতে পারে, তবু নিরাপদ বা সস্তা না-ও হতে পারে।

AI-এর দেওয়া storage কনফিগারেশন — যাচাইয়ের চেকলিস্ট

• Block public access চালু আছে, আর কোথাও "Principal": "*"-এর allow নেই
• প্রতিটি অনুমতি নির্দিষ্ট bucket, prefix আর কাজে সীমিত
• Lifecycle-এ noncurrent version আর অসমাপ্ত multipart-এর নিয়ম আছে, আর prefix ঠিক
• মোট বিল হিসাব করেছি: জমা, request, retrieval, ন্যূনতম সময় আর egress, budget alert-সহ
• মোছার কমান্ড আগে --dryrun-এ আর একটি পরীক্ষার bucket-এ চালিয়েছি
• প্রতিটি field official docs-এ মিলিয়েছি, আর prompt-এ কোনো আসল key বা secret দিইনি