Responsible infrastructure at hyperscale: Managing the full lifecycle of Azure hardware

Every new generation of cloud infrastructure creates two jobs. We must deploy more capable systems quickly, and we must manage the hardware they replace responsibly.

Even though these jobs happen behind the scenes, the results matter to Microsoft Azure customers. Newer systems deliver more compute capacity from the space and power available in a datacenter. At the same time, the reuse, refurbishment, and recycling of older equipment can extend the life of valuable components and return materials to the supply chain, ensuring cost efficiency and reliability.

Managing this process starts early in the lifecycle, with the design of our silicon, servers, networks, and datacenters. It continues through years of operation. When equipment leaves active service, Microsoft Circular Centers help determine its next useful life.

Discover more about Microsoft Circular Centers

With new Circular Centers in Newport, Wales, and Sydney, Australia, this work now spans North America, Europe, and Asia Pacific. These facilities help us recover components, prepare space for new infrastructure, and get more value from the hardware and materials already in our system.

Getting more from every rack and every watt

Cloud infrastructure must keep pace with the work customers want to run. That means increasing compute capacity while making better use of the space and power available in each datacenter.

Compared with early general-purpose systems, today’s servers provide significantly more processor cores, more memory capacity, and network bandwidth. As shown in the chart below, Azure infrastructure has become both denser and more efficient over time. Since 2014, cores per rack have increased approximately 13-fold, while the power required to complete the same task has decreased by roughly 90%. For example, a workload such as code compilation that consumed approximately 100 watts on early systems can now be completed using less than 10 watts.

This increase in compute density means we’re able to provide more server capacity to support customer workloads using the same datacenter footprint. By delivering more useful work from each rack, newer infrastructure helps improve resource efficiency while supporting continued growth and scale to meet cloud and AI demand.

Source: Microsoft internal analysis using combined average data across general compute infra partners and Cobalt using industry benchmark performance such as SPEC CPU report and industry-standard utilization markdown.

Azure Cobalt is one example of this systems approach. Our custom-designed cloud processor allows Microsoft to optimize silicon, servers, networking, storage, and software together. Cobalt 200 delivers up to 50% higher performance than Cobalt 100 and incorporates the latest Microsoft security, networking, and storage technologies.

This constant cycle of innovation is one of the defining characteristics of cloud infrastructure. As new generations of cloud and AI infrastructure are deployed, older hardware is gradually taken out of service. What happens to the equipment being replaced?

Giving hardware its next useful life

Last year, Microsoft achieved a 92% reuse and recycling rate for decommissioned servers and components. However, at the scale we operate, retiring a server is a little more complex than simply sorting components into the correct recycling bin. Every server must be securely decommissioned, and data-bearing components wiped. Then we must decide how to recover the most value from it. Can the complete system serve another purpose? Can processors, memory, and other components keep working elsewhere? Which materials can return to the supply chain?

Microsoft Circular Centers manage these decisions as part of our datacenter operations. At these facilities, our staff give decommissioned hardware a series of possible next lives. Complete systems can support Microsoft labs and training environments, help schools and universities teach technical skills, or be sold to qualified buyers for continued use. Components can become spare parts for other systems. Materials are recycled when reuse is no longer possible.

Our Circular Centers operate as a connected global network. With recent launches in Wales and Australia, eight centers are now in operation across North America, Europe, and Asia Pacific. The network continues to grow, with a new center planned for San Antonio, Texas.

We are also investing in technologies that improve the efficiency and scale of circular operations. Through automation initiatives with AI-powered capabilities, such as robotic disassembly and autonomous material handling, we are helping accelerate the recovery of components and materials.

Making the most of every resource

As demand for cloud and AI continues to grow, every part of the infrastructure lifecycle matters. We must get more compute from every rack and every watt, while getting more value from every server and component. Circular Centers help us do both. They make responsible recovery part of how we grow Azure, renew the foundational infrastructure, and build capacity for what customers need next.

Learn More

Explore Azure migration and modernization.

Learn more about Microsoft’s silicon to systems approach to Azure Infrastructure.

Learn how Microsoft Circular Centers are scaling cloud supply chain sustainability.

Read Microsoft’s 2026 Environmental Sustainability Report.

Microsoft Circular Centers

Helping deliver towards our commitment on Zero Waste

Take a virtual tour

The post Responsible infrastructure at hyperscale: Managing the full lifecycle of Azure hardware appeared first on Microsoft Azure Blog.
Quelle: Azure

Amazon Aurora DSQL now supports partial indexes

Amazon Aurora DSQL now lets you build an index over a specific subset of a table, storing only qualifying rows rather than every row in the entire table, which improves query performance and lowers index storage cost.
Many tables hold a small working set alongside a much larger history, such as open orders among years of completed ones. Add a WHERE clause to CREATE INDEX to index just that working set. The index stays small as the table grows, and queries that target those rows read less data. Aurora DSQL uses a partial index for any query whose filter falls within the index’s condition.
Partial indexes are available in all AWS Regions where Aurora DSQL is available. To learn more, see CREATE INDEX in the Aurora DSQL User Guide.
Quelle: aws.amazon.com

Amazon ECS adds Amazon VPC Lattice support for blue/green, linear, and canary deployments

Amazon Elastic Container Service (Amazon ECS) now supports built-in blue/green, linear, and canary deployment strategies for ECS services using Amazon VPC Lattice. Applications that use VPC Lattice for service-to-service communication across VPCs and AWS accounts can now take advantage of managed traffic shifting natively from Amazon ECS when rolling out updates.
With this launch, ECS customers using VPC Lattice can shift traffic in a controlled manner during deployments, choosing how quickly traffic moves based on their confidence in each release: all at once with blue/green, in equal increments with linear, or starting with a small percentage with canary. Teams can validate new versions with test traffic before shifting production traffic, and run custom validation steps or manual approvals with deployment lifecycle hooks, including Lambda and pause hooks. These services can also use Amazon CloudWatch alarms and the Amazon ECS deployment circuit breaker to automatically roll back deployments if issues are detected, with bake time keeping the previous version ready for a quick rollback without downtime.
To get started, select your VPC Lattice target groups, listener rule, and preferred deployment strategy in the ECS service configuration using the AWS Management Console, AWS CLI, AWS SDKs, or Infrastructure-as-Code tools. This functionality can be enabled for both new and existing ECS services in all AWS Regions where VPC Lattice is available. For more information, see Amazon ECS deployments with VPC Lattice.

Quelle: aws.amazon.com

Amazon ElastiCache for Valkey now supports OpenTelemetry metrics and detailed monitoring

Amazon ElastiCache for Valkey now publishes OpenTelemetry metrics to Amazon CloudWatch for your node-based clusters, and each metric carries attributes you can filter and aggregate on with Prometheus Query Language (PromQL) expressions. ElastiCache now offers two monitoring modes. Standard monitoring, the existing experience, continues to publish CloudWatch Metrics (Classic) every 60 seconds and now also publishes a core set of OpenTelemetry metrics at the same interval at no additional charge. Detailed monitoring, the new mode, lets you select from the full set of OpenTelemetry metrics and publish them every 15 seconds.
With OpenTelemetry metrics, you can detect any node in a cluster nearing its connection limit, break errors down by type during an incident, or forecast if a node will run out of memory. You can run these queries in CloudWatch and Grafana, keeping PromQL skills your team already has. With detailed monitoring, you can balance diagnostic depth and cost, with 15-second metrics enabling detection of short-lived events like latency spikes. The core set of OpenTelemetry metrics also powers ElastiCache Insights, a pre-built dashboard in Amazon CloudWatch.
To get started, open the Metrics tab for a cluster in the Amazon ElastiCache console, select Detailed, and choose Configure detailed metrics.
OpenTelemetry metrics and detailed monitoring are available for node-based Valkey clusters in all AWS Regions where Amazon CloudWatch supports OpenTelemetry metrics. There is no additional charge from ElastiCache for detailed monitoring. CloudWatch pricing for OpenTelemetry metrics applies to the detailed monitoring metrics you select, alarms you create, and PromQL API queries you run.
To learn more, see Monitoring ElastiCache with OpenTelemetry metrics in the Amazon ElastiCache User Guide.
Quelle: aws.amazon.com

The AWS MCP Server is now available in six additional AWS Regions

The AWS MCP Server is now available in six additional AWS Regions: Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Ireland), Europe (London), and US West (Oregon). The AWS MCP Server, part of the Agent Toolkit for AWS, is a managed Model Context Protocol server that gives AI coding agents a single interface to AWS APIs, so agents can discover and call AWS services without building and maintaining per-service integrations.
With this expansion, customers in these Regions can run the AWS MCP Server closer to their developers with lower latency, and keep request data within the Region to meet data residency requirements. For example, a development team in London can point its coding agents at a local endpoint to provision infrastructure, inspect running workloads, and debug failures without routing requests to another geography. The AWS MCP Server can access services in all commercial AWS Regions, while the AWS MCP Server itself runs in the Regions listed below.
You can use AWS MCP Server in the following AWS Regions: US East (N. Virginia), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), and Europe (London).
To get started, see the following resources:
– Getting started with the AWS MCP Server
– AWS MCP Server endpoints and quotas
Quelle: aws.amazon.com