الـ FortiGate-VM هو النسخة الافتراضية من الـ FortiGate التي تعمل فوق منصّات السحابة العامة مثل AWS و Azure و GCP و OCI، وكذلك السحابة الخاصة مثل VMware و KVM و Hyper-V. نفس الـ FortiOS الذي تعرفه على الجهاز الفعلي، لكن بلا hardware مخصّص، فتحصل على نفس الـ firewall و IPS و VPN داخل بيئة الـ cloud. في هذه الوحدة نفهم كيف نرخّص الـ VM، أين نضعه داخل الـ VPC أو الـ VNet، وكيف نؤمّن المرور الداخل والخارج وبين الـ subnets.

• 1الـ FortiGate-VM يشغّل نفس الـ FortiOS فوق الـ hypervisor أو الـ cloud platform، فكل سياسات الـ firewall و الـ security profiles تعمل بلا تغيير، والفرق الأساسي هو غياب الـ ASIC المخصّص فالأداء يعتمد على عدد الـ vCPU المرخّص.
• 2نموذجا الترخيص هما BYOL حيث تشتري الـ license مسبقاً وتنقلها بين البيئات بتكلفة ثابتة، و PAYG (On-Demand) حيث تدفع بالساعة عبر الـ Marketplace دون تكلفة أوّلية، وهو الأنسب للتوسّع السريع والـ auto-scaling.
• 3يُنشر الـ FortiGate-VM داخل الـ VPC في AWS أو الـ VNet في Azure ليؤمّن ثلاثة مسارات: الـ north-south عند حافة الإنترنت، والـ east-west بين الـ subnets والـ VPCs، والـ hybrid عبر IPsec VPN يربط السحابة بالـ on-prem.
• 4الـ HA والـ auto-scaling في السحابة لا يعتمدان على الـ heartbeat التقليدي بل على الـ cloud load balancer مع API calls تعيد توجيه الـ Elastic IP أو الـ route table عند الفشل، فتتوسّع المجموعة أفقياً حسب الحِمل.
• 5الـ SDN و Fabric Connectors يسحبون dynamic address objects مباشرة من السحابة بناءً على الـ tags أو الـ instances، فتتحدّث سياسات الـ firewall تلقائياً عند تغيّر الـ IP بدل التعديل اليدوي، مع بقاء الـ shared responsibility model سارياً.

• في AWS يُنشر الـ FortiGate-VM عادة بعدة ENIs: واحد للـ public subnet (الـ untrust) وواحد للـ private subnet (الـ trust) وثالث اختياري للـ HA management، ثم تُوجَّه الـ route tables بحيث يكون الـ FortiGate هو الـ next-hop لمرور الـ workloads الخارج، وهذا ما يحوّله إلى inspection point فعلي بدل أن يكون مجرّد جهاز جانبي.
• للـ east-west بين عدة VPCs أو VNets، النمط الحديث هو الـ hub-and-spoke حيث يجلس الـ FortiGate في hub VPC متّصل عبر Transit Gateway في AWS أو vWAN hub في Azure، فيمرّ كل المرور بين الـ spokes عبره ليُفحص مركزياً بدل بناء VPN mesh معقّد بين كل زوج.
• الـ auto-scaling group يحتاج تكويناً متّسقاً عبر الـ instances، لذا يُستخدم FortiManager أو bootstrap configuration عبر user-data وقت الإقلاع لحقن الـ config، ويُفضَّل PAYG هنا لأن كل instance جديد يبدأ فوترته تلقائياً دون إدارة license يدوية، مع FortiFlex كخيار مرن يوزّع points على الـ VMs حسب الحاجة.