In today’s cloud-first world, securing workloads across distributed environments is more critical than ever. As organizations migrate to AWS, they face the challenge of maintaining consistent security policies, ensuring high availability, and managing complex traffic flows across multiple VPCs and availability zones.

 

To address these challenges, Fortinet, a trusted leader in cybersecurity, has partnered with Amazon Web Services (AWS) to deliver robust, scalable, and cloud-native security solutions. Telefonica Tech UK has chosen Fortinet and AWS as a Strategic partners and utilising the “power of 3” Telefonica Tech can offer its customers the best options for securing their cloud environments.

 

Whether you’re a cloud architect, network engineer, or security professional, this blog will help you understand the architectural patterns, deployment strategies, and real-world use cases for securing your AWS environment with Fortinet.

 

Fortinet brings decades of cybersecurity expertise to the cloud, offering a suite of solutions that integrate deeply with AWS services. As an AWS ISV Accelerate Partner with multiple competencies—including Network & Security, WAF, and Outposts Ready, Fortinet is uniquely positioned to help organizations secure their cloud environments.

 

Key Benefits of Fortinet on AWS

 

  • Consistent Security Across Environments
    Fortinet ensures uniform security policies across on-premises, hybrid, and cloud environments. This consistency is critical for organizations managing complex, multi-cloud infrastructures.

 

  • Cloud-Native Integration
    Fortinet’s solutions are built to work natively with AWS services such as:

    • AWS Gateway Load Balancer (GWLB)
    • AWS Transit Gateway (TGW)
    • AWS Firewall Manager
    • AWS Security Hub
    • AWS WAF and CloudFront

 

  • Optimized Cloud Spend
    Through AWS Marketplace Private Offers and flexible consumption models, Fortinet helps customers manage and reduce cloud costs while meeting minimum spend commitments.

 

  • Centralized Visibility and Control
    With the Fortinet Security Fabric, users gain a unified view of their security posture across all environments, enabling faster response times and simplified management.

 

  • Powered by FortiGuard Labs
    Fortinet’s threat intelligence is backed by over 20 years of research and real-time data from FortiGuard Labs, ensuring proactive protection against emerging threats.

 

Active-Passive FGCP with AWS Transit Gateway

 

This architecture is a simple Active-Passive setup, this provides a similar architecture that you would expect to see in a traditional On-Prem setup. In this architecture we have two FortiGate virtual appliances across two availability zones in a centralised inspection VPC, this could also be quiet easily a sperate account depending on your needs.

 

 

This setup is very versatile, in this setup we have inspection for Ingress and Egress traffic, East to West traffic, we can also use this same setup to terminate IPSEC or SDWAN, and provide inspection for Direct Connect to and from On-Prem.

 

So how does failover operate in a Cloud environment when FortiGate is not in control of elements like Elastic IP’s and AWS Routing Tables? This is where the AWS Infrastructure API calls come in handy.

 

During a Failover the following procedure happens:-

  1. FortiGate B detects a HA event, for example the loss of FortiGate A
  2. FortiGate B contacts the relevant AWS APIs via a VPC Endpoint on the Management Subnet to move the Cluster Elastic IP and change routes on the Transit Subnets Route table
  3. Routes and Elastic IP migrate to FortiGate B
  4. Full convergence is usually complete in less than 10 secs

 

The below image illustrates this failover process

 

 

Lets look at some of the use case criteria for using the Active/Passive Architecture

 

  • Simple, Low-Traffic Environments
  • Ideal for small to medium deployments where traffic volume is predictable and doesn’t require horizontal scaling.
  • Stateful Inspection with Minimal Complexity
  • Active/Passive HA ensures session persistence and stateful failover, which is simpler to manage than stateless scaling.
  • Tight Control Over Failover
  • You want deterministic failover behaviour with Elastic IP and route table updates.
  • Cost-Conscious Deployments
  • Only one FortiGate instance is active at a time, reducing licensing and compute costs.
  • Traditional Perimeter Security
  • Often used for North-South traffic inspection (e.g., internet gateway or VPN termination).

 

 

Centralised Inspection with Gateway Load Balancer

 

In this architecture we are introducing AWS’s Gateway Load Balancer, a little more complicated than the Active/Passive setup, but relatively straight forward to understand and deploy. There are two modes of operation for this architecture, the first is just a single FortiGate in an Availability Zone, the diagram pics two zones but this could be one, or scaled to the number of Availability Zones in a particular region, for example, us-east-1 has 6 Availability Zones, if it was deemed sensible you could deploy across all zones for ultimate resiliency. The second option is to scale horizontally in each AZ, this would mean having multiple FortiGate’s per AZ.

 

Inside this option there are two options for design, the first is to design for a needed capacity (Manual), you size your instances accordingly and they are deployed across designated AZ’s and in the event you hit capacity issues you would manual intervene to add additional appliances to help with the load, this option has a few cons, the first is you are planning for expected capacity which means you will likely have over provisioned and under utilised instances operating 24/7 costing a lot of money, and while there are some tricks to combat some of these elements it is also entirely manual and means you have to react to an event and this is ultimately a slow process..

 

Fortinet have a second much better option called Fortinet Auto Scale for AWS, this option provides an far better capability. It utilises the AWS Autoscaling service and integrates with several other AWS services such as Lamba and DynamoDB to seamlessly scale out during periods of demand, and scale in when there is less demand on the system. This is a much more dynamic solution and one that we would recommend to our customers due to the flexibility of Autoscaling policies, using autoscaling also allows for the use of smaller instance types allow for cost reduction in the long term.

 

So lets take a look at these options.

 

 

In this setup we have a slight change to the previous setup. Firstly we have introduced a new VPC called the central inspection VPC, this holds our transit gateway attachments and the Gateway Load Balancer endpoints. In the FortiGate VPC we have removed the transit gateway subnet as it is no longer needed and replaced this with a Gateway Load Balancer which is associated to a Gateway Load Balancer Endpoint in the central inspection VPC. The FortiGate appliances are registered as targets with the GWLB and can have simple and complex health checks setup to monitor the health of the FortiGate appliances. This is a fully resilient setup that takes into account redundant paths from the work load VPC’s to the Inspection VPC’s and onward externally if that is needed.

 

Below we have the alternative option:

 

 

Architecturally this setup is the same as the previous option, however here we have the addition of an Auto Scaling group, this means we can operate with a minimum configuration during periods of less demand, and can react to scaling events that we define, some example scaling triggers could be, a sustained CPU limit on existing appliances for 5 Mins, we could schedule a scaling event, for example if we know that between 8am and 9:30am we have a peak demand due to users coming online with applications, would could set the number of instances to increase at 07:30am ready for the peak to start and then scale back in at 10:00am and then allow dynamic policies to take over throughout the day and overnight.

 

So what are some use case criteria for this type of architecture?

 

  • Horizontal Scalability
  • Ideal for dynamic environments where traffic volume fluctuates and auto scaling is needed.
  • Centralized Security in Multi-VPC Architectures
  • GWLB endpoints allow multiple VPCs to route traffic through a centralized FortiGate fleet.
  • East-West and North-South Inspection
  • Works well in containerized or service mesh environments where traffic patterns are complex.
  • Stateless, Distributed Traffic Handling
  • GWLB handles traffic distribution without requiring session stickiness, which is ideal for stateless inspection.

 

I hope this gives you a flavour of the benefits and flexibility of utilising Fortinet to protect your AWS environment. If you like to know more about how we can help you use Fortinet to protect your Cloud environment please get in touch, our Cloud Architects will be happy to talk to you about what uses cases you may have, and don’t forget with our partnership with Fortinet we have access to their huge array of talent to look at more complex issues if needed.

 

Keep a look out in the future for a follow edition to this blog where we will look at some more complex architectures for Fortinet where we have combinations of centralised and distributed elements.