Infrastructure as a Service (IaaS) | Benefits | Working | Use Case | Tips
What is Infrastructure as a Service ( IaaS )? Infrastructure as a Service (IaaS) is an on-demand computing…
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.
