Bucket, Object আর Key

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

• Amazon S3 কী, কেন এটা disk বা file system না হয়ে object storage, সেটা বোঝাতে; আর রোজকার কোন কোন কাজে এটা লাগে তা বলতে: ছবি আর media রাখা, backup, log archive, data lake, software download আর static website।
• কেন একটা bucket-এর নাম পুরো দুনিয়ায় অনন্য অথচ bucket-টা থাকে একটা Region-এ, সেটা ব্যাখ্যা করতে; bucket-এর নামের সব নিয়ম খাটাতে; আর সবার global namespace আর নিজের account regional namespace-এর মধ্যে বাছতে।
• Object, key আর prefix কী বোঝাতে, আর console-এ folder দেখা গেলেও কেন S3-এ সত্যিকারের কোনো folder নেই, সেটা বলতে।
• আকারের সীমাগুলো বলতে (object প্রতি ৫০ TB, PUT প্রতি ৫ GB, ৫ MiB থেকে ৫ GiB-এর ১০,০০০টা part), কখন multipart upload লাগবে ঠিক করতে, আর part-এর সংখ্যা ও আকার হিসাব করতে।
• System metadata, user metadata, tag আর version ID আলাদা করে চিনতে, আর upload-এর পরে কোনটা বদলানো যায় সেটা বলতে।
• S3-এর strong read-after-write consistency কী, কী এখনো eventually consistent, আর conditional write কীভাবে দুজন লেখককে একে অন্যের লেখা মুছে ফেলা থেকে আটকায়, সেটা ব্যাখ্যা করতে।
• S3-এ কীসের জন্য টাকা দিতে হয় তার তালিকা দিতে, আর মাসের একটা সহজ বিল আন্দাজ করতে।

#Amazon S3 জিনিসটা কী

Amazon S3 (Simple Storage Service) হলো AWS-এর object storage service, AWS-এর সবচেয়ে পুরনো আর সবচেয়ে বেশি ব্যবহৃত ভিতগুলোর একটা। একে বলা হয় এমন storage, যেটা সীমাহীনভাবে বাড়ে: কোনো volume বানাতে হয় না, আকার বাছতে হয় না, জায়গা বাড়াতেও হয় না। ডেটা রাখো, যতটুকু জমা আছে ততটুকুর দাম দাও, S3 তোমার সাথে সাথে বড় হতে থাকে। অনেক website-এর মেরুদণ্ডই S3, আর AWS-এর অনেক service-ও ভেতরে ভেতরে S3 ব্যবহার করে: EBS snapshot আর AMI জমা থাকে S3-এ, CloudTrail আর load balancer তাদের log লেখে S3-এ, আর Athena, Glue, Redshift সরাসরি S3 থেকে ডেটা পড়ে।

#Disk না, object storage

লেসন ৫.৪-এ আমরা তিন ধরনের storage তুলনা করেছিলাম। S3 হলো তৃতীয় ধরনটা:

S3 যেহেতু HTTP-তে কথা বলে, প্রতিটা object-এর একটা ঠিকানা থাকে, আর browser, phone app, Lambda function বা অন্য কোনো AWS service কিছু mount না করেই সেখানে পৌঁছাতে পারে। এই কারণেই অনেকগুলো system যেসব file ভাগাভাগি করে, সেগুলো রাখার স্বাভাবিক জায়গা হয়ে গেছে S3।

#মানুষ S3 দিয়ে কী করে

#Bucket

Bucket হলো সেই পাত্র, যেখানে object থাকে। Slide-এ bucket-কে বলা হয়েছে “directory”; শুরুতে ছবিটা মাথায় বসাতে এটা কাজের, তবে পুরোপুরি ঠিক না। Bucket হলো সবচেয়ে ওপরের স্তরের একটা পাত্র, যার একটা নাম, একটা Region, একজন মালিক আর নিজস্ব setting আছে (versioning, encryption, policy, lifecycle rule), আর একটা bucket আরেকটার ভেতরে বসানো যায় না।

#নাম পুরো দুনিয়ার, বাড়ি একটা Region-এ

Bucket নিয়ে দুটো কথা শুরুতে প্রায় সবাইকেই গুলিয়ে দেয়, আর পরীক্ষায় দুটোই আসে:

1. নামটা global। General purpose bucket-এর নাম partition-এর সব AWS account আর সব Region মিলিয়ে অনন্য হতে হবে। (Partition মানে কয়েকটা Region-এর একটা দল: সাধারণ aws partition, China, GovCloud (US) আর European Sovereign Cloud, প্রত্যেকের নিজের আলাদা namespace।) একবার dhaka-shop-photos-example তোমার হয়ে গেলে, তুমি না মোছা পর্যন্ত আর কেউ, কোথাও, এই নাম নিতে পারবে না।

2. Bucket থাকে একটা Region-এ। বানানোর সময় Region বেছে দাও, আর তুমি নিজে copy বা replicate না করলে তার object-গুলো শুধু সেখানেই থাকে। পরে bucket-কে অন্য Region-এ সরানো বা তার নাম বদলানো যায় না।

S3 console গোলমালটা আরও বাড়ায়: সব Region-এর bucket একটাই তালিকায় দেখায়, তাই S3-কে global service মনে হয়। আসলে তা না। প্রতিটা bucket-এর একটা Region আছে, আর request যায় সেই Region-এর endpoint-এ।

Region কেন ভেবেচিন্তে বাছবে?

• Latency: বাংলাদেশের কাস্টমারদের সেবা দেওয়া ঢাকার দোকান bucket রাখবে ap-south-1 (মুম্বাই) বা ap-southeast-1 (সিঙ্গাপুর)-এ, us-east-1-এ না।
• খরচ: Region-ভেদে দাম একটু আলাদা, আর এক Region থেকে আরেক Region-এ ডেটা সরাতে টাকা লাগে।
• আইন আর compliance: ব্যাংক বা হাসপাতালকে হয়তো নির্দিষ্ট দেশের ভেতরেই ডেটা রাখতে হয়; S3 নিশ্চয়তা দেয়, object নিজে নিজে Region ছেড়ে যাবে না।

Bucket নিয়ে আরও কয়েকটা কথা জেনে রাখো:

• শুরুতে private। নতুন bucket আর তার object শুধু মালিকের account পড়তে পারে। Block Public Access শুরু থেকেই চালু, আর ACL শুরু থেকেই বন্ধ (access নিয়ে পুরোটা লেসন ১০.২-এ)।
• শুরুতেই encrypted। জানুয়ারি ২০২৩ থেকে তুমি অন্য কিছু না বললে প্রতিটা নতুন object জমা হওয়ার সময় SSE-S3 দিয়ে encrypt হয় (লেসন ১০.৮)।
• Quota। একটা account শুরুতে ১০,০০০টা general purpose bucket বানাতে পারে (নভেম্বর ২০২৪-এ ১০০ থেকে বাড়ানো হয়েছে), চাইলে আরও চাওয়া যায়। এক bucket-এ object বা byte-এর কোনো সীমা নেই।
• টাকা দেয় bucket-এর মালিক। Storage আর request-এর বিল যায় মালিকের account-এ, আর usage report-এ হিসাব যোগ হয় bucket ধরে ধরে।

#নাম রাখার নিয়ম

General purpose bucket-এর নামকে এই সব নিয়ম মানতে হবে:

• লম্বায় ৩ থেকে ৬৩ অক্ষর।
• শুধু ছোট হাতের অক্ষর, সংখ্যা, dot (.) আর hyphen (-)। বড় হাতের অক্ষর না, underscore না, ফাঁকা জায়গা না।
• শুরু আর শেষ হবে অক্ষর বা সংখ্যা দিয়ে, আর কখনো পাশাপাশি দুটো dot না।
• IP address-এর মতো দেখতে হবে না, যেমন 192.0.2.10।
• সংরক্ষিত prefix xn--, sthree- বা amzn-s3-demo- দিয়ে শুরু হবে না।
• সংরক্ষিত suffix দিয়ে শেষ হবে না: -s3alias (access point alias), --ol-s3 (Object Lambda access point alias), .mrap (Multi-Region Access Point), --x-s3 (directory bucket) বা --table-s3 (table bucket)। -an suffix চলে শুধু account regional namespace-এর নামে।

এত কড়াকড়ি কেন? কারণ bucket-এর নাম একটা DNS host name-এর অংশ হয়ে যায়: dhaka-shop-photos-example.s3.ap-south-1.amazonaws.com। DNS নামে বড়-ছোট হাতের অক্ষরের তফাত নেই, underscore-ও চলে না, তাই bucket-এর নামেও চলে না। মার্চ ২০১৮-এর আগে us-east-1-এর bucket-এ বড় হাতের অক্ষর আর underscore রাখা যেত; সেরকম কিছু পুরনো bucket এখনো আছে, কিন্তু নতুন করে আর এভাবে বানানো যায় না।

নিয়মগুলো নিজে হাতে পরখ করো। নিচের checker একটা নামকে প্রতিটা নিয়মে যাচাই করে, dot আর সহজে আন্দাজযোগ্য নাম নিয়ে সাবধান করে, আর account regional suffix দেখতে কেমন সেটাও দেখায়।

#Bucket-এর ঠিকানা কেমন হয়

প্রতিটা object-এর একটা URL আছে। AWS তিন রকম রূপ ব্যবহার করে:

Website endpoint (…s3-website.ap-south-1.amazonaws.com) হলো চতুর্থ, আলাদা একটা ঠিকানা, যেটা সাধারণ HTTP-তে পাতা দেখায়; এটা লেসন ১০.৩-এর বিষয়। URL থাকা মানেই object public না: অনুমতি ছাড়া GET করলে আসে 403 Access Denied।

#Object আর key

Object হলো bucket-এ রাখা একেকটা জিনিস: ডেটা (value, মানে file-এর byte-গুলো) আর তার সম্পর্কে কিছু তথ্য। Slide-এ object-কে “file” বলা হয়েছে; রোজকার ভাষায় শব্দটা ঠিকই আছে, শুধু মনে রেখো, S3 কখনো এগুলো খোলে না বা বোঝে না।

#Key মানে পুরো নাম

প্রতিটা object-এর ঠিক একটা key থাকে, bucket-এর ভেতরে তার নাম। Key হলো পুরো path, শুধু file-এর নাম না:

• s3://dhaka-shop-photos-example/index.html → key index.html
• s3://dhaka-shop-photos-example/photos/2026/eid/cake.jpg → key photos/2026/eid/cake.jpg

Key হলো যেকোনো UTF-8 string, সর্বোচ্চ ১,০২৪ byte (মোটামুটি ১,০২৪টা ইংরেজি অক্ষর; বাংলার প্রতিটা অক্ষর ৩ byte করে নেয়)। এতে বড়-ছোট হাতের অক্ষর আলাদা ধরা হয়: Photos/cake.jpg আর photos/cake.jpg দুটো আলাদা object। Bucket + key (আর versioning থাকলে version ID) মিলে একটা object-কে অনন্যভাবে চেনায়। S3-কে ভাবতে পারো বিশাল একটা মানচিত্র হিসেবে, যেটা “bucket + key + version” থেকে object-এ নিয়ে যায়।

Key-তে নিরাপদ অক্ষর হলো বর্ণ, সংখ্যা আর ! - _ . * ' ( )। & $ @ = ; : + , ? আর ফাঁকা জায়গা চলে, তবে URL-encode করতে হয়। Backslash, যেকোনো ধরনের বন্ধনী, caret, percent চিহ্ন, backtick, উদ্ধৃতিচিহ্ন, tilde, hash, pipe আর ছাপা যায় না এমন অক্ষর এড়িয়ে চলো। আর শুধু . বা .. দিয়ে তৈরি path-এর অংশও এড়িয়ে চলো, কারণ অনেক tool এগুলোকে “ঠিকঠাক” করতে গিয়ে বাদ দিয়ে দেয়।

#Folder নেই, আছে শুধু prefix

S3-এ কোনো directory নেই। General purpose bucket হলো একটা সমতল namespace: key-দের একটা লম্বা, সাজানো তালিকা। photos/2026/eid/cake.jpg-এর slash একটা সাধারণ অক্ষর মাত্র। শেষ slash পর্যন্ত অংশটা, photos/2026/eid/, হলো prefix, আর বাকিটা, cake.jpg, হলো object-এর নাম। Key = prefix + object-এর নাম।

Slide-এর ভাষায়, console তোমাকে “ধোঁকা দিয়ে” folder দেখায়। Bucket খুললে console S3-কে বলে delimiter / দিয়ে key-এর তালিকা দিতে। S3 তখন প্রতিটা key-কে তার প্রথম slash পর্যন্ত লেখা দিয়ে দল বাঁধে, আর দলগুলো common prefix হিসেবে ফেরত দেয়; console সেগুলো folder হিসেবে আঁকে। একটা folder-এ click করা মানে একটু লম্বা prefix দিয়ে আরেকটা list call।

এর কিছু বাস্তব ফল আছে:

• Console-এর Create folder আসলে একটা শূন্য byte-এর object upload করে, যার key শেষ হয় / দিয়ে, যেমন photos/2027/। Console এটা লুকিয়ে রাখে; CLI আর SDK এটাকে সাধারণ object হিসেবেই দেখে।
• যে “folder” এভাবে বানানো হয়নি, সেটা আছে শুধু ততক্ষণ, যতক্ষণ অন্তত একটা key ওই prefix দিয়ে শুরু হয়। শেষ object-টা মুছলেই folder উধাও।
• নাম বদলানোর উপায় নেই, folder-এরও না, object-এরও না। photos/-কে images/ বানানো মানে প্রতিটা object নতুন key-তে copy করা আর পুরনোটা মোছা: প্রতি object-এ দুটো request। লাখ লাখ object ঢোকানোর আগেই key-এর নাম পরিকল্পনা করে নাও।
• Permission আর lifecycle rule তবু “folder” ধরে কাজ করতে পারে, কারণ এগুলো prefix মেলায়: policy-র resource arn:aws:s3:::dhaka-shop-photos-example/photos/* মানে photos/ দিয়ে শুরু হওয়া প্রতিটা key।
• Performance-এর জন্যও prefix জরুরি: S3 request-এর হার বাড়ায় prefix ধরে ধরে (প্রতি prefix-এ সেকেন্ডে ৩,৫০০ write আর ৫,৫০০ read), তাই ব্যস্ত key-গুলো কয়েকটা prefix-এ ছড়িয়ে দিলে সীমাটা ওপরে ওঠে। লেসন ১০.৬-এ এটা আছে।

#একটা object কত বড় হতে পারে

• একটা object ০ byte থেকে ৫০ TB পর্যন্ত যেকোনো আকারের হতে পারে।
• একটা PUT request-এ সর্বোচ্চ ৫ GB upload করা যায়। এর চেয়ে বড় হলে multipart upload লাগবেই।

#একটা object নিজের সাথে কী কী বয়ে বেড়ায়

Key আর ডেটার বাইরেও প্রতিটা object-এর সাথে কিছু বর্ণনামূলক তথ্য থাকে। কোনটা কী, আর কোনটা বদলানো যায়, এটা জানলে পরীক্ষার অবাক করা রকম অনেক প্রশ্নের উত্তর হয়ে যায়।

#Metadata: system আর user

Metadata হলো object-কে বর্ণনা করা কিছু নাম–মানের জোড়া। Notes এটাকে দুই ভাগে ভাগ করেছে:

• System metadata ঠিক করে S3। এর কিছু শুধু S3-ই বসাতে পারে, যেমন Date, Content-Length (আকার), Last-Modified আর ETag। কিছু তুমি upload-এর সময় বাছো, যেমন Content-Type (image/jpeg দিলে browser ছবিটা download না করে দেখায়), Cache-Control, storage class আর encryption-এর setting।
• User metadata হলো তোমার নিজের জোড়া, HTTP header হিসেবে পাঠানো, যেগুলো শুরু হয় x-amz-meta- দিয়ে, যেমন x-amz-meta-photographer: rahim। S3 নামগুলো ছোট হাতের অক্ষরে রাখে আর প্রতিটা GET ও HEAD-এ ফেরত দেয়। Object প্রতি user metadata সর্বোচ্চ ২ KB, আর পুরো PUT request-এর header সর্বোচ্চ ৮ KB।

জরুরি নিয়মটা হলো: upload-এর পরে metadata সম্পাদনা করা যায় না। বদলাতে হলে object-টাকে নতুন metadata দিয়ে নিজের ওপরেই (বা নতুন key-তে) copy করতে হয়, তাতে নতুন একটা object তৈরি হয়, versioning চালু থাকলে নতুন একটা version। Console-এর “Edit metadata”-ও পর্দার আড়ালে ঠিক এটাই করে।

#Tag

Object tag হলো object প্রতি সর্বোচ্চ ১০টা key–value জোড়া, যেমন team=catalog আর status=live। Tag-এর key সর্বোচ্চ ১২৮ অক্ষর, value সর্বোচ্চ ২৫৬, আর দুটোতেই বড়-ছোট হাতের অক্ষর আলাদা। Metadata-র মতো না, tag থাকে object-এর পাশে, আর ডেটায় হাত না দিয়েই যেকোনো সময় যোগ করা, বদলানো বা মোছা যায়।

Tag কাজের, কারণ AWS-এর অন্য অংশগুলো এগুলো দেখে কাজ করতে পারে:

• নিরাপত্তা: IAM বা bucket policy শুধু classification=public tag দেওয়া object-এ access দিতে পারে (লেসন ১০.২)।
• Lifecycle: একটা rule শুধু phototype=raw tag দেওয়া object-গুলোকে ৯০ দিন পরে Glacier-এ পাঠাতে পারে (লেসন ১০.৫)।
• বিশ্লেষণ আর খরচ: Storage Class Analysis, CloudWatch metric আর S3 Batch Operations tag দিয়ে বাছাই করে কাজ করতে পারে।

#Version ID

কোনো bucket-এ versioning চালু থাকলে (লেসন ১০.৪) একটা key-তে প্রতিবার লেখা নতুন, অনন্য একটা version ID পায়, যেমন 3HL4kqtJlcpXroDTDmJ+rmSpXd3dIbrHY, আর পুরনো version-গুলোও থেকে যায়। তখন আগের যেকোনো version পড়া বা ফিরিয়ে আনা যায়। Versioning না থাকলে object-এর version ID হয় null, আর নতুন PUT পুরনো object-কে সোজা বদলে দেয়। Versioning চালুর আগে থেকে থাকা object-গুলোর version ID-ও null থেকে যায়।

#ETag আর checksum

ETag হলো object-এর বিষয়বস্তুর একটা আঙুলের ছাপ, যেটা S3 প্রতিটা PUT, GET আর HEAD-এ ফেরত দেয়। একটা PUT-এ upload করা আর SSE-KMS দিয়ে encrypt না করা object-এর ETag হলো ডেটার MD5, তাই client নিজের hash-এর সাথে মিলিয়ে দেখতে পারে। Multipart upload-এ ETag হিসাব হয় part-গুলো থেকে, আর শেষে থাকে -N, মানে part-এর সংখ্যা; তাই এটা পুরো file-এর MD5 না। এই ক্ষেত্রে একে file-এর hash হিসেবে ব্যবহার কোরো না।

সত্যিকারের নিখুঁততা যাচাইয়ের জন্য S3 বাড়তি checksum সমর্থন করে (CRC-64/NVME, CRC-32, CRC-32C, SHA-1, SHA-256)। ২০২৪-এর শেষ থেকে AWS SDK আর CLI upload-এর সময় নিজে থেকেই একটা CRC checksum হিসাব করে, আর S3 object জমা রাখার আগে সেটা মিলিয়ে নেয়, তাই পথে কিছু নষ্ট হলে ধরা পড়ে।

#Upload: একটা PUT নাকি অনেকগুলো part

#একটা PUT, সর্বোচ্চ ৫ GB

সবচেয়ে সহজ upload হলো একটা PUT request, যার body-তে পুরো file। ছোট object-এর জন্য এটা একদম ঠিক: একটা product-এর ছবি, একটা JSON document, একটা log file। বড় file-এ এর দুটো দুর্বলতা: একটা request মানে একটাই stream, যেটা দ্রুত লাইন খুব কমই পুরোটা কাজে লাগায়; আর ৯০%-এ গিয়ে connection কেটে গেলে S3 কিছুই রাখে না, পুরো file আবার পাঠাতে হয়। তার ওপর একটা PUT-এর সীমা ৫ GB।

#Multipart upload

Multipart upload একটা object-কে কয়েকটা part-এ ভাগ করে, part-গুলো আলাদা আলাদা upload করে (সাধারণত সমান্তরালে), আর শেষে জুড়ে একটা object বানায়। Notes-এর মোটা দাগের নিয়ম: ১০০ MB-এর বেশি হলে সুপারিশ করা হয়, ৫ GB-এর বেশি হলে বাধ্যতামূলক।

1. শুরু

   Client key আর দরকারি metadata, tag আর storage class দিয়ে একটা create-multipart-upload request পাঠায়। S3 একটা upload ID ফেরত দেয়, যেটা সব part-কে এক সুতোয় বাঁধে।

2. Part-গুলো upload

   Client part-গুলো upload করে, প্রতিটার সাথে ১ থেকে ১০,০০০-এর মধ্যে একটা part number, যেকোনো ক্রমে, সমান্তরালে। S3 প্রতিটা part-এর জবাবে একটা ETag দেয়। কোনো part ব্যর্থ হলে একই number দিয়ে শুধু সেটা আবার upload করা হয়।

3. শেষ করা

   Client part number আর তাদের ETag-এর তালিকা পাঠায়। S3 part number-এর ক্রমে part-গুলো জুড়ে একটা object বানায়, আর bucket-এ সেটা দেখা যায় কেবল এখনই। Client যদি বরং upload-টা abort করে, S3 part-গুলো মুছে দেয়।

সীমাগুলো:

Multipart কেন কাজে লাগে:

• গতি: একসাথে কয়েকটা part চললে bandwidth-এর বেশি অংশ কাজে লাগে (লেসন ১০.৬ আরও এগোয়, Transfer Acceleration আর byte-range download নিয়ে)।
• টিকে থাকার ক্ষমতা: network-এ গোলমাল হলে হারায় একটা part, পুরো file না। Notes-এর পরীক্ষার কৌশল এটাই: “অনির্ভরযোগ্য network-এ upload বারবার ব্যর্থ হচ্ছে” → multipart upload, কারণ শুধু ব্যর্থ part-টাই আবার পাঠানো হয়।
• থামিয়ে আবার চালানো: যে part-গুলো upload হয়ে গেছে, complete বা abort না করা পর্যন্ত সেগুলো জমা থাকে, তাই একটা laptop কালকে বাকিটা চালাতে পারে।
• আকার না জেনেও শুরু: একটা stream, যেমন live video বা তৈরি হতে থাকা database dump, শেষ আকার জানার আগেই upload শুরু করা যায়।

এই ধাপগুলো হাতে খুব কমই call করতে হয়। aws s3 cp আর SDK-র transfer manager একটা সীমার ওপরে (CLI-তে default ৮ MB) নিজে থেকেই multipart-এ চলে যায়, আর part-এর আকারও নিজেরাই বেছে নেয়। Application-স্তরের তিনটা পথের প্রথমটাও multipart upload, লেসন ১০.১২-এ যেটা pre-signed URL আর Batch Operations-এর পাশে রাখা আছে।

#Part-এর অঙ্ক

দুটো হিসাব বারবার আসে:

• কয়টা part লাগবে? File-এর আকারকে part-এর আকার দিয়ে ভাগ করে ওপরের দিকে গোল করো। ১০০ MiB part দিয়ে ৬ GB-এর একটা backup: ৬,০০০,০০০,০০০ ÷ ১০৪,৮৫৭,৬০০ = ৫৭.২, তাই ৫৮টা part।
• সবচেয়ে ছোট কত আকারের part নেওয়া যায়? File-এর আকারকে ১০,০০০ দিয়ে ভাগ করো। ১.২ TB-এর একটা scan archive-এর part হতে হবে অন্তত ১,২০০,০০০,০০০,০০০ ÷ ১০,০০০ = ১২০,০০০,০০০ byte, প্রায় ১১৫ MiB। ১০০ MiB part নিলে লাগত ১১,৪৪৫টা part, সীমার বাইরে, তাই upload ব্যর্থ হতো।

Planner-এ দুটো হিসাবই চালিয়ে দেখো, তারপর part 3 ব্যর্থ করিয়ে তুলনা করো, একটা PUT আর একটা multipart upload-কে কতটা আবার পাঠাতে হয়।

#Upload কখনো শেষ না হলে

কোনো client multipart upload শুরু করে তারপর crash করলে, বা “complete” পাঠাতেই ভুলে গেলে, part-গুলো bucket-এ থেকে যায়। সাধারণ listing-এ বা console-এর object তালিকায় এগুলো দেখা যায় না, কিন্তু upload abort না করা পর্যন্ত এদের storage-এর টাকা দিতে হয়। অস্থির client-ওয়ালা ব্যস্ত একটা bucket-এ এটা চুপচাপ terabyte ছাড়িয়ে যেতে পারে। সমাধান হলো এমন একটা lifecycle rule, যেটা কয়েক দিন পর অসমাপ্ত multipart upload abort করে দেয় (লেসন ১০.৫)। aws s3api list-multipart-uploads দিয়ে এগুলো দেখা যায়, আর S3 Storage Lens-ও এদের হিসাব দেখায় (লেসন ১০.৭)।

#Consistency: লেখার পরে পাঠক কী দেখে

#Strong read-after-write

ডিসেম্বর ২০২০ থেকে S3 প্রতিটা object operation-এ, সব Region-এ, নিজে থেকেই আর বাড়তি কোনো খরচ ছাড়া strong read-after-write consistency দেয়:

• নতুন object-এর একটা PUT সফল হওয়ার পরে যেকোনো GET সেটা ফেরত দেয়, যেকোনো list-এ সেটা থাকে।
• একটা overwrite সফল হওয়ার পরে যেকোনো GET নতুন ডেটা দেয়, কখনো পুরনোটা না।
• একটা DELETE সফল হওয়ার পরে যেকোনো GET 404 দেয়, আর যেকোনো list থেকে সেটা বাদ পড়ে।
• Metadata (HEAD), tag আর ACL পড়াও strongly consistent।

“পরে” মানে: write সফলতা জানানোর পরে read শুরু হয়েছে। Write চলাকালীন শুরু হওয়া একটা read পুরনো বা নতুন যেকোনোটা পেতে পারে, কিন্তু কখনো দুটোর মিশেল না: একটা key-এর প্রতিটা আপডেট atomic।

#দুজন লেখক, একটা key

Strong consistency মানে কিন্তু lock না। দুজন client প্রায় একই সময়ে একই key-তে PUT করলে S3 রাখে সবচেয়ে পরের timestamp-এর request-টা (শেষ লেখকই জেতে), আর অন্য আপডেটটা কোনো error ছাড়াই হারিয়ে যায়। কয়েকটা key জুড়ে আপডেটও atomic না: S3-এ কোনো transaction নেই।

২০২৪ থেকে general purpose bucket-এ conditional write আছে:

• If-None-Match: * → লেখো শুধু যদি key এখনো না থাকে। দুজন client একসাথে orders/1001.json বানাতে গেলে একজন জেতে, অন্যজন overwrite করার বদলে পায় 412 Precondition Failed।
• If-Match: <etag> → লেখো শুধু যদি object এখনো সেই version-ই থাকে যেটা আমি পড়েছিলাম। এটা optimistic locking: পড়ো, বদলাও, ETag দিয়ে লিখে দাও, 412 পেলে আবার চেষ্টা করো।

চাইলে bucket policy দিয়ে প্রতিটা write-এ এই header বাধ্যতামূলকও করা যায়। যেখানে সত্যিকারের transaction লাগে, যেমন stock-এর হিসাব বা সিট বুকিং, সেখানে অবস্থাটা রাখো একটা database-এ (DynamoDB, RDS), আর S3-এ রাখো শুধু file।

#এখনো যা eventually consistent

• Bucket-এর configuration। Versioning চালু করা, policy বদলানো বা bucket মোছা S3-এর ভেতরে ছড়াতে একটু সময় নেয়। AWS বলে, versioning চালুর পরে যেসব object-এর version থাকতেই হবে, সেগুলো লেখার আগে প্রায় ১৫ মিনিট অপেক্ষা করো; আর মোছা bucket কিছুক্ষণ bucket-এর তালিকায় দেখা যেতে পারে।
• আরেকটা bucket-এ replication asynchronous (লেসন ১০.৪): অন্য Region-এর কপি দেখা যায় কয়েক সেকেন্ড থেকে কয়েক মিনিট পরে।

#S3-এর খরচ কোথায়

S3-এ আগাম কোনো fee নেই, সর্বনিম্ন কোনো বিলও নেই। বিলের কয়েকটা অংশ আছে, আর কোনগুলো বিনা পয়সার, পরীক্ষা সেটা জানতে চায়।

দাম বদলায়, Region-ভেদে আলাদাও হয়, তাই আসল হিসাবের জন্য AWS Pricing Calculator ব্যবহার করো। Design-এর জন্য দরকার বিলের চেহারাটা বোঝা।

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

#System design-এ S3

প্রায় প্রতিটা architecture-এ যে কাঠামো দেখা যায়: byte-গুলো রাখো S3-এ, সেগুলোর তথ্য রাখো database-এ। বিপুল সংখ্যক object রাখা আর অনেক পাঠকের কাছে পৌঁছে দেওয়ায় S3 দারুণ। কিন্তু S3 database না: object-এর ভেতরের লেখা নিয়ে query নেই, transaction নেই, আংশিক আপডেট নেই।

• ছবি বা document-এর app। App S3-এ রাখে products/shirt-42.jpg, আর DynamoDB বা RDS-এ একটা row: key, মালিক, দাম আর upload-এর সময়। পাতাগুলো database পড়ে, তারপর CloudFront হয়ে S3 থেকে ছবি আনে। User-রা pre-signed URL দিয়ে সরাসরি S3-এ upload করতে পারে, file তখন web server-এর ভেতর দিয়েই যায় না (লেসন ১০.৯ আর ১০.১২)।
• Log archive। Load balancer, CloudTrail আর application লেখে logs/app/2026/10/25/web-1.gz-এর মতো key-তে। তারিখভিত্তিক prefix থাকলে একটা দিনের log process করা সস্তা, আর lifecycle rule পুরনো log Glacier-এ পাঠায়। ব্যাংকের auditor Object Lock যোগ করতে পারেন, যাতে log বদলানো না যায় (লেসন ১০.৯)।
• Data lake। কাঁচা ডেটা নামে raw/-এ, পরিষ্কার করা ডেটা clean/-এ, query-র জন্য তৈরি file curated/-এ, অনেক সময় key-এর ভেতরেই ভাগ করা থাকে (trips/year=2026/month=10/day=25/)। Athena, Spark আর Redshift Spectrum সরাসরি S3 থেকে পড়ে, তাই storage আর compute আলাদাভাবে বাড়ে।
• Key-এর নকশা। ডেটা ঢোকানোর আগেই key-এর বিন্যাস ঠিক করো: নাম বদলানোর উপায় নেই, lifecycle rule আর permission চলে prefix ধরে, আর request-এর হার বাড়ে prefix ধরে (লেসন ১০.৬)। Key-এ গোপন বা ব্যক্তিগত তথ্য রেখো না; log আর URL-এ এগুলো দেখা যায়।
• বড় upload। Client বড় file পাঠায় multipart upload দিয়ে, পারলে সরাসরি S3-এ, আর একটা lifecycle rule পরিত্যক্ত upload সাফ করে।

#পরীক্ষার চেনা ছক

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

এই command-গুলো AWS CLI v2 দিয়ে, এমন একটা profile-এ চালাও যার S3 ব্যবহারের অনুমতি আছে। Bucket-এর নাম নিজের মতো বদলে নিও; এখানকার -example নামগুলো শুধু উদাহরণ।

মুম্বাইতে একটা bucket বানাও, আর সেটা কোথায় আছে দেখো:

# us-east-1-এর বাইরে Region-টা LocationConstraint হিসেবে আবার দিতে হয়
aws s3api create-bucket --bucket dhaka-shop-photos-example \
  --region ap-south-1 \
  --create-bucket-configuration LocationConstraint=ap-south-1

aws s3api get-bucket-location --bucket dhaka-shop-photos-example

# একই কাজ, নিজের account regional namespace-এ (এই নামের মালিক শুধু তোমার account-ই হতে পারবে)
aws s3api create-bucket --bucket shop-photos-111122223333-ap-south-1-an \
  --bucket-namespace account-regional \
  --region ap-south-1 \
  --create-bucket-configuration LocationConstraint=ap-south-1

Content type, user metadata আর tag দিয়ে একটা object upload করো, তারপর download না করেই তার metadata পড়ো:

aws s3api put-object --bucket dhaka-shop-photos-example \
  --key photos/2026/eid/cake.jpg --body cake.jpg \
  --content-type image/jpeg \
  --metadata photographer=rahim,shoot=eid-2026 \
  --tagging 'team=catalog&status=live'

aws s3api head-object --bucket dhaka-shop-photos-example --key photos/2026/eid/cake.jpg
aws s3api get-object-tagging --bucket dhaka-shop-photos-example --key photos/2026/eid/cake.jpg

Key-এর সমতল তালিকা দেখো, আর console যে folder আঁকত সেগুলোও:

aws s3 ls s3://dhaka-shop-photos-example/ --recursive        # সব key, কোনো folder নেই
aws s3 ls s3://dhaka-shop-photos-example/photos/             # PRE 2026/ = একটা common prefix
aws s3api list-objects-v2 --bucket dhaka-shop-photos-example \
  --prefix photos/ --delimiter /                             # JSON-এ CommonPrefixes

Metadata বদলাও (সম্পাদনার উপায় নেই: object-টাকে নিজের ওপর copy করো) আর tag বদলাও (জায়গায় বসেই):

aws s3api copy-object --bucket dhaka-shop-photos-example \
  --key photos/2026/eid/cake.jpg \
  --copy-source dhaka-shop-photos-example/photos/2026/eid/cake.jpg \
  --metadata-directive REPLACE \
  --content-type image/jpeg --metadata photographer=karim

aws s3api put-object-tagging --bucket dhaka-shop-photos-example \
  --key photos/2026/eid/cake.jpg \
  --tagging 'TagSet=[{Key=team,Value=catalog},{Key=status,Value=archived}]'

হাতে হাতে একটা multipart upload, আর পরিষ্কারের command:

aws s3api create-multipart-upload --bucket dhaka-shop-photos-example \
  --key backups/db-2026-10-25.sql.gz                    # একটা UploadId ফেরত দেয়

aws s3api upload-part --bucket dhaka-shop-photos-example \
  --key backups/db-2026-10-25.sql.gz --part-number 1 \
  --body part-001 --upload-id "$UPLOAD_ID"               # part-এর ETag ফেরত দেয়

aws s3api complete-multipart-upload --bucket dhaka-shop-photos-example \
  --key backups/db-2026-10-25.sql.gz --upload-id "$UPLOAD_ID" \
  --multipart-upload file://parts.json                   # {"Parts":[{"PartNumber":1,"ETag":"..."}]}

aws s3api list-multipart-uploads --bucket dhaka-shop-photos-example   # পরিত্যক্তগুলো খুঁজে বের করো
aws s3api abort-multipart-upload --bucket dhaka-shop-photos-example \
  --key backups/db-2026-10-25.sql.gz --upload-id "$UPLOAD_ID"

উঁচু স্তরের command এর সবটা তোমার হয়ে, সমান্তরালে করে দেয়, আর কখন multipart-এ যাবে সেটাও ঠিক করে দেওয়া যায়:

aws configure set default.s3.multipart_threshold 64MB
aws configure set default.s3.multipart_chunksize 16MB
aws s3 cp ./db-2026-10-25.sql.gz s3://dhaka-shop-photos-example/backups/

Key না থাকলে তবেই object বানাও (একটা conditional write):

aws s3api put-object --bucket dhaka-shop-photos-example \
  --key orders/1001.json --body 1001.json --if-none-match '*'
# দুবার চালাও: দ্বিতীয়বার 412 Precondition Failed দিয়ে ব্যর্থ হবে

কাজ শেষে পরিষ্কার করো (আগে খালি, তারপর মোছা; মনে রেখো, মোছা নাম অন্য কেউ নিয়ে নিতে পারে):

aws s3 rm s3://dhaka-shop-photos-example --recursive
aws s3api delete-bucket --bucket dhaka-shop-photos-example --region ap-south-1

#সারসংক্ষেপ

মূল কথা

• S3 হলো object storage: HTTP দিয়ে পুরো পুরো object, আগে থেকে জায়গা ঠিক করার ঝামেলা নেই, এগারোটা নয়ের durability। Media, backup, archive, log, data lake, download আর static site-এর জন্য।
• Bucket থাকে একটা Region-এ, কিন্তু তার নাম partition-এর সব account আর Region মিলিয়ে অনন্য। Console দেখতে global; bucket আসলে regional। নাম আর Region বদলানো যায় না।
• নামের নিয়ম: ৩–৬৩ অক্ষর, ছোট হাতের অক্ষর, সংখ্যা, dot আর hyphen, শুরু আর শেষ অক্ষর বা সংখ্যায়, .. না, IP address না, xn-- / sthree- / amzn-s3-demo- prefix না, -s3alias / --ol-s3 / .mrap / --x-s3 / --table-s3 suffix না। বড় হাতের অক্ষর বা underscore = ভুল option। Dot এড়িয়ে চলো।
• Account regional namespace (২০২৬): -<account>-<region>-an দিয়ে শেষ হওয়া নাম, যেটা শুধু তোমার account-ই কখনো বানাতে পারে। Code এখনো যে bucket ব্যবহার করে, সেটা মুছো না।
• একটা object = key + ডেটা + metadata + tag (+ version ID)। Key মানে পুরো নাম, সর্বোচ্চ ১,০২৪ byte, বড়-ছোট হাতের অক্ষর আলাদা। Folder নেই: prefix আর / delimiter; Create folder বানায় শূন্য byte-এর object; নাম বদলানোর উপায় নেই।
• আকার: object ০ B থেকে ৫০ TB (পুরনো সংখ্যা ৫ TB); একটা PUT ≤ ৫ GB; multipart ১০০ MB-এর ওপরে সুপারিশ, ৫ GB-এর ওপরে বাধ্যতামূলক; ৫ MiB–৫ GiB-এর ১০,০০০টা part। Part-এর আকার ≥ file ÷ ১০,০০০।
• Multipart = সমান্তরালে গতি, শুধু ব্যর্থ part আবার পাঠানো, পরে আবার চালু। অসমাপ্ত upload abort করো বা lifecycle দিয়ে সাফ করো, কারণ তাদের part-এর টাকা লাগে।
• System metadata (S3-এর), user metadata (x-amz-meta-*, ২ KB, upload-এই স্থির; বদলানো = copy), tag (১০টা জোড়া, বদলানো যায়, policy আর lifecycle ব্যবহার করে), version ID (versioning ছাড়া null)। এক part-এর ETag = MD5; multipart-এর ETag শেষ হয় -N দিয়ে।
• ডিসেম্বর ২০২০ থেকে PUT, overwrite, DELETE আর list-এ strong read-after-write consistency; lock ছাড়া শেষ লেখকই জেতে; conditional write (If-None-Match, If-Match) আপডেট হারানো আটকায়; bucket-এর configuration eventually consistent।
• খরচ: storage GB-month, request, বাইরে যাওয়া ডেটা, retrieval আর management feature। ভেতরে আসা ডেটা বিনা পয়সার, CloudFront-এ বা একই Region-এর service-এ পাঠানোও বিনা পয়সার।

নিজেকে যাচাই করো: Bucket, Object আর Key৩১টি প্রশ্ন