Networking & Content Delivery

LexisNexis Risk Solutions success story: Enhancing global connectivity with AWS Cloud WAN

In this post, we review how LexisNexis Risk Solutions modernized their Amazon Web Services (AWS) network by migrating from a legacy Transit Virtual Private Cloud (Transit VPC) architecture to a highly resilient global backbone network built with AWS Cloud WAN. We also dive deep into how AWS Cloud WAN helped LexisNexis Risk Solutions achieve streamlined network management and introduced traffic inspection capabilities while reducing cost and improving performance.

LexisNexis Risk Solutions is a global data analytics and technology company that helps organizations make confident, risk-informed decisions in highly regulated environments. As part of RELX, LexisNexis Risk Solutions combines rich proprietary and public data with advanced analytics and machine learning (ML) to deliver solutions for identity verification, fraud prevention, and risk management. Through a strategic alliance with AWS, LexisNexis Risk Solutions continues to modernize its platforms and scale innovation, serving customers across financial services, insurance, government, and enterprise sectors worldwide.

Prerequisites

Before proceeding, we assume that you’re familiar with AWS networking constructs such as Amazon Virtual Private Cloud (Amazon VPC), AWS Direct Connect, AWS Site to Site VPN, AWS Network Firewall, and AWS Cloud WAN. Detailed information about AWS Cloud WAN service insertion concepts used in this post can be found in the AWS Cloud WAN Service Insertion user guide.

Transit VPC architecture (legacy solution)

LexisNexis Risk Solutions deployed a global transit network on AWS using the Transit VPC architecture as the centralized hub connecting geographically distributed VPCs within and across AWS Regions. AWS Transit Gateway had not yet launched at the time, which made Transit VPC the optimal solution for LexisNexis Risk Solutions’ connectivity requirements.

The Transit VPC design uses virtual router instances deployed across AWS Regions. In a Transit VPC architecture, virtual router instances serve as regional hubs, connecting VPCs and on-premises environments through IPsec VPN tunnels, as shown in the following figure.

Figure 1: LexisNexis Risk Solutions Transit VPC architecture

Figure 1: LexisNexis Risk Solutions Transit VPC architecture

Primary components

The following primary components are included in this architecture.

Transit VPC hub: The VPC hub contains two Virtual Router instances providing VPN termination and dynamic routing. Each instance runs in a separate Availability Zone (AZ) for resiliency during failures.

Spoke VPC: Each spoke VPC has dynamically routed IPSec VPN tunnels terminating over Virtual Private Gateway (VGW). These tunnels establish connectivity between each spoke VPC and the Regional Transit VPC. Dynamically routed VPN connections enable communication between LexisNexis Risk Solutions’ private data centers and AWS-based spoke VPCs through the Global Transit VPC.

Technical and business challenges

As LexisNexis Risk Solutions expanded its cloud footprint to support hundreds of business applications, the legacy Transit VPC architecture revealed fundamental scalability and operational limitations. The architecture was originally designed to centralize routing and connectivity between AWS workloads and on-premises environments. In turn, it struggled to meet the performance, reliability, and automation requirements of a modern enterprise cloud ecosystem.

The design introduced operational complexity through manually managed virtual networking components. Network throughput was constrained by IPSec tunnel limitations—each VPN tunnel capped at approximately 1.25 Gbps—creating performance bottlenecks as application traffic increased. Furthermore, the architecture lacked native traffic inspection capabilities and depended on costly third-party virtual router appliances, increasing infrastructure spend, and operational overhead.

Manual configuration during virtual router maintenance amplified operational inefficiencies. Failover processes required manually stopping one virtual router to force traffic through the secondary device, introducing risk and operational friction. Troubleshooting required proactive Amazon CloudWatch log review combined with custom Lambda scripts to identify root causes, adding complexity and time to issue resolution. These factors drove the need for a more scalable, resilient, and cloud-native networking model.

Solution: How AWS Cloud WAN helped solve these problems

To address the challenges outlined in the previous section, LexisNexis Risk Solutions decided to migrate their inter-Region transit network to AWS Cloud WAN, a managed wide area networking service that streamlines multi-Region connectivity.

AWS Cloud WAN streamlines network operations through its global network policy. Organizations can use AWS Cloud WAN to define their connectivity intent through the network policy—specifying which segments can communicate and how traffic should flow. VPC attachments supporting up to 100 Gbps per Availability Zone, built-in network segmentation, and dynamic route propagation made AWS Cloud WAN the right fit for LexisNexis Risk Solutions’ performance and scalability requirements.

Beyond addressing immediate needs, AWS Cloud WAN positioned LexisNexis Risk Solutions for future growth with a modern, scalable architecture. AWS Network Manager provides unified visibility across the entire global network—including AWS Regions and on-premises infrastructure—through an intuitive graphical console that displays topology, segment mappings, routes, and network events in near real-time. AWS Cloud WAN service insertion enables centralized traffic inspection between segments across AWS Regions, supporting security and compliance needs without adding operational complexity. Integration with AWS Direct Connect opens the door to high-bandwidth hybrid connectivity. For LexisNexis Risk Solutions, AWS Cloud WAN delivered the combination of streamlined operations, consistent global segmentation, and comprehensive visibility they were looking for—all backed by the managed infrastructure and global backbone network of AWS.

Implementation: How LexisNexis Risk Solutions migrated from Transit VPC to AWS Cloud WAN with minimal downtime

Replacing a global network backbone requires careful planning. LexisNexis Risk Solutions approached the migration methodically, breaking it into three phases to minimize risk and ensure business continuity throughout the transition.

Phase 1: Moving Spoke VPCs to Cloud WAN

The journey began with establishing the AWS Cloud WAN foundation and shifting spoke VPCs away from the legacy architecture, as shown in the following figure.

Figure 2: Migrating Spoke attachments to AWS Cloud WAN

Figure 2: Migrating Spoke attachments to AWS Cloud WAN

  1. Stood up the AWS Cloud WAN core network across AWS Regions where LexisNexis Risk Solutions runs workloads, with segments defined to match their business needs.
  2. Attached each spoke VPC attachments to the AWS Cloud WAN core network and mapped them to the defined segments.
  3. Established new IPsec VPN tunnels directly between the on-premises router and the geographically closest AWS Cloud WAN core network edge (CNE).
  4. Added a summarized static route for RFC 1918 ranges pointing to AWS Cloud WAN in each VPC route table. Existing routes to the VGW were more specific, thus they remained preferred—keeping traffic flowing through the old path until LexisNexis Risk Solutions was ready to cut over.
  5. During the maintenance window, BGP sessions on the Transit VPC virtual routers were shut down. This pulled back the on-premises route advertisements from the VGW in the spoke VPC route table and traffic from spoke VPCs shifted to the AWS Cloud WAN core network.

Phase 2: Upgrading hybrid connectivity to AWS Direct Connect

With spoke VPCs running smoothly on AWS Cloud WAN, LexisNexis Risk Solutions shifted focus to replacing IPsec VPN tunnels with Direct Connect for better performance and reliable hybrid connectivity, as shown in the following figure.

Figure 3: Upgrading hybrid connectivity to AWS Direct Connect

Figure 3: Upgrading hybrid connectivity to AWS Direct Connect

  1. Brought up Direct Connect links between on-premises data centers and AWS.
  2. Advertised the same CIDR ranges with AS-Path prepending over a Transit Virtual Interface connected to Direct Connect Gateway.
  3. Associated the Direct Connect Gateway to AWS Cloud WAN CNEs in every AWS Region. At this point, both IPsec VPN and Direct Connect were advertising identical routes to the AWS Cloud WAN core network, but IPsec VPN was preferred due to shorter AS-Path as compared to Direct Connect.
  4. When LexisNexis Risk Solutions withdrew the VPN advertisements, traffic gracefully moved over to Direct Connect.

Phase 3: Enabling traffic inspection with Service Insertion

Figure 4: Centralized traffic inspection with AWS Cloud WAN

Figure 4: Centralized traffic inspection with AWS Cloud WAN

The final phase introduced centralized security inspection to the AWS Cloud WAN network, as shown in the following figure.

  1. Deployed Network Firewall in a dedicated inspection VPC across all AWS Regions, with rules configured to meet security and compliance requirements.
  2. Set up a Network Function Group (NFG) and mapped the inspection VPCs to it.
  3. Updated the AWS Cloud WAN network policy using the Service Insertion “send-via” action to steer traffic between AWS workloads and on-premises through the firewall for inspection. 

Outcome/ summary: What LexisNexis Risk Solutions achieved with AWS Cloud WAN

LexisNexis Risk Solutions was able to achieve the following with AWS Cloud WAN:

Reduced network management overhead

AWS Cloud WAN eliminated the need for self-managed virtual routers for hub and spoke connectivity. LexisNexis Risk Solutions adopted a fully managed native AWS service and no longer had to maintain routing appliances or coordinate upgrades across their fleet of virtual routers. This significantly reduced operational risk and overhead.

High bandwidth connectivity

AWS Cloud WAN removed bandwidth constraints inherent to IPsec-VPN-based spoke connectivity, which limited the connectivity to spoke to 1.25 Gbps bandwidth per tunnel. Native VPC attachments for AWS Cloud WAN support up to 100 Gbps per Availability Zone, so that LexisNexis Risk Solutions could scale application traffic without redesigning the network. This increased bandwidth and made it practical to transition hybrid connectivity from IPsec VPNs to Direct Connect, which improved throughput, latency consistency, and reliability for hybrid network connectivity to their data centers.

Unified observability

AWS Cloud WAN streamlined network troubleshooting across LexisNexis Risk Solutions’ multi-Region, multi-account environment. The AWS Network Manager graphical interface provides a unified view that spans across AWS Regions and on-premises infrastructure. The network team can now visualize how individual attachments map to network segments, monitor network events in real-time, and access routing information—all from a single console. This consolidated visibility eliminated the operational challenges of monitoring distributed hub virtual routers independently and reduced the Mean Time to Repair (MTTR) by 70% to troubleshoot network connectivity issues.

Enhanced security with network segmentation and traffic inspection

AWS Cloud WAN introduced consistent network segmentation and governance capabilities. The AWS Cloud WAN single global network policy allows LexisNexis Risk Solutions to define segmentation rules centrally and apply them uniformly across all AWS Regions, ensuring consistency at scale. The AWS Cloud WAN Service Insertion feature streamlined centralized traffic inspection between segments, strengthening security posture and supporting compliance requirements.

Cost savings

LexisNexis Risk Solutions adopted AWS Cloud WAN and achieved 60% total annual cost savings across its global cloud networking footprint. Retiring virtual router appliances eliminated licensing fees that were deployed in a high availability setup in multiple Availability Zones across every AWS Region that hosted their workloads. The migration also removed expenses tied to running Amazon Elastic Compute Cloud (Amazon EC2) instances for those appliances. With native VPC attachments replacing IPsec VPN connectivity, LexisNexis Risk Solutions no longer needed public IPs for each VPN connection. This was a significant cost reduction given the scale of their multi-Region environment

Conclusion

In this post, we reviewed how LexisNexis Risk Solutions modernized their legacy transit VPC based network and used the AWS Cloud WAN service to unify network connectivity across multiple AWS Regions and data centers. By migrating to AWS Cloud WAN, Lexis Nexis Risk Solutions was able to achieve high bandwidth connectivity, unified observability, enhanced security and cost savings. To find out more details about AWS Cloud WAN, check the documentation. If you have questions about this post, then start a new thread on AWS re:Post or contact AWS Support.

About the authors

shsnghb.jpg

Shubham Singh

Shubham is a Senior Network Specialist Solutions Architect at AWS. He helps customers design innovative, resilient, and cost-effective solutions using AWS services. He is passionate about technology and enjoys building solutions in the Networking and Security domain. He holds a MS in Telecommunication Systems Management from Northeastern University, specializing in Computer Networking.

marcineditimage.png

Marcin Jarota

Marcin is a Senior Networking Specialist Solutions Architect within Strategic Accounts at Amazon Web Services. He focuses on helping customers with building highly scalable and resilient AWS environments.

Sanjit-Screenshot-1.jpg

Sanjit Varghese (Guest)

Sanjit Varghese is a Senior Network Architect at LexisNexis Risk Solutions with over 20 years of experience designing enterprise grade network platforms. Sanjit is passionate about redefining network infrastructure to meet the demands of an increasingly dynamic digital landscape. He holds a master’s degree in electrical and computer engineering from the NYU School of Engineering. Outside of work, Sanjit enjoys traveling and immersing himself in diverse cultures around the world.