# Border Gateway Scenarios Border Gateway is a general-purpose edge routing object. Rather than describing every possible architecture, this page walks through the four scenarios that account for most deployments. They fall into two groups: * **Connecting your VPC to a network in another cloud** — the most common multi-cloud pattern. BGP runs between the ZEC Border Gateway and the other cloud's routing endpoint. * **Connecting two ZEC VPCs** — either within one account or across accounts. Two VPCs are always independent by default; Border Gateway on each side exchanges their routes. If your situation looks like one of these, the page tells you how to lay it out. If it doesn't, the underlying pieces ([dynamic routing](/welcome/elastic-compute/networking/01-overview-2/04-dynamic-routing.md), [routing modes](/welcome/elastic-compute/networking/01-overview-2/05-routing-modes.md)) still compose the same way. *** ## Connecting to Another Cloud The most common reason to bring in Border Gateway: a workload has components in ZEC and components in another cloud provider. Whether you need the connection from *one region* or from *every region* changes only the routing mode and the number of gateways. ### Scenario 1 — Another Cloud to a Single Region **What you're doing:** connecting a VPC in ZEC to a network in another cloud (AWS / Azure / GCP / other), so private workloads on both sides can communicate. Both sides run BGP. **How to lay it out:** 1. Attach a Border Gateway to the VPC in the region closest to the other cloud's endpoint. 2. Set up a BGP session between the other cloud's router and the Border Gateway. Traffic rides on Zenlayer's global private-connectivity backbone — you don't provision tunnels. 3. On the ZEC side, advertise the VPC subnets you want exposed — either all of them or a specific list. See [Dynamic Routing](/welcome/elastic-compute/networking/01-overview-2/04-dynamic-routing.md). 4. On the other cloud side, advertise the prefixes you want this VPC to reach. The Border Gateway learns them and installs them in the VPC route table as Dynamic Routes. 5. Leave the routing mode at **regional** — only this region needs to reach the other cloud. See [Routing Modes](/welcome/elastic-compute/networking/01-overview-2/05-routing-modes.md). **Why BGP:** Cloud route tables evolve — new subnets, renumbering, failovers. BGP tracks those changes without you touching the ZEC side. ![Another Cloud to a Single Region](/files/ckRQlEj8LUeF9AyZbd53) ### Scenario 2 — Another Cloud to Every Region (Hub) **What you're doing:** the same multi-cloud peering as Scenario 1, but every VPC region needs to reach the other cloud's prefixes. Rather than peering from each region, you centralize the BGP session in one hub region. **How to lay it out:** 1. Attach a Border Gateway in the region where the external peering lives. Call this the hub region. 2. Peer with the other cloud's router (and any other external neighbors) from that one gateway. 3. Set the Border Gateway's routing mode to **global**. See [Routing Modes](/welcome/elastic-compute/networking/01-overview-2/05-routing-modes.md). 4. Learned prefixes propagate through the private backbone to every region's VPC route table. Instances in any region reach the external prefixes. **Why this is useful:** you centralize external peering management. One BGP session to maintain, one place to change policy, one gateway to audit. The alternative — a Border Gateway in every region peering with the same external partner — works but multiplies operational overhead. **Trade-off:** traffic from a distant region transits the backbone to reach the hub region before exiting to the external peer. If latency from those regions to the external peer matters, a per-region gateway may be worth the extra complexity. ![Central Hub with Global Routing Mode](/files/Gk2gzM9HkNHruxeuFRoW) ### Scenario 3 — Multi-Cloud Interconnect with Multiple Providers **What you're doing:** connecting a ZEC VPC to more than one other cloud (AWS + GCP, for instance). BGP between two routers is the routing pattern; the transport underneath is the private backbone. **How to lay it out:** 1. Attach a Border Gateway to the VPC on the ZEC side. 2. Run a separate BGP session from the gateway to each cloud's router. 3. Advertise this VPC's subnets to each peer and learn that peer's prefixes back. **Watch out for:** address-space overlap across peers. If two other clouds both advertise `10.0.0.0/8` ranges that collide, BGP will still happily carry the routes — but traffic will go to the wrong place. Plan your address space before you peer. ![Multi-Cloud Interconnect over BGP](/files/1uVYYp0Eu2AZptFt698t) *** ## Connecting Two ZEC VPCs Two ZEC VPCs are independent by default. Even within one account, subnets of VPC A are not reachable from VPC B — Cross-Region Bandwidth connects subnets within a single VPC, not between VPCs. Border Gateway is how two VPCs exchange reachability. ### Scenario 4 — VPC-to-VPC via BGP **What you're doing:** two VPCs — same account or different accounts — need to exchange routes. Both sides run BGP so that prefix changes propagate automatically without hand-maintained route tables. **How to lay it out:** 1. Attach a Border Gateway to each VPC. 2. Run BGP between the two Border Gateways. Traffic rides on the private backbone. 3. Each side advertises the VPC subnets it wants to expose. Changes on either side propagate through BGP instead of being hand-maintained. **Why BGP for VPC-to-VPC:** * Cross-Region Bandwidth does not bridge VPCs — it only works *within* one VPC. * Hand-maintaining the other VPC's prefix list as manual entries doesn't scale as either side changes. * Where VPCs belong to different accounts, there's no single team to coordinate updates. ![Cross-Account Dynamic Routing with Two Border Gateways](/files/rDPiX9VEHCEtQfUgXF5s) *** ## Choosing Between Patterns | You want... | Pattern | | ------------------------------------------------------------------------ | ------------------------------------------ | | A ZEC VPC → one region reaching another cloud | Scenario 1, regional mode | | A ZEC VPC → VPCs everywhere reaching another cloud, single peering point | Scenario 2 (hub), global mode | | A ZEC VPC to multiple other cloud providers | Scenario 3 | | Two ZEC VPCs (same or different account) | Scenario 4 | | Multiple clouds and multiple VPCs all connected | Combine Scenarios 1/2 + 4 on a hub gateway | --- # 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-2/02-scenarios.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.