Cloud repatriation, moving workloads from AWS back to on-prem or a private cloud, is increasingly common when steady-state demand turns out to cost more on metered cloud than on owned hardware. This is the reverse of cloud adoption, and the decision is entirely workload-shaped: some things should come back, many shouldn’t. The honest first step is proving the cost case per workload.
The cost case, prove it first
The repatriation argument is strongest for predictable, high-utilization, steady-state workloads: always-on databases, fixed-size app tiers, storage you’re paying egress on constantly. For these, amortized on-prem hardware + power + space + ops can beat the cloud run-rate, and you stop paying egress and managed-service premiums. It’s weakest for spiky, bursty, or unpredictable workloads, where cloud elasticity wins. Before moving anything, baseline each workload’s AWS run-cost against a realistic on-prem TCO, including the hardware refresh cycle and the ops headcount you’re taking back on. If the numbers don’t favor on-prem for a given workload, leave it in AWS. “Retain” is a valid answer.
When repatriation saves money, and when it doesn’t
The honest version of the cost case has two sides. Repatriation wins when utilization is high and flat: hardware you own is cheapest when it runs near capacity around the clock, because the amortized cost per useful hour is low and there is no per-request or per-GB meter running. It loses when demand is bursty, because on-prem you either overprovision for the peak and waste the trough, or you undersize and fail under load, whereas the cloud simply bills for what you used. The line items that push steady workloads back on-prem are egress you pay repeatedly, inter-AZ transfer, and managed-service premiums. The line items that keep workloads in the cloud are elasticity, agility, and not carrying an ops team for undifferentiated infrastructure. Run each workload through that lens rather than making one blanket decision for the whole estate.
What’s hard to bring back
Lifting EC2 VMs back is mechanical; the friction is AWS-managed services with no on-prem equivalent:
- RDS/Aurora → self-managed PostgreSQL/MySQL on your hypervisor (you take back DBA ops).
- S3 → on-prem object storage (MinIO/Ceph RGW), and you must rehydrate the data (egress cost + time).
- DynamoDB, Lambda, SQS/SNS, managed AI, these need self-hosted substitutes (Cassandra/ScyllaDB, OpenFaaS/Knative, RabbitMQ/Kafka) or re-architecture. The deeper you went into proprietary AWS PaaS, the more rework.
Inventory how much proprietary AWS service you use, that’s the true difficulty, not the VMs.
Stand up the landing platform first
Build the on-prem/private-cloud target before migrating: hypervisor (Proxmox, Nutanix, VMware, or OpenStack), storage, and networking, sized for the workloads coming back plus N+1 headroom. Establish connectivity (Direct Connect / VPN) for replication and hybrid operation during transition.
Rebuilding on-prem capacity
Capacity planning is the discipline the cloud let you forget, and repatriation hands it back. Size the platform for the real peak of the workloads returning, not their average, then add N+1 so a node can fail without taking the service down. Account for the full facility cost, not just the servers: power draw, cooling, rack space, and the network gear that ties it together. Plan the hardware refresh cycle up front, because owned kit ages and the replacement is a future CapEx event you are now signing up for. Most importantly, staff for it: managed services quietly absorbed patching, backups, and on-call, and bringing workloads home means bringing that operational load home too. Fold all of it into the TCO, because a repatriation that pencils out on hardware alone can still lose once power, refresh, and headcount are counted.
The migration mechanics
- Inventory workloads, AWS-managed-service dependencies, data volumes, and per-workload cost; classify keep-in-cloud vs repatriate.
- Provision the on-prem platform and connectivity.
- Move compute, export EC2 via VM Import/Export, or replicate instances to your hypervisor with a V2V/replication tool (Veeam, etc.).
- Rehydrate data, pull from S3 (
aws s3 sync) to on-prem object storage; migrate RDS via dump/replication to self-managed databases; budget egress and transfer time (Snowball for very large datasets). - Rebuild managed-service equivalents and re-point apps.
- Validate, then cut over DNS, keeping AWS as fallback through hypercare.
What “done” has to prove
Acceptance bar: functional + integration parity, performance at/above baseline, validated steady-state cost, and a DR/failover test, plus an honest confirmation that the on-prem run-cost actually beats AWS for each repatriated workload. Capacity planning matters: unlike cloud, you can’t burst beyond the hardware you bought.
Bringing it home, or not
AWS → on-premise pays off for steady-state, high-utilization workloads where owned hardware beats the metered run-rate and egress, but it’s the wrong move for spiky demand, and proprietary AWS PaaS is what makes it hard. Prove the per-workload cost case first, stand up the landing platform, replicate compute and rehydrate data, and cut over DNS with AWS as fallback. Use the per-vCPU calculator above to compare on-prem TCO against AWS, and treat the figures as illustrative until your baseline and real utilization confirm the case.