Cloud Repatriation Cost: AWS, Azure or GCP vs Bare Metal TCO Calculator
Cloud repatriation moves selected workloads from a public cloud to bare metal, private cloud or a hybrid environment. The financial case depends on utilization, data movement, service dependencies and operating scope. A valid comparison uses the same workload, availability target, security controls and support level on both sides.
This model is for CTOs, platform teams and owners investigating cloud cost optimization for steady databases, APIs, analytics, storage and GPU workloads. It also shows where public cloud elasticity and managed services remain the better choice.
Use the cloud repatriation cost as a planning workflow: define the workload, collect a normal and peak baseline, identify the first limiting resource, shortlist two viable designs and test them with production-like data. Keep assumptions visible so a future review can update the model without repeating discovery.
Commercial options referenced in this guide: cloud migration and repatriation (https://unihost.com/migration/); dedicated servers (https://unihost.com/dedicated/); server management (https://unihost.com/management/)
Related Unihost reading: From Cloud to Bare Metal (https://unihost.com/blog/from-cloud-to-bare-metal-2025/); Bare Metal vs Cloud in 2026 (https://unihost.com/blog/bare-metal-vs-cloud-2026/); zero-downtime migration (https://unihost.com/blog/zero-downtime-migration/)
What cloud repatriation means and when it makes sense
Repatriation is selective infrastructure placement, not a rejection of cloud. It makes sense when a workload is stable, continuously utilized, expensive to move between zones or regions, sensitive to performance variance, or constrained by a large data egress cost. Short-lived experiments and unpredictable bursts often stay in public cloud.
Collect hourly utilization, reservation coverage, egress by destination, storage growth, managed-service consumption, latency variance and engineering effort during ordinary traffic and during a representative peak. Align infrastructure timestamps with application traces so the team can connect a slow request or failed job to the resource that was constrained. Averages are useful for cost planning, but p95, p99 and queue growth show whether short bursts are already damaging the service.
Evaluate one bounded workload first and preserve cloud services that provide clear operational or product value. The main planning risk is treating the full cloud bill as removable even though shared services, identity, observability or edge components will remain. Validate the choice with a workload inventory that maps every dependency, data flow, owner and cost line. Keep the test conditions and acceptance threshold in the runbook so later changes can be checked against the same baseline.
Capacity should also cover maintenance and failure behavior. Reserve enough room for monitoring, log rotation, security scanning, backup activity and the temporary loss of a node when the architecture promises continuity. This reserve is not a fixed percentage: derive it from the failure scenario and show it explicitly in the worksheet.
Cloud repatriation cost and TCO model
The cloud TCO calculator should include compute, memory, accelerators, block and object storage, IOPS, snapshots, backups, data egress, inter-zone traffic, support, licenses, monitoring, security tooling and staff time. Bare metal requires corresponding server, network, storage, management, backup and migration entries. Use the cloud vs bare metal cost model to expose the AWS vs dedicated server cost drivers that a headline instance rate can hide.
Build the baseline from twelve months of invoices, tagging coverage, unit consumption, utilization by hour, support plan, license model and incident labor. Record the same signals before and after every tuning or infrastructure change. If throughput rises while tail latency and errors remain controlled, the change created usable capacity. If queues grow or latency bends upward, the system has reached a limit even when one headline utilization number still looks comfortable.
Normalize every cost to the same month, workload volume and availability objective, then show one-time migration separately from recurring run rate. Watch for using list prices while ignoring commitments and credits, or comparing cloud managed services with an unmanaged server. Before ordering or migrating, use a finance and engineering review of every worksheet line. A documented rejection criterion is as important as a success criterion because it tells the team when to stop the rollout or move to the next capacity tier.
A useful decision has a scale path. State what can be expanded in place, what requires a restart or migration and which threshold starts that work. Procurement lead time, data-copy duration and change windows belong in capacity planning because a resource that can be added next month may not help during next week’s peak.
Cloud vs bare metal TCO model
| Category | Public cloud input | Bare metal input | Normalization rule |
|---|---|---|---|
| Compute | Instances, commitments, autoscaling | Servers and reserved capacity | Same workload and availability |
| Storage | Capacity, IOPS, snapshots, operations | Local, NAS or object storage plus redundancy | Same usable capacity and recovery |
| Network | Internet egress and inter-zone transfer | Port, transfer allowance and private network | Same destinations and peak throughput |
| Support and operations | Provider support plus platform labor | Management plus platform labor | Same coverage hours and responsibilities |
| Licenses and security | Images, marketplace, security services | OS, panels, security tools | Same features and compliance |
| Migration | Exit preparation | Build, sync, testing and rollback | One-time, amortized separately |
Three example workloads with transparent assumptions
Examples should expose assumptions instead of announcing a universal savings percentage. A steady API and database can compare a full month of provisioned capacity. A data platform must add inter-zone and data egress cost. GPU inference must include accelerator availability, utilization, model storage and cost per successful request.
Use business transaction volume, compute hours, active storage, bytes moved, support scope and target latency as a small capacity model rather than a dashboard snapshot. Separate steady demand, scheduled work and exceptional peaks. The model should explain which resource saturates first, how long the saturation lasts and which customer or operational outcome changes at that point.
Use low, expected and high scenarios for each workload and change one assumption at a time. The design can still fail through choosing an example whose utilization or availability model does not resemble the real system. Prove the intended behavior with a shadow workload or pilot with identical request mix and data volume. Include monitoring, backups and security controls in the test because production overhead should not appear for the first time after launch.
Cost should be attached to a unit of successful work, such as an order, request, completed job, restored terabyte or accepted model response. That view prevents a cheap configuration from winning when it misses the latency or recovery target, and it prevents unused headroom from being treated as free.
Example workload assumptions
| Workload | Cloud cost drivers | Bare metal cost drivers | Decision metric |
|---|---|---|---|
| Steady SaaS API plus database | Always-on instances, database service, storage and egress | Compute, NVMe, backup and management | Cost per successful transaction at target p95 |
| Analytics pipeline | Compute bursts, object operations, inter-zone movement | High-core nodes, local NVMe, storage tier and scheduling | Cost per completed dataset within window |
| LLM inference | GPU hours, endpoint overhead, model storage and egress | GPU server, VRAM fit, power included in rent, operations | Cost per accepted response at target latency |
What bare metal changes in performance and predictability
Bare metal removes shared hypervisor scheduling and gives the team direct control over CPU topology, RAM, local NVMe, network queues and accelerators. That can improve consistency, but results still depend on application design, storage layout, kernel tuning and failover. Predictable infrastructure pricing is valuable only when capacity is used well.
Measure throughput, p95 and p99 latency, CPU utilization, storage tail latency, packet loss, accelerator utilization and cost per unit of work with enough resolution to capture bursts and enough duration to expose leaks, cache effects and background jobs. Keep the workload mix visible. A test dominated by easy requests can report healthy averages while the expensive path is already queueing.
Benchmark the production request mix and compare variance as well as average performance. Do not ignore assuming dedicated hardware automatically fixes inefficient queries, serialized code or poor caching. Confirm the recommendation through a sustained benchmark with production-size data, warm caches, backups and monitoring enabled. Record which assumption has the lowest confidence and retest that assumption first when traffic, data or software changes.
Keep software efficiency in the model. Query plans, cache policy, compression, batching and concurrency limits can change resource demand more than one hardware tier. Re-run the same evidence set after tuning so the final purchase reflects the improved system rather than an avoidable defect.
Risks, hybrid options and cases where public cloud should remain
Public cloud should often remain for unpredictable bursts, global managed services, event-driven jobs, disaster-recovery capacity and teams that cannot operate the replacement stack safely. Hybrid designs can keep edge, identity or burst workers in cloud while steady databases, storage or GPU inference run on dedicated hardware.
Create a repeatable evidence set from demand variance, scaling time, dependency depth, recovery capability, regional requirements and staff coverage. Store workload inputs beside the results, including software version, data size, cache state and concurrency. This turns the next capacity review into a comparison instead of another estimate from memory.
Place each component where its economics and operational model are strongest instead of forcing an all-or-nothing move. The most expensive mistake would be creating a hybrid environment without clear ownership, private connectivity, observability or failure boundaries. Reduce that uncertainty with a failure-mode review covering loss of cloud, bare metal, network and identity dependencies. Keep an upgrade or rollback path that does not depend on the already constrained component.
Capacity should also cover maintenance and failure behavior. Reserve enough room for monitoring, log rotation, security scanning, backup activity and the temporary loss of a node when the architecture promises continuity. This reserve is not a fixed percentage: derive it from the failure scenario and show it explicitly in the worksheet.
Step-by-step plan to migrate from AWS to bare metal
Start with discovery, dependency mapping and a target design. Build infrastructure as code, configure identity, security, monitoring and backups, replicate data, rehearse the application, shift read traffic or a small cohort, verify, complete the cutover and retain a rollback path until acceptance criteria hold.
Track replication lag, data checksums, error rate, latency, queue depth, cost during dual running and rollback time at the component and service levels. Resource headroom is valuable only when it preserves the latency, correctness and recovery objectives that matter to the business. Use the first consistently constrained metric to guide the next test.
Use stage gates with explicit owners and stop conditions rather than one large migration weekend. A common failure mode is moving data before the target has operational controls or losing rollback by decommissioning cloud resources too early. Use a full rehearsal plus a restore and rollback exercise before treating the configuration as production-ready. Review the result with the application owner as well as the infrastructure team.
A useful decision has a scale path. State what can be expanded in place, what requires a restart or migration and which threshold starts that work. Procurement lead time, data-copy duration and change windows belong in capacity planning because a resource that can be added next month may not help during next week’s peak.
Cloud TCO worksheet users can copy
The worksheet should separate usage quantities from unit prices so it can be refreshed without rewriting the model. Record the source and date for every rate. Include a scenario selector, one-time costs, monthly recurring costs, risk reserve and the business metric used to compare outcomes.
Collect quantity, unit, rate, monthly total, annual total, owner, source date and confidence level during ordinary traffic and during a representative peak. Align infrastructure timestamps with application traces so the team can connect a slow request or failed job to the resource that was constrained. Averages are useful for cost planning, but p95, p99 and queue growth show whether short bursts are already damaging the service.
Approve repatriation only when the expected case is attractive and the high-cost case remains acceptable. The main planning risk is hiding uncertain inputs inside a single total or counting projected savings before the workload passes performance and recovery tests. Validate the choice with independent review by finance, platform engineering and the workload owner. Keep the test conditions and acceptance threshold in the runbook so later changes can be checked against the same baseline.
Cost should be attached to a unit of successful work, such as an order, request, completed job, restored terabyte or accepted model response. That view prevents a cheap configuration from winning when it misses the latency or recovery target, and it prevents unused headroom from being treated as free.
Copyable TCO worksheet
| Line item | Quantity | Unit rate | Monthly total | Source and confidence |
|---|---|---|---|---|
| Compute or server | Invoice or current offer | |||
| RAM or accelerator premium | Measured requirement | |||
| Storage and operations | Capacity, IOPS and retention | |||
| Internet and inter-zone transfer | Billing export and traffic logs | |||
| Support, management and monitoring | Equivalent service scope | |||
| Licenses and security | Current contracts | |||
| Migration amortization | Project estimate and period | |||
| Risk reserve | Documented uncertainty |
Frequently Asked Questions
What is cloud repatriation?
Cloud repatriation moves selected workloads or data from public cloud to bare metal, private cloud or another controlled environment. It is usually selective rather than total. The aim may be lower recurring cost, steadier performance, data control or a better operational fit.
When is bare metal cheaper than AWS?
Bare metal can be cheaper when a workload runs continuously at substantial utilization, needs large local storage or transfers significant data. The answer depends on commitments, managed services, support and operations. Compare the full TCO with identical availability and security requirements.
Which costs should be included in cloud TCO?
Include compute, memory, accelerators, storage capacity and operations, snapshots, backups, egress, inter-zone transfer, support, licenses, monitoring, security tooling and staff time. Show migration and dual-running costs separately. Use current invoices and documented rates.
Can a company use a hybrid cloud and bare metal model?
Yes. A common design keeps steady databases, storage or GPU workloads on dedicated hardware and uses cloud for bursts, managed services, edge roles or disaster recovery. Private connectivity, identity, monitoring and ownership must cover both environments.
