Cloud WAN cuts Betsson latency by 100 ms globally

Betsson migrated its global gaming network across three continents with zero downtime by replacing complex mesh topologies.

The industry shift toward managed connectivity is undeniable as organizations abandon discrete hardware for integrated cloud solutions. By centralizing control, enterprises can achieve the scalability required for modern, multi-region operations without sacrificing security or performance.

Readers will examine the specific role of Cloud WAN in simplifying global network architecture, moving beyond fragmented hub-and-spoke models. We dissect the underlying routing mechanics and security integration that enable automatic full-mesh peering and flexible pathing. Finally, the guide details a proven strategy for executing a zero-downtime migration, outlining the critical planning phases Betsson employed to document BGP ASN ranges and IP allocations before switching live traffic.

The Role of AWS Cloud WAN in Modern Global Network Architecture

AWS Cloud WAN Core Components and Segments

AWS Cloud WAN functions as a managed wide-area networking service that unifies global connectivity through centralized policy enforcement rather than manual peering. The architecture replaces discrete Transit Gateway meshes with a single logical construct known as the core network, which automatically establishes full-mesh peering across regions. This shift eliminates the operational overhead of configuring individual IPSEC VPN tunnels for every site connection. The fundamental building block within this framework is the segment, a logical isolation boundary that groups attachments sharing common routing and security requirements.

Betsson Group replaced a complex Transit Gateway mesh with AWS Cloud WAN to unify operations across three continents. The legacy architecture struggled with routing complexity in an Active/Active Hub & Spoke topology as the organization scaled rapidly. Manual configuration of peering links created operational friction that a policy-driven approach resolves automatically. This shift enabled automatic full mesh peering without requiring engineers to script individual BGP sessions for every region. The migration delivered a 100 ms latency improvement alongside a 10-15% cost reduction by consolidating redundant links. Operators achieve these gains because the service exchanges routes using Border Gateway Protocol without manual intervention per site.

The pricing structure depends on the count of core network edges and data processing volume rather than discrete peering attachments. This shift reduces the financial penalty associated with expanding into new geographic zones. However, the centralized model removes granular control over individual path preferences that some legacy designs require for traffic engineering. Teams must accept that segment sharing policies apply globally, limiting region-specific route manipulation. Architects who need strict local preference adjustments may find the automated flexible routing too rigid for specialized failover scenarios. Migration eliminates the need to manually configure IPSEC VPN tunnels for every site pair.

BGP ASN Planning and Attachment Isolation Mechanics

Sequential BGP ASN ranges prevent route leaks when Betsson inventory shows overlapping region allocations. Operators must document existing on-premises and cloud assignments before defining a new unique range for the core network. This sequential approach eliminates ambiguity during peer establishment, ensuring distinct path attributes for every environment. Unique numbering avoids the connectivity failures observed when legacy meshes reuse identifiers across boundaries. Attachment isolation enforces security boundaries by restricting direct route propagation between specific network interfaces. Sensitive workloads require this policy to force all east-west traffic through a centralized firewall inspection point. Administrators assign attachments to corresponding segments based on tags, enabling automated network segmentation without manual route filter updates. The mechanism blocks default inter-segment peering, creating a zero-trust perimeter inside the global fabric.

The cost of strict isolation is increased hop count, yet this trade-off guarantees consistent policy application. External connectivity like Direct Connect maps to a dedicated hybrid segment to contain risk exposure. JSON-set policies replace per-device access lists, reducing configuration drift across the central dashboard. Engineers gain granular control while the system maintains uniform security postures globally.

Configuring AWS Network Firewall for East-West Inspection

East-west traffic between segments requires forced traversal through AWS Network Firewall using centralized policy documents. Operators define a centralized network policy document to mandate that sensitive VPCs apply attachment isolation, preventing direct route propagation. This configuration ensures any communication crossing segment boundaries hits an inspection engine before reaching its destination. The mechanism relies on service insertion capabilities that redirect flows based on tags rather than static route tables. Implementing this architecture involves four specific steps to guarantee consistent security postures:

1. Define core network segments with explicit isolation flags for production workloads. 2.

The final design mandates that all external traffic passes through a central egress environment, completing the zero-trust loop.

Handling Regions Without Native Cloud WAN Support

Betsson bridged the sa-east-1 coverage gap by deploying a standalone AWS Transit Gateway peered to the global core network. This hybrid pattern addresses the operational risk where specific geographies lack native Cloud WAN support, forcing a fallback to manual routing domains. Operators must configure route table attachments to map regional traffic into the appropriate security segment, preserving trust levels despite the architectural discontinuity. The cost implication involves extra charges for AWS Transit Gateway peering attachments alongside standard data processing fees. Pricing models explicitly include these peering links as a distinct factor determining total monthly expenditure.

Traffic flowing through the bridge gateway incurs data transfer costs starting at $0.09/GB after the initial 100GB free tier. Engineers must verify that the inspection segment remains shared across both native and peered environments to prevent bypass scenarios. This approach optimizes capital expenditure by avoiding duplicate firewall clusters while using existing Transit Gateway investments. The limitation is a loss of fully automated attachment approval for the bridged region. Manual intervention remains required when scaling VPC count within the unsupported zone.

Executing Zero-Downtime Migration from Transit Gateway to Cloud WAN

Zero-Downtime BGP Routing Mechanics with AS-Prepends

Deploying a new set of IPSEC VPNs from on-premises equipment establishes the parallel path required for uninterrupted site-to-site connectivity. Operators shift traffic flow by manipulating BGP routing attributes, specifically applying AS-Prepends to the legacy AWS Transit Gateway session to artificially inflate path length. This technique forces the on-premises router to prefer the shorter AS path advertised by the new AWS Cloud WAN endpoint without dropping active packets. The mechanism relies on the fact that AWS Transit Gateway provides teams with more direct control over routing tables compared to fully managed alternatives, allowing granular prepend injection during the cutover window. Execution requires a strict four-step sequence to prevent routing loops: 1.

Executing the swap requires modifying Terraform state to replace `tgw-*` identifiers with `core-network-*` targets in private subnet route tables. This operation shifts traffic flow from the legacy mesh to the centralized global network Operators must retain existing AWS NAT Gateway entries for specific subnets where external partners enforce strict IP allowlisting policies. Changing these egress points prematurely breaks connectivity for third-party integrations that cannot dynamically update firewall rules. The migration procedure follows a strict four-step sequence to maintain service availability:

1. Import existing VPC attachments into the Terraform state file under the new AWS Cloud WAN resource block. 2.

A March 1, 2025 incident revealed that Network Health indicators may misrepresent path status when destinations traverse an AWS Transit Gateway. This blind spot creates a false sense of security during migration, as the dashboard reports green while underlying routes remain blackholed. Operators must manually verify connectivity rather than trusting the centralized view. The root cause lies in how legacy peering attachments report state to the management plane. Corrective action requires a shift from passive dashboard monitoring to active event stream analysis.

1. Subscribe to AWS Network Manager event buses for real-time topology change alerts.
2. Filter specifically for blackhole route announcements originating from hybrid segments.
3. Cross-reference admin policy changes against BGP session flaps in the logs.
4. Validate actual data plane reachability using synthetic probes across segments.

Relying solely on the default UI exposes the network to silent failures where traffic drops without triggering alarms. This limitation stems from the architecture where centralized policy-based approach tools abstract away lower-level path details. Pricing models charge for AWS Transit Gateway peering attachments separately, incentivizing complex topologies that exacerbate visibility gaps.

Defining Measurable Cloud WAN Business Outcomes

Enterprises should adopt Cloud WAN when manual mesh complexity prevents rapid regional expansion within minutes instead of hours. Success metrics extend beyond simple migration speed to include financial efficiency and market alignment. Operators targeting a benefit-to-investment cost ratio exceeding 5:1 typically realize breakeven within ten months, validating the shift from legacy transit architectures. This financial velocity supports the broader industry shift where hybrid cloud spending approaches $194.14 billion in 2026. Zero-downtime execution remains the primary technical constraint, requiring parallel BGP sessions rather than disruptive cutovers.

A hidden tension exists between rapid deployment and observability completeness, as network health indicators may lag during transitional states. Teams must verify path integrity through event streams rather than relying solely on dashboard status lights. The implication for network architects is clear: measurable success requires decoupling deployment speed from validation rigor.

Betsson achieved a 100 ms latency reduction between regions by replacing manual mesh topologies with centralized policy enforcement. This technical shift eliminated the routing complexity inherent in full-mesh AWS Transit Gateway designs, directly supporting 2,500 employees across three continents. Operational efficiency surged as deployment times for new AWS regions dropped from hours to minutes, enabling rapid scaling without proportional staff increases. Similar enterprise migrations demonstrate that operational efficiency can increase by 50% when teams abandon legacy peering models for managed core networks. These gains align with broader market data showing AWS, Microsoft Azure, and Google Cloud controlling 68% of enterprise cloud spending as of 2026. Financial modeling indicates that such architectural shifts often yield a benefit-to-investment ratio exceeding 5:1 However, realizing these metrics requires strict adherence to BGP ASN planning to prevent path conflicts during the transition. Operators must define unique sequential ranges before activating segments, or risk blackholing traffic during the cutover phase.

Verify zero-downtime status by confirming BGP session stability before expanding Network function groups beyond the initial two regions. Operators must validate that traffic flows through the centralized policy document without packet loss during the transition. Future phases require implementing service insertion. This expansion addresses the previous limitation where direct integration for AWS Direct Connect attachments remained unavailable during the initial migration window. Teams should prioritize adding these attachments to complete the hybrid architecture.

The cost of delayed service insertion is measurable, as uninspected regions increase the attack surface for lateral movement. Expanding security policies too rapidly without validating underlying global network InterLIR recommends a phased rollout that ties new region activation to successful firewall throughput tests. This approach balances speed with the necessity of maintaining strict attachment isolation for sensitive workloads.