Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

How can I implement centralized firewalling with a next-generation firewall in AWS, Azure and GCP?

Distributed vs. Centralized Architectures

In a distributed architecture, firewalls are placed in each VPC (Virtual Private Cloud) or VNET (Virtual Network) to provide security at the perimeter of each individual network segment. This approach allows for granular control over traffic but can lead to increased management overhead and complexity, as firewall configurations must be maintained for each VPC or VNET.

In contrast, centralized firewalling leverages “inspection VPCs” or “hub VNETs” that serve as a centralized security hub for traffic inspection and management across all VPCs or VNETs in the cloud environment. Some benefits of centralized architectures include simplified management, reduced firewall sprawl, and consistent security policies across multiple network segments.

However, centralized architectures also have disadvantages, such as additional routing complexity and increased data transfer costs due to the need to route traffic through the centralized inspection VPCs or VNETs.

PaaS Firewalls vs. Virtual Firewall Offerings

PaaS offerings like AWS Firewall and Azure Firewall provide basic firewall services within their respective cloud environments. They offer features like application and network-level filtering, automatic scaling, and integration with other native cloud services. While they provide benefits like automatic scaling and eliminate requirements for load-balancers, they are often more complex to configure and because cost is partially based on data transfer, the total cost is difficult to predict.

Virtual firewall offerings from companies like Palo Alto, Fortinet, and Checkpoint offer next-generation firewall capabilities, such as deep packet inspection, intrusion prevention, and advanced threat protection. These virtual firewalls can be deployed across multiple cloud providers, providing a consistent security posture and advanced features across AWS, Azure, and GCP.

Centralizing Firewalls with Native Networking Components

It is possible to build centralized firewalling architectures in each of the clouds leveraging several similar building blocks.

Inspection VPC or Hub VNET

Inspection VPC or Hub VNET is a dedicated VPC/VNET created to host next-generation firewall instances for traffic inspection and filtering. The inspection VPC acts as a central hub for managing and enforcing security policies across multiple VPCs within the cloud environment. In AWS, this is a VPC that connects to a Transit Gateway. In Azure, it is hub VNET to which all other application VNETs peer. In GCP, its somewhat more complicated with multiple VPCs and firewalls that have interfaces bridging VPCs.

Subnets and Firewall Instances

The inspection VPC contains multiple subnets, ideally spread across different availability zones for redundancy and high availability. Each subnet hosts firewall instances from your preferred vendor (e.g., Palo Alto, Fortinet, or Checkpoint) that are responsible for inspecting and filtering traffic based on the defined security policies.


Load-balancers sit in front of the Firewall instances to provide HA and Scalability while maintaining flow symmetry. With AWS, and the Gateway Load Balancer, traffic is encapsulated to the firewalls leveraging the GENEVE overlay protocol which requires explicit support from the firewall vendor. In Azure an Internal Load Balancer can connect to firewalls without requiring specific support from the firewall vendor.

Native Networking to Connect VPC/VNETs

In AWS this is often AWS Transit Gateway. In Azure it is VNET peering. In an Azure hub VNET architecture, the Firewalls also act as routers and route traffic from VNET to VNET, serving one of the functions of AWS Transit Gateway. In both scenarios, the connectivity between VPCs and the centralized firewalls accrues data transfer cost, which is one of several drawbacks of centralized firewall architectures.

User-Defined Routes and Route Tables

Once the pieces are in place, custom routes and route tables must be applied to force traffic to the firewall. This can be relatively simple for a centralized egress design but may require an individual route table per VPC for East-West inspection with AWS and complex UDRs in each VNET in Azure. While routing might start simple, it can grow in complexity quickly as security requirements evolve.

While possible, each solution requires a lot of manual complexity to configure and maintain and grows with complexity as the solutions scale. While the pieces are similar, there is almost no overlap in Terraform configuration between the different architectures. Firewalls can quickly become bottlenecks, and each come with unique complexities especially when selective inspection is required.

Aviatrix Firenet

Aviatrix Firenet is a cloud networking and security solution that simplifies the implementation of centralized firewalling across multiple cloud providers reducing the provisioning time from months to hours providing flexibility and simplifying day 2 operations as security requirements evolve.

Consistent Secure Perimeter Architecture

Aviatrix Firenet provides a consistent secure perimeter architecture across AWS, Azure, GCP, Oracle Cloud and Alibaba.

Eliminates Complex Manual Routing Requirements

Aviatrix Firenet automates routing and traffic steering, reducing the complexity of implementing firewall policies and ensuring that network traffic is compliant and flows through the

firewall as intended. Individual VPCs can easily be marked for inspection without changing route tables or UDRs. This is especially important in multi-cloud environments where cloud-native offerings might require manual routing configuration.

Automates Firewall Provisioning and Embeds

Aviatrix Firenet automatically creates firewall instances to that they are properly configured, and integrates load-balancing either by automatically deploying native components or leveraging embedded, and symmetric load-balancing capabilities in the Aviatrix Transit Gateways.

Integration with Firewall Vendors of Choice

Aviatrix Firenet integrates with leading firewall vendors, such as Palo Alto, Fortinet, and Checkpoint, allowing customers to choose the firewall that best fits their needs while still benefiting from the centralized, automated management provided by Aviatrix. This integration also enhances the chosen firewall solution by providing a consistent architecture that can scale with demand.

Centralized Security Designs with Aviatrix Firenet

Aviatrix Firenet can be used to centralize various security aspects, including:

  • Egress Security: By centralizing egress security, Aviatrix Firenet simplifies the management of outbound traffic to the internet.
  • East-West Security: Aviatrix Firenet helps secure traffic between VPCs or VNETs, enabling better control and visibility over internal traffic.
  • Ingress Security: Aviatrix Firenet supports centralized ingress security designs, such as “cloud DMZs,” to protect cloud resources from inbound threats.

Aviatrix Secure Egress

Aviatrix Secure Egress provides comprehensive egress security for outbound internet traffic. It can be deployed in a distributed architecture for individual VPCs or VNETs or integrated with Aviatrix Firenet to centralize Internet Egress Security.

In summary, implementing centralized firewalling with a next-generation firewall in AWS, Azure, and GCP can be achieved using a combination of cloud-native offerings and virtual firewall solutions from leading vendors. The Aviatrix Firenet solution stands out as a superior option, providing a consistent secure perimeter architecture, automated routing, integration with the customer’s firewall vendor of choice, and a scalable architecture that can adapt to changing needs. Additionally, Aviatrix Firenet can be used to centralize egress, east-west, and ingress security, further simplifying the management and protection of cloud resources. Aviatrix Secure Egress offers an additional layer of security by allowing for domain-based egress filtering, which can be deployed in a distributed architecture or integrated with Aviatrix Firenet to centralize Internet Egress Security.