Landing Zone

A landing zone is a set of design guidelines and baseline configurations that give your workloads a secure, governed, and scalable foundation. It reflects practices common on hyperscale platforms, adapted to Exoscale’s simpler and sovereign approach.

A landing zone is a design guide to adapt to your size, compliance requirements, network constraints, and team structure. It takes a few weeks to set up at the start, and far longer to retrofit. Once in place, give it an owner and a backlog: a landing zone left alone gets bypassed.

Who is it for?

• Organizations adopting Exoscale at scale that want a repeatable, consistent way to deploy workloads.
• Teams with compliance or governance requirements that need separation of duties, auditing, and security guardrails.
• Cloud architects and platform engineers building internal platforms and automation pipelines.

Design areas

The questions below cover the decisions behind each area.

Where is your isolation boundary?

On Exoscale, the Organization is the unit of isolation and billing, with its own users, resources, quotas, and invoice. If the question is “can development break production?”, the answer should be a separate Organization, not a label.

Organizations can form a tree up to five levels deep, with billing consolidated at the top. A common layout:

Root              → billing and owners only, no workloads
├── Platform      → shared services: bastion, CI runners, observability, Terraform state
├── Sandbox       → experiments, default quotas, regular cleanup
├── NonProd
│   ├── Dev
│   └── Staging
└── Prod
    ├── Prod-App  → application workloads
    └── Prod-Data → sensitive data and backups

Each environment is a workload landing zone with its own users, roles, and quotas. Start with the first level and add the second only when a real need appears: each Organization adds users, roles, and keys to maintain. Tree organizations are created on request by the support team.

Who can do what, and what is the ceiling?

Exoscale IAM checks every request against two policies: the Organization Policy, which applies to every user and API key, and the policy of the role in use. Both must allow it. The Organization Policy is your guardrail: limit operations to approved zones, or protect audit and backup buckets from deletion.

Policies are CEL expressions evaluated in order. A request that matches no rule is denied, and an invalid expression is silently skipped, so test policies in your pipeline rather than assume them. Create roles from code, the same way in every Organization.

How do people sign in?

Single sign-on connects your OIDC identity provider to Exoscale. At each login, a CEL expression reads the ID token and returns the IAM role to assign, for example based on a groups claim. Your identity provider becomes the source of truth for access, and enforces multi-factor authentication.

SSO is configured separately for each Organization. Offboarding happens in the identity provider: an SSO user removed only on the Exoscale side is recreated at their next login. Keep two break-glass owners as standard users with two-factor authentication.

Is your baseline secure by default?

Security Groups deny all inbound traffic until you add a rule, but allow all outbound traffic until you define an outbound rule, so decide on egress deliberately. Block Storage volumes and new Object Storage buckets are encrypted at rest by default, and KMS lets you manage your own keys, with rotation and replication across zones.

Keep secrets out of code and pipeline definitions. API keys cannot be modified once created: rotate them by creating a new key and deleting the old one. Use one key per purpose, never per person, and restrict automation keys to known source IP ranges.

How do your workloads reach each other?

Private Networks are layer 2 networks confined to a single zone, and Security Group rules do not apply to traffic inside them. Segmentation between internal services is yours to define, with host firewalls or network policies on SKS. Resilience across zones relies on replication and DNS failover. To reach your own infrastructure, use a VPN on instances or a dedicated Private Connect link.

Exoscale is evolving from Private Networks to VPC-based networking, which will bring subnets, routing, and Security Groups for both public and private traffic. Plan addressing as if each Private Network were already a subnet: one non-overlapping block per zone and environment, networks split by tier rather than by application, and no hard-coded IP addresses.

Can you tell what each resource is for, and what it costs?

A naming convention such as <env>-<app>-<tier> and consistent labels (environment, team, cost center) make every resource attributable. Since IAM policies can match on labels, restrict who can change them.

Billing follows the organization tree: the root receives the invoice, and each child Organization sees the usage of its own resources. Usage details are updated every hour and available through the API. Quotas are set per Organization, which also caps what a Sandbox can spend. Model new environments in the pricing calculator before building them.

Is everything reproducible?

Every change to the landing zone goes through code: the Terraform provider for most resources, the AWS provider for Object Storage buckets, and the CLI for scripts. A pipeline with review, a mandatory plan, and a protected apply is the only path to production. Store Terraform state in Object Storage with versioning enabled, and revoke the key used to bootstrap it.

Can you see what is happening, and what happened?

Run observability as a shared service in the Platform organization. DBaaS provides managed Grafana, OpenSearch, and Thanos for dashboards, logs, and long-term metrics. On SKS, enable Kubernetes audit logs.

The Audit Trail keeps 30 days of API activity by default, which rarely meets regulatory needs. Advanced support plans add a daily export to Object Storage: keep it in a bucket that application roles cannot reach.

Can you recover?

Use snapshots for instances, DBaaS backups for databases, and versioning and object lock for backups and audit logs, with replication to another zone where needed. Keep backups in an Organization separate from the workloads they protect, and test restores regularly.

Adapting it to your context

Every landing zone is a starting point, not a one-size-fits-all solution. What shapes yours:

• Regulatory requirements, such as data residency and audit retention
• Scale, from a single team to multiple business units
• Your automation and DevOps toolchain
• Connectivity and hybrid cloud needs
• The security and compliance frameworks in scope

Use this page as a foundation, and adapt it to your internal standards and external requirements.

Going deeper

• Write IAM policies: CEL rules, bindings, and best practices
• Shared Responsibility Model: what Exoscale covers, and what remains yours
• Support plans: advanced plans add detailed usage reports and the long-term Audit Trail export