# Cross-Region Best Practices ## Keep related workloads in the same VPC Cross-Region Network connects subnets **within the same VPC**, across regions. If two workloads need to talk across regions, the cleanest setup is to put them in the same VPC and let the default mesh do the work. Splitting them into separate VPCs turns a same-VPC cross-region problem into a cross-VPC problem, which Cross-Region Network does not solve. The legitimate reasons to create a separate VPC are address-space isolation, strict blast-radius boundaries, or CIDR alignment with an external network. If none of those apply, keep workloads in the same VPC. ## Size paid bandwidth to peak, not average Cross-Region Bandwidth is a hard ceiling, not a burst cap. If your nightly replication needs 800 Mbps for three hours, a 400 Mbps purchase will shape the transfer and the job will miss its window. Size to the peak sustained rate and add 20–30% headroom. Re-evaluate when workload volumes change. ## Treat the free baseline as a reachability test, not a production pipe The free default bandwidth is intentionally small — it exists so you can `ping` between regions and measure latency on day one. It is not sized for real traffic. If anything more than a connectivity check is going over the pair, **raise Cross-Region Bandwidth** — the rate is adjustable from a few Mbps up to 10 Gbps and beyond, and you can change it at any time without dropping connections. ## MTU: use the 9000 default Most regions provision a 9000-byte MTU by default. Cross-region traffic is encapsulated over the backbone, and 9000-byte MTU accommodates the encapsulation overhead with room to spare — you don't need to clamp MSS or drop to a 1400-byte MTU for cross-region paths in those regions. A small number of regions run a smaller MTU. If you operate in one of them, check the subnet's advertised MTU before assuming jumbo frames end-to-end. When a cross-region path spans one of those regions, path MTU is governed by the smaller side. ## Don't try to peer subnets inside a VPC Subnets in the same VPC are already reachable to each other, same region or across regions. There is no peering step between them — if you find yourself looking for one, the model is different here than on other clouds. What you might be looking for is **Border Gateway**, which is the tool for bridging *different* VPCs. ## Review paid bandwidth periodically Cross-Region Bandwidth bills on the configured rate, not actual usage. An over-provisioned purchase from an old project is quiet waste. Review your Cross-Region Bandwidth purchases quarterly, confirm the workload still needs the configured rate, and drop the ones no longer serving traffic — the pair falls back to the free default mesh automatically. ## IPv6 works — use it where it makes sense Cross-Region Network carries both IPv4 and IPv6 inside the same VPC. If your application is dual-stack, the cross-region path doesn't force you to fall back to IPv4. Design your addressing plan around what your application needs, not around a network-stack limitation that doesn't exist. *** ## Troubleshooting **Two workloads in different regions can't reach each other.** First check they are in the **same VPC**. If they are in different VPCs, Cross-Region Network does not connect them — you need Border Gateway or a redesign. If they are in the same VPC, check OS-level firewalls on both instances before suspecting the network. The platform's security groups do not filter intra-VPC traffic (they're for public-network traffic), so they are not the cause of a cross-region failure. **Ping fails, but TCP to the remote instance works.** This is not a mesh problem. Something is blocking ICMP inside the guest — an instance firewall or an OS-level filter. The mesh itself does not drop ICMP. **Throughput is lower than I expected on a region pair.** If you have not raised the Cross-Region Bandwidth for that pair, you are on the tiny free baseline — it's meant for `ping` and latency checks, not throughput. Raise the bandwidth to the rate your workload needs. If you *have* raised it and `iperf3` tops out well below the configured rate, open a [support ticket](mailto:support@zenlayer.com) with both endpoint instance IDs and the timestamp. **A new subnet's prefix conflicts with an existing route.** A custom route already matches the prefix the platform wants to install for the new subnet. Navigate to **VPC → Route Tables**, find the conflicting entry, remove or renumber it, then retry. **Traffic works in one direction but not the other.** This is almost always an OS firewall or an application-layer policy on one end, not the network. Cross-region subnets are installed in the route table symmetrically — both sides see each other the moment the subnets exist. Check firewall state on the side that isn't answering. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.console.zenlayer.com/welcome/elastic-compute/networking/01-overview-1/05-best-practices.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.