Regional Edge SaaS Application Deployment Recommended Practices

[netta2]

The guidelines presented in this walkthrough are informed by extensive field experience, incorporating insights from customers, F5 Solutions Engineers, Architects, and Professional Services teams. Having supported numerous deployments across diverse environments, this cumulative knowledge provides a practical and reliable starting point for publishing applications. This guide aims to help navigate the Distributed Cloud platform, offering a balanced approach to application delivery and security.

The below figure represents the HTTP-LB configuration options alongside the typical flow of traffic from downstream client to upstream origin or application endpoint.

Prerequisites:

Article on how Distributed Cloud advertises and picks up traffic (Listener Logic) can be found here:

F5 Distributed Cloud - Listener Logic

 

Domains and Certificates:

This is where you define what the load balancer listens on and how it presents itself to clients. For an initial deployment with a publicly accessible application, the following settings cover most use cases.  We recommend a single HTTP-LB per application for visibility, telemetry, day 2 operations, and blast radius.  Any more consolidation may cause friction going forward.

Recommended Settings:

• Domain Name:Your application FQDN (e.g., app.example.com)
• Load Balancer Type:
  • Certificate: Use F5 XC Auto-Cert when possible. If your domain is delegated to XC DNS, certificate management is fully automated. For non-delegated domains, F5 XC provides a cname challenge record value that you can add to your DNS provider to satisfy the Lets Encrypt ACME challenge, then add the provided Host Name.ves.io CNAME record pointing to XC to complete the certificate setup
    • HTTP to HTTPS Redirect:Enable
    • HSTS Header:Enable
  • Listener Port: 443
  • Client-Side TLS: High security profile
  • Protocol: HTTP/1.1 and HTTP/2

 

Origins and Health Checking:

Origin Pools:

A note on structure and origin access: Use Routes (covered in the next section) as the primary mechanism for attaching Origin Pools to your HTTP LB. The default Origin Pool field on the HTTP LB itself is best reserved as a potential fallback option depending on origin and route design (Engage your F5 SE if you need to discuss further). This approach gives you path-aware routing controls and per-route retry and timeout tuning.  Also at the origin premise you should limit access to F5 Distributed Cloud RE’s only.  You have a few options to achieve this.  Limit via a security group or IP Access List to RE IP ranges, mTLS, insert a response header from the HTTP-LB that the origin server is expecting, or a combination of the 3.

Recommended Settings for Publicly Available Endpoints:

• Origin Server Type: Public IP-based.
  • Provide the IPv4 address directly.
  • Where possible, target origins by IP with Host Header.
  • If using public DNS-based origin endpoint targeting, be aware that XC does not honor standard DNS TTL and overrides the value!
• Origin Server Port: 443
• Connection Pool Reuse: Enable
• Health Check Port: Endpoint port (same as origin port unless otherwise directed)
• Load Balancing Algorithm: Load Balancer Override (Load Balancer algorithm set at HTTP-LB)
• Endpoint Selection: Local Endpoints Preferred (Distributed Cloud Construct to leverage local endpoints over remote endpoints goal is to Egress the same RE as Ingress)

TLS to Origin:

• Enable TLS
  • SNI: Host Header
  • TLS Security Level: High
  • Origin Server Verification: Use Default Root CA Certificate
  • mTLS: Disable unless required

Other Origin Pool Options:

• Exception Handling: Setup for specific application/origin server requirements (configurable options available for application specific error-handling requirements)
• Origin Server Subsets: Disable unless you have a specific canary or subset routing requirement
• HTTP Protocol Configuration: Automatic (adjust to a specific version if your origin requires it)
• Proxy Protocol: Disable
• LB Source IP Persistence: Disable

Health Checks:

The default health check thresholds are tuned conservatively. In practice, this means a failed origin stays in rotation longer than it should, and a recovered origin comes back into rotation slowly. Adjust the thresholds to react more aggressively to recovery while still being tolerant of transient failures.

Recommended Health Check Settings:

Setting	Recommended Value	Default	Why
Healthy Threshold	1	3	Bring a recovered endpoint back into rotation after a single successful check
Unhealthy Threshold	3	1	Require 3 consecutive failures before removing an endpoint — avoids flapping on transient issues
Interval	15 seconds	15 seconds	No change needed
Jitter Percent	30%	30%	Stagger health check timing across endpoints (30% of 15s = up to 4.5s offset)

Key insight for jitter setting: 

When you have multiple endpoints in a pool, health checks without jitter all fire at the same instant that can create amongst other issues a temporary artificial network congestion or failure at endpoints. The 30% jitter setting randomizes the start time of each health check within a window (default: 15s interval with a 30% jitter, so checks are offset by up to 4.5 seconds). Leave this at the default unless you have a specific reason to change it.

Advanced health check options:

• Host Header: Set to the value your application expects (do not leave blank if your origin validates the Host header)
• Path: Set a meaningful health endpoint like /healthz a common convention, but use whatever your application exposes
• Expected Status Codes: 200, 3xx
• Request/Response Header Manipulation: Add or remove headers as required by your application
• Expected http response: Validate the Raw Bytes expected in the Response of HTTP Health Check

Origin Pool Display in UI:

Routes:

Routes are where your HTTP LB gains precision. Rather than sending all traffic to a single origin pool, Routes let you make forwarding decisions based on path, method, headers, and query parameters. They also expose per-route controls for timeouts, retries, header manipulation, and security policy controls that are not available at the origin pool level.

Recommended Route Configuration:

• Route Type: Simple Route
  • HTTP Method: Any
  • Path Match:
    • Prefix (use Regex or Exact match when you need more specificity)
    • /
  • Headers: Add header match conditions only if required
  • Port Match: Adjust only if needed
  • Origin targeting:
    • Origin Pools:Add the Origin Pool(s) you configured in the previous section
  • Host Rewrite Method: Automatic Host Rewrite (or set a specific value if your origin requires a fixed Host header)
  • Query Parameters: Retain (Remove and Replace are available options)
  • Route Activation: Enabled (Disable option)
• Advanced route options:
  • Load Balancing Control: Use LB Hash Policy
  • Priority: Default
  • Origin Server Subsets: Leave unset unless subset routing is required
  • Request/Response Manipulation:
    • Header add/remove, cookie add/remove, set-cookie add/remove -configure as needed for your application
  • Security (per-route overrides):
    • WAF:Inherit from HTTP LB (recommended) or specify a different policy per route
    • WAF Exclusion:Inherit from HTTP LB or specify an Exclusion Policy — see the note in the Gotchas section below on inline exclusions
    • CORS and CSRF:Configure as needed
  • Protocol Upgrades:
    • SPDY:Disable (enable only if required)
    • WebSockets:Disable (enable only if your application requires WebSocket support)

Retry Policy:

Key insight “retry values”:

The retry settings below are tuned for typical HTTPS application traffic. The per-retry timeout of 1000ms prevents a slow origin from consuming the full route timeout on every attempt, and the retry interval backoff (25ms initial, 2500ms max) avoids hammering a struggling origin. Validate these values with load testing before going live.

Custom Retry Policy Settings:

• Retry Conditions:
  • 500
  • Gateway-error
  • Connect-failure
  • Refused-stream
  • Reset
  • Retriable-4xx
• Number of Retries: 3
• Per-Retry Timeout: 1000ms
• Retry Interval: 25ms
• Max Retry Interval: 2500ms

Miscellaneous Route Options:

• Route Timeout: 30000ms (30 seconds)
• Route-Specific Buffering: Common
• Mirroring: Disable

Cluster Retract:

• Disable (validate with testing before enabling)

Security Settings:

Security configuration in F5 XC is layered. The settings below represent a solid baseline for an initial deployment. Individual applications will likely require tuning — use this as a starting point, not a final state.

Web Application Firewall:

The recommended starting posture is blocking mode with High and Medium attack signatures active. This catches the most common attack patterns while keeping false positive rates manageable. Do not start in detection-only mode and leave it there — establish a review cycle and move to blocking on a defined schedule.

• WAF: Enable
  • Enforcement Mode: “Monitor” then after review migrate to “Blocking”
    • Security Policy:Custom
      • Attack Signatures:
        • Default signature set
        • High, Medium, and Low severity
    • Automatic Attack Signature Tuning:Disable
    • Automatic Signature Staging:Enable (7days)
    • Threat Campaigns:Enable
    • Violations:Default
    • Signature-Based Bot Detection:Default
  • Enhance with AI: Enable
    • Mitigate High and Medium (have a review cadence)
• WAF Exclusion: Use a dedicated WAF Exclusion Policy object — do not use inline exclusions (see Gotchas below)
• Additional WAF-adjacent features — configure as needed for your application:
  • Data Guard
  • CSRF Protection
  • GraphQL Inspection
  • Cookie Protection

API Protection:

Enable as needed. If your application exposes a defined API surface, uploading an OpenAPI spec and enabling API Discovery is a worthwhile early step.

Malware Protection:

Disable

DoS Settings:

• Mitigation Action: Block
• RPS Threshold: Typically based on Capacity of origin application endpoints
• Client-Side Challenge: Enabled if web based application
• Custom Service Policy for DoS: Apply a specific geo location and IPI during DDoS
• DDoS Mitigation Rules: Default
• Slow DDoS: Default

Service Policies:

Service Policies match on a set of criteria and apply an action. They operate at the connection level and complement WAF, which operates at the request content level.

• Service Policies: Apply Specified Service Policies (list any access restriction policies you need)
• IP Reputation: select the reputation categories appropriate for your threat model
• Threat Mesh: Disable
• User Identifier Policy: Create a policy using Client IP and TLS Fingerprint based on JA4 as identifiers (other identifier types are available)
• Malicious User Detection: Enable
• Malicious User Mitigation: Enable, Default settings
• Rate Limiting: Configure as needed based on expected traffic profile
• Trusted Client Rules: Configure as needed
• Client Blocking Rules: Configure as needed
• CORS Policy: Configure as needed

 

Other Settings:

VIP Advertisement:

This is what makes the HTTP LB publicly reachable through the F5 Regional Edge network. If you change this to a Custom setting, validate your advertisement policy carefully as a misconfiguration here means no traffic reaches your LB.

• Advertise
  • Internet

Load Balancing Algorithm:

Choose based on your application’s session and traffic characteristics. Round Robin is the default and works for most stateless applications. If you have session affinity requirements, evaluate the hash-based options.

Trusted Client IP:

Disable unless you have a specific use case that requires preserving the original client IP through a proxy chain upstream of XC.

Location Header:

Enable “Add XC RE Ingress Location” to include the Regional Edge location in response headers. This is useful for troubleshooting and for understanding which RE node handled a request.

Header and Cookie Options:

Configure request/response header additions, removals, and cookie manipulation as required by your application.

Error Response:

Configure custom error response pages as needed. The default F5 error pages are functional but not branded.  Most production deployments will want custom responses for 4xx and 5xx errors.

Buffer Policy:

• Default: No buffering (requests are streamed to the origin)
• Max Buffer Size: 10,485,760 bytes (10MB) – if the request body exceeds this, XC returns HTTP 413 (Payload Too Large)
• Timeout behavior: If the full request body is not received before the timeout, XC returns HTTP 408 (Request Timeout)
• When to enable: Enable buffering if your origin cannot handle streaming request bodies, or if you are using WAF inspection on large POST requests

Compression:

• Algorithm: GZIP only (not configurable)
• Compression Level: 5 (not configurable)
• Behavior: XC compresses responses dispatched from the upstream origin when the client signals support via “Accept-Encoding”
• Enable if your origins do not already compress responses and your client traffic includes browser-based users

Idle Timeout:

• Default: Client Side - 30 seconds
• Behavior: A stream with no activity (upstream or downstream) for this duration is terminated with HTTP 504
• Increase for applications with long-running server-sent events, streaming responses, or slow upload scenarios

Common Gotchas:

These are the issues that come up repeatedly in initial deployments. Check these before you go live.

Using DNS-based origin targeting instead of IP + Host Header:

By default Distributed Cloud rewrites the host header so validate and set appropriately.  DNS-based origin targeting works but introduces a dependency on DNS TTL behavior that XC does override in non-standard ways. During a failover event, you may experience stale resolution longer than you expect. Use IP-based origin with Host Header wherever possible for predictable behavior.

Not Configuring a Health Check at all or Leaving health check thresholds at defaults: 

By default, a health check is not added to an origin pool.  Also, the default Healthy Threshold of 3 means a recovered origin must pass 3 consecutive checks before re-entering rotation. If your check interval is 15 seconds, that is 45 seconds of unnecessary exclusion for an endpoint that came back healthy. Set Healthy Threshold to 1. The default Unhealthy Threshold of 1 is the opposite problem a single failed check removes the endpoint. Set Unhealthy Threshold to 3 to tolerate transient blips.

Attaching Origin Pools directly to the HTTP LB instead of utilizing Routes: 

The default Origin Pool field on the HTTP LB is a catch-all fallback. If you attach your primary origin there and do not configure Routes, you lose access to per-route retry policies, timeouts, header manipulation, and security overrides. Build your routing structure with explicit Routes from the start.

Starting in WAF Monitor mode and never switching to blocking: 

Monitoring mode is a valid tuning step, but it is easy to leave it there indefinitely. Set a review date when you configure monitor mode. Establish your false positive baseline and move to blocking on a defined timeline.

Not setting a Host Header on the health check: 

Leaving the Idle Timeout at 30 seconds for streaming applications: 

The 30-second idle timeout will terminate long-lived connections, WebSocket connections, server-sent event streams, slow uploads without warning. If your application uses any of these patterns, increase the Idle Timeout before testing.