বিশাল পরিমাণ ডেটা সরানো

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

• কোনো একটা link-এ transfer-এ কত সময় লাগবে, দশমিক একক আর bit ধরে হিসাব করতে পারবে, আর বুঝবে আসল সংখ্যা কেন সবসময় বইয়ের সংখ্যার চেয়ে খারাপ হয় (protocol-এর overhead, ভাগাভাগির line, বারবার নতুন করে শুরু, bit-এর জায়গায় byte বসানোর ভুল)।
• Slide-এর চেনা উদাহরণটা নিজে কষে দেখতে পারবে (১০০ Mbps-এ ২০০ TB, ১ Gbps Direct Connect-এ, আর Snowball-এ), সাথে বাংলাদেশের মাপের তিনটা ঘটনা: একটা television archive, একটা bank-এর petabyte, আর প্রতিদিনের বিশাল বদল।
• Online পদ্ধতিগুলো (DataSync সহ internet, Site-to-Site VPN, Direct Connect, S3 Transfer Acceleration) আর offline পদ্ধতি (Snowball) পাশাপাশি রেখে তুলনা করতে পারবে: setup-এর সময়, গতি, encryption আর খরচ।
• একটা আসল migration দুই ভাগে সাজাতে পারবে: একবারের bulk copy, তারপর cutover পর্যন্ত VPN বা Direct Connect-এর ওপর DataSync বা DMS দিয়ে চলমান sync।
• পরীক্ষার keyword ধরতে পারবে (“internet-এ কয়েক সপ্তাহ”, “petabyte”, “setup-এর জন্য এক মাস অপেক্ষা করা যায়”, “সারা পৃথিবীর user এক bucket-এ upload করে”), আর জানবে প্রশ্নগুলো লেখার পর Snow Family-র গল্পের কোন অংশ বদলে গেছে।

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

এই chapter-এর আগের চারটা লেসনে আমরা server আর database সরিয়েছি। প্রতিটা সরানোই আগে বা পরে একই দেয়ালে ধাক্কা খায়: data-টাকে তো তোমার building থেকে একটা AWS Region-এ পৌঁছাতে হবে, আর সেটা হতে পারে কয়েক terabyte বা petabyte। এই লেসন সেই দেয়াল নিয়ে, আর এটা সংখ্যার লেসন: পরীক্ষা তোমাকে data-র মাপ আর link-এর গতি দেবে, আর আশা করবে service বাছার আগে তুমি হিসাবটা করে নেবে।

Tool-গুলো নিজেরা অন্য জায়গায় শেখানো হয়েছে, তাই এখানে শুধু তুলনা করব আর পেছনে ফিরিয়ে দেখাব:

• Snowball Edge, তার job-এর জীবনচক্র আর আজকের অবস্থা: লেসন ১২.১। S3-এ bulk data নেওয়ার পথগুলো (DataSync, Snowball, Transfer Acceleration): লেসন ১০.১১। DataSync বিস্তারিত: লেসন ১২.৪।
• Network হিসেবে Site-to-Site VPN আর Direct Connect: লেসন ২২.৪ আর লেসন ২২.৫। এখানে এরা শুধু একেকটা নল, যার একটা গতি আর একটা setup-এর সময় আছে।
• Database-এর জন্য DMS আর change data capture: লেসন ২৩.৩। পুরো server-এর জন্য MGN: লেসন ২৩.৪।

Note পদ্ধতিগুলোকে ঠিক পরীক্ষার মতোই দুই ভাগ করেছে: network দিয়ে (online) আর offline (physical)। আমরা শুরু করব হিসাব দিয়ে, কারণ কোনটা বাছবে সেটা হিসাবই ঠিক করে দেয়।

#আগে সবসময় অঙ্কটা কষো

#Bit, byte আর দশমিক একক

একটা সূত্রই পুরো কাজ করে:

transfer-এর সময় = bit-এ data ÷ প্রতি second-এ ব্যবহারযোগ্য bit

তিনটা কথা মাথায় রাখলে উত্তর ঠিক আসবে:

• Link বিক্রি হয় প্রতি second-এ bit হিসেবে (Mbps, Gbps)। Data মাপা হয় byte-এ (GB, TB)। এক byte মানে ৮ bit, তাই ১০০ Mbps আসলে বয় মাত্র প্রতি second-এ ১২.৫ MB, আর ১ Gbps বয় ১২৫ MB/s।
• দশমিক একক ব্যবহার করো, network আর পরীক্ষা যেমন করে: ১ TB = ১,০০০ GB = ১০,০০,০০০ MB, তাই ১ TB = ৮,০০০ gigabit = ৮০,০০,০০০ megabit। ১ PB = ১,০০০ TB।
• একদিনে ৮৬,৪০০ second। Second-কে ৮৬,৪০০ দিয়ে ভাগ করলে দিন।

মাথায় রাখার মতো একটা সহজ হিসাব: ১০০ Mbps-এর একটা line দিনে বড়জোর মোটামুটি ১ TB বয় (১০০ Mbps × ৮৬,৪০০ s = ৮৬,৪০,০০০ megabit = ১.০৮ TB)। ১ Gbps line দিনে প্রায় ১০.৮ TB, আর ১০ Gbps প্রায় ১০৮ TB। নিচের সব হিসাব এই কথাটাকেই বড়-ছোট করা।

#Slide-এর উদাহরণ, কষে দেখা

চেনা ঘটনাটা: ২০০ TB AWS-এ নিতে হবে, আর company-র আছে ১০০ Mbps-এর একটা internet connection।

Internet বা Site-to-Site VPN দিয়ে।

• ধাপ ১: Megabit-এ data: ২০০ TB × ১,০০০ GB × ১,০০০ MB × ৮ = ১,৬০,০০,০০,০০০ megabit।
• ধাপ ২: Link দিয়ে ভাগ: ১,৬০,০০,০০,০০০ ÷ ১০০ Mbps = ১,৬০,০০,০০০ second।
• ধাপ ৩: দিনে নাও: ১,৬০,০০,০০০ ÷ ৮৬,৪০০ = প্রায় ১৮৫ দিন, মানে ছয় মাস।

Setup-এর সময় শূন্য: line আগে থেকেই আছে, VPN একই দিনে চালু হয়ে যায়। কিন্তু VPN line-কে চওড়া করে না: সে শুধু একই internet traffic-কে encrypt করে।

১ Gbps Direct Connect দিয়ে।

• ধাপ ১: Gigabit-এ data: ২০০ × ১,০০০ × ৮ = ১৬,০০,০০০ gigabit।
• ধাপ ২: Link দিয়ে ভাগ: ১৬,০০,০০০ ÷ ১ Gbps = ১৬,০০,০০০ second।
• ধাপ ৩: দিনে নাও: প্রায় ১৮.৫ দিন।

কিন্তু আগে তো line-টা থাকতে হবে। Slide বলে একবারের setup-এ এক মাসের বেশি লাগে; AWS-এর নিজের hybrid connectivity-র নির্দেশনা বলে, একদম নতুন dedicated connection-এ সাধারণত কয়েক সপ্তাহ থেকে কয়েক মাস লাগে। তাই order দেওয়ার দিন থেকে ধরলে মোটামুটি ৫০ দিন বা তার বেশি।

Snowball দিয়ে। Transfer-টার জন্য শুরু থেকে শেষ মোটামুটি এক সপ্তাহ: device আসে, local network-এ দুই-এক দিনে ভরা হয় (১ GB/s-এর কাছাকাছি গতিতে ২০০ TB লাগে প্রায় ২.৩ দিন), ফেরত যায়, import হয়। Slide আরও বলে, database-এর জন্য এটা DMS-এর সাথে মেলানো যায়; সেটা নিচে দেখব।

এই table-টাই ছোট করে পুরো লেসন: internet আজই শুরু হয় কিন্তু দেরিতে শেষ হয়, Direct Connect দ্রুত কিন্তু দেরিতে শুরু হয়, Snowball তারটাকেই এড়িয়ে যায়।

#আসল সংখ্যা কেন আরও খারাপ

Slide-এর সংখ্যা ধরে নেয়, line ছয় মাস ধরে পুরো ১০০% গতিতে তোমার data বয়ে যাবে। তা কখনো হয় না:

• Protocol-এর overhead। প্রতিটা packet-এ থাকে TCP/IP header, copy tool যোগ করে TLS, VPN যোগ করে IPsec header। হারানো packet আবার পাঠাতে হয়।
• আসল ব্যবহার। নিজস্ব line হলে মোটামুটি ৮০% ধরে পরিকল্পনা করো। ১৮৫ দিন ÷ ০.৮ = প্রায় ২৩১ দিন।
• ভাগাভাগির line। দিনে অফিসের line লাগলে সকাল ৯টা থেকে বিকেল ৫টা copy হয়তো পায় অর্ধেক। দিনে ৫০ Mbps আর রাতে ৮০ Mbps মিলিয়ে গড়ে প্রায় ৬০ Mbps: প্রায় ৩০০ দিন।
• বিভ্রাট আর নতুন করে শুরু। কয়েক মাসে line কাটবেই; ভালো tool (DataSync) যেখানে থেমেছিল সেখান থেকে চালায় আর মিলিয়ে দেখে, নিজে লেখা script হয়তো file-টা আবার গোড়া থেকে শুরু করে।
• Source-এ binary একক। Storage-এর tool প্রায়ই দেখায় TiB (২^৪০ byte, প্রায় ১.১ TB)। NAS-এর পর্দায় “২০০ TiB” মানে তারে প্রায় ২২০ TB: সময় ১০% বেশি।
• Bit-এর জায়গায় byte-এর ভুল। ২০০ TB ÷ “১০০ MB/s” = ২০,০০,০০০ s = ২৩ দিন। ৮ গুণ ভুল, আর পরীক্ষার প্রশ্নে এটা একটা চেনা ভুল option।

#Online পদ্ধতিগুলো

Note network দিয়ে data নেওয়ার চারটা উপায়ের কথা বলে। প্রতিটা পরীক্ষার আলাদা একেকটা keyword-এর উত্তর।

#AWS DataSync: copy-র ইঞ্জিন

DataSync নিজে কোনো নল না, বরং নলটা যে ব্যবহার করে সেই tool। একটা agent (তোমার storage-এর পাশে একটা virtual machine) পড়ে NFS, SMB, HDFS বা S3-এর মতো object storage, অন্য cloud-এর storage-ও পড়া যায়; service লেখে S3, EFS বা যেকোনো FSx file system-এ। কী বদলেছে দেখে শুধু সেটুকু copy করে, শেষে মিলিয়ে দেখে, file-এর metadata রাখে, পথে TLS দিয়ে encrypt করে, আর নির্দিষ্ট সময় ধরে চলে। Agent থাকলে একটা task ১০ Gbps পর্যন্ত বইতে পারে। যে link আছে তার ওপরেই চলে: internet, VPN বা Direct Connect।

পরীক্ষার keyword (note থেকে): “on-premises storage থেকে AWS storage-এ automated, scheduled online data transfer” → DataSync। বিস্তারিত আর দাম: লেসন ১২.৪।

#Site-to-Site VPN

তোমার router আর AWS-এর মাঝে internet-এর ওপর দিয়ে একটা IPsec tunnel। Note এর যে চেহারা দেয়, সেটা এখনও ঠিক:

• Setup দ্রুত: কয়েক মিনিট থেকে কয়েক ঘণ্টা, কোনো carrier বা চুক্তি লাগে না।
• নকশাতেই encrypted।
• গতি internet-এর: তোমার line-এর চেয়ে বেশি না, আর internet-এর ভিড়ে ওঠানামা করে।
• আরেকটা ছাদ, যেটা note বলেনি: একটা standard tunnel বড়জোর প্রায় ১.২৫ Gbps বয়। নভেম্বর ২০২৫ থেকে transit gateway বা Cloud WAN-এ ৫ Gbps পর্যন্ত large bandwidth tunnel আছে, আর কয়েকটা tunnel একসাথেও চালানো যায় (লেসন ২২.৪)।

যখন encryption দরকার, আজই শুরু করতে হবে, আর data-র পরিমাণ line-এ আঁটে, তখন এটা।

#AWS Direct Connect

তোমার জায়গা থেকে AWS পর্যন্ত একটা private, নিজস্ব line, যা কখনো public internet দিয়ে যায় না। Note এর শক্তি আর একটা ফাঁদ, দুটোই বলে:

• দ্রুত আর স্থির: ১, ১০, ১০০ বা ৪০০ Gbps-এর dedicated port, বা partner-এর কাছ থেকে ছোট hosted connection; internet-এর ভিড়ে latency আর গতি দোলে না।
• Setup ধীর: একদম নতুন dedicated connection-এ সাধারণত কয়েক সপ্তাহ থেকে কয়েক মাস; partner-এর আগে থেকে থাকা port-এ hosted connection কয়েক দিনেও হয়ে যেতে পারে।
• নিজে থেকে তোমার link-এ encrypted না। Note যে সংশোধনটা বাদ দিয়েছে: encrypt করতে চাইলে MACsec (১০, ১০০ আর ৪০০ Gbps dedicated connection-এ) ব্যবহার করো, অথবা Direct Connect-এর ওপর দিয়ে IPsec VPN চালাও। দুটোই বানানো হয়েছে লেসন ২২.৫-এ।
• Internet-এর চেয়ে data transfer out-এর খরচ কম, আর migration-এর পরেও line কাজে লাগতে থাকে।

পরীক্ষার keyword: “dedicated private connection দরকার, কিন্তু setup-এর জন্য এক মাস অপেক্ষা করা যায়” → Direct Connect।

#S3 Transfer Acceleration

এটা অন্য সমস্যার জন্য: bucket থেকে অনেক দূরে থাকা অনেক মানুষ। Upload AWS-এর network-এ ঢোকে সবচেয়ে কাছের edge location-এ (CloudFront network), তারপর AWS backbone ধরে bucket-এর Region-এ যায়, public internet-এর লম্বা পথে না। এটা দূরত্বের সমস্যা কমায়, তোমার নিজের line না: ১০০ Mbps-এর অফিস তখনও ১০০ Mbps-ই পাঠায়। প্রতি GB-তে একটা বাড়তি fee লাগে, তাও শুধু তখন যখন transfer সত্যিই দ্রুত হয়েছে। বিস্তারিত: লেসন ১০.১১।

পরীক্ষার keyword: “সারা পৃথিবীর user একটা S3 bucket-এ বড় file upload করে” → S3 Transfer Acceleration।

#Online পদ্ধতিগুলো পাশাপাশি

#Offline পদ্ধতি: Snowball

Data-র পরিমাণের তুলনায় line যখন খুব ধীর, খুব ভাগাভাগির বা খুব দামি, তখন data একটা বাক্সে ভরে পাঠিয়ে দাও। Note তিনটা device-এর কথা বলে, আর অনেক প্রশ্ন এখনও সেভাবেই লেখা:

নতুন customer-দের AWS পাঠায় বড় link-এর ওপর DataSync-এ (যেমন কিছুদিনের জন্য একটা hosted Direct Connect) আর AWS Data Transfer Terminal-এ: physical জায়গা, ফেব্রুয়ারি ২০২৬-এর পর ১১টা, যুক্তরাষ্ট্র, ইউরোপ, Sydney আর Tokyo-তে, যেখানে নিজের drive নিয়ে গিয়ে খুব দ্রুত fibre-এ upload করা যায়। Device-এর খুঁটিনাটি, দাম আর job-এর ধাপ আছে লেসন ১২.১-এ; এখানে আবার বলার দরকার নেই।

#“এক সপ্তাহের বেশি” নিয়মটা আসলে মোটা দাগের হিসাব

Note এটাকে AWS-এর নিয়ম বলে: network-এ এক সপ্তাহের বেশি লাগলে Snow Family ব্যবহার করো। এটা একটা পড়াশোনার মোটা দাগের হিসাব, AWS-এর কোনো আনুষ্ঠানিক নিয়ম না। এসেছে AWS-এর পুরনো একটা পরামর্শ থেকে, যে network-এ মোটামুটি এক সপ্তাহের বেশি লাগলে device ভাবা উচিত, আর এই কারণে যে একটা Snowball-এর আসা-যাওয়ায় মোটামুটি এক সপ্তাহ লাগত। পরীক্ষার প্রশ্নে এটা এখনও কাজ করে। বাস্তবে নিয়মটা যে তিনটা জিনিস চাপা দেয় সেগুলোও মাপো: device তৈরিতে ৪ সপ্তাহ পর্যন্ত লাগতে পারে; মোটা নিজস্ব link যেকোনো courier-কে হারায় (১০ Gbps-এ ৮০% ধরে ৬০ TB যায় ১৭ ঘণ্টারও কমে); আর প্রতিদিনের স্থির স্রোত কোনো device দিয়ে কখনো সামলানো যায় না।

#একবারের bulk, তারপর চলমান sync

আসল migration-এ data সরানোর সময় ব্যবসা প্রায় কখনো থামে না। Slide-এর শেষ কথাটাই সেই ধরন, যা প্রতিটা বড় migration মেনে চলে:

1. একবার bulk copy

   বড়, মোটামুটি স্থির অংশটা সরাও: archive, file share, database-এর table। তার খুব ধীর হলে Snowball-এ, না হলে Direct Connect-এর ওপর DataSync-এ।

2. বদলগুলো ধরে রাখতে থাকো

   Bulk copy শুরুর মুহূর্ত থেকেই মূল data বদলাতে থাকে। File-এর জন্য DataSync নিয়ম করে চলে আর শুধু বদলানো অংশ copy করে। Database-এর জন্য DMS তার change data capture দিয়ে প্রতিটা বদল লিখে রাখে আর পরে চালায় (লেসন ২৩.৩)।

3. VPN বা Direct Connect-এর ওপর চলমান replication

   বদলগুলো তারের জন্য যথেষ্ট ছোট: DMS বা DataSync সহ Site-to-Site VPN বা Direct Connect, ঠিক যেমন slide বলে।

4. Cutover

   কয়েক মিনিটের জন্য লেখা বন্ধ রাখো, শেষ sync চালাও, সংখ্যা আর checksum মিলিয়ে দেখো, user বা application-কে AWS-এ পাঠাও। নিশ্চিত না হওয়া পর্যন্ত পুরনো copy রেখে দাও।

Database-এর bulk-ও device-এ যেতে পারে: SCT-এর data extraction agent table-গুলো Snowball Edge-এ লেখে, AWS সেগুলো S3 হয়ে target-এ (সাধারণত Redshift) তোলে, আর এর মধ্যে জমা বদলগুলো DMS চালিয়ে দেয়। “Snowball-কে DMS-এর সাথে মেলানো যায়” মানে এটাই।

#সংখ্যা ধরে বাছাই

এবার সব একসাথে। যেকোনো প্রশ্নে এই ক্রমে চারটা জিনিসের উত্তর দাও: কত data, line কত দ্রুত, কত দিন অপেক্ষা করা যায়, আর data কি বদলাতেই থাকে?

Calculator যা শেখায়, চার কথায়:

• মোটামুটি ভালো line-এ অল্প data: সোজা পাঠিয়ে দাও (DataSync বা VPN); অন্য কিছুর setup-এর ঝামেলা পোষায় না।
• ধীর line-এ বিশাল data, একবার: device তারকে হারায়; পরীক্ষার উত্তর Snowball।
• বিশাল data আর যে line থেকে যাবে: Direct Connect, আসতে কয়েক সপ্তাহ লাগলেও।
• প্রতিদিনের স্থির স্রোত: শুধু line-ই হিসাবে আসে; এমন মাপের line নাও যাতে একদিনের বদল একদিনের অনেক আগেই চলে যায়।

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

#System design-এ

• প্রতিটা migration plan শুরু হয় transfer-এর বাজেট দিয়ে। MGN, DMS বা অন্য কিছু বাছার আগে হিসাব করো প্রতিটা পথে data-র কত সময় লাগবে, setup আর প্রতিদিনের বদল সহ।
• দুটো line, দুটো কাজ। খুব চেনা একটা hybrid design: স্থির traffic-এর জন্য Direct Connect, আর encrypted backup পথ হিসেবে একটা Site-to-Site VPN (লেসন ২২.৫)।
• Line-এর মাপ ঠিক করো স্রোত দেখে, bulk দেখে না। Bulk হয় একবার; প্রতিদিনের বদল চলে চিরকাল। Line যদি একদিনের বদল একদিনে বইতে না পারে, bulk যেভাবেই যাক design ভুল।
• মিলিয়ে দেখা transfer-এরই অংশ। DataSync নিজে মিলিয়ে দেখে; device-এর ক্ষেত্রে import-এর পরে object-এর সংখ্যা আর checksum মেলাও; মেলা না পর্যন্ত মূল data রেখে দাও।
• ২০২৬-এর পরে যা থাকবে, সেটা ধরে পরিকল্পনা। লম্বা project-এ DataSync, Direct Connect আর Data Transfer Terminal দিয়ে design করো, আর Snowball-কে পরীক্ষার জ্ঞান হিসেবে রাখো।

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

প্রথমে অঙ্ক। bc আছে এমন যেকোনো shell (বা একটা calculator) হলেই চলবে:

# Days to move 200 TB over 100 Mbps at 100% and 80%
echo "200*8000*1000 / 100 / 86400" | bc -l          # megabits ÷ Mbps ÷ s/day
#   185.18518518518518518518
echo "200*8000*1000 / (100*0.8) / 86400" | bc -l
#   231.48148148148148148148

# Over a 1 Gbps Direct Connect (gigabits ÷ Gbps)
echo "200*8000 / 1 / 86400" | bc -l
#   18.51851851851851851851

# How much a line carries per day, in TB (200 Mbps at 80%)
echo "0.2*0.8*86400 / 8000" | bc -l
#   1.72800000000000000000

যে link আছে তার ওপর একটা DataSync task, অফিসের সময়ের জন্য bandwidth limit সহ (ID-গুলো উদাহরণ):

# Locations were created before: the NFS share (through the agent) and the bucket
aws datasync create-task \
  --source-location-arn arn:aws:datasync:ap-southeast-1:111122223333:location/loc-0abc1234example1 \
  --destination-location-arn arn:aws:datasync:ap-southeast-1:111122223333:location/loc-0def5678example2 \
  --name archive-to-s3 \
  --options VerifyMode=ONLY_FILES_TRANSFERRED,TransferMode=CHANGED,BytesPerSecond=6250000 \
  --schedule ScheduleExpression="cron(0 20 * * ? *)"
#   { "TaskArn": "arn:aws:datasync:ap-southeast-1:111122223333:task/task-0123456789abcdef0" }
# BytesPerSecond=6250000 is 50 Mbps: the copy leaves the rest of a 100 Mbps line to the office

aws datasync start-task-execution \
  --task-arn arn:aws:datasync:ap-southeast-1:111122223333:task/task-0123456789abcdef0
#   { "TaskExecutionArn": ".../task-0123456789abcdef0/execution/exec-0a1b2c3d4e5f60718" }

দূরের uploader-দের জন্য Transfer Acceleration:

aws s3api put-bucket-accelerate-configuration \
  --bucket media-uploads-example --accelerate-configuration Status=Enabled
aws s3 cp ./clip.mp4 s3://media-uploads-example/raw/ --endpoint-url https://s3-accelerate.amazonaws.com

আর একটা Snowball import job, শুধু সেই account-গুলোর জন্য যাদের এখনও access আছে (পুরো ধাপ লেসন ১২.১-এ):

aws snowball create-job --job-type IMPORT --snowball-type V3_5S --snowball-capacity-preference T240 \
  --resources '{"S3Resources":[{"BucketArn":"arn:aws:s3:::archive-import-example"}]}' \
  --address-id ADID1a2b3c4d-1111-2222-3333-444455556666 \
  --role-arn arn:aws:iam::111122223333:role/SnowballImportRole \
  --shipping-option SECOND_DAY
#   { "JobId": "JID123e4567-e89b-12d3-a456-426655440000" }

#সারসংক্ষেপ

মূল কথাগুলো

• সময় = bit ÷ প্রতি second-এ ব্যবহারযোগ্য bit। ১ TB = ৮,০০০ gigabit; একদিন = ৮৬,৪০০ s; ১০০ Mbps ≈ দিনে ১ TB, ১ Gbps ≈ দিনে ১০.৮ TB। Byte-কে ৮ দিয়ে গুণ করো।
• Slide-এর ২০০ TB: ১০০ Mbps internet বা VPN-এ ১৮৫ দিন (setup লাগে না), ১ Gbps Direct Connect-এ ১৮.৫ দিন (সাথে এক মাসের বেশি setup), Snowball-এ মোটামুটি এক সপ্তাহ। আসল সংখ্যা আরও খারাপ: ৮০% ধরে পরিকল্পনা করো, ভাগাভাগির line-এ আরও কম।
• VPN: দ্রুত, encrypted, internet-এর গতি, standard tunnel-এ প্রায় ১.২৫ Gbps (২০২৫ থেকে ৫ Gbps-এর large tunnel)। Direct Connect: private, স্থির, setup-এ কয়েক সপ্তাহ থেকে কয়েক মাস, নিজে থেকে encrypted না (MACsec বা DX-এর ওপর VPN)। DataSync: যেকোনো link-এর ওপর scheduled, যাচাই করা copy। Transfer Acceleration: দূরের user, এক bucket।
• Offline: network-এ কয়েক সপ্তাহ লাগার মতো পরিমাণের জন্য Snowball Edge। Snowmobile বন্ধ (২০২৪), Snowcone বন্ধ (২০২৪), Snowball নতুন customer নেয় না (নভেম্বর ২০২৫), support শেষ ৩১ ডিসেম্বর ২০২৬; পরীক্ষা তবুও Snowball-ই চায়।
• “এক সপ্তাহের বেশি → Snow” পড়াশোনার মোটা দাগের হিসাব, AWS-এর নিয়ম না।
• আসল migration মানে bulk + চলমান sync: bulk-এর জন্য Snowball (বা DX-এর ওপর DataSync), তারপর cutover পর্যন্ত VPN বা Direct Connect-এর ওপর DMS বা DataSync। Device একবারের bulk-এর সমাধান করে, প্রতিদিনের স্রোতের কখনো না।

নিজেকে যাচাই করো: বিশাল পরিমাণ ডেটা সরানো৩০টি প্রশ্ন