​

Billing Usage Types

Published March 15, 2026 | Last modified March 16, 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: Secure Mesh (Advanced)

  • Billing Usage Type: Network - Anycast VIP - Count
  • Metering Logic: Each Anycast VIP is billed and provisioned separately for your tenant.
  • Description: 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.

  • Billing Usage Type: LB - Rate Limiting - Requests to Origin - Millions
  • Metering Logic: You are 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.
  • Description: 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: CE - Data Transfer to RE - Bytes
  • Metering Logic: 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.
  • Description: 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.

  • Billing Usage Type: RE - Load Balancer - Public - Count
  • Metering Logic: You are 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.
  • Description: 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: CE - Mesh Node - Small (4 vCPU) - Count
  • Metering Logic: Usage is measured as aggregated node-seconds per hour for active Mesh Nodes (up to 4 vCPU). Metering starts only when a node is active and running, not just because a site is created. If a node is powered down or inactive, it does not accumulate usage. This ensures you are only monitored for actual runtime, not for provisioned but idle resources.
  • Description: Reduce the number of CE sites where possible. Fewer sites mean fewer Mesh Nodes and lower operational overhead. Group CE sites logically for centralized management and scaling. This avoids redundant deployments and simplifies operations. Use clustering strategies that balance redundancy and cost. Avoid unnecessary active-active deployments if not required.

  • Billing Usage Type: CE - Mesh Node - Medium (8 vCPU) - Count
  • Metering Logic: Usage is measured as aggregated node-seconds per hour for active Mesh Nodes (up to 8 vCPU). Metering starts only when a node is active and running, not just because a site is created. If a node is powered down or inactive, it does not accumulate usage. This ensures you are only monitored for actual runtime, not for provisioned but idle resources.
  • Description: Reduce the number of CE sites where possible. Fewer sites mean fewer Mesh Nodes and lower operational overhead. Group CE sites logically for centralized management and scaling. This avoids redundant deployments and simplifies operations. Use clustering strategies that balance redundancy and cost. Avoid unnecessary active-active deployments if not required.

  • Billing Usage Type: CE - Mesh Node - Large (16 vCPU) - Count
  • Metering Logic: Usage is measured as aggregated node-seconds per hour for active Mesh Nodes (up to 16 vCPU). Metering starts only when a node is active and running, not just because a site is created. If a node is powered down or inactive, it does not accumulate usage. This ensures you are only monitored for actual runtime, not for provisioned but idle resources.
  • Description: Reduce the number of CE sites where possible. Fewer sites mean fewer Mesh Nodes and lower operational overhead. Group CE sites logically for centralized management and scaling. This avoids redundant deployments and simplifies operations. Use clustering strategies that balance redundancy and cost. Avoid unnecessary active-active deployments if not required.

Service Name: Web App & API Protection (Standard)

  • Billing Usage Type: CE - App Firewall - Count
  • Metering Logic: 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.
  • Description: In the Distributed Cloud Console:

    • Navigate to Web App and 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.

Service Name: Web App & API Protection (Advanced)

  • Billing Usage Type: LB - API Protection - Enabled - Requests to Origin - Millions

  • Metering Logic: 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"

  • Description: API Protection usage is reported in the console under Usage & Billing.


  • Billing Usage Type: LB - API Discovery - Enabled - Count

  • Metering Logic:

    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

  • Description: API Discovery usage is reported in the console under Usage & Billing

Service Name: App Stack

  • Billing Usage Type: CE - App Stack Combo - Small (4 vCPU) - Count
  • Metering Logic: Usage is measured as aggregated node-seconds per hour for active Mesh Nodes (up to 4 vCPU).
  • Description: Reduce the number of CE sites where possible. Fewer sites mean fewer Mesh Nodes and lower operational overhead.

  • Billing Usage Type: CE - App Stack Combo - Medium (8 vCPU) - Count
  • Metering Logic: Usage is measured as aggregated node-seconds per hour for active Mesh Nodes (up to 8 vCPU).
  • Description: Reduce the number of CE sites where possible. Fewer sites mean fewer Mesh Nodes and lower operational overhead.

  • Billing Usage Type: CE - App Stack Combo - Large (16 vCPU) - Count
  • Metering Logic: Measured as aggregated node-seconds per hour for active Mesh Nodes (up to 16 vCPU).
  • Description: Usage is tracked by node-seconds per hour. Optimization focuses on using clustering strategies that balance redundancy and cost.

  • Billing Usage Type: RE - Container - Tiny (0.1 vCPU) - Count
  • Metering Logic: You are billed based on the total time Tiny containers run on Regional Edge nodes. Each container running in each Regional Edge location contributes to the total. Each hour a container runs counts toward your usage, and each container running in each Regional Edge location contributes to the total.
  • Description: Configured and deployed via Distributed Apps / Virtual K8s deployments targeted to Regional Edge virtual sites; usage is visible in the console.

  • Billing Usage Type: RE - Container - Medium (0.25 vCPU) - Count
  • Metering Logic: You are billed based on the total time Medium containers run on Regional Edge nodes. Each hour a container runs counts toward usage. Each container running in each Regional Edge location contributes to the total. Each hour a container runs counts toward your usage, and each container running in each Regional Edge location contributes to the total.
  • Description: Configured and deployed via Distributed Apps / Virtual K8s deployments targeted to Regional Edge virtual sites; usage is visible in Usage & Billing in console.

  • Billing Usage Type: RE - Container - Large (1 vCPU) - Count
  • Metering Logic: You are billed based on the total time Large containers run on Regional Edge nodes. Billed by count and time enabled, not by traffic. Each hour a container runs counts toward your usage, and each container running in each Regional Edge location contributes to the total.
  • Description: Customers should reserve Large containers for workloads that genuinely require high throughput or sustained compute, limit the number of Large containers deployed, scope them only to Regional Edges where that capacity is required, and remove or downsize containers when demand drops. Because Large containers are billed by count and time enabled—not by traffic—optimization focuses on reducing over‑provisioned capacity rather than reducing load.

Service Name: DNS

  • Billing Usage Type: DNS Load Balancer - Count
  • Metering Logic: Usage is metered as the total time DNS Load Balancers are active and attached to DNS zones, measured in seconds and aggregated hourly, then converted to billable hours for the billing period.
  • Description: DNS Load Balancer usage is visible in the Distributed Cloud Console under DNS → Load Balancers, and summarized in Usage & Billing for the tenant.

  • Billing Usage Type: DNS Load Balancer - Health Checks - Enabled - Count
  • Metering Logic: Usage is metered based on the total time DNS Health Checks are attached to DNS Load Balancers measured in seconds, aggregated hourly, and converted to billable hours.
  • Description: DNS Health Check usage can be viewed in the Distributed Cloud Console under DNS → Load Balancers → Health Checks, and reflected in Usage & Billing.

  • Billing Usage Type: DNS - Zones - Count
  • Metering Logic: Usage is metered as the total time DNS Zones are configured, measured in seconds and aggregated hourly.
  • Description: DNS usage is visible in Usage & Billing in console.

Service Name: Synthetic Monitoring

  • Billing Usage Type: Synthetic Monitor - DNS and HTTP - Executions
  • Metering Logic: 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.
  • Description: Invocations or executions reported in Usage & Billing in console.

Service Name: Client-Side

  • Billing Usage Type: Client Side - Transactions
  • Metering Logic: 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.
  • Description: Number of Client-Side transactions. Usage is visible in Usage & Billing in console.

Service Name: Malware Protection

  • Billing Usage Type: LB - Malware Protection - Enabled - Scanned Requests
  • Metering Logic: Total millions of successful scan requests across all load balancers (RE and CE) where Malware Protection is enabled.
  • Description: Successful scan requests of all load balancers (RE and CE) on which Malware Protection is enabled.

Service Name: Content Delivery Network (Standard)

  • Billing Usage Type: CDN - North America - Data Transfer - Bytes
  • Metering Logic: Usage is metered as the total volume of data transferred from North America CDN points of presence to the public internet, aggregated hourly and summed monthly, reported in terabytes (TB).
  • Description: CDN data transfer usage is visible in the Distributed Cloud Console under Usage & Billing → CDN, with regional breakdowns by North America.

  • Billing Usage Type: CDN - Europe - Data Transfer - Bytes
  • Metering Logic: Usage is metered as the total volume of data transferred from European CDN points of presence to the public internet, aggregated hourly and summed monthly, reported in terabytes (TB).
  • Description: CDN data transfer usage is visible in the Distributed Cloud Console under Usage & Billing → CDN, with regional breakdowns by Europe.

  • Billing Usage Type: CDN - Asia - Data Transfer - Bytes
  • Metering Logic: Usage is metered as the total volume of data transferred from Asia - Pacific CDN points of presence to the public internet, aggregated hourly and summed monthly, reported in terabytes (TB).
  • Description: CDN data transfer usage is visible in the Distributed Cloud Console under Usage & Billing → CDN, with regional breakdowns by Asia - Pacific.

  • Billing Usage Type: CDN - South America - Data Transfer - Bytes
  • Metering Logic: Usage is metered as the total volume of data transferred from South America CDN points of presence to the public internet, aggregated hourly and summed monthly, reported in terabytes (TB).
  • Description: CDN data transfer usage is visible in the Distributed Cloud Console under Usage & Billing → CDN, with regional breakdowns by South America.

  • Billing Usage Type: CDN -- North America -- Public RE -- Requests
  • Metering Logic: Usage is metered as the total number of HTTP(S) requests served from North America CDN points of presence, aggregated hourly and summed monthly, reported in millions of requests.
  • Description: CDN request usage is visible in the Distributed Cloud Console under Usage & Billing → CDN, with request metrics broken down by region.

  • Billing Usage Type: CDN -- Europe -- Public RE -- Requests
  • Metering Logic: Usage is metered as the total number of HTTP(S) requests served from European CDN points of presence, aggregated hourly and summed monthly, reported in millions of requests.
  • Description: CDN request usage is visible in the Distributed Cloud Console under Usage & Billing → CDN, with request metrics broken down by region.

  • Billing Usage Type: CDN -- Asia -- Public RE -- Requests
  • Metering Logic: Usage is metered as the total number of HTTP(S) requests served from Asia - Pacific CDN points of presence, aggregated hourly and summed monthly, reported in millions of requests.
  • Description: CDN request usage is visible in the Distributed Cloud Console under Usage & Billing → CDN, with request metrics broken down by region.

  • Billing Usage Type: CDN -- South America -- Public RE -- Requests
  • Metering Logic: Usage is metered as the total number of HTTP(S) requests served from South America CDN points of presence, aggregated hourly and summed monthly, reported in millions of requests.
  • Description: CDN request usage is visible in the Distributed Cloud Console under Usage & Billing → CDN, with request metrics broken down by region.
On this page: