Snowball আর Edge Computing

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

• ধীর, ভাগাভাগি করা বা একেবারে না-থাকা network link থাকলে কেন data পাঠানোর চেয়ে device ডাকে পাঠানো দ্রুত, সেটা বোঝাতে; আর data-র পরিমাণ, link-এর গতি আর ব্যবহারযোগ্য অংশ থেকে network transfer-এর সময় হিসাব করতে।
• Note আর পরীক্ষা Snow Family-কে যেভাবে চেনে (Snowcone, Snowball Edge, Snowmobile), আর আজ সেটা কেমন, দুটোই বলতে: দুটো Snowball Edge device, নভেম্বর ২০২৫ থেকে নতুন customer-এর জন্য বন্ধ, আর ৩১ ডিসেম্বর ২০২৬-এ support শেষ।
• একটা Snowball Edge job-কে শুরু থেকে শেষ পর্যন্ত চালিয়ে নিতে: job type, job-এর অবস্থা, OpsHub দিয়ে unlock, S3 interface বা NFS দিয়ে copy, ফেরত, import আর মুছে ফেলা; আর ধীর অংশগুলোর জন্য আগে থেকে পরিকল্পনা করতে।
• Edge computing কী, আর Snowball Edge-এ কী কী চলে বোঝাতে: EC2-compatible instance, IoT Greengrass দিয়ে Lambda, EKS Anywhere আর local S3-compatible storage।
• ডাকে চলা একটা device কীভাবে নিরাপদ থাকে বোঝাতে: KMS দিয়ে envelope encryption, manifest আর unlock code, কারসাজি ধরা পড়ার ব্যবস্থা, TPM আর NIST মেনে মুছে ফেলা।
• S3-এ import আর একটা lifecycle rule দিয়ে Snowball-এর data Glacier-এ নামাতে, ছোট object-এর ফাঁদ এড়াতে, আর Snowball, DataSync, Transfer Acceleration ও নতুন বিকল্পগুলোর মধ্যে বেছে নিতে।

#কখন তারের চেয়ে বাক্স জেতে

#তারের সমস্যা

লেসন ১০.১১-এ Snowball-কে আমরা S3-এ যাওয়ার ৮ নম্বর পথ হিসেবে চিনেছি: offline পথ। এই লেসনে আমরা ভেতরে ঢুকব। শুরুটা note-এর কথাতেই: তোমার নিজের data centre বা অফিসে, মানে on-premises-এ, বিশাল পরিমাণ data আছে, সেটা AWS-এ নিতে হবে, অথচ internet খুব ধীর, কিংবা internet দিয়ে পাঠানো নিয়ে security-র দুশ্চিন্তা আছে। তখন তুমি একটা physical device নাও আর offline transfer করো।

পাঁচটা কারণে network-ই সমস্যা হয়ে দাঁড়াতে পারে; slide-এ এগুলোকে data migration-এর চ্যালেঞ্জ হিসেবে দেখানো হয়েছে:

• যোগাযোগ সীমিত। Link ভরসার না, বা প্রায় নেই-ই: জাহাজ, খনি, দুর্যোগের এলাকা, গ্রামের কোনো সাইট।
• Bandwidth কম। অফিসের জন্য ১০০ Mbps চলে, কিন্তু ২০০ TB-র জন্য একেবারেই অচল।
• Network-এর খরচ বেশি। কোনো কোনো সাইটে প্রতি GB-র জন্য টাকা দিতে হয়, বা নতুন একটা দামি line টানতে হতো।
• Bandwidth ভাগাভাগি। একই line দিয়ে চলে hospital-এর রোগীর system বা কারখানার order, তাই migration পায় তার একটা অংশমাত্র, পুরোটা দখল করতে পারে না।
• Connection অস্থির। কয়েক সপ্তাহ ধরে চলা transfer বেশ কয়েকবার বিভ্রাটে পড়বে, আর প্রতিবার নতুন করে শুরু মানে সময় নষ্ট।

এর যেকোনোটা যখন কামড় দেয়, তখন data একটা বাক্সে ভরে ডাকে পাঠানোই দ্রুত। Snow Family-র মূল ভাবনা এটাই। Slide ছবিটা আঁকে দুই লাইনে: একদিকে client থেকে internet দিয়ে সোজা S3 bucket-এ upload, অন্যদিকে client একটা Snowball-এ copy করে, device ডাকে যায়, আর AWS সেটা bucket-এ import করে।

#হিসাবটা করে দেখা

এই বিষয়ের বেশিরভাগ পরীক্ষার প্রশ্নের মূলে এই হিসাব:

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

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

• Network গোনে দশমিক bit-এ। ১ TB মানে ১,০০০ GB, আর ১ GB মানে ৮ gigabit, তাই ১ TB = ৮,০০০ gigabit। ১ PB মানে ১,০০০ TB।
• Link বিক্রি হয় প্রতি second-এ bit হিসেবে (Mbps, Gbps); copy আর disk মাপা হয় প্রতি second-এ byte হিসেবে (MB/s, GB/s)। ১ Gbps link বড়জোর ১২৫ MB/s বইতে পারে।
• Link কখনো ১০০% তোমার না: protocol-এর বাড়তি খরচ, অন্য traffic আর দিনের ব্যবসা, সবাই একটা ভাগ নেয়। নিজস্ব link হলে মোটামুটি ৮০% ধরে পরিকল্পনা করো, ভাগাভাগির link হলে আরও অনেক কম।

(সবগুলোই link-এর ৮০% ধরে। Slide একই table-কে গোল করে ১২ দিন, ৩০ ঘণ্টা আর ৩ ঘণ্টা লেখে; ১০০% ধরলে প্রথম সারিটা হতো ৯.৩ দিন, ২২ ঘণ্টা আর ২.২ ঘণ্টা।)

একটা উদাহরণ কষে দেখি: ১ Gbps line-এ ৪০০ TB, migration পাবে line-এর ৫০%। ৪০০ × ৮,০০০ = ৩২,০০,০০০ gigabit। ব্যবহারযোগ্য গতি: ১ × ০.৫ = ০.৫ Gbps। ৩২,০০,০০০ ÷ ০.৫ = ৬৪,০০,০০০ second। ÷ ৮৬,৪০০ = ৭৪ দিন। দুটো Snowball Edge device কয়েক সপ্তাহেই কাজটা সেরে দিতে পারত।

আর উল্টো দিকের উদাহরণ: একই line-এ ৮০% পেয়ে ৫ TB: ৪০,০০০ ÷ ০.৮ = ৫০,০০০ second, প্রায় ১৪ ঘণ্টা। এই সময়ের মধ্যে কোনো device তো এসেই পৌঁছাবে না।

Slide শেষ হয় একটা মোটা দাগের নিয়ম দিয়ে, আর পরীক্ষা এটা বারবার ব্যবহার করে: network দিয়ে transfer-এ মোটামুটি এক সপ্তাহের বেশি লাগলে Snowball device ব্যবহার করো। নিজেই যাচাই করে দেখো:

Calculator দুটো জিনিস দেখায়, যেগুলো মোটা দাগের নিয়মে চাপা পড়ে যায়:

• এক সপ্তাহটা শুধু রাস্তার হিসাব। Device পাঠানো, ভরা আর import করতে মোটামুটি এক সপ্তাহ লাগে, কিন্তু AWS সাবধান করে দেয়, তোমার job-এর জন্য device তৈরি করতেই ৪ সপ্তাহ পর্যন্ত লাগতে পারে। আসল project-এ আগেভাগে order দাও, নইলে network-ই জিতে যেতে পারে।
• মোটা pipe যেকোনো courier-কে হারায়। নিজস্ব ১০ Gbps link-এ ৮০% পেলে ৬০ TB যায় ১৭ ঘণ্টারও কমে। Snowball হলো ধীর বা ভাগাভাগির link-এর উত্তর, সব বড় সংখ্যার উত্তর না।

#Snow Family: তখন আর এখন

#Note আর অনেক practice প্রশ্ন যা বলে

Note-এ তিনটা সদস্যের কথা আছে, আর SAA-C03-এর প্রশ্নে এখনও এই নামগুলোই আসে:

Note-এর exam trick-গুলো চেনা: internet-এ transfer করতে কয়েক মাস বা বছর লাগবে → Snowball Edge; edge computing বা দূরের এলাকায় IoT data সংগ্রহ → Snowcone বা Snowball Edge Compute Optimized।

#আজ কী আছে

ওই table-এর অনেকটাই এখন ইতিহাস। অক্টোবর ২০২৬-এ AWS-এর সাথে মিলিয়ে দেখা:

• Snowmobile ২০২৪-এ অবসরে গেছে; এপ্রিল ২০২৪-এর মধ্যে AWS এটা দেওয়া বন্ধ করে, আর customer-দের Snowball আর DataSync-এর দিকে পাঠায়।
• Snowcone (দুটো model-ই) আর পুরনো Snowball Edge model-গুলো (৮০ TB Storage Optimized, ৫২-vCPU Compute Optimized আর GPU Compute Optimized) ১২ নভেম্বর ২০২৪-এ বন্ধ হয়; চালু device-গুলোর support ছিল ১২ নভেম্বর ২০২৫ পর্যন্ত।
• ৭ নভেম্বর ২০২৫ থেকে Snowball Edge শুধু পুরনো customer-দের জন্য: যেসব account ওই তারিখের আগে sign up করেছিল। নতুন customer-দের AWS পাঠায় online transfer-এর জন্য AWS DataSync-এ, physical transfer-এর জন্য AWS Data Transfer Terminal-এ, AWS Partner-দের সমাধানে, আর edge computing-এর জন্য AWS Outposts-এ।
• AWS ঘোষণা দিয়েছে, ৩১ ডিসেম্বর ২০২৬-এ সব commercial Region-এ Snowball device-এর support বন্ধ হবে, Storage Optimized আর Compute Optimized দুটোরই; তারপর Snow console আর Snowball resource-এ আর ঢোকাই যাবে না। (চালু job থাকা GovCloud আর dedicated-cloud Region-এর customer-দের ওপর এই বদল খাটে না।)

এখন যে দুটো device টিকে আছে:

এখানে note আর পুরনো material-এর প্রথম সংশোধনটা খেয়াল করো: আজকের Storage Optimized device-এও Compute Optimized-এর মতোই ১০৪ vCPU আর ৪১৬ GB memory (slide-এও তাই দেখানো)। তফাতটা disk-এ: data-র জন্য ২১০ TB, বনাম compute-এর কাজের জন্য ২৮ TB দ্রুত NVMe।

টাকার দিকটা: S3-এ data ঢোকাতে প্রতি GB-র কোনো খরচ নেই; S3 থেকে device-এ data বের করলে অন্য যেকোনো data transfer out-এর মতোই প্রতি GB-তে টাকা লাগে। Shipping-এর খরচ courier-এর দামে। অনেক ছোট file (১ MB বা কম) থাকলে import-এর সময় S3-এর request-এর খরচ বাড়তে পারে।

#একটা Snowball job-এর জীবন

#তিন রকম job

Device নিয়ে যা-ই করো, সেটা একটা job: Snow console বা API-তে বানানো কাজের একটা একক।

• S3-এ import। ২১০ TB পর্যন্ত data একটা device-এ copy হয়, ফেরত এলে তোমার bucket-এ import হয়। এক job, এক device; data বেশি হলে job বেশি (একটা job clone-ও করা যায়)।
• S3 থেকে export। তোমার bucket-এর যেকোনো পরিমাণ data, AWS ভাগ করে সর্বোচ্চ ২১০ TB-র job part-এ, প্রতি part-এ একটা device। চাইলে একটা key range-এ সীমিত রাখা যায়। Export-এর device ফেরত এলে মুছে ফেলা হয়।
• Local compute and storage। Device শুধু সাইটেই কাজে লাগে, একা বা কয়েকটা device-এর একটা cluster-এ, যাতে local storage আরও টেকসই হয়। শুরু হয় খালি অবস্থায়, শেষে কিছুই import হয় না; ফেরত এলে মুছে ফেলা হয়।

তিন ধরনের job-ই সাইটে থাকার সময় compute চালাতে পারে (EC2-compatible instance, Lambda)। Edge computing-এ এটা জরুরি: যে device edge-এ data জমাবে আর সেই data S3-এ পৌঁছাতে হবে, তাকে import job হিসেবেই order দিতে হবে।

#ধাপে ধাপে একটা job

1. Job বানাও (অবস্থা: Job created)

   তুমি বেছে দাও job type, bucket, device type, একটা KMS key, একটা IAM role যেটা দিয়ে Snowball তোমার bucket-এ লিখতে পারবে, ডেলিভারির ঠিকানা আর shipping-এর গতি। শুধু এই অবস্থাতেই job বাতিল করা যায়। দুটো বাধা সহজে চোখ এড়ায়: console-এ ঢুকতে হয় bucket যে Region-এ, সেই Region-এই, আর device যায় শুধু সেই Region যে দেশ সামলায় তার ভেতরে (Mumbai-র job-এর device ভারতের ভেতরে; ইউরোপের Region-গুলো EU-র সদস্য দেশে পাঠায়)। কোনো Snowball Region বাংলাদেশ সামলায় না, তাই ঢাকার অফিস একটা device order দিতেই পারে না।

2. AWS device তৈরি করে (Preparing appliance, export job-এ Exporting, Preparing shipment)

   AWS software, job-এর encrypt করা manifest, আর তুমি চাইলে তোমার AMI আর Lambda function device-এ তোলে। Export job হলে এই সময়েই S3 থেকে data copy করে। AWS সাবধান করে দেয়, তৈরি হতে ৪ সপ্তাহ পর্যন্ত লাগতে পারে।

3. Shipping (In transit to you, Delivered to you)

   বাক্সের গায়ের E Ink পর্দাটাই shipping label। Shipping-এর গতি দেশভেদে আলাদা: আমেরিকায় পরের দিন বা দ্বিতীয় দিন, EU আর অস্ট্রেলিয়ায় express-এ মোটামুটি এক দিন, ভারতের ভেতরে এক থেকে সাত দিন। যে গতি বেছে নাও, যাওয়া-আসা দুই দিকেই সেটা খাটে।

4. লাগাও, unlock করো, copy করো (তখনও Delivered to you)

   Device-এ কোনো ক্ষতি আছে কি না দেখো, বিদ্যুৎ আর একটা network port লাগাও, তারপর job-এর manifest file আর unlock code দিয়ে unlock করো, AWS OpsHub (free desktop app) বা Snowball Edge client (command line) দিয়ে। তারপর device-এর S3 interface (device-এর endpoint-এ aws s3 cp) বা একটা NFS mount দিয়ে data copy করো।

5. ফেরত (In transit to AWS, At sorting facility, At AWS)

   Device বন্ধ করো; E Ink label নিজে থেকেই ফেরতের ঠিকানায় বদলে যায়, আর courier নিয়ে যায়। AWS-এ গিয়ে আগে একটা sorting facility হয়ে যায়; পৌঁছানোর এক-দুই দিনের মধ্যে সাধারণত import শুরু হয়।

6. Import আর মুছে ফেলা (Importing, Completed)

   AWS দেখে device-এ কারসাজি হয়েছে কি না, তারপর data তোমার bucket-এ import করে, আর তুমি পাও একটা job report আর log, কোনটা সফল আর কোনটা ব্যর্থ। শেষে AWS NIST-এর media sanitisation নির্দেশিকা মেনে software দিয়ে device মুছে ফেলে।

#Device-এ তাড়াতাড়ি data তোলা

বেশিরভাগ ধীর Snowball project ধীর হয় সাইটে, রাস্তায় না:

• ঠিকঠাক একটা copy host নাও। ২৫ Gb বা ১০০ Gb port-এ একটা শক্তিশালী workstation, ১ Gb port-এ লাগানো laptop না (১ Gb-তে copper port-এর আলো হলুদ জ্বলে-নেভে, ১০ Gb-তে সবুজ, আর বড় transfer-এ AWS ১ Gb ব্যবহার করতে মানা করে)। কয়েকটা device হলে প্রতি device-এর জন্য একটা করে copy host।
• একসাথে কয়েকটা copy চালাও। একসাথে কয়েকটা stream (aws s3 cp-এ বেশি concurrent request, বা কয়েকটা copy job) device-কে ব্যস্ত রাখে।
• ছোট file batch করো। প্রতিটা file একটা request, যার নিজস্ব বাড়তি খরচ, তাই ১ MB বা তার ছোট file হামাগুড়ি দিয়ে চলে। এগুলো tar (বা zip, tar.gz) archive-এ ভরো, প্রতিটায় মোটামুটি ১০,০০০ file আর সর্বোচ্চ ১০০ GB, আর snowball-auto-extract=true metadata দিয়ে copy করো; import-এর সময় AWS এগুলো খুলে আগের folder-এর গড়নেই সাজিয়ে দেয়। (একটা batch-এ ১,০০,০০০-এর বেশি file থাকলে import ধীর হয়।)
• কোন metadata লাগবে দেখে interface বাছো। NFS interface দিয়ে গেলে মালিক, সময়ের মতো file metadata থাকে। S3 interface দিয়ে গেলে টেকে শুধু নাম আর size।
• Source কখনো মুছবে না, যতক্ষণ না job Completed হয় আর তুমি job report মিলিয়ে দেখছ। তাহলে একটা device হারালে বা নষ্ট হলে যায় শুধু সময়, data না।

দুটো পুরনো feature-এর কথা এখনও পড়তে পারো, যেগুলো আর নেই: সাধারণ file interface মার্চ ২০২৪-এ তুলে দেওয়া হয়েছে, আর Snowball Edge-এ Tape Gateway (offline-এ tape migration-এর জন্য) মার্চ ২০২৪-এ বন্ধ হয়েছে।

#Snowball Edge দিয়ে edge computing

#Edge computing মানে কী

Edge computing মানে data যেখানে তৈরি হচ্ছে, তৈরি হওয়ার সময়েই সেখানে প্রসেস করা: বড় অর্থে একটা edge location-এ, CloudFront-এর edge না। Slide-এর উদাহরণ: রাস্তায় চলা ট্রাক, সমুদ্রে জাহাজ, মাটির নিচে খনির স্টেশন। এসব জায়গায় internet সীমিত, আর নিজস্ব computing power-এর কোনো ব্যবস্থা নেই।

সেখানে computing করার জন্য তুমি একটা Snowball Edge বসাও। এই কাজের জন্য আলাদা করে বানানো device Compute Optimized, তবে Storage Optimized-ও workload চালাতে পারে। Slide তিনটা চেনা ব্যবহারের নাম দেয়:

• Data আগেভাগে প্রসেস করা: sensor-এর reading ছেঁকে, জোড়া দিয়ে বা compress করে, যাতে শুধু দরকারি অংশটুকু পাঠাতে হয়।
• Machine learning: train করা একটা model data-র পাশেই চালানো (inference), যেমন ত্রুটি ধরতে বা যন্ত্র বিকল হওয়ার পূর্বাভাস দিতে।
• Media transcode করা: কাঁচা video সাইটেই ছোট format-এ বদলানো।

#Device-এ কী কী চলে

• EC2-compatible instance। Order দেওয়ার সময় job-এ AMI যোগ করো (তোমার নিজের image, আর AWS Marketplace-এর কিছু image-ও), তারপর OpsHub বা Snowball Edge client দিয়ে device-এ instance চালাও। Instance type-গুলো device-এর vCPU আর memory ব্যবহার করে; security group প্রায় VPC-র মতোই কাজ করে।
• AWS IoT Greengrass দিয়ে Lambda function। Device-এর একটা EC2 instance-এ IoT Greengrass core software install করো, তারপর Python-এ লেখা Lambda function Greengrass component হিসেবে deploy করো। Local IoT device-এর MQTT message এগুলো চালু করতে পারে। প্রতিটায় সুপারিশ করা ১২৮ MB ধরলে একটা job-এ মোটামুটি সাতটা function ধরে: এটা হালকা, ঘটনা-নির্ভর code-এর জন্য।
• EKS Anywhere। ২০২৩ থেকে Amazon EKS Anywhere দিয়ে Snowball Edge device-এ Kubernetes cluster চালানো যায়, ফলে container workload edge-এ cloud-এর মতোই চলে।
• Local storage। Device-এর S3-compatible storage (local-এ লেখা যায় এমন bucket, cluster-এও) আর একটা NFS file share।

সবকিছু চলতে থাকে AWS-এর সাথে কোনো connection ছাড়াই: device unlock হয় সেখানেই, আর তার instance আর storage cloud-এর ওপর নির্ভর করে না।

#Snowball-এর পরে edge computing

নতুন customer-দের জন্য edge-এর গল্প এগিয়ে গেছে। AWS তাদের পাঠায় AWS Outposts-এ (তোমার নিজের ভবনে বসানো AWS-এর rack, একটা Region-এর সাথে যুক্ত; ছোট Outposts server নতুন customer-দের কাছে আর বিক্রি হয় না), আর শহর ও mobile network-এর কাছে কম latency-র জন্য Local Zones আর Wavelength-এ (অধ্যায় ২৫, Outposts, Batch and more)। এগুলোর AWS-এর সাথে network connection লাগে, তাই সত্যিকারের যোগাযোগহীন সাইটের জন্য পরীক্ষার উত্তর এখনও Snowball Edge।

#Security: ডাকে চলা data-র বাক্স

Hospital-এর record ভরা একটা device courier-এর van-এ চড়ে যায়। কয়েক স্তরের ব্যবস্থা সেটাকে নিরাপদ রাখে:

• এমন key দিয়ে encryption, যেটা device-এ নেই। Device-এর সব data ২৫৬-bit key দিয়ে encrypt করা। শৃঙ্খলটা envelope encryption: job-এর জন্য তুমি যে KMS key বেছে নাও, সেটা job-এর unlock code encrypt করে; unlock code খোলে manifest file-এর বাইরের স্তর; আর manifest-এ থাকে সেই key, যা দিয়ে data encrypt আর decrypt হয়। এর কোনোটাই device-এর সাথে যায় না।
• দুটো আলাদা credential। Manifest download করো আর ২৯ অক্ষরের unlock code পড়ো console থেকে (বা aws snowball get-job-manifest আর get-job-unlock-code দিয়ে)। দুটোই আর সাথে device যার কাছে, সে data পড়তে পারে, তাই দুটো আলাদা রাখো, IAM দিয়ে এই দুটো অনুমতি সীমিত করো, আর কে কখন আনল CloudTrail-কে লিখে রাখতে দাও।
• পথে encryption। Device-এ যে data copy হয় তা TLS-এর ওপর দিয়ে যায়।
• কারসাজি চোখে পড়ে। খোলা কঠিন এমন বাক্স: লুকানো screw, কেউ খুললে টের পাওয়ার switch, কারসাজি-বিরোধী insert আর যাচাই করা যায় এমন NFC tag, সাথে একটা TPM (Trusted Platform Module), যার কল্যাণে device ফিরলে AWS যেকোনো বদল ধরতে পারে। পৌঁছানোর পর পরীক্ষা করো; কিছু গোলমেলে মনে হলে connect কোরো না, AWS নতুন device পাঠাবে।
• E Ink label। বদলে দেওয়া বা ভুল পড়ার মতো কোনো কাগজের label নেই: পর্দা দুই দিকেই ঠিক ঠিকানা দেখায়, নিচে job ID।
• S3-এ। Import হওয়া object পায় server-side encryption (SSE-S3, বা bucket-এর default, যেমন SSE-KMS; import SSE-C দেয় না)। Bucket policy দিয়ে এটা বাধ্যতামূলক করা যায়, লেসন ১০.৮-এর মতো।
• পরে। AWS NIST-এর media sanitisation নির্দেশিকা মেনে device মুছে ফেলে।

#Snowball থেকে Glacier

এটা note-এর প্রিয় ফাঁদ, আর slide-এ এর জন্য একটা পুরো পাতা: Snowball সরাসরি S3 Glacier বা Glacier Deep Archive-এ import করতে পারে না। Job-এ শুধু S3 bucket-এর নাম থাকে; Glacier-এর কোনো option নেই, আর device Glacier vault API-তে কথাও বলে না।

সমাধান দুই ধাপে (লেসন ১০.৫-এ lifecycle rule বিস্তারিত আছে):

1. যথারীতি S3-এ import করো (default-এ S3 Standard; note-এ Standard-IA-র কথাও আছে, ভাবনা একই: আগে একটা S3 class)।
2. Bucket বা prefix-এ একটা S3 lifecycle rule দাও, যেটা ০ দিন পরে object-গুলো Glacier Flexible Retrieval বা Glacier Deep Archive-এ transition করবে। এটা করো device ফেরত পাঠানোর আগেই।

Lifecycle পেছনে নিজের মতো চলে, তাই ০ দিনের rule এক-দুই দিনের মধ্যে object সরায়, আর Standard-এর ভাড়া দিতে হয় অল্প কদিনের। বিলটা ঠিক করে দুটো খুঁটিনাটি:

• ছোট object default-এ সরে না। Size filter না দিলে lifecycle rule ১২৮ KB-র ছোট object বাদ দেয়।
• প্রতিটা transition একটা request-এর খরচ, Deep Archive-এ প্রতি ১,০০০ object-এ প্রায় $০.০৫ (us-east-1), আর archive হওয়া প্রতিটা object-এর সাথে প্রায় ৪০ KB বাড়তি metadata-র বিল। শুধু transition করতেই ৯ কোটি thumbnail-এর খরচ প্রায় $৪,৫০০। ছোট file সাইটেই বড় tar archive-এ ভরো, আর auto-extract ছাড়া copy করো, যাতে প্রতিটা archive একটা object হয়।

লেসন ১০.১১-এর প্রতিবেশীদের সাথে মিলিয়ে নাও: DataSync সরাসরি Glacier class-এ লিখতে পারে; S3 File Gateway লেখে Standard, Standard-IA, One Zone-IA বা Intelligent-Tiering-এ, আর Glacier-এ পৌঁছাতে তারও lifecycle rule লাগে।

#Data কীভাবে সরাবে, বেছে নেওয়া

Snowball অনেকগুলো tool-এর একটা মাত্র। সিদ্ধান্ত নেওয়ার প্রশ্ন তিনটা: data কতটা, link কেমন, আর transfer একবারের নাকি চলতেই থাকবে:

আসল project-এর জন্য তিনটা পাশের কথা:

• দুই ধাপের migration-ই চল: আগে বড় copy (Snowball, বা বড় link-এ DataSync), তারপর cut-over-এর দিন পর্যন্ত বদলগুলোর জন্য নির্দিষ্ট সময়ে চলা DataSync।
• নতুন customer-দের জন্য বড় migration-এ AWS device-এর বদলে কিছুদিনের জন্য নেওয়া hosted Direct Connect-এর ওপর DataSync সুপারিশ করে (Direct Connect আছে লেসন ২২.৫-এ); অধ্যায় ২৩ বড় পরিমাণ data সরানো-র সব বিকল্প পাশাপাশি তুলনা করে।
• AWS Data Transfer Terminal (ডিসেম্বর ২০২৪) হলো AWS-এর একটা জায়গায় একটা ঘর: slot reserve করো, নিজের drive নিয়ে যাও, আর S3, EFS সহ যেকোনো AWS endpoint-এ upload করো। দাম port-hour হিসেবে (যেমন উত্তর আমেরিকার terminal থেকে উত্তর আমেরিকার Region-এ প্রতি port-hour-এ $৩০০), প্রতি GB-র আলাদা খরচ নেই। পরীক্ষায় এটা এখনও আসে না।

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

#System design-এ Snowball

• Data centre ছেড়ে আসা। বড় অংশ Snowball-এ, বদল DataSync-এ, একটা cut-over-এর সপ্তাহান্ত, তারপর পুরনো storage বন্ধ। Job report আর import log প্রমাণের অংশ যে কিছুই হারায়নি।
• Archive project। এমন bucket-এ import করো, যার lifecycle rule আগে থেকেই সবকিছু Deep Archive-এ পাঠায়; ছোট file আগে ভরে নাও। দশ বছরের compliance data-র মাসিক খরচ হাজার ডলার না, কয়েক ডলার।
• যোগাযোগহীন edge সাইট। জাহাজ, খনি, তেলের rig, মাঠের hospital, film-এর shooting set: Compute Optimized device সাইটেই data জমায় আর প্রসেস করে, আর নিয়ম করে device বদলে import হয়।
• AWS থেকে data বাইরে বিলি। Export job দুর্বল যোগাযোগের কোনো সাইটে (গবেষণার partner, নতুন campus) বড় dataset পাঠায়, বের হওয়া প্রতি GB-র দাম দিয়ে।
• শেষের তারিখটা জেনে রাখো। ২০২৬-এর পরের যেকোনো পরিকল্পনায় DataSync, Direct Connect, Data Transfer Terminal বা Outposts দিয়ে design করো, আর Snowball-কে পরীক্ষার জ্ঞান হিসেবে রাখো।

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

এই command-গুলো চলবে শুধু সেসব account-এ, যাদের এখনও Snowball Edge-এর access আছে। aws snowball API job সামলায়; Snowball Edge client (snowballEdge) আর OpsHub তোমার network-এ device-এর সাথে সরাসরি কথা বলে। নিচের address আর ID উদাহরণমাত্র।

# 1. ডেলিভারির ঠিকানা একবার সেভ করো (একটা address ID ফেরত আসে)
aws snowball create-address --region ap-south-1 --address \
  'Name=Hospital IT,Company=Example Health,Street1=12 Park Street,City=Kolkata,StateOrProvince=WB,PostalCode=700016,Country=IN,PhoneNumber=+910000000000'
#   { "AddressId": "ADID1a2b3c4d-1111-2222-3333-444455556666" }

# 2. Storage Optimized 210 TB device-এর জন্য import job (type V3_5S, capacity T240)
aws snowball create-job --region ap-south-1 --job-type IMPORT \
  --resources '{"S3Resources":[{"BucketArn":"arn:aws:s3:::scan-archive-example"}]}' \
  --address-id ADID1a2b3c4d-1111-2222-3333-444455556666 \
  --kms-key-arn arn:aws:kms:ap-south-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \
  --role-arn arn:aws:iam::111122223333:role/SnowballImportRole \
  --snowball-type V3_5S --snowball-capacity-preference T240 --shipping-option STANDARD \
  --description "Scan archive part 1"
#   { "JobId": "JID123e4567-e89b-12d3-a456-426655440000" }

# 3. Job-এর অবস্থা দেখো, তারপর দুটো credential আলাদা আলাদা আনো
aws snowball describe-job --region ap-south-1 --job-id JID123e4567-e89b-12d3-a456-426655440000 \
  --query 'JobMetadata.JobState'
#   "InTransitToCustomer"
aws snowball get-job-manifest --region ap-south-1 --job-id JID123e4567-e89b-12d3-a456-426655440000
#   { "ManifestURI": "https://...presigned-url..." }      (এক ঘণ্টার মধ্যে download করো)
aws snowball get-job-unlock-code --region ap-south-1 --job-id JID123e4567-e89b-12d3-a456-426655440000
#   { "UnlockCode": "7c0e1-c3c1a-80c6e-dd5cf-12345" }

# 4. সাইটে: device unlock করো আর তার local S3 credential নাও
snowballEdge unlock-device --endpoint https://10.0.0.50 \
  --manifest-file ./JID123e4567-e89b-12d3-a456-426655440000_manifest.bin \
  --unlock-code 7c0e1-c3c1a-80c6e-dd5cf-12345
snowballEdge describe-device --endpoint https://10.0.0.50 --manifest-file ./..._manifest.bin \
  --unlock-code 7c0e1-c3c1a-80c6e-dd5cf-12345
#   "DeviceType" : "V3_5S", "UnlockStatus" : { "State" : "UNLOCKED" }, ... "PhysicalNetworkInterfaces" ...
snowballEdge list-access-keys       # তারপর: snowballEdge get-secret-access-key --access-key-id <id>

# 5. বড় file device-এর S3 interface দিয়ে copy করো
aws s3 cp /archive/2016/ s3://scan-archive-example/2016/ --recursive \
  --endpoint-url https://10.0.0.50:8443 --profile snowball --ca-bundle ./device-cert.pem

#    ...আর ছোট file tar batch-এ, যেগুলো import-এর সময় খুলে যাবে
tar -cf - /archive/thumbs/batch-0001 | aws s3 cp - s3://scan-archive-example/thumbs/batch-0001.tar \
  --metadata snowball-auto-extract=true --endpoint-url https://10.0.0.50:8443 --profile snowball

# 6. ফেরত পাঠানোর আগে: ০ দিন পরে সবকিছু Deep Archive-এ পাঠানোর lifecycle rule
aws s3api put-bucket-lifecycle-configuration --bucket scan-archive-example \
  --lifecycle-configuration '{"Rules":[{"ID":"to-deep-archive","Status":"Enabled",
    "Filter":{"Prefix":""},"Transitions":[{"Days":0,"StorageClass":"DEEP_ARCHIVE"}]}]}'

# 7. Import-এর পরে: on-premises-এ কিছু মোছার আগে job report আর log পড়ো
aws snowball describe-job --region ap-south-1 --job-id JID123e4567-e89b-12d3-a456-426655440000 \
  --query 'JobMetadata.{State:JobState,Report:DataTransferProgress}'

Command-গুলো নিয়ে কয়েকটা কথা:

• V3_5S সাথে capacity T240 হলো ২১০ TB Storage Optimized device-এর API নাম; V3_5C সাথে T32 হলো Compute Optimized। পুরনো উদাহরণে (কিছু practice test-সহ) EDGE_S বা EDGE দেখবে, যেগুলো বন্ধ হয়ে যাওয়া model-এর নাম ছিল।
• Device-এর S3 interface ব্যবহার করে তার নিজস্ব access key আর certificate, যেগুলো unlock-এর পর Snowball Edge client দিয়ে device থেকে পড়ে নিতে হয়; cloud-এর IAM key কখনো না।
• --shipping-option দেশভেদে SECOND_DAY, NEXT_DAY, EXPRESS বা STANDARD নেয়।

#সারসংক্ষেপ

মূল কথাগুলো

• Link ধীর, ভাগাভাগির, দামি, অস্থির বা অনুপস্থিত হলে network-এর চেয়ে device পাঠানো দ্রুত। সময় = TB × ৮,০০০ ÷ ব্যবহারযোগ্য Gbps second; নিজস্ব link-এর মোটামুটি ৮০% ধরে পরিকল্পনা করো। ১ Gbps-এ ১০০ TB ≈ ১২ দিন। মোটা দাগের নিয়ম: network-এ মোটামুটি এক সপ্তাহের বেশি → Snowball, কিন্তু মোটা pipe তবুও জেতে, আর device তৈরি হতে ৪ সপ্তাহ পর্যন্ত লাগতে পারে।
• Note-এর তালিকা (Snowcone ৮ TB HDD / ১৪ TB SSD, Snowball Edge ৮০ TB / ৪২ TB, Snowmobile ১০০ PB) এখন ইতিহাস: Snowmobile ২০২৪-এ অবসরে, Snowcone আর পুরনো model ১২ নভেম্বর ২০২৪-এ বন্ধ, Snowball Edge ৭ নভেম্বর ২০২৫ থেকে নতুন customer-এর জন্য বন্ধ, ৩১ ডিসেম্বর ২০২৬-এ support শেষ। আজ আছে: Storage Optimized ২১০ TB আর Compute Optimized ২৮ TB, দুটোতেই ১০৪ vCPU, ৪১৬ GB। পরীক্ষা এখনও চেনা উত্তরগুলোই চায়।
• Job type: import (এক device, ≤ ২১০ TB), export (≤ ২১০ TB-র job part, বের হওয়া প্রতি GB-তে খরচ), local compute and storage (কিছুই import করে না)। অবস্থা: Job created (বাতিলের একমাত্র সুযোগ) → Preparing appliance → Preparing shipment → In transit → Delivered → In transit to AWS → At AWS → Importing → Completed। Device যায় শুধু Region-এর দেশের ভেতরে।
• সাইটে: manifest + unlock code দিয়ে OpsHub বা Snowball Edge client-এ unlock; S3 interface (শুধু নাম আর size টেকে) বা NFS (metadata টেকে) দিয়ে copy; snowball-auto-extract সহ tar archive-এ (≤ ১০০ GB, ~১০,০০০ file) ছোট file batch করো; Completed না হওয়া পর্যন্ত source রেখে দাও।
• Edge computing: যেখানে data তৈরি হয় (ট্রাক, জাহাজ, খনি), কম internet নিয়ে সেখানেই প্রসেস করা। Snowball Edge চালায় EC2-compatible instance, IoT Greengrass দিয়ে Lambda (MQTT দিয়ে চালু), EKS Anywhere, local S3-compatible storage আর NFS, পুরোপুরি যোগাযোগ ছাড়াই। ব্যবহার: আগেভাগে প্রসেস, machine learning, transcoding। নতুন customer: Outposts।
• Security: ২৫৬-bit encryption; KMS key → unlock code → manifest → data key, device-এ কোনো key নেই; manifest আর code আলাদা রাখো; পথে TLS; খোলা কঠিন বাক্স, NFC tag, TPM; E Ink label; NIST মেনে মুছে ফেলা; S3-এ SSE।
• Snowball Glacier-এ import করতে পারে না। S3 Standard-এ import করো, তারপর lifecycle rule (০ দিন) দিয়ে Glacier বা Deep Archive, device ফেরত যাওয়ার আগেই বসাও। ১২৮ KB-র ছোট object default-এ বাদ পড়ে; প্রতিটা transition একটা request আর ~৪০ KB metadata, তাই ছোট file ভরে নাও।
• S3-এ import প্রতি GB-তে ফ্রি; job-এ service fee, তাতে সাইটে ১৫ দিন ধরা (us-east-1-এ on demand $১,৮০০ / $৩,২০০), প্রতি বাড়তি দিনে $২৫০, সাথে shipping। বিকল্প: DataSync (online, একটু একটু করে), Transfer Acceleration (দূরত্ব), Data Transfer Terminal (নিজের drive নিয়ে যাও)।

নিজেকে যাচাই করো: Snowball আর Edge Computing৩০টি প্রশ্ন