Prepare the decision: Cloud Exit Check for destination selection. Arrange a consultation.
Moving from AWS to a European cloud starts with which services the destination must provide and who will operate them. A server comparison answers only part of that question. This guide compares destination choices, rather than individual tariffs. As of October 2026. The assessment paths are our recommendations, not benchmarks or a customer test.
Contents
- Inventory services and responsibilities first
- Compare five destinations by operating model
- Resolve AWS dependencies individually
- Specify regions and control requirements
- Assess costs and acceptance before selecting
- Our approach at WZ-IT
- Further guides
Inventory services and responsibilities first
Create an inventory per application: compute, database, object storage, identities, queues, scheduling, DNS and deployment. Assign an owner to each entry. Also record which AWS interface appears in code or infrastructure definitions and which business processes depend on it.
Our recommendation: distinguish required functionality from convenience features. A required database type can be an exclusion criterion; a different administration portal usually is not. Apply the same list to every candidate. Otherwise, you compare a self-administered server with a platform service without accounting for additional operations.
The decision record should also state what may remain on AWS. A partial migration is a separate design with documented data flows, access and incident responsibilities. Leaving AWS does not require changing every application in the same project.
Compare five destinations by operating model
The table lists documented building blocks and assessment tasks derived from them. It is not a ranking. Product coverage is deliberately limited and claims neither completeness nor feature equivalence with AWS.
| Candidate | Documented starting point | Our assessment task before selection |
|---|---|---|
| Hetzner | Cloud servers | Cost server operations, database operations and required additional services separately |
| STACKIT | Managed PostgreSQL Flex | Check database extensions, access and responsibility boundaries |
| IONOS | Managed PostgreSQL | Match database requirements and networking to the target product |
| OVHcloud | Managed Kubernetes | Assess container platform, persistent data and operational scope together |
| Scaleway | Managed PostgreSQL and MySQL | Check database product, access path and application compatibility |
Hetzner is a possible candidate for a server-based path. If the existing design relies heavily on managed databases or a managed container platform, assess corresponding products from the other candidates too. This produces no universal winner: the appropriate mapping comes from your inventory.
A provider can cover several roles. The table does not restrict it to the listed service. For every required function, request the specific product documentation, selected region and current service specification. A product name alone is not an acceptance criterion.
Resolve AWS dependencies individually
Recommended inventory framework:
| AWS reference in the estate | Decision to document | Acceptance point |
|---|---|---|
| EC2 and server images | Rebuild the server or use a suitable image transfer | Boot, drivers, network, application and recovery |
| RDS or Aurora PostgreSQL | Target PostgreSQL and required extensions | Schema, roles, data and application queries |
| S3 | Required API actions, metadata and delivery | Upload, download, permissions and special functions in use |
| Lambda or event processing | Replacement runtime and triggers per function | Retries, failure paths and permissions |
| IAM and other cross-service bindings | New identities and permissions per access path | Permitted and explicitly prohibited access |
S3 compatibility does not establish full feature parity. Hetzner lists unsupported actions including bucket replication and tagging. A design relying on them needs a separate replacement. Supported S3 actions.
Our recommendation for proprietary interfaces: document inputs, outputs, permissions and failure handling first. Then decide on the replacement. A similar product name does not replace this contract between application and infrastructure.
Specify regions and control requirements
Choosing a European provider does not automatically select a German or European location. Hetzner documents cloud locations in Germany and Finland as well as the USA and Singapore. Location overview.
We therefore recommend separate columns for the selected region, backup destinations, administrator access and external connections. Review contracts and privacy requirements for the actual design with the responsible specialists. This comparison awards no blanket compliance or sovereignty certification.
Assess costs and acceptance before selecting
Compare the same items over the same assessment period: resources, storage growth, traffic, licences, operations and recovery. Record migration, parallel operations and any application changes separately. Leave uncertain values open instead of substituting a general savings percentage.
Before commissioning work, define technical acceptance: a representative dataset, application paths, permission checks, backup restoration and a documented return path. This is a planning recommendation, not a claim about completed tests. We recommend cancelling and deleting the source only after acceptance and clarification of retention obligations.
If critical target functionality has not been demonstrated, selection remains open. Further clarification or a bounded partial migration are then more useful outcomes than a predetermined provider recommendation.
Our approach at WZ-IT
The Cloud Exit Check is the entry point for an open decision: inventory, cost analysis, lock-in assessment, target architecture and migration path. AWS-to-Hetzner migration fits when that destination is established. The migration hub lists further migration paths.
Initial enquiry material can include services in use, cost exports, data volumes, desired regions and existing operational responsibilities. The actual service scope is defined before commissioning work. Comparing vendor products here establishes no additional WZ-IT partnership or support commitments.
Further guides
- Compare AWS and Hetzner prices and operations
- Select Hetzner alternatives by requirements
- Distinguish cloud repatriation from switching providers
Assess the destination: The Cloud Exit Check evaluates the estate and migration path. Arrange a consultation.
For Linode, DigitalOcean and other source platforms, the US cloud and European alternatives comparison complements service-level destination selection.
