Use Google Cloud Armor, load balancing, and Cloud CDN to deploy programmable global front ends

Last reviewed 2024-04-04 UTC

This document provides a reference architecture for a web application that's hosted on Google Cloud. The architecture uses a global front end which incorporates Google Cloud best practices to help scale, secure, and accelerate the delivery of your internet-facing applications. The architecture includes support for Cloud Build, as well as third-party continuous integration (CI) and continuous delivery (CD) tools like Jenkins and GitLab. This architecture is intended for developers and app owners who want to scale their application with a 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.

Web application architecture.

In this architecture, the application is load balanced with global external Application Load Balancers, which distribute HTTP and HTTPS traffic across multiple backend instances, across multiple regions. Cloud CDN accelerates internet-facing applications by using Google's edge points of presence (PoPs) and works with the global external Application Load Balancer to deliver content to users. The backends are protected by Google Cloud Armor security policies that provide Layer 7 filtering by scrubbing incoming requests for common web attacks or other Layer 7 attributes, helping to block traffic before it reaches the load-balanced backend services. Protection against volumetric DDoS attacks is enabled by default.

When a user requests content from your service, that request is sent to the global front end for internet-facing applications, which is provided by the Cross-Cloud Network. The request is evaluated by Google Cloud Armor security policies, starting with Google Cloud Armor edge security policies. If the request is allowed and can be fulfilled by Cloud CDN, the content is retrieved from the Google Cloud Armor cache and sent back to the user. If the request results in a cache miss, it's evaluated by backend policies and then, according to the policy'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 is a proxy-based Layer 7 load balancer that lets you run and scale your services. The Application Load Balancer distributes HTTP and HTTPS traffic to backends that are hosted on a variety of Google Cloud platforms. The Application Load Balancer has the following features:

    • Configurable backend: This architecture uses two Managed Instance Groups (MIGs) in different regions, but you can configure any backend that the global external Application Load Balancer supports. You can use the same load balancer for GKE, Cloud Run, Cloud Run functions, and App Engine applications, as well as those hosted on-premises and on other clouds using a different backend configuration. To learn more, see Application Load Balancer overview.
    • Traffic splitting: You can use the Application Load Balancer for traffic management, including the management of software versions by sending different users to different backend servers. In the architecture described 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 configurable timeouts and retries and determine your preferred balancing mode.

  • Cloud CDN: The Cloud CDN platform acts as a cache. It's deployed 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. This approach allows your application to scale globally without compromising performance, and also reduce bandwidth and front-end compute costs. The default configuration that the global front end uses is based on Cloud CDN content delivery best practices and web security best practices.

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

Products used

This reference architecture uses the following Google Cloud products:

Design considerations

This section provides guidance to help you use this document as a starting point to 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 use this reference architecture to deploy the web application.

Establish a security baseline

To help to further enhance your security, the architecture described in this document is also compatible with the Enterprise foundations blueprint. The blueprint helps organizations that are using Google Cloud to establish a secure baseline for all future workloads, including the setup of Identity and Access Management (IAM), Cloud Key Management Service, and Security Command Center.

Protect user data with Cloud CDN

In this architecture, we recommend that you don't cache user-specific content. For caching HTML (text/html) and JSON (application/json) content types, set explicit cache-control headers in the Cloud CDN response. Make sure that you don't cache one user's data and serve 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 that user should be permitted to access an application. To enable IAP for the Application Load Balancer for both the global external mode or the classic mode, you enable it on the backend services of the load balancer. Inbound HTTP/HTTPS requests are evaluated by Google Cloud Armor before they are sent for load balancing by the Application Load Balancer. If Google Cloud Armor blocks a request, IAP doesn't evaluate the request. If Google Cloud Armor allows a request, IAP then evaluates that request. The request is blocked if IAP doesn't authenticate the request. To learn more, see Integrating Google Cloud Armor with other Google products.

Cost optimization

As a general guideline, using Cloud CDN together with Google Cloud Armor can help to minimize the effect of data transfer out charges.

Cloud CDN

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

Google Cloud Armor

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

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

Deployment

To deploy this reference architecture, use the Terraform example. To learn more, see the README file. The web_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:

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

What's next

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

Contributors

Authors:

Other contributors: