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 gates when selecting an instance: the EC2 type must be selectable in the Marketplace CloudFormation template currently open for the chosen region and AMI, its performance must suit the expected throughput and connection profile, and, for BYOL, its vCPU and RAM must not exceed the purchased virtual firewall license. Choose the smallest offered size that meets these requirements with headroom, then record the EC2 type, AMI or SFOS version, and license limit in the build plan. With PAYG, software charges stop only after all applicable firewall instances are removed from the AWS account.

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.

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 Sophos template initially enables management access only for WebAdmin and SSH. IPsec, SSL VPN, RED, WAF, User Portal, and published applications need corresponding AWS security-group rules. RED uses TCP 3410, for example.

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 Sophos Fusion (formerly Sophos Central) API credentials. In Fusion, go to My products > General settings > API credentials management and create a credential with the Service principal firewall role. Treat its Client ID and Client secret like a password and use them only in the intended deployment step.

Select Sophos Auto Scaling Firewall for AWS as the Marketplace fulfillment option. The template requires two different availability zones. For an existing VPC, provide two public subnets and one private subnet; enable Auto-assign public IPv4 address on both public subnets.

Review these parameters carefully:

• Trusted Network CIDR: the public admin address as /32, never 0.0.0.0/0;
• Public Network CIDR: 0.0.0.0/0 allows the entire internet to reach non-management ports. Avanet recommends entering known source networks now or narrowing this value immediately after deployment;
• Minimum capacity: the lowest number of workers that must remain available;
• Starting capacity: workers launched initially. Set this to Maximum capacity for the initial deployment so all workers register and join the Fusion group together;
• Maximum capacity: the hard worker and cost ceiling;
• Warm Pool Refresh Period: interval after which stopped warm-pool instances start and synchronize the Fusion group policy; the default is five days;
• Use CloudWatch: sends firewall logs to CloudWatch Logs.

After CREATE_COMPLETE, go to My products > Firewall management > Firewalls and confirm that the automatically created group exists and contains every expected approved PAYG worker. Only then change capacity or scaling policy.

DNAT behind the Network Load Balancer

For a published service, an AWS Network Load Balancer TCP listener forwards to a target group of firewall workers. In the Sophos Fusion group policy, create IP ranges for the WAN subnets in both availability zones, the internal target host, and a service for the actual published port. Don’t include the first IP address of either AWS subnet in its range.

In this single-arm design, the firewall rule matches WAN to WAN for the WAN ranges and exact service. DNAT translates to the internal server and uses MASQ as translated source so the return path traverses the same firewall worker. Then associate the target group, Auto Scaling group, and NLB listener.

Direct RDP publishing isn’t recommended. Prefer VPN or ZTNA. If DNAT is unavoidable, restrict sources at the NLB, AWS, and SFOS layers, enable IPS and logging, and perform a negative test from an unauthorized source.

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.