Using IBM Cloud Transit Gateway to Simplify Multi‑VPC Connectivity

Problem: Managing many VPC‑to‑VPC links becomes tedious

When you operate several IBM Cloud VPCs in the same region, each new workload often requires a fresh VPN or VPC‑peering connection. Keeping track of CIDR‑based routes, security‑group updates, and separate billing for every link quickly turns into operational overhead.

Thesis: A regional Transit Gateway acts as a hub

Instead of wiring every pair of VPCs together, you attach each VPC to a single regional gateway. The gateway automatically routes traffic between attached spokes, removing the need for pairwise peering.

How Transit Gateway works

IBM Cloud Transit Gateway (TG) is a regional service. You create a single gateway in a region, then attach one or more VPC spokes by specifying the VPC ID and at least one subnet. Once attached, the gateway programs routes in each spoke’s route table so that any private IP in another spoke is reachable via the TG. The service is highly available across zones and does not charge extra for intra‑region traffic that stays inside the gateway.

Worked example: Connecting two VPCs in the same region

1. Prerequisites
   • IBM Cloud CLI installed and logged in (ibmcloud login).
   • You need the Network Administrator or Administrator IAM role on the target resource group.
   • Two VPCs (e.g., vpc-a and vpc-b) each with at least one subnet and a compute instance (e.g., a VSI) that you can ping.
2. Create the Transit Gateway

   ibmcloud tg create --name my-tg --region us-south --resource-group default

   Replace us-south with your region. The command returns a gateway ID, e.g., tg-1234abcd.

3. Attach the first VPC

   ibmcloud tg attachment-create \
     --gateway-id tg-1234abcd \
     --name vpc-a-attachment \
     --vpc-id <vpc-a-id> \
     --subnet-ids <subnet-a-id>

   You can repeat this step for additional subnets in the same VPC if you want multiple attachment points.

4. Attach the second VPC

   ibmcloud tg attachment-create \
     --gateway-id tg-1234abcd \
     --name vpc-b-attachment \
     --vpc-id <vpc-b-id> \
     --subnet-ids <subnet-b-id>

5. Verify route propagation

   ibmcloud tg route-list tg-1234abcd

   You should see entries pointing to the attached VPC CIDRs with the gateway as next hop.

6. Test connectivity

   Log into an instance in VPC‑A (via SSH or the console) and ping the private IP of an instance in VPC‑B:

   ping 10.10.20.5

   If you receive replies, the Transit Gateway is successfully routing traffic.

Trade‑offs and limitations

• Regional scope: A single TG only spans one region. To connect VPCs across regions you need additional gateways or a VPN link, which adds cost and complexity.
• Throughput ceiling: Each attachment is limited to 5 Gbps. High‑bandwidth workloads may require multiple gateways or alternative designs (e.g., Direct Link).
• Feature inheritance: Certain VPC‑specific settings such as floating IP reservations or security‑group references are not automatically shared across spokes; you must configure them manually in each VPC if needed.

Actionable next steps

If your architecture involves more than three VPCs in the same region, start by provisioning a Transit Gateway and attaching the VPCs with the highest inter‑traffic volume. Monitor traffic with IBM Cloud Monitoring to ensure you stay below the 5 Gbps per‑attachment limit, and add attachments or a second gateway if you observe sustained throttling.