These are the concepts that separate an engineer who has merely heard “AWS ships a truck” from one who can actually decide whether it belongs in a migration architecture. We assume you already understand basic data transfer and Snowball Edge — we’re going straight into what makes the truck-scale offering fundamentally different.

The exabyte-scale economics problem

Snowmobile exists to solve a single equation: at sufficiently large data volumes, the cost and time of network transfer — even over the fastest realistic dedicated link — exceeds the cost and time of physically loading storage hardware onto a vehicle and driving it to a data center. AWS’s own published guidance places the crossover point at roughly 10 petabytes and above, where Snowmobile begins to outperform even a fully dedicated, uncontended 1 Gbps or 10 Gbps circuit once you account for real-world network utilization, which is never 100% for months at a stretch. Below that threshold, Snowball Edge devices ordered in bulk and run in parallel are almost always the better tool.

The container as a data center rack, not a storage box

Where a Snowball Edge is a single ruggedized appliance you can carry, a Snowmobile is architecturally a shipping container fitted out as a functioning micro data center: redundant storage nodes, network switching, a dedicated power system, and environmental controls, all installed inside a tamper-resistant, GPS-tracked, video-monitored enclosure on a truck chassis. The mental shift required here is significant — you are not provisioning a device, you are provisioning a temporary, mobile extension of AWS’s data center perimeter, parked in your parking lot.

Up to 100 petabytes per unit, and horizontal scaling by fleet

A single Snowmobile is rated for up to 100 petabytes of usable capacity. For migrations exceeding that figure — genuinely exabyte-scale efforts — AWS deploys multiple Snowmobiles in parallel to the same site, each independently cabled into the customer’s network and loaded concurrently, turning what would be a single linear bottleneck into a horizontally parallelized ingestion operation limited primarily by how many trucks can physically be staged and cabled at the source facility.

High-speed local network ingestion

Data moves from the customer’s existing storage infrastructure into the Snowmobile over a high-speed network connection established on-site — architected to sustain aggregate throughput up to roughly 1 terabit per second per truck under ideal conditions. This is a local, physically-cabled network link between the customer’s data center switching fabric and the truck’s own network interface, not a connection that ever traverses the public internet; the entire ingestion event happens as if the truck were simply another rack rolled into the existing server room.

Encryption as a non-negotiable default, not an option

All data written to a Snowmobile is encrypted using 256-bit AES encryption, with encryption keys managed through AWS Key Management Service and never stored unencrypted on the truck itself. This is architecturally identical in spirit to Snowball Edge’s encryption model, scaled up: even if the physical security perimeter around the vehicle were somehow defeated, the data at rest on the storage nodes is cryptographically useless without keys that never travel with the hardware.

Post-ingest landing in Amazon S3

Once the truck arrives back at an AWS facility, its contents are ingested directly into Amazon S3 through a high-speed internal AWS network connection, at which point the data becomes available through the same S3 APIs, storage classes, and lifecycle policies as data uploaded any other way. Snowmobile’s job ends at the S3 ingestion boundary — everything after that (storage class selection, replication, lifecycle transitions) is standard S3 architecture, not a Snowmobile-specific concern.

Positioning within the broader Snow Family

An advanced architect thinks of the Snow Family as a continuum, not a menu of unrelated products: Snowcone handles terabyte-scale edge collection in constrained spaces, Snowball Edge handles single- to multi-petabyte migrations and edge compute with a device you can ship yourself, and Snowmobile sits at the far end of that continuum, purpose-built for the volumes where even ordering dozens of Snowball Edge devices in parallel becomes logistically harder than a single truck engagement. Framing Snowmobile as “Snowball but bigger” misses the point — it is a fundamentally different operating model involving on-site personnel, custom power and network provisioning, and a physical security program, not simply a larger storage number.

Standard storage protocols at the ingestion interface

The truck presents itself to the customer’s network using standard, familiar network file storage protocols at the point of connection, which is deliberate: it lets existing backup software, file transfer tools, and data movement pipelines write to the Snowmobile largely the same way they would write to any other network-attached storage target, minimizing the amount of custom tooling a customer must build purely to interface with the migration hardware itself.

Geofencing and continuous location verification

Beyond simple GPS tracking, the vehicle’s location is continuously verified against its planned route and expected geofenced boundaries throughout the engagement, with any deviation treated as a security event requiring investigation — a control that matters specifically because the transport phase is the one part of the engagement where the data is physically outside both the customer’s and AWS’s fixed-facility security perimeters simultaneously.

Understanding what physically happens between “AWS backs the truck up to your loading dock” and “your data appears in an S3 bucket” explains every scheduling and bottleneck decision in a Snowmobile engagement.

Inside the container, the architecture is a dense array of storage server nodes connected by an internal high-speed network fabric, presenting itself to the customer’s environment as a network-attached storage endpoint reachable over the on-site cabled connection. AWS field engineers physically connect this endpoint to the customer’s network switching infrastructure, typically requiring the customer to provision a dedicated high-throughput uplink (commonly multiple 40 or 100 gigabit connections aggregated) from their existing storage systems to the point where the truck’s network interface is staged.

flowchart LR
    A[Customer Storage Systems] --> B[On-Site Network Switching]
    B --> C[Dedicated High-Speed Uplink]
    C --> D[Snowmobile Network Interface]
    D --> E[Internal Storage Node Array]
    E --> F[AES-256 Encryption at Write Time]
    F --> G[(Encrypted Storage on Truck)]
    G --> H[Physical Transport to AWS Facility]
    H --> I[High-Speed Internal AWS Network]
    I --> J[Amazon S3 Bucket]
    

Once data begins writing into the storage array, it is encrypted in-line before it is persisted — there is no unencrypted-at-rest window on the device at any point in the pipeline. The storage array itself is architected with redundancy internally (distributing data across multiple nodes and drives inside the truck), so a single drive or node failure during the loading window does not require restarting the entire transfer, an important operational property given that a loading window can span days to weeks depending on source data volume and read throughput of the customer’s own storage systems.

Why source read throughput, not the truck, is usually the real bottleneck

A subtlety senior architects learn quickly: the truck’s roughly 1 terabit-per-second ingestion ceiling is rarely the limiting factor in practice. The customer’s own source storage systems — often older, spinning-disk-based archival systems, tape libraries being decommissioned, or file servers never designed to sustain terabit-scale sequential reads — are almost always the actual bottleneck. This reframes the entire engagement: Snowmobile projects live or die on how well the customer’s export/read pipeline is engineered, not on anything AWS controls once the truck is cabled in.

Metadata handling at exabyte scale

Beyond raw byte throughput, exabyte-scale migrations carry an enormous number of individual file objects, and the metadata operations involved in enumerating, reading permissions for, and tracking the transfer status of billions of individual files can itself become a bottleneck distinct from raw data throughput — a directory listing operation that takes milliseconds on a small file share can take hours across billions of objects on a legacy file system never designed for that scale of enumeration. Advanced migration planning accounts for this by pre-building a file manifest and transfer inventory ahead of the loading window, rather than discovering the metadata bottleneck for the first time once the truck is already on-site and the clock has started.

Environmental and power self-sufficiency

The container includes its own climate control to keep the storage hardware within safe operating temperature and humidity ranges regardless of the outdoor environment where the truck is parked, and its own power distribution, typically drawing from a dedicated power feed arranged as part of site preparation, since ordinary building electrical circuits are not sized for a data-center-density rack’s continuous draw over a multi-week loading window.

Hot-swappable drives and in-flight capacity management

Because the loading window can run for weeks, the storage array is designed around hot-swappable drive modules, allowing AWS field personnel to service or replace a failed component without pausing the ongoing transfer job — an operational necessity given that a dense, exabyte-scale storage array running continuously for weeks will statistically encounter individual component failures as a routine occurrence rather than an exception.

Network switch fabric and multi-path aggregation

Internally, the truck’s network switching fabric aggregates multiple physical network paths into the combined high-throughput link presented to the customer, meaning the practical ingestion speed a customer experiences depends on how many of those aggregated paths their own network cabling and switching infrastructure can actually terminate and drive concurrently — a customer providing only a single physical uplink where multiple were available will see meaningfully lower throughput than the truck’s theoretical ceiling.

On-site AWS personnel as an operational, not just security, resource

AWS field engineers remaining on-site throughout the loading window serve a dual role: they are the security presence described in Chapter 7, and they are also the operational point of contact who monitors loading progress, coordinates drive replacement, and can advise the customer’s team in real time if the export pipeline needs adjustment to better utilize the available link — meaning the engagement is genuinely staffed and monitored throughout, not simply dropped off and picked up later.

Tracing one Snowmobile engagement end to end reveals every decision point an architect can influence, most of which happen well before the truck ever arrives.

The pre-engagement phase as the true project critical path

Experienced program managers treat the engagement, sizing, site survey, and site preparation phases — steps one through three in the timeline above — as the true critical path of the entire project, not the loading phase itself. A truck that arrives to a fully prepared site with a well-engineered, pre-tested export pipeline routinely finishes loading close to its planned schedule; a truck that arrives to an unprepared site or an untested export process almost always slips, regardless of how capable the hardware inside the container is. This is why AWS invests significant effort in the site survey before ever scheduling a delivery date.

The trade-off underneath all of these points is the same one that governs the entire Snow Family: physical transport trades network dependency for logistics dependency. Snowmobile pushes that trade to its most extreme form — the logistics burden (power, space, site access, scheduling) is significant, but in exchange it removes the one constraint that no amount of engineering cleverness can shrink at exabyte scale: the finite speed of a wire.

Opportunity cost of the loading window

An often-underweighted trade-off is the operational impact of the loading process itself on the source systems being read from. If those systems are still serving production traffic, sustaining a high continuous read throughput for the export job can compete with production I/O capacity, forcing a trade-off between migration speed and production performance headroom that has to be actively managed — typically by throttling the export during peak business hours and accelerating it overnight, extending the total loading window in exchange for protecting production stability.

Comparing total cost of ownership, not just line-item price

A mature cost comparison weighs Snowmobile not merely against the per-gigabyte cost of alternative transfer methods, but against the fully loaded cost of the alternative’s timeline: a multi-year network transfer effort carries its own sustained staffing, project management, and opportunity cost of delayed cloud value realization, which frequently dwarfs the nominal bandwidth cost difference once the comparison is done honestly over the full project horizon rather than a simple per-terabyte transfer rate.

Trade-off against building custom transfer infrastructure

Some organizations at the scale where Snowmobile becomes relevant have, historically, considered building their own dedicated high-capacity network circuit or custom bulk-shipping hardware solution rather than engaging AWS’s service. The trade-off there is straightforward once stated plainly: a custom-built circuit or hardware solution is a one-time-use capital investment requiring specialized engineering the organization would then own indefinitely, whereas Snowmobile is engaged, used, and returned, converting what would otherwise be a capital expenditure and long-term maintenance burden into a single bounded service engagement — a trade-off that favors Snowmobile for the overwhelming majority of organizations for whom bulk data migration is a rare, non-repeating event rather than a permanent operational capability worth building in-house.

Performance conversations about Snowmobile are really conversations about three independent throughput ceilings — the source system’s read speed, the on-site network link into the truck, and the number of trucks deployed in parallel — and advanced planning treats all three as separate levers.

The on-site link is rarely the constraint

As covered in Chapter 2, the roughly 1 terabit-per-second aggregate ingestion capability of a single Snowmobile vastly exceeds what most legacy on-premises storage systems can sustain as a continuous read rate. Sizing a migration timeline off the truck’s theoretical maximum, rather than off a realistic assessment of the source system’s sustained read throughput under production load (since the source system is frequently still serving live traffic during the migration), is the most common scalability planning error.

Parallelizing the source read path

The advanced optimization is parallelizing the export process itself — running many concurrent read streams from different source storage nodes or file shares simultaneously, rather than a single sequential copy job — to better saturate the available on-site network link and get closer to the truck’s real ingestion ceiling. This mirrors the same “batch and parallelize” philosophy that governs high-throughput cloud-native data pipelines, just applied to a one-time physical migration instead of an ongoing service.

Scaling beyond a single truck

For migrations that exceed a single Snowmobile’s 100-petabyte capacity, AWS coordinates multiple trucks staged and loaded concurrently at the same or multiple facilities, each independently cabled to its own dedicated network uplink and power feed. This transforms the scalability question from “how fast is one truck” into “how many trucks can this facility physically stage, power, and network simultaneously” — a facilities and logistics constraint at least as much as a technical one.

Post-arrival ingestion throughput into S3

The final leg — offloading the truck’s contents into S3 at the AWS facility — happens over AWS’s own internal, extremely high-throughput network fabric, which is engineered specifically not to become the bottleneck in this pipeline; the constraining factors are always upstream, at the customer’s own facility, not downstream inside AWS’s infrastructure.

Scaling the destination side: S3 write throughput

A less obvious scalability consideration lives entirely on the AWS side of the pipeline: once truck data begins ingesting into S3, the destination bucket’s own request-rate and partitioning characteristics matter. S3 scales its request-handling capacity automatically as sustained request volume increases, but architects who understand this behavior design key-naming schemes for the migrated data that spread writes across a wide range of prefixes from the start, avoiding an artificial hot-spot that would otherwise slow the final ingestion step regardless of how well the on-site portion of the migration went.

Scheduling as a scalability constraint

At the fleet level, the number of Snowmobiles AWS can physically build, maintain, and deploy at any given time is itself a finite, planned resource, meaning very large multi-truck engagements require lead-time scheduling coordinated well in advance through the account team — a real-world capacity constraint distinct from any technical throughput ceiling discussed above, and one that has direct implications for how far ahead a large migration program needs to lock in its Snowmobile engagement.

Reliability for Snowmobile means something different than it does for an always-on cloud service: there is no “uptime percentage” to quote, because the unit of work is a single, bounded, physical engagement. Reliability instead means the loading process tolerates hardware failure without losing progress, and the transport process tolerates real-world logistics risk without losing data.

Internal storage redundancy during the loading window

The storage node array inside the truck distributes data redundantly across multiple nodes and drives during the loading process, so a single drive or node failure mid-transfer does not corrupt already-written data or force a restart of the entire loading job from zero — an essential property given that a full loading window can span weeks, during which some hardware failure across a dense storage array is a statistical near-certainty, not an edge case.

Checksummed, verified transfer

Data integrity is verified through checksum validation performed before the truck departs the customer site, confirming that what was written to the truck’s storage matches the source data bit-for-bit, and again as part of the ingestion process into S3 at the AWS facility — giving two independent verification checkpoints bracketing the highest-risk phase of the entire engagement, the physical transport itself.

Physical and logistical redundancy in transport

Secure transport logistics are planned with contingency routing and monitoring specifically because a single point of failure in a one-time physical transport event (unlike a redundant multi-AZ cloud service) cannot simply be “failed over” to a standby — the entire engagement’s reliability model is built around preventing failure during transport in the first place, through continuous GPS tracking, monitoring, and established secure-logistics procedures, rather than recovering gracefully after the fact.

What “reliability” cannot mean here

It’s worth being explicit about the boundary: Snowmobile reliability does not extend to protecting against a customer’s own decision to migrate without retaining a verified source-side backup until S3 ingestion is fully confirmed. Mature engagements treat the source data as the system of record until the customer has independently validated the arrived data in S3, rather than treating “the truck picked it up” as equivalent to “the data is safely migrated.”

Redundant power and cooling within the container

Just as the storage array avoids single points of failure at the drive and node level, the container’s own power distribution and cooling systems are similarly designed with redundancy, so that a single component failure in the truck’s own infrastructure — a cooling unit or a power supply — does not force an unplanned pause of a multi-week loading job already in progress, protecting the schedule commitment the customer is depending on.

Failure recovery during transport

In the rare event of a transport disruption — a mechanical issue with the vehicle itself, for instance — the engagement’s contingency planning accounts for continued security monitoring of the stationary vehicle and coordinated recovery logistics, rather than leaving a temporarily immobilized truck without continuous oversight; the reliability model treats “vehicle stopped” and “vehicle unmonitored” as two entirely different risk categories, and is engineered to prevent the second regardless of the first.

Reliability as a function of process discipline, not just hardware

It is worth stating directly: the majority of Snowmobile’s reliability guarantee comes from process discipline — the site survey, the pre-loading checklist, the dual checksum verification, the chain-of-custody documentation — rather than from any single piece of redundant hardware. An architect evaluating Snowmobile’s reliability posture for a compliance review should expect to examine and validate these process controls specifically, since they are what actually closes the gap between “the hardware is redundant” and “the entire engagement can be trusted end to end.”

Layered physical security

Security for a vehicle carrying an exabyte of potentially sensitive data cannot rely on a single control. Snowmobile’s physical security model layers multiple independent mechanisms: continuous GPS tracking of the vehicle’s location, 24/7 video surveillance covering the container, and dedicated security personnel accompanying high-sensitivity engagements — none of which is treated as sufficient alone, each compensating for what the others cannot cover.

Encryption architecture

As established in Chapter 1, all data is encrypted at 256-bit AES the moment it is written to the truck’s storage array, with the encryption keys managed entirely through AWS Key Management Service and never stored on the device itself. This means the physical theft or interception of the vehicle alone — absent a completely separate compromise of the customer’s or AWS’s key management infrastructure — does not expose readable data, which is the specific threat model this architecture is designed to defeat.

Chain of custody as a security control, not just paperwork

Every stage of the engagement — cabling, loading, disconnection, departure, transit, arrival, ingestion, and erasure — is documented as part of a formal chain-of-custody record. In regulated industries, this record is frequently as important to the compliance posture as the encryption itself, since auditors and regulators need to verify not just that data was encrypted, but that its physical location and handling were continuously accounted for with no unexplained gap.

Secure data erasure after ingestion

Following customer-confirmed successful ingestion into S3, the truck’s storage array undergoes a secure data sanitization process before the vehicle is redeployed to another customer engagement, ensuring no residual customer data persists on shared physical infrastructure between unrelated engagements — an obvious but essential control given the vehicle’s fleet reuse model.

Personnel vetting and access control

AWS field personnel involved in a Snowmobile engagement operate under the same rigorous background-check and access-control standards applied across AWS’s physical data center security program, since the truck is, functionally, a temporary extension of that same security perimeter. Access to the vehicle’s interior during transport is restricted and logged, consistent with the chain-of-custody principle that every point of physical access to the data must be individually accountable, not merely covered by a general assumption of trustworthy staff.

Tamper-evident seals as a detection layer

In addition to active monitoring, tamper-evident physical seals on the container provide a passive detection layer — a control that does not prevent an intrusion attempt on its own, but ensures that any attempt leaves unambiguous physical evidence discoverable at the next inspection point, complementing the active GPS and video monitoring with a control that keeps working even in a hypothetical gap in active surveillance.

A genuinely advanced question for a physical logistics service: what does observability even mean when the “system” is a truck, and how do you know the migration is on track before it’s too late to course-correct?

Throughout the engagement, AWS provides status visibility through the same management console and support channels used for other Snow Family services, reporting job status transitions — order placed, site survey scheduled, truck delivered, data loading in progress, transfer complete, in transit, ingestion complete — giving the customer a persistent, checkable status rather than relying on ad hoc phone updates from field personnel.

Loading progress as the critical operational signal

During the multi-day-to-multi-week loading window, the single most important operational metric is bytes transferred versus total planned volume, tracked against the elapsed time, since this is what surfaces the source-read-throughput bottleneck described in Chapter 5 early enough to intervene — for example, by adding parallel export streams — rather than discovering at the end of the planned window that the transfer is far from complete.

Checksum verification as a monitoring checkpoint

The pre-departure and post-ingestion checksum verification steps function as explicit monitoring checkpoints in their own right: a checksum mismatch at either stage is the signal that triggers investigation before the engagement is allowed to proceed to its next phase, rather than being discovered only when a customer later tries to read corrupted data out of S3.

Audit trail via AWS account activity logging

Job creation, status changes, and completion events associated with the Snowmobile engagement are recorded in the customer’s AWS account activity history, giving the same kind of auditable record used elsewhere in AWS for compliance review — who initiated the engagement, when each phase transitioned, and when data became available in the destination S3 bucket.

Post-migration reconciliation reporting

Upon completion, a reconciliation report is the standard artifact used to formally close out the engagement — comparing the total object count and byte volume recorded at source export time against what was verified as successfully ingested into the destination S3 bucket. This report becomes the durable evidence a compliance or audit function relies on long after the truck itself has been redeployed to another customer, which is why generating and archiving it as a first-class deliverable, rather than treating the console status screen as sufficient documentation, is standard practice in regulated migrations.

Unlike a service you provision through an API, deploying Snowmobile is fundamentally a procurement and logistics exercise conducted in partnership with an AWS account team, and understanding that process is itself an advanced deployment competency.

Engagement through the AWS account team, not self-service

Snowmobile is not a self-service, console-provisioned resource the way Snowball Edge is; it is engaged directly through an AWS account team given the scale of logistics, facilities coordination, and custom sizing involved. This is a deliberate deployment model difference worth internalizing for interview and planning purposes: at exabyte scale, no standardized self-service workflow can substitute for a human-led site survey and customized logistics plan.

Site readiness as a deployment prerequisite

Successful deployment depends entirely on the customer completing site preparation identified during the survey phase — dedicated power capacity, a high-speed network cross-connect point, and adequate physical space and loading-dock access for a large vehicle — before the truck’s scheduled arrival. Treating site preparation as a parallel, independent workstream that must be complete before the engagement’s clock starts, rather than something addressed reactively once the truck arrives, is the deployment discipline that keeps large migrations on schedule.

Integration into a broader data center exit strategy

Snowmobile is most commonly deployed as one phase within a larger data center decommissioning or cloud-migration program, not as a standalone project. It typically follows an assessment and data-classification phase (deciding what actually needs to move versus what can be archived or deleted) and precedes a post-migration validation and cutover phase, making it the bulk-transport middle chapter of a much longer organizational migration story rather than the entire story itself.

Landing zone and S3 architecture readiness

Because Snowmobile’s output is a raw landing of data into Amazon S3, the destination bucket structure, storage class strategy, and downstream lifecycle policies should be fully designed and provisioned before the truck begins loading — not improvised after an exabyte of data has already landed in a single flat, unorganized bucket that then has to be reorganized in place at enormous scale.

Multi-account and multi-region destination planning

For organizations operating a multi-account AWS Organizations structure, the deployment plan must decide in advance which account and region will serve as the S3 destination, since moving an already-ingested exabyte-scale dataset between AWS accounts or regions afterward reintroduces exactly the network-transfer bottleneck Snowmobile was engaged to avoid in the first place — making destination account and region selection one of the highest-stakes decisions in the entire engagement, not an afterthought settled once data has already arrived.

Coordinating with change freezes and business calendars

Because the on-site loading window can place meaningful read load on production source systems, deployment scheduling is commonly coordinated around the business’s own change-freeze calendar — avoiding peak retail seasons, financial close periods, or other periods where source-system stability is least tolerant of additional load — treating the Snowmobile schedule as a variable to be fit around the business, not a fixed external constraint the business must accommodate unconditionally.

Best practices

• Validate that data volume genuinely exceeds the economic crossover point before engaging Snowmobile; run the comparison against Snowball Edge fleets and Direct Connect explicitly, not by assumption.
• Engineer a parallelized, multi-stream source export pipeline ahead of the truck’s arrival rather than relying on a single sequential copy process.
• Complete power and network site preparation fully before the scheduled arrival date, treating it as a hard dependency with its own project timeline.
• Design the destination S3 bucket structure, storage classes, and lifecycle policies before data lands, not after.
• Retain and independently verify the source data until ingestion into S3 is confirmed via checksum comparison, before decommissioning any source system.
• Treat Snowmobile as one phase of a larger migration program, with clear phases before it (classification, assessment) and after it (delta sync, cutover, validation).
• Track bytes-transferred-versus-elapsed-time continuously during the loading window to catch a throughput shortfall early enough to add parallel export streams.

Common mistakes

Why these mistakes keep recurring

Nearly every mistake above traces back to treating Snowmobile as a purely technical procurement rather than a joint logistics-and-engineering program. Because the truck itself performs reliably within its own well-engineered boundaries, nearly all real-world friction happens at the seams — the customer’s source systems, the customer’s site readiness, and the customer’s downstream S3 design — which is exactly where a program manager’s attention, not an engineer’s, needs to be focused earliest.

Building an internal readiness checklist

Organizations that have run Snowmobile engagements successfully more than once typically formalize the site-preparation and export-pipeline work into a reusable internal readiness checklist — covering power capacity confirmation, network cross-connect testing, parallel export tooling, destination bucket provisioning, and a source-retention policy — turning what was originally a one-off, ad hoc coordination effort into a repeatable program artifact that shortens the lead time and reduces risk on every subsequent engagement, whether for a later phase of the same migration or an entirely separate business unit’s data center exit.

Involving compliance and legal stakeholders early

For regulated data sets, the single most costly best-practice omission is failing to involve compliance, legal, and data-governance stakeholders during the sizing and engagement phase rather than after site preparation has already begun. Questions about data residency during transport, cross-border movement if the destination region differs from the source country, and required retention of the chain-of-custody documentation are far cheaper to resolve before a truck and crew are scheduled than after, when a compliance objection discovered mid-engagement can force a costly pause or re-scoping of an already-mobilized project.

AWS Snowmobile solves exactly one problem, extremely well: moving data at a scale where physics, not engineering effort, makes network transfer impractical. Understanding its real bottlenecks and logistics dependencies is what separates a smooth exabyte-scale migration from a stalled one.