Azure News - 2026-09-23

Introduction

One of the most common questions during Azure networking troubleshooting is:

“Did anything change before the issue started?”

Whether we are investigating VPN/, connectivity problems, Azure Firewall behavior changes, VM outages, routing issues, or application failures, identifying recent configuration changes is often the fastest way to determine the root cause.

Change Analysis is a powerful capability built on Azure Resource Graph that allows engineers and administrators to quickly see:

• What changed
• When the change occurred
• Who made the change
• Which client or tool performed the change
• The exact configuration differences before and after the change

What is Change Analysis?

Azure resources are constantly being modified through:

• Azure portal
• Azure CLI
• PowerShell
• ARM/Bicep deployments
• Terraform
• Azure Policy remediation
• Automation runbooks
• CI/CD pipelines

In many organizations, multiple administrators and engineers have access to the same Azure tenant and subscriptions. Because teams often work across different regions and time zones, it can be difficult to determine who made a change and to quickly contact the responsible person when an issue occurs. While most changes are intentional and necessary for daily operations, some modifications can unintentionally introduce outages, connectivity issues, or performance problems. Azure Change Analysis provides a centralized view of resource changes and helps organizations quickly answer critical troubleshooting questions such as: Who changed a setting? Was a route table updated before traffic stopped flowing? Did someone modify an NSG rule? Was the Azure Firewall configuration changed? When was a virtual machine resized? By showing what changed, when it changed, and who made the change, Change Analysis significantly reduces troubleshooting time and helps accelerate root cause analysis.

How Change Analysis works

When an Azure resource is:

• Created
• Updated
• Deleted

 Azure Resource Graph captures change information and stores snapshots that can later be queried.

The platform records:

This dramatically reduces troubleshooting time because engineers can immediately identify configuration drift or recent modifications.

Accessing Change Analysis in Azure portal

As shown in the screenshot, Change Analysis can be accessed directly from the Azure portal.

Navigation options

Global Change Analysis view

1. Open Azure portal
2. Search for Change Analysis
3. Select Change Analysis

This approach is particularly useful when troubleshooting a specific service such as:

• VPN Gateway
• Azure Firewall
• Virtual Machine
• Load Balancer
• Application Gateway
• Network security group (NSG)

Compare old and new configuration

• View the exact configuration changes made to a resource.
• Compare Old Configuration (left panel) with New Configuration (right panel).
• Identify added, removed, or modified properties.
• Review configuration differences at the property level.
• Quickly determine what changed during the incident timeframe.
• Useful for analyzing:
• NSG rule additions or deletions
• Route table modifications
• Azure Firewall rule changes
• VPN Gateway configuration updates
• Public IP changes
• Resource property updates

Example: In the screenshot above, Change Analysis clearly shows the previous NSG rule configuration on the left and the updated configuration on the right, making it easy to identify exactly which rule was added, modified, or removed. This helps engineers quickly correlate configuration changes with service disruptions and accelerate root cause analysis.

Common Azure networking use cases

As an Azure networking some practical scenarios include:

VPN Gateway troubleshooting

VPN down

• Modified Local Network Gateway prefixes
• BGP ASN changes
• Tunnel configuration updates
• Public IP changes
• IKE parameter

Azure Firewall investigation

A workload suddenly loses connectivity.

Change Analysis may show:

• DNAT rule modification
• Network Rule change
• Application Rule update

NSG connectivity problems

When VM traffic is blocked unexpectedly, Change Analysis can identify:

• Newly added deny rules
• Priority changes
• Rule deletions

Route table changes

Change Analysis quickly exposes:

• Next-hop modifications
• UDR updates
• Route propagation changes

Querying changes using Azure Resource Graph

Azure Portal → Monitor → Change Analysis →Open query  →Azure Resource Graph Explorer.

resourcechanges

|extend timestamp = todatetime(properties.changeAttributes.timestamp)

|where timestamp > ago(24h)

|extend resourceType = properties.targetResourceType

|extend resourceId = properties.targetResourceId

|extend changeType = properties.changeType

|extend changeAttributes = parse_json(properties.changeAttributes)

|where resourceId in ('-----------')

|project id, timestamp, subscriptionId, resourceGroup, resourceId, resourceType, changeType, changeAttributes

|order by timestamp desc

Conclusion

Change Analysis has become one of the most valuable troubleshooting tools available in Azure. By providing visibility into who changed what and when, it helps engineers quickly identify configuration drift, reduce mean time to resolution, and accelerate root cause analysis.

For Azure networking scenarios such as VPN Gateway, ExpressRoute, Azure Firewall, Route Tables, and NSGs, Change Analysis should be one of the very first tools consulted when investigating unexpected behavior.

As every Azure support engineer knows, solving an incident often starts with a simple question:

“What changed?”

Change Analysis helps answer that question in seconds

Azure Functions can already connect to many Azure services through triggers and bindings. With managed connectors, your functions can access about 1,700 connectors across services such as Microsoft 365, Microsoft Teams, Dataverse, SharePoint, OneDrive, and third-party systems. 

Connector triggers deliver events from these services to your function, while typed connector clients let your code take actions against them. You get this broader integration surface without writing the webhook registration code or managing the OAuth tokens required to connect to each service. Focus on your function's business logic and let Azure Connector Namespace handles the connection.

Azure Functions integration with Connector Namespace is currently in public preview. It supports .NET isolated, Python, and Node.js. Review the managed connectors overview for current language, hosting plan, and regional availability.

To demonstrate how connector triggers and actions work together, this article follows a .NET sample that automates RFP intake across SharePoint, Azure Content Understanding, and Teams.

From an uploaded RFP to Teams notification

Consider an organization that receives requests for proposals (RFPs) in a shared SharePoint document library. Someone must read each document, identify the requested capabilities, determine which subject-matter experts should respond, and notify the right team.

The automated RFP intake sample turns that process into an event-driven workflow:

1. A customer uploads an RFP to a SharePoint document library.
2. A SharePoint connector trigger invokes an Azure Function when the file is created.
3. The function uses a typed SharePoint connector client to retrieve the file contents.
4. Azure Content Understanding extracts the document’s text and layout.
5. The function applies deterministic rules to identify the customer, required capabilities, and recommended subject-matter experts.
6. The function uses a typed Teams connector client to post the results as an Adaptive Card in a channel.

Connector Namespace manages the SharePoint and Teams connections. The function controls file processing, document analysis, routing rules, error handling, and notification content

How the sample works

The .NET sample demonstrates both parts of the connector programming model: a connector trigger receives an event from SharePoint, and typed connector clients provided by the Connector SDKs to perform actions against SharePoint and Teams.

The function starts when the SharePoint When a file is created trigger detects a new RFP. It declares the trigger using the ConnectorTrigger attribute and receives a typed payload containing the file’s properties:

Because the trigger provides file properties rather than its contents, the function uses a typed SharePoint client to retrieve the document:

byte[] document = SharePointFileContent.Decode(response);

The SharePoint and Teams clients are registered through dependency injection. Each client uses the runtime URL of its Connector Namespace connection and authenticates with DefaultAzureCredential:

services.AddSingleton( new TeamsClient( new Uri(teamsRuntimeUrl), credential));

The function sends the document to Content Understanding’s prebuilt-layout analyzer, which extracts its text and structure. It then applies deterministic C# rules to identify the customer and required capabilities and map those capabilities to predefined subject-matter expert roles.

Finally, the function creates an Adaptive Card containing the results and posts it to the configured Teams channel with the typed Teams client:

Connector Namespace handles the SharePoint and Teams connections, while the function controls the document analysis, routing logic, error handling, and notification content.

Try the sample

The RFP intake sample includes the function code, Bicep infrastructure, Azure Developer CLI configuration, and supporting scripts. Its README explains how to test the workflow locally and deploy it to Azure.

Common connector patterns

Managed connectors are useful when a function must react to events or perform operations in external systems. Common patterns include:

• Event to action: React to an event in one service and take an action in another.
• Event to enrich to action: Retrieve additional information related to an event before acting.
• Event to document analysis to action: Extract text and structure from a document, apply application rules, and send the result through another connector.
• Event to AI to action: Analyze event data with an AI service and write the result back through a connector.
• Extend an existing function app: Add connector-based integrations alongside HTTP, timer, queue, Service Bus, Event Grid, or Durable Functions workloads.

The RFP sample combines several of these patterns. A SharePoint event starts the workflow, a SharePoint action retrieves the document, Content Understanding extracts its contents, application code enriches the result, and a Teams action sends the notification.

Closing thoughts

Managed connectors extend the external systems that can trigger your functions and the services your function code can act on. This brings services such as SharePoint, Teams, Microsoft 365, and many third-party systems into the Azure Functions programming model without requiring you to build the underlying webhook and OAuth infrastructure.

Choose Azure Functions with managed connectors when you want this broader integration surface in a code-first application and need custom branching, application libraries and SDKs, other Functions bindings, document or AI processing, or application-specific logic between the trigger and action.

If the workload primarily orchestrates connector operations, involves little custom code, and would benefit from a visual designer, Azure Logic Apps is usually the simpler choice.

Resources

Documentations 

• Overview of managed connectors in Azure Functions
• Azure Functions connector samples
• Azure Connector Namespace overview
• Content Understanding prebuilt-layout analyzer

Connector SDK GitHub repos

• .NET SDK
• Python SDK
• Node.js SDK

AI changed what teams ask of Kubernetes. Workloads today are more than a stateless web tier, they are an inference service with an expensive GPU behind it, an agent that behaves unpredictably, and a data path that shifts from dataset throughput to checkpoint durability to serving latency as the application matures. Today at the Reactor event, we are showing demos and announcing new capabilities to support your AI workloads.  

This wave of AKS releases answers three of those pressures directly: isolating AI workloads, assembling the componentry that agentic applications need, and making capacity work harder than it did last quarter.

Workload and AI isolation

Agents are unpredictable by design. Consider an agent installing packages, making unexpected network calls, or attempting to escape its pod into the node — with a shared kernel, one compromise becomes a node-wide problem. The AKS answer is layered: secure by default, verify the workload, then raise the boundary when the data demands it.

• GA: Pod sandboxing support in node auto-provisioning (NAP). Every pod runs inside its own lightweight VM with an isolated guest kernel, built on the open-source Kata Containers project, so a compromise of one kernel instance is contained to one workload. With NAP support, that isolated compute is provisioned efficiently instead of hand-sized.
• GA: Confidential GPU support. AMD SEV-SNP confidential VMs with NVIDIA H100 Tensor Core GPUs, linking CPU and GPU trusted execution environments. Memory stays hardware-encrypted, which helps prevent data access by cloud providers, administrators, and privileged users — the control that makes sovereign, regulated, and privacy-sensitive AI workloads viable.
• GA: Trusted Launch support in NAP. Secure boot, virtual TPM, and boot integrity monitoring on Generation 2 VMs, applied automatically whenever NAP selects a Gen 2 SKU. No touch, no configuration, hardened nodes.
• GA: Identity Bindings. Removes the 20 federated identity credential ceiling on a user-assigned managed identity. Multiple clusters now share one managed identity through a single credential, with access governed by granular Kubernetes RBAC and AKS-managed token exchange — the difference between a platform that stops at 20 clusters and one that doesn't.
• GA: NFS encryption in transit and workload identity for Azure Files CSI. Protects traffic on the shared-file path and lets pods authenticate with identity instead of storage account keys, for the models, artifacts, and configuration many replicas read at once.
• GA: Argo CD extension for AKS. Automate application deployment and continuous reconciliation from Git with trusted access and security controls built in: see application health, sync state, and the deployed revision at a glance, get improved security through automatic updates of the Argo CD components, sign in to the Argo CD UI with Azure identities, and authenticate to ACR and Azure DevOps with workload identity. 

Agent componentry

Agentic applications need a path from code to a verified deployment, a runtime that absorbs bursts, and enough observability to find out why a GPU ran out of memory at 2am.

• GA: Argo CD extension for AKS. Managed GitOps with application health, sync state, and deployed revision visible in one place, automatic updates for Argo CD components, single sign-on with Azure identities, and workload identity authentication to ACR and Azure DevOps. The Flux extension for AKS remains available for Flux-based workflows.
• Public Preview: Virtual Nodes v2 as a cluster extension. Burst into Azure Container Instances in seconds without waiting for node provisioning, pay only while pods run, and get Hyper-V isolated microVMs with confidential container support. Inference spikes and agent fan-out stop requiring permanently overprovisioned nodes.
• Public Preview: GPU memory profiling. See which functions allocate GPU memory, with no app code changes and no sidecar, and go from "memory is under pressure" to the exact call path as a flame graph. Profile, fix, re-profile.

• GA: NFS encryption in transit and workload identity for Azure Files CSI. Secures the shared-file path that many replicas read at once, protecting traffic on the wire and letting pods authenticate with identity instead of storage account keys. Best fit for models, artifacts, configuration, and shared application data reached through a Kubernetes-native interface.
• GA: Azure Container Storage v2.2.1. Improves local NVMe provisioning and expansion, reduces resource consumption at scale, and adds Elastic SAN support on tainted nodes, strengthening the production foundation for databases, data pipelines, and model-serving workloads that need container-native volume orchestration.
• GA: Azure CSI driver security hardening (AKS release v20260904). Stronger input and mount validation, credential isolation and refresh, protection against resource-exhaustion paths, and better diagnostics. The storage integration is part of the workload trust boundary, and this release treats it that way.

Around these, the developer surfaces stay where teams already work: the AKS extension for VS Code, AKS Skills in GitHub Copilot and your preferred CLI, AKS desktop, and Azure Kubernetes Fleet Manager resource placement for declaring one release intent across many clusters and regions.

Efficiency

Getting the most out of expensive compute is key, and we want to ensure your training, inference, fine-tuning and batch jobs spend with purpose and scale with demand. We’re introducing the following capabilities to help support.

• GA: Improved Spot VM handling in NAP. Proactive replacement of evicted spot nodes via Node Problem Detector, extended eviction notification, and an in-VM rebalancing signal, so spot capacity becomes usable for real workloads.
• GA: Provisioning Request support in Cluster Autoscaler. Immediate cleanup of partially provisioned compute when capacity constraints prevent full allocation, reducing wasted spend and capacity fragmentation for AI and batch job orchestrators.
• GA: Ultra SSD and GPU Operator/BYO driver support in NAP. Sub-millisecond, high-IOPS storage for stateful and AI workloads, and your choice of AKS-managed GPU driver, NVIDIA GPU Operator, or a self-managed custom driver.
• Public Preview: AKS Hyperscale Configuration. Pre-provisioned control planes in H2, H4, and H8 tiers, reaching 7,000 API server executing seats, 400 pods per second scheduling, and six etcd partitions. For AI training, HPC, batch, and surge events, the control plane is ready before demand arrives.
• Public Preview: Automatic zonal placement. Zones auto lets AKS pick SKU-supported zones, cap any single zone at 50% of the pool, and re-evaluate capacity during scale-out instead of failing against a fixed zone list.
• GA: Managed system components uptime SLA. A 99.9% guarantee for system components running on managed system node pools in AKS Automatic clusters, including CoreDNS, KEDA, Eraser, Konnectivity, VPA, and workload identity.
• Private Preview: Azure Chaos Studio extension. Blue/green node pool upgrades, node pool rollback up to seven days, maxUnavailable fallback, capacity reservation groups for existing node pools, pod eviction on freeze, on-demand node health checks

• Public Preview: Flex Nodes for AKS. A deployment option that lets application and platform teams use hybrid and edge infrastructure as connected worker nodes attached to an AKS control plane in Azure.

With Flex Nodes for AKS, we’ve seen three forces pull workloads outside a single Azure region: data residency, constrained capacity, and latency. The traditional answer is another cluster at the edge, and with it another control plane, another upgrade cycle, another policy surface. Flex Nodes offers an alternative architecture. The Kubernetes control plane stays in Azure while only worker nodes run at the edge or on customer infrastructure, giving one cluster and one operating model across cloud and edge.

Flex Nodes fits applications that require local execution but not local operations: AI inference, data processing, industrial applications, content delivery, branch office services, and latency-sensitive business workloads. Flex nodes can specifically detect NVIDIA hardware and configure the runtime, while customers supply the driver and Kubernetes GPU components today. Azure Linux, Ubuntu, and RHEL are supported. Learn more at: aka.ms/aks/flexnodeforaks.

Where local autonomy is the requirement instead, we also have the Public Preview for AKS on bare metal Ubuntu runs a full local cluster on your own CPU and GPU hardware with no virtualization layer.

AKS is more than where your AI application runs. Your Kubernetes environments now operate the contract between the workload and its state, its isolation boundary, its capacity, and its location, so your teams can spend their attention on building new AI apps, deploying agents, and supporting development teams with the open-source frameworks they need.

Agents Act. You Set the Limits.

Your platform needs to run untrusted code. Agents choose actions at runtime, from installing packages to calling APIs. In a multi-tenant service, you have to support both without letting one customer's code reach another customer's data. That requires an execution environment you control for each tenant, session, or task.

Azure Container Apps Sandboxes is that execution environment, as a service. Each sandbox is a hardware-isolated microVM with its own Linux kernel. It starts in under a second, and you decide per sandbox what it can reach, how large it is, and how long it lives.

For each user, controlling which credentials their agent can use and what it can reach is key. Untrusted code must stay isolated from other workloads and the host kernel. Preserving a session state without giving up scale to zero or instant startup is important, as is visibility into what each agent did. Let's unpack these one at a time.

Control What Your Agents Can Reach

The first question about an agent is not what it can do, but what it can reach. Per-sandbox egress policies answer that: an external proxy evaluates every outbound request against rules you set - by host, domain pattern, or CIDR. You can start with a default 'Deny' action and allow only the endpoints the task needs, so a prompt injection or a compromised dependency has nowhere to go. Network Audit shows you what was allowed and what was denied.

Approved endpoints usually need credentials, and handing an API key to an agent means the key can be logged, echoed into a response, or carried off somewhere you did not intend. Transform rules can inject authentication headers at the proxy from sandbox-group secrets instead. The agent sends a request with no secret in it, the proxy adds the credential outside the sandbox, and the call goes through. The agent gets access to the service without ever getting the API key.

When a static allowlist cannot express the rule you need, an egress webhook hands each request to your own service before it leaves. You can build a service that reviews all outbound calls, approves some and rejects others.

Good results depend on the agent reaching the right data, and the data that matters usually sits on your private network. Outbound, VNet integration places the sandbox group on a dedicated subnet, so agents can reach internal APIs, databases, and services behind private endpoints. Egress rules are still enforced: routing is chosen per rule, so a call to an internal database is filtered, transformed, and recorded in Network Audit exactly like a call to the open internet. Inbound, a Private Endpoint brings the sandbox service into your VNet, so your own applications reach into your sandboxes without crossing the public internet.

Run Untrusted Code Without Sharing a Kernel

Each sandbox runs in a hardware-isolated microVM with its own Linux kernel and virtual hardware, with memory separation enforced through CPU virtualization. In contrast, typical container runtimes isolate processes while sharing the host kernel. In a sandbox, code calls into its own guest kernel, so the blast radius of a kernel exploit is one sandbox. You get that boundary with ACA Sandboxes.

Inside that boundary, the filesystem is yours to choose. The quickest way to start is by creating a sandbox based on a platform-provided disk image:

Availability and versions change over time, please check the portal's catalog for the current list. Images are provided as is.

For a custom environment with your own code and dependencies, you can bring a container image from a public or private registry. The platform converts it into an optimized, bootable disk image containing your application, agent harness, runtimes, and toolchain. For a private registry, you authenticate with registry credentials or a managed identity for Azure Container Registry.

You can also start from a sandbox you already have running. A disk snapshot captures the filesystem as a new disk image, while a memory snapshot captures disk and memory together, so a sandbox created from it resumes where the original left off. Installed dependencies, or a cloned repo, are set up once, and every sandbox created from the snapshot starts with them.

Give Every Task Its Own Sandbox

A sandbox starts in under a second, and that is why it is practical to give every task its own machine. When a machine takes minutes to come up, everything ends up sharing that same space. When it starts instantly, each task, user, or tool call runs in isolation, and gets deleted when the work is done. Thousands at a time.

Sandboxes are sized when created by selecting a resource tier. These range from 0.25 vCPU with 0.5 GB of memory and a 5 GB disk, enough for a short script or a quick evaluation, to 4 vCPU with 8 GB of memory and an 80 GB disk for compilation and heavier analysis, with multiple steps in between. Programmatically you can go up to 16 vCPU with 32 GB of memory and a 320 GB disk for the most demanding work.

Sandboxes do not have to be discarded by hand. Lifecycle policies stop a sandbox once it goes idle, capturing the disk and optionally the memory. It can resume on a start command or automatically on arriving network traffic. A policy can also auto-delete a sandbox that has been stopped long enough, so abandoned work does not linger.

Keep State and Bring Your Data

Most agent tasks are short - run a script, or return a result. That is not the limit. A long-running agent needs state that outlives single runs, and volumes attach persistent storage to a sandbox at a path you choose. Code reads and writes to it through ordinary filesystem calls, and the data stays after the sandbox is deleted. There are three kinds:

• A Data Disk mounts to one sandbox at a time and gives it a fast, fully POSIX-compatible filesystem on local disk, which suits a working database, a build cache, or an agent's accumulated memory.
• An Azure Blob volume mounts to many sandboxes at once, for sharing a large read-heavy dataset rather than supporting concurrent writers.

• Azure Blob BYO volume (bring your own) does the same for blob storage you already own, referenced by resource ID.

See What Your Sandboxes Are Doing

Observability is how you know what a fleet of short-lived sandboxes did. Telemetry is opt-in and configured per sandbox when you create it, and it streams out while the sandbox runs, so you can go back to a run that finished hours ago. A sandbox emits four categories of data, and you choose which of them to collect:

Each category is then pointed at a destination: any OTLP-compatible collector, Log Analytics through the Logs Ingestion API, or Application Insights. They mix freely, so console logs can go to your collector while egress decisions go to Log Analytics.  The credential that writes to the destination never enters the sandbox. OTLP resolves their from a sandbox-group secret, Log Analytics authenticates with a managed identity on the group.

Separate from what a sandbox exports, the platform publishes cores and memory to Azure Monitor on the sandbox group, and that is what the portal shows for a Sandbox group. Sandbox group totals come by default, and you can opt-in for per sandbox details if you need that level of granularity.

Use It From Code, a Shell, or a Browser

Every one of these operations is available from code, a shell, a template, or a browser, so the choice comes down to what you are doing at the time.

When the sandbox is part of your application, use an SDK. Today available for Python and TypeScript, with .NET on the way. An app or service you build creates sandboxes, writes and reads files, runs commands, mounts volumes, and captures snapshots as native objects in the language you use.

When the work is scripted, the ACA CLI covers the same surface from Bash or PowerShell: aca sandbox create --disk ubuntu or aca sandbox snapshot. Commands accept label selectors, so automation and CI act on -l name=build-agent instead of tracking generated IDs.

When the group itself is managed in source control, define it as infrastructure as code. Microsoft.App/sandboxGroups is a first-class ARM resource, so a Bicep template attaches a managed identity, links a delegated VNet subnet, and assigns data-plane roles. An ACA Terraform provider (Preview) covers the same group-level controls for teams standardized on Terraform.

Sandboxes portal

Designing a new resource type from scratch let us rethink the portal experience along with it. The creation flow asks the minimal set of questions - a disk image and resource tier - and you have a running sandbox. The Advanced section allows you to go deeper to ports, volumes, lifecycle policies, egress policies, logging and more. All there when you need it.

What you see afterward is tailored the same way. A sandbox group gives you the overview of all sandboxes in that group: how many exist and how many are running, cores and memory in use over time. The most recent sandboxes with their state and size, and the disk images and snapshots the group can build from. 

A single sandbox gives you the machine: a terminal, live CPU, memory, storage, and network, a log stream, running processes, the files on disk, mounted volumes, and the egress traffic it generated with each request marked allowed or denied.

You get that same experience wherever you start. Reach sandboxes from the Azure portal, alongside the rest of your resources and under the same subscriptions, RBAC, and policies, or go straight to the standalone ACA Sandboxes portal. It is the same experience either way, so there is nothing to relearn and nothing you can only do in one of them.

How Much Does It Cost?

Three types of charges:

• vCPU, per core-second while the sandbox runs.
• Memory, per GiB-second while the sandbox runs.
• Storage, per GB stored, for as long as you keep it.

The resource tier of the sandbox determines the amount of vCPU and GiB of memory. These rates are on the Container Apps pricing page.

Storage is charged (coming soon) at Premium Azure Blob ZRS rates and covers:

• Custom Disk Images, including Disk Snapshots. The platform converts your OCI container image into a bootable disk image. You pay to store one copy of that image for as long as you keep it, regardless of how many sandboxes boot from it. The OS disk each of those sandboxes runs on is not billed.
• Snapshots are the combined memory and disk snapshots of your sandboxes, including those taken automatically when a sandbox stops.
• Optional Data Disk Volumes and Azure Blob Volumes that can be attached to sandboxes.

Thank You and What Comes Next

General availability is not the destination, it is where many more of you get to start. During public preview that we announced in June 2026, the usage surpassed quickly a million sandboxes created every day. Our team worked closely with early customers that provided valuable feedback that shaped the product as it's today. From teams running real workloads on sandboxes ranging from start-ups like Templafy to organizations like KPMG and Cognite. KPMG built their Cowork AI Agent for their global workforce on ACA Sandboxes. Cognite uses ACA Sandboxes in their industrial Atlas AI system. Lastly, the Department for Education, South Australia - uses ACA sandboxes to power their EdChat - 

A safe place for every learner. We run the EdChat so students can learn by writing code and exploring data alongside AI, across 60,000 students and more than 40,000 staff. That model only works if every student gets an environment of their own, with clear guardrails, and can come back later to find their work exactly as they left it. Building that in house meant owning the machinery behind it. We estimate that moving to Azure Container Apps Sandboxes lets us retire close to 50,000 lines of code written to manage custom code interpreter and state ourselves. It is the per-user execution model that scales for our school system, and a lower maintenance burden for us.

Cody Little, AI Technical Lead, Department for Education, South Australia 

In addition, many internal customers at Microsoft adopted ACA Sandboxes to build and enhance their products for their customers. Among those Microsoft Foundry built hosted agents, Copilot Studio hosts agents you create - both on ACA Sandboxes and – our very own Azure Container Apps Express built a modern and fast serverless container platform on sandboxes. Their feedback and your feedback set the next priorities, and we are grateful to you for it.

Three focus areas of work that follow: Sandbox groups get more control and visibility, so a platform team can observe sandboxes, audit and enforce policies at the sandbox group level. Broad extensibility with more SDKs and tighter integration with VS Code. Lastly, extensive interoperability with Connectors and Triggers (now in preview) that will provide even larger customizability and on-behalf-of authentication (OBO), so agents securely reach the systems needed to do their job.

Next Steps

• Open the ACA Sandboxes portal and create a group with a sandbox.
• Clone the samples repo and start with the working code.
• Read the documentation for the quick starts and the reference behind everything above.

We appreciate your feedback, please submit it in the ACA Sandboxes portal, or open an issue in the Azure Container Apps repo Issues · microsoft/azure-container-apps.