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.

Simple diagram:

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.