This architecture uses click-to-deploy so you can spin up infrastructure in minutes using terraform!

DDoS attacks are a type of cyber attack that can overwhelm a website or server with traffic, making it unavailable to users. These attacks can be costly and disruptive, and they can negatively impact your business.Cloud Armor is a product that protects your applications against a wide range of attacks, including SQL injection, cross-site scripting (XXS) and Denial of Service.

Cloud load balancing is a service that distributes incoming network or application traffic across multiple servers. This can help to improve the performance, reliability, and availability of your applications. When you combine Cloud Armor and Load Balancing, you can create a powerful and scalable security solution for your applications. Cloud Armor can protect your applications from a wide range of attacks, while Load Balancing can ensure your apps are always available.

This repo is based on the Cloud Foundation Fabric blueprint available here.

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.

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.

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.

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.

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

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.

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

• The project ID

Click on the button below, sign in if required and when the prompt appears, click on “confirm”. It will walk you through setting up your architecture.

This is the startup screen that appears after clicking the button and confirming:

During the process, you will be asked for some user input. All necessary variables are explained at the bottom of this ReadMe file. In case of failure, you can simply click the button again.

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, run 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, run the following command from the siege VM and verify that you get a 403 Forbidden error code back.

    curl http://$LB_IP
   

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

deploystack uninstall

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