Snowball and Edge Computing

By the end of this lesson you will be able to

• Explain why a slow, shared or missing network link makes shipping a device faster than sending data, and calculate a network transfer time from the data size, the link speed and the usable share.
• Describe the Snow Family as the notes and the exam know it (Snowcone, Snowball Edge, Snowmobile) and as it is today: two Snowball Edge devices, closed to new customers since November 2025, with support ending on 31 December 2026.
• Walk a Snowball Edge job through its life: job types, job states, unlocking with OpsHub, copying over the S3 interface or NFS, return, import and erasure, and plan for the slow parts.
• Explain edge computing and what runs on a Snowball Edge: EC2-compatible instances, Lambda through IoT Greengrass, EKS Anywhere and local S3-compatible storage.
• Explain how a device in the post stays safe: KMS envelope encryption, the manifest and the unlock code, tamper evidence, the TPM and NIST erasure.
• Land Snowball data in Glacier with an import to S3 and a lifecycle rule, avoid the small-object traps, and choose between Snowball, DataSync, Transfer Acceleration and the newer alternatives.

#When a box beats the network

#The problem with the wire

Lesson 10.11 introduced Snowball as path 8 to S3: the offline path. This lesson is the deep dive. The starting point is the same as the notes put it: you have a huge amount of data on premises, in your own data centre or office, and it must go to AWS, but the internet is very slow, or there are security concerns about sending it over the internet. Then you use a physical device and do an offline transfer.

Five things can make the network the problem, and the slides list them as the challenges of a data migration:

• Limited connectivity. The link is unreliable or barely exists: a ship, a mine, a disaster zone, a rural site.
• Limited bandwidth. 100 Mbps is fine for an office and hopeless for 200 TB.
• High network cost. Some sites pay for every GB, or would need a new, expensive line.
• Shared bandwidth. The same line carries the hospital’s patient system or the factory’s orders, so a migration may use only part of it and cannot max it out.
• Connection stability. A transfer that runs for weeks will see outages, and every restart costs time.

When any of these bites, putting the data in a box and shipping it is faster. That is the idea of the Snow Family. The slides draw it in two lines: a direct upload from the client to an S3 bucket over the internet, against the client copying onto a Snowball, the device being shipped, and AWS importing it into the bucket.

#Doing the maths

The calculation is the core of most exam questions on this topic:

time = data in bits ÷ usable link speed

Three unit facts make it work:

• Networks count in decimal bits. 1 TB is 1,000 GB, and 1 GB is 8 gigabits, so 1 TB = 8,000 gigabits. 1 PB is 1,000 TB.
• A link is sold in bits per second (Mbps, Gbps); copies and disks are measured in bytes per second (MB/s, GB/s). 1 Gbps carries at most 125 MB/s.
• A link is never yours at 100%: protocol overhead, other traffic and the daytime business all take a share. Plan with about 80% of a dedicated link, and much less of a shared one.

(All at 80% of the link. The slides round the same table to 12 days, 30 hours and 3 hours; at 100% the first row would be 9.3 days, 22 hours and 2.2 hours.)

Worked example: 400 TB over a 1 Gbps line that the migration may use at 50%. 400 × 8,000 = 3,200,000 gigabits. Usable speed: 1 × 0.5 = 0.5 Gbps. 3,200,000 ÷ 0.5 = 6,400,000 seconds. ÷ 86,400 = 74 days. Two Snowball Edge devices could do it in a few weeks.

And the other direction: 5 TB over the same line at 80%: 40,000 ÷ 0.8 = 50,000 seconds, about 14 hours. No device will even arrive in that time.

The slides end with a rule of thumb, and the exam uses it constantly: if a transfer would take more than about a week over the network, use Snowball devices. Test it yourself:

Two things the calculator shows that the rule of thumb hides:

• The week is only the road. Shipping, filling and importing a device takes about a week, but AWS warns that preparing a device for your job can take up to 4 weeks. In a real project, order early, or the network may still win.
• A fat pipe beats any courier. 60 TB over a dedicated 10 Gbps link at 80% takes under 17 hours. Snowball is the answer for a slow or shared link, not for every big number.

#The Snow Family, then and now

#What the notes and many practice questions describe

The notes describe three members, and this is still the vocabulary of SAA-C03 questions:

The notes’ exam tricks are the classic ones: a transfer that would take months or years over the internet → Snowball Edge; edge computing or IoT data collection in remote areas → Snowcone or Snowball Edge Compute Optimized.

#What exists today

Much of that table is history. Checked against AWS in October 2026:

• Snowmobile was retired in 2024; AWS stopped offering it by April 2024 and pointed customers to Snowball and DataSync.
• Snowcone (both models) and the older Snowball Edge models (the 80 TB Storage Optimized, the 52-vCPU Compute Optimized and the GPU Compute Optimized) were discontinued on 12 November 2024, with support for existing devices until 12 November 2025.
• Since 7 November 2025, Snowball Edge is available only to existing customers: accounts that had signed up before that date. New customers are pointed to AWS DataSync for online transfers, AWS Data Transfer Terminal for physical transfers, AWS Partner solutions, and AWS Outposts for edge computing.
• AWS has announced that on 31 December 2026 it discontinues support for Snowball devices in all commercial Regions, Storage Optimized and Compute Optimized alike; after that date the Snow console and Snowball resources can no longer be accessed. (GovCloud and dedicated-cloud Region customers with active jobs are not affected by this change.)

The two devices that remain:

Notice the first correction to the notes and the older material: today’s Storage Optimized device has the same 104 vCPUs and 416 GB of memory as the Compute Optimized one (the slides show this too). The difference is the disk: 210 TB for data versus 28 TB of fast NVMe for compute workloads.

The money side: importing data into S3 has no per-GB charge; exporting data out of S3 onto a device is charged per GB like any data transfer out. Shipping is charged at carrier rates. Many small files (1 MB or less) can raise the S3 request charges at import.

#The life of a Snowball job

#Three job types

Everything you do with a device is a job: one unit of work, created in the Snow console or with the API.

• Import into S3. Up to 210 TB copied onto one device and imported into your buckets when it comes back. One job, one device; more data means more jobs (you can clone one).
• Export from S3. Any amount of data from your buckets, split by AWS into job parts of at most 210 TB, one device per part. You can limit it to a key range. When an export device comes back, it is erased.
• Local compute and storage. The device is used on site only, alone or in a cluster of several devices for more durable local storage. It starts empty and nothing is imported at the end; it is erased when it comes back.

All three can run compute (EC2-compatible instances, Lambda) while they are on site. That matters for edge computing: a device that collects data at the edge and should bring it into S3 must be ordered as an import job.

#A job step by step

1. Create the job (state: Job created)

   You choose the job type, the bucket(s), the device type, a KMS key, an IAM role that Snowball may use to write to your buckets, the delivery address and the shipping speed. This is the only state in which you can still cancel the job. Two restrictions are easy to miss: you sign in to the console in the same Region as the bucket, and the device ships only inside that Region’s country (a Mumbai job ships within India; the EU Regions ship to EU member states). Bangladesh is not served by any Snowball Region, so a Dhaka office cannot order one.

2. AWS prepares the device (Preparing appliance, Exporting for export jobs, Preparing shipment)

   AWS loads the software, the job’s encrypted manifest and, if you asked, your AMIs and Lambda functions. For an export job it copies the data out of S3 now. AWS warns that preparation can take up to 4 weeks.

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

   The E Ink display on the case is the shipping label. Shipping speeds depend on the country: next-day or second-day in the US, express in about a day in the EU and Australia, one to seven days within India. The speed you choose applies both ways.

4. Connect, unlock and copy (still Delivered to you)

   Inspect the device for damage, connect power and one network port, and unlock it with the job’s manifest file and unlock code using AWS OpsHub (the free desktop app) or the Snowball Edge client (the command line). Then copy data to it through its S3 interface (aws s3 cp against the device’s endpoint) or an NFS mount.

5. Return (In transit to AWS, At sorting facility, At AWS)

   Power the device off; the E Ink label switches to the return address on its own, and the courier collects it. At AWS it goes through a sorting facility; import typically starts within a day or two of arrival.

6. Import and erase (Importing, Completed)

   AWS checks the device for tampering, imports the data into your bucket, and you get a job report and logs of what succeeded and what failed. Then AWS performs a software erasure that follows the NIST guidelines for media sanitisation.

#Getting data onto the device fast

Most slow Snowball projects are slow on site, not on the road:

• Use a real copy host. A powerful workstation on the 25 Gb or 100 Gb port, not a laptop on a 1 Gb port (the copper port’s light blinks amber at 1 Gb and green at 10 Gb, and AWS advises against 1 Gb for large transfers). For several devices, one copy host per device.
• Run copies in parallel. Several streams at once (aws s3 cp with more concurrent requests, or several copy jobs) keep the device busy.
• Batch small files. Every file is a request with its own overhead, so files of 1 MB or less crawl. Pack them into tar (or zip, tar.gz) archives of about 10,000 files and at most 100 GB each, and copy them with the metadata snowball-auto-extract=true; at import AWS unpacks them back into the original folder structure. (More than 100,000 files per batch slows the import.)
• Pick the interface for the metadata you need. Through the NFS interface, file metadata such as owners and timestamps is kept. Through the S3 interface, only the name and size survive.
• Never delete the source until the job is Completed and you have checked the job report. A lost or damaged device then costs time, not data.

Two older features you may still read about are gone: the plain file interface was removed in March 2024, and Tape Gateway on Snowball Edge (for offline tape migration) was deprecated in March 2024.

#Edge computing with Snowball Edge

#What edge computing means

Edge computing means processing data while it is being created, where it is created: on an edge location in the broad sense, not a CloudFront edge. The slides’ examples are a truck on the road, a ship at sea and a mining station underground. Such places have limited internet and no access to computing power of their own.

You set up a Snowball Edge there to do the computing. Compute Optimized is the device dedicated to this, but Storage Optimized can run workloads too. The slides name three typical uses:

• Pre-process data: filter, aggregate or compress sensor readings so only what matters needs to travel.
• Machine learning: run a trained model (inference) next to the data, for example to flag defects or predict failures.
• Transcode media: convert raw video into smaller formats on site.

#What runs on the device

• EC2-compatible instances. You add AMIs to the job when you order it (including your own images and some from AWS Marketplace), and launch instances on the device with OpsHub or the Snowball Edge client. Instance types use the device’s vCPUs and memory; security groups work much like in a VPC.
• Lambda functions through AWS IoT Greengrass. You install the IoT Greengrass core software on an EC2 instance on the device, then deploy Python Lambda functions as Greengrass components. They can be triggered by MQTT messages from local IoT devices. With the recommended 128 MB each, one job holds about seven functions: this is for light, event-driven code.
• EKS Anywhere. Since 2023 you can run Kubernetes clusters on Snowball Edge devices with Amazon EKS Anywhere, so container workloads run the same way at the edge as in the cloud.
• Local storage. S3-compatible storage on the device (buckets you can write to locally, also on clusters) and an NFS file share.

Everything keeps running without a connection to AWS: the device is unlocked locally, and its instances and storage do not depend on the cloud.

#Edge computing after Snowball

For new customers the edge story has moved on. AWS points them to AWS Outposts (AWS racks installed in your own building, connected to a Region; the smaller Outposts servers are no longer sold to new customers) and, for low latency near cities and mobile networks, Local Zones and Wavelength (chapter 25, Outposts, Batch and more). They need a network connection to AWS, so for a truly disconnected site the exam answer remains Snowball Edge.

#Security: a box of data in the post

A device full of hospital records travels in a courier’s van. Several layers make that safe:

• Encryption with keys that are not on the device. All data on the device is encrypted with 256-bit keys. The chain is envelope encryption: the KMS key you choose for the job encrypts the job’s unlock code; the unlock code decrypts the outer layer of the manifest file; the manifest holds the keys that encrypt and decrypt the data. None of it travels with the device.
• Two separate credentials. You download the manifest and read the 29-character unlock code from the console (or with aws snowball get-job-manifest and get-job-unlock-code). Anyone who has both, plus the device, can read the data, so keep them apart, limit those two permissions with IAM, and let CloudTrail record who fetched them.
• Encryption in transit. Data copied onto the device goes over TLS.
• Tamper evidence. A tamper-resistant enclosure with hidden screws, intrusion switches, anti-tamper inserts and NFC tags you can verify, plus a TPM (Trusted Platform Module) that lets AWS detect changes when the device returns. Inspect it on arrival; if anything looks wrong, do not connect it, and AWS sends a new one.
• The E Ink label. No paper label to swap or misread: the display shows the right address each way, and the job ID at the bottom.
• In S3. Imported objects get server-side encryption (SSE-S3, or your bucket’s default such as SSE-KMS; SSE-C is not offered by the import). You can enforce it with a bucket policy, as in lesson 10.8.
• Afterwards. AWS erases the device following the NIST media-sanitisation guidelines.

#Snowball into Glacier

This is the notes’ favourite trap, and the slides have a whole page on it: Snowball cannot import directly into S3 Glacier or Glacier Deep Archive. A job names S3 buckets; there is no Glacier option, and the device does not speak the Glacier vault API.

The solution is two steps (lesson 10.5 covers lifecycle rules in depth):

1. Import into S3 as usual (S3 Standard by default; the notes also mention Standard-IA, and the idea is the same: an S3 class first).
2. Add an S3 lifecycle rule on the bucket or prefix that transitions the objects to Glacier Flexible Retrieval or Glacier Deep Archive after 0 days. Do it before you ship the device back.

Lifecycle runs in the background, so a 0-day rule moves objects within a day or two, and you pay for Standard only briefly. Two details decide the bill:

• Small objects do not move by default. A lifecycle rule skips objects smaller than 128 KB unless you add a size filter.
• Each transition costs a request, about $0.05 per 1,000 objects into Deep Archive (us-east-1), and every archived object carries about 40 KB of extra billed metadata. Ninety million thumbnails cost about $4,500 just to transition. Pack small files into large tar archives on site and copy them without auto-extract, so each archive becomes one object.

Compare the neighbours from lesson 10.11: DataSync can write into the Glacier classes directly; S3 File Gateway writes Standard, Standard-IA, One Zone-IA or Intelligent-Tiering, and also needs a lifecycle rule to reach Glacier.

#Choosing how to move the data

Snowball is one tool among several. The deciding questions are how much data, how good the link is, and whether the transfer is one-off or ongoing:

Three side notes for real projects:

• Two-phase migrations are the norm: a bulk copy (Snowball, or DataSync over a big link) followed by scheduled DataSync runs for the changes, until cut-over day.
• For new customers, AWS suggests DataSync over a temporary hosted Direct Connect connection for big migrations instead of devices (Direct Connect is in lesson 22.5); chapter 23 compares all the options for moving large amounts of data.
• AWS Data Transfer Terminal (December 2024) is a room in an AWS facility: you reserve a slot, bring your drives, and upload to any AWS endpoint, including S3 and EFS. It is billed per port-hour (for example $300 per port-hour for a North American terminal to a North American Region), with no per-GB fee. It is not yet an exam topic.

#What goes wrong

#Snowball in system design

• Data centre exits. Snowball for the bulk, DataSync for the delta, a cut-over weekend, then the old storage is switched off. The job report and import logs are part of the evidence that nothing was lost.
• Archive projects. Import into a bucket whose lifecycle rule already sends everything to Deep Archive; pack small files first. Ten years of compliance data cost dollars, not thousands, per month.
• Disconnected edge sites. Ships, mines, oil rigs, field hospitals, film sets: Compute Optimized devices collect and process data on site, and devices are swapped and imported on a schedule.
• Data distribution out of AWS. Export jobs send large datasets to a site with poor connectivity (a research partner, a new campus), paying per-GB transfer out.
• Know the end date. For anything planned beyond 2026, design with DataSync, Direct Connect, Data Transfer Terminal or Outposts, and treat Snowball as exam knowledge.

#Try it yourself

These commands work only for accounts that still have Snowball Edge access. The aws snowball API manages jobs; the Snowball Edge client (snowballEdge) and OpsHub talk to the device itself on your network. Addresses and IDs below are examples.

# 1. Save the delivery address once (returns an 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. Create an import job for a Storage Optimized 210 TB device (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. Follow the job state, then fetch the two credentials separately
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 it within the hour)
aws snowball get-job-unlock-code --region ap-south-1 --job-id JID123e4567-e89b-12d3-a456-426655440000
#   { "UnlockCode": "7c0e1-c3c1a-80c6e-dd5cf-12345" }

# 4. On site: unlock the device and get its local S3 credentials
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       # then: snowballEdge get-secret-access-key --access-key-id <id>

# 5. Copy large files through the device's S3 interface
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

#    ...and small files in tar batches that are unpacked at 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. Before shipping back: a lifecycle rule that sends everything to Deep Archive after 0 days
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. After the import: read the job report and logs before deleting anything on premises
aws snowball describe-job --region ap-south-1 --job-id JID123e4567-e89b-12d3-a456-426655440000 \
  --query 'JobMetadata.{State:JobState,Report:DataTransferProgress}'

Notes on the commands:

• V3_5S with capacity T240 is the API name of the 210 TB Storage Optimized device; V3_5C with T32 is the Compute Optimized one. Older examples (including some in practice tests) use EDGE_S or EDGE, which named discontinued models.
• The device’s S3 interface uses its own access keys and certificate, which you read from the device with the Snowball Edge client after unlocking; never your cloud IAM keys.
• --shipping-option accepts SECOND_DAY, NEXT_DAY, EXPRESS or STANDARD, depending on the country.

#Summary

Key takeaways

• When the link is slow, shared, costly, unstable or missing, shipping a device beats the network. time = TB × 8,000 ÷ usable Gbps seconds; plan with about 80% of a dedicated link. 100 TB over 1 Gbps ≈ 12 days. Rule of thumb: more than about a week over the network → Snowball, but a fat pipe still wins, and device preparation can take up to 4 weeks.
• The notes’ line-up (Snowcone 8 TB HDD / 14 TB SSD, Snowball Edge 80 TB / 42 TB, Snowmobile 100 PB) is history: Snowmobile retired 2024, Snowcone and old models discontinued 12 Nov 2024, Snowball Edge closed to new customers 7 Nov 2025, support ends 31 Dec 2026. Today: Storage Optimized 210 TB and Compute Optimized 28 TB, both 104 vCPUs, 416 GB. The exam still uses the classic answers.
• Job types: import (one device, ≤ 210 TB), export (job parts of ≤ 210 TB, charged per GB out), local compute and storage (imports nothing). States: Job created (only time to cancel) → Preparing appliance → Preparing shipment → In transit → Delivered → In transit to AWS → At AWS → Importing → Completed. Ships only within the Region’s country.
• On site: unlock with OpsHub or the Snowball Edge client using the manifest + unlock code; copy via the S3 interface (only name and size kept) or NFS (metadata kept); batch small files into tar archives (≤ 100 GB, ~10,000 files) with snowball-auto-extract; keep the source until Completed.
• Edge computing: process data where it is created (truck, ship, mine) with little internet. Snowball Edge runs EC2-compatible instances, Lambda via IoT Greengrass (MQTT triggers), EKS Anywhere, local S3-compatible storage and NFS, fully disconnected. Uses: pre-processing, machine learning, transcoding. New customers: Outposts.
• Security: 256-bit encryption; KMS key → unlock code → manifest → data keys, no keys on the device; keep manifest and code apart; TLS in transit; tamper-resistant case, NFC tags, TPM; E Ink label; NIST erasure; SSE in S3.
• Snowball cannot import into Glacier. Import into S3 Standard, then a lifecycle rule (0 days) to Glacier or Deep Archive, set before the device ships back. Objects under 128 KB are skipped by default; each transition is a request plus ~40 KB metadata, so pack small files.
• Import into S3 is free per GB; jobs cost a service fee with 15 days on site ($1,800 / $3,200 on demand in us-east-1), $250 per extra day, plus shipping. Alternatives: DataSync (online, incremental), Transfer Acceleration (distance), Data Transfer Terminal (bring your drives).

Self-check: Snowball and Edge Computing30 questions