High availability and resilience in application hosting
To ensure high performance and reliability for your applications, you can design your infrastructure to be resilient and highly available. Achieving resilience today means designing your cloud infrastructure to withstand failures at every level - from individual servers to entire Availability Zones.
This page walks you through key strategies for deploying across multiple AZs, securing your data with reliable Block Storage snapshots, implementing automated failover with DNS management, and testing recovery procedures.
Scaleway products are available in multiple regions and locations worldwide.
- A region is a separate geographical area (Paris, Amsterdam, Warsaw). Each region contains one or multiple Availability Zones.
- Availability Zones (AZ) are isolated locations in a specific region. Each Availability Zone provides its own services and infrastructure.
Design for AZ redundancy
Regions and AZs allow you to distribute the Scaleway resources that make up your infrastructure across different physical places to enforce protection against localized failures.
Depending on your application’s availability requirements, data sensitivity, and tolerance for downtime or data loss, you might distribute your resources across regions, AZs or both.
When to distribute resources across AZs
We recommend using multiple AZs within the same region when:
- You need high availability and fault tolerance against localized failures such as power outages, network issues or hardware failures.
- Your application must meet uptime SLAs (99.9% or higher, for example).
- You want low-latency data replication and fast failover.
- You’re running production workloads that do not require global reach.
Example use-case: A customer-facing web application hosted on Scaleway Instances, balanced by a Load Balancer, and connected to a highly available PostgreSQL Managed Database, with all components distributed across two Availability Zones for resilience.
When to distribute resources across regions
We recommend using multiple regions when:
- You need protection against regional outages such as natural disasters and extended power or network failures.
- You must comply with data sovereignty laws - if you need to store EU user data in France, for example.
- Your users are geographically dispersed, and you want to reduce latency.
- You require backup and recovery in a physically separate location.
Example use-case: A static website hosted on Scaleway Object Storage in fr-par that replicates the content to a bucket in nl-ams using automated tools, ensuring the site remains deployable even during a regional disruption.
When to distribute resources across both
We recommend setting up resources to be both multi-AZ and multi-region when:
- Your application is business-critical and cannot tolerate extended downtime.
- You need both high availability and disaster recovery.
- You are subject to strict compliance or regulatory requirements.
- You operate a global service requiring low latency and continuous uptime.
Example use-case: A mission-critical SaaS platform running in active-passive mode across two regions, with each region operating in a multi-AZ configuration using Scaleway Instances, Load Balancers, and HA-managed databases, combined with cross-region DNS failover for uninterrupted service.
Use cases
Find below a list of example use cases to help you decide how to design resiliency and high-availability in your infrastructure.
| Use Case | Distribution Strategy |
|---|---|
| Basic production app | Multi-AZ within one region |
| High availability and auto-failover | Multi-AZ with HA services (Managed Databases, Load Balancer) |
| Data protection and compliance | Cross-region backups |
| Global reach and low latency | Multi-region deployment |
| Maximum resilience | Multi-AZ + Multi-region with failover |
Use multi-AZ services
Some Scaleway products inherently support multi-AZ deployments, when configured for high availability.
The table below lists which products offer cross-AZ resilience and under what conditions:
| Product | Multi-AZ Support | Description |
|---|---|---|
| Managed Databases (PostgreSQL, MySQL) | Yes (HA Mode) | Deploys primary and replica nodes across two AZs with automatic failover and synchronous replication. |
| Load Balancer | Yes | Distributes traffic across Instances in multiple AZs. Automatically detects unhealthy instances and reroutes traffic, ensuring resilience during AZ outages. |
| Object Storage | Yes (regional) | Data is stored across multiple AZs within a region. Inherently resilient and durable, with no user configuration required. |
| Managed MongoDB® | Yes (3-node Replica Set) | Requires using the 3-node replica set option includes 1 primary + 2 standby nodes. Provides redundancy and automatic failover. If the primary fails, a standby is promoted. |
Implement resilience best practices
A resilient architecture requires ongoing operational practices to maintain availability over time.
We recommend following these best practices to ensure your applications stay available:
- Automate deployments - use infrastructure-as-code tools, such as Terraform, to consistently deploy across AZs and regions.
- Back up regularly and test restores - Enable automated backups for managed services (Managed Databases, Managed MongoDB®), and regularly test that you can restore from them.
- Replicate critical data across regions - Use scripts or CI/CD pipelines to copy backups, dumps, or static assets using tools like
awscli,rclone, ors3cmd. - Monitor health and performance - Set up alerts for key metrics: instance health, database replication lag, storage capacity, and DNS reachability.
- Test failover procedures - Run regular recovery drills: simulate an AZ outage, restore a database from backup, or trigger DNS failover. Document the results to keep track of what works and what doesn't