Skip to content
Avanet
Sign in

Deploy Sophos XDR Data Collectors in AWS, Azure and GCP

Sophos Fusion Admin

A Sophos XDR Data Collector receives syslog events and forwards them to XDR over an encrypted connection. Cloud deployment starts under Security Operations > Integrations > Data Collectors > Actions > Add Collector > Cloud-Hosted. A template for AWS, Azure or GCP, associated with the specific collector configuration, is then generated and deployed in your cloud account.

These three paths do not use interchangeable VM images. AWS uses an AMI with CloudFormation and EC2 User Data, Azure a VHD with an ARM template and Custom Data, and GCP a Terraform configuration for Infrastructure Manager. This runbook covers those cloud paths; SVA migration and on-premises deployment remain separate.

Establish networking, ownership and costs before deployment

You need the correct Sophos tenant, an authorized cloud account or project, and cloud permissions for the chosen template. Instances, disks, load balancers and other resources can incur cloud charges. Review the template, target network, security rules, owners and removal scope before deployment. Restrict access to generated configurations and any credentials they contain.

For each source, record which events it sends, in what expected format, and to which destination address. Standard syslog inputs are UDP/514 and TCP/601. Restrict rules to required source networks rather than exposing them to the entire internet. The collector requires outbound TCP/443 to its assigned regional XDR uplink, DNS over UDP/TCP 53, and bootstrap time synchronization over UDP 123. The collector migration runbook explains regional destinations; check them against the current safelist before the change.

Without custom NTP settings, non-AWS collectors use the documented pool servers, while AWS uses 169.254.169.123. Once connected, time synchronization takes place through the backend connection; Admiral may then show ntp.collector. Host Proxy is optional. General collector help excludes hard-coded authenticated proxies, although some setup pages show syntax containing a username/password. Therefore, clarify a production authenticated-proxy path with Sophos first; embedding credentials in the template does not resolve this documentation conflict.

Common setup in Sophos Fusion

  1. Open Security Operations > Integrations > Data Collectors > Actions > Add Collector.
  2. Select Cloud-Hosted and continue with Next.
  3. Enter a unique Name and Hostname, with description, Host Proxy and custom NTP servers if needed. Check tenant, network assignment and values before Create Collector.
  4. Select Create Collector, then the appropriate cloud service provider. Subsequent settings and files belong only to this collector and must not be reused for multiple independent instances.

AWS: CloudFormation, one collector and an NLB

You need the correct 12-digit AWS Account ID, a region supported in the Sophos dialog, and a suitable existing VPC with subnets. The sample template creates a launch template with AMI/User Data, an Auto Scaling Group statically sized to one instance, a Network Load Balancer, and syslog security rules.

The NLB operates at Layer 4 and supports TCP and UDP. Its stable DNS name remains usable as the source destination when an instance is replaced. An Application Load Balancer or classic ELB is not a replacement for this documented design. The AWS collector does not support HA in this setup; keep the Auto Scaling Group size at 1. Two simultaneous instances using identical User Data are unsupported.

Deploy the AWS configuration

  1. In the Sophos dialog, select Amazon Web Services (AWS), enter the account ID and choose a supported AWS region.
  2. If needed, save and inspect the YAML template using Download. Launch Console opens CloudFormation’s Create stack page with the generated template.
  3. Assign CollectorName, VpcId and Subnets to the intended environment. Check the template’s VpcCidr and additional SyslogIngress against the source networks actually permitted. 0.0.0.0/0 is an unrestricted IPv4 source range and must not be adopted as a default.
  4. Check InstanceType. The Sophos template uses c5.xlarge with 4 vCPUs and 8 GB RAM. In a custom template, the additional data disk must remain at least 200 GB and mapped to /dev/sdb.
  5. If using EBS encryption, have the AWS owner check KmsCmkArn and the required key policy. An unsuitable policy can cause repeated failed instance launches.
  6. Use Next to inspect stack options. Only select Create stack after the specific resources and security rules are approved.
  7. After successful deployment, record CTPxCollectorDnsName from the stack’s Outputs. This NLB DNS address is the destination for intended syslog sources, rather than a temporary EC2 IP.

Check collector status in Sophos Fusion. Because AWS assigns addresses dynamically, an empty Address column there is not automatically an error. Investigate Auto Scaling Group launch loops using AWS events; for Client.InternalError: Client error on launch with EBS encryption enabled, check the KMS key policy in particular. Do not start additional instances of the same configuration in parallel.

Azure: a fresh ARM template and scoped deployment permissions

You need an Azure subscription and a suitable virtual network with a subnet. The Sophos sample template requires Owner, or Contributor + User Access Administrator. Scope these permissions to the necessary resources and approved deployment procedure rather than granting them permanently to every collector operator.

The template copies the VHD into a storage account with a private container, creates a managed image, and deploys a single collector VM with a network security group. The storage account is dedicated to this purpose. The VHD SAS URL is valid for only three hours after the ARM template is generated. Do not simply retry an old template unchanged.

Templates downloaded on or after August 3, 2026 use a temporary Azure Deployment Script outside the virtual network to transfer the VHD. This requires no bootstrap VM, bootstrap NSG or additional bootstrap outbound exception in the VNet. Older templates used a different design involving a temporary VM and cleanup container; do not preemptively carry their exceptions into a new deployment. Use a fresh template for a new rollout.

Deploy the Azure configuration

  1. Select Microsoft Azure in the Sophos dialog. Use Download ARM Template if needed; Deploy in Azure opens the prepared Custom deployment page.
  2. Choose the Subscription and correct Resource group. A dedicated resource group simplifies identification and later removal, but is not a reason to move shared network resources into it.
  3. Select an Azure region matching the intended VNet. Set Vm Name and Vm Size; the current Sophos guide recommends Standard_D4s_v3.
  4. Correctly identify the VNet resource group, Azure Virtual Network and Azure Virtual Network Subnet. Enter a free, suitable Static Private IP, or leave it blank for automatic assignment.
  5. Leave Utc Now and Random Seed at their generated defaults. They provide unique deployment names and a temporary deployment password, respectively.
  6. Review the generated NSG rules: the documented setup permits inbound UDP/514 and TCP/601 from the VNet and the required outbound XDR, DNS and NTP traffic. Account for any additional organizational networking and security requirements in the template.
  7. Review Marketplace terms, then start deployment with Purchase only after resource approval. Compare the Azure deployment result with collector status in Sophos Fusion.

For a customized template, keep the additional data disk at least 200 GB and mapped to /dev/sdc. This documented Azure setup does not support HA either; any VM Scale Set used in a custom design may run only one instance with this Custom Data. A working collector VM alone does not activate a Microsoft 365 audit integration; configure and validate that data source separately.

GCP: Infrastructure Manager and a dedicated service account

GCP requires an authorized project, the Infrastructure Manager API enabled, Cloud Shell or an already available gcloud CLI, and a user-managed service account. According to Sophos, the Google-managed account <numeric ID>@cloudservices.gserviceaccount.com is unsuitable.

The deployment administrator creates the account, for example infra-manager-sa, with the documented roles/compute.instanceAdmin.v1, roles/compute.securityAdmin and roles/config.agent roles in the target project. These permit instance/disk creation, firewall rule management and Infrastructure Manager operations. Approving these write permissions is a separate preparation step; a read-only collector review does not require them.

Generate and apply the GCP configuration

  1. Select Google Cloud Platform (GCP) in the Sophos dialog and enter the GCP Project ID.
  2. Under Service Agent ID, assign the intended user-managed service account. Despite the field label, do not use the Google-managed service agent.
  3. Check GCP Region, GCP Zone, Network Name, Subnet Name and the intended Network CIDR. The CIDR must match the required firewall rules; do not enter a blanket internet allowance.
  4. Save the generated Terraform archive with Download. Open Cloud Shell in the correct GCP project console, upload the specific ZIP, and extract it into a dedicated directory. The selected filename must belong to the newly generated collector.
unzip collector-*.zip -d collector-infrastructure

The vendor example uses a filename wildcard. The working directory must therefore contain exactly the intended archive; if multiple files match, use its exact filename instead. Before applying, review Terraform files for resources, networks, firewall rules and identity. The configuration creates a compute instance with a network interface and a data disk of at least 200 GB at /dev/sdb.

Sophos documents the following deployment command:

gcloud infra-manager deployments apply \
  projects/PROJECT_ID/locations/LOCATION/deployments/taegis-collector \
  --service-account projects/PROJECT_ID/serviceAccounts/infra-manager-sa@PROJECT_ID.iam.gserviceaccount.com \
  --local-source="./collector-infrastructure" \
  --tf-version-constraint="1.5.7"

Replace PROJECT_ID throughout with the authorized target project and LOCATION with a supported Infrastructure Manager location. The service account name must match the account actually created. taegis-collector names the deployment resource and must not inadvertently overwrite an unrelated existing deployment. apply creates or changes real cloud resources; execute it only after inspection and approval.

Sophos identifies gcloud infra-manager previews create as a prior preview option. Run previews in the correct project using an authorized account too; they do not replace reviewing the proposed changes. After a successful apply, check collector status and sources. According to the guide, Provisioning should end within ten minutes; if it persists, investigate deployment and connectivity errors rather than repeatedly creating the same deployment without control.

Shared VPC: separate network and service projects

By default, the template expects network and instance in the same project. With Shared VPC, the host project owns the VPC, subnets and firewall rules; the service project contains the collector instance and disk. Both projects must already exist.

The organization administrator enables Shared VPC on the host project and associates the service project. This requires roles/compute.xpnAdmin at organization level, not an ordinary project role. Then grant the service project’s infra-manager-sa additional roles/compute.securityAdmin for firewall rules and roles/compute.networkUser for network use in the host project.

In the Sophos wizard, fill Network Project ID with the host project ID; keep other project settings pointed at the service project. PROJECT_ID in the apply target and service account address also remains the service project ID. Check these assignments separately before approval: changing every placeholder to the host project would break the intended resource separation.

Validate sources and retain persistent configuration

After successful cloud deployment, the collector must be reachable in Sophos Fusion. Then configure a limited pilot source to send the appropriate syslog format to the correct cloud destination. Compare source, time, event type and expected fields through the XDR search path. A healthy collector or successful cloud stack does not prove complete ingestion and normalization.

The operations runbook explains source views, backlog and Admiral. Move further sources only after pilot acceptance; preserve existing log paths until the agreed acceptance point. A collector replaces neither SIEM entitlement and the retention inventory nor a product-specific API integration.

If collector configuration is later changed in Sophos Fusion, save new deployment files and update the existing cloud deployment too: the AWS CloudFormation stack with the current template, the Azure deployment with the current ARM template, or the GCP deployment with the new Terraform configuration. Otherwise, a future instance replacement may reuse old bootstrap settings. A successful online change alone does not establish this persistence.

For removal, first restore sources to the preserved previous path and verify fresh events there. Then remove only clearly identified collector resources through the relevant cloud change procedure. Do not delete shared VPCs/VNets, subnets, keys or service accounts as a blanket “collector cleanup.” Infrastructure rollback does not automatically restore events already lost or misnormalized in the past.