cost management
107 TopicsYour guide to FinOps for AI at Microsoft Ignite 2026
AI has moved from pilots to production, and the questions have changed with it. It is no longer enough to know what AI costs. Leaders want to know whether spend is predictable, who is driving it, and which investments are delivering real business value. That is the job of FinOps for AI: bringing finance, IT, engineering and business teams together to plan, control and optimize AI spend and value. At Microsoft Ignite, November 17–20, 2026, in San Francisco and online, FinOps for AI shows up across the agenda, from keynotes to breakouts, demos, lightning talks, table talks and hands-on labs. Whether you manage Microsoft 365 Copilot and agents, build on Microsoft Foundry and GitHub, or own the AI budget, there is a session for you. We've gathered them all in one place so you can plan your week. Innovation sessions Start with the big picture. These sessions will showcase how cost and value fit into Microsoft's broader AI vision, and what's new across the stack. INV642: Observability at every layer of the stack As AI and agents scale, visibility, trust, and security become business imperatives. Join Charles Lamanna, Executive Vice President, Copilot, Agents, and Platform, and Hayete Gallot, Executive Vice President, Microsoft Security, to explore how observability at every layer of the stack helps organizations understand where AI is being used, how agents are operating, what risks are emerging, and whether investments are delivering results. See how organizations can turn visibility into action to scale AI with confidence. Session page: https://ignite.microsoft.com/en-US/sessions/INV642 INV641: Harnessing Your IQ with a continuously improving agent platform Join Arun Ulag and Jay Parikh to discover how Microsoft IQ helps your organization activate, protect, and build on the knowledge that makes it unique. Learn how to keep improving as models evolve, with model choice and control intact. Explore how your data and expertise become AI that understands your business, so work runs faster, more accurately, and at lower cost. Session page: https://ignite.microsoft.com/en-US/sessions/INV641 Breakout sessions Breakouts go deeper, with technical content and live demos. We've grouped them by topics and scopes. Understand economics and value BRK537: From AI Ambition to Value at Scale As AI moves from experimentation into everyday business operations, growing usage alone does not tell leaders whether an investment is working. Learn how organizations can connect AI consumption to measurable business value, establish the visibility and accountability needed to manage it, and determine whether the economics continue to hold as adoption grows. Leave with a practical approach for deciding where AI has earned the right to scale, where to adjust, and where continued investment may not be justified. Session page: https://ignite.microsoft.com/en-US/sessions/BRK537 BRK308: How Microsoft IQ shapes the cost of enterprise AI Enterprise AI does not have one cost model. It has three: people, consumption, and capacity. Through a retail AI scenario and a live cost estimation demo, this session shows how Work IQ, Foundry IQ, Fabric IQ, and Web IQ create different cost shapes, and how to optimize each one for scale, value, and control. Session page: https://ignite.microsoft.com/en-US/sessions/BRK308 BRK260: The next evolution of AI FinOps: From cost to value Visibility into AI spend is just the beginning. Learn how leading organizations optimize investments across Microsoft 365 Copilot, Copilot Studio, and GitHub Copilot to maximize business impact. Discover how new capabilities, help you manage costs, prove value, and scale the AI initiatives that deliver the biggest results. Session page: https://ignite.microsoft.com/en-US/sessions/BRK260 Establish governance and guardrails BRK263: Master AI spend management with Agent 365: Govern your AI budget See the tools IT needs to govern, control, and optimize AI spend at scale. Join this deep dive into Agent 365 and Microsoft 365 Admin Center capabilities for AI FinOps. Learn how to establish guardrails with policies, monitor consumption across AI vendors, measure value, and confidently scale AI across your organization. This is the essential session for IT to understand the latest innovations in AI cost management and governance. Session page: https://ignite.microsoft.com/en-US/sessions/BRK263 BRK262: Scale agents, not risk: Governance and FinOps for the enterprise As agents move from experimentation to enterprise-wide deployment, IT needs a new approach to governance and FinOps. Learn how to build a scalable operating model across agent inventory, lifecycle, security, cost management, and optimization, giving teams the freedom to innovate while maintaining the visibility, guardrails, and financial discipline IT needs. Session page: https://ignite.microsoft.com/en-US/sessions/BRK262 BRK290: Humans, agents, and a game plan: AI governance with GitHub Enterprise Give developers, knowledge workers, and AI agents room to innovate with enterprise control. Follow an admin journey in GitHub Enterprise and Copilot: set model policies and managed settings, customize for teams, onboard fast, and manage access and spend. Review config changes via pull requests and use agent activity data to assess governance. See the roadmap linking policy, usage, and cost. Leave with a plan to set guardrails, measure impact, and grow AI adoption without friction. Session page: https://ignite.microsoft.com/en-US/sessions/BRK290 Optimize spend and technical choices BRK266: Maximize your Copilot Investment: Scale with flexibility and control AI investments are growing, but are organizations getting the most value from them? Learn not only how to gain visibility and control over AI spend, but also how to measure business value and continuously optimize. Explore new capabilities designed to help organizations manage spend against budget, allocate resources effectively, and maximize the value of their AI investments. Session page: https://ignite.microsoft.com/en-US/sessions/BRK266 BRK271: Manage GitHub Copilot spending and understand team adoption Make informed decisions about your Copilot investment. Explore how model choices, agent workflows, and GitHub Actions contribute to development costs, then use billing reports, budgets, and alerts to manage spending. Learn to interpret adoption and engagement trends, spot underused capabilities, and target support where teams need it. IT admins and engineering leaders will leave with practical steps to manage costs and help developers use Copilot effectively. Session page: https://ignite.microsoft.com/en-US/sessions/BRK271 BRK216: Multi-model AI in Copilot: Performance and value with built-in trust No single AI model is best for every task. As AI advances, organizations need access to the latest models without adding complexity for users, cost uncertainty for leaders, or administrative risk for administrators. Join us to see how Microsoft Copilot provides one governed front door to multi-model AI, with Microsoft evaluation and integration, intelligent routing with Auto, and cost management tools to you optimize AI value while maintaining security, compliance, and control. Session page: https://ignite.microsoft.com/en-US/sessions/BRK216 BRK280: Designing an agent harness that orchestrates models Choosing a model is becoming less important than deciding how and when models are used. Explore how routing can match models to different tasks, constraints, and stages of development. We’ll examine the signals and tradeoffs that guide these decisions, and approaches such as HydraFusion that coordinate models as a portfolio. Leave with a framework for building adaptable agent systems across quality, latency, cost, and control. Session page: https://ignite.microsoft.com/en-US/sessions/BRK280 BRK249: From traces to better agents: The Foundry improvement loop Building an agent is the start. Improving it in production is the real work. See how Microsoft Foundry connects traces, evaluations, and optimization to help teams find high-impact issues, test improvements, and re-measure results. Learn a repeatable loop to improve quality, manage cost, and ship better agents while developers stay in control. Session page: https://ignite.microsoft.com/en-US/sessions/BRK249 Session for partners BRK482: FinOps for AI: Partner Playbook for Building AI Solutions and Services AI is creating unprecedented opportunities for partners, but success requires more than innovative solutions. It requires managing the economics behind AI. In this session, Microsoft leaders and industry experts share a practical FinOps framework for AI to help partners anticipate and govern costs, optimize token consumption, and build repeatable, profitable services. Hear real-world partner examples and leave with actionable guidance to turn AI cost management into a competitive advantage. Session page: https://ignite.microsoft.com/en-US/sessions/BRK482 Theater sessions, lightning talks, table talks and labs Short on time or want to get hands-on? These shorter formats include product demos, focused talks, small-group discussions and labs. Labs require an RSVP, so reserve your seat early. Code Session Format Session page PREB23 Optimize your Copilot Investment Pre-day session https://ignite.microsoft.com/en-US/sessions/PREB23 THR865 Navigating AI spend across your organization Theater https://ignite.microsoft.com/en-US/sessions/THR865 THR895 AI for FinOps, continuous optimization for every workload Theater https://ignite.microsoft.com/en-US/sessions/THR895 LTG1170 AI That Pays Off: New Ways to Measure Value and Optimize Spend Lightning talk https://ignite.microsoft.com/en-US/sessions/LTG1170 LTG1165 Preparing for usage-based billing Lightning talk https://ignite.microsoft.com/en-US/sessions/LTG1165 LTG1193 A practical guide to FinOps for GitHub Copilot Lightning talk https://ignite.microsoft.com/en-US/sessions/LTG1193 LTG1342 FinOps for AI: Unlocking value across the AI lifecycle Lightning talk https://ignite.microsoft.com/en-US/sessions/LTG1342 LTG1206 Agent FinOps: Designing agents that scale responsibly Lightning talk https://ignite.microsoft.com/en-US/sessions/LTG1206 TT1669 Agent ROI, optimization and FinOps Table talk https://ignite.microsoft.com/en-US/sessions/TT1669 LAB660 Configuring, monitoring, and managing AI spend with Agent 365 Hands-on lab https://ignite.microsoft.com/en-US/sessions/LAB660 LTG1201 Optimizing AI decisions with the model router in Foundry Models Lightning talk https://ignite.microsoft.com/en-US/sessions/LTG1201 Plan your FinOps for AI week Every session above maps to the same journey: plan AI spend so it's predictable, control it so costs stay visible and accountable, and optimize it to get more value from every AI investment. Add the sessions that match your role to your Ignite schedule and stop by to talk with our team. We look forward to seeing you at Ignite. Next steps Join us at Microsoft Ignite, November 17–20 in San Francisco to see it in action and go hands-on with the team that built it. Catch us on 'Live at Microsoft Ignite' which will be broadcasted on Ignite.com, starting Tuesday, November 17th, through Thursday, November 19th.730Views0likes1CommentYou Get One Exchange Left: Rethinking Azure Commitments Before February 2027
Azure gives you two main ways to pay less by committing up front. A reservation gets you the deepest discount, but you are locking in a specific SKU in a specific region. A savings plan gives up some of that discount in exchange for freedom: you are only committing to spend a certain amount per hour on compute and database services, and it does not care which region you spend it in. Until now, a reservation could move with you. If your infrastructure or database environment changed, or a workload had to move to a new region, you exchanged the reservation for one that matched where things had landed. That flexibility is why teams could commit early and adjust as the environment evolved. That flexibility is changing. From February 1, 2027, you can no longer exchange a reservation for any service that a savings plan covers. Neither product is changing. What is changing is how much room you have to adjust a commitment after your environment shifts, which means the order you make these decisions in matters a lot more than it used to. What's changing Here is what is affected as of the announcement. Compute: Azure Virtual Machines (including swapping between non-premium and premium storage), Azure Dedicated Host, and Azure App Service. Databases: Azure Database for PostgreSQL, Azure Database for MySQL, Azure DocumentDB, Azure Cosmos DB, Azure SQL Database, and Azure SQL Managed Instance. That list will grow. As savings plans start covering more services, reservations for those services automatically fall under the same rule. Products that are being retired are excluded, and so are clouds where savings plans are not offered. Two details really matter. If you own a reservation for one of these services and you bought it before February 1, 2027, you get one final exchange after that date. Just one. Buy on or after that date and you get none. Full details, including the FAQ, are in the official announcement: "Reservation exchanges for Azure services covered by savings plans end starting Feb. 1, 2027". What's staying exactly the same This is worth spelling out, because it is easy to read more into the announcement than is actually there. All of this still works. VM instance size flexibility is untouched. Cancelling a reservation is untouched. Trading a reservation in for a savings plan is still there. Buying and renewing reservations is still available, and still the right call for steady workloads. Reservations are not going anywhere. The only thing changing is your ability to swap one for another when your environment moves underneath it. The part most teams get backwards You cannot think clearly about timing without this, and it is the thing people most often have wrong: reservations and savings plans are not a choice between two options. You can use both. They stack, and they apply in a set order every hour. Reservations go first, on anything they match. The savings plan picks up what is left, up to your hourly commitment. Whatever is still uncovered bills at pay-as-you-go, using your negotiated rate. Here is one hour, made concrete. Say you have reservations covering $10 an hour of matching VMs, plus a savings plan committed at $5 an hour. In an hour where you use $18 of eligible compute, $10 gets reservation pricing, $5 gets savings plan pricing, and the last $3 bills pay-as-you-go. The savings plan did not fight the reservation for that spend. It caught the overflow. Two things people assume that are not true. The terms do not have to match: a three-year reservation and a one-year savings plan work fine side by side. And you do not tag or assign anything. Once you buy a savings plan, it looks across whatever scope you bought it at and applies itself wherever it finds a fit. That flexibility is the whole point. A savings plan ties you to an hourly amount, not to a SKU or a region. A reservation ties you to both. Before February 2027 that difference was mostly about how big a discount you got. After, it also decides how easily your commitment can follow the environment as it changes. Three rules for buying from here on Lean on savings plans while things are still moving Before you commit to anything, ask what is going to change in the next ninety days. If a team is midway through centralizing their networking and is about to delete every per-subscription VPN gateway, any recommendation you generate this week will be wrong next month. Azure Advisor rescans every day and rewrites its recommendations as your environment shifts. If a workload is mid-migration, mid-consolidation, or mid-anything, a savings plan gets you a similar discount without locking you in. Move it to a reservation once it is genuinely settled. A domain controller running around the clock in one region is the textbook reservation. Something still being actively built is not. Start short, and know why that matters now Three years gets you the best rate. Starting with one year and extending as you get more confident was always the sensible approach. Now it carries more weight, because a reservation can no longer be exchanged when your environment moves. If one stops matching, your options are to cancel it under the existing policy, or trade it in for a savings plan. That is the whole list. Buy at the business-unit level, not the tenant level Buy everything centrally and you take away each team's ability to pick what suits their own workloads. Then, when a team wants more coverage than the central purchase gives them, they go and buy their own at subscription level, and now you are paying for the same thing twice. Buying per business unit also makes chargeback far easier, because the discount ends up sitting where the spending happens. Clean up before you commit There is a step that comes before all of this, and it is not new advice. Azure Advisor already flags unattached disks, idle virtual network gateways, and VMs that should be resized or switched off. If you have not done that sweep, "Identify your savings potential in Azure" walks through the tools properly. What is new is what happens if you skip it. Leftover and idle resources do not just eat into your savings. They inflate the number you size your commitment against. Commit against a messy environment and you have just locked in one to three years of spend on resources that should not be running. Up to now, an exchange gave you a way to adjust that later. Cleaning up used to be good housekeeping. Once you cannot exchange out of a reservation, it is genuinely about limiting risk. The same goes for the workloads you are keeping. Switch off VMs outside business hours before you buy a reservation, not after. Reservations only pay off on workloads that run constantly, and once you have bought one you owe the money whether the VM is running or deallocated. Scaling up and never scaling back down is the same problem wearing a different hat. How to check it actually worked Your reservation and savings plan discounts show up on the invoice under amortized cost. Three columns tell the story. Pay-as-you-go price is the list price. Unit price is your negotiated discount, before reservations are applied. Effective price is what you genuinely paid once reservations and savings plans were counted. There is no neat query for this. You read it off the invoice. It is the clunkiest part of the whole process and it is the first thing your finance partner will ask about, so get it into your reporting now rather than during your first chargeback cycle. What to do in the next ninety days List every active reservation you hold for an affected service. Work out which ones no longer match the workload. Those are your candidates for that one remaining exchange. Decide deliberately where that one exchange does the most good. Clean up orphaned disks, idle gateways, over-replicated storage, and scale-ups nobody scaled back down. Re-baseline your commitment sizing against the tidied-up environment. Buy at business-unit level, leaning toward savings plans anywhere the workload is still changing. The takeaway Reservations and savings plans both still work, and both still save you real money. What changes on February 1, 2027 is that a reservation can no longer be exchanged when your environment moves, so the decision has to be right at the point you make it rather than adjusted afterwards. That puts the weight on sequence: clean up first, size the commitment against what is actually running, use savings plans while a workload is still settling, and move to a reservation once it has stopped moving. The deadline is not something to panic about. It is a good excuse to finally do the bit most cost programs skip.1.1KViews1like1CommentNow Available: Management Group–Scoped Savings Plan and Reservation Recommendations in Azure
Smarter commitments, at the scope that matters We're excited to announce that both savings plan and reservation (including P3) recommendations are now available at the management group scope in the Azure Portal and via REST API. With management group–scoped recommendations, you can now evaluate and act on both your savings plan and reservation opportunities across an entire organizational hierarchy in a single, unified view. If you manage cost and commitments across a multi-subscription estate, this is another way to maximize both your savings plan and reservation commitment coverage with confidence. The value proposition Management groups are how enterprises organize subscriptions to reflect their real business structure — by department, environment, geography, or line of business. Bringing savings plan and reservation recommendations to this scope delivers three key benefits: Aggregated purchasing power. Recommendations account for the combined, steady-state usage and spend across the subscriptions under a management group. For both reservations and savings plans, this surfaces commitment levels that better reflect true aggregate consumption. Governance-aligned decisions. FinOps teams and central IT can generate and review both savings plan and reservation recommendations at the exact organizational boundary where budget and commitment decisions are actually made — no more reconciling dozens of separate subscription-level recommendations. Reduced analysis overhead. A single API call or portal view returns recommendations for an entire management group, with configurable term and look-back period. Less manual aggregation, faster time to a confident purchase decision. How it works The recommendation engine analyzes your historical usage over your selected look-back window, models the optimal commitment, and projects the expected savings versus pay-as-you-go pricing — now with the management group as a first-class scope for both savings plans and reservations. In the Azure Portal: Navigate to the Savings plans or Reservations purchasing experience, then select a management group scope to view aggregated recommendations. Via the REST API: For savings plans, call the Savings Plan Recommendations endpoint with a management group scope. For reservations — including P3 — call the Reservation Recommendations endpoint with a management group scope. Get started today Explore the Benefit Recommendations and Reservation Recommendations API references to start integrating management group recommendations into your FinOps tooling today.887Views0likes2CommentsAnnouncing savings plan for databases: flexible savings for modern, evolving workloads
As organizations modernize their data platforms, database environments are constantly changing. Teams migrate between services, scale across regions, and evolve architectures to support new applications and AI driven workloads. But optimizing costs in these environments can be challenging, especially when savings options require locking into specific services, regions, or configurations. To help with these challenges, we’re introducing savings plan for databases, a new way to save on eligible database services while maintaining the flexibility needed to modernize and grow your business. Savings plan for databases helps IT, engineering, and FinOps teams reduce database costs with a simple, spend based commitment—without slowing down architectural change. New: Choose a 3-year term for longer-term planning Savings plan for databases now gives you more choice in how you plan for your database investments, with 1-year and 3-year commitment options. Both terms provide the same discounted pricing, so the choice is less about finding a different discount and more about selecting the commitment period that best aligns with your business plans, workload lifecycle, and cloud strategy. The 3-year option can be a strong fit for organizations with longer-term database migration, modernization, or optimization initiatives. It provides a longer planning horizon for organizations that want predictable savings aligned to a multi-year database roadmap, while reducing the need to make a new commitment decision each year. If your database needs are changing more quickly or you prefer to reassess your commitments annually, the 1-year option may be a better fit. Choose the commitment term that matches your planning horizon: 1 year: Greater flexibility to reassess your database strategy and commitments annually. 3 years: Greater continuity for longer-term database strategies, migration and modernization programs, and multi-year planning. Whichever term you choose, savings plan for databases continues to give you the flexibility to save as your eligible database usage evolves. What is savings plan for databases? Savings plan for databases is a spend based pricing model that enables customers to save on eligible database services by committing to a fixed hourly spend for one year. In return, customers receive lower prices—up to 35% compared to pay-as-you go pricing on select services*. Instead of committing to a specific database service, region, or configuration, customers commit to an hourly dollar amount (for example, $5 per hour). The plan automatically applies savings to eligible database usage each hour, prioritizing the usage that delivers the greatest savings first—across services and regions—until the hourly commitment is met. Any usage beyond the commitment continues at pay-as-you go rates, ensuring flexibility as needs change. Pricing is for illustrative purposes only. Benefits designed for modern database workloads Flexibility as environments evolve Savings plan for databases is designed for change. Savings continue to apply as workloads modernize or move across regions—without requiring customers to repurchase or reconfigure commitments. This makes it well suited for dynamic environments where architectures are expected to evolve over time. Automatic cost optimization With a single hourly commitment, customers unlock discounted prices on eligible database usage. Savings are applied automatically each hour, ensuring customers get the most value from their commitment without manual management or constant tuning. Predictable budgeting and forecasting A fixed hourly spend replaces variable pay-as-you-go costs with a predictable commitment, making it easier for FinOps and IT finance teams to forecast spend, plan budgets, and manage cloud investments with confidence. What services that are covered with the savings plan for databases: Savings plan for databases pricing How to purchase a savings plan for databases Getting started is simple: Review personalized recommendations in the Azure portal based on recent database usage. Choose an hourly commitment and scope it into a subscription, resource group, management group, or entire account. Select a payment option—pay monthly or upfront at no additional cost—and optionally enable auto‑renewal. Once purchased, savings are applied automatically to eligible database usage every hour. Learn more here on how to purchase a savings plans here. Example: saving while modernizing Consider a team running a global application that uses Azure SQL Database and Azure Database for PostgreSQL today, with plans to expand into additional regions over the next year. Instead of purchasing individual reservations tied to specific services or regions, the team purchases a 1‑year savings plan for databases with a $5/hour commitment. As usage shifts across database services and regions, Azure automatically applies discounted prices to eligible usage up to the hourly commitment. The team continues modernizing without disruption—while benefiting from predictable savings. Summary Savings plan for databases provides a new way to optimize database costs —without locking into fixed architectures. With hourly commitments, automatic optimization, and predictable costs, it’s designed to support modernization today and continued growth tomorrow. Get started You can begin saving today: View your recommendation in Azure Advisor Purchase a plan in Azure portal Visit the Savings plan homepage Review the Microsoft Documentation Watch demo videos at the Azure Essentials Show *Customers may see savings estimated to be between 0% and 35%. The 35% savings estimate is based on one Azure SQL Database serverless running for 12 months at a pay-as-you-go rate vs. a reduced rate for a 1-year savings plan. Based on Azure pricing as of March 2026. Prices are subject to change. Actual savings may vary based on location, database service, and/or usage. ** Note that savings plan for databases will also be consumed by SQL Server on Azure Virtual Machines and SQL Server enabled by Azure Arc hourly license at the normal pay-go price.9.9KViews2likes0CommentsCost increases when selecting Amortised cost in cost analysis
Hi, this seems like a bug. When i select Amortized cost in Cost analysis, our monthly cost jumps from $25,664.54 to $76,315.83. The resource that causes the jump is a Reservation for a D4asv5 virtual machine. It jumps to $3,120.09 per day. Can someone please try it their side.Solved397Views0likes4CommentsSentinel Foundry - MCP Server (Github Community Release)
I’ve been cooking something that a lot of people in SOC have been struggling with — especially on the engineering side of Microsoft Sentinel. Thanks to the Microsoft Security team for shaping the capabilities of Sentinel even better with Sentinel Data Lake & Modern SecOps. Today’s the day I can finally share it. Note: This is not an official Microsoft product, but it is designed to make the Sentinel Build even better (complement) with much more intelligence. 🚀 Sentinel Foundry is now in public preview with 43 tools. (Sentinel Foundry - MCP Server) It’s an MCP server built to act like the brain of a strong Sentinel engineer — helping make building, improving, and operating Sentinel far more practical, faster, and honestly more enjoyable. For a lot of teams, the challenge is not understanding what Sentinel can do. The hard part is the engineering work around it: -> Deciding what data should actually be ingested -> Building a clean, scalable Sentinel foundation -> Writing useful detections instead of noisy ones -> Balancing security value with cost -> Turning ideas into deployable engineering outputs That is exactly why I built Sentinel Foundry to help communities grow stronger. It helps with the real engineering tasks behind Sentinel — from architecture thinking to detection design, deployment planning, ingestion strategy, automation ideas, and many of the workflows outlined in the GitHub project. How does it work? Here’s one of the flagship prompts I ran with it: “Give me a complete security posture report for our workspace. Score each pillar and tell me what to prioritise.” And within seconds, it produced a structured engineering blueprint that would normally take a lot longer to pull together manually. You can see the example prompts here in what it can do: https://github.com/prabhukiranveesam/Sentinel-Foundry#what-can-it-do I want building Sentinel to feel less like repetitive engineering overhead — and more like real security engineering that is fast, creative, and enjoyable. If you work with Sentinel as a SOC L2 analyst, engineer, detection engineer, consultant, or architect, I’d genuinely love for you to try it and tell me what you think. 🔗 Public Preview: https://github.com/prabhukiranveesam/Sentinel-Foundry This is just the start of an AI era — and I’m excited to keep shaping it with more powerful features over the coming days. This is very easy to set up and will be available to all of you at no cost during this month as part of the public preview, and your feedback is extremely valuable to shape this as a powerful solution.1.3KViews0likes2CommentsReservation exchanges for Azure services covered by savings plans end starting Feb. 1, 2027
Starting February 1, 2027, Azure reservation exchanges will no longer be available for services covered by savings plans. This change aligns reservation exchange policy with the flexibility already offered by savings plans, and it gives you a clear, predictable framework for choosing the right commitment-based discount for each workload. This post walks through what's changing, who's affected, what stays the same, and the actions you can take today to plan ahead. What's changing If a service supports Azure savings plans, the corresponding reservation for that service will no longer support exchanges as of February 1, 2027. This change excludes products or services that are deprecated and approaching end of life, as well as cloud environments that don't currently support savings plans. The policy is forward-looking, as savings plan coverage expands, reservations for those services will follow the same policy and will not support exchanges. Affected services At the time of this announcement, the change applies to reservations for the following services: Compute services Azure Virtual Machines — including exchanges between non-premium and premium storage Azure Dedicated Host Azure App Service Database services Azure Database for PostgreSQL Azure Database for MySQL Azure DocumentDB Azure Cosmos DB Azure SQL Database Azure SQL Managed Instance Important details to plan around One final exchange. Each active reservation for an impacted service, purchased before February 1, 2027, will retain the right to one final exchange after that date. Plan how and when you want to use it. New purchases. Reservations for impacted services purchased on or after February 1, 2027, will not support exchanges. Expanding scope. As savings plan eligibility grows, additional services will automatically fall under this policy. What's not changing Reservations remain the right choice for predictable, stable workloads, and you can continue to purchase them. Specifically: Instance size flexibility for virtual machines is not impacted by this change. The reservation cancellation policy is not impacted by this change. Recommended action If you need flexibility across services and regions, consider evaluating savings plans as a discount option for dynamic and evolving workloads. Savings plans can help provide cost savings on consistent spend across compute and database services, regardless of region. You can also trade in your existing reservations for a savings plan. Alternatively, reservations remain the appropriate option for predictable, stable workloads, and you can continue to purchase them. To compare your options, see decide between a savings plan and a reservation. Frequently Asked Questions What is changing? Starting February 1, 2027, Azure reservation exchanges will no longer be available for services covered by Azure savings plans. Reservations for these services will continue to be available for purchase and renewal. Which services are affected? At the time of this announcement, the policy applies to reservations for: Compute services Azure Virtual Machines (including exchanges between non-premium and premium storage) Azure Dedicated Host Azure App Service Database services Azure Database for PostgreSQL Azure Database for MySQL Azure DocumentDB Azure Cosmos DB Azure SQL Database Azure SQL Managed Instance As Azure savings plan coverage expands, additional savings plan-eligible services may become subject to this policy. Does this apply to all Azure cloud environments? No. This change applies only to cloud environments where Azure savings plans are available. Can I still exchange reservations before February 1, 2027? Yes. Reservation exchanges will continue to be available under the current policy until February 1, 2027. Does this affect reservations I already own? Active reservations for impacted services purchased before February 1, 2027, will retain the right to one final exchange after that date. What happens after I use my final exchange? Once the final exchange is used, the resulting reservation cannot be exchanged again. Can I still purchase or renew reservations? Yes. Reservations remain available and continue to be a valuable option for stable, predictable workloads. Is Azure retiring reservations? No. Reservations remain an important commitment-based discount offering. This change affects exchangeability only. What is not changing? The following capabilities remain available: VM instance size flexibility Reservation cancellations under existing policies Reservation-to-savings-plan trade-in Reservation purchases and renewals When should I choose a savings plan instead of a reservation? Review our guidance on how to decide between a savings plan and a reservation. What should I do before February 1, 2027? Review your reservation portfolio, evaluate future flexibility needs, consider Azure savings plans where appropriate, and plan how you want to use the one final exchange available to eligible active reservations. Where can I learn more? For more information, see: Changes to the Azure reservation exchange policy Exchanges and refunds for Azure reservations Trade in reservations for a savings plan Azure savings plans Decide between a savings plan and a reservation. Policy details are subject to change and may vary based on service eligibility and contractual terms.4.1KViews0likes0CommentsCap it with GitHub, make it count with Azure: governing GitHub Copilot spend
GitHub Copilot is now usage-based. Here is a working, one-command pattern to govern the spend: route Copilot BYOK through an Azure API Management gateway in front of Azure AI Foundry for real-time per-developer token quotas, per-developer metrics, and consumption on your own Azure meters.2KViews3likes3CommentsNCE in Azure Government
Can anyone give me a status on NCE for Azure Gov? We have a large number of older legacy subscriptions we'd like to get off of and onto Azure Plans and as I read it until NCE is available in Gov that isn't going to be an option unless we do a resource migration (which is expensive and an exercise the customer shouldn't have to go through to get access to the cost management tools). Thanks in advance!585Views0likes3CommentsRight‑sizing Azure Savings Plans, one hour at a time
Most of us have, at some point, sized a commitment the same way we order food for a team offsite: estimate, round up, and hope nobody complains. It works for pizza. It is a less robust strategy for a three‑year Savings Plan. Azure Cost Management already produces commitment recommendations for you, and they are a great starting point. But the headline dollar figure on the portal hides the most useful signal a FinOps team can get its hands on: the hourly Pay‑As‑You‑Go (PAYG) usage that the recommendation engine actually looked at. Once you have that signal in a spreadsheet, "right‑sized" stops being a vibe and starts being a number you can defend in a steering meeting. This post walks through how to pull that data out of the Cost Management REST API, and shares a small companion PowerShell script that does the heavy lifting and produces analyst‑friendly CSV and Markdown outputs. Why a single recommended number isn't enough A Savings Plan recommendation is, at its core, an optimisation against a distribution of hourly compute spend over a lookback window. The portal typically surfaces the single commitment level that maximises savings under a "reasonable utilisation" assumption. That's a sensible default, but it answers only one question. The questions FinOps practitioners also want to answer include: What does my PAYG demand actually look like hour‑by‑hour? Smooth and predictable, or spiky and seasonal? How does coverage and savings change if I commit a bit less, or a bit more? Will the recommended commitment leave me with wastage on weekends or overnight? Can I correlate the hourly profile with maintenance windows, batch jobs, or business hours? You cannot answer those questions with a single dollar figure. You can answer all of them with the hourly series and the alternative commitment levels — and the API exposes both. What the Benefit Recommendations API gives you The endpoint is the Benefit Recommendations - List operation (api-version=2025-03-01). Pointed at any of the supported scopes — Billing Account (EA), Billing Profile (MCA), Subscription, or Resource Group — it returns one or more recommendations for the chosen lookBackPeriod (Last7Days, Last30Days, Last60Days) and term (P1Y, P3Y). The two $expand options are where the magic lives: $expand=properties/allRecommendationDetails returns an array of alternative commitment levels (AllSavingsBenefitDetails). Each entry includes commitmentAmount, coveragePercentage, benefitCost, overageCost, savingsAmount, savingsPercentage, wastageCost, and averageUtilizationPercentage. $expand=properties/usage returns the hourly PAYG charge series (usage.charges) that the engine used. Combined with properties.firstConsumptionDate and properties.lastConsumptionDate, you get a complete time‑aligned view of demand. Both expansions are cheap and worth requesting every time. They turn a single recommendation into a small, complete data product. Meet the script: Export-BenefitRecommendations.ps1 To make this useful in five minutes rather than an afternoon, there is a PowerShell script on GitHub that wraps the API call and produces ready‑to‑use artifacts. It is interactive, so there is nothing to memorise: === Azure Benefit Recommendations Export === Select billing scope kind: * [1] Billing Account (EA) [2] Billing Profile (MCA) [3] Subscription [4] Resource Group Enter choice 1-4 (default 1): 1 Billing Account ID: <your-EA-billing-account-id> Select lookback period: [1] Last7Days * [2] Last30Days [3] Last60Days Enter choice 1-3 (default 2): 3 Select term: * [1] P1Y [2] P3Y Enter choice 1-2 (default 1): 2 ... Retrieved 1 recommendation(s). It authenticates via the Az.Accounts module, always requests both $expand options, follows nextLink pagination, verifies API access up front (translating 401/403/404 into actionable hints), and writes four files using a predictable name pattern: yyyy-MM-dd-<scope>-<lookback>-<term>-AllRecommendationDetails.csv — one row per commitment alternative, ready for pivot tables. yyyy-MM-dd-<scope>-<lookback>-<term>-TopRecommendation.md — a Markdown brief on the top recommendation, including the recommended commitment row and the full alternatives table. yyyy-MM-dd-<scope>-<lookback>-<term>-HourlyUsage.csv — hour‑by‑hour PAYG usage for the top recommendation, aligned to the API's actual data window (no padding, no trailing blanks). yyyy-MM-dd-<scope>-<lookback>-<term>-Raw.json — optional full response dump, for archival or downstream tooling. The naming convention is intentional: paste a folder of these into Power BI and the dates, scopes, and terms are already in the filename. A worked example Here is a real shape from a sample Last60Days / P3Y export against an EA billing account. The AllRecommendationDetails CSV gives us four commitment alternatives: averageUtilizationPercentage,coveragePercentage,commitmentAmount,overageCost,benefitCost,savingsAmount,savingsPercentage,totalCost,wastageCost 100.000,28.868,4.124,30914.280,5889.072,6656.889,15.317,36803.352,0.000 100.000,39.168,5.848,26437.791,8350.944,8671.506,19.953,34788.735,0.000 9.984,97.883,16.359,919.948,23360.652,19179.641,44.131,24280.600,3.767 98.684,98.900,16.806,477.956,23998.968,18983.317,43.680,24476.924,315.907 Read those rows like an interactive lever: Commit $4.124/hr → 28.9% coverage, 15.3% savings, zero wastage. Safe, but most of your spend is still PAYG. Commit $5.848/hr → 39.2% coverage, 19.9% savings. Still safe, still conservative. Commit $16.359/hr → 97.9% coverage, 44.1% savings, ~$3.77 of wastage. This is the sweet spot the engine flags as recommended. Commit $16.806/hr → 98.9% coverage, 43.7% savings, but wastage jumps to $315.9 over the window. You bought more coverage and the engine charged you for it. The hourly CSV is what makes the recommendation defensible. It contains 1,428 rows — one per hour from 2026-04-11T00:00 through 2026-06-09T11:00 (the API's reported data range, not "now minus 60 days"): DateTime,HourlyPayGoUsage 2026-04-11T00:00,29.5350191832771 2026-04-11T01:00,29.566694701744 ... 2026-06-09T11:00,32.7312920192344 Drop that into Excel or Power BI, lay a horizontal line at the recommended commitmentAmount ($16.359/hr), and you immediately see how often demand sits above the line (covered by PAYG overage) versus below it (where the commitment is technically idle but, given the savings rate, still net‑positive). You can also slice by hour‑of‑day to spot weekend troughs or batch‑job spikes that change how you interpret "average utilisation." Try it yourself The script and full documentation live at github.com/DirkBrinkmann/azure-savingsplan-insights. Quickstart: git clone https://github.com/DirkBrinkmann/azure-savingsplan-insights.git cd azure-savingsplan-insights Install-Module Az.Accounts -Scope CurrentUser # if you don't already have it #Connect to Azure Connect-AzAccount #Run the script .\Export-BenefitRecommendations.ps1 You will need read permission on the scope you target — Cost Management Reader on a subscription, or Billing Reader at the billing account / billing profile level, is enough. Give it a spin against your own scope and tell us how it goes. The repo at github.com/DirkBrinkmann/azure-savingsplan-insights has Issues and Discussions enabled — bug reports, edge cases ("my response shape looks different"), feature ideas, and "I plotted this in Power BI and learned X" stories are all welcome. The script will only get better with real‑world data behind it, and yours is the kind we want to hear about. Closing nudge In FinOps terms, this is squarely an Inform phase activity: turning a black‑box recommendation into a transparent dataset your team can challenge, chart, and align on. The API has had this data all along; the script just makes it boring to extract — which is exactly what you want a FinOps tool to be. Pull a Last60Days / P3Y export for your top‑spending scope, plot the hourly line, and decide your next Savings Plan with a number you can point to. Your future self (and your finance partner) will thank you.1.4KViews2likes2Comments