Hyperscaler

The term describes less a product than an operating philosophy: infrastructure is no longer procured but programmed. For mid-sized companies, this is a real shift, and in both directions. The entry barrier for projects that would once have meant a six-figure hardware investment has practically disappeared. At the same time, new dependencies and cost patterns emerge that you only understand when the third monthly bill arrives. This entry puts both into context.

What makes a hyperscaler technically

Four characteristics separate a hyperscaler from any other provider that rents out servers. They depend on each other: anyone who has only one of them is running classic hosting with a nicer interface.

Elasticity: capacity as an API call

Elasticity means that capacity is created and disappears again without human involvement. An autoscaling group starts additional instances when CPU utilisation exceeds a threshold and shuts them down when the load drops. For an online shop with campaign peaks, this means: Black Friday capacity is booked for four days instead of twelve months. The decisive point is not speed but direction: scaling down also works automatically, and that is exactly where classic set-ups fail.

Regions and availability zones

Hyperscalers organise their infrastructure into regions (geographical areas such as Frankfurt or Ireland), each consisting of several availability zones. An availability zone is one or more physically separate data centres with their own power, cooling and network connections, but connected within the region by very low-latency links. This makes it possible to distribute an application in such a way that the failure of an entire data centre does not mean a failure of the service, without operating two sites yourself.

For mid-sized companies, the choice of region is at the same time a legal decision. Anyone who stores customer data in an EU region has not thereby answered the data protection question conclusively, but has settled a significant part of it. Which part remains open is set out further below.

Managed services instead of self-operation

The second major difference lies above the virtual machine. Hyperscalers offer managed databases, message queues, object storage, container orchestration, search indexes, data warehouses and model endpoints for machine learning as ready-made building blocks. Patches, backups, failover and scaling are the provider's responsibility. Anyone building a microservices architecture saves most of the operating effort this way, and at the same time ties themselves to the interfaces of precisely this provider.

The billing model

Billing is per second or per hour according to actual use, usually broken down by computing time, storage volume, number of requests and volume of data transferred. There is no basic fee and no notice period. This is the greatest advantage and the greatest trap at the same time: a resource that nobody needs any more continues to cost money until someone actively deletes it. Discount models such as reserved instances or savings plans lower the price considerably, but in return trade flexibility for a one- or three-year commitment.

Hyperscalers, hosting providers, managed service providers and European providers

The terms are often mixed up in sales conversations. The differences are operationally relevant, however, because they determine who is responsible when something fails at three o'clock in the morning.

Where the difference really shows in everyday life

A hyperscaler sells you capabilities, not results. The shared responsibility model provides that the provider is responsible for security of the cloud (hardware, network, hypervisor, physical access control) and you for security in the cloud: configuration, identities, encryption, patches to your applications. An openly configured object storage bucket is not the provider's problem. This is exactly where cloud projects at mid-sized companies fail most often, because nobody internally takes on the role previously covered by the IT service provider contract. A managed service provider closes exactly this gap and is therefore not competition for the hyperscaler but in many cases its complement.

The market: the big three, Alibaba, Oracle and the neoclouds

Who is how big

For the second quarter of 2026, Synergy Research Group puts global spending on cloud infrastructure services at 143 billion US dollars, an increase of 43 per cent on the same quarter of the previous year and the highest growth rate in eight years. According to Synergy's analysis of 30 July 2026, global market shares were 28 per cent for Amazon, 20 per cent for Microsoft and 15 per cent for Google. In the narrower public cloud segment, these three providers together account for 67 per cent of the market. Synergy names generative AI as the main driver of the accelerated growth; AI-specific cloud services grew by 165 per cent year on year in the quarter.

Two things about this matter for your own choice of provider. First, the shares are shifting slowly: in a Synergy analysis from November 2025, the big three together held 63 per cent; Amazon's share has been gradually eroding for years while Microsoft and Google catch up. Second, these are global figures. For Europe, Synergy notes that the United Kingdom and Germany are the largest cloud markets, but the distribution of shares within a single country does not necessarily reflect the global distribution.

Alibaba, Oracle and the second tier

The gap between the top three and everyone else is considerable. In November 2025, Synergy chief analyst John Dinsdale put it this way: the third-placed provider, Google, is almost four times the size of the fourth-placed provider, Alibaba. Alibaba Cloud is therefore globally relevant but has its weight clearly in Asia; for a German mid-sized company project, the provider plays practically no role.

Oracle is the more interesting special case. In the second quarter of 2026, Synergy lists Oracle among the second-tier providers with the highest growth rates, together with specialised AI infrastructure providers such as CoreWeave, Crusoe, Nebius and Nscale, which now occupy nine places in the top 40. These so-called neoclouds are not hyperscalers in the sense described here: they offer a great deal of GPU capacity but no broad catalogue of platform services. Anyone buying AI training should know them. Anyone who wants to run a business application need not.

The cost traps that most often hit mid-sized companies

Egress fees

Transferring data into the cloud is free of charge with all the major providers. Getting data out again is not. These egress fees are charged per gigabyte transferred and are regularly underestimated because they do not appear in the project calculation, which counts computing power and storage, not traffic. Applications that deliver large files are particularly affected: media libraries, software downloads, image servers without an upstream CDN, backup restores and analytics pipelines that pull raw data from the cloud into a local data warehouse.

Unused and oversized resources

The second source of costs is less spectacular and usually larger. Because creating resources requires no approval, a sediment builds up over the months that nobody can attribute any more. Typical items:

• Test and staging environments that run through the night and at weekends, although they are only needed on working days
• Unattached storage volumes from virtual machines deleted long ago
• Reserved IP addresses and load balancers from completed projects
• Instances sized on the basis of an estimated peak load that never materialised
• Snapshots and backups without a retention rule that have been piling up for years
• Log data in expensive analytics services for which nobody has set a deletion period

The most effective countermeasure is not technology but accounting: a mandatory tagging policy that assigns every resource to a project, a cost centre and a person responsible, plus a monthly cost report sent to those responsible. Anyone who only introduces this after two years spends weeks on archaeology.

Vendor lock-in, digital sovereignty and the EU Data Act

The more managed services a project uses, the greater the benefit and the greater the lock-in. Anyone who bases an application on proprietary databases, provider-specific function services and an in-house identity management system has built an architecture that cannot be ported, only rewritten. That is not wrong per se, but it is a decision and should be recorded as such. The mechanics and countermeasures are described in detail in the entry on vendor lock-in; incidentally, the same question arises with every SaaS product.

What the EU Data Act changes from 12 January 2027

The EU Data Act intervenes precisely here. The regulation was published in the Official Journal on 22 December 2023 and has applied since 12 September 2025. Its Chapter VI governs switching between data processing services and obliges cloud and edge providers, among other things, to remove obstacles to switching, comply with minimum requirements for cloud contracts and provide open interfaces. Providers of platform as a service and software as a service must make data exportable in at least one common, machine-readable format; providers of infrastructure as a service must ensure "functional equivalence", i.e. that a customer switching to a service of the same type obtains materially comparable results with the same input.

When it comes to money, a separate deadline applies that is often reported incorrectly. According to the European Commission's explanation of the Data Act, switching charges, including egress fees, will be abolished completely from 12 January 2027. For the transitional period of three years after entry into force, i.e. from 11 January 2024 to 12 January 2027, providers may continue to charge the costs they actually incur for switching and data extraction. The widespread claim that there have been no switching fees since September 2025 is wrong: the general obligations of the regulation have applied since 12 September 2025, but the complete ban on charges only comes in 2027.

Real-world example: AWS and free data transfer out

How this works in practice can be traced at Amazon Web Services. On 5 March 2024, AWS announced that it would waive the fees for data transfer out to the internet when a customer leaves AWS, expressly, as the AWS announcement states, in the direction set by the European Data Act, and worldwide for all customers from every region. In the same post, AWS points out that more than 90 per cent of customers incur no data transfer out costs anyway, because 100 gigabytes per month of transfer from AWS regions to the internet are free.

The details are more revealing than the headline. The waiver does not happen automatically: you have to contact AWS Support, the request is reviewed at AWS account level and the refund is issued as a credit. In an update of 30 September 2025, AWS added that eligible customers have 90 days to switch and must inform Support if they need longer; for EU customers switching under the Data Act, AWS refers to a separate Data Act addendum. Switching therefore remains a project with an application, a deadline and an obligation to provide evidence; the fee is just one of several cost factors.

EU data boundary and sovereign cloud offerings

Digital sovereignty is the second dimension that increasingly determines the choice of provider at mid-sized companies, driven less by technology than by compliance requirements from tenders, corporate customers and their own supervisory board. All three major providers have responded with EU-specific offerings marketed under names such as "sovereign cloud" or "EU data boundary", which promise to keep data, and in some cases also operations and support, within the EU. These offerings differ considerably in scope; what matters is not the label but what the specific contract says about data storage, operating staff, key management and access routes.

The Data Act addresses the question in Chapter VII: non-personal data stored in the EU is to be protected against unlawful access by authorities from third countries. The regulation does not prohibit cross-border data flows but sets out conditions and safeguards for such access requests and obliges providers to take appropriate protective measures such as encryption and audits. The tension with the US CLOUD Act is thus regulated but not resolved, which is why, for particularly sensitive data sets, the question remains which legal system the provider's parent company is subject to.

When a hyperscaler fits, and when it does not

Good reasons for a hyperscaler

A hyperscaler is the right choice when the load curve fluctuates heavily and peaks are a multiple of the base load, when a product is to grow quickly and nobody knows how quickly, when several countries or continents have to be served with low latency, when AI or data services are needed whose self-operation would not pay off, or when resilience across several data centres is required without wanting to maintain two sites yourself. In these cases, the premium compared with a hosting provider is well spent, because you are buying options.

Good reasons for a European provider or managed hosting

Conversely, a lot speaks against a hyperscaler when the load is predictable and largely constant: a shop with stable revenue and two campaign peaks a year runs reliably and considerably more cheaply on rented servers. The same applies if outbound data traffic is high, because included traffic at European providers keeps the bill predictable. And if there is no team in the company that is permanently responsible for cloud configuration and cost control, a managed service provider with a clear SLA is usually the more honest solution than a hyperscaler account that nobody maintains after the project hand-over. Strict sovereignty requirements from a tender can also pre-empt the decision.

The pragmatic middle way

In practice, the decision is rarely binary. A common and usually sensible split is for the predictable core (application servers, database, object storage) to run where it is cheap and legally uncomplicated, while elastic or specialised parts sit with the hyperscaler: image processing, search index, AI inference, seasonal additional capacity. It is important to deliberately keep the interfaces between the parts open and to anchor data sovereignty in one place. How to make this cut in concrete terms and which questions must be answered before migration is covered in our decision guide to cloud migration and modern software architecture.

The most useful question before choosing a provider is not "Who is the best?" but "What will it cost us to leave in three years?". Anyone who can roughly quantify this figure has the architectural decision under control, regardless of which provider it ends up being.