cloud-foundation-fabric/blueprints/networking/glb-and-armor

HTTP Load Balancer with Cloud Armor

Introduction

This blueprint contains all necessary Terraform modules to build a multi-regional infrastructure with horizontally scalable managed instance group backends, HTTP load balancing and Google’s advanced WAF security tool (Cloud Armor) on top to securely deploy an application at global scale.

This tutorial is general enough to fit in a variety of use-cases, from hosting a mobile app's backend to deploy proprietary workloads at scale.

Use cases

Even though there are many ways to implement an architecture, some workloads require high compute power or specific licenses while making sure the services are secured by a managed service and highly available across multiple regions. An architecture consisting of Managed Instance Groups in multiple regions available through an HTTP Load Balancer with Cloud Armor enabled is suitable for such use-cases.

This architecture caters to multiple workloads ranging from the ones requiring compliance with specific data access restrictions to compute-specific proprietary applications with specific licensing and OS requirements. Descriptions of some possible use-cases are as follows:

• Proprietary OS workloads: Some applications require specific Operating systems (enterprise grade Linux distributions for example) with specific licensing requirements or low-level access to the kernel. In such cases, since the applications cannot be containerised and horizontal scaling is required, multi-region Managed Instance Group (MIG) with custom instance images are the ideal implementation.
• Industry-specific applications: Other applications may require high compute power alongside a sophisticated layer of networking security. This architecture satisfies both these requirements by promising configurable compute power on the instances backed by various features offered by Cloud Armor such as traffic restriction, DDoS protection etc.
• Workloads requiring GDPR compliance: Most applications require restricting data access and usage from outside a certain region (mostly to comply with data residency requirements). This architecture caters to such workloads as Cloud Armor allows you to lock access to your workloads from various fine-grained identifiers.
• Medical Queuing systems: Another great example usage for this architecture will be applications requiring high compute power, availability and limited memory access requirements such as a medical queuing system.
• DDoS Protection and WAF: Applications and workloads exposed to the internet expose themselves to the risk of DDoS attacks. While L3/L4 and protocol based attacks are handled at Google’s edge, L7 attacks can still be effective with botnets. A setup of an external Cloud Load Balancer with Cloud Armor and appropriate WAF rules can mitigate such attacks.
• Geofencing: If you want to restrict content served on your application due to licensing restrictions (similar to OTT content in the US), Geofencing allows you to create a virtual perimeter to stop the service from being accessed outside the region. The architecture of using a Cloud Load Balancer with Cloud Armor enables you to implement geofencing around your applications and services.

Architecture

The main components that we would be setting up are (to learn more about these products, click on the hyperlinks):

• Cloud Armor - Google Cloud Armor is the web-application firewall (WAF) and DDoS mitigation service that helps users defend their web apps and services at Google scale at the edge of Google’s network.
• Cloud Load Balancer - When your app usage spikes, it is important to scale, optimize and secure the app. Cloud Load Balancing is a fully distributed solution that balances user traffic to multiple backends to avoid congestion, reduce latency and increase security. Some important features it offers that we use here are:
  • Single global anycast IP and autoscaling - CLB acts as a frontend to all your backend instances across all regions. It provides cross-region load balancing, automatic multi-region failover and scales to support increase in resources.
  • Global Forwarding Rule - To route traffic to different regions, global load balancers use global forwarding rules, which bind the global IP address and a single target proxy.
  • Target Proxy - For external HTTP(S) load balancers, proxies route incoming requests to a URL map. This is essentially how you can handle the connections.
  • URL Map - URL Maps are used to route requests to a backend service based on the rules that you define for the host and path of an incoming URL.
  • Backend Service - A Backend Service defines CLB distributes traffic. The backend service configuration consists of a set of values - protocols to connect to backends, session settings, health checks and timeouts.
  • Health Check - Health check is a method provided to determine if the corresponding backends respond to traffic. Health checks connect to backends on a configurable, periodic basis. Each connection attempt is called a probe. Google Cloud records the success or failure of each probe.
• Firewall Rules - Firewall rules let you allow or deny connections to or from your VM instances based on a configuration you specify.
• Managed Instance Groups (MIG) - Instance group is a collection of VM instances that you can manage as a single entity. MIGs allow you to operate apps and workloads on multiple identical VMs. You can also leverage the various features like autoscaling, autohealing, regional / multi-zone deployments.

Costs

Pricing Estimates - We have created a sample estimate based on some usage we see from new startups looking to scale. This estimate would give you an idea of how much this deployment would essentially cost per month at this scale and you extend it to the scale you further prefer. Here's the link.

Setup

This solution assumes you already have a project created and set up where you wish to host these resources. If not, and you would like for the project to create a new project as well, please refer to the github repository for instructions.

Prerequisites

• Have an organization set up in Google cloud.
• Have a billing account set up.
• Have an existing project with billing enabled.

Roles & Permissions

In order to spin up this architecture, you will need to be a user with the “Project owner” IAM role on the existing project:

Note: To grant a user a role, take a look at the Granting and Revoking Access documentation.

Spinning up the architecture

Step 1: Cloning the repository

Click on the button below, sign in if required and when the prompt appears, click on “confirm”.

This will clone the repository to your cloud shell and a screen like this one will appear:

Before we deploy the architecture, you will need the following information:

• The project ID.

Step 2: Deploying the resources

1. After cloning the repo, and going through the prerequisites, head back to the cloud shell editor.

2. Make sure you’re in the following directory. if not, you can change your directory to it via the ‘cd’ command:

   cloudshell_open/cloud-foundation-fabric/blueprints/cloud-operations/glb_and_armor
   

3. Run the following command to initialize the terraform working directory:

   terraform init
   

4. Copy the following command into a console and replace [my-project-id] with your project’s ID. Then run the following command to run the terraform script and create all relevant resources for this architecture:

   terraform apply -var project_id=[my-project-id]
   

The resource creation will take a few minutes… but when it’s complete, you should see an output stating the command completed successfully with a list of the created resources.

Congratulations! You have successfully deployed an HTTP Load Balancer with two Managed Instance Group backends and Cloud Armor security.

Testing your architecture

1. Connect to the siege VM using SSH (from Cloud Console or CLI) and run the following command:

    siege -c 250 -t150s http://$LB_IP
   

2. In the Cloud Console, on the Navigation menu, click Network Services > Load balancing.

3. Click Backends, then click http-backend and navigate to http-lb

4. Click on the Monitoring tab.

5. Monitor the Frontend Location (Total inbound traffic) between North America and the two backends for 2 to 3 minutes. At first, traffic should just be directed to us-east1-mig but as the RPS increases, traffic is also directed to europe-west1-mig. This demonstrates that by default traffic is forwarded to the closest backend but if the load is very high, traffic can be distributed across the backends.

6. Now, to test the IP deny-listing, rerun terraform as follows:

    terraform apply -var project_id=my-project-id -var enforce_security_policy=true
   

This, applies a security policy to denylist the IP address of the siege VM

7. To test this, from the siege VM run the following command and verify that you get a 403 Forbidden error code back.

    curl http://$LB_IP
   

Cleaning up your environment

The easiest way to remove all the deployed resources is to run the following command in Cloud Shell:

    terraform destroy

The above command will delete the associated resources so there will be no billable charges made afterwards.

Variables

name	description	type	required	default
prefix	Prefix used for resource names.	string	✓
project_id	Identifier of the project.	string	✓
enforce_security_policy	Enforce security policy.	bool		true
project_create	Parameters for the creation of the new project.	object({…})		null

Outputs

name	description	sensitive
glb_ip_address	Load balancer IP address.
vm_siege_external_ip	Siege VM external IP address.

Test

module "test" {
  source = "./fabric/blueprints/networking/glb-and-armor"
  prefix = "test"
  project_create = {
    billing_account_id = "123456789"
    parent             = "organizations/123456789"
  }
  project_id              = "project-1"
  enforce_security_policy = true
}
# tftest modules=12 resources=28