This is a preview release. Do not use it in production environments.
Download the release bundle from Download Edge-Native Defender (Preview).
Edge-Native Defender is the Cequence Defender running in infrastructure you already operate: your CDN, your API gateway, your load balancer or your Kubernetes ingress. It enforces the same policies you author in Cequence and sends the same analytics, without routing your traffic through a separate proxy.
Pick your platform
| Your platform | How Defender attaches | Added latency, median | What you run | Article |
| Cloudflare | a Worker on your zone | about 10 ms | nothing: Cloudflare runs it | Defender for Cloudflare |
| AWS CloudFront | a function behind your distribution | being measured | nothing: AWS Lambda runs it | Defender for AWS CloudFront |
| Fastly | a Compute service in front of your origin | 5 to 10 ms | nothing: Fastly runs it | Defender for Fastly |
| Envoy you run yourself | a filter inside Envoy | about 0.2 ms | nothing new: Envoy runs it | Defender for Envoy |
| Kubernetes gateways: Envoy Gateway, Istio or kgateway, including the Tetrate and Solo.io products | a filter inside the gateway's Envoy, or on kgateway a service beside it | about 0.2 ms with the filter | nothing new, or one small service on kgateway | Defender for Kubernetes Gateways |
| Kong Gateway 3.4 or later | a plugin inside Kong | about 0.2 ms | nothing new: Kong runs it | Defender for Kong |
| nginx: OpenResty, or nginx with lua-nginx-module | a module inside nginx | about 0.2 ms, measured on Kong's identical engine | nothing new: nginx runs it | Defender for nginx |
| Google Cloud global external Application Load Balancer, including API Gateway behind one | a Service Extensions callout | 6.5 ms on GKE, 16.5 ms on Cloud Run | a small service in your project | Defender for Google Cloud |
| MuleSoft Omni Gateway (formerly Flex Gateway) 1.6.0 or later | the gateway's External Processing policy | about 2 ms | a small service beside the gateway | Defender for MuleSoft |
| Apigee X | shared flows on every proxy, calling Defender | about 9 ms on GKE, 27 ms on Cloud Run | a small service in your project | Defender for Apigee |
| IBM API Connect v10 with DataPower API Gateway | global policy hooks on every API in your catalogs, calling Defender | about 3.5 ms | a service beside DataPower | Defender for IBM API Connect |
| IBM DataPower Gateway on its own (Multi-Protocol Gateway) | GatewayScript actions in your processing policy, calling Defender | about 2.5 ms | a service beside DataPower | Defender for IBM DataPower Gateway |
Every platform is in the same release bundle and runs the same engine, so a policy decides the same way wherever it runs.
What you can count on
Deployment. Your routes, hosts, origins and upstreams stay as they are. Defender is added with one installer command, on MuleSoft with one gateway policy, or on DataPower with three GatewayScript actions, and every platform has a documented way to take it off the path again. There is nothing to author at the edge: Defender fetches the policies you publish in Cequence.
Performance. Defender decides each request in about a millisecond or less. What a platform adds beyond that is how it reaches Defender: nothing extra where Defender runs inside the gateway (Envoy, Kong, nginx), a short call where the platform calls a service beside it (Google Cloud, MuleSoft, Apigee, IBM API Connect, DataPower), and the platform's own function overhead on a CDN. The table above gives the measured figures; each article gives the details and the CPU and memory to plan for.
Cost. Cequence charges nothing for the infrastructure Defender runs on. You pay your platform's usual rates for what it uses: requests on a CDN, CPU and memory on a gateway, or one small always-on service on Google Cloud and MuleSoft. Each article states what to expect.
Availability. No request ever waits on Cequence. Policies are fetched in the background and analytics are sent after your clients have their responses, so if Cequence is slow or unreachable, your traffic is unaffected and Defender keeps enforcing the policies it last received. If Defender itself fails, every platform is set up to let traffic through rather than block it.
Upgrades. Each release is one bundle with one version number, listed on the Download page. You upgrade with the same command or image you installed with, and every platform has a way back to the previous version; where the platform allows it, the change rolls out gradually.
How it differs from the managed Defender
| Managed Defender | Edge-Native Defender | |
| Where it runs | Its own proxy, hosted by Cequence or deployed by you | Inside your CDN, gateway or load balancer, or beside it |
| Traffic path | Traffic is routed to the Defender, then on to your application | Unchanged: same routes, same hosts, same origins |
| Scaling | Sized and scaled as a service | Scales with the platform it runs in |
| Policies and analytics | Authored and viewed in Cequence | The same policies, the same analytics, in the same place |
| If Cequence is unreachable | Depends on how it is deployed | Traffic is unaffected; Defender keeps enforcing the last policies it received |
| Maturity | Generally available | Preview |
Choose Edge-Native Defender when your traffic already passes through one of the platforms above and you would rather not add a proxy in front of your application, when latency budgets are tight, or when you want protection to scale with the edge or gateway you already run.
Choose the managed Defender when your platform is not listed, when you need a capability this preview does not have yet, or for production today.
You can run both. Each protects the traffic that passes through it, and both report to the same Cequence tenant.
What is different in this preview
- Policy actions. Cloudflare, AWS, Kong and nginx enforce every action: block, add-header, challenge, rate-limit and redirect. Envoy, Kubernetes gateways, Fastly, Google Cloud, MuleSoft, Apigee, IBM API Connect and DataPower enforce block and add-header; a request a policy would challenge, rate-limit or redirect is forwarded and reported.
- Defender sees the request as your platform presents it. CDNs and gateways may reorder or add headers before Defender runs, so fingerprints computed at the edge differ from the managed Defender's for the same client. Fingerprint-keyed policies should be learned from edge traffic.
- TLS fingerprints may be absent. Some platforms do not expose JA3 or JA4 for every request; a policy keyed on an absent fingerprint does not fire.
- A fresh install blocks nothing until you publish policies to it.
Request and response bodies are inspected up to your tenant's capture settings. Your application always receives the full request, and your clients the full response.
Getting help
Contact Cequence support with your platform, the release version from the
bundle's VERSION file, and what you saw.