Azure News - 2026-10-08

Bring Your Own Key (BYOK) lets you import externally generated key material into Azure Key Vault. Importing that material again creates a new version; it does not recreate the original version identifier. If Azure Storage still requires the original customer-managed key (CMK) version to unwrap (decrypt) its account encryption key, re-importing the same material under a new version does not restore that access.

With Azure Storage CMK, the key in Key Vault wraps the account encryption key. A key change requires access to the current CMK version to unwrap the account encryption key before it can be wrapped with the new key. If the required version cannot be recovered at the referenced endpoint, importing the material under a new URI does not complete the transition.

Keep both the key material and the required Key Vault versions recoverable. Re-importing the material alone cannot complete a recovery operation that requires the original version.

The backup and restore procedures below apply to Azure Key Vault, not Azure Key Vault Managed HSM.

BYOK re-import vs. key restore

A versioned key URI includes the vault endpoint, key name and version identifier. Importing a key under an existing name creates a new version. Restoring a Key Vault key backup preserves the name and the version identifiers captured in that backup. These operations are not interchangeable, even when the imported material is identical. 

Restoring to another vault preserves the saved version identifiers but changes the vault endpoint and therefore the full URI. A service that still needs the original URI may be unable to switch to the restored copy. Account for the original endpoint, access permissions and service configuration when planning recovery.

Record each versioned key URI together with its dependent workloads, access identities and owner. This inventory is needed when rotating a shared key, changing vaults or recovering from a deletion. Retain the external key material and any Key Vault object backups required by the recovery policy.

If a dependent service references a key version that is no longer available, work in this order:

1. Check whether the key or the vault is soft-deleted. If it is, recover it; recovery brings back the original identifiers.
2. Otherwise, restore the most recent Key Vault backup that contains the referenced version into the original vault.
3. If neither is possible, open a Microsoft support case before you import replacement material or change the service's key configuration.

Key rotation in Azure Storage

Creating a new version in Key Vault does not immediately change every dependent service. Azure Storage must start using the new key version before the previous version is disabled. Keep the old and new versions enabled and accessible while the change completes. Storage updates the protection of its root encryption key without re-encrypting the stored data.

When automatic version updates are configured, Storage checks for a new version daily. Microsoft recommends waiting 24 hours after rotation before disabling the previous version. If the account is pinned to a specific version, update the configured version explicitly. Confirm the version in use and test data access before disabling the previous version; elapsed time alone is not sufficient.

If new keys must originate in your HSM, generate the material there and import it through the supported BYOK process. Re-importing unchanged material creates a version, but does not constitute cryptographic key rotation. Key Vault auto-rotation generates new material in Azure, not in your HSM, so you cannot use it for these keys.

This sequence assumes that the account is pinned to a key version, so the switch in step 4 happens only after the backup in step 3. With automatic version updates, Storage can adopt the new version at its next daily check, possibly before the backup exists. If your policy requires a backup before use, pin the key version and update it explicitly once the backup has completed.

Soft delete and purge protection

Azure Storage CMK requires soft delete and purge protection. Soft delete provides a configured recovery window of 7 to 90 days, with a default of 90 days. Purge protection prevents permanent deletion before that window expires. It does not prevent the initial deletion or keep a deleted key available to the service. 

Monitor key deletions and failed key access, and investigate before the recovery window closes. If the required object is still soft-deleted, recover it rather than importing a replacement. A recovery procedure must include the permissions, network access and responsible owner needed to perform that operation.

Monitoring and guardrails

Key Vault records key operations in its AuditEvent log category. Send these logs to a Log Analytics workspace with a diagnostic setting, and alert on operations that change which keys and versions exist.

If your diagnostic setting writes to resource-specific tables, query AZKVAuditLogs instead; some column names differ.

On the storage side, lost key access surfaces as HTTP 403 errors such as KeyVaultEncryptionKeyNotFound, KeyVaultVaultNotFound or KeyVaultAccessTokenCannotBeAcquired. Treat these errors as incidents, not as transient failures.

Resource locks do not protect keys. A CanNotDelete lock prevents deletion of the vault resource, but locks apply only to control plane operations, and deleting a key is a data plane operation. Limit who can delete, purge, back up and restore keys, and review those assignments regularly.

Retention of previous key versions

Active workloads, migrations and retained data backups can require old key versions after a rotation. Determine those dependencies before setting a retirement date. Data backups may still depend on retained encryption keys. Verify which versions the service requires to restore each retained recovery point; these dependencies vary by service. 

Test the recovery points you must retain before retiring a key. Keep disabling and deleting as separate decisions, with an owner for each. Key Vault does not support deleting individual historical versions, so deletion is not a version-cleanup strategy. 

Backup scope and restore constraints

A Key Vault key backup is an encrypted object snapshot, not a plaintext key export or a whole-vault backup. It can be restored only to a vault in the same Azure subscription and geography as the source vault, though not necessarily the same region. Restore brings back all captured versions, not one selected version. The original key name must be available in the destination. 

A snapshot does not include versions created after the backup, and restoring the key does not rebuild identities, permissions or networking. Backing up a key with more than 500 versions is not supported. Check version counts and backup completion as part of the rotation process.

Where key backups are required, back up the key again after each import or rotation. If policy requires a backup before use, configure the service to use the new version only after its backup has completed. Automatic adoption can otherwise occur before the backup completes. Keep the backup accessible even when the source CMK is unavailable. Restrict backup and restore permissions and monitor their use. Disabling the original key does not disable a copy restored elsewhere. 

Checking the active key version

The following Azure CLI commands use PowerShell line continuation. Replace the placeholders, sign in to the intended tenant and run each command separately, stopping on errors. The storage account and the key vault can be in different subscriptions. You need read, list, backup, and restore permissions, plus network access to the vault. The storage account's managed identity separately needs the get, wrapKey, and unwrapKey permissions. With Azure RBAC, the Key Vault Crypto Service Encryption User role covers these permissions.

Read the account's key properties and list the available versions:

az keyvault key list-versions --subscription "<key-subscription>" --vault-name "<source-vault>" --name "<key-name>" --query "[].kid" ` --output tsv

The currentVersionedKeyIdentifier property reports the version in use. An empty keyVersion means that automatic version updates are enabled; a value means that the account is pinned to that version. Do not rely only on the configured keyVersion or the newest version in Key Vault. Record the identifier before and after the change, and test application reads and writes separately. Azure Storage does not currently log key rotation in its Azure Monitor logs, so this record may be your only evidence of which version was in use.

Backup and restore with Azure CLI

Create a key backup with a unique file name for each snapshot:

az keyvault key backup --subscription "<key-subscription>" --vault-name "<source-vault>" --name "<key-name>" --file $backupFile

To test the restore, use an approved, isolated test vault in the same subscription and geography. The key name must not already be active or reserved by a soft-deleted object. HSM-protected keys require a compatible Premium vault. Do not delete or purge production keys to make room for a restore test.

az keyvault key list-versions --subscription "<key-subscription>" --vault-name "<isolated-test-vault>" --name "<key-name>" --query "[].kid" ` --output tsv

Compare the final version segment of each returned URI with the source inventory; the vault hostname will differ. These commands do not change Storage encryption. A successful test restore validates the backup, not the service recovery procedure. Test that procedure separately with a non-production workload before relying on it for production recovery.

Key retirement checklist

• Identify all services that use the key. Avoid unnecessary key sharing across production and non-production.
• Verify that the backup includes the required versions and can be restored to the intended destination.
• Confirm the version in use, test data access, and validate the required backup restores.
• Disable the old version only after confirming that no active workload or required backup restore still needs it.

Reliable recovery requires the key material, the referenced versions and a tested service recovery procedure. When a recovery operation depends on the original CMK version, re-importing the material under a new version cannot replace it. Disable old versions only after you verify that no remaining workload or backup depends on them.

Anyscale on Azure is now Generally Available. Enterprises can run the Ray distributed runtime as a managed service on Azure Kubernetes Service (AKS), with workloads running in the customer’s own Azure subscription, network, and identity boundary.  

With General Availability, Anyscale on Azure is ready for production workloads and comes with the commitments enterprises need. It is backed by a service level agreement and production support from both Microsoft and Anyscale. Customer workloads, datasets, and model artifacts run in their Azure subscription, while Anyscale operates the control plane in its own Azure tenant. Customers can use their Azure identity and governance controls for the resources in their subscription. Xoople is already using Anyscale on Azure to turn planetary-scale satellite imagery into decision-ready intelligence.

AI systems need more than a good model 

Model quality is only part of the challenge. Enterprises must also connect, secure, and operate the stages around the model. A typical stack assembles one tool for data preparation, another for distributed training, a third for evaluation, and a fourth for serving. Each tool solves part of the problem. Connecting them can require custom integration code, separately provisioned compute, and security controls that teams must maintain across systems. 

The resulting challenges fall into four areas: 

• Utilization: GPUs provisioned per stage can sit idle while another stage waits for capacity. Reserved capacity that is idle is still billed. 

• Security and governance: Teams must manage who can access data and models, where they are processed, and how security controls are configured across each system and handoff. 

• Engineering time: Integration code requires ongoing maintenance, monitoring, and troubleshooting alongside the tools themselves. 

• Development cycle time: Handoffs between stages can slow the path from experimentation to production. 

Anyscale on Azure addresses this fragmentation by bringing data preparation, training, evaluation, and inference into a common runtime and operational model. Shared infrastructure can reduce idle compute capacity, while managed Ray cluster lifecycles reduce the infrastructure work teams perform themselves. Workloads, datasets, and model artifacts remain in the customer’s Azure subscription, where teams configure access and networking controls. Using a common runtime across stages can also reduce the need to maintain separate compute stacks.  

The goal is to support an AI learning loop, not just inference: production feedback informs data curation, training or post-training, and evaluation before updated models return to serving. Anyscale provides the common compute platform; teams remain responsible for their models, evaluation criteria, application workflows, and security configuration.

How Anyscale on Azure works 

Anyscale on Azure is an Azure Native Integration with an Anyscale-operated control plane and a customer data plane that keeps core resources in the customer’s Azure tenant, helping teams maintain their security and data-residency requirements. 

Anyscale hosts and operates the control plane in Azure. You reach it from the Azure Portal, the Anyscale console, or the Anyscale CLI and SDK. The data plane runs entirely inside your own Azure subscription: Anyscale deploys an operator into your AKS cluster, which manages Ray cluster lifecycles on your behalf. This keeps Ray workloads, datasets, and model artifacts in your Azure subscription, while the Anyscale-hosted control plane processes operational metadata. Workloads run on AKS within your virtual network and use your existing Microsoft Entra ID, Azure RBAC, and private networking controls. 

The Anyscale operator and Ray clusters initiate outbound connections to the Anyscale control plane, so Anyscale does not require inbound firewall access to AKS nodes for those connections. Anyscale on Azure integrates with Azure Managed Identities for authentication, Azure Blob Storage and ADLS for data, Azure Key Vault for secrets, and Azure Container Registry for images. 

Use familiar Azure identity and resource controls 

Anyscale on Azure is backed by Azure Resource Manager, allowing platform teams to apply Azure Policy and discover Anyscale resources through Azure Resource Graph, just as they do with other Azure resources. 

For regulated industries such as financial services, healthcare, and public sector, Anyscale on Azure makes in-tenant AI attainable. 

In production: Xoople

Xoople is building what it calls Earth's system of record, a continuously updated and AI-ready picture of how the planet's surface is changing.  

The workload is a useful illustration of why a unified runtime matters. Turning raw spectral data from satellite constellations into decision-ready measurements is not primarily a model problem. It is continuous, large-scale, heterogeneous computation: ingest and reprojection, calibration, feature extraction, model training, and inference, each at a different shape and each needing different hardware.

With Anyscale on Azure, Xoople can reliably run massively distributed AI workloads over planetary-scale satellite imagery, transforming complex spectral data into decision-ready intelligence. Anyscale lets our teams focus on models and outcomes rather than infrastructure, dramatically accelerating the path from experimentation to deployment. 

— Milos Colic, VP of Engineering, Xoople 

Workloads teams run on Anyscale on Azure 

One runtime for the entire AI lifecycle 

One Ray runtime supports data preparation, training and fine-tuning, batch and online inference, and long-running agentic workloads. When each stage has its own compute, capacity reserved for one can sit idle while another waits. A shared scheduler reallocates compute as demand shifts, which can reduce idle capacity and lower infrastructure costs.

Model choice also matters. Fine-tuned, task-specific models can cut serving costs when they meet quality requirements, so weigh total cost, not inference alone. The Anyscale Runtime supports Ray APIs, so existing Ray code needs fewer changes to move over. Customers should validate dependencies, data access, networking, and deployment configuration.

Get started 

Anyscale on Azure is provisioned from the Azure Portal onto an AKS cluster in your own subscription. You manage and monitor deployments from Portal, and use the Anyscale console, CLI, and SDK for cluster-level work. 

1. Review the Anyscale on Azure overview on Microsoft Learn for architecture and prerequisites. 
2. Check regional availability against where your data resides. 
3. Create an Anyscale cloud on an existing AKS cluster from the Azure Portal, then configure managed identities for access to Blob Storage, Key Vault, and Container Registry. 
4. Move an existing Ray workload using compatible Ray APIs, after validating dependencies and deployment configuration, or start from the Anyscale on Azure quickstart. 

Check current Azure pricing and offer eligibility before assuming free-account credits apply to Anyscale on Azure usage. 

Resources 

• Anyscale on Azure architecture and overview   
• Anyscale on Azure pricing 
• Anyscale on Azure solution page  
• Anyscale on AKS Terraform reference deployment 
• Anyscale on Azure public preview announcement  
• Anyscale on Azure press release, June 2, 2026  
• Announcing Anyscale Runtime  
• Ray on AKS overview