azure-saas-architect

name

azure-saas-architect

description

Map a DECIDED logical architecture onto provider-idiomatic Azure for a multi-tenant SaaS — subscription layout, identity (Entra ID, managed identities, OIDC federation), network (VNets, Private Link, Front Door), Key Vault, data with an explicit tenant-isolation strategy per store (Azure SQL, Cosmos DB, Blob), compute chosen by team maturity (App Service, Container Apps, AKS, Functions), messaging (Service Bus, Event Grid), Azure Monitor observability, Azure Policy + Defender for Cloud/Sentinel posture, Bicep/Terraform IaC, and tag-keyed cost controls. Every choice ties to tenant isolation, cost, and operational maturity; SKU/quota/price claims become verification items, never asserted from memory. Use when asked to design or review Azure architecture for a SaaS, lay out a landing zone, or choose between Azure options. Do NOT use to decide WHETHER Azure (cloud-architecture-decider), for AWS (aws-saas-architect), tenancy semantics (saas-platform-architect), or IaC diffs (iac-reviewer).

Azure SaaS Architect

Purpose

Produce an Azure service architecture for a multi-tenant SaaS that a team can build and operate: per-capability service selections with rationale, tenant-isolation strategy per data store, identity and network topology, CI/CD and security posture, IaC strategy, and cost controls. The discipline is provider-idiomatic-without-invention: use Azure's native primitives the way Azure documents them, name services and capabilities — and leave SKU tiers, quotas, regional availability, and prices as verification items against current Azure docs, never asserted from memory.

Use When

• Use when: a cloud decision landed on Azure and the logical architecture needs mapping to concrete Azure services.
• Use when: asked to design an Azure landing zone / subscription layout for a SaaS, or to place identity, network, data, compute, messaging, and observability on Azure.
• Use when: choosing between Azure options for one capability (App Service vs Container Apps vs AKS; Azure SQL vs Cosmos DB; Service Bus vs Event Grid) with SaaS tenancy in play.
• Use when: reviewing an existing Azure architecture against SaaS isolation, cost, and operability expectations.
• Do NOT use when: the provider question is still open — cloud-architecture-decider first.
• Do NOT use when: the platform is AWS — aws-saas-architect.
• Do NOT use when: defining tenancy semantics or pooled/siloed structure — tenant-modeler / saas-platform-architect (their outputs are inputs here).
• Do NOT use when: reviewing a Bicep/Terraform change — iac-reviewer.

Inputs to Inspect

1. The cloud decision record (cloud-architecture-decider output): the constraints, hard filters, and managed-vs-self-hosted posture already decided.
2. The logical architecture and tenancy model: architecture-designer components, saas-platform-architect pooled/siloed decisions per component, tenant-modeler lifecycle.
3. Compliance/residency obligations and required regions.
4. Existing Azure estate if any: subscriptions, Entra tenant layout, networking, IaC in repo, deployed services.
5. Team operational maturity: AKS is a different operational bill than App Service — what has the team run?
6. Current Azure documentation for any capability where the design depends on a specific limit, SKU, or regional feature — these are verified, not recalled.

Workflow

1. Lay out the management structure: management groups, subscriptions (at minimum: production / non-production separation; per-environment or per-workload subscriptions as scale warrants), resource-group conventions, and the tagging standard (tenant, environment, workload, cost center) that cost controls and Azure Policy will key on.
2. Design identity first: Microsoft Entra ID as the identity plane — workforce vs customer identity (External ID) separation, managed identities for service-to-service auth (no connection-string culture), workload identity federation (OIDC) for CI/CD instead of long-lived service principals with secrets, RBAC role assignments at the narrowest scope that works.
3. Design the network: VNet topology (hub-spoke when multiple workloads/ environments warrant it), private endpoints via Private Link for data services, public ingress through Front Door or Application Gateway (WAF at the edge), egress control, and the rule that data stores are not publicly reachable.
4. Map data stores with a tenant-isolation strategy per store: Azure SQL (elastic pools for database-per-tenant silos; row-level scoping in pooled models), Cosmos DB (partition-key-per-tenant in pooled containers; database/container-per-tenant for silos), Blob Storage (tenant-prefixed paths or per-tenant containers), cache/search equivalents — each store carries: service, isolation mechanism, and the reason it satisfies the tenancy model. Delegate mechanism design detail to multi-tenant-data-architect.
5. Choose compute per workload shape: App Service (web workloads, low ops), Azure Container Apps (containers without cluster ops), AKS (only with a named reason and the operational bill accepted), Functions (event-driven/jobs) — biased by the team-maturity input, not resume ambition.
6. Map messaging: Service Bus for commands/queues with ordering and dead-lettering, Event Grid for event distribution/fan-out, Event Hubs for streaming volumes — with tenant context carried in messages and consumer-side tenant scoping stated.
7. Wire observability and secrets: Application Insights + Azure Monitor
   • Log Analytics with tenant-tagged telemetry (design detail per observability-operator / slo-reliability-architect), Key Vault per environment for secrets/keys/certs with rotation posture, diagnostic settings shipped to Log Analytics by default.
8. Set the CI/CD and security posture: deployment via GitHub Actions or Azure DevOps using OIDC federation to Entra (no stored cloud credentials), Azure Policy for guardrails (deny public storage, require tags, require private endpoints), activity logs retained — then place the security suite deliberately:

Output Format

AZURE SAAS ARCHITECTURE — <product/scope>
Management & tagging: <mgmt groups, subscriptions, resource-group + tag standard>
Identity: <Entra layout, workforce/customer split, managed identities, OIDC federation, RBAC scopes>
Network: <VNet topology, Private Link coverage, ingress/WAF, egress posture>
Data (per store): <store — service — tenant-isolation mechanism — why it fits the tenancy model>
Compute (per workload): <workload — service — rationale incl. operational bill>
Messaging: <needs → Service Bus / Event Grid / Event Hubs, tenant context propagation>
Observability & secrets: <Monitor/App Insights/Log Analytics wiring, Key Vault layout, rotation>
CI/CD & security posture: <OIDC deploy path, Azure Policy guardrails, Defender for Cloud plans, Sentinel (if D&R practice), CASB / ID Protection placements>
IaC strategy: <tool, state/environment layout, module conventions>
Cost controls: <budgets, views, attribution feed, top-3 cost risks>
Verification items: <each SKU/limit/region/price-dependent claim → verify against current Azure docs>
Assumptions & open questions: <each with risk-if-wrong / who answers>

Validation Checklist

• Every data store names its tenant-isolation mechanism and ties it to the tenancy model — no store ships isolation-unspecified.
• No SKU tier, quota, price, or regional-availability claim is asserted from memory — all such dependencies sit in Verification items.
• Identity design uses managed identities and OIDC federation; any long-lived credential is flagged, not normalized.
• Data services sit behind private endpoints; every public exposure is justified in writing.
• Compute choices cite the team-maturity input; AKS (if chosen) carries a named reason and its operational bill.
• Security-suite choices tie to team maturity and carry their cost meters; no plan/tier claim is asserted from memory.
• Cost controls key on the tagging standard and name the top cost risks of this specific design.
• Tenancy semantics, pipeline internals, and IaC diff review were delegated (saas-platform-architect/multi-tenant-data-architect, ci-pipeline-architect, iac-reviewer), not restated.

Gotchas

• Per-tenant Azure SQL databases without elastic pools price like a separate server per tenant; pools are the silo-model default — verify current pool limits before promising tenant counts.
• Cosmos DB partition-key-per-tenant pools hit noisy-neighbor throughput sharing; heavy tenants may need their own containers — design the promotion path now.
• Front Door and Application Gateway overlap on ingress: global anycast + CDN vs regional L7; picking by acronym rather than traffic shape is a recurring miss.
• Managed identities do not cross the Entra tenant boundary trivially; customer-facing auth (External ID) and workforce auth are different designs — do not conflate them.
• Log Analytics ingestion is a routine surprise top-3 cost line in SaaS telemetry designs; set daily caps/table plans as part of the design, not after the first bill.
• Defender for Cloud plans meter per resource and Sentinel rides the Log Analytics meter — the security suite is a routine surprise top-3 cost line; scope plans to the workloads this design deploys and cap security telemetry like any other Log Analytics table.
• Azure Policy guardrails applied after workloads exist produce a remediation backlog; ship policy with the landing zone, not as cleanup.

Stop Conditions

• No cloud decision record exists and the provider choice is actually contested → cloud-architecture-decider first; this skill does not arbitrate providers.
• The tenancy model (pooled/siloed per component) is undefined → run saas-platform-architect; per-store isolation cannot be mapped without it.
• A design constraint hinges on a SKU/limit/region fact that cannot be verified against current docs in this session → mark it blocking in Verification items and say so; do not design on a recalled number.
• The request shifts from designing to APPLYING changes to a live Azure estate → stop; this skill designs. Route execution through human-approval-boundary and the IaC/change process.

Supporting Files

• references/azure-mapping.md — capability → Azure service mapping table, tenancy-isolation options per store, landing-zone layout patterns.
• evals/evals.json — trigger + behavior cases.
• evals/trigger-evals.json — discrimination within the cloud cluster (cloud-architecture-decider, aws-saas-architect, iac-reviewer) and against shipped saas-platform-architect / architecture-designer.