Cloud Firewall Design Rationale

[wanartisan]

Hi,

Since I've been working in the cloud (about a year), I've noticed firewall design patterns are somewhat different, using a separate ingress and egress firewall/cluster, rather than a two-tier design more often seen on prem (although I have seen user traffic using a different firewall from server traffic, although there was still an internal tier).

What I haven't seen is a rationale for why this is the design choice for vendors. I first saw it with the Check Point CloudGuard architectures but I have seen a similar thing with Cisco's new Multicloud Defense aquisition.

Anyone have any guidance or links on the reason for this design preference?

Thanks in advance. 

[the_rock]

Since Im sort of obligated to say this now, as its AI answer, and should be taken with the grain of salt, but here it is : - )

Andy

*****************************

A Cloud Firewall Design Rationale explains the reasoning behind the architecture, components, and strategies used to secure cloud infrastructure using firewall technology. It ensures that firewall controls align with organizational security policies, compliance requirements, and cloud-native best practices.

Here’s a structured outline of a typical Cloud Firewall Design Rationale:

---

1. Purpose

Define the objective:

• Protect cloud workloads from unauthorized access.

• Enforce segmentation between environments (e.g., dev/test/prod).

• Meet compliance (e.g., PCI DSS, HIPAA, GDPR).

• Centralize control over ingress/egress traffic.

---

2. Assumptions

• The cloud provider (e.g., AWS, Azure, GCP) offers native firewalling capabilities.

• Workloads are distributed across multiple regions/zones.

• Use of Infrastructure-as-Code (IaC) for firewall rule deployment.

• Teams follow a shared responsibility model.

---

3. Firewall Types and Placement

a. Network Firewalls (Perimeter)

• Deployed at VPC/VNet boundaries.

• Inspect north-south traffic (external-internal).

b. Host-based Firewalls

• Installed on VMs/instances.

• Manage east-west traffic or workload-specific rules.

c. Web Application Firewalls (WAF)

• Protect against HTTP(S) threats (OWASP Top 10).

• Often placed in front of load balancers or APIs.

d. Cloud-native Firewalls

• e.g., AWS Network Firewall, Azure Firewall, GCP Cloud Firewall.

• Used for centralized policy enforcement.

---

4. Design Considerations

a. Scalability

• Stateless/stateful firewalls must auto-scale with demand.

• Use autoscaling groups or managed services.

b. High Availability

• Use zone-redundant or regionally distributed firewalls.

• Avoid single points of failure.

c. Logging and Monitoring

• Enable logging of accepted/denied traffic.

• Integrate with SIEM or cloud-native monitoring (e.g., CloudWatch, Azure Monitor).

d. Policy Management

• Use tags, labels, or security groups for dynamic rules.

• Maintain least privilege access principles.

---

5. Rule Management Strategy

• Whitelist-based approach: explicitly allow necessary traffic, deny all else.

• Automated provisioning via Terraform, ARM templates, or CloudFormation.

• Version control and peer review of rules.

---

6. Security Zoning

• Define zones: Internet, DMZ, Internal, Restricted.

• Control flow between zones using firewall policies.

---

7. Cost Considerations

• Evaluate cost of traffic inspection and logging.

• Optimize placement to avoid unnecessary data transfer charges.

---

8. Compliance and Governance

• Ensure firewall policies support compliance (PCI, ISO 27001).

• Periodic audits and automated compliance checks.

---

9. Example Use Case Scenarios

• Public API gateway protected by WAF and rate-limited.

• Internal database subnet with strict IP whitelisting.

• Egress firewall filtering to prevent data exfiltration.

[Don_Paterson · Accepted solution]

I had a lot of head scratching moment too when I saw public cloud designs and proposals, and the CloudGuard Blueprints. 

https://www.checkpoint.com/downloads/products/cloudguard-architecture-blueprint-diagrams.pdf

It comes down to the design and limitations of the public cloud, and vendors having to fit in with how it is in the cloud. 

In some ways it seems like networking was reinvented with the introduction of public cloud. 

SDN and virtualisation brings all sorts of new capabilities to networking.

For example, microsegmentation and traffic steering allows two hosts on the same subnet to be isolated at layer 2 by steering the traffic to the VNA for policy enforcement. 

That's not new though, VMware NSX offered that for on premises private cloud about a decade ago but it's SDN so public cloud uses the same capabilities. 

Of course the cloud comes with its own language and acronyms, like Virtual Network Appliances (VNA) and Workloads. 

It's not a crime to say Firewall and Virtual Machines in my world. 

Of course serverless and other Workloads are needing new terminology and acronyms. 

I joke about the book seller and an operating system vendor reinventing networking and throwing traditional networking out the window but again the reality is that SDN and SDDC are different and traffic handling and steering is enhanced.

AWS was first to offer a VM in the cloud and get the whole public cloud offerings going and it was them who defined the Well Architectected framework for cloud. 

It's effectively a series of blue prints (available in Kindle format of course) and offers customers (and potential customers) guidance for designing, deploying and maintaining in their cloud. 

Someone else's computer. 

Imagine you're going to deploy your IT assets and network in someone else's DC. You'd need to clearly define the agreement and work within their DCs capabilities and limitations. And you'd want the well documented. Well Architected.

https://aws.amazon.com/architecture/well-architected/

The public cloud is relatively new still and evolution is fast. That actually puts a burden on vendors like Check Point to reprogram their products to fit into new public cloud offerings (vWAN and GWLBs come to mind)  

They are also having to advise the CSPs on how they can improve in some cases. Calling on multiple decades of experience to advise the CSPs how networking and network security is best done.

A 7 minutes ClusterXL failover time comes to mind, when the cloud's APIs took 7 minutes to redirect the traffic following a ClusterXL failover, as it was in the early days. 

It's an interesting evolution to witness but keeps cloud customers on their toes, redesigning and redeploying (or not) to keep up with the cloud, and the cost savings potential. Or getting burned by excess costs, facing the disappointment and rethink the cloud approach. It happens. 

Check Point has 100,000 + customers but only 5k or maybe more, <10k (?), in the cloud (CloudGuard is a big family of products) so it is still early ish in terms of cloud adoption, with a growing trend and cloud first approach. 

My 2 cents (first draft) 

Hope that helps,

Don

[Don_Paterson]

The CG NW Blueprints are a result of the public cloud dictating/recommending topology and the vendor matching it with their solution melted into it. 

[the_rock]

Way better than AI answer : - )

Andy

[wanartisan]

Appreciate the response; however, I'm still not seeing the rationale. The closest I'm getting is the CSPs said it should be like that? What was their rationale? The cynic in me was thinking it is just a way to sell more firewall licenses....

Of course, you can still do two-tier designs in the cloud, but I haven't seen them recommended. 

Note: I tried AI too before I came here, but did not get a satisfactory response 🙂

[the_rock]

I would suggest maybe ask your local SE about it, but if you dont like their answer either, definitely open TAC case. Otherwise, lets see if anyone else responds here.

Andy

[Don_Paterson]

The CSP is indeed dictating the way it is. 

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/traditio...

[Don_Paterson]

Ask your Check Point rep to run you through the comparison between CSP firewall Threat Prevention offerings, and the cybersecurity vendor TP offerings and catch rate. 

That's one of the main drivers to go with a dedicated cybersecurity vendor. 

There is flexibility in how cloud SGs are deployed. A cloud solution can deal with network security in similar ways to an on prem SG, but the cloud is different and offers unique solutions that the traditional IT solutions don't. Security needs to be able to fit in with the rest of the solution. 

BYOL and PAYG models show the dynamic nature of the cloud and show how it may be advantageous to use cloud in some cases. 

[Don_Paterson]

AI can be a real disappointment at times. 

I got this, and it makes sense so I thought I'd share it. 

 Let's break down why cloud environments often use separate ingress and egress firewalls/clusters instead of the traditional two-tier design seen on-premises.

1. Cloud vs. On-Premises Environments:

In on-premises environments, firewalls are typically designed to handle both incoming (ingress) and outgoing (egress) traffic within a single or two-tier setup. This works well because the network infrastructure is static and controlled.

In cloud environments, however, the infrastructure is dynamic and scalable. Resources can be spun up or down based on demand, and they are often distributed across multiple regions or zones. This requires a different approach to network security.

**2. Separation of Ingress and Egress Traffic**:

- **Ingress Firewalls**: These are responsible for filtering and securing incoming traffic from the internet or other external sources. They ensure that only legitimate and authorized traffic reaches your cloud resources.

- **Egress Firewalls**: These handle outgoing traffic from your cloud resources to the internet or other external destinations. They help prevent data exfiltration and ensure that only authorized traffic leaves your network.

**3. Benefits of This Design**:

- **Scalability**: Cloud environments need to scale quickly to handle varying loads. By separating ingress and egress firewalls, each can be scaled independently based on the specific traffic patterns they handle.

- **Security**: Different types of traffic have different security requirements. Separating ingress and egress traffic allows for more granular and specialized security policies.

- **High Availability**: Cloud providers often distribute resources across multiple zones or regions to ensure high availability. Separate firewalls can be deployed in a way that supports this distribution, reducing the risk of a single point of failure.

**4. Vendor-Specific Implementations**:

- **Check Point CloudGuard**: This architecture leverages separate firewalls to provide robust security for cloud environments. It allows for centralized management and policy enforcement across different cloud platforms.

- **Cisco Multicloud Defense**: Similar to Check Point, Cisco's solution also uses separate ingress and egress firewalls to enhance security and manageability in multi-cloud environments.

For more detailed information, you can refer to the following resources:

- [Azure Firewall Architecture Overview](https://learn.microsoft.com/en-us/azure/architecture/example-scenario/firewalls/) 

- https://sc1.checkpoint.com/documents/CloudGuard_SaaS_GettingStartedGuide/210099.htm [2]

[Jeff_Engel]

Hi @wanartisan , he is the very short version.  The two-tier design comes down to traffic flows, risk mitigation, and capabilities that match the needs of what it is you are designing for.

For example in Azure we have a number of available architectures but they all have their pros and cons.  If you are protecting a web application that sees variable spikes in usage, it makes sense to deploy VMSS in front of it.  But VMSS doesn't support S2S VPN.

For E/W and traffic destined back and forth to HQ, it may make more sense to deploy High Availability or Virtual WAN for the VPN support and because the traffic loads are more of a known commodity.

Now take into account maintenance(patching and upgrades), instead of having all traffic for all traffic types flowing through a single choke point and the potential impact, you can do maintenance on one or the other at a time of your choosing.

Regarding licensing, we price CloudGuard Network Security on cores allocated(BYOL) or PAYG...so in comparison to one very large cluster versus a dynamically adjusting scale set or consumption or core-based configuration you are actually optimizing for what you actually need.

At the end of the day, please reach out to your account team who can and will connect you with one of our Cloud Architects to help design what makes the most sense for your particular use case.

Hope this helps!

BR!

Jeff