Annotation Reference

The UI dynamically generates configuration forms by reading @ui- annotations in terraform.tfvars.example files. The scaffold generator auto-creates these annotations from variables.tf metadata; users enrich them for better UI presentation.

Annotation Format

Add @ui- annotation comments directly above each variable assignment:

# @ui-label AWS Region
# @ui-description Select the AWS region for deployment
# @ui-type select
# @ui-options us-east-1|us-west-2|eu-west-1
# @ui-default us-west-2
# @ui-group Region Configuration
aws_region = "us-west-2"

Supported Tags

Core Tags

Resource Discovery Tags

Used with @ui-source aws-fortinet-resource for tag-based resource lookup:

Mutual Exclusivity Tags

Input Types

text

Single-line text input.

# @ui-label Customer Prefix
# @ui-type text
# @ui-required true
cp = ""

password

Masked text input for sensitive values.

# @ui-label Admin Password
# @ui-type password
# @ui-required true
admin_password = ""

number

Numeric input.

# @ui-label Desired Capacity
# @ui-type number
# @ui-default 2
asg_desired_capacity = 2

checkbox

Boolean toggle.

# @ui-label Enable FortiManager
# @ui-type checkbox
# @ui-default false
enable_fortimanager = false

select

Dropdown with predefined options.

# @ui-label Instance Type
# @ui-type select
# @ui-options c5n.xlarge|c5n.2xlarge|c5n.4xlarge
# @ui-default c5n.xlarge
instance_type = "c5n.xlarge"

list

Multiple values as a list.

# @ui-label Management CIDRs
# @ui-type list
# @ui-description IP ranges allowed to access management interfaces
management_cidr_sg = ["0.0.0.0/0"]

Grouping Fields

Use @ui-group to organize related fields together:

# @ui-label AWS Region
# @ui-group Region Configuration
aws_region = "us-west-2"

# @ui-label Availability Zone 1
# @ui-group Region Configuration
availability_zone_1 = "a"

# @ui-label Enable FortiManager
# @ui-group Optional Components
enable_fortimanager = false

Fields with the same @ui-group value appear together in the UI.

Conditional Fields

Use @ui-show-if to show fields only when a condition is met:

# @ui-label Enable FortiManager
# @ui-type checkbox
enable_fortimanager = false

# @ui-label FortiManager IP
# @ui-type text
# @ui-show-if enable_fortimanager=true
fortimanager_ip = ""

# @ui-label FortiManager Password
# @ui-type password
# @ui-show-if enable_fortimanager=true
fortimanager_password = ""

The FortiManager IP and password fields only appear when the checkbox is enabled.

Dynamic Data Sources

Use @ui-source to populate dropdowns from live cloud APIs:

# @ui-label AWS Region
# @ui-type select
# @ui-source aws-regions
aws_region = ""

# @ui-label Key Pair
# @ui-type select
# @ui-source aws-keypairs
keypair = ""

Fortinet-Role Tag Discovery

For fields that reference resources created by other templates:

# @ui-type select
# @ui-source aws-fortinet-resource
# @ui-tag-key Fortinet-Role
# @ui-tag-pattern {cp}-{env}-inspection-vpc
# @ui-tag-resource-type vpc
inspection_vpc = ""

Supported @ui-tag-resource-type values: vpc, subnet, igw, tgw, tgw-attachment, tgw-rtb

Placeholder tokens {cp}, {env}, {region}, {az1}, {az2} are replaced with the corresponding field values from the current form.

Scaffold Generation

When you register a template, the scaffold generator auto-creates annotations from variables.tf:

Variable names are converted to labels (e.g., enable_jump_box becomes Enable Jump Box). HCL description fields become @ui-description. Validation rules with condition expressions generate @ui-options.

Existing annotations in terraform.tfvars.example are preserved and merged with the generated scaffold.

Registering Templates

How to add Terraform templates to the UI via the template registry.

Overview

The UI uses a template registry to manage templates. Instead of placing templates in a local directory, you register a git repository URL and the backend clones it, parses variables.tf, and generates a scaffold tfvars.ui file with UI annotations.

Step 1: Prepare Your Template

Your template repository must contain at minimum:

my-template/
├── main.tf                      # Required - Terraform configuration
├── variables.tf                 # Required - Variable definitions (parsed for scaffold)
├── outputs.tf                   # Optional
└── terraform.tfvars.example     # Recommended - Pre-annotated defaults

The scaffold generator reads variables.tf for variable names, types, defaults, and descriptions. If terraform.tfvars.example exists, its @ui- annotations are merged into the scaffold.

Step 2: Register via UI

1. Click the "+" button next to the template dropdown
2. Fill in the registration form:
   • Name — Display name (e.g., “AWS Autoscale Template”)
   • Repository URL — Git clone URL (e.g., https://github.com/org/repo.git)
   • Branch — Branch to track (default: main)
   • Path in Repo — Subdirectory containing the template (e.g., terraform/aws/autoscale_template)
3. Click Register

The backend will:

1. Clone the repository
2. Verify the path exists
3. Scan all files and store SHA-256 hashes
4. Auto-generate a scaffold tfvars.ui

Register via API

curl -X POST http://127.0.0.1:8000/api/templates/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "AWS Autoscale Template",
    "repo_url": "https://github.com/FortinetCloudCSE/fortinet-ui-terraform.git",
    "branch": "main",
    "repo_path": "terraform/aws/autoscale_template"
  }'

Step 3: Review and Enrich the Scaffold

After registration, the scaffold tfvars.ui is auto-generated with basic annotations. To improve the UI:

1. Click Export to download the tfvars.ui file
2. Edit annotations to add:
   • Better @ui-label values
   • @ui-description help text
   • @ui-group for organizing fields
   • @ui-show-if for conditional visibility
   • @ui-source for dynamic dropdowns (e.g., aws-regions, aws-keypairs)
   • @ui-options for static select lists
3. Click Import to upload the enriched file

Export/Import via API

# Export scaffold
curl http://127.0.0.1:8000/api/templates/1/export

# Import enriched tfvars.ui
curl -X POST http://127.0.0.1:8000/api/templates/1/import \
  -H "Content-Type: application/json" \
  -d '{"content": "# @ui-label AWS Region\n# @ui-type select\naws_region = \"us-west-2\"\n"}'

Step 4: Verify in UI

1. Select your template from the dropdown
2. Verify all fields render correctly
3. Test conditional fields (@ui-show-if)
4. Test dynamic dropdowns (@ui-source)
5. Check drift status indicator (should show “Clean”)

Drift Detection

After registration, the backend tracks file hashes. When the upstream repository changes:

• Warning drift (non-critical .tf files changed): Yellow banner, does not block plan/apply
• Hard-stop drift (critical files like variables.tf, terraform.tfvars.example): Red indicator, blocks plan/apply until resolved

To resolve drift:

1. Click the drift indicator to open the resolution UI
2. Review changed files (side-by-side diff)
3. Re-scaffold if needed (pulls latest variables.tf changes)
4. Save & re-hash to clear the drift

Updating a Template

When the upstream repo changes:

# Update repo URL or branch
curl -X PUT http://127.0.0.1:8000/api/templates/1 \
  -H "Content-Type: application/json" \
  -d '{"branch": "v2.0"}'

The backend re-clones and re-hashes. If critical files changed, drift will be detected.

Deleting a Template

curl -X DELETE http://127.0.0.1:8000/api/templates/1

This removes the template record, file hashes, and cloned directory.

Best Practices

1. Write good variables.tf descriptions — The scaffold generator uses them for @ui-description
2. Use validation rules — HCL validation blocks with condition expressions generate @ui-options automatically
3. Pre-annotate terraform.tfvars.example — Existing @ui- annotations are preserved during scaffold generation
4. Group related fields — Use @ui-group to organize the form
5. Use @ui-show-if for conditional fields — Keeps the form clean
6. Mark sensitive fields as @ui-type password — Masks input appropriately
7. Set sensible @ui-default values — Reduces required user input
8. Track a stable branch — Avoid tracking main if it changes frequently (causes frequent drift)

Backend APIs

The backend provides three API routers for template management, configuration, and terraform execution.

API Structure

app/api/
├── templates.py           # Template registry CRUD
├── tfvars_ui.py           # Scaffold, export/import, drift detection
├── template_terraform.py  # Plan/apply/destroy against cloned repos
├── terraform.py           # Shared utilities (run_command_stream)
├── aws.py                 # AWS resource discovery
└── gcp.py                 # GCP resource discovery

Template Registry (/api/templates/)

CRUD operations for registered templates.

Register a Template

curl -X POST http://127.0.0.1:8000/api/templates/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "My Template",
    "repo_url": "https://github.com/org/repo.git",
    "branch": "main",
    "repo_path": "terraform/aws/my_template"
  }'

Response: Template object with id, name, repo_url, branch, repo_path, created_date, updated_date.

tfvars.ui Management (/api/templates/{id}/...)

Scaffold generation, export/import, and drift detection.

Scaffold Response

{
  "content": "# @ui-label AWS Region\n# @ui-type select\naws_region = \"us-west-2\"\n...",
  "variable_count": 42
}

Drift Response

{
  "status": "warning",
  "entries": [
    {"filename": "main.tf", "type": "changed", "hard_stop": false},
    {"filename": "variables.tf", "type": "changed", "hard_stop": true}
  ]
}

Drift statuses: clean (no changes), warning (non-critical files changed), hard_stop (critical files changed — blocks terraform execution).

Hard-stop files: *.tf, terraform.tfvars.example, terraform.tfvars, *.cfg, *.tpl, *.tftpl

Terraform Execution (/api/templates/{id}/terraform/...)

Run terraform commands against cloned template directories with drift guards.

All plan/apply/destroy endpoints:

• Perform a drift check before execution
• Return HTTP 409 Conflict if hard-stop drift is detected
• Stream output in real-time (text/plain)
• Inject cloud credentials (AWS env vars, GCP GOOGLE_CREDENTIALS)

Write terraform.tfvars

curl -X POST http://127.0.0.1:8000/api/templates/1/terraform/write-tfvars \
  -H "Content-Type: application/json" \
  -d '{"content": "aws_region = \"us-west-2\"\ncp = \"acme\"\n..."}'

Adding a New API Endpoint

Create a new router file in app/api/:

from fastapi import APIRouter, HTTPException
from pydantic import BaseModel

router = APIRouter(prefix="/api/my-feature", tags=["my-feature"])

class MyRequest(BaseModel):
    name: str
    enabled: bool = False

@router.post("/action")
async def perform_action(request: MyRequest):
    if not request.name:
        raise HTTPException(status_code=400, detail="Name required")
    return {"success": True, "message": f"Action on {request.name}"}

Register in app/main.py:

from app.api import my_feature
app.include_router(my_feature.router)

Parsers & Services

The backend uses a service layer for parsing, hashing, scaffolding, and drift detection.

Service Layer

app/services/
├── __init__.py                 # Central exports
├── hcl_parser.py               # Parse variables.tf
├── tfvars_example_parser.py    # Parse terraform.tfvars.example annotations
├── scaffold_generator.py       # Generate tfvars.ui from parsed data
├── git_service.py              # Clone/pull git repositories
├── file_hash_service.py        # SHA-256 file scanning
└── drift_service.py            # Drift detection between stored and current hashes

HCL Parser (hcl_parser.py)

Parses variables.tf to extract variable definitions.

from app.services import parse_variables, HCLVariable

variables: list[HCLVariable] = parse_variables(content)

Each HCLVariable contains:

• name — Variable name
• type — HCL type string (e.g., string, number, bool, list(string))
• description — Variable description
• default — Default value (if any)
• validation — Validation rules (condition + error_message)

Terraform.tfvars.example Parser (tfvars_example_parser.py)

Parses terraform.tfvars.example files to extract annotations and variable assignments.

from app.services import parse_tfvars_example, TfvarsEntry

entries: list[TfvarsEntry] = parse_tfvars_example(content)

Each TfvarsEntry contains:

• name — Variable name
• value — Assigned value (string)
• hcl_type — Inferred type
• comments — Plain comments above the variable
• annotations — Dict of @ui- annotations (e.g., {"ui-label": "AWS Region", "ui-type": "select"})
• group — Group name from @ui-group

Scaffold Generator (scaffold_generator.py)

Merges HCL variable definitions with existing annotations to produce a tfvars.ui file.

from app.services import generate_scaffold

content: str = generate_scaffold(variables, example_entries)

The generator:

1. Auto-infers @ui-type from HCL type (string → text, bool → checkbox, etc.)
2. Converts variable names to labels (enable_jump_box → Enable Jump Box)
3. Extracts @ui-options from HCL validation rules
4. Preserves existing @ui- annotations from terraform.tfvars.example
5. Groups variables by common prefix when @ui-group is present in example

Git Service (git_service.py)

Manages cloned template repositories.

from app.services import GitService

git = GitService(clone_dir=Path("data/clones"))

# Clone or update a repository
clone_path = await git.clone_or_pull("https://github.com/org/repo.git", branch="main")

# Get template subdirectory within clone
template_dir = git.get_template_dir("https://github.com/org/repo.git", "terraform/aws/template")

# Clean up
removed = await git.cleanup_clone("https://github.com/org/repo.git")
count = await git.cleanup_stale(max_age_days=30)

Clone directories are named by first 12 chars of SHA-256 hash of the repo URL.

File Hash Service (file_hash_service.py)

Scans directories and computes SHA-256 hashes for drift detection.

from app.services import FileHashService, FileHashEntry

service = FileHashService()

# Scan a directory
entries: list[FileHashEntry] = service.scan_directory(template_dir)

Each FileHashEntry contains:

• filename — Relative file path
• hash — SHA-256 hex digest
• hard_stop — Whether changes to this file block terraform execution

Hard-stop file patterns: *.tf, *.cfg, *.tpl, *.tftpl, terraform.tfvars, terraform.tfvars.example

Drift Service (drift_service.py)

Compares stored file hashes against current filesystem state.

from app.services import DriftService, DriftStatus, DriftType

drift = DriftService(file_hash_service=FileHashService())
report = drift.compare(stored_hashes, current_entries)

# report.status: DriftStatus.CLEAN | .WARNING | .HARD_STOP
# report.entries: list[DriftEntry] with filename, drift_type, hard_stop, old_hash, new_hash

Drift types:

• CHANGED — File exists but hash differs
• ADDED — New file appeared
• REMOVED — File was deleted

Status logic:

• CLEAN — No drift entries
• WARNING — Drift entries exist but none are hard-stop
• HARD_STOP — At least one hard-stop file changed

Adding a New Annotation Type

1. Update tfvars_example_parser.py to extract the new annotation
2. Update scaffold_generator.py to emit it during scaffold generation
3. Update the frontend FormField.jsx to handle the new annotation
4. Add tests in tests/test_tfvars_example_parser.py

Cloud Provider APIs

Integrating AWS, Azure, and GCP APIs for dynamic dropdowns.

AWS Provider Integration

Location: backend/providers/aws.py

The AWS provider uses boto3 to query AWS resources for dynamic dropdowns.

Adding a New AWS API

Example: Adding VPC discovery:

import boto3

def get_vpcs(region: str, credentials: dict) -> List[dict]:
    """Get VPCs in a region."""
    ec2 = boto3.client(
        'ec2',
        region_name=region,
        aws_access_key_id=credentials.get('access_key'),
        aws_secret_access_key=credentials.get('secret_key'),
        aws_session_token=credentials.get('session_token')
    )

    response = ec2.describe_vpcs()

    return [
        {
            "id": vpc['VpcId'],
            "cidr": vpc['CidrBlock'],
            "name": get_tag_value(vpc.get('Tags', []), 'Name')
        }
        for vpc in response['Vpcs']
    ]

Exposing via API Endpoint

@router.get("/api/aws/vpcs")
async def list_vpcs(region: str):
    """List VPCs in the specified region."""
    credentials = get_current_credentials()
    if not credentials:
        raise HTTPException(status_code=401, detail="AWS credentials not configured")

    vpcs = get_vpcs(region, credentials)
    return {"vpcs": vpcs}

Adding a New Cloud Provider

To add support for Azure or GCP:

1. Create Provider Module

backend/providers/azure.py:

from azure.identity import DefaultAzureCredential
from azure.mgmt.compute import ComputeManagementClient

def get_regions() -> List[dict]:
    """Get available Azure regions."""
    # Implementation

def get_resource_groups(subscription_id: str) -> List[dict]:
    """Get resource groups."""
    # Implementation

2. Add API Routes

In main.py:

from providers import azure

@router.get("/api/azure/regions")
async def list_azure_regions():
    return {"regions": azure.get_regions()}

@router.get("/api/azure/resource-groups")
async def list_resource_groups(subscription_id: str):
    return {"resource_groups": azure.get_resource_groups(subscription_id)}

3. Update Frontend

Update frontend to use new endpoints for Azure templates.

Frontend Development

React components and API client development.

Component Structure

frontend/src/
├── components/
│   ├── TerraformConfig.jsx       # Main UI: template selector, form, build controls
│   ├── TemplateRegistration.jsx  # Modal: register new template from git repo
│   ├── DriftResolution.jsx       # Modal: side-by-side drift resolution
│   └── FormField.jsx             # Individual field renderer (text, select, etc.)
├── services/
│   └── api.js                    # Backend API client
└── App.jsx

Key Components

TerraformConfig.jsx

The main UI component. Manages:

• Template selector — DB-driven dropdown populated from /api/templates/
• Drift indicators — Badge next to selector showing Clean/Warning/Hard Stop
• Warning banner — Non-blocking yellow banner for warning-level drift
• Template metadata — Repo URL, branch, last updated for selected template
• Form rendering — Dynamically generated from template schema
• Build controls — Plan/apply/destroy with streaming output

TemplateRegistration.jsx

Two-step modal workflow:

1. Registration form — Name, repo URL, branch, path in repo
2. Scaffold review — Shows generated tfvars.ui with Export/Import buttons

DriftResolution.jsx

Side-by-side modal for resolving hard-stop drift:

• Left panel — List of changed files with type icons (A=Added, M=Modified, D=Removed)
• Right panel — Inline tfvars.ui editor with Re-scaffold button
• Save & Re-hash — Persists changes and clears drift

API Client

Location: frontend/src/services/api.js

Template Registry Methods

import { api } from './services/api';

// List registered templates
const templates = await api.templates.list();

// Register a new template
const template = await api.templates.create({
  name: "My Template",
  repo_url: "https://github.com/org/repo.git",
  branch: "main",
  repo_path: "terraform/aws/my_template"
});

// Generate scaffold
const scaffold = await api.templates.scaffold(template.id);

// Export/import tfvars.ui
const exported = await api.templates.export(template.id);
await api.templates.import(template.id, enrichedContent);

// Check drift
const drift = await api.templates.getDrift(template.id);

// Delete
await api.templates.delete(template.id);

Cloud Provider Methods

// AWS
const regions = await api.aws.getRegions();
const azs = await api.aws.getAvailabilityZones(region);
const keypairs = await api.aws.getKeypairs(region);
const resources = await api.aws.discoverFortinetResources(region, cp, env);

// GCP
const projects = await api.gcp.getProjects();
const regions = await api.gcp.getRegions(project);
const networks = await api.gcp.getNetworks(project);

Adding Dynamic Dropdowns

To make a field populate from a cloud API:

1. Add Annotation

# @ui-label AWS Region
# @ui-type select
# @ui-source aws-regions
aws_region = "us-west-2"

2. Handle in FormField

The FormField.jsx component checks the source annotation and fetches data from the appropriate API endpoint. Supported sources:

3. Add a New Source

To add a new dynamic source (e.g., aws-security-groups):

1. Add the API endpoint in app/api/aws.py
2. Add the client method in api.js under api.aws
3. Add the source handler in FormField.jsx

Testing

Backend and frontend testing.

Backend Tests

The backend has 250+ pytest tests covering all services, database operations, and API endpoints.

cd ui/backend
uv run python -m pytest tests/ -v

Test Files

Running Specific Tests

# Run a single test file
uv run python -m pytest tests/test_drift_service.py -v

# Run tests matching a pattern
uv run python -m pytest tests/ -k "test_scaffold" -v

# Run with coverage
uv run python -m pytest tests/ --cov=app --cov-report=term-missing

Test Configuration

Tests use asyncio_mode = "auto" in pyproject.toml, so no @pytest.mark.asyncio decorators are needed. API tests use httpx.AsyncClient with the FastAPI test client.

Frontend Build Verification

The frontend uses Vite for building. Verify the build succeeds:

cd ui/frontend
npx vite build

A successful build produces output like:

vite v5.4.21 building for production...
✓ 47 modules transformed.
dist/index.html                   0.47 kB
dist/assets/index-*.css          17.79 kB
dist/assets/index-*.js          182.51 kB
✓ built in 274ms

Manual Testing Checklist

When adding new features:

• Template selector populates from database
• “+” button opens registration modal
• Registration form clones repo and generates scaffold
• Export downloads tfvars.ui file
• Import uploads enriched tfvars.ui
• Drift indicator shows correct status (Clean/Warning/Hard Stop)
• Warning banner appears for non-critical drift
• Drift resolution modal opens on hard-stop click
• Conditional fields show/hide correctly (@ui-show-if)
• Dynamic dropdowns populate from cloud APIs (@ui-source)
• Plan/apply/destroy stream output in real-time
• Hard-stop drift blocks plan/apply with 409 error
• AWS/GCP credential status displays correctly

Troubleshooting

Common issues and fixes for UI development.

Backend Issues

ModuleNotFoundError

cd ui/backend
uv sync

Port Already in Use

lsof -i :8000
kill -9 <PID>

Database Errors

If the SQLite database is corrupted or schema is outdated:

# Delete and recreate (data will be lost)
rm -f ui/backend/data/registry.db
# Restart backend — tables are auto-created on startup

Git Clone Failures

If template registration fails with a git error:

1. Verify the repo URL is accessible: git ls-remote <url>
2. Check the branch exists: git ls-remote --heads <url> <branch>
3. Check clone directory permissions: ls -la ui/backend/data/clones/
4. Clean up stale clones: rm -rf ui/backend/data/clones/*

Frontend Issues

Cannot Find Module

cd ui/frontend
npm install

Vite Build Fails

Always run the build from the ui/frontend/ directory:

cd ui/frontend
npx vite build

Running npx vite build from the repo root will pick up a global Vite version and fail with “Could not resolve entry module index.html”.

API Calls Failing

Check that backend is running and CORS is configured. The CORS origins are set in .env:

CORS_ORIGINS=http://localhost:3000,http://127.0.0.1:3000,http://localhost:5173,http://127.0.0.1:5173

AWS Credential Issues

Dropdowns Empty

1. Check credential status:

   curl http://localhost:8000/api/aws/credentials/status

2. If using SSO, ensure session is active:

   source ~/.local/bin/aws_login.sh your-profile

3. If credentials expired, re-run the login script.

GCP Credential Issues

GCP Dropdowns Empty

1. Check credential status:

   curl http://localhost:8000/api/gcp/credentials/status

2. Inject service account credentials:

   curl -X POST http://127.0.0.1:8000/api/gcp/credentials/set \
     -H "Content-Type: application/json" \
     -d @/path/to/service-account-key.json

Drift Issues

“Hard-stop drift detected” Error (409)

This means critical template files changed since last registration/import. To resolve:

1. Click the drift indicator in the UI to open the resolution modal
2. Review changed files
3. Re-scaffold if variables.tf changed
4. Save & re-hash to clear drift

Or via API:

# Check what drifted
curl http://127.0.0.1:8000/api/templates/1/drift

# Re-scaffold to pick up variable changes
curl -X POST http://127.0.0.1:8000/api/templates/1/scaffold

# Re-import to update hashes
curl -X POST http://127.0.0.1:8000/api/templates/1/import \
  -H "Content-Type: application/json" \
  -d '{"content": "<updated tfvars.ui content>"}'

Template Shows “Warning” Drift

Warning drift means non-critical files changed (e.g., a .tf file that isn’t variables.tf). This does not block plan/apply. The warning banner is dismissible.

Container Issues

Backend Not Starting in Docker

Check logs:

docker compose logs backend

Common causes:

• Missing data/ volume mount
• Port conflict on 8000
• Git not available in container (should be installed by Dockerfile)

Frontend Can’t Reach Backend

In container deployment, the frontend nginx proxies /api/ requests to the backend service. Ensure:

• Backend healthcheck passes: docker compose ps
• Frontend depends on backend: check docker-compose.yml depends_on condition

UI Deployment

Overview

This guide walks you through configuring the existing_vpc_resources template using the Web UI. This template creates the base infrastructure including management VPC, Transit Gateway, spoke VPCs, and test instances.

Step 1: Select Template

1. Open the UI at http://localhost:3000
2. In the Template dropdown at the top, select existing_vpc_resources
3. The form will load with default values

Step 2: Region Configuration

AWS Region

1. Locate the Region Configuration section
2. Click the AWS Region dropdown
3. Select your desired region (e.g., us-west-2)

Availability Zones

4. Availability Zone 1 dropdown will automatically populate with zones for your selected region
5. Select first AZ (e.g., a)
6. Availability Zone 2 dropdown updates automatically
7. Select second AZ - must be different from first (e.g., c)

Step 3: Customer Prefix and Environment

These values tag all resources for identification and must match between existing_vpc_resources and your chosen FortiGate template.

Customer Prefix (cp)

1. Enter your company or project identifier (e.g., acme)
2. Rules:
   • Lowercase letters, numbers, and hyphens only
   • Will prefix all resource names: acme-test-vpc

Environment (env)

3. Enter environment name (e.g., test, prod, dev)
4. Rules:
   • Lowercase letters, numbers, and hyphens only
   • Will be included in resource names: acme-test-vpc

{{% notice note %}} TODO: Add diagram - cp-env-fields

Show:

• Customer Prefix field with “acme” entered
• Environment field with “test” entered
• Help text explaining naming convention
• Example showing result: “acme-test-management-vpc” {{% /notice %}}

Step 4: Deployment Mode Selection (REQUIRED)

This is the most important decision - choose ONE deployment mode based on which FortiGate template you’ll deploy next.

Option A: AutoScale Deployment Mode

Choose this if you plan to deploy autoscale_template:

1. Check the box: Enable AutoScale Deployment
2. Uncheck: Enable HA Pair Deployment

This creates GWLB subnets (indices 4 & 5) for Gateway Load Balancer endpoints.

Option B: HA Pair Deployment Mode

Choose this if you plan to deploy ha_pair:

1. Check the box: Enable HA Pair Deployment
2. Uncheck: Enable AutoScale Deployment

This creates HA sync subnets (indices 10 & 11) for FGCP cluster synchronization.

{{% notice note %}} TODO: Add diagram - deployment-mode-selection

Show:

• Two checkboxes
• Enable AutoScale Deployment [[x]]
• Enable HA Pair Deployment [ ]
• Warning message: “These modes are mutually exclusive - choose one”
• Help text explaining what each mode creates {{% /notice %}}

Step 5: Component Flags

Enable or disable optional components based on your needs.

Management VPC

Check Enable Build Management VPC to create:

• Management VPC with public/private subnets
• Internet Gateway
• Security groups
• Optional: FortiManager, FortiAnalyzer, Jump Box

Enable this if you want management infrastructure deployed in a separate VPC.

Spoke VPCs and Transit Gateway

Check Enable Build Existing Subnets to create:

• Transit Gateway
• East spoke VPC
• West spoke VPC
• TGW route tables
• Optional: Linux test instances

Enable this for complete lab environment or if testing with spoke VPCs.

{{% notice note %}} TODO: Add diagram - component-flags

Show checkboxes for: [[x]] Enable Build Management VPC [[x]] Enable Build Existing Subnets With descriptions of what each creates {{% /notice %}}

Step 6: FortiManager Configuration (Optional)

If you enabled Management VPC and want FortiManager:

1. Check Enable FortiManager
2. Select Instance Type (default: m5.large)
   • m5.large: 2 vCPU / 8GB RAM
   • m5.xlarge: 4 vCPU / 16GB RAM
   • m5.2xlarge: 8 vCPU / 32GB RAM
3. Enter FortiManager OS Version (e.g., 7.4.5 or 7.6)
4. Admin Password - REQUIRED if enabled
   • Minimum 8 characters
   • Used to login to FortiManager GUI
5. Host IP (last octet only, e.g., 10 becomes 10.3.0.10)
6. License File (optional) - Path to BYOL license file (leave empty for PAYG)

{{% notice note %}} TODO: Add diagram - fortimanager-config

Show FortiManager section with:

• Enable FortiManager checkbox [[x]]
• Instance Type dropdown: “m5.large” selected
• OS Version field: “7.4.5”
• Admin Password field: [password masked]
• Host IP field: “10”
• License File field: empty (optional) {{% /notice %}}

Step 7: FortiAnalyzer Configuration (Optional)

If you enabled Management VPC and want FortiAnalyzer:

1. Check Enable FortiAnalyzer
2. Configure similarly to FortiManager:
   • Instance Type (default: m5.large)
   • OS Version (e.g., 7.4.5)
   • Admin Password (minimum 8 characters)
   • Host IP (e.g., 11 becomes 10.3.0.11)
   • License File (optional)

{{% notice note %}} TODO: Add diagram - fortianalyzer-config

Show FortiAnalyzer section similar to FortiManager {{% /notice %}}

Step 8: Jump Box Configuration (Optional)

If you enabled Management VPC and want a bastion host:

1. Check Enable Jump Box
2. Select Instance Type (default: t3.micro)
   • t3.micro: 2 vCPU / 1GB RAM
   • t3.small: 2 vCPU / 2GB RAM

The jump box provides SSH access to private resources and serves as a management bastion.

Step 9: Management VPC TGW Attachment (Optional)

If you enabled both Management VPC and Spoke VPCs:

1. Check Enable Management VPC TGW Attachment

This connects the management VPC to the Transit Gateway, allowing:

• Jump box access to spoke VPC instances
• FortiManager/FortiAnalyzer access via TGW

{{% notice note %}} TODO: Add diagram - tgw-attachment

Show:

• Enable Management VPC TGW Attachment checkbox
• Diagram showing Management VPC –> TGW –> Spoke VPCs connection {{% /notice %}}

Step 10: Linux Traffic Generators (Optional)

If you enabled Spoke VPCs and want traffic generation instances:

East Spoke Linux Instance

1. Check Enable East Linux Instances
2. Select Instance Type (default: t3.micro)

West Spoke Linux Instance

3. Check Enable West Linux Instances
4. Select Instance Type (default: t3.micro)

These instances provide:

• HTTP server on port 80 for connectivity testing
• Traffic generation tools (iperf3, curl, etc.)
• East-West traffic testing between spoke VPCs

Step 11: Debug TGW Attachment (Optional)

For advanced troubleshooting:

1. Check Enable Debug TGW Attachment

This creates a bypass path from Management VPC directly to spoke VPCs, skipping FortiGate inspection. Useful for:

• Validating connectivity independent of FortiGate
• Comparing performance with/without inspection
• Troubleshooting routing issues

Step 12: Network CIDRs

Configure IP address ranges for all VPCs.

Management VPC CIDR

1. Enter Management VPC CIDR (default: 10.3.0.0/16)
   • Used for jump box, FortiManager, FortiAnalyzer
   • Must not overlap with spoke VPCs

Spoke VPC CIDRs

If you enabled Spoke VPCs:

2. Spoke VPC Supernet (default: 192.168.0.0/16)

   • Parent CIDR containing all spoke VPCs

3. East Spoke VPC CIDR (default: 192.168.0.0/24)

   • Must be within spoke supernet
   • Used for east workload VPC

4. West Spoke VPC CIDR (default: 192.168.1.0/24)

   • Must be within spoke supernet
   • Used for west workload VPC

{{% notice note %}} TODO: Add diagram - cidr-configuration

Show:

• Management VPC CIDR: “10.3.0.0/16”
• Spoke Supernet: “192.168.0.0/16”
• East VPC CIDR: “192.168.0.0/24”
• West VPC CIDR: “192.168.1.0/24”
• Visual validation showing no overlaps
• Diagram showing CIDR relationships {{% /notice %}}

Step 13: Security Configuration

EC2 Key Pair

1. Click the Key Pair dropdown
2. Select an existing key pair in your region

aws ec2 create-key-pair --key-name my-keypair --region us-west-2 \
  --query 'KeyMaterial' --output text > my-keypair.pem
chmod 400 my-keypair.pem

Management CIDR Security Group

3. Enter Management CIDR - List of IP addresses/ranges for SSH/HTTPS access
   • Format: x.x.x.x/32 for single IP
   • Add multiple CIDRs by clicking “Add Item”
   • Example: 203.0.113.10/32, 10.0.0.0/8
   • Find your IP: https://ifconfig.me

{{% notice note %}} TODO: Add diagram - security-config

Show:

• Key Pair dropdown with “my-keypair” selected
• Management CIDR list field with:
  • First item: “203.0.113.10/32”
  • “Add Item” button to add more CIDRs
• Help text: “Restricts SSH and HTTPS access to management interfaces”
• Button: “Get My IP” (auto-fills current public IP) {{% /notice %}}

Step 14: Save Configuration

Before generating the terraform.tfvars file:

1. Click the Save Configuration button at the bottom
2. Confirmation message: “Configuration saved successfully!”

This saves your settings so you can return later and resume editing.

{{% notice note %}} TODO: Add diagram - save-button

Show:

• “Save Configuration” button (blue)
• “Reset to Defaults” button (gray)
• Success message after saving {{% /notice %}}

Step 15: Generate terraform.tfvars

1. Click the Generate terraform.tfvars button
2. A preview window appears showing the generated file contents
3. Review the configuration

{{% notice note %}} TODO: Add diagram - generated-preview

Show preview window with:

• Generated terraform.tfvars content
• Syntax highlighting
• Buttons: “Download”, “Save to Template”, “Clear” {{% /notice %}}

Step 16: Download or Save

Choose how to use the generated file:

Option A: Download File

1. Click Download
2. File saves as existing_vpc_resources.tfvars
3. Copy to terraform directory:

   cp ~/Downloads/existing_vpc_resources.tfvars \
     terraform/aws/existing_vpc_resources/terraform.tfvars

Option B: Save Directly to Template

1. Click Save to Template
2. Confirmation: “terraform.tfvars saved to: terraform/aws/existing_vpc_resources/terraform.tfvars”
3. Ready to deploy!

{{% notice note %}} TODO: Add diagram - download-save-options

Show:

• “Download” button
• “Save to Template” button
• Success message after saving {{% /notice %}}

Step 17: Deploy with Terraform

Now that your terraform.tfvars is configured:

cd terraform/aws/existing_vpc_resources

# Initialize Terraform
terraform init

# Review execution plan
terraform plan

# Deploy infrastructure
terraform apply

Type yes when prompted.

Expected deployment time: 10-15 minutes

Common Configuration Patterns

Pattern 1: Minimal Lab (Management VPC Only)

[x] Enable Build Management VPC
[x] Enable Jump Box
[ ] Enable FortiManager
[ ] Enable FortiAnalyzer
[ ] Enable Build Existing Subnets

Use case: Testing FortiGate deployment with minimal supporting infrastructure

Pattern 2: Complete Lab (Everything)

[x] Enable AutoScale Deployment (or HA Pair Deployment)
[x] Enable Build Management VPC
[x] Enable FortiManager
[x] Enable FortiAnalyzer
[x] Enable Jump Box
[x] Enable Management VPC TGW Attachment
[x] Enable Build Existing Subnets
[x] Enable East Linux Instances
[x] Enable West Linux Instances
[x] Enable Debug TGW Attachment

Use case: Full-featured training environment with all components

Pattern 3: Production Testing (No Debug Features)

[x] Enable AutoScale Deployment (or HA Pair Deployment)
[x] Enable Build Management VPC
[x] Enable FortiManager
[x] Enable FortiAnalyzer
[x] Enable Jump Box
[x] Enable Management VPC TGW Attachment
[x] Enable Build Existing Subnets
[ ] Enable East/West Linux Instances (use real workloads)
[ ] Enable Debug TGW Attachment

Use case: Production-like testing environment

Validation and Errors

The UI provides real-time validation:

CIDR Validation

• Valid CIDR format (e.g., 10.0.0.0/16)
• Invalid format shows error message
• Overlapping CIDRs highlighted

Required Fields

• Red border indicates required field not filled
• Cannot generate terraform.tfvars until all required fields valid

AWS Resource Validation

• Availability zones must be different
• Key pair must exist in selected region

{{% notice note %}} TODO: Add diagram - validation-errors

Show form with validation errors:

• Red border around empty required field
• Error message: “This field is required”
• CIDR overlap warning
• AZ conflict warning {{% /notice %}}

Next Steps

After deploying existing_vpc_resources:

1. Save the outputs:

   terraform output > ../outputs.txt

2. Record these critical values:

   • tgw_name - Transit Gateway name
   • fortimanager_private_ip - FortiManager IP (if enabled)
   • fortianalyzer_private_ip - FortiAnalyzer IP (if enabled)
   • deployment_mode - Verify correct mode was deployed

3. Continue to next template:

   • Configure autoscale_template (if you chose AutoScale mode)
   • Configure ha_pair (if you chose HA Pair mode)

Resetting Configuration

To start over with default values:

1. Click Reset to Defaults
2. Confirm: “Are you sure you want to reset to default values?”
3. Form resets to template defaults
4. Saved configuration is deleted

Manual Step-by-Step Deployment

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/fortinet-ui-terraform.git
cd fortinet-ui-terraform/terraform/aws/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: Select Deployment Mode (REQUIRED)

This is a critical decision - you must choose ONE deployment mode:

Option A: AutoScale Deployment

Choose this if you plan to deploy autoscale_template for elastic scaling:

enable_autoscale_deployment = true
enable_ha_pair_deployment   = false

This creates GWLB subnets (indices 4 & 5) for Gateway Load Balancer endpoints.

Option B: HA Pair Deployment

Choose this if you plan to deploy ha_pair template for fixed Active-Passive deployment:

enable_autoscale_deployment = false
enable_ha_pair_deployment   = true

This creates HA sync subnets (indices 10 & 11) for FGCP cluster synchronization and VPC Endpoint.

Step 5: Configure Component Flags

Management VPC

enable_build_management_vpc = true

Spoke VPCs and Transit Gateway

enable_build_existing_subnets = true

Step 6: 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 7: 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 8: 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 9: 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:

deployment_mode = "autoscale"  # or "ha_pair" based on selection
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 10: 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 11: Save Outputs for Next Template

Save key outputs for use in your chosen deployment template:

For AutoScale Deployment:

# 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

For HA Pair Deployment:

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

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

Outputs Reference

The template provides these outputs for use by your chosen deployment template:

Operations & Troubleshooting

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/aws/existing_vpc_resources
terraform destroy

Type yes when prompted.

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

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

# Step 1: Destroy ha_pair
cd terraform/aws/ha_pair
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 your chosen FortiGate template:

For AutoScale Deployment

Deploy autoscale_template to create the FortiGate autoscale group with Gateway Load Balancer:

Key information to carry forward:

• Transit Gateway name (from outputs): Use for attach_to_tgw_name
• FortiManager private IP (if enabled): Use for fortimanager_ip
• FortiAnalyzer private IP (if enabled): Use for FortiGate syslog config
• Same cp and env values (critical for resource discovery)

Recommended next reading:

• autoscale_template Deployment Guide
• FortiManager Integration Configuration
• Licensing Options

For HA Pair Deployment

Deploy ha_pair template to create the FortiGate Active-Passive HA Pair:

Key information to carry forward:

• Transit Gateway name (from outputs): Use for attach_to_tgw_name
• FortiManager private IP (if enabled): Use for fortimanager_ip
• FortiAnalyzer private IP (if enabled): Use for FortiGate syslog config
• Same cp and env values (critical for resource discovery)

Recommended next reading:

• ha_pair Template Deployment Guide
• FGCP HA Configuration
• Licensing Options

Autoscale Reference

Detailed explanations of autoscale template components, configuration options, and architectural considerations.

What You’ll Learn

This section covers the major architectural elements available in the autoscale_template:

• Internet Egress Options: Choose between EIP or NAT Gateway architectures
• Firewall Architecture: Understand 1-ARM vs 2-ARM configurations
• Management Isolation: Configure dedicated management ENI and VPC options
• Licensing: Manage BYOL licenses and integrate FortiFlex API
• FortiManager Integration: Enable centralized management and policy orchestration
• Capacity Planning: Configure autoscale group sizing and scaling strategies (AutoScale only)
• Primary Protection: Implement scale-in protection for configuration stability (AutoScale only)
• Additional Options: Fine-tune instance specifications and advanced settings

Each component page includes:

• Configuration examples
• Architecture diagrams
• Best practices
• Troubleshooting guidance
• Use case recommendations

Deployment Mode Comparison

Select a component from the navigation menu to learn more about specific autoscale_template configuration options.