Network Security Solutions in a Multicloud Environment

As organizations increasingly run internet-facing web applications in the public cloud, ensuring the security of sensitive financial and personal data becomes critical. Beyond basic security measures, intrusion detection and prevention systems (IDPS) on the network layer are essential. After working with both AWS and Azure to implement these solutions for several clients, I’ve observed significant differences between the two. This blog offers insights and guidelines to help you navigate these differences and work towards a more unified approach to network security in a multicloud environment

Start with native solutions 

When deploying new functionalities, it’s logical to first explore the native services provided by your cloud service provider. These services manage scaling, software updates, availability, and signature updates, among other things. Azure and AWS, the leading public cloud platforms, offer their own IDPS solutions: Azure Firewall Premium and AWS Network Firewall with Managed Rules. 
 
While both provide robust IDPS options, their architectures are notably different. 

• Azure Firewall Premium: Typically, you deploy a single firewall instance in a Hub Virtual Network (VNet) or Vwan Hub, assign it a private IP, and use route tables to direct traffic. 

• AWS Network Firewall: On AWS, you work with multiple Firewall Endpoints, offering far more flexibility. While this flexibility is a strong point, it also complicates cost estimation, making AWS solutions less predictable compared to Azure’s more straightforward pricing 

More complexity differences 

In one recent project, we deployed a multicloud landing zone with IDPS enabled on both AWS and Azure. On Azure, enabling IDPS in Azure Firewall Premium is as simple as flipping a switch in the portal or adding a single line of Terraform code. You can choose between running in Alert mode or Deny mode, and the firewall compares network traffic against a growing database of 70,000+ threat signatures. Tweaks like configuring bypasses for false positives or adding TLS inspection can be made later, but the core setup is fast and easy. 

As stated, AWS allows multiple network security architectures, for this customer we decided on the centralized ingress/egress deployment, which is fairly straightforward. AWS native IDPS is implemented by adding so called ‘managed firewall rules’ next to your own custom source-destination-protocol-port rules. These managed rules are based on the Suricata open source IDPS project, and actively maintained, again after adding a rule to your firewall policy you need to choose whether it needs to Alert or Block any hits. But it quickly becomes more complex. 

IDPS rules come in two main types: 

1. Domain and IP Rule Groups: Target domains and IPs associated with botnets, malware, or suspicious activity. 

1. Threat Signature Rule Groups: Analyze network traffic patterns for known threats. 

 There are 4 Domain and IP and 16 Threat Signature rule groups. To start with you have to decide and actively configure the location and processing order of these managed rules, whether it is applied to all traffic passing the firewall, or just east-west or north-south. This is done by choosing and assigning the appropriate rule group priority. 

Making choices

But we’re not there yet, every Firewall Policy has a maximum capacity limit of 30.000 units for both stateless and stateful rules. Any stateful rule is one capacity unit, but you have to reserve (and therefore already consume) sufficient capacity units for every custom rule group you created. For stateless rules the capacity is calculated on the number of matching criteria you define so it’s more calculation work. No match criteria (Any or All) have a complexity of 1. If you do have match criteria let’s say two source CIDR ranges, one destination CIDR range, one protocol (for example TCP or UDP) and one port number, those add up to 2*1*1*1=2. You see that as soon as you add more match criteria, multiplying them can quickly add up to more capacity consumption. Besides that, every Managed Rule Group you want to add for IDPS functionality also consumes a fixed number of capacity units, and these can also add up quickly. I have not found these Capacity Units documented anywhere, only in the AWS Console, so I’ll include them here for reference: 

As you can see the total is already well over 30K, so it’s impossible to include all of them in one firewall policy, which implies making choices. This means you need to be very well aware of the types of workloads you are running and threats that are most likely to affect them, which requires specialized security knowledge. A counter in the AWS Console will keep track of your Policy capacity consumption: 

A possible way to work around this capacity limit is defining all managed rule groups as Stateful rule groups, and only using Stateless capacity for all of your custom rules. However stateless rules are much less user friendly, as it only allows traffic in one direction, not automatically allowing return traffic, as stateful rules do, therefore not a great workaround. Since you can only attach one Firewall Policy to a Network Firewall instance, there’s no way increasing the unit limit. 

Finally this is not the only limitation, every Firewall Policy has a hard limit of 20 stateless and 20 stateful rule groups, so even when the capacity limit would not be present, adding all managed rules to your policy would not allow any room for custom stateful rule groups. Besides the AWS managed rules you also have the option to add rules managed by some well-known security providers, which makes the whole capacity calculation and estimation exercise even more complex. If like me you are deploying through TerraForm and try to add more than 20 Rule Groups, you will get the following error:  

 InvalidRequestException: StatefulRuleGroupReferences limit exceeded, parameter: [22], context: StatefulRuleGroupReferences 

The limits imposed here are quite restrictive, making this solution unsuitable for enterprise-level usage. While it’s possible to create multiple network firewalls and define various firewall policies, this approach may not align with your chosen firewall architecture. In addition to planning the placement of Firewall Endpoints within your network architecture, you must carefully manage policy capacity for custom rules. Then, you'll need to prioritize the most critical threats to your cloud workloads and determine which managed rules to activate accordingly. This process is starkly different from how Azure handles it. And that's without even considering the costs, since each Firewall Endpoint adds to your monthly expenses.

Let's go multicloud

For enterprises operating in a multicloud environment, the complexity multiplies. Each cloud provider’s IDPS requires different knowledge and expertise, resulting in varied network security implementations. For example, a web app protected in Azure might not have the same level of protection in AWS due to capacity or rule prioritization issues. 

Wouldn’t it be ideal to have a unified solution across all clouds? 

A universal solution: Aviatrix Distributed Cloud Firewall 

Enter Aviatrix, a platform built for multicloud environments. Aviatrix integrates seamlessly with all native cloud services, offering a Distributed Cloud Firewall that provides centralized visibility and management, regardless of whether your workloads are in AWS, Azure, or another cloud provider. 

By using Aviatrix Gateways, you can easily activate IDPS features. Aviatrix also introduces SmartGroups, which allow logical grouping of similar workloads across clouds for micro-segmentation. With Aviatrix, all network security features are controlled via the CoPilot console, which acts as a single pane of glass for your entire multicloud environment. 

Unlike centralized architectures in Azure and AWS that route all traffic through a central firewall, Aviatrix distributes traffic inspection across multiple VNet or VPC gateways. This distributed approach not only catches threats earlier but also reduces the likelihood of bottlenecks, improving performance and resilience. 

Enterprise-grade features 

Aviatrix is designed for enterprise use, supporting: 

• Up to 500 SmartGroups 

• 3,000 CIDRs per SmartGroup 

• 2,000 rules per policy 

• Overlapping IP ranges 

These capabilities ensure that Aviatrix offers the scalability and flexibility needed for large, complex environments. 

Conclusions 

If you’re working within a single cloud, enabling IDPS can be straightforward—though AWS requires more effort compared to Azure. However, when you move to a multicloud setup, differences in architecture, limitations, and customization options can make network security management significantly more complex. 

Aviatrix provides a compelling solution for multicloud environments, combining the best of both AWS and Azure: Azure’s simplicity and AWS’s distributed architecture. With lower costs, centralized management, and powerful customization features like SmartGroups, Aviatrix is an excellent option for organizations looking to bolster their network security across clouds.