<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Upgrade FortiOS - Autoscale Simplified Template</title><link>https://fortinetcloudcse.github.io/Autoscale-Simplified-Template/6_upgrade_fortios/index.html</link><description>Upgrading FortiOS on an Autoscale Group The upgrade_fortios/ toolset upgrades a FortiGate autoscale group running in AWS. Two strategies are available, selected interactively at runtime based on the deployment’s current state and the operator’s risk tolerance.
Upgrade Strategies Strategy Best For Traffic Impact Rollback In-Place Same-major-version bumps on healthy deployments Brief per-instance restart Manual LT revert Blue-Green Cross-major-version upgrades, config remediation, or when full fallback is required Near-zero (session interrupt at cutover) Single script call, &lt; 60 seconds In-Place Upgrade Paths The in-place strategy inspects live ASG state and selects the appropriate path automatically:</description><generator>Hugo</generator><language>en-US</language><atom:link href="https://fortinetcloudcse.github.io/Autoscale-Simplified-Template/6_upgrade_fortios/index.xml" rel="self" type="application/rss+xml"/><item><title>Overview</title><link>https://fortinetcloudcse.github.io/Autoscale-Simplified-Template/6_upgrade_fortios/6_1_overview/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://fortinetcloudcse.github.io/Autoscale-Simplified-Template/6_upgrade_fortios/6_1_overview/index.html</guid><description>Purpose The upgrade_fortios/ toolset upgrades the FortiOS version on a FortiGate autoscale group running in AWS. It reads the existing terraform.tfstate file to discover the deployment automatically — no manual resource identification is required.
Entry Points The toolset has two separate entry points — one for each strategy. Run discover.py first for both strategies to build the inventory file.
In-Place:
cd upgrade_fortios bash state/refresh.sh python3 scripts/discover.py --state state/autoscale_template.tfstate \ --target-version 7.6.2 --output state/blue_inventory.json python3 scripts/inplace_upgrade.py --inventory state/blue_inventory.json Blue-Green:</description></item><item><title>In-Place Upgrade</title><link>https://fortinetcloudcse.github.io/Autoscale-Simplified-Template/6_upgrade_fortios/6_2_in_place_upgrade/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://fortinetcloudcse.github.io/Autoscale-Simplified-Template/6_upgrade_fortios/6_2_in_place_upgrade/index.html</guid><description>Overview The in-place upgrade updates the launch template AMI and replaces running instances without deploying a parallel environment. The script reads live ASG state from AWS and selects the appropriate path automatically.
Warning Cross-major-version upgrades (e.g., 7.4.x → 7.6.x) require Path C — FortiGate native config sync does not work across major versions. Rolling replacement (Path B) alone is not sufficient; a config restore must follow.</description></item><item><title>Blue-Green Upgrade</title><link>https://fortinetcloudcse.github.io/Autoscale-Simplified-Template/6_upgrade_fortios/6_3_blue_green_upgrade/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://fortinetcloudcse.github.io/Autoscale-Simplified-Template/6_upgrade_fortios/6_3_blue_green_upgrade/index.html</guid><description>Overview Blue-green upgrade deploys a parallel (Green) inspection stack alongside the existing (Blue) stack, validates Green under real conditions, then flips all TGW routes atomically at cutover. Blue remains suspended as a live fallback until the operator explicitly approves cleanup.
This strategy eliminates cross-version config sync issues and gives full rollback capability at every phase up through cleanup.
Architecture Blue Environment (Existing) Spoke VPCs (East, West, ...) │ ▼ Transit Gateway │ TGW route tables → Blue inspection VPC attachment ▼ Blue Inspection VPC (10.0.0.0/16) ├── GWLB + Target Group ├── FortiGate ASG (BYOL + On-Demand) ├── DynamoDB (instance tracking) └── Lambda (lifecycle management) Green Environment (New — deployed in parallel) Transit Gateway │ TGW attachment created but routes NOT switched yet ▼ Green Inspection VPC (10.0.0.0/16) ← SAME CIDR as Blue ├── GWLB + Target Group (new) ├── FortiGate ASG (new FortiOS AMI, corrected config) ├── DynamoDB (clean state) └── Lambda (current version) After Cutover Spoke VPCs │ ▼ Transit Gateway │ TGW route tables → Green inspection VPC attachment ▼ Green Inspection VPC (traffic flows here) Blue Inspection VPC (suspended — no new instances, kept as rollback target) Why the Same CIDR Green uses the same CIDR blocks as the Blue inspection VPC. This is a deliberate design choice, not a limitation.</description></item><item><title>Discovery</title><link>https://fortinetcloudcse.github.io/Autoscale-Simplified-Template/6_upgrade_fortios/6_4_discovery/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://fortinetcloudcse.github.io/Autoscale-Simplified-Template/6_upgrade_fortios/6_4_discovery/index.html</guid><description>Overview discover.py extracts the complete Blue environment inventory from the existing terraform.tfstate file and produces a structured blue_inventory.json used by all subsequent upgrade phases.
Discovery does not rely on AWS resource tags — it reads the Terraform state directly. This makes it reliable for deployments that were not created with the Simplified Template and may not follow the {cp}-{env}-{resource} tag convention.
Getting the State File Local State If the deployment uses local Terraform state (default):</description></item></channel></rss>