What it is
BGP is the routing protocol networks use to tell each other which address ranges they can reach. It is a path vector protocol, so every route carries the list of autonomous systems it passed through. That list, the AS path, does two jobs. It is the main way BGP chooses between competing routes, and it prevents loops, because a router drops any route that already contains its own AS number.
An autonomous system is a network under one routing policy, identified by an AS number. Public ASNs come from a regional internet registry. Private ranges exist for internal use: 64512 through 65534, and 4200000000 through 4294967294. When two different ASNs exchange routes, that is eBGP. When routers inside the same AS do it, that is iBGP, and it behaves differently. It does not add to the AS path, and it does not pass routes learned from one internal peer to another, so you need a full mesh or a route reflector.
Cloud teams meet BGP more often than they expect. A VPN or dedicated link to a cloud provider almost always runs BGP to exchange prefixes. On AWS the customer gateway and transit gateway speak it. On Azure it is the VPN gateway or Azure Route Server. On Google Cloud it is Cloud Router, and on Oracle Cloud it is the dynamic routing gateway. If you run your own edge routers or anycast services, you work with it directly.
How it works
Two routers form a BGP session by opening a TCP connection to port 179 and exchanging OPEN messages with AS numbers and capabilities. Then they send keepalives. After that, each side sends UPDATE messages carrying prefixes plus attributes. The session is long lived, and session state, not a ping, is what tells you whether the peer is healthy.
When several routes point at the same prefix, BGP follows a fixed order. Highest local preference wins first, then shortest AS path, then lowest origin type, then lowest MED, then eBGP over iBGP, then the closest next hop by interior routing metric, and finally the lowest router ID. Knowing that order is most of the job. Local preference is set inside your AS to steer outbound traffic. AS path prepending and MED are how you influence inbound traffic, and they work only as far as your neighbors agree to honor them.
Real deployments need more than the base protocol. BFD gives fast failure detection instead of waiting for hold timers to expire. Maximum prefix limits stop a peer from sending you a full table by accident. Prefix lists and route maps filter inbound and outbound. Communities tag routes so a provider or your own policy can act on them. Graceful restart keeps forwarding while the control plane restarts. Route reflectors remove the need for every iBGP router to peer with every other one.
Why it matters for a business
For most companies the value is availability. Two links, two providers, and BGP failover mean an outage on one path does not take down your cloud connectivity. Without BGP you get static routes and manual cutovers. With it, a dead tunnel is withdrawn and traffic moves in seconds. The same mechanism lets you run active and passive paths on purpose rather than by accident.
It also controls cost and performance. Egress traffic that leaves through the wrong region or the wrong provider shows up on the bill and in latency. Route policy lets you send bulk traffic over a cheaper path and keep interactive traffic on the faster one. Anycast, which relies on BGP, advertises one address from several locations so users reach the nearest one, and it spreads attack traffic rather than concentrating it.
The risk side matters too. A single bad advertisement can black-hole traffic for your whole company, and a leaked route can send traffic where it should not go. Route policy, prefix limits and change review belong in the design, not in a cleanup task after launch.
Common mistakes
Not filtering. Accepting whatever a peer sends leaves you open to mistakes and to hijacks. Apply inbound prefix lists that allow only what you agreed, and outbound filters that stop you from advertising someone else's space. RPKI origin validation adds a check on top, and it is worth enabling where your providers support it.
Reusing one AS number on two sites that connect to the same provider. The provider sees its own AS in the path and drops the route. Use a different private ASN per site, or agree on a design with the provider that allows it.
Assuming inbound traffic follows your outbound choice. It does not. To steer inbound you need prepending, MED where the neighbor honors it, or provider communities, and you should test each one because provider policy varies.
Ignoring asymmetric routing, skipping maximum prefix limits, and running iBGP as a full mesh past a handful of routers. Also common: no monitoring of session flaps, so the first sign of trouble is a user ticket.
How to get started
Write down the prefixes you will advertise and the ones you expect to receive. Get an AS number and provider independent address space if you plan to multihome with your own addresses. Assign private ASNs internally with a simple naming scheme and record them in one place.
Build it in a lab first. Containerlab or a couple of small routers will let you test prepending, failover and filters before you touch production. Then apply changes in one direction at a time.
Monitor session state, prefix counts and route churn, not just reachability. Put BGP changes behind a review, and keep a runbook that says who to call when a session drops. If you want a second opinion on the design before you commit, the Cloudverg Expert architecture session at $450 one-time gives you 90 minutes with a senior architect plus a written summary.
Frequently asked questions
What is BGP in simple terms?
BGP is the routing protocol networks use to announce which address ranges they can reach and to pick the best path to them. Each route carries the list of networks it passed through, which is used both for path selection and loop prevention. Your cloud links and your internet connections most likely depend on it already.
Do I need BGP for a site-to-site connection to the cloud?
Not always, but you want it as soon as you have more than one path. A single link can run on static routes. Two links, two providers or a hybrid design with failover are far easier to operate with BGP, because dead paths are withdrawn automatically instead of needing manual cutover.
What is the difference between eBGP and iBGP?
eBGP runs between routers in different autonomous systems and adds the sending AS to the AS path. iBGP runs between routers inside the same AS, does not change the AS path, and does not re-advertise routes learned from one internal peer to another. That last rule is why internal designs use route reflectors or a full mesh.