Building an Azure Regional Catalog for Belgium Central

When you’re working in Belgium and designing Azure architectures, one question comes up more often than you’d expect: what’s actually available in Belgium Central, and how does it compare to the regions you’d normally default to?

West Europe has been the go-to for years. It’s mature, well-stocked, and covered in documentation. Belgium Central (belgiumcentral) is newer, and while Microsoft has been steadily expanding its footprint there, the reality is that not every SKU or service lands at the same time across regions. If you’re trying to justify a Belgium Central deployment (whether for data residency, latency, or sovereignty reasons) you need a way to quickly see where the gaps are.

That’s what this tool is for. You can find it at abc.midp.cloud.

What the tracker actually does

The Azure Regional Catalog is a daily-updated static dashboard that pulls two distinct types of data from Azure’s APIs and presents them side by side across four regions: Belgium Central, West Europe, Germany West Central, and — as of the latest round of updates — Sweden Central.

There are two separate data sources, and it’s worth understanding the distinction:

Pricing Catalog - pulled from the public Azure Retail Prices API. No authentication needed. This tells you what Azure charges for a given service or SKU in a region. It covers all Azure service families: Compute, Storage, Databases, Networking, AI, Containers, and more — and, as of recently, both Pay-As-You-Go and Reservation (1yr/3yr) pricing, in either USD or EUR via a toggle.
Compute Availability - pulled from the Azure Compute Resource SKUs API. This one requires a service principal with access to an Azure subscription. It tells you which VM SKUs your subscription is permitted to deploy in a region, and if something is blocked, it includes the restriction reason.

The dashboard is organised into five pages:

Overview - a summary card per region showing the total number of priced offers and available VM SKUs, broken down by service domain.
Region - drill into a single region’s full pricing catalog (filterable by domain, with the USD/EUR and Pay-As-You-Go/Reservation toggles) and compute availability table. This used to be a separate page per region; it’s now one page with a region dropdown at the top, which is just a nicer way to flip between the four regions without extra nav clutter.
Compare Regions - side-by-side comparison across all four regions, highlighting rows where availability or pricing differs between them. This is the most useful view when you’re trying to spot what’s missing in Belgium Central versus West Europe. The comparison data is precomputed server-side now rather than shipping every region’s full raw catalog to the browser, so the page loads a lot faster than it used to.
Digital Sovereignty - covered below.
About - a single page collecting the data-source explanation, caveats, and disclaimers that used to be repeated in every page’s footer.

One more small addition: rows in the Region page’s pricing table that have had more than one recorded price now show a little 📈 hint with the price history on hover — the tracker started keeping an append-only price history per meter, so this will get more useful the longer it runs.

What you can and can’t learn from it

The pricing catalog data is reliable for understanding what Azure publishes for a region. If a service shows up in the pricing catalog for Belgium Central, Azure has at least priced it there. That’s a useful signal, as it means the service exists in that region in some form.

What it doesn’t tell you is whether that service is actually deployable for your subscription. Pricing catalog entries are global and subscription-agnostic.

Compute availability is more nuanced. The tool collects this data from a specific subscription, so the results are subscription-scoped. A SKU showing as “Available” means it’s permitted for that subscription in that region, not necessarily for yours. Subscription type matters here: MSDN/Visual Studio subscriptions, for example, often have restrictions that a standard pay-as-you-go subscription doesn’t.

There’s also one important thing the tool explicitly cannot tell you: real-time capacity. Azure doesn’t expose a public API for live capacity. “Available” in the compute table means the SKU is permitted, it doesn’t mean Azure has physical capacity to fulfill a deployment right now. Constrained regions like West Europe frequently return SkuNotAvailable or allocation failures at deploy time even when a SKU appears as available. The only real way to confirm capacity is to attempt (or reserve) the deployment.

In short:

Good for spotting pricing gaps, identifying which services are priced in Belgium Central, comparing VM SKU availability across regions at a glance, and getting a rough sense of whether a 1yr/3yr Reservation is worth it for a given SKU
Not suitable for making final deployment or purchasing decisions without verifying in the Azure Portal or via the az CLI first

Digital sovereignty

One of the reasons Belgium Central comes up in architectural discussions is data residency. Belgian and EU organisations increasingly need to demonstrate where their data lives and who can access it, and simply picking West Europe because it’s familiar doesn’t always cut it anymore.

The sovereignty view in the tracker is a filtered version of the compare view, narrowed down to the services most relevant to regulated workloads. It’s organised around four areas that map to Microsoft’s Cloud for Sovereignty guidance:

Data residency and operational autonomy - storage accounts, SQL Database, SQL Managed Instance, Cosmos DB, Data Lake, Azure Arc, and Azure Stack. These are the services where you need to be confident data stays in a specific geography and that you retain operational control.
Confidential computing - confidential VMs (DCsv, DCasv, ECasv series), trusted launch, and SGX-backed SKUs. These keep data encrypted while it’s being processed, not just at rest or in transit.
Encryption and key management - Key Vault, Managed HSM, and Dedicated HSM. The ability to use customer-managed keys (CMK) or hold-your-own-key (HYOK) arrangements is often a hard requirement for regulated sectors.
Compliance and policy controls - Azure Policy, Microsoft Purview, Microsoft Sentinel, and Microsoft Defender for Cloud. These are the governance and monitoring layers that let you demonstrate continuous compliance rather than just point-in-time audits.

The view uses the same pricing catalog and compute availability data as the rest of the tool, just filtered to these categories and compared side by side across all four regions. If a confidential VM SKU is available in West Europe but not in Belgium Central, it shows up highlighted.

It’s worth being clear about what this doesn’t cover. The tracker has no visibility into Microsoft Cloud for Sovereignty add-ons like the Sovereign Landing Zone policies, the EU Data Boundary programme, or sovereignty transparency controls. It also doesn’t cover national or government clouds. Those require direct engagement with Microsoft and can’t be surfaced through the public APIs this tool relies on. The sovereignty view is useful for checking service and SKU availability as a starting point, but it’s not a substitute for a proper compliance assessment.

How it’s built

The stack is deliberately minimal. There’s no framework for the frontend, just plain HTML, CSS, and vanilla JavaScript served as a static site. The data files are JSON, committed to the repository by a daily GitHub Actions workflow.

Data collection is handled by a TypeScript collector (scripts/collect/) that runs on a schedule at 06:00 UTC. It queries both Azure APIs (now in both USD and EUR, and including Reservation terms), normalizes the results, and commits any changed JSON files directly to main. The git history becomes a full audit trail of how regional availability changes over time — and now that per-meter price history is tracked explicitly, spotting a price change doesn’t require digging through git blame either. API calls also retry with backoff on transient failures now, and if a region genuinely fails to collect, the workflow run shows up as failed instead of quietly succeeding with partial data.

The dashboard (web/) reads those JSON files at runtime via fetch(). The build step just copies the HTML/CSS/JS and the data directory into dist/. No bundler, no SSR. The Compare and Sovereignty pages used to fetch every region’s full raw catalog client-side; that comparison data is now precomputed by the collector instead, so the browser just fetches one small pre-joined file per page.

Deployment is via Cloudflare Pages, which rebuilds and redeploys the site on every push to main. Combined with the daily data collection commit, the dashboard stays at most 24 hours behind Azure’s actual state.

The service domain classification (Compute, Storage, Databases, Networking, Analytics & Data, AI & Machine Learning, Security, Containers, etc.) is handled by an explicit rules-based mapper in TypeScript, so there’s no ambiguity about which category a given Azure service lands in.

The look and feel also just got ported over to match this site — same color tokens, same Inter font, same dark mode toggle. Still plain static HTML/CSS/JS under the hood, no Astro; just borrowed the design system rather than the framework.

It’s a fairly niche tool, but if you’re regularly working with Azure in Belgium or evaluating Belgium Central as a deployment target, having this kind of reference available without digging through the Azure Portal every time is genuinely useful. The compare view in particular has saved me more than a few back-and-forth checks when scoping out a new workload.