Event, Requester Pays, Batch Operations আর Storage Lens

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

• S3 event notification সাজাতে: কোন event type চাও সেটা বাছা, prefix আর suffix দিয়ে ছাঁকা, destination হিসেবে SNS, SQS বা Lambda ঠিক করা, আর target-এর হাতে যে event message পৌঁছায় সেটা পড়তে পারা।
• কেন notification-এর destination-এ একটা resource-based policy লাগে (আর encrypted queue বা topic হলে key policy-ও), সেটা বোঝাতে, আর “Unable to validate the following destination configurations” error ঠিক করতে।
• Overlap-এর নিয়ম মেনে rule বানাতে, recursive loop এড়াতে, আর কখন S3 event Amazon EventBridge-এ পাঠানো ভালো সেটা ঠিক করতে।
• Requester Pays বোঝাতে: storage, request আর transfer-এর টাকা কে দেয়, requester-কে কী পাঠাতে হয়, আর কখন তবুও owner-এর ঘাড়েই বিল পড়ে।
• একটা S3 Batch Operations job-এর পরিকল্পনা করতে: S3 Inventory (আর Athena) বা filter দিয়ে object-এর তালিকা বানানো, operation বাছা, IAM role দেওয়া, completion report পড়া, আর কখন job fail করবে সেটা আগেই বলতে পারা।
• S3 Storage Lens-এর free আর advanced metric-এর মধ্যে বাছতে, আর এই সবের পাশে Amazon Athena কোথায় বসে সেটা জানতে।

#যে bucket সাড়া দেয়, আর যে bucket তুমি চালাও

এই chapter-এর প্রথম ছয়টা লেসনে S3 ছিল জিনিস রাখার জায়গা: bucket আর key (লেসন ১০.১), কে পড়তে পারবে (১০.২), website (১০.৩), version আর কপি (১০.৪), storage class (১০.৫), আর গতি (১০.৬)। এই লেসনটা সেই দুটো ব্যাপার নিয়ে, যেগুলো শুরু হয় bucket ব্যস্ত হয়ে ওঠার পর:

• বদলে সাড়া দেওয়া। নতুন ছবি এলে তার thumbnail বানাতে হবে, নতুন invoice এলে হিসাবে তুলতে হবে, কোনো ফাইল মুছে গেলে alert দিতে হবে। কী বদলাল জানতে কেউ প্রতি মিনিটে bucket ঘাঁটবে, এটা চলে না: S3 নিজেই জানিয়ে দিতে পারে, event notification দিয়ে বা Amazon EventBridge-এর মাধ্যমে।
• বড় মাপে চালানো। ২০০ কোটি object-ওয়ালা bucket এমন সব প্রশ্ন তোলে, যেগুলোর ভালো উত্তর কোনো script দিতে পারে না: বাইরের লোক public dataset download করলে টাকা কে দেবে (Requester Pays), একসাথে সব object-এর tag বা encryption কীভাবে বদলাবে (S3 Batch Operations, যার খাবার জোগায় S3 Inventory), আর storage ও request আসলে কোথায় যাচ্ছে (S3 Storage Lens, আর SQL দিয়ে উত্তর মেলে এমন প্রশ্নের জন্য Athena)।

#Event notification

#S3 কোন কোন ঘটনার খবর দেয়

Event notification হলো একটা message, যেটা S3 পাঠায় bucket-এর কোনো object-এর সাথে কিছু ঘটলে। Configuration-টা bucket-এর গায়েই থাকে (তার notification subresource-এ), আর প্রতিটা মিলে যাওয়া event-এর জন্য S3 একটা message ছাড়ে। যেসব event type সবচেয়ে বেশি দেখবে:

দুটো খুঁটিনাটি অনেককে ফাঁদে ফেলে:

• Lifecycle rule কোনো object মুছলে s3:ObjectRemoved:* চলে না। ওগুলোর জন্য s3:LifecycleExpiration:* শুনতে হয়।
• বড় ফাইল multipart দিয়ে upload হলে (লেসন ১০.১) সেটা হয় s3:ObjectCreated:CompleteMultipartUpload, :Put না। যে rule শুধু :Put শোনে, সে এটা হারায়; s3:ObjectCreated:* object তৈরির সব রাস্তাই ধরে।

#Prefix আর suffix দিয়ে ছাঁকা

প্রতিটা rule object-এর key দেখে event কমিয়ে আনতে পারে:

• একটা prefix, যেমন uploads/ (key এটা দিয়ে শুরু হতে হবে), আর/অথবা
• একটা suffix, যেমন .jpg (key এটা দিয়ে শেষ হতে হবে)।

দুটোই দেওয়া থাকলে দুটোই মিলতে হবে। Native notification-এর ছাঁকনি এটুকুই: wildcard চলে না (*.jpg লেখা যায় না, লিখতে হয় suffix .jpg), object-এর size, tag বা metadata দিয়ে ছাঁকা যায় না, আর ছোট-বড় অক্ষর আলাদা ধরা হয়, তাই Uploads/ আর uploads/ এক না। Filter-এ space থাকলে লিখতে হয় +, অন্য বিশেষ অক্ষর URL-encode করে।

#Event কোথায় কোথায় যেতে পারে

একটা rule তার event পাঠায় ঠিক একটা destination-এ, আর destination তিন রকম, সাথে পুরো bucket-এর জন্য EventBridge:

• একটা Amazon SNS topic (শুধু standard, FIFO না): একসাথে অনেক subscriber-এর কাছে ঠেলে পাঠানো, যেমন email, mobile push, বা কয়েকটা SQS queue (fan-out, বিস্তারিত লেসন ১৩.৪-এ);
• একটা Amazon SQS queue (শুধু standard, FIFO না): একটা জমার জায়গা, যেটা worker নিজের গতিতে খালি করে (লেসন ১৩.১);
• একটা AWS Lambda function: প্রতিটা event-এ একবার চলা code (লেসন ১৫.১);
• Amazon EventBridge: পুরো bucket-এর জন্য চালু করতে হয়, এর আলাদা অংশ নিচে আছে।

SNS topic, SQS queue আর Lambda function-কে bucket-এর একই Region-এ থাকতে হবে। SQS queue-তে অন্তত ৬৪ KB-এর message নেওয়ার ব্যবস্থা রাখো, কারণ S3-এর event message সর্বোচ্চ এত বড় হতে পারে।

#Event message দেখতে কেমন

Target হাতে পায় একটা JSON document, যাতে থাকে একটা Records array। প্রতিটা record-এ থাকে event-এর নাম, সময়, bucket, আর object-এর key, size, ETag, version ID (versioned bucket হলে) আর একটা sequencer:

{
  "Records": [
    {
      "eventSource": "aws:s3",
      "awsRegion": "ap-south-1",
      "eventTime": "2026-10-25T09:14:03.512Z",
      "eventName": "ObjectCreated:Put",
      "s3": {
        "bucket": { "name": "shop-media-example", "arn": "arn:aws:s3:::shop-media-example" },
        "object": {
          "key": "uploads/summer+sale+shirt.jpg",
          "size": 3145728,
          "eTag": "d41d8cd98f00b204e9800998ecf8427e",
          "sequencer": "0066A1B2C3D4E5F6A7"
        }
      }
    }
  ]
}

যে code এটা হাতে নেবে, তাকে লেখার সময় তিনটা জিনিস মাথায় রাখো:

1. সময়। Notification সাধারণত কয়েক সেকেন্ডে পৌঁছায়, কিন্তু কখনো কখনো এক মিনিট বা তার বেশি লাগে। এটা real-time-এর কোনো নিশ্চয়তা না।
2. অন্তত একবার, আর ক্রম ছাড়া। S3-এর design-ই এমন যে প্রতিটা notification অন্তত একবার পৌঁছাবে। কদাচিৎ retry-র কারণে একই event দুবার আসে, আর আলাদা দুটো লেখার event উল্টো ক্রমেও আসতে পারে। তাই handler-কে idempotent বানাও (একই কাজ দুবার হলেও ক্ষতি নেই), আর একটা key-এর বেলায় ক্রম জরুরি হলে sequencer মিলিয়ে দেখো: একই key-এর জন্য যার sequencer বড়, সেই event পরের।
3. Key আসে URL-encoded হয়ে। uploads/summer sale shirt.jpg object-টা আসে uploads/summer+sale+shirt.jpg হয়ে। যে code key-টা সোজা GetObject-এ দিয়ে দেয়, সে পায় “NoSuchKey”; আগে decode করে নাও।

পুরো একটা flow দেখো, সাথে এমন filter যেটা মেলে না, এমন destination যেটা S3-কে ঢুকতে দেয় না, আর একটা loop:

#Overlap-এর নিয়ম

যে configuration-এ দুটো rule একই event দাবি করতে পারে, S3 সেটা নেয় না। দুটো rule overlap করে, আর configuration save হয় না, যখন এই তিনটাই সত্যি:

1. তাদের event type overlap করে (s3:ObjectCreated:* আর s3:ObjectCreated:Put overlap করে, কিন্তু s3:ObjectRemoved:*-এর সাথে না);
2. তাদের prefix overlap করে: একটা আরেকটা দিয়ে শুরু হয়। খালি prefix সব prefix-এর সাথেই overlap করে;
3. তাদের suffix overlap করে: একটা আরেকটা দিয়ে শেষ হয় (jpg আর .jpg overlap করে, pg আর jpg-ও করে, কিন্তু .jpg আর .png করে না)। খালি suffix সব suffix-এর সাথেই overlap করে।

তাই owner-এর notes কাজের ক্ষেত্রে ঠিকই বলেছে: একই prefix আর একই event type-এর জন্য দুটো rule রাখা যায় না, যদি না তাদের suffix আলাদা হয়। Prefix images/ + suffix .jpg একটা function-এ আর prefix images/ + suffix .png আরেকটায়, এটা চলবে; একই event-এর জন্য prefix images/ একটা queue-তে আর prefix images/ একটা function-এ, এটা বাতিল। একই event কয়েক জায়গায় পাঠাতে চাইলে দুটো পথ:

• event পাঠাও একটা SNS topic-এ, আর তাতে কয়েকটা SQS queue বা function subscribe করাও (চেনা fan-out), অথবা
• EventBridge চালু করো, আর যত খুশি rule লেখো।

নিজে চেষ্টা করো: rule চালু-বন্ধ করো, save করো, তারপর test file upload করো।

#S3-কে পৌঁছাতে দেওয়া: resource policy

#Destination-কে কেন রাজি হতে হয়

S3 notification পৌঁছায় destination-কে service principal s3.amazonaws.com হিসেবে ডেকে। তোমার IAM user-এর permission event-এর সাথে যায় না, তাই S3 পৌঁছাতে পারে কেবল তখনই, যখন destination নিজে অনুমতি দেয়, তার resource-based policy দিয়ে (resource-এর গায়ে লাগানো policy, লেসন ২.২):

Owner-এর notes একে বলেছে “IAM permission”। বড় অর্থে এটা IAM-ই, কিন্তু exam আর console বোঝায় SNS topic, SQS queue বা Lambda function-এর গায়ে resource (access) policy, কোনো user বা role-এর policy না। Lambda-রটা ভুলে যাওয়া সহজ: S3 console-এ function বাছলে console নিজেই এটা যোগ করে দেয়, কিন্তু template বা CLI দিয়ে করলে আলাদা করে যোগ করতে হয়।

এমন একটা queue policy, যেটা শুধু একটা account-এর একটা bucket-কে message পাঠাতে দেয়:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ShopMedia",
      "Effect": "Allow",
      "Principal": { "Service": "s3.amazonaws.com" },
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:ap-south-1:111122223333:audit",
      "Condition": {
        "ArnLike": { "aws:SourceArn": "arn:aws:s3:*:*:shop-media-example" },
        "StringEquals": { "aws:SourceAccount": "111122223333" }
      }
    }
  ]
}

দুটো condition confused deputy সমস্যা আটকায়: এগুলো না থাকলে যেকোনো account-এর যেকোনো bucket তার notification তোমার queue-র দিকে তাক করতে পারত, আর S3 পৌঁছেও দিত, কারণ policy সাধারণভাবে “S3 service”-কেই বিশ্বাস করে। aws:SourceArn bucket-টার নাম বলে; aws:SourceAccount bucket-এর মালিককে বেঁধে দেয়, কারণ bucket-এর ARN-এ কোনো account ID থাকে না।

#Encrypted queue আর topic

SQS queue বা SNS topic যদি KMS দিয়ে server-side encryption ব্যবহার করে (KMS-এর বিস্তারিত লেসন ১০.৮-এ), তাহলে S3-কেও key-টা ব্যবহার করতে পারতে হবে: key policy-কে s3.amazonaws.com-কে kms:GenerateDataKey আর kms:Decrypt করতে দিতে হবে। AWS managed key-এর (aws/sqs, aws/sns) key policy তুমি বদলাতে পারো না, তাই S3-এর জন্য encrypted destination বানাতে customer managed key লাগে।

#Permission না থাকলে কী দেখা যায়

Configuration save করার সময় S3 প্রতিটা destination যাচাই করে আর তাতে একটা s3:TestEvent পাঠায়। Destination-এর policy S3-কে অনুমতি না দিলে save ব্যর্থ হয়, error আসে “Unable to validate the following destination configurations”, আর bucket-এ আগের configuration-টাই থেকে যায়। কেউ যদি permission-টা পরে সরিয়ে দেয়, তখন জোরে কিছু ভাঙে না: event শুধু চুপচাপ আসা বন্ধ করে দেয়। Notification হারিয়ে গেলে আগে destination-এর policy দেখো, তারপর KMS key policy, তারপর filter।

#S3 event Amazon EventBridge-এ পাঠানো

#কী বদলায়

Amazon EventBridge হলো serverless একটা event bus (এর নিজের লেসন আছে, ১৯.৫)। Bucket-এর একটা setting, “Send notifications to Amazon EventBridge for all events in this bucket”, চালু করলে S3 তার সব supported event পাঠায় একই Region-এর default event bus-এ। কোন event type যাবে বাছতে হয় না, S3-এর permission-ও লাগে না। এরপর EventBridge-এর rule event মেলায় আর target-এ পাঠায়।

এমন একটা rule, যেটা শুধু বড় video-র জন্য transcoding workflow চালু করে:

{
  "source": ["aws.s3"],
  "detail-type": ["Object Created"],
  "detail": {
    "bucket": { "name": ["videos-example"] },
    "object": {
      "key": [{ "suffix": ".mp4" }],
      "size": [{ "numeric": [">", 104857600] }]
    }
  }
}

#Requester Pays

#কোন খরচ কার

সাধারণভাবে সব টাকা দেয় bucket owner: storage, প্রতিটা request, আর download হওয়া প্রতিটা gigabyte। নিজের application-এর জন্য এটা ঠিকই আছে, কিন্তু সমস্যা হয় যখন তুমি ৫০ TB-এর একটা dataset প্রকাশ করো আর শত শত প্রতিষ্ঠান সেটা download করে: তাদের কৌতূহলের বিল এসে পড়ে তোমার ঘাড়ে। Requester Pays bucket সেই বিলের একটা অংশ সরিয়ে দেয়:

এটা চালু করতে হয় bucket ধরে (aws s3api put-bucket-request-payment … Payer=Requester)। বড় বড় public dataset প্রায়ই এভাবেই ভাগ করা হয়, যেমন Registry of Open Data on AWS-এর অনেক dataset।

#যে নিয়মগুলোতে এটা চলে

• Request-কে authenticated হতে হবে। কোন AWS account-এ বিল যাবে S3-কে সেটা জানতে হয়, তাই Requester Pays bucket নাম-পরিচয়হীন (anonymous) request ফিরিয়ে দেয়। এটা দিয়ে anonymous public website চালানো যায় না।
• Requester-কে খরচ মেনে নিতে হবে। প্রতিটা request-এ থাকতে হবে header x-amz-request-payer: requester (CLI-তে --request-payer requester)। এটা না থাকলে S3 উত্তর দেয় 403 Access Denied, bucket policy পড়তে দিলেও। Bucket owner-এর নিজের request-এ header লাগে না।
• Requester Pays নিজে কোনো অনুমতি দেয় না। Requester-এর তবুও permission লাগবে: অন্য account-কে অনুমতি দেওয়া একটা bucket policy (লেসন ১০.২), বা authenticated principal-দের অনুমতি দেওয়া একটা public dataset policy।
• Role গোনা হয় যার account-এর role, তার নামে। Requester যদি owner-এর account-এর একটা role assume করে, তাহলে request আসছে owner-এর account থেকেই, আর টাকা দেয় owner। Requester নিজের account-এর credential ব্যবহার করলে তবেই Requester Pays বিল সরায়।
• কিছু ব্যর্থ request-এর দায় তবুও owner-এর। Owner-এর নিজের account বা AWS Organization-এর ভেতর থেকে আসা কোনো request 403-এ ব্যর্থ হলে তার টাকা owner দেয়।
• Requester Pays bucket-কে server access logging-এর target bucket বানানো যায় না (access log-এর কথা লেসন ১০.৯-এ)।

Setting, কে download করছে আর data কোথায় যাচ্ছে, এগুলো বদলে খেলে দেখো:

হিসাব করে দেখো। S3 Standard-এ ২০ TB (২০,৪৮০ GB), প্রতি GB-মাসে $0.023 ধরে, owner-এর মাসে খরচ $471.04, Requester Pays থাকুক বা না থাকুক। একজন partner ৫ TB (৫,১২০ GB) internet-এ download করল, প্রতি GB $0.09: transfer $460.80, সাথে ১০০ MB-এর object ধরলে প্রায় ৫২,০০০টা GET request, প্রতি ১,০০০-এ $0.0004 (২ সেন্ট)। Requester Pays ছাড়া owner দেয় $931.86; থাকলে owner দেয় $471.04 আর partner $460.82। (উদাহরণের list price; আসল বিলে tier আর মাসিক free allowance থাকে।)

#S3 Batch Operations

#Script কেন না

“প্রতিটা object-এ retention=7y tag লাগাও”, “সব পুরনো object আমাদের নিজের KMS key দিয়ে আবার encrypt করো”, “৪০ কোটি object নতুন account-এর bucket-এ কপি করো”, “২০২০ সালের সব scan Deep Archive থেকে restore করো”। হাজারখানেক object-এর জন্য একটা script এটা পারে। ১০০ কোটির জন্য তাকে ঘণ্টার পর ঘণ্টা bucket-এর তালিকা নিতে হবে, দিনের পর দিন একটা machine-এ চলতে হবে, throttling আর retry সামলাতে হবে, reboot হলে টিকে থাকতে হবে, আর শেষে প্রমাণ দিতে হবে কোন কোন object ব্যর্থ হলো।

S3 Batch Operations মানে কাজটা S3 নিজেই তোমার হয়ে করে দেয়: একটা job একটা তালিকার প্রতিটা object-এ একটা operation চালায়, retry, progress-এর হিসাব, notification আর একটা completion report সহ, পুরোপুরি managed আর serverless একটা service হিসেবে। একটা job-এ ২০০০ কোটি পর্যন্ত object থাকতে পারে (আর ডিসেম্বর ২০২৫ থেকে বড় job ১০ গুণ পর্যন্ত দ্রুত চলে)।

#একটা job কী দিয়ে তৈরি

1. একটা manifest: object-এর তালিকা। হয় একটা S3 Inventory report (তার manifest.json), নয় bucket,key-এর একটা CSV ফাইল (চাইলে version ID-এর একটা column সহ), নয়তো কোনো ফাইলই না: Batch Operations নিজেই filter দিয়ে তালিকা বানিয়ে নিতে পারে, যেমন prefix, suffix, key-এর ভেতরের কোনো অংশ, তৈরির তারিখের সীমা, size, storage class বা encryption type, আর সেটা manifest হিসেবে রেখেও দিতে পারে। Replication configuration থেকেও তালিকা বানানো যায় (সেটাই Batch Replication, লেসন ১০.৪)।
2. একটা operation, তার parameter সহ (নিচের table দেখো)। এক job, এক operation; দুটো operation লাগলে দুটো job চালাও।
3. একটা IAM role, যেটা Batch Operations assume করে। এর trust policy service principal batchoperations.s3.amazonaws.com-কে অনুমতি দেয়; আর permission-এ থাকে manifest পড়া, report লেখা, আর operation-টা নিজে (যেমন copy-র জন্য source-এ s3:GetObject আর destination-এ s3:PutObject, encrypted data হলে KMS permission-ও)। Console এটা তোমার হয়ে বানিয়ে দিতে পারে। Role আর trust policy ছিল লেসন ২.৪-এ।
4. একটা completion report (ঐচ্ছিক, কিন্তু রাখাই ভালো): তোমার বাছা bucket-এ একটা CSV, যাতে থাকে সব task, বা শুধু ব্যর্থগুলো, তাদের error code সহ।
5. তোমার অন্য job-গুলোর মধ্যে একটা priority, আর চাইলে tag আর বর্ণনা।

#একটা job কী কী করতে পারে

“Delete objects” নামে কোনো operation নেই। লাখ লাখ object মুছতে lifecycle expiration rule ব্যবহার করো (লেসন ১০.৫), আর কোন object মুছবে সেটা জটিল হলে Invoke Lambda।

Job-এর নিজের কয়েকটা নিয়ম: copy job চলে destination Region-এ, বাকি সব job object-গুলোর Region-এ; object প্রসেস হয় কোনো নির্দিষ্ট ক্রম ছাড়া; console থেকে বানানো job তোমার নিশ্চিত করার জন্য অপেক্ষা করে (status Suspended), আর ৩০ দিন এভাবে পড়ে থাকলে fail করে; আর অন্তত ১,০০০টা task চলার পর ব্যর্থতার হার ৫০%-এর বেশি হলে S3 job থামিয়ে Failed করে দেয়, যাতে একটা ভুল তালিকা ঘণ্টার পর ঘণ্টা চলতে না পারে। Manifest শুধু একটা তালিকা, bucket-এর ছবি না: job চলার সময় কোনো object নতুন করে লেখা হলে, আর manifest-এ version ID না থাকলে, job কাজ করে সবচেয়ে নতুন version-এর ওপর।

খরচ: প্রতি job $0.25, আর প্রতি ১০ লাখ processed object-এ $1.00, তার ওপর operation-এর স্বাভাবিক request charge (Invoke Lambda হলে Lambda-র খরচও)।

#S3 Inventory: job-এর তালিকা

S3 Inventory একটা bucket-এর (বা একটা prefix-এর) object-গুলোর নিয়মিত একটা তালিকা বানায়, তোমার বাছা metadata সহ: size, শেষ বদলের তারিখ, storage class, ETag, encryption status (SSE-S3, SSE-KMS, DSSE-KMS, SSE-C, NOT-SSE), replication status, Object Lock-এর setting, Intelligent-Tiering-এর tier, version ID, আরও অনেক কিছু।

• আসে প্রতিদিন বা প্রতি সপ্তাহে, CSV, ORC বা Parquet হিসেবে, একই Region-এর একটা destination bucket-এ (সেটা অন্য account-এর হতে পারে, আর তাতে S3-কে লিখতে দেওয়ার bucket policy লাগে)। প্রথম report আসতে ৪৮ ঘণ্টা পর্যন্ত লাগতে পারে।
• এটা List request ব্যবহার করে না, তোমার bucket-এর request rate-ও ছোঁয় না, তাই ১০০ কোটি key-এর তালিকা নিজে নেওয়ার চেয়ে অনেক সস্তা।
• প্রতিটা তালিকা eventually consistent: একদম সাম্প্রতিক লেখা বা মোছা বাদ পড়তে পারে।
• এটাতে Amazon Athena দিয়ে query চালানো যায়, আর এভাবেই “সব object” থেকে বের করা যায় “scans/2019/-এর নিচে যেগুলো এখনো NOT-SSE”, তারপর ফলাফলটা job-এর CSV manifest হিসেবে রাখা যায়।

Slide-এ এই pipeline-টাই আঁকা: S3 Inventory → Athena (ছাঁকনি) → ছাঁকা তালিকা → S3 Batch Operations (operation + parameter) → processed object।

Data S3-তে ঢোকা বা বের হওয়ার তেরোটা পথের একটা হলো Batch Operations; লেসন ১০.১২ সেই বাছাইয়ের তালিকায় একে multipart upload আর pre-signed URL-এর পাশে বসিয়েছে।

#S3 Storage Lens

#সব storage এক নজরে

৪০টা account আর ৩,০০০ bucket-ওয়ালা একটা কোম্পানি একটা একটা bucket-এ click করে সহজ প্রশ্নের উত্তরও পায় না: কোন bucket সবচেয়ে দ্রুত বাড়ছে? অসম্পূর্ণ multipart upload-এর কত terabyte কোথায় লুকিয়ে আছে? কোন bucket-এ versioning নেই? S3 Storage Lens প্রতিদিন ব্যবহার আর activity-র metric জড়ো করে আর dashboard-এ দেখায়, ভাগ করে organisation, account, Region, storage class, bucket ধরে, আর advanced metric থাকলে prefix ধরেও (সাথে prefix, suffix, tag, size বা বয়স দিয়ে নিজের বানানো Storage Lens group)।

• প্রতিটা account-এ একটা default dashboard থাকে, default-account-dashboard, যেটা S3 নিজে সাজিয়ে রাখে। এর metric upgrade করা যায় বা একে বন্ধ করা যায়, কিন্তু মোছা যায় না।
• Home Region প্রতি আরও ৫০টা পর্যন্ত dashboard বানানো যায়, Region, bucket বা account ধরে সীমা টেনে। পুরো organisation-এর dashboard-এর জন্য AWS Organizations-এ trusted access লাগে, আর সেটা বানাতে হয় management account বা একটা delegated administrator থেকে।
• Metrics export প্রতিদিন metric-গুলো CSV বা Parquet হিসেবে একটা bucket-এ পাঠায় (অথবা AWS-এর সামলানো একটা S3 table bucket-এ, SQL query-র জন্য তৈরি অবস্থায়)।
• Recommendation আর outlier call-out আজকের হিসাব তোমার গত ৩০ দিনের সাথে মিলিয়ে অস্বাভাবিক বদল ধরিয়ে দেয়।

#Free metric আর advanced metric

Owner-এর notes বলছে free data থাকে “১৪ দিন (এখন অনেক Region-এ ২৮ দিন)”। আসলে ১৪ দিন: “২৮” হলো AWS শেষবার যখন গুনেছিল (২০২৩), তখন free tier-এ কয়টা usage metric ছিল সেই সংখ্যা, আর তারপর free-এর ধরন আরও বেড়েছে। Slide-এর “৩০ দিনের usage আর activity metric” কথাটাও বিভ্রান্তিকর: ৩০ দিন হলো outlier ধরার সময়ের জানালা; activity metric শুধু advanced-এ।

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

• Notification configuration save হচ্ছে না (“Unable to validate…”): SNS topic, SQS queue বা Lambda function-এ s3.amazonaws.com-এর জন্য resource policy নেই, destination অন্য Region-এ, queue বা topic FIFO, অথবা তার KMS key S3-কে অনুমতি দেয় না।
• Event আসা বন্ধ: configuration save হওয়ার পরে কেউ queue বা topic-এর policy বা key policy কড়া করেছে, অথবা কোনো deployment Lambda function বদলে দিয়েছে তার permission ছাড়াই।
• কিছু ফাইল কখনো trigger করে না: suffix বা prefix মেলে না (ছোট-বড় অক্ষর, .jpeg বনাম .jpg), অথবা rule শোনে :Put, আর ফাইল এসেছে multipart upload বা copy দিয়ে।
• নতুন rule যোগ করা যাচ্ছে না: একই event type-এর আগের কোনো rule-এর সাথে overlap করছে। SNS fan-out বা EventBridge ব্যবহার করো।
• কিছু ফাইলে Lambda NoSuchKey দিয়ে ব্যর্থ: event-এর key URL-encoded; decode করো।
• একই কাজ দুবার: delivery অন্তত একবার। Handler idempotent বানাও।
• খরচ লাফিয়ে বাড়ছে, function থামছেই না: recursive loop; অন্য prefix বা bucket-এ লেখো।
• Requester Pays bucket থেকে partner পাচ্ছে 403: তারা x-amz-request-payer পাঠায়নি, তারা anonymous, অথবা bucket policy তাদের অনুমতি দেয় না।
• Partner-এর download-এর টাকা তবুও owner দিচ্ছে: partner-রা owner-এর account-এর role assume করছে।
• Batch job Suspended-এ আটকে: console-এ বানানো, নিশ্চিত করার অপেক্ষায়।
• Batch job Failed: role manifest পড়তে বা report লিখতে পারে না, অথবা প্রথম ১,০০০+ task-এর অর্ধেকের বেশি ব্যর্থ (মুছে যাওয়া object, KMS permission নেই)। Completion report পড়ো।
• Storage Lens-এ prefix নেই, request-এর সংখ্যা নেই: dashboard free metric ব্যবহার করছে।

#এক নজরে exam-এর ধাঁচ

#System design-এ event আর operation

• Polling না, event ব্যবহার করো। “S3-এ কিছু এসে পড়েছে, এবার X করো”: AWS-এ এটাই সবচেয়ে চেনা serverless pattern: একটা upload bucket, একটা notification, একটা function বা একটা queue। দিনে দশটা ফাইল থেকে লাখ লাখ পর্যন্ত, design না বদলেই চলে।
• ধীর কাজের সামনে একটা queue রাখো। S3 থেকে সরাসরি Lambda মানায় ছোট, আলাদা আলাদা কাজে। ধীর বা হঠাৎ ভিড়ের কাজে, বা ভোক্তা মাঝে মাঝে বন্ধ থাকতে পারলে, event পাঠাও SQS-এ আর worker-দের সেটা খালি করতে দাও, বিষাক্ত ফাইলের জন্য একটা dead-letter queue সহ (লেসন ৯.৪-এর worker tier-এর pattern)।
• প্রথম দিন থেকেই fan-out মাথায় রাখো। নতুন object নিয়ে একাধিক দলের মাথাব্যথা থাকলে একটা function-এ সরাসরি notification না দিয়ে EventBridge (বা একটা SNS topic) দিয়ে শুরু করো, যাতে দ্বিতীয় ভোক্তা আসলে প্রথমজনের rule বদলাতে না হয়।
• Handler বানাও অন্তত-একবার আর এলোমেলো ক্রমের কথা ভেবে। Idempotent লেখা, key ধরে ক্রমের জন্য sequencer, আর যা কখনো বাদ পড়া চলবে না তার জন্য মাঝে মাঝে মিলিয়ে দেখা (inventory-কে তোমার database-এর সাথে)।
• Input আর output আলাদা রাখো। কাঁচা upload আর processed ফলের জন্য আলাদা prefix বা bucket, যাতে rule কখনো নিজের output দেখতে না পায়।
• ঠিক লোকের কাছে বিল পাঠাও। Public বা partner dataset রাখো Requester Pays bucket-এ; ভেতরের ভোক্তারা নিজেদের account-এর role ব্যবহার করুক, যাতে খরচের ভাগ পরিষ্কার থাকে।
• বড় বদলকে job হিসেবে দেখো। কোন object বদলাবে সেটা বাছতে Inventory + Athena, বদলাতে Batch Operations, audit-এর প্রমাণ হিসেবে completion report, আর পুরো organisation-এ ফল যাচাই করতে Storage Lens।

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

Lambda আর SQS-এ event notification:

# ১. S3-কে function চালানোর অনুমতি দাও (function-এর resource-based policy)
aws lambda add-permission --function-name make-thumb \
  --statement-id s3-shop-media --action lambda:InvokeFunction \
  --principal s3.amazonaws.com \
  --source-arn arn:aws:s3:::shop-media-example --source-account 111122223333

# ২. S3-কে queue-তে পাঠাতে দাও (লেসনের queue policy-টা queue-policy.json-এ রাখা)
aws sqs set-queue-attributes \
  --queue-url https://sqs.ap-south-1.amazonaws.com/111122223333/audit \
  --attributes file://queue-attributes.json   # {"Policy": "<policy JSON, string হিসেবে>"}

# ৩. Notification configuration: .jpg আর .png যাবে Lambda-তে, invoices/-এর সব যাবে SQS-এ
cat > notification.json <<'EOF'
{
  "LambdaFunctionConfigurations": [
    { "Id": "thumbs-jpg",
      "LambdaFunctionArn": "arn:aws:lambda:ap-south-1:111122223333:function:make-thumb",
      "Events": ["s3:ObjectCreated:*"],
      "Filter": { "Key": { "FilterRules": [
        { "Name": "prefix", "Value": "uploads/" }, { "Name": "suffix", "Value": ".jpg" } ] } } },
    { "Id": "thumbs-png",
      "LambdaFunctionArn": "arn:aws:lambda:ap-south-1:111122223333:function:make-thumb",
      "Events": ["s3:ObjectCreated:*"],
      "Filter": { "Key": { "FilterRules": [
        { "Name": "prefix", "Value": "uploads/" }, { "Name": "suffix", "Value": ".png" } ] } } }
  ],
  "QueueConfigurations": [
    { "Id": "invoices",
      "QueueArn": "arn:aws:sqs:ap-south-1:111122223333:audit",
      "Events": ["s3:ObjectCreated:*"],
      "Filter": { "Key": { "FilterRules": [ { "Name": "prefix", "Value": "invoices/" } ] } } }
  ],
  "EventBridgeConfiguration": {}
}
EOF
aws s3api put-bucket-notification-configuration --bucket shop-media-example \
  --notification-configuration file://notification.json
aws s3api get-bucket-notification-configuration --bucket shop-media-example

# ৪. Test: upload করো, তারপর queue আর function-এর log দেখো
aws s3 cp shirt-42.jpg s3://shop-media-example/uploads/shirt-42.jpg
aws sqs receive-message --queue-url https://sqs.ap-south-1.amazonaws.com/111122223333/audit
aws logs tail /aws/lambda/make-thumb --since 5m

"EventBridgeConfiguration": {} লাইনটাই EventBridge-এর পুরো switch। Default bus-এ একটা rule:

aws events put-rule --name big-videos \
  --event-pattern file://big-videos-pattern.json      # লেসনের JSON pattern-টা
aws events put-targets --rule big-videos \
  --targets Id=transcode,Arn=arn:aws:states:ap-south-1:111122223333:stateMachine:transcode,RoleArn=arn:aws:iam::111122223333:role/events-to-sfn

Requester Pays:

# Owner: চালু করো আর যাচাই করো
aws s3api put-bucket-request-payment --bucket bay-images-example \
  --request-payment-configuration Payer=Requester
aws s3api get-bucket-request-payment --bucket bay-images-example

# Partner (নিজের account-এর credential দিয়ে): প্রতিটা request-এ খরচ মেনে নাও
aws s3 ls s3://bay-images-example/2026/ --request-payer requester
aws s3 cp s3://bay-images-example/2026/10/scene-0042.tif . --request-payer requester
aws s3 cp s3://bay-images-example/2026/10/scene-0042.tif .      # → 403 Access Denied

S3 Inventory আর একটা Batch Operations job:

# scans-example-এর রোজকার CSV inventory, encryption status সহ, reports-example-এ
aws s3api put-bucket-inventory-configuration --bucket scans-example --id daily-all \
  --inventory-configuration '{"Id":"daily-all","IsEnabled":true,"IncludedObjectVersions":"Current",
    "Schedule":{"Frequency":"Daily"},
    "OptionalFields":["Size","StorageClass","EncryptionStatus"],
    "Destination":{"S3BucketDestination":{"Bucket":"arn:aws:s3:::reports-example",
      "Format":"CSV","Prefix":"inventory"}}}'

# একটা CSV manifest-এর ওপর tag বসানোর job, console-এর মতো নিশ্চিত করতে হবে না
aws s3control create-job --account-id 111122223333 --region ap-south-1 \
  --operation '{"S3PutObjectTagging":{"TagSet":[{"Key":"retention","Value":"7y"}]}}' \
  --manifest '{"Spec":{"Format":"S3BatchOperations_CSV_20180820","Fields":["Bucket","Key"]},
    "Location":{"ObjectArn":"arn:aws:s3:::reports-example/manifests/scans-2019.csv","ETag":"<csv-টার etag>"}}' \
  --report '{"Bucket":"arn:aws:s3:::reports-example","Prefix":"batch-reports",
    "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 list-jobs --account-id 111122223333 --region ap-south-1
aws s3control describe-job --account-id 111122223333 --region ap-south-1 --job-id <job-id>
aws s3control update-job-status --account-id 111122223333 --region ap-south-1 \
  --job-id <job-id> --requested-job-status Ready   # Suspended job নিশ্চিত করা

Storage Lens:

aws s3control list-storage-lens-configurations --account-id 111122223333 --region us-east-1
aws s3control get-storage-lens-configuration --account-id 111122223333 \
  --config-id default-account-dashboard --region us-east-1

#সারসংক্ষেপ

মূল কথাগুলো

• Event notification object-এর event (তৈরি, মোছা, restore, replication, lifecycle, tagging…) পাঠায় একই Region-এর SNS (standard), SQS (standard) বা Lambda-তে, প্রতি rule-এ একটা destination, আর ছাঁকনি শুধু key-এর prefix আর suffix (wildcard নেই, ছোট-বড় অক্ষর আলাদা)।
• Delivery সাধারণত কয়েক সেকেন্ডে, কখনো এক মিনিট বা বেশি, অন্তত একবার আর ক্রম ছাড়া; key আসে URL-encoded হয়ে। Handler idempotent রাখো, আর recursive loop এড়াতে output-কে শোনা prefix-এর বাইরে রাখো।
• Destination-কে তার resource-based policy-তে s3.amazonaws.com-কে অনুমতি দিতে হয় (sns:Publish, sqs:SendMessage, lambda:InvokeFunction), ভালো হয় aws:SourceArn আর aws:SourceAccount দিয়ে সীমা টানলে; encrypted queue আর topic-এর লাগে এমন customer managed KMS key, যার policy S3-কে অনুমতি দেয়। Permission না থাকলে → “Unable to validate the following destination configurations”।
• একই event type-এর rule-গুলোর prefix আর suffix একসাথে overlap করতে পারে না। অনেক ভোক্তার জন্য SNS fan-out বা EventBridge।
• EventBridge: bucket-এ একটা switch, সব event, কোনো permission লাগে না; size, metadata আর আরও অনেক কিছুর ওপর JSON rule; Step Functions আর SQS FIFO সহ বিশটারও বেশি ধরনের target; archive আর replay।
• Requester Pays: storage-এর টাকা owner-এর, request আর transfer-এর টাকা requester-এর; requester-কে authenticated হতে হবে আর পাঠাতে হবে x-amz-request-payer: requester; owner-এর account-এর role মানে টাকা owner-এর।
• S3 Batch Operations: একটা manifest থেকে (S3 Inventory, CSV, বা filter দিয়ে বানানো) কোটি কোটি object-এ একটা operation, একটা IAM role দিয়ে, retry সহ, একটা completion report, console-এ নিশ্চিত করা, আর ১,০০০ task-এর পর ৫০% ব্যর্থতার সীমা। Copy (≤ ৫ GB, একই জায়গায় encrypt), Lambda, tag, ACL, restore, Object Lock, update encryption, checksum, Batch Replication; delete নেই।
• S3 Inventory: encryption আর replication status সহ প্রতিদিন বা প্রতি সপ্তাহে CSV/ORC/Parquet তালিকা; query করো Athena দিয়ে (S3-এ serverless SQL, প্রতি TB scan-এ ~$5; Parquet, compression আর partition খরচ কমায়)।
• S3 Storage Lens: পুরো organisation-এর dashboard। Free: bucket পর্যন্ত, ১৪ দিন। Advanced: prefix পর্যন্ত, activity আর status-code metric, ১৫ মাস, CloudWatch, recommendation।

নিজেকে যাচাই করো: S3 event, Requester Pays, Batch Operations আর Storage Lens৩০টি প্রশ্ন