The Container, Not the Device

Where Snowball Edge is a single ruggedized appliance you unlock on a desk, Snowmobile is an entire 45-foot ISO shipping container, containing a rack-mounted, high-capacity storage cluster, delivered by truck and parked on your premises for the duration of the transfer — often weeks. The unit of transfer isn’t “a device,” it’s effectively “a mobile data center,” and every operational consideration that follows from that scale is what separates it from every other AWS transfer service.

On-Site Network Connection, Not Manual Copying

Unlike smaller Snow Family devices where data is typically copied manually over NFS or an S3-compatible endpoint by an individual operator, Snowmobile is physically cabled into your existing data center network via a high-speed fiber connection provided as part of the setup, and data transfer is coordinated jointly between your team and AWS engineers who are present on site for the duration of the job.

Capacity Measured in Petabytes, Not Terabytes

A single Snowmobile is designed to move up to 100 petabytes of data — several orders of magnitude beyond what a single Snowball Edge device can hold. For datasets that genuinely approach or exceed that scale, multiple Snowmobiles can be deployed in parallel, each handling a separate portion of the migration, coordinated as one overall project rather than one single job.

A Dedicated, Escorted Logistics Operation

Because a Snowmobile carries an extraordinarily large and sensitive dataset in a single physical unit, its transport is treated as a dedicated logistics operation rather than routine commercial freight — including GPS tracking of the vehicle, continuous monitoring, and optional armed security escort for particularly sensitive migrations, none of which apply to the standard carrier-based shipping used for smaller Snow Family devices.

AWS-Managed On-Site Presence

Snowmobile engagements typically include AWS personnel present on site to manage the physical setup, oversee the network connection, and coordinate the transfer — a meaningfully different operational model from Snowball Edge, where the customer independently unlocks and operates the device using OpsHub with no AWS staff physically present.

Why It’s Measured in Trucks, Not Racks

It helps to think of Snowmobile as a unit of migration capacity rather than a piece of hardware you configure. Where a Snowball Edge order asks “how many devices,” a Snowmobile engagement asks “how many trucks, over how many weeks, at how many sites” — a planning question closer to a construction or logistics project than a typical cloud infrastructure request. That framing shift is the single most important adjustment intermediate practitioners need to make when moving from Snowball Edge planning to Snowmobile planning.

Not a Permanent Fixture

A Snowmobile is deployed for the duration of a single engagement and then returns to AWS — it isn’t leased long-term or left on site as ongoing infrastructure. Once the transfer, verification, and disconnection steps are complete, the container departs, and any further data movement needs — ongoing incremental syncs, for instance — are handled through a different, typically network-based mechanism entirely.

flowchart LR
    Planning["Engagement Planning
with AWS Team"] --> Prep["Site Preparation
Power / Space / Access"]
    Prep --> Delivery["Snowmobile Delivered
via Escorted Transport"]
    Delivery --> Connect["Fiber Cabled to
Customer Data Center"]
    Connect --> Transfer["High-Speed Transfer
Local DC to Container"]
    Transfer --> Verify["On-Site Verification
of Copied Data"]
    Verify --> Depart["Container Ships Back
Escorted Transport"]
    Depart --> AWSFacility["AWS Facility"]
    AWSFacility --> Import["Import Pipeline
Decrypt + Validate"]
    Import --> S3[("Destination S3 Bucket")]
        

The presence of dedicated planning and verification phases on both ends of the diagram is not incidental — it reflects the fact that a single Snowmobile carries a dataset large enough that even a modest error rate, left uncaught, could represent a genuinely significant volume of corrupted or missing data. Verification isn’t an optional nicety here; it’s a structurally necessary phase given the scale involved.

Comparing the Component Stack to Snowball Edge

It’s worth explicitly contrasting this architecture against the smaller Snow Family devices covered elsewhere. A Snowball Edge job has essentially three moving parts: the device, a carrier, and the customer’s own local network. Snowmobile adds two entirely new layers with no equivalent at smaller scale — a dedicated on-site AWS engineering presence, and a formal site-preparation phase treating the customer’s facility itself as part of the architecture, not just the destination for a shipped box. Recognizing which layer a given problem belongs to — is this a data-transfer issue, a network-connection issue, or a physical-logistics issue — is a genuinely useful diagnostic habit once an engagement is underway.

Independence from the Customer’s Existing Infrastructure

Aside from the power connection and the network fiber link, the container is largely self-contained — its own climate control, its own storage and compute for managing the transfer, its own security systems — meaning it doesn’t depend on the customer’s facility for anything beyond those two connection points. This self-sufficiency is deliberate: it lets Snowmobile operate reliably across an enormous range of facility types and conditions without needing to be custom-integrated into each customer’s specific data center design.

Understanding how a Snowmobile actually fills up, and how the resulting data eventually lands in S3, requires separating the on-site transfer mechanics from what happens once the container leaves.

Fiber-Speed Local Transfer

Once cabled into the customer’s data center network, the container’s storage cluster can sustain transfer rates far beyond typical internet bandwidth — the entire reason Snowmobile exists is that at sufficiently large data volumes, even a fast dedicated internet circuit would take months or years to move the same volume that a direct, high-speed local fiber link can move in a matter of weeks.

Encryption at Rest Inside the Container

Data written into the Snowmobile’s storage is encrypted using AWS Key Management Service-managed keys, following the same core security principle used across the Snow Family: the encryption keys are never stored in a form usable without the associated job credentials, meaning the physical container itself — even during transport — never holds readable customer data on its own.

Live Monitoring During Transfer

Throughout the on-site transfer window, AWS engineers and the customer’s team jointly monitor transfer progress, throughput, and any errors in real time — closer to an ongoing managed operation than a fire-and-forget copy job, which is a direct consequence of both the scale involved and the multi-week duration a Snowmobile typically remains on site.

Import After Return

Once the container is physically returned to an AWS facility, its contents are imported into the destination S3 bucket through the same internal, high-throughput ingestion infrastructure used for Snowball Edge devices — the import mechanism itself isn’t fundamentally different at that stage, even though everything leading up to it is operating at a completely different scale.

Why Import Isn’t the Bottleneck

Given how much attention the on-site transfer phase requires, it’s worth explicitly noting that the AWS-side import process, once the container arrives back at a facility, is comparatively fast — running over dedicated internal infrastructure built specifically for ingesting Snow Family data at scale. The overwhelming majority of a Snowmobile engagement’s total duration is spent on-site collecting data and in physical transit, not waiting on AWS to process what’s already been collected.

Data Consistency During a Multi-Week Transfer

Because a Snowmobile engagement can span days to weeks on site, engineers need to account for the fact that source systems may continue changing during that window if they’re not fully frozen for the migration. Common approaches include scheduling the transfer against a read-only snapshot or backup of the source data, or explicitly accepting that the resulting dataset represents a rolling window rather than a single fixed point in time, and planning a smaller follow-up delta transfer afterward to reconcile any changes that occurred during the collection period.

The trade-off Snowmobile makes is an extension of the same principle behind the rest of the Snow Family, taken to its logical extreme: at sufficiently large data volumes, physical transport beats network transfer by such a wide margin that the operational overhead of coordinating trucks, site preparation, and on-site AWS personnel becomes worthwhile. But that overhead is real, and for datasets that don’t clear the multi-petabyte threshold where Snowmobile’s advantages actually kick in, a fleet of Snowball Edge devices — or even a single one — remains the simpler, faster-to-start option.

The Break-Even Point in Practical Terms

Roughly speaking, the case for Snowmobile strengthens as total data volume climbs into the multi-petabyte range and beyond, where the cumulative shipping cycles required for an equivalent fleet of smaller devices would stretch into many months, and the coordination overhead of managing that many parallel device jobs starts to rival the overhead of a single, larger, more structured engagement. Below that range, the simplicity of ordering one or a handful of Snowball Edge devices through the console typically wins on both speed-to-start and total operational effort.

Snowmobile’s performance characteristics are dominated by two factors most other AWS services never have to think about: the physical logistics timeline and the sustained throughput of a direct fiber connection into an enormous storage cluster.

Sustained High-Throughput Transfer

Because the container connects directly to the customer’s own network infrastructure via dedicated fiber, sustained transfer rates are governed primarily by the customer’s own network and source storage capabilities, not by any internet-facing bottleneck — meaning organizations with genuinely high-performance internal networks can fill a Snowmobile’s storage far faster than they could ever push the same volume out over a WAN link.

Scaling to Multiple Snowmobiles

For migrations exceeding a single unit’s 100-petabyte capacity, multiple Snowmobiles can be deployed to the same or multiple sites, run in parallel, and coordinated as one overall migration project — allowing genuinely exabyte-scale data center decommissions to be completed within a bounded, planned timeframe rather than stretching indefinitely.

Where the Bottleneck Actually Lives

For most Snowmobile engagements, the limiting factor on transfer speed ends up being the customer’s own source storage read throughput — how fast the existing systems can actually be read from — rather than the fiber link or the container’s ingest capacity. This mirrors a pattern seen throughout the Snow Family: AWS’s side of the pipeline is rarely the bottleneck; the customer’s own infrastructure usually is.

Planning Lead Time as a Scalability Constraint

Because Snowmobile units and the associated logistics coordination are a genuinely scarce, high-touch resource, engagement lead time itself becomes a planning constraint — organizations considering Snowmobile for a future migration typically need to engage AWS well in advance of their target start date, treating scheduling availability as part of the overall project timeline rather than an afterthought.

Diminishing Returns Beyond a Certain Fleet Size

While multiple Snowmobiles can run in parallel, coordinating a very large number of simultaneous units introduces its own overhead — site logistics across multiple facilities, synchronized on-site AWS staffing, and aggregate network capacity planning across all connection points at once. In practice, the scalability of “just add another Snowmobile” has practical limits driven by coordination complexity rather than any hard technical ceiling, which is another reason engagement scoping happens as a genuine planning exercise rather than a simple capacity calculation.

Reliability for a single, enormous physical asset carrying a genuinely irreplaceable dataset requires a fundamentally different posture than reliability for a small, easily-replaced device — there’s no “just ship another one” fallback if something goes wrong with the one Snowmobile carrying your entire migration.

Redundant Storage Within the Container

The storage architecture inside a Snowmobile is built with internal redundancy across its rack-mounted storage nodes, so that a single component or drive failure within the container doesn’t translate directly into data loss for the customer — an important distinction from a single small Snowball Edge device, which carries no such internal redundancy on its own.

On-Site Verification Before Departure

Because a Snowmobile carries such an enormous volume of data in one physical unit, verification against source checksums happens deliberately while the container is still connected on site and the original source data is still available — meaning any detected gap or corruption can be immediately re-copied before the container ever leaves, rather than discovered only after weeks of transit and import back at AWS.

Environmental and Physical Protection

The container’s onboard climate control and structural design protect the storage hardware against environmental extremes during both the on-site period and transit, while GPS tracking and continuous monitoring provide real-time visibility into the physical asset’s location and condition throughout the entire engagement — treating a single Snowmobile with a level of physical oversight closer to a secure logistics operation than routine freight shipping.

What a Reliability Failure Actually Looks Like

Because of the redundancy and verification measures described above, a genuine data-loss event tied to Snowmobile itself would be an extremely rare occurrence rather than a routine risk to plan around. The more realistic reliability consideration for customers is scheduling risk — a delay in site readiness, network connectivity issues discovered during setup, or unexpected data volume exceeding original scoping estimates — which is why the engagement scoping and site preparation phases receive as much attention as they do.

Redundancy Doesn’t Replace Source-Side Backups

Internal storage redundancy inside the container protects against hardware failure once data has been written to it, but it’s not a substitute for the customer maintaining their own backups of source data until final import is confirmed complete. Just as with smaller Snow Family devices, the disciplined practice of not deleting or decommissioning source systems until verified import is confirmed remains the customer’s responsibility, regardless of how much internal redundancy the Snowmobile itself carries.

Encryption Model

Data transferred onto a Snowmobile is encrypted using AWS Key Management Service-managed 256-bit keys, following the same core principle as the rest of the Snow Family: decryption happens only once the data is imported at an AWS facility, using keys tied to the specific job, never in a directly usable form while the data sits inside the container.

GPS Tracking and Continuous Monitoring

Throughout transport, the Snowmobile’s location is continuously tracked via GPS, and the container itself is monitored for tampering or environmental anomalies, giving both AWS and the customer real-time visibility into the physical asset’s status at every point in the journey — a security layer with no equivalent in standard commercial carrier shipping used for smaller devices.

Optional Armed Security Escort

For engagements involving particularly sensitive data — certain government, defense, or highly regulated commercial workloads — AWS offers the option of armed security escort during transport, reflecting the reality that a single Snowmobile can carry a dataset valuable and sensitive enough to warrant physical protection well beyond what’s appropriate for a small shipping box.

Chain of Custody Documentation

Given the scale and sensitivity typical of Snowmobile engagements, detailed chain-of-custody documentation — covering delivery, on-site presence, transfer activity, and return transport — is maintained throughout the engagement, supporting the compliance and audit requirements that regulated organizations commonly need to satisfy for a migration of this magnitude.

IAM and Job Governance

As with other Snow Family jobs, the AWS-side configuration of a Snowmobile engagement — destination bucket, associated KMS keys, and job permissions — is governed through standard IAM policies, ensuring that the digital access-control model remains consistent with the rest of an organization’s AWS security posture even though the physical logistics look entirely different.

Personnel Vetting for On-Site Engineers

Because Snowmobile engagements involve AWS personnel physically present at a customer facility, often for regulated or highly sensitive workloads, organizations with strict facility-access requirements typically coordinate personnel vetting and access procedures as part of the engagement planning — treating on-site AWS staff the same way they would treat any other personnel granted physical access to sensitive infrastructure.

Documenting the Custody Handoff at Each Stage

Chain-of-custody documentation typically records specific handoff points — delivery to the customer site, connection to the network, disconnection after verified transfer, departure, and arrival back at an AWS facility — each with its own timestamp and, where required, sign-off. This granular record is what allows organizations to demonstrate exactly when the data was under whose physical control at every stage of the engagement, rather than relying on a single start-and-end record for the entire multi-week process.

Data Deletion Guarantees After Import

Once import is verified complete and the engagement closes out, the container’s storage is securely wiped following the same rigorous media sanitization standards applied across the rest of the Snow Family, ensuring no residual customer data persists on the physical hardware before it’s prepared for a future engagement with a different customer.

Why This Level of Rigor Is Proportionate

It’s worth stepping back and noting that the security measures covered in this chapter — GPS tracking, armed escort options, personnel vetting, granular custody records — are proportionate to what’s actually at stake: a single Snowmobile can carry a dataset representing a meaningful fraction of an entire organization’s institutional history or intellectual property. Applying this level of physical and procedural rigor isn’t excessive caution; it’s the appropriate response to concentrating that much value into one physical, movable asset.

Joint Monitoring During Transfer

Unlike a self-service Snowball Edge job where a customer independently watches OpsHub, Snowmobile transfer progress is monitored jointly by the on-site AWS team and the customer, with regular status updates on volume transferred, throughput, and any issues encountered — a collaborative operational rhythm that reflects both the scale and the duration of a typical engagement.

Physical Asset Tracking

Beyond data-transfer metrics, the physical Snowmobile unit itself is tracked throughout its journey — location, security status, and environmental conditions inside the container — giving both parties a real-time operational picture that spans both the digital transfer progress and the physical asset’s condition and whereabouts.

CloudTrail and Console Visibility

Job-level configuration and status changes for a Snowmobile engagement are still reflected in AWS CloudTrail and the Snow Family console, consistent with the rest of the Snow Family, giving organizations a familiar audit trail for the digital side of the engagement even though much of the operational monitoring happens through direct, on-site coordination rather than purely through console dashboards.

Post-Engagement Reporting

At the conclusion of an engagement, customers typically receive a summary covering total data transferred, verification results, and the engagement timeline — documentation that serves both as a project closeout record and as supporting evidence for any compliance or audit requirements tied to the migration.

Distinguishing Transfer Metrics From Physical Logistics Metrics

It’s useful to track two separate categories of information throughout an engagement rather than conflating them: data-transfer metrics (volume moved, throughput, verification status) and physical-logistics metrics (container location, security status, schedule adherence). A slowdown in one doesn’t necessarily indicate a problem in the other — network throughput can be excellent while a scheduling delay affects the physical timeline, or vice versa — and keeping them conceptually separate makes it easier to diagnose which part of the engagement, if any, actually needs attention at a given moment.

A Consultative Engagement Model

Unlike Snowball Edge or Snowcone, which can be ordered directly through the console for straightforward jobs, Snowmobile engagements begin with direct consultation between the customer and AWS to assess data volume, site feasibility, and project timeline — reflecting the genuinely bespoke, high-touch nature of an engagement that involves physically parking a truck-mounted data center at a customer facility.

Why Self-Service Doesn’t Scale to This Model

A self-service console flow works well when the variables involved are simple — device type, destination bucket, shipping address. Snowmobile introduces variables that genuinely require human judgment and site-specific assessment: does the loading dock physically accommodate a 45-foot trailer, is there sufficient power capacity nearby, does the facility’s security policy accommodate an external team on site for weeks. None of those questions can be answered by a dropdown menu, which is precisely why the engagement model shifts from self-service to consultative at this scale.

Fitting Into a Broader Migration Strategy

Organizations undertaking a full data center decommission or a large-scale cloud migration often use Snowmobile specifically for the bulk, one-time transfer of the largest, most static portion of their existing data, while using smaller Snow Family devices or network-based tools like AWS DataSync for smaller subsets, ongoing incremental data, or remote sites that don’t warrant the scale of a Snowmobile engagement — treating it as one component of a broader, multi-tool migration plan rather than a universal solution.

Multi-Site and Multi-Unit Coordination

For organizations with data spread across multiple large facilities, engagements can involve multiple Snowmobiles deployed to different sites concurrently, each running its own on-site transfer in parallel, with the overall migration coordinated as a single program across sites rather than a sequence of independent, disconnected projects.

Interfacing with Existing Network Architecture

Establishing the fiber connection between a customer’s data center and the container typically requires coordination with the customer’s own network engineering team — confirming available ports, switch capacity, and routing configuration ahead of the physical connection being made. Treating this as a networking project with its own design review, rather than assuming the connection will be plug-and-play regardless of the customer’s existing architecture, avoids delays once the container is already on site and the clock on the engagement has effectively started.

Coordinating Facility Access for a Multi-Week Presence

Because AWS personnel and the physical container remain on site for an extended period, facility access policies — badge issuance, escort requirements, working-hours restrictions — need to be worked out in advance as part of the engagement plan, particularly for secure or regulated facilities where visitor access is normally tightly controlled. Addressing this during initial scoping rather than on the delivery date itself avoids a scenario where the container has arrived but the team responsible for operating it can’t yet get through the front door.

Pattern: Reserve Snowmobile for the Bulk, Static Portion

Mature migration plans use Snowmobile specifically for the large, relatively static core of a dataset — archival content, historical records, decommissioned system backups — while routing smaller, actively changing, or geographically distributed data through other tools, avoiding the mistake of trying to force every piece of a migration through a single, high-overhead mechanism regardless of fit.

Pattern: Scope Conservatively, Verify Continuously

Because underestimating total data volume mid-engagement is a real operational risk, experienced teams deliberately scope Snowmobile engagements with margin for discovered data beyond the initial estimate, and lean on the continuous, joint on-site monitoring described earlier to catch and address scoping gaps early rather than assuming the original estimate will hold exactly.

Designate a Single Point of Contact on Each Side

Given how many teams a Snowmobile engagement typically touches — networking, facilities, security, data owners, and the AWS on-site team — designating one clear point of contact on the customer side to coordinate across those groups, mirrored by AWS’s own engagement lead, avoids the common failure mode where decisions stall because no single person has visibility into every workstream at once.

Rehearse the Breakdown, Not Just the Setup

Teams often plan the delivery and connection phase in detail but give less thought to the disconnection and departure process — confirming who signs off on verification results, how quickly the site needs to be cleared, and what documentation needs to be collected before the container leaves. Planning the end of the engagement with the same rigor as the beginning avoids a rushed, poorly documented close-out at exactly the point where thorough records matter most.

Keep a Written Record of Every Scoping Assumption

Because engagement scoping involves estimates that can shift once the actual transfer begins, documenting the assumptions behind the original data-volume estimate — which systems were counted, whether snapshots and backups were included, what the source throughput assumption was based on — gives the team a clear reference point for understanding exactly what changed if the real numbers diverge from the plan, rather than debating from memory mid-engagement about what was originally assumed.