AWS SAA-C03: Data Transfer & Migration — Study Guide

By Laurynas Brazys · 15 July 2026 · #amazon #aws #saa-c03 #data-transfer-migration #certification #exam-prep #study-guide

Part of the AWS SAA-C03 Complete Study Guide. Practice these concepts with verified answers in the AWS/Amazon exam hub, or take timed practice tests on ExamRoll.io.

The Bandwidth-vs-Shipping Decision

Every migration begins with arithmetic. Compute the theoretical transfer time before choosing a tool:

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

The numbers are unforgiving. At a sustained 100 Mbps, 1 TB takes roughly 24 hours; at 1 Gbps, about 2.5 hours. A 15 Mbps link capped at 70% utilization delivers only ~113 GB per day, so 20 TB would need more than 175 days. Transferring 150 TB overnight (10 hours at 80% of 100 Mbps) yields ~360 GB per night, or 10.5 TB per month — nowhere near a 30-day deadline. Even fully saturated 24/7, 100 Mbps moves only ~1 TB/day, so 150 TB needs 150 days minimum. At petabyte scale the picture worsens: a 500 Mbps link at real-world efficiency delivers roughly 5.4 TB/day of theoretical throughput, meaning 10 PB would require more than five years of continuous transfer — longer than most Direct Connect circuits take to provision.

A reasonable rule of thumb:

The single most common wrong answer in migration scenarios is choosing a WAN transfer that mathematically cannot finish inside the window. The corollary trap — “we’ll just run it every night over the WAN” — is not merely slower. It consumes production bandwidth, risks partial or corrupted transfers requiring re-uploads, and typically costs more once bandwidth charges and engineering time are counted. A Snowball unit charge plus shipping is a fixed, predictable line item.

The Snow Family for Offline Bulk Transfer

Snowball Edge devices come in two variants:

Snowcone is the small form factor (~8 TB SSD), ruggedized and courier-shippable, useful for space-constrained sites and preloaded with DataSync agents for edge sync. Snowmobile — a 45-foot container hauling up to 100 PB — targeted exabyte-scale data-center evacuations, but has been deprecated in favor of parallel Snowball Edge fleets in most regions. Selecting Snowmobile for anything under a petabyte is a distractor.

The Compute variant is not just a bigger drive. It runs EC2 AMIs, Lambda functions, and Greengrass workloads locally, making it the right choice when data must be transformed, filtered, or have PII redacted before ingest, when a workload must resume immediately in AWS after ingest, or when the site is disconnected or intermittently connected (ships, remote mining, tactical deployments, remote research). Choose Compute Optimized when on-device processing is required; choose Storage Optimized when the workload is pure bulk copy.

Every Snow device performs 256-bit encryption at rest using KMS keys that never leave AWS. Enclosures are tamper-evident with an E Ink shipping label and a hardware Trusted Platform Module. Data on-device is written using the Snowball client, the S3-compatible endpoint, or an NFS mount; TLS protects data in transit during ingestion and shipping-manifest exchange. On return, contents are ingested to S3 and the device is cryptographically wiped per NIST 800-88.

For petabyte-per-site work, parallelism is the pattern. An office with 1–2 Gbps of link capacity would still need months of continuous saturation to move 1 PB online; a fleet of ~13 Storage Optimized devices per site (each 80 TB) shipped in parallel hits a four-week deadline while sparing the office’s internet link. For a 600 TB two-week job on a saturated 100 Mbps link, a small parallel fleet is the only correct answer — even ignoring cost, the physics make DataSync or new Direct Connect impossible.

DataSync for Online, Verified, Incremental Transfer

DataSync is the right tool when bandwidth is sufficient but workload characteristics — millions of small files, deep directory trees, ongoing incremental syncs, or cross-filesystem migration — would cripple naive tooling. A directory of 20 million 4 KB files copied with aws s3 cp is bottlenecked by round-trip latency, not throughput; each PutObject incurs a TLS/HTTP round trip and an API request charge. Bundling into archives works but forfeits per-file addressability. DataSync’s agent parallelizes across many TCP streams, handles metadata natively, checksum-verifies every file end-to-end with SHA-256, retries transparently, and reports to CloudWatch — achieving up to ~10 Gbps per agent with predictable per-GB pricing.

Sources and destinations span NFS, SMB, HDFS, self-managed object stores, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS, and FSx for NetApp ONTAP. Transfers use TLS 1.2 in transit and can traverse VPC interface endpoints to stay off the public internet.

A critical detail: DataSync requires an agent for on-premises NFS/SMB sources. The agent runs as a VM on VMware, Hyper-V, or KVM, on EC2, or on Snowcone. Believing DataSync is agentless for on-prem is a common trap — it is only agentless when both endpoints are AWS-native services.

A minimal deployment:

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

Two operational features matter. Bandwidth throttling (BytesPerSecond) prevents saturating a shared link — directly answering “1 Gbps link shared with other departments” patterns. Filtering and scheduling allow off-hours syncs and exclusion of transient files. Over a 10 Gbps Direct Connect with users continuing to read and write, scheduling repeated tasks is the canonical pattern: the initial sweep transfers the bulk, successive incremental runs catch deltas, and 700 TB is achievable in well under a week even at partial utilization.

A subtler pitfall concerns metadata fidelity. DataSync preserves a curated set of POSIX or SMB attributes — UID/GID/mode/timestamps for NFS, ownership and DACLs for SMB — but it does not capture every proprietary NAS attribute. Vendor-specific ACLs, extended attributes beyond what the protocol exposes, snapshots, and dedup metadata fall outside its scope. When compliance requires an exact NAS replica including vendor features, DataSync alone is insufficient; a NetApp-aware path such as FSx for ONTAP with SnapMirror, or a lift-and-shift via Storage Gateway, is required.

DataSync also complements Snowball: Snowball moves the initial 150 TB, and DataSync handles the ongoing weekly delta of a 500 GB working set thereafter.

Storage Gateway: Hybrid Presentation, Not Migration

Storage Gateway is not a migration tool — it is a hybrid presentation layer. On-premises applications continue to speak NFS, SMB, iSCSI, or iSCSI-VTL while data lands in S3, S3 Glacier, or EBS snapshots. Confusing Storage Gateway with DataSync is a frequent error: File Gateway is not designed to move 70 TB in a hurry, and DataSync does not present a persistent share to on-prem clients.

File Gateway is the workhorse. Writing \\gateway\share\reports\2024\report.pdf produces s3://bucket/reports/2024/report.pdf — natively consumable by Athena, Lambda, EMR, or any S3 client. This one-to-one file-to-object mapping is a major advantage over black-box backup targets. Local caching means hot files return at LAN speed; cold files stream from S3 on demand.

The cache is the point of the appliance. Reads for hot data are served locally; writes land on local disk first and upload asynchronously. A common design mistake is assuming that S3-backed means every read incurs internet-round-trip latency — it does not, provided the working set fits in the cache. Conversely, undersizing the cache produces constant cache misses and the workload appears “slow.” Rule of thumb: cache = 20% of total dataset or 100% of hot working set, whichever is larger.

The Cached-vs-Stored trap deserves special attention. Cached mode keeps the primary copy in S3 with hot blocks local — cheap, elastic, but a cache miss is a WAN round trip. Stored mode keeps the primary copy on local disk with async snapshots to S3 as EBS snapshots — every read is local and low-latency, but the entire dataset must fit on-prem. For a backup-replacement requirement of “local access to all data while it is backed up on AWS,” Stored is correct; Cached would violate the requirement. Choosing Cached for a workload that needs the entire dataset low-latency defeats the design; choosing Stored when the site cannot host the full dataset is impossible by definition.

Tape Gateway answers a very specific brief: retiring a physical tape library while keeping Veeam, NetBackup, or Commvault workflows intact by presenting a VTL over iSCSI, with data lifecycled from S3 to Glacier or Deep Archive. It is invaluable when regulatory retention is defined in terms of tape media and existing backup software cannot change.

AWS Transfer Family

Transfer Family provides fully managed SFTP, FTPS, FTP, and AS2 endpoints backed by S3 or EFS. The value proposition is preservation of partner-facing protocol contracts: vendor systems that emit files only via SFTP continue doing so unchanged while the receiving end is native S3 — with lifecycle policies, Lambda triggers, and analytics integration.

The trap here is assuming a legacy vendor can “just switch to S3 APIs.” Many vendor systems are appliances, hospital HL7 feeds, banking batch systems, or B2B EDI pipelines whose SFTP client is baked into firmware or signed binaries. The change management, security review, and re-certification cost of touching them often exceeds the entire AWS migration. Transfer Family sidesteps that entirely. AS2 support additionally enables EDI workloads with MDN receipts and message signing/encryption for B2B compliance.

Authentication supports service-managed users, AWS Directory Service (Managed Microsoft AD or AD Connector for on-prem AD), or a custom identity provider via API Gateway/Lambda — allowing existing corporate credentials to remain the source of truth. A Lambda authorizer can return per-user IAM roles, home directory mappings, and session policies, giving per-vendor isolation without per-vendor infrastructure.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow is the managed integration layer for SaaS-to-AWS data movement: Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk, and dozens of others flowing into S3, Redshift, or Snowflake. It handles pagination, incremental extraction, field mapping, filtering, masking, and validation without a hand-rolled ETL job.

The security-critical feature is PrivateLink integration for supported connectors (notably Salesforce). Instead of egressing to the public internet to reach the SaaS tenant and returning to AWS, the flow traverses a private VPC endpoint — eliminating public-internet exposure of extract payloads and simplifying audit posture for healthcare, finance, and PII workloads. Flows can be scheduled, event-triggered by SaaS record changes, or run on demand, and support up to 100 GB per flow execution.

AppFlow operates at a higher layer than DataSync or Storage Gateway: it is the right tool when the source is an API-driven SaaS, not a filesystem or database.

Database Migration: DMS and SCT

AWS Database Migration Service replicates data between source and target databases while the source remains fully operational. It supports homogeneous (MySQL → RDS MySQL, Oracle → RDS Oracle) and heterogeneous (Oracle → Aurora PostgreSQL, SQL Server → MySQL) migrations, and targets extend beyond RDS to Aurora, Redshift, S3, DynamoDB, and Kinesis. Sources include Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, and Db2.

A task operates in one of three modes:

The engine of minimal-downtime cutover is Change Data Capture. During full-load-plus-CDC, DMS bulk-copies existing rows while mining the source transaction log — Oracle redo, MySQL binlog, SQL Server MS-CDC or MS-Replication. Once full load completes, CDC applies queued changes and keeps the target continuously current until the application flips over. Failing to enable CDC when the application must stay writable is a common architectural error: full-load-only leaves the target stale the moment the load completes.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

For heterogeneous work, AWS Schema Conversion Tool (or its cloud sibling DMS Schema Conversion) translates DDL, stored procedures, views, and functions, flagging items requiring manual rewrites. DMS moves data; SCT converts schema. Skipping the SCT assessment report is how migrations fail three days before cutover.

Engine-specific prerequisites and limitations bite hard if ignored. Oracle LOBs above 64 KB require limited LOB mode with a fixed maximum; LONG RAW has caveats. PostgreSQL requires wal_level=logical and a replication role. MySQL requires binary logging in ROW format with sufficient binlog_row_image and elevated CDC privileges (REPLICATION CLIENT, REPLICATION SLAVE). Oracle Spatial, RAC-specific behaviors, and SQL Server CLR assemblies are commonly unsupported. TLS is enforced between the replication instance and endpoints, with SSL modes require, verify-ca, or verify-full.

DMS Serverless is the correct choice when workload profile is unpredictable or bursty — an on-prem Oracle system with daytime spikes and quiet nights, for example. You define MinCapacityUnits and MaxCapacityUnits in DCUs (DMS Capacity Units) and DMS scales replication capacity based on CPU and memory pressure:

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

A frequent trap is assuming a provisioned DMS instance (e.g., dms.c5.4xlarge) will auto-scale. It will not — provisioned instances are fixed-size EC2 hosts. If throughput exceeds capacity, replication lag grows and you must manually modify the instance class, restarting tasks. Provisioned DMS suits steady-state migrations of known throughput; Serverless suits unpredictable ones.

For a 20 TB MySQL migration with a two-week window and tight downtime, DMS with full-load plus CDC into Aurora MySQL or RDS MySQL is the cost-effective play. Native mysqldump/mysqlpump restores incur unacceptable downtime; Snowball adds shipping latency and offline gaps.

DMS Fleet Advisor discovers on-prem database inventories, useful for wave planning.

Server Migration: AWS Application Migration Service (MGN)

AWS Application Migration Service is the primary lift-and-shift (“rehost”) service and has superseded CloudEndure Migration and Server Migration Service for most use cases. MGN installs a lightweight AWS Replication Agent on each source server (physical, VMware, Hyper-V, or another cloud). The agent performs an initial block-level snapshot into a low-cost staging area in the target VPC — small T3 instances with attached EBS volumes — and then continuously replicates block-level changes asynchronously. Because replication is block-level and continuous, cutover is measured in minutes: MGN converts the staging volumes into production EC2 instances of the target instance type at cutover time.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

Test launches are essential and often skipped. MGN spins up isolated test instances from the current replication state without disrupting ongoing replication. You validate application behavior, discard the test, iterate, and only initiate cutover when tests pass — cutover stops replication, launches the final instance, and marks the wave complete.

The wrong approach is manually exporting VMs to OVF, uploading via aws ec2 import-image, and reinstalling applications on freshly provisioned EC2 instances. This is slow, error-prone, requires per-VM downtime equal to the export duration, provides no delta replication, and offers no non-disruptive tests. MGN eliminates all of that — the source keeps running until the final cutover second, and drift between source and target is essentially zero.

The general portfolio guidance is to rehost first, then re-platform or refactor in-Region where iteration cost is lower. Simultaneous refactor and migration multiplies risk without compensating benefit.

Hybrid Connectivity: Direct Connect and VPN

AWS Direct Connect provides a dedicated Layer 2 circuit from an on-prem router to a Direct Connect location, offering consistent bandwidth (1, 10, 100 Gbps dedicated; sub-1 Gbps via partner hosted connections) and predictable latency. Virtual Interfaces partition the circuit:

• Private VIF — access to a single VPC via a Virtual Private Gateway.
• Transit VIF — access to many VPCs via a Direct Connect Gateway attached to a Transit Gateway. This is the canonical pattern for large multi-VPC, multi-site environments.
• Public VIF — access to AWS public service endpoints (S3, DynamoDB) without traversing the internet.

DX is not, by itself, highly available: a single circuit at a single DX location depends on a single fiber path. Two resilience patterns matter:

1. DX + Site-to-Site VPN backup over the internet is the minimum viable HA. BGP handles automatic failover with AS-path prepending, MED, or local-pref to prefer DX in steady state.
2. Dual DX circuits at separate DX locations is the maximum-resilience pattern for mission-critical workloads and is required for the DX SLA.

Failing to provision any backup path is a well-known trap: when DX fails and there is no VPN, hybrid apps, DataSync jobs, and Storage Gateway uploads all stall for the duration of the carrier repair. Pure VPN is acceptable for lower-throughput workloads or as a bridge while DX is being provisioned, which can take weeks.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

Where physical-layer encryption is mandated, choose a MACsec-enabled DX connection. Combining DX for bandwidth, DataSync for orchestration, and Storage Gateway for continued local access is the canonical hybrid pattern for large, live datasets that cannot tolerate a downtime window.

AWS Outposts for On-Prem AWS Infrastructure

Outposts extends AWS infrastructure into a customer facility as a fully-managed rack (or 1U/2U Outposts servers). It runs a curated set of services locally — EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR — with the same APIs as the parent Region. Control-plane operations flow back to the parent Region over a service link of redundant encrypted tunnels; a WAN outage temporarily prevents launching new instances but does not stop running workloads.

The shared responsibility split is the trap that catches operators. AWS delivers and maintains the hardware, hypervisor, and managed services. The customer is responsible for:

• Physical space, power, cooling, and networking meeting Outposts specs (redundant power feeds, upstream switches, appropriate PDUs).
• Physical security of the facility.
• Local network configuration — the Local Gateway (LGW) for on-prem traffic and the service link uplink.
• OS and application concerns of workloads, exactly as in-Region.
• Adequate WAN connectivity back to the parent Region.

Outposts does not eliminate operations — it shifts the abstraction. Assuming AWS is responsible for datacenter power or upstream network is a fundamental misreading. It is also not “run any AWS service on-prem”: the supported list is finite, and services like Route 53 or IAM remain Region-based.

For a Hadoop/Spark modernization where data must stay on-premises for regulatory reasons, EMR on Outposts is the correct pattern — managed, elastic Spark clusters with in-Region tooling and local data residency. Storage Gateway or DataSync fail the residency requirement; lift-and-shift to in-Region EMR fails compliance.

Distributing Content to Edge Fleets

When Outposts servers, retail stores, or edge devices repeatedly pull the same large payload — a nightly software release, for example — pulling directly from an S3 bucket in a single Region saturates uplinks and inflates deployment time. The correct pattern is CloudFront with an S3 origin and signed URLs:

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

The first device in a region warms the edge cache; every subsequent device pulls at edge latency. Signed URLs prevent unauthorized downloads without per-device IAM credentials, and there is no fleet of regional replicas to manage.

Two anti-patterns to reject: hosting the release on a single EC2 web server (a scaling and latency disaster), and replicating the S3 bucket to every Region via Cross-Region Replication just to reduce download latency (unnecessary storage cost and operational complexity that CloudFront caching solves for free).

Decision Summary

← Previous: Storage · All domains · Next: Networking →

Practice Data Transfer questions → · Timed practice on ExamRoll.io →

Browse Amazon →