Skip to main content

AWS Multi AZ Gateway Deployment

This CloudFormation (CFN) template, named aws-enforza-boilerplate-multi-az-landing-zone, sets up a multi-AZ (Availability Zone) environment for deploying a resilient AWS landing zone with a resilient HA pair of enforza Gateways with connectivity health checks and automated failover. It includes several key AWS resources, such as a VPC, public and private subnets across two AZs, security groups, EC2 firewall instances in each AZ, and associated route tables.

Download the AWS Multi AZ Gateway CloudFormation template here.

Open Source License

These templates are open source and licensed under the GNU General Public License, version 3 (GPLv3).

This means you are free to:

  • Use these templates for any purpose, whether personal or commercial.
  • Distribute copies of the templates, whether in their original form or modified versions.
  • Modify the templates to suit your needs.

If you distribute modified versions, you must keep them licensed under GPLv3, ensuring that others have the same freedom to use, modify, and distribute.

For more details, see the GPLv3 License.

AWS Multi AZ Gateway Deployment


Below is a detailed explanation of the infrastructure and resources created:

1. VPC Creation​

  • A new Virtual Private Cloud (VPC) is created with a custom CIDR block (default 10.1.0.0/16), which defines the IP address range for the network. This VPC serves as the foundation for other resources.
  • DNS Hostnames and DNS Support are enabled to allow DNS resolution within the VPC.

2. Subnets​

  • Public Subnet 1: A publicly accessible subnet is created in the first availability zone using the first /24 range of the VPC's CIDR. It is configured to assign public IP addresses to instances automatically.
  • Public Subnet 2: A public subnet is also created in the second availability zone using the second /24 range of the VPC's CIDR block.
  • Private Subnets (AZ1 and AZ2): Six private subnets (three in each availability zone) are created. These subnets are isolated from direct internet access, used for internal resources, and provide redundancy across multiple AZs.

3. Internet Gateway and Route Tables​

  • Internet Gateway (IGW): An Internet Gateway is attached to the VPC, allowing resources in the public subnets to communicate with the internet.
  • Public Route Table: A public route table is associated with both public subnets. It contains a route directing all traffic (0.0.0.0/0) to the Internet Gateway.
  • Private Route Table: A private route table is created for the private subnets. Initially, traffic is routed through the firewall EC2 instance in AZ1 via its Elastic Network Interface (ENI). This enables controlled internet access for the private subnets.

4. Security Groups​

  • A security group is created to control inbound and outbound traffic to the EC2 instances. It permits:
    • All traffic from within the VPC.
    • SSH, ICMP, and SNMP access from Trusted Management IPs (specified by the user).
    • Tags the security group with a unique identifier for easy management.

5. EC2 Firewall Instances​

  • enforza Firewall Instance (AZ1): An EC2 instance is created in the first public subnet (AZ1). This instance serves as the primary enforza firewall. It uses the latest Ubuntu image, fetched from AWS SSM Parameter Store.
  • enforza Firewall Instance (AZ2): Another EC2 instance is created in the second public subnet (AZ2). This serves as a redundant firewall instance, ensuring high availability.
  • Both instances use custom Elastic Network Interfaces (ENIs), which facilitate routing between public and private subnets. The instances have roles and instance profiles enabling them to manage resources and tag themselves during installation.
  • User Data: The EC2 instances are configured with user data scripts that:
    • Set up an administrative user (efzadmin) with passwordless sudo access.
    • Execute the enforza installation script.
    • Extract and tag the instances with Claim Key and other metadata.

6. Private Route Configuration​

  • Private Route Table Association: The private subnets in both AZ1 and AZ2 are associated with the private route table. Initially, all traffic from the private subnets is routed through the firewall in AZ1.
  • Dynamic Route Updates: The private subnets’ routing will be dynamically updated based on the availability of the firewalls, using the Lambda functions described below.

7. Lambda Functions for Route Failover​

  • Master Lambda (enforzaGatewayCheckerSupervisor): This non-VPC-connected Lambda function runs every minute and checks the connectivity of both firewalls (in AZ1 and AZ2). If the primary firewall (AZ1) fails, it updates the private route table to route traffic through the secondary firewall in AZ2. Similarly, if the secondary firewall (AZ2) fails, it flips traffic back to AZ1.
  • Slave Lambda (enforzaGatewayCheckerAZWorkerAZ1 and AZ2): These VPC-connected Lambdas perform the actual connectivity checks via DNS queries. If a failure is detected in the primary firewall’s connectivity, the route table is updated to use the secondary firewall, and vice versa.

8. Logs and CloudWatch Events​

  • Log Groups: Log groups are created for both the Master and Slave Lambda functions to store logs of their operations in CloudWatch.
  • CloudWatch Event Rule: A scheduled rule triggers the Master Lambda every minute to perform its checks and take appropriate action if connectivity issues are detected.

9. Outputs​

The template provides output details such as:

  • VPC ID
  • Public Subnet IDs (for both AZ1 and AZ2)
  • Private Subnet IDs (for both AZ1 and AZ2)

Summary​

This CloudFormation template sets up a multi-AZ landing zone for enforza, providing redundancy across two Availability Zones (AZ1 and AZ2). It creates secure public and private subnets, with EC2 instances acting as firewalls in each zone. Dynamic routing is handled by Lambda functions that monitor the health of the firewalls, ensuring high availability. This setup is ideal for enterprises seeking a robust and highly available network infrastructure.