DDoS protection for applications front-ended by GCP L7 load balancers | by Gauravmadan | Google Cloud – Community | May, 2025

In today’s interconnected digital landscape, Layer 7 (L7) applications, the engines driving our online experiences, are increasingly fronted by load balancers to manage traffic and ensure high availability. However, this common architecture has become a prime target for sophisticated Distributed Denial of Service (DDoS) attacks. Imagine a scenario during peak shopping season where an e-commerce site suddenly halts, or a critical financial services portal becomes unresponsive during trading hours. For customers, this translates to frustration, loss of trust, and potentially significant financial or data loss. The attackers achieve this by exploiting the application layer itself, often overwhelming specific functionalities or resource-intensive processes. These subtle yet devastating attacks can bypass traditional network-layer defenses, making robust L7 protection crucial for business survival.

This blog is a followup blog of my previous blog which talked about DDOS mitigation in case your application is behind a Layer4 pass through load balancer . If you haven’t gone through the same , please spend some time to understand the context . My current blog focuses the situations where customer applications are behind a global Layer 7 proxy based load balancers

When it comes to DDOS mitigation , one of commonly asked questions for GCP is — “ Please explain the following statement written in public documentation here –

This blog is in the context of Layer 7 Load balancers only and hence i will be explaining the concept only in context of L7 GCP external load balancer only .

Lets pick following keywords from statement above –

• Volumetric attack : attacking a L7 app front ended by Google Cloud global layer 7 application load balancer with volumetric attack is like attacking GCP front end . Remember , L7 load balancer is a proxy based load balancer . So if an attacker is sending a high volume attack , those volumes are first hitting the GCP proxy layer before they are sent to the application . Given the GCP front end can scale to imagination of attacker , it all boils down to fact how much traffic is sent to actual application behind LB . While the proxy layer can absorb the volumetric attack , have a rate limit for traffic sent to backend of LB is a very good strategy.
• Protocol attack : This is again equivalent to attacking Google front end . For example : If this is something resulting in half formed TCP sessions etc , then the same will be caught by GCP front end and the same will not be proxied to the application , thereby mitigating the protocol attacks.
• Inline mitigation : Such protocol attack / vol based attacks needs to be detected and mitigated in real time [ hence inline inspection and mitigation ]

This is where “DDOS attack visibility telemetry” plays an important role.Google Cloud Armor Enterprise lets you use Cloud Logging and Cloud Monitoring to analyze DDoS attacks and their sources.

To show this in real time , I have spinned up following topology . Idea is to simulate an attack and show how it is mitigated in Google Cloud front end .

• In my topology , I had no Cloud Armor policy attached to the LB backend .
• In my topology , I had Cloud Armor enterprise tier enabled for the GCP project

Attacker VMs used hping to simulate SYN attack at load balancer VIP address as follows

hping3 -n --flood --syn  -p 80

Please note that this will again generate 3 type of log messages –

1. First indicating that attack is detected and system has started mitigation
2. Second indicating that mitigation is still going on
3. Lastly , log message indicating mitigation has been ended

Each of these log messages have critical piece of information , which are explained below –

MITIGATION STARTED LOG MESSAGE

{
insertId: "1knu532b5a"
jsonPayload: {
id: "<>_mitigation_1748238000"
mitigationType: "MITIGATION_STARTED"
started: {
totalAttackVolume: {
bps: "53989165"
pps: "168716"
}
}
targetVip: “<>"
totalVolume: {
bps: "53989165"
pps: "168716"
}
}
logName: "projects/<>/logs/networksecurity.googleapis.com%2Fnetwork_dos_attack_mitigations"
receiveTimestamp: "2025-05-26T05:46:20.719555287Z"
resource: {
labels: {
location: "global"
project_id: "gm-test-337806"
vip: "<>"
}
type: "networksecurity.googleapis.com/ProtectedEndpoint"
}
severity: "WARNING"

Key information sheared in this log –

1. Volume of attack
2. Which load balancer VIP IP address is under attack
3. Timestamp of start of mitigation

Important point to note here is that Google Cloud Armor automatically detects and mitigates network layer (Layer 3) and transportation layer (Layer 4) attacks, performing the mitigation before enforcing any security policies and evaluating only well-formed requests against your security policy rules.

Therefore, traffic dropped as a result of always-on DDoS protection does not appear in telemetry for security policies or backends .

This also clarifies the point which I had mentioned above that I had no cloud Armor policy implemented / attached in this example . The DDOS attack detection and mitigation in this example has taken place ( at load balancer front end layer ) much before backend security policy could be evaluated .

Hence a good way to catch auto detected / mitigated traffic is to filter your logs by log name “network_dos_attack_mitigations”

MITIGATION IS ONGOING

{
insertId: "cruo98b5t"
jsonPayload: {
id: "<>_mitigation_1748238000"
mitigationType: "MITIGATION_ONGOING"
ongoing: {
totalAttackVolume: {
bps: "84840666"
pps: "265127"
}
}
targetVip: "<>"
totalVolume: {
bps: "84840666"
pps: "265127"
}
}
logName: "projects/<>/logs/networksecurity.googleapis.com%2Fnetwork_dos_attack_mitigations"
receiveTimestamp: "2025-05-26T06:05:44.160205492Z"
resource: {
labels: {
location: "global"
project_id: "<>"
vip: "<>"
}
type: "networksecurity.googleapis.com/ProtectedEndpoint"
}
severity: "WARNING"

This “mitigation ongoing” message is generated once every 5 minutes .

MITIGATION ENDED

{
insertId: "1knu532b5d"
jsonPayload: {
ended: {
attackDurationSeconds: 2400
}
id: "<>_mitigation_1748238000"
mitigationType: "MITIGATION_ENDED"
targetVip: "<>"
totalVolume: {
bps: "1173"
pps: "2"
}
}
logName: "projects/gm-test-337806/logs/networksecurity.googleapis.com%2Fnetwork_dos_attack_mitigations"
receiveTimestamp: "2025-05-26T06:26:20.071926497Z"
resource: {
labels: {
location: "global"
project_id: "<>"
vip: "<>"
}
type: "networksecurity.googleapis.com/ProtectedEndpoint"
}
severity: "WARNING"

The last log message tells how long the attack lasted and what the total volume post attack ceased to exist.

Documentation links

Cloud Armor overview

DDoS attack visibility

In a nutshell, safeguarding your GCP-hosted services against the threat of DDoS attacks requires a layered defense strategy, with Google Cloud Armor playing a pivotal role at multiple levels. As we explored in Part 1, for Layer 4 (network-level) onslaughts targeting your Google Cloud Network Load Balancers, the key is leveraging Cloud Armor’s advanced network DDoS protection.

When Layer 7 (application-level) attacks come knocking, as detailed in this post, there are inbuilt features in Google Front End , which can mitigate protocol attacks . But in case you need visibility in what was attack , when was it discovered , how long it lasted , when was it mitigated → then you need your GCP project to be subscribed to Google Cloud Armor enterprise subscription . Additionally , Cloud Armor’s Web Application Firewall (WAF) capabilities may help in deploying pre-configured WAF rules, custom rules to filter malicious traffic based on various L7 attributes (like headers, cookies, or query parameters)+ implementing rate limiting to thwart brute-force attempts, helps to detect and mitigate sophisticated, emerging L7 attacks against your applications served via Google Cloud HTTP(S) Load Balancer

This is to inform readers that the views, thoughts, and opinions expressed in the text belong solely to the author, and not necessarily to the author’s employer, organization, committee or other group or individual.