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

Why Aviatrix is a very good fit for financial institutions and their cloud workloads?

In the Cloud, everybody has already heard about the 'Well-Architected Framework'.

It consists in 5-6 pillars / concepts essential to be satisfied to have an optimal Cloud Architecture and this, no matter the services consumed in the Cloud: it can be Database, Storage, etc.. or Network in our case..

If you work for a financial institution, what would be your best 2 picks among the 6 above? Don't get me wrong, they all are important in diverse degrees but 2 stand out...

Before a deep dive on these 2 dimensions, this is taken for granted that 'Compliance' & 'Governance' (of a new product, set of tools, features, etc..) are fulfilled according to financial company requirements.

- Compliance in business - state of meeting rules or standards. This is the process of making sure your company follow all laws, regulations, standards & practices that apply to the organization and its industry.

- Corporate Governance - refers specifically to the set of rules, controls, policies and resolutions put in place to dictate corporate behaviour.

AVIATRIX & Compliance

- PCI /DSS (Payment Card Industry / Data Security Standard) is an information security standard for financial organizations that handle branded credit cards from the major card scheme. Even if Aviatrix is not in-scope for PCI-DSS compliance because it does not process credit card information, nor has access to customer data's; it satisfies completely the PCI-DSS requirements (1, 2, 10 & 11) related to Networking.

- Aviatrix is compliant to FIPS140-2 (Federal Information Processing Standard). FIPS140-2 is a standard which handles cryptographic modules and the one that organizations use to encrypt data@rest & data-inTransit.

IPSEC is a good example with its standards around encryption and Integrity.

AVIATRIX & Governance

When a manufacturer or Editor sells its product to a financial institution for the first time, a preliminary Risk Assessment (RA) is performed to ensure it conforms rules & policies of the financial organization.  I personally witnessed a positive outcome to a RA between a financial institution and Aviatrix.

Every organization has its own Risk Assessment template, but 99% is about the same. An IT Vendor RA is a questionnaire that companies use to assess & vet their current & future vendors. It is designed to identify & evaluate the potential risks of working with a vendor.

Now, the pre-requisites having been discussed, let's go back to the initial question. What would be your 2 picks for financial organizations and well architected framework? 

1. SECURITY!!

By far, the most important!  For record, in the financial corporates, 10-15% of the FTEs focus solely on the Security aspects! They do not want data"s stolen or compromised by any means..

When it comes to Network Security in the Cloud, Aviatrix provides a complete solution to satisfy the most demanding financial institutions. There is no need to have a 3rd party for FQDN filtering + a complicated solution for Segmentation for instance, Aviatrix provides all in the simplest way. 

Please see my first blog (Security use Cases) talking about Network Segmentation, NG-FW insertion and FQDN filtering). 

But Network Security with AVIATRIX is much more.

THREATIQ with THREATGUARD

Internet access is everywhere in the Cloud. If you want to protect your business from security risks like Data Exfiltration, DDoS or Compromised hosts, then ThreatIQ with ThreatGuard is the perfect tool: it dynamically identifies, alert & remediate potential threats to known malicious destinations without impacting your data plane.

THREATIQ with NBA (Network Behaviour Analytics)

It continuously fingerprints your workloads and network traffic, offering improved accuracy & anomaly detection over time. It highlights any indicator of compromise & quickly locates and remediates anomalous behaviours as a result of Data exfiltration, DDoS or port scanning for example.

 

Cloud Network Security with Aviatrix: bottom line

2. RELIABILITY

 AVIATRIX Multi Cloud Resiliency

Aviatrix and its Transit Layer with Transit Peering between its Highly Available Transit Gateways from different Cloud Service Providers builds a highly resilient & secured (multiple IPSEC tunnels) MultiCloud network infrastructure.

Aviatrix Active Mesh or the concept of using all available links

Every Aviatrix Gateway can be configured in HA (high availability) mode. By default, Active Mesh is enabled on every Transit & Spoke Gateways. This builds again multiple IPSEC Tunnels between Transit & Spoke leveraging ECMP (Equal Cost MultiPath). With most of the scenarios, the convergence time is 'none'.

The second scenario (with primary Spoke GW failure) is the only one where convergence time occurs (~10-15 seconds).

These were simple thoughts from an ex-IT cloud network engineer in the financial industry having had strict requirements when designing IT Network infrastructures but more in-depth to come soon in Tech Talks with my colleagues Paul Carvill (Principal Solutions Architect) and John Gonsalves (Principal Field Evangelist).

Maxime