Service Types: Core, Direct and Additional¶
The platform offers its services in three types. The type tells you who can ask for a service, how it is set up and whether it comes with extra cost or a separate agreement. Which services exist on your platform depends on what was bought and enabled; ask your platform team.
| Type | What it is | Who asks for it | Extra agreement or fee |
|---|---|---|---|
| Core | The foundation every other service depends on. Run and maintained centrally. | Nobody: it is always there | No |
| Direct | Services a workload team can request directly. Configured for the team and isolated to its workload. | Workload team, through a standard change | No, part of the platform |
| Additional | Services on top of the baseline, with their own scope | Workload team, after an intake | Usually yes: a separate fee, a separate service level and, where needed, an implementation statement of work |
In the managed model (Operating models) the additional services are the part of the contract that goes beyond the platform baseline. In the self-managed model they are services your own platform team may choose to offer.
Core services¶
Core services are the utilities of the platform. Running them centrally keeps them reliable, secure and cost-efficient.
| Core service | What it covers | More |
|---|---|---|
| Connectivity | Virtual WAN and virtual hub per region, VPN and ExpressRoute gateways to datacentres and branch offices, the private DNS resolver, the central IP plan and IP groups | Architecture, DNS design |
| Firewalling | The central Azure Firewall policy, Application Gateway with Web Application Firewall (WAF), baseline NSGs, host-based firewalls inside VMs | Firewall rule organisation |
| Governance | Management groups, Azure Policy and initiatives, tags, RBAC model, cost management | Governance |
| Monitoring | Action groups, Azure Monitor Baseline Alerts, Service Health alerts, central Log Analytics | Operating responsibilities |
| Security platforms | Microsoft Defender for Cloud and, if enabled, Microsoft Sentinel | Identity and access model |
Firewalling in more detail¶
Firewalling is layered. Each layer has a different job.
| Component | Protects |
|---|---|
| Azure Firewall (hub) | Traffic between spokes, towards on-premises networks, towards other landing zones and towards the internet |
| Application Gateway with WAF | Inbound web traffic from the internet to workloads. The WAF blocks common exploits (for example SQL injection and cross-site scripting). |
| Network security groups (NSG) | Traffic in and out of a subnet. Every subnet gets an NSG so connectivity stays as narrow as possible. |
| Host-based firewall | Traffic on the machine itself. Owned by the workload team. |
| An existing on-premises firewall | Traffic from the other side of a VPN or ExpressRoute link, if you have one. Rules usually need changing on both sides. |
A set of principles for firewall rules, used by several managed platforms:
| Principle | Reason |
|---|---|
| Use encrypted protocols unless the workload cannot | Encryption keeps sensitive data secret |
| Rules are owned by a workload | It must always be clear who owns a rule |
| Keep production and non-production rules separate, and do not allow traffic between the two | Production data must not be processed in non-production environments |
| Keep internal and internet-facing rules separate | External traffic is a higher threat |
| Incoming traffic to a spoke is denied unless the workload needs it | Unnecessary communication is a direct risk |
| Define rules at the destination, as incoming traffic only | The firewall is shared. If workload B could add a rule that opens workload A, workload A would be open without its own approval. |
How to organise the rule files is in Firewall rule organisation.
Application Gateway and WAF: typical settings¶
The Application Gateway entry point is configured as code. Typical, tunable settings:
| Setting | Typical value | Why |
|---|---|---|
| Tier | WAF v2 | Enables the WAF for every request |
| Capacity | Autoscale with a minimum of two instances and a set maximum | Redundancy, with a ceiling on cost |
| HTTP/2 | Enabled | |
| TLS policy | A predefined policy with a minimum of TLS 1.2 | |
| WAF mode | Prevention, with the Microsoft-managed rule set and request body inspection | Actively blocks matching requests |
| Log scrubbing | Enabled | Masks sensitive values in WAF logs |
| Certificates | Stored in a dedicated Key Vault; the gateway reads them with a managed identity | |
| Access | Only the platform team, through PIM | Resources are in their own resource group |
Typical handling of false positives: the workload team requests an exception, the platform team asks security for approval, and the exception is then added as an exclusion for the specific rule and request argument. A rule that Microsoft itself advises to disable because of false positives can be disabled platform-wide. Keep a list of exclusions and disabled rules with their rationale.
The values above are examples. The actual settings are in your platform configuration (Application Gateway).
Direct services¶
Direct services are requested by the workload team and set up for that team.
| Service | What it is |
|---|---|
| Workload and spoke | A subscription with network, groups, PIM, service principal, Key Vault, storage and Log Analytics, connected to the hub. See What you get and Spoke variants. |
| Bastion access | A central Azure Bastion host, so teams do not deploy their own. See Connect to VMs and Bastion design notes. |
| Build agents | Self-hosted pipeline agents inside the network, to reach private resources. See Build agent access and the container agent pool. |
| Developer access over VPN | Point-to-site VPN so engineers can reach private resources in their spokes. See Developer access with point-to-site VPN. |
Bastion design notes¶
If the platform offers a central Bastion host, these are the settings that matter in a Virtual WAN design:
| Setting | Value | Why |
|---|---|---|
| Tier | Standard | Needed for connections by IP address, which a Virtual WAN design requires |
| IP-based connection | Enabled | Lets Bastion connect to a private IP address in another spoke |
| Native client support | Enabled | Allows the Azure CLI or native RDP and SSH clients, for example from macOS |
| Copy and paste | Enabled | Easier to paste scripts and commands |
| Instance count | Two or more | Redundancy |
Bastion sits in its own virtual network with a subnet named AzureBastionSubnet. The firewall only allows SSH (22) and RDP
(3389) from that subnet towards the workload address ranges. Access is controlled with an Entra ID group that has Reader
on the Bastion resource group, filled with team groups (not with individual users). Users need the IP address of the
target machine and credentials for it.
Additional services¶
Additional services need an intake, because their scope depends on the workload. A typical agreement contains:
- a service level addendum with the scope, the service window and the availability of day-to-day support,
- an implementation statement of work if the workload must first be made compliant with the service,
- a fee,
- reporting to the workload team.
Examples:
| Service | What changes compared to a normal spoke |
|---|---|
| Managed spoke (service description) | The platform team also builds, deploys, maintains and monitors the Azure resources of the workload, as infrastructure as code on top of the standard spoke |
| Managed virtual machines | The platform team does the initial configuration and the patching of the operating system. See Managed virtual machines. |
| Base Fabric Data Platform | A managed Microsoft Fabric environment (capacity, workspaces, private connectivity, connections) on top of a spoke. See Base Fabric Data Platform. |
| Integration Platform | Managed integration building blocks (Service Bus, Logic Apps, Function Apps, Container Apps, Data Factory) with shared API Management and Event Hubs. See Integration Platform. |
| AI Platform | A shared Azure AI Foundry account with a project per workload and agent data stores. See AI Platform. |
| AKS Platform | A managed Kubernetes variant (AKS in Azure or on Azure Local) with baseline, identity and security policy. See AKS Platform. |
| Agentic Developer Portal | An optional Backstage-based portal with a catalog of workloads, cost, network, security and compliance views, AI agents and an MCP server. See Agentic Developer Portal. |
| Other managed platforms (for example virtual desktops) | A managed variant of the service, offered when the platform team has built it |
Spoke variants¶
| Variant | Use it when | What differs |
|---|---|---|
| Standard spoke | Normal case | The default: one spoke per environment, one for production data and the others for non-production data |
| Sandbox | Experiments with Azure | A subscription in the sandbox management group with no connection to the hub, other workloads or internal networks. See New sandbox subscription. |
| Managed spoke | The team is still learning Azure, does not want to invest in the technical skills, or has too few people to support the workload technically | Same baseline as the standard spoke. The platform team also maintains the workload resources, within a separate agreement. |
For a managed spoke the usual process is: an intake with the platform team, an assessment of the current or new solution, a service level addendum, building and deploying the infrastructure as code, support within the agreed window and reporting to the workload team. The workload team stays accountable for the workload: see Responsibilities.
Requests for new services¶
A request for new shared functionality is first assessed by architecture, operations and security. It is either an extension of an existing service (for example a new option in a feature flag) or a new service. A feature that needs new Terraform is a development change in the code repository, not a standard change: see Platform philosophy.