Azure Operator Service Manager

About Azure Operator Service Manager

Azure Operator Service Manager is a Microsoft Azure orchestration service for telecom operators and network equipment providers that need to deploy, upgrade, and manage complex mobility and network-function workloads across Azure and operator edge environments. It is built around a telecom-specific resource model rather than general application deployment. Publishers onboard network functions, service designers compose them into network service designs, and operators deploy site network services with site-specific configuration. Microsoft positions the service closely with Azure Operator Nexus, where it can orchestrate both containerized and virtualized network functions while coordinating infrastructure, software, configuration, and lifecycle operations through Azure Resource Manager. Buyers should treat it as a specialized orchestration layer for multi-vendor telecom services, not as a replacement for Azure Kubernetes Service, Azure Arc, GitHub, or ordinary CI/CD tooling. Current Microsoft release notes also make regional support and software-version management important procurement considerations, because supported AOSM regions are narrower than Azure as a whole and the Network Function Operator component is updated through explicit releases.

What does Azure Operator Service Manager manage?

Azure Operator Service Manager manages the lifecycle of network functions and network services rather than acting as the compute platform itself. A publisher onboards a network function and creates a network function definition. A service designer combines network functions and infrastructure into a network service design and defines the configuration group schemas that expose the settings operators are allowed to provide. An operator then deploys a site network service using configuration group values for that site and runtime.

That separation is useful in telecom environments because the same network-function software may need to be deployed across many sites with different parameters, infrastructure dependencies, and upgrade timing. The service gives those stages a common Azure Resource Manager model instead of requiring every vendor or operations team to maintain a separate orchestration interface.

How does Azure Operator Service Manager work with Azure Operator Nexus?

Microsoft documents Azure Operator Nexus as a primary hosting platform for workloads orchestrated by Azure Operator Service Manager. For virtualized network functions, AOSM can coordinate supporting infrastructure such as Layer 2 and Layer 3 isolation domains, network resources, trunks, and content service network resources. For containerized network functions, it can create and prepare Nexus Kubernetes clusters and then deploy the network-function applications that make up the service.

The distinction matters. Azure Operator Nexus provides the carrier-grade hybrid infrastructure, while Azure Operator Service Manager provides the service model, configuration, deployment, upgrade, rollback, and lifecycle orchestration. An operator that only needs telecom infrastructure may not need AOSM. An operator that needs repeatable multi-vendor network-service rollout across sites is much closer to the intended use case.

What is the current Azure Operator Service Manager release?

Microsoft's release notes identify release 2606.03, dated June 30, 2026, as the latest generally available AOSM release at the time this page was checked on August 31, 2026. Microsoft lists Network Function Operator version 3.0.3462-255, resource provider version 1.0.3464-580, and AOSM CLI extension version 2.0.0b6 for that release. The release requires an update of the Network Function Operator component rather than deletion and reinstallation.

The 2606.03 release includes quality fixes for deletion behavior, stale deletion timestamps, controller-manager resource allocation, and Site Network Service delete-operation timeout handling. Microsoft also reports security work including a Go runtime upgrade and fixes for direct CVEs. Buyers operating AOSM should therefore include AOSM and Network Function Operator version management in their normal maintenance process rather than treating the service as a completely maintenance-free control plane.

Where is Azure Operator Service Manager currently supported?

Microsoft's current release notes say generally available AOSM releases are supported in East US, South Central US, West US 3, and UK South. The same document says West Europe was retired on February 1, 2026 and is no longer supported for new deployments or ongoing operations. Microsoft advises customers with a business need for an unlisted region to open a support request for consideration.

This is an important limitation because Azure Operator Service Manager does not automatically inherit the full Azure regional footprint. Operators should validate the control-plane region, target Nexus or edge design, latency, regulatory requirements, and any regional migration implications before standardizing on the service.

How are network functions and service designs represented?

The service uses Azure resources for publishers, network function definitions, network service designs, configuration schemas, sites, and site network services. Publishers package the artifacts required to deploy containerized or virtualized network functions. Microsoft documents familiar artifacts including Helm charts and Docker images for containerized network functions, VHD images for virtualized network functions, and Azure Resource Manager templates for infrastructure and deployment composition.

A service designer can then combine one or more network functions into a network service design and decide which parameters an operator should supply. Configuration group schemas define the allowed configuration surface, while configuration group values provide the site or runtime values. This can reduce configuration sprawl when a vendor workload exposes many internal settings but the operator should only control a smaller validated subset.

What safe deployment and upgrade controls are available?

Microsoft positions safe deployment as a core AOSM capability. The service supports sequencing, failure detection, pause-on-failure behavior, rollback-on-failure behavior, and versioned artifacts. Microsoft's current safe-upgrade documentation also describes Helm tests as an optional gate for container network functions. When enabled, AOSM runs the tests after an application install or upgrade and requires successful results before the network-function operation can complete successfully.

For container network functions, Microsoft also documents separate pause-on-failure and rollback-on-failure behaviors. Pause can reduce retry time when an operator wants to investigate and resume, while rollback is intended to return the network function toward its starting point. These controls do not replace workload-specific validation. Operators still need health signals, rollout rings, change windows, rollback criteria, and vendor-specific testing.

What limits should architects consider?

AOSM deployments inherit Azure platform limits as well as service-specific behavior. Microsoft's current best-practices documentation calls out Azure Resource Manager template limits including 256 parameters, 256 variables, 800 resources including copy count, 64 outputs, a 4 MB template size, and a 1 MB resource-definition size. It also calls out the Azure RBAC limit of 4,000 role assignments per subscription.

These limits matter for large service designs and multi-vendor estates because rendered templates, role assignments, and generated resources can grow quickly. Architects should keep service designs modular, control the number of generated assignments, and test large rendered templates before using the same design across many sites.

How should operators size the Network Function Operator extension?

Microsoft's current Network Function Operator management documentation exposes small, medium, and large scale settings for components such as the cluster registry and controller manager. For the cluster registry, Microsoft lists CPU requests of 100m, 250m, and 500m for small, medium, and large, with memory requests of 250 MiB, 500 MiB, and 1 GiB. The corresponding resource limits increase up to 1 CPU and 4 GiB of memory for the large profile.

For the controller manager, the default is small. Microsoft lists CPU requests from 100m to 1 CPU and memory requests from 256 MiB to 1 GiB across the three profiles, with limits scaling up to 2 CPUs and 4 GiB. Operators with large artifact sets or busy deployment pipelines should review these scale controls instead of assuming the defaults fit every Nexus cluster.

How does Azure Operator Service Manager support automation and security?

AOSM is built around Azure Resource Manager and can be driven through Azure interfaces such as the portal, CLI, APIs, and SDKs. Microsoft also documents Azure DevOps integration for CI/CD workflows. The service can integrate with broader Azure analytics and automation services, but buyers should keep the telecom service lifecycle distinct from generic application pipelines.

Microsoft documents Azure Private Link as part of the security model for interfaces between customer premises and Azure, along with secret-management mechanisms intended to reduce unnecessary exposure of privileged data. Microsoft also states that AOSM releases are produced under Microsoft's Secure Development Lifecycle, including change authorization, antimalware scanning, and security-vulnerability scanning. Teams still need to define publisher permissions, artifact trust, identity ownership, deployment approvals, and access to target Nexus or Arc-connected environments.

How is Azure Operator Service Manager priced?

Pricing was checked on August 31, 2026. Microsoft's current Azure product page states that Azure Operator Service Manager pricing is not publicly published and directs customers to contact their Microsoft account representative. BrandLigo therefore does not present an invented hourly, per-site, per-network-function, or subscription price.

Buyers should budget separately for the infrastructure and connected Azure services used by the deployment. Azure Operator Nexus capacity, Kubernetes or virtualized infrastructure, networking, monitoring, storage, registries, DevOps, analytics, and other Azure resources can have their own charges even when AOSM commercial terms are negotiated separately.

Who is Azure Operator Service Manager best suited for?

The strongest fit is a telecom operator or network equipment provider that manages complex containerized or virtualized network functions across multiple sites and needs an Azure-native process for publishing, composing, configuring, deploying, upgrading, testing, and rolling back those services. It is especially relevant when Azure Operator Nexus is already part of the infrastructure strategy.

AOSM can also help organizations that need a common lifecycle model across multiple equipment vendors, standardized configuration inputs, and controlled fleet-wide rollouts. The value is less about hosting one workload and more about coordinating a repeatable network-service lifecycle across many sites and software versions.

Who should choose something else?

Choose Azure Operator Nexus without Azure Operator Service Manager if the primary requirement is carrier-grade hybrid infrastructure and the organization already has an orchestration layer that meets its operational needs. Choose Azure Kubernetes Service for general managed Kubernetes workloads that do not require telecom network-function modeling. Choose Azure Arc when the main requirement is governance and management across heterogeneous servers and Kubernetes environments rather than network-service composition.

Teams deploying ordinary enterprise applications should generally use mainstream Azure application platforms and CI/CD tools instead. AOSM adds the most value when the workload model genuinely includes publishers, network functions, network service designs, sites, telecom-specific configuration, and coordinated multi-site lifecycle operations. Organizations that require an Azure region outside Microsoft's current AOSM support list should also evaluate alternatives or obtain Microsoft guidance before committing.