Someone asked me the other day about deleting Azure Sentinel from their subscription, because as of November 1 2019, billing will start for this service since it hit GA last week, and they've ingested quite a lot of data that wouldn't be ideal to pay for since it's part of a large-scale test of the service reliability. They want to keep the data since they use it to fine-tune other systems and integrations too, before deciding on a go-live.
Take caution when you make any modifications to services you have running in production. With that in mind, please read the entire post including the summary before you actually delete anything.
Disconnecting the connected solutions from Azure Sentinel
Since the requirement is about keeping the ingested data, but to remove the integration between Azure Sentinel and the LAW (Log Analytics Workspace), we don't want to actually delete everything - just disconnect them to avoid the cost.
Let's keep this short. Here's how you can disconnect Azure Sentinel from your LAW.
First, head on over to your Azure Sentinel service and then click "Workspace settings"
From this view, select "Solutions".
Listed on this page are all the connected solutions. Depending on how many connectors and data sources you have, this will look different for you. You can select what you want to disconnect from your Azure Sentinel by removing the appropriate solutions from the list.
Click the solution you want to remove.
Now, ensure that this is really the solution that you really want to remove. I emphasize this as it's likely not a good idea to disconnect something that you would like to keep. Be sure you're doing the right thing, then continue by clicking "Delete".
Query the data from your Log Analytics Workspace
The data remains, because we just removed the solution that connects Azure Sentinel to the Azure Log Analytics workspace. Looking at the workspace and making a query, we see that all the data still remains. Great.
This was a simple tip for how to disconnect your ingested data from the Azure Sentinel service in your directory. I hope it can help someone benefit from the experience.
I also recommend that you run a couple of dry-runs in your separate test and staging subscriptions before you make changes to workloads and services that have a lot of data. Because you do have those environments to test things out, right? :)
Read more about Azure Sentinel: