The AWS Snow Family was created for a practical problem: moving very large datasets or running certain workloads at a location where a reliable high-bandwidth connection to AWS was unavailable. Instead of requiring every byte to cross the public network, organizations could receive ruggedized hardware, load or process data locally, and return devices through a controlled logistics process. Snowcone, Snowball Edge and Snowmobile represented three different physical scales, from a portable device to a truck-based transfer service.
Those historical differences remain useful for understanding offline migration, but they no longer form a current product-selection menu. As of November 2026, Snowcone and Snowmobile are retired, Snowball Edge is unavailable to new customers, and AWS plans to end Snowball support in commercial Regions on December 31, 2026. A new migration plan should begin with the services AWS currently supports: network transfer through AWS DataSync, physical upload through AWS Data Transfer Terminal where offered, supported AWS Partner options, and other tools suited to the workload. The right choice depends on data volume, network capacity, location, security and an achievable cutover window.
Why offline AWS devices were valuable in the first place
Imagine a media studio that has accumulated hundreds of terabytes of raw video at a remote production site. The studio must migrate the footage to AWS for editing and long-term preservation, but it has only a modest network uplink shared with daily operations. Even if the network connection is technically available, a continuous transfer could take longer than the project allows or interfere with normal business traffic. An offline transfer appliance offered a different transport path: load the data locally, physically return the device, then import the objects to AWS.
Whether that approach is better depends on arithmetic as well as logistics. Estimate the usable bandwidth, not the headline link speed, and include protocol overhead, transfer retries, network contention and expected daily uptime. Then compare that duration with device provisioning, shipping, on-site copying, return delivery and final ingestion. A physical device is not automatically quicker because a dataset is large; a fast dedicated connection might complete a transfer without handling any hardware, while a highly constrained link can make physical movement attractive.
Security and data correctness matter throughout. A useful migration must define which files were included, how source data was frozen or changed during transfer, which identity can write the destination, and how a failed import will be reconciled. Device encryption protects against certain physical-loss risks, but the organization still owns sensitive-data classification, site access, custody procedures and the verification that the final object inventory is complete. A success message that says a device was received is not equivalent to proof that every business dataset is available to its intended application.
The history of Snow hardware is valuable because it makes the tradeoff concrete: the data can move through a network, a secured physical carrier, or both in different phases. Understanding cloud migration tradeoffs helps frame the choice around business disruption, security, costs and recovery rather than the appeal of an unusual piece of hardware.
Snowcone: a portable historical edge device, not a new-order option
AWS Snowcone was the smallest member of the old Snow Family. Its compact form was designed for portable or constrained environments where a larger appliance was impractical. Historically, organizations considered it for limited-site data capture and edge processing, including field collection and temporary disconnected workloads. Its scale and portability differentiated it from rack-sized or truck-sized options; the important lesson is that a field device’s weight, power, networking and physical security can affect whether the deployment is feasible at all.
AWS discontinued Snowcone on November 12, 2024. After that date, neither new nor existing customers could order additional Snowcone devices, and AWS continued support for devices already in customer use only through November 12, 2025. This is not an upcoming phase-out or a region-dependent purchase recommendation in November 2026: Snowcone should be presented as a retired historical option. Older tutorials describing its capacity, storage media or supported edge runtimes can explain what it did but must not be interpreted as evidence that AWS still supplies it.
A reader evaluating a portable edge collection project today should ask what actually requires local processing and how the data will eventually synchronize. A rugged computer or suitable partner-managed edge platform may collect and validate data at a remote site, with buffered uploads when connectivity returns. If a managed AWS-consistent on-premises runtime is required, compare the supported AWS Outposts options against the power, form-factor and network requirements. The answer may also be an ordinary securely managed local device plus an approved upload workflow rather than a direct Snowcone replacement.
For historical reference, AWS Snowcone’s compact edge design illustrates why teams once accepted physical-device logistics. Its retirement changes what can be ordered, not the underlying requirement to collect and preserve data where network coverage is unreliable.
Snowball Edge: existing-customer transition and commercial support deadline
AWS Snowball Edge offered larger storage and, in appropriate configurations, local compute capabilities. Storage-optimized and compute-optimized devices addressed different tasks: bulk migration from a constrained data center and processing closer to a remote data source. Operators needed to plan source connectors, local transfer performance, device access and the relationship between stored data and any local processing. A device that could transfer many terabytes did not automatically transform the source database into a consistent application-ready dataset.
The current availability rules are decisive. AWS changed Snowball Edge availability on November 7, 2025 so that the devices would be available only to existing customers. New customers were directed to AWS DataSync, AWS Data Transfer Terminal, AWS Partner solutions or, for edge compute, AWS Outposts. AWS further states that on December 31, 2026, it will discontinue Snowball support in all AWS commercial Regions, including storage-optimized and compute-optimized devices. After that date, commercial-Region customers will not be able to access the AWS Snow Console or Snowball resources.
AWS notes that the December 31, 2026 commercial-Region change does not affect GovCloud or ADC Region customers who have active Snow jobs in the same way. That exception is not a general promise of new device availability or unlimited future support. Organizations with active devices must consult AWS for their precise contracts, regions and transition timelines. New project plans should not treat a historical Snowball appliance specification as a supported procurement recommendation after the published cutoff.
Existing customers need a closeout plan: identify active jobs, confirm which datasets have been copied, reconcile import results, stop new dependencies on the device and arrange return or migration using AWS’s instructions. If a remote application currently runs on Snowball Edge compute, moving the data alone is not sufficient. Its container or virtual-machine workload, local storage expectations, access policies and network behavior also need a tested replacement. A device that is still functioning physically may be operationally unsupported after service retirement.
Snowmobile: the truck-sized service that has already ended
AWS Snowmobile was the most dramatic historical form of offline transfer. It was designed around a secure, truck-based shipping-container approach for extremely large data movements, with extensive site preparation and physical logistics. Its scale made sense only for exceptional migrations where the volume and available network bandwidth justified a complex deployment. The larger the physical transport operation, the more important chain-of-custody, power, network interfaces, site security and transfer reconciliation become.
Snowmobile is no longer an available AWS migration service. AWS’s shutdown inventory records the service as retired on March 14, 2024. Historical descriptions of its very large capacity illustrate a former architecture option, not a truck that an organization can order today. The distinction matters because a current article titled with Snowmobile might otherwise imply that a new customer should compare it alongside DataSync or Transfer Terminal.
For a modern multi-petabyte migration, divide the problem into workloads and transfer phases instead of assuming that one enormous device is necessary. Some data may be moved over an adequately provisioned network, some may use an available secure physical ingestion location, and some may remain on premises until the dependent applications have moved. A successful strategy identifies the authoritative source for each phase and prevents data from diverging while different transfer methods run in parallel.
Large-volume transport also has business constraints that cannot be resolved by capacity alone. A regulatory data set may have residency restrictions; a database may require a coordinated snapshot and change-data-capture handoff; an archive may contain objects that do not need to move at all. These questions should be answered before asking how many devices or network links are required. Snowmobile’s retirement makes this requirements-first approach more relevant, not less.
Compare AWS’s available network and physical transfer options
For many current migrations, AWS recommends AWS DataSync. It supports accelerated, managed movement of supported file and object data between eligible locations and AWS storage services. DataSync can help with repeatable network transfers and verification, but an engineer must still configure appropriate permissions, source access, schedules and destination behavior. It is not a universal application migration product, nor does it replace the need to validate whether the transferred files represent a consistent business snapshot.
AWS Data Transfer Terminal addresses a different physical workflow: a customer can bring its own appropriate storage media and transfer data at supported high-speed AWS ingestion locations. The relevant location, region, capacity, transfer procedures, security requirements and eligibility must be confirmed for the specific customer; it is not equivalent to AWS shipping a Snowball appliance to any field site. A team far from a supported facility should include transportation and operator logistics when comparing it with online transfer.
Where the organization has sustained demand and suitable connectivity, AWS Direct Connect can provide dedicated network connectivity; it does not itself guarantee encryption of every payload or that a large application will cut over without downtime. For secure managed file transfer protocols, supported AWS Transfer Family capabilities may be suitable for workflows such as SFTP. That is not the same thing as an offline bulk migration service. Choose between DataSync, Transfer Terminal, dedicated networking and partner services based on the required path, source type and operating model.
Database migrations require special care. Moving a database backup into AWS does not automatically synchronize later source transactions. A database service may support an initial load plus ongoing replication, while bulk file ingestion may require separate consistency checks. The discussion of AWS Database Migration Service is relevant when the source is a supported database and the desired result is a usable database target rather than simply a copied archive.
For every option, compare the complete path: source preparation, transfer window, destination write permissions, consistency, checksum or reconciliation, application cutover and rollback. An inexpensive transfer that leaves an application unavailable for several days may not be the best solution. Equally, a costly physical workflow with limited advantages over a reliable network connection may not be justified. A useful decision is measurable, not a ranking of device names.
Protect data from departure through S3 ingestion
Physical custody and encryption were central to Snow’s historical security model. The same responsibilities apply when data moves through network services or privately carried media. Inventory the data and identify who has permission to export it, which encryption keys protect the source and destination, and how copies or manifests are stored. A migration operator should not need unrestricted access to every confidential dataset in an organization merely to move the required files.
Once transferred, data commonly lands in Amazon S3 or another selected AWS destination. Object permissions, encryption, bucket policy, expected metadata and lifecycle rules need to be validated after ingestion. For data encrypted with customer-managed AWS KMS keys, the receiving services and authorized application principals must have suitable key permissions. A successful upload can still leave the application unable to read its own data when the key policy is too restrictive.
Use manifests and record counts to detect missing or duplicated transfers. A useful reconciliation records what the source contained at a known point, what the transfer service reported and what objects or records were actually imported. Sample critical datasets at the application level, not only at the byte-count level. An archive containing all its files is not necessarily a correct analytics table, and a database copied during ongoing writes may require transaction-aware consistency methods.
Retention is another part of the migration. Temporary transfer outputs and staging copies may be removed after a verified cutover, but regulated archives or rollback copies may need longer preservation. Define the retention owner and required evidence before applying S3 lifecycle policies. An automated expiration rule that deletes the only recoverable copy of a dataset would undermine a migration that otherwise appeared technically successful.
Plan edge compute separately from the data-transfer mechanism
Snowball Edge also historically served environments requiring local compute with intermittent connectivity. A remote plant might process sensor data locally, send only summary information over a limited link and preserve full raw readings for later synchronization. That is an edge-processing architecture, not just a bulk-transfer job. The replacement design must consider processor capacity, on-site storage, offline operation, authentication, software updates, monitoring and resilience if a single local device fails.
AWS identifies AWS Outposts and relevant partner options as alternatives for edge compute, but they have their own supported hardware, site and connectivity requirements. AWS Outposts is not a drop-in lightweight replacement for every portable Snowcone scenario. A team should decide which AWS services must operate locally, how frequently connectivity is required for management and whether the facility can support the required power and physical security. Other approved hardware may be more practical for a truly mobile or intermittent environment.
Where the main need is to keep using business software during network loss, application design may matter more than the selected hardware. Queue outbound events locally, store work durably, reconcile duplicates after reconnection and give users a clear indication of unsynchronized operations. Test a realistic outage rather than assuming any edge product automatically provides a correct offline-first workflow. The end-of-support deadlines should trigger an application migration and recovery review, not simply a procurement comparison.
Use the lifecycle deadlines to make a safe migration decision
As of November 2026, the three Snow technologies have different historical roles but a common lesson: AWS service availability changes, and migration advice must distinguish a supported current path from a retired example. Snowmobile ended in March 2024; Snowcone ordering ended November 2024 and support for existing devices ended November 2025; Snowball Edge became unavailable to new customers in November 2025 and has a commercial-Region support end date of December 31, 2026. Customers with specific GovCloud or ADC arrangements must review AWS’s documented exception and their actual active jobs rather than extrapolate from commercial-Region rules.
For a new migration, begin by calculating the transfer window at realistic network throughput. Then compare AWS DataSync, Data Transfer Terminal if the geography and process fit, suitable dedicated connectivity, or approved partner methods. For a running edge application, evaluate supported local compute platforms independently. Keep source and destination authorization, object validation, application cutover and recovery tests in the plan before approving a timetable.
The strongest outcome is not selecting the cleverest historical appliance. It is a repeatable migration whose data is complete, whose applications can access the destination safely, whose costs and downtime are understood, and whose operating model will remain supported after cutover. Snowcone, Snowball and Snowmobile illustrate how AWS addressed constrained environments; current AWS migration decisions must follow the services and lifecycle rules that exist now.