The following question and answer sets provide the pricing information for different types of F5® Distributed Cloud Services subscription and related usage:
I need a DDOS protection service. What services do you offer?
F5 Distributed Cloud DDoS provides three types of Cloud DDoS mitigation services:
On-demand infrastructure protection from 100Mbps up to 500Mbps clean traffic, which provides BGP redirect based Cloud DDoS mitigation for Layer3/Layer 4 infrastructure protection
Always-on infrastructure protection from 100Mbps up to 100Gbps clean traffic, which provides BGP redirect based Cloud DDoS mitigation for Layer3/Layer4 infrastructure protection
In addition, F5 Distributed Cloud Services provide SSL offload (a.k.a TLS termination) on F5 Distributed Cloud's Global Network points of presence in the country, improving the performance of the enterprise’s web application. Hence the name Web Application Security and Performance.
On-demand means limited amounts of mitigations and hours under attack for scrubbing. F5 Distributed Cloud Services provide 18 mitigations for up to 90 attack hours per year. If customer chooses this package, but need more hours for scrubbing, customers are provided with options to purchase additional SKUs for extra hours.
Note: After mitigation is done for the scrubbing, within 12hours, customer should move the traffic off F5 Distributed Cloud Console backbone, otherwise there will be additional on-net charge.
Always-on means unlimited amounts of mitigations and hours under attack for scrubbing.
Which plan offers which of these three services?
On-demand infrastructure protection and Always-on infrastructure protection is offered only in the Organization Plan. Web Application protection is offered in Individual, Teams and Organization plans.
What capabilities are included in the Web Application protection in the Organization Plan?
The Organization Base Plan already includes all the standard features required to protect your website or Public API. The base plan includes many capabilities described next that will help enterprises to protect their website/APIs.
Web Application Security
App Security (Basic WAFs) provides the following security capabilities:
- Network policies enabling users to define prefixes and ports (Layer3 and Layer 4) from which to accept traffic or send traffic to those destinations. Please see this link for more information. See Network Policy for more information.
- Network firewall to enable blocking/allowing traffic at layer 3/layer 4. See Network Firewall for more information.
- Egress Filter.
- Application Firewall: See App Firewall for more information.
Secure Networking provides fast ACLs that enable users to define a list of prefixes and ports (Layer 3 and Layer 7) from which to accept traffic. See Fast ACLs for more information.
Secure Networking provides the ability to define a policer action in addition to allow/deny actions. This policer action provides rate limiting capabilities at the VIP level. That means, it is applicable to all the domains that share the VIP. This is equivalent to the per VIP level rate limiting provided by Cloud Protect. See this link for more information with policer action: See Fast ACLs for more information.
Web Application Performance
- A public load-balancer that is globally distributed across all F5 Distributed Cloud Global Network points of presence.
- This public load balancer can load balance across origin servers spread across multiple geographic locations.
- The public load balancer performs health checks across multiple origin servers across multiple geographic locations
- Health checks are performed at a highly granularity 1 second.
- The VIP provided by F5 Distributed Cloud is anycast via all F5 Distributed Cloud global network. This means that enterprise’s end-users reach the closest global network site in country by default without the enterprise having to do any networking magic.
SSL offload (also known as TLS termination)
- F5 Distributed Cloud can perform SSL offload for https traffic reducing the load on the enterprise’s infrastructure.
- Furthermore, the SSL offload is performed on the global network in the country reducing the latency of the communication and improving web application performance.
Web Application protection is included in three plans Individual,Teams and Organization. Which capabilities are included with which plans?
The following table shows capabilities of each plan:
|L7 DDOS: WAFs||Included via Basic WAFs||Included via Basic WAFs||Included via Basic and Advanced WAFs Advanced WAFs include advanced rules.|
|L7 DDOS: HTTP large headers*||Included via Service Policy Rules||Included via Service Policy Rules||Included via Service Policy Rules|
|L7 DDOS: OCSP Stapling*||Included via Service Policy Rules||Included via Service Policy Rules||Included via Service Policy Rules|
|L7 DDOS: HSTS Settings*||Included via Service Policy Rules||Included via Service Policy Rules||Included via Service Policy Rules|
|L7 DDOS: SSL client authentication (using a certificate)*||Included via Service Policy Rules||Included via Service Policy Rules||Included via Service Policy Rules|
|L3/7 DDOS: Black/White lists of Source IP lists||Included via Service Policy Rules||Included via Service Policy Rules||Included via Service Policy Rules|
|L3/7 DDOS: AS Number Filtering||Included via Service Policy Rules (https://volterra.io/docs/how-to/advanced-security/configure-ip-prefix#create-ip-prefix-sets)||Included via Service Policy Rules (https://volterra.io/docs/how-to/advanced-security/configure-ip-prefix#create-ip-prefix-sets)||Included via Service Policy Rules (https://volterra.io/docs/how-to/advanced-security/configure-ip-prefix#create-ip-prefix-sets)|
|L3/4 DDOS: Volumetric DDOS Detection||Layer 3/4 Volumetric DDOS protection is included when customers’ VIP is advertised on the Global Network||Layer 3/4 Volumetric DDOS protection is included when customers’ VIP is advertised on the Global Network||Layer 3/4 Volumetric DDOS protection is included when customers’ VIP is advertised on the Global Network|
|L3 DDOS: Rate-limit Ingress Traffic to entire VIP||-||Included via FastACLs and Policer Action||Included via FastACLs and Policer Action|
|L3 DDOS: Rate-limit Ingress Traffic from whitelisted IPs to entire VIP||-||Included via FastACLs and Policer Action||Included via FastACLs and Policer Action|
|L7 DDOS: Ratelimit Traffic to specific URL/API endpoints from specific clients||-||-||Included via Rate Limiter policy rules.|
|L3/7 DDOS: Preserving IP of original requester behind CDN*||Included via Service Policy Rules||Included via Service Policy Rules||Included via Service Policy Rules|
|L3/7 DDOS: FW Origin IP*||Included via Service Policy Rules||Included via Service Policy Rules||Included via Service Policy Rules|
How many VIPs do I need? If I have 5 FQDNs, do I need 5 VIPs?
You don’t need a VIP per FQDN. All 5 FQDNs can be on the same VIP. Alternatively, each FQDN can be on separate VIP. The choice of number of VIPs depends upon your architecture. Some customers might want to have all their public APIs/URLs on one VIP, and important API/URLs , such as payment URL, or SaaS portal, on another VIP.
What is Rate Limiting in your plan description? Do I need it?
Rate Limiting per user provides the ability to rate limiting the number of requests originating from a particular user. The user can be defined by client IP address, cookie name, HTTP header name, query parameter key.
Please refer to Rate Limiting guide.
Do I need Rate Limiting for protecting my website ?Rate limiting is an advanced security protection concept. There are several advanced use cases where it could potentially be used. Examples include
Example 1: Say your website provides services to premium and free customers. And say, your website gets overloaded frequently. You might be working on increasing your capacity to meet the demand. However, in the interim, you want to ensure the user experience for your premium users is not affected due to increased load from the free users. In this case, one solution you could implement is to do http-header-name or cookie-name based rate limiting. Premium vs. free user’s traffic can be tagged at the client side with a premium-user-http-header or premium-user-cookie-name or free-user-http-header or free-user-cookie-name. And then you can ratelimit the free user’s traffic to your website, ensuring the premium user’s user-experience is not affected by the free users.
There are many other ways to solve this problem without using per user rate limiting. You could have two different VIPs, and two different websites for free vs. premium users.
Do I need API security and Anomaly detection to protect my Public API or my Website?
API security and Anomaly detection is an advanced capability that provides users ability to characterize how their APIs are being consumed, traffic patterns to their APIs, and the latency experienced by the users of the APIs. Moreover, Anomaly detection identifies patterns of API usage, baselines the patterns and identifies anomalies in the patterns.
How does billing for rate limiting per client work?
F5® Distributed Cloud Mesh rate limit per client automatically identifies and mitigates excessive request rates for specific URLs or for an entire domain. Rate Limiting protects against brute force attacks and limits access to forum searches, API calls, or resources that involve database-intensive operations at your origin.
You will then be charged
$0.05 per 10,000 requests. For example, if you had a total of 40,000 good/allowed requests matching any rate-limiting rule, you will be charged
$0.20 in total for Rate Limiting on your next billing date. The charge will appear as a line item on your invoice and will list the total number of requests billed.
Rate Limiting is billed based on the number of good (not blocked) requests that match your defined rules across all your websites. Each request is only counted once so you will not be double charged if a request matches multiple rules.
For example, given a rule that matches
acmecorp.com/login/* and blocks clients that send over 30 requests per minute:
Client A sends 45,000 requests to acmecorp.com/login/premium at a rate of 10 requests per minute. All requests are allowed.
Client B sends 120,000 requests to acmecorp.com/login/free, usually at a rate of 10 requests per minute, but with bursts over 30 requests per minute. 90,000 of their requests are blocked during the bursts, and 30,000 are allowed when their request rate is lower.
Client C sends 80,000 requests to acmecorp.com/docs at a rate of 40 requests per minute. While this exceeds the threshold, it doesn't match the rule path, so all 80,000 requests are allowed.
In this example, 75,000 (45,000 + 30,000) requests are billable: clients A and B both sent requests that matched the rule, but some of client B's requests were blocked, and those blocked requests were not billed. In total, the cost is
(75,000/10,000) * $0.05 = $0.375.
|Client||Request URL||Requests||Outcome||Monthly Cost|
|A||acmecorp.com/login/premium||45,000 at 10 req/min||URL pattern matches but threshold is not exceeded. All requests pass through.||
|B||acmecorp.com/login/free||120,000: 90,000 at 30 req/min + 30,000 under 30 req/min||URL pattern matches. Rule blocks 90,000 and allows 30,000 requests.||
|C||acmecorp.com/docs||80,000 at 40 req/min||URL pattern doesn't match. Rule doesn't apply. All requests pass through.||