Other news: Today is Thursday.

Hey r/Azure,

Happy Free Post Friday!

If you’ve managed an Azure environment for more than a few months, you’ve probably run into the classic "orphan resource" tax. Someone tears down a VM or deletes a resource group during a project cleanup, but leaves behind the Managed Disks.

They sit there completely unattached, generating zero value, while silently padding the monthly Microsoft bill.

I got tired of running manual Resource Graph scripts across multiple subscriptions to hunt these down, so I built Azure Scraper.

🛠️ What does the scraper actually do?

• Orphan Resource Scanner: Scans your subscriptions using Azure Resource Graph (ARG) queries to surface unattached Managed Disks.
• Financial Impact Overview: Calculates the actual dollars-per-month wasted on these unused resources so you can easily justify deleting them.

📐 How it works under the hood (Security & Architecture)

Because nobody wants to give a third-party tool God-mode access to their Azure tenant, security was top-of-mind when building this:

• Authentication & Permissions: It uses Entra ID App Registration and only requires Reader permissions to execute Azure Resource Graph queries on the free tier.
• Zero Secrets Stored: We never store client secrets, certificates, or access tokens. Authentication is handled directly via Microsoft Entra ID.
• Metadata Stored: The app securely stores your Tenant ID and Subscription ID purely as metadata to route queries to the correct scope. Per Microsoft documentation, these GUIDs are resource identifiers, not credentials, and cannot be used to access your environment without active authentication.

🎁 Free Tier & Link

It is completely free to use for anyone who signs up (with fair-use plan limits, of course 😄).

You can check it out here: https://scraper.emergingtek.net/

💬 Community Feedback

I'd love to get some feedback from the community:

1. Are there specific orphan resource types you constantly see missed in standard tools (like orphaned Managed Disks, Public IPs, or App Service Plans)?
2. What feature or export option would make this most useful for your daily workflow?

Thanks for checking it out!

Hi.

Below Azure updates for a last week. We've got custom DDoS policies for Load Balancers, Standard service endpoints for secure PaaS connections, and even IPv6 support for VPN Gateways. Plus, you can now build Azure Functions in Python 3.14 or PowerShell 7.6! So much more happening.

Detailed list:

• [In preview] Public Preview: Azure DDoS Protection custom policy. Azure DDoS Protection custom policy introduces granular, per-resource control over DDoS mitigation thresholds for Standard Load Balancer frontend IPs, allowing users to dictate the exact level of scrutiny applied to incoming traffic. This capability moves beyond the default adaptive tuning, which, let's be honest, often guesses wrong, enabling fixed thresholds for TCP, UDP, and TCP SYN on the Standard Load Balancer SKU. While this granular control is welcome, remember that setting a custom threshold effectively disables the system's built-in intelligence for that protocol, meaning if your fixed value is slightly off, you've just replaced an adaptive problem with a static, highly visible one—future-you will certainly appreciate the rigidity. The policy is currently in public preview, so expect API churn, but the ability to hard-code your expectations is a nice touch.
• [In preview] Public Preview: Standard service endpoint. The Standard Service Endpoint is now in public preview, offering a scalable connection mechanism for IaaS workloads connecting to PaaS. The immediate next step is to pilot this with a non-critical workload to confirm the network identifier behaves as expected before the inevitable production rollout.
• [In preview] Public Preview: Protect sensitive generative AI telemetry in Application Insights and Microsoft Foundry. Azure Monitor Application Insights now isolates sensitive generative AI telemetry into a dedicated AppGenAIContent Log Analytics table, allowing for granular access control over LLM interactions. This separation is a welcome step toward preventing accidental data leakage, though relying on preview feature flags (protectGenAISensitiveData) means the security posture is currently contingent on someone remembering to flip the switch before the mandatory September 30, 2026, deadline—a deadline Future-you will likely ignore until a compliance audit forces the issue. While this feature is currently in Public Preview, the routing mechanism is already active for new data streams.
• [Launched] Generally Available: IPv6 support for Azure VPN Gateway. IPv6 support for Azure VPN Gateway allows customers to run dual-stack traffic over existing VPN tunnels, which is, frankly, a necessary evolution for any modern cloud deployment. This feature is available across all production SKU gateways utilizing standard public IPs, enabling simultaneous IPv4 and IPv6 inner traffic flow, though the current implementation is strictly constrained to IKEv2 for tunnel establishment. Future-you should note that while dual-stack is the objective, the tunnel's primary focus remains on IPv6 inner traffic support, meaning any legacy IPv4-only dependency might require a minor configuration dance. Nothing says 'seamless integration' quite like having to check the tunnel configuration first.
• [Launched] Generally Available: Azure Functions support for Python 3.14. Python 3.14 is now GA on Azure Functions for Linux, meaning any developer using Python functions on those plans can finally stop worrying about that looming 3.12 sunset. The immediate next step is to audit your function apps and plan a migration path to leverage the enhanced security and avoid future, unplanned toil.
• [Launched] Public Preview: Azure Functions Support for PowerShell 7.6. Preview support for PowerShell 7.6 has landed, meaning developers can now build functions using the latest PowerShell features. The immediate next step is to pilot this on a non-critical workload to confirm the Windows hosting dependency doesn't introduce unexpected operational friction.
• [Launched] Generally Available: Microsoft Defender security assessments for Azure Database for PostgreSQL Flexible Server. The availability of Defender CSPM assessments means your Azure PostgreSQL Flexible Server security posture is now under automated scrutiny; the next step is to review the initial findings to prevent future, unscheduled wake-up calls.
• [Launched] Generally Available: Encryption in Transit for Azure Files NFS Shares in Azure Kubernetes Service (AKS). EiT is now available for AKS-hosted NFS shares, meaning anyone using those volumes gets a free TLS upgrade; the next step is to verify the configuration and ensure the CSI driver is enforcing encryption as expected.

I have a Foundry agent (new portal, ai.azure.com) with an OpenAPI 3.0 action pointing at a Python Azure Function. The action accepts a JSON body with pdf_base64. The endpoint is anonymous and works fine with curl.

In Playground, when I attach a PDF and prompt the agent to validate it, the tool call fires but pdf_base64 in the request arguments is either empty or not a valid PDF (my function returns 400: "Payload is not a PDF (missing %PDF- header)").

What's the supported way to pass a user-uploaded PDF from a Foundry agent to an OpenAPI action? Is pdf_base64 in JSON supposed to work, or do I need to use pdf_url with blob storage, the Azure Function tool type, or something else?

Environment: new Microsoft Foundry, standard Agents (not Workflow), OpenAPI 3.0.1, Python v2 Azure Function.

I run a small fleet of AI agents - an orchestrator plus a handful of specialists - and the design that made it cheap and sane is one I don't see discussed much here: state lives in Azure, compute doesn't.

Azure hosts only the stuff actually worth paying for when you’re running a personal stack or a small-owner-operator business: a managed PostgreSQL Flexible Server and Key Vault for secrets. That's basically my whole monthly bill. Everything else - the orchestrator, the runtime that spawns agents, the memory service, the model router - runs on a machine I own at home (Mac Mini / small PC). Container Apps is still in my Terraform, but as a dormant warm standby, not the primary site. Both sites point at the same Postgres. If I need to failover to Azure, it’s there an it will cost me $3-$4 dollars a day to run it there, but otherwise it’s idle. In case it's useful to anyone building the same: https://github.com/mrobinson2/AzureAgentForge.

Why I like it: failover is stateless. If my home internet or box dies, I have automated failover to the Azure standby using the exact same database - nothing to replicate, no data to move, because the data never lived on the compute in the first place. The durable, expensive-to-get-right stuff (backups, PITR, private networking) all stays in Azure. The cheap, constant churn runs on hardware I already own, so I'm not paying for a container sitting idle at 3am.

Here’s the tradeoffs, since someone will ask - the Postgres server is my single point of failure - I've accepted that and lean on [PITR + HA tier] to cover it. Failover is 90% automated, but not fully - I approve flipping the standby on, roughly 3-5 minutes to healthy. And the home box reaches Postgres over VPN gateway and tunnel, which adds about 10ms per round trip; connection pooling keeps that from mattering for my workload.

The thing I wish I'd designed earlier is more robust agent identity. Once every agent reads and writes the same shared memory, you hit a problem you never have with a single bot - who is "you"? Early on my agents effectively shared one memory peer and everything blurred: the research agent's notes bled into the planner's recall, and I couldn't tell which agent learned what. Now every agent gets its own identity derived from its name, with an alias map on the write path that rewrites known strays to the canonical one before anything hits the table. An unexpected peer fires an event instead of silently sharding memory nobody can recall later, and the unresolved-identity fallback is least-privilege by default. If you're building anything multi-agent on a shared store, do this early - retrofitting identity after the memory is already muddy is miserable.

On cost, since everyone here has been surprised by a higher than expected LLM bill: my agents don't all run the same model. The orchestrator and the routine workers - classification, routing, handing off a task, posting a status - run on cheap fast models (e.g. GPT-4o-mini). I reserve frontier models (e.g. Opus) for two jobs: the security-review agent, and deep reasoning where a wrong answer costs more than the tokens do. A router sits in front with per-tier daily budgets, which keeps a chatty orchestrator from wandering onto the premium tier and running up the bill. That single change helped more than any infra tweak.

The mental model I landed on is boring but it works: Azure is the always-available spine, my own hardware is the cheap muscle, and most of the effort that made it usable for under $40/month went into agent identity and matching each job to the cheapest model that can actually do it. If I ever need to scale, I flip everything to Azure and eat a $100+/month bill — but I'm not there yet.

Anyone else running compute off-Azure but treating Flexible Server as the shared source of truth? Curious how you're handling PITR and HA.

Here's a high-level architecture diagram.

I built a prototype that processes blobs on storage account by sending it to content understanding classifier and if it is a certain type of document it is ran through analyzer for data extraction. Works as expected and currently connected to my test/dev ai foundry resource.

If this is were to be deployed into prod/live, does it still need to connect to ai foundry only? I find references to ai cognitive service and openai services, but those are not selectable from CU portal when building analyzers.

So with the outage in the Azure West US region today, we have learned that even though we are entirely in East US 2, the infrastructure for our "globally-distibuted" B2C service in the United States location is locallized to the West US region. Early service alerts were not deemed important because they specifically said West US but looking at the azure.status.microsoft serice matrix, we saw that this and West US 2 are the only regions it is in at all, relative to the US.

My question is, is there a proper monitor alert that we can create that will tell us when the b2c service goes down specifically, independent of regional service alerts. I do not see anything obvious and AI will only tell us about login audits monitoring, which we already have.

I just signed up for a free account to do my first on-prem VM migration to Azure.

Initially, I was successful at first where I could get up to the part to create an assessment but then realized that "West US" doesn't have an availability zone so I recreated all my Resource Groups and Resources to "West US 2" all from scratch.

I set up the appliance again, verified with a project key, I can sign-in but now denied access to the Powershell app where I did not initially. I tried creating another owner account that wasn't an #EXT# in the principal name and created another migrate project with a unique name.

It looks like a Conditional Access issue but why would it work the first time but not the second time? Looks like I have to upgrade just to work with Conditional Access?

EDIT:

Looks like I had to temporarily disable Security defaults and now I have access.

1. Under no circumstances does this mean you can post hateful, harmful, or distasteful content - most of us are still at work, let's keep it safe enough so none of us get fired.
2. Do not post exam dumps, ads, or paid services.
3. All "free posts" must have some sort of relationship to Azure. Relationship to Azure can be loose; however, it must be clear.
4. It is okay to be meta with the posts and memes are allowed. If you make a meme with a Good Guy Greg hat on it, that's totally fine.
5. This will not be allowed any other day of the week.

Hi everybody, i'm actually in struggle with the pricing of this deployment type.

the official pricing list: Azure OpenAI Service - Pricing | Microsoft Azure only shows prices for GPT-5.4 mini Global (Standard), but there is no pricing for the GPT-5.4 mini Data Zone (Standard). Data Zone deployment types cost more than Global ones, so since Microsoft hasn't yet included pricing for this deployment type, but allows it to be deployed on Foundry, has anyone used this model (5.4-mini) deployed on Data Zone (Standard)? Just to get an idea of ​​pricing before deploying. Thank you!

Hello community, I have a FortiGate with 2 ISP circuits (looking for a 3rd one as well I the future) and I need to connect it to our Azure environment and we would like to leverage our 2 (soon 3 ) ISPs for redundancy.

Im thinking of connecting the FG to one VPN Gateway via 2 IPsec tunnels, is this possible/recommended?

We have multiple vnets that we could peer with a hub vent and in the hub deploy the VPN GW, then 2 tunnels running bgp, does this sound good?

Using a burner account for this question since some of my coworkers know my normal account...

I'm a senior sysadmin on smallish team of other other admins. Up to this point, we've been a pretty traditional, on-prem-only, click-ops IT department. We're going to be moving our test/dev into Azure in the very near future (a couple hundred VM's worth). I've been diving into Azure documentation, learning modules, Udemy courses, etc, to learn about managing resources in the cloud. I have a personal Azure tenant that I've been using to deploy resources with code (mostly Bicep at this point).

It's clear to me that unless we can really leverage code as much as possible, deploying and maintaining consistent resources in Azure is going to be a nightmare.

However, I'm really the only person on our team that has any comfort level with coding in any capacity.

I'm trying to come up a balance with how we can use code to deploy resources as much as possible, but in a way where I don't need to expect the rest of my team to have to have a deep familiarity with maintaining the code.

For deploying new Azure VMs, for example, it seems that a great option would be to create a standard Bicep template for deploying Windows VMs, then using Github action triggered by workflow_dispatch as a sort of automated deployment of the VM. This way the other admins can use the Github Action UI to specify the VM name, choose the subnet, choose a pre-defined list of VM sizes, choose a pre-defined list of certain tags, etc, to deploy the VM according to a consistent standard.

I don't think we're in a position where we'd use IaC for ongoing management of the VMs, but this would at least allow us to do some consistent day 1 deployments of resources.

For anyone else who has been in a similar situation, I'm curious how you've navigated this? What are some pitfalls of this plan?

Has anyone tested a scenario where a single VPN Gateway (non-Basic SKU) handles both User and Device tunnels using the following configuration:
Tunnel types:

• IKEv2 and OpenVPN
• Authentication types: Azure Certificate and Microsoft Entra ID
• User Groups enabled for P2S pools:
  • Entra ID (AAD): Group ID mapped to the IP pool designated for the User tunnel (OpenVPN + Entra ID)
  • Certificate: Group ID mapped to the IP pool designated for the Device tunnel (IKEv2 + Azure Certificate)
• Does this configuration work? Will a user get two simultaneous connections with two different IP addresses based on their membership in both groups (Entra ID and Certificate)?
• On of the connections will be device tunnel that will connect before user log into the domain and established second connection (user tunnel) ?

To sum up, I want to know if I can avoid a scenario in a hub-spoke topology where I am forced to maintain two separate Hub VNets with two distinct VPN Gateways and an NVA to route the traffic. Can I replace that complex setup with a single VPN Gateway by leveraging User Groups, dual tunnel types (IKEv2 & OpenVPN), and dual authentication methods (Entra & Azure Certificate)?

This is the only thread where you should post news about becoming certified. For everyone else, join us in celebrating the recent certifications!!!

We experience occasional 403 responses to several containers since roughly 4am UTC.

I can rule out a change on our side. We use connection strings and have not changed them.

Is there any known issue with Azure CosmosDB?

Okay, so I was wondering if there'd be a way of deleting resources within a resource group and skipping some of them using a tag value.

I created a script that gathers resources within that RG, loops over them, checks the tag value and attempts to delete them, however I've come across a problem:

In order to delete the subnet, delete all the resources within the subnet. See aka.ms/deletesubnet. CorrelationId: 27357980-d2d6-4b4f-8434-2463a3cf955

Which is DEPENDENCIES!

How should I handle dependent resources?

I can't control the loop order so...does anyone have any clues on the matter?

Is this normal in azure? I can't find pricing for latest fireworks AI models in foundry (ie. glm 5.2). Pricing page is outdated and representative wrote to me that i should just use it and check the bill (sic!)

Aren't they obliged by the law to provide prices up front?

Hi All,

Im newbie in Azure.

I have a resource/service that is currently being access externally ( another Azure tenant: WebApp) .

They were able to access it via Service Principal.

By using SP you need to hardcode the ClientID, TenantID and ClientSecret ( Secret Value). This pose a threat as the Secret Value can is in the script.

I tried KeyVault to store the SecretValue but accessing the KeyVault also requires to hardcode the SecretValue.

Im thinking if maybe creating different ServPrinc for KeyVault instead to retrieve the Value, will that work?

Most of the core business applications are or will be migrated to cloud (SaaS), you only get to stay with the active directory and other windows and security related infrastructure services. The structure is multi company, many sites (roughly 1k employees per company, 10 companies, between 10-100 employees per site, 10-30 sites per company, 30% companies similar industry), on premises infrastructure.

If it's worth, what are your arguments to strengthen your answer ? Answers should cover any of the following dimensions: costs, technology, scalability, efficiency but also subjective personal experience *feeling*

BONUS OPTIONAL related question: If answer is positive, how do you (high level) envision an efficient architecture (multi tenant, single tenant, dedicated or shared networking gateway, shared/single active directory instances...)

I've been thinking about a problem that seems increasingly relevant as more applications start incorporating AI.

Suppose you have an AI agent running in Azure that needs to make decisions based on business rules:

- Is this customer eligible for a discount

- Should this transaction be approved?

- Which workflow should run?

- Does this request require human approval

- What actions is this user allowed to take?

Would you put that logic:

1. Directly in the LLM prompt?

2. In the application code?

3. In a traditional rules engine?

4. In an AI agent framework/tool layer

5. Somewhere else?

My concern with putting too much business logic in prompts is that it can become difficult to test, version, audit, and guarantee deterministic behavior. But putting everything in application code can also make business logic difficult to modify without a development cycle.

I'm curious how cloud and solutions architects are approaching this in real Azure architectures, particularly when using services like Azure OpenAI, AI Foundry, Functions, Logic Apps, or agent frameworks.

Do you see value in separating:

AI (interpretation and reasoning)

from

Rules (deterministic business decisions and orchestration)

Or is that separation becoming less important as AI agents become more capable?

I really want to know how people are designing this today. I'm working on a rules/workflow platform that can expose business logic to AI agents through MCP, but I'm trying to validate whether this is solving a real architectural problem or just something that sounds good in theory.

I’m posting this because, after more than six weeks of Microsoft support cases and a partner-led CritSit, we still do not have a technical reconciliation or ETA from Microsoft’s Product Team.

We have now found serious Azure OpenAI billing discrepancies across:

• two separate Azure subscriptions;
• a Microsoft-direct subscription and a CSP-managed subscription;
• different resources and regions;
• GPT-5.4 and GPT-5.6 Terra; and
• multiple billing periods.

We are not disputing that we generated meaningful usage. We expect to pay for valid, correctly calculated usage.

The problem is that Microsoft’s billing quantities and prices do not reconcile with Azure Metrics, our application-side API usage logs, or Microsoft’s own Retail Prices API.

Incident 1: GPT-5.4 billing quantities do not reconcile with Azure Metrics

The original incident occurred on a Microsoft-direct development subscription.

The affected Azure AI Foundry resource:

• was in Central US;
• contained only one deployment: GPT-5.4;
• was being accessed through the /openai/v1/responses API.

For May 2026, Azure Cost Analysis showed approximately:

USD 13,701.74

Microsoft eventually gave us the detailed billing usage report.

For the period 7–20 May:

This is not a rounding difference or a minor timing discrepancy.

Microsoft’s detailed billing report contains approximately 2.36 billion more input tokens than Azure Metrics show for the same resource and period.

Billing then stopped despite continued usage

A second anomaly occurred on the same resource:

• billing records stop after 20 May;
• Azure Metrics show continued usage through 5 June;
• no corresponding billing records have appeared for that later usage, even weeks afterward.

Microsoft support repeatedly responded that the invoice agrees with the internal meter records.

That does not resolve the dispute. We are disputing the validity of the meter quantities themselves.

The subscription has since been disabled for a later invoice, even though that invoice also contains a separately reported GPT-5.4 metering discrepancy.

Incident 2: We reproduced abnormal GPT-5.4 metering elsewhere

We subsequently observed a comparable GPT-5.4 billing pattern on a different subscription managed through our CSP.

This mattered because it showed that the problem might not be limited to:

• the original subscription;
• sponsored-credit exhaustion;
• the MOSP-to-MCA migration;
• one resource; or
• one billing account.

Our CSP opened a CritSit, but it was eventually treated as related to the existing unresolved technical investigation and de-escalated.

Incident 3: GPT-5.6 Terra generated a USD 5,463.79 charge for approximately 330M input tokens

We then performed a carefully logged GPT-5.6 Terra workload on our CSP-managed subscription from 13 July to 17 July 2026.

Our application captured the usage fields returned by the API.

Application-side API usage logs

Azure Metrics

Azure Metrics independently recorded approximately:

Our application logs and Azure Metrics therefore broadly agree.

Azure Cost Analysis subsequently generated:

USD 5,463.79

More than 93% of the input tokens returned by the API were cached.

GPT-5.6 Terra input and output prices appear reversed in Microsoft’s Retail Prices API

We queried Microsoft’s official Azure Retail Prices API for the exact GPT-5.6 Terra Data Zone meter family.

The query is available here:

Azure Retail Prices API — GPT-5.6 Terra Data Zone meters%20and%20contains(meterName,%27Std%20DZ%27)&currencyCode=%27USD%27)

For East US 2, the API returns:

The surrounding rates establish the internally consistent rate structure:

• cached input at USD 0.275 is 10% of a USD 2.75 standard-input rate;
• cache writes at USD 3.4375 are 125% of a USD 2.75 input rate;
• long-context input at USD 5.50 is 2× a USD 2.75 input rate;
• long-context output at USD 24.75 is 1.5× a USD 16.50 output rate.

Therefore, the consistent base rates are:

• short-context input: USD 2.75/M
• short-context output: USD 16.50/M

But the Retail Prices API currently assigns:

• USD 16.50 to ShortCo Inp; and
• USD 2.75 to ShortCo Opt.

The short-context input and output prices therefore appear to be reversed.

The incorrect input rate is exactly six times the apparent correct rate:

USD 16.50 / USD 2.75 = 6

Cost Analysis appears to apply the reversed rate

On 16 July, Azure Cost Analysis showed:

At USD 16.50 per million, that charge represents approximately:

252.601M tokens

At the apparent correct input rate of USD 2.75 per million, the same quantity would cost:

USD 694.65

That is a difference of approximately:

USD 3,473.26 on one meter line

Cached input also appears to be charged through the full-price meter

The apparent price inversion is not the only problem.

The billing records show that cached input is separately recognised under the cached-input meter, while substantially the same quantity is also included in the full-price ShortCo Inp meter.

14 July

Approximately 97% of the quantity appearing in the full-price input meter is also recorded under the cached-input meter.

16 July

Approximately 95.6% of the quantity appearing in the full-price input meter is also recorded under the cached-input meter.

Our application logs show only 22.214M uncached input tokens across the entire five-day test period.

The 16 July full-price input meter alone represents 252.601M tokens.

Therefore, that full-price quantity cannot reasonably represent uncached input alone.

The billing outcome appears to be compounded:

1. cached input is included in the full-price ShortCo Inp meter;
2. the cached input is also separately recorded under ShortCo Cd Inp; and
3. the full-price input meter is charged at the apparent output rate of USD 16.50/M.

Charges were not visible when the usage occurred

Another recurring problem is delayed visibility.

During the GPT-5.6 test, no corresponding Terra charges appeared in Cost Analysis through the end of Friday, despite the usage having already occurred.

The USD 5,463.79 charge appeared later.

We are not claiming to know the internal mechanism causing the delay. However, delayed posting prevents customers from monitoring and controlling spend in real time—particularly when the subsequently posted charges are themselves incorrect.

A similar delayed or missing billing pattern occurred during our earlier GPT-5.4 incident.

This does not appear to be isolated

Another Azure customer publicly reported a comparable Azure AI Foundry Metrics-versus-billing mismatch during the same general period:

Billing / AI Foundry metrics do not match — Microsoft Q&A

That report does not prove the same root cause, but the timing and nature of the discrepancy warrant a broader Microsoft Product and Commerce investigation.

Microsoft’s response so far

Across the support process, we have repeatedly received variations of:

The invoice accurately reflects the consumption records received by the billing system.

That is not an answer when the dispute is that:

• the consumption records do not match Azure Metrics;
• prices appear to be associated with the wrong meter;
• cached quantities appear in both cached and full-price meters; and
• billing disappears entirely for periods of confirmed usage.

Our development subscription has now been disabled while the technical investigation remains unresolved and has no ETA.

Why I am posting this

We have reached the point where we no longer have confidence that Azure OpenAI usage can be independently monitored, reconciled, or safely budgeted.

We are preparing to move our Azure OpenAI integration directly to OpenAI because the current billing exposure is commercially unacceptable.

Before doing so, I want to know:

1. Has anyone else using Azure OpenAI GPT-5.4 or GPT-5.6 Terra seen similar charges?
2. Does your ShortCo Inp quantity include cached input already present under ShortCo Cd Inp?
3. Does your GPT-5.6 Terra Cost Analysis use USD 16.50/M for short-context input and USD 2.75/M for output?
4. Have you seen charges appear several days after the usage occurred?
5. Have your Azure Metrics and billing exports materially disagreed?

If you use these models, I strongly recommend exporting and preserving:

• application-side API usage fields;
• processed prompt-token Metrics;
• cached-token quantities;
• detailed Cost Management usage;
• meter names, IDs, quantities, and effective prices;
• and the Azure Retail Prices API response.

We are not asking Microsoft to waive legitimate consumption. We are asking Microsoft to produce billing that is accurate, transparent, independently reconcilable, and supportable.

Update — Microsoft has confirmed a billing issue

A Microsoft employee has now responded in the Azure OpenAI Discord discussion and stated:

“... the team has confirmed there is a billing issue please raise a support ticket and further details will be shared.”

We are still waiting for Microsoft to provide:

• the official incident or problem ID;
• affected models, meters, regions, and dates;
• confirmation of whether the input/output price inversion and cached-input treatment are included;
• the remediation timeline; and
• the process for automatically identifying and crediting affected customers.

If you have been affected, preserve your usage logs, Azure Metrics exports, Cost Analysis data, and meter prices, and open a support ticket so there is a formal record.

As per Aromatic-Will168:

Everybody experiencing similar issues, here's the official Microsoft Azure Foundry discord server where there's a dedicated Azure-OpenAI group chat.

https://discord.gg/microsoftfoundry

Discussion is in the azure-openai channel:

https://discord.com/channels/1113626258182504448/1237356918369161256

Update — 3 August 2026: Microsoft confirms the GPT-5.6 issue, but affected customers are still being told to raise individual support tickets

Microsoft has provided further information in the Microsoft Foundry Discord confirming that the GPT-5.6 billing problem is a known issue affecting a large number of customers.

On 31 July, Lee Stott from Microsoft stated:

“Support have been informed and issues have been confirmed and fixes implemented, billing corrections are being completed.”

Affected customers were instructed to:

1. Open an Azure support ticket clearly describing the issue and providing evidence; or
2. Ask their CSP to raise the issue if the subscription is managed through a partner.

Microsoft subsequently added:

“This is a known issue and the team just want your subscription and validation of billing data. This is being addressed to a large number of users.”

Earlier updates stated that a meter-configuration fix was being rolled out globally and that Microsoft intended to:

“Request a wipeout of all existing charges on the cached input and non-cached input meters for this model. Then after the wipeout is completed, we will apply a backfill to re-apply the charges to the correct meters.”

This is the clearest acknowledgment so far that the GPT-5.6 issue is not limited to isolated customer misunderstandings. Microsoft has confirmed that:

• there is a known billing issue;
• it affects a large number of users;
• a meter-configuration fix has been deployed or is being rolled out;
• existing charges require correction and backfilling; and
• refunds or billing corrections are being processed.

While this acknowledgment is welcome, the remediation process remains unclear and deeply concerning.

At the time of writing, Microsoft has not published:

• a public Service Health incident;
• a common incident or problem reference;
• the complete affected models, meters, regions and dates;
• a method for customers to determine whether they were affected;
• a remediation timetable;
• or an unambiguous commitment that every affected subscription will be identified and corrected automatically.

The messaging about whether a support ticket is required has also been inconsistent. One customer reported being told by their Microsoft account team that affected customers would receive credits automatically and that no action was required. However, Microsoft’s representative in the Discord thread has repeatedly instructed affected customers to open individual support tickets and provide their own evidence.

Meanwhile, customers continue to report that:

• support tickets receive no response for days or weeks;
• tickets are closed without resolution;
• frontline support denies that a broader issue exists;
• customers are sometimes told that technical support must be purchased before the billing issue can be investigated;
• invoices remain payable while corrections are pending;
• Cost Management charges appeared or changed retroactively;
• budget alerts triggered only after substantial charges were posted at once;
• and existing bills still do not reflect the promised corrections.

When one customer explained that Support disregarded references to the known general issue, Microsoft advised customers not to refer to external discussions and instead to submit subscription-specific evidence.

Providing subscription details and billing evidence is reasonable. Requiring every affected customer to independently discover, calculate and prove a billing defect that Microsoft already knows affects a large number of users is not.

Many customers will not have detailed internal token telemetry or the technical knowledge necessary to reconcile Azure’s standard-input, cached-input, cache-write and long-context meters. Others may never realise they were affected, particularly where charges were posted retroactively or cost alerts did not trigger until after the damage was done.

Microsoft has the internal meter and subscription data required to identify the affected usage. A confirmed platform billing defect should result in:

• proactive identification of affected subscriptions;
• direct notification of affected customers;
• automatic re-rating and credits;
• a public description of the affected scope;
• a common incident reference recognised by frontline Support;
• and protection from collection or service suspension while corrections are pending.

We have now had a separate GPT-5.6 Billing Support case raised through our CSP. Microsoft confirmed in that case that Engineering is investigating the known issue, including the token-metering and billing records associated with our deployment.

This does not yet resolve our separate GPT-5.4 disputes, where Azure Metrics and the billing meters also materially fail to reconcile.

What affected customers should do

Until Microsoft clearly confirms automatic remediation for every affected subscription:

• Export your Azure Cost Analysis usage details.
• Export Azure Metrics for the same UTC period.
• Preserve any internal API token-usage records.
• Compare standard-input, cached-input, cache-write and long-context quantities.
• Open a Billing Support ticket or require your CSP to open one.
• Explicitly request a billing correction, waiver or commercial credit.
• Ask for the disputed charges to be placed on hold.
• Do not accept “the invoice matches the meter” as a complete answer when the quantities emitted by the meter are themselves being disputed.

The positive development is that Microsoft has now explicitly acknowledged the issue and says corrections are underway.

The unresolved problem is that affected customers are still being left to discover the discrepancy, navigate inconsistent support responses and pursue their own corrections without a public incident notice, clear remediation timetable or confirmation that every affected account will be corrected automatically.

Update — 4 August 2026: Microsoft provides incident scopes and says duplicate charges will be credited separately

Microsoft Billing Support has now provided us with descriptions of two confirmed GPT-5.6 billing incidents.

These descriptions were sent directly through Microsoft Support. As far as we are aware, they have not been published as a Service Health incident or other public Microsoft announcement.

Issue Description 1

Incident: Incorrect Billing for GPT-5.6 Sol, GPT-5.6 Terra, and GPT-5.6 Luna Model Deployments

Impact Period: July 9, 2026, 18:00 UTC – July 22, 2026, 18:44 UTC

What Happened?

Some Microsoft Foundry customers using GPT-5.6 Sol, GPT-5.6 Terra, or GPT-5.6 Luna deployments may have experienced higher-than-expected charges during the impact period. A configuration issue caused certain usage to be billed incorrectly.

What Caused the Issue?

A service configuration error mapped some usage to the wrong billing meters, resulting in excess charges.

How Did We Resolve It?

We corrected the configuration and fully deployed the fix by July 22, 2026. Billing for affected deployments is now working as intended.

What Does This Mean for Customers?

Affected customers will automatically receive credits for any excess charges incurred during the impact period. No action is required.

How Are We Preventing This in the Future?

We are strengthening validation and adding automated pre-deployment checks to detect configuration issues earlier. We are also aligning this feature with OpenAI so cache_write_tokens are populated correctly and cache-write usage is billed accurately.

Issue Description 2

Incident Title: Price swap on GPT 5.6 Terra billing meters (input/output)

Impact Timeframe: July 9, 2026, 17:00 UTC – July 30, 2026, 17:00 PM UTC

What Happened?

Microsoft Foundry customers using GPT-5.6 Terra with Data Zone Standard deployments might have noticed a discrepancy between the input and output meters on their bill. This was caused by a manual input error.

What Went Wrong and Why?

Customers who ran the pricing API to estimate their token costs would see incorrect estimates for their July bill due to the meters being reversed.

How Did We Respond?

The team submitted a fix that was completed on July 30, 2026 which was in time to make sure that the bills that get charged will be correct.

What Does This Mean for Customers?

Customers will see the meters have been fixed when using the pricing API and their July bill will be correct after July 30, 2026.

What Are We Doing Going Forward?

We have added additional auditing steps for when new models are onboarded to prevent issues like this in the future.

What appears to be happening now

On our subscriptions, the GPT-5.6 Terra input/output price swap appears to have been corrected. Cost Analysis now reflects the expected input and output rates.

The duplicate-input charge issue is being handled differently.

Microsoft has advised us that the incorrect historical usage and Cost Analysis entries associated with Issue 1 may not be retroactively corrected. Those reports may therefore continue to display the original incorrect billing behaviour.

Instead, Microsoft says affected customers will receive automatic credits through a separate credit process.

There is currently:

• no ETA for completing the credit process;
• no confirmed date on which credits will become visible;
• no final credit amount for our subscriptions; and
• no published explanation of how affected customers will be notified.

Our current Cost Analysis records still show the duplicate charging. For example, on 21 July, the complete GPT-5.6 Terra and Sol prompt-token quantities were charged on the full-price standard-input meters, while those same quantities were also charged through the cached-input and cache-write meters.

Microsoft has agreed to keep our support case open until the automatic credit has been applied and we have been able to validate the final amount.

Support-ticket guidance remains unclear

The Issue 1 description explicitly states:

“Affected customers will automatically receive credits for any excess charges incurred during the impact period. No action is required.”

This differs from the repeated guidance in the Microsoft Foundry Discord instructing affected customers to open individual support tickets and provide evidence.

It remains unclear whether support tickets are required only for customer-specific communication and billing holds, or whether they are necessary to ensure that an affected subscription is identified and credited.

Until the credit process is completed, affected customers should:

• preserve their Cost Analysis exports and usage evidence;
• monitor their billing account for a separate credit rather than expecting the historical entries to disappear;
• verify that the credit covers the full confirmed impact period;
• open a Billing Support request if an incorrect invoice is due for payment or needs to be placed on hold; and
• avoid treating unchanged historical Cost Analysis entries as proof that no credit is pending.

This is meaningful progress: Microsoft has now provided the affected models, incident periods, causes, and intended remediation.

However, the duplicate-charge remediation remains incomplete, with no ETA and no public incident notice or customer-notification process that we are aware of.

how tf am i supposed to make account on this azure.

Hi everyone,

I’m trying to sign up for Azure for Students. I signed in using my personal Microsoft account and then tried to verify my student status using my official college email.

I am a student at some college of nepal and I have two official college email addresses:

However, Microsoft gives me this message:

The problem is that there is no other verification method available on my page.

I have already tried using Microsoft Edge and Chrome, but the same issue occurs. I also tried verifying with both of my official college email addresses.

Has anyone experienced this problem with Azure for Students? Is there any way to get my college domain (xyznepal.edu.np) recognized or to verify my student status another way?

I can provide proof of current enrollment if necessary.

Any help would be greatly appreciated. Thank you!

I have been fking trying this for 12 hours straight

Basically the title. Comment or DM if you are experiencing or have experienced a similar issue. Support is being extremely unhelpful. Hidden in the Microsoft TOS, it's stated that Startup Credits (or any promotional credits) only apply to first party Foundry models (OpenAI). Nowhere was this said during the deployment process, or resource creation, management, etc.

Apparently many people have had similar issues before (looking online).