de
Scaleway Landingzone

Building a Landing Zone on Scaleway

published at 08-31-2026 by Giacomo Sirri

A successful cloud journey starts with the right foundation. Discover how to build an enterprise-ready landing zone on Scaleway, bringing together security, networking, identity and observability to create a scalable and sovereign cloud environment for your workloads. Explore the architecture behind the solution and learn how platform engineering principles can turn a complex cloud setup into a secure, repeatable, and streamlined experience for application teams.

When you start using a cloud provider in an enterprise scenario, with multiple teams, multiple environments and real data, you quickly find out that the hard part is not picking the right instance type or the correct database. The hard part is the infrastructure underneath: who has access to what, how networks talk to each other, where logs go, how secrets are stored. If you sort these things out before deploying your first application rather than after, you save yourself a lot of future headaches. 

The concept of landing zone is exactly this: a pre-configured and standardized foundation, upon which applications are built. Instead of letting application teams figure out solutions for networking, logging, and access management on their own, platform teams provision a common set of resources that address those needs before any application is deployed. For this reason, defining a landing zone is the recommended first step in any organization's cloud adoption process. 

At Liquid Reply, we design and build multi-cloud enterprise-ready solutions, combining security principles, Infrastructure as Code, and platform engineering practices to create secure, repeatable and operationally manageable environments for application teams. 

In this series of blog posts, we will show how this knowledge can be applied to the creation of a landing zone for Scaleway. Scaleway is a French cloud provider that is increasingly used by European organizations, especially by those that require data sovereignty. 

This post covers the reasoning behind the design, the Scaleway services involved, and a complete architectural view. Later posts will go deeper into the implementation and possible future improvements. 

 

The Four Pillars of a Landing Zone 

The best landing zone design for an organization depends on its requirements and structure, as well as on the services offered by the cloud provider of choice. However, there are some foundational elements that every implementation should include: 

  • Identity & Access Management: who can do what. 
  • Networking: isolated environments connected in a controlled and auditable way. 
  • Management: centralized logging, monitoring, secrets, and state. 
  • Security: least-privilege defaults, encryption at rest, and an audit trail. 

Without these in place from the start, you tend to accumulate what is called the cloud security debt. Each workload added to an unstructured environment makes it harder to understand, audit, and fix when something goes wrong. The upfront investment becomes more worthwhile the more teams and workloads you expect to have. 

 

How the Big Providers Approach It 

The landing zone concept is mature enough that the three largest cloud providers each have opinionated implementations. 

Azure's is part of the Cloud Adoption Framework. The landing zone is actually split in two: a Platform Landing Zone (a centralized subscription that owns shared services like connectivity, identity, and management) and multiple Application Landing Zones, one per workload. On top of the landing zone is a Management Group hierarchy that uses Azure Policy to ensure every child subscription inherits the same security and compliance baselines automatically. Microsoft even provides accelerators (Bicep and Terraform modules) to simplify the deployment of the full reference architecture, complete with Log Analytics, Microsoft Defender for Cloud, and hub-and-spoke VNet peering. 

Google Cloud also refers to the concept of landing zone as Cloud Foundation. While GCP is less opinionated than Azure on how a landing zone should look like, we can still find the usual core elements: a resource hierarchy (Organization → Folder → Project), an identity provider, networking and security controls. Google publishes the Terraform Example Foundation on GitHub, a production-ready implementation you can fork and adapt. 

AWS takes a slightly different approach with Control Tower, a managed service that promises to set up a well-architected, multi-account environment in under 30 minutes, with built-in governance and best practices. 

What all three have in common is the vending machine pattern, where platform teams create pre-configured environments for application teams on demand, without repeating the same setup by hand each time. As demonstrated here, these ideas are not cloud-specific; they are good infrastructure practices that the big providers have documented and packaged into specific products or accelerators. 

 

Platform Engineering Principles 

We can think of a landing zone as a particular type of application platform: an integrated set of tools and services that support the entire lifecycle of applications, from development to deployment and management. 

Therefore, we can apply platform engineering principles to the design process of the landing zone: 

  • Usage of (Scaleway) native services whenever possible 
  • Infrastructure as Code by default 
  • Strict separation of concerns between the platform and the workloads 
  • Security as a first-class citizen 
  • Observability built into the platform 
  • Extensible architecture for customer-specific requirements 

 

The State of Landing Zones on Scaleway 

Scaleway has built quite a broad catalogue over the years: managed Kubernetes (Kapsule), S3-compatible Object Storage, VPC with private networks and a Cockpit observability stack built on Grafana, among others. The Terraform provider is actively maintained and covers most of it. 

What does not yet exist is a first-party landing zone framework. There is no Scaleway equivalent of Azure's Cloud Adoption Framework Accelerator or Google's Terraform Example Foundation. The community organization scaleway-terraform-modules contains some useful standalone modules — Redis, databases, container registries — but nothing that really reproduces the full governance model. 

A landing zone on Scaleway is feasible. After all, the necessary building blocks are already there. Now, we need to put everything together, to make it as simple as possible for you to start your sovereign cloud journey! 

 

What Scaleway Services Do We Need for the Landing Zone? 

The Scaleway landing zone we have designed takes inspiration from Azure's, particularly in the separation between the platform and the application landing zones. 

 

Platform Landing Zone 

The platform is a single Scaleway Project that acts as the control plane for the entire organization. It is deployed once and never deleted. 

Identity & Access Management is the first thing to get right. Scaleway IAM supports users, groups, policies, and IAM applications (a.k.a. service principals). The landing zone creates three groups — PlatformAdmins, NetworkAdmins, and ReadOnly — each with a scoped policy. 

Connectivity is based on a hub-and-spoke topology built on VPC and Private Networks. The Hub VPC consists of four subnets: hub-transit (internet-facing, attached to a Public Gateway), hub-shared-services, hub-management, and hub-vpn. Each spoke VPC connects to the hub through VPC Peering, which keeps all inter-VPC traffic on Scaleway's internal backbone rather than routing it over the public internet. The hub can also have a VPN Gateway for on-premises connectivity. Disaster-recovery VPCs are optionally created in backup regions to achieve high availability. Network ACLs enforce a default-deny policy with an explicit allow list. 

Management covers the operational baseline. Cockpit (Scaleway's managed Grafana stack) provides centralized metrics, logs, and traces across all projects. A Key Manager key handles encryption for sensitive resources. Two versioned Object Storage buckets store Terraform remote state and audit logs respectively. Secret Manager holds sensitive platform secrets such as the Grafana credentials. 

Security is simply handled through an auditor IAM Application scoped to read-only access across the platform project, plus a locked bucket policy on the audit log bucket that prevents deletion. 

 

Application Landing Zone 

Each workload gets its own isolated Scaleway Project. A member of the application team must provide the necessary input (e.g., workload name, region, ...) in the terraform.tfvars file. A CI/CD pipeline takes care of provisioning the following resources: 

  • A new project, for billing isolation. 
  • An IAM group with project-scoped access and a CI/CD application key. 
  • A spoke VPC with one or more Private Networks. 
  • Either a standalone Public Gateway (for internet-connected workloads) or a VPC Peering connection to the platform hub. 
  • A Network ACL inherited from the platform defaults. 
  • A Container Registry namespace. 
  • A Cockpit push token scoped to write metrics and logs into the central Grafana instance. 

The peering link to the hub is established as part of the application landing zone itself, so the spoke is connected as soon as the new infrastructure is created, with no manual intervention required. 

 

What Is Still Missing 

In the landing zone we have defined, some potential services are not included to avoid over-standardization. However, it is possible to extend it if necessary, for example by adding: 

  • DNS: Scaleway's managed DNS service could be added to the hub as a central resolver, giving spoke workloads consistent name resolution without each having to manage their own zone. Scaleway does not yet allow private DNS zones, so each zone would be public, which is nonoptimal for private workloads. 
  • Firewall / Egress inspection: The public gateway provides NAT and internet access. Adding a firewall layer would give the security team visibility into egress traffic from every spoke. 
  • Policy-as-code: A lightweight OPA layer in the CI pipeline could validate Terraform plans against custom rules (e.g., preventing any resource from being created without a cost-center tag) before the apply runs. 

  • Application Landing Zone self-service: The current design requires entries to be manually added to terraform.tfvars. A GitOps workflow where application teams open pull requests against a YAML manifest, and a pipeline provisions the application landing zone automatically, would remove that bottleneck entirely. 

     

Conclusion 

Landing zones are not something you only need on AWS or Azure, but rather a pattern that can be adopted on any mature cloud provider, Scaleway included. Since there is no ready-made reference implementation from Scaleway yet, this post and the following ones in this series show how to design and build one. So, stay tuned... 

And if you want to kickstart your journey on Scaleway, you are welcome to reach out to us at any time!