Reference Architecture: HIPAA-Aligned Scheduling Platform on Azure

Illustrative scenario. A representative engagement shape, not a client deployment. Design and rationale are real and reusable; the company is not. Aligned to the Microsoft Cloud Adoption Framework and Well-Architected Framework.

1. Scenario and constraints

A healthcare services company of roughly 200 staff runs a patient-facing scheduling application on-premises: IIS on Windows Server, SQL Server back end. Their datacenter lease expires and cannot be renewed.

The team constraint carries as much design weight as the compliance one. A platform nobody can operate is not a working platform.

2. Subscription and environment topology

Following the CAF subscription decision guide. The subscription is the boundary for policy, quota and billing, so it is the unit of separation, not resource groups.

Four subscriptions, not the full enterprise-scale hierarchy. A 4-engineer team operating a nine-subscription landing zone spends its time on the landing zone. Dev and test share one subscription and separate by resource group and spoke; they have identical policy posture, so a subscription boundary between them buys nothing.

Environments: dev → test → prod, identical Bicep, different parameter files. No environment is deployed by hand.

3. Naming convention

Per CAF resource naming and abbreviations.

<resource-type>-<workload>-<environment>-<region>-<instance>

Storage breaks the pattern because it is globally unique, lowercase alphanumeric only, 3–24 characters. Every convention meets a resource that will not accept it — decide the exception once and write it down, rather than letting each engineer improvise.

Naming is enforced by Azure Policy, not by review. A convention that depends on someone noticing does not survive an on-call deployment.

4. Network design

Hub and spoke. Region East US 2, paired secondary Central US for zone and region resilience.

Contiguous /22 per spoke, allocated from a plan rather than on demand. Overlapping ranges discovered later are the most expensive networking mistake available, because the fix is a re-address under change control.

Egress is forced through Azure Firewall by user-defined route. One inspection and logging point, which is also the artifact the assessor asks for.

5. Design decisions

The constraint that shapes most of the table below is "PHI must not traverse the public internet." Traced end to end, the public segment stops at Front Door:

6. Resource inventory

7. Identity and access

• Microsoft Entra ID with SSO; on-prem AD synchronised during migration
• Privileged Identity Management for all owner and contributor roles — standing access is time-bound, not permanent
• Two break-glass accounts, excluded from Conditional Access, credentials sealed, sign-in alerted
• Application-to-database authentication via managed identity, no SQL logins
• Access reviews quarterly, exported as assessment evidence

8. Resilience: meeting the numbers

Failure modes tested, not assumed: zone loss, region failover drill, database point-in-time restore, and expiry of the Front Door certificate.

9. Cost: what dominates and what moves it

SQL Managed Instance Business Critical is the largest line item by a wide margin. Optimise it before anything else; tuning App Service while SQL runs unreserved is effort in the wrong place.

Cost is a design output, not a monthly surprise: budgets and anomaly alerts are provisioned by the same templates that create the resources.

10. Infrastructure as code

Bicep, built on Azure Verified Modules.

Why Bicep here. No state file to store, lock or corrupt — a real consideration for a team new to the platform. New Azure resource types are supported on release rather than waiting on a provider. The tradeoff is honest: Terraform is the better choice for a multi-cloud estate or an established module ecosystem, and we would recommend it in that case.

Pipeline. GitHub Actions authenticating by OpenID Connect federation — no service principal secret is stored anywhere.

pull request  →  bicep build + lint  →  what-if against target  →  plan on PR
merge to main →  deploy dev          →  smoke tests
                 deploy test         →  integration tests
                 deploy prod         →  approval gate

The what-if output is posted to the pull request, so the diff is reviewed before it is applied rather than discovered afterwards.

What this buys. Environment parity by construction — dev, test and prod differ only by parameter file, so "works in test" carries meaning. Rebuild from source is a routine operation rather than a recovery plan. And every infrastructure change arrives with an author, a reviewer and a reason attached, which is most of what an assessor wants from change management.

11. What changes if

12. What we deliver

• This topology as reviewed Bicep, parameterised to your constraints
• A decision record for every deviation from this baseline, so the reasoning outlives the engagement
• Runbooks for the parts that need a human: break-glass access, failover drill, policy promotion, retention review
• A cost baseline with budgets and anomaly alerts deployed alongside the infrastructure