Sophos Firewall: Hardware, Virtual, or Cloud?
Sophos Firewall can be operated as an XGS Hardware Appliance, Virtual Appliance, Software Appliance, or Cloud Deployment. Technically, Sophos Firewall OS runs on all, but the operational model is not the same. The decision affects performance, support, port design, HA, recovery, licensing, monitoring, and who is responsible for which platform in case of a fault.
For new projects, it’s important not only to ask which variant seems cheaper. The key is which variant fits the location, virtualization platform, cloud architecture, and operations team. For performance sizing, the Sophos Firewall Sizing Guide is also important.
Quick Decision
| Variant | Usually fits when |
|---|---|
| XGS Hardware Appliance | a location needs a dedicated, clearly supportable firewall with physical ports |
| Virtual Appliance | a stable virtualization platform is available and network zones can be cleanly separated virtually |
| Software Appliance | own hardware is deliberately operated and supported as a firewall platform |
| Cloud Deployment | workloads in AWS or Azure need to be protected or connected with local networks |
The most important rule: A virtual or cloud firewall is not a free pass for less planning. CPU, RAM, storage, virtual switches, routing, HA, backup, and monitoring must be planned as carefully as with hardware.
When to Be Cautious
The decision should not be based solely on what is technically possible. Some environments look flexible on paper but create unnecessary risks in operation.
| Warning Signal | Why It Is Critical |
|---|---|
| Hypervisor is already heavily loaded | IPS, TLS Inspection, VPN, and logging require predictable CPU and I/O reserves |
| WAN, LAN, DMZ, and management run over the same physical bottleneck | A logically clean separation helps little if the real data path is overloaded or incorrectly segmented |
| No team feels jointly responsible for hypervisor and firewall | Disruptions remain stuck between platform, network, and firewall teams |
| HA was only planned as a checkbox | Without host, storage, network, and restore testing, high availability is not proven |
| Cloud routing is not fully documented | The firewall only protects traffic that is actually routed through it |
| Restore has never been practiced | A backup is only reliable when a restoration has been realistically tested or at least cleanly planned |
In such cases, an XGS Hardware Appliance is often not less modern but simply the more robust operational decision. Conversely, a virtual or cloud firewall can be very sensible if platform, network design, monitoring, and responsibilities are clearly defined.
XGS Hardware Appliance
An XGS Hardware Appliance is usually the most predictable variant for classic locations. Hardware, ports, support, RMA, lifecycle, and Firewall OS come as a coordinated system.
Advantages:
- dedicated firewall hardware,
- fixed port configuration and expansion options,
- clear assignment of WAN, LAN, DMZ, HA link, and management,
- simple hardware support and replacement process,
- no dependency on hypervisor resources,
- well-suited for branches, main locations, and edge firewalls.
The biggest advantage lies in operation: If there is a problem, you don’t have to first clarify whether the hypervisor, vSwitch, storage, cloud routing, or the firewall itself is the cause. For many SME locations, this is more important than maximum flexibility.
Virtual Appliance
A virtual Sophos Firewall is sensible if a clean virtualization platform is already available and the firewall is to be integrated into a data centre, a multi-tenant environment, or an internal segmentation design.
Relevant virtual platforms include VMware, Microsoft Hyper-V, KVM, Nutanix Prism, and Citrix Hypervisor. It is important that the platform, management tools, and network configuration are current and supported.
Key operational questions:
- Are CPU resources guaranteed or heavily overbooked?
- Is RAM and storage sufficiently sized?
- Are virtual NICs and port groups clearly separated?
- Are there dedicated network paths for WAN, LAN, DMZ, HA, and management?
- Is promiscuous mode, VLAN trunking, or SR-IOV needed?
- Is there a clean backup and restore concept?
- Is it clear who jointly troubleshoots hypervisor, storage, and firewall?
A virtual firewall can work very well. However, it quickly becomes problematic if it runs on an overloaded host or if WAN, LAN, and management only look logically clean but physically run over the same bottlenecks.
Software Appliance
A Software Appliance is installed on own hardware. This can be sensible for labs, special environments, or very targeted designs. In normal customer operations, this variant should be chosen deliberately because hardware selection, drivers, spare parts, monitoring, and support are more the operator’s responsibility.
Check:
- Is the hardware suitable for continuous operation?
- Are network cards, storage, and BIOS/UEFI configuration appropriate?
- Is there spare hardware?
- Is the installation and recovery process documented?
- Who is responsible for hardware failures?
For standard locations, an XGS Hardware Appliance is often simpler. For technical special cases, a Software Appliance can still fit if the operations team manages the platform cleanly.
Cloud Deployment
Cloud Deployments are particularly sensible when workloads in AWS or Azure need to be protected or when cloud networks need to be connected with local sites. In the cloud, different questions are important than at a classic location.
Plan for:
- VPC/VNet design,
- routing tables,
- availability zones,
- elastic IPs or public IPs,
- site-to-site VPN or SD-WAN,
- logging and central evaluation,
- cloud costs for instance, storage, traffic, and HA design,
- operational responsibility between cloud team and firewall team.
A cloud firewall does not replace a clean cloud network design. Only the paths that are actually routed through the firewall are protected.
Performance and Sizing
With hardware, performance results from the chosen model. With virtual, software, and cloud deployments, performance depends more on the platform.
Particularly relevant:
- CPU performance and CPU reservation,
- RAM,
- storage latency,
- virtual NICs,
- hypervisor or cloud network path,
- number of sessions,
- TLS Inspection,
- IPS,
- VPN throughput,
- logging and reporting.
Data sheet values should therefore always be read in context. Firewall throughput without security inspection is not the same as threat protection, TLS inspection, or IPsec VPN under real load. The differences are explained in Interpreting Sophos Firewall Performance Metrics.
HA and Recovery
High Availability differs significantly depending on the platform.
With hardware, HA is usually easier to understand: two appliances, HA link, defined interfaces, clear replacement device. With virtual and cloud deployments, additional questions arise:
- Do HA nodes run on different hosts?
- Are storage, network, and hypervisor truly redundant?
- Are virtual MAC addresses and vSwitch rules compatible?
- Are there dependencies on cloud routing or load balancing?
- Do backups and restore work on a new instance?
- Has the failure of a host or an availability zone been tested?
The basics of HA variants are covered in Setting Up Sophos Firewall High Availability (HA). For recovery, Creating or Restoring a Sophos Firewall Backup is essential reading.
Licensing and Support
Licensing should be checked early because hardware, virtual, and software-based firewalls can be treated differently. For virtual and software-based Sophos Firewall instances, it is particularly relevant how CPU cores, serial number, support, and subscription are planned.
For base license basics, see Sophos Firewall - Base License. The change in virtual and software licenses, where RAM is no longer the primary licensing limit, is explained in the blog post Sophos Firewall VM & SW - Only CPU Counts - No More RAM Limit.
Important in operation:
- Document license and support status.
- Accurately record serial number and registration status.
- Check HA licensing before setup.
- Verify firmware and support eligibility before upgrades.
- Know the RMA or recovery process for the chosen platform.
Before major upgrades, also refer to Checking Sophos Firewall Before SFOS 22 Upgrade because platform support, storage space, backup, HA, and old VPN configurations can be relevant for upgrades.
Decision Matrix
| Question | More Likely Hardware | More Likely Virtual or Cloud |
|---|---|---|
| Classic location with WAN, LAN, DMZ | yes | only with a good virtualization strategy |
| Data centre with existing hypervisor team | possible | often sensible |
| Cloud workloads in AWS or Azure | no | yes |
| Simple support and RMA important | yes | depends on the platform team |
| Many physical ports needed | yes | only with clean NIC/vSwitch design |
| Dynamic scaling and infrastructure-as-code | rather no | rather yes |
| Small IT team without hypervisor expertise | mostly yes | rather cautious |
| Multi-tenant or segmentation design in the data centre | possible | often sensible |
Common Mistakes
- Operating a virtual firewall on an overbooked host.
- Not cleanly separating WAN, LAN, and management on the hypervisor.
- Selecting hardware based only on price instead of sizing.
- Deploying a cloud firewall but not fully considering routing tables.
- Planning HA but not testing host, storage, or cloud failures.
- Creating a backup but never practicing restore.
- Checking license and support status only during firmware upgrade.
- Activating security features like TLS Inspection or IPS later without performance reserve.
- Bringing platform team, network team, and firewall responsible together only in case of disruption.
Checklist
- Deployment location clearly defined: site, data centre, or cloud.
- Traffic, bandwidth, and security features captured for sizing.
- Hardware, virtual, software, or cloud variant deliberately chosen.
- Responsibility for firewall, hypervisor, cloud, and network documented.
- HA and recovery design checked.
- Backup and restore process tested or planned.
- License, support, and registration clarified.
- Monitoring for firewall and underlying platform available.
- Upgrade capability and platform support checked.
- Responsible parties for platform, network, firewall, backup, and restore named.