Scaleway Cloud
The Scaleway Cloud is a French cloud provider with multiple regions in Europe. They offer a wide range of services and are a strong candidate for teams considering migrating from AWS.
As usual we will look at Scaleway Cloud’s offer from two perspectives. Developer Experience and Service Offering.
Developer Experience
As usual, there are multiple ways to interact with Scaleway Cloud’s services. We will focus on the primary ones used by Developers and Solutions Architects.
Scaleway Web Console
Like most providers, Scaleway offers a Web Console where you can explore the service offering and also manage (create, update, delete) your resources. It is well structured and everything is where you would intuitively expect it.
During the evaluation, we did barely use the Web Console to actively manage resources, as our goal is to define infrastructure as code. Hence the other available options suited our use-case more.
Scaleway uses a simple pay-as-you-go model, billing resources by time with no hidden costs, plus optional Savings Plans that give up to 25% discounts for predictable workloads. Unlike AWS, which offers a complex mix of On-Demand, Reserved Instances, Savings Plans, and Spot Instances, Scaleway keeps pricing transparent and easy to forecast. Scaleway also includes 75 GB of free egress traffic per month, while AWS charges for all outbound traffic. Overall, Scaleway’s model favors simplicity and smaller-scale flexibility, whereas AWS provides more options for optimization at enterprise scale.
On Scaleway’s general Website you can find prices for individual services, but there is no dedicated pricing calculator available. Once logged in, whenever you create a resource, the Console allows you to adjust usage parameters and get an indication of the upcoming costs. However a central Pricing Calculator, where one can see all future infrastructure cost in one central place, is desirable.
Overall, the Web Console provides a smooth user experience and serves its purpose well.
Scaleway CLI
Scaleway uses its own proprietary CLI, which is open source and can be installed on any client system. It supports interactive cloud authentication and makes working with their APIs very convenient.
Its interface is easy to understand and the CLI suggestions work effortlessly. Even switching between different projects frequently is no challenge.
Since we prefer a declarative approach, we opted for a third way for creating and updating resources. But even so, the CLI proved invaluable for exploring available resources, retrieving states, and listing configuration options.
Notably, Scaleway also offers a Docker Image, which comes with the CLI preinstalled on a minimal Linux base. By merely setting environment variables, you can use this image to easily setup automations like backups. A possible use case is to run a Cron Job (Kubernetes, Github Actions etc.) to download all available cloud backups to replicate them locally.
Terraform / OpenTofu Provider
The Terraform Provider was the primary tool for managing resources. As described for OTC in Part 2, there is not too much to say about this one. It just works!
The combination of the CLI to gather possible instance classes (or similar parameters) and default values with the good documentation of the Terraform Provider make it a breeze to get a working infrastructure up and running.
Technical Documentation
Scaleway Cloud provides extensive Service Documentation covering all available services, along with detailed API references and parameter descriptions.
During our evaluation, the most valuable resources were the technical guides (called How Tos) like „How to send metrics and logs to your Cockpit“. These guides added significant value by providing practical, hands-on instructions.
For exploring services and their parameters, the Scaleway CLI is the most effective tool. It offers developers a quick and convenient way to access the information they need, making it an excellent complement to the written documentation.
Feature and Service Overview
As we have already seen in Part 1 of this series, Scaleway Cloud checks many of the available boxes. The main gaps we identified are the lack of a Managed Kafka Solution and Network Peering. Additionally NACLs for VPCs are in Public Beta (not accessible using the UI, but only the CLI & API) and a managed S2S VPN is only in Private Beta currently.
Managed Kafka is useful for certain workloads, however it is not critical the majority of projects. One should keep this in mind, when selecting a cloud provider, but for many potential customers this isn’t a dealbreaker argument.
The missing VPC Peering Feature is in my opinion more relevant. For green-field projects starting fresh, it may not be a major problem. However for evolving projects with existing infrastructure this can become an important capability. Since many providers offer a feature like this, it seems possible that Scaleway will come up with a feature like this as well in the future, but as of writing this, they do not offer VPC Peering.
As of the remaining features, we focused on:
Project and Account Structure
The management structure of a Scaleway Account starts with the organization as the top level aspect. Within an organization, there can be multiple projects. Every project serves as an isolated space and has its own dedicated resources, making it possible to separate different environments (like dev and prod) or different applications. All projects share common settings like IAM, billing and organizational settings.
There is also a universal tagging concept, that can be used to structure components.
Currently there is no concept similar to Service Control Policies in AWS, that allows you to restrict the services or components a tenant can use. This needs to be handled using IAM policies.
Network
Networks in Scaleway Cloud have a familiar structure and naming to other cloud providers. At the top level, there is a Region-spanning VPC, that can be divided into Subnets called Private Networks, which are still regional and are not restricted to a single availability zone (AZ).
As the name implies, these networks are private by default, which means they are not internet-routable and also cannot directly access the internet. In order to gain internet access a Public Gateway must be created, which is attached to the Private Network via a Gateway Network and is assigned a public IP address to be routable. Public Gateways can route to all AZs within their region, but they themselves are not highly available by default. To achieve High Availability, you must manually deploy multiple Public Gateways in different AZs and advertise both as routes to the public Internet in the Private Network.
Some resources, like Load Balancers and Public Gateways need specific IP addresses assigned to be routable from the internet. Conversely, this does not apply to all resources though, as e.g. the Kubernetes Control Plane, is by default always routable from a specific URL.
The security concept also resembles what you might know from other clouds, with a few noticeable differences. There are instance security groups, which are stateful firewalls attached directly to the instances. These are not available for all types of resources. For example the Relational Database Service does not offer this feature as of now. Additionally there is the concept of VPC ACLs, which is as described earlier in public beta right now and offers the stateless firewall solution at the network border.
If you want to connect your corporate data center to Scaleway, there will be the feature to setup a managed S2S VPN, which is at the time of writing in private beta or to establish a physical data center connection using Scaleway Interlink, which is in public beta at the moment. Both allow access to private resources. As they are in beta now, these solutions were not tested. There is currently no concept similar to VPC Endpoints in Scaleway.
Identity and Access Management – IAM
Identity and Access Management in Scaleway allows you to assign permissions to users at different levels:
- Organization Wide (incl. Management, IAM & Billing)
- For all Current and Future Projects
- Individual Projects
A user can be assigned to multiple groups and get the permissions assigned to those groups. Policies may also be attached to users directly. For programmatic access, credentials in the form of ACCESS_KEY and SECRET_ACCESS_KEY are created, which are always bound to a specific project.
For automation and technical tasks, there is the concept of Scaleway IAM Application, which allows to directly create ACCESS_KEY and SECRET_ACCESS_KEY and binding permissions to them without attaching it to an IAM user.
Policies are attached to Users, Groups or IAM Applications and allow to distribute permissions for different services. For some services, such as Object Storage the permissions are highly granular, allowing to set permissions even to individual actions like creating or deleting objects in a bucket.
Unfortunately, this does not apply for all services. For Example the Relational Database Service offers only coarse-grained permissions: No Access, ReadOnlyAccess or FullAccess without the possibility to restrict to specific databases or patterns.
Another example makes the problem a bit more tangible:
Database Backups are a component within the Relational Database Service. In order to create a backup one needs to be able to Write the Backup within the service. This implies, neither No Access nor ReadOnlyAccess is sufficient to perform this action. Thus if you want to build an automation, that periodically creates database backups, the credentials attached to this automation need to have FullAccess to the Relational Database Service, which by definition includes FullAccess to all Databases.
The main issue with overly broad IAM permissions arises, if an account or token is compromised, since the attacker inherits all rights associated with the original entity. In this example, the attacker could gain administrative rights to all databases thus the ability to change or even delete them.
As of writing this post, there is no concept like IAM Roles in AWS and there is no possibility to integrate to an external Identity Provider like SAML or OpenID Connect.
Overall, Scaleway IAM provides a solid foundation for managing permissions and enables a wide range of workflows. Still, expanding fine-grained control across all services and adding external identity integration would make it more powerful and flexible.
Kapsule – Managed Kubernetes
Managed Kubernetes Instances are provisioned using Kapsule. By default the control plane itself is internet-routable and for every node pool you may decide, whether the nodes receive a public IP. It is not possible to create fully isolated node pools though. The attached network must always have a Public Gateway attached and thus have internet access.
Kapsule Clusters come in different configurations, ranging from a free non-HA solution, supporting up to 150 nodes, to a HA version with dedicated 16GB RAM and supports up to 500 nodes. HA solutions require a buy-commitment of 30 days.
Multiple node pools can be assigned to the cluster, each being in a single AZ. Multi-AZ environments can, as usual, be created by adding more node pools to the cluster. Every node pool has a fixed instance size and operating system and they support auto scaling.
Load Balancer
Scaleway Cloud offers Managed Load Balancers in various sizes depending on the bandwidth requirements and whether you want to connect multiple cloud environments to a single load balancer.
Load Balancers are always deployed in a redundant configuration, that allows automatic failover in case of an outage. This redundancy is zone-bound. This means, the primary load balancer, as well as the backup are deployed within the same AZ. In order to reach zone-redundancy you need to consider an own solution including e.g. a DNS failover mechanism.
Load Balancers can serve both internal and external traffic. In order for them to serve external traffic, a public IP needs to be attached. This is similar to OTC but very different to many other cloud providers that only provide a static DNS Name for HTTP load balancers. Note that Scaleway charges for stable public IPv4, while a public IPv6 can be provisioned for free.
In our evaluation, the load balancer was specifically tested and used in combination with the Kapsule Kubernetes Cluster serving as the cluster’s ingress. You specifically cannot create the Load Balancer using the Scaleway Interfaces (Web Console, API, CLI), but the Load Balancer must be automatically created by posting a Service of Type LoadBalancer to the Kubernetes Cluster (this only applies if you want to use the Load Balancer as a Kubernetes Ingress). Annotations on the resource decide what exact configuration of the Load Balancer will be provisioned. Conversely, if you want to attach a specific IP address to the Load Balancer, it must be pre-created in the Scaleway Environment. As mentioned in previous parts, personally I prefer having the load balancer definition with my infrastructure and solely referencing it in the cluster, due to the before-mentioned reasons of having all infrastructure defined in a single place and not binding the Load Balancer’s lifetime to that of the cluster. This comes down to personal preference and this is a perfectly viable solution.
Object Storage
Scaleway Cloud offers a fully managed S3-compatible Object Storage service. It supports many of the known AWS S3 Features.
Buckets may be public or private. Public buckets allow listing of objects via s3 ls command without authentication, while individual objects can also be set as public or private.
You can choose between three different storage classes, STANDARD, One-Zone IA and Glacier.
STANDARD serves the default regularly accessed storage and is the default.
One-Zone IA may be used for infrequently accessed data, that can be restored in case of a disaster, because, as the name suggests, it is not zone redundant.
Glacier is for long term backup being durable, but expensive for access.
Data can be transitioned between these classes manually or by a lifecycle configuration.
There are many additional features. Public Buckets may serve static websites. Buckets provide Object Versioning and there are metrics out of the box. Bucket ACLs and Bucket Policies, are resource policies that regulate access to the bucket and its objects. Buckets can be placed behind Edge Services, which is Scaleway’s CDN solution to serve static traffic closer to users. Object lock can be placed to provide a WORM (Write Once Read Many) model, and there is retention policies to guarantee a specific lifetime of objects to fulfill e.g. legal requirements.
The only two things missing in regard to the often-used Amazon S3 features are Cross-Region Replication and a notification service, when an object interaction has taken place.
Managed Messaging and Notifications
One of the unique selling points for Scaleway is their Managed Messaging Solutions. Particularly valuable for teams migrating from AWS, Scaleway offers a SQS-compatible solution. This solution provides an SQS-compatible API, including the possibility to create SQS-Standard and SQS-FIFO queues, as well as features like Visibility Timeout, Message Retention, Content-Based Deduplication and automatic dead-lettering.
If you want to migrate your AWS environment to a European Provider and are currently relying on SQS and the before-mentioned features, Scaleway is the preferable solution, because it offers a smooth migration path without sacrificing or changing core functionality.
Beyond migration, having a fully managed messaging service also reduces operational overhead and the risk of misconfiguration.
For those who prefer not to depend on a proprietary API, Scaleway additionally offers a managed NATS service. NATS is a high-performance, lightweight messaging system that is widely supported across many programming languages and frameworks, making it a flexible choice for cloud-native workloads.
To complement the SQS-compatible messaging, there is also an Amazon SNS-compatible solution called Topics & Events that allows you do notification and message fan-out. Since SQS is very often used in combination with SNS, this provides a complete solution to transition your environment from AWS to Scaleway.
Databases
Scaleway Cloud offers several types of databases including SQL, NoSQL, Caching and completely serverless solutions.
This section focuses on the Managed Relational Database Instances, specifically PostgreSQL instances.
All databases support native Disk Encryption and they are, by default only accessible from within a Private Network (public access is available if required). In-Transit Encryption using SSL is possible with a Scaleway-provided certificate. One limitation is that, at the time of writing, Security Groups cannot be attached to Database Instances.
Scaleway supports managed database instances for PostgreSQL and MySQL with recent versions. Instances can either be created as single-node setups for development or non-critical workloads or in a HA Primary / Standby fashion. Additionally you can provision Read Replicas, which serve readonly traffic for very read-intensive applications.
Backups for Database Instances can be created as full database backups, called Snapshots, which are backups of the whole instance. There is currently no native concept of incremental backups or PITR (Point in Time Recovery). It is also possible to backup single logical databases. This is a manual process, but can easily be automated and there is a great Guide provided by Scaleway how to set this up.
Container Registry
Container Images can be stored in your own private OCI-compliant registry.
As of writing this, there is no automatic vulnerability scanning in Scaleway.
Conclusion
Scaleway offers a broad spectrum of services. The deployed architectures worked flawlessly and working with Scaleway and their developer tools was a very pleasant experience.
Infrastructure as Code with OpenTofu integrates seamlessly, and the combination of the powerful CLI and the intuitive Web Console provides both visibility into deployed resources and guidance on what can be provisioned next.
While it is a bit unfortunate, that the IAM concept is not on par with some other cloud providers like AWS and Azure, the breadth of services and their quality compensate for this limitation. The developer and customer experience are already at a strong level.
There are virtually no restrictions on which architectures can be brought to Scaleway Cloud. In particular the AWS-compliance of S3, SQS and SNS might make Scaleway the number one choice for migrations from AWS. And even if you do not rely on any of these AWS services, Scaleway Service Offering is great and will provide you with everything you need to create a great cloud product.
Special Note to the Quality of the Documentation’s How Tos for every service. They are great for technical topics and I enjoy to have documentation provided „by techies for techies“.
