CFW High Availability Specification
Last updated:2026-01-23 17:12:54
Cloud Firewall (CFW) is a SaaS-based firewall built on a cloud-native architecture, providing unified security policy management and threat protection for enterprise cloud services. The product adopts a highly available design, delivering continuous security assurance for your business through core technologies such as multi-AZ deployment, distributed clusters, real-time health checks, and automatic failover, while minimizing impact on business traffic.
Cloud Firewall (CFW) provides diverse deployment modes to accommodate protection requirements across different network boundaries and business scenarios. Each mode has its own focus in terms of architecture and availability design, allowing you to make selections based on your actual business needs.
Internet Firewall
Architecture Design
This product adopts a high availability architecture design, aimed at ensuring service continuity and effectively handling various failure scenarios.
Multi-(AZ) deployment: Adopting a cross-AZ active-active architecture, firewall cluster instances are distributed across multiple (AZ)s. When a failure occurs in any AZ, it supports automatic and seamless switchover of business traffic to other healthy AZs, thus maximizing service continuity and high availability.
Distributed processing architecture: Adopting a distributed cluster architecture, client sessions will be load-balanced across multiple processing nodes within the cluster. This design not only effectively handles traffic surges but also achieves fault isolation: When a single machine fails, it only affects a small number of sessions being processed, which will be automatically rescheduled to other healthy nodes for recovery after client reconnection.
Access Impact
Second-level seamless access: Diverts traffic to the firewall by adding a single hop to the existing traffic path. This process requires no routing table modifications, thus without interrupting existing network sessions. Leveraging standard TCP/IP retransmission mechanisms, the entire access process remains transparent to the business network, causing no perceptible jitter or interruption to services.
Failover and Self-Healing
Node-level self-healing cluster: The management plane monitors each data plane node through real-time heartbeat detection. Upon detecting an abnormal node, the scheduling system will remove it within seconds and redistribute its traffic to healthy nodes using the (Re-hash) algorithm, achieving second-level fault isolation.
Session state synchronization: The cluster employs distributed session synchronization technology. During normal operation, session states are continuously synchronized across all nodes. When a single-node failure occurs and triggers traffic migration, the newly taking-over node can recognize and inherit the original session state, ensuring that most TCP long connections remain uninterrupted and achieving a seamless switchover imperceptible to users.
NAT Firewall
Architecture Design
NAT Firewall provides two deployment modes to meet different users' network architecture and security management requirements.
New mode: The firewall directly undertakes the NAT Gateway functionality, with public IP addresses (EIP) mounted on the firewall instance. This simplifies the network topology and enables unified management of security and networking features.
Deployment mode: The firewall is deployed in series between the Cloud Virtual Machine (CVM) and the existing NAT Gateway, serving as an intermediate hop for traffic scrubbing. This retains the user's existing NAT Gateway architecture and achieves smooth security reinforcement.
Access Impact
The impact of the access process varies depending on the deployment mode. It is recommended to choose an appropriate timing for the operation based on business sensitivity.
New mode: In this mode, EIPs are hosted by the firewall instance. To achieve high availability, it is recommended to configure an additional standard NAT Gateway as a backup egress. When the firewall fails, traffic can be redirected to the backup NAT Gateway by switching the standby route.
Note:
This switchover will result in changes to the egress EIP. Please assess whether your business can accommodate the following impacts:
1. Active network connections established through the original EIP will be interrupted, requiring clients to reconnect.
2. If third-party services (such as databases or APIs) have added the original EIP to their access allowlist, the EIP of the backup NAT Gateway must also be added to the allowlist in advance. Otherwise, access will be denied after the switchover.
3. If your business domain name resolves directly to this EIP, you need to synchronously update the DNS records.
Deployment mode: Brief network jitter may occur during implementation. As the next hop in the VPC routing table needs to be modified, the deployment process typically causes 1-2 seconds of network jitter, which may interrupt established long-lived connections (such as database connections or long polling).
Note:
It is recommended to perform the operation during off-peak business hours to minimize the impact on sensitive services.
Failover and Self-Healing
Disaster recovery in the new mode: Achieved through backup route switching. When the NAT Firewall fails, traffic can be switched to the backup NAT Gateway.
Note:
This switchover will result in changes to the egress EIP. Please assess whether your business can accommodate the following impacts:
1. Active network connections established through the originalEIP will be interrupted, requiring clients to reconnect.
2. If third-party services (such as databases or APIs) have added the original EIP to their access allowlist, the EIP of the backup NAT Gateway must also be added to the allowlist in advance. Otherwise, access will be denied after the switchover.
3. If your business domain name resolves directly to this EIP, you need to synchronously update the DNS records.
Disaster recovery in access mode: Supports primary/secondary switching and automatic bypass. When the firewall fails, the system will automatically point the next hop of the subnet route to the original NAT Gateway, allowing traffic to completely bypass the firewall and ensuring uninterrupted network connectivity.
Manual Bypass mechanism: Provides emergency response capability. In critical situations such as service misinterception or the need to temporarily restore maximum network performance, users can manually enable the Bypass feature to allow traffic to directly pass through along the original path, temporarily bypassing security inspection.
VPC Firewall (Cluster - Multi-route Table)
Architecture Design
VPC Firewall provides security protection for inter-VPC traffic through routing-based traffic steering and is built on an elastic and scalable distributed architecture.
Traffic steering principle: By dynamically modifying the default route table of the VPC, inter-VPC traffic to be protected is actively steered to the firewall cluster for security inspection.
Distributed cluster architecture: Employs a distributed cluster deployment model, leveraging a self-developed intelligent scheduling algorithm to load-balance traffic across multiple firewall engines within the cluster for parallel processing. When facing business traffic surges, the cluster can automatically scale elastically, effectively avoiding single-point performance bottlenecks.
Access Impact
VPC Firewall adopts a traffic steering mode, and the access process involves dynamic adjustments to routing policies. The specific impacts are as follows:
Network jitter: During Firewall Toggle activation, the underlying network undergoes routing convergence, typically resulting in 1-2 seconds of brief network jitter or latency.
CVM mutual access experience: For CVM mutual access across VPCs or between subnets within the same VPC, the network will not be interrupted. Based on the TCP/IP protocol's retransmission mechanism, this is typically perceived at the service level as a brief fluctuation in latency.
PaaS service impact: For PaaS services (such as databases and middleware) connected via (CCN), established long-lived connections may be interrupted during the traffic switching process, requiring the service side to implement reconnection mechanisms.
Failover and Self-Healing
Node-level self-healing cluster: The management plane monitors each data plane node through real-time heartbeat detection. Upon detecting an abnormal node, the scheduling system will remove it within seconds and redistribute its traffic to healthy nodes using the (Re-hash) algorithm, achieving second-level fault isolation.
Session state synchronization: The cluster employs distributed session synchronization technology. During normal operation, session states are continuously synchronized across all nodes. When a single-node failure occurs and triggers traffic migration, the newly taking-over node can recognize and inherit the original session state, ensuring that most TCP long connections remain uninterrupted and achieving a seamless switchover imperceptible to users.
Link-level bypass protection: In extreme scenarios (such as complete cluster unavailability), the system features an automatic Bypass mechanism. Upon detecting a failure, the (CCN) will automatically withdraw traffic steering routes, reverting traffic to the original path and ensuring fundamental connectivity.
Manual Bypass mechanism: Provides emergency response capability. In critical situations such as service misinterception or the need to temporarily restore maximum network performance, users can manually enable the Bypass feature to allow traffic to directly pass through along the original path, temporarily bypassing security inspection.
VPC Firewall (Cluster - Policy-based Routing)
Architecture Design
VPC Firewall's policy-based routing achieves service-unaware secure access through intelligent traffic steering technology.
Traffic steering principle: Cloud Firewall (CFW) automatically deploys routing policies, intelligently steering inter-VPC traffic requiring protection to the firewall cluster through policy-based routing, without requiring modifications to the user's existing route tables.
Distributed cluster architecture: Employs an elastic distributed cluster architecture, utilizing an intelligent scheduling algorithm to achieve load balancing of traffic across multiple firewall engines. Supports automatic elastic scaling to effectively handle business traffic fluctuations and avoid single-point performance bottlenecks.
Access Impact
Policy-based routing employs non-intrusive traffic steering technology to minimize impact on services:
Service-unaware access: Achieved through non-intrusive traffic steering technology, avoiding direct modifications to underlying network route tables, thereby maintaining the stability of the existing network architecture.
Zero-Jitter Deployment: The onboarding process aims to avoid business-perceivable network jitter or connection interruptions, achieving a smooth launch that is nearly imperceptible to the business side.
Real-time effect: Policies take effect immediately upon configuration without requiring business interruption or coordination.
Failover and Self-Healing
Node-level self-healing cluster: The management plane monitors each data plane node through real-time heartbeat detection. Upon detecting an abnormal node, the scheduling system will remove it within seconds and redistribute its traffic to healthy nodes using the (Re-hash) algorithm, achieving second-level fault isolation.
Session state synchronization: The cluster employs distributed session synchronization technology. During normal operation, session states are continuously synchronized across all nodes. When a single-node failure occurs and triggers traffic migration, the newly taking-over node can recognize and inherit the original session state, with the goal of maintaining TCP long-lived connection states. This reduces connection interruptions caused by node failures and achieves seamless switchover.
Link-level bypass protection: In extreme scenarios (such as complete cluster unavailability), the system features an automatic Bypass mechanism. Upon detecting a failure, the (CCN) will automatically withdraw traffic steering routes, reverting traffic to the original path and ensuring fundamental connectivity.
Manual Bypass mechanism: Provides emergency response capability. In critical situations such as service misinterception or the need to temporarily restore maximum network performance, users can manually enable the Bypass feature to allow traffic to directly pass through along the original path, temporarily bypassing security inspection.
VPC Firewall (Primary/Secondary)
Architecture Design
VPC Firewall (Primary/Secondary) provides secure protection for inter-VPC traffic by means of route table-based traffic steering, delivering reliable security assurance for enterprise cloud networks.
Traffic steering principle: By dynamically modifying the default route table of the VPC, inter-VPC traffic requiring protection is actively steered to the VPC firewall cluster for security inspection and Access Control.
Access Impact
VPC Firewall (Primary/Secondary) employs the route table-based traffic steering approach. The onboarding process entails adjustments to network routing, with specific impacts as follows:
Brief route convergence jitter: The enabling operation triggers dynamic route rule publishing, causing 1~2 seconds of network jitter during the brief period when routes take effect. This is a normal technical phenomenon; it is recommended to perform this operation during off-peak business hours.
Business access perception: This jitter has minimal impact on most services. Mutual access between Cloud Virtual Machines (CVMs) (whether across VPCs or within the same VPC) will not be interrupted, only experiencing brief delays; short-connection services typically remain imperceptibly affected.
Long-lived connection interruption risk: For PaaS services such as databases and message queues connected through Cloud Connect Network (CCN), their established TCP long-lived connections are highly likely to be interrupted during the switchover process. This represents the primary risk point.
Note:
Before enabling VPC Firewall (Primary/Secondary), be sure to verify and ensure that your application supports automatic reconnection/retransmission mechanisms for long-lived connections to prevent service abnormalities.
Failover and Self-Healing
Cross-AZ active-active disaster recovery: Supports distributing firewall cluster nodes across multiple (AZ)s within the same region. When a failure occurs in any AZ, traffic is automatically routed to healthy AZs, achieving AZ-level failover and ensuring business continuity.
Manual Bypass mechanism: Provides emergency response capability. In critical situations such as service misinterception or the need to temporarily restore maximum network performance, users can manually enable the Bypass feature to allow traffic to directly pass through along the original path, temporarily bypassing security inspection.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback