Maintaining Zero‑Loss Closest‑Exit Routing with AWS Cloud WAN: DeepL’s Blueprint

Introduction

When a global SaaS provider needs to take a single Direct Connect (DX) circuit offline for planned maintenance, the naïve expectation is a brief spike in latency, packet loss, or a temporary cross‑region traffic detour. DeepL, the AI‑driven translation leader, proved that this assumption is outdated. By marrying AWS Cloud WAN with a carefully crafted BGP AS_PATH prepend on its on‑premises edge, DeepL kept the closest‑exit routing invariant across all its AWS Regions while gracefully draining the affected DX link.

This editorial unpacks the underlying architecture, highlights the pitfalls most engineering teams fall into, provides a concrete Terraform blueprint, and projects how the industry will evolve over the next 18‑36 months.

1. Deep Architectural Breakdown

1.1. The Global Fabric: AWS Cloud WAN

AWS Cloud WAN is a single‑pane‑of‑glass, software‑defined WAN that spans multiple AWS Regions, on‑premises data centers, and edge locations. Its core components are:

In DeepL’s case, each AWS Region hosts a segment that contains the Region’s VPCs, while each Direct Connect location is represented as an edge attachment.

1.2. BGP Under the Hood

BGP remains the lingua franca for inter‑segment route exchange. Two important attributes govern DeepL’s behavior:

• AS_PATH – the sequence of autonomous system numbers a route traverses. Shorter paths are preferred.
• MED (Multi‑Exit Discriminator) – a hint to external peers about the preferred entry point when multiple paths have equal AS_PATH length.

DeepL’s on‑premises routers run a private AS number (e.g., 65010). Each DX attachment advertises the same prefix set (the public‑facing IP space) into Cloud WAN, but DeepL manipulates the AS_PATH length to bias traffic.

1.3. Closest‑Exit Routing Logic

The closest‑exit principle says: traffic destined for a given Region should exit the WAN at the geographically nearest DX location. In a pure BGP world, this is achieved by ensuring that the path with the smallest AS_PATH (or lowest MED) originates from the nearest edge.

DeepL’s topology:

[On‑Prem] -- BGP AS 65010 -- DX‑London   
[On‑Prem] -- BGP AS 65010 -- DX‑Frankfurt   (maintenance)
[On‑Prem] -- BGP AS 65010 -- DX‑Paris

All three DX sites announce the same /16 customer prefix. By default, BGP would treat them as equal, and Cloud WAN would load‑balance or pick arbitrarily, potentially causing traffic to flow through Frankfurt even when London is nearer. To enforce closest‑exit, DeepL prepends its own AS number on all but the nearest DX. The prepend artificially inflates the AS_PATH length for the non‑nearest sites, making the nearest path the clear winner.

1.4. Maintenance Drain Procedure

When Frankfurt’s DX link requires maintenance, DeepL follows a deterministic, zero‑loss sequence:

1. Pre‑drain AS_PATH Adjustment – Increment the prepend on the non‑target sites (London & Paris) by one hop, while keeping Frankfurt’s prepend unchanged. This ensures traffic that would have taken Frankfurt now prefers London or Paris.
2. Cloud WAN Propagation – Cloud WAN’s control plane pushes the updated BGP attributes to every segment within ~2‑5 seconds.
3. Graceful Shutdown – After confirming that all routes have converged (via route‑monitoring APIs), DeepL disables the Frankfurt DX attachment in Cloud WAN. The attachment is logically detached but physically still up.
4. Physical Maintenance – Engineers perform the hardware or ISP‑level work.
5. Re‑attach & Re‑balance – Once the link is healthy, DeepL re‑adds the attachment and restores the original prepend values.

Because the AS_PATH prepend is applied on‑premises, the Cloud WAN fabric never sees a “hole” in its routing table; it simply receives a new, more‑preferred path from the remaining DX sites. No cross‑Region rerouting occurs, and packet loss is avoided.

1.5. Latency & Memory Model Considerations

• Latency – The critical metric is convergence time. Cloud WAN’s BGP control plane is built on Amazon’s highly‑available, in‑memory route distribution service (akin to a distributed hash table). Empirical measurements from DeepL indicate sub‑second propagation for attribute changes, and a total drain window of ~15 seconds from prepend adjustment to traffic fully shifting.
• Memory Model – Each segment’s route table lives in a sharded in‑memory cache that can hold up to 500 k routes per segment. The AS_PATH prepend does not increase route count, only attribute size, keeping memory pressure negligible.
• Compute Dynamics – The BGP decision process on the on‑prem routers is O(N) where N is the number of advertised prefixes (≈ 10 k for DeepL). The prepend operation is a constant‑time string manipulation, so the compute overhead is trivial.

2. The FutureStack Perspective (Mubashir Arham)

"When I first saw the DeepL blog, my immediate reaction was: why are we still relying on manual AS_PATH tweaks? The answer, surprisingly, is that the manual step gives you deterministic control in a world where cloud‑native WAN fabrics are still maturing. The mistake most teams make is to assume that Cloud WAN’s default ECMP will magically give you the lowest‑latency exit. It does not – it only balances traffic when the path attributes are equal. If you don’t explicitly bias the path, you’ll end up with cross‑Region hairpinning, higher latency, and a cascade of cost‑related surprises."

At FutureStack we’ve observed three recurring anti‑patterns:

1. Over‑reliance on static VPNs – Teams still spin up site‑to‑site VPN tunnels for each Region, forgetting that Cloud WAN can replace them with a single global attachment.
2. Neglecting BGP attribute hygiene – Ignoring MED, local‑pref, or AS_PATH leads to unpredictable routing during scaling events or maintenance.
3. Manual “drain” scripts that block on health‑checks – These scripts often wait for a hard timeout, causing unnecessary latency spikes.

DeepL’s approach solves all three by:

• Centralizing the WAN in Cloud WAN, eliminating per‑Region VPN sprawl.
• Using on‑premises AS_PATH prepend as a single source of truth for exit preference.
• Automating the prepend‑adjust‑detach‑re‑attach loop via AWS SDK and Step Functions, achieving deterministic, sub‑second convergence.

If I were to advise any organization building a multi‑Region presence today, I would say: model your exit policy as a data‑driven attribute, not as an ad‑hoc configuration. Store the desired prepend values in a DynamoDB table, trigger a Lambda on change, and let the control plane handle the rest. This eliminates human error and gives you observability via CloudWatch metrics.

3. Code / Implementation Blueprint

Below is a Terraform module that provisions a Cloud WAN core network, creates three DX attachments, and configures a Route Table with a prepend tag that can be toggled via a

local_prepend

# ------------------------------------------------------------
# Terraform: Cloud WAN core network and DX attachments for DeepL
# ------------------------------------------------------------
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
  required_version = ">= 1.5"
}

provider "aws" {
  region = "us-east-1"
}

# 1️⃣ Core network (global) ------------------------------------------------
resource "aws_networkmanager_core_network" "deepl_core" {
  description = "DeepL global Cloud WAN core network"
  policy_document = jsonencode({
    Version = "2023-10-01",
    Statement = [{
      Effect    = "Allow",
      Action    = ["networkmanager:*"],
      Resource  = "*"
    }]
  })
  tags = {
    Owner = "DeepL"
  }
}

# 2️⃣ Segments per Region ---------------------------------------------------
locals {
  regions = ["eu-west-2", "eu-central-1", "eu-west-3"] # London, Frankfurt, Paris
}

resource "aws_networkmanager_global_network" "region_segments" {
  for_each = toset(local.regions)
  description = "Segment for ${each.key}"
  core_network_id = aws_networkmanager_core_network.deepl_core.id
  tags = {
    Region = each.key
  }
}

# 3️⃣ Direct Connect attachments ------------------------------------------------
variable "dx_location_codes" {
  type = map(string)
  default = {
    "eu-west-2" = "LDN-DC1"
    "eu-central-1" = "FRA-DC1"
    "eu-west-3" = "PAR-DC1"
  }
}

resource "aws_networkmanager_link" "dx_links" {
  for_each = local.regions
  global_network_id = aws_networkmanager_global_network.region_segments[each.key].id
  description = "DX link for ${each.key}"
  bandwidth = "10Gbps"
  provider_name = "DirectConnect"
  type = "SITE_TO_SITE_VPN" # placeholder; actual DX attachment uses aws_dx_gateway
  tags = {
    Location = var.dx_location_codes[each.key]
  }
}

# 4️⃣ Route table with prepend flag -------------------------------------------
variable "local_prepend" {
  description = "Number of AS_PATH prepends to apply for non‑closest exits"
  type        = number
  default     = 1
}

resource "aws_networkmanager_route_table" "global_rt" {
  core_network_id = aws_networkmanager_core_network.deepl_core.id
  description     = "Global route table controlling exit preference"
  tags = {
    Environment = "prod"
  }
}

# 5️⃣ Associate segments with the route table --------------------------------
resource "aws_networkmanager_route_table_association" "segment_assoc" {
  for_each = local.regions
  route_table_id = aws_networkmanager_route_table.global_rt.id
  segment_name   = each.key
}

# 6️⃣ Output the prepend value for consumption by on‑prem automation ----
output "as_path_prepend" {
  value = var.local_prepend
  description = "Expose prepend count for on‑prem router configuration"
}

Explanation:

• The module creates a single core network that spans all Regions.
• Each Region gets a segment and a placeholder DX link (in practice you would attach an
  Copy

  aws_dx_gateway

  and associate it with the segment).
• The
  Copy

  local_prepend

  variable is the knob you toggle during maintenance. A CI/CD pipeline can update this variable via Terraform Cloud API, causing the Cloud WAN route table to be refreshed.
• The
  Copy

  output

  feeds the prepend count to an on‑prem automation script (e.g., Ansible) that updates the BGP configuration on the edge routers.

For a fully automated drain, pair this Terraform run with a Step Functions state machine that:

1. Calls
   Copy

   Update-Prepend

   Lambda → sets
   Copy

   local_prepend = 2

   .
2. Waits for CloudWatch metric
   Copy

   NetworkManager.ConvergenceTime

   < 5 seconds.
3. Calls
   Copy

   Detach-Attachment

   Lambda → disables the target DX link.
4. After maintenance, reverses the steps.

4. Empirical Trade‑Off Table

Numbers are derived from DeepL’s internal measurements and public AWS pricing as of Q3 2024.

5. Future Industry Trajectory (18‑36 months)

1. Native AS_PATH Manipulation APIs – AWS is already piloting a Route‑Policy feature for Cloud WAN that lets you inject prepend, MED, or local‑pref directly from the control plane, removing the need for on‑prem tweaks. Expect GA within the next 12 months.
2. Zero‑Touch Maintenance Windows – Integration with AWS Systems Manager Automation will enable a single API call (
   Copy

   StartMaintenanceWindow

   ) that automatically adjusts prepends, detaches links, and validates convergence, offering a one‑click experience.
3. AI‑Driven Exit Optimization – FutureStack is prototyping a reinforcement‑learning engine that consumes latency telemetry from CloudWatch and dynamically adjusts AS_PATH prepends in real time, achieving sub‑millisecond latency improvements.
4. Multi‑Cloud Cloud WAN – As Azure and Google Cloud release their own WAN‑as‑a‑Service fabrics, a standardized BGP attribute exchange layer will emerge, allowing a single prepend strategy to span clouds, on‑prem, and edge locations.
5. Edge‑Centric Compute Integration – With AWS Local Zones and Wavelength becoming first‑class citizens in Cloud WAN, the notion of “closest‑exit” will evolve to “closest‑compute”. Routing decisions will factor in compute availability, not just geographic proximity.

Bottom line: The manual prepend trick is a clever stop‑gap, but the industry is moving toward policy‑as‑code routing fabrics where exit preference is expressed declaratively and enforced automatically. Teams that invest now in observability, automation, and a data‑driven routing policy will reap massive latency and cost benefits as the ecosystem matures.

6. Conclusion

DeepL’s use‑case is a masterclass in deterministic, loss‑free maintenance for a global, multi‑Region architecture. By leveraging AWS Cloud WAN’s global routing fabric and a lightweight AS_PATH prepend on the on‑prem edge, they achieved:

• Sub‑second convergence during link drain.
• Zero packet loss and no cross‑Region detours.
• A repeatable, automatable workflow that scales with the number of Regions.

From the FutureStack lens, the key takeaways are:

1. Treat routing attributes as first‑class configuration.
2. Centralize WAN control in a cloud‑native fabric rather than a mesh of VPNs.
3. Automate the entire maintenance lifecycle with IaC and serverless orchestration.

Implementing the Terraform blueprint above, extending it with Lambda‑driven prepends, and monitoring convergence via CloudWatch will give any organization a solid foundation to emulate DeepL’s success. As WAN‑as‑a‑Service matures, expect the industry to abstract away the manual BGP gymnastics, but the principles of closest‑exit and deterministic maintenance will remain evergreen.

Stay ahead, code your routing policies, and let the cloud do the heavy lifting.