Authored by Aidan Walden, Fortinet CSE & Global Dir. Engineering Cloud, Applications & Data Security
Cloud has evolved to become the corporate data center, the primary location for hosting business-critical applications. This includes SaaS and management constructs that need to be highly available to support the entire IT estate. For Fortinet customers, this includes choosing to host management, control, and analytics in public cloud environments. The high availability, support for log and signal aggregation at scale, and the cost-competitive nature of hosting management functions in the cloud have made AWS a popular destination for FortiManager and FortiAnalyzer deployments. Some of the largest deployments of Fortinet’s FortiGate NGFW and SD-WAN are managed out of public cloud environments.
As customers have grown their global footprint of Fortinet infrastructure, both in virtually and physically, they have asked for more efficiency in the way their FortiManager and FortiAnalyzer scale to support large deployments. We are happy to report to our customers that we have made available on AWS Marketplace a new one-and-done deployment of FortiManager and FortiAnalyzer. These Amazon Machine Images (AMIs) are cost optimized to support the tiered volume of FortiGates under management and the right-sized log rates, respectively. This means the cost of management and logging are scaled with the size of your FortiGate deployment.
The new tiered deployment and scaling model is available from FortiManager and FortiAnalyzer 7.6.0.
Focusing on FortiManager first, the scale of supported devices under management is tied to the instance size. The following chart gives the tiering:
The important consideration is “How are upgrades handled?” Its pretty simple and works well for deployments that are highly available. Let’s say you’re upgrading from your 10th deployed FortiGate and need to support an additional deployment that brings your FortiGate count to 15. In our example, we will upgrade from upgrade from 4vCPU to 8vCPU instance of FortiManager.
In an HA deployment, the FortiManager would be deployed in redundant pairs across availability zones, the details for which are described here: https://docs.fortinet.com/document/fortimanager-public-cloud/7.6.0/aws-administration-guide/140908/a.... In summary, the deployment is a VRRP pair that uses EIP migration between the active and the backup FortiManagers.
Starting with the backup, to change the instance size, and therefore supported scale, you will need to:
- Shutdown the backup FortiManager
- For the backup FortiManager instance, from the EC2 console (or CLI). Navigate to EC2 > Instances > Change Instance Type
- Select the new instance type of “m4.2xlarge” in our example, and then select “Change”.
- Restart the instance and confirm that the secondary instance is available to the management console.
- Now, repeat the upgrade process with the primary FortiManager. This should trigger a failover to the secondary FortiManager instance and move all of the FortiGate FGFM management tunnels.
This change should be transparent to the FortiGates as the elastic IP address to which their FGFM management tunnels are targeted has not changed.
With the FortiManagers upgraded to their new instance, they will automatically bill as prescribed by the instance size through your AWS marketplace billings. Keep in mind that these AMIs are available through AWS Private Offers.
Before we leave the FortiManager, let’s talk about some other reasons our customers choose to deploy in AWS.
Did you know that you can coordinate how FortiGates source metadata from AWS through FortiManager policy packages? This allows you to create globally scalable policies that are dynamic and automated for the infrastructure and applications they are protecting. For example, creating a workload in AWS with a key:value pair identifier or other attribute, maybe a specific VPC identifier, would allow that workload to be picked up by a policy matching those attributes. This forms a policy framework that removes the effort of managing manual policy changes and orients the security practice toward business intent. The FortiManager does this by either configuring the AWS connector directly on FortiGates or by acting as a proxy and calling the metadata and centrally distributing policy objects on behalf of the FortiGates.
For our customers that manage FortiGate-VM as auto scale groups (ASGs), the FortiManager supports the deployment and management of ASGs. As your clusters scale out or scale in, the FortiManager will manage device authorization and policy with the ASG.
For AWS customers running Fortinet, FortiAnalyzer is equally as powerful in its own right. FortiAnalyzer acts as signal correlation and enrichment point for events happening in the Fortinet, and most often FortiGate, environments. Intelligent correlation and AI on the FortiAnalyzer coordinate signal through Event Handlers which generate Indicators of Compromise (IOCs). These IOCs improve signal fidelity as highly reliable threat and alerts.
As with FortiManager, the FortiAnalyzer can be scaled up according to the volume and rate at which you need to collect logging. The log rate details are given on the FortiAnalyzer Dashboard.
Without going into the details, the upgrade process is very much like the FortiManager and can be followed in specificity here: https://docs.fortinet.com/document/fortianalyzer-public-cloud/7.6.0/aws-administration-guide/926709/...
The capacities and instance sizes are described in the table below and really is predicated in ensuring the minimum amount of resources for quality implementation.
If additional scale is required, FortiAnalyzer can be deployed in “Collector” and “Analyzer” modes to create a hierarchical or distributed model for log collection. See the details here: https://docs.fortinet.com/document/fortianalyzer/7.6.2/administration-guide/129528/collectors-and-an...
Let me cover some highlights of the FortiAnalyzer specific to AWS deployments that are important to know.
Many customers rely on Cloudwatch or S3 as part of the log collection and storage strategy. These are important and necessary for most AWS customers, and as such, FortiAnalyzer has been integrated into both services.
FortiAnalyzer’s fluentd service supports the ingestion of logs with customized outputs to services such as Cloudwatch. The screenshot below shows my FortiAnalyzer with custom filters for just the data and format that I would like to output to AWS Cloudwatch.
For S3, FortiAnalyzer can connect directly into S3 to offload log storage where it can be processed and used in other workflows, such as through SNS topics, or ingested into SIEMs, and so forth. In the example below, we create an AWS S3 Connector and define the storage bucket and permission for shipping the logs to AWS S3.
Our promise to our Fortinet customers is to provide greater flexibility, simplicity, and choice in how you deploy and manage security. We understand that security must be incorporated deeply and reliably into the platforms that you support. Our efforts to make FortiManager and FortiAnalyzer easier to consume and tightly integrated to support are a continuation of this mission.
Please give these deployments a try by using the AWS Marketplace listed AMIs linked below. Please reach out to your Fortinet support contacts with any questions and feedback. We are thankful for the opportunities to secure our customers.
Fortinet FortiManager (PAYG) Centralized Security Management
