# Border Gateway ## What Is Border Gateway? Border Gateway is the managed edge router for your VPC. It exists for two jobs: * **Bridging VPCs that aren't otherwise connected** — two ZEC VPCs in the same account, two VPCs in different accounts, or a ZEC VPC and a network in another cloud. * **Exchanging routes dynamically** — learned routes from BGP (and reachability you configure on the gateway) are installed in your VPC route table and, if you choose, propagated across regions. A Border Gateway is attached to a VPC. Once attached, it's a routing element other routes can point at: instances in the VPC reach prefixes that are only reachable through the gateway, and prefixes from inside the VPC can be advertised outward. The gateway itself is a managed service — you don't run the control plane, you don't patch the router, and you don't provision the hardware that carries traffic. You configure what to advertise and what neighbors to peer with; the platform handles the rest. ![Border Gateway Overview](/files/M1hCPrsKbYT8Rd7DmpX8) *** ## How It Relates to Cross-Region Bandwidth Border Gateway and **Cross-Region Bandwidth** are two **independent products**. They solve different problems, and they are sold and configured separately. What they share is the underlying transport: both ride on Zenlayer's global private-connectivity infrastructure, so traffic they carry stays on the private backbone. The distinction is about **what kind of endpoints they connect**: | Product | What it connects | | ---------------------- | -------------------------------------------------------------------------------------------------- | | Cross-Region Bandwidth | Subnets of the **same VPC** across different regions | | Border Gateway | **Different VPCs** (same account or cross-account), or a ZEC VPC to a **network in another cloud** | If you want two instances in the same VPC to talk across regions, that's Cross-Region Bandwidth (and the default free baseline is usually enough). If you want two *different* VPCs — or a VPC and another cloud — to reach each other, Cross-Region Bandwidth cannot do that, and you need Border Gateway. *** ## When You Need a Border Gateway **You need two VPCs to reach each other.** Two ZEC VPCs are independent by default. Neither Cross-Region Bandwidth nor the VPC route table will bridge them. Attaching a Border Gateway to each VPC and exchanging routes between them is how they meet. **You need to reach a network in another cloud.** If your application has one foot in a ZEC VPC and another in AWS / Azure / GCP, Border Gateway is the cloud-side endpoint that establishes the BGP session and installs the other cloud's prefixes into your VPC route table. **You need dynamic route exchange across an organizational boundary.** VPCs in different accounts, different billing entities, or different teams can't rely on one side's static-route maintenance. BGP lets both sides advertise and withdraw prefixes without coordinating manual updates. **You want routes learned in one region to be visible everywhere.** Attaching a Border Gateway in a single region and setting it to global routing mode means prefixes learned there appear in every region's route table automatically. *** ## When You Don't Need a Border Gateway * **Reachability within a single VPC across regions.** Cross-Region Bandwidth (or the free default baseline) covers that — no Border Gateway needed. * **Egress to the internet.** Use a NAT Gateway. Border Gateway is for private network edges, not the internet. * **Load balancing or service exposure.** Use a load balancer. Border Gateway doesn't terminate or inspect application traffic. *** ## In This Guide | Page | What You'll Learn | | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------- | | [Scenarios](/welcome/elastic-compute/networking/01-overview-2/02-scenarios.md) | Common architectures where Border Gateway is the right tool | | [Dynamic Routing](/welcome/elastic-compute/networking/01-overview-2/04-dynamic-routing.md) | BGP peerings, what to advertise, what you learn back | | [Routing Modes](/welcome/elastic-compute/networking/01-overview-2/05-routing-modes.md) | Regional versus global routing and how to choose | | [Best Practices](/welcome/elastic-compute/networking/01-overview-2/06-best-practices.md) | Guidance and troubleshooting | *** ## Frequently Asked Questions **Do I need Border Gateway to talk to another VPC?** Yes. Cross-Region Bandwidth only connects subnets **within the same VPC** across regions — it does not bridge two VPCs. If you need two separate VPCs to reach each other (same account or different accounts), Border Gateway is the product. **Can one Border Gateway handle multiple BGP neighbors?** Yes. A single gateway can peer with multiple neighbors — another VPC's gateway, a partner in another cloud, a carrier — and merge their learned prefixes into the VPC route table. **Is Border Gateway highly available?** Yes, the gateway is redundantly provisioned and operated by the platform. You don't run an active/standby pair yourself. From your side, a Border Gateway looks like a single routing element; the redundancy is internal. **Does Border Gateway use security groups?** No. Security groups apply to public-network traffic on instances — they don't filter Border Gateway traffic. If you need access control between what a BG session makes reachable and the workloads behind it, that has to live inside the application or on an in-path appliance, not on the 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.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.