Your service stayed up. The attack still showed up on the bill

Gcore TrafficGate gives Gcore CDN customers visibility into unwanted traffic and controls for bots, request sources, and L7 surges.

Imagine a website facing an application-layer (L7) DDoS attack, a flood of web requests intended to overwhelm the service. In this example, the CDN absorbs part of the attack traffic at the edge, the website’s backend servers (its origin) stay available, and users notice no disruption. Technically, the protection worked. But without TrafficGate, the attack traffic handled by the CDN still counts toward CDN usage and is billed to the customer, leaving them paying for traffic they never wanted to serve.

This is one version of a broader problem. An AI crawler can work through thousands of pages, a scraper can collect an entire product catalogue and its prices, and a legitimate client can call a compute-intensive API too frequently. A sudden influx of real users during a launch or live broadcast can put the origin under similar pressure.

Individually, these requests may look completely normal. Collectively, they compete for bandwidth, compute resources, and budget. The question for modern web traffic is increasingly whether you want to serve it, under what conditions, and at what volume. TrafficGate gives Gcore CDN customers the visibility and controls to make those decisions at the edge.

All screenshots below show demo data.

Surge Control shows detected and prevented attacks alongside the requests that passed.

Why this gap persisted

A CDN delivers content quickly and reliably, while basic rules can restrict access by IP address, geography, or User-Agent, a request header that identifies the browser or other software making the request. For many use cases, those controls are enough.

The problem becomes harder when traffic changes. Sources move, bots rotate addresses or use browser automation, and demand concentrates on specific URLs and API methods. A static blocklist quickly becomes outdated. A single rate limit, which controls how frequently requests are allowed, may fail to contain unwanted traffic or interfere with legitimate users when applied across an entire application.

Rate limiting can be handled at the origin or API gateway, where the application has more context about each request. But by then, the request has already reached the infrastructure and started consuming resources. A full Web Application and API Protection (WAAP) platform offers another approach, protecting applications and APIs against security threats that exploit vulnerabilities in their software.

There is an organisational reason this gap has persisted, too. CDN operations usually belong to DevOps, Platform, or SRE teams, while application security has a different owner and budget. DevOps needs origin headroom and traffic control, but may not need the broader security and investigation capabilities of a full WAAP deployment. The security team, meanwhile, is assessing application risk rather than CDN operating costs.

Teams can end up maintaining IP lists, origin rate limits, and one-off scripts without a single place to understand and control unwanted traffic at the edge. TrafficGate brings those decisions into the CDN delivery path.

First understand what is creating the load

Traffic Intelligence brings together information about requests, sources, bots, errors, and changes in demand. It helps you distinguish audience growth from crawler activity, identify an endpoint under pressure, and see which sources have changed the normal traffic profile.

That information can guide policies before the next surge. An API provider, for example, may need a request threshold for an expensive search operation. Understanding which clients generate the most traffic, when requests increase, and which endpoints are affected helps establish an appropriate policy.

Traffic Intelligence also provides a way to measure the effect of a policy. You can identify a change in traffic, find its source, apply a response through Traffic Policies, and see how the request patterns change.

Traffic Intelligence brings audience traffic, AI agents, bots and crawlers, and errors into one timeline.

Bots need different policies

Automated traffic can create value. Search crawlers help people discover a website, preview bots generate link previews on social platforms, and monitoring services check availability. An AI agent may also retrieve a page in direct response to a user's request.

Other automation collects content at scale, works through product catalogues, or creates unwanted load. A publisher may value search indexing but want to limit AI crawlers collecting large amounts of its content. An online shop may be more concerned about scrapers repeatedly extracting product listings and prices.

Applying the same policy to every bot can disrupt useful services or leave businesses with little control over how their content and resources are used.

TrafficGate Bot Control uses known-bot identification and behavioural signals to distinguish between types of automation. You can choose how different traffic should be handled: allow it, rate-limit it, require additional validation, or block it.

Bot Control groups known bots by category so different types of automation can receive different policies.

The decision depends on source, target, and intensity

An IP address or country can be a useful signal, but rarely tells the whole story. An address may belong to shared infrastructure, a source may use a proxy or hosting network, and a legitimate integration may generate unusually high request volumes.

TrafficGate Access Control filters requests using IP addresses, geography, and source-reputation categories, which provide signals about how trustworthy a request’s source may be. Traffic Policies adds more context, including the URL, path, HTTP method, headers, and request rate.

These controls allow policies to address specific situations. You could restrict an administrative area to trusted networks or rate-limit a compute-intensive search or export endpoint. An ecommerce business could apply a policy to scraper traffic collecting product information while preserving an exception for a trusted partner integration.

You can also observe matches for a new rule before enabling enforcement, helping identify unexpected effects on legitimate traffic.

Traffic Policies combines request conditions and actions so rules can be applied to specific traffic scenarios.

Sudden demand hits the origin like an attack

A product launch, sports broadcast, sale, or widely shared article can change the normal traffic profile within minutes. From the origin's perspective, the symptoms can resemble an attack: latency rises, workers and connections become exhausted, and errors begin to appear.

The resources required to handle each request also vary. A static page, a search across a large catalogue, and a complex API call place very different demands on an application. A single domain-wide rate limit cannot reflect those differences.

Surge Control contains application-layer (L7) DDoS traffic and sudden HTTP request spikes at the edge. Traffic Policies adds controls that reflect the specific target and the application's capacity, helping preserve resources for legitimate users and critical operations.

Pay for clean requests

TrafficGate uses clean-request billing. Requests filtered as L7 DDoS, malicious automation, traffic from prohibited sources, or other unwanted activity are not billed.

TrafficGate and WAAP solve different problems

TrafficGate focuses on understanding and controlling traffic: who or what is generating requests, whether the business wants to serve them, and how much the service can accept.

Gcore WAAP addresses the broader application-security problem. It protects applications and APIs against attacks targeting vulnerabilities, including OWASP Top 10 threats. When the primary risk involves SQL injection, cross-site scripting (XSS), API vulnerabilities, virtual patching, or other threats to application logic, WAAP provides the appropriate security capabilities.

Gcore CDN handles delivery, TrafficGate adds controls over the traffic using that delivery path, and WAAP protects applications and APIs against a wider range of security threats. Customers can expand their application-security capabilities as their requirements change.

Start with one problem on real traffic

TrafficGate is built for DevOps, Platform, and SRE teams using Gcore CDN to run public services with high or unpredictable HTTP request volumes.

The requirements vary across industries. Media and publishing platforms may need policies for AI crawlers and content scraping. Gaming services can face sharp traffic increases during launches, while ecommerce businesses may need to manage automated price collection and pressure on checkout operations. SaaS and API platforms often need more precise limits for particular clients or expensive operations.

TrafficGate is available to Gcore CDN customers. Start with one measurable problem, such as an L7 surge, bot traffic, scraping, or an overloaded endpoint.

Establish a baseline, validate exceptions for legitimate traffic, and measure the outcome on your own workload before expanding the policy.

Request a TrafficGate pilot →