Blog

Can a European Cloud Compete with Hyperscalers?

This blog documents my practical exploration of working with Scaleway, a recently announced partner of Conscia, and evaluates whether a European cloud provider can deliver the same core capabilities that originally drove widespread public cloud adoption?

Six years ago, I expected the cloud market to be dominated by three hyperscalers, supported by a small number of regional providers. I did not anticipate that cloud adoption would increasingly raise questions about jurisdiction, governance, and data sovereignty. 

While I still believe that providers like Amazon and Microsoft are strongly incentivized to protect their customers as otherwise would be bad for business, I have concluded that Europe needs viable, EU‑governed alternatives. Cloud choice should not be limited to American or Chinese providers alone. 
Over the years, I have worked with serverless solutions across both AWS and Azure. My first exposure was Azure Functions and Event Grid, where I developed a small service designed to front Azure AD (now Entra ID). The purpose of this service was to enable developers to create identity objects using a less-privileged role, effectively shielding a highly privileged role behind a controlled interface. This allowed developers to provision service principals directly through Azure DevOps (then Visual Studio Online), which at the time was not possible using ARM templates. 

In the years that followed, I have built numerous solutions across both Azure and AWS using a variety of serverless services, including deeper integrations with technologies such as Step Functions, Logic Apps and managed database services. What continues to resonate with me is the ease with which microservices can be delivered and composed, and the significant impact they can have on how organizations build and operate solutions. 

This naturally leads to a broader question: why did we embrace the public cloud in the first place, and what was its original value proposition? For me, the core value has always been speed of innovation and a strong focus on service delivery rather than infrastructure management. The ability to quickly test an idea without worrying about underlying infrastructure, and to evolve it rapidly if it proves viable, is fundamental to me. 

With that in mind, my first reaction when learning about a European cloud provider was to explore whether the same serverless principles could be applied. The technical implementation itself was only part of the story; the more interesting aspect was the journey and how it would feel to develop on a different platform, and what challenges or limitations I would encounter along the way. 

Architecture 

To explore this further, Vibebot (Github Copilot) and I decided to develop a simple API with basic data consistency requirements. To satisfy internal security requirements, the solution needs to be faced with a clear security perimeter. 
 
In a hyperscaler context, the architecture would be straightforward. In AWS, this would typically consist of an API Gateway in front of a Lambda function, with persistence handled by Amazon RDS. In both cases, the solution would be augmented with appropriate identity management and monitoring capabilities.

The entire solution would be deployed and managed using Infrastructure as Code, specifically Terraform, to remain aligned with multicloud thoughts. 

Governance

Based on the intended design, the goal was to develop a single API with a persistent data layer. As with Azure and AWS, however, this first required an understanding of the underlying governance model before any resources could be deployed. 

In Azure, governance is typically structured around tenants, management groups, subscriptions, and resource groups, each serving distinct purposes and security boundaries. Scaleway follows the same overarching principles, but with different terminology and structural concepts. For example, an Azure Subscription roughly maps to a Scaleway Project, while an Azure Tenant aligns with a Scaleway Organization. Concepts such as management groups and resource groups do not exist in Scaleway, meaning that similar governance outcomes must instead be achieved through a combination of IAM and tagging. 

This difference also has practical implications. Features such as Azure Policy, which are commonly used for centralized compliance and guardrails, are not yet available in Scaleway. Additionally, Scaleway enforces a soft limit of 25 projects per organization, which can significantly constrain governance and environmental isolation unless supplemented by additional platform engineering practices. 

After establishing these organizational foundations, I created a project within an existing organization and defined an application scoped specifically to that project. This approach was intended to emulate a basic landing zone model, resulting in a structure consisting of an organization, a project, and an application with write permissions. With this in place, the next logical step was to address access and identity management. 

Access

Over time, the way we interact with cloud environments has evolved significantly. Early approaches relied on basic tooling such as PowerShell modules, with authentication often based on static credentials or even consumer Microsoft Live ID accounts. Today, role-based access control combined with fully featured command-line interfaces has become the standard. 

In both Azure and AWS, programmatic interaction is now largely a matter of installing the appropriate CLI and performing an authenticated login, after which deploying infrastructure is both streamlined and repeatable. This naturally raises the question: how does programmatic access work in Scaleway? 

Scaleway provides a functional CLI similar in capability to those offered by AWS and Azure, making it straightforward to get started. However, authentication is currently based on traditional API keys rather than OAuth or OIDC. While this approach is effective, it is less modern and places greater emphasis on disciplined API key lifecycle management, including clear separation between environments and access scopes. 

Creating API keys is straightforward. With the organizational structure already in place, a dedicated set of API keys can be created under the previously defined application within the IAM configuration. After storing the credentials as local environment variables, the environment was ready for further development and automation. 

Development

Once access was in place, the next step was configuring the Terraform provider. Scaleway provides well‑maintained and up‑to‑date documentation, which made it straightforward to get started with the provider’s configuration and resource definitions. At the time of writing, the provider itself was being updated frequently, indicating an actively developed ecosystem. 

After completing the initial project structure and establishing the foundational Terraform modules with some assistance from Vibebot, I was able to provision the core infrastructure with relatively few issues. From a developer experience perspective, the process felt familiar enough that I rarely had to stop and consider that I was working in a different cloud environment. While there were naturally differences and minor friction points, deploying the service end‑to‑end was largely seamless. 

One notable distinction became apparent during implementation: even when working exclusively with serverless services, Scaleway requires explicit network constructs, including a VPC. This makes the platform more network‑centric compared to Azure’s network‑optional approach for serverless workloads. As a result, the final architecture featured a clearly defined virtual network layer even though the application itself was fully serverless. As a resultthe overall experience felt more like AWS than Azure. 

Despite using serverless primitives, it was still necessary to actively consider networking and infrastructure design to enforce a two‑tier model with a well‑defined security boundary. The primary source of friction was therefore not architectural but semantic service naming. However, these differences are largely superficial, as many of the underlying concepts closely mirror those of AWS and Azure, as illustrated below. 

Scaleway (this project)	AWS	Azure
VPC + Private Network	VPC + Private Subnet	VNet + Subnet
Public Gateway (NAT)	NAT Gateway	NAT Gateway
Instance (VM)	EC2	Virtual Machine
Serverless Function + Namespace	Lambda	Azure Functions (Function App)
Managed PostgreSQL RDB	RDS PostgreSQL	Azure Database for PostgreSQL Flexible Server
Object Storage (state bucket)	S3	Azure Blob Storage
IAM Application + API Key	IAM Role + Policy	Managed Identity
Secret Manager	Secrets Manager	Key Vault

The main capability I missed was native support for seamless OAuth integration at the function layer, like what is available when working with Azure Functions. Achieving this in Scaleway would require federating authentication through an external identity provider such as Entra ID or, in fully self‑hosted scenarios, deploying an alternative identity solution such as Keycloak, depending on the specific requirements. 

Conclusion

• Scaleway demonstrates that a European cloud provider can deliver the core capabilities and developer experience expected from a modern public cloud
• Scaleway’s operating model is familiar to users of other public clouds, making organizational adoption relatively straightforward. Scaleway should not be assessed through a 1:1 service comparison with more mature hyperscalers, but it delivers effectively on the core requirements. 
• If we want credible alternatives, we must actively support the providers that are capable of delivering them  

Conclusion Perspectives 

The service and overall integration experience with Scaleway aligns well with what I would expect from a mature public cloud provider. I have long been wary of relying too heavily on traditional fit‑gap analyses; instead, I believe the more relevant question is whether a platform delivers the capabilities required to meet specific needs. 

From that perspective, it is easy to argue that Scaleway is a “lesser” offering simply because it does not provide hundreds of individual services. However, service count alone is a poor indicator of cloud maturity. As discussed earlier, the value proposition that initially drew many organizations to public cloud was not breadth for its own sake, but speed of innovation and a focus on delivering outcomes rather than managing infrastructure. In these areas, Scaleway performs well. Based on this experience, it delivers on those core values and stands as a credible alternative to the US hyperscale’s. 

It is also worth reflecting on a common industry narrative: that there are no viable alternatives to US-based cloud providers, or that European options are inherently insufficient. While Microsoft and Amazon undoubtedly offer good products, the development of strong European cloud ecosystems depends on adoption as much as availability. Complaining about the lack of alternatives while consistently defaulting to the hyperscale’s is a self‑reinforcing cycle. 

 

Om forfatteren