The Starting Point: A Single Point of Leverage

The client, a Berlin-based fintech with 85 employees, operated a high-volume payment processing platform serving over 50,000 merchants. Initially, the entire infrastructure was hosted on a single hyperscaler. While this simplified initial deployment, it created a fragile dependency. As transaction volumes grew, the client found itself in a precarious position: escalating costs and limited negotiating power. The architecture was rigid, and every spike in traffic or a change in vendor pricing policy directly impacted the bottom line.

Key Pain Points:

  • Vendor Lock-In: 90% of workloads were tightly coupled to proprietary services, making migration or negotiation difficult.
  • Cost Volatility: A 25% increase in egress fees after traffic spikes eroded margins significantly.
  • Compliance Gaps: Difficulty in isolating data for specific GDPR and BaFin requirements within a single account structure created audit friction.

The Challenges

Before diving into the technical solution, we had to address three concrete operational and strategic hurdles that threatened the feasibility of a multi-cloud approach.

  1. Operational Complexity vs. Team Size: With only 85 employees, including a small DevOps team, managing two distinct cloud ecosystems seemed daunting. The risk of cognitive overload was high. We needed a strategy that reduced, not increased, the cognitive load on engineers.
  2. Data Egress Costs: Moving data between clouds is expensive. A naive migration that moved all data to the secondary cloud would have triggered massive egress fees, negating any savings from compute cost arbitrage.
  3. Compliance Isolation: BaFin regulations required strict data residency controls. The existing single-account structure did not allow for granular isolation of EU data streams, making it hard to prove compliance during audits.

The Approach: Abstraction Before Migration

We executed a phased multi-cloud migration over eight months, focusing on workload portability and cost efficiency. The goal was to create a flexible architecture where no single provider held critical leverage. We did not simply “lift and shift” workloads; we refactored the foundation first.

The strategy relied on three pillars: Kubernetes for compute abstraction, Terraform for infrastructure standardization, and a decoupled data layer.

Projektverlauf in 6 Phasen: Assess workload portability, Deploy EKS on AWS core, Deploy AKS on Azure analytics …

Technical Steps:

  • Workload Assessment: We identified stateless microservices suitable for abstraction. This initial audit took four weeks and involved profiling every service for its dependency on proprietary APIs.
  • Kubernetes Deployment: We implemented EKS (Elastic Kubernetes Service) on AWS for core transaction processing, leveraging its mature ecosystem for payment gateways. Simultaneously, we deployed AKS (Azure Kubernetes Service) on Azure for analytics and development environments, where Azure’s data integration tools offered distinct advantages.
  • Terraform Standardization: We created unified infrastructure-as-code templates to manage both clouds identically. This was the critical enabler. By abstracting the underlying cloud provider, our engineers could write one set of modules that deployed to either AWS or Azure with minimal configuration changes.
  • Data Layer Decoupling: We migrated the primary database to a cloud-agnostic PostgreSQL cluster managed via RDS on AWS. Crucially, we established read-replicas on Azure for disaster recovery. This kept heavy write operations on the primary cloud while allowing the secondary cloud to serve read-heavy analytics queries and act as a failover target.

How We Measured It

To ensure the migration delivered tangible value, we established a baseline before any changes were made. We used cloud cost management tools (AWS Cost Explorer and Azure Cost Management) to track spend by service category. We defined three core KPIs:

  1. Total Monthly Spend: Tracked against the previous 6-month average.
  2. Portability Score: A custom metric we developed, measuring the percentage of critical workloads that could be redeployed to the secondary cloud within 24 hours without code changes.
  3. RTO (Recovery Time Objective): Measured via automated chaos engineering drills, where we simulated a total failure of the primary region and timed the failover to the secondary region.

The Results

The transition resulted in a resilient, cost-optimized environment that significantly reduced dependency on a single vendor. The new architecture allows the client to shift workloads based on real-time pricing and performance metrics.

Key Achievements:

  • Reduced Lock-In: 40% of critical workloads are now easily portable between AWS and Azure. This means that if one provider raises prices or experiences an outage, we can shift significant capacity without downtime.
  • Cost Savings: 18% reduction in total monthly cloud spend through right-sizing and provider competition. By negotiating with both providers and shifting non-critical workloads to the cheaper option at any given time, we created a competitive dynamic.
  • Improved Resilience: Disaster recovery RTO improved from 4 hours to 30 minutes. The automated failover to the Azure read-replica cluster proved its worth during a regional incident in month six.
  • Compliance: Full isolation of EU data streams achieved, simplifying BaFin audits. The separate account structures and data residency policies made it trivial to generate compliance reports.

Cost Efficiency & Resilience Improvement: Vorher-Nachher-Vergleich der Kennzahlen in %

What We Would Do Differently Today

Honesty is part of the process. Looking back at the eight-month journey, there are two areas where we would adjust our approach.

First, we underestimated the initial complexity of the Terraform modules. We started with a “big bang” approach to standardization, trying to cover all services at once. We would now recommend a “crawl, walk, run” approach, starting with the most stateless, low-risk services to build confidence and refine the modules before tackling core transaction processing.

Second, we spent too little time on cross-training in the first month. The DevOps team was split between AWS and Azure experts for the first six weeks, leading to bottlenecks. We would now mandate a joint training week for the entire engineering team on the abstraction layer (Kubernetes/Terraform) before any cloud-specific deep dives, ensuring everyone speaks the same language from day one.

Lessons Learned

Multi-cloud is not just about having two clouds; it is about standardizing the abstraction layer. Without a robust IaC strategy, the complexity of managing two environments outweighs the benefits of reduced lock-in.

Key Takeaways:

  • Abstraction First: Invest in Kubernetes and Terraform before migrating workloads. The abstraction layer is the product, not the cloud.
  • Data Gravity: Keep heavy data processing on the primary cloud and use replicas for DR to minimize egress costs. Do not move data just because you can.
  • Team Skills: Cross-training engineers on both AWS and Azure was critical to avoid siloed expertise. A multi-cloud strategy fails if only one person knows how to manage the secondary cloud.

This case study demonstrates that for a fintech of this size, multi-cloud is not a luxury but a strategic necessity. It transforms the cloud provider from a monopoly into a competitive partner, giving the client the leverage to negotiate better terms and the resilience to survive regional outages.

Passend dazu