IBM Cloud managed security services

For specific security requirements, IBM Cloud offers managed services that might eliminate the need for a dedicated firewall appliance:

• IBM Cloud® Internet Services (CIS): Provides Layer 7 (application layer) web application firewall (WAF), Distributed Denial of Service (DDoS) protection, global load balancing, and content delivery network (CDN) capabilities. If you need only application-layer protection, CIS can meet your requirements because it is a fully managed service and does not require deployment of a firewall appliance.
• Virtual Private Network (VPN) for VPC and Client VPN services: It provides site-to-site and client-to-site VPN connectivity without requiring a firewall appliance.

When VPC native security might be sufficient

VPC native security features might be sufficient in the following scenarios:

• Simple workload isolation requirements
• Basic ingress and egress traffic control at network and instance levels
• No advanced inspection or logging requirements
• Application-layer protection is handled by Cloud Internet Services (CIS)
• VPN connectivity is handled by VPC VPN service

Compliance and regulatory requirements

Some compliance frameworks and regulatory standards require security capabilities that extend beyond VPC native security controls.

PCI DSS, HIPAA, SOC 2

Many compliance frameworks mandate next-generation firewall (NGFW) capabilities.

Audit logging

Detailed traffic logs for integration with security information and event management (SIEM) systems such as IBM QRadar®. VPC provides native logging capabilities, including flow logs for network-level visibility and data path logging for application load balancers. These services can support audit and monitoring requirements, depending on the level of detail and retention that is required.

Periodic security reports

Financial institutions and regulated industries often require comprehensive security reports every six to 12 months.

Simple Network Management Protocol (SNMP) traps and alerting

Integration with on-premises monitoring systems for real-time security event notification.

Advanced security capabilities

A dedicated firewall can provide advanced traffic inspection, threat detection, and policy enforcement capabilities that extend beyond VPC native security features.

Intrusion Prevention System (IPS)

Deep packet inspection to detect and block malicious traffic patterns.

Intrusion Detection System (IDS)

Monitors and alerts on suspicious network activity.

Application-layer inspection

Inspect traffic beyond Layer 4 (ports and protocols).

Layer 7 proxy and reverse proxy capabilities

Advanced firewall and proxy solutions can provide Hypertext Transfer Protocol (HTTP) and HTTP Secure (HTTPS) proxying, Transport Layer Security (TLS) termination, and deep application awareness.

Application Load Balancer (ALB) integration

ALBs can complement firewall deployments by providing Layer 7 traffic distribution and TLS termination before or alongside inspection architectures.

Server Name Indication (SNI) routing

Support hostname-based routing and inspection policies for HTTPS applications.

Egress SNI filtering

Some vendor solutions support outbound HTTPS filtering based on SNI values, enabling policy enforcement for outbound internet access without full TLS decryption.

Command-and-control (C2) blocking

Automatically block connections to known malicious servers.

Data loss prevention (DLP)

Inspect and control sensitive data that exits your network.

URL filtering

Control access to websites by category or specific URLs.

Quality of service (QoS)

Prioritize critical application traffic.

Operational requirements

Organizations with centralized security and governance requirements might benefit from deploying a dedicated firewall.

Centralized security policy management

Manage security rules across multiple VPCs from a single point.

Multi-tenant isolation

Separate security zones for different applications or customers.

Advanced logging and forensics

Detailed traffic logs with source and destination IP, ports, and application identification.

Automation capabilities

Enable application programming interface (API)-driven security policy updates and threat response.

Disaster recovery

Support Active/Passive or Active/Active high availability across zones or regions.

Network architecture requirements

Certain network architectures require traffic inspection, segmentation, or routing patterns that are best implemented with a dedicated firewall.

Transit VPC (hub and spoke)

A centralized connectivity pattern for traffic between multiple VPCs. For more information, see Transit VPC hub-and-spoke architecture. This pattern can also serve as a centralized security inspection point when advanced controls are required.

Custom routing and traffic engineering

IBM Cloud VPC supports custom routing tables and user-defined routes, enabling advanced traffic-steering patterns that are similar to IBM Cloud Classic Gateway Appliance deployments, including Vyatta®/Virtual Router Appliance (VRA), Juniper® vSRX, and Fortinet® vFSA solutions. Custom routes can direct traffic through firewalls, inspection points, transit gateways, or other network virtual appliances. This approach supports centralized security and segmented network architectures.

Hybrid cloud connectivity

Secure connections between VPC and on-premises data centers.

First-hop security

Stop and inspect all ingress and egress traffic at a single security checkpoint.

Zone-based security

Create security zones, such as DMZ, application tier, database tier, with controlled traffic flows between zones.

Cross-region connectivity and routing architecture

IBM Cloud VPC uses a Layer 3 SDN model in which cross-region and cross-account connectivity is implemented by using the IBM Cloud Transit Gateway service and VPN gateways, rather than firewall-centric routing. The IBM Cloud Transit Gateway provides the primary routing fabric between VPCs, while VPN gateways end encrypted Internet Protocol Security (IPsec) tunnels from on-premises or data center environments. In cross-region deployments, Transit Gateway instances are deployed in each region and connected through Transit Gateway peering to enable controlled inter-region routing without requiring firewall-based transit. This model replaces Classic infrastructure patterns where gateway firewalls were commonly used as centralized routing and connectivity hubs across data centers, accounts, or regions. For more information, see Transit VPC hub-and-spoke architecture.

Key difference in VPC

VPC uses a Layer 3 SDN architecture and the vendor-provided SDN Connector to provide more flexible security options. However, the advanced security capabilities that firewalls provide remain essential for many enterprise workloads.

Unlike Classic infrastructure, which relies on VLAN-based routing through gateway appliances such as VRA (Vyatta), VPC uses routing tables, custom routes, and transit architectures to steer traffic through security and inspection services.

Characteristics

• Simplest deployment model
• No automatic failover
• Lesser cost
• Any vendor supported

Available solutions

The following table outlines the available stand-alone firewall solutions from leading vendors, along with their corresponding products and catalog links. Vendor compatibility depends on the selected deployment mechanism and might require validation for BYOL and custom image deployments.

Best for

• Development and testing environments
• Noncritical workloads
• Cost-sensitive deployments
• Proof of concept projects

Stand-alone deployments do not provide firewall high availability. IBM does not suggest them for mission-critical production workloads.

Characteristics

• Load balancing across multiple firewall instances
• Scalable traffic distribution capacity
• Supports RMNLB or BGP over GRE
• Vendor support depends on the deployment mechanism
• Single-zone high availability

Available solutions

The following table outlines the available Active/Active (Single Zone) firewall solutions from leading vendors, along with their corresponding products and catalog links. Vendor compatibility depends on the selected deployment mechanism (RMNLB or BGP over GRE) and requires validation for BYOL and custom image deployments.

Implementation

• The firewall must support the BGP routing protocol for BGP over GRE deployments.
• RMNLB requires IP spoofing support on firewall instances.
• Vendor capability determines eligibility for BGP-based deployments.
• Some vendors might require custom configuration or validation, depending on the routing mode.

Best for

• High-throughput single-zone deployments
• Scalable traffic distribution architectures
• Environments that use RMNLB or BGP over GRE
• Firewall scaling within a single availability zone

Characteristics

• Zone-level high availability
• Automatic failover that uses SDN Connector
• Supports virtual server instance and bare metal server deployments
• Tested with Fortinet and Palo Alto

Available solutions

Implementation

• Virtual server instance deployments use SDN Connector for automatic failover
• Bare metal deployments use virtual network floating interfaces for failover
• Vendor capability determines automation support for failover orchestration
• Some vendors might require custom automation or manual failover, depending on the deployment model

Best for

• Production workloads that require zone-level resilience
• Applications that can tolerate zone-level outages
• Standard enterprise firewall high availability deployments

Implementation options are as follows:

Virtual server instances

• Fortinet vFSA (FortiGate):

  • Transit VPC with FortiGate Solution Guide
  • FortiGate with SDN Connector

Characteristics

• Regional high availability
• Protection against zone failures
• Automatic failover across zones
• SDN Connector-based automation for virtual server instance deployments
• Bare metal deployments use virtual network floating interfaces or customer-managed failover mechanisms
• Currently, optimized for Fortinet

In GRE-based designs, throughput characteristics depend on the firewall appliance processing architecture and might not scale linearly with more instances.

Available solutions

Implementation

• Virtual server instance deployments use SDN Connector for cross-zone failover orchestration
• Bare metal deployments require customer-managed failover mechanisms (for example, VRRP, Pacemaker, or equivalent vendor HA tools)
• Failover between zones depends on routing updates and zone-aware VPC routing behavior
• Vendor automation support varies and requires validation for BYOL/custom images

Best for

• Mission-critical production workloads
• Applications that require maximum availability
• Compliance requirements for regional resilience
• Disaster recovery scenarios

Failover method

SDN Connector with cross-zone awareness automatically updates routing when zone failure occurs.

Characteristics

• Regional high availability with load balancing. Route-mode designs require a per-zone NLB.
• Highest throughput and resilience
• BGP support is required
• Most complex deployment model

Implementation

• The firewall must support the BGP routing protocol
• Any vendor with BGP capability is supported for BGP-based deployments
• For more information, see Virtual firewall appliances with BGP Over GRE.

Stateful inspection in Active/Active designs requires symmetric routing through the same firewall instance. Where asymmetric routing can occur, some firewall vendors (including Fortinet FortiGate and supported Palo Alto Networks deployments) use state synchronization mechanisms. Examples include Fortinet FortiGate Session Life Support Protocol (FGSP) and equivalent session synchronization features that maintain session continuity across instances.

Best for

• Enterprise-scale deployments
• Maximum throughput and availability requirements
• Complex routing scenarios
• Multi-region architectures

BGP over GRE tunnels provide dynamic routing and automatic failover across availability zones.

Active/Active HA (multizone) with RMNLB and Fortinet state synchronization

An Active/Active multizone deployment pattern is available that does not require BGP for routing control. This pattern uses RMNLBs, typically one per availability zone, which is combined with state synchronization between firewall instances when flow recovery across zones is required.

In this design, firewall instances operate in Active/Active mode across multiple availability zones, and RMNLBs distribute traffic across the firewall pool while you preserve the source and destination IP addresses. This approach enables transparent inspection and stateful traffic handling without requiring dynamic routing protocols, such as BGP.

Fortinet deployments can use FGSP for session state synchronization between instances. FGSP helps maintain connection state consistency across availability zones when traffic for a session might be processed by different firewall instances.

FGSP is only required for asymmetric traffic scenarios or when session recovery is required following a zone failure event. Symmetric traffic flows do not require FGSP.

This model is useful in environments where BGP-based routing is not required or not supported, while still requiring horizontal scaling and multizone availability.

This pattern integrates with the IBM Cloud VPC routing model, where routing tables direct traffic toward the RMNLB as the next hop. The RMNLB then distributes traffic to available firewall instances for inspection and forwarding.

For cross-region architectures, this Active/Active model can be combined with Transit Gateway peering to extend inspection capabilities across regions while you maintain regional routing control boundaries.

Vendor support (virtual server instance only)

The following vendor support options are available for SDN Connector integration:

Fortinet FortiGate

Native SDN Connector integration is included in IBM Cloud VPC images.

Other vendors

Must implement custom automation or use manual failover processes.

For support information across all HA deployment models, see the vendor support matrix for HA firewall deployments.

How it works

1. Continuously monitors the HA cluster state.
2. Detects when an active node changes.
3. Uses IBM Cloud VPC APIs to update routing.
4. Redirects traffic to the new active node.

Failover process

The following sequence describes a typical failover event:

1. Active node fails or becomes unavailable.
2. The passive node detects failure and becomes active.
3. SDN Connector detects the cluster state change.
4. The connector queries VPC routing tables for routes with old active IP.
5. The connector deletes each old route.
6. The connector creates new routes that point to a new active node.
7. Traffic automatically flows through new active node.

Benefits

The SDN Connector provides the following benefits:

• Automatic failover without manual intervention
• Fast recovery, typically within seconds
• No external monitoring is required
• Integrated with firewall HA mechanism (Fortinet only)

Best for

• Production workloads that require zone-level resilience
• Applications that can tolerate zone-level outages

Vendor support

The following vendor support options are available for cross-zone failover:

Fortinet FortiGate

Native SDN Connector with cross-zone support and automatic public address range zone binding updates.

Other vendors

Require custom automation to support cross-zone failover.

Failover process

The following sequence describes a typical cross-zone failover event:

1. The Fortinet SDN Connector detects a zone failure or active node change.
2. Routes that point to the previous active node are identified and updated.
3. The SDN Connector updates the route zone to match the new active node's zone.
4. If you use Public Address Ranges for VPC, the public address range zone binding is updated for Fortinet deployments. Public address ranges support public IPs across multiple zones.

Route update pattern

For each route that points to an old active node:

1. DELETE the old route.

2. CREATE a new route with:

   • Same destination Classless Inter-Domain Routing (CIDR)
   • New next_hop IP (new active node)
   • New zone (new active node's zone)

Key points

Consider the following characteristics of cross-zone failover:

• Failover typically completes within seconds

• A brief traffic interruption during route updates

• Automatic recovery without manual intervention (Fortinet only)

• VPC routing table routes cannot be updated with new zone through PATCH (must use DELETE or CREATE)

• Floating IPs cannot move across zones (VPC limitation). Floating IPs support public IP access within a single zone.

  Floating IPs are zone-scoped resources, while Public Address Ranges are VPC-scoped and can be routed across zones by using routing tables.

What are Public Address Ranges for VPC?

Public Address Ranges for VPC provide the following capabilities:

• A public subnet that is bound to a specific VPC and zone.
• Integration with routing tables that use Public Internet as the traffic source.
• Source IP preservation without NAT by the VPC infrastructure.
• Optional NAT processing by the firewall for back-end applications.

Vendor support

The following vendor support options are available:

Fortinet FortiGate

Native Public Address Range integration with automatic zone-binding updates during cross-zone failover (FortiOS® 7.6.3 and later).

Other vendors

Public address ranges are supported, but custom automation is required for zone-binding updates.

Use cases

Public address ranges are commonly used for the following scenarios:

• Public-facing web applications that require source IP visibility
• Services with IP-based access control or logging requirements
• Compliance requirements for IP address logging
• DDoS protection deployments that require source IP preservation

How public address ranges work with firewalls

The following sequence describes a typical traffic flow:

1. The public address range is created and bound to a VPC and specific zone.
2. The routing table is configured with the public address range CIDR as the destination.
3. Traffic from the public internet matches the public address range routes.
4. Routes direct traffic through the firewall as the next hop.
5. The firewall inspects and forwards traffic to back-end applications.
6. Source IP addresses are preserved throughout the traffic flow.

Cross-zone failover with public address ranges (Fortinet only)

When an active firewall node moves to a different zone, the Fortinet SDN Connector automatically runs the following actions:

1. The SDN Connector updates routing table routes, including next_hop and zone information.
2. The SDN Connector updates the public address range zone binding to match the new active node's zone.
3. The SDN Connector maintains traffic flow through the new active node.

Benefits

Public address ranges provide the following benefits:

• Source IP preservation for security and compliance requirements
• Transparent firewall operation for public traffic
• Automatic failover with public address range zone binding updates for supported Fortinet deployments
• No application changes required

How route mode works

Route mode provides the following capabilities:

• Preserves source and destination IP addresses without NAT
• Acts as a bump-in-the-wire for traffic inspection
• Distributes traffic across multiple firewall instances
• Maintains session affinity for stateful inspection

Stateful firewalls require symmetric traffic flows. Return traffic must traverse the same firewall instance that processed the original session. Routing tables, load-balancing behavior, and failover mechanisms must be designed to avoid asymmetric routing conditions that can disrupt stateful inspection.

In Active/Active multizone deployments, RMNLB behavior can be combined with firewall-level state synchronization mechanisms such as Fortinet FGSP to maintain session consistency across multiple active instances. This allows scaling across zones without requiring BGP-based routing protocols while preserving the symmetric traffic flows that are required for stateful inspection.

Traffic flow

The following traffic flow illustrates route mode behavior:

REQUEST:  Client → VPC Routing Table → NLB (Route Mode) → Firewall → VPC Routing Table → Server
RESPONSE: Server → VPC Routing Table → NLB (Route Mode) → Same Firewall → VPC Routing Table → Client

Key characteristics

Route mode deployments provide the following characteristics:

Transparent operation

Client and server see each other's real IPs.

No NAT

Source and destination IPs are preserved throughout the flow.

Session persistence

Return traffic uses the same firewall instance.

Load distribution

Traffic is distributed across active firewall instances.

Ingress behavior limitation

RMNLB provides traffic steering and distribution but does not provide public IP failover or endpoint mobility. Public ingress failover must be implemented through routing design or vendor-specific mechanisms.

Vendor-agnostic

Works with any firewall vendor.

Configuration requirements

The following configuration requirements apply to route mode deployments:

• NLB with route mode enabled
• IP spoofing enabled on firewall interfaces
• Security group rules configured to allow traffic
• Routing tables configured to use NLB as the next hop
• Firewall instances that are configured as back-end pool members

Routing table configuration

Egress routing table (client VPC):

• Destination: Server subnet CIDR
• Next hop: NLB IP address
• Action: Deliver

Egress routing table (server VPC):

• Destination: Client subnet CIDR
• Next hop: NLB IP address
• Action: Deliver

Performance characteristics

Consider the following performance characteristics:

• Lesser latency than application load balancers
• Horizontal scaling by adding firewall instances
• Session persistence can ensure that stateful inspection works correctly
• Throughput scales with number of firewall instances
• Vendor-agnostic solution supports any firewall

Benefits

Route mode provides the following benefits:

Scalability

Add firewall instances to increase capacity.

High availability

Multiple active instances provide redundancy.

Flexibility

Works with any firewall vendor.

Simplicity

No complex BGP configuration required.

Performance

Efficient Layer 4 load balancing.

For more information, see Virtual firewall appliances with network load balancer for traffic management.

Gateway appliances (still available)

The following gateway appliance offerings are available in IBM Cloud Classic infrastructure:

• Virtual FortiGate (vFSA) (see Getting started with Fortigate Security Appliance)

• Virtual Juniper vSRX (see Getting started with IBM Cloud Juniper vSRX)

• Virtual Router Appliance (VRA (Vyatta)) (see Getting started with IBM Virtual Router Appliance)

For more information, see Getting started with IBM Cloud Gateway Appliance.

Deprecated physical firewalls

The following physical firewall offerings are deprecated:

• FortiGate 10G (see Exploring firewalls)
• Hardware Firewall (Shared) (see Getting started with Hardware Firewall)

Firewall license

Firewall vendor licenses typically determine the maximum throughput that a firewall can achieve.

Consider the following licensing factors:

vCPU count

Firewall vendor licenses typically limit throughput based on the number of licensed vCPUs.

Gating factor

The license vCPU limit is usually the primary constraint on performance.

Example

A 4-vCPU firewall license limits throughput regardless of virtual server instance profile size.

Recommendation

Match virtual server instance profile vCPU count to firewall license vCPU entitlement.

Virtual server instance profile selection

The selected virtual server instance profile affects the available network bandwidth and overall firewall performance.

Consider the following profile characteristics:

Profile size

Larger profiles provide higher bandwidth limits. For more information, see x86-64 instance profiles and Gen 4 profile examples.

Bandwidth pooling (Gen 4 profiles only)

Network bandwidth is pooled across all interfaces, which allows flexible allocation.

Pre-Gen 4 profiles

Available bandwidth is divided equally across interfaces and is not pooled.

Example

A bx4-32x128 profile provides a 64 Gbps bandwidth limit that can be pooled across all interfaces (Gen 4).

Network interface configuration

The number and configuration of network interfaces can affect available bandwidth.

Consider the following factors: Number of interfaces : More interfaces can affect available bandwidth per interface on pre-Gen 4 profiles.

Gen 4 advantage

Bandwidth pooling eliminates per-interface division.

Recommendation

Use Gen 4 profiles for firewall deployments when they are available.

Network Load Balancer (Active/Active)

Active/Active deployments that use an NLB introduce more performance considerations.

Consider the following factors:

NLB throughput

An NLB has its own throughput limits.

Route mode

Provides lesser latency than application load balancers, and enables efficient Layer 4 routing.

Scaling

Traffic can be distributed across multiple firewall instances to increase aggregate throughput.

In some virtual firewall implementations, GRE encapsulation and processing might reach CPU capacity limits, which restricts throughput even when network capacity is sufficient.

Bare metal servers

Bare metal servers provide dedicated hardware resources and can deliver consistent network performance.

Consider the following characteristics: High network throughput : Dedicated hardware resources provide consistent high performance.

Virtual network floating interfaces

Automatic failover without SDN Connector overhead.

Significant limitations

Manual hypervisor and VM configuration is required, along with monthly billing only, limited scaling flexibility, and customer-managed OS and software.

Recommendation

Consider virtual server instance deployments first due to operational simplicity and flexibility.

Key recommendations

The following recommendations can help optimize firewall deployments in VPC:

1. Help ensure that the virtual server instance profile vCPU count matches or exceeds the firewall license vCPU entitlement.
2. Use Gen 4 profiles, because bandwidth pooling provides better flexibility for multi-interface firewalls.
3. Start with virtual server instance deployments because they offer better flexibility, easier management, and hourly billing.
4. Validate that actual throughput meets requirements before production deployment.

Gen 4 virtual server instance profile examples

Balanced profiles (bx4)

The following examples show Gen 4 balanced profiles:

Gen 4 profiles feature bandwidth pooling across all interfaces. For complete profile details, see General-purpose instance profiles - Intel Gen 4.