Security Copilot richtig dimensionieren: So lassen sich SCUs realistisch planen
Nach der Demo von Security Copilot stellt sich meist die Kostenfrage, und die Antwort haengt komplett von der Dimensionierung ab. Viele Unternehmen planen die benoetigten SCUs falsch, etwa mit unnutzen Kapazitaetsreserven.
Veröffentlicht am 23. Okt. • Zuerst erschienen auf alanconcon.com
Die Frage, die nach der Security-Copilot-Demo immer kommt, ist immer dieselbe: Was wird das kosten. Die ehrliche Antwort ist unbefriedigend. Es hängt völlig davon ab, wie Sie die Dimensionierung vornehmen, und die meisten Menschen machen beim Sizing in eine von zwei Richtungen einen Fehler. Entweder reservieren sie eine Menge Kapazität, die sie nie nutzen, und verlieren still Geld, oder sie fahren zu knapp und sehen zu, wie das System mitten in genau der Untersuchung zusammenbricht, in der sie es wirklich gebraucht hätten.
Beginnen Sie mit Ihrer Lizenz. Wenn Sie Microsoft 365 E5 oder E7 haben, ist Security Copilot mit einer monatlichen SCU-Zuteilung enthalten, und Sie müssen nichts bereitstellen oder kaufen, um loszulegen. Der Großteil dieses Beitrags handelt vom eigenständigen Weg, bei dem Sie Kapazität selbst erwerben, und davon, was zu tun ist, wenn die enthaltene Zuteilung nicht ausreicht.
Das ist also der Beitrag zur Dimensionierung. Wenn Sie Security Copilot bereits aktiviert haben, geht es hier darum, herauszufinden, wie viel Rechenleistung Sie dahinterstellen, ohne zu überzahlen oder zu wenig bereitzustellen.
Security Copilot wird in Security Compute Units abgerechnet. Eine SCU ist einfach ein Maß für Rechenleistung, der Treibstoff, den die Plattform verbrennt, um etwas zu tun. Man sollte früh verstehen, dass der Verbrauch von der Arbeitslast und nicht von der Anzahl der Nutzer abhängt. Es ist keine Benutzerlizenz in Verkleidung.
Unterschiedliche Aktionen kosten sehr unterschiedliche Beträge. Ein großer, mehrstufiger Prompt, der auf mehrere Datenquellen zugreift und die Ergebnisse durch reasoning verarbeitet, kann auf einen Schlag mehrere Einheiten verbrauchen. Eine schnelle Incident-Zusammenfassung kostet möglicherweise nur einen Bruchteil einer Einheit. Zwei Teams mit derselben Anzahl von Analysten können also völlig unterschiedliche Rechnungen anhäufen, je nachdem, was sie das System tatsächlich tun lassen. Denken Sie bei der Dimensionierung in Arbeitsmengen und Häufigkeit, nicht in Personenzahl.
Sie zahlen für diese Rechenleistung auf zwei Arten, und jede hat ihre eigene Art, Sie zu schmerzen.
Bereitgestellte Kapazität ist durchgehend aktiv. Sie reservieren eine Anzahl von Einheiten und zahlen stundenlang für sie, jede Stunde, unabhängig davon, ob jemand Copilot nutzt oder nicht. Die Falle ist offensichtlich, sobald man sie ausspricht: Reserviert man zu viel, zahlt man rund um die Uhr Miete für ungenutzte Rechenleistung, auch nachts und am Wochenende, wenn niemand etwas laufen lässt.
Es ist allerdings keine langfristige Verpflichtung. Sie können bereitgestellte Einheiten jederzeit erhöhen oder senken, und abgerechnet wird für jede Stunde, in der sie bereitgestellt waren.
Overage funktioniert bedarfsorientiert. Sie greift, sobald die bereitgestellten Einheiten erschöpft sind, und Sie zahlen nur für das, was Sie tatsächlich nutzen. Sie können sie unbegrenzt lassen oder ein Limit setzen. Die Falle ist hier das Limit. Setzt man ein hartes Overage-Limit, das zu niedrig ist, baut man sich eine Klippe: Sobald echte Nachfrage sowohl die bereitgestellten Einheiten als auch das Overage aufbraucht, gibt Copilot einen Fehler zurück und nimmt keine neuen Prompts mehr an, bis zur nächsten Stunde. Dazu weiter unten mehr, denn das ist der Ausfallmodus, der wirklich schmerzt.
Hier kommt das, worüber niemand spricht, bis die Rechnung kommt. Bereitgestellte Kapazität wird in vollen Uhrzeitstunden abgerechnet, also 9:00 bis 10:00 Uhr und so weiter, mit einem Mindestmaß von einer Stunde. Jede bereitgestellte SCU wird für die volle Stunde berechnet, egal ob Sie einen Prompt ausgeführt haben oder keinen. Ungenutzte Einheiten verfallen am Ende der Stunde und werden nicht übertragen.
Die praktische Folge zeigt sich, wenn Sie die Kapazität ändern. Fügen Sie um 9:05 Uhr eine SCU hinzu, entfernen Sie sie um 9:35 Uhr, fügen Sie um 9:45 Uhr eine weitere hinzu, und Sie zahlen in dieser Stunde für zwei SCUs. Nehmen Sie Bereitstellungsänderungen also zu Beginn der Stunde vor. Overage funktioniert anders. Sie wird auf die exakt verbrauchten Einheiten abgerechnet, auf eine Dezimalstelle genau, ohne Aufrundung.
Wenn Ihre Organisation Microsoft 365 E5 oder E7 einsetzt, legen Sie das oben Gesagte einen Moment beiseite, denn Sie befinden sich in einem anderen Modell. Security Copilot ist enthalten, mit einer monatlichen Zuteilung von 400 SCUs für jeweils 1.000 bezahlte Benutzerlizenzen, bis zu einer Obergrenze von 10.000 pro Monat, ohne Mehrkosten. Diese Kapazität wird nicht stundenweise abgerechnet wie eigenständige bereitgestellte Kapazität. Der Verbrauch wird einfach vom monatlichen Kontingent abgezogen. Microsoft sagt, dass die Nutzung über die Zuteilung hinaus zu einem späteren Zeitpunkt gedrosselt wird, mit der Option, mehr zu kaufen, für 6 Dollar pro SCU, und mit 30 Tagen Vorlauf, bevor das in Kraft tritt.
Daraus ergeben sich zwei Dinge. Erstens wird die Zuteilung jeden Monat zurückgesetzt und wird nicht übertragen, sodass alles, was Sie nicht nutzen, einfach verfällt. Zweitens haben viele E5-Kunden bereits mehr Kapazität, als sie glauben, und müssen überhaupt nicht überstürzt eigenständige SCUs kaufen. Prüfen Sie, was Ihnen zusteht, bevor Sie etwas bereitstellen. Und falls Sie bereits eigenständige Kapazität hatten, bevor die Inklusion kam, lautet Microsofts Rat, diese zu behalten statt zu löschen, damit Sie den Zugriff nicht verlieren.
Die Methode, die funktioniert, ist die unspektakuläre, und sie hat dieselbe Form wie das Dimensionieren von allem anderen.
Beginnen Sie mit dem, was Sie bereits haben. Bei E5 oder E7 fahren Sie zuerst echte Arbeitslasten gegen die enthaltene Zuteilung. Wenn Sie eigenständige Kapazität kaufen, fangen Sie klein an. Ob Sie in Azure oder im Security-Copilot-Portal bereitstellen, Sie brauchen mindestens eine bereitgestellte Einheit. Sie können sie nicht auf null setzen und rein auf Overage laufen. Für einen ersten Blick ist Microsofts eigener Vorschlag drei bereitgestellte Einheiten mit unbegrenztem Overage. In jedem Fall beginnen Sie mit sehr wenig reservierter Kapazität.
Fahren Sie dann echte Arbeitslasten und lesen Sie die Daten. Das Nutzungsdashboard im Produkt umfasst neunzig Tage Historie und zeigt, was tatsächlich verbraucht wird: wie viele bereitgestellte und Overage-Einheiten, welche Plugins die Arbeit machen und wer die Sessions ausführt. Es gibt auch einen Kapazitätsrechner, falls Sie vorab eine Schätzung wollen. Mit beiden zusammen sehen Sie Ihre tatsächliche Dauerlast statt sie zu schätzen.
Erst dann legen Sie Ihr bereitgestelltes Niveau fest. Reservieren Sie genug, um Ihre normale Grundlast abzudecken, also das Aktivitätsniveau, das an den meisten Arbeitsstunden herrscht, und lassen Sie das Overage die Spitzen darüber auffangen. Das gibt Ihnen planbare Abrechnung für den Routinebetrieb und Flexibilität für die hektischen Tage, ohne rund um die Uhr eine auf Spitzenlast dimensionierte Zuteilung warmzuhalten. Schauen Sie zuerst auf die echte Nutzung, dimensionieren Sie danach. Widerstehen Sie dem Drang, am ersten Tag eine runde große Zahl zu wählen, nur weil sie sich sicher anfühlt.
Zum eigentlichen Geld: Microsofts US-Preisbeispiel nutzt 4 Dollar pro bereitgestellter SCU pro Stunde und 6 Dollar pro Overage-SCU. Betrachten Sie jede Zahl, die Sie lesen, auch diese, als Richtwert. Lassen Sie den Rechner mit Ihren eigenen Zahlen laufen, bevor Sie irgendetwas der Finanzabteilung vorlegen.
Wenn Sie mehr als ein Team oder eine Region betreiben, nutzen Sie Workspaces. Ein Workspace basiert auf seiner eigenen Kapazität, und das entscheidende Detail ist, dass SCUs nicht zwischen Workspaces fließen. Sie können keinen großen gemeinsamen Pool führen, der sich still selbst neu ausbalanciert.
Das klingt nach einer Einschränkung, und manchmal ist es auch eine, aber es ist auch nützlich. Es bedeutet, dass ein Team mit einer intensiven Woche nicht stillschweigend die Kapazität abgraben kann, auf die ein anderes Team angewiesen ist. Dimensionieren Sie jeden Workspace für seine eigene Arbeitslast, kalkulieren Sie sie unabhängig anhand ihrer eigenen Dashboard-Daten, und Sie bekommen Kosten und Kapazität, die zur tatsächlichen Arbeitsweise der Teams passen, statt einer undifferenzierten Rechnung, die niemand aufschlüsseln kann.
Genau gegen diesen Ausfallmodus sollte man entwerfen, denn er taucht im schlechtesten möglichen Moment auf. Wenn die Nutzung auf Ihr Limit zuklettert, bekommen Analysten Kapazitätswarnungen innerhalb ihrer Sessions, auch in den eingebetteten Copilot-Erlebnissen in Defender und Sentinel. Das ist Ihr frühes Signal.
Überschreitet man das Limit vollständig, wird aus der Warnung ein Stillstand. Sobald sowohl die bereitgestellten Einheiten als auch etwaiges Overage aufgebraucht sind, gibt Copilot einen Fehler zurück mit dem Hinweis, es könne wegen hoher Nutzung nicht antworten. Niemand kann weitere Prompts einreichen, bis in der nächsten Stunde Kapazität frei wird. Das Erhöhen der Einheiten behebt es, aber Änderungen können bis zu 30 Minuten dauern, bis sie wirksam werden. Stellen Sie sich das mitten in einem laufenden Incident vor, wo ein Analyst losgeschickt wird, denjenigen zu finden, dem die Kapazität gehört, um sie erhöhen zu lassen. Das ist eine selbst zugefügte Wunde, und sie führt geradewegs zurück auf ein hartes Overage-Limit, das zu niedrig gesetzt und nie wieder angesehen wurde.
Die Lösung ist nicht kompliziert. Entweder lassen Sie das Overage unbegrenzt und beobachten das Dashboard, oder Sie setzen ein Limit, das Sie wirklich durchdacht haben, und stellen sicher, dass die Personen, die es anheben können, erreichbar sind, wenn es darauf ankommt. Kapazität, die während eines Incidents still zur Neige geht, ist der eine Dimensionierungsfehler, den Sie wirklich nicht machen wollen.
Security Copilot zu dimensionieren ist keine Zahl, die man einmal richtig festlegt. Es heißt: klein anfangen, echte Arbeit laufen lassen, das Dashboard lesen, dann das bereitgestellte Niveau auf die Grundlast setzen und das Overage den Rest bewältigen lassen. Der Rechnungsschock, über den sich die Leute beschweren, kommt fast immer daher, dass man am Anfang schätzt statt misst, oder von einem Kapazitätslimit, das niemand mehr angesehen hat. Beides ist nicht die Schuld des Produkts, und beides lässt sich leicht vermeiden.
Ich schreibe über Security, Azure, Daten und die praktische Seite des Betriebs von Systemen. Wenn das hilfreich war, vernetzen Sie sich mit mir auf LinkedIn.
Zuerst erschienen auf alanconcon.com, wo ich alle zwei Wochen dienstags praxisnahe Beiträge zu Security, Azure und Daten veröffentliche.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
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.