---
title: "'Multi-AZ architectures for OVHcloud Connect'"
description: "'Understand how Multi-AZ architectures enhance resilience for OVHcloud Connect'"
url: https://docs.ovhcloud.com/pt/guides/network/ovhcloud-connect/multi-az
lang: pt
lastUpdated: 2026-06-16
---
# Multi-AZ architectures for OVHcloud Connect

## Objective

**Multi-AZ (Multiple Availability Zones)** is an architecture strategy where your resources and network connections are distributed across two or more physically separated data centres (Availability Zones) within a region. This protects against the failure of a single site.

## Why Multi-AZ matters for OVHcloud Connect

A single OVHcloud Connect link through a single PoP is a **single point of failure**. If that PoP, the cross-connect, or the physical link experiences an outage, your private connectivity is lost.

Multi-AZ designs address this by establishing **redundant connections through different PoPs or Availability Zones**, so that traffic can automatically reroute if one path fails.

## Architecture overview

![Multi-AZ architecture with redundant OVHcloud Connect links through separate PoPs and Availability Zones](/images/network/ovhcloud-connect/multi-az/image.png)
## How Multi-AZ works with OVHcloud Connect

1. **Order two OVHcloud Connect services** in two **different PoPs**.
2. **Configure BGP on both links** with appropriate route priorities (using BGP attributes like Local Preference, MED, or AS-path prepending) so that traffic prefers one path but can fall back to the other.
3. **Distribute your OVHcloud resources** across multiple Availability Zones within the same region.
4. **Test failover** by simulating a link outage and verifying that traffic switches to the backup path.

## Multi-AZ and BGP configuration

For automatic failover, your BGP configuration must distinguish between the primary and backup paths. Common approaches:

- **Local Preference** — Set a higher Local Preference on routes learned from the primary link.
- **AS-path prepending** — Make the backup path's AS-path longer so it is less preferred.
- **MED (Multi-Exit Discriminator)** — Use MED values to influence inbound routing from OVHcloud.

See [Configure OCC L3 with BGP](/pt/guides/network/ovhcloud-connect/l3-bgp.md) for detailed configuration guidance.

## When to use Multi-AZ

| Scenario                         | Recommendation                          |
| -------------------------------- | --------------------------------------- |
| Test / development workloads     | Single connection is usually sufficient |
| Non-critical production          | Single connection with monitoring       |
| Business-critical production     | **Multi-AZ recommended**                |
| Regulated / compliance workloads | **Multi-AZ required**                   |

## What's next?

- Learn about [SLAs](/pt/guides/network/ovhcloud-connect/slas.md) and how Multi-AZ affects your uptime guarantees.
- See the [AZ configuration guide](/pt/guides/network/ovhcloud-connect/vrack-network-setup.md) to set up subnets across zones.
- Explore [resilient architecture tutorials](/pt/guides/network/ovhcloud-connect/resilient-architecture.md) for step-by-step examples.

## Go further

For training or technical assistance implementing our solutions, contact your sales representative or visit our [Professional Services](https://www.ovhcloud.com/pt/professional-services/) page to request a quote and have your project analyzed by our experts.

Join our [community of users](https://community.ovhcloud.com/).