Enterprise Agreement indirect partners can now pull cost data from every customer enrollment programmatically, without sharing a single user password. Microsoft quietly shipped a handful of Cost Management updates in July and August 2025 that turn the Partner Admin Reader role into a service principal–compatible API credential, add ingestion‑time filtering for Azure Firewall logs, and launch a free, managed S3‑to‑Blob migration service. Together they address three persistent pain points: manual billing reconciliation, ballooning telemetry invoices, and multi‑cloud lock‑in.
The updates do not arrive with splashy keynotes. They show up in a blog post and a documentation refresh, and they reward the FinOps practitioner who already scripts exports and vets every line item. Each change delivers measurable operational savings when applied with proper governance, and each carries a small but real risk of misconfiguration that can undo the savings.
Service principal support for Partner Admin Reader gives EA indirect partners an API‑first cost pipeline
What changed
Previously, an Enterprise Agreement indirect partner who wanted to automate cost retrieval across multiple customer enrollments had to juggle interactive user accounts or static API keys. Microsoft now permits assigning the Partner Admin Reader role to an Azure Active Directory service principal, which means a CSP can authenticate once, then pull near‑real‑time billing data for every enrollment linked to its Partner Customer Number (PCN).
The role is read‑only and scoped to enrollments under the partner’s PCN. It is designed for programmatic access—the Azure portal offers no click‑path to add a service principal to this role; the assignment must be made through the Role Assignments REST API using the billing account name pcn.{PCN}. Microsoft’s documentation lists the supported roles, the required roleDefinitionId, and the API shape. The change went live in July 2025 and is available globally across all EA indirect billing accounts.
Why it matters
- Kills shared credentials: Service principals eliminate the shared human accounts that often sit in a spreadsheet or a plaintext config file. They rotate with certificates or short‑lived secrets, reducing the blast radius of a leak.
- Scales automation: A partner managing 200 customers can schedule one export pipeline instead of 200 manual sign‑ins. Cost data flows into billing platforms, anomaly detectors, and chargeback models without fragile screen‑scraping.
- Tightens governance: Because the role is assigned via Azure RBAC, partners can audit every principal, review the scope, and integrate the assignment into their existing IAM lifecycle.
- Enables real‑time FinOps: Partners can detect spending anomalies or reconcile invoices within minutes of a billing event, rather than waiting for overnight CSV dumps.
In conversations on the FinOps Foundation forums and the Microsoft Partner Community, MSPs immediately flagged this as the missing piece for production‑grade billing automation. One cloud solutions architect noted: “We’ve been asking for service principal support on Partner Admin Reader since the role appeared. It finally lets us retire the break‑glass user account we had running in an Azure Automation runbook.”
How to implement—and how to do it safely
Microsoft outlines a four‑step process:
- Register a Microsoft Entra application and create its service principal.
- Generate a GUID for the
billingRoleAssignmentName. - Call the
Role Assignments - PutREST API withbillingAccountName = pcn.{PCN}, settingproperties.principalIdto the service principal’s object ID andproperties.roleDefinitionIdto the Partner Admin Reader role ID. - Confirm a
200 OKand validate read‑only access to the intended billing scopes.
A service principal can hold only one EA role in this model, so partners must resist the temptation to reuse it for other administration tasks. The role’s read‑only nature limits damage, but a misconfigured PCN parameter could expose data to a wrong application. A structured rollout includes:
- Certificate‑based authentication with key rotation every 90 days.
- Conditional Access policies that restrict the service principal to a known IP range or compliant device state.
- A central register mapping PCN to customer enrollment, reviewed quarterly.
- Auditing of
Microsoft.Billing/billingAccounts/readAPI calls through Azure Monitor or Sentinel.
Organizations that follow these steps turn Partner Admin Reader into a transparent, low‑friction data feed. Those that skip governance risk an over‑privileged automation account, though the role’s read‑only constraint provides a hard stop.
Azure Firewall ingestion‑time transformation trims logging bills without sacrificing security
The feature
Network telemetry remains one of the fastest‑growing line items in many cloud bills. Azure Firewall now supports ingestion‑time transformation for Log Analytics—essentially, server‑side rules that filter or reshape data before it lands in the workspace. Microsoft made the capability generally available in July 2025, calling it “cost‑efficient logging.”
The transformation is applied at the pipeline, so dropped fields never incur ingestion or retention charges. Security teams can keep every alert‑related field while discarding verbose debug entries that add little analytical value.
Real‑world impact
In a high‑traffic environment processing 500 GB of firewall logs per day, retaining only threat‑relevant fields can cut ingestion by 30–50 percent. At $2.30 per GB ingested in Log Analytics (Pay‑As‑You‑Go), that reduction saves roughly $345–$575 daily. Annualized, even a conservative 20 percent reduction returns six‑figure savings for a large enterprise.
Network engineers in the TechCommunity thread that accompanied the announcement shared early results. One contributor reported cutting a $14,000 monthly bill to $9,200 after excluding destinationServiceName and deviceVendor that were already tagged in other tables. Another cautioned that over‑filtering can strip the forensic context needed for incident response—a concern echoed by Microsoft’s own guidance, which recommends retaining a short, unfiltered copy for investigation.
Implementation checklist
- Profile your current firewall telemetry: identify high‑volume tables and fields that contain redundant or low‑value data.
- Define transformation KQL queries that
projectonly the columns you need andwhereclauses that drop noise while keeping security‑relevant records. - Test the transformation on a secondary workspace or a cloned pipeline for one week.
- Enable the ingestion‑time rule and keep an unfiltered data export for 30 days to allow forensic drills.
- Monitor cost graphs for two billing cycles to verify the reduction and watch for any increase in query time due to smaller datasets.
Where caution is needed
A transformation that looks innocent—removing protocol or direction because “we don’t need it”—can blind a SOC analyst when they need to reconstruct an attack path. The decision to filter should be documented, signed off by both cost and security owners, and reversible within minutes. Microsoft’s documentation (updated in the same period) includes a walkthrough for building transformation workspaces, but it stops short of prescribing what to keep. That judgement call falls squarely on the customer.
Azure Storage Mover: free S3‑to‑Blob migration enters public preview
Moving data out of AWS can get expensive quickly, both in egress fees and third‑party migration tooling. In August 2025, Microsoft launched a public preview of cloud‑to‑cloud migration within Azure Storage Mover, offering a fully managed way to lift data from Amazon S3 into Azure Blob Storage at no additional service cost.
Storage Mover uses Azure Arc multicloud connectors to authenticate against AWS IAM and then orchestrates copy jobs. The service is intended for lift‑and‑shift scenarios, archival consolidation, or cross‑cloud analytics feeder patterns. Microsoft Learn documents the preview limits: a maximum of 10 jobs per Storage Mover resource, 500 objects per job, and a requirement to rehydrate S3 Glacier Deep Archive objects before migration.
Financial and operational arithmetic
A 100 TB migration using a popular third‑party tool at $0.02/GB adds $2,000 in license fees alone, not counting the virtual machine compute that runs the copy agent. With Storage Mover, those fees disappear. The egress bill—still charged by AWS—remains, but the service itself costs nothing during the preview.
For an enterprise consolidating three mid‑sized data lakes, the immediate benefit is straightforward: fewer vendor contracts and a migration pipeline that lives inside Azure governance. A pilot migration of 5 TB typically completes within a few hours, depending on object size distribution and source‑bucket geography.
Pilot playbook and limitations
- Start with a non‑critical bucket under 500 objects to measure throughput and spot any object‑level permission mismatches.
- Rehydrate archived objects 48 hours before the migration window; MS guidance says Deep Archive retrieval can take up to 12 hours.
- Validate blob integrity by comparing MD5 checksums after transfer.
- Plan for public preview constraints: the service currently lacks private endpoint support, so traffic may traverse public internet unless you configure a VPN. Large workloads may hit the job cap and require batching.
Microsoft frames the preview as a “no‑cost migration path” but advises customers to read the fine print. The service will eventually follow a usage‑based pricing model, and preview features may change before GA. Still, for teams already planning an S3‑to‑Azure move, it shaves months off the tooling evaluation phase.
Azure Pricing Calculator tip and refreshed learning resources
Auxiliary but practical: clicking the collapse button on a Pricing Calculator estimate hides the detailed configuration rows, showing only the summary lines. For a proposal containing 40 services, that action turns a scroll‑heavy spreadsheet into a single‑page executive view. Non‑technical stakeholders can compare cost totals without wading through SKU minutiae.
Microsoft also published short videos covering Cost Management access control, using Azure Copilot to query costs, and setting up cost allocation rules and tags. The documentation team refreshed pages on paying MCA bills—now with India‑specific payment methods—reservation management, and savings‑plan chargebacks. The change‑log is open on GitHub, welcoming community pull requests.
What these updates mean for FinOps teams, MSPs, and IT leaders
These releases clarify a market signal: Microsoft wants partners and enterprises to stop treating cost management as a monthly dashboard ritual and start wiring it into automated operations. Service principal support for Partner Admin Reader transforms billing data from a compliance artifact into an API‑first asset. Ingestion‑time transformation proves that platform‑native cost controls can match third‑party log shapers. And Storage Mover offers a migration route that does not demand a new procurement cycle.
The immediate opportunities break down by role:
- Partners and MSPs: Automate invoice reconciliation across dozens of PCNs, feed a billing platform, and reduce the manual hours spent on cost reporting. One partner forum contributor estimated a two‑full‑time‑employee reduction when moving from manual exports to an API pipeline.
- Network and security teams: Lower Log Analytics bills by 20–50% without sacrificing threat visibility; keep an unfiltered buffer to satisfy forensics.
- Cloud architects and migration squads: Pilot Storage Mover on archival buckets to eliminate third‑party license costs and simplify the move from AWS.
Risks that cannot be ignored
- Service principal scope error: A typo in the PCN parameter could expose billing data to an unintended principal. IAM review must be mandatory.
- Over‑filtered logs: Removing a single field during ingestion can prevent a SOC analyst from correlating events during an investigation. Every transformation should be treated as a security configuration change.
- Storage Mover preview gaps: No private endpoint, job limits, and enforced rehydration create operational friction for large‑scale migrations. Teams should maintain fallback plans.
Measuring success: KPIs that matter
To justify the engineering time invested, track concrete metrics:
| KPI | Target | Measurement method |
|---|---|---|
| Log Analytics ingestion reduction | ≥20% within first month | Workspace data ingestion graph |
| Automated billing accounts | All PCN‑linked enrollments via service principal | API audit log |
| Mean time to detect spending anomaly | ≤1 hour post‑ingestion | FinOps anomaly detector |
| S3 migration cost per TB | <$0.10/TB (excluding AWS egress) | Storage Mover job report |
These numbers turn anecdotal “this helps” into a business case for broader automation.
What’s next for Azure Cost Management
Microsoft’s roadmap, inferred from the blog’s closing and community feedback, points toward three priorities:
- Deeper partner APIs: Expect new roles or fine‑grained OAuth scopes that allow CSPs to pull not just cost totals but also tag‑level optimization recommendations.
- Instrumentation‑driven controls: Ingestion‑time filtering will likely expand to other resource types—Azure Monitor metrics, NSG logs—providing a unified cost‑control layer before data hits the analytics engine.
- Managed migration and Fabric integration: Storage Mover will add private endpoints and increased job limits, while tying into Microsoft Fabric to run analytics directly on migrated data without re‑copy.
Teams can prepare now: set up an automation sandbox to test service principal assignments, pilot ingestion‑time rules on a staging workspace, and run a small S3 migration to map throughput. These proactive steps ensure that when the features move from preview to production, the organization is already saving money and operating with less manual overhead.
The July–August 2025 Cost Management updates do not rewrite the rulebook, but they tighten the operational screws for anyone tasked with cloud financial governance. Partner billing automation shifts from brittle accounts to well‑governed service principals. Firewall logging moves from “ingest everything and pray” to surgical, cost‑conscious data collection. And cross‑cloud migration starts to look less like a project and more like an Azure‑native service call.