Period: today · Items: 6 · Source: Azure official updates RSS
Today is a great day to study “operational resilience” and “security boundaries” together. Features that are immediately tangible in real-world service operations stand out, such as WAF exception handling, application-centric experiments in Chaos Studio, and historical data export from Log Analytics. On top of that, with Event Hubs now embracing both Network Security Perimeter and Confidential Computing, the trend is becoming clear: even PaaS is moving toward more sophisticated designs for network isolation and protection of data while it is being processed.
· WAF Exceptions — How to design more granular exceptions to reduce WAF false positives, instead of simply “bypassing everything”
· Chaos Engineering Workspace/Scenario — An operating pattern for organizing failure experiments at the application scope rather than the individual resource level
· Log Analytics Export jobs — A data operations approach for selectively exporting historical logs to external storage by specifying queries and time ranges
· Network Security Perimeter (NSP) — A model for controlling public network access by applying logical network boundaries to PaaS resources
· Confidential Computing for streaming — The concept of protecting streaming data with a TEE even while it is being processed in memory
2 items
· A public preview has been announced for exception handling in Azure Web Application Firewall (WAF) to reduce cases where legitimate requests are blocked.
· Existing exclusions reduced false positives by skipping inspection of certain elements, but this announcement points toward a more granular exception model that enables tuning tailored to the application.
· This applies to WAF for Azure Application Gateway and Azure Front Door.
· It directly addresses a common operational need: “We want to keep security policies in place, while reducing unnecessary blocking caused by service-specific behavior.”
What it is: WAF helps block common web attacks, but it can also create false positives where legitimate application traffic is blocked by rules. This preview helps handle those situations more precisely, making it easier to balance security with normal service behavior.
Why it matters: Running a WAF is often less about “turning it on” and more about “tuning it well.” Understanding this feature helps build the mindset of designing which requests should be exempted under which conditions, rather than simply disabling rules.
Try it: Open the WAF policy menu in Azure Application Gateway or Azure Front Door, first review how exclusions are currently configured, and then write down examples of request patterns that would require exceptions based on the preview documentation.
Source: https://azure.microsoft.com/updates?id=567218
· Azure Event Hubs now generally supports Network Security Perimeter (NSP).
· NSP is a model for defining logical network isolation boundaries around PaaS resources and controlling public network access through perimeter-based access rules.
· With this support, Event Hubs can now be included in a more consistent PaaS security boundary design, beyond simple firewall and private endpoint configurations.
· Teams responsible for messaging and event ingestion layers may want to reassess how broadly their data ingestion pipelines are exposed externally.
What it is: With NSP now available for Event Hubs, access management for PaaS resources can be strengthened at the network-boundary level. It can be understood as a more structured security model beyond per-resource access control.
Why it matters: In practice, Event Hubs often becomes the gateway for data ingestion. Establishing a strong boundary at this point helps maintain a more secure downstream posture across the rest of the service chain.
Try it: Review the network access configuration for your Event Hubs namespace along with current Private Endpoint and firewall settings, then draw an architecture diagram showing which resources you would group within the same perimeter if NSP were applied.
Source: https://azure.microsoft.com/updates?id=567203
2 items
· Workspaces and Scenarios have been added to Azure Chaos Studio in public preview.
· The key point is that they enable faster, more application-centric validation of workload resilience under real failure conditions.
· Workspaces can be connected to an application scope such as a subscription, resource group, or service group to organize experiment targets.
· Scenarios appear to provide a more structured way to manage repeatable failure experiment configurations.
What it is: Chaos Studio is a service for validating system resilience by intentionally injecting failures. This preview goes beyond running experiments one resource at a time and strengthens the operational experience of defining scope and building scenarios at the application level.
Why it matters: Resilience testing is no longer just about isolated experiments like “reboot a specific VM.” It is increasingly important to observe how the entire application flow is affected. This feature helps SREs and platform engineers design more realistic resilience tests.
Try it: Using a sample system or test subscription you currently operate, list the resources that belong to a single application and design which boundary would feel most natural if you grouped them into a Chaos Studio Workspace.
Source: https://azure.microsoft.com/updates?id=567184
· A public preview has been announced for exporting historical data from a Log Analytics workspace using Export jobs.
· You can specify a query and time range to export only the data you need to an Azure Storage account.
· In other words, instead of dumping the entire workspace, you can selectively extract data, which is useful for external system integration or long-term retention scenarios.
· This is a highly practical feature for teams looking to reuse historical logs for operations, auditing, or analytics.
What it is: Log Analytics is typically used to search and analyze data within the workspace itself, but this feature supports a flow where historical data can be conditionally extracted and sent to other storage locations or systems. It makes the post-ingestion data lifecycle more flexible.
Why it matters: With observability data, it is just as important to think about “how it is retained and moved” as it is to think about “how it is collected.” Knowing this feature helps broaden your perspective on operational concerns such as cost, compliance, and integration with external analytics pipelines.
Try it: Pick a KQL query you use often in Log Analytics, then design an export flow based on the assumption: “If I export the last 30 days of these results to Azure Storage, what format and post-processing would be required?”
Source: https://azure.microsoft.com/updates?id=566591
1 item
· Azure Event Hubs Dedicated now generally supports Confidential Computing.
· Streaming data can now be protected with hardware-based Trusted Execution Environments (TEEs) even while it is being processed in memory.
· Organizations handling sensitive event streams can now consider protection not only at rest and in transit, but also in use.
· This is especially meaningful for high-security workloads using Event Hubs in a dedicated environment.
What it is: Confidential Computing is a technology that extends protection all the way into the memory region where data is actually processed. This announcement means that such a protection model can now be applied to the streaming data processing path in Event Hubs Dedicated.
Why it matters: Security discussions are increasingly shifting from “Is it encrypted?” to “Can it be trusted while running?” Understanding this concept at the messaging and event ingestion layer is highly valuable when designing architectures for sensitive data in industries such as finance, government, and healthcare.
Try it: Assume a scenario using Event Hubs Dedicated, and document how you would explain data protection across the three stages of at rest, in transit, and in use using the current combination of Azure services.
Source: https://azure.microsoft.com/updates?id=567212
1 item
· Azure Red Hat OpenShift (ARO) is now generally available in the Chile Central region.
· With the launch of Microsoft’s first Azure region in Chile, deployment options for OpenShift have expanded in South America.
· The key point is that fully managed OpenShift can now be operated from a closer region aligned with regional requirements.
· Regional expansion may not be as flashy as a feature launch, but it has a very direct impact on real deployment feasibility, latency, and data residency requirements.
What it is: ARO is a fully managed Red Hat OpenShift service on Azure. This GA announcement is not so much a feature enhancement as it is an expansion of regional availability, making the service officially available in Chile Central.
Why it matters: In infrastructure learning, region strategy is often underestimated, but in real projects it is tightly connected to regulation, latency, disaster recovery, and proximity to users. The regional expansion of ARO shows that container platforms ultimately sit on top of global infrastructure strategy.
Try it: Using ARO as the baseline, write a comparison note from the perspective of operating models and enterprise requirements answering the question, “Why would some teams choose OpenShift instead of AKS?”
Source: https://azure.microsoft.com/updates?id=566732
There are no separate service retirement items in today’s list.