description: An index to the isp6 reference-architecture series: how to land your /48 or /44 on AWS, Microsoft Azure, Google Cloud, or your own data centre, with cross-provider terminology mapping, a depl

Reference Architectures: An Overview

Audience: isp6 members and cloud, platform, and network architects who have already chosen a /48 or a /44 (see Sizing: /44 vs /48) and are deciding where to land it and what production topology to build. This page is the index for four deeper, provider-specific reference architectures.

Last updated: May 2026

1. How to use this section

The four reference-architecture articles linked from this page each cover a single deployment target (AWS, Azure, Google Cloud, or an on-premises / colocation data centre) and each shows two production topologies (a single-site and a multi-site pattern). They sit between two other parts of the knowledge base:

• Before this section: Sizing: /44 vs /48 decides how much address space you need. Address Planning decides how to carve it up internally. Bring Your Own IPv6 to AWS, Azure, and Google Cloud explain the BYOIP mechanics: ROAs, ownership verification, the lifecycle of pending-provision → provisioned → advertised.
• This section: where to land your space and what to build once the BYOIP prerequisites are met. Read the cross-provider material on this page first, then jump into one of the per-target articles.

These articles assume the BYOIP work has already happened (or will be tracked separately) and focus on the topology you sit on top of it.

2. The constellation: one allocation, many targets

A single isp6 /44 fits cleanly across all four target environments at the same time, and the per-target /48 stays the unit that the public internet routes from each location.

Two properties of this picture are worth pulling out:

• Independent lifecycles. Provisioning the Azure /48 has no effect on the AWS /48. Withdrawing the GCP /48 has no effect on the DC /48. Each target is its own BGP-origin event, governed by its own provider's tooling.
• One source of truth. The inet6num, route6, and ROA records that authorise every one of those advertisements all live in the RIPE Database and are managed by isp6 on your behalf. Adding a new target means adding a new ROA through your isp6 dashboard, not a new RIR engagement.

3. Cross-provider terminology mapping

The four targets use very different vocabulary for what are often the same network constructs. This table is the Rosetta stone. It does not claim feature parity, but it tells you which concept to look for as you read the per-target articles.

Use it as a glossary as you switch between articles. The technical behaviour is similar everywhere. The names are not.

4. Deployment-mode decision aid

Most real estates are not one target. They are a combination of targets, chosen along three axes. Use this short checklist to decide which combination is yours, then read the matching per-target article(s).

Three axes that should drive the choice, and that we revisit in each per-target article:

1. Routable-location count. Each independently-routable location needs its own /48. If that count is greater than one, you almost certainly want a /44 (see Sizing: /44 vs /48).
2. Operational coupling. A single global VPC (GCP) couples regions tightly; independent VPCs / VNets with explicit peering (AWS, Azure) keep them loosely coupled. Pick the model that matches how your teams operate, not the model that looks the simplest on a diagram.
3. Sovereignty and lifecycle. A /48 on your own DC is the answer when residency, hardware control, or "we will outlive any single cloud contract" matter, see Digital Sovereignty.

5. Reference architectures by target

Each article below is self-contained. They share the same shape: a single-site production topology, a multi-site production topology, the provider-specific nomenclature, and links back to the relevant BYOIP guide for the registration mechanics.

There is deliberately no "multi-cloud" article, because that pattern is the sum of the per-target articles, with one /48 per target carved out of a single /44. The constellation in Section 2 is the picture; the individual articles fill in the detail.

6. Reading the diagrams

Every per-target article uses the same visual grammar so you can read them in any order without re-learning it:

• The isp6 navy pill at the top of each diagram identifies the allocation you bring to the target, always a sample address inside 2001:db8::/32 (RFC 3849 documentation prefix).
• The provider boundary uses the provider's own brand colour as the stroke and a small mark in the corner that nods to the provider's logomark: the AWS smile cluster, the Azure four-square A, the Google four-colour ring, and a rack icon for the DC.
• VPC / VNet / global VPC is rendered in the provider's preferred networking hue: purple for AWS networking, Azure blue for Microsoft, Google blue for GCP, isp6 navy for the DC.
• Public subnets use a green family; private subnets use a teal family. Carries across all four providers so subnet posture is the same to read everywhere.
• The "advertise" arrow terminates in the same neutral grey Public Internet pill in every article, the unifying element that makes the four targets comparable.
• A legend at the bottom of every diagram names every shape.

Each SVG ships with a matching dark variant; the page swaps to it automatically when you toggle the theme in the top bar.

7. Scope, limits, and disclaimer

These reference architectures are deliberately opinionated and simplified. A few things they are not:

• Not a substitute for the provider's own Well-Architected guidance. Each diagram shows the IPv6 / BYOIP topology, the layer that's specific to bringing your isp6 allocation. The hundreds of other architectural decisions (compute shape, storage, identity, observability, FinOps) are out of scope. Read AWS's Well-Architected Framework, Microsoft's Cloud Adoption Framework and Well-Architected Framework, and Google's Cloud Architecture Framework alongside.
• Not a snapshot you can blindly diff against a provider's product roadmap. Cloud provider features change. ASN numbers, prefix-size constraints, and the names of the constructs in Section 3 evolve. Each article carries its own Last updated date and links to the authoritative documentation for the moving parts.
• Not a Terraform / Bicep / gcloud recipe. The BYOIP guides (AWS, Azure, Google Cloud) cover the provisioning side. These articles cover topology and the why.
• Not a security model in itself. Public/private subnet split is one input to a security posture. NSGs, security groups, firewall rules, route maps, RPKI, prefix-list filters, and a competent incident-response plan are the rest of it.

If a per-target article's diagram disagrees with a provider's current product documentation, trust the provider's documentation and let us know so we can update.

8. Further reading

isp6 knowledge base

• Sizing: /44 vs /48: sizing by site count, with the /48 routing boundary explained
• Planning Your isp6 Allocation: the bit-budget companion; how to carve the inside of an allocation
• IPv6 Prefix Chart: quick prefix-size reference
• Designing the Next Internet: An Introduction to IPv6: address anatomy, scopes, the /64 boundary
• Stop Thinking in IPv4: the IPv4 reflexes to unlearn before you read these architectures
• BYOIP mechanics, per provider: AWS, Azure, Google Cloud
• Digital Sovereignty: context for the on-prem / hybrid case

Authoritative provider architecture frameworks

• AWS Well-Architected Framework
• Microsoft Azure Well-Architected Framework
• Google Cloud Architecture Framework

RIPE NCC and IETF

• RFC 3849: IPv6 Address Prefix Reserved for Documentation
• RFC 6177: IPv6 Address Assignment to End Sites
• RFC 7454: BGP Operations and Security

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.