Azure – Struggling to understand why a VM is so expensive

Azure Log Analytics Workspace Limitations

Unfortunately, this is not currently possible. Azure does not yet support the following:

1. Send logs from one Workspace to another
2. Migrate logs from one Workspace to another

For cost-cutting purposes, we wanted to migrate a Workspace from a certain region, to East US region, because the cost is (EDIT: used to be lower. Somewhere in mid 2021, cost in other regions have reduced to be on par with EUS) 40% lower in EUS. Once we had setup the new Workspace, we tried to ask support for help in moving logs from the old Workspace to the new one but were told it's not possible and to just keep the old Log Analytics Workspace data long enough for the data to just get removed automatically, after the retention period expiry. We explored both options with the Azure team but were told that none of them were supported.

Considerations

1. Sending all event logs will definitely have an impact on the cost. Wouldn't recommend this approach. Instead you can try to filter the logs at source.

2. You're right LA data export is only for Event Hub, Storage Accounts. It does not support sending logs to another Workspace.

3. I just learnt about the new Azure Monitor agent - it looks promising but as you mentioned, is still in preview.

4. As a best practice, Azure recommends to keep the Sentinel Workspaces to one. Here are some pros and cons of this. The wordings here can be confusing. A Sentinel Workspace just refers to the LA Workspace attached to it, not an actual instance of Sentinel. However, depending on the business needs, more than one should be fine, with the other considerations in mind.

Solutions

Option 1

You could have a Powershell script filter and collect the logs locally, and then forward them to your LA Workspace via the Azure Monitor API. This is probably the best approach as it would avoid you changing your Azure setup but requires a bit of work.

Option 2

You can still consider the option of creating a second LA Workspace just for the limited SQL-related logs. You actually do not need to create a second Azure Sentinel instance for this. You only need to make sure your second Workspace is 'linked' to your single Sentinel instance. We're currently using two LA Workspaces attached to a single Sentinel instance. The downside as you mentioned is that you'll still need to do the cross-workspace queries to query data across Workspaces - this is not as tough as it sounds, but there could be some slight latency, amongst other limitations, when doing cross-workspace queries. See, use-case for multiple Sentinel Workspaces.

Option 3

Azure recommends to use Azure Lighthouse to consolidate Sentinel management in one interface. There is no additional cost for using Azure Lighthouse and although this is a product that targets service providers, enterprise customers can also leverage it. This option will still require you to have a second LA Workspace. I'm putting this as the last option as, although it can help with automation, it's also an extra step on top of Option 2.

Checking the X-Azure-FDID header, in combination with the IP restriction is the only way to lock this down currently without going down the private link route. So you would need to get your application code to validate that, given you don't have anything else in-between FD and the storage account.

Whilst having this in your client side code would expose the ID, it doesn't really matter. The IP restrictions mean that your only allow traffic from Front Door instances, and there is no way for an attacker to set that ID on a different FD instance.