Micro Segmentation in the Cloud: AWS vs Cisco Cloud ACI vs Aviatrix

Cloud Network Segmentation has become mandatory for better security & increased connectivity. It plays a critical role in securing & scaling cloud networks. With cloud segmentation enabled, sensitive data & core infrastructure are protected. The Cloud Network Segmentation is part of the zero-trust model.

The micro segmentation means everything and anything.. The purpose of this post is more to understand what are the different options available on the market to segment your cloud workloads @network level. 

I am not in a position today to compare all the CSP's solutions; but only AWS. For this reason, I will give you my thoughts on the cloud network segmentation capabilities between AWS, Cisco Cloud ACI & Aviatrix..

I am not a Cisco Cloud ACI expert neither 👷but based on meetings with Cisco & some technical research, I am giving you my analysis.

Also, as a Solutions Architect, I like to test new solutions and this post is only my perception (no one asked me to work on it).

Other CSPs

• Azure FW similar to AWS FW
• AliBaba similar to AWS FW
• GCP with Filter rules
• OCI with DRG (like AWS TGW Routing Tables)

AWS solutions

AWS TGW Routing Tables

This solution is a legacy solution from AWS. It consists in segregating the workloads in different Routing Tables of AWS TGW (like VRFs). That way they are not able to communicate together. If there is a need for an inter-workloads communication, then 'TGW attachment propagation' into the destination TGW Route Table must be enabled.

My feeling

• Limitation of 20 AWS TGW RTs by default. This feature is not designed for advanced segmentation
• Playing with 'route propagation' leads to complicated design & deployment. Difficult to control the flows
• AWS intends to leverage AWS Cloud WAN for that purpose

AWS FW

Principle

• Creation of an 'Inspection VPC' where the AWS FW is configured
• Traffic must be redirected to the inspection VPC to be inspected
• AWS FW Policy is created: it blocks & filters the traffic passing through it and also monitors

AWS FW use case with E-W inspection model

• 2 AWS TGW Routing Tables must be created
• FW or Inspection TGW RT
• Spoke TGW RT
• TGW Association
• Spoke VPCs must be associated to Spoke TGW RT
• FW VPC must be associated to FW TGW RT
• TGW Route propagation
• Inspection VPC attachment must be propagated to Spoke TGW RT
• Spoke VPC attachments must be propagated to FW TGW RT

My feeling

• AWS FW is a very expensive solution to achieve a single security requirement (eg. segmentation)
• Re-architecture must be done to deploy this solution; this can lead to migration strategy and unwanted downtime
• Overall added complexity when in place (flows path, multiple TGW RT, new Cloud Native constructs)

I will do a dedicated post on AWS FW later.

AWS Cloud WAN

AWS Cloud Wan builds on TGW Connect by allowing users to define a Core Network subdivided into segments. Each segment is a globally synchronized isolated Layer3 segment similar to VRFs, and provides an isolated routing domain within AWS Account. Remote endpoints are connected to the Core Network at Core Network Edge locations. With Cloud Wan, segments represent natural isolation boundaries.

• Segmentation is @VPC level
• AWS Cloud WAN is in Public Preview today and not in General Availability
• Centrally managed & globally distributed
• AWS Cloud WAN has the same limitations as AWS Transit Gateways (by default 20 segments only)

Principle

• Global Network: A single network that acts as the high-level container for your network objects. A Global Network can contain both AWS Transit Gateways and other Cloud WAN Core Networks. These are shown in the AWS Network Manager console.

• Core Network: The part of your global network managed by AWS. This includes Regional connection points and attachments, such as VPNs and VPCs. Your Core Network operates in the AWS Regions defined in your core network policy document.

• Core Network Policy (CNP): A single document that defines the global configuration of your Core Network. The Core Network Policy document defines how your VPCs, virtual private networks (VPNs), and existing AWS Transit Gateways connect to your network. The CNP also defines the routing policy and how traffic should be segmented across the network. Configure the CNP document via Visual Editor or JSON file.

• Attachments: Attachments are any connections or resources you want to add to your Core Network. Supported attachments include VPCs, VPNs, and TGW connect.

• Core Network Edge (CNE): The Regional connection point managed by AWS in each Region, as defined in the CNP. Every attachment connects to a Core Network Edge. The CNE uses similar technology to AWS TGW, but is managed by AWS. 

• Network segments: Segments are dedicated routing domains, which means only attachments within the same segment can communicate by default. You can define segment actions that share routes across segments in the Core Network Policy. In a traditional network, a segment is like a globally consistent VRF table.

How to configure it?

Steps 1-2: Global Network & Core Network creation

CNEs (Edge Location) & Primary Segment are configured

To continue further the configuration, you have to wait (a lot!)

Step 3: VPC Attachment to CNE

Don't forget the attachment tags!!

Step 4: VPC Route Table Configuration

Each VPC must have a route to destination CIDRs pointing to Regional CNE

Step 5a: Core Network Policy configuration - Segments

1. Create the second segment 'Testing'

2. Ensure that both segment have appropriate CNEs

3. Isolated attachments are set to 'no' - It determines whether attachments on the same segment can communicate with each other.

Step 5b: Core Network Policy configuration - Segments Action

Attachments can be shared across segments - Attachments in segment 'Developement' can reach Attachment in segment 'Testing'

Step 5c: Core Network Policy configuration - Attachment policies

Attachment policies control how your attachments map to your segments. They are based on Tags, previously configured in Step 3.

Step 5d: Core Network Policy configuration - Execute the policy

And wait again for 20 minutes, grab a coffee and cook you a nice meal!!!!

Visualization

Topology Graph

Topology Tree

Logical

Use Case 1: DEV-EU, DEV-US & Test-US can communicate with each other (what we configured previously)

Use Case 2: DEV-US can communicate with TEST-US but is prevented from communicating with DEV-EU.

Segment 'Developement' must be set to 'yes' as 'Isolated Attachment' (and wait again)

Use Case 3: DEV-US & DEV-EU are allowed to communicate with each other but can't communicated with TEST-EU

You have to modify the policy by removing the sharing in 'Segment Action' (and wait again)

My feeling

• Product not mature (no target date in General Availability)
• Relies too heavily on TGW thus same limitations: segmentation @TGW RT (which you want to avoid)
• Complex to configure (in particular Core Network Policies (Visual Editor or JSON)
• Configuration is time consuming (20mn for the first CNP to be created)
• AWS itself does not recommend it for Production workloads
• Very difficult to remove existing Global Network
• Different menus to configure (Network Manager & VPC)

Cisco Cloud ACI

• Comprehensive solution for simplified operations, automated network connectivity, consistent policy management & visibility for multiple on-prem DCs & public clouds (sic)
• I just see it as an extension of Cisco ACI (on prem) with a mapping between the CSP & Cisco ACI

You escape into the cloud network: do you want to face (again) EPGs, Contracts, BDs & VRFs?

• Tagging
• Centrally managed
• Only supports AWS & Azure
• Not designed for many VPCs (same number of segregated domains as per AWS TGW RT!!)
• Cisco Nexus Dashboard Orchestrator provides policy management, network policy configuration & application segmentation definition

My feeling

• Licensing pricing is prohibitive!!  (#subscriptions = #endpoints !!!!)
• Do you think Cisco Cloud ACI is a durable solution for the Cloud Networking?
• Would you like to pay for an ACI on-prem extension to the Cloud?
• Do you still want to maintain your existing Security Groups and many Route Tables for that purpose? (Cisco Cloud ACI does not remove the burden of  these Cloud Native Constructs)
• Don't you think it is (after all) a central policy management relying on the CSP? What does it bring as added value?

AVIATRIX Segmentation

Principle

• Segmentation is @VPC level 
• Centrally managed & globally distributed
• Obviously cloud agnostic
• Segmentation can be extended to on prem workloads
• 200 Security Domains can be configured (unmatched on the market)

IT IS MULTICLOUD!!!

View from CoPilot of the Security Domains & their Connection policies (here SD Blue can communicate with SD Purple; SD Orange cannot communicate with the 2 others)

4-steps configuration process

1. Enable Transit for segmentation (plan)

2. Create Security Domains (plan)

3. Create Connection policy (plan)

Here, 'Production' Security Domain can communicate with 'DataCenter' & Shared Services' SD's.

4. Associate Spoke to Security Domain (build)

My feeling

• Simple, quick and efficient solution to deploy - honestly, you are just 2 clicks ago -- easy, & I like it! --
• Most powerful when it comes to numbers & capabilities
• Bundled into Aviatrix platform -- no hidden cost
• More granular control to come on segmentation with Aviatrix (today seamless NGFW insertion is also possible for more granularity)

CONCLUSION

At the technical level, if you want:

- the most mature product available in the market

- a cloud agnostic product across your MultiCloud

- the product with added capabilities (more Security Domains, more granularity)

- the product with no additional cost (Cisco Cloud ACI & AWS FW / Cloud WAN will add non negligible costs to your existing infrastructure)

- the simplest product to enable quickly your segmentation for your Cloud workloads

Then Aviatrix is the best pick... My 2 cents..

Maxime