FortiGate Cloud-Native Firewall (CNF) and FortiGate-VM both bring Fortinet security into public cloud, but they use different operating models. FortiGate-VM is a virtual appliance that customers deploy and operate inside their cloud architecture. FortiGate CNF is delivered as a cloud-native firewall service designed to reduce the amount of firewall infrastructure customers must provision and maintain. Choosing between them is therefore less about which one is “more secure” and more about who should own scaling, lifecycle, networking, and advanced FortiOS functions.

The current NSE 4 FortiOS 7.6 Administrator materials explicitly include FortiGate CNF plus FortiGate-VM deployment in AWS and Azure. The decision becomes much clearer when you separate required security functions from operational control.

FortiGate-VM gives customers appliance-level FortiOS control

FortiGate-VM runs FortiOS as a virtual firewall appliance in cloud infrastructure. The customer chooses supported instance types, deployment topology, interfaces, routes, availability design, licensing model, bootstrap configuration, and software lifecycle within the supported platform model. That familiarity is valuable for teams that already operate FortiGate appliances and want similar controls in cloud.

Fortinet’s current public-cloud documentation covers FortiGate-VM deployment across AWS, Azure, Google Cloud, OCI, and other environments. The platform-specific network design still matters: route tables, subnets, cloud load balancers, transit architecture, availability zones, and failover mechanisms determine how traffic reaches the firewall.

This model provides flexibility but transfers responsibility. Someone must size and patch the appliance, plan redundancy, monitor health, manage licenses, and understand the cloud networking required to steer traffic through it. Teams that want that control may consider the work a benefit; teams that want a managed security service may see it as operational overhead.

FortiGate CNF reduces infrastructure management

Fortinet describes FortiGate CNF as software as a service that simplifies cloud network security by removing the need to configure, provision, and maintain firewall software infrastructure. A CNF instance can aggregate security for multiple cloud networks in a region and apply shared policy, with the service providing a standardized availability and scalability model.

CNF currently supports AWS and Azure. Fortinet positions it for organizations that want FortiOS-derived security without needing the same degree of firewall-appliance and cloud-networking expertise required for a VM deployment. The console and service model abstract more of the infrastructure lifecycle so teams can focus on policy and protected workloads.

That abstraction is not simply convenience. It changes the division of responsibility. Customers still design policy, choose what workloads are protected, integrate cloud accounts and networks, and monitor security outcomes, but they do not operate the underlying firewall instances in the same way as FortiGate-VM.

Feature requirements can decide the choice immediately

Fortinet’s CNF FAQ draws an important distinction: FortiGate-VM is the Fortinet cloud network security option that also provides functions such as VPN, NAT, and SD-WAN, while FortiGate CNF focuses on managed cloud network security use cases. If a design requires FortiGate to terminate VPNs, perform specific NAT behavior, participate in SD-WAN, or expose a broad FortiOS feature set, FortiGate-VM is usually the more natural candidate.

If the requirement is primarily inspecting cloud workload traffic with a managed firewall service and shared policy across networks, CNF may reduce complexity. Do not select CNF simply because the word “cloud-native” sounds newer; verify the actual networking and security features the application needs.

Differences among AWS, Azure, and Google Cloud platforms matter because cloud-native integrations and network constructs vary by provider. FortiGate CNF supports AWS and Azure, while FortiGate-VM also extends to other supported cloud platforms.

Scaling and availability responsibilities are different

A FortiGate-VM architecture can be designed for high availability and horizontal scale, but the customer chooses and operates the topology. That may involve multiple firewall instances, load balancing, cloud route updates, availability-zone placement, health monitoring, and automation. This control can be essential when the firewall is part of a highly customized transit design.

CNF provides a service-level scaling and availability model instead. Fortinet hosts the service components and lets the customer attach protected networks and policy to the service. That can reduce the number of moving pieces the customer must maintain, especially across many accounts or virtual networks in the same region.

Neither model eliminates architecture. CNF still needs intentional placement and integration, and VM designs still benefit from automation. The question is whether the organization wants to engineer the firewall infrastructure itself or consume a managed cloud firewall capability.

Software lifecycle and change control differ

FortiGate-VM gives customers more direct control over FortiOS version selection and upgrade timing within supported cloud images and licensing. That can be important for compatibility-sensitive environments where security teams require a specific FortiOS release or need detailed regression testing before upgrades.

CNF uses a managed service lifecycle. Fortinet publishes upgrade behavior and advises customers to test new CNF versions in a separate instance before production where appropriate. The service reduces day-to-day software maintenance, but customers accept a more standardized lifecycle than they would with their own VM appliance.

Governance should reflect this distinction. A team choosing CNF should understand the provider’s maintenance and upgrade process. A team choosing VM should demonstrate that it can patch, back up, test, and recover the appliance reliably. Operational responsibility does not disappear; it moves.

Network design is usually more complex with FortiGate-VM

To inspect traffic with a VM firewall, cloud route tables and forwarding paths must steer the relevant traffic through FortiGate interfaces. In AWS this can involve VPC routing, transit connectivity, Gateway Load Balancer patterns, or other architectures. Azure has its own virtual-network, route-table, and load-balancer constructs. Every design needs to preserve symmetric stateful paths.

CNF is intended to abstract more of that integration. Fortinet documents regional aggregation patterns and cloud-native integrations such as AWS Firewall Manager. This can be attractive when the security team wants consistent policy across many cloud networks without building a bespoke virtual-appliance transit architecture.

However, abstraction can constrain unusual requirements. If an application needs custom packet handling, specialized routing, or services beyond the CNF feature set, a VM architecture may offer the necessary control. Architecture should follow requirements, not operational fashion.

Cost comparisons must include engineering and operations

Comparing only license or consumption price misses a large part of the decision. FortiGate-VM costs can include cloud compute, storage, load balancing, data processing, networking, licenses, redundancy, and engineering time. CNF pricing may be consumption- or contract-oriented, with more infrastructure management included in the service model.

Estimate the cost of routine operations: upgrades, HA testing, incident response, route management, capacity changes, monitoring, and support. A VM that appears less expensive on a per-hour basis can cost more if the organization must maintain a complex fleet. A managed CNF service can also cost more than necessary if the deployment is small and the team already has strong FortiOS automation.

Across Fortinet certification roles, both models use familiar Fortinet security concepts, but the operating skills differ: FortiGate-VM rewards deeper appliance and cloud-network expertise, while CNF emphasizes cloud-service integration and policy.

A practical selection framework

Choose FortiGate-VM when you require broad FortiOS functions, VPN/NAT/SD-WAN, customized network topology, fine control over software lifecycle, or support across cloud platforms beyond the CNF footprint. Choose FortiGate CNF when the priority is a managed cloud firewall service, standardized scaling/availability, policy aggregation across supported AWS or Azure networks, and reduced appliance operations.

Then test the design with a real traffic matrix. Include north-south Internet flows, east-west workload flows, cross-account or cross-network paths, DNS, identity dependencies, logging, failure scenarios, and application latency. The correct architecture is the one that enforces policy predictably without creating a routing or operations model the team cannot sustain.

Finally, document the responsibility boundary. State who owns cloud routing, policy, upgrades, service health, incident response, certificates, logging, and recovery. FortiGate CNF and FortiGate-VM can both protect public-cloud workloads, but they create fundamentally different operational obligations. Making those obligations explicit is the most reliable way to choose between them.

Migration between CNF and VM should be treated as an architecture change

Moving from FortiGate-VM to CNF, or the reverse, is not a simple license conversion. The traffic-steering model, operational responsibility, feature set, logging integrations, upgrade process, and failure behavior all change. A migration plan should therefore begin with application flows and required security functions rather than with firewall objects.

Inventory every function the existing design performs: Internet egress inspection, east-west segmentation, inbound publishing, VPN termination, NAT, SD-WAN, threat inspection, logging, identity integration, and automation. Mark which functions are supported directly by the target model and which need a separate cloud-native or Fortinet component. This prevents a migration from discovering late that the old VM was quietly providing a service the CNF design does not intend to replace.

Build parallel policy where possible and validate with representative traffic. Compare allowed and denied flows, threat logs, source/destination identity, application latency, and failure recovery. For CNF, validate network/account attachment and regional scope. For VM, validate route convergence, health checks, scaling, and instance replacement. Security equivalence requires more than copying rule names.

Operations teams also need new runbooks. The person who replaces an unhealthy VM instance may not be the person who investigates a managed CNF service event. Monitoring dashboards, support escalation, backup expectations, and maintenance ownership should be updated before cutover.

Finally, plan rollback. Cloud routing changes can affect many workloads at once, so keep the old path available until the target architecture has passed functional and security validation. A controlled migration is safer than an all-at-once switch simply because both products carry the FortiGate name.

For regulated workloads, include compliance evidence in the selection. Determine how each model exposes logs, configuration history, policy changes, software-version evidence, and service-health information to auditors. A managed service can simplify infrastructure operations, but the organization still needs proof that its own policy and monitoring responsibilities are being performed. A VM can expose more appliance-level detail, but that detail is valuable only if the team consistently collects and reviews it.