Fortinet NSE4_FGT_AD-7.6: FortiGate-VM and CNF in Public Cloud
Deploying a firewall in the public cloud does not eliminate network trust boundaries; it moves the paths that carry traffic into virtual networks, routing tables, cloud interfaces, load balancers, and account-level controls. The critical first question is not which Fortinet product has the most features, but which traffic must be inspected and who controls the forwarding path that brings it to the inspection point. A deployed FortiGate instance that never sees the protected flow cannot enforce a useful policy.
The NSE 4 FortiOS 7.6 Administrator blueprint includes threats and challenges in public cloud, Fortinet cloud solutions, FortiGate virtual machines, FortiGate Cloud-Native Firewall (CNF), and relevant use cases. These subjects deserve one coherent comparison because the operational choice between a FortiGate-VM and FortiGate CNF influences deployment ownership, traffic steering, policy management, and the evidence an administrator can collect.
The examples below describe principles of the FortiOS 7.6.0 FortiGate-VM documentation and the separately versioned FortiGate CNF service. CNF platform releases and FortiOS software releases do not share a single version number. A current CNF administration screenshot or menu must not be presented as proof of what appears on a FortiOS 7.6.0 appliance. Verify cloud-provider limits, regions, available services, subscriptions, and the product-specific documentation before implementing a real design.
Cloud threats often begin with an unnoticed forwarding path
Public-cloud networks commonly involve virtual machines, application load balancers, managed databases, object storage, containers, and multiple accounts or subscriptions. Cloud-provider security groups and native access controls restrict parts of that environment, but they do not automatically provide a single point for cross-workload intrusion prevention or application-level inspection. An incorrectly scoped egress route, permissive peer relationship, exposed management endpoint, or unmonitored east-west connection can create a security blind spot even while perimeter dashboards report no fault.
Before choosing the firewall, build a flow inventory. Classify internet ingress, internet egress, application-tier east-west connections, shared-service access, VPN or on-premises links, and sensitive management paths. For each, identify the cloud route and next hop, the security control intended to inspect it, and whether the return path traverses the same stateful boundary. A central inspection architecture that only captures outbound internet traffic cannot be described as protecting every internal workload. The result of the inventory should be testable route and policy assertions, not an architectural drawing with arrows that have never been validated.
The shared-responsibility model does not mean the cloud provider operates an enterprise firewall policy on your behalf. Even when underlying infrastructure is managed, the customer still decides which workloads need segmentation, how private network traffic is steered, what logs are retained, and which administrators can modify security policy. Native provider controls and Fortinet inspection can complement one another; deploying both without an ownership map can instead create two overlapping but incomplete rule systems.
FortiGate-VM behaves like a customer-operated virtual firewall
A FortiGate-VM is a virtual FortiOS appliance running within a cloud infrastructure environment. The Fortinet FortiGate-VM on AWS architecture illustrates a virtual firewall with interfaces serving public-facing and protected networks. Equivalent principles apply on Azure with network interfaces, subnets and user-defined routes, although cloud constructs differ. The operator is responsible for selecting a supported instance type, arranging network interfaces, licensing, FortiOS administration, routing, access policies, logging and the recovery plan.
Operating it as a VM gives the team familiar FortiGate management concepts: firewall policies, security profiles, VPNs, diagnostics, and supported central-management integrations. That flexibility carries work. The design must account for capacity of the selected virtual appliance, CPU and network-interface limits, licensing model, upgrades, high availability, and cloud-specific failover mechanisms. A generic FortiOS guide alone cannot tell you whether a given VM instance can support a particular traffic load or whether its interface attachment is correct.
Management access deserves special treatment. The initial VM can need an address reachable for provisioning, but exposing administrative HTTPS or SSH to the open internet as an ongoing practice increases attack surface. Restrict administrative access, apply strong credentials and appropriate authentication, and keep a tested recovery route. Treat instance metadata, bootstrap data, cloud IAM permissions, and any configuration stored in templates or automation as sensitive deployment materials, not as harmless infrastructure code.
FortiGate CNF shifts infrastructure lifecycle toward a managed inspection service
FortiGate CNF is a cloud-native Fortinet firewall service with its own management model. Fortinet’s FortiGate CNF deployment documentation describes creating an instance, connecting cloud endpoints or load balancers, and assigning policy sets. In AWS it uses gateway load balancer endpoints; in Azure, load-balancer constructs carry traffic toward the inspection service. The administrator still owns the decision about which subnets and flows should be inspected, even if the service abstracts more of the underlying firewall infrastructure.
The CNF interface exposes instance status, cloud account or subscription relationships, endpoints, applicable policy sets, and operational evidence. A policy set is not merely a descriptive label: address objects, services and security profiles are combined with ordered rules and then associated with one or more instances. If different workloads need different inspection policy, the deployed architecture must express that isolation through the supported instance and policy arrangement. A single generic allow rule should not be presented as the default configuration for every attached workload.
Because CNF is managed separately, an operations team should not assume that FortiGate-VM CLI commands, firmware-upgrade steps or an HA runbook apply unchanged. The right division of labor needs to be written down: cloud platform team controls route tables and endpoints, security team controls allowed traffic and profile policy, and operations monitors instance health, logging and configuration revision. Misunderstanding that ownership can make a CNF deployment appear complete while traffic still bypasses its inspection path.
AWS inspection depends on VPC routes and GWLB endpoints
Consider two AWS workloads in different private subnets that need controlled communication. A FortiGate CNF design must connect the relevant VPC route to its gateway load balancer endpoint and maintain a valid return path. If a route sends the flow directly to a different target, the inspection policy will never see it; a ‘no matching logs’ symptom can therefore be a path issue rather than an absent security signature. Fortinet’s CNF guide explicitly notes that customers must make the appropriate routing changes in their own cloud accounts.
A FortiGate-VM topology solves the same visibility problem through different mechanisms. A VM can have cloud network interfaces in public and private subnets and operate as a routed inspection hop when the associated cloud routing, source/destination-check configuration where applicable, and return path have been designed correctly. It is not enough for the VM’s own network interface to be reachable. Test a packet generated by the protected application and confirm the intended FortiOS session and egress behavior.
Centralized inspection VPCs and distributed inspection per application VPC represent different operational choices. Centralized designs may simplify policy oversight and shared logging but introduce routing and failure-domain dependencies. Distributed designs can isolate teams or workloads but multiply policy and lifecycle management. Evaluate tenant boundaries, latency, data residency, blast radius and the need for east-west inspection before deciding which one is appropriate. FortiGate route selection offers useful packet-path concepts, but cloud gateway and route-table configuration still must be validated on the provider’s platform.
Azure uses different load-balancer and route constructs
On Azure, a FortiGate-VM design can use virtual networks, network interfaces, user-defined routes and the cloud provider’s supported load-balancing arrangements. Fortinet’s FortiGate Public Cloud 7.6.0 Azure guide documents a portal-based VM deployment, while other deployment workflows may use templates and automation. Do not transpose AWS gateway load balancer endpoint terms directly into Azure deployment steps. Compare the actual supported cloud product architecture and regional feature availability before choosing a design.
FortiGate CNF also supports Azure, but its service model uses Azure load balancers as the relevant inspection connection points. The policy set and target instance still need to agree with the route and service path. Verify the application subnet route, the cloud load-balancer attachment, the return path and the policy verdict as separate observable stages. A functioning portal dashboard without matching protected application logs says little about whether traffic is inspected.
Cloud native logging and Fortinet logging should be used together rather than substituted for one another. Provider network-flow information can help show which resource initiated traffic and which cloud route was selected; Fortinet inspection events help explain user or application policy, signature verdict and associated session handling. Timestamps, resource IDs, source/destination addresses and NAT transformations must be correlated carefully. Otherwise investigators can conclude that the firewall blocked an event when the packet was never routed to it.
Use policy sets and FortiOS policies according to the selected product
A common migration error is assuming that a FortiGate-VM’s existing policy and a CNF policy set are interchangeable without redesign. Both express an allow-or-deny security intention, but their object models, deployment scopes and lifecycle operations differ. Translate the original requirement first: which source workload or subnet can reach which destination application, over which service, and under which inspection controls? Then build the corresponding configuration in the selected product and validate the result against actual application traffic.
Policy ordering still matters. A broad allow preceding a specialized deny can undermine the intended segmentation; a narrowly scoped allow missing the actual source route can appear to work in configuration review but never be exercised. Define representative positive and negative tests for each new cloud firewall path and include the session identity, rule, inspection profile, and log destination. FortiGate policy evaluation describes the underlying enforcement reasoning even when the surrounding cloud routing or managed service interface differs.
Threat-prevention controls should be matched to observed traffic and deployment capabilities. Encrypted payloads can limit deep inspection unless certificates and trust are handled appropriately; application classification can depend on signatures and encrypted-session context; provider connectivity issues can resemble firewall denials. Separate cloud networking failures from policy and inspection failures before disabling a security control. The system should produce enough evidence to prove not only that a flow was permitted or blocked, but where that decision happened.
Capacity, licensing and recovery are different operating commitments
FortiGate-VM capacity planning combines the selected virtual hardware profile, expected concurrent sessions, encryption requirements, inspection workload and provider networking limits. The VM model’s licensing and FortiOS version can restrict what operators can configure and how long a deployment can be used. Do not assume a VM license or trial entitlement is equivalent to a fully deployed managed CNF service. Record each product’s contract, licensing scope and cloud-region support in the architecture decision.
For a VM deployment, document backups, supported software upgrade path, failover mechanism and cloud platform permissions required for recovery. HA behavior in public cloud may depend on cloud API calls or route and interface changes rather than only a traditional layer-2 appliance cluster. A test plan should observe the traffic path before and after a controlled member failure, not simply the status of an HA widget.
For CNF, document policy-set recovery, instance version management, cloud endpoint dependencies, logging destinations and service availability expectations. Even if Fortinet manages parts of the inspection infrastructure, customer-owned routes, cloud account permissions and workload failover remain operational dependencies. A safe rollout includes the procedure for detaching or rerouting a failed inspection path according to a previously approved failure policy. ‘Fail open’ versus ‘fail closed’ is a business and security decision, never an accidental side effect of a cloud route change.
Choose by the inspected workload and prove the actual packet path
A FortiGate-VM often fits an environment that needs familiar FortiOS appliance behavior, tailored networking, existing firewall operational tooling, and full customer-managed control over the virtual deployment. CNF can fit a cloud-native architecture that values an abstracted inspection-service lifecycle and policy sets associated with supported cloud endpoints. Neither choice provides universal security for every AWS or Azure traffic flow by mere presence in the account. The only meaningful selection test asks whether the chosen service can inspect the exact paths and enforce the required policy at an acceptable operational cost.
Build one repeatable test per important flow: a private workload making an approved outbound request, an unauthorized workload attempting lateral movement, a deliberately blocked threat-test pattern in an authorized lab, and a failed inspection path that should activate a documented recovery mode. For each, capture source and destination, cloud route, inspection attachment, policy verdict, return path, and log record. If a control unexpectedly fails, diagnose cloud routing before rewriting Fortinet policy. A supported deployment can still be operationally wrong when the next hop is missing.
This is the central NSE 4 lesson about cloud firewalls: deployment type, infrastructure responsibilities, firewall policy and traffic steering form one architecture. Public-cloud risks are not solved by naming a Fortinet product; they are reduced when the administrator can prove which workload reached which inspection control, why the policy was chosen, how the event was logged and how the system recovers without silently abandoning the protected boundary.
