Recently had a customer that wanted to limit the communication among the appliances that are in a certain region and devices that don't belong to a region. They also wanted to be able to create tunnels only to the international Hubs but not to appliances in other regions
We achieved this by creating a region (ConfigurationàOverlay&SecurityàRegions) and moving appliances to that region.
Appliances within the same region maintained tunnels to each other but deleted tunnels to the appliances that didn't belong to the same region. While this design is very tidy, some customers need the ability to have exceptions where branch appliances in one region build direct communication to Hubs in a different region. Normal regional architecture won't allow this, which is why there is the added capability on the Business Intent Overlay page.
When different regions are created, appliances in those regions will be able to build tunnels to each other. When a new site is added, Orchestrator will automatically build tunnels based on the Business Intent Overlay (BIO) page.
Creating regions and assigning them to sites has no impact on an environment. The changes only take place once we modify the BIOs to take advantage of the regions we have created. Each region can have a topology of their own (full mesh, partial mesh, HUB & Spoke)
Any environment can have up to 64 regions, but in practice most customers stick well below that. While the example above was due to a requirement around securing communication, this can also help environments scale or prevent Orchestrator from trying to build tunnels that will not work (i.e. government regulations that prevent tunnel formation).
Below is a link to Aruba documentation that explains regionalization in greater detail with topology examples.
https://www.arubanetworks.com/techdocs/sdwan/docs/orch/configuration/network/regions/