By Jeff Engel, Technical Marketing Engineer for Cloud Security, published December 19, 2022

Most organizations want to provide the best service for customers and users. It gives businesses a competitive edge and is often a differentiator when choosing a vendor. In our always-connected digital world, service depends on the organization’s availability, response time, resiliency, and other characteristics that support or obstruct their customers’ needs.

Cloud is now synonymous with making your business always available and serviceable; however, many organizations hosting applications and workloads in the cloud are finding that protecting them and keeping them “always-on” is difficult and time-consuming. Following are some best practices for availability and security in the cloud.

The importance of Availability Zones

Availability is the bedrock for any mission-critical application and the cornerstone for customer service. That’s why AWS recommends that customers deploy applications in at least two Availability Zones (AZ) whenever possible. The AWS Well-Architected Framework explains that organizations can achieve 99.99% uptime by utilizing these cross-AZ designs with at least two AZs. That equates to less than 53 minutes of down time per year, and represents a level of service that benefits customers, users, and your business.

However, providing security across those availability zones in AWS is not simple, because AWS limits subnets to a single AZ, High Availability network security clusters cannot be used across multi-AZ deployments. This limitation means that many cloud-based security gateways can only protect users on the same subnet. Each subnet requires separate and distinct cloud security instances, which would require buying, configuring, managing, and maintaining multiple cloud security images for your organization. The result? One possibility is a cloud asset protection approach that’s difficult, resource-intensive, and complex. The other possibility is the implementation of multiple services that don’t back each other up in the event of failure. Neither option is ideal.

Security that supports cross-AZ architecture

To alleviate this constraint and offer reliable and consistent AWS security, Check Point is proud to announce that CloudGuard Network Security now supports cross-AZ clusters. As a result, it just became much simpler for organizations to deploy security across availability zones in AWS environments, delivering highly available firewall and security gateway functionality with reduced manual configuration and less complexity. It’s a new reference architecture for Check Point customers on AWS, providing enhanced security resilience for cloud deployments across AWS regions using CloudGuard industry-leading advanced threat prevention.

This capability supports AWS traffic moving:

  • North/South: into and out of the internet, cloud assets, on-prem data centers, corporate intranet, etc.
  • East/West: lateral movement inside AWS
  • Across site-to-site VPNs

Support for cross-AZ clusters is included in CloudGuard’s recently-released R81.20 software version. Customers can now comfortably deploy best-practice application designs without the need to compromise security or build complex security architectures for failover scenarios. The functionality simplifies configuration and aids the ongoing challenge of managing cloud security, keeping things as simple as possible so that adding more assets, users, zones, routes, and applications doesn’t overwhelm your valuable operational resources.

The new cross-AZ clustering functionality supports all Check Point CloudGuard security features including:

  • IPS
  • Application control
  • Identity awareness
  • URL filtering
  • Anti-bot
  • Anti-virus
  • Content awareness
  • Sandblast zero-day prevention
    • Threat emulation
    • Threat extraction
  • Site-to-site VPN
  • Remote access VPN

The application of this new feature is intuitively simple. Choosing “Geo Mode” enables our cluster to span the sync traffic across separate subnets and automatically configures VPN link selection for Cross-AZ. That means you do not have to specify each and every data path and set up all available routes for all scenarios.  The capability is powered by an “Elastic Virtual IP” Address which gets assigned and shared across your clusters, and this alias address works with your public or private IP addressing so that traffic will always be directed to the active interface. In a failover situation the alias address can automatically switch from one cluster interface to another so that you always route traffic to the active interface and stay protected.

Reference Architectures

(1) Cross-AZ Cluster Without AWS Transit Gateway

AWS cross AZ architecture without TGW

This reference architecture diagram includes:

  • Security VPC with the CloudGuard Cross-AZ Cluster members deployed in different Availability Zones
  • Sync between the Cross-AZ Cluster members
  • Public routing tables associated with public subnets
  • Private routing table associated with the private subnets, with a default route to the active member private interface (eth1)
  • Ingress routing integration:
    • IGW routing table related to the IGW with routes from the subnets to protect the active member public interface (eth0)

(2) Cross-AZ Cluster With AWS Transit Gateway

AWS Cross AZ Cluster Architecture with TGW

This reference architecture diagram includes:

  • TGW routing table related to the TGW subnets with a default route to the active member public interface (eth0)
  • VPC attachment for the Security VPC to AWS TGW, attachments with TGW subnets
  • Spoke (Consumer) VPCs attached to the AWS TGW

Benefits to customers

The main benefit is the reduced complexity, increased operational efficiency, and time and cost savings. The new functionality supports the active/standby architecture, with cross-AZ increased availability, and has been extensively tested by Check Point and early-adopter customers and has proved to meet Check Point’s stringent stability requirements.

This new functionality can be used for VPN termination with greater performance and avoid cloud infrastructure native limitations (see https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-limits.html).

Additionally, the same solution can be used for the stateful inspection of all traffic flows.

What customers are saying

“Verisk has been on cloud adoption in a complex global business for several years,“ said Sophie Twu, Director Of Network Engineering at Verisk. “One of the business strategies is to transition from an on-prem hosted VPN to the cloud. Using R81.20 cross-AZ clustering enabled us to achieve a resilient clustering deployment in AWS without complexity or the need to change our public IP schema. The solution is scalable and very easy to manage. It was a time and money saver for us and we can see other new solutions coming and future applications working with Check Point.”

CloudGuard Network Security customers using previous software releases who want to take advantage of this new capability can upgrade their software to version R81.20. Your Check Point security engineers and channel partners can help you add this new capability into your cloud security environment and benefit from its reduced complexity and time and cost savings.

What’s next?

If you’re an existing customer, please read the CloudGuard for AWS Cross-AZ Cluster Administration Guide.

If you’d like further details about these new capabilities, please contact your Check Point channel partner, reach out directly to your local Check Point account team, or contact us.

You can also find further information about CloudGuard Network Security from the following resources:

At Check Point we do what we do, because we believe you deserve the best cloud security.

You may also like