This document provides a reference architecture for a web application that'shosted on Google Cloud. The architecture uses aglobal front end which incorporates Google Cloud best practices to help scale, secure, andaccelerate the delivery of your internet-facing applications. The architectureincludessupport for Cloud Build, as well as third-party continuous integration (CI) andcontinuous delivery (CD) tools like Jenkins and GitLab. This architecture isintended for developers and app owners who want to scale their application witha load balancer, and protect their applications from distributed denial-of-service(DDoS) and web-based attacks with a web application firewall (WAF).

Architecture

The following diagram shows the architecture that this document describes.

In this architecture, the application is load balanced withglobal external Application Load Balancers, which distribute HTTP and HTTPS traffic acrossmultiple backend instances, across multipleregions. Cloud CDN acceleratesinternet-facing applications by using Google'sedge points of presence (PoPs) and works with theglobal external Application Load Balancer to deliver content to users. The backends areprotected byGoogle Cloud Armor security policies that provide Layer 7 filtering by scrubbingincoming requests for common web attacks or other Layer 7 attributes, helping toblock traffic before it reaches the load-balanced backend services. Protectionagainst volumetric DDoS attacks is enabled by default.

When a user requests content from your service, that request is sent to theglobal front end for internet-facing applications, which is provided bytheCross-Cloud Network.The request is evaluated by Cloud Armor security policies, startingwith Cloud Armor edge security policies. If the request is allowed andcan be fulfilled by Cloud CDN, the content is retrieved from theCloud Armor cache and sent back to the user. If the request results ina cache miss, it's evaluated by backend policies and then, according to thepolicy's rules, denied or fulfilled by your backend server.

Architecture components

The preceding diagram includes the following components:

• Global external Application Load Balancer: This Application Load Balancer isa proxy-based Layer 7 load balancer that lets you run and scale yourservices. The Application Load Balancer distributes HTTP and HTTPS traffic tobackends that are hosted on a variety of Google Cloud platforms. TheApplication Load Balancer has the following features:

  • Configurable backend: This architecture uses twoManaged Instance Groups (MIGs) in different regions, but you can configure any backend that the globalexternal Application Load Balancer supports. You can use the same loadbalancer for GKE, Cloud Run, Cloud Run functions,and App Engine applications, as well as those hosted on-premises and on otherclouds using a different backend configuration. To learn more, seeApplication Load Balancer overview.
  • Traffic splitting: You can use the Application Load Balancerfor traffic management, including the management of software versions bysending different users to different backend servers. In the architecturedescribed in this document, there is a 60/40 simple traffic split. However,you can change this split to create more complex traffic management schemes.To learn about additional configuration options, see the configurabletimeouts and retries and determine your preferredbalancing mode.

• Cloud CDN: The Cloud CDN platform acts as a cache. It'sdeployed with the origin server to provide the full suite of Cloud CDN features,including QUIC and HTTP/2, as well as routing and caching controls. Thisapproach allows your application to scale globally without compromisingperformance, and also reduce bandwidth and front-end compute costs. Thedefault configuration that the global front end uses is based onCloud CDNcontent delivery best practices andweb security best practices.

• Cloud Armor: This component includes DDoS Protectionand WAF rules. The architecture has the following basic Cloud Armorconfiguration, which helps to mitigate against common threat vectors:

  • Default protection against volumetric DDoS attacks (Layer 3 and Layer 4).

  • Preconfigured WAF rules based on ModSecurity Core Rule Set CRS 3.3. These rules enable Cloud Armor toevaluate dozens of distinct traffic signatures by referring to pre-named rules,rather than requiring you to define each signature manually.

  • A basic configuration ofCloud Armor edge security policy to filterincoming requests and control access to protected backend services andCloud Storage buckets.

Products used

This reference architecture uses the following Google Cloud products:

• Cloud Load Balancing
• Cloud CDN
• Cloud Armor

Design considerations

This section provides guidance to help you use this document as a starting pointto develop an architecture that meets your specific requirements for security,reliability, operational efficiency, cost, and performance.

Security, privacy, and compliance

This section describes additional factors that you should consider when you usethis reference architecture to deploy the web application.

Establish a security baseline

To help to further enhance your security, the architecture described in thisdocument is also compatible with theEnterprise foundations blueprint. The blueprint helps organizations that are usingGoogle Cloud to establish a secure baseline for all future workloads,including the setup ofIdentity and Access Management (IAM),Cloud Key Management Service,andSecurity Command Center.

Protect user data with Cloud CDN

In this architecture, we recommend that you don't cache user-specific content.For cachingHTML (text/html) and JSON (application/json) content types, set explicit cache-control headers in theCloud CDN response. Make sure that you don't cache one user's data andserve it to all users.

Control access to your application with IAP

The architecture is also compatible with Identity-Aware Proxy (IAP).IAP verifies a user's identity and then determines whether thatuser should be permitted to access an application. To enable IAPfor theApplication Load Balancer for both the global external mode or the classic mode, you enable it on thebackend services of the load balancer. Inbound HTTP/HTTPS requests are evaluatedby Cloud Armor before they are sent for load balancing by the Application Load Balancer.If Cloud Armor blocks a request, IAP doesn't evaluate therequest. If Cloud Armor allows a request, IAP then evaluatesthat request. The request is blocked if IAP doesn't authenticate therequest. To learn more, seeIntegrating Cloud Armor with other Google products.

Cost optimization

As a general guideline, using Cloud CDN together withCloud Armor can help to minimize the effect ofdata transfer out charges.

Cloud CDN

Static objects that are served to the client from the cache don't transitthrough the load balancer. An effective caching strategy can reduce the amountof outbound data being processed by the load balancer and lower your costs.

Google Cloud Armor

Cloud Armor helps you to lower costs by preventing your account frombeing charged for unwanted traffic. Requests that are blocked byCloud Armor don't generate a response from your app, effectivelyreducing the amount of outbound data processed by the load balancer. The effecton your costs depends on the percentage of undesirable traffic blocked by theCloud Armor security policies that you implement.

Final costs can also vary, depending on how many services or applications youwant to protect, the number of Cloud Armor policies and rules that youhave, cache fill and egress, and data volume. To learn more, see the following:

• Cloud Armor pricing
• Cloud Load Balancing pricing
• Cloud CDN pricing
• To find the price for your specific deployment scenario, see theGoogle Cloud pricing calculator

Deployment

To deploy this reference architecture, use theTerraform example.To learn more, see theREADME file.Theweb_app_protection_example folder includes the(main.tf)file. The code in this file creates the architecture described in this document,and provides additional support for automatic deployment.

The folder structure in the Terraform folder is as follows:

• Source code repository:The Web Application Protection Example is part of theWeb Application and API Protection (WAAP) repository.
• CD and CI:The build folder contains the following descriptive files for Jenkins, GitLab, and Cloud Build:
  • Jenkins: This repository includes theJenkins file that contains the rules that the pipeline executes.
  • GitLab: This repository includes a.gitlab-ci YAML file that contains the rules that the GitLab pipeline executes.
  • Cloud Build: This repository includes theCloud Build file that contains the rules based on branch names.
• The repository includes an option for multi-environment (production and development)deployment. For more information, see theREADME file.

When you commit a change to any branch that your pipeline is based on, thosechanges trigger a pipeline run and the changes are integrated into a new releaseonce it completes. When you pull the toolkit for the first time, the solutionwill be loaded to your chosen Google Cloud project.

What's next

Learn more about the best practices for the Google Cloud products used inthis reference architecture:

• Web security best practices
• External Application Load Balancer performance best practices
• Content delivery best practices
• Best practices for tuning Cloud Armor WAF rules

• Cloud Armor Enterprise: The Cloud Armor capabilities in this architecture are available under the Cloud Armor Standard tier. Enrolling your project to Cloud Armor Enterprise lets you use additional features such as the following:

  • Threat Intelligence, which lets you allow or block traffic to external Application Load Balancers based on several categories of threat intelligence data.
  • Adaptive Protection, which helps to protect your Google Cloud applications, websites, and services against Layer 7 DDoS attacks such as HTTP floods, as well as other high-frequency Layer 7 (application-level) malicious activities. Adaptive Protection builds machine learning models that detect and alert on anomalous activity, generate a signature describing the potential attack, and generate a custom Cloud Armor WAF rule to block the signature.
  • DDoS attack visibility, which provides visibility through metrics, as well as logging of events such as Layer 3 Layer 4 volumetric attack attempts.
  • Additional services such as DDoS response support and DDoS bill protection. To learn more, seeCloud Armor Enterprise overview

• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.

Contributors

Authors:

• Lihi Shadmi | Product Manager
• David Tu | Customer Engineer

Other contributors:

• Alex Maclinovsky | Enterprise Architect
• Anderson Duboc | Customer Engineer
• Grant Sorbo | Solutions Architect
• Michele Chubirka | Cloud Security Advocate
• Rob Harman | Technical Solutions Engineer Manager
• Susan Wu | Outbound Product Manager