Scale your Marketplace sales with expanded Frontier Accelerate for Marketplace benefits
Discover how expanded Frontier Accelerate for Marketplace benefits give software companies more ways to grow, from new Azure sponsorship milestones to customer adoption, co-sell, and differentiation opportunities. See your benefits and next steps in App Advisor.Azure API Management v2: Restoring Predictable Outbound IP Addresses with NAT Gateway
Introduction A key consideration when deploying Azure API Management Standard v2 or Premium v2 is that outbound networking behavior differs from the classic tiers. This applies both when customers manually rebuild an existing solution on one of these tiers and when they create a new deployment based on assumptions formed from classic-tier behavior. In classic tiers, dedicated outbound IP addresses are available and are commonly used by backend services for source-IP allowlisting. With Standard v2 and Premium v2, customers should instead design outbound connectivity explicitly when a predictable public source IP is required. This article applies only to Standard v2 with virtual network integration and Premium v2 with either virtual network integration or virtual network injection. The Challenge Many backend systems still validate the source IP address of incoming traffic. Common examples include: Partner APIs Payment providers Legacy applications On-premises systems Third-party SaaS platforms When designing a new APIM v2 service, or manually rebuilding a solution previously hosted on a classic tier, backend teams often ask: “Which IP address should we allowlist?” Unlike a classic-tier design that relies on the service’s dedicated outbound IP addresses, an APIM v2 service may require an explicit egress pattern. Virtual network integration combined with Azure NAT Gateway can provide a predictable public source IP for outbound traffic that traverses the integrated subnet. Architecture Before: Classic APIM The backend allowlist contains the outbound public IP address associated with the APIM instance. After: APIM v2 Service with NAT Gateway The backend allowlist contains the public IP address assigned to the NAT Gateway. APIM outbound traffic uses the virtual network integration path, and the NAT Gateway provides the predictable public source IP for internet-bound connections from the associated subnet. Configuration Steps Prerequisite - Create an APIM v2 Service The portal walkthrough in this article uses a Standard v2 instance configured for outbound virtual network integration. As shown in the service overview, the dedicated public IP address information available in the classic tiers is not displayed for this APIM v2 instance. Step 1 - Create a Virtual Network Create or select the virtual network that will be used for APIM outbound virtual network integration. Step 2 - Create a Dedicated APIM Subnet Create a subnet dedicated to the APIM v2 instance. The integration subnet must meet the documented requirements for outbound virtual network integration. Reference: Integrate an API Management instance with a virtual network for outbound connectivity Subnet delegation depends on the APIM v2 tier: Standard v2: Delegate the subnet to Microsoft.Web/serverFarms for outbound virtual network integration. Premium v2: Delegate the subnet to Microsoft.ApiManagement/service, whether using virtual network integration or virtual network injection. Step 3 - Associate a Network Security Group Associate a Network Security Group (NSG) with the APIM integration subnet. Configure the required rules according to the documented APIM networking dependencies, while also applying the outbound controls required by your environment. Reference: APIM outbound virtual network integration requirements Step 4 - Configure APIM Virtual Network Integration In the Azure portal, open the API Management instance and navigate to Networking > Virtual network integration. Select the virtual network and dedicated subnet, and then save the configuration. Virtual network integration can also be configured when creating the APIM instance. References: Outbound virtual network integration | API Management v2 service tiers overview Test the Current Outbound IP This example uses a second APIM instance as the backend, although any backend service that records the request source IP can be used. Before NAT Gateway is configured, the backend can observe different Azure source IP addresses. The Azure IP Ranges and Service Tags - Public Cloud file is available from the Microsoft Download Center: Download Azure IP Ranges and Service Tags – Public Cloud from Official Microsoft Download Center Step 5 - Create a NAT Gateway Create an Azure NAT Gateway and associate it with one or more Standard public IP addresses or a public IP prefix. The assigned public IP becomes the predictable source address used for applicable outbound connections through the integrated subnet. For this example, the NAT Gateway uses a Standard public IP address resource. Step 6 - Associate the NAT Gateway with the APIM Subnet Open the NAT Gateway configuration and associate it with the APIM integration subnet. After the association is applied, validate that the effective network configuration matches the intended routing, NSG, and outbound connectivity design. Step 7 - Validate Send a test request through APIM to an endpoint that returns the caller’s public IP address, or inspect the destination backend logs. Confirm that the observed source IP matches the public IP assigned to the NAT Gateway. As expected, the source IP address observed by the backend now matches the NAT Gateway public IP address. When to Use This Pattern This pattern is useful when: Backend teams require source-IP allowlisting. Third-party vendors support only IP-based network controls. Legacy integrations cannot be changed quickly. A manual rebuild of a solution previously hosted on an APIM classic tier must preserve predictable outbound addressing. Recommendations A predictable source IP can simplify firewall integration, but it should not replace strong service-to-service authentication. Where supported, combine or replace IP-based controls with mechanisms such as: Mutual TLS (mTLS) OAuth 2.0 Client certificates Managed identity Private endpoints and Private Link Treat IP allowlisting as an additional network control rather than the primary authentication mechanism. Also validate capacity, resiliency, routing, DNS, NSG rules, and dependency access for the complete solution before production deployment. Conclusion APIM v2 services use a different outbound networking model from the classic tiers. For new deployments or manually rebuilt solutions, outbound virtual network integration combined with Azure NAT Gateway can provide a predictable public source IP for applicable outbound traffic and simplify integration with backend firewall rules.
Introducing the ABAP Cloud SDK for Azure: a native, secure path from SAP ABAP Cloud to Azure
Overview The ABAP Cloud SDK for Azure is now available as open source. It gives developers building on SAP Business AI Platform, ABAP environment and S/4HANA Cloud a first-class way to call Azure REST APIs — through a layered HTTP pipeline, pluggable Microsoft Entra ID credentials, typed exceptions, and strongly typed service clients — instead of hand-rolling if_web_http_client calls. SAP runs some of the largest enterprise workloads on Azure, and teams regularly ask for "better together" integrations — archiving documents to Storage, managing Compute, or querying their resource estate. Until now, doing this from ABAP Cloud (the restricted, released-API-only model behind SAP Business AI Platform, ABAP environment and S/4HANA Cloud) meant reinventing HTTP, authentication, and parsing in every program. This SDK closes that gap with a reusable, secure, and testable runtime, so developers can focus on their scenario instead of the plumbing. The first release ships three service clients — Azure Storage (Blob), Compute, and Resource Graph — backed by ABAP Unit tests, runnable demos, and full Microsoft open-source governance. Why it matters Accelerate SAP-on-Azure integration — give ABAP Cloud developers a native, low-friction way to call Azure REST APIs, cutting boilerplate and time to value. Bring Azure SDK patterns to ABAP — offer the same pipeline, credential, and typed-client model as the official Azure SDKs, so SAP teams feel at home quickly. Advance the Azure and SAP partnership — deepen Azure's value for the large SAP customer base and enable "better together" scenarios across storage, compute, and resource management. ABAP Cloud compliance — provide a released, cloud-ready SDK that complements the classic on-premises ABAP SDK for Azure for modern SAP Business AI Platform, ABAP environment and S/4HANA Cloud environments. Security-forward by default — encourage Microsoft Entra ID–based authentication, with a User Delegation SAS as the recommended path over account keys. Community-driven — ship an open-source MVP to gather feedback, validate demand, and shape the roadmap together with SAP and Azure customers. Relationship to the classic ABAP SDK for Azure This SDK is the ABAP Cloud counterpart to the established ABAP SDK for Azure. The classic SDK targets classic and on-premises ABAP; the new one is written entirely in ABAP for Cloud Development using only released APIs, so it activates cleanly on SAP Business AI Platform, ABAP environment and S/4HANA Cloud. Whichever platform your team runs on, there is a fitting option. Authentication: Microsoft Entra ID first Security is a design constraint here, not an afterthought. Authentication is built around Microsoft Entra ID (formerly Azure Active Directory). Every credential implements a single interface, zif_az_token_credential: a client-secret (service principal) credential, a managed-identity credential, and a default credential that resolves whatever is available in the environment. A token cache avoids re-fetching tokens that are still valid. For Storage Blob data-plane access, the SDK documents — and its demos and tests follow — a recommended order of authentication: prefer a User Delegation SAS (a short-lived SAS signed by a Microsoft Entra ID identity, with no account key involved), then a direct Microsoft Entra ID credential. Plain SAS and Shared Key (the storage account key) remain supported for compatibility, but are the least-recommended options. The guidance is simple and identity-first: prefer an Entra ID identity (ideally signing a User Delegation SAS); fall back to account keys only when no identity is available. DATA(lo_credential) = NEW zcl_az_client_secret_cred( " a Microsoft Entra ID identity iv_client_id = '<client-id>' iv_client_secret = '<client-secret>' iv_tenant_id = '<tenant-id>' ). DATA(lo_udk) = NEW zcl_az_blob_udk_sas( iv_account_name = '<storage-account>' io_credential = lo_credential ). " Entra ID identity signs the SAS DATA(lo_blob) = lo_udk->create_blob_client( iv_container = '<container>' iv_permissions = 'rl' " read + list iv_start = '2026-07-24T00:00:00Z' iv_expiry = '2026-07-25T00:00:00Z' ). DATA(lo_result) = lo_blob->list_blobs( iv_container = '<container>' ). " no account key Architecture at a glance The SDK is layered so each concern is isolated, testable, and reused across every service client. HTTP pipeline (zcl_az_http_pipeline) — a request flows through an ordered chain of policies before it hits the wire. Shipped policies cover retry, authentication, logging, and the transport itself. Credentials — everything authenticates through zif_az_token_credential, so any credential type plugs into any client. Typed exceptions (zcx_az_*) — callers handle meaningful SDK errors with context, not raw HTTP status codes. Typed models — responses deserialize into ABAP structures and result objects, so consumers work with fields, not strings. Injection seam — every client and credential constructor accepts an optional transport, so unit tests can substitute a double and run without a network. A service client stays thin — build a typed request, hand it to the pipeline, map the typed response back — while retry, auth, logging, and error translation are shared infrastructure. Anyone who has used the Azure SDKs for .NET or Java will recognize the shape immediately. Implemented services (first release) Service Client What you get Storage Blob zcl_az_blob_client Four convenient typed methods — list_containers, list_blobs, download_blob, upload_blob — with typed models and XML deserialization, plus the full generated REST surface (containers, leases, blocks, pages, append, service operations). Binary-safe for images and arbitrary bytes. Compute zcl_az_compute_client The Virtual Machines / Scale Sets / Images / Hosts surface with typed responses, path and query building, body serialization, and action endpoints such as start, deallocate, and restart. Resource Graph zcl_az_resourcegraph_client A streamlined query_resources interface (primitives in, object result out), plus the typed resources( body ) request/response and operations_list. Getting started Prerequisites An SAP Business AI Platform, ABAP environment or S/4HANA Cloud system with ABAP for Cloud Development. A Microsoft Entra ID identity (for example a service principal: client ID, client secret, tenant ID) with appropriate Azure RBAC roles for the resources you intend to access. The target Azure resources (a storage account and container, a subscription, etc.). Import Clone the repository and import the ABAP objects into your system (for example via abapGit). The objects are organized under a clean package hierarchy rooted at ZABAP_SDK_AZURE, with sub-packages for the core runtime, identity, services, tests, and demos. On import, assign the root package to your target parent package. A guided walkthrough 1. Blob access with a direct Entra ID credential Pass an Entra ID credential straight to the blob client. The identity needs a Storage Blob Data RBAC role on the account. DATA(lo_blob) = NEW zcl_az_blob_client( iv_account_name = '<storage-account>' io_credential = lo_credential ). " Microsoft Entra ID bearer token DATA(lo_result) = lo_blob->list_blobs( iv_container = '<container>' ). LOOP AT lo_result->mt_blobs INTO DATA(ls_blob). " ls_blob-name / ls_blob-content_type / ls_blob-content_length ... ENDLOOP. 2. Uploading a document to Blob storage A frequent SAP-to-Azure scenario is archiving a generated document into a storage container. With upload_blob, that is a single typed call: provide the container, blob name, content bytes, and content type, and the SDK handles the request, auth, and response mapping. The bundled blob demo shows this end to end — say, a PDF invoice upload (see below). 3. Running a Resource Graph query Query your Azure resource estate with KQL and get a typed result back: DATA(lo_rg) = NEW zcl_az_resourcegraph_client( io_credential = lo_credential ). DATA(lo_result) = lo_rg->query_resources( iv_query = `Resources | project name, type, location | limit 5` it_subscriptions = VALUE #( ( '<subscription-id>' ) ) ). Try it in minutes: the bundled demos The ZABAP_AZ_DEMO package contains three ready-to-run, self-contained example classes — one per service. Each is an if_oo_adt_classrun class, so you run it directly from ABAP Development Tools with F9 (Run As → ABAP Application (Console)). Demo class Service What it does zcl_az_demo_blob_ops Storage Blob Document upload: builds an in-memory PDF "invoice", uploads it to a container, lists blobs, and downloads it back. Demonstrates all auth modes and defaults to User Delegation SAS. zcl_az_demo_compute_vm Compute Lists the VMs in a resource group and deallocates a VM. zcl_az_demo_rg_quer Resource Graph Runs a KQL query three ways: the ergonomic facade, the typed resources( body ), and operations_list. Before running, replace the <YOUR_...> placeholder constants with your own environment values (storage account, container, subscription, resource group, VM name, and the Entra ID client ID / tenant ID / client secret). The demos ship with placeholders only — never commit real credentials, account names, or SAS tokens. Tested by design The SDK ships with ABAP Unit test methods, all RISK LEVEL HARMLESS DURATION SHORT, plus self-skipping integration tests for optional live verification. Because every client and credential accepts an optional transport, tests substitute a double and assert on the exact request that would go on the wire — URL, headers, body — and on how a canned response is parsed, all offline and deterministic. The runtime core (pipeline, policies, credentials, crypto, HTTP helpers) and each service client are covered. Open source and governance The project follows Microsoft open-source practice and is developed in the open under the Azure organization: License: MIT. Security: please report vulnerabilities privately per SECURITY.md (MSRC), not via public issues. Code of Conduct and Contributing guidelines are in the repository. This is an initial release This is a first / MVP release, published deliberately early so the community can use it, test it against real scenarios, and help steer it. APIs may evolve based on what we hear. What's next is community-driven. The same runtime — pipeline, credentials, typed exceptions, and models — is designed to be extended to additional Azure services beyond the initial three. Which services come next will be prioritized by what practitioners actually need, so early feedback has the most influence. Get involved Feedback and participation happen in the open on GitHub: Browse the code and docs: https://github.com/Azure/ABAP-Cloud-SDK-for-Azure Report a bug or request a feature: open a GitHub Issue. Ask questions, share scenarios, discuss ideas: start a thread in GitHub Discussions. Whether it is a bug, a missing operation, an awkward API, or a service you wish were covered — please tell us. Early, specific feedback is the fastest way to make this SDK genuinely useful for SAP-on-Azure integration. Get the SDK https://github.com/Azure/ABAP-Cloud-SDK-for-Azure Import it, run a demo, and let us know what you think.
A streaming pipeline can be healthy even when the data isn't complete yet.
One thing worth separating in streaming systems is processing time from event time. A message can arrive late because of a disconnected device, a network delay or an upstream system that buffers events. If downstream aggregations assume every event arrives in chronological order, the resulting windows can be misleading. In event-stream processing, event-time windows and watermarks help define how long the system waits for late events before considering a window sufficiently complete. The exact behaviour depends on the processing engine and its configuration. A few questions come up when designing these pipelines: How late can events realistically arrive? What should happen to events that arrive after the allowed lateness? Does the business require corrected historical aggregates? How do you monitor event-time lag separately from processing latency? There is not one watermark setting that fits every workload. A short delay may reduce reporting latency but increase the number of late events that need separate handling. How do you choose the lateness threshold for Azure streaming workloads, especially when the business expects both low latency and accurate historical results?
FinOps for AI Workloads on Azure: Tokens, PTU and Pay-As-You-Go
Originally published on Substack: https://gisli78.substack.com/p/finops-for-ai-workloads-on-azure Part 3 of my Azure AI landing zone series is about FinOps for AI workloads. Tokens are the AI bill most teams actually get, so the post covers: Picking the deployment type first: Global Standard, Data Zone, Batch and Flex (preview) Why quota isn't billing, and why max_tokens eats your TPM PTU vs pay-as-you-go, and when hourly PTU actually pays off Sizing PTU with Microsoft's formula, and how prompt caching helps Spillover: PTU for the baseline, pay-per-token for the peaks Showback per team with llm-token-limit and llm-emit-token-metric in API Management Cost Management: group by meter, tag your deployments, and remember budgets only alert Read the full article on Substack: https://gisli78.substack.com/p/finops-for-ai-workloads-on-azure Bicep sample: https://github.com/gislig/azure-ai-landing-zone/tree/main/examples/ai-finopsHybrid Logic Apps - SQL as storage provider benchmarking
Key findings for technical decision makers Hybrid Logic Apps ran a high-volume, file-driven integration workload on deliberately modest on-premises hardware: one host shared by the cluster, file storage and SQL Server 2025. Across both 30-minute tests there were no failed runs, and the one-hour dashboard view showed 45,821 successful runs at a 100% success rate. The database was not a cost driver: SQL Server used an average of 1.83% of host CPU capacity. Most runs finished in about 4 seconds, with a longer tail for the slowest 1%. The factor that most affects scale is storage, not server count, because adding workflow instances does not add disk capacity. For planning, budget for dedicated storage for the database and files as volumes grow, size capacity on peak and tail response times rather than averages, and validate with your own workloads. These results are a baseline for one workload, not a product-wide capacity guarantee. A practical look at throughput, latency, reads, writes, and locks The primary goal of this exercise is to evaluate SQL read and write behavior and the time spent waiting for locks under integration load. Workflow throughput supplies the workload context; it is not a substitute for those database measurements. This is a mixed-workload observation, not an isolated SQL capacity test. In a 30-minute baseline, files were offered to an Azure Logic Apps workflow at approximately 100 files per second. SQL CPU usage remained low, while a substantial file backlog accumulated. The lesson is not that one component is necessarily slow. It is that a useful benchmark must connect offered load, completed throughput, latency, and waiting rather than treating any one metric as the answer. The SQL comparison tells a different story from workflow throughput alone: average workflow-state data-file write I/O latency rose from 12.958 to 38.652 ms, while accumulated instance-wide lock waiting remained near 1,470 task-seconds. Faster workflow completion did not mean that every SQL measurement improved. A repeat of the same 30-minute workload subsequently showed 3.87% higher successful throughput, 6.40% lower p95 execution latency, and 8.68% lower p99 execution latency, with no failed workflow runs in either measured window. Both measurements are retained below: the repeat was an observed improvement, not proof of a tuning change or a product-wide performance guarantee. The workflow The workflow snapshot shows the processing sequence used in the benchmark. The workflow is taken such that huge set of I/O operations are performed during the workflow executions to simulate the SQL benchmarking under high I/O operations. The workflow performs six steps: Detect a newly created file in a receiving folder. Insert a business record into SQL. Read the source file's contents. Create a copy in a destination folder. Delete the source file. Delete the destination copy. This is a synthetic processing-and-cleanup scenario, not an archival workflow: both test-file copies are removed on successful completion. A successful run means that the complete sequence finished, not just that the SQL insert succeeded. Infrastructure: OpenShift K8se cluster with single node, one shared disk The deployment topology is a hosted Windows machine running an on-premises, single-node OpenShift cluster in a Linux VM, with local SMB storage and SQL Server 2025 on the same Windows host. The SMB files, SQL data and transaction logs, and cluster VM storage all share the same host drive and backing disk. Different folders or virtual disks on that shared backing disk do not create independent I/O capacity. The workflow operates in a fully disconnected runtime environment: the execution and data paths shown remain local, without an external runtime-service dependency for this workflow. This documents the supplied runtime topology, not an independent network-isolation test or a claim about offline installation and management. Autoscaling adds workflow pods, not OpenShift nodes or additional disks. The configured 1-10 replicas therefore share the same single-node compute and storage resources. This layout matters when interpreting performance. File creation, reads, copies, and deletion can overlap with SQL reads, data writes, transaction-log writes, and cluster storage activity on the same disk. More pods can increase that shared I/O demand without increasing disk capacity. Storage delays can also lengthen transactions and the time locks remain held, but the topology alone does not establish that disk contention caused the measured blocking or throughput limit. How the baseline was measured The test offered small, 1 KiB files at a target rate of 100 files per second for 30 minutes. The existing workflow and database configuration were retained during the measurement; this was a baseline, not a tuned result. Measurements covered file publication, workflow starts and outcomes, execution duration, SQL request timing, SQL process resources, database-file I/O, and blocking. Existing autoscaling remained enabled, so this was not a fixed-replica benchmark. Observability also has a cost: these are instrumented results, not a claim of zero measurement overhead. SQL benchmark: reads, writes, and locking periods The database results below come from the two measured 30-minute exercises, not from the one-hour dashboard view later in this post. SQL counter snapshots bracket each exercise: approximately 1,801.16 seconds for the initial workflow-state observation and 1,801.74 seconds for the repeat. Business-data counter coverage is approximately 1,801.16 and 1,801.71 seconds. The workflow load-generation window itself is exactly 1,800 seconds. Evaluation Plain-language question What the saved measurements can answer Read How much information does SQL retrieve, and how long do disk reads take? Physical database-file read counts and average I/O latency; completed SQL request timing. Write How much information does SQL save, and how long do data and log writes take? Physical data-file and log-file write counts and average I/O latency; completed SQL request timing. Locking period How long does an operation wait for another operation, and how long does the owner hold its lock? Accumulated lock-wait time, waiting-task counts, and sampled blocking. Individual lock-hold durations were not recorded. Read and write I/O: volume and latency The two database roles are labeled workflow state and business data. Each row below describes a file-I/O operation, not an individual SQL statement. Database role / file I/O operation Initial count Repeat count Initial average ms/I/O Repeat average ms/I/O Workflow state / data Read 35,169 9,331 0.896 0.571 Workflow state / data Write 74,146 90,913 12.958 38.652 Workflow state / log Write 318,134 334,775 0.938 1.115 Business data / data Read 104 19 0.923 0.474 Business data / data Write 124 14 0.919 0.714 Business data / log Write 25,826 27,018 1.152 1.425 Average read I/O latency = read-stall milliseconds / read I/O count. Average write I/O latency = write-stall milliseconds / write I/O count. These are operation-weighted counter ratios, not averages of sample averages. The repeat performed fewer physical data reads and more workflow-state writes. Its average workflow-state data-file write latency was approximately three times the initial value. Workflow-state log writes also became slower on average. The small business-data file-I/O counts should not be treated as a stable disk-performance estimate. A read satisfied from memory need not cause a physical file read. Likewise, many row changes can be persisted together, and transaction-log writes are distinct from later data-page writes. Consequently, these counts are not SELECT counts, INSERT counts, or committed business-record counts. None of the file-I/O averages is the duration of an entire SQL statement or transaction. Completed SQL request timing SQL requests provide a separate view of elapsed server-side work. The trace selected events completed within each exact 30-minute window. Percentiles are approximate; requests still running at cutoff are excluded. Database role / request type Window Completed events Average ms p95 ms p99 ms Workflow state / remote call Initial 1,127,136 1.780 2.431 62.479 Workflow state / remote call Repeat 1,170,736 1.647 1.643 52.385 Business data / remote call Initial 81,114 0.960 1.354 14.487 Business data / remote call Repeat 84,220 1.041 1.225 15.503 Workflow state / SQL batch Initial 586 0.244 0.382 0.557 Workflow state / SQL batch Repeat 645 101.029 33.750 7,967.948 A remote call is a completed RPC event, not necessarily one statement. These request populations mix reads, writes, and supporting work; they do not establish separate SELECT-only or INSERT-only latency distributions. Batch events are shown separately rather than hidden inside the much larger remote-call population. Database-wide activity can include monitoring and dashboard requests, so this is not an application-only isolation test. The repeat improved workflow-state remote-call latency, but business-data p99 and batch latency worsened. There is no basis for saying that all SQL latency improved. Lock waiting: duration, concurrency, and observation period A lock hold belongs to the operation owning the lock: acquisition through release. A lock wait belongs to another operation waiting to obtain a conflicting lock. These are different periods; a waiting operation's duration does not reveal precisely how long the owner held the lock. Locking measurement Scope Initial Repeat Accumulated lock-wait time SQL instance 1,473.235 s 1,467.470 s Lock-waiting task count SQL instance 51,283 50,548 Wait-time / waiting-task counter ratio SQL instance 28.728 ms 29.031 ms Range/update coordination waits SQL instance 1,287.958 s 1,273.562 s Update coordination waits SQL instance 183.449 s 168.197 s Other lock waits SQL instance 1.828 s 25.711 s Peak sampled blocked requests Workflow-state database 16 20 Snapshots showing blocked requests Workflow-state database 85 / 353 78 / 354 Longest span of consecutive positive blocking snapshots Workflow-state database Approximately 15.2 s Approximately 10.2 s The cumulative lock counters are instance-wide and reported once, not added again for each database. Other activity on the instance can contribute. They count waiting SQL tasks, not unique transactions, locks, or workflow runs. The mean counter ratio is not a measured per-lock hold time or a lock-wait percentile. 1,473 accumulated wait-seconds does not mean the database was continuously blocked for 1,473 seconds. Concurrent tasks can wait at the same time. The totals cannot be divided by test duration and described as the percentage of the test spent blocked. The roughly five-second snapshots count requests blocked by another identified session. They do not record each request's wait type or lock lifetime. The longest positive-snapshot span means blocking was present at successive observations; different requests may have been involved, and blocking could have stopped between samples. It is not proof of one continuous blocking episode or one transaction holding a lock for that long. No blocked business-data requests were seen in the snapshots; brief blocking between samples remains possible. For write-related context, instance-wide waiting for transaction-log flushes accumulated 1,200.092 seconds initially and 1,390.289 seconds in the repeat. These are task-wait sums, not individual commit latency or additional time to add to workflow duration. What this does and does not establish The exercise establishes measured read/write I/O volume and average latency, mixed SQL request timing, and aggregate lock waiting with sampled blocking under the workflow workload. It does not establish isolated SQL read/write capacity, statement-specific read/write latency, exact blocking-episode lengths, or p50/p95/p99 lock-hold durations. One-hour dashboard results (Initial + repeat) These are actual values from the supplied dashboard with Last 1 hour visibly selected. This is a rolling dashboard observation, not a newly executed one-hour controlled load test. Measurement Dashboard result Selected observation period Last 1 hour Total runs displayed 45,821 Successful runs displayed 45,821 Failed runs displayed 0 Displayed successful count / 3,600 seconds 12.728 runs/second Average execution duration displayed 3.70 seconds Success rate displayed 100% Retry count No data Processing beyond the cutoff This supplied dashboard view spans a longer period than the 30-minute baseline. Processing continues after file generation stops. The displayed run total belongs to the dashboard's selected scope and aggregation. It is not the number of successful completions during the fixed measurement window, and it has not been reconciled to the exact benchmark cohort. The curve shows run counts over time, not a cumulative completion counter; its bucket size is not specified here, so the vertical values should not be read as runs per second. Latency: look beyond the average Successful workflow execution duration Result Average 4.11 seconds p50 Approximately 3.89 seconds p95 Approximately 6.20 seconds p99 Approximately 13.01 seconds Maximum 23.71 seconds These durations measure workflow execution after a run starts. They exclude time spent waiting in the receiving folder. As the backlog grows, a file's arrival-to-completion time can be much longer. Each point summarizes one minute. Workflow duration uses seconds; SQL request duration uses milliseconds. The SQL panels separate requests associated with workflow state from requests associated with business data, without exposing database identities. The first few minutes show higher workflow latency than much of the later window. The chart exposes this change but does not, by itself, establish its cause. The workflow chart includes successful runs completed by cutoff. SQL timing includes captured completed requests; requests still running at cutoff are not represented in those percentiles. Workflow bucket and whole-window comparison percentiles were computed from the observed completed runs; displayed values are rounded. SQL percentiles are approximate. SQL activity in the broader observation period These supplied SQL panels provide broader context, not additional fixed-window baseline results. SQL operations per second counts database work, not completed workflow runs: one workflow can require multiple SQL operations. The CPU line here is measured in milliseconds of SQL execution CPU time, not the percentage of host capacity shown below. Dashboard time ranges and aggregation differ from the baseline charts, so their averages and totals should not be substituted for the 30-minute measurements. SQL process measurement Result Average CPU, normalized to host capacity 1.83% Peak sampled CPU, normalized to host capacity 8.08% Physical memory at the first recorded sample Approximately 1.20 GiB Physical memory at the last recorded sample and peak Approximately 3.15 GiB These are instance-wide SQL process measurements, not workflow-container utilization or total machine utilization. CPU points represent roughly five-second interval averages, not instantaneous peaks. The dashed reference uses the reported full-window average; the recorded series ends slightly before cutoff and is not extrapolated. A system can have CPU headroom while work waits for storage, another transaction, a network response, or another part of the workflow. Aggregate CPU usage can also hide a narrower, serialized bottleneck. Configured scaling and application resources The deployment's configured scaling values were captured after the repeat. Application-configuration fingerprints matched before and after the test. Scaling setting Captured value Minimum replicas 1 Maximum replicas 10 Polling interval 30 seconds Configured cooldown 300 seconds Polling and cooldown values describe configuration, not guaranteed reaction times. Actual scaling also depends on controller decisions and stabilization. The dashboard's matching-pod count rises from about one to five, then steps down through four to three during the repeat. A later increase occurs after the measurement cutoff, while queued work continues processing. This panel counts matching pod records; it does not filter explicitly for readiness. It should not be interpreted as proof that every displayed pod was ready at every instant. Independent runtime checks found one ready replica before the repeat and three after it. The captured resource budget also distinguishes the application container from the entire pod: Resource scope, per replica CPU request CPU limit Memory request Memory limit Application container 0.425 cores 1 core 1,844 MiB 2 GiB Whole pod, including supporting containers 0.501 cores 1.5 cores 2 GiB 4.5 GiB Green represents usage; yellow represents the summed application-container limits. The chart's resource scope excludes supporting containers, so it is not the whole-pod or cluster resource budget. The CPU usage line is a five-minute rate expressed in cores. Memory usage is the containers' working set. As the number of matching application containers changes, their summed limits change too; this does not mean usage suddenly rose to the limit. These application metrics are not interchangeable with SQL process CPU percentages or SQL process physical memory. Aggregate headroom also does not exclude per-container throttling or uneven load distribution. Supplied latency dashboard This supplied panel shows p50 3.60 s, p95 5.47 s, and p99 10.5 s for its selected scope. Its time filter is not visible, so these values are not substituted for the fixed-window comparison above. Run and SQL trends beyond the repeat window This view extends beyond the 20:54:59 IST measurement cutoff and includes continued processing. Values are counts in the dashboard's time buckets, not a cumulative total or a documented runs-per-second rate. SQL duration and SQL CPU time here are in milliseconds. They are not workflow execution time or host CPU percentage. The dashboard aggregation covers a different scope from the verified 30-minute SQL measurements. How to use these results This is a baseline for one synthetic workflow, payload size, workload shape, and deployment. It is not a product-wide capacity limit, service-level guarantee, or comparison between deployment platforms. Workflow outcomes describe runs started within the measurement window and their status at cutoff. They are time-window totals, not a file-by-file correlation audit; concurrent executions of the same workflow can contribute. SQL process resources and wait measurements can include other activity on the same instance; individual SQL requests are not equivalent to workflow runs. For organizations that must keep integrations close to their data, whether for regulatory, data-residency or operational reasons, Hybrid Logic Apps brings the Logic Apps platform into their own datacenter. In this benchmark, the workflow ran fully disconnected on a single on-premises host, with SQL Server 2025 storing workflow state and no dependency on an external runtime service. The business value is straightforward. Sensitive data stays on site, workflow state lives in a database your team already operates and protects, capacity scales automatically within the hardware you own, and when demand spikes, work queues instead of failing. Teams also build on the same Logic Apps skills they use in Azure, rather than maintaining a separate integration stack for on-premises workloads.Azure DevOps in 2026: Are We Moving Towards Fully AI-Driven DevOps Pipelines?
With AI becoming increasingly integrated into software development and IT operations, I've been thinking about how the role of Azure DevOps might evolve over the next few years. Traditionally, Azure DevOps has helped teams manage repositories, CI/CD pipelines, testing, artifacts, and project delivery. But with the growing adoption of AI agents, automated code reviews, intelligent monitoring, and predictive analytics, could we be approaching a new era of autonomous DevOps? I'm particularly interested in exploring a few questions: 1. AI-powered CI/CD: How far are we from pipelines that can identify issues, recommend fixes, and optimize deployments with minimal human intervention? 2. Azure DevOps vs. GitHub: With GitHub Actions and AI-assisted development becoming increasingly popular, how do you see the long-term positioning of Azure DevOps? 3. Intelligent infrastructure management: Can AI agents eventually manage deployment decisions, infrastructure optimization, and incident response while maintaining appropriate human oversight? 4. Security and governance: How should organizations balance automation with compliance, accountability, and security? 5. The future of DevOps engineers: Will AI primarily assist DevOps professionals, or fundamentally transform their responsibilities? I believe the next major evolution in DevOps won't simply be faster automation, but systems capable of making increasingly intelligent, auditable operational decisions. I'd love to hear from the Microsoft Tech Community: What AI-driven DevOps capabilities are you already implementing, and what do you believe will become mainstream over the next three to five years? Looking forward to learning from your experiences and perspectives.
Billing Profile Disabled (PastDue) despite Amount Due = $0.00 and no active subscriptions
Hello everyone, I am trying to create a new Azure subscription, but Azure returns the following error: You can't add a billing profile. Your billing account has a past due balance. After investigating with Azure Portal and Azure CLI, I found conflicting information. Current Account Status Billing Account Status: Active Agreement Type: Microsoft Customer Agreement (MCA) Account Type: Individual Role: Billing Account Owner No active Azure subscriptions Billing Profile Azure CLI returns: Billing Profile: TWJS-5ASF-BG7-PGB Status: Disabled StatusReasonCode: PastDue Azure Portal Information Azure Portal shows: Amount Due: $0.00 Outstanding Balance: $0.00 Payment Method: Active Overpayment Credit: $0.04 No unpaid invoices are displayed in the portal. Historical Invoices Found via Azure CLI I found the following invoices: G007411389 Amount Due: $4.69 Status: Unknown G008278248 Amount Due: $17.21 Status: Unknown G008948077 Amount Due: $16.18 Status: Unknown G009572675 Amount Due: $16.32 Status: Unknown What Confuses Me Azure Portal indicates that there is no outstanding balance. However, Azure Billing API still reports: Billing Profile Status = Disabled Reason = PastDue a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Because of this, I cannot: Create a new Billing Profile Create a new Azure Subscription Questions Is it possible that these historical invoices are still causing the Billing Profile to remain in a PastDue state? Has anyone experienced a situation where Azure Portal shows $0.00 due but Billing API still reports PastDue? Is there any way to reactivate the Billing Profile without direct intervention from the Microsoft Billing team? Any advice would be greatly appreciated. Thank you.Azure Storage Discovery now offers advanced capacity insights
Azure Storage Discovery is introducing advanced capacity insights to help customers gain deeper visibility into their data estate, identify inactive or inefficiently stored data, understand storage composition and retention considerations, and pinpoint resources for further investigation and optimization.
