4004 news

Strategic Hyperscaler Exit: Cost & Sovereignty

A case study on migrating a Danish vacation rental platform from AWS to Hetzner Cloud. The analysis covers an 80% infrastructure cost reduction, the strategic shift from hyperscalers to simple cloud providers, and the operational trade-offs of self-managed databases and infrastructure as code.

Executive Summary

This analysis examines the strategic and operational implications of migrating a high-traffic vacation rental platform from AWS to Hetzner Cloud. The case study highlights a dual motivation for exiting hyperscaler infrastructure: data sovereignty concerns driven by geopolitical tensions and a substantial 80% reduction in infrastructure costs. The migration demonstrates that for established businesses, the "simple cloud" model offers a superior balance of cost efficiency and operational control compared to both hyperscalers and bare metal solutions.

Strategic Shifts

The core strategic insight is the distinction between hyperscalers and simple cloud providers. Hyperscalers like AWS, Azure, and Google Cloud dominate the market with over 63% combined share, offering extensive service catalogs that create significant vendor lock-in. In contrast, simple cloud providers offer a limited set of core services (virtual servers, load balancers, object storage) that cover 99% of typical business needs. This limited scope reduces complexity and egress costs, which are often hidden drivers of hyperscaler expenses. The case study confirms that the price gap between hyperscalers and simple clouds is substantial, while the gap between simple clouds and bare metal is negligible, making simple clouds the optimal middle ground for most enterprises.

Operational Trade-offs

The migration required significant architectural adjustments, particularly regarding database management. Unlike hyperscalers, Hetzner Cloud does not offer managed database services, necessitating self-hosting of Postgres. This shift increased operational complexity, requiring three weeks of engineering effort to configure backups, point-in-time recovery, and performance tuning. However, the team mitigated this by adopting Infrastructure as Code (IaC) using Terraform, which allowed for reproducible environments and reduced manual operational tasks. The team also replaced Redis-based job queues with database-backed queues, leveraging modern Postgres capabilities to eliminate an additional infrastructure dependency.

Actionable Framework

Organizations considering a hyperscaler exit should adopt a phased approach. First, audit current infrastructure to identify services that can be consolidated or removed. Second, refactor the application architecture to align with the target provider's capabilities, ensuring that the source and target environments are as similar as possible before migration. Third, evaluate the true need for advanced features like autoscaling and serverless functions, as these often add cost and complexity without proportional benefit for stable workloads. Finally, plan for a controlled migration window, accepting brief downtime if the engineering cost of zero-downtime migration outweighs the business impact of the outage. This framework enables businesses to achieve significant cost savings while maintaining operational resilience and reducing geopolitical risk.

Key insights

  1. The primary cost savings in cloud migration come from moving from hyperscalers to simple cloud providers, not from moving to bare metal. Simple clouds provide the necessary flexibility and managed services at a fraction of the hyperscaler cost.

    Cost Optimization →

    Impact: Enables significant budget reallocation from infrastructure to product development or marketing, improving overall business margins.

  2. Vendor lock-in is driven by the breadth of service offerings rather than the quality of individual services. Limiting the technology stack to a core set of services reduces dependency on a single provider and increases negotiating leverage.

    Vendor Management →

    Impact: Increases organizational agility and reduces the risk and cost associated with future infrastructure migrations or provider negotiations.

  3. Self-managing databases on simple cloud providers introduces significant operational complexity, including backup strategies, performance tuning, and high-availability setups. This requires dedicated engineering time and expertise that may not be available in smaller teams.

    Operational Complexity →

    Impact: Requires careful resource planning to ensure that the engineering effort invested in database management does not offset the financial savings from the migration.

  4. Infrastructure as Code (IaC) is a critical enabler for successful cloud migrations, allowing for reproducible environments and reducing the risk of configuration drift. It also facilitates the management of multiple environments, such as staging and production.

    Technical Strategy →

    Impact: Improves deployment reliability and reduces the time required for environment setup, accelerating development and testing cycles.

  5. Data sovereignty is an increasingly important factor in infrastructure decisions, driven by geopolitical risks and regulatory pressures. Migrating to non-US providers can mitigate these risks and align with corporate values and customer expectations.

    Risk Management →

    Impact: Enhances brand reputation and customer trust, particularly in markets with strict data protection regulations or heightened geopolitical sensitivity.

Action items

  • Conduct a comprehensive audit of current cloud infrastructure to identify services that can be consolidated, removed, or replaced with simpler alternatives. Focus on reducing the number of distinct services to minimize lock-in.

    Impact: Identifies immediate cost-saving opportunities and simplifies the architecture, making future migrations easier and less risky.

  • Implement Infrastructure as Code (IaC) using tools like Terraform or OpenTofu to manage all infrastructure components. This ensures that environments are reproducible and reduces the risk of manual configuration errors.

    Impact: Improves operational efficiency and reliability, reducing the time and effort required for environment setup and maintenance.

  • Evaluate the true need for advanced features like autoscaling and serverless functions. If these features are not critical for the business, consider simpler alternatives that reduce cost and complexity.

    Impact: Avoids unnecessary expenditure on advanced features that may not provide proportional value, optimizing the infrastructure budget.

  • Plan for a controlled migration window, accepting brief downtime if the engineering cost of zero-downtime migration outweighs the business impact of the outage. Coordinate with stakeholders to ensure that the downtime is scheduled during low-traffic periods.

    Impact: Reduces the engineering effort and risk associated with the migration, ensuring a smoother and more cost-effective transition.

  • Develop a robust backup and disaster recovery strategy for self-managed databases. This includes regular backups, point-in-time recovery capabilities, and high-availability setups to ensure data integrity and availability.

    Impact: Mitigates the operational risks associated with self-managed databases, ensuring that data loss is minimized and recovery times are acceptable.

Quotes

“in dem konkreten Fall von Fayo ist es so, dass wir durch den Umstieg 80% der Infrastrukturkosten eingespart haben”
“der Preisunterschied von allem, was ich weiß und beobachtet haben und was wir auch ausgerechnet haben für den Fall von Fayo, besteht zwischen AWS und also AWS Azure, Google Cloud Cloud Professor und allen anderen quasi”
“wir haben quasi die gesamte ABS-Um-Infrastruktur umgebaut auf AWS und so, dass wir sie so haben, wie wir sie auf Hetzner haben wollen”