How DeepL keeps closest-exit routing during maintenance with AWS Cloud WAN

DeepL is a Language AI company that builds written and real-time AI voice translation products used by more than 200,000 business teams worldwide. Its infrastructure spans multiple AWS Regions across Europe, North America and Asia, with hybrid connectivity back to two European data centers.

Taking a single AWS Direct Connect link out of service for planned maintenance is a routine task, but in a multi-Region hybrid network it demands care. DeepL connects its AWS Regions to its data centers through Direct Connect and relies on the default closest-exit egress behavior to keep latency low. For maintenance, the team’s goal was to drain one link while every other Region continued using its local exit.

This post describes how DeepL does this with AWS Cloud WAN and a Direct Connect gateway attached natively to the core network. An AS_PATH prepend on the link being maintained moves only that Region’s traffic to another location, and the other Regions keep their local exit. It also covers the trade-offs, including inter-Region data transfer while a link is drained.

This post is for network architects and cloud platform teams who operate hybrid connectivity at scale, who are evaluating AWS Cloud WAN for global routing, or who are working through Direct Connect traffic engineering across Regions.

DeepL’s hybrid architecture

DeepL runs workloads in multiple AWS Regions, including three in Europe (eu-west-1 in Ireland, eu-central-1 in Frankfurt, and eu-north-1 in Stockholm), two in the United States (us-east-1 and us-west-2), and one in Tokyo (ap-northeast-1). Each Region has multiple virtual private clouds (VPCs) and accounts. On premises, two European data centers connect over a resilient Multiprotocol Label Switching (MPLS) network with dedicated fiber between the sites.

The connectivity design is built for geographic redundancy:

• Three AWS Direct Connect locations (Dublin, Copenhagen, and Stockholm), each with a hosted 25 Gbps connection through AWS Direct Connect Partner Megaport.
• An AWS Cloud WAN core network with a core network edge (CNE) in multiple Regions that connects the VPCs and accounts in that Region.
• One global Direct Connect gateway, linked to all three Direct Connect locations and attached natively to the core network. Native Direct Connect gateway attachments for AWS Cloud WAN have been available since November 2024.
• The same prefixes advertised from the on-premises routers in both data centers, so that the Direct Connect gateway learns them over all three Direct Connect locations (simplified here to a single /16).

The following diagram shows this architecture.

Figure 1: DeepL’s hybrid architecture with AWS Cloud WAN

In steady state, DeepL runs no additional traffic engineering. By default, egress traffic leaves AWS through the Direct Connect location closest to where it originated: traffic from eu-west-1 leaves through Dublin, traffic from eu-central-1 through Copenhagen, and traffic from eu-north-1 through Stockholm. This closest-exit behavior keeps latency low and avoids extra configuration.

Minimize network impact with single-link maintenance

DeepL wanted to take the router at one Direct Connect location out of service for a maintenance window. Traffic had to move off that single link while the other two locations kept serving their Regions as before. This is a common requirement for enterprises running multiple Direct Connect locations.

Where the egress decision is made

Before changing any Border Gateway Protocol (BGP) attribute, it helps to know which component makes the egress decision, because that determines which attributes influence it. With Direct Connect attached to an AWS Cloud WAN core network, path selection happens in two places:

• The Direct Connect gateway.
• Each core network edge.

Path selection on the Direct Connect gateway

For a prefix reachable through multiple Direct Connect locations, the Direct Connect gateway prefers the path with the highest BGP local preference. By default, AWS sets a medium local preference (community 7224:7200) on the Direct Connect locations associated with the Region where the traffic originates, and a lower value on other locations. Local preference is evaluated before AS_PATH. Setting a local preference community on a prefix applies one ranking to every Region the gateway serves, which suits designs that want the same preferred location everywhere.

The important detail is where local preference sits in the BGP best-path order. When a router has more than one route to the same destination, it walks an ordered list of tie-breakers and stops at the first one that produces a winner. On the AWS side, the first few steps are:

1. Longest prefix match.
2. Highest local preference (the closest-exit decision is made here).
3. Shortest AS_PATH.
4. Lowest MED.

Local preference is evaluated before AS_PATH. As the Direct Connect documentation states: “Local preference BGP community tags are evaluated before any AS_PATH attribute.” Because the default local preference already selects the Dublin location for eu-west-1 traffic, a longer AS_PATH on the Dublin path doesn’t change the gateway’s choice. The drain takes effect on the core network edge instead, as the next section shows.

Path selection on the core network edge

Each core network edge receives the on-premises path from the Direct Connect gateway with the AS_PATH preserved. Direct Connect BGP communities are only relevant to the Direct Connect gateway and don’t influence core network routing decisions. Each edge also learns the same prefix from its peer edges across the core network, and each of those paths is one AS hop longer because the peer edge adds its own autonomous system number (ASN). The core network edge evaluates AS_PATH length first, so by default each edge prefers the path through the Direct Connect gateway instead of the path from a peer edge. For the three European Regions in DeepL’s environment, that is the path through the Region’s local Direct Connect location. See Direct Connect gateway attachments in AWS Cloud WAN.

The following diagram shows how the eu-west-1 core network edge selects its exit in steady state.

Figure 2: Path selection on the eu-west-1 core network edge

This gives DeepL a per-Region lever. An on-premises AS_PATH prepend that makes one location’s path longer changes the decision only on the core network edge that uses that location.

Why DeepL doesn’t use local preference for the drain: By default, the Direct Connect gateway gives each Region its own preferred locations: the Direct Connect locations associated with that Region. That default is what gives each Region its closest exit, and it applies only while the prefix carries no local preference community. As soon as you tag a prefix, your ranking replaces the default and applies to every Region at once. DeepL advertises the same /16 from both data centers, so lowering the preference on the Dublin advertisement would change the exit for all Regions, not only eu-west-1. The Regions that aren’t being drained would lose their closest exit. A different ranking per Region would require more-specific prefixes per location, which is the per-link configuration DeepL wanted to avoid.

The maintenance drain in practice

To drain the Dublin link, DeepL prepends its prefixes on the Dublin virtual interface from its on-premises routers. This has two effects:

• With at least two prepends, the path that the eu-west-1 edge receives from the Direct Connect gateway is longer than the paths it learns from the eu-central-1 and eu-north-1 edges. The eu-west-1 edge now prefers a peer path. When two peer edges offer identical routes, AWS Cloud WAN selects one of them. The eu-west-1 traffic then crosses the core network and leaves through either the Copenhagen or the Stockholm Direct Connect location.
• The eu-central-1 and eu-north-1 edges are untouched. Their local path from the Direct Connect gateway is still the shortest, so closest exit is preserved everywhere except in the Region being drained.

The following diagram shows egress during a drain of the Dublin link.

Figure 3: Draining the Dublin Direct Connect link with an on-premises AS_PATH prepend

All BGP sessions stay up during the drain. The prepend makes the Dublin path less preferred, so traffic moves before the link is taken down. Because no routes are withdrawn, DeepL avoids the convergence gap that a route withdrawal causes. Of the three European edges, only the eu-west-1 edge changes its decision.

Draining the Dublin link, step by step

Validate each step in a non-production environment first.

1. Confirm steady state: each Region’s core network edge egresses through its local Direct Connect location.
2. Apply the on-premises AS_PATH prepend (at least two prepends, and DeepL uses five) to DeepL’s prefixes advertised on the Dublin Direct Connect virtual interface, so that the path the eu-west-1 edge receives from the Direct Connect gateway is longer than the paths it learns from its peer edges.
3. Lower the BGP local preference on the Dublin sessions on DeepL’s on-premises routers, so that traffic toward AWS also moves to the Copenhagen and Stockholm Direct Connect locations.
4. Verify that the eu-west-1 edge now selects a path learned from the eu-central-1 or eu-north-1 edge, and confirm that those two edges still egress locally.
5. Confirm that traffic in both directions has shifted off the Dublin link and is stable.
6. Perform the physical or router maintenance on the drained Dublin link.
7. Reverse the change: remove the prepend, restore the local preference on the Dublin sessions, and confirm the eu-west-1 edge returns to its local Dublin path.

Considerations

Plan for the following before you use this pattern:

• Inter-Region data transfer: While the drain is in place, eu-west-1 traffic crosses Regions on the core network. Plan for inter-Region data transfer charges for the duration of the maintenance window.
• Prepend count: Use at least two prepends. A single prepend only ties the path length with the peer paths, and on a tie AWS Cloud WAN prefers the route propagated from the Direct Connect gateway, so the drained location would still be used. DeepL uses five prepends for margin.
• Fallback location: With default path selection, AWS Cloud WAN chooses between equal peer paths, so you don’t control whether Copenhagen or Stockholm takes the displaced traffic. Routing policies, covered in the next section, address this.
• Traffic toward AWS: The prepend only steers traffic leaving AWS. Traffic from the data centers toward AWS is chosen by DeepL’s own routers. During a drain, DeepL lowers BGP local preference on its routers for routes learned over the Dublin sessions, so this traffic also moves off the drained link, and restores it afterward. This setting only affects DeepL’s own routers. It is separate from the Direct Connect local preference communities described earlier, which DeepL doesn’t use. Because the two directions are chosen independently, traffic can leave AWS through one location and return through another. If a stateful firewall sits in the path, traffic must be symmetric, so make sure both directions use the same fallback location.
• Regions without a local Direct Connect location: Check egress for Regions that have no local Direct Connect location, such as the US and Tokyo Regions in DeepL’s case, before and during the drain, and confirm that none of them still uses the drained link.

What’s next for DeepL: AWS Cloud WAN routing policies

The maintenance drain uses the default path selection of AWS Cloud WAN and doesn’t need a routing policy. Going forward, DeepL plans to adopt routing policies.

AWS Cloud WAN routing policies are priority-ordered rules that give explicit control over route propagation and BGP path attributes inside the core network. Two use cases are on DeepL’s roadmap:

• Deterministic maintenance failover: With default path selection, AWS Cloud WAN chooses which remaining location takes the displaced traffic. With a routing policy, DeepL can set an explicit preference, so a drained Region’s traffic lands on a location that DeepL chooses.
• Route filtering and summarization: As DeepL adds locations, a routing policy can summarize routes in the core network instead of DeepL hand-crafting more-specific routes per link. This keeps the number of advertised routes manageable.

Conclusion

For multi-Region enterprises that rely on default closest-exit egress, it helps to identify where the egress decision is made before changing BGP attributes. With Direct Connect attached natively to AWS Cloud WAN, each core network edge makes that decision based on the preserved on-premises AS_PATH. DeepL uses this to drain a single Direct Connect link with an AS_PATH prepend while every other Region keeps its local exit. As a next step, DeepL plans to use AWS Cloud WAN routing policies to choose the fallback location and to summarize routes.

If you operate multi-Region Direct Connect at scale, review Direct Connect gateway attachments in AWS Cloud WAN, Simplify global hybrid connectivity with AWS Cloud WAN and AWS Direct Connect integration, and Direct Connect routing policies and BGP communities, and validate the drain in a test environment before your next maintenance window.

To learn more about AWS Cloud WAN, visit the AWS Cloud WAN product page.

Acknowledgements

We thank the DeepL networking team for partnering on this post and for sharing their architecture and operational experience with the community.

About the authors