Cloud Perimeter Security Implementation Guide

The Cloud Perimeter Security Implementation Guide outlines the technical steps required to implement the Aviatrix Secure Egress solution. The goal is to achieve deep visibility into your traffic and centralized policy enforcement, ensuring secure, compliant, and optimized performance and cost efficiency.

secure egress topology

  1. Aviatrix Gateways provide advanced NAT and network security capabilities for your workloads.

  2. By assigning workload subnets to separate route tables, the traffic load can be spread over multiple gateways.

  3. In case a gateway becomes unavailable, automatic control over the route table can reroute workload traffic over another gateway within the same or other Availability Zone in the VPC.

  4. The Aviatrix Gateways can be deployed in a horizontally scalable manner, with multiple gateways per AZ, or you can scale to multiple AZs.

Aviatrix security features such as Availability Zones, High Performance Encryption, NAT policies, and Distributed Cloud Firewall rules enhance the security posture of Spoke gateways and ensure robust protection for cloud and on-premises environments.

Network Design

Design your network comoponents to interact with minimal dependencies.

Configuration Steps

Aviatrix recommends following these steps to implement your cloud egress security.

1. Spoke Gateway Sizing

See the Gateway Sizing Best Practices Guide for information on common deployments, to assist with pre-deployment planning.

2. NAT Configuration

Enable NAT on Spoke Gateways to manage IP address translation for both Internet and internal network destinations. Various NAT capabilities are supported.

  • Internet Egress: Enable single IP SNAT to secure and NAT traffic directly from workloads to the Internet. Single IP SNAT translates all outbound traffic originating from the Spoke VPC/VNet to use the gateway’s public IP address.

  • Native East/West Traffic: Source NAT or destination NAT traffic from workload VPCs toward other cloud or on-premise resources across native routing constructs. This involves spoke gateways created in your CSPs.

  • Aviatrix East/West Traffic: Secure and NAT traffic from workload VPCs (NAT is optional) toward other cloud or on-premise resources across the Aviatrix data plane. This relies on using Aviatrix Transit gateways as a hub to connect to its destination.

  • Custom SNAT: Address IP exhaustion and overlapping IP spaces by creating specific NAT rules that map internal IP ranges to different external IPs. Implement custom SNAT rules to address IP exhaustion and overlapping IP spaces.

    Additionally, Aviatrix allows the creation of custom SNAT rules to address IP exhaustion and overlapping IP spaces. For VPCs requiring egress access to the Internet, an AWS Internet Gateway is necessary, and Aviatrix ensures that traffic egresses via the Aviatrix gateway, providing secure and compliant egress.

3. Security Groups and IAM Policies (AWS only)

4. Monitoring Traffic

Use the Monitoring features in CoPilot to analyze your Spoke gateway traffic and make improvements.

  • CoPilot: Use CoPilot features such as the CoPilot dashboard and topology map to analyze Spoke gateway traffic and make improvements.

  • Alerts and notifications: Configure alerts and notifications to monitor gateway health.

  • FlowIQ: Use FlowIQ for detailed traffic flow analysis and anomaly detection.

5. Availability Zones and High Availability

  • Availability Zones: Deploy Aviatrix gateways in each Availability Zone (AZ) with workloads to minimize cross-AZ data transfer charges.

  • High Availability: The Aviatrix Controller takes care of configuring route tables to distribute the workload traffic among the available Spoke gateways. If a Spoke gateway becomes unavailable, Controller automatically reprograms the route table so that traffic is rerouted over another Spoke gateway within the same or another availability zone in the VPC.

    Dynamic peer discovery in Azure automatically detects changes in peered VNet CIDRs and updates routes accordingly.

  • Single AZ HA: Enable single AZ High Availability (HA) for non-production environments. This feature is enabled by default if the gateway is launched from the Controller or CoPilot. However, if using Terraform, you must enable the appropriate flag.

6. Centralized Management

  • Aviatrix control plane: To scale management across multiple VPCs, Aviatrix utilizes a centralized management and control plane. This enables customers to deploy and manage spoke gateways, along with their NAT and security policies, from a single console or through automation capabilities such as Terraform and API.

  • Multicloud transit network design: Implement a transit network architecture for centralized and simplified network connectivity. By using a hub-and-spoke model, you can connect multiple VPC or VNet environments to a central transit hub, which provides redundancy and centralized control. Also see Aviatrix Multicloud Transit Network FAQ.

7. Policy-based Routing (AWS only)

Policy-based routing enables you to route VPN traffic to a different subnet with its default gateway. If you want to force the VPN traffic to go out on a different subnet than the VPN gateway eth0 subnet, you can specify a PBR subnet in the VPC and the PBR default gateway.

8. Spoke Subnet Groups (Azure only)

Azure Spoke Subnet Groups: When you add an Azure Spoke subnet group, selecting the Spoke Gateway automatically synchronizes the Subnet(s) list with the Azure portal so that the list is refreshed with any new subnets for this Spoke Gateway.

9. CoPilot Alerts

Configure CoPilot alerts to monitor gateway CPU and memory utilization. Alerts can be configured based on various metrics, including gateway status, CPU utilization, and memory usage.

10. Create SmartGroups, WebGroups, and ExternalGroups

  • SmartGroups: Create logical groupings of resources for DCF rules.

  • WebGroups: Manage outbound Internet traffic with WebGroups.

  • ExternalGroups: Manage external feeds (such as Countries, Threat Feeds, and SaaS-based services) with ExternalGroups.

11. Create Distributed Cloud Firewall Rules

Distributed Cloud Firewall (DCF) operates within individual VPCs or VNets, inspecting and enforcing the DCF security rules directly in the cloud network where the traffic originates, regardless of the destination.

DCF rules are applied directly at the point of ingress or egress. You can configure IDS and TLS as part of creating DCF rules.

  • Use the Aviatrix DCF solution to maintain consistent security policies across cloud platforms. The rules defined in the DCF policy describe the relationship and trust between resources in different SmartGroups, WebGroups, and External Groups. Individual rules can be customized to meet required levels of inspection, logging, and enforcement.

  • Rules are evaluated in order and should use a naming convention that indicates their intent.

  • Establish a pattern that works for your cloud deployment needs.