Next-Gen Transit Network
Introduction: Why and when to Segment groups of VPCs

Reduce your blast radius.
(and make your SecOps happy)

Companies now have many categories of VPCs in their AWS environment. Based on the applications running on EC2 instances in a VPC, Cloud teams usually categorize a VPC by the resident application privileges and permissions. Those categories can include “Dev”, “Test”, “Prod”, and/or any other approach to group VPCs. Each category of VPC tends to have a common set of policies, per the privilege of the applications, governing what other cloud resources they can reach. While Security Groups provide some instance-level isolation, there has not been a VPC-level way to isolate categories of VPCs.

Another consideration is that a VPC is a way to partition your overall environment into smaller networks (of VPCs). Each VPC itself reduced the blast radius should an intrusion occur. Now, with AWS Transit Gateway (TGW), the best practice is to attach all VPCs to the TGW. This is great for connectivity but the blast radius increases dramatically. When you have a growing number of ten or more VPCs, it becomes increasingly difficult to manage. There isn’t a common way to develop and enforce a ruleset to control the traffic by the category of VPC.

How Aviatrix Security Domains solve that?

Aviatrix Security Domains for isolating your VPC types

Aviatrix Next-Gen Transit Network provides a common way to control your VPC traffic. It uses a prescriptive approach to working your with categories of VPCs. Each VPC member of a category can be grouped together into an Aviatrix Security Domain. Each Security Domains is flexible to have as few as one VPC to many 100s of VPCs. Aviatrix Security Domains have these rules:

  • Segmentation: Every VPC within a domain can reach each other VPC via the AWS Transit Gateway (TGW)
  • Isolation: Other VPCs cannot reach that group unless specifically configured. One common use case is to prevent east-west traffic between VPC categories.
  • Policy-based Routing: Aviatrix Connection Policies can specifically configure domain to domain routing

The Aviatrix Controller dynamically programs, updates, and enforces the TGW Route Tables and VPC Route Tables to ensure the above rules. The Controller orchestrates all routing when there are changes: VPCs are attached or detached from the TGW, VPCs are added or removed from an Aviatrix Security Domain, and/or Connection Policies are changed.

Why is it called an Aviatrix Security Domain?

First, Aviatrix Security Domains ensure the hard separation of VPCs. Even if every VPC is attached to the AWS Transit Gateway (TGW), the VPCs are separate and non-routable if they are not allowed by the Domain and Connection Policies. Furthermore, the Aviatrix Security Domain is enforced by the Aviatrix Controller. If another VPC is configured to reach into another Aviatrix Security Domain, you’ll be alerted to take action. In working with AWS, Aviatrix will continue to build more into the Aviatrix Security Domain. For example, future releases could infer anomalies based on traffic metadata and protocols.

How is it different from another route table/route domain?

Built on top of AWS TGW Route Domains (TGW Route Tables)

With the AWS Transit Gateway, AWS introduced the powerful concept of TGW Route Domains. Each new Route Domain appears as another TGW Route Table, in addition to the default TGW Route Table. Route Tables are very flexibly configured. That flexibility can make it difficult to ensure a common routing architecture for categories of VPCs which are attached to the TGW. Also, as a regional service, AWS Transit Gateway Route Domains involve detailed configuration and customization.

Aviatrix has partnered with AWS to build on top of TGW Route Domains – making them simplified and secure… Aviatrix Security Domains. AWS was impressed so much that AWS invited us on stage to talk about them at re:Invent 2018.

Now that I understand Aviatrix Security Domains, how about Aviatrix Connection Policies

And Aviatrix Connection Policies?

Aviatrix Connection Policies are used in conjunction with Aviatrix Security Domains. Connection Policies are applied at the group level. A common policy would be for the Shared Services Security Domain to be able to reach the Dev and Prod Domains but Dev and Prod could not reach each other. Using Connection Policies avoid the custom effort to individually configure each VPC. That can oftentimes lead to “policy-drift” within an organization. Also, Connection Policies provide easily auditable rules that are enforced dynamically at runtime. Those policies can be defined in the GUI or via Terraform/Config files.

Aviatrix Security Domains and Connection Policies enables your organization to deploy VPCs securely without compromising your security or compliance controls.