When did you last look at the virtual machine (VM) size running your chosen NGFW in Azure? For most organisations the honest answer is “when we built it”, and that was years ago. The network virtual appliance (NVA) has done its job quietly ever since, so nobody has had a reason to revisit it.
Here’s the thing: this is almost never a performance problem. Very few customers are tapping out the throughput of their firewall. It’s a platform problem. Azure needs to retire the hardware sitting underneath those old VMs, and Microsoft has started removing the commercial reasons to stay put.
Why Now? Microsoft pulled the Reservation lever
Most firewall vendors still ship Azure Resource Manager (ARM) templates that default to the original Fs or Fsv2 sizes. Deploy from the marketplace and that is very likely what you get. Those sizes are now the wrong end of the roadmap, and the billing has caught up with them.
From 1 July 2026, Microsoft no longer sells or renews one-year Reserved VM Instances for several legacy VM series including F, Fs and Fsv2. Reservations are a billing construct, so existing commitments run to the end of their term with no disruption to running workloads. The pain arrives at expiry, when the discount stops and the firewall quietly reverts to pay-as-you-go. That’s textbook bill shock, and it’s entirely avoidable.
Microsoft’s guidance points at two exits: trade into an Azure savings plan for compute, which is not tied to a VM family or region, or modernise onto newer sizes. For a firewall NVA, modernising is usually the better answer, because you were going to be forcibly moved off the old hardware later anyway.
What you actually get on Fv7
There is no dedicated “firewall SKU” in Azure. What you want is the compute-optimised F-family, and its v7 generation runs on AMD’s 5th Generation EPYC 9005 “Turin” processor, boosting to 4.5 GHz.
Three things matter for a firewall:
- Full cores, no hyperthreading: The v7 series drops Simultaneous Multithreading (SMT), so each vCPU maps to a full physical core. Your data plane threads get dedicated, uncontested silicon, which means more predictable throughput and less jitter under load.
- A better NIC-to-core ratio: The series scales from 2 to 15 network interface cards (NICs), so you can provision the multiple interfaces an NVA needs without paying for cores you will never use.
- MANA as standard: v7 uses the Microsoft Azure Network Adapter (MANA) in place of the older ConnectX path and pushes up to 80 Gbps against 36 Gbps on the v6 generation.
Here is how the Falsv7 sizes compare with the two generations most firewalls are running on:
| Specification | F / Fs (original) | Fsv2 | Falsv7 (new) |
| Processor | Intel Xeon E5-2673 v3 (Haswell), 2.4 GHz | Intel Xeon Platinum (Skylake to Emerald Rapids) | AMD EPYC 9005 (Turin), to 4.5 GHz |
| Cores | Hyperthreaded | Hyperthreaded | Full physical cores |
| Max vCPUs | 16 | 72 | 80 |
| Max NICs | 8 | 8 | 15 |
| Max network throughput | 12 Gbps | 30 Gbps | 80 Gbps |
| Network interface | NetVSC | NetVSC / ConnectX / MANA | NetVSC / MANA |
Which Fv7 size should you pick?
The v7 line comes in three memory ratios, and firewalls lean on cores and NICs far more than on memory:
- Falsv7 (2 GiB per vCPU): the low-memory option and our default for firewall NVAs. You are buying cores and network interfaces, not RAM, so this is where the money goes furthest.
- Fasv7 (4 GiB per vCPU): the balanced option, worth it when intrusion prevention and application control push your memory use up.
- Famsv7 (8 GiB per vCPU): the high-memory option, for heavy deep-packet inspection, very large connection tables, and Transport Layer Security (TLS) inspection at scale.
- The “d” variants (Faldsv7, Fadsv7, Famdsv7): add a local temporary disk. The standard Falsv7 sizes ship with no local storage at all, so pick a “d” size if your appliance wants scratch space for logs or caching.
For most of our customers the practical answer is simpler than that. If you are running an F4s, the F4als_v7 is your like-for-like replacement, and it’s the size we see most often in high-availability, active-passive firewall pairs:
| Specification | F4s (today) | F4als_v7 (replacement) |
| vCPUs | 4 | 4 |
| Memory | 8 GiB | 8 GiB |
| Max NICs | 4 | 4 |
| Cores | 4 hyperthreaded | 4 full physical cores |
| Processor | Intel Xeon E5-2673 v3 (Haswell), 2.4 GHz | AMD EPYC 9005 (Turin), to 4.5 GHz |
Same vCPU count, same memory, same four NICs, allowing for dedicated high-availability sync and management interfaces. What changes is underneath: four full Turin cores in place of four hyperthreaded Intel ones, and MANA as standard.
Get MANA-ready before you move
This is the step that catches people out. The Fv7 sizes are built for MANA, so moving to them without a MANA-capable appliance build is a downgrade, not an upgrade.
- Mind the minimum versions: FortiOS below 7.6.1 and PAN-OS below 12.1.5 lack the MANA drivers and drop back to the synthetic network path.
- Know the cost of getting it wrong: Palo Alto’s own advisory puts that fallback at a 50% or greater cut in maximum throughput, and it happens with no warning after a redeploy or servicing event.
- Treat the tag as a bridge: the LegacyVMNVA tag holds appliances on non-MANA hardware, but it is only honoured until 31 May 2027. It only buys you a migration window.
We covered the detail, including the tagging process and how to check your exposure, in Get Your FortiGate and Palo Alto NVAs Ready for Azure MANA. Upgrade to a MANA-ready build first, then move the VM size. Doing it the other way around is how you end up explaining a throughput drop to the business.
The Hub-Swap: Build the new one beside the old one
Here’s where most people go wrong. They try to resize in place, upgrade the appliance under load, and change the routing, all in the same maintenance window, on the firewall the whole business depends on. Do not hack at something old but working.
- We call the alternative a hub-swap: build a brand-new firewall hub in parallel, prove it, then move traffic to it. It’s the same argument we made about DMZs, that this is an opportunity rather than just a migration, and it applies exactly to a firewall refresh.
- Build it new, in code: stand the replacement hub up with infrastructure as code (IaC) rather than clicking through a portal or reusing a vendor template you have quietly edited for years. You get a repeatable build, a reviewable diff, and an honest answer to “what is actually configured?”
- Fix the routing while you are there: if you’re still hand-maintaining user-defined routes, look at Azure Route Server. It peers with your NVA over Border Gateway Protocol (BGP) and programs the learned routes into Azure’s software defined network automatically, which removes the manual route table updates and supports active-passive pairs natively.
- Test properly, not at 2am: with both hubs standing you can run real traffic through the new one, validate rules and throughput, and confirm the MANA data path is engaged, all before anything depends on it.
- Then coordinate the cutover: the change itself becomes a routing change you have already rehearsed, with the old hub still sitting there as your rollback. That is a very different conversation with your change advisory board.
The same logic we set out in our article “Moving Your DMZ to Azure? It’s an Opportunity, Not Just a Migration”, applies here: rebuilding gives you the chance to retire the workarounds that accumulated in the original build, rather than carrying them across to new hardware.
Check these while you build
- Generation 2 and NVMe only: the v7 series supports Generation 2 VMs only and will not run on an image without NVMe (Non-Volatile Memory Express) support. Old firewall images may simply fail to boot.
- No local disk on the standard sizes: Falsv7 ships with no local temporary storage, so check what your appliance expects, or pick a Faldsv7 size instead.
- Regional rollout: new sizes land region by region. Confirm availability in your target region before you design around it.
- Vendor certification: confirm the size against your vendor’s supported list, as well as how many vCores your licensing allows.
Final Thoughts
Your firewall is not slow. It is sitting on hardware Azure wants to retire, and Microsoft has removed the reservation discount that made staying put feel sensible. The Fv7 sizes are the natural landing place: full cores, MANA as standard, and F4als_v7 as a like-for-like swap for the F4s most active-passive pairs are running on. Do not resize in place and hope. Build the new hub in code beside the old one, get onto a MANA-ready build, test it properly, and cut over on your terms with a rollback option still available should you need it.
Not sure when your firewall reservations expire, or what the right firewall size looks like? Get in touch with Codify for an obligation-free chat.
