Fortigate as gateway for multiple vpcs

Yes you can do that. Through Gateway Load balancer Endpoint in spoke + GWLB with Fortgiate as target in dedicated VPC.

See Diagram 2 in Palo Alto article with dotted green and dotted blue line flow ( forget about TGW in that diagram )

Essentially , you will created Gateway Endpoint in both spoke, link them with Gateway LB in dedicated VPC that has Fortigate registered with it.

After that some Appliances provide 2 ARM design where traffic will exit out to internet through second ENI of fortigate through IGW in fortigate/GWLB VPC. or in One Arm design where traffic will come back to spoke VPC and exit through spoke VPC IGW.

https://www.paloaltonetworks.com/blog/network-security/vm-series-integration-with-aws-gateway-loadbalancer/

I just want to give you architectural guidance that what you want to do is achievable.

Here you got.

https://docs.fortinet.com/document/fortigate-public-cloud/7.2.0/aws-administration-guide/570271/north-south-security-inspection-to-customer-vpc

Dont forget to accept the answer

Hi, why would you like to achieve this without a transit gateway? Technical requirement, cost? it depends on the reason the most suitable answer. If its because cost, then there other options like Gateway Load balancer but this also implies a cost, if it is because you would like to get other benefits like load balancing, north-south traffic inspection then gateway load balancer could be a solution without transit gateway. If is other reason and you just want to remove transit gateway, then before the transit gateway this kind of scenario was deployed using a Transit VPC, where one central VPC (your fortigate VPC) connects with every other VPC (spoke VPC) through a VPN connection. This architecture comes with own challenges, and transit gateway was the service that came to resolve them, however is still possible to do that configuration.

As mentioned, generally yes there are deployment options where you can use a Centralized FortiGate NGFW to provide traffic security gateway functionality for other VPC's without using TransitGateway, but there are limitations and every deployment has pros/cons.

TLDR: if your desire is to use a FortiGate in Security VPC for North-South (Ingress-Egress) inspection for 2 additional 'workload' VPC's you can setup:

• FortiGate + GWLB distributed deployment with GWLB endpoints in each of the workload VPC's (1 per AZ).
• You will not be able to inspect traffic between the 2 'workload' VPC's with the FortiGate + GWLB

Reference: https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/

• For larger deployments with many VPC's, TransitGateway + Gateway load balancer + FortiGate is generally the most modern/complete solution covering all traffic use case scenarios and GWLB deployment options: Ingress inspection (inspection either pre or post NLB), Egress inspection, and East-West Inspection.

• GWLB distributed deployments (GWLB endpoint in workload VPC's) DO NOT NEED TGW, and can support Ingress, Egress, and Intra VPC inter-subnet inspection, BUT NOT East-West inter-VPC inspection

• GWLB Centralized Deployments (GWLB endpoint in a central Security VPC) do require a TGW and can support Ingress, Egress, Intra VPC inter-subnet inspection, AND East-West inter-VPC inspection

• Centralized and Decentralized GWLB deployments can be combined to cover any traffic inspection scenario with a single GWLB & FortiGate Autoscaling TargetGroup

• Transit Gateway was created as the successor to Transit VPC, providing a simplified inter-VPC and inter-Region routing capability with external IPSec VPN capability. This added functionality has inherent costs

• GWLB was created to provide scalable & fault tolerant traffic inspection capabilities while eliminating the need to handle complexities of IPSec Tunnels/BGP/ECMP or SNAT for traffic inspection. This added functionality has inherent costs, and there are other considerations depending on your applications and traffic load like handling of existing flows in the event of an appliance failure

• Alternative options may provide a specific solution to your query at a lower financial cost ($/month) but added complexity cost (extra configuration/dependencies/etc) resulting in a more difficult solution to support and maintain.