Technical Forum

How are you and your teams approaching Terraform in general. Terraform is great in certain use-cases but I want to hear what are the limitations and choke points in using Terraform? What are the things it cannot really do?

Network segmentation is a highly effective strategy to limit the impact of network intrusion. This article delves into ways to simplify network segmentation and how Aviatrix Network Security Domains, along with AWS Transit Gateway (TGW), provide a solution for secure network traffic in multi-VPC environments. Cloud Network Segmentation: why and how? First, let’s look at why network segmentation is vital to network security. In the traditional data center networks, segmentation was primarily done via a DMZ or perimeter which had firewall devices. The issue here was that once a bad actor got into the network, they gained wide reach throughout the “private” network. Segmentation approaches called for partitions of numerous smaller networks, reducing the reachability for intruders, minimizing the damage they could do. This type of segmentation involves developing and enforcing a set of rules to manage the traffic between segments. The best practice was to find a manageable level

The problem: The number of inbound or outbound rules per security group in amazon is 60. Reference. From the inbound perspective, this is not a big issue because if your instances are serving customers on the internet, then your security group is wide open; on the other hand, if you want to allow access only from a few internal IPs, then the 60 IP limit is sufficient. However, outbound or egress traffic is a different discussion. Let's say you have a production instance that needs updates from updates.ubuntu.com ( 15 IPs) and a few other repositories like GitHub (12 IPs), and perhaps a third party partner. You can quickly realize that 60 IPs are not enough. The solution: Aviatrix solution to this problem is the Secure Cloud Egress with FQDN that allows you to specify filters using Fully Qualified Domain Name of the destinations that your instances are allowed to reach. This simplifies the management as you only introduce FQDN such as update.ubuntu.com or github.com to

AWS Transit Gateway (TGW) enables customers to connect their VPCs and their on-premises networks to a single gateway. It acts as a hub that controls how traffic is routed among all the connected networks which act like spokes. The AWS Transit Gateway (TGW) was designed to replace the older Transit VPC architecture, which deployed third-party instances that performed transitive routing functions. While both the AWS Transit Gateway (TGW) and the older Transit VPC constructs allow for connectivity, the routing updates and related challenges are entirely different. Let’s take a look at the legacy approach of implementing transit using the Transit VPC architecture:   The connectivity to on-premise relies on Direct Connect or IPsec VPN and terminates in a VGW, which is attached to the Transit VPC. A third-party appliance (Cloud Router) with transitive routing capabilities connects the VGW to all the “spoke VPCs.” In this construct, the on-premise (or Datacenter) environment

looking for some details on pros/cons of leveraging native AWS TGW vs using Aviatrix transit gateway ?

The AWS Transit Gateway (TGW) was introduced to eliminate complexity involved in peering many VPCs together. In the pre-AWS Transit Gateway (TGW) world, if you had to connect many VPCs, you were required to use a complex mesh of VPC peerings. To be accurate n (n-1)/2, where n is the number of VPCs. AWS Transit Gateway (TGW) was introduced to make peering of VPCs easier. But, it does not make routing easy. When attaching the AWS Transit Gateway (TGW) to a VPC, it does not propagate routes to the VPCs. Similarly, creating propagation across route tables in the AWS Transit Gateway (TGW) does not automatically populate routes into the respective tables. The formula of how many route tables need to be managed, reviewed and updated when using an AWS Transit Gateway (TGW) is equal to: n ( s + r - 1), where n is the number of VPCs attached to the AWS Transit Gateway (TGW), s is the number of subnets in each VPC and r is the number of route tables in the AWS Transit Gateway (TGW). Let

Azure VPN GW cannot be used as a transit gateway. You should be using NVA (for example Aviatrix Trnsit GW) in Transit VNET

I am building a lab environment and deploying Aviatrix Service Gateways. Is there a matrix that can tell me what features I can enable on the same GW?For example can I enable Aviatrix Transit and FireNet on the same Gateway?What are the features I cannot turn on the same GW?

Wondering how to recover from a failed upgrade on my controller? I tried to install the upgrade again but it failed. 

I am using Cloudwatch for logging all aviatrix events. We would like to raise an alert whenever there is a status change in one of the tunnels. Email alerts contain the following text: "State Change: Up -> Down" but I have not been able to find a similar text in the logs.  Any help would be welcome. Antonio

I'm looking for the User-VPN connection history view. Is it in the dashboard?

What are some of the ways your teams have provided operational visibility in the Cloud. Can you guys share your experience please?