Cloud firewall protection
across your Virtual Machines

The cloud firewall runs at the hypervisor level, outside your VM, so traffic is filtered before it reaches the instance. There is nothing to install inside the machine, and because enforcement sits outside it, the rules continue to apply even if the VM is misconfigured or compromised. It is protection that software running on the VM cannot accidentally disable.

The rules are central rather than per-machine. You manage one rule set and apply it to a group, so configurations don’t drift apart over time. Every VM in the group stays consistent, and a rebuilt machine comes back with the same protection rather than an empty firewall.

Yes. You can write outbound rules as well as inbound ones, so you control not just what reaches a VM but what it’s allowed to reach. Restricting outbound traffic is a good way to contain a breach, since a compromised host can’t freely call out to wherever it likes.

Work default-deny. Open only the ports the service needs, 80 and 443 for a web server, for example, lock administrative ports like SSH to your own addresses, and leave everything else closed. New exposure then only ever happens when you deliberately add a rule.

Alongside. A private network decides what’s reachable, while the network firewall controls what is allowed over the connections that exist. Together they give you defence in depth. You get to isolate sensitive VMs on a private network and then filter the traffic that’s still permitted with firewall rules.

Yes. Rules are managed through the console or the API, so you can keep them in your infrastructure-as-code alongside everything else and apply changes through the same pipeline. That keeps your cloud firewall configuration reviewed, versioned and consistent with the infrastructure it protects.