Internet Egress Options

Overview

The FortiGate autoscale solution provides two distinct architectures for internet egress traffic, each optimized for different operational requirements and cost considerations.

Option 1: Elastic IP (EIP) per Instance

Each FortiGate instance in the autoscale group receives a dedicated Elastic IP address. All traffic destined for the public internet is source-NATed behind the instance’s assigned EIP.

Configuration

access_internet_mode = "eip"

Architecture Behavior

In EIP mode, the architecture routes all internet-bound traffic to port2 (the public interface). The route table for the public subnet directs traffic to the Internet Gateway (IGW), where automatic source NAT to the associated EIP occurs.

Advantages

• No NAT Gateway costs: Eliminates monthly NAT Gateway charges ($0.045/hour + data processing)
• Distributed egress: Each instance has independent internet connectivity
• Simplified troubleshooting: Per-instance source IP simplifies traffic flow analysis
• No single point of failure: Loss of one instance’s EIP doesn’t affect others

Considerations

• Unpredictable IP addresses: EIPs are allocated from AWS’s pool; you cannot predict or specify the assigned addresses
• Allowlist complexity: Destinations requiring IP allowlisting must accommodate a pool of EIPs (one per maximum autoscale capacity)
• IP churn during scaling: Scale-out events introduce new source IPs; scale-in events remove them
• Limited EIP quota: AWS accounts have default limits (5 EIPs per region, increased upon request)

Best Use Cases

• Cost-sensitive deployments where NAT Gateway charges exceed EIP allocation costs
• Environments where destination allowlisting is not required
• Architectures prioritizing distributed egress over consistent source IPs
• Development and testing environments with limited budget

Option 2: NAT Gateway

All FortiGate instances share one or more NAT Gateways deployed in public subnets. Traffic is source-NATed to the NAT Gateway’s static Elastic IP address.

Configuration

access_internet_mode = "nat_gw"

Architecture Behavior

NAT Gateway mode requires additional subnet and route table configuration. Internet-bound traffic is first routed to the NAT Gateway in the public subnet, which performs source NAT to its static EIP before forwarding to the IGW.

Advantages

• Predictable source IP: Single, stable public IP address for the lifetime of the NAT Gateway
• Simplified allowlisting: Destinations only need to allowlist one IP address (per Availability Zone)
• High throughput: NAT Gateway supports up to 45 Gbps per AZ
• Managed service: AWS handles NAT Gateway scaling and availability
• Independent of FortiGate scaling: Source IP remains constant during scale-in/scale-out events

Considerations

• Additional costs: $0.045/hour per NAT Gateway + $0.045 per GB data processed
• Per-AZ deployment: Multi-AZ architectures require NAT Gateway in each AZ for fault tolerance
• Additional subnet requirements: Requires dedicated NAT Gateway subnet in each AZ
• Route table complexity: Additional route tables needed for NAT Gateway routing

Cost Analysis Example

Scenario: 4 FortiGate instances processing 10 TB/month egress traffic

EIP Mode:

• 4 EIP allocations: $0 (first EIP free, then $0.00/hour per EIP)
• Total monthly: ~$0 (minimal costs)

NAT Gateway Mode (2 AZs):

• 2 NAT Gateways: 2 × $0.045/hour × 730 hours = $65.70
• Data processing: 10,000 GB × $0.045 = $450.00
• Total monthly: $515.70

Decision Point: NAT Gateway makes sense when consistent source IP requirement justifies the additional cost.

Best Use Cases

• Production environments requiring predictable source IPs
• Compliance scenarios where destination IP allowlisting is mandatory
• High-volume egress traffic to SaaS providers with IP allowlisting requirements
• Architectures where operational simplicity outweighs additional cost

Decision Matrix

Next Steps

After selecting your internet egress option, proceed to Firewall Architecture to configure the FortiGate interface model.

Firewall Architecture

Overview

FortiGate instances can operate in single-arm (1-ARM) or dual-arm (2-ARM) network configurations, fundamentally changing traffic flow patterns through the firewall.

Configuration

firewall_policy_mode = "1-arm"  # or "2-arm"

2-ARM Configuration (Recommended for Most Deployments)

Architecture Overview

The 2-ARM configuration deploys FortiGate instances with distinct “trusted” (private) and “untrusted” (public) interfaces, providing clear network segmentation.

Traffic Flow:

1. Traffic arrives at GWLB Endpoints (GWLBe) in the inspection VPC
2. GWLB load-balances traffic across healthy FortiGate instances
3. Traffic encapsulated in Geneve tunnels arrives at FortiGate port1 (data plane)
4. FortiGate inspects traffic and applies security policies
5. Internet-bound traffic exits via port2 (public interface)
6. Port2 traffic is source-NATed via EIP or NAT Gateway
7. Return traffic follows reverse path back through Geneve tunnels

Interface Assignments

• port1: Data plane interface for GWLB connectivity (Geneve tunnel termination)
• port2: Public interface for internet egress (with optional dedicated management when enabled)

Network Interfaces Visualization

The FortiGate GUI displays both physical interfaces and logical Geneve tunnel interfaces. Traffic inspection occurs on the logical tunnel interfaces, while physical port2 handles egress.

Advantages

• Clear network segmentation: Separate trusted and untrusted zones
• Traditional firewall model: Familiar architecture for network security teams
• Simplified policy creation: North-South policies align with interface direction
• Better traffic visibility: Distinct ingress/egress paths ease troubleshooting
• Dedicated management option: Port2 can be isolated for management traffic

Best Use Cases

• Production deployments requiring clear network segmentation
• Environments with security policies mandating separate trusted/untrusted zones
• Architectures where dedicated management interface is required
• Standard north-south inspection use cases

1-ARM Configuration

Architecture Overview

The 1-ARM configuration uses a single interface (port1) for all data plane traffic, eliminating the need for a second network interface.

Traffic Flow:

1. Traffic arrives at port1 encapsulated in Geneve tunnels from GWLB
2. FortiGate inspects traffic and applies security policies
3. Traffic is hairpinned back through the same Geneve tunnel it arrived on
4. Traffic returns to originating distributed VPC through GWLB
5. Distributed VPC uses its own internet egress path (IGW/NAT Gateway)

This “bump-in-the-wire” architecture is the typical 1-ARM pattern for distributed inspection, where the FortiGate provides security inspection but traffic egresses from the spoke VPC, not the inspection VPC.

Important Behavior: Stateful Load Balancing

GWLB Statefulness: The Gateway Load Balancer maintains connection state tables for traffic flows.

Primary Traffic Pattern (Distributed Architecture):

• ✅ Traffic enters via Geneve tunnel → FortiGate inspection → Hairpins back through same Geneve tunnel
• ✅ Distributed VPC handles actual internet egress via its own IGW/NAT Gateway
• ✅ This “bump-in-the-wire” model provides security inspection without routing traffic through inspection VPC

Key Requirement: Symmetric routing through the GWLB. Traffic must return via the same Geneve tunnel it arrived on to maintain proper state table entries.

Interface Assignments

• port1: Combined data plane (Geneve) and egress (internet) interface

Advantages

• Reduced complexity: Single interface simplifies routing and subnet allocation
• Lower costs: Fewer ENIs to manage and potential for smaller instance types
• Simplified subnet design: Only requires one data subnet per AZ

Considerations

• Hairpinning pattern: Traffic typically hairpins back through same Geneve tunnel
• Higher port1 bandwidth requirements: All traffic flows through single interface (both directions)
• Limited management options: Cannot enable dedicated management ENI in true 1-ARM mode
• Symmetric routing requirement: All traffic must egress and return via port1 for proper state table maintenance

Best Use Cases

• Cost-optimized deployments with lower throughput requirements
• Simple north-south inspection without management VPC integration
• Development and testing environments
• Architectures where simplified subnet design is prioritized

Comparison Matrix

Next Steps

After selecting your firewall architecture, proceed to Dedicated Management ENI to learn about management plane isolation options.

Management Isolation Options

Overview

The FortiGate autoscale solution provides multiple approaches to isolating management traffic from data plane traffic, ranging from shared interfaces to complete physical network separation.

This page covers three progressive levels of management isolation, allowing you to choose the appropriate security posture for your deployment requirements.

Option 1: Combined Data + Management (Default)

Architecture Overview

In the default configuration, port2 serves dual purposes:

• Data plane: Internet egress for inspected traffic (in 2-ARM mode)
• Management plane: GUI, SSH, SNMP access

Configuration

enable_dedicated_management_eni = false
enable_dedicated_management_vpc = false

Characteristics

• Simplest configuration: No additional interfaces or VPCs required
• Lower cost: Minimal infrastructure overhead
• Shared security groups: Same rules govern data and management traffic
• Single failure domain: Management access tied to data plane availability

When to Use

• Development and testing environments
• Proof-of-concept deployments
• Budget-constrained projects
• Simple architectures without compliance requirements

Option 2: Dedicated Management ENI

Architecture Overview

Port2 is removed from the data plane and dedicated exclusively to management functions. FortiOS configures the interface with set dedicated-to management, placing it in an isolated VRF with independent routing.

Configuration

enable_dedicated_management_eni = true

How It Works

1. Dedicated-to attribute: FortiOS configures port2 with set dedicated-to management
2. Separate VRF: Port2 is placed in an isolated VRF with independent routing table
3. Policy restrictions: FortiGate prevents creation of firewall policies using port2
4. Management-only traffic: GUI, SSH, SNMP, and FortiManager/FortiAnalyzer connectivity

FortiOS Configuration Impact

The dedicated management ENI can be verified in the FortiGate GUI:

The interface shows the dedicated-to: management attribute and separate VRF assignment, preventing data plane traffic from using this interface.

Important Compatibility Notes

Characteristics

• Clear separation of concerns: Management traffic isolated from data plane
• Independent security policies: Separate security groups for management interface
• Enhanced security posture: Reduces attack surface on management plane
• Moderate complexity: Requires additional subnet and routing configuration

When to Use

• Production deployments requiring management isolation
• Security-conscious environments
• Architectures without dedicated management VPC
• Compliance requirements for management plane separation

Option 3: Dedicated Management VPC (Full Isolation)

Architecture Overview

The dedicated management VPC provides complete physical network separation by deploying FortiGate management interfaces in an entirely separate VPC from the data plane.

Configuration

enable_dedicated_management_vpc = true
dedicated_management_vpc_tag = "your-mgmt-vpc-tag"
dedicated_management_public_az1_subnet_tag = "your-az1-subnet-tag"
dedicated_management_public_az2_subnet_tag = "your-az2-subnet-tag"

Benefits

• Physical network separation: Management traffic never traverses inspection VPC
• Independent internet connectivity: Management VPC has dedicated IGW or VPN
• Centralized management infrastructure: FortiManager and FortiAnalyzer deployed in management VPC
• Separate security controls: Management VPC security groups independent of data plane
• Isolated failure domains: Management VPC issues don’t affect data plane

Management VPC Creation Options

Option A: Created by existing_vpc_resources Template (Recommended)

The existing_vpc_resources template creates the management VPC with standardized tags that the simplified template automatically discovers.

Advantages:

• Management VPC lifecycle independent of inspection VPC
• FortiManager/FortiAnalyzer persistence across inspection VPC redeployments
• Separation of concerns for infrastructure management

Default Tags (automatically created):

Configuration (terraform.tfvars):

enable_dedicated_management_vpc = true
dedicated_management_vpc_tag = "acme-test-management-vpc"
dedicated_management_public_az1_subnet_tag = "acme-test-management-public-az1-subnet"
dedicated_management_public_az2_subnet_tag = "acme-test-management-public-az2-subnet"

Option B: Use Existing Management VPC

If you have an existing management VPC with custom tags, configure the template to discover it:

Configuration:

enable_dedicated_management_vpc = true
dedicated_management_vpc_tag = "my-custom-mgmt-vpc-tag"
dedicated_management_public_az1_subnet_tag = "my-custom-mgmt-public-az1-tag"
dedicated_management_public_az2_subnet_tag = "my-custom-mgmt-public-az2-tag"

The template uses these tags to locate the management VPC and subnets via Terraform data sources.

Behavior When Enabled

When enable_dedicated_management_vpc = true:

1. Automatic ENI creation: Template creates dedicated management ENI (port2) in management VPC subnets
2. Implies dedicated management ENI: Automatically sets enable_dedicated_management_eni = true
3. VPC peering/TGW: Management VPC must have connectivity to inspection VPC for HA sync
4. Security group creation: Appropriate security groups created for management traffic

Network Connectivity Requirements

Management VPC → Inspection VPC Connectivity:

• Required for FortiGate HA synchronization between instances
• Typically implemented via VPC peering or Transit Gateway attachment
• Must allow TCP port 443 (HA sync), TCP 22 (SSH), ICMP (health checks)

Management VPC → Internet Connectivity:

• Required for FortiGuard services (signature updates, licensing)
• Required for administrator access to FortiGate management interfaces
• Can be via Internet Gateway, NAT Gateway, or AWS Direct Connect

Characteristics

• Highest security posture: Complete physical isolation
• Greatest flexibility: Independent infrastructure lifecycle
• Higher complexity: Requires VPC peering or TGW configuration
• Additional cost: Separate VPC infrastructure and data transfer charges

When to Use

• Enterprise production deployments
• Strict compliance requirements (PCI-DSS, HIPAA, etc.)
• Multi-account AWS architectures
• Environments with dedicated management infrastructure
• Organizations with existing management VPCs for network security appliances

Comparison Matrix

Decision Tree

Use this decision tree to select the appropriate management isolation level:

1. Is this a production deployment?
   ├─ No → Combined Data + Management (simplest)
   └─ Yes → Continue to question 2

2. Do you have compliance requirements for management plane isolation?
   ├─ No → Dedicated Management ENI (good balance)
   └─ Yes → Continue to question 3

3. Do you have existing management VPC infrastructure?
   ├─ Yes → Dedicated Management VPC (leverage existing)
   └─ No → Evaluate cost/benefit:
       ├─ High security requirements → Dedicated Management VPC
       └─ Moderate requirements → Dedicated Management ENI

Deployment Patterns

Pattern 1: Dedicated ENI + EIP Mode

firewall_policy_mode = "2-arm"
access_internet_mode = "eip"
enable_dedicated_management_eni = true

• Port2 receives EIP for public management access
• Suitable for environments without management VPC
• Simplified deployment with direct internet management access

Pattern 2: Dedicated ENI + Management VPC

firewall_policy_mode = "2-arm"
access_internet_mode = "nat_gw"
enable_dedicated_management_vpc = true
dedicated_management_vpc_tag = "my-mgmt-vpc"

• Port2 connects to separate management VPC
• Management VPC has dedicated internet gateway or VPN connectivity
• Preferred for production environments with strict network segmentation

Pattern 3: Combined Management (Default)

firewall_policy_mode = "2-arm"
access_internet_mode = "eip"
enable_dedicated_management_eni = false

• Port2 remains in data plane
• Management access shares public interface with egress traffic
• Simplest configuration but lacks management plane isolation

Best Practices

1. Enable dedicated management ENI for production: Provides clear separation of concerns
2. Use dedicated management VPC for enterprise deployments: Optimal security posture
3. Document connectivity requirements: Ensure operations teams understand access paths
4. Test connectivity before production: Verify alternative access methods work
5. Plan for failure scenarios: Ensure backup access methods (SSM, VPN) are available
6. Use existing_vpc_resources template for management VPC: Separates lifecycle management
7. Document tag conventions: Ensure consistent tagging across environments
8. Monitor management interface health: Set up CloudWatch alarms for management connectivity

Troubleshooting

Issue: Cannot access FortiGate management interface

Check:

1. Security groups allow inbound traffic on management port (443, 22)
2. Route tables provide path from your location to management interface
3. If using dedicated management VPC, verify VPC peering or TGW is operational
4. If using NAT Gateway mode, verify you have alternative access method (VPN, Direct Connect)

Issue: Management interface has no public IP

Cause: Using access_internet_mode = "nat_gw" with dedicated management ENI

Solutions:

1. Switch to access_internet_mode = "eip" to receive public IP on port2
2. Enable enable_dedicated_management_vpc = true with separate internet connectivity
3. Use AWS Systems Manager Session Manager for private access
4. Configure VPN or Direct Connect for private network access

Issue: HA sync not working with dedicated management VPC

Check:

1. VPC peering or TGW attachment is configured between management and inspection VPCs
2. Security groups allow TCP 443 between FortiGate instances
3. Route tables in both VPCs have routes to each other’s subnets
4. Network ACLs permit required traffic

Next Steps

After configuring management isolation, proceed to Licensing Options to choose between BYOL, FortiFlex, or PAYG.

Licensing Options

Overview

The FortiGate autoscale solution supports three distinct licensing models, each optimized for different use cases, cost structures, and operational requirements. You can use a single licensing model or combine them in hybrid configurations for optimal cost efficiency.

Licensing Model Comparison

Option 1: BYOL (Bring Your Own License)

Overview

BYOL uses traditional FortiGate-VM license files that you purchase from Fortinet or resellers. The template automates license distribution through S3 bucket storage and Lambda-based assignment.

Configuration

asg_license_directory = "asg_license"
asg_byol_asg_min_size = 2
asg_byol_asg_max_size = 4

Directory Structure Requirements

Place BYOL license files in the directory specified by asg_license_directory:

terraform/autoscale_template/
├── terraform.tfvars
├── asg_license/
│   ├── FGVM01-001.lic
│   ├── FGVM01-002.lic
│   ├── FGVM01-003.lic
│   └── FGVM01-004.lic

Automated License Assignment

1. Terraform uploads .lic files to S3 during terraform apply
2. Lambda retrieves available licenses when instances launch
3. DynamoDB tracks assignments to prevent duplicates
4. Lambda injects license via user-data script
5. Licenses return to pool when instances terminate

Critical Capacity Planning

Characteristics

• ✅ Lowest total cost: Best value for long-term (12+ months)
• ✅ Predictable costs: Fixed licensing regardless of usage
• ⚠️ License management: Requires managing physical files
• ⚠️ Upfront investment: Must purchase licenses in advance

When to Use

• Long-term production (12+ months)
• Predictable, steady-state workloads
• Existing FortiGate BYOL licenses
• Cost-conscious deployments

Option 2: FortiFlex (Usage-Based Licensing)

Overview

FortiFlex provides consumption-based, API-driven licensing. Points are consumed daily based on configuration, offering flexibility and cost optimization compared to PAYG.

Prerequisites

1. Register FortiFlex Program via FortiCare
2. Purchase Point Packs
3. Create Configurations in FortiFlex portal
4. Generate API Credentials via IAM

For detailed setup, see Licensing Section.

Configuration

fortiflex_username      = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
fortiflex_password      = "xxxxxxxxxxxxxxxxxxxxx"
fortiflex_sn_list       = ["FGVMELTMxxxxxxxx"]
fortiflex_configid_list = ["My_4CPU_Config"]

Obtaining Required Values

1. API Username and Password:

• Navigate to Services > IAM in FortiCare
• Create permission profile with FortiFlex Read/Write access
• Create API user and download credentials
• Username is UUID in credentials file

2. Serial Number List:

• Navigate to Services > Assets & Accounts > FortiFlex
• View your FortiFlex programs
• Note serial numbers from program details

3. Configuration ID List:

• In FortiFlex portal, go to Configurations
• Configuration ID is the Name field you assigned

Match CPU counts:

fgt_instance_type = "c6i.xlarge"  # 4 vCPUs
fortiflex_configid_list = ["My_4CPU_Config"]  # Must match

Lambda Integration Behavior

At instance launch:

1. Lambda authenticates to FortiFlex API
2. Creates new entitlement under specified configuration
3. Receives and injects license token
4. Instance activates, point consumption begins

At instance termination:

1. Lambda calls API to STOP entitlement
2. Point consumption halts immediately
3. Entitlement preserved for reactivation

Troubleshooting

Problem: Instances don’t activate license

• Check Lambda CloudWatch logs for API errors
• Verify FortiFlex portal for failed entitlements
• Confirm network connectivity to FortiFlex API

Problem: “Insufficient points” error

• Check point balance in FortiFlex portal
• Purchase additional point packs
• Verify configurations use expected CPU counts

Characteristics

• ✅ Flexible consumption: Pay only for what you use
• ✅ No license file management: API-driven automation
• ✅ Lower cost than PAYG: Typically 20-40% less
• ⚠️ Point-based: Requires monitoring consumption
• ⚠️ API credentials: Additional security considerations

When to Use

• Variable workloads with unpredictable scaling
• Development and testing
• Short to medium-term (3-12 months)
• Burst capacity in hybrid architectures

Option 3: PAYG (Pay-As-You-Go)

Overview

PAYG uses AWS Marketplace on-demand instances with licensing included in hourly EC2 charge.

Configuration

asg_ondemand_asg_min_size = 0
asg_ondemand_asg_max_size = 4
asg_ondemand_asg_desired_size = 0

How It Works

1. Accept FortiGate-VM AWS Marketplace terms
2. Lambda launches instances using Marketplace AMI
3. FortiGate activates automatically via AWS
4. Hourly licensing cost added to EC2 charge

Characteristics

• ✅ Simplest option: Zero license management
• ✅ No upfront commitment: Pay per running hour
• ✅ Instant availability: No license pool constraints
• ⚠️ Highest hourly cost: Premium pricing for convenience

When to Use

• Proof-of-concept and evaluation
• Very short-term (< 3 months)
• Burst capacity in hybrid architectures
• Zero license administration requirement

Cost Comparison Example

Scenario: 2 FortiGate-VM instances (c6i.xlarge, 4 vCPU, UTP) running 24/7

Note: Illustrative costs. Actual pricing varies by term and bundle.

Hybrid Licensing Strategies

Strategy 1: BYOL Baseline + PAYG Burst (Recommended)

# BYOL for baseline
asg_license_directory = "asg_license"
asg_byol_asg_min_size = 2
asg_byol_asg_max_size = 4

# PAYG for burst
asg_ondemand_asg_max_size = 4

Best for: Production with occasional spikes

Strategy 2: FortiFlex Baseline + PAYG Burst

# FortiFlex for flexible baseline
fortiflex_configid_list = ["My_4CPU_Config"]
asg_byol_asg_max_size = 4

# PAYG for burst
asg_ondemand_asg_max_size = 4

Best for: Variable workloads with unpredictable spikes

Strategy 3: All BYOL (Cost-Optimized)

asg_license_directory = "asg_license"
asg_byol_asg_min_size = 2
asg_byol_asg_max_size = 6
asg_ondemand_asg_max_size = 0

Best for: Stable, predictable workloads

Strategy 4: All PAYG (Simplest)

asg_byol_asg_max_size = 0
asg_ondemand_asg_min_size = 2
asg_ondemand_asg_max_size = 8

Best for: POC, short-term, extreme variability

Decision Tree

1. Expected deployment duration?
   ├─ < 3 months → PAYG
   ├─ 3-12 months → FortiFlex or evaluate costs
   └─ > 12 months → BYOL + PAYG burst

2. Workload predictable?
   ├─ Yes, stable → BYOL
   └─ No, variable → FortiFlex or Hybrid

3. Want to manage license files?
   ├─ No → FortiFlex or PAYG
   └─ Yes, for cost savings → BYOL

4. Tolerance for complexity?
   ├─ Low → PAYG
   ├─ Medium → FortiFlex
   └─ High (cost focus) → BYOL

Best Practices

1. Calculate TCO: Use comparison matrix for your scenario
2. Start simple: Begin with PAYG for POC, optimize for production
3. Monitor costs: Track consumption via CloudWatch and FortiFlex reports
4. Provision buffer: 20% more licenses/entitlements than max_size
5. Secure credentials: Never commit FortiFlex credentials to git
6. Test assignment: Verify Lambda logs show successful injection
7. Plan exhaustion: Configure PAYG burst as safety net
8. Document strategy: Ensure ops team understands hybrid configs

Next Steps

After configuring licensing, proceed to FortiManager Integration for centralized management.

FortiManager Integration

Overview

The template supports optional integration with FortiManager for centralized management, policy orchestration, and configuration synchronization across the autoscale group.

Configuration

Enable FortiManager integration by setting the following variables in terraform.tfvars:

enable_fortimanager_integration = true
fortimanager_ip                 = "10.0.100.50"
fortimanager_sn                 = "FMGVM0000000001"
fortimanager_vrf_select         = 1

Variable Definitions

How FortiManager Integration Works

When enable_fortimanager_integration = true:

1. Lambda generates FortiOS config: Lambda function creates config system central-management stanza
2. Primary instance registration: Only the primary FortiGate instance registers with FortiManager
3. VDOM exception configured: Lambda adds config system vdom-exception to prevent central-management config from syncing to secondaries
4. Configuration synchronization: Primary instance syncs configuration to secondary instances via FortiGate-native HA sync
5. Policy deployment: Policies deployed from FortiManager propagate through primary → secondary sync

Generated FortiOS Configuration

Lambda automatically generates the following configuration on the primary instance only:

config system vdom-exception
    edit 0
        set object system.central-management
    next
end

config system central-management
    set type fortimanager
    set fmg 10.0.100.50
    set serial-number FMGVM0000000001
    set vrf-select 1
end

Secondary instances do not receive central-management configuration, preventing:

• Orphaned device entries on FortiManager during scale-in events
• Confusion about which instance is authoritative for policy
• Unnecessary FortiManager license consumption

Network Connectivity Requirements

FortiGate → FortiManager:

• TCP 541: FortiManager to FortiGate communication (FGFM protocol)
• TCP 514 (optional): Syslog if logging to FortiManager
• HTTPS 443: FortiManager GUI access for administrators

Ensure:

• Security groups allow traffic from FortiGate management interfaces to FortiManager
• Route tables provide path to FortiManager IP
• Network ACLs permit required traffic
• VRF routing configured if using non-default VRF

VRF Selection

The fortimanager_vrf_select parameter specifies which VRF to use for FortiManager connectivity:

Common scenarios:

• 0 (default): Use global VRF; FortiManager accessible via default routing table
• 1 or higher: Use specific management VRF; FortiManager accessible via separate routing domain

When to use non-default VRF:

• FortiManager in separate management VPC requiring VPC peering or TGW
• Network segmentation requires management traffic in dedicated VRF
• Multiple VRFs configured and explicit path selection needed

FortiManager 7.6.3+ Critical Requirement

config system global
    set fgfm-allow-vm enable
end

show system global | grep fgfm-allow-vm

FortiManager Workflow

After deployment:

1. Verify device registration:

   • Log into FortiManager GUI
   • Navigate to Device Manager > Device & Groups
   • Confirm primary FortiGate instance appears as unauthorized device

2. Authorize device:

   • Right-click on unauthorized device
   • Select Authorize
   • Assign to appropriate ADOM and device group

3. Install policy package:

   • Create or assign policy package to authorized device
   • Click Install to push policies to FortiGate

4. Verify configuration sync:

   • Make configuration change on FortiManager
   • Install policy package to primary FortiGate
   • Verify change appears on secondary FortiGate instances via HA sync

Best Practices

1. Pre-configure FortiManager: Create ADOMs, device groups, and policy packages before deploying autoscale group
2. Test in non-production: Validate FortiManager integration in dev/test environment first
3. Monitor device status: Set up FortiManager alerts for device disconnections
4. Document policy workflow: Ensure team understands FortiManager → Primary → Secondary sync pattern
5. Plan for primary failover: If primary instance fails, new primary automatically registers with FortiManager
6. Backup FortiManager regularly: Critical single point of management; ensure proper backup strategy

Reference Documentation

For complete FortiManager integration details, including User Managed Scaling (UMS) mode, see the project file: FortiManager Integration Configuration

Next Steps

After configuring FortiManager integration, proceed to Autoscale Group Capacity to configure instance counts and scaling behavior.

Autoscale Group Capacity

Overview

Configure the autoscale group size parameters to define minimum, maximum, and desired instance counts for both BYOL and on-demand (PAYG) autoscale groups.

Configuration

# BYOL ASG capacity
asg_byol_asg_min_size         = 1
asg_byol_asg_max_size         = 2
asg_byol_asg_desired_size     = 1

# On-Demand (PAYG) ASG capacity
asg_ondemand_asg_min_size     = 0
asg_ondemand_asg_max_size     = 2
asg_ondemand_asg_desired_size = 0

Parameter Definitions

Capacity Planning Strategies

Strategy 1: BYOL Baseline with PAYG Burst (Recommended)

Objective: Optimize costs by using BYOL for steady-state traffic and PAYG for unpredictable spikes

# BYOL handles baseline 24/7 traffic
asg_byol_asg_min_size = 2
asg_byol_asg_max_size = 4
asg_byol_asg_desired_size = 2

# PAYG handles burst traffic only
asg_ondemand_asg_min_size = 0
asg_ondemand_asg_max_size = 6
asg_ondemand_asg_desired_size = 0

Scaling behavior:

1. Normal operations: 2 BYOL instances handle traffic
2. Traffic increases: BYOL ASG scales up to 4 instances
3. Traffic continues increasing: PAYG ASG scales from 0 → 6 instances
4. Traffic decreases: PAYG ASG scales down to 0, then BYOL ASG scales down to 2

Strategy 2: All PAYG (Simplest)

Objective: Maximum flexibility with zero license management overhead

# No BYOL instances
asg_byol_asg_min_size = 0
asg_byol_asg_max_size = 0
asg_byol_asg_desired_size = 0

# All capacity is PAYG
asg_ondemand_asg_min_size = 2
asg_ondemand_asg_max_size = 8
asg_ondemand_asg_desired_size = 2

Use cases:

• Proof of concept or testing
• Short-term projects (< 6 months)
• Extreme variability where license planning is impractical

Strategy 3: All BYOL (Lowest Cost)

Objective: Minimum operating costs for long-term, predictable workloads

# All capacity is BYOL
asg_byol_asg_min_size = 2
asg_byol_asg_max_size = 6
asg_byol_asg_desired_size = 2

# No PAYG instances
asg_ondemand_asg_min_size = 0
asg_ondemand_asg_max_size = 0
asg_ondemand_asg_desired_size = 0

Requirements:

• Sufficient BYOL licenses for max_size (6 in this example)
• Predictable traffic patterns that rarely exceed max capacity
• Willingness to accept capacity ceiling (no burst beyond BYOL max)

CloudWatch Alarm Integration

Autoscale group scaling is triggered by CloudWatch alarms monitoring CPU utilization:

Default thresholds (set in underlying module):

• Scale-out alarm: CPU > 70% for 2 consecutive periods (2 minutes)
• Scale-in alarm: CPU < 30% for 2 consecutive periods (2 minutes)

Customization (requires editing underlying module):

# Located in module: fortinetdev/cloud-modules/aws
scale_out_threshold = 80  # Higher threshold = more aggressive cost optimization
scale_in_threshold  = 20  # Lower threshold = more aggressive cost optimization

Capacity Planning Calculator

Formula: Capacity Needed = (Peak Gbps Throughput) / (Per-Instance Gbps) × 1.2

Example:

• Peak throughput requirement: 8 Gbps
• c6i.xlarge (4 vCPU) with IPS enabled: ~2 Gbps per instance
• Calculation: 8 / 2 × 1.2 = 4.8 → round up to 5 instances
• Set max_size = 5 or higher for safety margin

Important Considerations

Next Steps

After configuring capacity, proceed to Primary Scale-In Protection to protect the primary instance from being terminated during scale-in events.

Primary Scale-In Protection

Overview

Protect the primary FortiGate instance from scale-in events to maintain configuration synchronization stability and prevent unnecessary primary elections.

Configuration

primary_scalein_protection = true

Why Protect the Primary Instance?

In FortiGate autoscale architecture:

• Primary instance: Elected leader responsible for configuration management and HA sync
• Secondary instances: Receive configuration from primary via FortiGate-native HA synchronization

Without scale-in protection:

1. AWS autoscaling may select primary instance for termination during scale-in
2. Remaining instances must elect new primary
3. Configuration may be temporarily unavailable during election
4. Potential for configuration loss if primary was processing updates

With scale-in protection:

1. AWS autoscaling only terminates secondary instances
2. Primary instance remains stable unless it is the last instance
3. Configuration synchronization continues uninterrupted
4. Predictable autoscale group behavior

How It Works

The primary_scalein_protection variable is passed through to the autoscale group configuration:

In the underlying Terraform module (autoscale_group.tf):

AWS autoscaling respects the protection attribute and never selects protected instances for scale-in events.

Verification

You can verify scale-in protection in the AWS Console:

1. Navigate to EC2 > Auto Scaling Groups
2. Select your autoscale group
3. Click Instance management tab
4. Look for Scale-in protection column showing “Protected” for primary instance

When Protection is Removed

Scale-in protection automatically removes when:

• Instance is the last remaining instance in the ASG (respecting min_size)
• Manual termination via AWS Console or API (protection can be overridden)
• Autoscale group is deleted

Best Practices

1. Always enable for production: Set primary_scalein_protection = true for production deployments
2. Consider disabling for dev/test: Development environments may not require protection
3. Monitor primary health: Protected instances still fail health checks and can be replaced
4. Document protection status: Ensure operations teams understand why primary instance is protected

AWS Documentation Reference

For more information on AWS autoscaling instance protection:

• Using AWS Autoscale Scale-in Protection

Next Steps

After configuring primary protection, review Additional Configuration Options for fine-tuning instance specifications and advanced settings.

Additional Configuration Options

Overview

This section covers additional configuration options for fine-tuning FortiGate instance specifications and advanced deployment settings.

FortiGate Instance Specifications

Instance Type Selection

fgt_instance_type = "c7gn.xlarge"

Instance type selection considerations:

• c6i/c7i series: Intel-based compute-optimized (best for x86 workloads)
• c6g/c7g/c7gn series: AWS Graviton (ARM-based, excellent performance)
• Sizing: Choose vCPU count matching expected throughput requirements

Common instance types for FortiGate:

FortiOS Version

fortios_version = "7.4.5"

Version specification options:

• Exact version (e.g., "7.4.5"): Pin to specific version for consistency across environments
• Major version (e.g., "7.4"): Automatically use latest minor version within major release
• Latest: Omit or use "latest" to always deploy newest available version

Recommendations:

• Production: Use exact version numbers to prevent unexpected changes
• Dev/Test: Use major version or latest to test new features and fixes
• Always test new FortiOS versions in non-production before upgrading production deployments

Version considerations:

• Newer versions may include critical security fixes
• Performance improvements and new features
• Potential breaking changes in configuration syntax
• Always review release notes before upgrading

FortiGate GUI Port

fortigate_gui_port = 443

Common options:

• 443 (default): Standard HTTPS port
• 8443: Alternate HTTPS port (some organizations prefer moving GUI off default port for security)
• 10443: Another common alternate port

When changing the GUI port:

• Update security group rules to allow traffic to new port
• Update documentation and runbooks with new port
• Existing sessions will be dropped when port changes
• Coordinate change with operations team

Gateway Load Balancer Cross-Zone Load Balancing

allow_cross_zone_load_balancing = true

Enabled (true) - Recommended for Production

• GWLB distributes traffic to healthy FortiGate instances in any Availability Zone
• Better utilization of capacity during partial AZ failures
• Improved overall availability and fault tolerance
• Traffic can flow to any healthy instance regardless of AZ

Disabled (false)

• GWLB only distributes traffic to instances in same AZ as GWLB endpoint
• Traffic remains within single AZ (lowest latency)
• Reduced capacity during AZ-specific health issues
• Must maintain sufficient capacity in each AZ independently

Decision Factors

Enable for:

• Production environments requiring maximum availability
• Multi-AZ deployments where instance distribution may be uneven
• Architectures where AZ-level failures must be transparent to applications
• Workloads where availability is prioritized over lowest latency

Disable for:

• Workloads with strict latency requirements
• Architectures with guaranteed even instance distribution across AZs
• Environments with predictable AZ-local traffic patterns
• Data residency requirements mandating AZ-local processing

Recommendation: Enable for production deployments to maximize availability and capacity utilization

SSH Key Pair

keypair_name = "my-fortigate-keypair"

Purpose: SSH key pair for emergency CLI access to FortiGate instances

Best practices:

• Create dedicated key pair for FortiGate instances (separate from application instances)
• Store private key securely in password manager or AWS Secrets Manager
• Rotate key pairs periodically (every 6-12 months)
• Document key pair name and location in runbooks
• Limit access to private key to authorized personnel only

Creating a key pair:

# Via AWS CLI
aws ec2 create-key-pair --key-name my-fortigate-keypair --query 'KeyMaterial' --output text > my-fortigate-keypair.pem
chmod 400 my-fortigate-keypair.pem

# Or via AWS Console: EC2 > Key Pairs > Create Key Pair

Resource Tagging

resource_tags = {
  Environment = "Production"
  Project     = "FortiGate-Autoscale"
  Owner       = "security-team@example.com"
  CostCenter  = "CC-12345"
}

Common tags to include:

• Environment: Production, Development, Staging, Test
• Project: Project or application name
• Owner: Team or individual responsible for resources
• CostCenter: For cost allocation and chargeback
• ManagedBy: Terraform, CloudFormation, etc.
• CreatedDate: When resources were initially deployed

Benefits of comprehensive tagging:

• Cost allocation and reporting
• Resource organization and filtering
• Access control policies
• Automation and orchestration
• Compliance and governance

Summary Checklist

Before proceeding to deployment, verify you’ve configured:

• ✅ Internet Egress: EIP or NAT Gateway mode selected
• ✅ Firewall Architecture: 1-ARM or 2-ARM mode chosen
• ✅ Management Isolation: Dedicated ENI and/or VPC configured (if required)
• ✅ Licensing: BYOL directory populated or FortiFlex configured
• ✅ FortiManager: Integration enabled (if centralized management required)
• ✅ Capacity: ASG min/max/desired sizes set appropriately
• ✅ Primary Protection: Scale-in protection enabled for production
• ✅ Instance Specs: Instance type and FortiOS version selected
• ✅ Additional Options: GUI port, cross-zone LB, key pair, tags configured

Next Steps

You’re now ready to proceed to the Summary page for a complete overview of all solution components, or jump directly to Templates to begin deployment.

Solution Components Summary

Overview

This summary provides a comprehensive reference of all solution components covered in this section, with quick decision guides and configuration references.

Component Quick Reference

1. Internet Egress Options

† Data processing example: 1 TB/month = $45 additional cost
Total NAT Gateway cost estimate: $65 (base) + $45 (1TB data) = $110/month for 2 AZs with 1TB egress

access_internet_mode = "eip"  # or "nat_gw"

Key Decision: Do you need predictable source IPs for allowlisting (white-listing)?

• Yes → NAT Gateway (stable IPs, higher cost)
• No → EIP (variable IPs, lower cost)

2. Firewall Architecture

firewall_policy_mode = "2-arm"  # or "1-arm"

3. Management Isolation

Three progressive levels:

1. Combined (Default): Port2 serves data + management
2. Dedicated ENI: Port2 dedicated to management only
3. Dedicated VPC: Complete physical network separation

enable_dedicated_management_eni = true
enable_dedicated_management_vpc = true

4. Licensing Options

Hybrid Strategy (Recommended): BYOL baseline + PAYG burst

5. FortiManager Integration

enable_fortimanager_integration = true
fortimanager_ip                 = "10.0.100.50"
fortimanager_sn                 = "FMGVM0000000001"

⚠️ Critical: FortiManager 7.6.3+ requires fgfm-allow-vm enabled before deployment

6. Autoscale Group Capacity

asg_byol_asg_min_size = 2
asg_byol_asg_max_size = 4
asg_ondemand_asg_max_size = 4

Formula: Capacity = (Peak Gbps / Per-Instance Gbps) × 1.2

7. Primary Scale-In Protection

primary_scalein_protection = true

Always enable for production to prevent primary instance termination during scale-in.

8. Additional Configuration

fgt_instance_type               = "c6i.xlarge"
fortios_version                 = "7.4.5"
fortigate_gui_port              = 443
allow_cross_zone_load_balancing = true
keypair_name                    = "my-fortigate-keypair"

Common Deployment Patterns

Pattern 1: Production with Maximum Isolation

access_internet_mode = "nat_gw"
firewall_policy_mode = "2-arm"
enable_dedicated_management_eni = true
enable_dedicated_management_vpc = true
asg_license_directory = "asg_license"
enable_fortimanager_integration = true
primary_scalein_protection = true

Use case: Enterprise production, compliance-driven

Pattern 2: Development and Testing

access_internet_mode = "eip"
firewall_policy_mode = "1-arm"
asg_ondemand_asg_min_size = 1
asg_ondemand_asg_max_size = 2
enable_fortimanager_integration = false

Use case: Development, testing, POC

Pattern 3: Balanced Production

access_internet_mode = "nat_gw"
firewall_policy_mode = "2-arm"
enable_dedicated_management_eni = true
fortiflex_username = "your-api-username"
enable_fortimanager_integration = true
primary_scalein_protection = true

Use case: Standard production, flexible licensing

Decision Tree

1. Do you need predictable source IPs for allowlisting?
   ├─ Yes → NAT Gateway (~$110/month for 2 AZs + 1TB data)
   └─ No → EIP (~$7/month)

2. Dedicated management interface?
   ├─ Yes → 2-ARM + Dedicated ENI
   └─ No → 1-ARM

3. Complete management isolation?
   ├─ Yes → Dedicated Management VPC
   └─ No → Dedicated ENI or skip

4. Licensing model?
   ├─ Long-term (12+ months) → BYOL
   ├─ Variable workload → FortiFlex
   ├─ Short-term (< 3 months) → PAYG
   └─ Best optimization → BYOL + PAYG hybrid

5. Centralized policy management?
   ├─ Yes → Enable FortiManager
   └─ No → Standalone

6. Production deployment?
   ├─ Yes → Enable primary scale-in protection
   └─ No → Optional

Pre-Deployment Checklist

Infrastructure:

• AWS account with permissions
• VPC architecture designed
• Subnet CIDR planning complete
• Transit Gateway configured (if needed)

Licensing:

• BYOL: License files ready (≥ max_size)
• FortiFlex: Program registered, API credentials
• PAYG: Marketplace subscription accepted

FortiManager (if applicable):

• FortiManager deployed and accessible
• FortiManager 7.6.3+: fgfm-allow-vm enabled
• ADOMs and device groups created
• Network connectivity verified

Configuration:

• terraform.tfvars populated
• SSH key pair created
• Resource tags defined
• Instance type selected

Troubleshooting Quick Reference

Next Steps

Proceed to Templates for step-by-step deployment procedures.

Additional Resources

• Fortinet Documentation
• FortiFlex Setup Guide
• FortiManager Integration
• Terraform Module Repository

Templates Overview

Introduction

The FortiGate Autoscale Simplified Template consists of two complementary Terraform templates that work together to deploy a complete FortiGate autoscale architecture in AWS:

1. existing_vpc_resources (Required First): Creates the Inspection VPC and supporting infrastructure with Fortinet-Role tags for resource discovery
2. autoscale_template (Required Second): Deploys the FortiGate autoscale group into the existing Inspection VPC

This modular approach allows you to:

• Separate VPC infrastructure from FortiGate deployment for better lifecycle management
• Use tag-based resource discovery for flexible integration
• Create a complete lab environment including management VPC, Transit Gateway, and spoke VPCs with traffic generators
• Mix and match components based on your specific requirements

Template Architecture

Component Relationships

┌─────────────────────────────────────────────────────────────────┐
│ existing_vpc_resources Template (Run First)                     │
│                                                                 │
│  ┌──────────────────┐    ┌─────────────────┐                    │
│  │ Management VPC   │    │ Transit Gateway │                    │
│  │ - FortiManager   │    │ - Spoke VPCs    │                    │
│  │ - FortiAnalyzer  │    │ - Linux Instances                    │
│  │ - Jump Box       │    │ - Test Traffic  │                    │
│  └──────────────────┘    └─────────────────┘                    │
│          │                       │                              │
│          └───────────┬───────────┘                              │
│                      │                                          │
│  ┌───────────────────▼───────────────────┐                      │
│  │ Inspection VPC (with Fortinet-Role    │                      │
│  │ tags for resource discovery)          │                      │
│  │ - Public/Private/GWLBE Subnets        │                      │
│  │ - Route Tables, IGW, NAT GW           │                      │
│  │ - TGW Attachment (optional)           │                      │
│  └───────────────────────────────────────┘                      │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
                       │ (Fortinet-Role tag discovery)
┌──────────────────────┼──────────────────────────────────────────┐
│ autoscale_template (Run Second)   │                               │
│                      │                                          │
│  ┌────────────────── ▼ ────────────────┐                        │
│  │ Deploys INTO Inspection VPC         │                        │
│  │ - FortiGate Autoscale Group         │                        │
│  │ - Gateway Load Balancer             │                        │
│  │ - GWLB Endpoints                    │                        │
│  │ - Lambda Functions                  │                        │
│  │ - Route modifications               │                        │
│  └─────────────────────────────────────┘                        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Fortinet-Role Tag Discovery

The autoscale_template discovers existing resources using Fortinet-Role tags. This tag-based approach provides:

• Decoupled lifecycle management: VPC infrastructure can persist while FortiGate deployments are updated
• Flexible integration: Works with any VPC that has the correct tags, not just those created by existing_vpc_resources
• Clear resource ownership: Tags explicitly identify resources intended for FortiGate integration

Quick Decision Tree

Use this decision tree to determine your deployment approach:

1. Do you have existing VPCs with Fortinet-Role tags?
   ├─ YES → Deploy autoscale_template only
   │         (Resources discovered via Fortinet-Role tags)
   │
   └─ NO → Continue to question 2

2. Do you need a complete lab environment for testing?
   ├─ YES → Deploy existing_vpc_resources (all components)
   │         Then deploy autoscale_template
   │         See: Lab Environment Pattern
   │
   └─ NO → Continue to question 3

3. Do you need centralized management (FortiManager/FortiAnalyzer)?
   ├─ YES → Deploy existing_vpc_resources (with management VPC)
   │         Then deploy autoscale_template
   │         See: Management VPC Pattern
   │
   └─ NO → Deploy existing_vpc_resources (inspection VPC only)
           Then deploy autoscale_template
           See: Minimal Deployment Pattern

Template Comparison

Common Integration Patterns

Pattern 1: Complete Lab Environment

Use case: Full-featured testing environment with management and traffic generation

Templates needed:

1. ✅ existing_vpc_resources (with all components enabled including Inspection VPC)
2. ✅ autoscale_template (deploys into Inspection VPC via Fortinet-Role tags)

What you get:

• Inspection VPC with Fortinet-Role tags for resource discovery
• Management VPC with FortiManager, FortiAnalyzer, and Jump Box
• Transit Gateway with spoke VPCs
• Linux instances for traffic generation
• FortiGate autoscale group with GWLB
• Complete end-to-end testing environment

Estimated cost: ~$300-400/month for complete lab

Deployment time: ~25-30 minutes

Next steps: Lab Environment Workflow

Pattern 2: Production Integration (Existing VPCs)

Use case: Deploy FortiGate inspection to existing production infrastructure

Templates needed:

1. ⚠️ Manual tagging of existing VPCs with Fortinet-Role tags, OR
2. ✅ existing_vpc_resources (inspection VPC only, to create properly tagged infrastructure)
3. ✅ autoscale_template (discovers resources via Fortinet-Role tags)

Prerequisites:

• Existing VPCs must have Fortinet-Role tags (see Required Tags)
• OR use existing_vpc_resources to create new Inspection VPC with correct tags
• Network connectivity established

What you get:

• FortiGate autoscale group with GWLB deployed into existing/tagged VPC
• Integration with existing Transit Gateway
• Tag-based resource discovery for flexibility

Estimated cost: ~$150-250/month (FortiGates only, plus any new VPC infrastructure)

Deployment time: ~15-20 minutes (plus tagging time if manual)

Next steps: Production Integration Workflow

Pattern 3: Management VPC Only

Use case: Testing FortiManager/FortiAnalyzer integration without spoke VPCs

Templates needed:

1. ✅ existing_vpc_resources (Inspection VPC + management VPC components)
2. ✅ autoscale_template (with FortiManager integration enabled)

What you get:

• Inspection VPC with Fortinet-Role tags
• Dedicated management VPC with FortiManager and FortiAnalyzer
• FortiGate autoscale group managed by FortiManager
• No Transit Gateway or spoke VPCs

Estimated cost: ~$300/month

Deployment time: ~20-25 minutes

Next steps: Management VPC Workflow

Pattern 4: Minimal Inspection VPC Only

Use case: Simplest deployment for testing FortiGate autoscale

Templates needed:

1. ✅ existing_vpc_resources (Inspection VPC only)
2. ✅ autoscale_template (without TGW attachment)

Configuration:

# existing_vpc_resources
enable_build_inspection_vpc   = true
enable_build_management_vpc   = false
enable_build_existing_subnets = false

What you get:

• Inspection VPC with Fortinet-Role tags
• FortiGate autoscale group with GWLB
• No management infrastructure or spoke VPCs

Estimated cost: ~$150-200/month

Deployment time: ~15 minutes

Next steps: Minimal Deployment Workflow

Required Fortinet-Role Tags

The autoscale_template discovers existing resources using Fortinet-Role tags. These tags are automatically created by existing_vpc_resources, or you can manually apply them to existing VPCs.

Required Tags for Inspection VPC

Example: For cp="acme" and env="test", the VPC tag would be acme-test-inspection-vpc

Optional Tags for Management VPC

Deployment Workflows

Lab Environment Workflow

Objective: Create complete testing environment from scratch

# Step 1: Deploy existing_vpc_resources (creates Inspection VPC with Fortinet-Role tags)
cd terraform/existing_vpc_resources
cp terraform.tfvars.example terraform.tfvars
# Edit: Enable all components:
#   enable_build_inspection_vpc   = true
#   enable_build_management_vpc   = true
#   enable_build_existing_subnets = true
#   enable_fortimanager           = true
#   enable_fortianalyzer          = true
terraform init && terraform apply

# Step 2: Note outputs (Fortinet-Role tags created automatically)
terraform output  # Save TGW name and FortiManager IP

# Step 3: Deploy autoscale_template (discovers VPCs via Fortinet-Role tags)
cd ../autoscale_template
cp terraform.tfvars.example terraform.tfvars
# Edit: Use SAME cp and env values (critical for tag discovery)
#       Set attach_to_tgw_name from Step 2 output
#       Configure FortiManager integration
terraform init && terraform apply

# Step 4: Verify
ssh -i ~/.ssh/keypair.pem ec2-user@<jump-box-ip>
curl http://<linux-instance-ip>  # Test connectivity

Time to complete: 30-40 minutes

See detailed guide: existing_vpc_resources Template

Production Integration Workflow

Objective: Deploy FortiGate inspection into existing or new Inspection VPC

Option A: Tag Existing VPCs Manually

If you have existing VPCs you want to use:

1. Apply Fortinet-Role tags to your existing VPC resources (see Required Tags)
2. Deploy autoscale_template with matching cp and env values

Option B: Create New Inspection VPC (Recommended)

# Step 1: Deploy existing_vpc_resources (Inspection VPC only)
cd terraform/existing_vpc_resources
cp terraform.tfvars.example terraform.tfvars
# Edit:
#   enable_build_inspection_vpc   = true
#   enable_build_management_vpc   = false
#   enable_build_existing_subnets = true  # if TGW needed
#   attach_to_tgw_name            = "production-tgw"  # existing TGW
terraform init && terraform apply

# Step 2: Deploy autoscale_template
cd ../autoscale_template
cp terraform.tfvars.example terraform.tfvars
# Edit: Use SAME cp and env values
#       Set attach_to_tgw_name to production TGW
#       Configure production-appropriate capacity
terraform init && terraform apply

# Step 3: Update TGW route tables (if needed)
# Route spoke VPC traffic (0.0.0.0/0) to inspection VPC attachment

# Step 4: Test and validate
# Verify traffic flows through FortiGate

Time to complete: 20-30 minutes

See detailed guide: autoscale_template

Management VPC Workflow

Objective: Deploy management infrastructure with FortiManager/FortiAnalyzer

# Step 1: Deploy existing_vpc_resources (Inspection + Management VPCs)
cd terraform/existing_vpc_resources
cp terraform.tfvars.example terraform.tfvars
# Edit:
#   enable_build_inspection_vpc   = true
#   enable_build_management_vpc   = true
#   enable_fortimanager           = true
#   enable_fortianalyzer          = true
#   enable_build_existing_subnets = false
terraform init && terraform apply

# Step 2: Configure FortiManager
# Access FortiManager GUI: https://<fmgr-ip>
# Enable VM device recognition if FMG 7.6.3+
config system global
    set fgfm-allow-vm enable
end

# Step 3: Deploy autoscale_template
cd ../autoscale_template
cp terraform.tfvars.example terraform.tfvars
# Edit: Use SAME cp and env values
#       enable_fortimanager_integration = true
#       fortimanager_ip = <from Step 1 output>
#       enable_dedicated_management_vpc = true
terraform init && terraform apply

# Step 4: Authorize devices on FortiManager
# Device Manager > Device & Groups
# Right-click unauthorized device > Authorize

Time to complete: 25-35 minutes

Minimal Deployment Workflow

Objective: Deploy FortiGate with minimal infrastructure

# Step 1: Deploy existing_vpc_resources (Inspection VPC only)
cd terraform/existing_vpc_resources
cp terraform.tfvars.example terraform.tfvars
# Edit:
#   enable_build_inspection_vpc   = true
#   enable_build_management_vpc   = false
#   enable_build_existing_subnets = false
#   inspection_access_internet_mode = "eip"  # simpler, lower cost
terraform init && terraform apply

# Step 2: Deploy autoscale_template
cd ../autoscale_template
cp terraform.tfvars.example terraform.tfvars
# Edit: Use SAME cp and env values
#       enable_tgw_attachment = false
#       access_internet_mode = "eip"
terraform init && terraform apply

# Step 3: Note GWLB endpoint IDs for spoke VPC integration
terraform output gwlb_endpoint_az1_id
terraform output gwlb_endpoint_az2_id

# Step 4: Integrate spoke VPCs
# Deploy GWLB endpoints in spoke VPCs
# Update spoke VPC route tables to point to GWLB endpoints

Time to complete: 20-25 minutes (plus spoke VPC endpoint deployment)

When to Use Each Template

existing_vpc_resources - Always Required First

The existing_vpc_resources template is required to create the Inspection VPC with proper Fortinet-Role tags. Use it when:

✅ Any new FortiGate autoscale deployment

• Creates Inspection VPC with all required subnets and tags
• Can optionally include Management VPC, TGW, and spoke VPCs
• Provides foundation for autoscale_template deployment

✅ Creating a lab or test environment

• Enable all components for complete testing environment
• Includes FortiManager/FortiAnalyzer for management testing
• Traffic generators in spoke VPCs for load testing

✅ Production deployments with new infrastructure

• Creates properly tagged VPCs for FortiGate deployment
• Can attach to existing Transit Gateway
• Separates VPC lifecycle from FortiGate lifecycle

Alternative to existing_vpc_resources:

⚠️ Manually tag existing VPCs (advanced users only)

• Apply Fortinet-Role tags to existing VPCs following the tag schema
• Ensures all required resources (subnets, route tables, IGW, etc.) are properly tagged
• Useful when you cannot create new VPCs

autoscale_template - Always Required Second

The autoscale_template deploys FortiGate into the existing Inspection VPC:

✅ All FortiGate autoscale deployments

• Discovers Inspection VPC via Fortinet-Role tags
• Deploys FortiGate ASG, GWLB, Lambda functions
• Modifies route tables to enable traffic inspection

✅ Can be redeployed independently

• Inspection VPC persists between FortiGate redeployments
• Allows FortiGate version upgrades without VPC changes
• Simplifies lifecycle management

Template Variable Coordination

When using both templates together, certain variables must match exactly for Fortinet-Role tag discovery to work:

Critical Variables for Tag Discovery

Example Coordinated Configuration

existing_vpc_resources/terraform.tfvars:

aws_region          = "us-west-2"
availability_zone_1 = "a"
availability_zone_2 = "c"
cp                  = "acme"      # Creates tags like "acme-test-inspection-vpc"
env                 = "test"
vpc_cidr_ns_inspection = "10.0.0.0/16"
vpc_cidr_management    = "10.3.0.0/16"

autoscale_template/terraform.tfvars:

aws_region          = "us-west-2"  # MUST MATCH
availability_zone_1 = "a"          # MUST MATCH
availability_zone_2 = "c"          # MUST MATCH
cp                  = "acme"       # MUST MATCH - used for tag lookup
env                 = "test"       # MUST MATCH - used for tag lookup
vpc_cidr_inspection = "10.0.0.0/16"  # Should match existing VPC CIDR
vpc_cidr_management = "10.3.0.0/16"  # Should match if using management VPC

attach_to_tgw_name = "acme-test-tgw"  # Matches cp-env naming convention

How Tag Discovery Works

When autoscale_template runs, it looks up resources like this:

# autoscale_template/vpc_inspection.tf
data "aws_vpc" "inspection" {
  filter {
    name   = "tag:Fortinet-Role"
    values = ["${var.cp}-${var.env}-inspection-vpc"]  # e.g., "acme-test-inspection-vpc"
  }
}

This is why matching cp and env values is essential.

Next Steps

Choose your deployment pattern and proceed to the appropriate template guide:

1. Lab/Test Environment: Start with existing_vpc_resources Template
2. Production Deployment: Go directly to autoscale_template
3. Need to review components?: See Solution Components
4. Need licensing guidance?: See Licensing Options

Summary

The FortiGate Autoscale Simplified Template uses a two-phase deployment approach with Fortinet-Role tag discovery:

Key Principles:

1. Run existing_vpc_resources first - Creates Inspection VPC with Fortinet-Role tags
2. Match cp and env values - Critical for tag discovery between templates
3. autoscale_template deploys into existing VPCs - Does not create VPC infrastructure

Recommended Starting Point:

• First-time users: Deploy both templates for complete lab environment
• Production deployments: Use existing_vpc_resources for new Inspection VPC, or manually tag existing VPCs
• All deployments: Ensure cp and env match between templates

existing_vpc_resources Template

Overview

The existing_vpc_resources template creates the Inspection VPC and supporting infrastructure required for the FortiGate autoscale deployment. All resources are tagged with Fortinet-Role tags that allow the autoscale_template to discover and deploy into them.

What It Creates

The template conditionally creates the following components based on boolean variables. All resources are tagged with Fortinet-Role tags for discovery by autoscale_template.

Component Overview

Total estimated cost for complete lab: ~$300-400/month

Component Details

0. Inspection VPC (Required)

Purpose: The VPC where FortiGate autoscale group will be deployed by autoscale_template

Configuration variable:

enable_build_inspection_vpc = true

What gets created:

Inspection VPC (10.0.0.0/16)
├── Public Subnet AZ1 (FortiGate login/management)
├── Public Subnet AZ2
├── GWLBE Subnet AZ1 (Gateway Load Balancer Endpoints)
├── GWLBE Subnet AZ2
├── Private Subnet AZ1 (TGW attachment)
├── Private Subnet AZ2
├── Management Subnet AZ1 (optional - dedicated management ENI)
├── Management Subnet AZ2 (optional)
├── Internet Gateway
├── NAT Gateways (optional - if nat_gw mode)
├── Route Tables (per subnet type and AZ)
└── TGW Attachment (optional - if TGW enabled)

Fortinet-Role tags applied (for autoscale_template discovery):

Example: For cp="acme" and env="test", tags would be acme-test-inspection-vpc, acme-test-inspection-public-az1, etc.

Inspection VPC Internet Mode

inspection_access_internet_mode = "nat_gw"  # or "eip"

• nat_gw: Creates NAT Gateways for FortiGate internet access (recommended for production)
• eip: FortiGates use Elastic IPs directly (simpler, lower cost)

Inspection VPC Dedicated Management ENI

inspection_enable_dedicated_management_eni = true

Creates additional management subnets within the Inspection VPC for dedicated management interfaces on FortiGate instances.

1. Management VPC (Optional)

Purpose: Centralized management infrastructure isolated from production traffic

Components:

• Dedicated VPC with public and private subnets across two Availability Zones
• Internet Gateway for external connectivity
• Security groups for management traffic
• Fortinet-Role tags for discovery by autoscale_template

Configuration variable:

enable_build_management_vpc = true

What gets created:

Management VPC (10.3.0.0/16)
├── Public Subnet AZ1 (10.3.1.0/24)
├── Public Subnet AZ2 (10.3.2.0/24)
├── Internet Gateway
└── Route Tables

Fortinet-Role tags applied (for autoscale_template discovery):

FortiManager (Optional within Management VPC)

Configuration:

enable_fortimanager = true
fortimanager_instance_type = "m5.large"
fortimanager_os_version = "7.4.5"
fortimanager_host_ip = "10"  # Results in .3.0.10

Access:

• GUI: https://<FortiManager-Public-IP>
• SSH: ssh admin@<FortiManager-Public-IP>
• Default credentials: admin / <instance-id>

Use cases:

• Testing FortiManager integration with autoscale group
• Centralized policy management demonstrations
• Device orchestration testing

FortiAnalyzer (Optional within Management VPC)

Configuration:

enable_fortianalyzer = true
fortianalyzer_instance_type = "m5.large"
fortianalyzer_os_version = "7.4.5"
fortianalyzer_host_ip = "11"  # Results in .3.0.11

Access:

• GUI: https://<FortiAnalyzer-Public-IP>
• SSH: ssh admin@<FortiAnalyzer-Public-IP>
• Default credentials: admin / <instance-id>

Use cases:

• Centralized logging for autoscale group
• Reporting and analytics demonstrations
• Log retention testing

Jump Box (Optional within Management VPC)

Configuration:

enable_jump_box = true
jump_box_instance_type = "t3.micro"

Access:

ssh -i ~/.ssh/keypair.pem ec2-user@<jump-box-public-ip>

Use cases:

• Secure access to spoke VPC instances
• Testing connectivity without FortiGate in path (via debug attachment)
• Management access to FortiGate private IPs

Management VPC TGW Attachment (Optional)

Configuration:

enable_mgmt_vpc_tgw_attachment = true

Purpose: Connects management VPC to Transit Gateway, allowing:

• Jump box access to spoke VPC Linux instances
• FortiManager/FortiAnalyzer access to FortiGate instances via TGW
• Alternative management access paths

Routing:

• Management VPC → TGW → Spoke VPCs
• Can be combined with enable_debug_tgw_attachment for bypass testing

2. Transit Gateway and Spoke VPCs (Optional)

Purpose: Simulates production multi-VPC environment for traffic generation and testing

Configuration variable:

enable_build_existing_subnets = true

What gets created:

Transit Gateway
├── East Spoke VPC (192.168.0.0/24)
│   ├── Public Subnet AZ1
│   ├── Private Subnet AZ1
│   ├── NAT Gateway (optional)
│   └── Linux Instance (optional)
│
├── West Spoke VPC (192.168.1.0/24)
│   ├── Public Subnet AZ1
│   ├── Private Subnet AZ1
│   ├── NAT Gateway (optional)
│   └── Linux Instance (optional)
│
└── TGW Route Tables
    ├── Spoke-to-Spoke (via inspection VPC)
    └── Inspection-to-Internet

Transit Gateway

Configuration:

# Created automatically when enable_build_existing_subnets = true
# Named: {cp}-{env}-tgw

Purpose:

• Central hub for VPC interconnectivity
• Enables centralized egress architecture
• Allows east-west traffic inspection

Attachments:

• East Spoke VPC
• West Spoke VPC
• Inspection VPC (created by autoscale_template)
• Management VPC (if enable_mgmt_vpc_tgw_attachment = true)
• Debug attachment (if enable_debug_tgw_attachment = true)

Spoke VPCs (East and West)

Configuration:

vpc_cidr_east = "192.168.0.0/24"
vpc_cidr_west = "192.168.1.0/24"
vpc_cidr_spoke = "192.168.0.0/16"  # Supernet

Components per spoke VPC:

• Public and private subnets
• NAT Gateway for internet egress
• Route tables for internet and TGW connectivity
• Security groups for instance access

Linux Instances (Traffic Generators)

Configuration:

enable_east_linux_instances = true
east_linux_instance_type = "t3.micro"

enable_west_linux_instances = true
west_linux_instance_type = "t3.micro"

What they provide:

• HTTP server on port 80 (for connectivity testing)
• Internet egress capability (for testing FortiGate inspection)
• East-West traffic generation between spoke VPCs

Testing with Linux instances:

# From jump box or another instance
curl http://<linux-instance-ip>
# Returns: "Hello from <hostname>"

# Generate internet egress traffic
ssh ec2-user@<linux-instance-ip>
curl http://www.google.com  # Traffic goes through FortiGate

Debug TGW Attachment (Optional)

Configuration:

enable_debug_tgw_attachment = true

Purpose: Creates a bypass attachment from Management VPC directly to Transit Gateway, allowing traffic to flow:

Jump Box → TGW → Spoke VPC Linux Instances (bypassing FortiGate inspection)

Debug path use cases:

• Validate spoke VPC connectivity independent of FortiGate inspection
• Compare latency/throughput with and without inspection
• Troubleshoot routing issues by eliminating FortiGate as variable
• Generate baseline traffic patterns for capacity planning

Configuration Scenarios

Scenario 1: Complete Lab Environment

Use case: Full-featured lab for testing all capabilities

# Inspection VPC (Required)
enable_build_inspection_vpc            = true
inspection_access_internet_mode        = "nat_gw"
inspection_enable_dedicated_management_eni = false

# Management VPC Components
enable_build_management_vpc    = true
enable_fortimanager            = true
enable_fortianalyzer           = true
enable_jump_box                = true
enable_mgmt_vpc_tgw_attachment = true

# Spoke VPC Components
enable_build_existing_subnets  = true
enable_east_linux_instances    = true
enable_west_linux_instances    = true
enable_debug_tgw_attachment    = true

What you get: Complete environment with inspection VPC (with Fortinet-Role tags), management, spoke VPCs, traffic generators, and debug path

Cost: ~$300-400/month

Best for: Training, demonstrations, comprehensive testing

Scenario 2: Inspection + Management VPC Only

Use case: Testing FortiManager/FortiAnalyzer integration without spoke VPCs

# Inspection VPC (Required)
enable_build_inspection_vpc            = true
inspection_access_internet_mode        = "eip"

# Management VPC Components
enable_build_management_vpc    = true
enable_fortimanager            = true
enable_fortianalyzer           = true
enable_jump_box                = false
enable_mgmt_vpc_tgw_attachment = false

# Spoke VPC Components
enable_build_existing_subnets  = false

What you get: Inspection VPC (with Fortinet-Role tags) and Management VPC with FortiManager and FortiAnalyzer

Cost: ~$200/month

Best for: FortiManager/FortiAnalyzer integration testing, centralized management evaluation

Scenario 3: Inspection VPC + Traffic Generation

Use case: Testing autoscale with traffic generators, no management VPC

# Inspection VPC (Required)
enable_build_inspection_vpc            = true
inspection_access_internet_mode        = "nat_gw"

# Management VPC Components
enable_build_management_vpc    = false

# Spoke VPC Components
enable_build_existing_subnets  = true
enable_east_linux_instances    = true
enable_west_linux_instances    = true
enable_debug_tgw_attachment    = false

What you get: Inspection VPC (with Fortinet-Role tags), Transit Gateway, and spoke VPCs with Linux instances

Cost: ~$100-150/month

Best for: Autoscale behavior testing, load testing, capacity planning

Scenario 4: Minimal Inspection VPC Only

Use case: Lowest cost configuration - Inspection VPC only

# Inspection VPC (Required)
enable_build_inspection_vpc            = true
inspection_access_internet_mode        = "eip"  # Lower cost than nat_gw

# Management VPC Components
enable_build_management_vpc    = false

# Spoke VPC Components
enable_build_existing_subnets  = false

What you get: Inspection VPC with Fortinet-Role tags only - minimum required for autoscale_template

Cost: ~$30-50/month (VPC infrastructure only)

Best for: Minimal FortiGate testing, cost-sensitive environments, integration with existing TGW/spoke VPCs

Step-by-Step Deployment

Prerequisites

• AWS account with appropriate permissions
• Terraform 1.0 or later installed
• AWS CLI configured with credentials
• Git installed
• SSH keypair created in target AWS region

Step 1: Clone the Repository

Clone the repository containing both templates:

git clone https://github.com/FortinetCloudCSE/Autoscale-Simplified-Template.git
cd Autoscale-Simplified-Template/terraform/existing_vpc_resources

Step 2: Create terraform.tfvars

Copy the example file and customize:

cp terraform.tfvars.example terraform.tfvars

Step 3: Configure Core Variables

Region and Availability Zones

aws_region         = "us-west-2"
availability_zone_1 = "a"
availability_zone_2 = "c"

aws ec2 describe-availability-zones --region us-west-2

Customer Prefix and Environment

These values are prepended to all resources for identification:

cp  = "acme"    # Customer prefix
env = "test"    # Environment: prod, test, dev

Result: Resources named like acme-test-management-vpc, acme-test-tgw, etc.

Step 4: Configure Component Flags

Inspection VPC (Required)

The Inspection VPC is required and must be enabled. This creates the VPC where FortiGate autoscale group will be deployed.

enable_build_inspection_vpc            = true
inspection_access_internet_mode        = "nat_gw"  # or "eip"
inspection_enable_dedicated_management_eni = false  # or true for dedicated mgmt ENI

Management VPC (Optional)

enable_build_management_vpc = true

Spoke VPCs and Transit Gateway (Optional)

enable_build_existing_subnets = true

Step 5: Configure Optional Components

FortiManager and FortiAnalyzer

enable_fortimanager  = true
fortimanager_instance_type = "m5.large"
fortimanager_os_version = "7.4.5"
fortimanager_host_ip = "10"  # .3.0.10 within management VPC CIDR

enable_fortianalyzer = true
fortianalyzer_instance_type = "m5.large"
fortianalyzer_os_version = "7.4.5"
fortianalyzer_host_ip = "11"  # .3.0.11 within management VPC CIDR

Management VPC Transit Gateway Attachment

enable_mgmt_vpc_tgw_attachment = true

This allows jump box and management instances to reach spoke VPC Linux instances for testing.

Linux Traffic Generators

enable_jump_box = true
jump_box_instance_type = "t3.micro"

enable_east_linux_instances = true
east_linux_instance_type = "t3.micro"

enable_west_linux_instances = true
west_linux_instance_type = "t3.micro"

Debug TGW Attachment

enable_debug_tgw_attachment = true

Enables bypass path for connectivity testing without FortiGate inspection.

Step 6: Configure Network CIDRs

vpc_cidr_management = "10.3.0.0/16"
vpc_cidr_east       = "192.168.0.0/24"
vpc_cidr_west       = "192.168.1.0/24"
vpc_cidr_spoke      = "192.168.0.0/16"  # Supernet for all spoke VPCs

Step 7: Configure Security Variables

keypair = "my-aws-keypair"  # Must exist in target region
my_ip   = "203.0.113.10/32" # Your public IP for SSH access

Step 8: Deploy the Template

Initialize Terraform:

terraform init

Review the execution plan:

terraform plan

Expected output will show resources to be created based on enabled flags.

Deploy the infrastructure:

terraform apply

Type yes when prompted to confirm.

Expected deployment time: 10-15 minutes

Deployment progress:

Apply complete! Resources: 47 added, 0 changed, 0 destroyed.

Outputs:

east_linux_instance_ip = "192.168.0.50"
fortianalyzer_public_ip = "52.10.20.30"
fortimanager_public_ip = "52.10.20.40"
jump_box_public_ip = "52.10.20.50"
management_vpc_id = "vpc-0123456789abcdef0"
tgw_id = "tgw-0123456789abcdef0"
tgw_name = "acme-test-tgw"
west_linux_instance_ip = "192.168.1.50"

Step 9: Verify Deployment

Verify Management VPC

aws ec2 describe-vpcs --filters "Name=tag:Name,Values=acme-test-management-vpc"

Expected: VPC ID and CIDR information

Access FortiManager (if enabled)

# Get public IP from outputs
terraform output fortimanager_public_ip

# Access GUI
open https://<FortiManager-Public-IP>

# Or SSH
ssh admin@<FortiManager-Public-IP>
# Default password: <instance-id>

First-time FortiManager setup:

1. Login with admin / instance-id
2. Change password when prompted
3. Complete initial setup wizard
4. Navigate to Device Manager > Device & Groups

Enable VM device recognition (FortiManager 7.6.3+):

config system global
    set fgfm-allow-vm enable
end

Access FortiAnalyzer (if enabled)

# Get public IP from outputs
terraform output fortianalyzer_public_ip

# Access GUI
open https://<FortiAnalyzer-Public-IP>

# Or SSH  
ssh admin@<FortiAnalyzer-Public-IP>

Verify Transit Gateway (if enabled)

aws ec2 describe-transit-gateways --filters "Name=tag:Name,Values=acme-test-tgw"

Expected: Transit Gateway in “available” state

Test Linux Instances (if enabled)

# Get instance IPs from outputs
terraform output east_linux_instance_ip
terraform output west_linux_instance_ip

# Test HTTP connectivity (if jump box enabled)
ssh -i ~/.ssh/keypair.pem ec2-user@<jump-box-ip>
curl http://<east-linux-ip>
# Expected: "Hello from ip-192-168-0-50"

Step 10: Save Outputs for autoscale_template

Save key outputs for use in autoscale_template configuration:

# Save all outputs
terraform output > ../outputs.txt

# Or save specific values
echo "tgw_name: $(terraform output -raw tgw_name)" >> ../autoscale_template/terraform.tfvars
echo "fortimanager_ip: $(terraform output -raw fortimanager_private_ip)" >> ../autoscale_template/terraform.tfvars

Outputs Reference

The template provides these outputs. Note that autoscale_template discovers resources via Fortinet-Role tags rather than using output values directly.

Inspection VPC Outputs

Management and Supporting Infrastructure Outputs

Post-Deployment Configuration

Configure FortiManager for Integration

If you enabled FortiManager and plan to integrate with autoscale group:

1. Access FortiManager GUI: https://<FortiManager-Public-IP>

2. Change default password:

   • Login with admin / <instance-id>
   • Follow password change prompts

3. Enable VM device recognition (7.6.3+):

   config system global
       set fgfm-allow-vm enable
   end

4. Create ADOM for autoscale group (optional):

   • Device Manager > ADOM
   • Create ADOM for organizing autoscale FortiGates

5. Note FortiManager details for autoscale_template:

   • Private IP: From outputs
   • Serial number: Get from CLI: get system status

Configure FortiAnalyzer for Logging

If you enabled FortiAnalyzer:

1. Access FortiAnalyzer GUI: https://<FortiAnalyzer-Public-IP>

2. Change default password

3. Configure log settings:

   • System Settings > Storage
   • Configure log retention policies
   • Enable features needed for testing

4. Note FortiAnalyzer private IP for FortiGate syslog configuration

Important Notes

Resource Lifecycle Considerations

Cost Optimization Tips

enable_fortimanager = false    # Save $73/month
enable_fortianalyzer = false   # Save $73/month
jump_box_instance_type = "t3.micro"  # Use smallest size
east_linux_instance_type = "t3.micro"
west_linux_instance_type = "t3.micro"

State File Management

Store Terraform state securely:

# backend.tf (optional - recommended for teams)
terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "existing-vpc-resources/terraform.tfstate"
    region = "us-west-2"
    encrypt = true
    dynamodb_table = "terraform-locks"
  }
}

Troubleshooting

Issue: Terraform Fails with “Resource Already Exists”

Symptoms:

Error: Error creating VPC: VpcLimitExceeded

Solutions:

• Check VPC limits in your AWS account
• Clean up unused VPCs
• Request limit increase via AWS Support

Issue: Cannot Access FortiManager/FortiAnalyzer

Symptoms:

• Timeout when accessing GUI
• SSH connection refused

Solutions:

1. Verify security groups allow your IP:

   aws ec2 describe-security-groups --group-ids <sg-id>

2. Check instance is running:

   aws ec2 describe-instances --filters "Name=tag:Name,Values=*fortimanager*"

3. Verify my_ip variable matches your current public IP:

   curl ifconfig.me

4. Check instance system log for boot issues:

   aws ec2 get-console-output --instance-id <instance-id>

Issue: Transit Gateway Attachment Pending

Symptoms:

• TGW attachment stuck in “pending” state
• Spoke VPCs can’t communicate

Solutions:

1. Wait 5-10 minutes for attachment to complete
2. Check TGW route tables are configured
3. Verify no CIDR overlaps between VPCs
4. Check TGW attachment state:

   aws ec2 describe-transit-gateway-attachments

Issue: Linux Instances Not Reachable

Symptoms:

• Cannot curl or SSH to Linux instances

Solutions:

1. Verify you’re accessing from jump box (if not public)
2. Check security groups allow port 80 and 22
3. Verify NAT Gateway is functioning for internet access
4. Check route tables in spoke VPCs

Issue: High Costs After Deployment

Symptoms:

• AWS bill higher than expected

Solutions:

1. Check what’s running:

   aws ec2 describe-instances --filters "Name=instance-state-name,Values=running"

2. Identify expensive resources:

   # Use AWS Cost Explorer in AWS Console
   # Filter by resource tags: cp and env

3. Shut down unused components:

   terraform destroy -target=module.fortimanager
   terraform destroy -target=module.fortianalyzer

4. Or destroy entire deployment:

   terraform destroy

Cleanup

Destroying Resources

To destroy the existing_vpc_resources infrastructure:

cd terraform/existing_vpc_resources
terraform destroy

Type yes when prompted.

# Step 1: Destroy autoscale_template
cd terraform/autoscale_template
terraform destroy

# Step 2: Destroy existing_vpc_resources  
cd ../existing_vpc_resources
terraform destroy

Selective Cleanup

To destroy only specific components:

# Destroy only FortiManager
terraform destroy -target=module.fortimanager

# Destroy only spoke VPCs and TGW
terraform destroy -target=module.transit_gateway
terraform destroy -target=module.spoke_vpcs

# Destroy only management VPC
terraform destroy -target=module.management_vpc

Verify Complete Cleanup

After destroying, verify no resources remain:

# Check VPCs
aws ec2 describe-vpcs --filters "Name=tag:cp,Values=acme" "Name=tag:env,Values=test"

# Check Transit Gateways
aws ec2 describe-transit-gateways --filters "Name=tag:cp,Values=acme"

# Check running instances
aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" "Name=tag:cp,Values=acme"

Next Steps

After deploying existing_vpc_resources, proceed to deploy the autoscale_template to create the FortiGate autoscale group and inspection VPC.

Key information to carry forward:

• Transit Gateway name (from outputs)
• FortiManager private IP (if enabled)
• FortiAnalyzer private IP (if enabled)
• Same cp and env values

Recommended next reading:

• autoscale_template Deployment Guide
• FortiManager Integration Configuration
• Licensing Options

autoscale_template

Overview

The autoscale_template deploys the FortiGate autoscale group into an existing Inspection VPC. It discovers VPC resources using Fortinet-Role tags created by the existing_vpc_resources template.

What It Creates

The autoscale_template discovers the existing Inspection VPC via Fortinet-Role tags and deploys FortiGate autoscale components into it:

Resource Discovery (via Fortinet-Role Tags)

Components Created

Optional Components

Architecture Patterns

The autoscale_template supports multiple deployment patterns:

Pattern 1: Centralized Architecture with TGW

Configuration:

enable_tgw_attachment = true
attach_to_tgw_name = "production-tgw"

Traffic flow:

Spoke VPCs → TGW → Inspection VPC → FortiGate → GWLB → Internet

Use cases:

• Production centralized egress
• Multi-VPC environments
• East-west traffic inspection

Pattern 2: Distributed Architecture (No TGW)

Configuration:

enable_tgw_attachment = false

Traffic flow:

Spoke VPC → GWLB Endpoint → FortiGate → Internet Gateway

Use cases:

• Distributed security architecture
• Per-VPC inspection requirements
• Bump-in-the-wire deployments

Pattern 3: Hybrid with Management VPC

Configuration:

enable_tgw_attachment = true
enable_dedicated_management_vpc = true
enable_fortimanager_integration = true

Traffic flow:

Data: Spoke VPCs → TGW → FortiGate → Internet
Management: FortiGate → Management VPC → FortiManager

Use cases:

• Enterprise deployments
• Centralized management requirements
• Compliance-driven architectures

Integration Modes

Fortinet-Role Tag Discovery

The autoscale_template discovers all Inspection VPC resources using Fortinet-Role tags. This is how it finds the VPC, subnets, route tables, and other resources created by existing_vpc_resources.

How discovery works:

# autoscale_template looks up resources like this:
data "aws_vpc" "inspection" {
  filter {
    name   = "tag:Fortinet-Role"
    values = ["${var.cp}-${var.env}-inspection-vpc"]
  }
}

data "aws_subnet" "inspection_public_az1" {
  filter {
    name   = "tag:Fortinet-Role"
    values = ["${var.cp}-${var.env}-inspection-public-az1"]
  }
}

Integration with existing_vpc_resources

When deploying after existing_vpc_resources:

Required variable coordination:

# MUST MATCH existing_vpc_resources values (for Fortinet-Role tag discovery)
aws_region          = "us-west-2"
availability_zone_1 = "a"
availability_zone_2 = "c"
cp                  = "acme"      # MUST MATCH - used for tag lookup
env                 = "test"      # MUST MATCH - used for tag lookup

# Connect to created TGW (if enabled in existing_vpc_resources)
enable_tgw_attachment = true
attach_to_tgw_name    = "acme-test-tgw"  # From existing_vpc_resources output

# Connect to management VPC (if created in existing_vpc_resources)
enable_dedicated_management_vpc = true
# Management VPC also discovered via Fortinet-Role tags

# FortiManager integration (if enabled in existing_vpc_resources)
enable_fortimanager_integration = true
fortimanager_ip = "10.3.0.10"  # From existing_vpc_resources output
fortimanager_sn = "FMGVM0000000001"

Integration with Manually Tagged VPCs

If you have existing VPCs that you want to use instead of creating new ones with existing_vpc_resources, you must apply Fortinet-Role tags to all required resources:

Required tags (see Templates Overview for complete list):

• VPC: {cp}-{env}-inspection-vpc
• Subnets: {cp}-{env}-inspection-{public|gwlbe|private}-az{1|2}
• Route Tables: {cp}-{env}-inspection-{type}-rt-az{1|2}
• IGW: {cp}-{env}-inspection-igw

Configuration:

# Match your tag prefix
cp  = "acme"
env = "prod"

# Connect to existing production TGW
enable_tgw_attachment = true
attach_to_tgw_name = "production-tgw"  # Your existing TGW

# Use existing management infrastructure
enable_fortimanager_integration = true
fortimanager_ip = "10.100.50.10"  # Your existing FortiManager
fortimanager_sn = "FMGVM1234567890"

Step-by-Step Deployment

Prerequisites

• ✅ AWS account with appropriate permissions
• ✅ Terraform 1.0 or later installed
• ✅ AWS CLI configured with credentials
• ✅ SSH keypair created in target AWS region
• ✅ FortiGate licenses (if using BYOL) or FortiFlex account (if using FortiFlex)
• ✅ existing_vpc_resources deployed (creates Inspection VPC with Fortinet-Role tags)
• ✅ OR existing VPCs with Fortinet-Role tags applied manually

Step 1: Navigate to Template Directory

cd Autoscale-Simplified-Template/terraform/autoscale_template

Step 2: Create terraform.tfvars

cp terraform.tfvars.example terraform.tfvars

Step 3: Configure Core Variables

Region and Availability Zones

aws_region         = "us-west-2"
availability_zone_1 = "a"
availability_zone_2 = "c"

Customer Prefix and Environment

cp  = "acme"    # Customer prefix - MUST MATCH existing_vpc_resources
env = "test"    # Environment - MUST MATCH existing_vpc_resources

Step 4: Configure Security Variables

keypair                 = "my-aws-keypair"  # Must exist in target region
my_ip                   = "203.0.113.10/32" # Your public IP for management access
fortigate_asg_password  = "SecurePassword123!"  # Admin password for FortiGates

Step 5: Configure Transit Gateway Integration

To connect to Transit Gateway:

enable_tgw_attachment = true

Specify TGW name:

# If using existing_vpc_resources template
attach_to_tgw_name = "acme-test-tgw"  # Matches existing_vpc_resources output

# If using existing production TGW
attach_to_tgw_name = "production-tgw"  # Your production TGW name

aws ec2 describe-transit-gateways \
  --query 'TransitGateways[*].[Tags[?Key==`Name`].Value | [0], TransitGatewayId]' \
  --output table

To skip TGW attachment (distributed architecture):

enable_tgw_attachment = false

East-West Inspection (requires TGW attachment):

enable_east_west_inspection = true  # Routes spoke-to-spoke traffic through FortiGate

Step 6: Configure Architecture Options

Firewall Mode

firewall_policy_mode = "2-arm"  # or "1-arm"

Recommendations:

• 2-arm: Recommended for most deployments (better throughput)
• 1-arm: Use when simplified routing is required

See Firewall Architecture for detailed comparison.

Internet Egress Mode

access_internet_mode = "nat_gw"  # or "eip"

Recommendations:

• nat_gw: Production deployments (higher availability)
• eip: Lower cost, simpler architecture

See Internet Egress for detailed comparison.

Step 7: Configure Management Options

Dedicated Management ENI

enable_dedicated_management_eni = true

Separates management traffic from data plane. Recommended for production.

Dedicated Management VPC

enable_dedicated_management_vpc = true

# If using existing_vpc_resources with default tags:
dedicated_management_vpc_tag = "acme-test-management-vpc"
dedicated_management_public_az1_subnet_tag = "acme-test-management-public-az1-subnet"
dedicated_management_public_az2_subnet_tag = "acme-test-management-public-az2-subnet"

# If using existing management VPC with custom tags:
dedicated_management_vpc_tag = "my-custom-mgmt-vpc-tag"
dedicated_management_public_az1_subnet_tag = "my-custom-mgmt-az1-tag"
dedicated_management_public_az2_subnet_tag = "my-custom-mgmt-az2-tag"

See Management Isolation for options and recommendations.

Step 8: Configure Licensing

The template supports three licensing models. Choose one or combine them for hybrid licensing.

Option 1: BYOL (Bring Your Own License)

asg_license_directory = "asg_license"  # Directory containing .lic files

Prerequisites:

1. Create the license directory:

   mkdir asg_license

2. Place license files in the directory:

   terraform/autoscale_template/
   ├── terraform.tfvars
   ├── asg_license/
   │   ├── FGVM01-001.lic
   │   ├── FGVM01-002.lic
   │   ├── FGVM01-003.lic
   │   └── FGVM01-004.lic

3. Ensure you have at least as many licenses as asg_byol_asg_max_size