Centralized Enterprise Network & Security Appliance Services

AWS Integration of Virtual Network Appliances & Virtual Security Appliances

Raghu Ram Meda
6 min readJun 23, 2022

Introduction

Traditionally, Enterprises are using Network Appliances/ISVs such as Checkpoint, Fortinet, Netscout, PaloAlto, etc. for having different network and security services for managing and monitoring the on-prem traffic (northbound, southbound, east-west traffic). Typically, those Appliances/ISVs provide physical hardware based or custom equipment & software based solutions which enterprises are trusting since years.

In general the licensing of Network Appliances will differ a lot compared to typical business software and COTS applications. Typically, enterprises will have long term CapEx based long term licensing agreements with Network Appliance Vendors and hence, the obvious expectation would be to carry forward those licenses and continue use those tested and proved solutions for the traffic associated with the workloads that are moved to Cloud as well.

Services offered by Network Appliances

Network appliances sit in line with network traffic and inspect incoming and outbound traffic flows. The most common services provided by Appliances is to insert a network firewall, but there will much more functions such as

  • Deep Packet Inspection
  • Policy Enforcement
  • Route Optimization
  • Packet or Payload Manipulation
  • Non-intrusive Visualization & Tracing
  • Intrusion Detection & Prevention
  • URL Filtering
  • Anti-Spam & Anti-Malware Protection

This type of transparent insertion has many names, service chaining, bump-in-the-wire, and network functions virtualization.

The network and security services will be designed and implemented as common platform capabilities across the enterprise which will be managed, maintained and operated by a central network team. Application teams will need to consume those services and depend on those capabilities for compliance and policy enforcement. Sometime these can include Traffic Analytics services, Network Intelligence Services, Telemetry, etc. which will also be provided by some Software Appliances or ISVs to enterprises. So, enterprises want to continue build and operate those services centrally when the workloads are migrated or extended to Cloud as well.

AWS GWLB

By combining a transparent network gateway and a load balancer, the new AWS Gateway Load Balancer meets the requirement to target the load balancers and Interface VPC endpoints in VPC route tables, creating a new way to deploy, scale, and provide high-availability for third-party virtual network appliances such as firewalls, intrusion detection & prevention systems, deep packet inspection systems, etc in the AWS. It combines the functionality of a L3 gateway (next-hop, no packet rewrite) and a L4 load balancer (scaling, stickiness, Health checks, Flow rerouting) allowing customers to transparently insert virtual network appliances directly from AWS Market Place with High Availability, Auto Scaling and Fault Tolerance.

GWLB’s data-plane (frontend) faces the traffic source and destination, and operates in bump-in-the-wire mode, acting as the next-hop gateway, with no packet rewrite.

GWLB’s control-plane (backend) faces the fleet of virtual appliances, operates as a load-balancer for routing traffic flows to and from one of multiple equivalent target appliances. GWLB ensures stickiness of flows in both directions to target appliances, performs regular health checks of the appliances, and reroutes flows if the selected appliance becomes unhealthy.

GWLB receives a traffic packet, processes it at layer 3, encapsulates it with a Geneve (Generic Network Virtualization) protocol encapsulation and sends it to the appliance without any change to the original traffic packet (also known as “packet-in, packet-out”) to achieve transparent forwarding without the need of source NAT.

GWLB Endpoint (GWLBe) is the replica or mirror image of GWLB’s data-plane acts as the next-hop gateway for each subnet of the service consuming VPC that needs traffic inspection, that is different from the VPC which hosts the corresponding GWLB. Thus, the GWLBe enables deploying multi-tenanted traffic filtering service in a Appliance/Security VPC (different from the VPC/s of the traffic source or applications).

AWS GWLB enables enterprises to continue using the same Appliance services and solutions (virtualized) when their workloads are migrated to AWS using BYOL (Bring Your Own License) or brand new license model or migrate to a different next generation Virtual Appliance services through AWS Marketplace for frictionless management.

Basic Architecture for using Virtual Appliances

Solution for Central Management of Network & Security Appliances

Many enterprises will have different organizations with different and multiple VPCs respectively. Also it would be an obvious condition to have Hybrid Cloud environments where the workloads would have been distributed across Onpremise and multiple Clouds.

When it comes to Network & Security Appliances, many enterprises want to manage and maintain them centrally by network or infrastructure organization for various reasons such as

  • Apply and enforce policies uniformly and consistently across the enterprise
  • Achieve overall alignment easily for the security and compliance aspects while providing the autonomy for the teams to consume the services out of the box easily
  • Reduce the overall cost of running and maintaining the network and security appliances by managing them centrally and efficiently
  • Avoid the complexity and redundancy of multiple vendor appliances used across the core teams for the same purpose

Usecases & Reference Architectures

Each enterprise will have different usecases or scenarios related to centralized management of Network & Security Appliances as specified below. For all those scenarios, reference architecture options are provided below assuming that a given enterprise want to leverage the highly available, resilient and easily manageable Appliances in AWS using GWLB with BYOL or new AWS Marketplace licenses of them as applicable.

Hybrid Cloud — Traffic between Applications spread across Onprem DCs and AWS

Hybrid Cloud — Traffic between Applications spread across Onprem DCs, AWS and GCP

Within the Public Cloud (AWS) — Traffic between Applications spread across multiple VPCs within AWS (each per Organization or LoB)

Within the Public Cloud (AWS) — Internet Traffic destined to Applications within a given VPC

Within the Public Cloud (AWS) — Distributed GWLB and Outbound Traffic from VPC

Distributed GWLBe and Centralized GWLB for Scalability
Application packet flow to the Internet from the spoke VPC
Return packet flow from the Internet to the application in the spoke VPC

Benefits

Frictionless Integration: Introduce the new Appliance stack or extend the existing stack easily for High Availability in Security VPC without any impact on applications on consuming side.

Performance & Scalability: Appliances can be scaled out easily to increase the performance seamlessly with Auto Scaling support and hence provide greater performance for the applications traffic

No NAT: GWLB uses the Geneve encapsulation to traffic packet headers and payload intact providing complete visibility of the source identity to the applications and hence there will be no need of source NAT to maintain flow symmetry.

Cost Effective: Using AWS managed GWLB service, enterprises can consolidate all the (Virtualized) Appliances into AWS to achieve high availability, auto scaling and performance with simplified central management. That increases the overall efficiency and as well reduces the cost of operating compared to fragmented and different control planes for each Appliance and associated Physical Equipment management.

References

Access virtual appliances through AWS PrivateLink: https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway-load-balancer.html

Introducing AWS Gateway Load Balancer: Supported architecture patterns: https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/

Scaling network traffic inspection using AWS Gateway Load Balancer: https://aws.amazon.com/blogs/networking-and-content-delivery/scaling-network-traffic-inspection-using-aws-gateway-load-balancer/

Centralized inspection architecture with AWS Gateway Load Balancer and AWS Transit Gateway: https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/

Checkpoint Network Security for AWS Gateway Load Balancer Architecture Options: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk174447

How to integrate third-party firewall appliances into an AWS environment without using Gateway Load Balancer: https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-integrate-third-party-firewall-appliances-into-an-aws-environment/

Geneve protocol: https://tools.ietf.org/html/draft-ietf-nvo3-geneve-16

--

--

Raghu Ram Meda

Principal Enterprise Architect, Thought Leader, Domain Consultant & Technology Practioner