Multi-cloud with one address space: patterns and pitfalls

Holding one IPv4 block and using it across several clouds keeps addressing consistent and makes your space portable. It also brings routing and registry details that single-cloud setups never meet. This article covers the patterns that work, the conflicts to avoid and the failover limits you should plan around.

The basic pattern: one /24 per provider

The /24 is the practical unit for multi-cloud BYOIP. It is the smallest prefix AWS, Azure, Google Cloud and OVHcloud accept, and the smallest prefix most networks accept in the global routing table. A single /24 cannot sensibly be shared between providers, because only one of them should announce it.

A /22 shows how this works in practice:

• First /24: announced by AWS.
• Second /24: announced by Azure.
• Third /24: announced by Google Cloud.
• Fourth /24: used on your own network or OVHcloud, or held in reserve.

Each provider sees only its own /24 and announces it independently. Your address plan, not any one provider’s console, is the record of which range lives where.

Provider limits shape the plan:

• AWS takes a /24 minimum and allows 5 ranges per Region by default.
• Azure custom IP prefixes run from /21 to /24.
• Google Cloud advertised prefixes run from /16 to /24.
• OVHcloud accepts /24 to /19.

ROAs: one per provider ASN

Every /24 needs a ROA naming the ASN of the provider that announces it: Amazon’s ASNs for AWS, AS8075 for Azure, AS16276 for OVHcloud and the origin given in Google Cloud’s BYOIP instructions.

The trap to watch for is a covering ROA. If you create a ROA for the whole /22 with your own ASN and a max length of /22, any /24 a cloud provider announces without its own matching ROA becomes RPKI-invalid. Networks that enforce route origin validation will drop it, and part of the internet will lose that range.

Rules of thumb:

• Create one ROA per /24 per origin ASN, with a max length of /24.
• Only issue a ROA for the aggregate if you actually announce the aggregate, and keep its max length at the aggregate’s size.
• Mirror each ROA with a route object in the RIPE Database for networks that filter on IRR data.
• Remove ROAs and route objects when a /24 leaves a provider.

Announcement conflicts to avoid

Problems start when two networks announce overlapping space without a plan.

• Same /24 from two providers. Each remote network picks a path by its own routing policy, so some users reach one cloud and some reach the other. Sessions break and troubleshooting is slow, because the result depends on where the user is.
• Aggregate plus more-specifics. If you announce the /22 from your own network while clouds announce /24s inside it, the more-specific /24s win wherever they are accepted. That can work as a deliberate fallback, but if a cloud stops announcing its /24, traffic for that range lands on your network, which must be ready to handle or drop it.
• Leftover announcements. An old provider or transit network still announcing a range competes with the new one. Check the routing table before and after every move.

The limits of failover

It is tempting to treat one address space as a failover mechanism: if one cloud has a problem, move its /24 to another. That is not something to rely on at incident speed.

• The destination provider must already have the prefix provisioned and validated. Provisioning is not instant, and on Google Cloud it takes weeks.
• A /24 should only be announced by one provider at a time, or you get the conflicts described above.
• Workloads, firewall rules and reverse DNS in the destination cloud must already be built for those addresses.

If you want a standby arrangement, ask each provider whether a prefix can be prepared without being announced, and test the switch in a planned window before you depend on it.

A more dependable pattern is to run active services in each cloud on their own /24 and fail over at the DNS or application layer. Addresses stay stable, each provider announces only what it owns, and failover becomes a DNS change rather than a routing event.

Keep the operational side in order

Multi-cloud address space needs more bookkeeping than a single provider:

1. One authoritative address plan listing each /24 with its provider, ROA, route object, validation record and reverse DNS delegation.
2. Regular checks that what is announced in the global table matches what the plan says.
3. Blocklist monitoring across all ranges. Some blocklists list wider ranges, so abuse in one /24 can affect its neighbours.
4. A written procedure for moving a /24, so every change follows the same order: new ROA and route object, new announcement, old announcement withdrawn, old records removed.

Our subnet calculator is useful when you split a larger block on clean boundaries.

How TACS can help

TACS prepares ROAs, route objects and validation records for each provider, so one block can be split across clouds through our BYOIP support. If you need more /24s to complete the plan, we can help you buy IPv4 or lease IPv4.