3-AZ resilience: Mechanisms and reference architectures

This diagram illustrates a three-tier application (web frontend, application backend, and database) deployed across three availability zones (AZ), relying on regional Public Cloud services (Load Balancer, managed database, Floating IP, and Gateway) to ensure high availability and resilience, even in case of an incident impacting one AZ.

1. The Gateway exposes the Load Balancer publicly using a Floating IP.
2. The Load Balancer distributes network traffic across the web instances.
3. The web security group:
   • Accepts only ingress traffic from the Load Balancer’s private IPs on the web port.
   • Allows only egress traffic to the App security group on the App port.
4. The App security group:
   • Accepts only ingress traffic from the web security group on the App port.
   • Allows only egress traffic to the managed database’s private IP and port.
5. The managed database uses an ACL that only permits connections from the private IPs of the App instances.

Normal Operation (Left side):

• The application is deployed across three AZs (a, b, and c).
• All AZs are connected to the same Private Network.
• Web tier: 3 web instances are distributed across the AZs (Web 1 on AZ-a, Web 2 on AZ-b, Web 3 on AZ-c).
• App tier: 3 application instances are distributed across the AZs (App 1 on AZ-a, App 2 on AZ-b, App 3 on AZ-c).
• Data tier: A regional managed database is available across all AZs.
• A regional Load Balancer (with active/passive nodes managed by OVHcloud) distributes traffic between the web instances.
• Security groups restrict traffic between tiers:
  • Web security group allows only connections from the Load Balancer and towards the App tier.
  • App security group allows only connections from the web tier and towards the managed database.
• Connectivity is ensured by a Floating IP and a Gateway. Both services also rely on an OVHcloud-managed active/passive mechanism, so no additional deployment is required.

AZ-a Incident (Right side):

• AZ-a goes down, making Web 1 and App 1 unavailable.
• The Gateway in AZ-a becomes inaccessible, but the passive Gateway in another AZ automatically takes over (resilience managed by OVHcloud).
• The Load Balancer remains available thanks to its active/passive architecture managed by OVHcloud, and continues to distribute traffic across Web 2 and Web 3.
• The Floating IP remains available thanks to its active/passive mechanism, and continues routing requests to healthy instances.
• Application backend instances App 2 (AZ-b) and App 3 (AZ-c) continue to operate and handle requests.
• The regional managed database remains fully available across AZs.
• The application continues to serve users without interruption, though overall capacity is temporarily reduced.

Thanks to the regional services (Load Balancer, Gateway, Floating IP, and managed database), the application remains resilient and available throughout the incident. Once AZ-a is restored, Web 1 and App 1 automatically reintegrate into the system, and the application returns to full high-availability mode.

Recovery:

• Once AZ‑a is restored, its Web 1 and App 1 instances restart and synchronize with the rest of the application. They become active again and resume handling application traffic.
• Regional OVHcloud network services (Gateway, Load Balancer, Floating IP) in AZ‑a are reactivated, but do not return to their original active state. They remain passive, as the AZ where they were previously active continues to hold that role. OVHcloud manages the active/passive mechanism automatically to ensure resilience.
• The managed database continues to accept connections from AZ‑a and synchronizes normally.
• The Load Balancer gradually reintegrates Web 1 into the traffic distribution.
• The application regains full high availability (HA) across all three AZs. However, the active/passive state of the network services may differ from the initial configuration: AZ‑a is active for application instances but passive for network services, while the AZ that was originally active for network services remains active.

This diagram illustrates an application deployed across two availability zones (AZ), relying on a regional Block Storage service to ensure resilience:

Normal Operation (Left side):

• The app is spread over two AZs (a and b).
• The 2 AZs are in the same Private Network.
• Instance 1 runs on AZ-a and Instance 2 on AZ-b.
• An active Load Balancer distributes traffic on the AZ-a, with a passive Load Balancer waiting on the AZ-b.
• The Block Storage service is regional, shared between the AZs and simultaneously attached to both Instance 1 on AZ-a and Instance 2 on AZ-b. For more information, please refer to our guide "Proper Usage and Limitations of Classic Multi-Attach Block Storage in 3AZ Regions".
• Connectivity is provided by a Floating IP and a Gateway (including a second one available in case of failure).

AZ-a Incident (Right Side):

• The AZ-a goes down, making Instance 1 and the active Load Balancer unavailable.
• The AZ-a Gateway becomes inaccessible but a second one in another AZ takes over.
• The passive Load Balancer becomes active to ensure continuity of service.
• The Floating IP can dynamically be switched through Private Network to the AZ-b to allow continuous access to the application.
• Instance 2 (which is located in AZ-b) automatically takes over.
• The app remains available, but the app no longer works in High Availability (HA) mode.

Thanks to dynamic service transfer between availability zones, the application remained active throughout the incident, without interruption to users. Once AZ-a is restored, the application returns to its initial state and becomes high-available again.

This diagram illustrates a 2 AZ deployment architecture with a local Block Storage service.

Normal Operation (Left Side):

• The app is spread over two AZs (a and b).
• The 2 AZs are in the same Private Network.
• Instance 1 runs on AZ-a, and Instance 2 on AZ-b.
• An active Load Balancer distributes traffic on the AZ-a, with a passive Load Balancer waiting on the AZ-b.
• The Block Storage service is local, meaning that each instance has its own volume attached to its AZ and not shared with the other AZ.
• Connectivity is provided by a Floating IP and a Gateway (including a second one available in case of failure).

Incident on AZ-a (Right Side):

• The AZ-a goes down, making Instance 1 and the active Load Balancer unavailable
• The AZ-a Gateway becomes inaccessible but a second one in another AZ takes over.
• The passive Load Balancer becomes active to ensure service continuity.
• The Floating IP can dynamically be switched through Private Network to the AZ-b to allow continuous access to the application.
• Instance 2 (which is located in AZ-b) automatically takes over.
• The app remains available, but the app no longer works in High Availability (HA) mode.
• Since the Block Storage service is local and not regional, data stored on the AZ-a instance can be temporarily or definitely (in case of major outage) lost until the zone is restored.

Thanks to dynamic service transfer between availability zones, the application remained active throughout the incident, without interruption to users. Once AZ-a is restored, the application returns to its initial state and becomes high-available again. A pre-scheduled backup can be useful to recover data and restore Block Storage volumes in case of major outage.