An application can be running perfectly well while the infrastructure beneath it becomes harder to expand, more expensive to retain, or more demanding to operate. That is a familiar enterprise problem, and it provides a useful way to read Azure’s announcements since the beginning of September. Microsoft is changing how customers plan the life of a virtual machine, where Kubernetes can run, and how much of the surrounding operational work the platform can absorb.
I see Azure becoming more deeply involved in the continuing operation of the enterprise estate. The latest developments extend its management model onto customer hardware while making the public cloud more capable of maintaining itself. This is a sensible direction for organizations with long-lived applications and mixed infrastructure. It also gives Microsoft a larger role in their architecture and spending decisions. The changes through October 17 make that direction much more concrete.
Modernization becomes a continuing obligation
The VM lifecycle policy published on September 28 establishes four stages: Current, Extended, End of Life and Retired. Current families are the preferred destination for new deployments. Extended families remain supported, with transition planning encouraged. End of Life means retirement has been announced, while maintenance and support continue; capacity, purchasing options and pricing can become less favorable. At retirement, remaining VMs are deallocated and lose support and SLA coverage. The initial policy covers general-purpose, memory-, compute- and storage-optimized families. It makes the consequences of retaining older infrastructure much more explicit.
For example, Microsoft’s retirement guidance for Dv3, Dsv3, Ev3 and Esv3 sets November 15, 2029 as the deadline in the affected public-cloud environments, excluding government, 21Vianet and sovereign regions. Capacity growth restrictions already apply separately. An application owner therefore has to consider whether a workload can expand or be redeployed as well as whether it runs today. HPC Pack 2019’s end of support in August 2027 creates a related planning task for organizations relying on that cluster-management and scheduling stack. Cloud adoption has not removed infrastructure renewal from the budget.
There are new destinations for that renewal. The Lasv5 and Laosv5 VM families reached general availability on September 29. They combine fifth-generation AMD EPYC processors with substantial local NVMe storage for workloads such as caching and distributed storage. Laosv5 provides three times the local storage capacity per vCPU of Lasv5. The useful distinction is the resource balance: organizations can choose a denser storage configuration without treating every storage-heavy workload as a reason to buy proportionately more CPU.
Azure Migrate’s September previews address the work needed to reach a new environment. Network assessments examine VMware environments, including NSX, and recommend Azure networks, security controls and load-balancing resources alongside readiness and cost estimates. Auto Wave Planning uses inventory, assessment results, application mappings and dependencies to propose migration groups and their order. Together, these features bring the application’s connections and sequencing into the migration plan. That is a substantial improvement over a project organized around a list of servers, because moving the machines is only useful if their applications can still communicate.
The management-group scope added to savings-plan and reservation recommendations also fits this broader view. Finance and platform teams can evaluate opportunities across an organizational hierarchy of subscriptions, rather than assemble every subscription’s picture separately. I would connect this directly to modernization planning. A recommendation based on consumption is useful evidence, but a commitment should reflect the infrastructure the business expects to retain. Microsoft is improving the view of current demand; deciding which demand will survive a migration remains an architectural and financial judgment.
Azure management reaches further into the estate
The September 22 public preview of AKS flex nodes lets an existing Azure Kubernetes Service cluster use worker nodes in other Azure regions, on premises or at the edge. An encrypted overlay connects those nodes to the cluster’s API server, and Kubernetes scheduling and access controls operate across the expanded cluster. This offers a way to use capacity near an application’s data, or capacity available elsewhere, without introducing another cluster control plane. The management boundary grows while the compute can stay where it is needed.
AKS on bare-metal Ubuntu, announced on September 30, takes a different approach. Both the Kubernetes control plane and the workloads run on customer-owned Ubuntu hardware, without a hypervisor between Kubernetes and the server. Azure supplies the management integration, while the customer retains control over the host and hardware stack. The current public preview is limited to single-node clusters, so this is an evaluation opportunity for local and edge computing rather than a ready-made replacement for a large production cluster. Its significance is the direction: Azure’s Kubernetes offering is extending to infrastructure Microsoft does not own.
September’s Azure Red Hat OpenShift hosted-control-plane preview changes the division of work within Azure itself. The control plane moves outside the customer’s worker subscription, while application workers remain in the customer’s virtual network. The documented architecture reduces the minimum customer compute footprint from three control-plane nodes and three workers to two workers, and separates control-plane upgrades from worker-pool upgrades. That could make smaller clusters and stronger separation between application teams easier to justify. The economic change comes from reducing the infrastructure and coordination needed to operate each cluster.
Azure Virtual Desktop Hybrid became generally available in September. Azure Arc connects local session hosts to the Azure desktop service, so organizations can deliver remote applications and desktops from infrastructure they already own. The service handles the cloud desktop layer while the customer operates the local machines. Provisioning, power management and autoscale remain outside this hybrid offering, and Windows Enterprise multi-session is unsupported. This is nevertheless a useful concession to enterprise reality: a business can adopt a managed access service while continuing to use its existing hosting investment.
Other Virtual Desktop changes make that service easier to operate and reach. Regional host pools, generally available in September, store host-pool metadata in the chosen region instead of a database shared across regions, reducing cross-region dependencies. Managed identities also reached general availability for supported host-pool operations, including session-host configuration, autoscale and Start VM on Connect. October adds general availability of external-identity support in Windows App on iOS, allowing invited external users to access assigned desktops and applications from that client in supported configurations.
These announcements describe several distinct deployment models, but they share a commercial logic. Microsoft can supply more of the operating environment even when moving every workload into an Azure datacenter would be impractical. I think that is a stronger enterprise proposition than treating retained infrastructure as an unfinished migration. It gives customers more choice about location while increasing the importance of Azure’s identities, policies and management services to the estate as a whole.
More operational work moves into the platform
Azure Firewall explicit proxy reached general availability on September 2. Applications and browsers can send outbound HTTP and HTTPS traffic to the firewall through ordinary proxy settings. The GA release uses one proxy endpoint port for both, and can retrieve proxy auto-configuration files from Blob Storage using a managed identity. This lets organizations replace self-managed forward proxies while retaining a familiar application configuration. It also allows selected traffic to pass through the firewall without redirecting every connection from the subnet, making modernization easier to stage.
Network security perimeter metrics became generally available on September 30. For protected resources, Azure Monitor now exposes aggregate allowed and denied access activity that teams can chart, alert on and compare as rules change. Teams can establish a traffic baseline before enforcing a perimeter and see whether a policy change produces unexpected denials. Detailed investigations still use diagnostic logs, but routine monitoring becomes more accessible. Security policy is more useful when its effect is visible to the people operating the application.
Reliability is receiving similar treatment. Microsoft’s September 9 guidance on two-zone and three-zone designs asks architects to evaluate each component’s surviving capacity and consistency requirements. A stateless application tier and a quorum-based system need different reasoning. This is architecture guidance, not a new service, and I welcome its emphasis on proving what survives a failure. Counting zones on a diagram cannot establish that the remaining application will carry the business workload.
Two scale-set features turn parts of that reasoning into platform behavior. September’s Automatic Zone Placement preview chooses zones for new instances using SKU availability, capacity and customer constraints. It reduces the need to maintain fixed zone lists for every region. Automatic Zone Balance was announced as generally available on October 15 and addresses an existing deployment’s uneven distribution. Its create-before-delete mechanism creates a replacement in an underrepresented zone and checks health before removing an instance elsewhere. Placement governs new capacity; balancing corrects drift. Because balancing recreates instances, the application must tolerate that lifecycle, and it should not be treated as a zone-outage recovery system.
The October 14 general availability of StandardV2 NAT Gateway for AKS-managed egress strengthens another dependency that can otherwise undermine a resilient cluster: outbound connectivity. StandardV2 is zone redundant, supports IPv6 and raises the throughput ceiling from 50 to 100 Gbps. New clusters using the applicable API and managed-NAT configuration receive it in supported regions. Existing clusters retain Standard until migrated. That migration replaces the gateway and changes its public addresses, so it requires coordination with systems that allowlist outbound traffic. The improvement matters because distributing application workers across zones achieves little if their shared route to essential external services remains vulnerable.
Specialist infrastructure is also moving into managed services. Azure Payment HSM v2 entered public preview on September 17, initially in West US and West Europe. It combines Marvell hardware security modules with Utimaco Atalla payment software to provide cryptographic operations such as PIN translation, card issuance and key management through Azure. For payment providers, the proposed operational change is substantial: consuming the payment-security platform as a service can remove the need to deploy and maintain its physical appliances. Azure is extending into work that previously required a particularly specialized local infrastructure team.
The engineering underneath Azure is changing too
Anyscale on Azure reached general availability on October 7. It provides managed Ray, the distributed-computing runtime, on AKS. Customer workloads, datasets and model artifacts stay in the customer’s Azure subscription, while Anyscale operates its control plane in its own Azure tenant and processes operational metadata there. The relevant Azure development is the packaging of specialist infrastructure into a supported operating service. Teams can run distributed workloads without taking on every part of the Ray cluster lifecycle themselves.
The Open Compute Project announcements on October 13 show how far below the software interface the next round of infrastructure work reaches. Microsoft’s power architecture work advances 800-volt DC distribution and the Mt. Diablo design, which moves power conversion into a separate rack so power and compute can scale independently. Solid-state transformer research aims to reduce conversion stages between the utility supply and computing equipment. These are engineering initiatives at differing stages of development, rather than new Azure services to select in the portal. Their purpose is to make increasing compute density physically and economically supportable.
On networking, Microsoft and partners have released the Multipath Reliable Connection v1.0 specification through OCP. It distributes an RDMA connection, used for high-speed communication between machines, across multiple network paths. Traffic can use available capacity and route around congestion or failed links, helping large accelerator systems continue useful work. The strategic point is that buying more compute is insufficient if its communication system leaves it waiting. Azure’s future performance depends increasingly on the behavior of the complete system.
The hardware-security announcements apply the same thinking to trust. Tessera Integrated HSM opens the specifications and supporting software for hardware-protected key management close to workloads, with a path toward fully open-source silicon. Composite Entity Attestation Token binds evidence from components such as CPUs, GPUs and storage into a single signed platform claim, simplifying verification of a whole machine. These contributions aim to make independently supplied components work together securely. Open interfaces help Microsoft build and evolve its infrastructure with a wider ecosystem; they do not, by themselves, make an Azure application portable to another provider.
Taken together, this is a credible direction for Azure. Microsoft is improving the machinery that keeps applications running while widening the range of infrastructure that its management services can reach. AI helps explain the urgency of the power and network work, but the broader enterprise benefit is operational: more placement decisions, lifecycle tasks and specialist services can be handled through the platform. Fabric, databases and Copilot deserve their own examination; this infrastructure story already has consequences for organizations whose main concern is dependable business applications.
I would judge the next phase by how much operating work these services actually remove. Retaining local compute can be the right decision if Azure makes it easier to govern and maintain. A new managed service earns its place when fewer people need to coordinate upgrades, diagnose dependencies or keep specialist appliances running. The tradeoff is a deeper relationship with Microsoft’s operating model, even where the hardware remains elsewhere. For many enterprises that will be worthwhile. The strongest case for Azure is becoming the quality of that continuing relationship, measured in reliable applications and manageable costs over their working lives.
