Resource aviatrix_vpc creates a VPC/vNet/VCN in various cloud types. For Aviatrix Transit VPC, there would be various different subnets created for the purpose of integrating with SDWan appliances, insertion of Firewalls, integration with AWS TGW (Aviatrix Orchestrated), or utilizing AWS Gateway Load Balancer etc.
An example of subnets created in AWS for Aviatrix Transit VPC with High-Performance Encryption, TGW-O integration, and Firewall integration with GWLB.
It is common for enterprise customers to run a workload in AWS in a public-facing subnet, where the default route (0.0.0.0/0) would be pointing to the AWS internet gateway (IGW). Reference: AWS Internet Gateway Documentation
The IGW provides NAT between the public IP and the private IP assigned to the instance. You may control inbound/outbound traffic via Security Group, where you can control what protocol and IP range that would have access. However, IGW won’t provide you much visibility of the traffic going in/out from your instance, and you may need to use FlowLogs to gain some level of visibility. Some examples of FlowLogs can be found here: Flow log record examples. You may find it lack of detail and very difficult to read.
For enterprise customers that value visibility and security, as well as simplified IT operations, Aviatrix has designed a Public Subnet Filtering gateway feature for AWS public subnet workload.
Aviatrix developed Migration Toolkit to help customer migrate from existing AWS/ Azure environment to Aviatrix Transit and Spoke Multi-Cloud Networking Architecture (MCNA). I have discussed the process in blog: Migrate from Azure vNet hub and spoke architecture to Aviatrix Transit. The AWS migration process is similar, where the toolkit make copies of existing route tables, when Aviatrix Spoke is attached to Aviatrix Transit, we are using these copied route tables, hence no traffic interruption would happen. During the traffic switching phrase, subnets will be associated with the copied route table, and in TGW we disable the migrating VPC router advertisement, so the traffic would swing over to Aviatrix Spoke/Transit.
Some of our customers are using CloudFormation to manage the deployment of their environment, while Aviatrix Controller will handle bulk of the work such as populating RFC1918 and/or default route in the route table and/or non-RFC1918 routes from External connections, they still would like to have the ability to continue to use CloudFormation to manage endpoint routes. This created a split brain scenario, how do we handle this?
One of our customers approached Aviatrix in search of a high-performance encryption solution for their on-premise data centers and AWS. They were impressed with Aviatrix’s features, including visibility, a dedicated data plane, high-throughput encryption, and Terraform capability. However, they also had sister business entities still using AWS TGW, and didn’t want to spend too much time trying to convince them to switch to Aviatrix. That’s when they turned to us for a hybrid architecture solution.
Recently we were helping customer to launch Spoke Gateways in their AWS account, after 10 minutes launching the gateway, the gateway creation were reverted and following errors generated
Error: [AVXERR-TRANSIT-0119] Failed to launch gateway test. Instance i-0005da0797da40ae8 could not be started. Delete the gateway test to clean up resources and try again. It is possible that gateway size t3.small is not supported in the region us-east-1 or EBS encryption KMS CMK Key policy Key administrators and users are not updated with your Aviatrix APP role and Aviatrix EC2 role.
In AWS, subnet that doesn’t have default 0.0.0.0/0 point to Internet Gateway (IGW) is considered as private subnet. Where subnet that have default 0.0.0.0/0 point to IGW is considered as public subnet. Instances running on private subnet still need to access Internet to download patches, packages etc. You may use AWS NAT Gateway on public subnet to provide this connectivity. NAT Gateway cost $0.045 USD per hour plus $0.045 per GB data processed.
If you already have Aviatrix Spoke Gateway deployed, and need internet access (egress) from private subnet, also you don’t need any fancy egress control, then you may reuse the existing Aviatrix Spoke Gateway as Egress Gateway by using SNAT rule.
If you need better control and traffic inspection, you should consider Aviatrix FQDN egress gateway for L7 egress control based on Fully Qualified Domain Name eg: allow https://github.com deny https://youtube.com. Or if deep packet inspection using Next Generation Firewall (NGFW) is required, then you may consider Aviatrix FireNet with NGFW integration.
In the last two blog posts, we discussed two methods for connecting on-premises to Aviatrix Transit via Direct Connect:
Option 1: Use detached Virtual Private Gateway (VGW) to build BGP over IPSec tunnels with Aviatrix Transit. This solution has following constrains: 1.25Gbps per IPSec tunnel, max 100 prefixes between on-premise and cloud, also potential exposure to the man in the middle attack.
Option 2: Use attached VGW to build underlay connectivity between on-premise router/firewall and Aviatrix Transit VPC, then use GRE tunnels to build overlay connectivity between on-premise router/firewall to Aviatrix Transit. This solution would provide 5Gbps per GRE tunnel, and bypass the 100 prefixes limitation. However this solution only works with AWS, and still have potential exposure to the man in the middle attack.
Today, more and more enterprises are going into multiple cloud service providers (CSPs). Some due to merger and acquisitions, or partner/ vendor preferences, or simply one CSP provides superior products that are not offered by other CSPs.
Is there a solution that can standardize networking architecture across all CSPs, and provide necessary securities and bandwidths, and more importantly provide enterprise grade features, and also help enterprise obtain day 2 operational excellencies?
In my last blog post, I have covered one option to connect On-Premise data center to Aviatrix Transit via Direct Connect, it’s easy to implement however with following draw backs:
Each IPSec tunnel between Aviatrix Transit and AWS Virtual Private Gateway (VGW) is limited to 1.25Gbps of throughput, and we can only have 4 tunnels which limits the aggregated throughput to 5Gbps. For customer want to have higher throughput, this won’t be viable.
Private Virtual Interface support up to 100 BGP routes, BGP session will go DOWN when more routes been advertised
Between On-Premise to VGW, traffic maybe protected by MACSec, but still expose to man in the middle attack. Reference article: Securing your network connection to the cloud: MACSec vs. IPSec
How do we overcome these constrains? Let me take you through the second option connecting to Aviatrix Transit via Direct connect.
Aviatrix Controller isn’t In data path, controller down will affect ability to change currently configuration, or to monitor gateway status to make changes to route tables, or to authenticate new VPN user connection request.
To make sure Aviatrix controller in AWS highly available by avoiding single AZ failure, Aviatrix has developed a CloudFormation template that utilizes Auto Scaling Group and Lambda function to automatically monitor controller failure, redeploy controller and restore configuration.