AnyCast EIP
Use a Misaka.io-provided AnyCast EIP as one global service endpoint.
Misaka.io AnyCast EIP gives your service a public IP address from our address space. We manage the public route announcements, so you do not need to supply an IP prefix or operate public BGP. Each backend VM establishes a BGP session with our BGP speaker and announces the assigned address as a /32. You can use an ASN already configured through BYOASN or request a Private ASN from us.
Internet routing directs clients to one of the locations announcing the address. This gives a replicated service one stable public endpoint and can reduce the impact of a single-location network failure.
Private beta
AnyCast EIP is currently in private beta.
Bringing your own IP address?
This page only covers IP addresses we provide. To announce a prefix that you own or control, see our BYOIP / Public BGP Service and BGP / BYOIP guide.
AnyCast EIP or BYOIP?
| Feature | Misaka.io AnyCast EIP | BYOIP / BGP |
|---|---|---|
| Address space | Our address space | Your address space |
| Public route announcement | We manage it | Managed announcement or customer-operated BGP |
| Customer ASN | Existing BYOASN configuration or a Private ASN issued by us | Depends on the selected announcement model |
| IRR, RPKI, and authorization | We manage these for our address space | You must authorize your prefix |
| Customer BGP configuration | Required between each backend VM and our BGP speaker | Only for customer-operated BGP sessions |
How it works
- Purchase one or more VMs in the Supported Regions using the standard VM purchase flow.
- Purchase the AnyCast EIP add-on. We assign the address and provide the BGP peer parameters.
- Choose the ASN for the BGP session:
- If BYOASN is already configured for your account, use your own ASN.
- Otherwise, request a Private ASN in the BGP section and use that ASN.
- From each VM, establish a BGP session with our BGP speaker and announce the assigned AnyCast EIP as a
/32. - We advertise the address from each region where at least one VM is announcing the
/32. Once the route is active, the AnyCast EIP is ready to use.
You can configure multiple VMs in the same region. When they announce the same /32, traffic is distributed between them using ECMP. ECMP is not guaranteed across regions.
Failover
- Within a region: When a VM withdraws the
/32, new traffic is automatically routed to other VMs in that region that continue to announce it. - Across regions: When no VM in a region continues to announce the
/32, new traffic is routed to an active VM in a nearby region selected according to latency and current backbone load.
Cross-region protocol limitations
During cross-region failover, forwarding may be limited to TCP, UDP, and ICMP. Other IP protocols, such as GRE and IP-in-IP (IPIP), may be dropped.
Failover takes effect after the route withdrawal propagates. Existing connections may be interrupted.
Supported regions
| Area | Location | Closest AWS Region | Status |
|---|---|---|---|
| NA | Ashburn, VA | ~1 ms | Available |
| NA | New York Metro (Secaucus, NJ) | <10 ms | Available |
| NA | Miami, FL | <30 ms | Available |
| NA | Seattle, WA | <10 ms | Available |
| NA | San Jose, CA | <5 ms | Available |
| NA | Los Angeles, CA | <15 ms | Available |
| SA | São Paulo | <5 ms | Available |
| EU | Frankfurt am Main | ~1 ms | Planned |
| EU | Berlin | ~1 ms | Available |
| EU | London / Slough | ~1 ms | Available |
| EU | Amsterdam | <10 ms | Available |
| EU | Stockholm | ~1 ms | Planned |
| EU | Marseille | <10 ms | Planned |
| EU | Madrid | <5 ms | Planned |
| AP | Hong Kong | <5 ms | Available |
| AP | Taipei | <5 ms | Available |
| AP | Singapore | <5 ms | Available |
| AP | Tokyo | <5 ms | Available |
| AF | Johannesburg | <25 ms | Available |
Closest AWS Region is based on approximate geographic proximity. Latency is an estimated round-trip time (RTT) under normal conditions; actual latency and routing may vary and are not guaranteed.
Test IP addresses
Use these IPv4 addresses to compare routing behavior:
| IP address | Backend deployment |
|---|---|
201.4.3.0 | Backend VMs are deployed globally |
201.4.3.8 | Backend VMs are deployed only in Berlin, DE |
Good use cases
AnyCast EIP is a good fit when you need:
- One stable public IP address for a service deployed in multiple locations
- A globally reachable endpoint without supplying your own portable address space
- Regional ingress for stateless APIs, web frontends, DNS, reverse proxies, or service discovery
- Routing failover between equivalent service locations when configured
Every location should be able to provide an equivalent response. Keep application configuration and data synchronized between locations.
FAQ
Does AnyCast EIP support IPv6?
No. It currently supports IPv4 only. If you need IPv6, use our BYOIP / Public BGP Service.
Do you plan to support VMs outside Misaka.io?
No. AnyCast EIP depends on specific network architecture that is not available in every region we operate. For the same reason, we cannot support VMs outside our network.
Will traffic always reach the geographically closest region?
No. BGP selects paths according to Internet topology and routing policy. It does not guarantee the geographically closest region or distribute traffic evenly between regions. For operational background, see RFC 4786: Operation of Anycast Services.
What if I find a suboptimal case?
Routing optimization is provided on a best-effort basis. Some paths cannot be improved because your ISP or carrier controls part of the routing policy. For example, some Asian carriers prefer to peer outside their home markets and may charge very high fees for peering within or near their home markets.
You can submit an MTR trace from the affected network to the AnyCast EIP. We will investigate and make routing adjustments where possible, but we cannot guarantee that every suboptimal path can be resolved.
How does egress routing work?
Egress traffic follows the network type and Routing Profile of the VM handling the connection. If the instance uses Premium Plus, egress traffic uses Premium Plus when it is available for the destination carrier; otherwise, it falls back to Premium.
The ingress and egress paths may differ. This is expected.
What happens when a backend route is withdrawn?
New traffic is routed to another VM in the same region that continues to announce the /32. If no active route remains in that region, traffic moves to a nearby active region based on latency and current backbone load. This takes effect after BGP converges, so failover is not instantaneous. Existing connections can break if their path changes. Stopping the application alone does not withdraw its BGP route; couple route advertisement to service health if you need automated failover.
Can I use long-lived or stateful connections?
They can be used, but a routing change can interrupt an existing TCP or UDP flow. Applications should tolerate reconnection, and service state should be available in every active region.
Where is the BGP configuration guide?
Each backend VM must establish a session with our BGP speaker using your BYOASN configuration or a Private ASN requested in the BGP section. Use the peer parameters and permitted routes shown for the service. A step-by-step configuration guide will be published separately.
How should I monitor and maintain the service?
Monitor each backend through its unicast management path and monitor the AnyCast EIP from multiple external networks. Before planned maintenance, withdraw the affected backend route and wait for traffic to move away. Verify the backend before advertising the route again.
Related documentation
- BYOIP / Public BGP Service — for customer-supplied IP prefixes
- BGP / BYOIP — for customer-operated BGP sessions
- Network troubleshooting
How is this guide?
Last updated on