Amazon CloudWatch log centralization now available in AWS GovCloud and additional commercial Regions

Amazon CloudWatch log centralization is now available in AWS GovCloud (US) and 13 additional commercial Regions. CloudWatch log centralization copies log data from multiple AWS accounts and Regions into a single destination account, integrating with AWS Organizations for efficient aggregation without the need for custom solutions.
With this launch, organizations in the AWS GovCloud (US) partition and commercial partition can each centralize logs across their accounts and Regions for centralized monitoring. You can scope centralization rules to your entire organization, specific organizational units, or selected accounts and copy logs into a single account while preserving source context through enriched system fields.
CloudWatch log centralization is now additionally available in Africa (Cape Town), Asia Pacific (Hong Kong), Asia Pacific (Hyderabad), Asia Pacific (Jakarta), Asia Pacific (Malaysia), Asia Pacific (Melbourne), Canada West (Calgary), Europe (Milan), Europe (Spain), Europe (Zurich), Israel (Tel Aviv), Middle East (Bahrain), Middle East (UAE), AWS GovCloud (US-East), and AWS GovCloud (US-West). For a complete list of supported Regions, see the AWS Region table.
To get started, create a centralization rule in the Amazon CloudWatch console, or by using the AWS CLI or AWS SDKs. To learn more, see Log centralization in the Amazon CloudWatch Logs User Guide. Customers can centralize one copy of logs for free; additional copies are charged at $0.05/GB. For details, see Amazon CloudWatch pricing.
Quelle: aws.amazon.com

Microsoft named a Leader in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms

We’re proud to share that Microsoft has been named a Leader in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms. We believe this recognition comes at an important moment for enterprise infrastructure. The question is no longer simply which hypervisor to run. It is how to create a consistent operating model across cloud, datacenter, edge, and sovereign environments. Microsoft addresses that challenge at two levels: operational consistency through Azure and Azure Arc, and infrastructure consistency through Hyper-V.

Read the report

From choosing a hypervisor to choosing an operating model

For years, the primary virtualization decision was which hypervisor to run. Today, the more consequential decision is how infrastructure will be operated across every environment the business depends on. Virtualization remains a critical foundation, but the value of the platform increasingly depends on how infrastructure is managed, governed, secured, updated, and connected across environments. As infrastructure becomes more distributed, how it is operated becomes as important as where it runs.

Microsoft delivers that consistency at two complementary levels:

Operational consistency: Azure provides common management, governance, and security across cloud, datacenter, and edge environments. Azure Arc extends those capabilities to distributed infrastructure, giving organizations a unified way to operate diverse environments.

Infrastructure consistency: Hyper-V provides a common virtualization foundation across Azure, Azure Local, and Windows Server, helping organizations maintain a consistent infrastructure layer wherever workloads run.

Together, these layers help organizations preserve choice without multiplying operational models. Workloads can move, environments can evolve, and new technologies can be adopted without requiring a separate operating model for every environment.

Ready for what comes next

Operational and infrastructure consistency will become even more important as AI reshapes enterprise IT. Models, agents, applications, and data will increasingly span cloud, datacenter, edge, and sovereign environments. AI alone will not reduce the complexity of distributed infrastructure; in many cases, it will increase the need for common management, governance, security, and infrastructure foundations.

Being named a Leader in this Magic Quadrant is an honor for us. More importantly, we believe it reflects a direction many organizations are pursuing: operational consistency across increasingly distributed environments. We remain committed to helping customers combine the flexibility to run workloads where they choose with the consistency required to manage them as one environment.

Recognized as a Leader

in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms

Read the report

Gartner, Magic Quadrant for Server Virtualization Platforms, Tony Harvey, Daniel Bowers, Paul Delory, Tony Iams, Owen Marino, 14 September 2026.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

Gartner and Magic Quadrant are trademarks of Gartner, Inc., and/or its affiliates. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Microsoft here.
The post Microsoft named a Leader in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms appeared first on Microsoft Azure Blog.
Quelle: Azure

Evolving the cloud-native foundation for the next generation of AI

Building a cloud-native foundation for AI

The relationship between model innovation and AI infrastructure has never been more clear; as AI becomes more capable, the platform underneath it matters even more. Agents are fundamentally changing how applications work, and with that, what organizations need from the cloud.

Learn how to build a cloud-native AI foundation

Cloud-native practices gave organizations the scale, flexibility and resilience to build a generation of distributed applications. Agents build on that foundation, but they work differently, placing new demands on it. Unlike applications designed around more predictable workflows, agents behave in entirely new ways, gathering information and deep intelligence from across the business, using tools, making decisions, and coordinating work across long-running processes. To complete complex tasks, they pause for approval, respond to new information in real time and change course as conditions evolve. All this changes what the platform needs to deliver.

Customers need infrastructure that adapts as demand changes, applications that remain reliable as work becomes more dynamic, and the visibility and control to understand what is happening across the system. Meeting those needs doesn’t mean starting over, but it does require that the cloud-native foundation organizations already rely on, to evolve. Compute, storage and networking need to work together. Application platforms need to make it easier to build and run AI workloads. Open technologies need to give customers flexibility without adding unnecessary complexity.

The platform decisions organizations make today are increasingly strategic, shaping how effectively they can put AI to work for their business. Evolving the cloud-native foundation is essential to helping organizations get more from AI today while giving them the flexibility to take advantage of new capabilities as they emerge.

Optimize infrastructure for AI workloads

The true measure of AI infrastructure is the useful work it enables. AI workloads rarely place the same demands on infrastructure from beginning to end. Different parts of the work may need accelerated compute, CPUs, fast access to data or connectivity across applications and environments. The answer isn’t simply more capacity, but rather, to match the right resources to the right work at the right time.

That makes coordination across the infrastructure extremely important. Compute, storage and networking need to work together as demands change. When they do, teams can spend less time managing infrastructure and more time focused on the applications and outcomes that matter to their business.

Economics matter, too. Infrastructure needs to be tuned to the demands of the application and the business value it delivers, with the right balance of performance, reliability and cost across the complete workload.

Basecamp Research is one example. The company used Azure to assemble 9.7 trillion nucleotides for EDEN, its therapeutic-design models, and reported laboratory validation across three therapeutic applications within about three weeks. In this example, AI didn’t simply require more infrastructure, it needed AI infrastructure that was coordinated and designed around the outcome – bringing together the compute, data and platform capabilities needed to move complex work forward.

As Glen Gowers, co-founder of Basecamp Research put it: “To really be successful here, we need those three ingredients to come together. We need someone scaling the data; that’s us. But someone who really knows how to scale models and scale compute is Microsoft.”

Leadership takeaway: Measure success by the useful work AI completes. Judge infrastructure investment by the performance, reliability and cost of delivering those outcomes, with compute, storage and networking operating as one system.

Turn open-source innovation into production capability

Open technologies have long helped drive cloud innovation, and AI is accelerating that pace. New models, frameworks and cloud-native technologies give organizations more choice in how they build and adapt applications.

That opportunity builds on an established cloud-native foundation. Gartner forecasts that by 2028, 95% of new AI agent deployment will use Kubernetes.1 Reusing established components can shorten the path to production, allowing developers to focus on differentiated business capabilities rather than rebuilding the foundation.

More choice can also bring more complexity. Taking advantage of open-source innovation often requires specialized expertise to integrate, manage and maintain technologies in production. That expertise is hard to find and even harder to scale. We need to make these capabilities accessible to more businesses, without requiring every organization to build and maintain that expertise themselves.

Azure helps reduce that burden. Services like Azure Kubernetes Service give teams access to open-source innovation while helping manage the complexity and risk of running it in production. This makes it easier for more businesses to take advantage of open technologies while preserving the flexibility to adapt with changing needs.

Leadership takeaway: Choose a platform that helps turn open-source freedom into business advantage. Preserve the ability to adapt and optimize while reducing the expertise and operating effort required to sustain those choices in production.

Align AI infrastructure costs with business value

As more organizations put AI into production, understanding the economics becomes increasingly important. AI investment starts with an expectation of business value: faster decisions, more responsive services or greater capacity to get useful work done. Then, it’s evaluating whether the value justifies the investment to deliver it. FinOps can help teams understand that return and make more informed decisions in this area.

For customers, that starts with understanding the full investment required to run AI applications and how to optimize it as workloads scale. Models represent a significant expense, with token usage and agent behavior influencing spending. Compute, storage, networking and operations also factor into the equation. Considering these together helps customers make more informed decisions about where to optimize.

Learn FinOps best practices for compute

Teams can’t simply place their bets on spending less. They need to carefully consider that a more capable model or additional infrastructure that costs more may be the right choice if it produces greater value long-term. Teams need to understand the full cost, establish ownership and put guardrails in place as they scale. From there, they can use business outcomes to decide where to optimize and where to invest.

Leadership takeaway: Manage AI investment against the business return it needs to deliver. Evaluate model and platform costs together, then use evidence of outcome value to decide where to optimize and where to invest.

Transform cloud operations with agentic AI

Operations teams are already stretched thin, keeping critical services running while balancing competing priorities and constant change. AI adds new complexity, and it also creates an opportunity to change how those environments are managed.

Cloud-native operations gave teams a new model for managing infrastructure, bringing increased automation, visibility and resilience. Agentic operations build on that foundation, bringing deeper intelligence across applications and infrastructure by connecting signals from otherwise disconnected systems. This helps teams identify issues earlier and resolve them faster, while increasing automation and continuously improving how their environments perform; all within the tools they already use.

Over time, AI can help operations teams move from reacting to problems toward anticipating and addressing them before they disrupt the business. As these capabilities mature, more actions can be automated within defined controls, with people remaining in the loop and accountable for critical decisions. When operations teams have greater reach without additional manual effort, reliability, performance and cost are continuously improved while critical services remain uninterrupted.

Leadership takeaway: Invest in operations that can anticipate problems and coordinate action across the environment. Expand autonomy as capabilities are validated, with clear controls and human accountability protecting critical business services.

Automate operations with Azure SRE Agent

Build a cloud-native AI foundation on Azure

Azure serves as the foundation customers need to put AI to work at scale. That means infrastructure designed around the complete workload, access to open innovation without unnecessary complexity, and a clear view of cost and business value. Greater intelligence across cloud operations helps teams anticipate issues and continuously improve how their environments perform as application needs evolve.

We’re continuing to invest in capabilities across Azure that give customers greater flexibility in how they build and run AI applications. From secure, isolated environments for agents to simpler application deployment and the ability to run workloads across cloud and edge environments, these investments help customers take advantage of new capabilities without adding unnecessary operational complexity.

Get started with Azure Kubernetes Service (AKS)

AI is changing what applications can do, and Azure has already evolved to support that shift. The cloud platform has to evolve with them. Years of focused engineering investment have built the foundation for some of the most advanced AI workloads running today, with continued innovation to support what comes next.

Build for the next generation of AI

Platform value compounds when improvements reinforce one another: faster information access keeps compute productive, operational insight exposes waste, and open technologies preserve room to adapt. The leadership task is to make those gains work together. That is the next chapter of cloud native: a foundation that turns advances in AI into dependable business value.

To learn more about the recent Azure innovations and how Azure is evolving the cloud-native foundation for AI applications and agents, explore:

Flex Nodes for AKS

Azure SRE Agent

Azure Container Apps Sandboxes

Azure Container Apps Express

Explore what this means for your organization. Register for our upcoming discovery session to learn how to put a cloud-native foundation for AI applications and agents into practice.

Build your AI foundation

Learn how to put a cloud-native foundation for AI applications and agents into practice in our upcoming discovery session.

Register now

1 Gartner®, Magic Quadrant™ for Container Management, Dennis Smith, Wataru Katsurashima, et al., 6 August 2025

GARTNER and MAGIC QUADRANT are trademarks of Gartner, Inc. and/or its affiliates.
The post Evolving the cloud-native foundation for the next generation of AI appeared first on Microsoft Azure Blog.
Quelle: Azure

Managing open-weight model risk in enterprise deployments

The growing AI landscape is giving enterprises more choice in how they build, customize, and deploy increasingly capable models. Open-weight models are an important part of that landscape. They give enterprises access to model weights and greater flexibility to inspect, evaluate, modify, and run models within their own environments.

While that flexibility can be valuable, it also affects how enterprises evaluate models, where they implement safeguards, and who is responsible for maintaining those safeguards over time.

As enterprises choose which models to deploy, the relevant question is broader than whether a model is open-weight or closed-weight. Enterprises need to understand what they are using the model for, what could go wrong in that context, and what evidence and controls they need to manage risks.

Today, Microsoft and NVIDIA are publishing Risk Management for Open-Weight Models in Enterprise, the first in a planned series of joint resources intended to help enterprises address those questions. The paper introduces a shared risk taxonomy and an approach to managing model risks grounded in established standards and frameworks, including International Organization for Standardization (ISO) standards and the National Institute of Standards and Technology (NIST) AI Risk Management Framework.

The paper reflects a core idea: weight openness alone does not determine an AI system’s risk. Risk depends on the model, use case, deployment, and safeguards.

Read the whitepaper: Risk Management for Open-Weight Models in EnterpriseUnderstanding risk in the deployment contextOpen- and closed-weight models can share many of the same underlying risks, but how those risks materialize depends on the deployment. A model used to help an employee draft a document presents different considerations than the same model used in a customer-facing workflow, just as a standalone inference endpoint differs from a system connected to external data or tools.

The architecture matters too. A risk may originate in the model, while the most effective control may sit in the inference environment, application, or surrounding operational processes. The joint guidance looks beyond the model label to factors including provenance, intended use, users, deployment conditions, and surrounding controls. This first paper focuses primarily on model-layer risks. Evaluating a model alone does not establish the safety of an agent or application: teams must also assess its permissions, data access, tools, runtime, and operational controls.

Establishing a common languageManaging these risks consistently also requires a common vocabulary across engineering, security, legal, safety, and business teams.

The initial Microsoft and NVIDIA taxonomy organizes risks into five broad categories: Cybersecurity, Data Protection, Content, Human-AI Interaction, and Bias. It is not a policy or deployment checklist, but instead it should be used by enterprises to adapt it to their own systems, use cases, and risk criteria, then connect relevant risks to evaluations, mitigations, and accountable owners.

Using evaluations as risk evidenceEvaluations help turn the taxonomy into something enterprises can use. The paper maps evaluations to a selection of risks across the five categories, giving teams a way to start with a risk that matters for their deployment and identify evaluations that can produce relevant evidence about it.

Microsoft Foundry helps enterprises assess quality, groundedness, and safety with built-in and custom evaluations and automated red teaming. Its configurable content-safety controls help detect and mitigate harmful inputs and outputs and prompt attacks. Teams should validate control availability for their model and deployment, including preview status, and combine these capabilities with application-specific testing, monitoring, and human oversight.

Evaluations still need to be interpreted in the context of a particular deployment and the goal is to make it easier for teams to connect the risks they identify with useful evidence, while building a broader set of evaluation resources that can evolve alongside models, deployment patterns, and emerging risks. Microsoft and NVIDIA plan to use the joint repository to share additional evaluations and point to existing resources that can help enterprises assess specific risks.

Accounting for changes in control and responsibilityOpen-weight access gives enterprises greater control over how a model is evaluated, modified, and deployed. Model access and deployment are separate choices: open-weight models can also be used through managed platforms. Responsibility for safeguards depends on the service and deployment configuration; enterprises that operate their own model deployments may take on controls otherwise provided by a managed service.

Those safeguards can operate at different layers, and (depending on the risk) enterprises might use model changes, access controls, input and output filtering, monitoring, or human review. The important step is connecting each identified risk to controls that can effectively address it within the deployed system. Those decisions need to be revisited as models and deployments change.

Building on this workRisk Management for Open-Weight Models in Enterprise focuses primarily on the model layer. Future work from Microsoft and NVIDIA is intended to extend this approach across the runtime, harness, and application layers, with additional technical guidance on evaluation and mitigation.

We also expect the resources supporting this work to evolve as new models, evaluations, and deployment patterns emerge. The joint repository will provide a place to share additional evaluation resources, including contributions from the broader community.

For enterprises deploying open-weight models today, the paper provides guidance they can begin applying to their own use cases. We encourage developers, security practitioners, researchers, and others working in this space to read the paper, explore the evaluations, and contribute evaluations that can help strengthen this shared body of work.

Read the joint Microsoft-NVIDIA paper, Risk Management for Open-Weight Models in Enterprise.

Explore the joint repository and technical resources.

Risk Management for Open-Weight Models in Enterprise was developed jointly by Microsoft and NVIDIA, with Andrew Berkley and April Chen of Microsoft and Michael Boone, Eileen Long, and Arun Rao of NVIDIA leading the development and editing of the paper.

Explore Microsoft Foundry evaluations and content-safety controls for implementation guidance.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
The post Managing open-weight model risk in enterprise deployments appeared first on Microsoft Azure Blog.
Quelle: Azure

From Containers to Sandboxes: Developer Trust in the Agentic Era

What the 2026 Stack Overflow Developer Survey tells us about where trust goes next

If you’ve followed Docker lately, you know we’re all-in on sandboxes. We’ve spent a ton of time talking about the difference between sandboxes and containers, and helping our customers and the industry as a whole understand when to use which. In fact, Docker president Mark Cavage dedicated his opening keynote at WeAreDevelopers World Congress North America to this exact topic, using live demos to show why sandboxes (and not containers) provide the level of isolation required to contain autonomous agents. 

To be clear: none of that means we suddenly think less of containers or the vital role they will continue to play in the software development process and ecosystem. We are Docker, after all. And lest anyone forget, as the just-released 2026 Stack Overflow Developer Survey confirmed yet again, when it comes to containers, there’s Docker, and there’s everyone else. Docker is the most used (59%) and most desired (38%) tool in the survey’s cloud development category.

Now, we can all agree that the tech industry is inundated with surveys these days. Vendors, analysts, research firms, everyone’s got a groundbreaking new survey. So, if your reflex response to reading about new survey results is to roll your eyes and think here we go again, well, I get it. 

But the annual Stack Overflow Developer Survey isn’t just another survey. When it comes to the developer community, it’s arguably the survey, the one developers themselves pay attention to. Over the course of 16 years, it has become something of a de facto standard for those of us interested in truly understanding how developers think and act. Released earlier this month, the 2026 survey reached more than 30,000 respondents across 169 countries.

Of course, this year’s survey did more than just remind us of Docker’s continued container dominance. It painted a picture of an industry in transition as developers grapple with one of the biggest questions in technology right now: how to bridge the gap between what they want to do with agents and what they can securely and confidently run in production. 

Consider:

Only 7% of developers trust AI output for important work decisions. Nearly half (48%) trust it only when they can verify it themselves.

Security and privacy ranked as the second biggest factor in whether teams adopt or expand AI tools (behind only accuracy). 

Nearly one in four developers said AI-related security or privacy issues cost their team valuable time in the past year.

Put it all together, and the missing ingredient is clear: trust. Developers want to tap into everything agents make possible without crossing their fingers and hoping “everything” doesn’t include a catastrophic security failure.

I didn’t point out those earlier Docker numbers just to brag (though, hey, I’m a marketer, so it was at least part of it). I mentioned them because they’re a reflection of trust — trust earned across more than a decade helping developers make software portable, open, reproducible, and secure. 

Today, we’re building on that foundation and extending that trust into the agentic era. At WeAreDevelopers, you saw the first steps. We launched Docker Cloud Sandboxes, published the next-generation Sandbox Kit specification (which we’ve committed to submitting to the Cloud Native Computing Foundation), and built nearly everything we showed around one idea: helping developers manufacture trust for AI agents. 

If it all looked and felt like a slightly different Docker, that was intentional. We’re at the start of a transformative era for Docker, and you’ll see a lot more from us in the coming weeks and months.

But no matter how much the industry changes, and no matter how much we evolve along with it, one thing won’t change. Docker will continue to run on trust.

If you’d like to see what that looks like in practice, try Docker Sandboxes (and get a $250 credit if you sign up before Oct. 31). You can start an agent on your laptop, ship longer jobs off to the cloud, and bring the results back. We’d love to hear what you think.

Quelle: https://blog.docker.com/feed/

Second-generation AWS Outposts racks now supported in the AWS Mexico (Central) Region

Second-generation AWS Outposts racks are now supported in the AWS Mexico (Central) Region. Outposts racks extend AWS infrastructure, AWS services, APIs, and tools to virtually any on-premises data center or colocation space for a truly consistent hybrid experience. 

 

Organizations of every size, from startups to enterprises to public sector agencies, can now order Outposts racks connected to this newly supported Region to optimize for latency and data residency needs. This regional expansion provides additional flexibility in the number of AWS Regions that customers’ Outposts can connect to.
To learn more about second-generation Outposts racks, read the blog post and the user guide. For the latest list of countries and territories and the AWS Regions where second-generation Outposts racks are supported, see the Outposts rack FAQs page.
Quelle: aws.amazon.com