> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/elastic-compute/01-overview/03-eip.md).

# EIP to HAVIP

A HAVIP is a **private** IP resource. It lives inside a subnet, and on its own it is reachable only from within the VPC — which is exactly what many HA designs want. To make the highly available service reachable **from the internet**, you bind an **Elastic IP (EIP)** to the HAVIP.

These are two separate, independently usable capabilities:

* **HAVIP alone** — a private floating IP. Internal HA, reachable only inside the VPC.
* **HAVIP + EIP** — the same private floating IP, now also fronted by a public address. Internet-facing HA.

A HAVIP is not born with public access and does not need it. Bind an EIP only when the service genuinely faces the internet.

![An EIP fronts the HAVIP; public traffic reaches whichever instance currently holds it](/files/8EECUtqm2s9f2LYtFwej)

***

## Keep It Private, or Add an EIP

**Stay private** when the HA endpoint is consumed only by other resources in the VPC — no EIP needed:

* **Internal load balancer.** A self-built LVS tier serving an HA virtual service to backends in the same VPC.
* **Internal Kubernetes endpoint.** A control-plane or Service VIP that must stay on the private network.
* **Database / stateful-service VIP.** A primary/replica pair that application servers reach over a stable private address.

**Add an EIP** when the service must be reachable from the internet:

* **Self-built public load balancer.** Your own LVS or HAProxy tier accepting traffic from public clients.
* **Public-facing HA gateway or proxy.** An internet-facing API gateway or edge proxy you run as an active/standby pair.

The division of labor is always the same: **the HAVIP provides failover; the EIP provides public reachability.** Layering them gives you an internet-facing endpoint that survives instance failure.

***

## How the EIP and HAVIP Work Together

The EIP is bound to the **HAVIP** — to its virtual IP — not to any one instance's vNIC. That single fact is what makes the combination failover-safe, and it governs traffic in both directions.

### Inbound — internet to the current holder

1. A public client sends traffic to the EIP.
2. The EIP forwards it to the HAVIP's private virtual IP.
3. From there it follows the normal HAVIP path — it reaches whichever instance currently holds the HAVIP.
4. On failover the holder changes and the network re-points the HAVIP (see [How a HAVIP Works](/welcome/elastic-compute/01-overview/02-how-it-works.md#how-the-network-follows-the-holder)). **The EIP binding does not change** — it points at the HAVIP, not at an instance — so the public address is unaffected.

```
   Internet
      │
      ▼
   ┌─────┐      ┌─────────────────┐      ┌───────────────────────┐
   │ EIP │ ───▶ │ HAVIP 10.0.1.50 │ ───▶ │ current holder (vm-A)  │
   └─────┘      └─────────────────┘      └───────────────────────┘
                         │                 on failover ──▶ vm-B
                         └── the EIP is bound to the HAVIP, so it
                             survives the holder changing
```

### Outbound — the HAVIP is the public identity

The binding also governs traffic the HA service *originates*. When the instance holding the HAVIP reaches the internet through this EIP, the packet is **sourced from the HAVIP** — its private source address is the HAVIP's IP, not the instance's own private IP, and on the internet it appears as the EIP.

The practical consequence: the HA pair presents **one stable public identity in both directions**. Inbound and outbound traffic both ride the same EIP, and that identity does not change when the holder fails over. For a public gateway or proxy — where the remote side may pin firewall rules or allow-lists to your address — this is what you want.

***

## Rules for the Binding

| Rule                  | Detail                                                                              |
| --------------------- | ----------------------------------------------------------------------------------- |
| **Same region**       | The EIP must be in the same region as the HAVIP.                                    |
| **EIP must be free**  | The EIP has to be available — not already bound to another resource — at bind time. |
| **One EIP per HAVIP** | A HAVIP is fronted by a single EIP.                                                 |
| **Bind to the HAVIP** | The EIP attaches to the HAVIP itself, not to one instance's vNIC.                   |

!!! warning "Bind the EIP to the HAVIP, not to one instance" To get failover-safe public access, the EIP must be bound to the **HAVIP**. If you instead bind an EIP directly to one instance's vNIC, that EIP is pinned to that instance — when it fails, the public address fails with it, and the HAVIP failover underneath buys you nothing on the public path. The EIP and the HAVIP must move as one unit, and they do so only when the EIP is bound to the HAVIP.

***

## What's Next

* [**Use Cases**](/welcome/elastic-compute/01-overview/04-use-cases.md) — public and private deployment patterns, end to end.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.console.zenlayer.com/welcome/elastic-compute/01-overview/03-eip.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.