How Many SCUs Does Security Copilot Actually Need? Sizing Capacity Without the Bill Shock

Posted on Oct 23 • Originally published at alanconlon.com

The question that always lands after the Security Copilot demo is the same one: what’s this going to cost. The honest answer is unsatisfying. It depends entirely on how you size it, and most people get the sizing wrong in one of two directions. They either reserve a pile of capacity they never use and quietly bleed money, or they run it too lean and watch it fall over in the middle of the one investigation where they actually needed it.

Start with your licence. If you’re on Microsoft 365 E5 or E7, Security Copilot is included with a monthly SCU allowance, and you don’t need to provision or buy anything to start. Most of this post is about the standalone route, where you buy capacity yourself, and about what to do if the included allowance isn’t enough.

So this is the sizing post. If you’ve already switched it on, this is the bit where you work out how much compute to put behind it without overpaying or starving it.

Security Copilot is metered in Security Compute Units. An SCU is just a measure of compute, the fuel the platform burns to do something. The thing to get straight early is that consumption is driven by work, not by headcount. It is not a per-user licence in disguise.

Different actions cost wildly different amounts. A big, multi-step prompt that reaches across several data sources and reasons over the results can burn several units in one go. A quick incident summary might cost a fraction of one. So two teams with the same number of analysts can run up completely different bills depending on what they actually ask it to do. When you’re sizing, think in terms of how much work and how often, not how many people.

You pay for that compute two ways, and each has its own way of hurting you.

Provisioned capacity is always-on. You reserve a number of units and pay for them by the hour, every hour, whether anyone uses Copilot or not. The trap here is obvious once you say it out loud: reserve too much and you’re paying rent on idle compute around the clock, including the nights and weekends when nobody’s running a thing.

It isn’t a long-term commitment, though. You can raise or lower provisioned units at any time, and you’re billed for each hour they’re provisioned.

Overage is on-demand. It kicks in once you’ve exhausted the provisioned units, and you’re billed only for what you use. You can leave it unlimited or set a cap. The trap here is the cap. Set a hard overage limit that’s too low and you’ve built yourself a cliff: once real demand uses up both the provisioned units and the overage, Copilot returns an error and won’t take new prompts until the next hour. More on that further down, because it’s the failure mode that actually bites.

Here’s the one nobody mentions until the invoice arrives. Provisioned capacity is billed in whole clock-hour blocks, 9:00 to 10:00 and so on, with a one-hour minimum. Each provisioned SCU is charged for the full hour, whether you ran one prompt or none. Unused units expire at the end of the hour and don’t roll over.

The practical effect shows up when you change capacity. Add an SCU at 9:05, remove it at 9:35, add another at 9:45, and you pay for two SCUs in that hour. So make provisioning changes at the start of the hour. Overage works differently. It’s charged on the exact units consumed, to one decimal place, with no rounding up.

If your organisation is on Microsoft 365 E5 or E7, set most of the above aside for a moment, because you’re on a different model. Security Copilot comes included, with a monthly allocation of 400 SCUs for every 1,000 paid user licences, up to a ceiling of 10,000 a month, at no extra cost. That capacity isn’t billed by the hour the way standalone provisioned capacity is. Usage is simply deducted from the monthly pot. Microsoft says usage beyond the allocation will be throttled at a future date, with an option to pay for more at $6 an SCU, and 30 days’ notice before that starts.

Two things follow. First, the allocation resets every month and doesn’t roll over, so anything you don’t use just disappears. Second, a lot of E5 shops already have more capacity than they realise and don’t need to rush out and buy standalone SCUs at all. Check what you’re entitled to before you provision anything. And if you already had standalone capacity before the inclusion arrived, Microsoft’s advice is to keep it rather than delete it, so you don’t lose access.

The method that works is the unglamorous one, and it’s the same shape as sizing anything else.

Start with what you already have. On E5 or E7, run real work against the included allowance first. If you’re buying standalone capacity, start small. Whether you provision in Azure or in the Security Copilot portal, you need at least one provisioned unit. You can’t set it to zero and run purely on overage. For a first look, Microsoft’s own suggestion is three provisioned units with overage left unlimited. Either way, you begin with very little reserved.

Then run real workloads and read the data. The in-product usage dashboard holds ninety days of history and shows you what’s genuinely being consumed: how many provisioned and overage units, which plugins are doing the work, and who’s running the sessions. There’s also a capacity calculator if you want an estimate up front. Between the two, you can see your actual steady-state demand instead of guessing at it.

Only then do you set your provisioned level. Reserve enough to cover your normal baseline, the floor of activity that happens most working hours, and let overage absorb the spikes on top. That gives you predictable billing for the routine and flexibility for the busy days, without paying to keep a peak-sized allocation warm twenty-four hours a day. Look at real usage first, size second. Resist the urge to pick a big round number on day one because it feels safe.

On the actual money: Microsoft’s US pricing example uses $4 per provisioned SCU per hour and $6 per overage SCU. Treat any figure you read, including that one, as indicative. Run the calculator against your own numbers for anything you’d put in front of finance.

If you’re running more than one team or region, use workspaces. A workspace is backed by its own capacity, and the detail that matters is that SCUs don’t flow between workspaces. You can’t keep one big shared pool that quietly rebalances itself.

That sounds like a limitation, and sometimes it is, but it’s also useful. It means one team having a heavy week can’t silently drain the capacity another team is relying on. Provision each workspace for its own workload, size them independently off their own dashboard data, and you get cost and capacity that line up with how the teams actually operate rather than one undifferentiated bill nobody can break down.

This is the failure mode worth designing against, because it turns up at the worst possible moment. As usage climbs towards your limit, analysts start getting capacity warnings inside their sessions, including the embedded Copilot experiences inside Defender and Sentinel. That’s your early signal.

Push past the limit entirely and it stops being a warning. Once both the provisioned units and any overage are used up, Copilot returns an error saying it can’t respond because of high usage. Nobody can submit more prompts until capacity frees up in the next hour. Raising the units fixes it, but changes can take up to 30 minutes to take effect. Picture that landing halfway through a live incident, with an analyst told to go and find whoever owns the capacity to get it raised. That’s a self-inflicted wound, and it traces straight back to a hard overage cap set too low and never revisited.

The fix isn’t complicated. Either leave overage unlimited and watch the dashboard, or set a cap you’ve genuinely thought through and make sure the people who can lift it are reachable when it matters. Capacity that runs dry quietly during an incident is the one sizing mistake you really don’t want to make.

Sizing Security Copilot isn’t a number you get right once. It’s start small, run real work, read the dashboard, then set provisioned to your baseline and let overage handle the rest. The bill shock people complain about almost always comes from guessing at the start instead of measuring, or from a capacity cap nobody looked at again. Neither is the product’s fault, and both are easy to avoid.

I write about security, Azure, data, and the practical side of running things. If this was useful, connect with me on LinkedIn.

Originally published at alanconlon.com, where I post practical security, Azure and data write-ups every other Tuesday.