Often I see questions around how I can the auto provisioning agents capabilities (now renamed to Settings & monitoring) in Defender for Cloud via API.
Enable Defender for Cloud Auto provisioning agents via Bicep
Tag: Azure Policy
Tips on creating Azure policies for Azure SQL Databases
Azure SQL Databases is quite a big service and it is also one of the oldest. Because of these two there are a few architectural designs that you should be aware. Some of these are:
- with every SQL logical server there is a master database resource that is created. This resource is not directly managed but for example when you configure diagnostic settings on server level you need to configure those against the master database resource rather the SQL logical server
- The SKUs of Azure SQL Databases are mostly divided into DTU and vCore based. Among the vCore based we also have Hyperscale and Serverless variants. You can also have elastic pools for some SKUs and than the databases under those elastic pools inherit their SKUs. Not all Azure SQL SKUs support all of the features of the service. Some of the features that may not be available or have some limitations across different SKUs are:
- Zone redundancy
- Hybrid benefit
- Read replicas
- Failover Group support – for example not supported on Hyperscale SKUs and supported on Serverless SKUs only auto pause delay is disabled
- Geo replication
- Short term backup
- Long term backup
Among these we also have Datawarehouses (now known as Azure Synapse Analytics) which underneath are the same resource as Azure SQL databases but have completely different options.
Controlling Azure SQL Firewall Rules
Recently on Microsoft Q&A there was question on how you can control Azure SQL Firewall rule in a way that only certain IP addresses are allowed to be configured. Naturally I gave general answer that you can do that via Azure Policy. Initially I didn’t give the person an actual policy as I haven’t done such before. Of course creating Azure Policy definition can be challenging so the person asked him if I can provide him with example.
Azure Policy Policies not evaluated right away
Azure Policy has a unique feature compared to other competitors when it comes to evaluating Azure Resources. As Azure Policy is built along Azure Resource Manager (ARM) policies are in effect right away. This means if you have policy that blocks location and you try to deploy to that location a resource you will not be able to. The effect is enforced no matter if you use ARM Template Deployments, Portal, PowerShell, CLI, SDK or just plain old REST API. Of course on existing resources the policies are evaluated once 24 hours but you can of course trigger on-demand evaluation scan. The time that the scan will run depends on how many resources the policy will need to evaluate. Obviously policies that evaluate many resources (such as policies for tags or locations) will take longer (also dependable on the number of resources for the applied scope).
Azure Policy for Sending Azure Activity Logs
One of my blog readers has asked me about policy for sending Azure Activity logs to Log Analytics. As I have written before this is now possible via diagnostic settings at subscription level and thus is easier to make this into policy.
Cloud Administrator in Azure World 