Deploy and operate Sophos Firewall on AWS

Sophos Firewall 22 runs in AWS as a virtual EC2 appliance inline in a VPC. Start by defining which traffic the firewall must inspect. A standalone firewall can inspect inbound and outbound traffic. The Sophos Auto Scaling template is a specialized PAYG design for inbound DNAT or WAF traffic.

The safe short path is to select the architecture and license, record the IP and routing plan, launch the matching Marketplace template, restrict management to a fixed source IP, validate one flow end to end, and only then expose additional services.

⚠️ AWS security groups remain a second firewall layer. An allowing SFOS rule doesn’t help when a security group, NACL, or route table blocks the path. Conversely, don’t combine an open AWS port with a broad Sophos rule. Security groups are stateful and network ACLs are stateless, so a custom NACL must allow both request and return traffic.

Choose standalone or Auto Scaling

AWS doesn’t support native Sophos Firewall appliance HA. Auto Scaling and Network Load Balancing are a separate cloud design, not SFOS HA synchronization. A standalone design therefore also needs a rebuild procedure and an accepted outage window for maintenance or failure.

Apply three checks when selecting an instance: the EC2 type must be offered in the open Marketplace CloudFormation template for the chosen region and AMI; CPU, RAM and network performance must suit the throughput and connection profile; and, for BYOL, CPU entitlement and the terms applicable to that specific licence must be confirmed.

The SFOS 22/23 mapping lists, for example, m5.large with 2 vCPU and 8 GB RAM for SFv2C4, and m5.xlarge with 4 vCPU and 16 GB RAM for SFv4C6. These are version- and offer-specific mapping examples, not a guarantee for every current template. The historical RAM suffix in the licence is therefore not a reliable upper limit for physical EC2 RAM; however, this does not imply a blanket promise of unlimited RAM entitlement either. Before purchasing, clarify and document the specific licence/offer entitlement with Sophos or the licensing partner; do not deploy to production if anything remains unclear.

Choose an offered size with headroom and record the EC2 type, AMI/SFOS version and confirmed licence terms in the build plan.

With PAYG, software billing stops only when all applicable firewall instances have been removed; separate AWS resources that remain may continue to incur costs.

If the planned type is absent from the template or CloudFormation rejects the region, AMI, and size combination, don’t force it with a manual template override. Select an offered type that meets the workload and license requirements, or stop the deployment until the region, offer, or license is resolved.

Clarify licensing and pilot terms before purchasing

If PAYG is unavailable in your country or offer, Standalone BYOL with a confirmed licence is an option; this does not make the PAYG-only Auto Scaling template usable with BYOL. You can also explore a Private Offer with individually agreed prices and terms through Sophos or a partner. BYOL avoids the Marketplace software fee, not EC2 and infrastructure costs.

For a pilot, check the actual trial entitlement, duration and terms of the selected offer. The historical AWS FAQ describes a 30-day PAYG software trial; this is not a guarantee for the offer selected today. Once that offer’s trial ends, continued PAYG software use automatically becomes chargeable. EC2, storage, networking and other infrastructure may already incur charges during the trial. Record the end date, cost owner, budget alarm and a decision on continued operation or timely decommissioning. For BYOL, use a trial activation offered during initial setup or a trial licence approved in advance; registration alone does not guarantee a licence.

A production UTM licence can be converted to Sophos Firewall only through the designated, entitlement-dependent conversion process. Transferring an existing firewall licence is likewise possible only in permitted scenarios, not by arbitrarily reusing the same key. Confirm both with the licensing partner before starting BYOL. Activate a licence key then describes activation.

Under the shared responsibility model, applications, data, configuration and maintenance remain your responsibility. IPS, web filtering and WAF supplement SG/NACL controls only on the traffic path they actually inspect. Synchronized Security requires suitable endpoint licences, registration and a Heartbeat/firewall policy; it does not automatically isolate every lateral EC2 path that bypasses those controls. Central integration explains the connection to central management.

Prepare the standalone deployment

Record these values before launching the stack:

• AWS account, region, availability zone, and BYOL or PAYG offer;
• new or existing VPC and non-overlapping public and private subnet CIDRs;
• fixed management source, such as 198.51.100.27/32, instead of global management access;
• Elastic IP, DNS names, and required inbound services;
• private target networks, default route, and expected return path for each test flow;
• supported EC2 type, license limit, cost owner, and tags;
• backup, firmware, and rebuild procedures.

198.51.100.27/32 is a documentation address; replace it with the actual public address of the admin connection. If that address changes frequently, management through a VPN or controlled jump host is safer than broadly exposing TCP 4444.

For an existing VPC, don’t choose public and private subnets by name alone. Their route tables must match the intended direction. AWS explains network-appliance insertion in its middlebox routing examples. Source/destination checks must also be disabled on the firewall ENIs because the appliance forwards third-party traffic. Let CloudFormation set these platform details, then verify rather than changing them blindly.

Deploy standalone with CloudFormation

1. Open the Sophos Firewall BYOL or PAYG offer in AWS Marketplace, select View purchase options, and accept the terms.
2. Under Continue to Configuration, select the fulfillment option, current SFOS software version, and region.
3. Under Continue to Launch, select Launch CloudFormation and open the template in the AWS CloudFormation console.
4. Enter a unique Stack name. For a new VPC, check the proposed ranges for overlap with existing VPCs, VPNs, and on-premises networks.
5. For an existing VPC, map the VPC ID, one existing public subnet, one existing private subnet, and a new or unused existing Elastic IP. Leave Network Address Prefix for new VPC unchanged.
6. Use only an EC2 size offered by the open template for the region and AMI, and, for BYOL, check it again against the recorded license limit. Don’t store passwords or other secrets in tickets, screenshots, or publicly readable parameter files.
7. Review the IAM resources requested by the template. Only then acknowledge I acknowledge that AWS CloudFormation might create IAM resources and select Submit.
8. Wait for CREATE_COMPLETE. Read the Elastic IP under Outputs, then verify both instance status checks and the expected ENIs in the EC2 console.
9. Open WebAdmin from the approved source at https://<EIP>:4444. Bypass the initially locally signed certificate warning only after checking the destination IP, accept the terms, and complete registration and basic setup. Then open Administration > Licensing and confirm that the expected license is active; if it differs, correct the instance size or license assignment before allowing production traffic.

Marketplace parameters can change, so compare the visible field names with the template you actually opened before every production rollout.

Open AWS and SFOS rules together

The standalone Sophos template enables only management access for WebAdmin and SSH by default. This statement does not apply universally to Auto Scaling: there, Public Network CIDR controls non-management traffic. IPsec, SSL VPN, RED, WAF, User Portal and published applications also require appropriate AWS security group rules. For SD-RED 20/60, account for TCP 3400 to the firewall for the control channel and UDP 3410 for the data tunnel; check the additional provisioning, DNS and NTP requirements and other RED variants separately.

For every exposure, document protocol, destination port, and source once, but implement them separately at each layer:

1. The security group allows only the required source to the required port on the correct ENI.
2. A custom NACL allows the request and its return traffic. AWS documents the distinction under security groups and network ACLs.
3. The route table sends the data path through the firewall and provides a valid return path.
4. The SFOS firewall rule and, if needed, NAT rule use specific zones, hosts, and services, log traffic, and apply the appropriate security profiles.

Never preemptively expose SSH or WebAdmin to 0.0.0.0/0. Narrow AWS access doesn’t replace a precise SFOS rule; keeping both layers explicit also preserves the intended policy if routes or security groups change later.

Build Auto Scaling for inbound traffic

Auto Scaling requires an AWS account, the Sophos Cloud Firewall (PAYG) Marketplace offer and a Sophos Fusion account with the required firewall management permissions. In Sophos Fusion (formerly Sophos Central), under My products > General settings > API credentials management, review the terms and create a credential with a name, description and the Service principal firewall role. Store Client ID and Client secret in an access-restricted secret store, not an unprotected text file. The Sophos ID account password is a different secret from the API client secret.

1. In the required AWS region, under EC2 > Network & security > Key pairs, create a suitable key pair or reuse an existing one. Store the private key securely and note the name for SSH KeyPair Name.
2. In Marketplace, open View purchase options and Continue to configuration. Select Sophos Auto Scaling Firewall for AWS as the Fulfillment option, the approved Software version and Region. Under Continue to launch, select the Launch CloudFormation action, click Launch, then Next in CloudFormation.
3. Enter a unique Stack name. Check AMI ID against the selected offer and version, and choose an offered size with sufficient performance under Instance size. Select two different AZs under AvailabilityZone 1 for deployment and AvailabilityZone 2 for deployment.
4. New VPC: under Network Address Prefix for new VPC, enter the first two octets of a planned, non-overlapping range; leave the existing VPC fields blank. Existing VPC: leave the prefix parameter unchanged and enter Deploy to an existing VPC, Existing public subnet ID 1, Existing public subnet ID 2 and Existing private subnet ID from the build plan. The public subnets must belong to the selected AZs and have Auto-assign public IPv4 address enabled. Also check routes and NACLs.
5. Set the firewall name, Admin Password for WebAdmin/CLI, Secure Storage Master Key Password and SSH KeyPair Name. Protect the two firewall passwords separately from the API secret.
6. Enter the intended account’s Sophos ID email address and Sophos ID password, Sophos Central client ID, Sophos Central client secret and Sophos Central AS Group name. The Central field names may remain in the template despite the Fusion branding; the group is created automatically in the associated account. Do not include secrets in tickets, screenshots or public parameter files.
7. Set the following network, capacity and logging parameters. After reviewing I accept the Sophos End User License Agreement and acknowledge the Sophos Privacy Policy, enter exactly yes; this is case-sensitive. Make a deliberate choice for Opt in to the customer experience improvement program.
8. Select Next to open the stack options, set owner/cost tags and review the requested IAM permissions. Only then confirm I acknowledge that AWS CloudFormation might create IAM resources, review the full summary and start with Submit.

After CREATE_COMPLETE, check the EC2 instances and, under My products > Firewall management > Firewalls, the automatically created group with all expected approved PAYG workers. Confirm policy synchronisation before exposing a service. If a worker is missing or registration fails, do not open any further ports; check Stack Events, network access and the account/API mapping without logging secrets. Change capacity later under EC2 > Auto scaling > Auto scaling groups > Capacity overview > Edit and confirm with Update. Document each instance ID, AZ and firewall name unambiguously; check every capacity change again against group membership and Target Health.

DNAT behind the Network Load Balancer

A working, verified Auto Scaling deployment is a prerequisite. For an approved TCP service, the NLB listener forwards to a target group of firewall workers, not directly to the backend. The following original diagram shows an example HTTPS path, not a measured connection:

Permitted client : ephemeral source port
                 | TCP destination port 443
          NLB TCP listener :443
                 |
       Firewall worker target group
         /                       \
 AZ 1: Worker PortB       AZ 2: Worker PortB
         \                       /
          DNAT to backend :443
          SNAT = worker MASQ
                 |
          Internal app server :443
                 | Response
          Same worker -> NLB -> Client

Diagram: two AZs, one active PortB per worker and a MASQ return path. The arrows describe the logical data path; load balancing does not guarantee even utilisation. Adapt all example values to the approved service.

1. In Fusion, under My products > Firewall management > Firewalls, open Manage policy for the correct Auto Scaling firewall group. Under Hosts and services > IP host, create two IPv4 IP ranges for the actual WAN subnets in both AZs and an IPv4 host for the internal server. Do not include the first address of either subnet; include only actually usable worker addresses, not AWS-reserved addresses.
2. Under Hosts and services > Services, create a TCP/UDP service with Protocol TCP. For this inbound connection establishment, the ephemeral client port is the source and the published service port is the destination. The following direction applies to the request, not the response; 3389 or 8080 are not opened in addition.

3. Save the firewall rule under Rules and policies > Firewall rules and the NAT rule under Rules and policies > NAT rules in the group policy. Check synchronisation on every running worker.
4. Under EC2 > Load balancing > Target groups > Create target group, select Instances, a unique name, Protocol TCP, Port 443 and the deployment VPC. Deliberately adapt the health check protocol, port and, if applicable, path to the verified service. During creation, do not manually select any instance under Available instances, particularly not the backend server.
5. Under EC2 > Auto scaling > Auto scaling groups, select the firewall ASG and attach the target group under Integrations > Load balancing > Edit; confirm with Update. The ASG then registers its workers automatically, including workers started later.
6. Before starting the listener, check the security group association of the actual template NLB under Load balancers. If the NLB was created without a security group, one cannot be added later. In that case, do not expose a public listener until a supported, source-restricted path has been approved; alternatively, use VPN/ZTNA. Do not blindly modify the managed template or promise that a security group can be attached later.
7. If the restricted path is in place, configure TCP and port 443 in the NLB under Listeners > Add listener, with the worker target group as the Default action. Restrict the NLB SG to permitted client CIDRs and the listener port; at the worker, separately allow the destination and health check ports required by the NLB. NLB egress must be able to reach the health checks. Health check access is not public application access. Also restrict direct access to workers and the backend.
8. Before production use, verify that the expected workers in both AZs and a worker newly started during the approved change window appear automatically in the target group and pass the intended health checks. Using the NLB DNS name, test the positive application flow and a negative attempt from an unauthorised source; Log Viewer must show the expected rule and DNAT/MASQ. Do not rely solely on healthy.

Direct public RDP is still not recommended; prefer VPN or ZTNA. If a target remains unhealthy, first check ASG association, synchronised policy, health check port/path, NLB egress, worker SG and NACL. If the backend or return path is wrong, keep the listener closed and correct NAT/service/route settings. Interpret the ports in the direction of the client–listener–backend request path.

Accept one flow layer by layer

Write down one initial flow, for example 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. The source port is only an example ephemeral client port. Check in this order:

1. DNS and the NLB listener point to the expected target, and the target group reports the expected workers as healthy.
2. Security groups and NACLs allow exactly this request and return path.
3. Subnet route tables and ENIs send traffic through the appliance, with source/destination checks disabled on forwarding firewall interfaces.
4. SFOS Log Viewer shows the expected firewall Rule ID. For DNAT, the original and translated destinations and the return path are correct.
5. The allowed test reaches the intended application, while a test from an unauthorized source remains blocked.

If SFOS has no log entry, investigate the layers before the firewall: DNS, listener, target health, security group, NACL, and route. If a drop shows an unexpected Rule ID, correct zones, network objects, service, and rule order first. If the request arrives but the reply doesn’t, inspect the route table, NACL, server default gateway, and, for Auto Scaling, the MASQ setting.

Operate and recover

Standalone and Auto Scaling require different runbooks. For standalone, document an SFOS backup and tested restore, the firmware process, CloudFormation parameters, and a rebuild exercise. An EC2 snapshot isn’t a replacement for an exported SFOS backup.

Auto Scaling workers are ephemeral. With CloudWatch enabled, their logs appear in log groups under /sophos/xg/; explicitly configure retention, encryption, access, and cost controls. Terminated EC2 instances remain in the Fusion firewall group and must be deleted there manually. Warm-pool synchronization doesn’t replace confirmation that every running worker received the latest group policy.

The operations record should cover ownership and cost tags, budget alarms, license state, secret rotation, CloudWatch retention, Fusion cleanup, firmware approval, change tests, and recovery. Repeat the defined positive and negative flow after every template, routing, or policy change. Acceptance then proves not only that the instance is running, but that AWS and SFOS together allow exactly the intended traffic.

Stop the change and roll back selectively

Before the change, save stack parameters and resource IDs, listener/target group associations, SG/NACL/route tables, and the SFOS group policy and backup. If the destination is wrong, the source is unexpected, policy synchronisation is missing or an existing connection is disrupted, first close the newly added listener or remove the new exposure; then revert only the newly introduced rules and routes to the documented safe state. Recheck existing traffic and blocked unauthorised sources. Do not delete a shared VPC, subnets, gateway or existing listeners to troubleshoot a problem.

For planned PAYG decommissioning, terminating individual workers is not enough: the ASG can recreate them. First remove the new exposure, carry out the approved decommissioning through the stack/ASG lifecycle, and verify that neither scaling actions nor Warm Pool instances restart workers. Remove all associated PAYG firewall instances and check the actual resource inventory. Assess retained volumes, EIPs, NLB, Log Groups and other chargeable resources individually against the resource list rather than deleting them indiscriminately; remove terminated workers from the Fusion group. Then review billing and cost controls.