Introducing the Copilot for Security SCU Optimizer Solution

A custom solution to automate scaling of Copilot for Security

A screenshot of the Edit tab of the SCU Optimizer

Reference GitHub

In today’s fast-paced digital landscape, small to medium-sized organizations often find themselves grappling with the challenge of optimizing costs while maintaining security operations.

As someone who has been deeply involved in customer conversations since Copilot for Security was launched, I’ve witnessed firsthand the concerns and hurdles organizations face.

That’s why I developed the Copilot for Security SCU Optimizer—a solution designed to simplify cost management and enhance operational efficiency.

In this post I’ll walk you through the features and benefits of the solution, which can be deployed in under 10 minutes.

Note: This solution is a community contribution and is not officially supported by Microsoft beyond standard service/product support. If you leverage the solution and have questions, comments, or concerns, feel free to drop a comment or report a bug on GitHub.

The Challenge

The challenge many customers encounter is justifying the cost of Copilot for Security while operating their SOC in a more limited capacity than 24 x 7, for example, operating from 9 AM to 5 PM on Weekdays. The native Copilot for Security experience is a static deployment of SCUs, meaning that when you deploy at 2 SCUs, those 2 SCUs will be charged hourly both during and outside of your SOC operating hours. If we want to match our deployment with our usage patterns, we need to take advantage of automation.

Understanding Copilot for Security costs

Copilot for Security is charged based on provisioned SCUs - Security Compute Units. These SCUs determine how we can use the product, how many prompts we can run, and the complexity of those prompts. The same logic applies across the 3 experiences: embedded, standalone and in logic apps.

Provisioned SCUs are charged and refreshed hourly and serve as the capacity available for us to leverage. Typically, if we want to run more queries, more complex queries, or leverage more experiences, we’ll need to deploy more SCU capacity.

One consideration we have with SCUs is that they’re limited to a minimum of 1 SCU and a maximum of 100 SCUs at the high end. Now for most customers starting out, you’ll benefit from 2 - 5 SCUs depending on usage patterns. Start low and scale from there. The exact costs may be variable depending on deployment region and currency.

The Solution

The solution is created using 2 core components:

• Sentinel Workbook - Copilot for Security SCU Optimizer

• Logic App - Copilot for Security Scaler

The Copilot for Security SCU Optimizer solution architecture

The SCU Optimizer Sentinel solution offers 3 core features:

1. View - Security teams can view existing scheduling (or lack there of) on a Compute Capacity, and displays predicted costs of the solution

2. Modify - Security architects can add/modify existing schedules, view cost calculations based on the new schedule, and compare it with the existing config.

3. Apply - Finally, the Logic App runs hourly (5 minutes after the hour, to avoid conflict with other automations), to find resources with a schedule applied, then apply the relevant SCU capacity.

A screenshot of the View tab of the SCU Optimization solution displaying a Compute Capacity with no schedule applied

Scenario Comparison

By leveraging this solution we’re able to manage our provisioned SCU capacity along with our SOC operation hours which can mean we can either drastically reduce our costs, or we can drastically increase the SCU capacity available to us during business hours.

As a quick thought experiment - let’s explore a few scenarios:

Scenario 1:

If we had 2 x SCUs deployed full time without a schedule, that would be:

(24 hours a day x 7 days a week) x 2 (# of SCUs) x 4 ($ per SCU) = $1344 per week

Scenario 2:

If we scaled down to 1 x SCU outside of business hours (9-5 M-F) using a schedule, that would be:

Operating Hours: (8 hours a day x 5 days a week) x 2 (# of SCUs) x 4 ($ per SCU) = $320
Outside Hours: + (16 hours a day x 5 days a week) x 1 (# of SCUs) x 4 ($ per SCU) = $320
Weekends: + (24 hours x 2 days a week) x 1 (# of SCUs) x 4 ($ per SCU) = $192
$320 (Operating) + $320 (Outside of business) + $192 (Weekend) = $832 per week

Scenario 3:

If we scaled down to 1 x SCU outside of business hours (9-5 M-F) and we also scaled up to 4 x SCU during business hours using a schedule that would be:

Operating Hours: (8 hours a day x 5 days a week) x 4 (# of SCUs) x 4 ($ per SCU) = $640
Outside Hours: + (16 hours a day x 5 days a week) x 1 (# of SCUs) x 4 ($ per SCU) = $320
Weekends: + (24 hours x 2 days a week) x 1 (# of SCUs) x 4 ($ per SCU) = $192
$640 (Operating) + $320 (Outside of business) + $192 (Weekend) = $1152 per week

In this last scenario, we reduced our cost outside of our operating hours (still leaving a bit for simple automations or on-call staff, and doubled our available capacity during business hours while still being cheaper than operating without a schedule.

How it works

The solution allows Security Architects to interact with their Compute Capacities in the Copilot for Security SCU Optimizer workbook to view cost predictions, compare, adjust, and apply a new schedule. The schedules are stored as a JSON Resource Tag: CopilotforSecurityConfig to the Copilot for Security Compute Capacity. This tag is applied by leveraging an API call which relies on the permissions of the active user.

A screenshot of the Edit tab showing a new schedule being modified

The CopilotforSecurityConfig tag contains all the schedule information that the scaler needs to operate:

{
"SCULimits": {
"Min": 1,
"Max": 3
},
"Schedule": {
"ActiveDays": [ 1, 2, 3, 4 ],
"ActiveStartHour": 8,
"ActiveEndHour": 18,
"TimeOffset": -6
}
}

The property definitions are as follows:

• SCULimits

  • Min: SCU count applied for Low Usage days/times

  • Max: SCU count applied for High Usage days/times

• Schedule

  • ActiveDays: integer representations of days of the week:

    • 0 = Sunday

    • 1 = Monday

    • 2 = Tuesday

    • 3 = Wednesday

    • 4 = Thursday

    • 5 = Friday

    • 6 = Saturday

  • ActiveStartHour: for high usage days, time when Maximum SCU count should be applied

  • ActiveEndHour: for high usage days, time when Minimum SCU count should be applied

  • TimeOffset: Hour offset from UTC. This is leveraged to ensure Copilot for Security is operating in the desired local time, and is paired with the workbook to validate offset to local comparison.

A screenshot of the Edit tab displaying schedule configurations with a cost comparison

When the Scaler logic app triggers, it scans the environment for Copilot for Security Compute Capacities with the CopilotforSecurityConfig tag using the permissions assigned to its managed identity. To align with the principles of least-privilege, instructions are provided for creation of a custom role.

For each of these Compute Capacities the logic app extracts the config from the tag, then evaluates the current time/date against the contents and if necessary, applies the change to the Compute Capacity.

A screenshot of the SCU Optimizer scaler logic app

How to get started

If you’re leveraging Copilot for Security and you think this might be a good fit for your team, check out the GitHub for install instructions to give it a try!

Copilot for Security SCU Optimizer GitHub

Leave a comment below with your thoughts!