AKS Platform Architecture — Non-production and Production

Diagram 1

Non-production target architecture

Two private AKS clusters, dev and test, each in its own resource group and its own Terraform workspace. Everything they share — the private DNS zones, one container registry, and the Key Vault and App Configuration pair per environment — lives in a single platform resource group alongside the fleet. dev and test keep separate configuration because they are meant to differ; they share the registry because an image should be built once and promoted, distinguished by tag rather than by which registry it sits in.

Standalone vector file: 01-nonprod-architecture.svg

Diagram 2

Edge — Front Door Premium

Both clusters are private and neither has a public listener, so public traffic arrives through one Azure Front Door Premium profile and reaches the internal ingress load balancer over Private Link. Premium matters here: the Standard tier cannot use a Private Link origin. TLS terminates at the edge on an Azure-managed certificate and the hop to nginx is plain HTTP inside the Microsoft backbone, which is why the origin Host header is set on each origin rather than once on the route. The second cluster joins as a second origin in the same origin group, with its own Private Link Service — equal priority load-balances between the two, a different priority turns it into failover.

Standalone vector file: 02-edge-front-door.svg

Diagram 3

Address plan

Non-production uses one spoke, twcoredevmainbecvnet, with address space 10.56.0.0/14. Subnets are allocated in list order from the front of that block: ACR PE, AKS system, apps (ingress ILB 10.56.1.122), pods, snet-pe, then a reserved automation subnet. A second cluster does not get a second VNet — it appends from 10.56.4.48. The bar zooms the first /21, where every address in use today sits; the rest of the /14 is free.

Standalone vector file: 03-network-layout.svg

Diagram 4

Fleet update flow

Fleet Manager is used purely to orchestrate upgrades — there is no hub cluster, so no additional control plane to pay for or secure. A single update run walks the clusters in a fixed order: dev first, a 300 second soak, then test. Runs are created in a NotStarted state and must be triggered explicitly, so an infrastructure deployment can never upgrade a running cluster as a side effect.

Standalone vector file: 04-fleet-update-flow.svg

Diagram 5

Production — next phase

Production reuses the same Terraform modules and the same private-only posture, with two clusters behind one fleet. It runs on its own spoke VNet: no non-production deployment can reach production networking, and each side owns a complete set of private DNS zones — a VNet can only be linked once per privatelink namespace, so separate VNets remove that constraint instead of working around it. Configuration is the second difference: production runs a single Key Vault and a single App Configuration shared by both clusters, because both must behave identically and a second copy would only introduce drift. In code this is one list variable, not a forked module.

Standalone vector file: 05-prod-architecture.svg

Diagram 6

Delivery sequence

The current pvt and sbx environments are removed before the new build starts. They are not redundant infrastructure that can be left running in parallel: they occupy the address ranges, the private endpoint subnet and the private DNS zone links that the new environments need. Steps 2 and 3 carry no risk to anything running; step 1 is the only destructive one, and it applies to non-production only.

Standalone vector file: 06-cutover-sequence.svg

Azure service icons are the official Microsoft Azure architecture icon set, used for architecture documentation. Diagrams are generated from docs/architecture/generate.py — edit the script and re-run it rather than hand-editing the SVG files.