ALB

Working with this resource via an AI agent? Datum publishes three skills covering Application Load Balancer: Application Load Balancer (creating and managing one, plus WAF and auth), Client Traffic (TLS termination, HTTP/3, connection limits; not available yet), and HTTPRoute (path routing, traffic splitting, redirects).

Datum’s Application Load Balancer (ALB) is an edge proxy built on Envoy, with a Coraza-based web application firewall (WAF). It started life as Datum’s “AI Gateway”, and it’s built for AI and agent traffic as much as for websites and APIs. Application Load Balancers help you protect and route internet traffic to your backend services. We support HTTP(S) 1.1, HTTP/2, gRPC, and WebSockets.

Running NGINX, Apache, Caddy, or Traefik in front of your app? To replace that container with an ALB, see Use ALB as your HTTP proxy.

The Datum Cloud console showing an Application Load Balancer's overview, with live request rate, error rate, p95 latency, requests blocked by the firewall, and a panel for attaching custom hostnames — The overview for a load balancer: whether it is serving, live request rate, error rate, latency and blocked requests, and the hostnames it answers on

How it works

An ALB isn’t a server you size or place. You declare it once in your project, and Datum serves it from Envoy in every Datum location:

Clients reach the nearest location. Your ALB’s hostnames are anycast, so each request arrives at the nearest Datum location. Envoy there terminates TLS, runs the firewall, and applies your routes.
Datum runs and scales the proxies. Envoy runs as a shared fleet in every location, serving every customer’s ALBs. Creating an ALB doesn’t start new infrastructure, and you don’t choose locations or capacity.
Changes reach every location. When you change an ALB, Datum publishes the new configuration to Envoy in every location.
Your origin can be anywhere. An origin can be a public site, reached over HTTPS on the internet; Compute Instances, reached over plain HTTP on your private gVPC network; or a service on your own machine, reached through a Connector tunnel.

For Compute origins, Envoy prefers an Instance in the same location, and sends the request to the nearest location with a healthy Instance when there isn’t one. For how Datum runs Envoy, including how it reaches your private network without ever reaching another customer’s, see Envoy.

What an ALB is made of

In Datum today, an Application Load Balancer is a product experience over several platform resources — not a single API kind. Creating an ALB in the Cloud Portal stitches these together for you:

Application Load Balancer (product)
├── HTTPProxy (user-created) — L7 routing, origin, Force HTTPS, Host header
│     └── operator materializes Gateway (same name), canonical hostname,
│         DNSRecordSet(s), and TLS certificates (ACME)
├── TrafficProtectionPolicy (created with the proxy, same name) — Coraza/OWASP WAF
│     └── targetRefs → Gateway
└── [optional] SecurityPolicy + Secret *-basic-auth — basic authentication

Piece	Role
`HTTPProxy`	Primary user-facing resource for hostnames, origin backends, redirects, and request filters
`TrafficProtectionPolicy`	WAF policy (Observe / Enforce / Disabled) attached 1:1 to the proxy’s Gateway
Gateway (operator)	Provisioned from the HTTPProxy; WAF and auth policies target it
DNS + TLS (operator)	Canonical hostname, DNSRecordSets, and ACME certificates from proxy status
SecurityPolicy (optional)	Basic auth via Envoy Gateway, backed by a Secret

Portal create always POSTs an HTTPProxy, then attempts a matching TrafficProtectionPolicy (best-effort today if WAF attach fails). There’s no composite ALB API yet. With datumctl, datumctl alb create creates the HTTPProxy and its TrafficProtectionPolicy for you (see Create a load balancer), or you can apply the resources yourself. To learn how Datum runs Envoy, see Envoy. See HTTPProxy for schemas and datumctl examples.

Features

Each Application Load Balancer deploys with a default hostname and enforces HTTPS (you can disable this).

Protection - The OWASP Coraza Web Application Firewall (WAF) provides built-in protection with the OWASP Core Rule Set, running inside Envoy before requests reach your origin. A load balancer created with datumctl alb create starts in Enforce mode at sensitivity 1. A TrafficProtectionPolicy that doesn’t set a mode runs in Observe mode. See Roll out traffic protection safely.
Custom Hostnames – Verify domains (or use already verified domain resources) to use custom hostnames with an Application Load Balancer.
Basic Authentication - Add a username and password to restrict access to an Application Load Balancer.
Load Balancing - Split traffic across several origins by weight, choose the load balancing algorithm, and turn on passive health checks. See Load balancing and health checks.

To monitor the health of your Application Load Balancers, you can use:

Status – View status “Accepted” and “Programmed”, Generated hostname(s), Custom hostname verification status, and TLS verification status.
Metrics - The Datum Cloud portal provides a variety of baseline metrics, filtered by region, including: global upstream latency percentile, regional upstream RPS, and regional upstream response.
Activity Logs - View and filter activity across a project, and filter by resource type (including Application Load Balancer) and action.

Introduction

Explore

How it works

What an ALB is made of

Features

​How it works

​What an ALB is made of

​Features

How it works

What an ALB is made of

Features