Amazon Web Services raised list prices on its GPU capacity twice in six months, something it had not done to an EC2 instance model in roughly twenty years of running the service. Microsoft's Azure had a five-hour outage in West US traced to a maintenance script that removed more network routes than it was supposed to. Both happened while the Kubernetes project and its surrounding networking tools kept shipping on schedule. Buyers running workloads on any of the three hyperscalers now have a cost story and a reliability story to watch at the same time.
AWS breaks its own pricing pattern
AWS raised prices on EC2 Capacity Blocks, the reservation model customers use to guarantee GPU capacity for short, fixed windows, on January 4, 2026 and again on July 1, 2026. The two increases compound to roughly 38 percent on the instance types most affected, including the p5e.48xlarge family (Network World, 2026; DataCenterDynamics, 2026).
Under AWS's current published rates, Capacity Blocks for ML now run $14.04 per accelerator-hour for P6-B300 instances, $12.355 for P6-B200, and $5.191 for P5, with older P4de capacity at $2.214 (Network World, 2026). AWS attributed the change to supply and demand for GPU capacity rather than any change in the underlying hardware cost, according to comments the company gave reporters (IT Pro, 2026).
What makes this notable is not the size of the increase. It is the direction. AWS On-Demand and Reserved Instance pricing for standard compute has trended downward for most of the service's history, and price cuts have been a recurring marketing moment at re:Invent. Capacity Blocks are a narrower product, aimed at teams that need guaranteed GPU access for training runs rather than steady-state capacity, so the increase does not touch every AWS customer. But it is the first time AWS has moved an EC2 pricing model up instead of down, and it lands at a moment when GPU-heavy workloads are a growing share of new cloud spend. Any team budgeting GPU capacity on Capacity Blocks for the second half of 2026 should reprice against the current page rather than an older quote.
Azure's West US outage traces to a maintenance bug, not a security incident
Microsoft Azure had a regional network outage in West US from 14:44 to 19:41 UTC on July 23, 2026, just under five hours of impact. Services affected included Azure Kubernetes Service, App Service, Application Gateway, ExpressRoute Circuits, Azure Monitor, and several Microsoft 365 services including Teams that depend on the same backbone (DataCenterDynamics, 2026).
Microsoft's own post-incident account, reported by Petri, traced the cause to a break-fix repair on a single optical device intended to address a network reliability risk. A defect in Azure's blast-radius analysis system misclassified the scope of that repair and applied it to every optical device carrying traffic out of the West US datacenter, removing IP routes it should not have touched. Traffic entering or leaving the region was affected; traffic that stayed inside the region was not (Petri, 2026).
The mechanism matters more than the outage itself. This was not a capacity failure or a demand spike. It was a change-management system that got its own blast radius wrong, a category of failure that is hard to catch with load testing because it is not a load problem. It also follows a separate AWS incident in May 2026, when a cooling failure in a single Northern Virginia data hall took EC2 and EBS offline in the us-east-1 region for close to a day and disrupted Coinbase and FanDuel among other customers (IT Pro, 2026). Neither hyperscaler has had a quiet year on reliability, and both incidents point to the same operational lesson: the failure mode that takes down a region increasingly starts in a single automated system making a decision at a scale nobody reviewed in time.
The open-source layer keeps shipping regardless
Against that backdrop, the Kubernetes ecosystem had a normal, productive summer. Kubernetes v1.37.0-rc.0 landed in early August with 67 total enhancements: 16 graduating to Stable, 23 to Beta, and 27 entering Alpha, ahead of a general availability date of August 26, 2026 (Kubernetes.dev, 2026). The headline stable feature is KYAML, a constrained YAML output format available across kubectl commands that use --output, designed to remove the whitespace-sensitivity and type-coercion bugs that make YAML configuration files a recurring source of production incidents (Cloudsmith, 2026). Device-level taints and tolerations for Dynamic Resource Allocation also graduate to GA in this release, continuing Kubernetes' multi-cycle push to make GPU and specialized-hardware scheduling a first-class, stable feature rather than an alpha add-on.
Cilium, the CNCF networking and security project many platform teams run underneath Kubernetes, shipped version 1.20.0 on July 29, 2026, with more than 2,660 commits from over 1,100 contributors. The release moves Cilium's Gateway API support from v1.4 to v1.6.1, which extends the same routing and policy model used for HTTP traffic to non-HTTP services including databases, DNS, and game servers, and adds support for authenticating and authorizing HTTPRoute requests through an external service before they reach the application (GitHub, 2026).
None of this is dependent on what the hyperscalers do with pricing or reliability. It is a reminder that the control plane layer buyers rely on for portability, the thing that in theory makes it easier to move workloads if a given cloud's pricing or uptime stops working for you, keeps advancing on its own release cadence.
What to watch next
Kubernetes v1.37.0 is scheduled to reach general availability on August 26, 2026. The gap between the current release candidate's feature list and what actually ships GA is normally small, but DRA changes in particular have shifted between RC and final release in past cycles, so platform teams building v1.37 into upgrade plans should confirm the finished changelog against the RC before locking configuration. On the pricing side, the next scheduled moment to watch is AWS re:Invent in December, historically the venue where AWS has announced compute price cuts. Whether Capacity Block pricing gets revisited there, in either direction, will be the clearest signal yet of whether the January and July increases were a one-off correction or the start of a new pattern.
Sources
- Network World, "AWS hikes prices for EC2 capacity blocks amid soaring GPU demand" - https://www.networkworld.com/article/4113150/aws-hikes-prices-for-ec2-capacity-blocks-amid-soaring-gpu-demand.html
- DataCenterDynamics, "AWS quietly increases prices for H200 EC2 instances by 15%" - https://www.datacenterdynamics.com/en/news/aws-quietly-increases-prices-for-h200-ec2-instances-by-15/
- IT Pro, "AWS Amazon EC2 capacity blocks price increase" - https://www.itpro.com/cloud/cloud-computing/aws-amazon-ec2-capacity-blocks-price-increase
- DataCenterDynamics, "Microsoft Azure outage at West US region causes intermittent connectivity failures" - https://www.datacenterdynamics.com/en/news/microsoft-azure-outage-at-west-us-region-causes-intermittent-connectivity-failures/
- Petri, "Microsoft Azure outage: network maintenance error" - https://petri.com/microsoft-azure-outage-network-maintenance-error/
- Kubernetes.dev, "Release schedule / resources" - https://www.kubernetes.dev/resources/release/
- Cloudsmith, "Kubernetes 1.37: what you need to know" - https://cloudsmith.com/blog/kubernetes-1-37-what-you-need-to-know
- Cilium GitHub, "Release v1.20.0" - https://github.com/cilium/cilium/releases/tag/v1.20.0
- IT Pro, "AWS outage explained: May 2026 data center overheating" - https://www.itpro.com/infrastructure/aws-outage-explained-may-2026-data-center-overheating