AWS Snow Family
View on GitHubAWS Snow Family
A set of physical, ruggedized devices and services used to transfer large volumes of data and optionally run compute at the edge when network transfer is impractical. Devices are shipped to customer sites to import or export data and can be used for disconnected or intermittently connected edge compute workloads before data is ingested into AWS. It typically fits in architectures where offline data transfer, pre-staging bulk datasets, or local processing at remote sites is required prior to integration with AWS storage and compute services.
🗂 Resource Category
Migration and Transfer • Storage
🧠 Exam Memory Hook
Think: "Very large or offline data + edge compute needs = AWS Snow Family"
📖 Ownership
Classification: Shared Responsibility Service
AWS responsibilities: AWS owns and operates the physical devices, shipping logistics (when a job is created), device hardware maintenance, and the managed device platform and firmware. AWS manages the device lifecycle processes such as job orchestration, transfer APIs, and the import/export workflows that ingest data into AWS storage services when the device is returned and processed. AWS is responsible for physical infrastructure patching and maintenance of the device firmware and the underlying service platform components provided as part of the Snow service.
Customer responsibilities: The customer is responsible for preparing data, creating and configuring import/export jobs, securing and encrypting data before or during transfer according to their policies, connecting devices to local networks, running and maintaining any applications, guest operating systems, runtimes, libraries, and packaged dependencies that they deploy to the device, and validating successful data transfer after ingestion into AWS. The customer is also responsible for on-device access control, operational monitoring while the device is on-site, maintaining application-level backups, and complying with organisational chain-of-custody requirements.
Patching responsibilities: AWS patches and updates the physical device hardware, device firmware, and the managed device runtime that AWS provides as part of the Snow service. When customers run EC2 instances, containers, or their own applications on Snow devices, the customer patches the guest operating systems, application runtimes, libraries, dependencies, and their applications. If a managed runtime provided by AWS on the device exists, AWS patches that runtime; otherwise patching of user-deployed runtimes is the customer's responsibility.
🏗 Typical Architecture
💡 Top 5 Features
- Physical, ruggedized appliances for offline bulk data transfer to and from AWS.
- Optional local compute capabilities to run workloads at the edge before shipment or while disconnected.
- Integration with Amazon S3 import/export workflows to ingest data after device return.
- Support for encryption and secure transfer workflows integrated with AWS key management and transfer APIs.
- Logistics and job orchestration services to order, track, and return devices for data transfer operations.
✅ Top 5 Use Cases
- Bulk import or export of terabytes to petabytes of data where network transfer is too slow, costly, or unavailable.
- Running analytics or preprocessing on large datasets at remote sites before shipping processed results to AWS.
- Collecting and aggregating field or sensor data in disconnected or intermittently connected environments for later ingestion.
- Seeding cloud storage with media libraries or archival content when initial network seeding would take an impractical time.
- Recovering or transferring backups and archives when physical transport is preferred for compliance or large volume reasons.
🏗 Architecture Placement
AWS Snow Family devices are deployed at the customer edge or on-premises to collect, store, or preprocess data offline and then physically shipped back to AWS for ingestion; they typically connect to local systems and networks for data transfer and to AWS import/export workflows that write to Amazon S3 after processing. Depending on configuration, devices can run local compute workloads and integrate with services such as Amazon EC2 and AWS Lambda after data ingestion. Placement is physical and job-based rather than a global service endpoint, and devices are associated with the account that created the transfer job.
🎯 Commonly Used With
- Amazon S3
- AWS DataSync
- Amazon EC2
- AWS Lambda
- AWS IoT Greengrass
🌍 5 Real-World Examples
- A media production facility stages large raw video files onto a Snowball Edge device to move petabyte-scale footage to Amazon S3 for post-production workflows.
- A healthcare imaging department collects large medical image datasets at remote clinics onto Snow devices for secure transfer and centralised analysis in AWS.
- An oil and gas exploration site runs edge processing on sensor data using a Snow device when the site has limited or no continuous network connectivity before shipping results to AWS.
- A government agency uses Snow devices to move large archive datasets securely to Amazon S3 while preserving chain-of-custody and auditability during physical transport.
- A retail chain aggregates daily transaction and inventory data from stores onto Snow Family devices in areas with poor WAN links, then imports the data into AWS for central analytics.
🎓 AWS Exam Clues
- Choose Snow when network bandwidth or cost makes online transfer impractical for very large data sets.
- Consider Snow for disconnected or intermittently connected edge compute requirements where local processing is needed.
- Use Snow when a physical data movement model with courier logistics and chain-of-custody is acceptable for the project timeline.
- Integrate Snow with Amazon S3 import/export workflows and validate post-ingest processing rather than assuming immediate cloud availability.
- Assess operational factors such as device shipping time, on-site setup, and secure key handling when deciding between Snow and online transfer solutions.
📝 Quick Revision
AWS Snow Family provides physical devices for offline bulk data transfer and optional edge compute for disconnected locations. Use it when network transfer is impractical; consider shipping time, chain-of-custody, device setup, and responsibility for patching guest software and applications.
🏷 Keywords
Snowball Edge • Snowcone • Snowmobile • offline transfer • edge compute • physical appliance • import/export job • ruggedized device • courier logistics • on-device storage • AWS KMS integration • local preprocessing