Beyond the Gateway: How Best Buy’s Cloud WAN Segment Matrix Turns Network Routing into a Security Superpower

Who is Best Buy?

Best Buy is the largest electronics retailer in North America, operating over 1,000 stores, distribution centers, and healthcare facilities across multiple clouds and data centers. Their mission is to enrich people’s lives through technology. As Best Buy launched their third-party Marketplace and Best Buy Ads businesses—expanding partnerships with new vendors—the network backbone needed improvements in resilience, performance, and security.

In this post, you’ll learn how Best Buy transformed their network over many phases and years, and how the latest iteration uses a segment matrix constructed with Cloud WAN’s advanced routing policy to improve security, flexibility, and contain costs simultaneously. For retailers and enterprises with complex networks containing several segments, the segment matrix simplifies the design, build, and operations of the network, allowing for more rapid deployment and easier team understanding – it’ll pass the 2:00am test!

Best Buy’s network transformation journey

Best Buy started their AWS cloud adoption in 2011 running BestBuy.com on AWS and has been iterating ever since. In 2024, Best Buy improved in-store customer experience using SD-WAN, powered by AWS Transit Gateway (TGW) Connect and Fortinet FortiGate, to achieve a 20% latency reduction for mission-critical systems like Order Pickup and Product Inventory. Then, Best Buy Health’s Resilient Care Centers powered by AWS Cloud WAN and SD-WAN reduced latency from care centers while meeting strict failover requirements for health-related 911 emergency traffic that required minimal failover times. Most recently, Best Buy completed Phase 3 by implementing AWS Cloud WAN for both corporate and retail. To support critical domains like Best Buy Ads and Marketplace, they designed an innovative segment matrix with inspection through Network Function Groups—reducing firewall complexity, lowering operational overhead, and improving security simultaneously.

Growing pains with AWS Transit Gateway

Best Buy’s former TGW design served them well. It provided connectivity between data centers, cloud, and stores using AWS Transit Gateway’s Connect attachment functionality with their SD-WAN infrastructure. But there were growing pains:

• Route table growth: Each trust boundary required its own TGW route table with associations and propagations. As the VPC count grew, the operational work and mandatory change windows grew with it.
• Segmentation intent lived outside the platform: TGW route tables isolate segments but don’t say why. The reasoning sat within wiki pages and people’s heads—prone to drift. The routing design wasn’t carrying any security load, so other layers compensated.
• Firewall policies compensated for routing: Most segments had routes to each other, so the firewall blocked traffic that should never have had a path. Each environment had its own firewall, inbound and outbound. The same flow was often in two rule sets, both growing—every new rule is one more PCI audit item.
• Regional scope: TGW is regional. Multi-region required TGW peering with static routing only. Their routing footprint spans SD-WAN and cross-cloud connectivity where dynamic routing lets traffic take the best path—static routes couldn’t do that even when a better path existed.

The segment matrix design

Best Buy didn’t design segments around network topology or organization structure. They started from trust boundaries—the same categories security teams and PCI assessors already use—and made the segment layout match directly.

Six workload segments map to trust boundaries:

Workload segments aren’t the whole picture. Traffic also enters the core network from external sources, and each entry point gets its own segment rather than landing directly in a workload segment:

• NPSDWAN / PSDWAN: Tunnel-less Connect attachments from the SD-WAN fabric, split by environment. Traffic arrives in its own segment first, so the matrix—not the attachment—decides what it can reach.
• NPCC / PCC: Cross-cloud connectivity, split by environment.
• ONPREM: Direct Connect Gateway from data centers.

Keeping landing zones separate means external traffic follows the same cell-by-cell decisions as everything else. There’s no “trusted because it came from on-prem”—that trust must be written into the matrix explicitly.

Network function groups

Four NFGs handle every inspection point:

• NPEWNFG: east-west traffic between non-prod VPCs
• PEWNFG: east-west between prod VPCs, plus the one sanctioned cross-environment path: non-prod workloads reaching prod shared services
• NPNSNFG: north-south (internet) from non-prod
• PNSNFG: north-south (internet) from prod

Here’s what this replaces: instead of traffic hitting two firewalls (source environment out, destination environment in), a flow crosses exactly one NFG. The matrix defines which one. Cross-environment flows to prod shared services go through PEWNFG—the prod firewall owns them—inspected once.

Building the matrix

Every segment pair gets one of three answers: NOROUTE (default—no path exists), NFG (inspected path using a Network Function Group), or OPEN (flat routing within the same trust boundary).

ONPREM is OPEN to all three workload trust boundaries because on-prem inspection lives at an edge firewall on-premises. ONPREM is also OPEN to SDWAN segments because the backhaul path for store failover is a direct AWS-terminated SD-WAN tunnel. Consider this in your own design.

As seen in Figure 1, below, the segment matrix provides a bird’s eye view of all of the applicable routes between segments. It outlines where we have an open routing path, an inspection path, or a closed path. This is a great way to visualize explicit routing policy versus a complex JSON policy document.

What you’ll see in the segment matrix visualization is how trust boundaries are formed and implemented: for example a production non-trusted workload in PTB1 cannot access cardholder data in the PCI-DSS production segment PTB3. There’s no firewall policy enforcing this; the route doesn’t even exist!

A note on TB3 / CDE segments: NPTB3 and PTB3 (the cardholder data environments) have no lateral egress in this design — their rows in the matrix are almost entirely NOROUTE. This is intentional. CDE segments receive inspected inbound traffic only: NPTB2 can reach NPTB3 via NPEWNFG, and PTB2 can reach PTB3 via PEWNFG, for sanctioned shared-services access. No other outbound or lateral paths exist. If you are adapting this policy, do not add send-via or share rules for TB3 segments without a compliance review — these rows are the primary PCI-DSS segmentation control in the design, and adding a path here bypasses that control at the routing layer, not just the firewall.

Figure 1: Segment Matrix Visualization

How AWS Cloud WAN implements the matrix

We can implement this using AWS Cloud WAN’s advanced routing policy. AWS Cloud WAN is a managed wide-area networking service that lets you build, manage, and monitor a global network connecting your branch offices, data centers, and AWS VPCs through a central dashboard — using a core network policy to define segments, regions, and routing behavior as code.

With advanced routing policy, you can control how traffic flows between segments by using BGP community tags and attachment policies to apply fine-grained rules — for example, allowing spoke-to-hub traffic while blocking spoke-to-spoke, or steering specific prefixes to inspection VPCs — all without manually managing route tables across every region.

Cloud WAN’s advanced routing policy provides features used for implementing a segment matrix:

• Route filtering: The default between segments is no route at all. A path that doesn’t exist can’t be misconfigured—more secure than a route with a firewall rule in front of it.
• Community tagging: Route prefixes are tagged with trust classification at the source and propagated to SD-WAN appliances for tag-based (not IP/subnet-based) traffic decisions.
• Prefix-list / AS-PATH prepend: Cross-cloud providers advertise summaries; received routes are manipulated for best-path decisions while keeping tables clean.
• Summarization: Segments advertise summarized prefixes instead of individual VPC CIDRs, keeping route counts under quota and limiting what each segment can see.

With Network Function Group (NFG) service insertion, the core network policy states that cross-segment traffic goes through the NFG fronting AWS Network Firewall endpoints. There’s no route arrangement to maintain—a new attachment physically cannot bypass inspection because the send-via behavior belongs to the segment relationship, not any route table. Since routing already removed illegitimate paths, the firewall only handles traffic between boundaries allowed to communicate. The policy becomes an allowlist rather than a growing deny list.

Benefits and outcomes

1. Security at the routing layer: Illegitimate segment pairs are NOROUTE by default—the path doesn’t exist for a firewall to block. Legitimate cross-boundary flows are forced through NFGs. The blast radius of a compromised segment shrinks because paths out don’t exist—not because rules block them.
2. Reduced complexity: One global policy document replaces per-boundary TGW route tables. New VPCs join the correct segment through tags—no route-table work, no change windows. Firewall policies shifted from deny-heavy rule sets to clean allowlists.
3. Lower cost with better performance: Consolidating inspection to one NFG per-flow means less traffic hits the firewall, lowering inspection and data-processing costs. Fewer rules mean fewer audit hours. Dynamic multi-region routing and Tunnel-less Connect (removing the GRE bandwidth ceiling) let traffic take the best path—Best Buy Health saw a 66% round-trip latency reduction for mission-critical voice traffic.

How to build your own segment matrix

Best Buy’s pattern isn’t specific to their scale. You can build your own:

1. Define trust boundaries first: Work with security and compliance to itemize trust categories—not applications, not teams. For most organizations: untrusted/user-facing, shared infrastructure, and regulated environments (PCI-DSS, HIPAA). Environments × trust boundaries = your matrix. Best Buy’s is 2×3 with six segments.
2. Decide connectivity cell by cell: For every pair: no path (default—if nobody can name a business reason, it doesn’t exist), inspected (NFG, standard for crossing a trust boundary), or open. Document as a literal matrix before writing policy—it’s the design artifact and the document you hand to auditors.
3. Separate routing from firewalling: Routing answers: can this traffic exist? Firewalling answers: should this specific flow be allowed? Every path removed at the routing layer is a rule you never write, log, or audit. Each layer shrinks the problem for the next.

See the example policy on AWS Samples that follows the design above. You can use this to get started with your own segment matrix. Note that advanced routing policies are optional. They cover the case where community tags carried from Cloud WAN to the SD-WAN virtual appliance are used by SD-WAN routing policies on the SD-WAN VM to make routing and security decisions, with one tag per trust boundary. The CIDRs and TAGs mentioned are for illustration purposes—adjust as needed. As new CIDRs are added, they won’t match this policy so you’ll want to configure SD-WAN to treat untagged routes as untrusted and drop the traffic.

Lessons learned

• Start with business requirements—don’t overengineer or under-engineer
• Plan around where stateful devices live—this determines your migration sequencing
• Engage your AWS Account Team early. Some quotas are hard and require service team design review before increase
• Avoid big-bang cutover. Sequence by traffic pattern: east-west first, egress next, on-premises last
• During migration, VPCs on both Cloud WAN and TGW must maintain AZ affinity—asymmetric routing through stateful inspection causes outages
• Centralized egress is recommended for most customers
• Use advanced routing policy to summarize prefixes and apply route filters at segment boundaries
• Core Network policy schema must be 2025.11 for advanced routing policy (default is 2021.12)
• When using Tunnel-less Connect with SD-WAN, configure recursive routing in the VPC subnet route table

Next steps & conclusion

Best Buy plans to migrate store SD-WAN from TGW to Cloud WAN’s Tunnel-less Connect attachment and implement AWS Interconnect Multicloud for cross-cloud workloads.

The network has become a cornerstone enabler—any retailer with a store footprint would benefit from this SD-WAN and Cloud WAN integration. Many AWS customers could benefit from the segment matrix design that Best Buy has pioneered, which has resulted in reductions in latency, hardened security, controlled costs, improved flexibility, and higher reliability. We can’t wait to share what’s next—Best Buy continues to focus on the fundamentals with a networking and security foundation to unlock even richer customer experiences across their stores.