Mastering FortiGate Firewall Deployment and Configuration on AWS
.
In today's hybrid and multi-cloud environments, securing network traffic in Amazon Web Services (AWS) demands enterprise-grade solutions that bridge traditional security practices with cloud-native architectures. FortiGate Next-Generation Firewalls provide this critical bridge, offering advanced threat protection, VPN connectivity, and network segmentation within AWS Virtual Private Clouds (VPCs). This comprehensive guide synthesizes official documentation and expert implementation insights to help you successfully deploy, configure, and manage FortiGate firewalls in AWS, whether for simple internet gateway protection, complex multi-VPC traffic inspection, or hybrid cloud connectivity via site-to-site VPN.
The journey from selecting the right deployment model to establishing fully encrypted tunnels between on-premises data centers and AWS resources requires careful planning and execution. By understanding the available options—from standalone instances and high-availability clusters to integrations with Aviatrix FireNet and AWS Firewall Manager—you can architect a security posture that is both robust and adaptable to your organization's evolving cloud footprint.
Core Deployment Models and Architecture
Standalone FortiGate-VM Deployment
The foundation of AWS firewall security begins with deploying the FortiGate-VM instance from the AWS Marketplace. According to Fortinet's documentation, the FortiGate-VM for AWS combines stateful inspection with a comprehensive suite of security features, including application control, IPS, antivirus, and web filtering. The security-hardened FortiOS operating system is purpose-built for inspecting and identifying malware, supporting direct single root I/O virtualization for consistent performance in the cloud environment.
A typical deployment involves launching an instance with at least two network interfaces: one for the untrusted (WAN/egress) segment (often in a public subnet) and another for the trusted (LAN) segment (in a private subnet). The instance size (e.g., c5.xlarge) should be selected based on anticipated throughput and inspection requirements. Initial access is gained via the generated key pair for SSH or by navigating to the public IP for HTTPS management access, with the default password being the instance ID.
High-Availability and Scalability Configurations
For production environments requiring resilience, FortiGate-VM supports active/passive high availability (HA) with native unicast HA synchronization. In this configuration, if the primary node fails, the passive firewall instance becomes active and uses AWS API calls to reconfigure its network interfaces. Beyond traditional HA, the platform also supports active/active configurations using Elastic Load Balancing (ELB) and autoscaling groups to handle variable traffic loads, ensuring both fault tolerance and elastic scalability that aligns with cloud principles.
Integration with Aviatrix FireNet
For organizations managing complex multi-VPC or transit gateway architectures, the Aviatrix Firewall Network (FireNet) offers a streamlined integration path. As detailed in Aviatrix's documentation, FireNet can automatically launch and orchestrate FortiGate instances to inspect traffic between network domains (e.g., different VPCs or from VPC to internet). In this model, the FortiGate's LAN interface (port2) is placed on the same subnet as the Aviatrix gateway, and the controller can be integrated via a REST API token to enable automatic route updates, simplifying policy-based traffic steering.
Step-by-Step Configuration Workflow
Initial Firewall Setup and Interface Configuration
After deployment, the initial login (username 'admin') requires a password change. The first critical step is configuring the network interfaces. For the WAN interface (port1), administrators should enable DHCP to retrieve a private IP from AWS and select the "Retrieve default gateway from server" option. This interface is typically assigned a "WAN" role. For the LAN interface (port2), DHCP is also enabled for IP assignment, but retrieving the default gateway should be disabled. Administrative access (HTTPS) should be enabled on this interface, and it should be assigned a "LAN" role.
Routing and Policy Configuration
Proper routing ensures traffic flows through the firewall for inspection. A fundamental step is creating static routes for traffic destined to other VPCs or on-premises networks. A common practice is to configure a route for all RFC 1918 private address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) pointing to the AWS default gateway on the LAN interface subnet (e.g., 10.66.0.97 for a 10.66.0.96/28 subnet). This "hairpins" the traffic back to the transit gateway or next-hop device for further delivery.
Security policies govern what traffic is permitted. A basic VPC-to-VPC inspection policy would have the LAN interface as both the incoming and outgoing interface, with source, destination, and service set to "ALL," and the action set to "ACCEPT." For egress internet traffic, a separate policy is created with the LAN interface as the source and the WAN interface as the destination, with NAT enabled. These baseline policies can later be refined with specific user, schedule, and application controls.
Establishing Site-to-Site VPN to AWS
Creating a secure hybrid cloud connection is a multi-step process involving both AWS and FortiGate configuration.
- AWS Infrastructure Setup: Create a Virtual Private Gateway (VPG) and attach it to your VPC. Create a Customer Gateway (CGW) resource, specifying your on-premises FortiGate's public IP address.
- VPN Connection Creation: Create a Site-to-Site VPN Connection linking the VPG and CGW. Select static routing and download the configuration file, which contains the crucial details for the FortiGate side.
- FortiGate IPSec Configuration:
- Phase 1: Create a new custom VPN tunnel. Enter the remote gateway IP (the VPG address from AWS). Set the mode to "Aggressive" if using dynamic on-premises IP, or "Main" for static IP. Use the pre-shared key from the AWS config. Set encryption (e.g., AES-128), authentication (SHA-1), and Diffie-Hellman group (e.g., 2).
- Phase 2: Create a Phase 2 selector defining the encryption domain. Set the local subnet (your on-premises network, e.g., 192.168.1.0/24) and remote subnet (your AWS VPC CIDR, e.g., 10.0.0.0/16). Enable Perfect Forward Secrecy (PFS).
- Firewall Policies and Routing: Finally, create firewall policies on the FortiGate to allow traffic between the internal network interface and the new VPN tunnel interface. Add a static route on the FortiGate directing traffic for the AWS VPC subnet through the VPN tunnel interface.
Advanced Management and Security Integration
Centralized Policy with AWS Firewall Manager
For organizations with multiple AWS accounts, AWS Firewall Manager provides centralized governance. You can create Firewall Manager AWS WAF policies that automatically deploy and maintain Web Application Firewall (WAF) rules across your accounts. While this service manages AWS WAF and Shield Advanced, it represents the operational model of centralized security management that should be mirrored in your FortiGate strategy, potentially using FortiManager for centralized FortiGate policy administration.
Cost Management and Operational Vigilance
A critical, often overlooked aspect of running third-party firewalls in the cloud is cost management. Fortinet emphasizes that customers are responsible for all AWS costs incurred, including compute, storage, data transfer, and—importantly—automatically generated system logs, snapshots, and temporary files. Proactive measures are non-negotiable: set up AWS Budgets and Cost Alarms, monitor disk usage via CloudWatch, and establish clear procedures for decommissioning test environments to avoid unexpected charges.
FAQs: FortiGate Firewall on AWS
What are the primary deployment models for FortiGate on AWS?
The three primary models are: 1) Standalone FortiGate-VM, deployed directly from the AWS Marketplace for securing a single VPC; 2) High-Availability (HA) Pairs, using FortiGate-native HA for stateful failover within an Availability Zone or across AZs; and 3) Integrated with a Cloud Network Platform, such as Aviatrix FireNet, where the firewall is launched and managed as part of a broader transit architecture for inspecting traffic between multiple VPCs and the internet.
How do I choose between an active/passive HA and an autoscaling group?
Choose active/passive HA when you require stateful failover with session persistence for stateful connections (like VPNs or certain application sessions). This is critical for mission-critical, stateful applications. Use an autoscaling group behind an Elastic Load Balancer when your workload is primarily stateless (like web traffic) and you need to scale the firewall capacity in and out dynamically based on traffic load, accepting that individual instance failures will drop existing sessions.
Can I use AWS Firewall Manager to manage my FortiGate instances?
No, AWS Firewall Manager is a native AWS service designed to manage other native AWS security services like AWS WAF, AWS Shield Advanced, and VPC security groups. It cannot manage third-party virtual appliances like FortiGate. To achieve centralized, multi-account management for FortiGate policies, you should deploy FortiManager on AWS, which is Fortinet's dedicated centralized management platform for their firewall ecosystem.
What is the most common mistake when setting up Site-to-Site VPN between FortiGate and AWS?
The most common mistake is a mismatch in Phase 1 or Phase 2 parameters. Every setting—including the encryption algorithm, hash algorithm, Diffie-Hellman group, lifetime, and mode (Main vs. Aggressive)—must be identical on both the FortiGate and the AWS Virtual Private Gateway configuration. Always double-check these parameters against the configuration file downloaded from the AWS VPN Connection console. Also, ensure that the necessary UDP ports 500 and 4500 are open in any associated security groups or on-premises firewalls.
How can I control costs associated with running FortiGate-VM on AWS?
Implement a rigorous tagging strategy for all firewall-related resources (instances, EBS volumes, snapshots) to track costs. Use AWS Cost Explorer to break down expenses. Most importantly, set up Amazon CloudWatch Alarms for metrics like CPU utilization and network throughput to right-size instances, and configure AWS Budgets with alerts to notify you when costs exceed expected thresholds. Regularly audit and delete unattached EBS volumes and old AMI snapshots that are no longer needed.