“Every company I talk to is either in the cloud, moving to the cloud, or lying about moving to the cloud.” — Kelsey Hightower, former Principal Engineer at Google Cloud
In 2023, a mid-sized Dutch logistics company migrated their entire platform to AWS, following the Silicon Valley playbook to the letter: Kubernetes clusters, microservices, managed databases, the works. Their monthly cloud bill: €12,000.
By 2025, that bill had grown to €78,000/month. Nothing architectural had fundamentally changed — they just added more customers and more data. When they finally hired a cloud cost optimization consultant, the diagnosis was brutal: they were paying for 340% more compute than they actually needed, running three separate Kubernetes clusters where one would suffice, and storing 14TB of logs they never queried.
The €2 million mistake was not that they moved to the cloud. It was that they moved to the cloud without a cloud strategy.
The Three Cloud Fallacies European CTOs Still Believe
Fallacy 1: “Cloud = Cost Savings”
“The cloud is not cheaper. The cloud is more flexible. If you treat it like a cheaper data center, you will pay data center prices without data center predictability.” — Corey Quinn, Cloud Economist and Chief Economist at The Duckbill Group
Cloud infrastructure is consumption-based. If you do not actively optimize consumption, costs grow linearly (or worse, exponentially) with usage. The companies that save money in the cloud are the ones that treat FinOps as a core engineering discipline — not an afterthought.
The industry-wide numbers back this up. Flexera’s 2025 State of the Cloud Report — based on a survey of over 750 global cloud decision-makers — found that organizations waste an average of 27% of their cloud spend, and that the average enterprise overshoots its annual cloud budget by 17%. Neither figure has improved meaningfully over the prior year despite widespread FinOps adoption, because most teams treat cost optimization as a quarterly cleanup exercise rather than a continuous engineering practice built into every deployment.
The real math:
The optimized cloud column requires dedicated FinOps engineering effort: reserved instance planning, right-sizing, spot instance usage for non-critical workloads, and aggressive auto-scaling policies. Without it, you get the middle column — which is more expensive than the servers in your basement.
Fallacy 2: “Multi-Cloud = No Vendor Lock-In”
Multi-cloud is one of the most expensive strategies a mid-sized company can pursue. Running the same workload on both AWS and Azure means:
- Building and maintaining two sets of infrastructure-as-code
- Training engineers on two different cloud providers’ services
- Abstracting away provider-specific optimizations (which defeats the purpose of using managed services)
- Doubling your monitoring, alerting, and incident response complexity
“Multi-cloud is a strategy for companies with 10,000+ engineers and a CTO who reports to the board. For everyone else, it is a way to double your cloud bill while halving your engineering velocity.” — Adrian Cockcroft, former VP Cloud Architecture at AWS and Netflix
The honest recommendation: Pick one primary cloud provider. Use a second provider only for specific services that are genuinely superior (e.g., Google Cloud for BigQuery/AI, AWS for Lambda, Azure for Active Directory integration). Never mirror your entire stack across two providers unless you are a bank or a government.
Fallacy 3: “Serverless is Always Better”
Serverless (AWS Lambda, Azure Functions, Google Cloud Functions) eliminates server management and charges only for execution time. In theory, this is perfect. In practice, it creates two problems that bite at scale:
Cold start latency: For customer-facing APIs that require sub-200ms response times, a cold start penalty of 500ms-2s makes serverless unsuitable without provisioned concurrency — which eliminates most of the cost advantage.
Cost inversion point: Below approximately 1 million requests/month, serverless is cheaper. Above 3-5 million requests/month, a properly sized container running on Fargate or EKS becomes 40-70% cheaper than the equivalent Lambda execution.
Cloud Strategy for European-Specific Requirements
European enterprises face constraints that Silicon Valley startups do not:
Data Sovereignty (GDPR + Schrems II)
Since the Court of Justice of the European Union’s Schrems II ruling (Case C-311/18, decided 16 July 2020), which invalidated the EU-US Privacy Shield framework, transferring personal data of EU residents to US-based infrastructure requires supplementary measures that most companies implement incorrectly. In practice, this means:
- Production databases containing personal data must reside in EU regions (AWS eu-west-1/eu-central-1, Azure West Europe/North Europe, GCP europe-west1)
- Log aggregation systems that capture IP addresses, user IDs, or session data are also subject to GDPR and must be EU-hosted
- AI/ML pipelines that process personal data for training or inference must use EU-based compute — which limits which foundation model APIs you can use
“GDPR is not a compliance checkbox. It is an architectural constraint that must be embedded in your system design from the first sprint.” — Max Schrems, founder of noyb and the person who invalidated Privacy Shield
Digital Operational Resilience Act (DORA)
For financial services companies in the EU, DORA (effective January 2025) requires explicit contracts with cloud providers specifying:
- Exit strategy and data portability guarantees
- Full audit rights over the cloud provider’s security controls
- Incident notification within 4 hours of a critical incident affecting your services
- ICT risk management frameworks for all outsourced technology functions
This means your cloud architecture must be designed for portability from Day 1 — Kubernetes with Helm charts, Terraform for infrastructure, and application code that avoids deep lock-in to provider-specific services.
The Cloud Repatriation Trend: When Moving Workloads Back Makes Sense
The “always move to the cloud” narrative that dominated 2015-2022 has quietly cracked. Flexera’s 2025 State of the Cloud Report found that 21% of enterprise workloads were repatriated from public cloud back to private infrastructure or on-premises in the preceding 12 months — and a Barclays CIO Survey covering late 2024 found that 83% of CIOs planned to move at least some public cloud workloads back to private or on-premises environments, the highest share the survey has recorded since it began tracking the question. The top-cited drivers in that survey were cost (54%), performance (31%), and data sovereignty (27%).
This is not a mass exodus. Global public cloud spend still grew to $723 billion in 2025 (Gartner), and Flexera’s own data shows the “flow in” of new cloud workloads still far exceeds the “flow out” of repatriated ones. What is actually happening is selective repositioning: specific, well-defined workload categories move back on-premises while everything else stays cloud-native. For a European CTO building cloud strategy in 2026, the practical question is not “cloud or not” — it is which workloads belong where.
The decision framework:
The practical takeaway: Repatriation is rarely “leave the cloud.” It is usually a hybrid move — pulling one predictable, high-utilization workload (often GPU-heavy AI training, a data warehouse, or a legacy always-on database) back to owned or colocated infrastructure while everything elastic, customer-facing, and compliance-sensitive stays on AWS, Azure, or GCP. Building for this from Day 1 — Kubernetes and Terraform rather than deep provider-specific services — is what keeps repatriation a deliberate architecture decision instead of a multi-quarter rewrite.
The Right Cloud Architecture for a €5M-€50M European Company
Based on our experience building cloud-native applications for European enterprises, here is the architecture we recommend:
How Manifera Implements Cloud Strategy
At Manifera, cloud architecture is not an afterthought — it is the first decision we make before writing application code.
Our Amsterdam architects design the cloud topology, select the appropriate EU regions for data residency, and define the FinOps guardrails (budget alerts, auto-scaling policies, reserved instance planning). Our Vietnam and Singapore engineering teams implement this architecture using Terraform, Kubernetes, and CI/CD pipelines that enforce compliance checks on every deployment.
The result: European enterprises get cloud architectures that are cost-optimized from Day 1, GDPR-compliant by design, and portable enough to satisfy DORA requirements — without paying Amsterdam consulting rates for every line of Terraform.
FAQs
How much should a European company budget for cloud infrastructure per month? (Scenario: CFO Annual Planning)
For a B2B SaaS application serving 1,000-10,000 users, budget €3,000-€8,000/month for production infrastructure on AWS or Azure. This includes compute (Kubernetes cluster), managed database (RDS/Cloud SQL), caching (Redis), file storage (S3), CDN, monitoring, and log management. Add 30-40% for staging and development environments. The most common mistake is budgeting only for compute and forgetting data transfer costs, which can add €500-€2,000/month for applications with significant API traffic or media serving.
Should we use AWS, Azure, or Google Cloud in 2026? (Scenario: CTO Making a Strategic Platform Decision)
For most European enterprises: AWS if you need the broadest service catalog and largest talent pool of certified engineers; Azure if your organization is deeply invested in Microsoft 365 and Active Directory; Google Cloud if your primary workloads are data analytics, machine learning, or BigQuery-heavy. The decision should not be based on pricing — all three providers are within 10-15% of each other for equivalent workloads. It should be based on which ecosystem your engineering team already knows and which managed services match your technical requirements. Retraining a team from AWS to GCP costs 3-6 months of reduced velocity.
What is FinOps and why does our cloud bill keep growing? (Scenario: VP Engineering Explaining Budget Overrun)
FinOps is the practice of bringing financial accountability to variable cloud spending. Cloud bills grow because cloud pricing is consumption-based, and most engineering teams optimize for development speed rather than cost efficiency. The three most common culprits are: over-provisioned instances (paying for 8 CPU cores when your application uses 2), idle resources (development environments running 24/7 when developers work 8 hours), and data retention without lifecycle policies (storing 24 months of logs when only 30 days are ever queried). A dedicated FinOps engineer or practice typically reduces cloud spend by 30-45% within the first quarter.
How do we ensure GDPR compliance in our cloud architecture? (Scenario: DPO Reviewing Technical Architecture)
Four architectural requirements must be embedded from Day 1. First, all databases and storage services containing personal data must use EU regions — no exceptions, no “temporary” US-region usage for development. Second, encrypt all personal data at rest (AES-256) and in transit (TLS 1.3). Third, implement data retention automation — personal data must be automatically deleted or anonymized when the legal basis for processing expires. Fourth, maintain a data processing inventory that maps every service, database, and third-party API that touches personal data, including the legal basis for each processing activity. At Manifera, our architects produce this inventory as a standard deliverable in the architecture phase.
Can we move from AWS to Azure (or vice versa) later if needed? (Scenario: CTO Planning Long-Term Cloud Strategy)
Yes, but the cost and timeline depend entirely on how your application was built. If you used Terraform for infrastructure, Kubernetes for compute, PostgreSQL for databases, and avoided deep integration with provider-specific services (like AWS Step Functions or Azure Logic Apps), a migration takes 4-8 weeks of engineering effort. If you built on top of DynamoDB, CloudFormation, and Lambda with provider-specific event sources, expect 6-12 months and a near-complete rewrite of your infrastructure layer. The rule of thumb: every provider-specific managed service you adopt saves 2 weeks of development time now and costs 4 weeks of migration time later. Design for portability from the start, even if you never migrate.
Should we be worried about cloud repatriation, or is “cloud-first” still the right default? (Scenario: CTO Reassessing Strategy After Reading Repatriation Headlines)
“Cloud-first” is still the right default for the large majority of workloads — customer-facing applications, anything with unpredictable traffic, and anything you want to ship fast without hiring an infrastructure team. Repatriation headlines (Flexera’s 2025 State of the Cloud Report found 21% of workloads repatriated in the prior year; a Barclays CIO Survey found 83% of CIOs planning to move at least some workloads back) describe a selective, hybrid shift, not a return to on-premises defaults. The pattern that actually shows up in the data: companies keep elastic, customer-facing systems in the cloud and pull specific, predictable, high-utilization workloads — GPU-heavy AI training, data warehouses, always-on legacy databases — back to owned or colocated infrastructure once utilization is consistently high enough that reserved-instance discounts stop moving the needle. Design your architecture to make that an option later (Kubernetes, Terraform, PostgreSQL) rather than a decision you are forced into now.
Suggested Posts
How useful was this post?
Share it with your friends
Get our latest articles here!
Thank you for subscribing to our blog!
Do you have any questions?
Help us improve the content of this Insightful blog by asking us questions. Manifera's team of experts will help you answer these questions as soon as possible.
