Cloud transit gateways sit at the heart of most serious multi-VPC networking designs, yet they're misunderstood more often than almost any other infrastructure component. Australian IT teams adopt them to replace the tangle of VPC peering relationships that accumulates as environments grow, then discover months later that they've traded one set of problems for a different, more expensive one.
A transit gateway acts as a regional hub: connect each VPC and on-premises network once, and the gateway handles routing between all of them. On paper, this replaces an n-squared peering mesh with a hub-and-spoke topology. In practice, the simplicity at the diagram level doesn't always survive contact with real workloads.
Why teams adopt transit gateways for the wrong reasons
The most common trigger for adopting a transit gateway is hitting the VPC peering limit, or dreading the management overhead of 30-plus peering connections. Both are legitimate motivations. The mistake is treating the transit gateway as a drop-in replacement rather than an architecture decision with its own trade-offs.
VPC peering is free for same-region traffic, excluding data transfer costs. AWS Transit Gateway, by contrast, charges both an hourly attachment fee and a per-GB processing fee for every gigabyte that passes through it. In the Sydney region (ap-southeast-2), the attachment cost per VPC runs to roughly $0.07 per hour, and transit gateway data processing adds on top of standard data transfer charges. A team with 20 VPCs moving significant east-west traffic between them can see the transit gateway line item overtake the cost of the workloads themselves.
Azure's Virtual WAN and GCP's Network Connectivity Center follow similar pricing models. The throughput charges are not hidden, but they're buried in pricing calculators that teams rarely run before committing to the architecture. This is closely related to the broader cloud egress cost problem Australian teams face, where the unit economics of data movement only become visible after the invoice arrives.
Routing table complexity: the real operational risk
Transit gateway routing tables are where most operational problems live. Each attachment (VPC, VPN, Direct Connect, or another gateway) can be associated with one routing table and can propagate its routes to one or more tables. That sounds manageable. It stops being manageable when teams have multiple environments (production, staging, dev, shared services) and want to enforce isolation between some of them while allowing connectivity between others.
The failure mode is predictable. A team starts with a single routing table for everything, realises dev and prod are fully routable to each other, then tries to retrofit isolation by creating additional routing tables. The retrofitting breaks assumptions baked into DNS configurations, security group rules, and application connection strings that nobody documented. The resulting change is more disruptive than starting from scratch would have been.
Get the routing table design right at the start. Production VPCs should sit in their own routing table with no association to dev or staging attachments. Shared services (DNS, monitoring, Active Directory) get a separate table that production and non-production tables can both reference. A blackhole route for RFC 1918 space is a useful safety net: traffic that doesn't match a more specific route drops cleanly rather than hairpinning through an unexpected path.
Common misconfigurations and how they surface
Three misconfiguration patterns show up repeatedly in Australian environments:
- Asymmetric routing through inspection appliances. Teams route traffic through a security inspection VPC (running a firewall or IDS) in one direction but not the return path. The stateful firewall drops return traffic. This surfaces as intermittent connection failures that correlate with the firewall's state table, making it look like a capacity problem.
- Overlapping CIDR blocks. Transit gateways can't route between two attachments that advertise the same prefix. Teams that issued VPC address space from different cloud accounts without central coordination hit this immediately when trying to connect them.
- Propagation without scoping. Enabling route propagation from all attachments into a shared routing table means every attachment can reach every other one. This is fine for small environments and quietly catastrophic for larger ones where the intent was segmentation.
The overlapping CIDR problem deserves particular attention for Australian organisations with hybrid setups. Direct Connect or VPN connections into a transit gateway carry on-premises prefixes. If those prefixes overlap with any VPC CIDR, the gateway silently prefers one over the other based on route specificity and propagation order. The result is traffic blackholing that's extremely difficult to trace without inspecting the effective route table for each attachment. Good logging discipline in distributed systems is the fastest way to surface these routing anomalies before they become production incidents.
Inter-region peering and its cost implications
Transit gateway inter-region peering lets you connect two regional transit gateways and route traffic between them. For Australian organisations with workloads in ap-southeast-2 (Sydney) and ap-southeast-4 (Melbourne), this is an obvious capability to reach for. The inter-region peering charge adds to the already non-trivial per-GB processing fees, so the economics need deliberate analysis before deployment.
A workload that replicates large datasets between Sydney and Melbourne (database replicas, object storage sync, log aggregation) will accumulate significant charges through a transit gateway peer. Direct VPC peering between specific VPCs across regions is cheaper for these high-volume, point-to-point flows. Transit gateway inter-region peering is most justified for complex topologies where many VPCs in one region need access to many VPCs in another, and the routing table simplification outweighs the per-GB overhead.
Run the numbers for your actual traffic profile before deciding. Cloud providers publish inter-region data transfer prices and transit gateway processing fees separately. You need both.
When to use transit gateway and when not to
Transit gateways make sense when an environment has more than 10 VPCs that need mutual connectivity, when on-premises connectivity needs to be shared across multiple VPCs, or when centralised routing control (for inspection or compliance logging) is a firm requirement.
Skip the transit gateway when the connectivity requirement is between a small number of VPC pairs, when traffic volumes between VPCs are high enough to make processing fees substantial, or when the environment is early-stage and likely to restructure. In those cases, VPC peering is cheaper, simpler, and easier to reason about.
For AWS-specific deployments, cloud networking decisions in Australia often hinge on latency and compliance requirements that change the right answer for a given workload. Transit gateways are an availability-zone-aware resource: an attachment in one AZ doesn't automatically get optimal routing through the gateway for traffic originating in another AZ. Cross-AZ transit gateway traffic incurs AZ data transfer charges on top of the gateway processing fee. For latency-sensitive workloads, this makes the architecture more expensive than the pricing page suggests.
Practical steps before you commit
Before provisioning a transit gateway, document the connectivity matrix your environment actually needs. List every VPC, every on-premises network, and every inter-account connection. Mark which pairs need to communicate and which must stay isolated. That matrix drives the routing table design directly, and it surfaces CIDR conflicts before they become outage root causes.
Estimate the data transfer volume for each path in the matrix. Multiply by the transit gateway processing rate and the relevant data transfer rate. Compare this against the cost of point-to-point VPC peering for the same paths. For most environments, a hybrid approach is correct: transit gateway for the general fabric, direct peering for the highest-volume specific flows.
Assign ownership of the transit gateway routing tables to a specific team. Gateway routing tables have a way of accumulating entries added by different teams for different purposes, with nobody tracking the full picture. Treat the routing table as infrastructure-as-code from day one, peer-reviewed the same way application code is reviewed. Six months after adoption, a transit gateway whose routing tables aren't in version control is one configuration mistake away from a network partition.