<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1705902170274878&amp;ev=PageView&amp;noscript=1">
Skip to content
Talk to Us
  • There are no suggestions because the search field is empty.

Hybrid Cloud Firewall

Rather than a separate firewall in every cloud, a hybrid cloud firewall places one virtual security instance on the managed edge and routes all inter-tier and inter-cloud traffic through it – one consistent inspection and policy point for the whole estate.

When to use it

Use this pattern when a single application spans on-premises and more than one cloud, or when security and compliance require that traffic between tiers and between clouds be inspected at a controlled boundary. Duplicating firewalls per cloud fragments policy and multiplies cost and audit surface; consolidating gives you one rule set to write and prove.

How it works

A virtual firewall (and, where needed, a virtual router) runs on the IZO™+ Multi Cloud Connect managed edge. Each cloud attaches to the edge over a private, dedicated connection, and each on-premises site connects the same way. The topology is hub-and-spoke with the firewall at the hub: traffic between a web tier in one cloud and a database tier in another, or between the enterprise and any cloud, transits the firewall as the central Layer 3 and security point.

Setup is layered – the private connections are established first, then Layer 3 peering (BGP) is brought up so the firewall becomes the routed pivot. Internal traffic stays on private addressing; where a tier must be reached from the internet, address translation and a controlled public address are applied at the edge rather than opening each cloud independently. The result is a single choke point where segmentation, inspection and policy live.

For availability, a single instance is the baseline; because a firewall is stateful, production designs use the active-standby cluster from the High Availability & Redundancy Models page so failover preserves session state.

Example

A pharmaceutical company runs a validated application with a web tier in AWS, a database tier in Azure, and identity and shared services on-premises. Regulatory rules require inspected, logged traffic between tiers. It deploys a virtual firewall as an active-standby cluster on the managed edge; every cloud and the on-premises site attach privately, and all inter-tier traffic routes through the firewall. One policy set governs the whole application, and one log stream supports audit.

MCC Visual Reference Architecture & Use Cases-13.10 Hybrid Cloud Firewall.drawio-1

IZO™+ Multi Cloud Connect components in this architecture

A hybrid cloud firewall is a Flex pattern – the firewall is an in-path VNF at the hub:

IZO™+ Multi Cloud Connect Flex (internet underlay with an in-path VNF):

  • Fabric Port – the on-ramp where your network meets the service (Hosted or Dedicated; L3 Private access is typical). Present in every solution.

  • Edge Connect – the short leg that carries traffic from the Fabric Port to the VNF.

  • VNF – Firewall / WAF – the central inspection and policy point; sized by vCPU, Tata-managed or customer-managed, Tata-subscription or BYOL.

  • Virtual Cloud Connection – one private landing per cloud attached to the hub.

  • Device Interconnection – for a dual/clustered firewall pair, or to chain the firewall to another function (for example SD-WAN).

From the IZO™+ Multi Cloud Connect side, this architecture uses a Fabric Port + Edge Connect + Firewall VNF + Virtual Cloud Connection(s); everything up to the Virtual Cloud Connection is delivered and billed by Tata Communications, while each cloud port/attachment and egress sit on your cloud bill.

Considerations

  • Flex is required - The firewall is an in-path function, so this is always IZO™+ Multi Cloud Connect Flex.

  • Stateful HA - A firewall is stateful – use the clustered (active-standby) build with a Device Interconnection for state sync so failover preserves sessions.

  • Hub-and-spoke - Every cloud and on-premises site attaches privately; all inter-tier and inter-cloud traffic transits the firewall as the single Layer 3 and policy point.

  • Addressing - Internal traffic stays on private addressing; use NAT and a controlled public address at the edge for internet-facing tiers rather than opening each cloud separately.

  • Sizing & vendors - vCPU size drives throughput and cost; Cisco is default, other vendors via your Account Manager – confirm which are GA before listing.

What’s on the cloud side

Each cloud connection and its gateway are created in the cloud provider’s console. This page covers how the central firewall and private attachments are delivered on the Tata Communications side; for the cloud-side connection request and routing, see the relevant per-cloud section.

Related pages