Multicloud Networking Security: Transit and Peering

Once networks in two or more clouds are joined, every peering, transit attachment and interconnect becomes a path an attacker can use to move from the least protected environment to the most valuable one. Each provider has its own routing model, defaults and logs, so a rule that blocks traffic in one cloud may have no equivalent in the next. This guide covers the security of the connections themselves: transit hubs, peering, private interconnects between clouds, route control, inspection points and the logs that show what crossed. It is written for cloud network and security architects who already run workloads in AWS, Google Cloud or Microsoft Azure and are joining them together. Platforms are listed alphabetically throughout; the order is not a ranking.

Key takeaways

Routing is your first firewall. If a route to a network does not exist, nothing can reach it; design route tables, propagation and filters before you write a single firewall rule.
Peering is not transitive in any of the three clouds. That limits accidental reach, but hub designs that add transit deliberately can undo it, so every hub needs an explicit segmentation model.
Inspect at the hub, symmetrically. Send inter-cloud and inter-environment traffic through a firewall in the transit hub and confirm that return traffic takes the same path.
Encrypt and authenticate the inter-cloud link. Use MACsec on dedicated interconnects where offered, IPsec over the top where you need end-to-end encryption, and BGP session protection on every peering.
Log the transit layer, not only workloads. Flow logs on transit gateways, VLAN attachments and hub firewalls are the only record of what moved between clouds.

How inter-cloud traffic actually flows

Multicloud connectivity is built from three layers, and each has its own controls.

Layer	What it is	Main risks	Primary controls
Intra-cloud transit	Hub that joins many VPCs or VNets in one provider (transit gateway, virtual WAN hub, connectivity hub)	Flat any-to-any routing between environments, new attachments joining the wrong domain	Separate route tables or segments, explicit association, blackhole or filter routes
Peering	Direct link between two networks in the same provider	Full connectivity by default, overlapping trust between owners, forgotten cross-organisation peers	Network policy on both sides, route import and export choices, periodic review
Inter-cloud link	Dedicated interconnect, partner interconnect or IPsec VPN between providers, sometimes via a colocation or on-premises router	Unencrypted links, route leaks, unfiltered BGP, single points of failure	MACsec or IPsec, BGP prefix filters and authentication, redundant paths

Attackers who gain a foothold in one cloud look for exactly these paths. Network boundary bridging (ATT&CK T1599) is the technique to keep in mind when you review who can alter routes and attachments, and exfiltration over an alternative protocol (T1048) is what an unmonitored interconnect enables. The Hybrid Cloud Security guide covers attack paths between on-premises and cloud; this guide stays with cloud-to-cloud and cloud-internal transit.

Peering behaviour by platform

All three providers make peering non-transitive, which is a useful safety property. The differences are in what is exchanged and what is open by default.

AWS: VPC peering

AWS documentation states that VPC peering does not support transitive peering: with peerings A to B and A to C, B cannot reach C through A. It also blocks edge to edge routing, so a peered VPC cannot use another VPC's internet gateway, NAT device, VPN connection, Direct Connect connection or S3 gateway endpoint. Peering fails if any IPv4 or IPv6 CIDR blocks overlap, even if you only intend to use the non-overlapping ranges. Security groups and network ACLs on each side decide what traffic is allowed. See the Amazon VPC Security Guide.

Google Cloud: VPC Network Peering

Google Cloud documentation states that VPC Network Peering does not provide transitive routing. Subnet routes are always exchanged (with an exception for privately used public IPv4 ranges), while static and dynamic routes are controlled with the --export-custom-routes and --import-custom-routes settings, with exports governed by the local administrator and imports by the peer. Peering does not exchange VPC firewall rules, so each side writes its own ingress allow rules using the peer's ranges. Subnet ranges may not match, contain or fit within each other. See the Google Cloud VPC and Cloud NGFW Security Guide.

Microsoft Azure: virtual network peering

Microsoft documentation states that peerings by themselves are not transitive. Each side of a peering has four settings; on the local side, "Allow 'vnet-1' to access the peered virtual network" is selected by default, while receiving forwarded traffic, allowing the gateway or route server to forward traffic, and using the remote gateway or route server are not selected by default. Microsoft notes that full connectivity is the default and that network security groups can then block specific access. Creating a peering needs Network Contributor or a custom role with Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write, and peering works across subscriptions and Microsoft Entra tenants. See the Azure Virtual Network Security Guide.

Transit hubs and segmentation by platform

Transit hubs are where most multicloud designs concentrate risk. The security goal is the same in every cloud: environments such as production, non-production, shared services and partner connections sit in separate routing domains, and any path between domains passes through inspection.

AWS: Transit Gateway

Route tables: each attachment (VPC, VPN, Direct Connect gateway, peering, Connect and others) is associated with one route table, and its routes can be propagated into one or more route tables.
Defaults: a transit gateway comes with a default route table that is, by default, both the default association and the default propagation route table. For segmented designs, turn off default association and propagation so every new attachment must be placed deliberately.
Blackhole routes: AWS documents blackhole routes that drop matching traffic, for example one per VPC CIDR to prevent inter-VPC communication.
Appliance mode: for a stateful firewall in an inspection VPC, enable appliance mode on that VPC attachment so the transit gateway uses the same Availability Zone for that attachment for the lifetime of a flow. AWS warns that enabling it on an existing attachment can change current routing.

Google Cloud: Network Connectivity Center

Hubs and spokes: a global hub joins VPC spokes (which exchange subnet routes, including across projects and organisations) and hybrid spokes backed by router appliance VMs, HA VPN tunnels or Cloud Interconnect VLAN attachments, including Cross-Cloud Interconnect.
Filters: export filters control which routes a spoke sends to the hub; import filters control what a hybrid spoke imports. Use them to keep production ranges out of non-production spoke groups.
Producer VPC spokes: publish a producer service network to other spokes without full mesh peering.
Inspection: NCC Gateway spokes are regional spokes that support third-party security service edge inspection.

Microsoft Azure: Virtual WAN routing intent

Policies: each hub can have one Internet Traffic Routing Policy and one Private Traffic Routing Policy, each with a single next hop: Azure Firewall, an eligible network virtual appliance, or a SaaS firewall.
Inter-hub inspection: Microsoft states routing intent is the only mechanism in Virtual WAN for inter-hub traffic inspection, and it must be enabled on all hubs so traffic is routed symmetrically.
Private prefixes: private traffic matches RFC 1918 aggregates by default; any other private prefixes must be added to Private Traffic Prefixes on every hub.
Rollback: removing routing intent sets all connections to propagate to the default label and does not restore the previous configuration, so export gateways, connections and route tables first.

Availability: AWS documents per-Region attachment rules for Transit Gateway; Google Cloud documents that hybrid spokes must be in the same project as the hub; Microsoft documents that routing intent is not offered in Azure operated by 21Vianet and has limited NVA and SaaS support in Azure Government. Check each provider's current limits page before design sign-off.

Securing the inter-cloud link

The link between providers carries the most sensitive traffic in a multicloud estate and is often the least reviewed.

Option	How it works	Security properties to configure	Choose it when
IPsec VPN over the internet	Provider VPN gateways at each end with BGP over the tunnels	IKEv2, strong cipher suites, unique pre-shared keys or certificates per tunnel, two tunnels per gateway	Lower bandwidth, fast setup, or as an encrypted overlay on a private link
Provider-built cross-cloud interconnect	Dedicated physical connection between two providers' networks (Google Cloud Cross-Cloud Interconnect; AWS Interconnect multicloud)	MACsec where offered, redundant ports, BGP prefix filters, flow logs on the attachments	High, steady bandwidth between two named providers
Colocation or partner routing	Each cloud's dedicated circuit lands in a shared facility and your or a partner's routers join them	Router hardening, MACsec or IPsec, BGP authentication and filtering, physical security	More than two providers or existing on-premises routing hub

AWS Interconnect multicloud: AWS documentation states the AWS attach point is always a Direct Connect gateway, that Transit Gateways reach only an Interconnect local to their Region, and that links between AWS and partner devices are encrypted by default with IEEE 802.1AE MACsec and transmit customer traffic only while the encryption session is active.
Google Cloud Cross-Cloud Interconnect: Google documentation lists AWS, Microsoft Azure, Oracle Cloud Infrastructure and Alibaba Cloud as supported providers, uses VLAN attachments on primary and redundant ports, and offers optional MACsec for Cloud Interconnect.
Microsoft Azure: Azure joins other clouds through VPN Gateway, ExpressRoute circuits landing at a shared colocation or partner, or the inbound cross-cloud products of the other providers listed above, with routing intent deciding whether that traffic is inspected in the hub.

MACsec protects the physical hop only. Where policy needs encryption from workload network to workload network, run IPsec or TLS on top. Filter BGP on both sides: accept only the prefixes you expect from the other cloud, set maximum-prefix limits and refuse default routes unless the design requires them. See the BGP and Routing Security Guide and the Cloud Private Connectivity Guide, which covers private endpoints and service access within one provider.

Where identity fits

Network paths in the cloud are created through APIs, so the people and pipelines that hold network permissions decide your real segmentation. Review who holds roles that can create peerings, accept transit attachments, edit route tables or change routing intent, including service accounts used by infrastructure as code. Cross-tenant and cross-organisation peering in particular should need approval from both owners. Workload identity matters too: identity-aware controls such as private endpoint policies and service perimeters still apply after traffic crosses a link. See the Multi-Cloud Identity Guide for federating identities across providers.

Decision guidance

Peering or hub: two or three networks with a stable relationship can use direct peering with tight network policy. Beyond that, a hub with separate routing domains is easier to audit than a growing mesh.
Central or distributed inspection: one inspection hub per cloud keeps policy consistent and logs in one place; distributed firewalls in each spoke suit teams with strong local ownership but multiply rule sets. Large estates usually inspect inter-environment and inter-cloud traffic centrally and leave intra-application traffic to workload controls.
Dedicated link or VPN: dedicated interconnects suit sustained bandwidth and predictable latency; VPNs suit small volumes, quick starts and backup paths. Many organisations run both, with the VPN as an encrypted fallback.
Small organisations: start with IPsec VPN between one hub per cloud, a single inspection point, and flow logs on the gateways. Avoid a full mesh of peerings.
Large organisations: separate routing domains per environment, central network team approval for every attachment, route filters on every BGP session and an address plan that prevents overlap across clouds.

Implementation steps

Map the current state. Export every peering, transit attachment, route table, VPN and interconnect in each cloud, with owners. Draw the actual reachability, not the intended design.
Agree an address plan. Allocate non-overlapping ranges per cloud and environment; overlap blocks peering and pushes teams to NAT workarounds that hide sources in logs.
Define routing domains. Decide which environments may reach which, and through which inspection point. Write it as a matrix and keep it under change control.
Build the hub in parallel. Create new route tables or segments with default association and propagation off, the inspection firewall in place and flow logs on, before moving any attachment.
Test in log-only mode. Run the firewall in alert or allow-and-log mode first, review a full business cycle of traffic, then switch to enforcement.
Migrate one spoke at a time. Move non-production first, check routing symmetry and application health, then production.
Keep rollback ready. Export route tables and hub configuration before each change. Re-associating an attachment with its old route table is the fastest rollback; for Azure routing intent, saved configuration is required because removal does not restore it.
Lock down change. Restrict network permissions to the network team and pipelines, require approval for cross-account and cross-tenant attachments, and alert on any change made outside the pipeline.

Detection and measurement

Turn on flow logging at the transit layer in each cloud and send it to the same SIEM:

Platform	Transit-layer logs	Useful fields and notes
AWS	Transit Gateway Flow Logs to CloudWatch Logs, Amazon S3 or Firehose; VPC Flow Logs for interfaces	`tgw-attachment-id`, source and destination VPC and account, `packets-lost-blackhole` and `packets-lost-no-route` show blocked attempts
Google Cloud	VPC Flow Logs on VLAN attachments and Cloud VPN tunnels, written to Cloud Logging	Sampled and aggregated by 5-tuple; enable on the attachment or at network or organisation level, since subnet-level logging does not include gateways
Microsoft Azure	Virtual network flow logs in Network Watcher, stored in Azure Storage, plus hub firewall logs	Records the NSG or security admin rule that allowed or denied each flow, and the encryption state

Alert on: new peerings or attachments, especially cross-account or cross-tenant; route table and propagation changes; routing intent or hub policy changes; BGP sessions advertising unexpected prefixes; and traffic between routing domains that bypasses the inspection hub.

Metrics:

Percentage of peerings and attachments with a recorded owner and business reason (target 100%).
Percentage of inter-environment and inter-cloud flows passing an inspection point (target 100% for defined domains).
Transit attachments and interconnect VLANs with flow logging on (target 100%).
Network changes made outside the approved pipeline per month (target falling to zero).
BGP sessions with prefix filters and maximum-prefix limits (target 100%).
Mean time to detect an unapproved peering or attachment.

Framework mapping

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	CIS Controls v8.1	ATT&CK technique addressed
Network inventory and data flow maps	ID.AM-03	CM-8	12	T1599 Network Boundary Bridging
Routing domains and segmentation	PR.IR-01	SC-7, SC-7(21), AC-4	12	T1021 Remote Services
Deny by default between domains	PR.IR-01	SC-7(5)	13	T1048 Exfiltration Over Alternative Protocol
Link encryption	PR.DS-02	SC-8	3	T1557 Adversary-in-the-Middle
Change control of network configuration	PR.PS-01	CM-2, CM-7	4	T1599 Network Boundary Bridging
Transit logging and monitoring	DE.CM-01, PR.PS-04	AU-12	8, 13	T1537 Transfer Data to Cloud Account
Resilient paths	PR.IR-03	CP-8, CP-8(2)	12	T1498 Network Denial of Service

In ISO/IEC 27001:2022 Annex A, the same ground is covered by 8.20 Networks security, 8.21 Security of network services and 8.22 Segregation of networks.

Common failure patterns

Default propagation left on: every new attachment joins the shared route table, so a test VPC or partner VPN can reach production the day it is attached.
Asymmetric inspection: traffic goes out through the hub firewall but returns directly, so the stateful firewall drops it or, worse, teams add bypass routes that remove inspection altogether.
Peering treated as a trust decision once: cross-organisation peers set up for a project stay in place years later with full connectivity and no owner.
Unfiltered BGP on the interconnect: one cloud accepts every prefix the other advertises, so a misconfiguration leaks routes or attracts traffic to the wrong place.
Logging only workloads: flow logs are on in application subnets but not on transit attachments or interconnect VLANs, leaving no record of what crossed between clouds.
Overlapping address space: clouds built separately reuse the same ranges, and NAT added later hides true sources from detection rules.

Practitioner checklist

Export and map every peering, attachment, route table, VPN and interconnect in each cloud, with owners.
Agree a non-overlapping address plan across clouds and environments.
Turn off default route table association and propagation (or the equivalent) and place each attachment deliberately.
Route inter-environment and inter-cloud traffic through an inspection point and verify symmetry.
Use MACsec on dedicated interconnects where offered and IPsec or TLS where end-to-end encryption is required.
Apply prefix filters and maximum-prefix limits on every BGP session between clouds.
Enable flow logs on transit gateways, VLAN attachments, VPN tunnels and hub firewalls, centralised in one SIEM.
Limit network-changing permissions to the network team and pipelines, and alert on out-of-band changes.
Review cross-account and cross-tenant peerings quarterly and remove those without an owner.

Multicloud Networking Security: Controlling Transit, Peering and Inter Cloud Traffic