Scenario:
By default, Aviatrix Spoke and Transit architecture requires administrators to onboard the spoke VPC/VNet accounts/subscription on Aviatrix Controller. This requires administrators to have some level of basic access/privileges over the account/subscription.
In this situation, what are some of the alternate approaches to be considered?
Support for Overlapping IP Address Ranges:
An additional complexity that must be considered is that you will likely have no control over the IP address range(s) being used by the customer spoke and will need to cater for potential overlapping IP Addresses. Both the Solutions mentioned below also support overlapping IP addresses.
Solution
In situations where Aviatrix Administrator is unable to onboard the spokes to the Controller, there are several alternate designs available as shown in the following diagram. There are pros and cons associated with all options. The intent of this article is to introduce the options, for detailed discussion contact the author.
Choice A - Leverage Landing VPC/VNet:
Connect the Workload spoke to a Landing Spoke VPC/VNet. If you wish to leverage Aviatrix Multi-Cloud Network Segmentation then creating a landing VPC/VNet for each set of customer(s) may be needed.
Option 1: VPC Peering.
If the Customer 1 only needs access to applications that live in the Landing Spoke, then no additional configuration is needed. However, if it needs to access any other network, leverage the Aviatrix Advance NAT functionality.
Option 2: Use a native VPN appliance such as AWS VGW, or Azure VNG etc.
Each cloud provider has some sort of VPN appliance that can be used to build IPSec tunnels to the landing VPC Spokes. This option provides more flexibility with Aviatrix BGP on Spoke feature and allows access to all the networks. It simplifies advance traffic engineering and route propagation.
Option 3: Leverage a 3rd party router, firewall or other network devices
The end VPC may already have a 3rd party appliance such as a FW capable of establishing IPSec or GRE tunnels. These can be leveraged to build the connectivity between external spokes and Aviatrix managed environments.
Note: When Aviatrix deploys its Gateway in the spoke, it also manages and orchestrates the native route tables. In above options, customer will have to manage the routing of remote spoke networks while Aviatrix will manage the routes in the landing VPC and Gateways.
Choice B - Connect to Aviatrix Transit:
Option 4 or Option 5: Connect via Native VPN GW or 3rd Party Appliance
Similar to Option 2 & 3, you can also directly connect customer environments with Aviatrix Transit. The additional capability this brings are:
Segmentation: Each connection can be treated as a segment of its own and using Aviatrix Multi-Cloud Network Segmentation, policies can be defined to control its access.
Aviatrix Transit FireNet: Each connection can be subjected to Aviatrix FireNet policy model and forced to traverse thru a NGFW which is integrated at Aviatrix Transit.