Transfer Family, DataSync আর পুরো Storage-এর ম্যাপ

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

• AWS Transfer Family কোন জিনিসের জায়গা নেয় তা বোঝাতে, আর একটা session-কে login থেকে শুরু করে identity provider, IAM role আর home directory হয়ে S3 বা EFS পর্যন্ত অনুসরণ করতে।
• SFTP, FTPS, FTP আর AS2-এর জন্য ঠিক endpoint type (public, VPC internet-facing, VPC internal) বেছে নিতে, আর একদল user-এর জন্য ঠিক identity provider বাছতে।
• File পৌঁছানোর পর managed workflow দিয়ে সেটা process করতে, আর endpoint-hour আর gigabyte থেকে Transfer Family-র বিল আন্দাজ করতে।
• একটা DataSync migration তার অংশগুলো (agent, location, task, schedule, execution) দিয়ে সাজাতে, একটা run-এর প্রতিটা phase বোঝাতে, আর task option, task mode ও network endpoint বেছে নিতে।
• একটা DataSync copy আর তার রাতের run-গুলোতে কত সময় আর কত টাকা লাগবে হিসাব করতে, আর কখন network আর উত্তর না, সেটা ঠিক করতে।
• DataSync-কে Storage Gateway, Snowball, Transfer Family আর S3 Transfer Acceleration থেকে এক বাক্যে আলাদা করতে, আর প্রশ্নের শব্দ দেখে এদের মধ্যে বেছে নিতে।
• Course-এর সবগুলো storage service (S3, Glacier class, EBS, instance store, EFS, চারটা FSx file system, Storage Gateway, Transfer Family, DataSync, Snowball, আর database) একটা ম্যাপে বসাতে, আর কোনো scenario-র জন্য ঠিকটা বেছে নিতে।

#এই লেসন কোথায় বসে

লেসন ১০.১১-এ S3-এ data পৌঁছানোর পথগুলোর মধ্যে DataSync ছিল “Path 7” আর Transfer Family ছিল “Path 10”: কোনটা কী, একটা বাস্তব উদাহরণ, আর File Gateway, Snowball ও Transfer Acceleration-এর সাথে পাঁচজনের তুলনা। এই লেসনটা তার গভীরে ডুব। এখানে আমরা একটা Transfer Family session আর একটা DataSync task-এর ভেতরে ঢুকব, বাস্তব project-এ যেসব option, সীমা, ব্যর্থতার ঘটনা আর দাম জানা লাগে সেগুলো দেখব, তারপর course-এর পুরো storage-এর ম্যাপ দিয়ে অধ্যায় ১২ শেষ করব।

এই অধ্যায়ের বাকি লেসনগুলো: ১২.১ Snowball আর edge computing, ১২.২ FSx-এর পরিবার আর ১২.৩ Storage Gateway। অধ্যায় ৫-এর storage service (EBS, instance store, EFS) আর অধ্যায় ১০-এর S3 ও তার storage class শেষের ম্যাপে আবার ফিরে আসবে।

#AWS Transfer Family

#কোম্পানিগুলো এখনো কেন file transfer server চালায়

File transfer protocol cloud-এর চেয়েও পুরোনো, আর এগুলো সবখানে আছে। Bank employer আর wallet-এর কাছ থেকে বেতন আর settlement-এর file পায়, garments রপ্তানিকারক ইউরোপের retailer-দের সাথে purchase order আদান-প্রদান করে, হাসপাতাল lab-এর রিপোর্ট পায়, সরকারি অফিস dataset প্রকাশ করে। অন্য পক্ষের কাছে আছে script, scheduler আর software, যেগুলো SFTP, FTPS বা FTP বোঝে, কিংবা business-to-business standard AS2, আর তোমার জন্য কেউ এগুলো নতুন করে লিখবে না।

তাই তুমি একটা file transfer server চালাও। মানে একটা EC2 instance বা data centre-এর একটা বাক্স, যেখানে SSH daemon চলছে, প্রতি মাসে patch, ভরে যাওয়া disk, text file-এ রাখা user আর key, নতুন file storage-এ copy করার একটা script, আর একটা single point of failure, যেটা রাতে কাউকে ঘুম থেকে তোলে।

AWS Transfer Family হলো এর managed রূপ: ওই protocol-গুলো দিয়ে Amazon S3 বা Amazon EFS-এ file ঢোকানো আর বের করার জন্য একটা পুরোপুরি managed service। তোমাকে কোনো server বা software সামলাতে হয় না। Slide-এর কথায়: infrastructure managed, scalable, নির্ভরযোগ্য আর highly available (সর্বোচ্চ তিনটা Availability Zone-এ চলে), টাকা দাও provision করা endpoint-এর প্রতি ঘণ্টা আর transfer হওয়া প্রতি gigabyte-এর জন্য, user-দের credential service-এর ভেতরেই রাখা যায়, আর আগে থেকে থাকা authentication system-এর সাথে জুড়ে নেওয়া যায়।

Slide-এ সাধারণ ব্যবহারগুলোর তালিকা: file শেয়ার করা, public dataset প্রকাশ করা, আর CRM ও ERP system-এর সাথে data আদান-প্রদান।

#একটা session, ধাপে ধাপে

Transfer Family-র সবকিছু চারটা জিনিসের ওপর দাঁড়িয়ে: একটা server (endpoint, তার protocol আর endpoint type সহ), একটা identity provider (কে login করতে পারবে), একজন user আর তার IAM role (সে কী করতে পারবে), আর একটা home directory (login করে সে কোথায় নামবে)।

1. Client server-এর hostname-এ connect করে: হয় AWS-এর নাম s-1234abcd.server.transfer.ap-southeast-1.amazonaws.com, নয়তো তোমার নিজের নাম, যেমন sftp.bank.example, যেটা Route 53 দিয়ে ওদিকে দেখানো (slide-এ Route 53-কে ঐচ্ছিক বলা আছে)। SFTP server তার host key দিয়ে নিজের পরিচয় প্রমাণ করে; পুরোনো server থেকে সরে এলে তার host key import করে নিতে পারো, তাতে client আগের মতোই একই fingerprint দেখে, কিছুই ভাঙে না।
2. Server identity provider-কে জিজ্ঞেস করে, username আর key বা password ঠিক আছে কি না।
3. উত্তরে থাকে user-এর IAM role, ঐচ্ছিক একটা session policy আর home directory।
4. এই session-এর জন্য server role-টা assume করে। প্রতিটা read আর write হয় ওই role-এর permission দিয়ে। Role-টাকে transfer.amazonaws.com-কে বিশ্বাস (trust) করতে হয়।
5. Upload সরাসরি S3-এ object হয়ে লেখা হয় (বা EFS-এ file হয়ে)। Client আর storage-এর মাঝখানে কোনো server-এর disk নেই।
6. Upload শেষ হলে একটা managed workflow file-টা process করতে পারে, আর S3 event (লেসন ১০.৭) বাকি যেকোনো কাজ শুরু করতে পারে।

পুরো শিকলটা দেখো, আর দেখো তিনভাবে সেটা ভাঙে:

#Endpoint type: কে server পর্যন্ত পৌঁছাতে পারে

Endpoint type ঠিক করে কে server পর্যন্ত পৌঁছাতে পারবে, আর কোন কোন protocol চালু করা যাবে।

তিনটা নিয়ম মনে রাখার মতো:

• সাধারণ FTP চালু করা যায় শুধু internal VPC endpoint-এ। FTP password খোলা লেখায় পাঠায়, তাই AWS এটাকে কখনো internet-এর সামনে খোলে না। Slide-ও একইভাবে আঁকে: FTP “only within VPC”।
• যে partner-রা তাদের firewall-এ address allowlist করে, তাদের জন্য লাগবে Elastic IP সহ internet-facing VPC endpoint, যেটা একটা security group দিয়ে আটকেও দেওয়া যায়। Public endpoint এর কোনোটাই পারে না।
• Security group-এ SFTP-র জন্য port 22 লাগে (বেছে নিলে 2222 বা 22000-ও), FTP বা FTPS-এর control channel-এর জন্য 21, আর data channel-এর জন্য 8192–8200। (পুরোনো একটা endpoint type, VPC_ENDPOINT, এখন আর বানানো যায় না; VPC ব্যবহার করো।)

#Identity provider: কে login করতে পারবে

Slide-এর “Microsoft Active Directory, LDAP, Okta, Amazon Cognito, custom” তালিকাটা এটাই: AD ভেতরেই আছে; বাকিগুলো যায় custom identity provider দিয়ে। Custom provider-এ function যদি ফাঁকা উত্তর দেয়, তার মানে “authenticated না”। আরেকটা কথা, Transfer Family এক বা দুই অক্ষরের username আর root নামটা ঢুকতেই দেয় না, কারণ password scanner-রা অনবরত এগুলোই চেষ্টা করে।

#Home directory, role আর server-এর পেছনের storage

• S3 backend। User-এর IAM role ঠিক করে bucket-এ কোন কাজ চলবে। একটা session policy প্রতিটা user-এর জন্য সেটা আরও সরু করে দেয়, তাই একটাই role অনেক partner-কে সামলাতে পারে। Logical directory user যা দেখে তাকে আসল জায়গার সাথে মিলিয়ে দেয়: partner দেখে /, যেটা আসলে payroll-example/inbound/acme/; সে কখনো bucket-এর নাম বা অন্যের folder দেখে না (একে বলে “chroot”)।
• EFS backend। অনুমতি নিয়ন্ত্রণ হয় প্রতিটা user-কে দেওয়া POSIX user ID আর group ID দিয়ে, ঠিক একটা Linux server-এর মতো, সাথে role। EFS তখন নাও, যখন file-গুলো এমন application পড়বে যেটা file system mount করে, যেমন EC2-তে চলা কোনো পুরোনো batch job।
• দুই ক্ষেত্রেই পরে file-টা সাধারণ data। S3-এ তুমি তার version রাখতে পারো, replicate করতে পারো, lifecycle দিয়ে Glacier-এ পাঠাতে পারো (লেসন ১০.৫), বা Athena দিয়ে query করতে পারো।

#File পৌঁছানোর পর: workflow, connector, AS2 আর web app

• Managed workflow। Server-এর সাথে জোড়া একটা workflow প্রতিটা upload-এর পরে চলে (চাইলে connection কেটে গিয়ে অর্ধেক upload হলেও)। ধাপগুলো: copy, tag, delete, decrypt (PGP) আর custom (যেকোনো Lambda function: malware scan, যাচাই, database-এ তোলা)। কোনো ধাপ ব্যর্থ হলে বদলে চলে workflow-এর exception handler, যেমন file-টা quarantine/-এ সরিয়ে কাউকে জানানো।
• SFTP connector। Transfer Family S3 থেকে একটা partner-এর বাইরের SFTP server-এ file পাঠাতেও পারে, বা সেখান থেকে file আনতে পারে, তাই বাইরে পাঠানোর জন্যও আলাদা server লাগে না।
• AS2। যে trading partner-রা AS2 চায় তাদের জন্য: message sign আর encrypt করা থাকে, প্রাপক sign করা রসিদ ফেরত পাঠায়, আর file জমা হয় S3-এ।
• Web app। Business user-দের জন্য একটা managed web page, যেখানে তারা S3-এর file দেখতে, upload আর download করতে পারে; sign-in হয় IAM Identity Center দিয়ে, অনুমতি আসে S3 Access Grants থেকে।

#দাম আর availability

হিসাবটা করে দেখি: ওপরের পরিবেশকের একটা server-এ SFTP আর FTPS: ২ × $0.30 × ৭২০ ঘণ্টা = মাসে $432, কেউ connect না করলেও, সাথে মাসে ৫০০ GB × $0.04 = $20। খরচের বড় অংশ endpoint-hour: test server মুছে ফেলো, অব্যবহৃত protocol বন্ধ রাখো। তিনটা পর্যন্ত AZ বাছতে বাড়তি টাকা লাগে না, আর S3, EFS, Lambda, CloudWatch-এর বিল আলাদা আসে, যেমন আসে।

#AWS DataSync

#DataSync কীসের জন্য

AWS DataSync network দিয়ে বিশাল পরিমাণ data সরায়, দ্রুত আর নিরাপদে, একবার বা নির্দিষ্ট সময় ধরে: অফিস (বা অন্য cloud) থেকে AWS-এ, AWS থেকে বাইরে, কিংবা AWS-এর এক storage service থেকে আরেকটায়, যেমন EFS থেকে S3-এ। Note-এ এর তিনটা বৈশিষ্ট্য বলা আছে: অফিসে একটা agent বসাতে হয়, data পাঠাতে সে নিজের দ্রুত protocol ব্যবহার করে, আর তাকে schedule করে দেওয়া যায় (যেমন প্রতি রাত ১২টায়)।

AWS storage-এর মালপত্র সরানোর কোম্পানি এটা: গুছিয়ে নেয়, সরায়, মিলিয়ে দেখে, তারপর চলে যায়। তোমার application যেখানে পড়ে বা লেখে, সেই জায়গা সে কখনো হয়ে ওঠে না।

#গঠনের অংশগুলো

Data কোথায় যেতে পারে, slide-এর তালিকাটা একটু গুছিয়ে:

• Agent লাগে: অফিসের বা অন্য cloud-এর storage (NFS, SMB, HDFS, S3 API বোঝে এমন নিজের object storage, Google Cloud Storage, Azure Files) থেকে AWS-এ বা উল্টো দিকে।
• Agent লাগে না: AWS-এর storage service-গুলোর মধ্যে (S3, EFS, FSx), আলাদা account আর Region হলেও, আর Enhanced mode-এ S3 ও অন্য cloud-এর object storage-এর মধ্যে।
• AWS-এ destination: S3-এর যেকোনো storage class, Glacier Instant Retrieval, Flexible Retrieval আর Deep Archive সহ; EFS; FSx for Windows File Server, Lustre, NetApp ONTAP আর OpenZFS।

Activation আর network। তুমি agent বসাও, browser থেকে একবার তার port 80-তে গিয়ে একটা activation key নাও (বা local console থেকে নাও), তারপর নিজের Region-এ activate করো। এরপর agent শুধু বাইরের দিকে HTTPS (port 443) connection খোলে, তাই ভেতরে ঢোকার কোনো firewall rule লাগে না। তার service endpoint হতে পারে public, FIPS, বা একটা VPC endpoint (AWS PrivateLink), যেটা transfer-কে তোমার VPN বা Direct Connect-এর ওপর রাখে, internet ছুঁতে দেয় না (লেসন ১০.১০)। পথে data encrypt হয় TLS 1.3 দিয়ে।

#একটা run-এ কী হয়

একটা task execution এই অবস্থাগুলো পার হয়:

প্রথম run সবকিছু copy করে; পরের প্রতিটা run copy করে শুধু যা নতুন বা বদলেছে (এটাই default, মানে incremental)। তাই একটা migration দেখতে এরকম: একটা বড় run, তারপর রাতের run-গুলো ছোট হতে হতে কয়েক মিনিটে নামে, তারপর cut-over-এর দিনে অল্প সময় লেখা বন্ধ রেখে শেষ একটা run।

#যে task option-গুলো গুরুত্বপূর্ণ

• কী copy হবে। Transfer mode: শুধু যা বদলেছে (default), বা সবকিছু। Include আর exclude filter (যেমন *.tmp বাদ), অথবা একটা manifest: copy করার file-গুলোর হুবহু তালিকা।
• মুছে ফেলা file। Default-এ source-এ মুছে ফেলা file destination-এ রয়ে যায়। হুবহু আয়না (mirror) চাইলে option বদলে মুছে ফেলতে বলো। যেসব S3 class-এর ন্যূনতম রাখার মেয়াদ আছে (Standard-IA, Glacier), সেখানে overwrite আর delete-এ আগেভাগে মোছার charge লাগতে পারে, তাই অনবরত বদলাতে থাকা folder সরাসরি Glacier-এ sync করার আগে ভেবে নাও।
• Metadata। POSIX মালিকানা, permission আর timestamp (NFS), NTFS ACL আর মালিক (SMB, FSx for Windows), আর object storage-এর tag ও metadata অটুট রাখে। Slide-এর “file permission আর metadata রক্ষা হয়” কথাটা এটাই।
• যাচাই। শুধু যা transfer হলো তা যাচাই করো, বা পুরো destination, বা বাদ দাও। Destination archive class হলে “শুধু transfer হওয়া data” বেছে নাও।
• Bandwidth। Agent সহ একটা task সর্বোচ্চ ১০ Gbps নিতে পারে (agent ছাড়া transfer-এ ৫ Gbps)। একটা bandwidth limit বসানো যায়, আর execution চলার সময়ও সেটা বদলানো যায়।
• Schedule। প্রতি ঘণ্টা, প্রতিদিন, প্রতি সপ্তাহ, বা একটা cron বা rate expression (ঘণ্টায় একবারের বেশি না), আর schedule চাইলে থামিয়ে রাখা যায়।
• Report আর log। Task report প্রতিটা file-এর হিসাব দেয়: transfer হলো, বাদ গেল, যাচাই হলো, নাকি ব্যর্থ; CloudWatch Logs আর EventBridge event দিয়ে ব্যর্থতায় alarm বসানো যায়।

#Basic mode আর Enhanced mode

২০২৪-এর শেষ থেকে প্রতিটা task-এর একটা task mode থাকে, task বানানোর সময় বেছে নিতে হয়:

Agent-এর নিজের কোনো দাম নেই। S3-এর request আর storage-এর সাধারণ charge, আর source থেকে বাইরে যাওয়া data-র খরচ (যেমন অন্য cloud থেকে) তবুও লাগে।

#কত সময়, কত টাকা?

লেসন ১০.১১-এর সেই একই সূত্র: সময় = bit-এ data ÷ ব্যবহারযোগ্য গতি, যেখানে ১ TB = ৮,০০০ gigabit।

হিসাব করে দেখি, garments group-এর ক্ষেত্রে: ৩০ TB = ২,৪০,০০০ Gb। অফিসের ১০ ঘণ্টায় ৩০০ Mbps আর রাতের ১৪ ঘণ্টায় ৮০০ Mbps (১ Gbps-এর ৮০%) ধরলে দিনে যায় ০.৩ × ৩৬,০০০ + ০.৮ × ৫০,৪০০ = ৫১,১২০ Gb, মোটামুটি ৬.৪ TB। তাই প্রথম copy-তে লাগে প্রায় ৪.৭ দিন। রাতের ২০ GB পরিবর্তন = ১৬০ Gb, ০.৮ Gbps-এ লাগে ২০০ সেকেন্ড। Basic mode-এ খরচ: (৩০,০০০ + ৩০ × ২০) GB × $0.0125 = প্রথম মাসে $382.50।

নিজের সংখ্যা দিয়ে চেষ্টা করো। প্রথম copy এক সপ্তাহ বা এক মাস পেরিয়ে গেলে রায়ও বদলে যায়:

#DataSync আর Snow Family, আগে আর এখন

লেসন ১২.১-এর Snow device-এর সাথে DataSync-এর দুটো যোগসূত্র এখন ইতিহাস: Snowcone-এ DataSync agent আগে থেকেই install করা থাকত, আর DataSync একটা Snowball Edge-এর S3-compatible storage থেকে copy করতে পারত। ১২ নভেম্বর ২০২৪ থেকে DataSync আর Snow device সমর্থন করে না, যেদিন Snowcone বন্ধ হলো। আজকের ধরনটা সোজা: বড় চালানটা Snowball Edge-এ (যেখানে এখনো order করা যায়), পরের পরিবর্তনগুলো network দিয়ে DataSync-এ। ২০২৫-এর আরেকটা অবসর: DataSync Discovery, যেটা অফিসের storage বিশ্লেষণ করে AWS-এ কোথায় যাবে তার পরামর্শ দিত, ২০ মে ২০২৫-এ বন্ধ হয়ে গেছে।

#DataSync নাকি Storage Gateway?

Note এক বাক্যে সীমারেখাটা টেনেছে: Storage Gateway হলো একটা চলমান storage-এর সম্প্রসারণ, যেটা তোমার local storage-এর অংশ হিসেবে কাজ করে; DataSync হলো data এক জায়গা থেকে আরেক জায়গায় copy করার বা স্থায়ীভাবে migrate করার tool।

এরা প্রায়ই একসাথে কাজ করে: DataSync দশ বছরের ইতিহাস একটা bucket-এ তোলে, তারপর যে application-গুলো নতুন file বানিয়েই চলেছে, সেগুলোকে একই bucket-এর একটা File Gateway share-এর দিকে দেখিয়ে দেওয়া হয়। DataSync যেহেতু gateway-কে না জানিয়ে লেখে, তাই gateway-এর cache refresh করো, যাতে share নতুন object-গুলো দেখায় (লেসন ১২.৩)।

#Transfer service বেছে নেওয়া

পাঁচটা transfer service (আর তাদের নিচের network line) আলাদা আলাদা প্রশ্নের উত্তর দেয়। প্রশ্নগুলো এই ক্রমে করো:

1. অফিসের application কি প্রতিদিন এই data ব্যবহার করে যাবে? হ্যাঁ → Storage Gateway (NFS/SMB-এর জন্য File, iSCSI disk-এর জন্য Volume, backup software-এর জন্য Tape)। পথে থেকে যায় শুধু এটাই।
2. Data কে পাঠায়? SFTP, FTPS, FTP বা AS2 ব্যবহার করা বাইরের কোম্পানি বা মানুষ → Transfer Family। Bucket থেকে দূরের আলাদা আলাদা user, HTTPS-এ upload করছে → S3 Transfer Acceleration।
3. নিজেদের server বা storage, আর network যথেষ্ট? Copy, migrate বা sync, schedule আর যাচাই সহ → DataSync।
4. Network-এ সপ্তাহ বা মাস লেগে যাবে? → Snowball Edge (offline), তারপর পরিবর্তনের জন্য DataSync। যেখানে Snow device তোমার নাগালে নেই: বড় বা সাময়িক Direct Connect line, AWS Data Transfer Terminal (নিজের drive নিয়ে AWS-এর একটা জায়গায় যাও), বা কোনো partner service।

দুটো প্রতিবেশী, যারা storage service না কিন্তু একই প্রশ্নে হাজির হয়: Site-to-Site VPN আর Direct Connect (লেসন ১০.১০) হলো রাস্তা, ট্রাক না: DataSync আর Storage Gateway এদের ওপর দিয়েই চলে। AWS DMS database সরায়, আর AWS Application Migration Service পুরো server সরায় (দুটোই অধ্যায় ২৩-এ, বিশাল পরিমাণ ডেটা সরানো আর তার পাশের লেসনগুলোতে)।

#পুরো storage-এর ম্যাপ

#তিন রকম storage, সাথে data সরানোর service

এই course-এর প্রতিটা storage service তিন রকমের একটা (লেসন ৫.৪-এ পরিচয় হয়েছিল):

• Block storage হলো কাঁচা একটা disk। একটা operating system সেটাকে file system দিয়ে format করে নিজের করে নেয়: EBS, instance store, আর Volume Gateway ও FSx for NetApp ONTAP-এর iSCSI volume।
• File storage হলো folder-এর একটা শেয়ার করা গাছ, network protocol দিয়ে পৌঁছাতে হয় (NFS, SMB, Lustre): EFS আর চারটা FSx file system।
• Object storage হলো পুরো object-এর একটা সমতল bucket, HTTPS API দিয়ে পৌঁছাতে হয়: S3 আর তার Glacier class।

এদের চারপাশে আছে hybrid আর transfer service, যেগুলো তোমার অফিসকে AWS-এর সাথে জোড়ে: Storage Gateway, Transfer Family, DataSync আর Snowball। আর data যখন field ধরে খুঁজতে, index করতে আর update করতে হয়, তখন উত্তর storage-ই না, একটা database।

#সবকিছু একটা টেবিলে

Note-এর তুলনার টেবিল আর slide-এর storage-সারাংশ, অধ্যায় ৫, ১০ আর ১২-এ যা শিখেছি সব দিয়ে পূর্ণ করা:

Database-এর জন্য course-এ আলাদা অধ্যায় আছে: অধ্যায় ৭-এ RDS আর Aurora, অধ্যায় ১৫-তে DynamoDB, আর অধ্যায় ১৬-তে database কীভাবে বাছবে। Slide-ও storage-সারাংশ একইভাবে শেষ করে: database নির্দিষ্ট ধরনের কাজের জন্য, সাধারণত index আর query সহ।

নিজের scenario প্রশ্নগুলোর ভেতর দিয়ে হাঁটিয়ে দেখো:

#যা ভুল হয়

#System design-এ Transfer Family আর DataSync

• Partner-দের data ঢোকানোর pipeline। Transfer Family (internet-facing VPC endpoint, Elastic IP, custom identity provider) → partner-প্রতি একটা prefix সহ S3 → managed workflow (decrypt, scan, tag) → EventBridge বা S3 event processing শুরু করে (লেসন ১০.৭) → lifecycle দিয়ে Glacier। Partner-দের কিছুই বদলাতে হয় না; তোমাকে কোনো server চালাতে হয় না।
• High availability। একটা Transfer Family server এমনিতেই তিনটা AZ পর্যন্ত ছড়ানো। Region-বদলের জন্য আরেকটা Region-এ replicate করা bucket সহ দ্বিতীয় একটা server চালাও, আর Route 53 health check দিয়ে বদলাও। Transfer Family-র সামনে Global Accelerator দূরের throughput বাড়াতে পারে (অধ্যায় ১১)।
• Private file আদান-প্রদান। নিজেদের শাখার জন্য Direct Connect বা VPN দিয়ে পৌঁছানো internal VPC endpoint, পুরোনো FTP device সহ।
• ধাপে ধাপে migration। খোঁজখবর আর পরিকল্পনা, তারপর বড় অংশের জন্য DataSync (network-এ সপ্তাহ লাগলে Snowball Edge), রাতের incremental run, লেখা বন্ধ, শেষ run আর যাচাইয়ের report, তারপর cut-over আর পুরোনোটা বন্ধ। DataSync-এর জন্য VPC endpoint ব্যবহার করো, যাতে copy কখনো internet না পেরোয়।
• AWS service-এর মধ্যে copy। Agent ছাড়া DataSync: সস্তা দ্বিতীয় copy-র জন্য EFS → S3, file চায় এমন application-এর জন্য S3 → EFS, আরেক Region-এ FSx → FSx, বা আরেক account-এ।
• চিরকালের hybrid। Application যখন অফিসেই থাকে, তখন Storage Gateway, DataSync না; প্রথম বড় copy-টা তবুও DataSync করতে পারে।
• Storage সবার শেষে বাছো। আগে ঠিক করো data-তে কীভাবে পৌঁছানো হবে (block, file, object, query), কে পৌঁছাবে (একটা host, অনেকগুলো, পুরো internet), কোন protocol-এ, আর কতদিনের জন্য। তারপর ওপরের টেবিলই একটা উত্তর দিয়ে দেয়।

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

Transfer Family: VPC-র ভেতরে একটা internet-facing SFTP server, logical home directory সহ একজন service-managed user, তারপর একটা upload।

# 1. Create the server: SFTP on a VPC endpoint, CloudWatch logging
aws transfer create-server --protocols SFTP --identity-provider-type SERVICE_MANAGED \
  --endpoint-type VPC \
  --endpoint-details VpcId=vpc-0a1b2c3d4example,SubnetIds=subnet-0aa11example,SecurityGroupIds=sg-0cc33example \
  --logging-role arn:aws:iam::111122223333:role/AWSTransferLoggingAccess
# { "ServerId": "s-01234567890abcdef" }

#    Make it internet-facing: Elastic IPs are attached with update-server, while it is stopped
aws transfer stop-server --server-id s-01234567890abcdef
aws transfer update-server --server-id s-01234567890abcdef \
  --endpoint-details VpcId=vpc-0a1b2c3d4example,SubnetIds=subnet-0aa11example,AddressAllocationIds=eipalloc-0bb22example
aws transfer start-server --server-id s-01234567890abcdef

# 2. Add a partner: role, logical home directory (chroot to their prefix), SSH public key
aws transfer create-user --server-id s-01234567890abcdef --user-name acme \
  --role arn:aws:iam::111122223333:role/TransferPartnerS3 \
  --home-directory-type LOGICAL \
  --home-directory-mappings '[{"Entry":"/","Target":"/payroll-example/inbound/acme"}]' \
  --ssh-public-key-body "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKey acme@example.com"

# 3. Check that the identity setup returns what you expect
aws transfer test-identity-provider --server-id s-01234567890abcdef --user-name acme \
  --server-protocol SFTP --source-ip 203.0.113.10
# { "StatusCode": 200, "Message": "", "Url": "..." }

# 4. As the partner: connect and upload, then see the object
sftp -i acme_key acme@198.51.100.20
# sftp> put salary-oct.csv
aws s3 ls s3://payroll-example/inbound/acme/
# 2026-10-26 09:14:02     184213 salary-oct.csv

DataSync: একটা agent, একটা SMB source, একটা FSx for Windows destination, bandwidth limit সহ রাতের একটা task, একবার চালানো।

# 1. Activate the agent VM (activation key from the agent's local console)
aws datasync create-agent --agent-name head-office-agent --activation-key ABCDE-12345-FGHIJ-67890-KLMNO
# { "AgentArn": "arn:aws:datasync:ap-south-1:111122223333:agent/agent-0b0addbeef44baca3" }

# 2. Source: the old Windows file server over SMB
aws datasync create-location-smb --server-hostname 10.20.1.40 --subdirectory /shares \
  --user svc-datasync --domain CORP --password '<from your vault>' \
  --agent-arns arn:aws:datasync:ap-south-1:111122223333:agent/agent-0b0addbeef44baca3

# 3. Destination: FSx for Windows File Server
aws datasync create-location-fsx-windows \
  --fsx-filesystem-arn arn:aws:fsx:ap-south-1:111122223333:file-system/fs-0123456789example \
  --security-group-arns arn:aws:ec2:ap-south-1:111122223333:security-group/sg-0dd44example \
  --user svc-datasync --domain CORP --password '<from your vault>'

# 4. The task: changed files only, copy NTFS permissions, verify, 300 Mbps cap, every night at 1 AM
aws datasync create-task --name shares-to-fsx --task-mode BASIC \
  --source-location-arn <smb-location-arn> --destination-location-arn <fsx-location-arn> \
  --options TransferMode=CHANGED,VerifyMode=ONLY_FILES_TRANSFERRED,SecurityDescriptorCopyFlags=OWNER_DACL,BytesPerSecond=37500000,LogLevel=TRANSFER \
  --schedule ScheduleExpression="cron(0 1 * * ? *)"

# 5. Run it now and watch the phases
aws datasync start-task-execution --task-arn <task-arn>
aws datasync describe-task-execution --task-execution-arn <execution-arn>
# "Status": "TRANSFERRING", "FilesTransferred": 1204533, "BytesTransferred": 8812004376011,
# "BytesCompressed": 7105227001338, "EstimatedFilesToTransfer": 4100000

# 6. Lift the cap for the night without stopping the execution
aws datasync update-task-execution --task-execution-arn <execution-arn> --options BytesPerSecond=-1

BytesPerSecond=37500000 মানে ৩০০ Mbps, আর -1 মানে কোনো সীমা নেই। কাজ শেষে test Transfer Family server মুছে ফেলো: সেটা প্রতি ঘণ্টায় বিল তোলে।

#সারসংক্ষেপ

মূল কথা

• Transfer Family হলো S3 বা EFS-এর সামনে একটা পুরোপুরি managed SFTP, FTPS, FTP আর AS2 endpoint (সাথে browser-এর web app)। পরীক্ষায়: SFTP/FTP/FTPS + “without managing servers”।
• একটা session: hostname (Route 53 দিয়ে নিজের নাম, import করা host key) → identity provider → IAM role + session policy + logical home directory → সরাসরি S3-এ লেখা object → managed workflow (copy, tag, delete, PGP decrypt, Lambda; exception handler)।
• Endpoint type: public = শুধু SFTP, বদলাতে থাকা IP, security group নেই; VPC internet-facing = SFTP, FTPS, AS2, সাথে Elastic IP আর security group; VPC internal = চারটাই, আর সাধারণ FTP চলে শুধু এখানেই।
• Identity: service managed (SSH key), AWS Directory Service (Microsoft AD), বা Lambda বা API Gateway দিয়ে একটা custom identity provider (LDAP, Okta, Cognito…)।
• দাম: চালু থাকা প্রতিটা protocol-এ ঘণ্টায় $0.30, সাথে প্রতি GB $0.04; অলস server-ও protocol-প্রতি মাসে প্রায় $216 নেয়।
• DataSync network দিয়ে বিশাল data copy করে, একবার বা নির্দিষ্ট সময়ে (প্রতি ঘণ্টা, দিন, সপ্তাহ): অফিস আর অন্য cloud-এর জন্য agent (source-এর কাছের একটা VM, শুধু বাইরের দিকে 443), AWS service-এর মধ্যে agent লাগে না। গন্তব্য: Glacier সহ যেকোনো class-এর S3, EFS, চারটা FSx-ই।
• একটা run: queued → launching → preparing → transferring (TLS, compress করা, metadata রক্ষা) → verifying। Default-এ incremental, প্রতি task-এ ১০ Gbps পর্যন্ত, bandwidth limit, filter, manifest, report।
• Basic mode: প্রতি GB $0.0125, প্রতি run-এ ৫ কোটি file; Enhanced mode: সব একসাথে, কার্যত সীমাহীন file, প্রতি GB $0.015 + প্রতি run $0.55।
• DataSync copy করে চলে যায়; Storage Gateway পথেই থেকে যায়, cache সহ local NFS, SMB, iSCSI বা tape-এর মুখ হয়ে। প্রায়ই দুটোই: অতীতের জন্য DataSync, ভবিষ্যতের জন্য gateway।
• বাছাই: অফিসের app ব্যবহার করে যাবে → Storage Gateway; বাইরের কেউ file protocol-এ → Transfer Family; দূরের user upload করে → Transfer Acceleration; নিজের storage, network-এ → DataSync; network-এ সপ্তাহ → Snowball Edge।
• ম্যাপ: block (EBS, instance store), file (EFS, FSx for Windows, Lustre, NetApp ONTAP, OpenZFS), object (S3, Glacier class), hybrid আর transfer (Storage Gateway, Transfer Family, DataSync, Snowball), আর query করতে হলে database।

নিজেকে যাচাই করো: Transfer Family, DataSync আর storage-এর ম্যাপ৩০টি প্রশ্ন