On-Premises Workloads & Migration to AWS

1. Bringing AWS to You: AWS Outposts

AWS Outposts is physical AWS infrastructure, delivered as a full 42U rack for large deployments or as compact 1U/2U Outposts servers for smaller footprints, installed in your own datacenter, office, or colocation facility, and fully managed, monitored, and patched by AWS. The defining idea is that it is not "AWS-like" hardware you operate yourself: it runs the exact same APIs, SDKs, console, and services (EC2, EBS, ECS, EKS, RDS, and S3 on Outposts) as the public Region it extends.

• Low-latency local processing - manufacturing lines, trading desks, or live production environments where even a few milliseconds of round-trip time to the nearest Region is unacceptable.
• Local data processing - workloads that generate or consume very large datasets on-site (medical imaging, video production) where moving the data first would be slower and more expensive than processing it locally.
• Data residency and compliance - regulations that require certain data to physically remain within a specific building, city, or country, while still letting teams build against the AWS APIs they already know.

Provisioning a resource on an Outpost looks almost identical to provisioning one in the Region, the only real difference is one extra property pointing at the Outpost itself:

# A subnet that lives on an Outposts rack: same VPC, same APIs, different hardware
outpost_subnet = ec2.CfnSubnet(self, "OutpostSubnet",
    vpc_id=vpc.vpc_id,
    cidr_block="10.0.10.0/24",
    availability_zone="us-east-1a",
    outpost_arn="arn:aws:outposts:us-east-1:123456789012:outpost/op-0123456789abcdef0",
)

# An EC2 instance scheduled onto that subnet runs on the Outpost in your facility,
# but is created, billed, monitored, and managed exactly like any other EC2 instance
local_processor = ec2.CfnInstance(self, "LocalProcessingNode",
    image_id=ami.image_id,
    instance_type="m5.xlarge",
    subnet_id=outpost_subnet.ref,
)

2. Deciding How Each Application Should Move: The Seven Rs

Outposts answers "what if a workload cannot leave?" Most applications, though, are migrating into AWS, and the first real decision is not a technical one: it is choosing, application by application, how it should move. AWS groups those choices into a well-known set of strategies, often called "the Rs":

3. Planning, Tracking, and Executing the Move

Once a strategy is chosen for each application, a small family of services helps plan, track, and carry out the move itself:

4. Moving the Data Itself: Online and Offline Transfer

Replicating servers and databases is one kind of move. Separately, most migrations also involve a mountain of files, backups, media, or logs that need to land in S3, EFS, or FSx. AWS splits that problem into two paths: move it over the network, or, when the network is not big enough for the job, move it on a truck.

Both of those ride on your network connection, fine for steady, ongoing transfers. But when the dataset is so large, or the available bandwidth so limited, that even a fast link would take weeks or months, the fastest path stops being a wire. It becomes a truck.

The Snow Family: When the Network Isn't the Answer

The AWS Snow Family is a line of ruggedized physical devices: AWS ships one to your site, you load it with data (or run compute and machine learning workloads directly on it at the edge), ship it back, and AWS imports the data into S3. It is the cloud-era version of an old engineering joke: never underestimate the bandwidth of a station wagon full of hard drives speeding down the highway.

DataSync locations and tasks are just CDK constructs like any other, defining where the data comes from, where it goes, and when it should run:

# Source: an on-premises NFS share, reached through a DataSync agent
nfs_location = datasync.CfnLocationNFS(self, "OnPremShare",
    server_hostname="nfs.onprem.example.com",
    subdirectory="/exports/datasets",
    on_prem_config=datasync.CfnLocationNFS.OnPremConfigProperty(
        agent_arns=["arn:aws:datasync:us-east-1:123456789012:agent/agent-0123456789abcdef0"],
    ),
)

# Destination: an S3 bucket, accessed through a role DataSync assumes
s3_location = datasync.CfnLocationS3(self, "S3Destination",
    s3_bucket_arn=destination_bucket.bucket_arn,
    s3_config=datasync.CfnLocationS3.S3ConfigProperty(
        bucket_access_role_arn=datasync_role.role_arn,
    ),
)

# A recurring task that only transfers what changed since the last run
nightly_sync = datasync.CfnTask(self, "NightlySync",
    source_location_arn=nfs_location.attr_location_arn,
    destination_location_arn=s3_location.attr_location_arn,
    schedule=datasync.CfnTask.TaskScheduleProperty(schedule_expression="cron(0 2 * * ? *)"),
)

5. Reference Architecture: A Migration in Motion

Putting the planning and execution services together: Application Discovery Service maps the on-premises estate first, so the team can group applications into waves with a clear strategy for each. Application Migration Service and Database Migration Service then replicate servers and databases continuously, while Migration Hub aggregates status from every tool into one view. Each wave finishes with a low-risk cutover into the target VPC, validated before traffic ever moves.

Zooming into a single wave shows what "continuous replication" actually buys you: the ability to test the destination before committing to it, with the source application still running the whole time.