Azure Operator Service Manager Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Hybrid + Multicloud

by

Category

Hybrid + Multicloud

1. Introduction

Azure Operator Service Manager is an Azure service designed for telecom operators and network function vendors to onboard, validate, publish, and manage the lifecycle of network functions and network service designs, and then deploy them consistently to supported execution environments (for example, operator cloud/edge platforms).

In simple terms: it helps you take a vendor’s “network function package” (like a 5G core component or IMS function), store and version it safely, define how it should be deployed and configured, and then roll it out to one or many sites with controlled lifecycle operations.

Technically, Azure Operator Service Manager provides an Azure Resource Manager (ARM) control plane (resource provider–based) for network function onboarding and lifecycle management, including publishing artifacts, creating network function definitions and network service designs, and orchestrating deployments to supported targets. It integrates with standard Azure building blocks—Azure RBAC, managed identities, Azure Monitor, Activity Logs, and Azure-native governance.

The core problem it solves is common in carrier and edge environments: multi-vendor network functions are hard to package, validate, version, distribute, and deploy repeatedly across many sites without creating bespoke automation for every vendor and every site. Azure Operator Service Manager aims to provide a consistent, Azure-governed approach to that lifecycle, aligned to Hybrid + Multicloud realities (distributed sites, on-prem edge, and cloud-hosted management).

Naming note (important): Microsoft documentation and the Azure resource provider namespace may still reference earlier naming such as Microsoft.HybridNetwork. If you see “Hybrid Network” terminology in APIs, CLI extensions, or resource types, verify in official docs how it maps to the current Azure Operator Service Manager branding and scope.

2. What is Azure Operator Service Manager?

Official purpose

Azure Operator Service Manager is intended to help telecom operators and partners manage the lifecycle of network functions and network services: onboarding and storing artifacts, creating deployable definitions, publishing versions, and orchestrating deployment into supported environments with Azure governance.

Core capabilities (what it enables)

  • Onboarding network function artifacts/packages from vendors into Azure-managed constructs.
  • Versioning of network function definitions and network service designs.
  • Publishing and distribution patterns to enable controlled reuse across teams/subscriptions (exact publishing models depend on your setup—verify in official docs).
  • Lifecycle management operations (create/update/delete/upgrade patterns) for network functions and services—implemented through ARM resources and integrations with execution environments.
  • Governed deployments using Azure identity, policy, logging, and resource hierarchy.

Major components (conceptual model)

Exact object names can vary by API version and documentation set, but the service typically revolves around:

  • Publisher / onboarding boundary: a logical boundary representing who owns and publishes network function artifacts.
  • Artifact storage integration: where packages/manifests are stored (commonly backed by Azure Storage).
  • Network Function Definition (NFD): a deployable definition of a network function, typically versioned, pointing to artifacts and deployment templates.
  • Network Service Design (NSD): a higher-level design that composes one or more network functions plus connectivity/configuration intent.
  • Network Function Instance / Network Service Instance: deployed instances created from the above definitions.

Verify the exact resource types and hierarchy in the official Azure Operator Service Manager documentation for your API version and region.

Service type

  • Control-plane service integrated with Azure Resource Manager (ARM).
  • Designed for telecom/operator network function lifecycle management, not general application deployment.
  • Typically used together with operator/edge execution platforms rather than replacing them.

Scope (subscription/region)

  • Azure Operator Service Manager is represented as ARM resources inside an Azure subscription.
  • Many resources in ARM are regional (they have a location), even if they manage multi-site deployments.
    Verify supported regions and whether specific resource types are regional or global in the official docs.

How it fits into the Azure ecosystem

Azure Operator Service Manager sits in the “operator lifecycle” layer: – Uses Azure identity (Microsoft Entra ID) + Azure RBAC for access control. – Uses Azure Storage (commonly) for artifact storage. – Uses Azure Monitor / Log Analytics and Activity Logs for auditability and operations. – Can be used in Hybrid + Multicloud patterns where sites may be distributed and where management needs centralized governance.

3. Why use Azure Operator Service Manager?

Business reasons

  • Faster onboarding of vendor network functions with consistent packaging and lifecycle patterns.
  • Repeatable deployments across many sites (common in telecom/edge footprints).
  • Reduced integration cost versus building a custom MANO-like orchestration layer for each vendor.
  • Governance and audit aligned with Azure enterprise controls.

Technical reasons

  • ARM-native resource model: network function lifecycle becomes declarative resources with Azure-native deployment patterns.
  • Versioned definitions: safer upgrades/rollouts with controlled versions.
  • Separation of concerns: vendors/publishers can manage artifacts and definitions while operators control deployments and operations (implementation depends on your organizational model).

Operational reasons

  • Standardized lifecycle operations (deploy, update, retire) rather than bespoke scripts.
  • Centralized observability hooks through Azure Monitor/diagnostic settings (where supported).
  • Consistent tagging, policy, and resource organization.

Security/compliance reasons

  • Azure RBAC for control-plane permissions.
  • Activity Log visibility for management operations.
  • Integration possibilities with managed identities and Key Vault (pattern depends on how your execution environment consumes secrets—verify in docs).

Scalability/performance reasons

  • Designed for multi-site deployment realities (large fleets of sites/edge clusters).
  • Lets you standardize artifacts and definitions to reduce per-site complexity.

When teams should choose it

Choose Azure Operator Service Manager when you: – Are a telecom operator (or partner) managing network functions (CNFs/VNFs, depending on supported targets). – Need governed onboarding + lifecycle of multi-vendor network functions. – Need consistent deployment across distributed edge sites (Hybrid + Multicloud).

When teams should not choose it

Avoid (or reconsider) if you: – Only need to deploy normal microservices apps (use AKS, Arc, GitOps/Flux, or standard CI/CD instead). – Need a fully open-source MANO stack with broad ETSI integration requirements (consider ONAP, OSM, or vendor MANO products). – Don’t have access/enablement for Azure Operator Service Manager in your subscription/region (some operator services require onboarding—verify in official docs).

4. Where is Azure Operator Service Manager used?

Industries

  • Telecommunications (mobile core, IMS/VoLTE, RAN-related workloads where applicable, edge services)
  • Private 5G / enterprise networks (where operator-managed)
  • Critical infrastructure with edge footprints (subject to supported execution environments)

Team types

  • Network Cloud Engineering (NCE)
  • Telco Platform Engineering
  • DevOps/SRE teams supporting CNF lifecycle
  • Vendor integration teams (NFV/CNF onboarding)
  • Security and compliance teams overseeing operator platforms

Workloads

  • 4G/5G core network functions (where vendor + platform support exists)
  • IMS components
  • Packet core adjacent services
  • Network edge service chains (where supported)

Architectures

  • Centralized control plane with distributed edge sites
  • Multi-region operator clouds with consistent artifact distribution
  • Hybrid patterns where execution is at edge/on-prem, and management is in Azure

Real-world deployment contexts

  • Operator cloud: centralized management plane controlling deployments to operator platforms.
  • Edge sites: tens/hundreds of locations requiring consistent configuration and upgrade workflows.
  • Vendor onboarding: enabling a controlled pipeline from vendor release → operator validation → production rollout.

Production vs dev/test usage

  • Dev/test: validate onboarding, definitions, and upgrade workflows; run pre-prod canary deployments.
  • Production: controlled version promotion, staged rollouts, policy enforcement, audited changes, and strict RBAC boundaries.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Azure Operator Service Manager is commonly evaluated.

1) Vendor CNF onboarding and version governance

  • Problem: Vendor releases arrive as packages that differ in structure and require manual handling.
  • Why it fits: Provides a governed onboarding model with versioned definitions.
  • Example: Onboard CNF v1.2.0, keep v1.1.4 available for rollback, and promote v1.2.0 to production after validation.

2) Multi-site deployment standardization (edge fleet)

  • Problem: Each edge site ends up with one-off scripts and configuration drift.
  • Why it fits: Central definitions + service designs reduce drift and improve repeatability.
  • Example: Deploy the same UPF function to 40 edge sites with site-specific parameters (IP ranges, VLAN IDs, DNS).

3) Network service composition (service design)

  • Problem: A service is not a single function; it’s a chain of functions with defined connectivity.
  • Why it fits: Network service designs can model composition and deployment intent.
  • Example: Define an “Enterprise Private 5G Core” design that includes AMF/SMF/UPF plus config.

4) Controlled upgrades with staged rollout

  • Problem: Upgrades across a distributed network cause outages if not staged and audited.
  • Why it fits: Versioned artifacts and managed lifecycle operations enable phased rollouts.
  • Example: Upgrade 5 sites first (canary), then 20, then the remaining fleet after KPIs meet thresholds.

5) Operational separation of duties (publisher vs operator)

  • Problem: Security requires the vendor integration team to manage packages while ops controls deployments.
  • Why it fits: The resource model can support separation of onboarding/publishing from deployment permissions (implementation depends on RBAC design).
  • Example: Vendor team can create/modify definitions; ops team can deploy instances.

6) Repeatable environment creation for lab, staging, production

  • Problem: Pre-prod never matches prod, causing release surprises.
  • Why it fits: Same definitions and service designs can be deployed into multiple environments.
  • Example: Use identical NSD versions in staging and production, with environment-specific parameters.

7) Artifact traceability and audit for compliance

  • Problem: Regulators or internal audit require proof of what version ran where and when.
  • Why it fits: ARM resources + Activity Logs support traceability.
  • Example: Generate an audit report for all deployments of CNF v2.0.1 across regions.

8) Integration into CI/CD for network functions

  • Problem: Vendor packages are handled manually; no consistent pipeline.
  • Why it fits: Onboarding and versioning can be integrated into pipelines via ARM/REST tooling.
  • Example: GitHub Actions uploads a package, creates a new definition version, triggers staged rollout.

9) Cross-subscription governance with shared definitions

  • Problem: Multiple business units deploy the same NF but manage different subscriptions.
  • Why it fits: Shared publishing patterns can reduce duplication (verify supported models).
  • Example: A central platform team publishes approved definitions; BU subscriptions deploy instances.

10) Site-specific parameterization without drifting templates

  • Problem: Copy/paste templates per site leads to drift and errors.
  • Why it fits: Central definitions + per-instance parameters keep templates consistent.
  • Example: Same UPF package deployed everywhere, but each site provides local networking parameters.

11) Disaster recovery and redeploy patterns

  • Problem: Rebuilding a failed site takes too long and is error-prone.
  • Why it fits: Stored, versioned definitions accelerate redeploy with known-good artifacts.
  • Example: Redeploy the last approved NSD version to a replacement cluster in a DR region.

12) Multi-vendor catalog normalization

  • Problem: Operators support multiple NF vendors; operations need a unified lifecycle approach.
  • Why it fits: Common ARM model abstracts some differences at the lifecycle layer.
  • Example: Operate Vendor A firewall CNF and Vendor B UPF CNF using the same governance approach.

6. Core Features

Feature availability can vary by region, API version, and your operator platform integration. Verify in official docs for your environment.

1) ARM-based resource model (Azure-native control plane)

  • What it does: Exposes onboarding, definitions, and instances as ARM resources.
  • Why it matters: Enables consistent provisioning, RBAC, tagging, and policy.
  • Practical benefit: Works with standard Azure tooling (portal, ARM templates, Bicep, REST APIs).
  • Caveats: Some advanced lifecycle actions may require specific supported execution environments.

2) Artifact onboarding and storage integration

  • What it does: Associates network function packages/manifests with an onboarding workflow and storage backend.
  • Why it matters: Centralizes artifact handling and versioning.
  • Practical benefit: Reduces “package sprawl” and improves traceability.
  • Caveats: Artifact formats and validation rules are strict; vendor packages must comply.

3) Versioned network function definitions

  • What it does: Lets you create versioned definitions that reference specific artifacts and deployment templates.
  • Why it matters: Upgrades/rollbacks require precise version control.
  • Practical benefit: You can pin production to known-good versions and test new versions safely.
  • Caveats: Version promotion workflow depends on your operating model; not all workflows are fully automated.

4) Network service design (service composition)

  • What it does: Defines a service composed of one or more network functions and their configuration intent.
  • Why it matters: Real services are usually multi-function and require consistent orchestration.
  • Practical benefit: Reduces ad-hoc “runbooks” for multi-component rollouts.
  • Caveats: The depth of composition and connectivity modeling depends on supported integrations.

5) Instance lifecycle management

  • What it does: Creates and manages deployed instances from definitions/designs.
  • Why it matters: Operators need repeatable lifecycle operations across many sites.
  • Practical benefit: Centralizes management operations and supports controlled updates.
  • Caveats: Day-2 operations and telemetry depend on the execution platform and vendor NF capabilities.

6) Azure RBAC and governance integration

  • What it does: Uses Azure identity and RBAC for management-plane access.
  • Why it matters: Operator environments require strict separation of duties.
  • Practical benefit: Grant least privilege per team (onboarding vs deployment vs audit).
  • Caveats: Data-plane access to artifacts (Azure Storage) requires separate permissions.

7) Auditability via Azure Activity Logs

  • What it does: Records control-plane operations in Azure’s standard Activity Log.
  • Why it matters: Compliance and incident response require audit trails.
  • Practical benefit: You can correlate “who changed what” with deployment outcomes.
  • Caveats: Activity Logs cover control-plane actions; workload runtime logs are separate.

8) Integration hooks for monitoring (Azure Monitor / diagnostics)

  • What it does: Supports Azure monitoring patterns for supported resource types.
  • Why it matters: Operator-grade operations require centralized monitoring.
  • Practical benefit: Route logs/metrics to Log Analytics and SIEM/SOAR.
  • Caveats: Telemetry richness varies by integration; verify what signals exist.

9) Multi-environment consistency (dev/test/prod)

  • What it does: Enables reuse of definitions and designs across environments.
  • Why it matters: Promoting releases requires consistency.
  • Practical benefit: Same artifact + definition version deployed across stages with parameter differences.
  • Caveats: Network and capacity differences can still affect outcomes.

10) Automation friendliness (API-first)

  • What it does: Can be driven through ARM APIs and tooling.
  • Why it matters: Operators want CI/CD and GitOps-like control for NF lifecycle.
  • Practical benefit: Integrate onboarding and deployments into pipelines.
  • Caveats: Some actions may require preview APIs or specific tooling; verify current CLI/SDK support.

7. Architecture and How It Works

High-level architecture

At a high level, Azure Operator Service Manager acts as a management plane:

  1. Onboarding: A publisher/team onboards vendor artifacts into an approved storage location and registers a versioned definition.
  2. Design: A network service design defines how one or more functions should be deployed and configured.
  3. Deployment: An operator deploys instances to a supported execution environment (for example, an operator edge platform).
  4. Operations: Azure logs/audit record control-plane actions; runtime monitoring depends on the target environment and NF telemetry.

Request / control flow (typical)

  • User or pipeline authenticates via Microsoft Entra ID.
  • Requests go to Azure Resource Manager and the Azure Operator Service Manager resource provider.
  • The service reads metadata and references artifacts in Azure Storage (or another supported artifact backend).
  • Deployment orchestration is executed toward supported targets (verify target integrations in official docs).
  • Status is surfaced back as ARM resource state, with additional diagnostics depending on configuration.

Integrations with related Azure services

Common integrations/patterns include: – Microsoft Entra ID for identity. – Azure RBAC for authorization. – Azure Storage for artifact storage (common pattern). – Azure Monitor / Log Analytics for centralized monitoring and diagnostics. – Azure Policy for governance controls (tagging, allowed locations, etc.). – Azure Key Vault for secrets (pattern depends on how NFs consume secrets).

Dependency services

You should plan for dependencies such as: – A supported execution environment (operator cloud/edge platform). – Storage for artifacts. – Monitoring workspace(s) and log routing. – Networking connectivity between management plane and your environments, as required.

Security/authentication model

  • Authentication: Microsoft Entra ID.
  • Authorization: Azure RBAC at subscription/resource group/resource scope.
  • Artifact access: typically requires Storage Blob Data roles on the artifact storage account/container (separate from ARM permissions).
  • Automation identities: use managed identities or service principals with least privilege.

Networking model

  • The management plane is accessed via Azure’s control plane endpoints.
  • Artifact storage access is data-plane traffic to Azure Storage endpoints (public endpoints or private endpoints depending on your design).
  • Connectivity to targets varies; some operator platforms are integrated and may not require inbound access from public internet, but design depends on target environment and supported architecture.

Monitoring/logging/governance considerations

  • Use Activity Log to audit control-plane changes.
  • Use diagnostic settings on supported resources to push logs to Log Analytics/Event Hub/Storage.
  • Establish resource naming, tagging, and RBAC conventions before production rollout.
  • Use Azure Policy for guardrails (allowed regions, required tags, private endpoints for storage, etc.).

Simple architecture diagram (conceptual)

flowchart LR
  U[Engineer / Pipeline] -->|Entra ID auth| ARM[Azure Resource Manager]
  ARM --> AOSM[Azure Operator Service Manager<br/>(resource provider)]
  AOSM --> ST[Artifact Storage<br/>(Azure Storage)]
  AOSM --> TGT[Execution Environment<br/>(operator/edge platform)]
  AOSM --> MON[Azure Monitor / Activity Logs]

Production-style architecture diagram (multi-site, governed)

flowchart TB
  subgraph mgmt[Azure subscription: Management plane]
    AAD[Microsoft Entra ID]
    ARM[Azure Resource Manager]
    AOSM[Azure Operator Service Manager]
    KV[Key Vault (optional)]
    ST[Azure Storage (artifacts)]
    LAW[Log Analytics Workspace]
    EH[Event Hub (optional SIEM export)]
    POL[Azure Policy]
  end

  subgraph cicd[CI/CD]
    GH[GitHub Actions / Azure DevOps]
  end

  subgraph sites[Distributed sites / regions]
    S1[Site A: execution env]
    S2[Site B: execution env]
    S3[Site C: execution env]
  end

  GH -->|OIDC/SPN/MI| AAD
  GH --> ARM
  AAD --> ARM
  ARM --> AOSM

  POL --> ARM
  AOSM --> ST
  AOSM --> KV

  AOSM -->|orchestrate deploy| S1
  AOSM -->|orchestrate deploy| S2
  AOSM -->|orchestrate deploy| S3

  ARM -->|Activity Log| LAW
  AOSM -->|Diagnostics (if supported)| LAW
  LAW --> EH

8. Prerequisites

Because Azure Operator Service Manager is operator-focused, prerequisites are more stringent than typical app services.

Account/subscription requirements

  • An Azure subscription where you can register resource providers and create resources.
  • Your subscription/tenant may require allowlisting or onboarding to use Azure operator services.
    If you encounter Forbidden, AuthorizationFailed, or “feature not registered” errors, verify in official docs and contact Microsoft support/your account team.

Permissions / IAM roles

You typically need: – Owner or Contributor at the subscription or resource group to create resources. – Permission to register resource providers (often requires Owner). – For artifact storage: – Storage Blob Data Contributor (or higher) to upload packages to Azure Storage containers. – For monitoring: – Log Analytics Contributor (or equivalent) to configure workspace and diagnostic settings.

Billing requirements

  • Valid billing set up for your subscription.
  • Expect charges for underlying resources (storage, monitoring, and the execution environment compute/network).

CLI/SDK/tools needed

  • Azure CLI: https://learn.microsoft.com/cli/azure/install-azure-cli
  • Optional: Az PowerShell, Bicep, ARM templates
  • Optional: Storage tooling:
  • Azure CLI storage commands
  • AzCopy: https://learn.microsoft.com/azure/storage/common/storage-use-azcopy-v10

CLI note: Some operator services expose CLI functionality via extensions. For Azure Operator Service Manager, you may see CLI support under an extension related to Hybrid Network. Verify the current CLI extension name and commands in official docs.

Region availability

  • Operator services are often region-limited.
  • Verify region availability for Azure Operator Service Manager in the official documentation for your tenant.

Quotas/limits

  • Standard Azure limits apply (resource group limits, storage account limits, Log Analytics ingestion limits).
  • Service-specific limits (number of definitions, versions, instances, etc.) should be verified in official docs.

Prerequisite services

For this tutorial’s lab (safe, low-cost control-plane setup), you’ll use: – Resource group – Azure Storage account (for artifacts) – Log Analytics workspace (optional but recommended for operational readiness)

For real deployments you will also need: – A supported execution environment / target platform (verify supported targets in docs)

9. Pricing / Cost

Pricing model (how you are billed)

Azure Operator Service Manager is primarily a control-plane service. In many Azure services of this style, the management plane may not have a standalone price meter, and costs come from the resources it provisions/uses (storage, compute, networking, monitoring) and from the execution environment where network functions run.

Because pricing can change and can be tied to operator-specific contracts, you should: – Verify whether Azure Operator Service Manager has a standalone meter on an official pricing page (if available). – Use the Azure Pricing Calculator for dependent services and your target platform.

Official tools: – Azure Pricing Calculator: https://azure.microsoft.com/pricing/calculator/ – Azure pricing overview: https://azure.microsoft.com/pricing/

If you cannot find a dedicated Azure Operator Service Manager pricing page, treat it as “cost is primarily underlying Azure resources + operator platform charges” and confirm with Microsoft and the official docs.

Pricing dimensions (what drives cost)

Common direct and indirect cost drivers include:

  1. Artifact storage – Azure Storage capacity (GB stored) – Operations/transactions (uploads, downloads, list operations) – Redundancy (LRS/ZRS/GRS) – Data transfer (especially egress)

  2. Monitoring and logs – Log Analytics ingestion (GB/day) – Retention beyond included retention (varies by pricing model/region) – Diagnostic export (Event Hub, Storage)

  3. Execution environment – Compute nodes, accelerators (if applicable), and storage for network functions – Networking (load balancers, IPs, firewalling, cross-site connectivity) – Site-to-site WAN bandwidth and any data egress to internet/other clouds

  4. Automation and pipelines – CI/CD runners – Artifact scanning tools – Container registries (if used)

Free tier

  • Azure Operator Service Manager itself may not have a traditional free tier.
  • Some dependent services have limited free grants (for example, certain monitoring free allowances), but these vary—verify in official pricing.

Hidden or indirect costs to plan for

  • Artifact duplication across regions for performance/resilience.
  • Cross-region replication and associated bandwidth.
  • Long retention of logs for compliance.
  • Private endpoints for storage (cost per endpoint + DNS + network).

Network/data transfer implications

  • Uploading vendor packages into Azure is usually inbound (often free), but:
  • Egress from Azure Storage to other regions, sites, or on-prem can cost money.
  • Replication to other storage accounts/regions can add transfer and storage costs.

Cost optimization strategies

  • Use LRS for dev/test artifact storage; consider ZRS/GRS for production only where required.
  • Keep artifact packages lean; enforce retention policies for old versions.
  • Use lifecycle management policies in Azure Storage (move older artifacts to cool/archive if appropriate).
  • Route only necessary logs to Log Analytics; set retention to meet compliance without excess.
  • Use tagging (env, owner, costCenter) and Azure Cost Management budgets/alerts.

Example: low-cost starter estimate (lab-style)

A minimal “control plane readiness” setup typically includes: – 1 resource group – 1 small Azure Storage account for artifacts (small GB footprint) – Optional: 1 Log Analytics workspace with minimal ingestion – No real network function runtime compute

To estimate: 1. Go to the calculator and add: – Storage Accounts (Blob storage) in your region, choose redundancy, estimate GB stored and operations. – Log Analytics / Azure Monitor ingestion (GB/day) and retention. 2. Add Private Endpoints only if you enforce private access.

This yields a low-cost baseline without running any CNFs.

Example: production cost considerations

In production, your dominant cost drivers are usually: – The execution environment (cluster nodes/edge hardware, networking, storage). – High-volume telemetry/log ingestion. – Artifact distribution bandwidth if you have many sites pulling large packages.

Treat Azure Operator Service Manager as an enabler/control plane and focus your cost analysis on: – per-site runtime resources, – per-site network connectivity, – fleet-wide monitoring retention requirements, – artifact replication strategy.

10. Step-by-Step Hands-On Tutorial

This lab is intentionally scoped to be safe and low-cost by focusing on the control-plane setup and validation (resource provider registration, artifact storage, basic governance). A full deployment of a telecom network function requires a supported execution environment and a vendor package, which may not be available in a generic sandbox subscription.

Objective

Set up the foundational Azure resources used with Azure Operator Service Manager and validate you can: – Register the required resource provider – Prepare artifact storage – Apply least-privilege access for artifact upload – Establish basic monitoring/audit readiness

Lab Overview

You will: 1. Create a resource group. 2. Register the Azure Operator Service Manager resource provider (commonly surfaced under Microsoft.HybridNetwork—verify in your tenant). 3. Create an Azure Storage account and a container for artifacts. 4. Create an Entra ID security boundary (a user-assigned managed identity) for automation and grant it artifact upload permissions. 5. (Optional) Create a Log Analytics workspace to prepare for diagnostics and audit workflows. 6. Validate access and perform a test artifact upload. 7. Clean up.

Step 1: Create a resource group

Expected outcome: A resource group exists to hold lab resources.

# Variables (edit for your environment)
LOCATION="eastus"              # verify a supported region for your subscription
RG="rg-aosm-lab"

az login
az account show
az group create --name "$RG" --location "$LOCATION"

Verify:

az group show --name "$RG" --query "{name:name, location:location, provisioningState:properties.provisioningState}"

Step 2: Register the Azure Operator Service Manager resource provider

Azure Operator Service Manager is exposed through an Azure resource provider. In many tenants this is associated with Microsoft.HybridNetwork.

Expected outcome: The provider is registered (state: Registered).

# Check current registration state
az provider show --namespace Microsoft.HybridNetwork --query "{namespace:namespace, registrationState:registrationState}"

If not registered:

az provider register --namespace Microsoft.HybridNetwork

Wait and re-check:

az provider show --namespace Microsoft.HybridNetwork --query "{namespace:namespace, registrationState:registrationState}"

If registration fails or never becomes registered: – Your subscription might not be eligible or may require feature registration/onboarding. Verify in official docs for Azure Operator Service Manager access requirements.

Step 3: Create artifact storage (Storage account + container)

Expected outcome: A storage account and container exist for artifact uploads.

Create a storage account (choose a globally unique name):

STORAGE_NAME="aosmartifacts$RANDOM"
CONTAINER_NAME="artifacts"

az storage account create \
  --name "$STORAGE_NAME" \
  --resource-group "$RG" \
  --location "$LOCATION" \
  --sku Standard_LRS \
  --kind StorageV2

Create a container:

az storage container create \
  --name "$CONTAINER_NAME" \
  --account-name "$STORAGE_NAME" \
  --auth-mode login

Verification:

az storage account show --name "$STORAGE_NAME" --resource-group "$RG" --query "{name:name, location:primaryLocation, sku:sku.name}"
az storage container show --name "$CONTAINER_NAME" --account-name "$STORAGE_NAME" --auth-mode login --query "{name:name}"

Step 4: Create a user-assigned managed identity for automation

This identity is a good practice for CI/CD pipelines or controlled automation that uploads artifacts.

Expected outcome: A user-assigned managed identity exists.

IDENTITY_NAME="id-aosm-artifact-uploader"

az identity create \
  --name "$IDENTITY_NAME" \
  --resource-group "$RG" \
  --location "$LOCATION"

Capture its principal ID:

PRINCIPAL_ID=$(az identity show --name "$IDENTITY_NAME" --resource-group "$RG" --query principalId -o tsv)
echo "$PRINCIPAL_ID"

Step 5: Grant least-privilege access to upload artifacts

Grant the identity permissions on the storage account scope.

Expected outcome: The identity can upload blobs to the container.

STORAGE_ID=$(az storage account show --name "$STORAGE_NAME" --resource-group "$RG" --query id -o tsv)

az role assignment create \
  --assignee-object-id "$PRINCIPAL_ID" \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Contributor" \
  --scope "$STORAGE_ID"

Verify role assignment:

az role assignment list --scope "$STORAGE_ID" --query "[?principalId=='$PRINCIPAL_ID'].{role:roleDefinitionName, scope:scope}" -o table

Step 6 (Optional but recommended): Create a Log Analytics workspace

Even if you don’t enable diagnostics yet, having a workspace is a common operational baseline.

Expected outcome: A workspace exists.

LAW="law-aosm-lab"

az monitor log-analytics workspace create \
  --resource-group "$RG" \
  --workspace-name "$LAW" \
  --location "$LOCATION"

Verify:

az monitor log-analytics workspace show \
  --resource-group "$RG" \
  --workspace-name "$LAW" \
  --query "{name:name, location:location, sku:sku.name}"

Step 7: Upload a test artifact (sanity check)

This confirms your storage/container setup works. In a real AOSM workflow, the “artifact” would be a vendor package that matches required schemas.

Expected outcome: A blob exists in the container.

Create a small test file:

echo "Azure Operator Service Manager lab artifact" > sample-artifact.txt

Upload:

az storage blob upload \
  --account-name "$STORAGE_NAME" \
  --container-name "$CONTAINER_NAME" \
  --name "sample-artifact.txt" \
  --file "sample-artifact.txt" \
  --auth-mode login

List blobs:

az storage blob list \
  --account-name "$STORAGE_NAME" \
  --container-name "$CONTAINER_NAME" \
  --auth-mode login \
  --query "[].{name:name, size:properties.contentLength}" \
  -o table

Validation

You have successfully completed the lab if: – Microsoft.HybridNetwork provider shows Registered. – Storage account and container exist. – Managed identity exists and has Storage Blob Data Contributor role assignment on the storage account. – sample-artifact.txt appears in the blob list.

Troubleshooting

Problem: Provider registration stuck in “Registering” – Wait a few minutes and retry. – Confirm you have permission to register providers. – If it never registers, your subscription may not be eligible; verify Azure Operator Service Manager onboarding requirements in official docs.

Problem: AuthorizationPermissionMismatch when uploading to blob – Your user needs Storage Blob Data Contributor (or similar) at the storage account/container scope. – Ensure you are using --auth-mode login and you are logged in to the correct tenant/subscription.

Problem: RoleAssignmentExists – That’s fine; it means the assignment was already created.

Problem: Region errors – Choose a region supported by your subscription and the operator service. Verify in official docs.

Cleanup

To avoid ongoing charges, delete the resource group:

az group delete --name "$RG" --yes --no-wait

Confirm deletion:

az group exists --name "$RG"

11. Best Practices

Architecture best practices

  • Treat Azure Operator Service Manager as a control plane; design your runtime/execution environment with equal rigor (capacity, HA, networking).
  • Separate artifact onboarding from deployment responsibilities using subscriptions/resource groups and RBAC boundaries.
  • Standardize definitions and service designs, and enforce version pinning for production.

IAM/security best practices

  • Use least privilege:
  • Onboarding team: rights to create/update definitions and artifact references.
  • Operations team: rights to deploy/operate instances.
  • Security/audit: read-only with activity log access.
  • Prefer managed identities for automation over long-lived client secrets.
  • Separate control-plane permissions (ARM) from artifact data-plane permissions (Storage Blob Data roles).

Cost best practices

  • Implement artifact retention and lifecycle policies.
  • Avoid unnecessary cross-region artifact replication.
  • Monitor Log Analytics ingestion; keep only what you need at high verbosity.

Performance best practices

  • Keep artifacts close to the sites that will pull them (region strategy).
  • Size storage throughput appropriately if many sites deploy simultaneously.
  • Plan staged rollouts rather than “big bang” pushes.

Reliability best practices

  • Use multi-region strategy for critical artifacts (GRS/ZRS as required by your RTO/RPO).
  • Keep older versions available for rollback (but with clear retention limits).
  • Automate validation checks before promoting a definition version to production.

Operations best practices

  • Standardize naming: include publisher, NF name, version, and environment.
  • Enable diagnostic settings where supported; route to centralized Log Analytics.
  • Use change management: track deployments via tags, release IDs, and pipeline metadata.

Governance/tagging/naming best practices

  • Required tags: env, owner, costCenter, service, dataClassification.
  • Use Azure Policy to enforce:
  • Required tags
  • Allowed regions
  • Private endpoint usage for storage (if required)
  • No public blob access (if required)

12. Security Considerations

Identity and access model

  • Control plane: Microsoft Entra ID + Azure RBAC.
  • Data plane (artifacts): Azure Storage RBAC (Blob Data roles) and/or SAS policies (avoid SAS for long-lived automation where possible).
  • Implement separation of duties:
  • Artifact uploaders cannot deploy to production.
  • Production deployers cannot modify artifacts.

Encryption

  • Azure Storage encrypts data at rest by default (Microsoft-managed keys), with optional CMK depending on your requirements.
  • Use TLS for all artifact transfers.
  • If you require customer-managed keys, confirm supported configurations for your storage and any integrated components.

Network exposure

  • Prefer private endpoints for Azure Storage if compliance requires it.
  • Restrict storage access by:
  • Disabling public blob access (if not required)
  • Limiting networks and using firewall rules
  • Keep management-plane access controlled via RBAC, Conditional Access, and privileged identity management.

Secrets handling

  • Do not store secrets in artifact packages.
  • Use Key Vault and managed identity where your runtime platform supports it.
  • Establish a secret rotation process (certs, API keys) independent of artifact versioning.

Audit/logging

  • Use Azure Activity Log for who/what/when on control-plane actions.
  • Export Activity Logs to a central workspace and/or SIEM.
  • Ensure logs meet your compliance retention requirements.

Compliance considerations

  • Telecom deployments often require strict controls (change management, access logging, encryption, and retention).
  • Use Azure Policy and standard audit workflows.
  • Confirm data residency requirements (regions, replication) and align storage redundancy accordingly.

Common security mistakes

  • Granting broad Owner rights to automation identities.
  • Using long-lived SAS tokens for artifact access.
  • Leaving artifact storage publicly accessible.
  • No retention policy → infinite artifact accumulation and increased exposure.

Secure deployment recommendations

  • Use dedicated subscriptions for:
  • Onboarding/publishing artifacts
  • Staging
  • Production deployments
  • Use private networking for artifact storage and strict RBAC boundaries.
  • Integrate with security tooling: Defender for Cloud (where applicable), SIEM, and vulnerability scanning for artifacts (process design).

13. Limitations and Gotchas

Treat this section as a checklist to validate early in your design.

  • Access/onboarding may be required: Some operator services require tenant/subscription approval.
  • Region availability can be limited: Verify supported regions for your environment.
  • Execution environment dependency: You may not get value without a supported operator/edge platform to deploy into.
  • Artifact format strictness: Vendor packages must match expected schemas; onboarding can fail if packaging is inconsistent.
  • Data-plane vs control-plane permissions: Having ARM rights does not automatically grant blob upload/download rights.
  • Networking constraints: Private endpoints and restricted storage firewalls can break onboarding workflows if not planned.
  • Logging cost surprises: High telemetry volume can make Log Analytics expensive quickly.
  • Version sprawl: Without retention policies, definitions and artifacts accumulate and complicate operations.
  • API/CLI maturity: Some functionality may be preview or only exposed via REST/portal depending on timeframe—verify current tooling in official docs.
  • Change management complexity: Multi-site upgrades require careful orchestration to avoid service impact.

14. Comparison with Alternatives

Azure Operator Service Manager is specialized. It’s best compared to operator/telco lifecycle tools, not generic app deployment services.

Option Best For Strengths Weaknesses When to Choose
Azure Operator Service Manager Operator-grade onboarding and lifecycle of network functions and service designs Azure-native governance (RBAC, ARM, Activity Logs), versioned definitions, operator focus Requires supported targets and often onboarding; not for generic apps You manage telecom network functions across many sites and need Azure-governed lifecycle
Azure Kubernetes Service (AKS) + Helm + GitOps (Flux) Cloud-native apps and CNFs where you own packaging and ops Mature tooling, broad ecosystem, GitOps workflows You must build your own NF onboarding/versioning/governance model You have strong platform engineering and don’t need operator-specific onboarding constructs
Azure Arc-enabled Kubernetes + GitOps Hybrid + Multicloud Kubernetes fleet management Central policy, GitOps at scale, hybrid reach Not NF-specific; packaging and service design are DIY You need hybrid fleet governance more than telco-specific lifecycle constructs
Azure Operator Nexus (platform) Running operator workloads on a dedicated operator platform Operator-grade runtime platform Not the onboarding/service design control plane itself Use with AOSM when your target runtime is Operator Nexus (verify integration)
AWS Telco Network Builder Telco network function onboarding/deployment in AWS AWS-native telco tooling Different ecosystem; may not fit Azure-based operator strategy You’re standardized on AWS for telco NF lifecycle
Google Cloud telecom automation solutions Telco automation in Google Cloud Google-native automation patterns Different ecosystem; service parity varies You’re standardized on Google Cloud for telco automation
ETSI MANO stacks (ONAP / OSM) Standards-driven NFV orchestration Open-source/standards-aligned, vendor ecosystem Can be heavy to operate; integration effort You need broad ETSI MANO alignment and accept operational complexity
Vendor MANO / orchestrators (e.g., Nokia/Ericsson/HPE, etc.) End-to-end vendor-supported telco orchestration Integrated vendor support Vendor lock-in, less Azure-native governance You want a single-vendor supported stack and accept vendor coupling

15. Real-World Example

Enterprise / telecom operator example

Problem:
A telecom operator runs a distributed edge footprint (dozens of metro sites). Multiple NF vendors deliver monthly releases. The operator must enforce strict change control, run canary upgrades, and maintain audit trails for compliance.

Proposed architecture: – Azure Operator Service Manager as the onboarding + lifecycle control plane in a central Azure subscription. – Azure Storage accounts per region for artifact locality and redundancy. – Separation of duties via Azure RBAC: – Vendor integration team manages definitions/artifacts in a “publishing” subscription. – Operations deploys instances from approved versions in production subscriptions. – Log Analytics + SIEM integration for audit and operational telemetry. – Staged rollout pipelines (CI/CD) that promote versions across dev → staging → prod and deploy canary sites first.

Why Azure Operator Service Manager was chosen: – A centralized, Azure-governed resource model for NF artifacts and versions. – Better consistency than bespoke scripts across sites. – Auditable, policy-controlled management-plane operations.

Expected outcomes: – Reduced deployment time per site. – Safer upgrades with controlled version promotion. – Better compliance posture with centralized logs and RBAC.

Startup / small-team example (private 5G integrator)

Problem:
A small systems integrator deploys private 5G solutions for industrial customers. They need repeatable deployments and consistent packaging for a small set of CNFs across customer sites, but want Azure governance and a scalable approach.

Proposed architecture: – Use Azure Operator Service Manager for onboarding and versioning a curated catalog of approved CNFs. – Use standardized service designs for common customer profiles. – Automate deployments using a pipeline identity with least privilege. – Store artifacts in Azure Storage with lifecycle policies.

Why Azure Operator Service Manager was chosen: – Provides a structured lifecycle approach without building a custom system. – Helps keep versions consistent across customers.

Expected outcomes: – Faster onboarding of new CNF versions. – Reduced configuration drift across customer sites. – Improved operational repeatability.

16. FAQ

1) Is Azure Operator Service Manager the same as Azure Operator Nexus?
No. Azure Operator Service Manager is primarily a lifecycle/onboarding/service design control plane. Azure Operator Nexus is a runtime platform for operator workloads. They can be complementary; verify the supported integration path in official docs.

2) Do I need Azure Operator Service Manager to run CNFs on AKS?
Not necessarily. Many teams use AKS + Helm/GitOps directly. Azure Operator Service Manager is most relevant when you need operator-style onboarding, versioning, and lifecycle governance for network functions across sites.

3) Is Azure Operator Service Manager suitable for non-telco workloads?
Usually no. It is designed for operator network functions and service designs, not general application hosting.

4) What Azure resource provider does it use?
You may encounter the Microsoft.HybridNetwork namespace in ARM/provider registration. Verify the current mapping and required providers in the official Azure Operator Service Manager documentation.

5) Is it available in all Azure regions?
Operator services are often region-limited. Always verify region availability in official docs.

6) Do I need special subscription enablement?
Possibly. If provider registration or resource creation fails with forbidden/feature errors, you likely need onboarding/allowlisting. Verify in official docs and contact Microsoft support/account team.

7) Where should I store network function packages?
Commonly in Azure Storage with strict access controls, lifecycle policies, and (optionally) private endpoints. Exact requirements depend on your workflow and official guidance.

8) How do I manage access so vendors can upload artifacts but not deploy to prod?
Use separate subscriptions/resource groups plus Azure RBAC. Grant data-plane storage permissions only where needed, and keep production deployment permissions separate.

9) Does it support CI/CD automation?
Yes in principle (ARM/API-driven), but the exact tooling (CLI/SDK) and supported operations can vary. Verify current automation guidance in official docs.

10) How do I track who deployed what version to which site?
Use ARM resource states, tags, pipeline metadata, and Azure Activity Logs. For deeper operational telemetry, integrate with monitoring from the execution environment.

11) How should I handle rollbacks?
Keep previous versions of artifacts/definitions available and tested. Use staged rollouts and explicit version pinning for production deployments.

12) Can I use private endpoints for artifact storage?
Yes for Azure Storage, but ensure all components that need access can resolve DNS and reach the private endpoint. Misconfigured private networking is a common failure mode.

13) What are the biggest cost risks?
Typically log ingestion/retention and the runtime execution environment (compute/network). Artifact storage is usually smaller unless you retain many large packages across regions.

14) Does Azure Operator Service Manager validate vendor packages?
It can enforce schema/structure expectations as part of onboarding workflows. The exact validations depend on the official package requirements—verify in docs.

15) What should I build first: service designs or network function definitions?
Start with network function onboarding and definitions, validate deployment of a single NF, then compose multiple functions into service designs.

16) How does Hybrid + Multicloud relate here?
Operator deployments commonly span distributed sites and edge locations. Azure Operator Service Manager provides centralized governance while the execution environment may be deployed across hybrid footprints.

17) Can I export logs to a SIEM?
Yes. Use Log Analytics exports or diagnostic routing to Event Hub (common pattern) and then connect to your SIEM.

17. Top Online Resources to Learn Azure Operator Service Manager

Resource Type Name Why It Is Useful
Official documentation https://learn.microsoft.com/azure/operator-service-manager/ Primary reference for concepts, APIs, supported regions, and workflows
Official Azure CLI docs https://learn.microsoft.com/cli/azure/ Baseline CLI usage for provisioning prerequisites and automation
Azure REST API reference https://learn.microsoft.com/rest/api/azure/ Useful if AOSM operations require ARM REST calls (verify service-specific endpoints)
Azure Pricing Calculator https://azure.microsoft.com/pricing/calculator/ Estimate dependent service costs (storage, monitoring, network, runtime)
Azure Monitor docs https://learn.microsoft.com/azure/azure-monitor/ Logging, metrics, diagnostic settings, and operational patterns
Azure Storage security https://learn.microsoft.com/azure/storage/common/storage-security-guide Best practices for securing artifact storage
Azure RBAC documentation https://learn.microsoft.com/azure/role-based-access-control/ Designing least-privilege access for onboarding vs deployment
Azure Policy documentation https://learn.microsoft.com/azure/governance/policy/ Guardrails: tags, region restrictions, private endpoints, compliance
Azure Architecture Center https://learn.microsoft.com/azure/architecture/ Reference architectures and operational best practices (adapt to operator workloads)
Azure Well-Architected Framework https://learn.microsoft.com/azure/well-architected/ Reliability, security, cost optimization guidance for production designs

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com DevOps engineers, SREs, platform teams DevOps, cloud operations, pipelines, governance fundamentals Check website https://www.devopsschool.com/
ScmGalaxy.com Beginners to intermediate engineers SCM, DevOps foundations, automation practices Check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud ops and platform teams Cloud operations, monitoring, reliability practices Check website https://www.cloudopsnow.in/
SreSchool.com SREs, operations teams SRE practices: SLOs, incident response, observability Check website https://www.sreschool.com/
AiOpsSchool.com Ops teams, engineers adopting AIOps AIOps concepts, monitoring automation, operational analytics Check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz DevOps/cloud training and guidance (verify current offerings) Beginners to practitioners https://rajeshkumar.xyz/
devopstrainer.in DevOps training and mentoring (verify current offerings) DevOps engineers, SREs https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps support/training platform (verify current offerings) Teams needing hands-on assistance https://www.devopsfreelancer.com/
devopssupport.in DevOps support and training (verify current offerings) Ops/DevOps teams https://www.devopssupport.in/

20. Top Consulting Companies

Company Name Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com DevOps, cloud consulting (verify current portfolio) Cloud architecture, automation, operations Designing CI/CD for onboarding, governance baseline, monitoring integration https://www.cotocus.com/
DevOpsSchool.com DevOps and cloud consulting/training Platform enablement, DevOps processes Building deployment pipelines, RBAC design, operational readiness reviews https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting services (verify current portfolio) Automation, cloud operations Implementing IaC standards, monitoring/logging, cost controls https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Azure Operator Service Manager

  • Azure fundamentals: subscriptions, resource groups, ARM
  • Microsoft Entra ID basics: identities, service principals, managed identities
  • Azure RBAC and governance (Policy, tags)
  • Azure Storage fundamentals and security (Blob storage, private endpoints)
  • Monitoring basics (Azure Monitor, Log Analytics)
  • Kubernetes basics (helpful for CNFs, even if your target platform abstracts it)

What to learn after

  • Operator-grade runtime platforms (the execution environment your organization uses)
  • Advanced hybrid networking (site-to-site connectivity, private DNS, firewalling)
  • CI/CD for infrastructure and controlled rollouts
  • SRE practices for distributed systems (SLOs, incident response)
  • Compliance/audit patterns for telecom environments

Job roles that use it

  • Telco cloud/platform engineer
  • Network cloud engineer (NCE)
  • DevOps/SRE for operator platforms
  • NF onboarding/integration engineer
  • Cloud security engineer supporting operator workloads
  • Solutions architect for telecom/edge

Certification path (if available)

There is no universally recognized single certification dedicated only to Azure Operator Service Manager. Practical paths commonly include: – Azure fundamentals and architecture certifications – Security and governance certifications – Kubernetes certifications (for CNF-adjacent roles)

Always verify the latest Microsoft certification offerings and role-based guidance.

Project ideas for practice

  • Build an “artifact onboarding pipeline” that:
  • uploads a package to Azure Storage,
  • enforces naming/versioning,
  • records metadata in a release registry (Git tags + ARM tags).
  • Create Azure Policy initiatives enforcing:
  • required tags,
  • storage private endpoint requirement,
  • allowed regions.
  • Implement a logging blueprint:
  • Activity Logs → central Log Analytics
  • alerts on unauthorized changes (role assignments, storage firewall changes)

22. Glossary

  • AOSM: Azure Operator Service Manager.
  • ARM: Azure Resource Manager; Azure’s control plane for managing resources.
  • Publisher: Logical entity representing who publishes/onboards NF artifacts (verify exact definition in docs).
  • Artifact: A vendor-delivered package/bundle used to deploy a network function.
  • Artifact repository/storage: Where artifacts are stored (often Azure Storage).
  • NFD (Network Function Definition): Versioned deployable definition for a network function.
  • NSD (Network Service Design): A design composing one or more network functions into a service.
  • Instance: A deployed runtime entity created from a definition/design.
  • CNF: Cloud-Native Network Function (containerized network function).
  • VNF: Virtual Network Function (VM-based network function); support depends on platform/integration.
  • RBAC: Role-Based Access Control in Azure.
  • Managed Identity: Azure identity for workloads to access resources without storing secrets.
  • Data plane: Service endpoints used to access actual data (e.g., blobs in storage).
  • Control plane: Management endpoints used to create/update resources (ARM).
  • Activity Log: Azure log of control-plane operations.
  • Log Analytics: Centralized log store/query engine in Azure Monitor.
  • Private Endpoint: NIC in your VNet that maps to a PaaS service privately.
  • Least privilege: Grant only the minimal permissions needed.
  • Version pinning: Deploying a specific version intentionally to control upgrades.
  • Canary rollout: Deploying to a small subset first to reduce risk.
  • Hybrid + Multicloud: Architectures spanning on-prem/edge and multiple clouds.

23. Summary

Azure Operator Service Manager is an Azure control-plane service for onboarding, versioning, and lifecycle management of telecom network functions and network service designs, built on Azure Resource Manager and aligned with Hybrid + Multicloud realities like distributed edge sites and strict operational governance.

It matters because operators need a consistent way to manage multi-vendor network function packages, perform controlled upgrades, and maintain auditability across large site fleets—without reinventing lifecycle tooling per vendor and per site.

From a cost perspective, plan primarily for artifact storage, monitoring/log retention, and (most importantly) the execution environment where network functions run. From a security perspective, design strong RBAC separation, secure your artifact storage (private endpoints and least privilege), and centralize audit logs.

Use Azure Operator Service Manager when you are operating network functions at scale and need Azure-governed lifecycle controls. If you are deploying regular applications, prefer AKS/Arc and standard DevOps tooling.

Next step: read the official Azure Operator Service Manager documentation, confirm region/eligibility for your tenant, and extend the lab into a staging workflow that onboards a real vendor NF package and deploys it into your supported execution environment.