Skip to content
Avanet

Deploy Sophos Server Protection on AWS EC2 and Azure VMs

Sophos Server Protection

An EC2 instance or Azure VM is protected inside the guest operating system with Sophos Server Protection. Use the Windows Server Installer for Windows Server and Sophos Protection for Linux (SPL) for supported Linux servers. Where the VM runs does not change the choice of server agent. Sophos Firewall as a virtual appliance in AWS or Azure protects and routes network traffic; it does not replace a guest agent. Sophos Cloud Optix is a separate cloud-posture and inventory product, not a prerequisite for installing Server Protection: according to the Sophos lifecycle announcement, support and access will end on September 30, 2026. It is therefore not a basis for a new or long-term cloud inventory and cleanup process. Check separately whether Server Protection and its features are available and covered by contract in your tenant.

Quick path: Choose a representative VM, approve its operating system and protection mode, test connectivity to Sophos Fusion from its actual cloud network, and install the tenant-specific server installer. Then check My Products > Server > Servers and the server details. Release the next wave only after registration, group assignment, policies, agent health, and application operation have been verified. For short-lived instances, also plan a separate reconciliation with the cloud inventory.

Before the pilot: establish protection and network access

  1. VM and contract: Record the AWS account or Azure subscription, region, VM role, operating system build or Linux distribution, architecture, and lifecycle. Check current support for that specific guest operating system and the required components. Confirm the tenant’s license, the purchased server SKU, and its contractual terms for these VMs; a visible download button is not proof of entitlement.
  2. Protection mode: Decide between full Sophos malware protection and XDR Sensor. XDR Sensor alone does not provide malware protection and requires active third-party protection. Before switching modes, resolve conflicts with existing security software and establish a rollback path for the affected VM.
  3. Outbound connectivity: From the intended subnet, check that DNS, HTTPS, the Sophos destinations required for the tenant, and any proxy or Message Relay are reachable during installation and operation. Security Groups, Network Security Groups, cloud routes, NAT, firewalls, and TLS inspection can affect the path. See network and proxy requirements for the current allowlist and proxy diagnostics. Do not assume a fixed list of cloud IP addresses can replace the Sophos destinations.
  4. Pilot and acceptance: Choose a small set of VMs representing the server role, OS version, network segment, and proxy path, if applicable. Record names, expected server group, target policies, reboot window, workload test, and stop criteria. If subnets or images differ, plan at least one suitable test for each distinct path.

For example, a Windows application VM and a Linux worker VM in separate private subnets are two pilot cases, not a single network test. A successful installation on the first VM does not prove that the second can reach its update destination through its own NAT or proxy path.

Run the installer in the guest and handle images correctly

Under My Environment > Installers > Server Protection, select the Windows Server Installer or Linux Server Installer for the approved protection mode from the correct Sophos Fusion tenant. For an individual Windows VM, transfer SophosSetup.exe securely, run it with local administrator rights, heed the displayed pre-installation checks, and complete installation and any requested reboot. For a Linux VM, transfer SophosSetup.sh securely, make it executable, run sudo ./SophosSetup.sh --test first, and then, if the test succeeds, run sudo ./SophosSetup.sh. Check tenant registration and local agent health afterward; an installer that has finished is not sufficient proof. Protection modes, advanced CLI options, logs, and troubleshooting are covered in Install and deploy Windows Server Protection and Install and deploy SPL. Keep the tenant-specific installer and its download URL in a protected package repository, not in a public VM image or repository.

Do not clone an already registered master VM without preparing it. For SPL in a Linux gold image, deregister the master VM after installation with registerCentral --deregister as described in the Linux gold-image procedure, shut it down immediately, and save the image while it is powered off. Starting the master VM again can cause it to re-register; if that happens, deregister it again before saving the image. Start two clones and verify that they have distinct identities.

Windows Server has a different image process: Before building the image, check that Tamper Protection is disabled for image configuration and whether Server Lockdown or Update Cache is active; do not create a gold image from servers using either of those features. BitLocker-encrypted masters and masters with Sophos Encryption components are also excluded. As an administrator, run SophosSetup.exe --goldimage with the tenant-specific Windows Server Installer following the Windows gold-image procedure (also for servers), check installation and health, re-enable Tamper Protection, and shut down the master before taking the image snapshot. On first boot, each clone must receive its final computer name, different from the master’s, in time for Sophos detection: Sophos identifies clones by the name change, not by the cloud instance ID. If name assignment is delayed, check the timeout mode described in the guide; its Notification Mode is documented for VMware Horizon Instant Clone and should not be applied indiscriminately to EC2 or Azure. Do not assume an ordinary Windows installation is ready to clone. Here too, validate two clones separately in Fusion.

Check each cloud rollout wave and stop on failures

After installing or starting a pilot clone, open each expected server under My Products > Server > Servers. Two concurrently running clones must appear as two distinguishable server objects. For acceptance, maintain an external mapping of AWS account/Azure subscription, region, EC2 instance ID/Azure VM resource ID, Fusion server ID, owner, and creation time; the server list does not automatically display cloud IDs. In the server details, check Summary, Status, and Policies, along with last activity, health, installed components, and effective server policies. The initial automatic Default Policy is not necessarily the planned production policy. Then compare services, application access, backups, and a representative workload test before and after any necessary reboot.

If a VM is missing from Fusion, first check the tenant and filters, then DNS, proxy, outbound network path, and installation logs according to the relevant Windows or Linux runbook. If clones cannot be distinguished, stop the image rollout and check the identity step in the gold-image procedure. If components are wrong, health is poor, or the workload is disrupted, do not release another wave; investigate the affected wave in isolation instead of repeatedly applying installers and policies blindly.

Handle terminated instances separately from inactive devices

Short-lived VMs may have been terminated while their entries remain visible in Sophos Fusion. An old Last Active timestamp proves neither that a cloud instance has been terminated nor that a universal automatic cleanup period has elapsed. Regularly reconcile the external mapping of account/subscription, region, cloud instance/resource ID, and Fusion server ID with the AWS/Azure inventory and Fusion device inventory. Record the owner, lifecycle timestamps, and evidence of the EC2 Terminate or Azure VM Delete event. A reused hostname or a stopped Azure VM is not evidence that the associated server object has been retired.

Manual reconciliation and targeted Delete remain the baseline: Only after positive evidence of cloud termination and an unambiguous ID match should you preserve required alerts and investigation data, check for possible duplicates, and document decommissioning or replacement protection. Delete in Fusion does not replace uninstalling the agent from a still-running VM or carrying out the cloud lifecycle process.

Separately, Sophos documents a configurable Server rule for inactive devices under Removal of inactive devices: it can target groups or apply globally with group exceptions (exceptions do not apply to targeted rules). It responds to inactivity, not to a confirmed EC2 Terminate or Azure Delete event, and does not uninstall an agent. Before enabling it in your tenant, test the groups, time period, exceptions, data retention, and consequences for stopped or temporarily unreachable production VMs against a test inventory; do not assume a universal period or licensing effect. The former Cloud Optix integration offered separate termination cleanup for existing AWS/Azure environments linked in the same tenant with server agents; it was disabled by default, could be enabled only by a Super Admin, and did not apply retroactively to previously terminated instances. Because support and access end on September 30, 2026, this is historical context only, not a recommendation for new setup or long-term automation. No unverified workflow is promised for autoscaling deletion hooks, API automation, or license counting.