Software as a Service | Benefits | Working | Use case | Future | Tips
What is Software as a Service ( SaaS )? Software as a Service (SaaS) is a type of…
F5 BIG-IP Virtual Edition runs in Azure as a virtual machine, providing load balancing, WAF, SSL offload and access control. It is deployed when Azure’s native Load Balancer and Application Gateway do not cover what you need, typically iRules, advanced health monitors, or consistency with an existing on-premises F5 estate.
Do You Actually Need It?
Worth asking first, because BIG-IP VE is a substantially more expensive and more complex option than the native services.
| Requirement | Use |
|---|---|
| Layer 4 TCP/UDP distribution | Azure Load Balancer |
| Layer 7 HTTP routing plus a basic WAF | Azure Application Gateway |
| Global multi-region traffic steering | Azure Front Door / Traffic Manager |
| iRules, complex traffic manipulation | F5 BIG-IP |
| Advanced WAF policies you already own | F5 BIG-IP |
| Consistent config with on-premises F5 | F5 BIG-IP |
| Non-HTTP protocols needing Layer 7 logic | F5 BIG-IP |
The strongest case is operational rather than technical: if your team already runs F5 on-premises, running the same platform in Azure means one skill set, one configuration model and one set of iRules.
Licensing Models
| Model | How it works | Suits |
|---|---|---|
| PAYG | Hourly from the Azure Marketplace, licence included | Short-term, testing, variable load |
| BYOL | You buy the licence from F5 and apply it | Long-running production, cheaper over time |
| ELA / subscription | Enterprise agreement covering many instances | Large estates |
PAYG throughput tiers (25 Mbps, 200 Mbps, 1 Gbps and up) are enforced by the licence, not the VM size. Size the licence to your peak traffic, an oversized VM on an undersized licence is throttled and the symptom looks like a performance problem rather than a licensing one.
Single-NIC vs Multi-NIC
| Single-NIC | Multi-NIC (3-arm) | |
|---|---|---|
| Interfaces | One, management and data share it | Management, external, internal |
| Complexity | Low | Higher |
| Traffic separation | None | Proper separation |
| Suits | Dev, test, simple deployments | Production |
Use multi-NIC in production. Sharing management and data traffic on one interface means a data-plane problem can also cost you management access, which is exactly when you need it.
NIC count is limited by VM size. A three-NIC deployment needs a VM size supporting at least three, so check the size before designing the topology rather than after.
Deployment Steps
- Plan the VNet and subnets, separate subnets for management, external and internal. Our Azure networking concepts guide covers the building blocks. Remember Azure reserves five addresses per subnet.
- Deploy from the Azure Marketplace, or use F5’s ARM or Terraform templates, which handle the NIC and routing configuration correctly.
- Assign NSGs. Management restricted to your admin ranges only; external open to the traffic you intend to serve.
- Connect and license. Reach the management interface over HTTPS on 443 or SSH, complete the setup utility, and apply the licence.
- Provision modules, LTM at minimum, plus ASM, APM or others as required. Each consumes memory, so provision only what you use.
- Configure VLANs and self-IPs matching the Azure subnets.
- Create pools with health monitors, then virtual servers pointing at them.
- Attach an Azure Public IP to the external NIC, or front the whole thing with an Azure Load Balancer.
- Test failure, take a pool member out and confirm traffic moves.
The HA Model Is Different in Azure
This is the single biggest departure from an on-premises deployment, and the most common source of a failed design.
On-premises, an F5 HA pair uses gratuitous ARP to move a floating IP between units. Azure’s software-defined network does not honour gratuitous ARP. The traditional mechanism simply does not work.
Azure deployments use one of these instead:
| Method | How it works | Failover time |
|---|---|---|
| API-based failover | The active unit calls the Azure API to move the IP configuration or update route tables | Tens of seconds, API-dependent |
| Azure Load Balancer in front | An ALB health-probes both BIG-IPs and sends traffic to the healthy one | Seconds, faster and more predictable |
| Active/active with ALB | Both units serve traffic behind the ALB | Immediate, no failover event |
Fronting the pair with an Azure Load Balancer is the more robust pattern. API-based failover depends on the Azure control plane responding promptly, and it needs a service principal or managed identity with permission to modify network resources, one more thing that can be misconfigured or have its credentials expire.
Whichever you choose, place the two instances in an Availability Set or across Availability Zones, or a single host fault takes both down.
Routing Traps
- Asymmetric routing. If backend servers have their own route to the internet, replies bypass the BIG-IP and connections break. Fix with SNAT on the virtual server, or a User Defined Route forcing return traffic back through the BIG-IP.
- SNAT hides the client IP. Necessary in most Azure designs, but the backend then sees the BIG-IP’s address. Insert
X-Forwarded-Forfor HTTP traffic and configure the application to trust it. - IP forwarding must be enabled on the BIG-IP’s NICs in Azure, or it silently drops transit traffic. This is an Azure NIC setting, not a BIG-IP one.
- NSGs are evaluated before the BIG-IP. A rule blocking the traffic means the BIG-IP never sees it, and its logs will show nothing at all, which makes it look like a BIG-IP problem when it is not.
- UDRs override system routes. Check the effective routes on the NIC, not just the route table you intended to apply.
Sizing and Cost
- Accelerated Networking should be enabled on supported VM sizes, it is a significant throughput improvement for no extra cost.
- SSL/TLS handling is CPU-bound. If you terminate TLS at high volume, CPU is the constraint, not network bandwidth.
- Match the licence tier to peak traffic, not average, throttling at peak is what users notice.
- Budget for two instances plus an Azure Load Balancer, not one. A single BIG-IP is a single point of failure in front of everything behind it.
- Cross-zone data transfer is billed. Spreading across zones improves resilience and adds cost.
Frequently Asked Questions
Can I use Azure Load Balancer instead of F5?
For Layer 4 distribution, yes, and it is far cheaper. Azure Application Gateway covers Layer 7 HTTP routing with a basic WAF. F5 is warranted when you need iRules, advanced WAF policies, or configuration consistency with an existing on-premises estate.
Why does my F5 HA pair not fail over in Azure?
Because Azure’s network does not honour gratuitous ARP, which is how on-premises failover works. Azure deployments need API-based failover or an Azure Load Balancer in front of both units.
Should I use single-NIC or multi-NIC?
Multi-NIC for production, so management and data traffic are separated. Single-NIC is fine for testing. Check the VM size supports the NIC count you need before designing.
Is PAYG or BYOL cheaper?
PAYG for short-term or variable workloads. BYOL is normally cheaper for anything running continuously, and the crossover point is typically a few months.
Why does my backend see the F5’s IP instead of the client’s?
Because SNAT is applied, which is usually necessary in Azure to avoid asymmetric routing. Insert X-Forwarded-For on the virtual server and configure the application to read it.
Do I need two instances?
For anything production, yes. A single BIG-IP is a single point of failure in front of every application behind it. Deploy a pair across Availability Zones with an Azure Load Balancer distributing to them. See software load balancers for the wider comparison.
