S3-তে পৌঁছানোর পথ (২/৩): একসঙ্গে অনেক ডেটা সরানো

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

• S3-তে data পৌঁছানোর ১৩টা পথের মানচিত্রে এই লেসনের ৫টা bulk পথ কোথায় বসে সেটা দেখাতে, আর প্রতিটা কী কাজের জন্য, এক বাক্যে বলতে।
• S3 File Gateway কীভাবে একটা NFS বা SMB share-কে bucket-এর object বানিয়ে ফেলে, local cache, Active Directory আর lifecycle rule সহ, সেটা বোঝাতে; আর Storage Gateway-এর বাকি ধরনগুলো (Volume, Tape, FSx File) চিনতে।
• DataSync কীভাবে agent, schedule, incremental copy আর যাচাই দিয়ে data migrate আর sync করে, AWS থেকে AWS আর অন্য cloud থেকে transfer-সহ, সেটা বলতে।
• একটা network link-এ transfer-এ কত সময় লাগবে হিসাব করতে, কখন Snowball device ডাকে পাঠানো দ্রুত সেটা ঠিক করতে, আর lifecycle rule দিয়ে Snowball-এর data Glacier-এ নামাতে।
• S3 Transfer Acceleration কীভাবে edge location ব্যবহার করে, এর শর্ত আর দাম কী, আর কখন এটা কোনো কাজে আসে না, সেটা বোঝাতে।
• AWS Transfer Family দিয়ে managed SFTP, FTPS, FTP বা AS2 endpoint বানাতে, প্রতিটা partner-কে তার নিজের prefix-এ আটকে রাখতে, আর ঠিক identity provider বাছতে।
• কোনো পরিস্থিতিতে এই পাঁচটার মধ্যে বাছতে, সেই প্রশ্নগুলো দিয়ে যেগুলো এদের আলাদা করে: একবারের না চলমান, online না offline, file protocol লাগবে কি না, data কে পাঠায়।

#মানচিত্রে এই লেসনের জায়গা

S3-তে data ঢোকা বা বের হওয়ার সব উপায় পাশাপাশি এক জায়গায় দেখতে চেয়েছিলেন owner, কারণ এই service-গুলো খুব সহজেই গুলিয়ে যায়। পথ মোট ১৩টা, তিনটা লেসনে ভাগ করা। লেসন ১০.১০-এ ছিল private network-এর রাস্তা (১ Gateway endpoint, ২ Interface endpoint, ৩ VPC Peering, ৪ Transit Gateway, ৫ Site-to-Site VPN বা Direct Connect): packet কোন রাস্তা ধরবে, সেটা ওরা ঠিক করে। এই লেসনে bulk পথ (৬ S3 File Gateway, ৭ AWS DataSync, ৮ AWS Snowball, ৯ S3 Transfer Acceleration, ১০ AWS Transfer Family): এরা প্রত্যেকে নিজের মতো করে তোমার হয়ে অনেক data সরায়। লেসন ১০.১২-এ application-এর পথ (১১ multipart upload, ১২ pre-signed URL, ১৩ Batch Operations), আর শেষে ১৩টা পথ মিলিয়ে বাছাইয়ের একটা গাইড।

এই লেসনের পাঁচটা আলাদা আলাদা প্রশ্নের উত্তর দেয়, আর এদের কখনো না গুলিয়ে ফেলার চাবিকাঠি এটাই:

এদের প্রতিটা course-এর পরের দিকে আরও গভীরে পড়ানো হবে: Snowball, Storage Gateway, Transfer Family আর DataSync chapter ১২-তে (Snowball Edge, Storage Gateway, Transfer Family, DataSync আর বাছাই), আর বড় migration chapter ২৩-এ (বিপুল data সরানো)। Transfer Acceleration performance-এর tool হিসেবেও এসেছে লেসন ১০.৬-এ। তবু এই লেসন নিজেই সম্পূর্ণ: প্রতিটা কী, data কীভাবে যায়, সীমা আর দাম কত, একটা বাস্তব উদাহরণ, আর বাকি চারটা ফেলে কেন এটা বাছবে।

#পথ ৬: Amazon S3 File Gateway

#Hybrid storage-এ একজন দোভাষী কেন লাগে

অনেক কোম্পানি hybrid cloud চালায়: system-এর কিছু অংশ AWS-এ, কিছু নিজের অফিসে (on-premises)। কারণগুলো খুব সাধারণ: migration শেষ হতে বছর লেগে যায়, security বা compliance-এর নিয়মে কিছু system বিল্ডিংয়ের ভেতরেই রাখতে হয়, বা স্রেফ কোম্পানির IT strategy। যে server-গুলো অফিসে থেকে যায়, তাদেরও storage লাগে, আর S3 লোভনীয়: সীমাহীন, এগারোটা নয়ের durability, সস্তা archive class।

কিন্তু S3 হলো object storage, তার নিজের HTTPS API আছে (PUT, GET, list request); এটা file system না। Linux server file share mount করে NFS দিয়ে, Windows server SMB দিয়ে, আর পুরনো application S3 API ডাকতে জানেই না। EFS নিজেই NFS বোঝে (লেসন ৫.৪), কিন্তু S3-এর একজন দোভাষী লাগে। সেই দোভাষী হলো AWS Storage Gateway: on-premises data আর cloud storage-এর মধ্যে একটা সেতু, যেটা backup আর restore, disaster recovery, tiered storage আর কম latency-র local cache-এর কাজে লাগে। এর কয়েকটা ধরন আছে; যেটা ফাইল S3-এ রাখে, তার নাম Amazon S3 File Gateway।

#একটা ফাইল কীভাবে object হয়

S3 File Gateway হলো একটা virtual appliance, যেটা তুমি অফিসেই চালাও: VMware, Microsoft Hyper-V, Linux KVM বা Nutanix-এ একটা VM, অথবা AMI থেকে একটা EC2 instance। এতে একটা cache disk দাও আর এক বা একাধিক S3 bucket-এর সাথে জুড়ে দাও। তারপর:

1. Gateway-তে একটা file share বানাও: NFS export (NFS v3 বা v4.1) বা SMB share (SMB v2 বা v3)। প্রতিটা share একটা bucket-এর সাথে, বা bucket-এর একটা prefix-এর সাথে জোড়া। একটা gateway-তে সর্বোচ্চ ৫০টা share।
2. Server-গুলো এটা যেকোনো NAS-এর মতোই mount করে। Application ফাইল লিখলে gateway সেটা local cache-এ রাখে আর সাথে সাথে “হয়ে গেছে” বলে, ফলে application পায় local disk-এর গতি।
3. পেছনে পেছনে gateway ফাইলটা HTTPS দিয়ে S3-এ upload করে (internet দিয়ে, বা লেসন ১০.১০-এর Direct Connect বা VPN দিয়ে)। একটা ফাইল মানে একটা object; path হয়ে যায় key, আর মালিক, permission, সময়ের মতো file metadata object-এর metadata-তে থেকে যায়।
4. সম্প্রতি ব্যবহার হওয়া ফাইল পড়া হয় cache থেকে (cache hit)। বাকি সবকিছু আনতে হয় S3 থেকে (cache miss), তারপর cache-এ থেকে যায়।
5. Gateway লেখে S3 Standard, Standard-IA, One Zone-IA বা Intelligent-Tiering-এ। সরাসরি Glacier class-এ লিখতে পারে না; bucket-এর একটা সাধারণ lifecycle rule (লেসন ১০.৫) পুরনো object সেখানে সরায়। কোনো object Glacier Flexible Retrieval বা Deep Archive-এ চলে গেলে, share দিয়ে আবার পড়ার আগে সেটা restore করতে হয়।
6. Gateway bucket-এ পৌঁছায় তোমার দেওয়া একটা IAM role দিয়ে (প্রতি share-এ একটা)। SMB share-এর জন্য সে তোমার Active Directory-তে join করতে পারে, তাই user-রা নিজেদের সাধারণ domain account দিয়েই login করে, Windows permission-ও খাটে।

Data যেহেতু সাধারণ object হয়ে নামে, AWS-এর সবকিছু এটা ব্যবহার করতে পারে: Athena দিয়ে analytics, machine learning, অন্য Region-এ replication, versioning, Object Lock। NAS-এর তুলনায় বড় সুবিধা এটাই: যাদের দরকার তাদের জন্য ফাইল অফিসেই আছে, আর বাকি সবকিছুর জন্য আছে cloud-এ।

সীমা আর সংখ্যা। প্রতি gateway-তে cache ১৫০ GiB থেকে ৬৪ TiB পর্যন্ত। প্রতি gateway-তে সর্বোচ্চ ৫০টা file share। সবচেয়ে বড় ফাইল ৫ TiB (একটা S3 object-এর সীমা)। খরচ: AWS-এ লেখা প্রতি GB-তে প্রায় $0.01, প্রতি gateway-তে মাসে সর্বোচ্চ $125 (প্রতি account-এ প্রথম ১০০ GB বিনা পয়সায়), সাথে S3-এর সাধারণ storage আর request-এর দাম; VM চলে তোমার নিজের hardware-এ, নয়তো EC2 instance-এর দাম দাও।

একটা write, cache hit আর miss, lifecycle-এ সরানো, Active Directory-র যাচাই আর internet link বন্ধ হওয়া, সব দেখো:

#Storage Gateway পরিবারের বাকিরা

S3 File Gateway হলো চার ধরনের gateway-এর একটা। এই লেসনে বাকিগুলো শুধু প্রসঙ্গ হিসেবে জানলেই চলবে; chapter ১২-এ বিস্তারিত আছে।

• Volume Gateway তোমার server-কে iSCSI দিয়ে block storage দেয় (disk, ফাইল না); পেছনে থাকে S3, আর backup হয় EBS snapshot হিসেবে। দুটো ধরন:
  • Cached volume: পুরো data থাকে AWS-এ; শুধু ঘনঘন ব্যবহার হওয়া data অফিসে cache হয়, কম latency-র জন্য। মূল কপি cloud-এ রাখতে চাইলে এটা।
  • Stored volume: পুরো data অফিসেই থাকে, সবচেয়ে কম latency-র জন্য, আর gateway asynchronous ভাবে নির্দিষ্ট সময়ের backup AWS-এ EBS snapshot হিসেবে পাঠায়। সবকিছু local রাখতেই হবে, কিন্তু অফিসের বাইরে backup চাও, তখন এটা।
• Tape Gateway আসল tape-এর জায়গা নেয় (নিচের উদাহরণ দেখো)। এটা একটা VTL, virtual tape library: তোমার backup software iSCSI দিয়ে একে tape drive আর media changer হিসেবে দেখে। Virtual tape-গুলো থাকে S3-এ; backup software কোনো tape eject (archive) করলে সেটা চলে যায় S3 Glacier Flexible Retrieval বা Glacier Deep Archive-এ।
• Amazon FSx File Gateway অফিসগুলোকে একটা FSx for Windows File Server share-এর সামনে local cache দিত। ২৮ অক্টোবর ২০২৪ থেকে এটা নতুন customer-দের জন্য বন্ধ; পুরনোরা চালিয়ে যেতে পারে।

#পথ ৭: AWS DataSync

#এটা কী, আর data কীভাবে সরায়

AWS DataSync হলো network দিয়ে বিপুল data copy করার একটা managed service, দ্রুত আর নিরাপদে, একবার বা schedule ধরে। একে একটা পেশাদার মালপত্র সরানোর কোম্পানি ভাবো: গুছিয়ে বাঁধে, নিয়ে যায়, কিছু ভাঙল কি না মিলিয়ে দেখে, তারপর চলে যায়। Gateway-এর মতো data-র পথে সে থেকে যায় না।

• কোথা থেকে, কোথায়। অফিসে: NFS, SMB, HDFS (Hadoop) আর S3 API বোঝে এমন নিজের চালানো object storage। AWS-এ: S3 (যেকোনো storage class, Glacier Flexible Retrieval আর Deep Archive-সহ), EFS, আর সব FSx file system। অন্য cloud: Google Cloud Storage, Azure Blob Storage আর Azure Files, আর Wasabi, Oracle, Cloudflare R2-এর মতো S3-compatible store।
• Agent। অফিসের storage-এর জন্য একটা DataSync agent বসাতে হয়: একটা VM (VMware, Hyper-V, KVM) বা একটা EC2 instance, যেটা storage-এর কাছে বসে NFS, SMB বা HDFS দিয়ে পড়ে। File server-এর নিজের গায়ে কিছুই install হয় না। একই account-এর AWS storage service-গুলোর মধ্যে, বা S3 আর অন্য cloud-এর object storage-এর মধ্যে agent লাগে না।
• Transfer। একটা task-এ থাকে source location, destination location আর কিছু option। Agent একসাথে অনেক ফাইল পড়ে আর AWS-এর নিজের protocol-এ TLS দিয়ে পাঠায়; সেই protocol পথে compress করে, sparse file চেনে, আর লম্বা, ব্যস্ত link-কে ভরিয়ে রাখে। একটা task প্রায় ১০ Gbps পর্যন্ত ব্যবহার করতে পারে; বড় কাজে কয়েকটা agent আর task একসাথে চালানো যায়।
• Incremental। Default-এ প্রতিটা run শুধু সেই data copy করে যা আগের run-এর পর নতুন এসেছে বা বদলেছে; ফলে প্রথম run সব নেয়, পরেরগুলো নেয় শুধু পার্থক্যটুকু।
• Schedule। Task চলতে পারে প্রতি ঘণ্টা, প্রতিদিন বা প্রতি সপ্তাহে (notes-এর উদাহরণ: প্রতি রাত ১২টায়)।
• Bandwidth limit। একটা task-এর bandwidth বেঁধে দেওয়া যায়, যেমন অফিসের সময়ে।
• যাচাই। DataSync যা পড়েছে আর যা লিখেছে, দুটোর checksum মেলায়, না মিললে সেই ফাইলের কথা report করে। শুধু যা পাঠানো হলো সেটা, পুরো destination, বা কিছুই না, তিনভাবেই যাচাই বাছা যায়।
• Metadata। File permission আর metadata (NFS-এর POSIX মালিকানা আর permission, SMB-এর attribute আর ACL, সময়) থেকে যায়; EFS বা FSx-এ copy করার সময় এটা জরুরি, কারণ user-দের permission ঠিক থাকতে হবে।
• Filter আর report। কোন ফাইল নেবে বা বাদ দেবে তার pattern, আর task report, যেখানে প্রতিটা ফাইল পাঠানো, বাদ পড়া বা fail হওয়ার হিসাব থাকে।

খরচ। Copy করা প্রতি GB-তে টাকা: Basic mode-এ প্রতি GB $0.0125, অথবা Enhanced mode-এ প্রতি GB $0.015 আর প্রতি task execution-এ $0.55। Enhanced mode নতুন একটা mode, S3, অন্য cloud আর NFS/SMB থেকে S3-এর transfer-এর জন্য, যেটা প্রায় সীমাহীন সংখ্যক ফাইল সামলাতে পারে। সাথে S3-এর সাধারণ request charge আর source থেকে বের হওয়া data transfer-এর দাম। Agent-এর জন্য আলাদা কোনো টাকা নেই।

#DataSync, নাকি Storage Gateway?

Owner-এর notes ঠিক এই জোড়া নিয়েই সাবধান করেছে, আর পার্থক্যটা এক শব্দে: copy বনাম extension।

এরা প্রায়ই একসাথে চলে: বছরের পর বছরের ফাইলের বড় প্রথম copy-টা DataSync দিয়ে, তারপর যে application-গুলো নতুন ফাইল লিখতেই থাকবে তাদের জন্য একটা File Gateway।

#পথ ৮: AWS Snowball

#ট্রাকে করে data পাঠানো কেন

কখনো কখনো সমস্যাটা network-এই। Link ধীর, পুরো অফিস মিলে ভাগ করে চালায়, দামি, অস্থির, বা একেবারেই নেই (জাহাজ, খনি, দুর্যোগের এলাকা)। তখন data একটা device-এ ভরে ডাকে পাঠানোই দ্রুত। এটাই AWS Snowball: নিরাপদ, শক্তপোক্ত, বহনযোগ্য device, AWS-এ data offline-এ আনা-নেওয়া আর edge-এ computing-এর জন্য। Terabyte থেকে petabyte পর্যন্ত সামলায়।

এখনকার device হলো Snowball Edge:

একটা job কীভাবে চলে:

1. Console-এ একটা job বানাও: S3-এ import, S3 থেকে export, বা শুধু local compute আর storage। Bucket আর পৌঁছানোর ঠিকানা বেছে দাও।
2. AWS device পাঠায়। তার E Ink পর্দায় shipping label দেখা যায়।
3. Local network-এ (১০ থেকে ১০০ Gb Ethernet) লাগাও, job-এর manifest file আর unlock code দিয়ে unlock করো, তারপর S3-compatible endpoint বা NFS mount দিয়ে data copy করো। Local network-এর গতিতে ২০০ TB-ও এক-দুই দিনে ভরে যায়।
4. বন্ধ করো; E Ink label বদলে ফেরত ঠিকানা দেখায়; courier নিয়ে যায়।
5. AWS data তোমার bucket-এ import করে, তারপর NIST standard মেনে device মুছে ফেলে। Job-এর অবস্থা console-এ দেখতে পাও।

Security। সবকিছু AWS KMS-এ রাখা ২৫৬-bit key দিয়ে encrypt করা; key কখনো device-এ থাকে না। Device-টা সহজে খোলা যায় না, আর manifest আর unlock code ছাড়া পথে হারালেও কিছু ফাঁস হয় না।

খরচ। প্রতি job-এ একটা service fee (তাতে কিছু দিন সাইটে রাখা ধরা থাকে), বাড়তি দিনের জন্য দৈনিক fee, আর shipping। S3-এ data ঢোকাতে প্রতি GB-র কোনো transfer charge নেই; S3 থেকে export করলে প্রতি GB-তে টাকা লাগে।

#Network-এ কত সময় লাগত?

হিসাবটা সহজ, আর পরীক্ষার অনেক প্রশ্নে আসে:

সময় = bit-এ data ÷ কাজে লাগানো যায় এমন link-এর গতি

১ TB মানে ৮,০০০ gigabit (দশমিক একক, network যেভাবে গোনে)। Link খুব কমই ১০০%-এ চলে, কারণ অন্য traffic-ও ভাগ বসায়, তাই প্রায় ৮০% ধরে পরিকল্পনা করো:

হাতে-কলমে উদাহরণ: ১ Gbps-এ ১০০ TB = ৮,০০,০০০ gigabit ÷ ০.৮ Gbps = ১০,০০,০০০ সেকেন্ড = ১১.৬ দিন (একদম নিখুঁত ১০০%-এও ৯.৩ দিন)। Snowball দিয়ে: device আসতে ২-৩ দিন, local গতিতে ভরতে প্রায় এক দিন, ফেরত যেতে ২-৩ দিন, import-এ এক দিন: মোটামুটি এক সপ্তাহ, একটা device-এর ২১০ TB পর্যন্ত আকার যাই হোক, কারণ কয়েকটা device একসাথে ভরা যায়।

হাতের নিয়ম: network-এ মোটামুটি এক সপ্তাহের বেশি লাগলে Snowball নাও।

#Snowball সরাসরি Glacier-এ import করতে পারে না

পরীক্ষার খুব প্রিয় একটা ফাঁদ। তোমার কাছে একগাদা পুরনো data, শুধু archive করে রাখতে হবে। Snowball job কি এটা সরাসরি S3 Glacier বা Glacier Deep Archive-এ রাখতে পারে? না। Snowball import সবসময় S3-এ নামে (default-এ Standard)। সমাধান:

1. আগের মতোই S3 Standard-এ import করো।
2. Device ফেরত পাঠানোর আগেই bucket-এ (বা prefix-এ) একটা S3 lifecycle rule দাও, যেটা ০ দিন পরে object-গুলো Glacier Flexible Retrieval বা Deep Archive-এ transition করে।
3. Import-এর এক-দুই দিনের মধ্যে object-গুলো archive class-এ চলে যায়, তাই Standard-এর storage-এর দাম দিতে হয় অল্প সময়ের জন্য।

DataSync-এর সাথে তুলনা করো: সে Glacier class-এ সরাসরি লিখতে পারে। আর মনে রাখো, S3 File Gateway লেখে শুধু Standard, IA বা Intelligent-Tiering-এ। Offline আর gateway, দুই ক্ষেত্রেই Glacier পর্যন্ত সেতু হলো lifecycle rule।

#Snowball Edge দিয়ে edge computing

Edge computing মানে data যেখানে তৈরি হয় সেখানেই প্রক্রিয়া করা, এমন জায়গায় যেখানে internet সীমিত আর computing power নেই: রাস্তায় চলা ট্রাক, সমুদ্রে জাহাজ, মাটির নিচের খনি। একটা Snowball Edge (Compute Optimized এই কাজের জন্যই বানানো; Storage Optimized-ও ছোট workload চালাতে পারে) সাইটেই EC2 instance আর Lambda function চালায়, যেমন sensor data আগেভাগে প্রক্রিয়া করা, machine learning inference চালানো বা video transcode করা, আর পরে ফলাফল AWS-এ পাঠিয়ে দেয়।

#আজকের Snow Family, আর পরীক্ষা কী চায়

Snow Family অনেক বদলেছে, আর notes আর অনেক practice question পুরনো লাইন-আপের কথা বলে:

• AWS Snowcone (ছোট, বহনযোগ্য device: ৮ TB HDD বা ১৪ TB SSD; ড্রোন, ফায়ার স্টেশন, কারখানা আর যেখানে জায়গা কম বা internet নেই সেখানে) ১২ নভেম্বর ২০২৪-এ বন্ধ হয়েছে।
• AWS Snowmobile (shipping container-ওয়ালা একটা ট্রাক, ১০০ PB পর্যন্ত, exabyte মাপের সরানোর জন্য) ২০২৪-এ অবসরে গেছে।
• পুরনো Snowball Edge model-গুলো (৮০ TB Storage Optimized, ৫২-vCPU আর GPU-ওয়ালা Compute Optimized) নভেম্বর ২০২৪-এ বন্ধ হয়ে ওপরের ২১০ TB আর ২৮ TB model এসেছে।
• ৭ নভেম্বর ২০২৫ থেকে Snowball Edge শুধু পুরনো customer-দের জন্য: নতুন customer-কে AWS আর কোনো Snow device দেয় না। নতুনদের AWS দেখায় online transfer-এর জন্য DataSync (গতির জন্য অস্থায়ী একটা hosted Direct Connect connection সহ), AWS Data Transfer Terminal (AWS-এর কিছু সত্যিকারের জায়গা, যেখানে নিজের drive নিয়ে গিয়ে খুব দ্রুত upload করা যায়) বা partner-দের offline service, আর edge computing-এর জন্য AWS Outposts।

#পথ ৯: S3 Transfer Acceleration

#আগেভাগে AWS-এর মহাসড়কে ওঠা

অনেক দূরের পথে বড় upload-এর জন্য public internet ধীর। প্রতিটা packet অনেকগুলো network পার হয়; Sydney থেকে Virginia যাওয়া-আসায় প্রায় ২০০ ms লাগে; কিছু packet হারায়; আর loss দেখলেই TCP গতি কমায়। দ্রুত একটা অফিস লাইনও দূরের bucket পর্যন্ত তার গতির সামান্য অংশই পৌঁছাতে পারে।

S3 Transfer Acceleration লম্বা অংশটা সারিয়ে দেয়। Bucket-এ এটা চালু করো, আর client একটা বিশেষ endpoint ব্যবহার করে, bucketname.s3-accelerate.amazonaws.com (IPv6-এর জন্য bucketname.s3-accelerate.dualstack.amazonaws.com)। DNS প্রতিটা client-কে পাঠায় সবচেয়ে কাছের CloudFront edge location-এ, অল্প একটু পথ। সেখান থেকে data bucket-এর Region-এ যায় AWS-এর private backbone দিয়ে, tune করা, আগে থেকে চালু connection-এ। Bucket, তার object, তার Region কিছুই বদলায় না; বদলায় শুধু পথটা।

• শর্ত: bucket-এর নাম DNS-মানা হতে হবে, কোনো dot (.) থাকবে না; request virtual-hosted style-এ হতে হবে; চালু করতে পারে শুধু bucket-এর মালিক (বা যার s3:PutAccelerateConfiguration আছে); গতি বাড়তে ২০ মিনিট পর্যন্ত লাগতে পারে। বেশিরভাগ commercial Region-এর general purpose bucket-এ চলে।
• Multipart upload-এর সাথে মেলাও (লেসন ১০.১২): প্রতিটা part একসাথে দ্রুত পথ ধরে। দূরের পথে AWS প্রায় ৫০% থেকে কয়েকশো শতাংশ পর্যন্ত উন্নতির কথা বলে।
• খরচ: S3-এর সাধারণ দামের ওপর, United States, ইউরোপ আর জাপানের edge দিয়ে upload-এ প্রতি GB $0.04, বাকি সব edge দিয়ে প্রতি GB $0.08; download-এ প্রতি GB $0.04। কোনো accelerated transfer সাধারণটার চেয়ে দ্রুত হয়নি বলে AWS দেখলে, সেটার acceleration fee নেয় না। Speed Comparison tool তোমার জায়গা থেকে কতটা লাভ হবে, দেখায়।
• কখন কাজে আসে না: user যদি bucket-এর Region-এর কাছেই থাকে, ছোট ছোট object যেখানে latency-ই মূল বিষয়, বা link নিজেই যদি খুব ছোট হয়।

Transfer Acceleration CloudFront-এর edge location ব্যবহার করে, কিন্তু এটা CloudFront না: CloudFront হলো এমন content-এর সামনে একটা cache, যেটা অনেক মানুষ download করে (chapter ১১), আর acceleration মূলত আলাদা আলাদা object-এর upload (আর download)-এর জন্য দ্রুত একটা প্রবেশপথ। এর কাছাকাছি আরেকটা ধারণা, Global Accelerator, যেকোনো TCP বা UDP traffic AWS backbone দিয়ে পাঠায় (সেটাও chapter ১১)। পুরো S3-এর performance tuning-এর জন্য দেখো লেসন ১০.৬।

#পথ ১০: AWS Transfer Family

#Managed file transfer server

হাজার হাজার ব্যবসায়িক কাজ এখনো পুরনো, ভরসার protocol দিয়ে ফাইল আদান-প্রদান করে: partner-দের কাছ থেকে bank-এর payment file নেওয়া, supplier-দের সাথে retailer-এর order বিনিময়, হাসপাতালে lab-এর ফলাফল আসা। Partner-দের script আর tool SFTP, FTPS বা FTP বোঝে, আর সেগুলো বদলানোর প্রশ্নই ওঠে না। আগে তুমি নিজেই একটা SFTP server চালাতে: patch করো, scale করো, backup নাও, সেখান থেকে ফাইল storage-এ copy করো।

AWS Transfer Family হলো একটা পুরোপুরি managed file transfer service, যেটা Amazon S3 বা Amazon EFS-এর সামনে একটা server endpoint বসায়:

• Protocol: SFTP (SSH-এর ওপর), FTPS (TLS-এর ওপর FTP), FTP (encrypt ছাড়া), আর AS2 (signed রসিদ সহ business-to-business standard, supply chain আর payment-এ খুব চলে)। ২০২৪-এর শেষ থেকে আছে Transfer Family web app-ও, business user-দের জন্য browser দিয়ে S3-এ ফাইল upload আর download করার উপায়।
• Endpoint: একটা public endpoint (শুধু SFTP), অথবা একটা VPC endpoint, যেটা হয় internal, নয়তো Elastic IP address আর security group সহ internet-facing। সাধারণ FTP চলে শুধু internal VPC endpoint-এ, internet দিয়ে কখনো না। Route 53 দিয়ে সামনে নিজের DNS নাম বসাতে পারো। Endpoint সর্বোচ্চ তিনটা AZ জুড়ে চলে, নিজে থেকেই scale করে।
• Identity: service-managed user (SSH key service-এর ভেতরেই রাখা; শুধু SFTP), AWS Directory Service for Microsoft AD, অথবা Lambda বা API Gateway দিয়ে একটা custom identity provider (LDAP, Okta, Amazon Cognito, অন্য যেকোনো কিছু)।
• Access: প্রতিটা user-এর একটা IAM role থাকে, যেটা ঠিক করে ওই user-এর হয়ে server bucket-এ কী করতে পারবে, সাথে ইচ্ছা হলে একটা session policy আর একটা home directory। Logical directory user-এর “/”-কে inbound/partner-a/-এর মতো একটা prefix-এর সাথে জুড়ে দেয় (chroot), তাই user কখনো bucket-এর নাম বা একে অপরকে দেখে না।
• Upload-এর পরে: ফাইলটা একটা সাধারণ object, তাই S3 event notification (লেসন ১০.৭) বা Transfer Family-র managed workflow (copy, tag, decrypt, scan, বা যেকোনো Lambda ধাপ) সাথে সাথে কাজ শুরু করতে পারে। SFTP connector দিয়ে AWS নিজেও partner-এর SFTP server-এ ফাইল পাঠাতে পারে।
• খরচ: endpoint-এ চালু প্রতিটা protocol-এর জন্য ঘণ্টাপ্রতি (us-east-1-এ প্রায় $0.30, অলস পড়ে থাকলেও), সাথে upload বা download-এর প্রতি GB-তে প্রায় $0.04; AS2-এর বিল হয় message ধরে, web app-এর unit-ঘণ্টা ধরে।

#পাঁচটা পাশাপাশি

Chooser-টা চালিয়ে দেখো: data-র আকার আর link বদলে দেখো কোথায় গিয়ে network আর উত্তর থাকে না, আর data কে পাঠায় সেটা বদলে দেখো কীভাবে protocol-ই সিদ্ধান্ত নেয়।

#কোথায় ভুল হয়

• প্রশ্ন দেখে না, অভ্যাস দেখে বাছা। “Data সরাতে হবে” যথেষ্ট না। জিজ্ঞেস করো: online না offline? একবার না চিরকাল? অফিসের app-এর share লাগবে কি? কে পাঠায়? পাঁচটার প্রতিটা আলাদা একটা মিশ্রণের উত্তর।
• Snowball থেকে সরাসরি Glacier। সম্ভব না; S3-এ import করো আর device ফেরত পাঠানোর আগেই ০ দিনের lifecycle rule দাও।
• Source আগেভাগে মুছে ফেলা। Import বা DataSync-এর যাচাই report প্রতিটা ফাইল নিশ্চিত না করা পর্যন্ত মূল data রাখো। হারানো device বা fail হওয়া ফাইল আবার পাঠাতে হবে।
• খুব ছোট gateway cache। প্রতিটা read হয়ে যায় ধীর miss, আর outage-এর সময় জমে থাকা upload cache ভরিয়ে write ধীর করে দিতে পারে। Cache-এর মাপ ঠিক করো সাপ্তাহিক working set আর জমে থাকা upload মিলিয়ে।
• Gateway-কে না জানিয়ে bucket-এ লেখা। অন্য কোনো process সরাসরি bucket-এ object রাখলে, gateway-এর cache refresh না হওয়া পর্যন্ত (হাতে, schedule ধরে বা automatic refresh setting দিয়ে) gateway সেগুলো list-এ দেখায় না। আর দুটো gateway-কে কখনো একই prefix-এ লিখতে দিও না: ওদের মধ্যে কোনো file locking নেই।
• File share-এর পেছনে archive হয়ে যাওয়া object। Lifecycle দিয়ে Glacier Flexible Retrieval বা Deep Archive-এ গেলে restore না করা পর্যন্ত share দিয়ে সেই ফাইল পড়া যায় না। মানুষ আসলে যেভাবে পড়ে, সেই মাপে transition-এর দিন ঠিক করো।
• বদলাতে থাকা ফাইল copy করা। DataSync-এর যাচাই এগুলো ধরে ফেলবে; user-রা লেখা থামালে একটা incremental pass চালাও, আর cut-over-এর জন্য অল্প সময়ের একটা freeze রাখো।
• অফিসের link পুরো দখল করে ফেলা। একটা DataSync task ১০ Gbps নিতে পারে; bandwidth limit দাও বা অফিসের সময়ের বাইরে schedule করো।
• Dot-ওয়ালা bucket-এর নাম আর Transfer Acceleration। এগুলো accelerate হয় না। Bucket-এর নাম বদলানো যায় না; নতুন একটা বানিয়ে copy করো।
• Acceleration দিয়ে ছোট link সারানোর আশা। এটা লম্বা পথকে ভালো করে; bandwidth বানাতে পারে না।
• Internet-এ সাধারণ FTP। Transfer Family এটা চালাতে দেয় না; SFTP বা FTPS নাও, অথবা VPN বা Direct Connect দিয়ে একটা internal VPC endpoint।
• অলস Transfer Family endpoint। চালু প্রতিটা protocol-এর বিল প্রতি ঘণ্টায় হয়, traffic না থাকলেও। Test endpoint আর অব্যবহৃত protocol মুছে ফেলো।

#System design-এ

• দুই ধাপের migration: প্রথমে বড় চালান (network দিয়ে DataSync, অথবা network-এ কয়েক সপ্তাহ লাগলে Snowball), তারপর cut-over পর্যন্ত ক্রমাগত sync (schedule দেওয়া DataSync)। বিশাল পরিমাণের জন্য প্রায়ই Direct Connect দিয়ে link-টাকেই সাময়িকভাবে বড় করা হয় (লেসন ১০.১০, chapter ২২)।
• দীর্ঘমেয়াদি hybrid: যে application-কে অফিসে file share রাখতেই হবে, তার জন্য S3 File Gateway; block volume-এর জন্য Volume Gateway; tape library বিদায় দিতে Tape Gateway। Gateway-এর traffic Direct Connect বা VPN-এ রাখো, আর internet পার হওয়া না চলে তো VPC Interface endpoint দিয়ে S3-এ পৌঁছাও (লেসন ১০.১০)।
• মানুষ আর partner-এর কাছ থেকে data নেওয়া: partner আর পুরনো protocol-এর জন্য Transfer Family, দূরের user-এর জন্য Transfer Acceleration আর multipart upload, নিজের app-এর browser upload-এর জন্য pre-signed URL (লেসন ১০.১২)।
• সস্তায় archive: data যেভাবেই আসুক, একটা lifecycle rule সেটা Glacier Flexible Retrieval বা Deep Archive-এ সরায়। পাঁচটা bulk পথের মধ্যে একমাত্র DataSync-ই সেখানে সরাসরি লিখতে পারে।
• পৌঁছানোর সাথে সাথে কাজ: প্রতিটা পথ শেষ হয় S3-এর object-এ, তাই ফাইল নামার সাথে সাথে S3 event বা EventBridge (লেসন ১০.৭) কাজ শুরু করতে পারে।

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

S3 File Gateway (gateway VM বসিয়ে activate করার পর):

# Create an NFS share on the gateway that maps to a bucket, writing as S3 Standard
aws storagegateway create-nfs-file-share \
  --client-token pacs-share-1 \
  --gateway-arn arn:aws:storagegateway:us-east-1:111122223333:gateway/sgw-12A3456B \
  --role arn:aws:iam::111122223333:role/FileGatewayS3Access \
  --location-arn arn:aws:s3:::hospital-scans-example \
  --default-storage-class S3_STANDARD \
  --client-list 10.20.0.0/16

# Make the gateway notice objects written to the bucket by something else
aws storagegateway refresh-cache --file-share-arn <share-arn>

# On a Linux server on premises: mount it like any NFS share
sudo mount -t nfs -o nolock,hard 10.20.1.15:/hospital-scans-example /mnt/scans

Share-এর ফাইল archive করার একটা lifecycle rule (Days 0 দিলে এটাই Snowball থেকে Glacier-এর কৌশল):

aws s3api put-bucket-lifecycle-configuration --bucket hospital-scans-example \
  --lifecycle-configuration '{"Rules":[{"ID":"archive-scans","Status":"Enabled",
    "Filter":{"Prefix":"scans/"},
    "Transitions":[{"Days":180,"StorageClass":"DEEP_ARCHIVE"}]}]}'

DataSync, অফিসের NFS server থেকে S3-এ, প্রতি রাতে, যাচাই সহ:

aws datasync create-location-nfs --server-hostname 10.20.1.40 \
  --subdirectory /photos --on-prem-config AgentArns=<agent-arn>
aws datasync create-location-s3 --s3-bucket-arn arn:aws:s3:::news-photos-example \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Access
aws datasync create-task --name photos-nightly \
  --source-location-arn <nfs-location-arn> --destination-location-arn <s3-location-arn> \
  --schedule ScheduleExpression="cron(0 0 * * ? *)" \
  --options VerifyMode=ONLY_FILES_TRANSFERRED,TransferMode=CHANGED,BytesPerSecond=37500000
aws datasync start-task-execution --task-arn <task-arn>
aws datasync describe-task-execution --task-execution-arn <execution-arn>

(BytesPerSecond=37500000 মানে ৩০০ Mbps।)

Snowball (পুরনো customer-দের জন্য):

aws snowball create-job --job-type IMPORT \
  --resources '{"S3Resources":[{"BucketArn":"arn:aws:s3:::studio-footage-example"}]}' \
  --address-id <address-id> --role-arn arn:aws:iam::111122223333:role/SnowballImport \
  --snowball-type V3_5S --snowball-capacity-preference T240 --shipping-option SECOND_DAY
aws snowball describe-job --job-id <job-id>
aws snowball get-job-unlock-code --job-id <job-id>

Transfer Acceleration:

aws s3api put-bucket-accelerate-configuration --bucket media-central-example \
  --accelerate-configuration Status=Enabled
aws s3api get-bucket-accelerate-configuration --bucket media-central-example

# Upload through the accelerated endpoint (the CLI uses multipart for big files)
aws s3 cp ./shoot-0425.zip s3://media-central-example/sydney/ \
  --endpoint-url https://s3-accelerate.amazonaws.com
# or set it once: aws configure set default.s3.use_accelerate_endpoint true

Transfer Family, একটা SFTP endpoint, যেখানে একজন partner নিজের prefix-এ আটকানো:

aws transfer create-server --protocols SFTP --identity-provider-type SERVICE_MANAGED \
  --endpoint-type PUBLIC --domain S3
aws transfer create-user --server-id s-1234567890abcdef0 --user-name partner-a \
  --role arn:aws:iam::111122223333:role/TransferPartnerAccess \
  --home-directory-type LOGICAL \
  --home-directory-mappings '[{"Entry":"/","Target":"/bank-inbound-example/inbound/partner-a"}]' \
  --ssh-public-key-body "ssh-ed25519 AAAAC3Nza... partner-a"

# What the partner runs (unchanged from before)
sftp -i partner-a.key partner-a@s-1234567890abcdef0.server.transfer.us-east-1.amazonaws.com

#সারসংক্ষেপ

মূল কথাগুলো

• S3-তে পৌঁছানোর ১৩টা পথ: network-এর রাস্তা (১০.১০), bulk পথ (এই লেসন), application-এর পথ (১০.১২)। পাঁচটা bulk পথ আলাদা আলাদা প্রশ্নের উত্তর; জিজ্ঞেস করো online না offline, একবার না চলমান, file share লাগবে কি না, কে পাঠায়।
• S3 File Gateway: অফিসে একটা NFS (v3, v4.1) বা SMB (v2, v3) share, চলে VM বা EC2 instance হিসেবে; সাম্প্রতিক ফাইলের জন্য local cache; ১ ফাইল = ১ object; Standard / IA / One Zone-IA / Intelligent-Tiering, তারপর lifecycle দিয়ে Glacier; প্রতি share-এ একটা IAM role; SMB-এর জন্য AD। স্থায়ী, data-র পথে থেকে যায়।
• অন্য gateway: Volume (iSCSI block; cached = data AWS-এ, stored = data অফিসে; EBS snapshot), Tape (iSCSI-তে VTL, tape S3-এ, eject করলে Glacier/Deep Archive), FSx File (অক্টোবর ২০২৪ থেকে নতুন customer-দের জন্য বন্ধ)।
• DataSync: agent-ভিত্তিক (AWS থেকে AWS বা S3 থেকে অন্য cloud-এ লাগে না) copy আর sync; NFS, SMB, HDFS, object storage, অন্য cloud → S3 (যেকোনো class, সরাসরি Glacier), EFS, FSx; প্রতি task-এ প্রায় ১০ Gbps; schedule, incremental, bandwidth limit, যাচাই, metadata থাকে; প্রতি GB-তে দাম। Copy, extension না।
• Snowball Edge: offline device (২১০ TB Storage Optimized, ২৮ TB Compute Optimized); অর্ডার → পাঠানো → local-এ copy → ফেরত → import; KMS দিয়ে encrypt; S3-এ import বিনা পয়সায়। Network-এ এক সপ্তাহের বেশি → ডাকে পাঠাও। Glacier-এ import হয় না: S3-এ import, ০ দিনের lifecycle rule। Snowcone আর Snowmobile অবসরে, নভেম্বর ২০২৫ থেকে Snowball শুধু পুরনো customer-দের জন্য, কিন্তু পরীক্ষা এখনো এই উত্তরগুলোই চায়।
• Transfer-এর সময় = bit ÷ কাজের গতি: ১ Gbps আর ৮০%-এ ১০০ TB ≈ ১১.৬ দিন।
• Transfer Acceleration: s3-accelerate endpoint → সবচেয়ে কাছের edge location → AWS backbone; bucket-এর নামে dot চলবে না; প্রতি GB-তে বাড়তি $0.04 বা $0.08, দ্রুত না হলে টাকা নেই; দূরের পথে multipart-এর সাথে সবচেয়ে ভালো।
• Transfer Family: managed SFTP, FTPS, FTP, AS2 (আর web app), গন্তব্য S3 বা EFS; FTP শুধু VPC-র ভেতরে; service-managed (SFTP), AD বা custom identity; প্রতি user-এ IAM role + logical home directory; বিল protocol-ঘণ্টা + প্রতি GB।

নিজেকে যাচাই করো: S3-তে একসঙ্গে অনেক data৩০টি প্রশ্ন