​
Select Service
Billing Usage Types
Published March 15, 2026 | Last modified August 12, 2026
Objective
The following list provides explanation on all billing usage types for F5® Distributed Cloud Services subscriptions. All usage types are organized by the various Services offered in the Distributed Cloud console.
View your usage information in F5® Distributed Cloud console at Homepage > Billing and Usage tile, or contact your Account Manager.
Service Name: App Stack
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| CE - App Stack Combo - Small (4 vCPU) / Medium (8 vCPU) / Large (16 vCPU) - Count | Measured as aggregated node-seconds per hour for active Mesh Nodes (up to 4 vCPU / 8 vCPU / 16 vCPU). Metering starts only when a node is active and running, not just because a site is created. | Optimization Strategies: - Reduce total CE sites to lower operational overhead. - Group sites for centralized management and scaling. - Use clustering strategies to balance redundancy and cost. - Avoid unnecessary active-active deployments. |
| RE - Container - Tiny (0.1 vCPU) / Medium (0.25 vCPU) / Large (1 vCPU) - Count | Billed based on the total time your Tiny / Medium / Large containers run on Regional Edge nodes. Each hour a container runs counts toward your usage, and each container running in each Regional Edge location contributes to the total. | Configured and deployed via Distributed Apps / Virtual K8s deployments targeted to Regional Edge virtual sites; usage is visible in Usage & Billing in console. Reserve for high-throughput workloads. Optimization focuses on reducing over-provisioned capacity and downsizing containers when demand drops. |
Service Name: Client-Side Defense
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| Client Side Defense- Transactions | A transaction is an HTTP request made to CSD's reporting API, and is designed to happen once per page view. In the case of single-page applications (SPA), a page view is counted using the number of times a particular top-level URL in the browser's location bar displays the URL where the CSD JS is injected. | Number of Client-Side Defense transactions. Usage is visible in the Console under Usage & Billing. |
Service Name: Content Delivery Network (Standard)
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| CDN - North America - Data Transfer - Bytes | Total volume of data transferred (TB) from North America CDN points of presence to the public internet. Metered hourly and summed monthly. | Usage is visible in the Console under Usage & Billing → CDN, with regional breakdowns. |
| CDN - Europe - Data Transfer - Bytes | Total volume of data transferred (TB) from European CDN points of presence to the public internet. Metered hourly and summed monthly. | Usage is visible in the Console under Usage & Billing → CDN, with regional breakdowns. |
| CDN - Asia - Data Transfer - Bytes | Total volume of data transferred (TB) from Asia-Pacific CDN points of presence to the public internet. Metered hourly and summed monthly. | Usage is visible in the Console under Usage & Billing → CDN, with regional breakdowns. |
| CDN - South America - Data Transfer - Bytes | Total volume of data transferred (TB) from South America CDN points of presence to the public internet. Metered hourly and summed monthly. | Usage is visible in the Console under Usage & Billing → CDN, with regional breakdowns. |
| CDN - North America - Public RE - Requests | Total number of HTTP(S) requests served from North America CDN points of presence. Reported in millions, metered hourly, and summed monthly. | Usage is visible in the Console under Usage & Billing → CDN, with regional breakdowns. |
| CDN - Europe - Public RE - Requests | Total number of HTTP(S) requests served from European CDN points of presence. Reported in millions, metered hourly, and summed monthly. | Usage is visible in the Console under Usage & Billing → CDN, with regional breakdowns. |
| CDN - Asia - Public RE - Requests | Total number of HTTP(S) requests served from Asia-Pacific CDN points of presence. Reported in millions, metered hourly, and summed monthly. | Usage is visible in the Console under Usage & Billing → CDN, with regional breakdowns. |
| CDN - South America - Public RE - Requests | Total number of HTTP(S) requests served from South America CDN points of presence. Reported in millions, metered hourly, and summed monthly. | Usage is visible in the Console under Usage & Billing → CDN, with regional breakdowns. |
Service Name: DNS
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| DNS Load Balancer - Count | Metered as total active time DNS Load Balancers are active and attached to DNS zones. Measured in seconds, aggregated hourly, and converted to billable hours. | Visible in the Console under DNS → Load Balancers and summarized in Usage & Billing. |
| DNS Load Balancer - Health Checks - Enabled - Count | Metered as total time DNS Health Checks are attached to DNS Load Balancers. Measured in seconds, aggregated hourly, and converted to billable hours. | Visible in the Console under DNS → Load Balancers → Health Checks and reflected in Usage & Billing. |
| DNS - Zones - Count | Metered as the total time DNS Zones are configured. Measured in seconds and aggregated hourly. | DNS usage is visible in the Console under Usage & Billing. |
Service Name: Malware Protection
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| LB - Malware Protection - Enabled - Scanned Requests | Total millions of successful scan requests across all load balancers (RE and CE) where Malware Protection is enabled, per month. | Successful scan requests of all load balancers (RE and CE) on which Malware Protection is enabled. |
Service Name: Secure Mesh (Advanced)
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| Network - Anycast VIP - Count | Each Anycast VIP is billed and provisioned separately for your tenant. | An Anycast Virtual IP (VIP) is a single IP address advertised from multiple Points of Presence (PoPs) across F5's global network using the Anycast routing protocol. |
| LB - Rate Limiting - Requests to Origin - Millions | Billed based on the number of requests that reach your origin servers after rate limiting is applied. We count these in units of one million requests. | Rate limiting safeguards backend applications by capping traffic within set intervals, preventing overload. Billing is based on each million requests reaching the origin servers after rate limiting. |
Service Name: Secure Mesh (Standard)
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| CE - Data Transfer to RE - Bytes | This measures the amount of data (in TB) sent from your Customer Edge (CE) location to an F5 Regional Edge (RE) location. We track all data plane traffic (application traffic) from CE to RE. Data is summed across all tunnels and aggregated hourly. Control plane traffic (config sync, health checks) is not billed. If you use multiple REs, traffic to each RE is counted separately. | Each CE-RE tunnel is counted separately so multiple RE connections will increase usage. Reducing the number of CE sites sending traffic to multiple REs can also conserve on data transfers. |
| RE - Load Balancer - Public - Count | Billed based on the number of active public load balancers deployed on Regional Edge (RE) nodes. A public load balancer is defined as one with a shared VIP or public VIP. Internally, we track usage by observing the aggregate number of public load balancer seconds on RE nodes. These observations are aggregated hourly to confirm continuous activity. If a single public load balancer spans multiple REs, it is counted only once — as if it were on a single RE. This ensures fairness and avoids duplicate charges. | To optimize usage and control costs, consolidate multiple domains on fewer load balancers, centralize certificate management, and remove idle resources. |
Service Name: Site Management
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| CE - Mesh Node - Small (4 vCPU) / Medium (8 vCPU) / Large (16 vCPU) - Count | Measured as aggregated node-seconds per hour for active Mesh Nodes. Metering starts only when a node is active and running, not just because a site is created. | Optimization Strategies: - Reduce total CE sites to lower operational overhead. - Group sites for centralized management and scaling. - Use clustering strategies to balance redundancy and cost. - Avoid unnecessary active-active deployments. |
Service Name: Synthetic Monitoring
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| Synthetic Monitor - DNS and HTTP - Executions | Executions represent the number of individual times a monitor has been run across all configured regions. The two factors that determine the monthly consumption for a monitor are the number of regions for the monitor and execution interval. | Invocations or executions reported in Usage & Billing in console. |
Service Name: Web App & API Protection (Advanced)
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| LB - API Protection - Enabled - Requests to Origin - Millions | Frequently Asked Questions (FAQs): How is API Protection billed? API Protection is billed based on the number of Good Requests per month. A Good Request is any request that is not blocked and is forwarded to the application or API origin servers. For pricing and included usage, please contact your account team. What features generate billable Good Requests? Good Requests are counted when any of the following features are enabled on a Load Balancer: - API Protection Rules - API Rate Limiting - Malicious User Detection - OAS Validation - JWT Validation How do I enable API Protection? API Protection is enabled per Load Balancer in the console under: Load Balancer → API Protection → Security Controls (example, enable Protection Rules, Rate Limiting, JWT Validation, and so on) How do I calculate the number of Good Requests I will be billed for? API Protection usage represents the total number of Good Requests across all Load Balancers with API Protection enabled. Formula: Total Good Requests per month / 1,000,000 = Good Requests (Millions) Examples: - 30,000,000 Good Requests in a month = 30 units - 250,000,000 Good Requests in a month = 250 units - 2,000,000,000 Good Requests in a month = 2,000 units | API Protection usage is reported in the console under Usage & Billing. |
| LB - API Discovery - Enabled - Count | Frequently Asked Questions (FAQs): How is API Discovery billed? API Discovery is available for all Organization and Enterprise plans. Billing is based on the number of Load Balancers with API Discovery enabled, measured in Load Balancer-Days per billing period. For pricing and included usage, please contact your account team. What is a billable unit for API Discovery? A billable unit is one Load Balancer-Day with API Discovery enabled. Time is metered continuously while the feature is enabled on a Load Balancer. How do I enable API Discovery? API Discovery is enabled per Load Balancer in the console under: Load Balancer → API Protection → Enable API Discovery How do I calculate my API Discovery usage? API Discovery usage represents the total time API Discovery is enabled across all Load Balancers. Formula: (Load Balancer-Seconds Enabled / 3600 / 24) = Load Balancer-Days Examples: - 1 Load Balancer enabled for a full 30-day month ≈ 30 Load Balancer-Days - 3 Load Balancers enabled for 10 days ≈ 30 Load Balancer-Days - 10 Load Balancers enabled for a full 30-day month ≈ 300 Load Balancer-Days | API Discovery usage is reported in the console under Usage & Billing |
Service Name: Web App & API Protection (Standard)
| Billing Usage Type | Metering Logic | Description |
|---|---|---|
| CE - App Firewall - Count | Count increases when a WAF policy is attached to an HTTP Load Balancer running on a CE site, or when multiple CE sites each have their own WAF policy attached. | In the Distributed Cloud Console: - Navigate to Web App & API Protection > Manage > App Firewall. - Review existing WAF policies. - To disable: Detach the WAF policy from the CE-based HTTP Load Balancer. Alternatively, delete the WAF policy if it is no longer needed. Tip: Ensure you are in the correct namespace for the CE site before making changes. Best Practice for Cost Control: - Consolidate WAF policies where possible. - Use Regional Edge (RE) WAF instead of CE WAF if global protection suffices. - Regularly audit CE sites for unused or redundant WAF policies. |
| RE - WAF - Requests - Millions | Usage is measured as the total number of inspected requests during the billing period. A WAF request is counted when an HTTP(S) request reaches an Distributed Cloud HTTP Load Balancer with WAF enabled and the request is inspected. | Visible in the Distributed Cloud Console under Web App & API Protection and Billing → Usage Data for the load balancers where WAF is enabled. |
On this page:
- Objective
- Service Name: App Stack
- Service Name: Client-Side Defense
- Service Name: Content Delivery Network (Standard)
- Service Name: DNS
- Service Name: Malware Protection
- Service Name: Secure Mesh (Advanced)
- Service Name: Secure Mesh (Standard)
- Service Name: Site Management
- Service Name: Synthetic Monitoring
- Service Name: Web App & API Protection (Advanced)
- Service Name: Web App & API Protection (Standard)