DEV Community: Denys Zaruin

Migrating from AWS to UpCloud: what moves, what changes, what it costs

Denys Zaruin — Thu, 29 Oct 2026 18:49:06 +0000

Originally published on moveinfra.eu.

Migrating from AWS to UpCloud is straightforward for companies running standard web architectures built on virtual machines, Kubernetes, relational databases, and S3-compatible object storage. Most core compute, storage, and networking resources map directly between the two platforms, while proprietary AWS services like DynamoDB, SQS, or Lambda require replacing with open-source equivalents or container workloads. Companies making this move typically reduce their monthly cloud spend by eliminating outbound data transfer fees, avoiding Kubernetes control plane charges, and switching to predictable, bundled server pricing.

Key takeaways

Direct infrastructure mapping: EC2, RDS (PostgreSQL and MySQL), ElastiCache, S3, EKS, and Application Load Balancers all have direct managed equivalents on UpCloud.
True European jurisdiction: UpCloud is headquartered in Helsinki, Finland, operating under EU and Finnish law rather than US extraterritorial jurisdiction.
Predictable cost structure: UpCloud includes storage and outbound data transfer (under a Fair Transfer Policy) in its server plans, removing two of the most unpredictable items on an AWS bill.
Proprietary services need adjustment: Workloads relying heavily on AWS Lambda, SQS, or DynamoDB must be refactored to run on containers, self-managed queues, or standard databases before or during the move.
Egress fees for switching are regulated: Under the EU Data Act, cloud providers can charge no more than their actual cost for switching egress until January 12, 2027, when switching charges are banned altogether.

Why European companies move from AWS to UpCloud

For most 10-to-300-person European companies, AWS offers far more services than the engineering team actually uses. You pay a premium—both in monthly invoices and in cognitive load—for a catalog of over 200 services when your application only needs compute, a relational database, a Redis-compatible cache, and object storage.

Three practical reasons usually trigger a move to UpCloud:

Cost predictability: AWS bills are composite. A single virtual machine involves separate charges for the EC2 instance, the EBS root volume, provisioned IOPS, public IPv4 addresses, NAT Gateway hourly fees,NAT Gateway data processing fees, and outbound internet traffic. UpCloud bundles CPU, memory, high-speed MaxIOPS block storage, and outbound data transfer into a single flat rate.
Data sovereignty and compliance: UpCloud Ltd is a Finnish company. While AWS offers EU regions and an AWS European Sovereign Cloud that keeps data and operations inside the EU, Amazon remains a US parent corporation subject to the US CLOUD Act. For teams bound by strict customer contracts or regulations like DORA (Regulation (EU) 2022/2554), moving to an EU-owned provider simplifies compliance and risk assessments.
Right-sized operational complexity: Managing AWS IAM policies, VPC route tables, and multi-layered security rules takes dedicated specialist time. UpCloud provides a cleaner API, native Terraform and OpenTofu providers, and straightforward private networking without losing production essentials.

Service mapping: what moves directly

If your stack is built on open standards or Linux primitives, migrating from AWS to UpCloud is mostly an infrastructure-as-code translation exercise.

AWS Service	UpCloud Equivalent	Migration Notes
EC2	Cloud Servers (Starter, Premium, Cloud Native)	Rebuild via Terraform or Ansible; deploy existing Docker images or binaries.
EBS (gp3 / io2)	MaxIOPS Block Storage	Included in server plans or attached as extra volumes; no separate IOPS provisioning needed.
RDS (PostgreSQL, MySQL)	Managed Databases (PostgreSQL, MySQL)	Migrate using native logical replication (`pglogical` or MySQL binlog) for minimal cutover pause.
ElastiCache (Redis / Valkey)	Managed Valkey	Valkey is the open-source, drop-in successor to Redis. Standard Redis clients connect without code changes.
S3	Managed Object Storage	S3-compatible API. Update endpoint URLs and credentials in your application config; sync data via `rclone` or AWS CLI.
EKS	UpCloud Kubernetes Service (UKS)	CNCF-certified Kubernetes. Manifests and Helm charts move directly; update storage classes and ingress annotations.
ALB / NLB	Managed Load Balancer	Supports HTTP/HTTPS and TCP balancing, TLS termination, and health checks.
VPC, Subnets, NAT Gateway	SDN Private Networks & NAT Gateway	Private Layer 2/3 networks between servers, databases, and Kubernetes clusters.
EFS	File Storage (NFS)	Shared network storage across multiple Cloud Servers.
OpenSearch Service	Managed OpenSearch	Direct managed equivalent for search and log analytics.

Compute and Block Storage

On AWS, you choose between dozens of instance families (t3, m6i, c7g) and configure EBS volumes separately. As of 2026, UpCloud organizes its general compute primarily around Starter plans (aimed at development, testing, and lighter workloads), Premium plans (built on AMD EPYC hardware with bundled MaxIOPS storage for production), and Cloud Native plans (designed for Kubernetes and container nodes where you size storage separately). UpCloud also offers dedicated GPU servers for machine learning workloads.

Managed Databases and Caches

AWS RDS for PostgreSQL and MySQL map directly to UpCloud Managed Databases. UpCloud handles automated backups, point-in-time recovery, minor version upgrades, and high-availability failover. For caching, AWS ElastiCache users move to UpCloud Managed Valkey. Because Valkey maintains wire-protocol compatibility with Redis, your application libraries (ioredis, redis-py, go-redis) work by simply changing the connection string.

Kubernetes (EKS to UKS)

Migrating from Amazon EKS to UpCloud Kubernetes Service (UKS) often removes significant glue code. EKS relies heavily on AWS-specific IAM Roles for Service Accounts (IRSA), the AWS Load Balancer Controller, and the EBS CSI driver. On UKS, the UpCloud Container Storage Interface (CSI) and Cloud Controller Manager are pre-configured, so creating a standard Kubernetes PersistentVolumeClaim or a Service of type LoadBalancer automatically provisions UpCloud block storage or a Managed Load Balancer.

What changes in your architecture

Not every part of an AWS account has a 1-to-1 button on UpCloud. When planning your migration, expect to adjust the following areas.

1. Identity and Access Management (IAM)

AWS uses IAM not just for human users, but as a service-to-service authentication fabric (for example, allowing an EC2 instance role to write to an S3 bucket without static keys). UpCloud supports sub-accounts, workspace permissions, API tokens, and S3 user access policies, but it does not replicate AWS's cross-service IAM role assumption.

What to change: Use S3 access keys stored in secret managers or Kubernetes Secrets for Object Storage access, and rely on private SDN networks and firewall rules to restrict database and cache traffic to authorized compute nodes.

2. Queues, Emails, and Serverless Functions

UpCloud focuses on core infrastructure (IaaS) and essential managed platforms (PaaS) rather than application-layer microservices. It does not offer native equivalents to AWS SQS, SNS, SES, or Lambda.

Serverless functions (Lambda): Most teams package their Node.js, Python, or Go functions as lightweight HTTP containers and deploy them onto their UKS cluster or a small Cloud Server, triggering them via standard cron jobs or webhooks.
Message queues (SQS/SNS): If you use queues for background jobs, you can move the queue workload onto your UpCloud Managed Valkey instance (using BullMQ, Sidekiq, or Celery) or run RabbitMQ / NATS on your Kubernetes cluster.
Transactional email (SES): Point your application to a dedicated European email provider (such as Scaleway Transactional Email or Mailjet) via standard SMTP or REST API.

3. Proprietary Databases and Warehouses

Workloads tied to Amazon DynamoDB, Aurora Serverless features, or Amazon Redshift cannot be lifted and shifted without code changes. If DynamoDB is used simply as a key-value store or session cache, it can often be replaced with PostgreSQL (using JSONB columns) or Valkey. If your entire application data model is built around single-table DynamoDB designs, you will need a dedicated refactoring project before moving.

4. DNS and CDN

UpCloud does not operate an authoritative DNS service equivalent to Route 53, though it is rolling out its own Content Delivery Network. Most engineering teams keep DNS on an independent provider (like Cloudflare or DNSimple) or another European provider. Keeping DNS independent of your compute provider is good operational practice anyway, as it makes traffic switching and multi-cloud rollbacks much easier.

What it costs: AWS vs. UpCloud in 2026

Cloud pricing changes frequently, so you should always verify current numbers on the official AWS and UpCloud pricing pages. However, comparing the pricing structures as of 2026 highlights why bills look so different on the two platforms.

Compute and Storage Pricing

On AWS (eu-central-1, Frankfurt), a standard production general-purpose instance like an m6i.xlarge (4 vCPUs, 16 GB RAM) costs approximately $180 to $190 per month on-demand, before adding EBS storage (roughly $0.09/GB-month for gp3) and public IPv4 fees (approximately $3.65/month per IP).

On UpCloud, as of 2026, compute is priced in flat tiers with storage included:

Starter plans (for dev/test and lighter workloads) start at approximately €3/month (1 vCPU, 1 GB RAM, 10 GB storage) and run up to €28/month for 4 vCPUs, 16 GB RAM, and 50 GB storage.
Premium plans (AMD EPYC production hardware with MaxIOPS storage) start at approximately €5/month. A production server with 4 CPU cores, 8 GB RAM, and 100 GB of MaxIOPS storage costs approximately €52/month, while 4 CPU cores, 16 GB RAM, and 150 GB of storage is approximately €92/month (excluding VAT).

The Hidden Multipliers: Egress and Control Planes

Where European companies usually see the biggest savings is not raw CPU cost, but the elimination of AWS overhead fees:

Data egress (outbound traffic): AWS charges roughly $0.09 per GB for data transferred out to the internet after the first 100 GB, plus cross-AZ transfer fees ($0.01/GB in each direction) when instances talk to databases or load balancers in different Availability Zones. UpCloud includes zero-cost egress across its plans under a generous Fair Transfer Policy, and private SDN traffic between your servers within a data center is free.
Kubernetes control plane: AWS charges $0.10 per hour (approximately $73/month) per EKS cluster just for the control plane—if you run separate dev, staging, and production clusters, that is over $215/month before booting a single worker node. UpCloud includes the UKS control plane at no additional cost as part of its "UpCloud Essentials" offering; you only pay for the worker nodes, load balancers, and storage you attach.
One-time migration egress fees: Historically, AWS charged steep data transfer fees when copying terabytes of S3 data and database snapshots out to another provider. Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers may charge no more than their actual incurred cost for data egress when a customer is switching providers until January 12, 2027. Starting January 12, 2027, switching charges—including data egress fees for switching—are completely banned across the EU.

Pre-migration checklist: how to execute the move

A disciplined migration avoids "big bang" rewrites. Build the new environment alongside the old one, synchronize the data, and switch traffic only when both environments match.

Audit your AWS bill and state: Export your last three AWS bills and your Terraform state. Flag any proprietary services (SQS, Lambda, SES) and decide how you will replace them before touching production.
Choose your UpCloud region: Select a European data center close to your users—such as Frankfurt (de-fra1), Amsterdam (nl-ams1), Helsinki (fi-hel1 / fi-hel2), Madrid (es-mad1), Warsaw (pl-waw1), Stockholm (se-sto1), Copenhagen, or Oslo.
Rebuild infrastructure as code: Write new Terraform or OpenTofu configurations using the official UpCloudLtd/upcloud provider to provision SDN private networks, firewall rules, UKS clusters or Cloud Servers, and Managed Databases.
Update CI/CD pipelines: Duplicate your GitHub Actions or GitLab CI deployment jobs so your team can deploy the exact same application build to both AWS and UpCloud simultaneously.
Sync Object Storage: Use rclone or S3 migration tooling to copy objects from AWS S3 to UpCloud Managed Object Storage. Run periodic delta syncs with checksum verification to capture newly uploaded files.
Set up live database replication: Configure logical replication from AWS RDS to UpCloud Managed Databases. This allows your UpCloud database to stay within seconds of your live AWS production database without taking your app offline.
Lower DNS TTLs: At least 48 hours before cutover, reduce the Time-To-Live (TTL) on your DNS records to 60 seconds.
Cut over with a short write pause: During a low-traffic window, put the AWS application into maintenance (read-only) mode, verify that database replication lag is zero, run a final object storage delta sync, promote the UpCloud database to primary, and update your DNS records to point to your UpCloud Load Balancer.
Keep a rollback window: Do not delete your AWS environment on day one. Keep reverse replication or snapshots running for two to four weeks until your team is confident in the new setup, then decommission the AWS resources.

Frequently asked questions

Does UpCloud support multi-AZ deployments like AWS?

UpCloud approaches availability differently than AWS. Instead of splitting every city into three separate Availability Zones and charging for cross-AZ traffic, UpCloud builds high redundancy directly into each data center (including triple-replicated MaxIOPS storage over InfiniBand and redundant networking) backed by a 99.99% uptime SLA. For Managed Databases and Managed Load Balancers, you can select multi-node High Availability plans that automatically handle node failures. For disaster recovery across physical locations, you can replicate across UpCloud's multiple European data centers.

Do we need to rewrite our applications to move from S3 to UpCloud Object Storage?

No. UpCloud Managed Object Storage is S3-compatible. You keep using the official AWS SDKs (@aws-sdk/client-s3, boto3, etc.) in your application code. You only need to change the endpoint configuration parameter to point to your UpCloud Object Storage URL and update your access key and secret key.

How long does a typical AWS to UpCloud migration take?

For a company with 10 to 300 employees running a standard web stack (VMs or Kubernetes, PostgreSQL/MySQL, Redis, and S3), the end-to-end process typically takes between two and four weeks. Most of that calendar time is spent testing the staging environment, updating CI/CD pipelines, and letting large initial data transfers complete in the background. The actual production cutover pause usually takes between 5 and 30 minutes.

What happens to our AWS Reserved Instances or Savings Plans?

If you have active 1-year or 3-year AWS Savings Plans or Reserved Instances, you remain financially committed to those hourly payments until the term expires (though some standard EC2 Reserved Instances can be listed on the AWS RI Marketplace). Before migrating, check the expiration dates in AWS Cost Explorer. Even with an active commitment, some companies move part of their workload early to eliminate high AWS NAT Gateway and data egress charges.

Sources

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

AWS European Sovereign Cloud vs EU-Owned Providers Compared

Denys Zaruin — Thu, 29 Oct 2026 09:24:24 +0000

Originally published on moveinfra.eu.

The AWS European Sovereign Cloud, which reached general availability in January 2026 in Brandenburg, Germany, offers physical and logical separation from standard AWS regions and is operated exclusively by EU residents. However, it remains a wholly owned subsidiary of Amazon.com, Inc., a US corporation. For European companies evaluating cloud sovereignty, the core choice comes down to risk tolerance and technical requirements: the AWS European Sovereign Cloud provides strict operational and metadata residency in the EU while preserving access to proprietary AWS services, whereas EU-owned providers (such as UpCloud, Scaleway, OVHcloud, Hetzner, and STACKIT) provide complete legal independence from US extraterritorial laws alongside lower, more predictable infrastructure pricing.

Key takeaways

Data and operational residency vs. legal sovereignty: The AWS European Sovereign Cloud keeps customer data, metadata, billing, and operations inside the EU under EU-resident staff. EU-owned providers offer this same operational residency, plus ultimate corporate ownership domiciled inside Europe.
Moving to the AWS Sovereign Cloud is still a migration: Because the AWS European Sovereign Cloud is logically isolated with its own identity, billing, and account systems, moving there from eu-central-1 (Frankfurt) or eu-west-1 (Ireland) requires creating new accounts and migrating data and workloads.
Service breadth vs. standard primitives: AWS offers a much larger catalog of proprietary managed services than any European provider. However, most 10-to-300-person companies rely primarily on standard primitives—virtual machines, Kubernetes, managed PostgreSQL or MySQL, Redis, and S3-compatible object storage—which EU-owned clouds support natively.
Cost and egress dynamics: Under Article 29 of the EU Data Act, cloud switching charges (including data egress fees for moving to another provider) are capped at actual cost until 12 January 2027 and banned entirely from 12 January 2027.

What is the AWS European Sovereign Cloud?

In January 2026, Amazon Web Services launched the AWS European Sovereign Cloud with its initial region located in Brandenburg, Germany. AWS built this environment specifically for European public sector bodies and regulated businesses that face strict compliance requirements around data residency and operational autonomy.

In standard AWS European regions—such as Frankfurt (eu-central-1), Ireland (eu-west-1), or Stockholm (eu-north-1)—customer content stays in the selected region by default. However, account management, billing systems, global IAM planes, and certain operational metadata are connected to AWS's global infrastructure, and support or maintenance may involve non-EU personnel.

The AWS European Sovereign Cloud changes this architecture in several ways:

Physical and logical separation: The infrastructure is separate from existing AWS regions, with no critical dependencies on non-EU infrastructure. It even maintains a local, in-EU copy of the source code required to run the cloud.
Metadata residency: Not only customer application data, but also customer-created metadata (such as resource tags, IAM role names, and configuration details) and billing records remain inside the EU.
EU-resident personnel: Day-to-day operations, data center access, and technical support are restricted exclusively to AWS employees who are EU residents located within the European Union.
Corporate governance: The cloud operates under dedicated European legal entities managed by EU nationals, supported by an independent advisory board. In early 2026, it achieved its initial C5 (BSI Cloud Computing Compliance Criteria Catalogue) and SOC 2 reports alongside ISO certifications.

For organizations that are deeply tied to AWS-specific APIs and need verified assurance that operational metadata and support tickets never leave European borders, this architecture is a major upgrade over standard AWS regions.

How EU-owned cloud providers differ

While AWS has engineered strong technical and operational boundaries in Brandenburg, EU-owned cloud providers start from a fundamentally different legal foundation. Providers such as UpCloud (Finland), Scaleway (France), OVHcloud (France), Hetzner (Germany), STACKIT (Germany), IONOS (Germany), and Exoscale (Switzerland/Austria) are headquartered in Europe and owned by European parent companies.

When comparing these two models, compliance teams, CTOs, and CFOs usually divide sovereignty into three distinct layers:

1. Data and metadata residency

Both the AWS European Sovereign Cloud and EU-owned cloud providers keep your databases, object storage buckets, backups, and operational metadata inside European borders. On this layer, both options satisfy strict geographic localization requirements.

2. Operational sovereignty

Operational sovereignty measures who controls the keyboards and whether the cloud can keep running if cut off from the rest of the world. AWS addresses this in its Sovereign Cloud by staffing exclusively with EU residents and running periodic exercises to demonstrate that the region can operate independently of the global AWS network backbone. EU-owned providers achieve this natively, as their core engineering, executive leadership, and network operations centers are already based in Europe.

3. Legal and corporate sovereignty

This is where the two paths diverge. However autonomous a local European subsidiary may be in its daily operations, the AWS European Sovereign Cloud ultimately belongs to Amazon.com, Inc., a US company.

Under the US Clarifying Lawful Overseas Use of Data (CLOUD) Act of 2018, US law enforcement authorities can compel US-based technology companies to provide data stored on servers regardless of whether that data is located in the United States or a foreign country, provided the parent company exercises "possession, custody, or control" over the subsidiary.

AWS states that it uses strong technical, operational, and legal measures to challenge unlawful or conflicting law enforcement requests, and notes that customer encryption keys can be managed separately. For many commercial companies, those safeguards are sufficient. However, for European businesses whose clients, regulators, or public-sector tenders explicitly require immunity from non-EU extraterritorial laws, only a provider whose ultimate parent company is domiciled in the EU or EEA completely removes US jurisdiction from the legal chain.

Side-by-side comparison

The table below outlines the practical differences between standard AWS EU regions, the AWS European Sovereign Cloud, and EU-owned cloud providers.

Feature / Criterion	Standard AWS EU Regions (e.g., Frankfurt)	AWS European Sovereign Cloud (Brandenburg)	EU-Owned Cloud Providers (UpCloud, Scaleway, OVHcloud, etc.)
Ultimate parent company	Amazon.com, Inc. (US)	Amazon.com, Inc. (US)	European corporate parent (EU / EEA / CH)
Application data location	EU (customer selectable)	EU only (Germany, plus select EU Local Zones)	EU / EEA data centers
Account metadata & billing	Global AWS control plane	Strictly within the EU	Strictly within Europe
Operations & support staff	Global follow-the-sun staff	EU residents located in the EU only	Primarily EU-based staff
Exposure to US CLOUD Act	Yes	Legal debate remains due to US parent ownership	None (for providers without US operations/nexus)
Service catalog depth	200+ services (full AWS catalog)	Comprehensive, though slightly smaller than standard regions	Focused on core IaaS, PaaS, Kubernetes, and managed databases
Migration required from AWS Frankfurt/Ireland?	N/A	Yes (separate accounts, IAM, and network plane)	Yes (rebuild infrastructure and replicate data)
Pricing structure	Complex; high bandwidth and managed service markups	Dedicated sovereign pricing; complex metering	Transparent, flat or bundled bandwidth, lower compute/storage rates

The hidden catch: moving to the AWS Sovereign Cloud is still a migration

A common misconception among executives is that switching from AWS Frankfurt (eu-central-1) to the AWS European Sovereign Cloud is a simple configuration toggle in the AWS Console.

Because the Sovereign Cloud is physically and logically isolated from standard AWS partitions, it does not share a global IAM plane, Organization structure, billing account, or private VPC peering backbone with standard AWS regions.

To move an existing workload from a standard AWS region into the AWS European Sovereign Cloud, your engineering team must:

Establish a separate sovereign account and billing agreement.
Provision new networks, security groups, IAM policies, and compute resources inside the sovereign partition.
Replicate databases and copy S3 buckets across the boundary between the standard AWS partition and the sovereign partition.
Update CI/CD pipelines, secrets, and DNS records to point to the new environment.

Your existing Infrastructure-as-Code (such as Terraform or CloudFormation templates) will require far fewer edits when moving to the AWS Sovereign Cloud than when moving to an EU provider, provided all the AWS services you use are available in the Brandenburg region. However, because you still have to perform a full data migration and cutover window, many engineering and finance leaders use this mandatory migration moment to evaluate whether they should move to an EU-owned cloud instead.

Technical trade-offs: proprietary services vs. standard infrastructure

When evaluating whether to stay within the AWS ecosystem or move to an European provider like UpCloud, Scaleway, OVHcloud, or STACKIT, the most important technical question is what services your application actually uses.

When the AWS Sovereign Cloud is the stronger fit

If your software architecture is built heavily around AWS-proprietary services—such as Amazon DynamoDB, AWS Step Functions, Amazon Kinesis, AWS Glue, or Amazon Redshift—moving to an EU-owned cloud requires rewriting application code. Re-architecting a core product away from DynamoDB to PostgreSQL takes engineering time and carries delivery risk. If you need stronger EU operational residency without changing your application code, the AWS European Sovereign Cloud is designed for your situation.

When EU-owned providers are the stronger fit

In practice, a high percentage of European SaaS companies, digital agencies, and mid-market enterprises do not rely deeply on proprietary cloud APIs. Instead, their stack consists of portable, industry-standard components:

Linux virtual machines or managed Kubernetes clusters (EKS equivalents).
Relational databases running PostgreSQL or MySQL (RDS equivalents).
Redis-compatible in-memory caches (ElastiCache equivalents).
S3-compatible object storage for files and backups.
Standard load balancers, private networks, and firewalls.

Every major EU-owned cloud provider offers these core building blocks(though Hetzner focuses on unmanaged virtual and dedicated servers where Kubernetes and databases are run directly on instances, while UpCloud, Scaleway, OVHcloud, and STACKIT provide fully managed databases and Kubernetes). When your application uses standard open-source protocols, you can run on European infrastructure without rewriting your application logic.

Pricing, egress fees, and regulatory drivers

Cost and compliance are closely linked when comparing hyperscalers with European providers.

Predictable infrastructure spend

Hyperscaler bills often grow unpredictable due to itemized charges for NAT gateways, cross-AZ data transfer, IOPS provisioning, and high markups on managed databases. European cloud providers typically compete by offering simpler pricing structures, lower baseline costs for CPU, RAM, and NVMe storage, and generous or flat-rate outbound bandwidth allowances. (Because cloud pricing varies by region and instance generation, always check each provider's official pricing page for current 2026 list prices.)

The EU Data Act and switching costs

Historically, high data egress fees made leaving a hyperscaler expensive. Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers may charge no more than their actual, directly incurred costs for switching-related data egress until 12 January 2027. Starting on 12 January 2027, switching charges—including data egress fees when migrating to another provider—are banned across the EU. This removes the financial penalty for copying terabytes of object storage and database state out of standard AWS regions.

DORA and exit strategies

For financial entities and their critical ICT suppliers, the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) has applied since 17 January 2025. DORA requires covered institutions to manage ICT third-party concentration risk and maintain documented, tested exit strategies for critical services. Moving standard workloads to EU-owned providers—or maintaining portable Terraform configurations that do not rely on proprietary hyperscaler APIs—directly supports DORA compliance.

Decision checklist: which path fits your company?

Use this checklist with your leadership and engineering teams to decide which environment matches your constraints:

Audit your customer and regulatory requirements: Do your customers or regulators require only that data and operations stay in the EU, or do they require a provider free from US corporate ownership and the US CLOUD Act?
Inventory your cloud bill and service usage: List every AWS service accounting for more than 1% of your monthly spend. Are they standard primitives (EC2, RDS Postgres/MySQL, EKS, S3, ElastiCache) or proprietary services (DynamoDB, Redshift, Cognito)?
Compare total cost of ownership (TCO): Model your current resource footprint (vCPUs, RAM, storage, and monthly bandwidth) against the sovereign pricing of AWS versus an EU provider like UpCloud, Scaleway, or OVHcloud.
Assess migration effort: Since moving from eu-central-1 to the AWS European Sovereign Cloud already requires provisioning new accounts, networks, and database replication, evaluate whether the effort is comparable to migrating to an EU-owned provider.

Frequently asked questions

Does the AWS European Sovereign Cloud protect against the US CLOUD Act?

The AWS European Sovereign Cloud operates under European legal entities with EU-resident staff and strong technical controls, which lowers the practical risk of routine foreign access. However, because the ultimate parent company is Amazon.com, Inc. (a US corporation), legal experts and European data protection authorities note that it remains within the theoretical reach of the US CLOUD Act. Only providers wholly owned and headquartered outside US jurisdiction avoid the US CLOUD Act entirely.

Can I migrate from AWS Frankfurt to the AWS Sovereign Cloud with one click?

No. The AWS European Sovereign Cloud is a separate logical partition with independent billing, identity (IAM), and network planes. Moving workloads from standard AWS regions requires setting up new sovereign accounts, deploying new infrastructure, and migrating your data across partitions.

Are EU-owned clouds reliable enough for production SaaS workloads?

Yes, provided you choose the right provider and architecture for your needs. Providers such as UpCloud, Scaleway, OVHcloud, Exoscale, and STACKIT offer multi-zone availability, SLA-backed managed Kubernetes and relational databases, ISO 27001 certifications, and high-performance NVMe storage suitable for demanding production SaaS applications.

What happens to AWS data egress fees if we move to an EU provider?

Under Article 29 of the EU Data Act, cloud providers can only pass on the actual cost of switching until 12 January 2027, and from 12 January 2027 onward, all switching charges—including data egress fees when migrating to a new cloud provider—are prohibited by EU law.

Sources

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.

Moving from AWS to Hetzner: What You Gain and What You Must Build

Denys Zaruin — Thu, 29 Oct 2026 09:22:01 +0000

Originally published on moveinfra.eu.

Moving from AWS to Hetzner gives European companies much lower compute and network costs, predictable monthly billing, and strict German legal jurisdiction, while requiring engineering teams to self-manage services that AWS runs for them. Hetzner provides core infrastructure building blocks—including virtual servers, dedicated bare-metal machines, block volumes, S3-compatible object storage, private networks, firewalls, and load balancers—at a fraction of hyperscaler prices. However, Hetzner does not offer managed relational databases (like AWS RDS), managed Kubernetes (like Amazon EKS), managed caching (like ElastiCache), or serverless queues and functions. If your architecture relies on these services, migrating to Hetzner means deploying and operating them yourself on virtual or dedicated servers, or choosing another European provider that offers managed platform services.

Key takeaways

Substantial cost reductions on compute and egress: Hetzner bundles generous outbound data transfer (typically 20 TB per server in European locations) and charges a single flat rate for compute, removing the complex per-gigabyte NAT gateway and egress fees common on AWS.
True European jurisdiction: Hetzner Online GmbH is headquartered in Germany and operates data centers in Nuremberg and Falkenstein (Germany) and Helsinki (Finland), keeping your infrastructure outside the reach of US extraterritorial laws.
No managed databases or Kubernetes: Unlike AWS, Hetzner focuses strictly on Infrastructure as a Service (IaaS). You must run PostgreSQL, MySQL, Redis, and Kubernetes on your own cloud or dedicated instances using open-source tools and automation.
Simpler networking and permissions: You trade AWS's sprawling IAM policies and multi-layered VPC billing for straightforward cloud firewalls, private networks, and project-based API tokens.
Regulatory tailwinds for switching: Under the EU Data Act (Regulation (EU) 2023/2854), cloud providers can charge no more than their direct cost for switching egress until January 12, 2027, after which switching fees are banned completely.

Why European companies move from AWS to Hetzner

For most 10-to-300-person companies in Europe, the initial push to evaluate Hetzner comes from looking at the monthly AWS bill. On AWS, compute is rarely the only major expense. Costs accumulate through managed service premiums, per-gigabyte charges for traffic passing through NAT gateways, cross-availability-zone data transfer fees, and outbound internet egress.

Hetzner structures its pricing around flat, predictable resource usage. Whether you rent shared-CPU virtual machines, dedicated-CPU cloud instances, or physical bare-metal servers through Hetzner Robot, the monthly ceiling is clear. In European regions, cloud servers include 20 TB of outbound traffic per month at no additional charge, and internal traffic over Hetzner Private Networks is free. You should always check Hetzner's official pricing page for current figures, especially following their June 2026 price adjustments on dedicated hardware, as exact numbers depend on server generation and location.

The second driver is legal and operational sovereignty. Even if you deploy workloads in the AWS Frankfurt (eu-central-1) region or use the AWS European Sovereign Cloud, the underlying provider remains Amazon, a US corporation subject to the US CLOUD Act. Hetzner Online GmbH is a privately owned German company founded in 1997. When you host in its German or Finnish data centers, both the physical hardware and the corporate parent fall strictly under EU and national law. For companies subject to strict GDPR interpretations by enterprise customers, or financial entities building exit strategies under the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), moving to a domestic European provider simplifies compliance audits.

Finally, there is engineering clarity. AWS offers over two hundred services, which often leads small engineering teams to build overly complex architectures. Moving to Hetzner forces a return to standard Linux servers, containers, and open-source software that can run anywhere.

AWS to Hetzner service mapping

Before planning a migration, both technical leads and finance teams need an honest view of how AWS components translate to Hetzner. Some services map directly, while others shift operational responsibility back to your team.

AWS Service	Hetzner Equivalent	What Changes in Practice
EC2 (Virtual Servers)	Hetzner Cloud VMs / Dedicated Servers	Direct replacement. Available in shared x86, Arm64 (Ampere), dedicated vCPU, and bare-metal options.
EBS (Block Storage)	Hetzner Cloud Volumes	Network-attached block storage expandable up to 10 TB per volume. Attached directly to Cloud VMs.
S3 (Object Storage)	Hetzner Object Storage	Native S3-compatible object storage. Supports standard S3 API calls, buckets, and access keys, though advanced AWS-specific features (like S3 Select or Glacier) are not present.
ALB / NLB (Load Balancers)	Hetzner Cloud Load Balancers	Managed Layer 4 (TCP) and Layer 7 (HTTP/HTTPS) load balancers with automated Let's Encrypt TLS certificates and health checks.
VPC & Security Groups	Private Networks & Cloud Firewalls	Simpler flat private routing across servers and stateful firewall rules applied via server labels or direct assignment.
Route 53 (DNS)	Hetzner DNS Console	Supports standard DNS zone management via UI and API, without complex geo-proximity or latency-based routing policies.
RDS / Aurora (PostgreSQL, MySQL)	None (Self-managed on VMs)	You must install, configure, replicate, and back up databases on Hetzner servers yourself.
EKS / ECS (Containers)	None (Self-managed on VMs)	You must bootstrap and maintain your own Kubernetes cluster (e.g., via k3s, Talos, or kubeadm) on Hetzner VMs.
ElastiCache (Redis)	None (Self-managed on VMs)	Requires running Redis or Valkey directly on virtual machines with Sentinel or cluster configuration for high availability.
SQS / SNS / EventBridge	None (Self-managed on VMs)	Requires deploying RabbitMQ, NATS, Redis streams, or database-backed job queues on your own compute instances.
AWS IAM	Project Access & API Tokens	Hetzner uses team roles at the project level and read/write API tokens rather than granular per-resource policy documents.

What you must build and operate yourself

The financial savings on Hetzner are real, but they are not free money. A portion of what you stop paying Amazon is traded for engineering ownership. Here is what your team must be prepared to build and maintain.

1. Relational databases and high availability

On AWS RDS, enabling Multi-AZ high availability, automated point-in-time recovery (PITR), and minor version upgrades takes a few clicks. Because Hetzner does not offer managed databases, you must build this resilience on top of Hetzner Cloud VMs or dedicated servers.

In a production environment, you should not simply run a single apt install postgresql instance without safeguards. To match RDS reliability, teams typically deploy a two- or three-node cluster managed by open-source orchestrators like Patroni (with etcd or Consul for consensus), or use automated provisioning stacks. You must also configure continuous Write-Ahead Log (WAL) archiving and daily base backups using tools like pgBackRest or WAL-G, pushing encrypted backups to Hetzner Object Storage (or an external backup destination). Crucially, you must test restoring these backups regularly.

2. Kubernetes or container orchestration

If you run microservices on Amazon EKS or AWS Fargate, moving to Hetzner means taking over the Kubernetes control plane. While EKS manages the API servers and etcd nodes for you, on Hetzner you will run both control-plane nodes and worker nodes on your own virtual machines.

Fortunately, the open-source ecosystem around Hetzner is mature. Many European teams run lightweight distributions like k3s or immutable Kubernetes operating systems like Talos Linux on Hetzner Cloud. Hetzner maintains official open-source integrations that make Kubernetes behave like a native cloud environment:

Hetzner Cloud Controller Manager (HCCM): Automatically provisions Hetzner Load Balancers when you create a Kubernetes Service of type LoadBalancer and configures private network routing between nodes.
Container Storage Interface (CSI) Driver: Automatically creates, attaches, and resizes Hetzner Cloud Volumes when your pods request PersistentVolumeClaims.
Cluster Autoscaler: Adds or removes Hetzner worker VMs based on pending pod resource requests.

Even with these drivers, your team remains responsible for upgrading Kubernetes versions, rotating certificates, and monitoring etcd health.

3. Caching, queues, and background jobs

Many AWS architectures rely heavily on SQS for decoupling services, Lambda for cron jobs and webhooks, and ElastiCache for session storage. When moving to Hetzner, architectural simplification helps a great deal.

Instead of replacing every AWS primitive with a separate distributed system, evaluate whether your existing stack can absorb the workload. For example, if you run PostgreSQL, tools like pg-boss (Node.js), Oban (Elixir), or Solid Queue (Ruby) let you run reliable background jobs directly inside your database, removing the need for a separate SQS replacement. If you need high-throughput message brokering or caching, you will need to provision dedicated VMs running Valkey, Redis, or RabbitMQ via Terraform and Ansible, wired into your monitoring stack.

4. Observability, logging, and alerting

Without AWS CloudWatch collecting logs and metrics by default, you need a self-hosted or third-party observability stack. On Hetzner, teams normally deploy the Prometheus and Grafana stack (alongside node_exporter and Loki for logs) on a dedicated monitoring VM, or ship telemetry to a European-hosted observability service. You will also need to configure alert routing (via Alertmanager or similar) to wake up your on-call engineers if a disk fills up or a database node fails over.

5. Access control and secret management

AWS IAM lets you restrict a specific server to reading a single S3 bucket or writing to one DynamoDB table. Hetzner's Cloud API uses bearer tokens that grant access to an entire project. This means you must be careful about where you place Hetzner API keys (such as inside your Kubernetes cluster for the CSI driver). For application secrets that previously lived in AWS Secrets Manager or SSM Parameter Store, you will need to adopt encrypted secrets in Git (using SOPS or Sealed Secrets), use your CI/CD platform's secret injection, or host a vault service like HashiCorp Vault or OpenBao.

When Hetzner is the right choice (and when to pick another EU cloud)

Hetzner is an exceptional fit if:

Your team has at least one engineer comfortable with Linux administration, Terraform, and Docker or Kubernetes.
You run compute-heavy, memory-heavy, or bandwidth-heavy workloads where AWS costs scale poorly.
Your architecture is relatively clean—such as a monolithic web application or a sensible set of containerized services backed by PostgreSQL, Redis, and S3 object storage.

However, if your company has no dedicated DevOps or platform engineering capacity, and leadership does not want engineers spending time maintaining database replication or Kubernetes upgrades, Hetzner may require too much operational overhead. In that case, you do not have to stay on AWS. Other European cloud providers—such as UpCloud, Scaleway, or OVHcloud—offer managed PostgreSQL/MySQL databases and managed Kubernetes control planes out of the box. You will pay more per CPU core on those platforms than on Hetzner, but still generally less than on AWS, while keeping managed database convenience under European jurisdiction.

Practical migration checklist: AWS to Hetzner

If you decide to move to Hetzner, follow a structured process to keep downtime to a minimum and preserve a clean rollback path.

Audit your AWS footprint and egress: List every active resource across your AWS regions. Identify hidden dependencies like Lambda functions triggered by S3 events, hard-coded IAM role assumptions (sts:AssumeRole), and proprietary databases like DynamoDB. Note that under Article 29 of the EU Data Act, you can request switching terms from AWS where data egress fees are capped at direct cost until January 12, 2027, and eliminated thereafter.
Define your Hetzner architecture in Terraform: Do not click around in the Hetzner Cloud Console to build production. Use the official hcloud Terraform provider to define your private networks, firewalls, load balancers, and compute nodes. Set up automated configuration management (such as Ansible or cloud-init) to bootstrap your database clusters and container hosts.
Clone object storage with checksums: Create your buckets in Hetzner Object Storage. Use an S3 synchronization tool like rclone to copy objects from AWS S3 to Hetzner, verifying file integrity with checksums. Keep periodic syncs running until cutover day.
Establish live database replication: Rather than taking a multi-hour downtime window to dump and restore your database, set up logical replication from AWS RDS to your new PostgreSQL or MySQL cluster on Hetzner. Connect the two environments over an encrypted VPN tunnel (such as WireGuard) so your Hetzner database stays within seconds of your live AWS database.
Update your CI/CD pipelines: Adjust your GitHub Actions or GitLab CI workflows to deploy your application containers to the new Hetzner environment in parallel with AWS. Run end-to-end tests against the Hetzner staging endpoints.
Lower DNS TTLs and execute the switch: A few days before migration, lower your DNS Time-To-Live (TTL) values to 60 seconds. During a planned low-traffic window, put your application into a brief maintenance/read-only mode, verify that database replication lag is zero, run a final S3 sync, promote the Hetzner database to primary, and update your DNS records to point to the Hetzner Load Balancer.
Maintain a rollback option before cleanup: Keep your old AWS environment running and configure reverse replication from Hetzner back to AWS if possible, or maintain snapshots for at least 30 days. Once everything runs smoothly through a full monthly billing cycle, decommission your AWS resources.

Frequently asked questions

Does Hetzner have an equivalent to AWS S3?

Yes. Hetzner offers native, S3-compatible Object Storage. You can interact with it using the standard AWS CLI, SDKs, or Terraform providers by changing the endpoint URL to Hetzner's regional object storage endpoint. It supports standard bucket operations, access keys, and public/private visibility, though it does not include AWS-specific extensions like S3 Glacier archival tiers or EventBridge notifications.

How do we handle high-availability databases on Hetzner without RDS?

Because Hetzner does not sell a managed database service, high availability is achieved by provisioning multiple Hetzner Cloud VMs across different physical availability zones or data center locations, attached to local NVMe disks or Cloud Volumes. You then run an automated failover manager like Patroni for PostgreSQL, combined with automated backup tools (such as pgBackRest) that stream backups continuously to S3-compatible object storage.

Can we mix Hetzner Cloud VMs and Dedicated Servers in the same network?

Yes. Through the Hetzner vSwitch feature, you can connect dedicated bare-metal servers from Hetzner Robot directly into your Hetzner Cloud Private Networks. This allows teams to run stateless web applications on flexible Cloud VMs while placing heavy, predictable database workloads on high-performance bare-metal NVMe servers over private internal IPs.

Will we have to pay huge AWS data egress fees when moving our data to Hetzner?

Data egress fees are shrinking due to European regulation. Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers operating in the EU may only charge the direct cost incurred for switching data egress until January 12, 2027, and from January 12, 2027 onward, all switching charges—including data egress fees when moving to another provider—are banned. Furthermore, AWS offers a specific fee waiver program for customers permanently migrating off the platform under the Data Act framework.

Sources

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.