When is leaving the public cloud worth it, and when is it not?

It is worth it for static, long-running workloads with high outbound data volumes — typically core systems, databases, storage, backups and video. It is not worth it for globally distributed services, unpredictable peaks, experimental development, or anywhere you depend on proprietary services such as Lambda, BigQuery or Bedrock. For most companies the right answer is not to move everything, but to split the workload.

What is cloud repatriation?

Cloud repatriation means moving workloads from the public cloud back to owned or leased infrastructure. It does not mean returning to servers under a desk — modern repatriation targets a private cloud with APIs, automation and self-service, just on dedicated hardware at a predictable price. Storage, databases and stable production workloads are repatriated most often.

How much does egress cost with you?

Nothing. PROZETA Tier5 does not charge for outbound data and applies no cap. For comparison: AWS in Frankfurt charges USD 0.09 per GB beyond a free 100 GB per month, Azure in West Europe USD 0.08 per GB, and Google Cloud on the Premium Tier USD 0.12 per GiB with a free allowance of just 1 GiB per month. At 10 TB per month, AWS comes to roughly USD 891 monthly.

How does a hybrid setup with AWS work?

The workload is split according to which model suits which part. The most common arrangement is data and core systems with us, compute and digital channels in AWS. The key property is that hyperscalers do not charge for inbound data and we do not charge for outbound — so transfer from us to them is free on both sides. We describe four concrete patterns, including what is hard about each.

What does the US CLOUD Act mean for European companies?

The CLOUD Act lets US authorities request data from providers subject to US jurisdiction regardless of where the data physically sits. The difference is therefore not where data is stored — the AWS Frankfurt region is also in the EU — but who controls the provider. Article 32 of EU Regulation 2023/2854 places the same obligation on every provider in the EU; it is not our advantage, only the difficulty of meeting it differs. PRO-ZETA is a Czech company with no parent outside the EU.

Will we lose elasticity by migrating?

Only the part you move loses elasticity — and that part is deliberately the static one. If you have genuine peaks, they belong in the public cloud and stay there; we describe that as the Spillover pattern. It is worth checking how much elasticity you actually use: anyone who has bought a one- or three-year Savings Plan or Reserved Instance has already declared their workload static in writing.

How long does migrating from AWS to a private cloud take?

It depends on scope and how much you migrate. Storage alone is usually a matter of weeks; moving a full production environment is more like two to four months. Our first phase is not migration but an assessment of what should move and what should not — for part of the workload, the right conclusion is to leave it where it is.

Does the EU Data Act change provider switching fees?

Yes. Under Article 29 of EU Regulation 2023/2854, from 12 January 2027 providers may not charge any fee for switching provider; until then they may charge no more than the costs actually incurred. The definition in Article 2(36) explicitly covers data egress charges. Note two common misreadings: what is abolished is egress on exit, not ordinary operational egress. And if you run both providers in parallel — a hybrid setup — Article 34(2) applies: egress is still billed, though now capped at the costs actually incurred.

Public cloud alternative: pragmatism over dogma

Public cloud is no longer an innovation. It is the norm — and the norm is judged on whether it serves and whether it adds up. This page sets out honestly where AWS, Azure and Google Cloud win and where they cost you more than they need to, and offers four concrete hybrid arrangements, including what is hard about each one.

Request a workload assessment When to keep the public cloud

Zero

egress, no cap

Prague

our own datacenter

ISO 27001

+ ISO 9001

8+ years

production OpenStack

From 12 January 2027, under Article 29 of EU Regulation 2023/2854, cloud providers may not charge switching fees — including egress on exit. Plan your move early →

Honestly: do you understand your invoice?

A public cloud invoice is not opaque by accident. It is assembled from dozens of independently metered items, several of which are calculated in ways you cannot reconstruct from the statement. A predictable invoice is not an accounting detail — it is a precondition for budgeting.

What share of your last public cloud invoice could you explain line by line?

The items that most often disappear from view

Egress to the internet

USD 0.09/GB

Outbound data from AWS eu-central-1. First 100 GB per month free, then descending bands. At 10 TB per month that is roughly USD 891.

NAT Gateway

USD 0.052/h + /GB

Billed per hour and per GB processed, regardless of direction or destination. It runs permanently, even when nothing flows through it.

Cross-zone traffic

USD 0.01/GB

High availability across availability zones is the recommended architecture — and it is metered. Azure bills it separately in each direction.

Provisioned IOPS

+USD 0.006/IOPS

gp3 includes 3,000 IOPS; every one above that is charged separately. On io2 every provisioned IOPS is charged from the first.

Snapshots

USD 0.054/GB-mo

Billed per GB-month and they grow quietly with retention. The archive class is cheaper, but restoring from it costs extra.

Load balancer LCUs

USD 0.008/LCU-h

Calculated from four dimensions — new connections, active connections, processed bytes and rule evaluations — and only the highest is billed. The invoice will not tell you which; CloudWatch metrics will.

CloudWatch and logs

USD 0.63/GB ingest

Ingest, storage and every query are billed separately. A cheaper Infrequent Access class exists, but you have to know about it and switch it on.

Support as a % of spend

9–10% of spend

Business Support+ starts at 9% of monthly spend, Enterprise Support at 10% with a USD 5,000 monthly minimum. The more you spend, the more support costs.

Unused commitments

1–3 year term

Savings Plans and Reserved Instances are paid whether or not you consume them. The commitment runs for one to three years.

Rates from the providers' public price lists as of 7 August 2026, AWS eu-central-1 (Frankfurt) unless stated otherwise. Prices change over time; verify against the current price list before deciding.

Is your elasticity real, or a story?

Stories about unlimited elasticity sound compelling — they are backed by the largest marketing budgets in the industry. Looked at honestly over the past three years, though, they hold for only some companies. Most workloads settle into a static range for one reason or another — criticality, reservation savings, operational inertia — and elasticity then works upward only.

A reservation is a written admission that your workload is static

Savings Plans and Reserved Instances are bought for one to three years and paid regardless of usage. Anyone who has bought one has already classified their workload as predictable — otherwise the commitment would make no sense. Which leaves the question of why a predictable workload is being billed on a model designed for unpredictable ones.

For core systems, elasticity is beside the point

Backbone systems need stability and predictable behaviour above all. Scaling them up and down with demand is not a feature, it is a risk. This part of the workload barely changes from year to year — and it is exactly where pay-per-use costs the most.

Shutting down dev environments at night is not elasticity

It is wallet defence. Real elasticity means capacity follows demand without anyone having to think about it. When a team is deciding whether to leave a test environment running over the weekend, they are not paying for flexibility — they are paying for the lack of it.

Where the public cloud wins, and we do not pretend otherwise

There is no one-size-fits-all answer. For certain kinds of company and workload the public cloud is clearly the right choice, and moving them to us would be a mistake. Here are the cases where we will tell you to stay where you are.

Globally distributed services

If you need to be close to users on three continents, no single datacenter in Prague will substitute for that. Global reach is something hyperscalers have and we do not.

Genuinely unpredictable peaks

If your load swings by an order of magnitude and cannot be forecast, pay-per-use is the right model. Paying for fixed capacity sized to the highest peak would cost more.

Experimental development

For a product that may not exist in six months, the value of starting fast with no commitment outweighs any saving on running costs. Committing to hardware would be premature.

Proprietary managed services

If you are built on Lambda, BigQuery, DynamoDB or Bedrock, no portable equivalent exists. Rewriting an application purely for infrastructure reasons almost never pays off.

Teams without operations capacity

A small team with no ops role benefits most from managed services. Our platform is managed too, but a hybrid arrangement assumes somebody is making architectural decisions.

Startups on cloud credits

While you are burning provider credits, your effective price is zero. Considering repatriation at that stage is premature optimisation — revisit it when the credits run out.

Four hybrid arrangements that actually work

Pragmatism beats marketing: take the best of both worlds. These are not theoretical options but concrete arrangements with their mechanics, their economics — and what is hard about each. We include that last point deliberately, because without it this would be just another sales sheet.

Strongest economics

The Data Anchor

Your data sits with us, compute runs anywhere — including AWS.

Who it suits: Companies with heavy data and light compute: video and IPTV, backups and archives, analytics exports, CDN origin, scientific and telemetry data. Typically wherever egress is a larger share of the bill than the servers themselves.
How it works: You move storage to us and leave the application and compute layer where it is. Data reaches compute over a private interconnect or the public internet from our Prague datacenter. You rewrite no applications and give up none of the proprietary services you depend on.
Why it saves: Hyperscalers do not charge for inbound data. We do not charge for outbound. In the direction from us to them, transfer is therefore free on both sides. The reverse arrangement — data in S3, compute elsewhere — bills you on every read.

What is hard about it

Latency. Prague to Frankfurt is a few milliseconds, which is fine for batch processing, streaming and analytics, but not for chatty per-query database access. The pattern suits large volumes and few round trips, not the other way round.

Anchor and Sail

Core systems and data anchored with us, digital channels and experiments in the public cloud.

Who it suits: Companies with a clearly separated stable backbone and a volatile front end — e-commerce, HR tech, media, betting and gaming platforms.
How it works: Channels stay in the public cloud, where they benefit from global reach and fast deployment. Core systems and data move to us, running on dedicated hardware with a predictable invoice. The two talk over an API, ideally across a private interconnect rather than the public internet.
Why it saves: Core workloads are the most static and longest running, which is precisely where a pay-per-use model makes least sense. It also puts personal and financial data outside a foreign jurisdiction.

What is hard about it

Splitting the stack creates a network boundary where none existed. It calls for a well-designed API and accepting that there is latency between the layers, and that the link can fail. This is not a pattern for a monolith that calls itself a hundred times per request.

The Quiet Twin

Production in the public cloud, a warm standby with us — DR without a second region.

Who it suits: Companies already in the public cloud and happy there, but solving disaster recovery by buying a second region from the same provider — doubling both the dependency and the bill.
How it works: Data replicates continuously into our datacenter, where a scaled-down environment stands ready to take over. Failover is tested on a schedule. If the provider or the region fails, traffic switches to us.
Why it saves: A standby environment is static by definition and runs permanently — the worst possible profile for pay-per-use. A second region from the same provider also protects against neither a control-plane outage nor a contractual or billing problem.

What is hard about it

DR that is never tested is not DR. This pattern lives or dies by the discipline of regular failover drills and honestly calculated RPO and RTO. Without them it is simply a second invoice.

The Spillover

A static base with us, peaks spilling into the public cloud.

Who it suits: Companies with pronounced seasonality or campaign peaks — retail before Christmas, betting around major fixtures, media during live broadcasts, ticketing.
How it works: The baseline capacity you run 365 days a year sits with us at a fixed price. Above it, capacity spins up in the public cloud during a peak and shuts down afterwards. It is driven either by load balancer weighting or by autoscaling across a federated cluster.
Why it saves: You pay for elasticity only in the hours you genuinely need it, instead of paying for it all year in the price of every core. Meanwhile the baseline runs on the cheapest possible model — fixed capacity.

What is hard about it

The most demanding pattern here. It requires a stateless application layer, shared state and a switchover tested in advance. Done badly, the peak exposes the problem at the worst possible moment. We do not recommend introducing it just before a season.

How does Tier5 compare with a hyperscaler?

PROZETA Tier5 against the public cloud (AWS, Azure, Google Cloud). We have left in the rows where the hyperscaler wins — a table in which one side wins everything is not a comparison, it is an advertisement.

Feature	PROZETA Tier5	Hyperscaler (AWS/Azure/GCP)
Billing model	Fixed monthly	Pay-per-use, dozens of meters
Egress (outbound data)	Zero, no cap	from USD 0.08/GB
Predictable invoice
Minimum commitment	None	Discounts need 1–3 years
Dedicated hardware
Noisy neighbours	None (dedicated HW)	Shared infrastructure
Data location	Prague, Czechia	Region of your choice
Who controls the provider	Czech company	Usually a US parent
Incident escalation	Straight to an engineer	Ticket, by support tier
Support included	24/7 included	9–10% of spend
Cost of static workloads
Cost of short peaks
Global reach
Managed service catalogue
Scaling in seconds

What are the AWS and Azure equivalents on our platform?

Tier5 is built on OpenStack, so most fundamental building blocks map directly. For each one we also note how ours differs — and separately below, what you will not find with us at all.

EC2 / Virtual MachinesNova (KVM)

Virtual machines on dedicated hardware, with no performance shared with anyone else's workload.

A smaller catalogue of instance types.

S3 / Blob StorageObject storage

S3-compatible API, so most libraries and tools work unchanged.

No global replication behind a single switch.

EBS / Managed DisksBlackStor

Our own NVMe storage, not Ceph. Higher IOPS and lower latency.

IOPS are not ordered separately — they are part of the performance.

RDS / Azure SQLManaged databases

Operated databases including backups, monitoring and updates.

A narrower choice of engines and versions.

EKS / AKSKubernetes (Magnum)

Production clusters on dedicated infrastructure with BlackStor storage.

No deep ties into provider-proprietary services.

ELB / Load BalancerOctavia

L4 and L7 balancing, billed as part of the environment rather than per LCU.

No global anycast balancing.

VPC / VNetNeutron (OVN)

Software-defined networking with VLAN/VXLAN, firewalling and VPN.

No Transit Gateway equivalent for dozens of accounts.

IAM / Entra IDKeystone

Projects, roles and granular permissions, connectable to your identity provider.

Less fine-grained policy control than IAM.

CloudWatch / MonitorMonitoring included

Metrics, logs and alerting as part of the service rather than a separately billed line.

Without the large ecosystem of ready-made integrations.

What you will not find with us

We do not have these and do not pretend to. If you depend on them, the right answer is not to replace them but to leave them where they are — and use one of the hybrid patterns.

Serverless functions such as AWS Lambda
Data warehouses such as BigQuery or Redshift
Managed AI platforms such as Bedrock or Vertex AI
Globally replicated NoSQL such as DynamoDB or Cosmos DB
Our own global CDN with edge locations
Hundreds of adjacent services in one catalogue

How to work with them in a hybrid setup →

What would the same workload cost at a hyperscaler?

Enter your workload and the calculator itemises the AWS bill line by line, from actual list rates for Frankfurt. The point is not one big number but how many separately billed lines hide behind it.

vCPUs

432 vCPU256

Memory

8128 GB1024

Block storage

14 TB100

Monthly outbound data (egress)

010 TB200

Include

NAT GatewayEffectively required for private subnets with outbound accessApplication Load BalancerBilled per hour and by data processedSnapshots (50% of disk size)Grow quietly with retentionBusiness Support+A percentage of spend, not a flat fee

Monthly AWS bill, itemised

Line item	Rate	Monthly
Compute	32× vCPU m7i · 44.07 USD	32,436 Kč
gp3 storage	4,000 GB · 0.0952 USD/GB	8,758 Kč
Snapshots	2,000 GB · 0.054 USD/GB	2,484 Kč
Egress to internet	10,000 GB · od 0.09 USD/GB	20,493 Kč
NAT Gateway	0.052 USD/h + 0.052 USD/GB	12,833 Kč
Load balancer	0.027 USD/h + 0.008 USD/LCU-h	2,293 Kč
Support	9–3 % of spend	7,137 Kč
AWS total		86,434 Kč1,037,209 Kč per year

Your requirement fits the m7i ratio without overpaying.

PROZETA Tier5

Egress to internetZero, no cap
Support24/7 — In the monthly fee

Indicative estimate, total51,860 – 60,504 Kčtypically 30–40% less

This is neither a quote nor a price list. We price ad hoc against the specific configuration, commitment length and operational requirements — some workloads land lower, others higher. The only two figures that always hold are zero egress and support included. We will cost your case properly.

One line on the invoice. Instead of seven separately billed metrics to reconcile month after month.

Get this compared for our workload

The same egress elsewhere

AWS (eu-central-1)

20,493 Kč

Azure (West Europe)

18,216 Kč

Google Cloud (Premium Tier)

25,527 Kč

List rates as of 7. 8. 2026, AWS eu-central-1 (Frankfurt), On-Demand Linux with no commitment, converted at CZK 23/USD. The load balancer is costed from the processed-data dimension only — AWS bills the highest of four dimensions, so the real figure may be higher. Excludes cross-zone traffic, inter-region transfer, CloudWatch and backup services.

How does repatriation work?

The first phase is not migration but an assessment of what should move and what should not. Not everything should. That is the entire point of this page.

Phase 1

Assessment: what moves and what does not

We go through your workload and your invoice line by line. The result is a split between what is worth repatriating and what should stay with the hyperscaler. For part of the workload, the right answer is to do nothing.

Phase 2

Hybrid design

We pick a pattern and design the boundary between the two worlds — interconnect, network and security perimeter. This includes a cost model for before and after, not just a technical diagram.

Phase 3

Environment build

We build your dedicated Tier5 environment on HPE hardware with BlackStor storage in our Prague datacenter, including interconnect and monitoring.

Phase 4

Move and verify

Data and workloads move in waves, with a path back at every step. Each wave is verified for performance and functionality before the next one starts.

Hybrid cloud and repatriation FAQ

Answers to the questions CTOs and infrastructure teams ask us when they are considering moving part of a workload out of the public cloud.

Not sure which half of your workload should move?

We will go through your invoice and your architecture and tell you what is worth repatriating and what should stay where it is. No commitment — and quite possibly with the conclusion that you should stay.

Book an assessment