Deploy and operate Sophos Firewall on AWS
Sophos Firewall runs in AWS as an EC2 appliance inline in a VPC. Decide first whether the design needs one standalone firewall or a dynamic Auto Scaling group. The models don’t share the same licensing, interface, or traffic behavior.
⚠️ 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.
Standalone or Auto Scaling
| Model | Suitable for | Important boundary |
|---|---|---|
| Standalone BYOL | Long-term appliance with a Sophos license | EC2 charges remain separate and licensed cores must match the instance. |
| Standalone PAYG | Hourly operation and pilots | FullGuard is billed by AWS; verify regional availability. |
| Auto Scaling PAYG | Variable inbound DNAT or WAF traffic | PAYG only, single-arm through PortB, and inbound traffic only. No normal LAN-to-WAN egress path. |
AWS doesn’t support native Sophos Firewall appliance HA. Auto Scaling and load balancing are a separate cloud design, not SFOS HA synchronization.
Deploy standalone with CloudFormation
- Select the BYOL or PAYG Marketplace offer, accept the terms, and choose the region and current SFOS version.
- Use Launch CloudFormation and select a new or existing VPC.
- For an existing VPC, map its VPC ID, public subnet, private subnet, and new or existing Elastic IP explicitly.
- Size EC2 for traffic and licensing; a BYOL instance must not exceed licensed cores.
- Review IAM creation before acknowledging it and submit the stack.
- After
CREATE_COMPLETE, read the Elastic IP from Outputs and wait for the EC2 status checks. - Initially allow WebAdmin only from a fixed admin source at
https://<EIP>:4444, accept the terms, and complete registration. - Verify PortA, PortB, route tables, source/destination check, security groups, NACLs, and return path with a defined flow.
The template initially opens only management access. IPsec, SSL VPN, RED, WAF, and portals need matching AWS security-group rules; RED uses TCP 3410, for example. Keep sources narrow and never preemptively allow SSH or WebAdmin from 0.0.0.0/0.
Operate Auto Scaling safely
Auto Scaling registers workers through a Sophos Central service principal into a firewall group. Define two availability zones, minimum, starting, and maximum capacity, and the warm-pool refresh period. Set Trusted Network CIDR to the public admin address as /32, not 0.0.0.0/0, and reduce Public Network CIDR to real source networks after deployment.
Workers are ephemeral. When CloudWatch is enabled, logs are stored under /sophos/xg/. Terminated EC2 instances remain in the Central firewall group and must be deleted there manually. Warm-pool synchronization doesn’t replace confirmation that every running worker received the latest group policy.
DNAT behind the Network Load Balancer
The NLB listener sends an approved service to a target group of firewall workers. In the Central group policy, define the WAN subnet ranges from both availability zones, the target host, and the exact service. The firewall rule matches WAN to WAN for those ranges; DNAT translates to the internal server and uses MASQ in this design for a symmetric return path.
The official example uses RDP, but direct RDP publishing isn’t a recommendation. 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.
Acceptance and operation
Validate AWS routes, security groups, NACLs, NLB health, SFOS Rule ID, DNAT, return path, Central group status, and logs together. Document ownership, cost alerts, firmware, licensing, CloudWatch retention, Central cleanup, and CloudFormation rebuild. An EC2 snapshot isn’t a replacement for an exported SFOS backup.