Cloud repatriation: from AWS or Azure to Riga

Cloud repatriation means moving some workloads from a public cloud such as AWS or Azure to servers you rent or own, usually to get a predictable monthly bill. It rarely means leaving the cloud completely: steady workloads such as databases, ERP and file servers tend to move, while spiky, global or managed-service-heavy ones stay. Below: when a move pays off, how to cost it with egress fees included, how to run it step by step and where our Riga data centre fits. All prices were checked on 27 September 2026 and exclude VAT.

What cloud repatriation is, and what it is not

The term covers any move of a workload out of a large public cloud into infrastructure with a fixed price: rented dedicated servers, your own servers in colocation, or virtual servers from a regional provider. The usual result is hybrid: the database and internal systems run on fixed-price servers, while a content delivery network, email or a few managed services stay in the cloud. So the useful question is not whether to use the cloud at all, but which workloads pay cloud prices for flexibility they never use.

Why companies move workloads out of the public cloud

• A predictable monthly cost. A cloud bill is the sum of many metered lines: compute hours, disks, snapshots, IP addresses, load balancers, requests and traffic. That is fair for a workload that changes, but for a server that runs flat all month a fixed price is easier to budget. Reservations and savings plans lower the cloud price, but they commit you for one or three years and give away the flexibility you went to the cloud for.
• Egress fees. Data coming into AWS and Azure is free; data going out to the internet is billed per gigabyte after a small free allowance. A service that sends a lot to its users or copies backups to another site pays for every gigabyte, while a fixed-price server usually includes traffic up to a monthly allowance.
• Data location in the EU. AWS and Azure have EU regions, and data stored there stays in the EU. Some companies still prefer, or their clients require, a provider that is itself an EU company, with a contract under EU law. Our article on EU and US clouds and why data location matters explains the difference between where data sits and which law governs the provider.
• Performance of steady workloads. A database or an ERP system that runs all day benefits from dedicated cores, local disks and predictable latency. The cloud offers that too, but the larger instances and premium disks that deliver it are where the bill grows. On a dedicated server the whole machine is yours at a fixed price.

When to stay in the public cloud

Repatriation is not a verdict on the cloud. Keep a workload where it is when:

• the load is spiky or seasonal, so on your own servers you would pay all year for a peak that lasts a few days;
• users are spread over several continents and the service needs regions or edge locations close to each of them;
• the application is built on managed services such as serverless functions, managed databases, queues or AI APIs, and rebuilding them would cost more engineering time than the move saves;
• the project is short or experimental, and nobody knows its size yet;
• reservations or savings plans are still running, because you pay for them whether the workload moves or not;
• your team works in that cloud every day and nobody looks after servers.

How to cost a repatriation

Compare full monthly costs, not virtual machine prices. On the cloud side, take the last three to six invoices and group every line by workload: compute, disks and snapshots, backup, IP addresses, managed services, the support plan and data transfer. On the fixed-price side, add the server rent or colocation fee with electricity, backup with an off-site copy, licences, a second internet line if the office now depends on the data centre, and administration hours. Our five-year cost comparison of office, colocation, dedicated servers and cloud walks through such a calculation with every assumption shown.

Egress: the line that is easy to miss

Internet egress list prices, checked on 27 September 2026:

In the first tier every terabyte that leaves costs about 90 USD: 1024 GB at 0.09 USD is 92.16 USD on AWS, and at 0.087 USD it is 89.09 USD on Azure. Count egress twice: as a monthly cost of the running service, which goes away for the workloads that move, and as a one-time cost of copying your data out.

Exit waivers and the EU Data Act

Both providers waive the one-time egress of a move out, on request. AWS offers free data transfer out to the internet when you move off AWS: you contact AWS Support first, the request is reviewed at account level, and once it is approved you have 90 days to complete the move; you do not have to close the account. Azure credits egress charges for customers leaving Azure: you open a support request with the planned start date and the expected volume, then have 60 days to transfer the data, or longer if your request describes the timeline. You must cancel all Azure subscriptions on the account before claiming the credit, so for most customers a partial move does not qualify.

The EU Data Act, which applies since 12 September 2025, sets a legal floor. Until 12 January 2027 providers may charge for switching and data egress only the costs linked to the switch, and from 12 January 2027 switching charges, including egress charges, are removed entirely. Neither the waivers nor the Data Act cover the everyday traffic of services that stay in the cloud, so in a hybrid setup the monthly egress stays in your comparison.

Data centre migration step by step

1. Inventory. List every virtual machine, database, storage bucket, DNS zone, certificate, scheduled job and external integration, with its size, monthly cost and owner.
2. Dependencies. Map what talks to what: which application reads which database, which service relies on a cloud queue, identity service or object storage, and which of your IP addresses partners allow through their firewalls. Whatever stays in the cloud needs a secure path to what moves, usually a site-to-site VPN.
3. A target for each workload. Steady servers go to dedicated servers or colocation, small services to a VPS. Each managed service is either rebuilt, for example a managed database becomes a database server with replication and backups, or left in the cloud on purpose.
4. Build and rehearse. Set up the servers, network, firewall, backup and monitoring, restore a copy of the data and test the application while the cloud version keeps serving users.
5. Data transfer. Copy the bulk first, then keep it in sync with database replication or repeated incremental file copies, so that the final difference is small. Estimate the time honestly: at a sustained 500 Mbit/s one terabyte takes about four and a half hours at best, and throughput on the cloud side can be lower than your port.
6. DNS cutover. A day or two ahead, lower the TTL of the records that will change, for example to 300 seconds, so the switch reaches users within minutes. Check SPF records, partner allowlists and certificates that name the old addresses.
7. The switch. In an agreed window, stop writes on the old side, sync the last changes, switch DNS or connection strings and run the checks written down in advance.
8. Parallel run. Keep the cloud environment intact but idle until month-end jobs, reports and backups have run once in the new place.
9. Rollback. Decide before the window which failed check sends you back and how data written on the new side would return. Going back is part of the plan, not a failure.
10. Decommission. Only then delete cloud resources, snapshots and unattached disks, claim any egress credit and check the next two cloud invoices for forgotten items.

Where CloudHosting fits

CloudHosting SIA runs its own data centre at Bērzaunes iela 1 in Riga, Latvia. The facility is carrier-neutral and built to a Tier 3+ design, with N+1 power and cooling, UPS and a diesel generator, and our own network AS58269 with two uplinks. The data centre is guarded, visitors are not admitted to it, and only a limited number of our specialists have access. If you bring your own servers, you hand them over at our office and our engineers install them.

Monitoring and incident response run 24/7, and engineers answer on working days 9:00-17:00 Riga time. 99.9% availability is our target, not an SLA written into the contract. The contract is with CloudHosting SIA under Latvian law, invoiced in EUR, with a data processing agreement. Every line of a colocation bill is explained in colocation pricing in Riga 2026.

Our migration service covers the survey, a written plan with a rollback for every step, the rehearsal, the switch in an agreed window and monitoring afterwards. For a normal company setup the survey is part of preparing the offer, and the migration work is quoted before it starts. We are not the right home for everything: if a workload is spiky, global or built on managed services, we will say so and suggest keeping it where it is. To start, send us the list of workloads and a recent cloud invoice.