S3-তে পৌঁছানোর পথ (৩/৩): Multipart, Pre-signed URL আর Batch Operations

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

• তোমার নিজের application-এর ভেতর থেকে শুরু হওয়া তিনটা পথ আলাদা করে চিনতে: multipart upload, pre-signed URL আর S3 Batch Operations, আর কোনটা কোন সমস্যার সমাধান সেটা বলতে।
• একটা multipart upload-এর প্রতিটা call ধাপে ধাপে বোঝাতে, সীমার মধ্যে থেকে part-এর আকার আর সংখ্যা হিসাব করতে, আর ফেলে রাখা upload যেন টাকা না খায় তার ব্যবস্থা করতে।
• একটা pre-signed URL কার অনুমতি নিয়ে চলে, কোন ধরনের credential-এ সেটা কতদিন বাঁচে, আর মেয়াদের আগেই কেন মরে যায় সেটা ব্যাখ্যা করতে; এমন একটা browser upload design করতে, যেটা তোমার server ছুঁয়েও যায় না।
• Manifest, operation, IAM role আর report দিয়ে একটা Batch Operations job বানাতে, আর কিছু ব্যর্থতা নিয়ে শেষ হওয়া job সামলাতে।
• Data কোথা থেকে শুরু, কতটা, কত ঘনঘন যায় আর কোনটা সবচেয়ে জরুরি, তা দেখে ১৩টা পথের মধ্যে বেছে নিতে, আর পরীক্ষার শব্দ দেখেই প্রতিটা পথ চিনে ফেলতে।

#তোমার application থেকে শুরু হওয়া তিনটা পথ

#১৩টা পথের মধ্যে ১১–১৩ কোথায় বসে

S3-এ data ঢোকার, বের হওয়ার বা S3-এর ভেতরেই চলাফেরার সব উপায় এক জায়গায় জড়ো করার তিনটা লেসনের এটা শেষটা, যাতে এগুলো আর গুলিয়ে না যায়:

• পথ ১–৫ (লেসন ১০.১০) হলো network-এর রাস্তা: একটা VPC বা data centre থেকে packet কীভাবে private ভাবে S3-এ পৌঁছায়। Gateway endpoint, interface endpoint, VPC Peering, Transit Gateway, আর Site-to-Site VPN বা Direct Connect।
• পথ ৬–১০ (লেসন ১০.১১) হলো transfer service: যে tool-গুলো তোমার হয়ে বিপুল data সরায়। S3 File Gateway, DataSync, Snowball, Transfer Acceleration আর Transfer Family।
• পথ ১১–১৩ (এই লেসন) হলো তোমার নিজের code S3 API দিয়ে যা করে। কিছু deploy করতে হয় না, network-ও বদলাতে হয় না:
  • ১১. Multipart upload: একটা বড় object কীভাবে টুকরো টুকরো হয়ে ঢোকে।
  • ১২. Pre-signed URL: AWS credential নেই এমন কেউ কীভাবে একটা object ঢোকায় বা বের করে।
  • ১৩. S3 Batch Operations: আগে থেকেই S3-এ থাকা লাখ লাখ object কীভাবে একবারে বদলানো হয়।

তিনটা আসলে তিনটা আলাদা প্রশ্নের উত্তর, আর পরীক্ষাও এদের আলাদা করে শব্দ দিয়ে: "বড় ফাইল, অনির্ভরযোগ্য network" মানে ১১, "user সরাসরি browser থেকে upload করে" মানে ১২, "লাখ লাখ পুরোনো object" মানে ১৩। বাকি দশটার সাথে এরা মিলেমিশেও চলে: একটা multipart upload gateway endpoint দিয়ে যেতে পারে, তার প্রতিটা part pre-sign করা যায়, আর তার traffic accelerate-ও করা যায়।

এর কিছু অংশ এই chapter-এর অন্য লেসনে অন্য দিক থেকে শেখানো হয়েছে: গতির দিক থেকে multipart ১০.৬-এ, bucket-এর tool হিসেবে Batch Operations ১০.৭-এ, নিরাপত্তার নিয়ন্ত্রণ হিসেবে pre-signed URL ১০.৯-এ। এই লেসনটা নিজেই সম্পূর্ণ, "পথ"-এর চোখে দেখা: bytes কোথা থেকে শুরু, কে পাঠায়, আর অন্য পথ বাদ দিয়ে এটা কেন বাছবে।

#পথ ১১: multipart upload

#Multipart: জিনিসটা কী, আর কেন লাগে

সাধারণ upload মানে একটা PutObject request: একটা HTTP request-এ পুরো object। বড় ফাইলের বেলায় এর দুটো কঠিন সমস্যা আছে:

1. আকারের সীমা। একটা PUT সর্বোচ্চ ৫ GB বইতে পারে।
2. হয় সব, নয় কিছুই না। ৪ GB-র upload ৯৫%-এ গিয়ে সংযোগ কেটে গেলে request ব্যর্থ, আবার শূন্য থেকে শুরু। ফোনে বা মহাদেশ পেরোনো লম্বা লাইনে বড় একটা single request হয়তো কোনোদিন শেষই হবে না।

Multipart upload একটা object-কে কয়েকটা part-এ ভাগ করে; part-গুলো আলাদা আলাদা, যেকোনো ক্রমে, একসাথে upload হয়, তারপর S3 সেগুলো জুড়ে একটা object বানায়। কোনো part ব্যর্থ হলে শুধু সেটাই আবার যায়। Owner-এর notes নিয়মটা সহজ করে বলেছে, AWS-ও তাই বলে: মোটামুটি ১০০ MB থেকে multipart-এর কথা ভাবো, আর ৫ GB-র বেশি হলে এটা বাধ্যতামূলক। পরীক্ষায় S3-এর সবচেয়ে বড় object ৫ TB (২০২৫-এর বদলটা নিচের পাশের কথায় দেখো)।

#ধাপে ধাপে কীভাবে চলে

1. ১. CreateMultipartUpload

   তুমি S3-কে bucket, key আর object-এর setting (storage class, encryption, metadata, tag) জানাও। S3 একটা UploadId ফেরত দেয়, পরের প্রতিটা call-এ যেটা উল্লেখ করতেই হবে।

2. ২. UploadPart, বহুবার, একসাথে

   প্রতিটা request-এ থাকে একটা part, সাথে ১ থেকে ১০,০০০-এর মধ্যে একটা part number। S3 part-টা রেখে তার ETag ফেরত দেয়; তোমার code part number আর ETag-এর একটা তালিকা রাখে। Part যেকোনো ক্রমে আসতে পারে, কয়েকটা thread থেকে, এমনকি কয়েকটা machine থেকেও। একই part number আবার upload করলে আগের part-টা স্রেফ বদলে যায়; retry এভাবেই কাজ করে।

3. ৩. CompleteMultipartUpload

   তুমি part number আর তাদের ETag-এর তালিকা পাঠাও। S3 part number-এর ক্রমে part-গুলো জোড়া দেয়, আর object হাজির হয় atomically: এই call-এর আগে কেউ সেটা পড়তে পারে না, পরে সবাই পারে। Object-এর ETag-এর শেষে থাকে -N, মানে part-এর সংখ্যা; এজন্যই multipart object-এর ETag ফাইলের MD5 না।

4. অথবা: AbortMultipartUpload

   হাল ছেড়ে দিলে UploadId দিয়ে abort করো। S3 রাখা part-গুলো মুছে দেয়, ওগুলোর টাকাও আর লাগে না। ListParts একটা upload-এর part দেখায়, আর ListMultipartUploads দেখায় bucket-এ চলমান সব upload।

এই call-গুলো সাধারণত হাতে লিখতে হয় না। AWS CLI (aws s3 cp) আর SDK-গুলোর transfer manager একটা সীমার ওপরে নিজে থেকেই multipart-এ চলে যায় (CLI-তে default ৮ MB), part-এর আকার বেছে নেয়, একসাথে কয়েকটা part চালায় (CLI-তে default ১০টা) আর ব্যর্থ part আবার পাঠায়।

#Part-এর সীমা আর হিসাব

১০,০০০ part-এর সীমাটাই ঠিক করে দেয়, একটা object-এর জন্য সবচেয়ে ছোট কত আকারের part নেওয়া যাবে:

• ৮ GB-র একটা video, ৮ MiB-র part: ৮,১৯২ MiB ÷ ৮ MiB = ১,০২৪টা part। কোনো সমস্যা নেই।
• ১০০ GiB-র একটা database dump ৫ MiB-র সর্বনিম্ন আকারে ভাঙলে লাগবে ২০,৪৮০টা part, সীমার অনেক বেশি। Part হতে হবে অন্তত ১০০ GiB ÷ ১০,০০০ ≈ ১০.২৪ MiB, তাই তুমি নেবে ১৬ MiB (৬,৪০০টা part)।
• ১ TiB-র ফাইলে part লাগবে অন্তত ১,০৪৮,৫৭৬ MiB ÷ ১০,০০০ ≈ ১০৫ MiB।

ফাইল ১০,০০০ part ছাড়িয়ে যাবে মনে হলে CLI আর SDK নিজেই part-এর আকার বাড়িয়ে নেয়; তোমার নিজের code-কেও সেটা করতে হবে।

#একটা part আবার পাঠানো, আর একসাথে পাঠানোর গতি

একই design থেকে দুটো আলাদা লাভ আসে:

• টিকে থাকার ক্ষমতা। সংযোগ কাটলে ক্ষতি একটা part-এর, পুরো object-এর না। নড়বড়ে mobile লাইনে ১৬ MiB-র part হলে একবার কাটলে বড়জোর ১৬ MiB নষ্ট। Owner-এর পরীক্ষার কৌশলটা এটাই: "network সমস্যায় upload ব্যর্থ হয়" → multipart, যাতে শুধু ব্যর্থ part আবার upload হয়। Upload কয়েক দিন থামিয়ে রেখে আবার চালানোও যায়, কারণ complete বা abort না করা পর্যন্ত রাখা part-গুলো S3-এ অপেক্ষা করে।
• গতি। একটা TCP stream দ্রুত লাইনকে খুব কমই পুরোটা কাজে লাগাতে পারে, বিশেষ করে দূরত্ব বেশি হলে। একসাথে দশটা part চললে লাইন অনেক ভালোভাবে ভরে। লেসন ১০.৬ এই দিকটা দেখায়, সাথে byte-range fetch, যেটা download-এর বেলায় একই কৌশল খাটায়।

Part ছোট হলে retry সস্তা, কিন্তু request বেশি (প্রতিটা part বিলে একটা PUT request); part বড় হলে request কম, কিন্তু আবার পাঠাতে হয় বেশি। ৮ থেকে ১০০ MiB-এর মধ্যে নেওয়াটা চলতি পছন্দ।

#ফেলে রাখা upload-ও টাকা খায়

যে upload কখনো complete বা abort হয়নি, তার part-গুলো তোমার বাছা storage class-এ রাখা থাকে আর বিল হয়, কিন্তু সেগুলো object না: bucket-এর তালিকায় আসে না, console-এর object list ফাঁকা দেখায়। যে mobile app দিনে হাজারটা upload হারায়, সে চুপচাপ কয়েক terabyte চোখে-না-পড়া, বিল-হওয়া part জমিয়ে ফেলে।

সমাধান: যে bucket-এ multipart upload আসে, তার প্রতিটায় একটা lifecycle rule: upload শুরু হওয়ার কয়েক দিন পরে (৭ দিন চলতি) AbortIncompleteMultipartUpload। তখন S3 বাসি upload-গুলো abort করে তাদের part মুছে দেয়। Lifecycle rule শেখানো হয়েছে লেসন ১০.৫-এ; কোন bucket-এ অসমাপ্ত upload-এর কত byte আছে, S3 Storage Lens (১০.৭) তা দেখায়।

#অন্য উপায় বাদ দিয়ে কেন multipart

#পথ ১২: pre-signed URL

#Pre-signed URL: জিনিসটা কী, আর কেন লাগে

তোমার bucket private, যেমনটা হওয়া উচিত। এখন একজন customer-কে একটা invoice download করতে হবে, বা একজন seller-কে পণ্যের একটা ছবি upload করতে হবে। কারও AWS credential নেই, আর তুমি bucket public করতে বা প্রতিটা customer-এর জন্য একটা IAM user বানাতে চাও না।

Pre-signed URL হলো একটা সাধারণ S3 URL, যার query string-এ একটা signature থাকে। যার অনুমতি আছে (তোমার backend), সে একটা object, একটা method, একটা নির্দিষ্ট সময় পর্যন্ত-এর জন্য একটা request সই করে দেয়; তারপর URL যার হাতে থাকবে, সে মেয়াদ শেষ হওয়া পর্যন্ত AWS credential ছাড়াই ঠিক ওই request-টা করতে পারবে। একটা অনুমতির চিরকুটের মতো: "এই চিরকুটের বাহক ১০:০৫ পর্যন্ত sellers/42/photo.jpg PUT করতে পারবে, স্বাক্ষর: shop-এর backend।"

#Pre-signed GET আর PUT

• GET (download): "login করা এই student-কে এক ঘণ্টা এই paid video দেখতে দাও", "এই customer-কে এই invoice নামাতে দাও"। URL-টা browser-এ, একটা <img> tag-এ বা video player-এ বসিয়ে দেওয়া যায়।
• PUT (upload): "এই seller-কে ঠিক এই key-তে একটা ছবি upload করতে দাও"। Browser ফাইলটা একটা HTTP PUT-এর body-তে পাঠায়। একই key-র object আগে থাকলে সেটা বদলে যায়, তাই key ঠিক করুক backend, প্রতি upload-এ আলাদা (একটা UUID)।
• অন্য method-ও সই করা যায় (metadata পড়তে HEAD, multipart upload-এর প্রতিটা part-এর জন্য UploadPart, DELETE)।

Pre-signed URL বানানো যায় S3 console থেকে (object share), AWS CLI থেকে (aws s3 presign, যেটা শুধু GET সই করে) আর SDK থেকে (যেকোনো method, PUT সহ)। বানানোটা স্থানীয় একটা হিসাব: SDK signer-এর secret key দিয়ে একটা HMAC বের করে, AWS-এ কোনো call যায় না। এজন্যই এমন object-এর URL-ও "সফলভাবে" বানানো যায় যেটা নেই, বা এমন credential দিয়েও, যার অনুমতিই নেই। ভুলটা ধরা পড়ে শুধু URL ব্যবহার করার সময়।

#URL কার অনুমতি নিয়ে চলে

Pre-signed request এলে S3 সেটাকে signer-এর করা request হিসেবে দেখে, signer-এর ওই মুহূর্তের অনুমতি দিয়ে। Owner-এর notes-ও তাই বলে: user URL-এর নির্মাতার অনুমতি পায়। এর তিনটা ফল:

1. কাজটা করার অনুমতি signer-এর থাকতে হবে। যে backend role-এর ওই key-তে s3:PutObject নেই, সে যত URL সই করবে সব 403 দিয়ে ব্যর্থ হবে।
2. Signer-কে বাতিল করলে URL-ও বাতিল। অনুমতি সরিয়ে নাও, IAM user-এর access key মুছে দাও বা নিষ্ক্রিয় করো, বা role-এর session শেষ হতে দাও: তার সই করা প্রতিটা URL কাজ করা বন্ধ করবে, নিজের মেয়াদ শেষ হওয়ার আগেই।
3. এটা একটা bearer token। URL যে পাবে সে-ই ব্যবহার করতে পারবে, যতবার খুশি, মেয়াদ শেষ হওয়া পর্যন্ত। Password-এর মতো আগলে রাখো: ছোট মেয়াদ, শুধু HTTPS, কখনো log-এ না।

Block Public Access pre-signed URL-এ কোনো প্রভাব ফেলে না, কারণ request-টা সই করা: S3 দেখে signer-এর একটা authenticated request, অচেনা কারও না। তবে bucket policy দিয়ে এগুলোকেও বাঁধা যায়, যেমন s3:signatureAge খুব পুরোনো হলে deny, বা request তোমার network থেকে না এলে deny (aws:SourceIp, বা endpoint হয়ে এলে aws:SourceVpce)।

#একটা URL কতদিন বাঁচে

S3 মেয়াদ দেখে request শুরু হওয়ার সময়। মেয়াদ শেষের এক সেকেন্ড আগে শুরু হওয়া ২ GB-র download শেষ হবেই; কিন্তু সংযোগ কেটে গিয়ে player মেয়াদের পরে আবার জুড়তে চাইলে ব্যর্থ হবে।

#Browser থেকে সরাসরি S3-এ upload

যেকোনো ছবি, document বা video-র site এই কাঠামোটাই ব্যবহার করে:

1. Browser তোমার backend-এর কাছে একটা upload URL চায়, পাঠায় শুধু ফাইলের নাম, ধরন আর আকার।
2. Backend user-কে যাচাই করে, key ঠিক করে (sellers/42/2f1c….jpg), কয়েক মিনিটের জন্য একটা PUT URL সই করে ফেরত দেয়।
3. Browser ওই URL দিয়ে ফাইলটা সরাসরি S3-এ পাঠায়। এজন্য bucket-এ এমন একটা CORS rule লাগে, যেটা তোমার site-এর origin থেকে PUT allow করে (লেসন ১০.৩)।
4. S3 object-টা রাখে; একটা S3 event (লেসন ১০.৭) thumbnail বা virus scan শুরু করে।

তোমার server ফাইলের বদলে বয় কয়েকশো byte-এর JSON। Upload-এর জন্য তার আর bandwidth, memory বা সময় লাগে না, আর যত ভিড়ই হোক S3 সামলে নেয়। বড় ফাইলের জন্য পথ ১১-র সাথে মেলাও: backend multipart upload শুরু করে, প্রতিটা UploadPart pre-sign করে, আর browser ETag-গুলো জানালে complete করে।

#Pre-signed POST: নিয়ম বেঁধে দেওয়া একটা HTML form

Pre-signed PUT URL key আর method বেঁধে দেয়, কিন্তু "সর্বোচ্চ ১০ MB" বা "শুধু ছবি" বলতে পারে না। এর জন্য S3 দেয় pre-signed POST: backend শর্তসহ একটা policy document সই করে, আর browser একটা সাধারণ HTML form (multipart/form-data) দিয়ে upload করে। চলতি শর্তগুলো:

• content-length-range ১ byte থেকে ১০ MB;
• key শুরু হতে হবে sellers/42/ দিয়ে;
• Content-Type শুরু হতে হবে image/ দিয়ে;
• policy-র একটা মেয়াদ।

কোনো শর্ত ভাঙলে S3 upload-টা রাখার আগেই ফিরিয়ে দেয়। যারা upload করবে তাদের ভরসা করা না গেলে, আর আকার ও ধরন বেঁধে দিতে হলে POST নাও; ফাইলটা তোমার নিজের app-এর code নিয়ন্ত্রণ করলে PUT সহজ।

#অন্য উপায় বাদ দিয়ে কেন pre-signed URL

#পথ ১৩: S3 Batch Operations

#Batch Operations: জিনিসটা কী, আর কেন লাগে

পথ ১–১২ data S3-এ ঢোকায় (বা বের করে)। পথ ১৩ কাজ করে আগে থেকেই সেখানে থাকা data নিয়ে। আজ হোক কাল হোক, প্রতিটা বড় bucket-এ একটা বদল প্রতিটা object-এ বসাতে হয়: খরচ ভাগ করার জন্য নতুন tag, বছর বছর আগে লেখা object-এ encryption, নতুন account-এ copy, Glacier থেকে restore, প্রতিটা ফাইলে নিজের কোনো কাজ।

একটা script লেখা যায়: bucket-এর তালিকা নাও, key ধরে ধরে loop চালাও, API ডাকো, throttling সামলাও, ব্যর্থগুলো আবার চেষ্টা করো, laptop ঘুমিয়ে পড়লে কোথায় থেমেছিলে মনে রাখো, শেষে কী কী ব্যর্থ হলো তার তালিকা বানাও। ৩০ কোটি object-এর বেলায় এমন script কয়েক দিন চলে, আর নানা অদ্ভুত উপায়ে ভাঙে। S3 Batch Operations একই কাজ করে একটা managed service হিসেবে: একটা request দিয়ে একটা job শুরু, যেটা একটা তালিকার প্রতিটা object-এ একটা operation চালায়, retry, অগ্রগতির হিসাব, notification আর একটা completion report সহ। Owner-এর পরীক্ষার কৌশল: "লাখ লাখ পুরোনো object-এর ওপর একটা কাজ করো", "শত কোটি ফাইলের tag বদলাও" → Batch Operations, নিজের script বা Lambda-র loop না।

#Job-এর চার অংশ: manifest, operation, role, report

একটা job-এর মূল অংশ চারটা:

1. Manifest: object-এর তালিকা। তিনভাবে দেওয়া যায়:
   • একটা S3 Inventory report (CSV, তার manifest.json দিয়ে); Inventory প্রতিদিন বা প্রতি সপ্তাহে সব object-এর তালিকা লেখে, আর Athena (chapter ১৭) দিয়ে query করে ছেঁকে নেওয়া যায়, যেমন "encryption ছাড়া ১ MB-র বড় সব object";
   • তোমার লেখা একটা CSV ফাইল: প্রতি লাইনে bucket,key বা bucket,key,versionId, key URL-encoded;
   • একটা বানিয়ে নেওয়া তালিকা: job নিজেই filter (prefix বা suffix, তৈরির তারিখ, আকার, storage class, encryption-এর ধরন) দিয়ে তালিকা বানায়, চাইলে manifest হিসেবে রেখেও দেয়।
2. Operation: প্রতি job-এ ঠিক একটা, তার parameter সহ (tag-এর set, গন্তব্য bucket, restore-এর tier…)।
3. IAM role: job চলে এই role হিসেবে। Role-টা batchoperations.s3.amazonaws.com-কে বিশ্বাস করে, আর তার লাগে operation-এর অনুমতি (copy হলে: উৎসে পড়া, গন্তব্যে লেখা), সাথে manifest পড়ার আর report bucket-এ লেখার অনুমতি।
4. Completion report (ঐচ্ছিক, তবে নেওয়াই ভালো): তোমার বাছা bucket-এ লেখা হয়, সব task-এর বা শুধু ব্যর্থ task-এর, প্রতিটা key-র অবস্থা আর error code সহ।

সাথে একটা priority (Region-এ তোমার job-গুলোর মধ্যে বড় সংখ্যা আগে চলে), আর console-এ বানানো job-এর জন্য একটা confirmation ধাপ: তুমি confirm না করা পর্যন্ত job Suspended-এ অপেক্ষা করে।

#কোন কোন operation চালানো যায়

#Job-এর জীবনচক্র, retry আর আংশিক ব্যর্থতা

একটা job চলে New → Preparing → (Suspended →) Ready → Active → Complete পথে, অথবা শেষ হয় Cancelled বা Failed-এ। বেশি priority-র job এলে কম priority-রটা থেমে যেতে পারে।

• Task ব্যর্থ হয় আলাদা আলাদা। Inventory নেওয়ার পরে মুছে ফেলা object, copy-তে ৫ GB-র বড় object, role যে KMS key ব্যবহার করতে পারে না: প্রতিটা একটা ব্যর্থ task, report-এ লেখা থাকে, আর job এগিয়ে যায়। Throttling-এর মতো সাময়িক error নিজে থেকেই আবার চেষ্টা হয়।
• পুরো job ব্যর্থ হয় শুধু তখন, যখন অন্তত ১,০০০টা task চলার পরে ৫০%-এর বেশি ব্যর্থ হয়। সাধারণত এর মানে ভুল role, ভুল bucket বা ভুল manifest, আর আগেভাগে থেমে যাওয়ায় তোমার টাকা বাঁচে।
• Snapshot না। Job প্রতিটা key-র কাছে পৌঁছে তখনকার সর্বশেষ version-এ কাজ করে। লম্বা job চলার সময় object বদলাতে পারলে manifest-এ version ID দাও।
• ব্যর্থতা ঠিক করা। Report-এ প্রতিটা ব্যর্থ key তার error সহ থাকে। ওই তালিকাটাই আরেকটা ছোট job-এর manifest করে দাও।
• খরচ। Job-প্রতি প্রায় $0.25, আর প্রতি ১০ লাখ object-এ $1.00, তার ওপর operation-এর সাধারণ request-এর charge (আর function ডাকলে Lambda-র charge)। ৩০ কোটি object ≈ $300, সাথে request।

#অন্য উপায় বাদ দিয়ে কেন Batch Operations

#তিনটা পাশাপাশি

#১৩টা পথের মধ্যে বেছে নেওয়া

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

টেবিলটা বাঁ থেকে ডানে প্রশ্ন হিসেবে পড়ো: data কোথায়, তাকে কি private থাকতেই হবে, কতটা আর কত ঘনঘন, আর অন্য প্রান্তে কে কোন protocol বোঝে। পথ ১–১০ বিস্তারিত শেখানো হয়েছে লেসন ১০.১০ আর ১০.১১-এ; chapter ১২ (hybrid storage), ২২ (advanced networking) আর ২৩ (migration) আরও গভীরে যায়।

#১৩ পথের chooser

#যে শব্দ দেখলেই উত্তর বোঝা যায়

• "NAT ছাড়া private subnet থেকে", "internet না ছুঁয়ে", একই Region, সবচেয়ে সস্তা → gateway endpoint (১)।
• "Direct Connect দিয়ে on-premises থেকে private ভাবে", "S3-এর জন্য private IP" → VPN / Direct Connect (৫)-এর পেছনে interface endpoint (২)।
• "অনেক VPC একটাই endpoint শেয়ার করবে" → hub VPC-তে interface endpoint + Transit Gateway (৪), দুটো VPC হলে peering (৩)।
• "Application-গুলোকে NFS বা SMB share-ই ব্যবহার করে যেতে হবে" → S3 File Gateway (৬)।
• "File server online-এ migrate", "schedule করা copy", "permission আর timestamp রেখে" → DataSync (৭)।
• "Petabyte", "কম bandwidth", "কয়েক সপ্তাহ লাগবে", "সংযোগ নেই" → Snowball (৮)।
• "সারা বিশ্বের user একটা bucket-এ ধীরে upload করে" → Transfer Acceleration (৯)।
• "Partner SFTP ব্যবহার করে", "AS2", "client বদলাতে পারবে না" → Transfer Family (১০)।
• "বড় ফাইল", "network ছিন্ন হয়", "৫ GB-র বেশি" → multipart upload (১১)।
• "User সরাসরি browser থেকে upload করবে", "private object-এ সাময়িক access" → pre-signed URL (১২)।
• "লাখ লাখ পুরোনো object", "একসাথে retag / re-encrypt / restore" → Batch Operations (১৩)।

#System design-এ পথ ১১–১৩

• User-এর ফাইল কখনো তোমার app server দিয়ে বইয়ো না। Browser → pre-signed URL → S3 → event → processing, এটাই upload-এর চেনা pipeline। Upload-এর bandwidth তোমার scaling-এর মাথাব্যথা থেকে বের হয়ে যায়, আর bucket private থাকে।
• একটা পথ না, কয়েকটা মিলিয়ে নাও। সারা বিশ্বের একটা video app Transfer Acceleration (৯)-এর সাথে pre-signed multipart part (১২ + ১১) ব্যবহার করে; private subnet-এর একটা backend নিজের multipart upload gateway endpoint দিয়ে পাঠায় (১১ + ১)।
• প্রতিটা upload bucket-এ একটা abort rule রাখো। এর কোনো খরচ নেই, আর চুপচাপ বাড়তে থাকা বিল আটকায়।
• Pre-signed URL ছোট রাখো আর দরকারের মুহূর্তে সই করো, সবচেয়ে সরু অনুমতির একটা role দিয়ে (শুধু uploads/*-এ s3:PutObject), আর স্পর্শকাতর data-র জন্য bucket policy-তে s3:signatureAge বা network-এর শর্ত যোগ করো।
• একসাথে বদল script দিয়ে না, job হিসেবে ভাবো। দরকার পড়ার আগেই S3 Inventory চালু রাখো; Athena দিয়ে ছেঁকে নাও; report সহ Batch Operations চালাও; ব্যর্থ তালিকা আবার চালাও। আগে একটা ছোট manifest-এ পরীক্ষা করো; console-এ confirmation ধাপটাই তোমার শেষ সুযোগ।
• লম্বা job চলার সময় object বদলাতে পারলে manifest-এ version ID দাও।

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

হাতে হাতে multipart (aws s3 cp দিয়ে CLI এটা নিজেই করে):

# 0. Make a 40 MB test file and split it into 8 MiB parts (the last part is smaller)
dd if=/dev/urandom of=big.bin bs=1M count=40
split -b 8M big.bin part-

# 1. Start the upload and keep the UploadId
UPLOAD_ID=$(aws s3api create-multipart-upload --bucket uploads-example \
  --key videos/big.bin --query UploadId --output text)

# 2. Upload the parts (each returns an ETag)
aws s3api upload-part --bucket uploads-example --key videos/big.bin \
  --part-number 1 --body part-aa --upload-id "$UPLOAD_ID"
# ...parts 2 to 5 the same way, then list what S3 has:
aws s3api list-parts --bucket uploads-example --key videos/big.bin --upload-id "$UPLOAD_ID"

# 3. Complete with the part numbers and ETags (parts.json: {"Parts":[{"PartNumber":1,"ETag":"..."},...]})
aws s3api complete-multipart-upload --bucket uploads-example --key videos/big.bin \
  --upload-id "$UPLOAD_ID" --multipart-upload file://parts.json

# Find and abort forgotten uploads
aws s3api list-multipart-uploads --bucket uploads-example
aws s3api abort-multipart-upload --bucket uploads-example --key videos/old.bin --upload-id EXAMPLEID

# The safety net: abort incomplete uploads after 7 days
aws s3api put-bucket-lifecycle-configuration --bucket uploads-example --lifecycle-configuration \
  '{"Rules":[{"ID":"abort-mpu","Status":"Enabled","Filter":{},"AbortIncompleteMultipartUpload":{"DaysAfterInitiation":7}}]}'

# Let the high-level CLI choose parts and run them in parallel
aws configure set default.s3.multipart_chunksize 16MB
aws configure set default.s3.max_concurrent_requests 10
aws s3 cp ./trip-video.mp4 s3://uploads-example/videos/

Pre-signed URL:

# A GET URL valid for 10 minutes (the CLI signs GET only)
aws s3 presign s3://invoices-example/2026/10/inv-1042.pdf --expires-in 600
curl -o inv.pdf "<the URL>"          # works without AWS credentials
sleep 601; curl -I "<the URL>"       # 403 after expiry

# PUT and POST need an SDK (boto3 shown)
import boto3, uuid
s3 = boto3.client("s3")
key = f"sellers/42/{uuid.uuid4()}.jpg"

put_url = s3.generate_presigned_url(
    "put_object",
    Params={"Bucket": "photos-example", "Key": key, "ContentType": "image/jpeg"},
    ExpiresIn=300,
)
# Browser: fetch(put_url, {method: "PUT", headers: {"Content-Type": "image/jpeg"}, body: file})

post = s3.generate_presigned_post(
    "photos-example", key,
    Fields={"Content-Type": "image/jpeg"},
    Conditions=[["content-length-range", 1, 10 * 1024 * 1024],
                ["starts-with", "$Content-Type", "image/"]],
    ExpiresIn=600,
)
# post["url"] and post["fields"] go into an HTML form with the file input last

Batch Operations (S3 Control API):

# A role Batch Operations can assume
aws iam create-role --role-name s3-batch-tagging --assume-role-policy-document \
  '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"batchoperations.s3.amazonaws.com"},"Action":"sts:AssumeRole"}]}'

# A job that tags every object listed in a CSV manifest, with a report of failures
aws s3control create-job --account-id 111122223333 --region us-east-1 \
  --operation '{"S3PutObjectTagging":{"TagSet":[{"Key":"desk","Value":"sports"}]}}' \
  --manifest '{"Spec":{"Format":"S3BatchOperations_CSV_20180820","Fields":["Bucket","Key"]},"Location":{"ObjectArn":"arn:aws:s3:::manifests-example/sports.csv","ETag":"EXAMPLEETAG"}}' \
  --report '{"Bucket":"arn:aws:s3:::reports-example","Prefix":"batch","Format":"Report_CSV_20180820","Enabled":true,"ReportScope":"FailedTasksOnly"}' \
  --priority 10 --role-arn arn:aws:iam::111122223333:role/s3-batch-tagging \
  --no-confirmation-required

aws s3control describe-job --account-id 111122223333 --job-id <job-id>
aws s3control list-jobs --account-id 111122223333 --job-statuses Active Complete

#সারসংক্ষেপ

মূল কথাগুলো

• পথ ১১–১৩ হলো তোমার code S3 API দিয়ে যা করে: একটা বড় object-এর জন্য multipart, credential নেই এমন মানুষের জন্য pre-signed URL, আগে থেকেই S3-এ থাকা লাখ লাখ object-এর জন্য Batch Operations। পথ ১–১০-এর সাথে এরা মিলেমিশে চলে।
• Multipart: CreateMultipartUpload → UploadPart (একসাথে, যেকোনো ক্রমে, প্রতিটায় ETag) → CompleteMultipartUpload (atomic) অথবা Abort। Part ৫ MiB–৫ GiB (শেষটা ছোট হতে পারে), ১০,০০০ part, ৫ TB object (ডিসেম্বর ২০২৫ থেকে ৫০ TB)। ১০০ MB-র বেশি হলে পরামর্শ, ৫ GB-র বেশি হলে বাধ্যতামূলক। ব্যর্থ part একাই আবার যায়।
• অসমাপ্ত upload চোখে পড়ে না, কিন্তু বিল হয়: AbortIncompleteMultipartUpload lifecycle rule যোগ করো। SSE-KMS সহ multipart-এ kms:Decrypt-ও লাগে।
• Pre-signed URL: একটা object, একটা method, একটা মেয়াদ; চলে signer হিসেবে, signer-এর ব্যবহারের মুহূর্তের অনুমতি নিয়ে। Console ১ মিনিট–১২ ঘণ্টা; CLI default ১ ঘণ্টা, IAM user key-তে সর্বোচ্চ ৭ দিন; role-এর credential হলে session-এর সাথেই মরে। CLI শুধু GET presign করে; PUT আর POST-এর জন্য SDK লাগে।
• Browser → backend সই করে → browser সোজা S3-এ PUT করে (bucket-এ CORS) → event। Pre-signed POST আকার, ধরন আর key-prefix-এর শর্ত যোগ করে।
• Batch Operations job = manifest (Inventory, CSV বা বানিয়ে নেওয়া) + একটা operation + IAM role + report + priority। Operation: copy, Lambda, tag, ACL, restore, Object Lock, replicate, checksum, update encryption। Retry, report-এ আংশিক ব্যর্থতা, ১,০০০ task-এর পরে ৫০%-এর বেশি ব্যর্থ হলে job ব্যর্থ। প্রায় $0.25/job + প্রতি ১০ লাখ object-এ $1।
• ১৩টার মধ্যে বাছাই: শুরু করো data কোথায় তা দিয়ে, তারপর private কি না, কতটা, কত ঘনঘন, আর কে কোন protocol বোঝে।

নিজেকে যাচাই করো: multipart, pre-signed URL, Batch Operations আর ১৩টা পথ৩০টি প্রশ্ন