Contents

Azure SQL Documentation

Azure SQL
What is Azure SQL?
Migrate to Azure SQL
Shared SQL DB & SQL MI docs
Purchasing models
Overview
vCore model overview
Azure Hybrid Benefit
Reserved capacity
Compute & storage
Overview
General purpose / Standard
Business critical / Premium
Shared concepts
Feature comparison
Multi-model features
Scheduled maintenance
Maintenance window
Configure maintenance window
Maintenance window FAQ
Advance notifications
In-memory OLTP
Temporal tables
Scale up / down
Read Scale-Out
Distributed transactions
Security
Overview
 Best practices
Security controls by Azure Policy
Security baseline
Always Encrypted
Microsoft Defender for SQL
Advanced Threat Protection
Data discovery and classification
Dynamic data masking
SQL Vulnerability Assessment
SQL Vulnerability Assessment
Vulnerability Assessment rules
Vulnerability Assessment rules changelog
Store vulnerability scans in storage
Logins, user accounts, roles, and permissions
Azure AD Authentication
Configure Azure AD auth
Multi-factor Azure AD auth
Configure multi-factor auth
Conditional Access
Service principals (Applications)
Directory Readers role
Azure AD-only authentication
Azure Policy for Azure AD-only authentication
Transparent Data Encryption (TDE)
Overview
Bring Your Own Key (BYOK)
Business continuity
Overview
High availability
Auto-failover groups
Backup and recovery
Automated backups
 Accelerated database recovery
Recovery using backups
Long-term backup retention
Monitor and tune
Documentation
Overview
Intelligent Insights
SQL Analytics
Automatic tuning
In-memory OLTP
Extended events
Extended events
Extended events - event file
Extended events - ring buffer
Shared how-to's
Job automation with elastic jobs
Job automation with SQL Agent
Connect and query from apps
.NET with Visual Studio
.NET Core
Go
Node.js
PHP
Python
Ruby
Business continuity
Configure failover group
Configure temporal retention policy
Configure backup retention using Azure Blob storage
Security
Azure AD Authentication
Create Azure AD guest users and set as an Azure AD admin
 Assign Directory Readers role to groups
Enable Azure AD-only authentication
Enforce Azure AD-only authentication using Azure Policy
Create server with Azure AD-only authentication enabled
Configure TDE with BYOK
Always Encrypted
Use the Azure key vault
Use the certificate store
Monitor & tune
Identify query performance issues
Troubleshoot performance issues
Batching for performance
Load data with BCP
Application and database tuning guidance
Use DMVs to monitor performance
Understand and resolve blocking
Configure the max degree of parallelism (MAXDOP)
Log diagnostic telemetry
In-memory OLTP
Configure In-Memory OLTP
Try in-memory features
Monitor In-memory OLTP space
Load and move data
Import a database from a BACPAC file
Export a database to a BACPAC file
Move resources to a new region
Load data with ADF
Develop data applications
Overview
Working with JSON data
Use Spark Connector
Use ASP.NET App Service
 Use Azure Functions
Use Azure Logic Apps
Index with Azure Cognitive Search
Server-side CLR/.NET integration
Java
Use Java and JDBC
Use Spring Data JDBC
Use Spring Data JPA
Use Spring Data R2DBC
SQL Database (SQL DB)
Documentation
Overview
What is SQL Database?
What's new?
Single databases
Elastic pools
Logical SQL servers
Service Tiers
Serverless
DTU model overview
Hyperscale
Hyperscale FAQ
Hyperscale replicas
Hyperscale replicas FAQ
vCore
Plan and manage costs
Quickstarts
Create database
Azure portal, PowerShell, Az CLI
ARM template
With ledger and digest storage
Configure
 Server-level IP firewall rules
GitHub Actions
Tutorials
Design a database
Design database using SSMS
Design database using .NET
Business continuity
Add db to failover group
Add pool to failover group
Configure security for replicas
Geo-distributed application
Active geo-replication
Security
Always Encrypted with secure enclaves
Configure security
Create users using service principals
Rotate TDE BYOK keys
Remove TDE protector
Move data
Migrate using DMS
Set up SQL Data Sync
Migrate SQLite to serverless
Scale out
Configure security for named replicas
Migration guides
From Access
From Db2
From Oracle
From MySQL
From SAP ASE
From SQL Server
Overview
 Migrate
Assessment rules
Concepts
Connectivity architecture
Connectivity settings
T-SQL differences
Azure Automation
Elastic queries
Elastic transactions
Resource management
Single database resources
vCore resource limits
DTU resource limits
Elastic pool resources
vCore resource limits
DTU resource limits
Logical SQL server resources
Database resource limits
Business continuity
Active geo-replication
Outage recovery guidance
Recovery drills
SQL Data Sync
Overview
Data Sync Agent
Best practices for Data Sync
Troubleshoot Data Sync
Security
Always Encrypted
Always Encrypted with secure enclaves
Configure and use Always Encrypted with secure enclaves >
Plan for Intel SGX enclaves and attestation
 Enable Intel SGX
Configure Azure Attestation
Azure SQL Auditing
Audit log format
DNS aliases
Ledger
Ledger
Ledger overview
Database ledger
Updatable ledger tables
Append-only ledger tables
Digest management and database verification
Ledger auditing
Ledger limitations
Network access controls
Outbound firewall rules
Private Link
VNet endpoints
Server roles
Database sharding
Database sharding
Glossary
Elastic client library
Shard maps
Query routing
Manage credentials
Move sharded data
Elastic tools FAQ
How to
Connect and query
Connect and run ad-hoc queries
Azure Data Studio
 SSMS
Azure portal
VS Code
Connect and query from apps
.NET with Active Directory MFA
Java
Java with Spring Data JDBC
Java with Spring Data JPA
Java with Spring Data R2DBC
Manage
Management API reference
DNS alias PowerShell
Manage file space
Use Resource Health for connectivity issues
Migrate DTU to vCore
Scale database resources
Scale pool resources
Manage pool resources
Resource management in dense elastic pools
Hyperscale performance diagnostics
Block T-SQL CRUD
Secure
Audit to storage account behind VNet or firewall
Configure threat detection
Configure dynamic data masking
IP-based firewall
Ledger
Create append-only ledger tables
Create updatable ledger tables
Access Azure Confidential Ledger digest
Verify ledger database for tampering
vNet endpoints - PowerShell
Business continuity
Configure backup retention using Azure Blob storage
Configure geo-replication - Portal
Configure security for geo-replicas
Performance
Use Query Performance Insights
Enable automatic tuning
Enable e-mail notifications for automatic tuning
Apply performance recommendations
Create alerts
Implement database advisor recommendations
Stream data with Stream Analytics
Load and move data
Migrate to SQL Database
Manage SQL Database after migration
Import/export (allow Azure services disabled)
Import a database from a BACPAC file
Copy a database within Azure
Replicate to SQL Database
Replicate schema changes (Data sync)
Database sharding
Upgrade client library
Create sharded app
Query horizontally-sharded data
Multi-shard queries
Move sharded data
Security configuration
Add a shard
Fix shard map problems
Migrate sharded database
Create counters
Use entity framework
 Use Dapper framework
Query distributed data
Query vertically partitioned data
Report across scaled-out data tier
Query across tables with different schemas
Elastic jobs (preview)
Configure jobs
Create and manage (PowerShell)
Create and manage (T-SQL)
Migrate (from old Elastic jobs)
Design data applications
Authenticate app
Design for disaster recovery
Design for elastic pools
Design for app upgrades
C and C ++
Excel
Ports - ADO.NET
Multi-tenant SaaS
SaaS design patterns
SaaS video indexer
SaaS app security
Multi-tenant SaaS sample application
Wingtip Tickets sample
General guidance
Single application
Database per tenant
Disaster recovery using geo-restore
Disaster recovery using database geo-replication
Multi-tenant database
Deploy example app
Provision tenants
 Monitor database performance
Run ad-hoc queries
Manage tenant schema
ETL for analytics
Samples
Azure CLI
Azure PowerShell
Azure Resource Manager
Code samples
Azure Resource Graph queries
SQL Managed Instance (SQL MI)
Documentation
Overview
What is SQL Managed Instance?
What's new?
Instance pools
Frequently asked questions
Quickstarts
Create SQL Managed Instance
Azure portal
PowerShell
ARM template
Create instance pools
Configure
Service-aided subnet configuration
Public endpoint
Minimal TLS version
Client VM connection
Point-to-site connection
Long-term backup retention
Load data
Restore sample database
Tutorials
Migrate using DMS
Configure security
Add instance to failover group
Migrate on-premises users and groups
Transactional replication
MI pub to MI sub
MI pub, MI dist, SQL sub
Migration guides
From Db2
From Oracle
From SQL Server
Overview
Migrate
Performance baseline
Assessment rules
Concepts
Resource limits
Compute Hardware
Connectivity architecture
T-SQL differences
Transactional replication
Link feature for SQL MI
Management operations
Overview
Monitor operations
Cancel operations
API reference
Machine Learning Services
Overview
Key differences
Quickstarts
 Python
Run Python scripts
Data structures and objects
Python functions
Train and score a model
Deploy ONNX models
R
Run R scripts
Data types and objects
R functions
Train and score a model
Tutorials
Python
Ski rental (linear regression)
Categorize customers (k-means clustering)
NYC taxi tips (classification)
R
Ski rental (decision tree)
Categorize customers (k-means clustering)
NYC taxi tips (classification)
How to
Data exploration and modeling
Python
Data type conversions
Python to SQL
R to SQL
Deploy
Operationalize using stored procedures
Convert R code for SQL Server
Create a stored procedure using sqlrutils
Predictions
Native scoring with PREDICT T-SQL
 Package management
Install new Python packages
Install new R packages
Administration
Monitor
Security
Give users permission
Features
Linked servers
Service Broker
Database mail
Security
Always Encrypted
Auditing
Secure public endpoints
Server trust groups
How to
How-to documentation
Connect applications
Configure settings
Customize time zone
Configure connection types
Create alerts on SQL MI
Configure threat detection
Configure networking
Determine size of SQL MI subnet
Create new VNet and subnet for SQL MI
Configure existing VNet and subnet for SQL MI
Configure service endpoint policies for SQL MI
Move SQL MI to another subnet
Delete subnet after deleting SQL MI
Configure custom DNS
 Sync DNS configuration
Sync network configuration
Find management endpoint IP address
Verify built-in firewall protection
Migrate
Migrate SQL Server to SQL MI Guide
Migrate database using Log Replay Service
Migrate TDE cert
Configure business continuity
Restore to a point in time
Monitor back up
Manually initiate a failover on managed instance
Samples
Azure CLI
Azure PowerShell
Azure Resource Manager
Code samples
SQL Server on Azure VMs
Documentation
What's new?
Windows
Overview
What is a SQL Server VM?
Quickstarts
Portal
PowerShell
ARM template
Concepts
Business continuity
Overview
Backup and restore
Azure Storage for backup
 Availability group (AG)
Failover cluster instance (FCI)
Windows Server Failover Cluster
Best practices
Quick checklist
VM size
Storage
Security
HADR configuration
Application patterns
Collect baseline
Management
SQL IaaS Agent extension
Dedicated host
Extend support for SQL 2008 & R2
How-to guides
Connect to SQL Server VM
Create SQL Server VM
Use the portal
Use Azure PowerShell
Manage
With the Azure portal
License model
Change edition
Change version
Storage
Automated Patching
SQL Assessment
Azure Key Vault Integration
Migrate storage to UltraSSD
SQL IaaS Agent extension
Automatic registration
 Register single VM
Bulk register multiple VMs
Migrate
SQL Server database to VM
VM to a new region
Business continuity
Configure cluster quorum
Backup and restore
Automated backup (SQL 2016+)
Automated backup (SQL 2014)
Availability group (AG)
Configure AG (multi-subnet)
Configure AG (single subnet)
Failover cluster instance (FCI)
Prepare VM for FCI
Create FCI
Configure connectivity (Single subnet)
Reference
Azure PowerShell
Azure CLI
T-SQL
SQL Server Drivers
REST
Azure Policy built-ins
Resources
FAQ
Pricing
Archived classic RM docs
SQL Server Data Tools (SSDT)
SQL Server Management Studio (SSMS)
SQL Server Tools
Azure Roadmap
 MSDN forum
Stack Overflow
Linux
Overview
About Linux SQL Server VMs
Quickstarts
Create SQL VM - Portal
Concepts
SQL IaaS agent extension
How-to guides
Register with SQL IaaS extension
Tutorials
Setting up Azure RHEL VM availability group with STONITH
Configure availability group listener for SQL Server on RHEL virtual machines in
Azure
Setup Always On availability group with DH2i DxEnterprise
Resources
FAQ
SQL Server on Linux Documentation
SQL Server Data Tools (SSDT)
SQL Server Tools
Azure Roadmap
Stack Overflow
Migration guides
From Db2
From Oracle
From SQL Server
Overview
Migration guide
Availability group (AG)
Failover cluster instance (FCI)
Reference
T-SQL language reference
 Azure CLI
Azure PowerShell
.NET
Java
REST
Resource Manager templates for SQL
SQL tools
SQL Server Management Studio (SSMS)
SQL Server Data Tools (SSDT)
BCP
SQLCMD
SqlPackage
SQL Database Management Library package
SQL connection drivers
SQL Server drivers
ADO.NET
JDBC
Node.js
ODBC
PHP
Python
Ruby
Azure Policy built-ins
Resources
Build your skills with Microsoft Learn
SQL Server Blog
Microsoft Azure Blog
Azure Roadmap
Public data sets
Pricing
MSDN forum
Stack Overflow
Troubleshoot
Known issues with SQL Managed Instance
Capacity errors during deployment
Connectivity errors
Common connection issues
Troubleshoot out of memory errors
Import/Export service hangs
Transaction log errors
Request quota increases
Service updates
SSL root certificate expiring
Gateway IP address updates
Periodic maintenance events
Videos
Service updates
Architecture center
Customer stories
 What is Azure SQL?
12/6/2021 • 18 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance SQL Server on Azure VM
Azure SQL is a family of managed, secure, and intelligent products that use the SQL Server database engine in
the Azure cloud.
Azure SQL Database : Support modern cloud applications on an intelligent, managed database service, that
includes serverless compute.
Azure SQL Managed Instance : Modernize your existing SQL Server applications at scale with an
intelligent fully managed instance as a service, with almost 100% feature parity with the SQL Server
database engine. Best for most migrations to the cloud.
SQL Ser ver on Azure VMs : Lift-and-shift your SQL Server workloads with ease and maintain 100% SQL
Server compatibility and operating system-level access.
Azure SQL is built upon the familiar SQL Server engine, so you can migrate applications with ease and continue
to use the tools, languages, and resources you're familiar with. Your skills and experience transfer to the cloud,
so you can do even more with what you already have.
Learn how each product fits into Microsoft's Azure SQL data platform to match the right option for your
business requirements. Whether you prioritize cost savings or minimal administration, this article can help you
decide which approach delivers against the business requirements you care about most.
Survey to improve Azure SQL!
If you're new to Azure SQL, check out the What is Azure SQL video from our in-depth Azure SQL video series:

Overview
In today's data-driven world, driving digital transformation increasingly depends on our ability to manage
massive amounts of data and harness its potential. But today's data estates are increasingly complex, with data
hosted on-premises, in the cloud, or at the edge of the network. Developers who are building intelligent and
immersive applications can find themselves constrained by limitations that can ultimately impact their
experience. Limitations arising from incompatible platforms, inadequate data security, insufficient resources and
price-performance barriers create complexity that can inhibit app modernization and development.
One of the first things to understand in any discussion of Azure versus on-premises SQL Server databases is
that you can use it all. Microsoft's data platform leverages SQL Server technology and makes it available across
physical on-premises machines, private cloud environments, third-party hosted private cloud environments, and
the public cloud.
Fully managed and always up to date
Spend more time innovating and less time patching, updating, and backing up your databases. Azure is the only
cloud with evergreen SQL that automatically applies the latest updates and patches so that your databases are
always up to date—eliminating end-of-support hassle. Even complex tasks like performance tuning, high
availability, disaster recovery, and backups are automated, freeing you to focus on applications.
Protect your data with built-in intelligent security
Azure constantly monitors your data for threats. With Azure SQL, you can:
 Remediate potential threats in real time with intelligent advanced threat detection and proactive vulnerability
assessment alerts.
Get industry-leading, multi-layered protection with built-in security controls including T-SQL, authentication,
networking, and key management.
Take advantage of the most comprehensive compliance coverage of any cloud database service.
Business motivations
There are several factors that can influence your decision to choose between the different data offerings:
Cost: Both PaaS and IaaS option include base price that covers underlying infrastructure and licensing.
However, with IaaS option you need to invest additional time and resources to manage your database, while
in PaaS you get these administration features included in the price. IaaS enables you to shut down resources
while you are not using them to decrease the cost, while PaaS is always running unless you drop and re-
create your resources when they are needed.
Administration: PaaS options reduce the amount of time that you need to invest to administer the database.
However, it also limits the range of custom administration tasks and scripts that you can perform or run. For
example, the CLR is not supported with SQL Database, but is supported for an instance of SQL Managed
Instance. Also, no deployment options in PaaS support the use of trace flags.
Service-level agreement: Both IaaS and PaaS provide high, industry standard SLA. PaaS option guarantees
99.99% SLA, while IaaS guarantees 99.95% SLA for infrastructure, meaning that you need to implement
additional mechanisms to ensure availability of your databases. You can attain 99.99% SLA by creating an
additional SQL virtual machine, and implementing the SQL Server Always On availability group high
availability solution.
Time to move to Azure: SQL Server on Azure VM is the exact match of your environment, so migration from
on-premises to the Azure VM is no different than moving the databases from one on-premises server to
another. SQL Managed Instance also enables easy migration; however, there might be some changes that you
need to apply before your migration.

Service comparison

As seen in the diagram, each service offering can be characterized by the level of administration you have over
the infrastructure, and by the degree of cost efficiency.
In Azure, you can have your SQL Server workloads running as a hosted service (PaaS), or a hosted infrastructure
(IaaS). Within PaaS, you have multiple product options, and service tiers within each option. The key question
that you need to ask when deciding between PaaS or IaaS is do you want to manage your database, apply
patches, and take backups, or do you want to delegate these operations to Azure?
Azure SQL Database
Azure SQL Database is a relational database-as-a-service (DBaaS) hosted in Azure that falls into the industry
category of Platform-as-a-Service (PaaS).
Best for modern cloud applications that want to use the latest stable SQL Server features and have time
constraints in development and marketing.
A fully managed SQL Server database engine, based on the latest stable Enterprise Edition of SQL Server.
SQL Database has two deployment options built on standardized hardware and software that is owned,
hosted, and maintained by Microsoft.
With SQL Server, you can use built-in features and functionality that requires extensive configuration (either on-
premises or in an Azure virtual machine). When using SQL Database, you pay-as-you-go with options to scale
up or out for greater power with no interruption. SQL Database has some additional features that are not
available in SQL Server, such as built-in high availability, intelligence, and management.
Azure SQL Database offers the following deployment options:
As a single database with its own set of resources managed via a logical SQL server. A single database is
similar to a contained database in SQL Server. This option is optimized for modern application development
of new cloud-born applications. Hyperscale and serverless options are available.
An elastic pool, which is a collection of databases with a shared set of resources managed via a logical SQL
server. Single databases can be moved into and out of an elastic pool. This option is optimized for modern
application development of new cloud-born applications using the multi-tenant SaaS application pattern.
Elastic pools provide a cost-effective solution for managing the performance of multiple databases that have
variable usage patterns.
Azure SQL Managed Instance
Azure SQL Managed Instance falls into the industry category of Platform-as-a-Service (PaaS), and is best for
most migrations to the cloud. SQL Managed Instance is a collection of system and user databases with a shared
set of resources that is lift-and-shift ready.
Best for new applications or existing on-premises applications that want to use the latest stable SQL Server
features and that are migrated to the cloud with minimal changes. An instance of SQL Managed Instance is
similar to an instance of the Microsoft SQL Server database engine offering shared resources for databases
and additional instance-scoped features.
SQL Managed Instance supports database migration from on-premises with minimal to no database change.
This option provides all of the PaaS benefits of Azure SQL Database but adds capabilities that were
previously only available in SQL Server VMs. This includes a native virtual network and near 100%
compatibility with on-premises SQL Server. Instances of SQL Managed Instance provide full SQL Server
access and feature compatibility for migrating SQL Servers to Azure.
SQL Server on Azure VM
SQL Server on Azure VM falls into the industry category Infrastructure-as-a-Service (IaaS) and allows you to
run SQL Server inside a fully managed virtual machine (VM) in Azure.
SQL Server installed and hosted in the cloud runs on Windows Server or Linux virtual machines running on
Azure, also known as an infrastructure as a service (IaaS). SQL virtual machines are a good option for
migrating on-premises SQL Server databases and applications without any database change. All recent
versions and editions of SQL Server are available for installation in an IaaS virtual machine.
Best for migrations and applications requiring OS-level access. SQL virtual machines in Azure are lift-and-
shift ready for existing applications that require fast migration to the cloud with minimal changes or no
changes. SQL virtual machines offer full administrative control over the SQL Server instance and underlying
OS for migration to Azure.
 The most significant difference from SQL Database and SQL Managed Instance is that SQL Server on Azure
Virtual Machines allows full control over the database engine. You can choose when to start
maintenance/patching, change the recovery model to simple or bulk-logged, pause or start the service when
needed, and you can fully customize the SQL Server database engine. With this additional control comes the
added responsibility to manage the virtual machine.
Rapid development and test scenarios when you do not want to buy on-premises non-production SQL
Server hardware. SQL virtual machines also run on standardized hardware that is owned, hosted, and
maintained by Microsoft. When using SQL virtual machines, you can either pay-as-you-go for a SQL Server
license already included in a SQL Server image or easily use an existing license. You can also stop or resume
the VM as needed.
Optimized for migrating existing applications to Azure or extending existing on-premises applications to the
cloud in hybrid deployments. In addition, you can use SQL Server in a virtual machine to develop and test
traditional SQL Server applications. With SQL virtual machines, you have the full administrative rights over a
dedicated SQL Server instance and a cloud-based VM. It is a perfect choice when an organization already has
IT resources available to maintain the virtual machines. These capabilities allow you to build a highly
customized system to address your application’s specific performance and availability requirements.
Comparison table
Additional differences are listed in the following table, but both SQL Database and SQL Managed Instance are
optimized to reduce overall management costs to a minimum for provisioning and managing many databases.
Ongoing administration costs are reduced since you do not have to manage any virtual machines, operating
system, or database software. You do not have to manage upgrades, high availability, or backups.
In general, SQL Database and SQL Managed Instance can dramatically increase the number of databases
managed by a single IT or development resource. Elastic pools also support SaaS multi-tenant application
architectures with features including tenant isolation and the ability to scale to reduce costs by sharing
resources across databases. SQL Managed Instance provides support for instance-scoped features enabling
easy migration of existing applications, as well as sharing resources among databases. Whereas, SQL Server on
Azure VMs provide DBAs with an experience most similar to the on-premises environment they're familiar with.

A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E SQ L SERVER O N A Z URE VM

Supports most on-premises database- Supports almost all on-premises You have full control over the SQL
level capabilities. The most commonly instance-level and database-level Server engine. Supports all on-
used SQL Server features are available. capabilities. High compatibility with premises capabilities.
99.995% availability guaranteed. SQL Server. Up to 99.99% availability.
Built-in backups, patching, recovery. 99.99% availability guaranteed. Full parity with the matching version of
Latest stable Database Engine version. Built-in backups, patching, recovery. on-premises SQL Server.
Ability to assign necessary resources Latest stable Database Engine version. Fixed, well-known Database Engine
(CPU/storage) to individual databases. Easy migration from SQL Server. version.
Built-in advanced intelligence and Private IP address within Azure Virtual Easy migration from SQL Server.
security. Network. Private IP address within Azure Virtual
Online change of resources Built-in advanced intelligence and Network.
(CPU/storage). security. You have the ability to deploy
Online change of resources application or services on the host
(CPU/storage). where SQL Server is placed.
 A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E SQ L SERVER O N A Z URE VM

Migration from SQL Server might be There is still some minimal number of You need to manage your backups and
challenging. SQL Server features that are not patches.
Some SQL Server features are not available. You need to implement your own
available. No guaranteed exact maintenance High-Availability solution.
No guaranteed exact maintenance time (but nearly transparent). There is a downtime while changing
time (but nearly transparent). Compatibility with the SQL Server the resources(CPU/storage)
Compatibility with the SQL Server version can be achieved only using
version can be achieved only using database compatibility levels.
database compatibility levels.
Private IP address support with Azure
Private Link.

Databases of up to 100 TB. Up to 16 TB. SQL Server instances with up to 256

TB of storage. The instance can
support as many databases as needed.

On-premises application can access Native virtual network implementation With SQL virtual machines, you can
data in Azure SQL Database. and connectivity to your on-premises have applications that run partly in the
environment using Azure Express cloud and partly on-premises. For
Route or VPN Gateway. example, you can extend your on-
premises network and Active Directory
Domain to the cloud via Azure Virtual
Network. For more information on
hybrid cloud solutions, see Extending
on-premises data solutions to the
cloud.

Cost
Whether you're a startup that is strapped for cash, or a team in an established company that operates under
tight budget constraints, limited funding is often the primary driver when deciding how to host your databases.
In this section, you learn about the billing and licensing basics in Azure associated with the Azure SQL family of
services. You also learn about calculating the total application cost.
Billing and licensing basics
Currently, both SQL Database and SQL Managed Instance are sold as a service and are available with
several options and in several service tiers with different prices for resources, all of which are billed hourly at a
fixed rate based on the service tier and compute size you choose. For the latest information on the current
supported service tiers, compute sizes, and storage amounts, see DTU-based purchasing model for SQL
Database and vCore-based purchasing model for both SQL Database and SQL Managed Instance.
With SQL Database, you can choose a service tier that fits your needs from a wide range of prices starting
from 5$/month for basic tier and you can create elastic pools to share resources among databases to reduce
costs and accommodate usage spikes.
With SQL Managed Instance, you can also bring your own license. For more information on bring-your-own
licensing, see License Mobility through Software Assurance on Azure or use the Azure Hybrid Benefit
calculator to see how to save up to 40% .
In addition, you are billed for outgoing Internet traffic at regular data transfer rates. You can dynamically adjust
service tiers and compute sizes to match your application’s varied throughput needs.
With SQL Database and SQL Managed Instance , the database software is automatically configured, patched,
and upgraded by Azure, which reduces your administration costs. In addition, its built-in backup capabilities help
you achieve significant cost savings, especially when you have a large number of databases.
With SQL on Azure VMs , you can use any of the platform-provided SQL Server images (which includes a
license) or bring your SQL Server license. All the supported SQL Server versions (2008R2, 2012, 2014, 2016,
2017, 2019) and editions (Developer, Express, Web, Standard, Enterprise) are available. In addition, Bring-Your-
Own-License versions (BYOL) of the images are available. When using the Azure provided images, the
operational cost depends on the VM size and the edition of SQL Server you choose. Regardless of VM size or
SQL Server edition, you pay per-minute licensing cost of SQL Server and the Windows or Linux Server, along
with the Azure Storage cost for the VM disks. The per-minute billing option allows you to use SQL Server for as
long as you need without buying addition SQL Server licenses. If you bring your own SQL Server license to
Azure, you are charged for server and storage costs only. For more information on bring-your-own licensing,
see License Mobility through Software Assurance on Azure. In addition, you are billed for outgoing Internet
traffic at regular data transfer rates.
Calculating the total application cost
When you start using a cloud platform, the cost of running your application includes the cost for new
development and ongoing administration costs, plus the public cloud platform service costs.
For more information on pricing, see the following resources:
SQL Database & SQL Managed Instance pricing
Virtual machine pricing for SQL and for Windows
Azure Pricing Calculator

Administration
For many businesses, the decision to transition to a cloud service is as much about offloading complexity of
administration as it is cost. With IaaS and PaaS, Azure administers the underlying infrastructure and
automatically replicates all data to provide disaster recovery, configures and upgrades the database software,
manages load balancing, and does transparent failover if there is a server failure within a data center.
With SQL Database and SQL Managed Instance , you can continue to administer your database, but you
no longer need to manage the database engine, the operating system, or the hardware. Examples of items
you can continue to administer include databases and logins, index and query tuning, and auditing and
security. Additionally, configuring high availability to another data center requires minimal configuration and
administration.
With SQL on Azure VM , you have full control over the operating system and SQL Server instance
configuration. With a VM, it's up to you to decide when to update/upgrade the operating system and
database software and when to install any additional software such as anti-virus. Some automated features
are provided to dramatically simplify patching, backup, and high availability. In addition, you can control the
size of the VM, the number of disks, and their storage configurations. Azure allows you to change the size of
a VM as needed. For information, see Virtual Machine and Cloud Service Sizes for Azure.

Service-level agreement (SLA)

For many IT departments, meeting up-time obligations of a service-level agreement (SLA) is a top priority. In
this section, we look at what SLA applies to each database hosting option.
For both Azure SQL Database and Azure SQL Managed Instance , Microsoft provides an availability SLA of
99.99%. For the latest information, see Service-level agreement.
For SQL on Azure VM , Microsoft provides an availability SLA of 99.95% that covers just the virtual machine.
This SLA does not cover the processes (such as SQL Server) running on the VM and requires that you host at
least two VM instances in an availability set. For the latest information, see the VM SLA. For database high
availability (HA) within VMs, you should configure one of the supported high availability options in SQL Server,
such as Always On availability groups. Using a supported high availability option doesn't provide an additional
SLA, but allows you to achieve >99.99% database availability.
Time to move to Azure
Azure SQL Database is the right solution for cloud-designed applications when developer productivity and
fast time-to-market for new solutions are critical. With programmatic DBA-like functionality, it is perfect for
cloud architects and developers as it lowers the need for managing the underlying operating system and
database.
Azure SQL Managed Instance greatly simplifies the migration of existing applications to Azure, enabling you
to bring migrated database applications to market in Azure quickly.
SQL on Azure VM is perfect if your existing or new applications require large databases or access to all
features in SQL Server or Windows/Linux, and you want to avoid the time and expense of acquiring new on-
premises hardware. It is also a good fit when you want to migrate existing on-premises applications and
databases to Azure as-is - in cases where SQL Database or SQL Managed Instance is not a good fit. Since you do
not need to change the presentation, application, and data layers, you save time and budget on re-architecting
your existing solution. Instead, you can focus on migrating all your solutions to Azure and in doing some
performance optimizations that may be required by the Azure platform. For more information, see Performance
Best Practices for SQL Server on Azure Virtual Machines.

Create and manage Azure SQL resources with the Azure portal
The Azure portal provides a single page where you can manage all of your Azure SQL resources including your
SQL virtual machines.
To access the Azure SQL page, from the Azure portal menu, select Azure SQL or search for and select Azure
SQL in any page.

NOTE
Azure SQL provides a quick and easy way to access all of your SQL resources in the Azure portal, including single and
pooled database in Azure SQL Database as well as the logical SQL server hosting them, SQL Managed Instances, and SQL
virtual machines. Azure SQL is not a service or resource, but rather a family of SQL-related services.

To manage existing resources, select the desired item in the list. To create new Azure SQL resources, select +
Add .
After selecting + Add , view additional information about the different options by selecting Show details on
any tile.

For details, see:

Create a single database
Create an elastic pool
Create a managed instance
 Create a SQL virtual machine

Next steps
See Your first Azure SQL Database to get started with SQL Database.
See Your first Azure SQL Managed Instance to get started with SQL Managed Instance.
See SQL Database pricing.
See Azure SQL Managed Instance pricing.
See Provision a SQL Server virtual machine in Azure to get started with SQL Server on Azure VMs.
Identify the right SQL Database or SQL Managed Instance SKU for your on-premises database.
 Choose between the vCore and DTU purchasing
models - Azure SQL Database and SQL Managed
Instance
12/6/2021 • 12 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database and Azure SQL Managed Instance let you easily purchase a fully managed platform as a
service (PaaS) database engine that fits your performance and cost needs. Depending on the deployment model
you've chosen for Azure SQL Database, you can select the purchasing model that works for you:
Virtual core (vCore)-based purchasing model (recommended). This purchasing model provides a choice
between a provisioned compute tier and a serverless compute tier. With the provisioned compute tier, you
choose the exact amount of compute resources that are always provisioned for your workload. With the
serverless compute tier, you specify the autoscaling of the compute resources over a configurable compute
range. With this compute tier, you can also automatically pause and resume the database based on workload
activity. The vCore unit price per unit of time is lower in the provisioned compute tier than it is in the
serverless compute tier.
Database transaction unit (DTU)-based purchasing model. This purchasing model provides bundled compute
and storage packages balanced for common workloads.
Survey to improve Azure SQL!
There are two purchasing models:
vCore-based purchasing model is available for both Azure SQL Database and Azure SQL Managed Instance.
The Hyperscale service tier is available for single databases that are using the vCore-based purchasing
model.
DTU-based purchasing model is available for Azure SQL Database.
The following table and chart compare and contrast the vCore-based and the DTU-based purchasing models:

P URC H A SIN G M O DEL DESC RIP T IO N B EST F O R

DTU-based This model is based on a bundled Customers who want simple,

measure of compute, storage, and I/O preconfigured resource options
resources. Compute sizes are
expressed in DTUs for single databases
and in elastic database transaction
units (eDTUs) for elastic pools. For
more information about DTUs and
eDTUs, see What are DTUs and
eDTUs?.

vCore-based This model allows you to Customers who value flexibility,

independently choose compute and control, and transparency
storage resources. The vCore-based
purchasing model also allows you to
use Azure Hybrid Benefit for SQL
Server to save costs.
Want to optimize and save on your cloud spending?
Azure services cost money. Azure Cost Management helps you set budgets and configure alerts to keep
spending under control. Analyze, manage, and optimize your Azure costs with Cost Management. To learn more,
see the quickstart on analyzing your costs.

Compute costs
Provisioned compute costs
In the provisioned compute tier, the compute cost reflects the total compute capacity that is provisioned for the
application.
In the Business Critical service tier, we automatically allocate at least three replicas. To reflect this additional
allocation of compute resources, the price in the vCore-based purchasing model is approximately 2.7 times
higher in the Business Critical service tier than it is in the General Purpose service tier. Likewise, the higher
storage price per GB in the Business Critical service tier reflects the higher IO limits and lower latency of the SSD
storage.
The cost of backup storage is the same for the Business Critical service tier and the General Purpose service tier
because both tiers use standard storage for backups.
Serverless compute costs
For a description of how compute capacity is defined and costs are calculated for the serverless compute tier,
see SQL Database serverless tier.

Storage costs
Different types of storage are billed differently. For data storage, you're charged for the provisioned storage
based upon the maximum database or pool size you select. The cost doesn't change unless you reduce or
increase that maximum. Backup storage is associated with automated backups of your instance and is allocated
dynamically. Increasing your backup-retention period increases the backup storage that's consumed by your
instance.
By default, seven days of automated backups of your databases are copied to a read-access geo-redundant
storage (RA-GRS) standard Blob storage account. This storage is used by weekly full backups, daily differential
backups, and transaction log backups, which are copied every five minutes. The size of the transaction logs
depends on the rate of change of the database. A minimum storage amount equal to 100 percent of the
database size is provided at no extra charge. Additional consumption of backup storage is charged in GB per
month.
For more information about storage prices, see the pricing page.
vCore-based purchasing model
A virtual core (vCore) represents a logical CPU and offers you the option to choose between generations of
hardware and the physical characteristics of the hardware (for example, the number of cores, the memory, and
the storage size). The vCore-based purchasing model gives you flexibility, control, transparency of individual
resource consumption, and a straightforward way to translate on-premises workload requirements to the cloud.
This model allows you to choose compute, memory, and storage resources based on your workload needs.
In the vCore-based purchasing model, you can choose between the General Purpose and Business Critical
service tiers for SQL Database and SQL Managed Instance. For single databases, you can also choose the
Hyperscale service tier.
The vCore-based purchasing model lets you independently choose compute and storage resources, match on-
premises performance, and optimize price. In the vCore-based purchasing model, you pay for:
Compute resources (the service tier + the number of vCores and the amount of memory + the generation of
hardware).
The type and amount of data and log storage.
Backup storage (RA-GRS).

IMPORTANT
Compute resources, I/O, and data and log storage are charged per database or elastic pool. Backup storage is charged per
each database. For more information about SQL Managed Instance charges, see SQL Managed Instance. Region
limitations: For the current list of supported regions, see products available by region. To create a managed instance in a
region that currently isn't supported, send a support request via the Azure portal.

If your database consumes more than 300 DTUs, converting to the vCore-based purchasing model might reduce
your costs. You can convert by using your API of choice or by using the Azure portal, with no downtime.
However, conversion isn't required and isn't done automatically. If the DTU-based purchasing model meets your
performance and business requirements, you should continue using it.
To convert from the DTU-based purchasing model to the vCore-based purchasing model, see Migrate from DTU
to vCore.

DTU-based purchasing model

A database transaction unit (DTU) represents a blended measure of CPU, memory, reads, and writes. The DTU-
based purchasing model offers a set of preconfigured bundles of compute resources and included storage to
drive different levels of application performance. If you prefer the simplicity of a preconfigured bundle and fixed
payments each month, the DTU-based model might be more suitable for your needs.
In the DTU-based purchasing model, you can choose between the basic, standard, and premium service tiers for
Azure SQL Database. The DTU-based purchasing model isn't available for Azure SQL Managed Instance.
Database transaction units (DTUs)
For a single database at a specific compute size within a service tier, Azure guarantees a certain level of
resources for that database (independent of any other database in the Azure cloud). This guarantee provides a
predictable level of performance. The amount of resources allocated for a database is calculated as a number of
DTUs and is a bundled measure of compute, storage, and I/O resources.
The ratio among these resources is originally determined by an online transaction processing (OLTP) benchmark
workload designed to be typical of real-world OLTP workloads. When your workload exceeds the amount of any
of these resources, your throughput is throttled, resulting in slower performance and time-outs.
The resources used by your workload don't impact the resources available to other databases in the Azure cloud.
Likewise, the resources used by other workloads don't impact the resources available to your database.

DTUs are most useful for understanding the relative resources that are allocated for databases at different
compute sizes and service tiers. For example:
Doubling the DTUs by increasing the compute size of a database equates to doubling the set of resources
available to that database.
A premium service tier P11 database with 1750 DTUs provides 350 times more DTU compute power than a
basic service tier database with 5 DTUs.
To gain deeper insight into the resource (DTU) consumption of your workload, use query-performance insights
to:
Identify the top queries by CPU/duration/execution count that can potentially be tuned for improved
performance. For example, an I/O-intensive query might benefit from in-memory optimization techniques to
make better use of the available memory at a certain service tier and compute size.
Drill down into the details of a query to view its text and its history of resource usage.
Access performance-tuning recommendations that show actions taken by SQL Database Advisor.
Elastic database transaction units (eDTUs)
For databases that are always available, rather than provide a dedicated set of resources (DTUs) that might not
always be needed, you can place these databases into an elastic pool. The databases in an elastic pool are on a
single server and share a pool of resources.
The shared resources in an elastic pool are measured by elastic database transaction units (eDTUs). Elastic pools
provide a simple, cost-effective solution to manage performance goals for multiple databases that have widely
varying and unpredictable usage patterns. An elastic pool guarantees that all the resources can't be consumed
by one database in the pool, while ensuring that each database in the pool always has a minimum amount of
necessary resources available.
A pool is given a set number of eDTUs for a set price. In the elastic pool, individual databases can autoscale
within the configured boundaries. A database under a heavier load will consume more eDTUs to meet demand.
Databases under lighter loads will consume fewer eDTUs. Databases with no load will consume no eDTUs.
Because resources are provisioned for the entire pool, rather than per database, elastic pools simplify your
management tasks and provide a predictable budget for the pool.
You can add additional eDTUs to an existing pool with no database downtime and with no impact on the
databases in the pool. Similarly, if you no longer need extra eDTUs, remove them from an existing pool at any
time. You can also add databases to or subtract databases from a pool at any time. To reserve eDTUs for other
databases, limit the number of eDTUs a database can use under a heavy load. If a database consistently
underuses resources, move it out of the pool and configure it as a single database with a predictable amount of
required resources.
Determine the number of DTUs needed by a workload
If you want to migrate an existing on-premises or SQL Server virtual machine workload to SQL Database, use
the DTU calculator to approximate the number of DTUs needed. For an existing SQL Database workload, use
query-performance insights to understand your database-resource consumption (DTUs) and gain deeper
insights for optimizing your workload. The sys.dm_db_resource_stats dynamic management view (DMV) lets
you view resource consumption for the last hour. The sys.resource_stats catalog view displays resource
consumption for the last 14 days, but at a lower fidelity of five-minute averages.
Determine DTU utilization
To determine the average percentage of DTU/eDTU utilization relative to the DTU/eDTU limit of a database or an
elastic pool, use the following formula:
avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

The input values for this formula can be obtained from sys.dm_db_resource_stats, sys.resource_stats, and
sys.elastic_pool_resource_stats DMVs. In other words, to determine the percentage of DTU/eDTU utilization
toward the DTU/eDTU limit of a database or an elastic pool, pick the largest percentage value from the following:
avg_cpu_percent , avg_data_io_percent , and avg_log_write_percent at a given point in time.

NOTE
The DTU limit of a database is determined by CPU, reads, writes, and memory available to the database. However,
because the SQL Database engine typically uses all available memory for its data cache to improve performance, the
avg_memory_usage_percent value will usually be close to 100 percent, regardless of current database load. Therefore,
even though memory does indirectly influence the DTU limit, it is not used in the DTU utilization formula.

Workloads that benefit from an elastic pool of resources

Pools are well suited for databases with a low resource-utilization average and relatively infrequent utilization
spikes. For more information, see When should you consider a SQL Database elastic pool?.
Hardware generations in the DTU -based purchasing model
In the DTU-based purchasing model, customers cannot choose the hardware generation used for their
databases. While a given database usually stays on a specific hardware generation for a long time (commonly
for multiple months), there are certain events that can cause a database to be moved to another hardware
generation.
For example, a database can be moved to a different hardware generation if it's scaled up or down to a different
service objective, or if the current infrastructure in a datacenter is approaching its capacity limits, or if the
currently used hardware is being decommissioned due to its end of life.
If a database is moved to different hardware, workload performance can change. The DTU model guarantees
that the throughput and response time of the DTU benchmark workload will remain substantially identical as the
database moves to a different hardware generation, as long as its service objective (the number of DTUs) stays
the same.
However, across the wide spectrum of customer workloads running in Azure SQL Database, the impact of using
different hardware for the same service objective can be more pronounced. Different workloads will benefit
from different hardware configuration and features. Therefore, for workloads other than the DTU benchmark, it's
possible to see performance differences if the database moves from one hardware generation to another.
For example, an application that is sensitive to network latency can see better performance on Gen5 hardware
vs. Gen4 due to the use of Accelerated Networking in Gen5, but an application using intensive read IO can see
better performance on Gen4 hardware versus Gen5 due to a higher memory per core ratio on Gen4.
Customers with workloads that are sensitive to hardware changes or customers who wish to control the choice
of hardware generation for their database can use the vCore model to choose their preferred hardware
generation during database creation and scaling. In the vCore model, resource limits of each service objective
on each hardware generation are documented, for both single databases and elastic pools. For more
information about hardware generations in the vCore model, see Hardware generations for SQL Database or
Hardware generations for SQL Managed Instance.

Frequently asked questions (FAQs)

Do I need to take my application offline to convert from a DTU -based service tier to a vCore -based service
tier?
No. You don't need to take the application offline. The new service tiers offer a simple online-conversion method
that's similar to the existing process of upgrading databases from the standard to the premium service tier and
the other way around. You can start this conversion by using the Azure portal, PowerShell, the Azure CLI, T-SQL,
or the REST API. See Manage single databases and Manage elastic pools.
Can I convert a database from a service tier in the vCore -based purchasing model to a service tier in the DTU -
based purchasing model?
Yes, you can easily convert your database to any supported performance objective by using the Azure portal,
PowerShell, the Azure CLI, T-SQL, or the REST API. See Manage single databases and Manage elastic pools.

Next steps
For more information about the vCore-based purchasing model, see vCore-based purchasing model.
For more information about the DTU-based purchasing model, see DTU-based purchasing model.
 vCore model overview - Azure SQL Database and
Azure SQL Managed Instance
12/6/2021 • 2 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

The virtual core (vCore) purchasing model used by Azure SQL Database and Azure SQL Managed Instance
provides several benefits:
Control over the hardware generation to better match compute and memory requirements of the workload.
Pricing discounts for Azure Hybrid Benefit (AHB) and Reserved Instance (RI).
Greater transparency in the hardware details that power the compute, that facilitates planning for migrations
from on-premises deployments.
In the case of Azure SQL Database, vCore purchasing model provides higher compute, memory, I/O, and
storage limits than the DTU model.
For more information on choosing between the vCore and DTU purchase models, see Choose between the
vCore and DTU purchasing models.
Survey to improve Azure SQL!

Service tiers
The following articles provide specific information on the vCore purchase model in each product.
For information on Azure SQL Database service tiers for the vCore model, see vCore model overview - Azure
SQL Database.
For information on Azure SQL Managed Instance service tiers for the vCore model, see vCore model
overview - Azure SQL Managed Instance.

Next steps
To get started, see:
Creating a SQL Database using the Azure portal
Creating a SQL Managed Instance using the Azure portal
For pricing details, see
Azure SQL Database pricing page
Azure SQL Managed Instance single instance pricing page
Azure SQL Managed Instance pools pricing page
For details about the specific compute and storage sizes available in the general purpose and business critical
service tiers, see:
vCore-based resource limits for Azure SQL Database.
vCore-based resource limits for pooled Azure SQL Database.
vCore-based resource limits for Azure SQL Managed Instance.
 Azure Hybrid Benefit - Azure SQL Database & SQL
Managed Instance
12/6/2021 • 4 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

Azure Hybrid Benefit allows you to exchange your existing licenses for discounted rates on Azure SQL Database
and Azure SQL Managed Instance. You can save up to 30 percent or more on SQL Database and SQL Managed
Instance by using your Software Assurance-enabled SQL Server licenses on Azure. The Azure Hybrid Benefit
page has a calculator to help determine savings.
Changing to Azure Hybrid Benefit does not require any downtime.

Overview

With Azure Hybrid Benefit, you pay only for the underlying Azure infrastructure by using your existing SQL
Server license for the SQL Server database engine itself (Base Compute pricing). If you do not use Azure Hybrid
Benefit, you pay for both the underlying infrastructure and the SQL Server license (License-Included pricing).
For Azure SQL Database, Azure Hybrid Benefit is only available when using the provisioned compute tier of the
vCore-based purchasing model. Azure Hybrid Benefit doesn't apply to DTU-based purchasing models or the
serverless compute tier.

Enable Azure Hybrid Benefit

Azure SQL Database
You can choose or change your licensing model for Azure SQL Database using the Azure portal or the API of
your choice.
You can only apply the Azure Hybrid licensing model when you choose a vCore-based purchasing model and
the provisioned compute tier for your Azure SQL Database. Azure Hybrid Benefit isn't available for service tiers
under the DTU-based purchasing model or for the serverless compute tier.
Portal
PowerShell
Azure CLI
REST API

To set or update the license type using the Azure portal:

For new databases, during creation, select Configure database on the Basics tab and select the option to
Save money .
For existing databases, select Compute + storage in the Settings menu and select the option to Save
money .
If you don't see the Save money option in the Azure portal, verify that you selected a service tier using the
vCore-based purchasing model and the provisioned compute tier.
Azure SQL Managed Instance
You can choose or change your licensing model for Azure SQL Managed Instance using the Azure portal or the
API of your choice.
Portal
PowerShell
Azure CLI
REST API

To set or update the license type using the Azure portal:

For new managed instances, during creation, select Configure Managed Instance on the Basics tab and
select the option for Azure Hybrid Benefit .
For existing managed instances, select Compute + storage in the Settings menu and select the option for
Azure Hybrid Benefit .

Frequently asked questions

Are there dual-use rights with Azure Hybrid Benefit for SQL Server?
You have 180 days of dual use rights of the license to ensure migrations are running seamlessly. After that 180-
day period, you can only use the SQL Server license on Azure. You no longer have dual use rights on-premises
and on Azure.
How does Azure Hybrid Benefit for SQL Server differ from license mobility?
We offer license mobility benefits to SQL Server customers with Software Assurance. License mobility allows
reassignment of their licenses to a partner's shared servers. You can use this benefit on Azure IaaS and AWS
EC2.
Azure Hybrid Benefit for SQL Server differs from license mobility in two key areas:
It provides economic benefits for moving highly virtualized workloads to Azure. SQL Server Enterprise
Edition customers can get four cores in Azure in the General Purpose SKU for every core they own on-
 premises for highly virtualized applications. License mobility doesn't allow any special cost benefits for
moving virtualized workloads to the cloud.
It provides for a PaaS destination on Azure (SQL Managed Instance) that's highly compatible with SQL Server.
What are the specific rights of the Azure Hybrid Benefit for SQL Server?
SQL Database and SQL Managed Instance customers have the following rights associated with Azure Hybrid
Benefit for SQL Server:

W H AT DO ES A Z URE H Y B RID B EN EF IT F O R SQ L SERVER GET

L IC EN SE F O OT P RIN T Y O U?

SQL Server Enterprise Edition core customers with SA Can pay base rate on Hyperscale, General Purpose, or
Business Critical SKU

One core on-premises = Four vCores in Hyperscale SKU

One core on-premises = Four vCores in General Purpose

SKU

One core on-premises = One vCore in Business Critical

SKU

SQL Server Standard Edition core customers with SA Can pay base rate on Hyperscale, General Purpose, or
Business Critical SKU

One core on-premises = One vCore in Hyperscale SKU

One core on-premises = One vCore in General Purpose

SKU

Four cores on-premises = One vCore in Business Critical

SKU

Next steps
For help with choosing an Azure SQL deployment option, see Service comparison.
For a comparison of SQL Database and SQL Managed Instance features, see Features of SQL Database and
SQL Managed Instance.
 Save costs for resources with reserved capacity -
Azure SQL Database & SQL Managed Instance
12/6/2021 • 6 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

Save money with Azure SQL Database and SQL Managed Instance by committing to a reservation for compute
resources compared to pay-as-you-go prices. With reserved capacity, you make a commitment for SQL
Database and/or SQL Managed Instance use for a period of one or three years to get a significant discount on
the compute costs. To purchase reserved capacity, you need to specify the Azure region, deployment type,
performance tier, and term.
You do not need to assign the reservation to a specific database or managed instance. Matching existing
deployments that are already running or ones that are newly deployed automatically get the benefit. By
purchasing a reservation, you commit to usage for the compute costs for a period of one or three years. As soon
as you buy a reservation, the compute charges that match the reservation attributes are no longer charged at
the pay-as-you go rates.
A reservation applies to both primary and billable secondary compute replicas, but does not cover software,
networking, or storage charges associated with the service. At the end of the reservation term, the billing benefit
expires and the database or managed instance is billed at the pay-as-you go price. Reservations do not
automatically renew. For pricing information, see the reserved capacity offering.
You can buy reserved capacity in the Azure portal. Pay for the reservation up front or with monthly payments. To
buy reserved capacity:
You must be in the owner role for at least one Enterprise or individual subscription with pay-as-you-go rates.
For Enterprise subscriptions, Add Reser ved Instances must be enabled in the EA portal. Or, if that setting is
disabled, you must be an EA Admin on the subscription. Reserved capacity.
For more information about how enterprise customers and Pay-As-You-Go customers are charged for
reservation purchases, see Understand Azure reservation usage for your Enterprise enrollment and Understand
Azure reservation usage for your Pay-As-You-Go subscription.

NOTE
Purchasing reserved capacity does not pre-allocate or reserve specific infrastructure resources (virtual machines or nodes)
for your use.

Determine correct size before purchase

The size of reservation should be based on the total amount of compute used by the existing or soon-to-be-
deployed database or managed instance within a specific region and using the same performance tier and
hardware generation.
For example, let's suppose that you are running one general purpose, Gen5 – 16 vCore elastic pool and two
business critical Gen5 – 4 vCore single databases. Further, let's supposed that you plan to deploy within the next
month an additional general purpose Gen5 – 16 vCore elastic pool and one business critical Gen5 – 32 vCore
elastic pool. Also, let's suppose that you know that you will need these resources for at least 1 year. In this case,
you should purchase a 32 (2x16) vCores 1-year reservation for single database/elastic pool general purpose -
Gen5 and a 40 (2x4 + 32) vCore 1-year reservation for single database/elastic pool business critical - Gen5.

Buy reserved capacity

1. Sign in to the Azure portal.
2. Select All ser vices > Reser vations .
3. Select Add and then in the Purchase Reser vations pane, select SQL Database to purchase a new
reservation for SQL Database.
4. Fill in the required fields. Existing databases in SQL Database and SQL Managed Instance that match the
attributes you select qualify to get the reserved capacity discount. The actual number of databases or
managed instances that get the discount depends on the scope and quantity selected.

The following table describes required fields.

F IEL D DESC RIP T IO N

Subscription The subscription used to pay for the capacity

reservation. The payment method on the subscription is
charged the upfront costs for the reservation. The
subscription type must be an enterprise agreement (offer
number MS-AZR-0017P or MS-AZR-0148P) or an
individual agreement with pay-as-you-go pricing (offer
number MS-AZR-0003P or MS-AZR-0023P). For an
enterprise subscription, the charges are deducted from
the enrollment's Azure Prepayment (previously called
monetary commitment) balance or charged as overage.
For an individual subscription with pay-as-you-go
pricing, the charges are billed to the credit card or
invoice payment method on the subscription.
 F IEL D DESC RIP T IO N

Scope The vCore reservation's scope can cover one subscription

or multiple subscriptions (shared scope). If you select

Shared , the vCore reservation discount is applied to the

database or managed instance running in any
subscriptions within your billing context. For enterprise
customers, the shared scope is the enrollment and
includes all subscriptions within the enrollment. For Pay-
As-You-Go customers, the shared scope is all Pay-As-
You-Go subscriptions created by the account
administrator.

Single subscription , the vCore reservation discount is

applied to the databases or managed instances in this
subscription.

Single resource group , the reservation discount is

applied to the instances of databases or managed
instances in the selected subscription and the selected
resource group within that subscription.

Management group , the reservation discount is

applied to the matching resource in the list of
subscriptions that are a part of both the management
group and billing scope.

Region The Azure region that's covered by the capacity

reservation.

Deployment Type The SQL resource type that you want to buy the
reservation for.

Performance Tier The service tier for the databases or managed instances.

Term One year or three years.

Quantity The amount of compute resources being purchased

within the capacity reservation. The quantity is a number
of vCores in the selected Azure region and Performance
tier that are being reserved and will get the billing
discount. For example, if you run or plan to run multiple
databases with the total compute capacity of Gen5 16
vCores in the East US region, then you would specify the
quantity as 16 to maximize the benefit for all the
databases.

5. Review the cost of the capacity reservation in the Costs section.

6. Select Purchase .
7. Select View this Reser vation to see the status of your purchase.

Cancel, exchange, or refund reservations

You can cancel, exchange, or refund reservations with certain limitations. For more information, see Self-service
exchanges and refunds for Azure Reservations.
vCore size flexibility
vCore size flexibility helps you scale up or down within a performance tier and region, without losing the
reserved capacity benefit. Reserved capacity also provides you with the flexibility to temporarily move your hot
databases in and out of elastic pools (within the same region and performance tier) as part of your normal
operations without losing the reserved capacity benefit. By keeping an unapplied buffer in your reservation, you
can effectively manage the performance spikes without exceeding your budget.

Limitation
You cannot reserve DTU-based (basic, standard, or premium) databases in SQL Database. Reserved capacity
pricing is only supported for features and products that are in General Availability state.

Need help? Contact us

If you have questions or need help, create a support request.

Next steps
The vCore reservation discount is applied automatically to the number of databases or managed instances that
match the capacity reservation scope and attributes. You can update the scope of the capacity reservation
through the Azure portal, PowerShell, Azure CLI, or the API.
For information on Azure SQL Database service tiers for the vCore model, see vCore model overview - Azure
SQL Database.
For information on Azure SQL Managed Instance service tiers for the vCore model, see vCore model
overview - Azure SQL Managed Instance.
To learn how to manage the capacity reservation, see manage reserved capacity.
To learn more about Azure Reservations, see the following articles:
What are Azure Reservations?
Manage Azure Reservations
Understand Azure Reservations discount
Understand reservation usage for your Pay-As-You-Go subscription
Understand reservation usage for your Enterprise enrollment
Azure Reservations in Partner Center Cloud Solution Provider (CSP) program
 Azure SQL Database and Azure SQL Managed
Instance service tiers
12/6/2021 • 6 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

Two vCore service tiers are available in both Azure SQL Database and Azure SQL Managed Instance:
General purpose is a budget-friendly tier designed for most workloads with common performance and
availability requirements.
Business critical tier is designed for performance-sensitive workloads with strict availability requirements.
Azure SQL Database also provides the Hyperscale service tier:
Hyperscale is designed for most business workloads, providing highly scalable storage, read scale-out, fast
scaling, and fast database restore capabilities.
For a comparison of the vCore-based purchasing model with the DTU-based purchasing model, see purchasing
models and resources.

Service tier comparison

The following table describes the key differences between service tiers.

- RESO URC E T Y P E GEN ERA L P URP O SE H Y P ERSC A L E B USIN ESS C RIT IC A L

Best for Offers budget Most business OLTP applications

oriented balanced workloads. Auto- with high transaction
compute and storage scaling storage size rate and low IO
options. up to 100 TB, fluid latency. Offers
vertical and highest resilience to
horizontal compute failures and fast
scaling, fast database failovers using
restore. multiple
synchronously
updated replicas.

Available in SQL Database / SQL Single Azure SQL SQL Database / SQL
resource type: Managed Instance Database Managed Instance

Compute size SQL Database 1 to 80 vCores 1 to 80 vCores 1 to 128 vCores

SQL Managed 4, 8, 16, 24, 32, 40, N/A 4, 8, 16, 24, 32, 40,
Instance 64, 80 vCores 64, 80 vCores

SQL Managed 2, 4, 8, 16, 24, 32, N/A N/A

Instance pools 40, 64, 80 vCores

Storage type All Remote storage Tiered remote and Local SSD storage
local SSD storage

Database size SQL Database 1 GB – 4 TB 40 GB - 100 TB 1 GB – 4 TB

- RESO URC E T Y P E GEN ERA L P URP O SE H Y P ERSC A L E B USIN ESS C RIT IC A L

SQL Managed 32 GB – 16 TB N/A 32 GB – 16 TB

Instance

Storage size SQL Database 1 GB – 4 TB 40 GB - 100 TB 1 GB – 4 TB

SQL Managed 32 GB – 16 TB N/A 32 GB – 16 TB

Instance

TempDB size SQL Database 32 GB per vCore 32 GB per vCore 32 GB per vCore

SQL Managed 24 GB per vCore N/A Up to 4 TB - limited

Instance by storage size

Log write SQL Database Single databases: 4.5 100 MB/s Single databases: 12
throughput MB/s per vCore (max MB/s per vCore (max
50 MB/s) 96 MB/s)
Elastic pools: 6 MB/s Elastic pools: 15
per vCore (max 62.5 MB/s per vCore (max
MB/s) 120 MB/s)

SQL Managed 3 MB/s per vCore N/A 4 MB/s per vCore

Instance (max 22 MB/s) (max 48 MB/s)

Availability SQL Database (SLA) 99.99% 99.95% with one 99.99%

secondary replica, 99.995% with zone
99.99% with more redundant single
replicas database

SQL Managed 99.99% 99.95% with one 99.99%

Instance (SLA) secondary replica, 99.995% with zone
99.99% with more redundant single
replicas database

Backups All RA-GRS, 1-35 days RA-GRS, 7 days, fast RA-GRS, 1-35 days
(7 days by default) point-in-time (7 days by default)
recovery (PITR)

In-memor y OLTP N/A Partial support. Available

Memory-optimized
table types, table
variables, and
natively compiled
modules are
supported.

Read-only replicas 0 built-in 0 - 4 built-in 1 built-in, included in

0 - 4 using geo- price
replication 0 - 4 using geo-
replication

Pricing/billing SQL Database vCore, reserved vCore for each replica vCore, reserved
storage, and backup and used storage are storage, and backup
storage are charged. charged. storage are charged.
IOPS is not charged. IOPS not yet IOPS is not charged.
charged.
 - RESO URC E T Y P E GEN ERA L P URP O SE H Y P ERSC A L E B USIN ESS C RIT IC A L

SQL Managed vCore, reserved N/A vCore, reserved

Instance storage, and backup storage, and backup
storage is charged. storage is charged.
IOPS is not charged IOPS is not charged.

Discount models Reserved instances Azure Hybrid Benefit Reserved instances

Azure Hybrid Benefit (not available on Azure Hybrid Benefit
(not available on dev/test (not available on
dev/test subscriptions) dev/test
subscriptions) Enterprise and Pay- subscriptions)
Enterprise and Pay- As-You-Go Dev/Test Enterprise and Pay-
As-You-Go Dev/Test subscriptions As-You-Go Dev/Test
subscriptions subscriptions

NOTE
For more information on the Service Level Agreement (SLA), see SLA for Azure SQL Database or SLA for Azure SQL
Managed Instance.

Resource limits
For more information on resource limits, see:
Azure SQL Database (vCore)
Single Azure SQL Database (DTU)
Pooled Azure SQL Database (DTU)
Azure SQL Managed Instance

Data and log storage

The following factors affect the amount of storage used for data and log files, and apply to General Purpose and
Business Critical tiers. For details on data and log storage in Hyperscale, see Hyperscale service tier.
Each compute size supports a maximum data size, with a default of 32 GB.
When you configure maximum data size, an additional 30 percent of storage is automatically added for log
files.
You can select any maximum data size between 1 GB and the supported storage size maximum, in 1 GB
increments.
In the General Purpose service tier, tempdb uses local SSD storage, and this storage cost is included in the
vCore price.
In the Business Critical service tier, tempdb shares local SSD storage with data and log files, and tempdb
storage cost is included in the vCore price.
The maximum storage size for a SQL Managed Instance must be specified in multiples of 32 GB.

IMPORTANT
In the General Purpose and Business Critical tiers, you are charged for the maximum storage size configured for a
database, elastic pool, or managed instance. In the Hyperscale tier, you are charged for the allocated data storage.

To monitor the current allocated and used data storage size in SQL Database, use allocated_data_storage and
storage Azure Monitor metrics respectively. To monitor total consumed instance storage size for SQL Managed
Instance, use the storage_space_used_mb metric. To monitor the current allocated and used storage size of
individual data and log files in a database using T-SQL, use the sys.database_files view and the FILEPROPERTY(...
, 'SpaceUsed') function.

TIP
Under some circumstances, you may need to shrink a database to reclaim unused space. For more information, see
Manage file space in Azure SQL Database.

Backups and storage

Storage for database backups is allocated to support the point-in-time restore (PITR) and long-term retention
(LTR) capabilities of SQL Database and SQL Managed Instance. This storage is separate from data and log file
storage, and is billed separately.
PITR : In General Purpose and Business Critical tiers, individual database backups are copied to read-access
geo-redundant (RA-GRS) storage automatically. The storage size increases dynamically as new backups are
created. The storage is used by full, differential, and transaction log backups. The storage consumption
depends on the rate of change of the database and the retention period configured for backups. You can
configure a separate retention period for each database between 1 and 35 days for SQL Database, and 0 to
35 days for SQL Managed Instance. A backup storage amount equal to the configured maximum data size is
provided at no extra charge.
LTR : You also have the option to configure long-term retention of full backups for up to 10 years. If you set
up an LTR policy, these backups are stored in RA-GRS storage automatically, but you can control how often
the backups are copied. To meet different compliance requirements, you can select different retention periods
for weekly, monthly, and/or yearly backups. The configuration you choose determines how much storage will
be used for LTR backups. For more information, see Long-term backup retention.

Next steps
For details about the specific compute and storage sizes available in vCore service tiers, see:
vCore-based resource limits for Azure SQL Database.
vCore-based resource limits for pooled databases in Azure SQL Database.
vCore-based resource limits for Azure SQL Managed Instance.
 General Purpose service tier - Azure SQL Database
and Azure SQL Managed Instance
12/6/2021 • 2 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

NOTE
The General Purpose service tier in the vCore-based purchasing model is called the standard service tier in the DTU-based
purchasing model. For a comparison of the vCore-based purchasing model with the DTU-based purchasing model, see
purchasing models and resources.

Azure SQL Database and Azure SQL Managed Instance are based on the SQL Server database engine
architecture adapted for the cloud environment in order to ensure 99.99% availability even in the cases of
infrastructure failures.
There are two service tiers used by Azure SQL Database and SQL Managed Instance:
General Purpose
Business Critical
Azure SQL Database also has a third service tier, which is currently unavailable for Azure SQL Managed Instance:
Hyperscale
The architectural model for the General Purpose service tier is based on a separation of compute and storage.
This architectural model relies on high availability and reliability of Azure Blob storage that transparently
replicates database files and guarantees no data loss if underlying infrastructure failure happens.
The following figure shows four nodes in standard architectural model with the separated compute and storage
layers.

In the architectural model for the General Purpose service tier, there are two layers:
A stateless compute layer that is running the sqlservr.exe process and contains only transient and cached
 data (for example – plan cache, buffer pool, column store pool). This stateless node is operated by Azure
Service Fabric that initializes process, controls health of the node, and performs failover to another place if
necessary.
A stateful data layer with database files (.mdf/.ldf) that are stored in Azure Blob storage. Azure Blob storage
guarantees that there will be no data loss of any record that is placed in any database file. Azure Storage has
built-in data availability/redundancy that ensures that every record in log file or page in data file will be
preserved even if the process crashes.
Whenever the database engine or operating system is upgraded, some part of underlying infrastructure fails, or
if some critical issue is detected in the sqlservr.exe process, Azure Service Fabric will move the stateless
process to another stateless compute node. There is a set of spare nodes that is waiting to run new compute
service if a failover of the primary node happens in order to minimize failover time. Data in Azure storage layer
is not affected, and data/log files are attached to newly initialized process. This process guarantees 99.99%
availability, but it might have some performance impacts on heavy workloads that are running due to transition
time and the fact the new node starts with cold cache.

When to choose this service tier

The General Purpose service tier is a default service tier in Azure SQL Database and Azure SQL Managed
Instance that is designed for most of generic workloads. If you need a fully managed database engine with
99.99% SLA with storage latency between 5 and 10 ms that match SQL Server on an Azure virtual machine in
most of the cases, the General Purpose tier is the option for you.

Next steps
Find resource characteristics (number of cores, I/O, memory) of the General Purpose/standard tier in SQL
Managed Instance, single database in vCore model or DTU model, or elastic pool in vCore model and DTU
model.
Learn about Business Critical and Hyperscale tiers.
Learn about Service Fabric.
For more options for high availability and disaster recovery, see Business Continuity.
 Business Critical tier - Azure SQL Database and
Azure SQL Managed Instance
12/6/2021 • 4 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

NOTE
Business Critical tier is called Premium in the DTU purchasing model. For a comparison of the vCore-based purchasing
model with the DTU-based purchasing model, see Azure SQL Database purchasing models and resources.

Azure SQL Database and Azure SQL Managed Instance are both based on SQL Server database engine
architecture that is adjusted for the cloud environment in order to ensure 99.99% availability even in the cases
of infrastructure failures. There are three architectural models that are used:
General Purpose/Standard
Business Critical/Premium
Hyperscale
Premium/Business Critical service tier model is based on a cluster of database engine processes. This
architectural model relies on a fact that there is always a quorum of available database engine nodes and has
minimal performance impact on your workload even during maintenance activities. The hyperscale service tier
is currently only available for Azure SQL Database (not SQL Managed Instance), and is a highly scalable storage
and compute performance tier that leverages the Azure architecture to scale out the storage and compute
resources for a database in Azure SQL Database substantially beyond the limits available for the General
Purpose and Business Critical service tiers.
Azure upgrades and patches underlying operating system, drivers, and SQL Server database engine
transparently with the minimal down-time for end users.
Premium availability is enabled in Premium and Business Critical service tiers and it is designed for intensive
workloads that cannot tolerate any performance impact due to the ongoing maintenance operations.
Compute and storage is integrated on the single node in the premium model. High availability in this
architectural model is achieved by replication of compute (SQL Server database engine process) and storage
(locally attached SSD) deployed to a four node cluster, using technology similar to SQL Server Always On
availability groups.
Both the SQL Server database engine process and underlying .mdf/.ldf files are placed on the same node with
locally attached SSD storage providing low latency to your workload. High availability is implemented using
technology similar to SQL Server Always On availability groups. Every database is a cluster of database nodes
with one primary database that is accessible for customer workloads, and a three secondary processes
containing copies of data. The primary node constantly pushes changes to the secondary nodes in order to
ensure that the data is available on secondary replicas if the primary node fails for any reason. Failover is
handled by the SQL Server database engine – one secondary replica becomes the primary node and a new
secondary replica is created to ensure there are enough nodes in the cluster. The workload is automatically
redirected to the new primary node.
In addition, Business Critical cluster has built-in Read Scale-Out capability that provides free-of charge built-in
read-only node that can be used to run read-only queries (for example reports) that should not affect
performance of your primary workload.

When to choose this service tier

Business Critical service tier is designed for applications that require low-latency responses from the underlying
SSD storage (1-2 ms in average), fast recovery if the underlying infrastructure fails, or need to off-load reports,
analytics, and read-only queries to the free of charge readable secondary replica of the primary database.
The key reasons why you should choose Business Critical service tier instead of General Purpose tier are:
Low I/O latency requirements – workloads that need a fast response from the storage layer (1-2
milliseconds in average) should use Business Critical tier.
 Frequent communication between application and database . Applications that cannot leverage
application-layer caching or request batching and need to send many SQL queries that must be quickly
processed are good candidates for the Business Critical tier.
Large number of updates – insert, update, and delete operations modify the data pages in memory (dirty
page) that must be saved to data files with CHECKPOINT operation. Potential database engine process crash or
a failover of the database with a large number of dirty pages might increase recovery time in General
Purpose tier. Use Business Critical tier if you have a workload that causes many in-memory changes.
Long running transactions that modify data . Transactions that are opened for a longer time prevent log
file truncation, which might increase log size and number of Virtual log files (VLF). High number of VLFs can
slow down recovery of database after failover.
Workload with repor ting and analytic queries that can be redirected to the free-of-charge secondary
read-only replica.
Higher resiliency and faster recover y from failures . In a case of system failure, the database on
primary instance will be disabled and one of the secondary replicas will be immediately became new read-
write primary database that is ready to process queries. The database engine doesn't need to analyze and
redo transactions from the log file and load all data in the memory buffer.
Advanced data corruption protection . Business Critical tier leverages database replicas behind-the-
scenes for business continuity purposes, and so the service also then leverages automatic page repair, which
is the same technology used for SQL Server database mirroring and availability groups. In the event that a
replica cannot read a page due to a data integrity issue, a fresh copy of the page will be retrieved from
another replica, replacing the unreadable page without data loss or customer downtime. This functionality is
applicable in General Purpose tier if the database has geo-secondary replica.
Higher availability - Business Critical tier in Multi-AZ configuration guarantees 99.995% availability,
compared to 99.99% of General Purpose tier.
Fast geo-recover y - Business Critical tier configured with geo-replication has a guaranteed Recovery point
objective (RPO) of 5 sec and Recovery time objective (RTO) of 30 sec for 100% of deployed hours.

Next steps
Find resource characteristics (number of cores, I/O, memory) of Business Critical tier in SQL Managed
Instance, Single database in vCore model or DTU model, or Elastic pool in vCore model and DTU model.
Learn about General Purpose and Hyperscale tiers.
Learn about Service Fabric.
For more options for high availability and disaster recovery, see Business Continuity.
 Features comparison: Azure SQL Database and
Azure SQL Managed Instance
12/6/2021 • 14 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database and SQL Managed Instance share a common code base with the latest stable version of
SQL Server. Most of the standard SQL language, query processing, and database management features are
identical. The features that are common between SQL Server and SQL Database or SQL Managed Instance are:
Language features - Control of flow language keywords, Cursors, Data types, DML statements, Predicates,
Sequence numbers, Stored procedures, and Variables.
Database features - Automatic tuning (plan forcing), Change tracking, Database collation, Contained
databases, Contained users, Data compression, Database configuration settings, Online index operations,
Partitioning, and Temporal tables (see getting started guide).
Security features - Application roles, Dynamic data masking (see getting started guide), Row Level Security,
and Threat detection - see getting started guides for SQL Database and SQL Managed Instance.
Multi-model capabilities - Graph processing, JSON data (see getting started guide), OPENXML, Spatial,
OPENJSON, and XML indexes.
Azure manages your databases and guarantees their high-availability. Some features that might affect high-
availability or can't be used in PaaS world have limited functionalities in SQL Database and SQL Managed
Instance. These features are described in the tables below.
If you need more details about the differences, you can find them in the separate pages:
Azure SQL Database vs. SQL Server differences
Azure SQL Managed Instance vs. SQL Server differences
Survey to improve Azure SQL!

Features of SQL Database and SQL Managed Instance

The following table lists the major features of SQL Server and provides information about whether the feature is
partially or fully supported in Azure SQL Database and Azure SQL Managed Instance, with a link to more
information about the feature.

F EAT URE A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Always Encrypted Yes - see Cert store and Key vault Yes - see Cert store and Key vault
F EAT URE A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Always On Availability Groups 99.99-99.995% availability is 99.99.% availability is guaranteed for

guaranteed for every database. every database and can't be managed
Disaster recovery is discussed in by user. Disaster recovery is discussed
Overview of business continuity with in Overview of business continuity
Azure SQL Database with Azure SQL Database. Use Auto-
failover groups to configure a
secondary SQL Managed Instance in
another region. SQL Server instances
and SQL Database can't be used as
secondaries for SQL Managed
Instance.

Attach a database No No

Auditing Yes Yes, with some differences

Azure Active Directory (Azure AD) Yes. Azure AD users only. Yes. Including server-level Azure AD
authentication logins.

BACKUP command No, only system-initiated automatic Yes, user initiated copy-only backups
backups - see Automated backups to Azure Blob storage (automatic
system backups can't be initiated by
user) - see Backup differences

Built-in functions Most - see individual functions Yes - see Stored procedures, functions,
triggers differences

BULK INSERT statement Yes, but just from Azure Blob storage Yes, but just from Azure Blob Storage
as a source. as a source - see differences.

Certificates and asymmetric keys Yes, without access to file system for Yes, without access to file system for
BACKUP and CREATE operations. BACKUP and CREATE operations -
see certificate differences.

Change data capture - CDC Yes (Preview) for S3 tier and above. Yes
Basic, S0, S1, S2 are not supported.

Collation - server/instance No, default server collation Yes, can be set when the instance is
SQL_Latin1_General_CP1_CI_AS is created and can't be updated later.
always used.

Columnstore indexes Yes - Premium tier, Standard tier - S3 Yes

and above, General Purpose tier,
Business Critical, and HyperScale tiers

Common language runtime - CLR No Yes, but without access to file system
in CREATE ASSEMBLY statement - see
CLR differences

Credentials Yes, but only database scoped Yes, but only Azure Key Vault and
credentials. SHARED ACCESS SIGNATURE are
supported - see details

Cross-database/three-part name No - see Elastic queries Yes, plus Elastic queries

queries
F EAT URE A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Cross-database transactions No Yes, within the instance. See Linked

server differences for cross-instance
queries.

Database mail - DbMail No Yes

Database mirroring No No

Database snapshots No No

DBCC statements Most - see individual statements Yes - see DBCC differences

DDL statements Most - see individual statements Yes - see T-SQL differences

DDL triggers Database only Yes

Distributed partition views No Yes

Distributed transactions - MS DTC No - see Elastic transactions No - see Elastic transactions

DML triggers Most - see individual statements Yes

DMVs Most - see individual DMVs Yes - see T-SQL differences

Elastic query (in public preview) Yes, with required RDBMS type. No

Event notifications No - see Alerts No

Expressions Yes Yes

Extended events (XEvent) Some - see Extended events in SQL Yes - see Extended events differences
Database

Extended stored procedures No No

Files and file groups Primary file group only Yes. File paths are automatically
assigned and the file location can't be
specified in
ALTER DATABASE ADD FILE
statement.

Filestream No No

Full-text search (FTS) Yes, but third-party word breakers are Yes, but third-party word breakers are
not supported not supported

Functions Most - see individual functions Yes - see Stored procedures, functions,
triggers differences
F EAT URE A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

In-memory optimization Yes in Premium and Business Critical Yes in Business Critical service tier
service tiers.
Limited support for non-persistent In-
Memory OLTP objects such as
memory-optimized table variables in
Hyperscale service tier.

Language elements Most - see individual elements Yes - see T-SQL differences

Ledger Yes No

Linked servers No - see Elastic query Yes. Only to SQL Server and SQL
Database without distributed
transactions.

Linked servers that read from files No. Use BULK INSERT or No. Use BULK INSERT or
(CSV, Excel) OPENROWSET as an alternative for OPENROWSET as an alternative for
CSV format. CSV format. Track these requests on
SQL Managed Instance feedback item

Log shipping High availability is included with every Natively built in as a part of Azure
database. Disaster recovery is Data Migration Service (DMS)
discussed in Overview of business migration process. Natively built for
continuity. custom data migration projects as an
external Log Replay Service (LRS).
Not available as High availability
solution, because other High
availability methods are included with
every database and it is not
recommended to use Log-shipping as
HA alternative. Disaster recovery is
discussed in Overview of business
continuity. Not available as a
replication mechanism between
databases - use secondary replicas on
Business Critical tier, auto-failover
groups, or transactional replication as
the alternatives.

Logins and users Yes, but CREATE and ALTER login Yes, with some differences. Windows
statements do not offer all the options logins are not supported and they
(no Windows and server-level Azure should be replaced with Azure Active
Active Directory logins). Directory logins.
EXECUTE AS LOGIN is not supported
- use EXECUTE AS USER instead.

Minimal logging in bulk import No, only Full Recovery model is No, only Full Recovery model is
supported. supported.

Modifying system data No Yes

OLE Automation No No

OPENDATASOURCE No Yes, only to SQL Database, SQL

Managed Instance and SQL Server. See
T-SQL differences
F EAT URE A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

OPENQUERY No Yes, only to SQL Database, SQL

Managed Instance and SQL Server. See
T-SQL differences

OPENROWSET Yes, only to import from Azure Blob Yes, only to SQL Database, SQL
storage. Managed Instance and SQL Server,
and to import from Azure Blob
storage. See T-SQL differences

Operators Most - see individual operators Yes - see T-SQL differences

Polybase No. You can query data in the files No. You can query data in the files
placed on Azure Blob Storage using placed on Azure Blob Storage using
OPENROWSET function or use an OPENROWSET function, a linked server
external table that references a that references a serverless SQL pool
serverless SQL pool in Synapse in Synapse Analytics, or an external
Analytics. table (in public preview) that references
a serverless SQL pool in Synapse
Analytics or SQL Server.

Query Notifications No Yes

Machine Learning Services (Formerly R No Yes, see Machine Learning Services in

Services) Azure SQL Managed Instance

Recovery models Only Full Recovery that guarantees Only Full Recovery that guarantees
high availability is supported. Simple high availability is supported. Simple
and Bulk Logged recovery models are and Bulk Logged recovery models are
not available. not available.

Resource governor No Yes

RESTORE statements No Yes, with mandatory FROM URL

options for the backups files placed on
Azure Blob Storage. See Restore
differences

Restore database from backup From automated backups only - see From automated backups - see SQL
SQL Database recovery Database recovery and from full
backups placed on Azure Blob Storage
- see Backup differences

Restore database to SQL Server No. Use BACPAC or BCP instead of No, because SQL Server database
native restore. engine used in SQL Managed Instance
has higher version than any RTM
version of SQL Server used on-
premises. Use BACPAC, BCP, or
Transactional replication instead.

Semantic search No No
F EAT URE A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Service Broker No Yes, but only within the instance. If you

are using remote Service Broker
routes, try to consolidate databases
from several distributed SQL Server
instances into one SQL Managed
Instance during migration and use
only local routes. See Service Broker
differences

Server configuration settings No Yes - see T-SQL differences

Set statements Most - see individual statements Yes - see T-SQL differences

SQL Server Agent No - see Elastic jobs (preview) Yes - see SQL Server Agent differences

SQL Server Auditing No - see SQL Database auditing Yes - see Auditing differences

System stored functions Most - see individual functions Yes - see Stored procedures, functions,
triggers differences

System stored procedures Some - see individual stored Yes - see Stored procedures, functions,
procedures triggers differences

System tables Some - see individual tables Yes - see T-SQL differences

System catalog views Some - see individual views Yes - see T-SQL differences

TempDB Yes. 32-GB size per core for every Yes. 24-GB size per vCore for entire GP
database. tier and limited by instance size on BC
tier

Temporary tables Local and database-scoped global Local and instance-scoped global
temporary tables temporary tables

Time zone choice No Yes, and it must be configured when

the SQL Managed Instance is created.

Trace flags No Yes, but only limited set of global trace

flags. See DBCC differences

Transactional Replication Yes, Transactional and snapshot Yes, in public preview. See the
replication subscriber only constraints here.

Transparent data encryption (TDE) Yes - General Purpose, Business Yes

Critical, and Hyperscale (in preview)
service tiers only

Windows authentication No No

Windows Server Failover Clustering No. Other techniques that provide No. Other techniques that provide
high availability are included with high availability are included with
every database. Disaster recovery is every database. Disaster recovery is
discussed in Overview of business discussed in Overview of business
continuity with Azure SQL Database. continuity with Azure SQL Database.
Platform capabilities
The Azure platform provides a number of PaaS capabilities that are added as an additional value to the standard
database features. There is a number of external services that can be used with Azure SQL Database.

P L AT F O RM F EAT URE A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Active geo-replication Yes - all service tiers other than No, see Auto-failover groups as an
hyperscale alternative

Auto-failover groups Yes - all service tiers other than Yes, see Auto-failover groups
hyperscale

Auto-scale Yes, but only in serverless model. In No, you need to choose reserved
the non-serverless model, the change compute and storage. The change of
of service tier (change of vCore, service tier (vCore or max storage) is
storage, or DTU) is fast and online. The online and requires minimal or no
service tier change requires minimal or downtime.
no downtime.

Automatic backups Yes. Full backups are taken every 7 Yes. Full backups are taken every 7
days, differential 12 hours, and log days, differential 12 hours, and log
backups every 5-10 min. backups every 5-10 min.

Automatic tuning (indexes) Yes No

Availability Zones Yes No

Azure Resource Health Yes No

Backup retention Yes. 7 days default, max 35 days. Yes. 7 days default, max 35 days.

Data Migration Service (DMS) Yes Yes

Elastic jobs Yes - see Elastic jobs (preview) No (SQL Agent can be used instead).

File system access No. Use BULK INSERT or No. Use BULK INSERT or
OPENROWSET to access and load data OPENROWSET to access and load data
from Azure Blob Storage as an from Azure Blob Storage as an
alternative. alternative.

Geo-restore Yes Yes

Hyperscale architecture Yes No

Long-term backup retention - LTR Yes, keep automatically taken backups Yes, keep automatically taken backups
up to 10 years. up to 10 years.

Pause/resume Yes, in serverless model No

Policy-based management No No
P L AT F O RM F EAT URE A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Public IP address Yes. The access can be restricted using Yes. Needs to be explicitly enabled and
firewall or service endpoints. port 3342 must be enabled in NSG
rules. Public IP can be disabled if
needed. See Public endpoint for more
details.

Point in time database restore Yes - all service tiers other than Yes - see SQL Database recovery
hyperscale - see SQL Database
recovery

Resource pools Yes, as Elastic pools Yes. A single instance of SQL Managed
Instance can have multiple databases
that share the same pool of resources.
In addition, you can deploy multiple
instances of SQL Managed Instance in
instance pools (preview) that can share
the resources.

Scaling up or down (online) Yes, you can either change DTU or Yes, you can change reserved vCores
reserved vCores or max storage with or max storage with the minimal
the minimal downtime. downtime.

SQL Alias No, use DNS Alias No, use Cliconfg to set up alias on the
client machines.

SQL Analytics Yes Yes

SQL Data Sync Yes No

SQL Server Analysis Services (SSAS) No, Azure Analysis Services is a No, Azure Analysis Services is a
separate Azure cloud service. separate Azure cloud service.

SQL Server Integration Services (SSIS) Yes, with a managed SSIS in Azure Yes, with a managed SSIS in Azure
Data Factory (ADF) environment, Data Factory (ADF) environment,
where packages are stored in SSISDB where packages are stored in SSISDB
hosted by Azure SQL Database and hosted by SQL Managed Instance and
executed on Azure SSIS Integration executed on Azure SSIS Integration
Runtime (IR), see Create Azure-SSIS IR Runtime (IR), see Create Azure-SSIS IR
in ADF. in ADF.

To compare the SSIS features in SQL To compare the SSIS features in SQL
Database and SQL Managed Instance, Database and SQL Managed Instance,
see Compare SQL Database to SQL see Compare SQL Database to SQL
Managed Instance. Managed Instance.

SQL Server Reporting Services (SSRS) No - see Power BI No - use Power BI paginated reports
instead or host SSRS on an Azure VM.
While SQL Managed Instance cannot
run SSRS as a service, it can host SSRS
catalog databases for a reporting
server installed on Azure Virtual
Machine, using SQL Server
authentication.

Query Performance Insights (QPI) Yes No. Use built-in reports in SQL Server
Management Studio and Azure Data
Studio.
 P L AT F O RM F EAT URE A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

VNet Partial, it enables restricted access Yes, SQL Managed Instance is injected
using VNet Endpoints in customer's VNet. See subnet and
VNet

VNet Service endpoint Yes No

VNet Global peering Yes, using Private IP and service Yes, using Virtual network peering.
endpoints

Private connectivity Yes, using Private Link Yes, using VNet.

Tools
Azure SQL Database and Azure SQL Managed Instance support various data tools that can help you manage
your data.

TO O L A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Azure portal Yes Yes

Azure CLI Yes Yes

Azure Data Studio Yes Yes

Azure PowerShell Yes Yes

BACPAC file (export) Yes - see SQL Database export Yes - see SQL Managed Instance
export

BACPAC file (import) Yes - see SQL Database import Yes - see SQL Managed Instance
import

Data Quality Services (DQS) No No

Master Data Services (MDS) No No

SMO Yes Yes version 150

SQL Server Data Tools (SSDT) Yes Yes

SQL Server Management Studio Yes Yes version 18.0 and higher
(SSMS)

SQL Server PowerShell Yes Yes

SQL Server Profiler No - see Extended events Yes

System Center Operations Manager Yes Yes

Migration methods
You can use different migration methods to move your data between SQL Server, Azure SQL Database and
Azure SQL Managed Instance. Some methods are Online and picking-up all changes that are made on the
source while you are running migration, while in Offline methods you need to stop your workload that is
modifying data on the source while the migration is in progress.

SO URC E A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

SQL Server (on-prem, AzureVM, Online: Transactional Replication Online: Data Migration Service (DMS),
Amazon RDS) Offline: Data Migration Service Transactional Replication
(DMS), BACPAC file (import), BCP Offline: Native backup/restore,
BACPAC file (import), BCP, Snapshot
replication

Single database Offline: BACPAC file (import), BCP Offline: BACPAC file (import), BCP

SQL Managed Instance Online: Transactional Replication Online: Transactional Replication

Offline: BACPAC file (import), BCP, Offline: Cross-instance point-in-time
Snapshot replication restore (Azure PowerShell or Azure
CLI), Native backup/restore, BACPAC
file (import), BCP, Snapshot replication

Next steps
Microsoft continues to add features to Azure SQL Database. Visit the Service Updates webpage for Azure for the
newest updates using these filters:
Filtered to Azure SQL Database.
Filtered to General Availability (GA) announcements for SQL Database features.
For more information about Azure SQL Database and Azure SQL Managed Instance, see:
What is Azure SQL Database?
What is Azure SQL Managed Instance?
What is an Azure SQL Managed Instance pool?
 Multi-model capabilities of Azure SQL Database
and SQL Managed Instance
12/6/2021 • 8 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

Multi-model databases enable you to store and work with data in multiple formats, such as relational data,
graph, JSON or XML documents, spatial data, and key-value pairs.
The Azure SQL family of products uses a relational model that provides the best performance for a variety of
general-purpose applications. However, Azure SQL products like Azure SQL Database and SQL Managed
Instance are not limited to relational data. They enable you to use non-relational formats that are tightly
integrated into the relational model.
Consider using the multi-model capabilities of Azure SQL in the following cases:
You have some information or structures that are a better fit for NoSQL models, and you don't want to use a
separate NoSQL database.
A majority of your data is suitable for a relational model, and you need to model some parts of your data in a
NoSQL style.
You want to use the Transact-SQL language to query and analyze both relational and NoSQL data, and then
integrate that data with tools and applications that can use the SQL language.
You want to apply database features such as in-memory technologies to improve the performance of your
analytics or the processing of your NoSQL data structures. You can use transactional replication or readable
replicas to create copies of your data and offload some analytic workloads from the primary database.
The following sections describe the most important multi-model capabilities of Azure SQL.

NOTE
You can use JSONPath expressions, XQuery/XPath expressions, spatial functions, and graph query expressions in the same
Transact-SQL query to access any data that you stored in the database. Any tool or programming language that can
execute Transact-SQL queries can also use that query interface to access multi-model data. This is the key difference from
multi-model databases such as Azure Cosmos DB, which provide specialized APIs for data models.

Graph features
Azure SQL products offer graph database capabilities to model many-to-many relationships in a database. A
graph is a collection of nodes (or vertices) and edges (or relationships). A node represents an entity (for
example, a person or an organization). An edge represents a relationship between the two nodes that it connects
(for example, likes or friends).
Here are some features that make a graph database unique:
Edges are first-class entities in a graph database. They can have attributes or properties associated with them.
A single edge can flexibly connect multiple nodes in a graph database.
You can express pattern matching and multi-hop navigation queries easily.
You can express transitive closure and polymorphic queries easily.
Graph relationships and graph query capabilities are integrated into Transact-SQL and receive the benefits of
using the SQL Server database engine as the foundational database management system. Graph features use
standard Transact-SQL queries enhanced with the graph MATCH operator to query the graph data.
A relational database can achieve anything that a graph database can. However, a graph database can make it
easier to express certain queries. Your decision to choose one over the other can be based on the following
factors:
You need to model hierarchical data where one node can have multiple parents, so you can't use the
hierarchyId data type.
Your application has complex many-to-many relationships. As the application evolves, new relationships are
added.
You need to analyze interconnected data and relationships.
You want to use graph-specific T-SQL search conditions such as SHORTEST_PATH.

JSON features
In Azure SQL products, you can parse and query data represented in JavaScript Object Notation (JSON) format,
and export your relational data as JSON text. JSON is a core feature of the SQL Server database engine.
JSON features enable you to put JSON documents in tables, transform relational data into JSON documents,
and transform JSON documents into relational data. You can use the standard Transact-SQL language enhanced
with JSON functions for parsing documents. You can also use non-clustered indexes, columnstore indexes, or
memory-optimized tables to optimize your queries.
JSON is a popular data format for exchanging data in modern web and mobile applications. JSON is also used
for storing semistructured data in log files or in NoSQL databases. Many REST web services return results
formatted as JSON text or accept data formatted as JSON.
Most Azure services have REST endpoints that return or consume JSON. These services include Azure Cognitive
Search, Azure Storage, and Azure Cosmos DB.
If you have JSON text, you can extract data from JSON or verify that JSON is properly formatted by using the
built-in functions JSON_VALUE, JSON_QUERY, and ISJSON. The other functions are:
JSON_MODIFY: Lets you update values inside JSON text.
OPENJSON: Can transform an array of JSON objects into a set of rows, for more advanced querying and
analysis. Any SQL query can be executed on the returned result set.
FOR JSON: Lets you format data stored in your relational tables as JSON text.

For more information, see How to work with JSON data.

You can use document models instead of the relational models in some specific scenarios:
 High normalization of the schema doesn't bring significant benefits because you access all the fields of the
objects at once, or you never update normalized parts of the objects. However, the normalized model
increases the complexity of your queries because you need to join a large number of tables to get the data.
You're working with applications that natively use JSON documents for communication or data models, and
you don't want to introduce more layers that transform relational data into JSON and vice versa.
You need to simplify your data model by denormalizing child tables or Entity-Object-Value patterns.
You need to load or export data stored in JSON format without an additional tool that parses the data.

XML features
XML features enable you to store and index XML data in your database and use native XQuery/XPath operations
to work with XML data. Azure SQL products have a specialized, built-in XML data type and query functions that
process XML data.
The SQL Server database engine provides a powerful platform for developing applications to manage
semistructured data. Support for XML is integrated into all the components of the database engine and includes:
The ability to store XML values natively in an XML data-type column that can be typed according to a
collection of XML schemas or left untyped. You can index the XML column.
The ability to specify an XQuery query against XML data stored in columns and variables of the XML type.
You can use XQuery functionalities in any Transact-SQL query that accesses a data model that you use in
your database.
Automatic indexing of all elements in XML documents by using the primary XML index. Or you can specify
the exact paths that should be indexed by using the secondary XML index.
OPENROWSET , which allows the bulk loading of XML data.
The ability to transform relational data into XML format.
You can use document models instead of the relational models in some specific scenarios:
High normalization of the schema doesn't bring significant benefits because you access all the fields of the
objects at once, or you never update normalized parts of the objects. However, the normalized model
increases the complexity of your queries because you need to join a large number of tables to get the data.
You're working with applications that natively use XML documents for communication or data models, and
you don't want to introduce more layers that transform relational data into JSON and vice versa.
You need to simplify your data model by denormalizing child tables or Entity-Object-Value patterns.
You need to load or export data stored in XML format without an additional tool that parses the data.

Spatial features
Spatial data represents information about the physical location and shape of objects. These objects can be point
locations or more complex objects such as countries/regions, roads, or lakes.
Azure SQL supports two spatial data types:
The geometry type represents data in a Euclidean (flat) coordinate system.
The geography type represents data in a round-earth coordinate system.
Spatial features in Azure SQL enable you to store geometrical and geographical data. You can use spatial objects
in Azure SQL to parse and query data represented in JSON format, and export your relational data as JSON text.
These spatial objects include Point, LineString, and Polygon. Azure SQL also provides specialized spatial indexes
that you can use to improve the performance of your spatial queries.
Spatial support is a core feature of the SQL Server database engine.
Key-value pairs
Azure SQL products don't have specialized types or structures that support key-value pairs, because key-value
structures can be natively represented as standard relational tables:

CREATE TABLE Collection (

Id int identity primary key,
Data nvarchar(max)
)

You can customize this key-value structure to fit your needs without any constraints. As an example, the value
can be an XML document instead of the nvarchar(max) type. If the value is a JSON document, you can use a
CHECK constraint that verifies the validity of JSON content. You can put any number of values related to one key
in the additional columns. For example:
Add computed columns and indexes to simplify and optimize data access.
Define the table as a memory-optimized, schema-only table to get better performance.
For an example of how a relational model can be effectively used as a key-value pair solution in practice, see
How bwin is using SQL Server 2016 In-Memory OLTP to achieve unprecedented performance and scale. In this
case study, bwin used a relational model for its ASP.NET caching solution to achieve 1.2 million batches per
second.

Next steps
Multi-model capabilities are core SQL Server database engine features that are shared among Azure SQL
products. To learn more about these features, see these articles:
Graph processing with SQL Server and Azure SQL Database
JSON data in SQL Server
Spatial data in SQL Server
XML data in SQL Server
Key-value store performance in Azure SQL Database
 Maintenance window (Preview)
12/6/2021 • 8 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

The maintenance window feature allows you to configure maintenance schedule for Azure SQL Database and
Azure SQL Managed Instance resources making impactful maintenance events predictable and less disruptive
for your workload.

NOTE
The maintenance window feature only protects from planned impact from upgrades or scheduled maintenance. It does
not protect from all failover causes; exceptions that may cause short connection interruptions outside of a maintenance
window include hardware failures, cluster load balancing, and database reconfigurations due to events like a change in
database Service Level Objective.

Overview
Azure periodically performs planned maintenance of SQL Database and SQL managed instance resources.
During Azure SQL maintenance event, databases are fully available but can be subject to short reconfigurations
within respective availability SLAs for SQL Database and SQL managed instance.
Maintenance window is intended for production workloads that are not resilient to database or instance
reconfigurations and cannot absorb short connection interruptions caused by planned maintenance events. By
choosing a maintenance window you prefer, you can minimize the impact of planned maintenance as it will be
occurring outside of your peak business hours. Resilient workloads and non-production workloads may rely on
Azure SQL's default maintenance policy.
The maintenance window can be configured on creation or for existing Azure SQL resources. It can be
configured using theAzure portal,PowerShell, CLI, or Azure API.

IMPORTANT
Configuring maintenance window is a long running asynchronous operation, similar to changing the service tier of the
Azure SQL resource. The resource is available during the operation, except a short reconfiguration that happens at the
end of the operation and typically lasts up to 8 seconds even in case of interrupted long-running transactions. To
minimize the impact of the reconfiguration you should perform the operation outside of the peak hours.

Gain more predictability with maintenance window

By default, Azure SQL maintenance policy blocks most impactful updates during the period 8AM to 5PM local
time ever y day to avoid any disruptions during typical peak business hours. Local time is determined by the
location of Azure region that hosts the resource and may observe daylight saving time in accordance with local
time zone definition.
You can further adjust the maintenance updates to a time suitable to your Azure SQL resources by choosing
from two additional maintenance window slots:
Weekday window: 10:00 PM to 6:00 AM local time, Monday - Thursday
Weekend window: 10:00 PM to 6:00 AM local time, Friday - Sunday
Maintenance window days listed indicate the starting day of each eight-hour maintenance window. For example,
"10:00 PM to 6:00 AM local time, Monday – Thursday" means that the maintenance windows start at 10:00 PM
local time on each day (Monday through Thursday) and complete at 6:00 AM local time the following day
(Tuesday through Friday).
Once the maintenance window selection is made and service configuration completed, planned maintenance
will occur only during the window of your choice. While maintenance events typically complete within a single
window, some of them may span two or more adjacent windows.

IMPORTANT
In very rare circumstances where any postponement of action could cause serious impact, like applying critical security
patch, configured maintenance window may be temporarily overriden.

Cost and eligibility

Configuring and using maintenance window is free of charge for all eligible offer types: Pay-As-You-Go, Cloud
Solution Provider (CSP), Microsoft Enterprise Agreement, or Microsoft Customer Agreement.

NOTE
An Azure offer is the type of the Azure subscription you have. For example, a subscription with pay-as-you-go rates,
Azure in Open, and Visual Studio Enterprise are all Azure offers. Each offer or plan has different terms and benefits. Your
offer or plan is shown on the subscription's Overview. For more information on switching your subscription to a different
offer, see Change your Azure subscription to a different offer.

Advance notifications
Maintenance notifications can be configured to alert you on upcoming planned maintenance events for your
Azure SQL Database 24 hours in advance, at the time of maintenance, and when the maintenance is complete.
For more information, see Advance Notifications.

Availability
Supported service level objectives
Choosing a maintenance window other than the default is available on all SLOs except for :
Instance pools
Legacy Gen4 vCore
Basic, S0 and S1
DC, Fsv2, M-series
Azure region support
Choosing a maintenance window other than the default is currently available in the following regions:

SQ L DATA B A SE IN A N
A Z URE REGIO N SQ L M A N A GED IN STA N C E SQ L DATA B A SE A Z URE AVA IL A B IL IT Y Z O N E

Australia Central 1 Yes

Australia Central 2 Yes

Australia East Yes Yes Yes

Australia Southeast Yes Yes

 SQ L DATA B A SE IN A N
A Z URE REGIO N SQ L M A N A GED IN STA N C E SQ L DATA B A SE A Z URE AVA IL A B IL IT Y Z O N E

Brazil South Yes Yes

Canada Central Yes Yes Yes

Canada East Yes Yes

Central India Yes Yes

Central US Yes Yes Yes

China East 2 Yes Yes

China North 2 Yes Yes

East US Yes Yes Yes

East US 2 Yes Yes Yes

East Asia Yes Yes

France Central Yes Yes

France South Yes Yes

Germany West Central Yes Yes

Germany North Yes

Japan East Yes Yes Yes

Japan West Yes Yes

Korea Central Yes

Korea South Yes

North Central US Yes Yes

North Europe Yes Yes Yes

South Africa North Yes

South Africa West Yes

South Central US Yes Yes Yes

South India Yes Yes

Southeast Asia Yes Yes Yes

 SQ L DATA B A SE IN A N
A Z URE REGIO N SQ L M A N A GED IN STA N C E SQ L DATA B A SE A Z URE AVA IL A B IL IT Y Z O N E

Switzerland North Yes Yes

Switzerland West Yes

UAE Central Yes

UAE North Yes

UK South Yes Yes Yes

UK West Yes Yes

West Central US Yes Yes

West Europe Yes Yes Yes

West India Yes

West US Yes Yes

West US 2 Yes Yes Yes

Gateway maintenance for Azure SQL Database

To get the maximum benefit from maintenance windows, make sure your client applications are using the
redirect connection policy. Redirect is the recommended connection policy, where clients establish connections
directly to the node hosting the database, leading to reduced latency and improved throughput.
In Azure SQL Database, any connections using the proxy connection policy could be affected by both the
chosen maintenance window and a gateway node maintenance window. However, client connections
using the recommended redirect connection policy are unaffected by a gateway node maintenance
reconfiguration.
In Azure SQL Managed Instance, the gateway nodes are hosted within the virtual cluster and have the
same maintenance window as the managed instance, but using the redirect connection policy is still
recommended to minimize number of disruptions during the maintenance event.
For more on the client connection policy in Azure SQL Database, see Azure SQL Database Connection policy.
For more on the client connection policy in Azure SQL Managed Instance, see Azure SQL Managed Instance
connection types.

Considerations for Azure SQL Managed Instance

Azure SQL Managed Instance consists of service components hosted on a dedicated set of isolated virtual
machines that run inside the customer's virtual network subnet. These virtual machines form virtual cluster(s)
that can host multiple managed instances. Maintenance window configured on instances of one subnet can
influence the number of virtual clusters within the subnet, distribution of instances among virtual clusters, and
virtual cluster management operations. This may require a consideration of few effects.
Maintenance window configuration is long running operation
All instances hosted in a virtual cluster share the maintenance window. By default, all managed instances are
hosted in the virtual cluster with the default maintenance window. Specifying another maintenance window for
managed instance during its creation or afterwards means that it must be placed in virtual cluster with
corresponding maintenance window. If there is no such virtual cluster in the subnet, a new one must be created
first to accommodate the instance. Accommodating additional instance in the existing virtual cluster may
require cluster resize. Both operations contribute to the duration of configuring maintenance window for a
managed instance. Expected duration of configuring maintenance window on managed instance can be
calculated using estimated duration of instance management operations.

IMPORTANT
A short reconfiguration happens at the end of the maintenance operation and typically lasts up to 8 seconds even in case
of interrupted long-running transactions. To minimize the impact of the reconfiguration you should schedule the
operation outside of the peak hours.

IP address space requirements

Each new virtual cluster in subnet requires additional IP addresses according to the virtual cluster IP address
allocation. Changing maintenance window for existing managed instance also requires temporary additional IP
capacity as in scaling vCores scenario for corresponding service tier.
IP address change
Configuring and changing maintenance window causes change of the IP address of the instance, within the IP
address range of the subnet.

IMPORTANT
Make sure that NSG and firewall rules won't block data traffic after IP address change.

Serialization of virtual cluster management operations

Operations affecting the virtual cluster, like service upgrades and virtual cluster resize (adding new or removing
unneeded compute nodes) are serialized. In other words, a new virtual cluster management operation cannot
start until the previous one is completed. In case that maintenance window closes before the ongoing service
upgrade or maintenance operation is completed, any other virtual cluster management operations submitted in
the meantime will be put on hold until next maintenance window opens and service upgrade or maintenance
operation completes. It is not common for a maintenance operation to take longer than a single window per
virtual cluster, but it can happen in case of very complex maintenance operations.
The serialization of virtual cluster management operations is general behavior that applies to the default
maintenance policy as well. With a maintenance window schedule configured, the period between two adjacent
windows can be few days long. Submitted operations can also be on hold for few days if the maintenance
operation spans two windows. That is very rare case, but creation of new instances or resize of the existing
instances (if additional compute nodes are needed) may be blocked during this period.

Next steps
Configure maintenance window
Advance notifications

Learn more
Maintenance window FAQ
Azure SQL Database
SQL managed instance
Plan for Azure maintenance events in Azure SQL Database and Azure SQL Managed Instance
 Configure maintenance window (Preview)
12/6/2021 • 10 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

Configure the maintenance window (Preview) for an Azure SQL database, elastic pool, or Azure SQL Managed
Instance database during resource creation, or anytime after a resource is created.
The System default maintenance window is 5PM to 8AM daily (local time of the Azure region the resource is
located) to avoid peak business hours interruptions. If the System default maintenance window is not the best
time, select one of the other available maintenance windows.
The ability to change to a different maintenance window is not available for every service level or in every
region. For details on availability, see Maintenance window availability.

IMPORTANT
Configuring maintenance window is a long running asynchronous operation, similar to changing the service tier of the
Azure SQL resource. The resource is available during the operation, except a short reconfiguration that happens at the
end of the operation and typically lasts up to 8 seconds even in case of interrupted long-running transactions. To
minimize the impact of the reconfiguration you should perform the operation outside of the peak hours.

Configure maintenance window during database creation

Portal
PowerShell
CLI

To configure the maintenance window when you create a database, elastic pool, or managed instance, set the
desired Maintenance window on the Additional settings page.

Set the maintenance window while creating a single database or

elastic pool
For step-by-step information on creating a new database or pool, see Create an Azure SQL Database single
database.
Set the maintenance window while creating a managed instance
For step-by-step information on creating a new managed instance, see Create an Azure SQL Managed Instance.
Configure maintenance window for existing databases
When applying a maintenance window selection to a database, a brief reconfiguration (several seconds) may be
experienced in some cases as Azure applies the required changes.

Portal
PowerShell
CLI

The following steps set the maintenance window on an existing database, elastic pool, or managed instance
using the Azure portal:

Set the maintenance window for an existing database or elastic pool

1. Navigate to the SQL database or elastic pool you want to set the maintenance window for.
2. In the Settings menu select Maintenance , then select the desired maintenance window.

Set the maintenance window for an existing managed instance

1. Navigate to the managed instance you want to set the maintenance window for.
2. In the Settings menu select Maintenance , then select the desired maintenance window.
Cleanup resources
Be sure to delete unneeded resources after you're finished with them to avoid unnecessary charges.

Portal
PowerShell
CLI

1. Navigate to the SQL database or elastic pool you no longer need.

2. On the Over view menu, select the option to delete the resource.

Next steps
To learn more about maintenance window, see Maintenance window (Preview).
For more information, see Maintenance window FAQ.
To learn about optimizing performance, see Monitoring and performance tuning in Azure SQL Database and
Azure SQL Managed Instance.
 Advance notifications for planned maintenance
events (Preview)
12/6/2021 • 2 minutes to read • Edit Online

APPLIES TO: Azure SQL Database

Advance notifications (Preview) is available for databases configured to use a non-default Maintenance Window
(Preview). Advance notifications enable customers to configure notifications to be sent up to 24 hours in
advance of any planned event.
Notifications can be configured so you can get texts, emails, Azure push notifications, and voicemails when
planned maintenance is due to begin in the next 24 hours. Additional notifications are sent when maintenance
begins and when maintenance ends.
Advance notifications cannot be configured for the System default maintenance window option. Choose a
maintenance window other than the System default to configure and enable Advance notifications.

NOTE
While the ability to choose a maintenance window is available for Azure SQL managed instances, advance notifications are
not currently available for Azure SQL managed instances.

Create an advance notification

Advance notifications are available for Azure SQL databases that have their maintenance window configured.
Complete the following steps to enable a notification.
1. Go to the Planned maintenance page, select Health aler ts , then Add ser vice health aler t .

2. In the Actions section, select Add action groups .

3. Complete the Create action group form, then select Next: Notifications .
4. On the Notifications tab, select the Notification type . The Email/SMS message/Push/Voice option
offers the most flexibility and is the recommended option. Select the pen to configure the notification.

a. Complete the Add or edit notification form that opens and select OK :
b. Actions and Tags are optional. Here you can configure additional actions to be triggered or use
tags to categorize and organize your Azure resources.
c. Check the details on the Review + create tab and select Create .
5. After selecting create, the alert rule configuration screen opens and the action group will be selected. Give
a name to your new alert rule, then choose the resource group for it, and select Create aler t rule .
6. Click the Health aler ts menu item again, and the list of alerts now contains your new alert.
You're all set. Next time there's a planned Azure SQL maintenance event, you'll receive an advance notification.

Receiving notifications
The following table shows the general-information notifications you may receive:

STAT US DESC RIP T IO N

Planned Deployment Received 24 hours prior to the maintenance event.

Maintenance is planned on DATE between 5pm - 8am (local
time) for DBxyz.

In-Progress Maintenance for databasexyzis starting.

Complete Maintenance of database xyz is complete.

The following table shows additional notifications that may be sent while maintenance is ongoing:

STAT US DESC RIP T IO N

Extended Maintenance is in progress but didn't complete for database

xyz. Maintenance will continue at the next maintenance
window.
 STAT US DESC RIP T IO N

Canceled Maintenance for database xyz is canceled and will be

rescheduled later.

Blocked There was a problem during maintenance for database xyz.

We'll notify you when we resume.

Resumed The problem has been resolved and maintenance will

continue at the next maintenance window.

Next steps
Maintenance window
Maintenance window FAQ
Overview of alerts in Microsoft Azure
Email Azure Resource Manager Role
 Optimize performance by using in-memory
technologies in Azure SQL Database and Azure
SQL Managed Instance
12/6/2021 • 11 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

In-memory technologies enable you to improve performance of your application, and potentially reduce cost of
your database.

When to use in-memory technologies

By using in-memory technologies, you can achieve performance improvements with various workloads:
Transactional (online transactional processing (OLTP)) where most of the requests read or update smaller
set of data (for example, CRUD operations).
Analytic (online analytical processing (OLAP)) where most of the queries have complex calculations for the
reporting purposes, with a certain number of queries that load and append data to the existing tables (so
called bulk-load), or delete the data from the tables.
Mixed (hybrid transaction/analytical processing (HTAP)) where both OLTP and OLAP queries are executed on
the same set of data.
In-memory technologies can improve performance of these workloads by keeping the data that should be
processed into the memory, using native compilation of the queries, or advanced processing such as batch
processing and SIMD instructions that are available on the underlying hardware.

Overview
Azure SQL Database and Azure SQL Managed Instance have the following in-memory technologies:
In-Memory OLTP increases number of transactions per second and reduces latency for transaction
processing. Scenarios that benefit from In-Memory OLTP are: high-throughput transaction processing such
as trading and gaming, data ingestion from events or IoT devices, caching, data load, and temporary table
and table variable scenarios.
Clustered columnstore indexes reduce your storage footprint (up to 10 times) and improve performance for
reporting and analytics queries. You can use it with fact tables in your data marts to fit more data in your
database and improve performance. Also, you can use it with historical data in your operational database to
archive and be able to query up to 10 times more data.
Nonclustered columnstore indexes for HTAP help you to gain real-time insights into your business through
querying the operational database directly, without the need to run an expensive extract, transform, and load
(ETL) process and wait for the data warehouse to be populated. Nonclustered columnstore indexes allow fast
execution of analytics queries on the OLTP database, while reducing the impact on the operational workload.
Memory-optimized clustered columnstore indexes for HTAP enables you to perform fast transaction
processing, and to concurrently run analytics queries very quickly on the same data.
Both columnstore indexes and In-Memory OLTP have been part of the SQL Server product since 2012 and
2014, respectively. Azure SQL Database, Azure SQL Managed Instance, and SQL Server share the same
implementation of in-memory technologies.
Benefits of in-memory technology
Because of the more efficient query and transaction processing, in-memory technologies also help you to
reduce cost. You typically don't need to upgrade the pricing tier of the database to achieve performance gains. In
some cases, you might even be able reduce the pricing tier, while still seeing performance improvements with
in-memory technologies.
By using In-Memory OLTP, Quorum Business Solutions was able to double their workload while improving DTUs
by 70%. For more information, see the blog post: In-Memory OLTP.

NOTE
In-memory technologies are available in the Premium and Business Critical tiers.

This article describes aspects of In-Memory OLTP and columnstore indexes that are specific to Azure SQL
Database and Azure SQL Managed Instance, and also includes samples:
You'll see the impact of these technologies on storage and data size limits.
You'll see how to manage the movement of databases that use these technologies between the different
pricing tiers.
You'll see two samples that illustrate the use of In-Memory OLTP, as well as columnstore indexes.
For more information about in-memory in SQL Server, see:
In-Memory OLTP Overview and Usage Scenarios (includes references to customer case studies and
information to get started)
Documentation for In-Memory OLTP
Columnstore Indexes Guide
Hybrid transactional/analytical processing (HTAP), also known as real-time operational analytics

In-Memory OLTP
In-Memory OLTP technology provides extremely fast data access operations by keeping all data in memory. It
also uses specialized indexes, native compilation of queries, and latch-free data-access to improve performance
of the OLTP workload. There are two ways to organize your In-Memory OLTP data:
Memor y-optimized rowstore format where every row is a separate memory object. This is a classic
In-Memory OLTP format optimized for high-performance OLTP workloads. There are two types of
memory-optimized tables that can be used in the memory-optimized rowstore format:
Durable tables (SCHEMA_AND_DATA) where the rows placed in memory are preserved after server
restart. This type of tables behaves like a traditional rowstore table with the additional benefits of in-
memory optimizations.
Non-durable tables (SCHEMA_ONLY) where the rows are not-preserved after restart. This type of
table is designed for temporary data (for example, replacement of temp tables), or tables where you
need to quickly load data before you move it to some persisted table (so called staging tables).
Memor y-optimized columnstore format where data is organized in a columnar format. This structure
is designed for HTAP scenarios where you need to run analytic queries on the same data structure where
your OLTP workload is running.
 NOTE
In-Memory OLTP technology is designed for the data structures that can fully reside in memory. Since the In-memory
data cannot be offloaded to disk, make sure that you are using database that has enough memory. See Data size and
storage cap for In-Memory OLTP for more details.

A quick primer on In-Memory OLTP: Quickstart 1: In-Memory OLTP Technologies for Faster T-SQL
Performance.
There is a programmatic way to understand whether a given database supports In-Memory OLTP. You can
execute the following Transact-SQL query:

SELECT DatabasePropertyEx(DB_NAME(), 'IsXTPSupported');

If the query returns 1 , In-Memory OLTP is supported in this database. The following queries identify all objects
that need to be removed before a database can be downgraded to General Purpose, Standard, or Basic:

SELECT * FROM sys.tables WHERE is_memory_optimized=1

SELECT * FROM sys.table_types WHERE is_memory_optimized=1
SELECT * FROM sys.sql_modules WHERE uses_native_compilation=1

Data size and storage cap for In-Memory OLTP

In-Memory OLTP includes memory-optimized tables, which are used for storing user data. These tables are
required to fit in memory. Because you manage memory directly in SQL Database, we have the concept of a
quota for user data. This idea is referred to as In-Memory OLTP storage.
Each supported single database pricing tier and each elastic pool pricing tier includes a certain amount of In-
Memory OLTP storage.
DTU-based resource limits - single database
DTU-based resource limits - elastic pools
vCore-based resource limits - single databases
vCore-based resource limits - elastic pools
vCore-based resource limits - managed instance
The following items count toward your In-Memory OLTP storage cap:
Active user data rows in memory-optimized tables and table variables. Note that old row versions don't
count toward the cap.
Indexes on memory-optimized tables.
Operational overhead of ALTER TABLE operations.
If you hit the cap, you receive an out-of-quota error, and you are no longer able to insert or update data. To
mitigate this error, delete data or increase the pricing tier of the database or pool.
For details about monitoring In-Memory OLTP storage utilization and configuring alerts when you almost hit
the cap, see Monitor in-memory storage.
About elastic pools
With elastic pools, the In-Memory OLTP storage is shared across all databases in the pool. Therefore, the usage
in one database can potentially affect other databases. Two mitigations for this are:
Configure a Max-eDTU or MaxvCore for databases that is lower than the eDTU or vCore count for the pool as
a whole. This maximum caps the In-Memory OLTP storage utilization, in any database in the pool, to the size
 that corresponds to the eDTU count.
Configure a Min-eDTU or MinvCore that is greater than 0. This minimum guarantees that each database in
the pool has the amount of available In-Memory OLTP storage that corresponds to the configured Min-eDTU
or vCore .
Changing service tiers of databases that use In-Memory OLTP technologies
You can always upgrade your database or instance to a higher tier, such as from General Purpose to Business
Critical (or Standard to Premium). The available functionality and resources only increase.
But downgrading the tier can negatively impact your database. The impact is especially apparent when you
downgrade from Business Critical to General Purpose (or Premium to Standard or Basic) when your database
contains In-Memory OLTP objects. Memory-optimized tables are unavailable after the downgrade (even if they
remain visible). The same considerations apply when you're lowering the pricing tier of an elastic pool, or
moving a database with in-memory technologies, into a General Purpose, Standard, or Basic elastic pool.

IMPORTANT
In-Memory OLTP isn't supported in the General Purpose, Standard or Basic tier. Therefore, it isn't possible to move a
database that has any In-Memory OLTP objects to one of these tiers.

Before you downgrade the database to General Purpose, Standard, or Basic, remove all memory-optimized
tables and table types, as well as all natively compiled T-SQL modules.
Scaling-down resources in Business Critical tier: Data in memory-optimized tables must fit within the In-
Memory OLTP storage that is associated with the tier of the database or the managed instance, or it is available
in the elastic pool. If you try to scale-down the tier or move the database into a pool that doesn't have enough
available In-Memory OLTP storage, the operation fails.

In-memory columnstore
In-memory columnstore technology is enabling you to store and query a large amount of data in the tables.
Columnstore technology uses column-based data storage format and batch query processing to achieve gain
up to 10 times the query performance in OLAP workloads over traditional row-oriented storage. You can also
achieve gains up to 10 times the data compression over the uncompressed data size. There are two types of
columnstore models that you can use to organize your data:
Clustered columnstore where all data in the table is organized in the columnar format. In this model, all
rows in the table are placed in columnar format that highly compresses the data and enables you to execute
fast analytical queries and reports on the table. Depending on the nature of your data, the size of your data
might be decreased 10x-100x. Clustered columnstore model also enables fast ingestion of large amount of
data (bulk-load) since large batches of data greater than 100K rows are compressed before they are stored
on disk. This model is a good choice for the classic data warehouse scenarios.
Non-clustered columnstore where the data is stored in traditional rowstore table and there is an index in
the columnstore format that is used for the analytical queries. This model enables Hybrid Transactional-
Analytic Processing (HTAP): the ability to run performant real-time analytics on a transactional workload.
OLTP queries are executed on rowstore table that is optimized for accessing a small set of rows, while OLAP
queries are executed on columnstore index that is better choice for scans and analytics. The query optimizer
dynamically chooses rowstore or columnstore format based on the query. Non-clustered columnstore
indexes don't decrease the size of the data since original data-set is kept in the original rowstore table
without any change. However, the size of additional columnstore index should be in order of magnitude
smaller than the equivalent B-tree index.
 NOTE
In-memory columnstore technology keeps only the data that is needed for processing in the memory, while the data that
cannot fit into the memory is stored on-disk. Therefore, the amount of data in in-memory columnstore structures can
exceed the amount of available memory.

In-depth video about the technology:

Columnstore Index: In-memory Analytics Videos from Ignite 2016
Data size and storage for columnstore indexes
Columnstore indexes aren't required to fit in memory. Therefore, the only cap on the size of the indexes is the
maximum overall database size, which is documented in the DTU-based purchasing model and vCore-based
purchasing model articles.
When you use clustered columnstore indexes, columnar compression is used for the base table storage. This
compression can significantly reduce the storage footprint of your user data, which means that you can fit more
data in the database. And the compression can be further increased with columnar archival compression. The
amount of compression that you can achieve depends on the nature of the data, but 10 times the compression
is not uncommon.
For example, if you have a database with a maximum size of 1 terabyte (TB) and you achieve 10 times the
compression by using columnstore indexes, you can fit a total of 10 TB of user data in the database.
When you use nonclustered columnstore indexes, the base table is still stored in the traditional rowstore format.
Therefore, the storage savings aren't as significant as with clustered columnstore indexes. However, if you're
replacing a number of traditional nonclustered indexes with a single columnstore index, you can still see an
overall savings in the storage footprint for the table.
Changing service tiers of databases containing Columnstore indexes
Downgrading single database to Basic or Standard might not be possible if your target tier is below S3.
Columnstore indexes are supported only on the Business Critical/Premium pricing tier and on the Standard tier,
S3 and above, and not on the Basic tier. When you downgrade your database to an unsupported tier or level,
your columnstore index becomes unavailable. The system maintains your columnstore index, but it never
leverages the index. If you later upgrade back to a supported tier or level, your columnstore index is
immediately ready to be leveraged again.
If you have a clustered columnstore index, the whole table becomes unavailable after the downgrade.
Therefore we recommend that you drop all clustered columnstore indexes before you downgrade your database
to an unsupported tier or level.

NOTE
SQL Managed Instance supports Columnstore indexes in all tiers.

Next steps
Quickstart 1: In-Memory OLTP Technologies for faster T-SQL Performance
Use In-Memory OLTP in an existing Azure SQL application
Monitor In-Memory OLTP storage for In-Memory OLTP
Try in-memory features
Additional resources
Deeper information
Learn how Quorum doubles key database's workload while lowering DTU by 70% with In-Memory OLTP in
SQL Database
In-Memory OLTP Blog Post
Learn about In-Memory OLTP
Learn about columnstore indexes
Learn about real-time operational analytics
See Common Workload Patterns and Migration Considerations (which describes workload patterns where
In-Memory OLTP commonly provides significant performance gains)
Application design
In-Memory OLTP (in-memory optimization)
Use In-Memory OLTP in an existing Azure SQL application
Tools
Azure portal
SQL Server Management Studio (SSMS)
SQL Server Data Tools (SSDT)
 Getting started with temporal tables in Azure SQL
Database and Azure SQL Managed Instance
12/6/2021 • 7 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

Temporal tables are a programmability feature of Azure SQL Database and Azure SQL Managed Instance that
allows you to track and analyze the full history of changes in your data, without the need for custom coding.
Temporal tables keep data closely related to time context so that stored facts can be interpreted as valid only
within the specific period. This property of temporal tables allows for efficient time-based analysis and getting
insights from data evolution.

Temporal scenario
This article illustrates the steps to utilize temporal tables in an application scenario. Suppose that you want to
track user activity on a new website that is being developed from scratch or on an existing website that you
want to extend with user activity analytics. In this simplified example, we assume that the number of visited web
pages during a period of time is an indicator that needs to be captured and monitored in the website database
that is hosted on Azure SQL Database or Azure SQL Managed Instance. The goal of the historical analysis of user
activity is to get inputs to redesign website and provide better experience for the visitors.
The database model for this scenario is very simple - user activity metric is represented with a single integer
field, PageVisited , and is captured along with basic information on the user profile. Additionally, for time-based
analysis, you would keep a series of rows for each user, where every row represents the number of pages a
particular user visited within a specific period of time.

Fortunately, you do not need to put any effort in your app to maintain this activity information. With temporal
tables, this process is automated - giving you full flexibility during website design and more time to focus on the
data analysis itself. The only thing you have to do is to ensure that WebSiteInfo table is configured as temporal
system-versioned. The exact steps to utilize temporal tables in this scenario are described below.

Step 1: Configure tables as temporal

Depending on whether you are starting new development or upgrading existing application, you will either
create temporal tables or modify existing ones by adding temporal attributes. In general case, your scenario can
be a mix of these two options. Perform these action using SQL Server Management Studio (SSMS), SQL Server
Data Tools (SSDT), Azure Data Studio, or any other Transact-SQL development tool.
 IMPORTANT
It is recommended that you always use the latest version of Management Studio to remain synchronized with updates to
Azure SQL Database and Azure SQL Managed Instance. Update SQL Server Management Studio.

Create new table

Use context menu item "New System-Versioned Table" in SSMS Object Explorer to open the query editor with a
temporal table template script and then use "Specify Values for Template Parameters" (Ctrl+Shift+M) to
populate the template:

In SSDT, choose "Temporal Table (System-Versioned)" template when adding new items to the database project.
That will open table designer and enable you to easily specify the table layout:
You can also create temporal table by specifying the Transact-SQL statements directly, as shown in the example
below. Note that the mandatory elements of every temporal table are the PERIOD definition and the
SYSTEM_VERSIONING clause with a reference to another user table that will store historical row versions:

CREATE TABLE WebsiteUserInfo

(
[UserID] int NOT NULL PRIMARY KEY CLUSTERED
, [UserName] nvarchar(100) NOT NULL
, [PagesVisited] int NOT NULL
, [ValidFrom] datetime2 (0) GENERATED ALWAYS AS ROW START
, [ValidTo] datetime2 (0) GENERATED ALWAYS AS ROW END
, PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.WebsiteUserInfoHistory));

When you create system-versioned temporal table, the accompanying history table with the default
configuration is automatically created. The default history table contains a clustered B-tree index on the period
columns (end, start) with page compression enabled. This configuration is optimal for the majority of scenarios
in which temporal tables are used, especially for data auditing.
In this particular case, we aim to perform time-based trend analysis over a longer data history and with bigger
data sets, so the storage choice for the history table is a clustered columnstore index. A clustered columnstore
provides very good compression and performance for analytical queries. Temporal tables give you the flexibility
to configure indexes on the current and temporal tables completely independently.

NOTE
Columnstore indexes are available in the Business Critical, General Purpose, and Premium tiers and in the Standard tier, S3
and above.

The following script shows how default index on history table can be changed to the clustered columnstore:

CREATE CLUSTERED COLUMNSTORE INDEX IX_WebsiteUserInfoHistory

ON dbo.WebsiteUserInfoHistory
WITH (DROP_EXISTING = ON);

Temporal tables are represented in the Object Explorer with the specific icon for easier identification, while its
history table is displayed as a child node.
Alter existing table to temporal
Let's cover the alternative scenario in which the WebsiteUserInfo table already exists, but was not designed to
keep a history of changes. In this case, you can simply extend the existing table to become temporal, as shown in
the following example:

ALTER TABLE WebsiteUserInfo

ADD
ValidFrom datetime2 (0) GENERATED ALWAYS AS ROW START HIDDEN
constraint DF_ValidFrom DEFAULT DATEADD(SECOND, -1, SYSUTCDATETIME())
, ValidTo datetime2 (0) GENERATED ALWAYS AS ROW END HIDDEN
constraint DF_ValidTo DEFAULT '9999.12.31 23:59:59.99'
, PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo);

ALTER TABLE WebsiteUserInfo

SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.WebsiteUserInfoHistory));
GO

CREATE CLUSTERED COLUMNSTORE INDEX IX_WebsiteUserInfoHistory

ON dbo.WebsiteUserInfoHistory
WITH (DROP_EXISTING = ON);

Step 2: Run your workload regularly

The main advantage of temporal tables is that you do not need to change or adjust your website in any way to
perform change tracking. Once created, temporal tables transparently persist previous row versions every time
you perform modifications on your data.
In order to leverage automatic change tracking for this particular scenario, let's just update column
PagesVisited every time a user ends their session on the website:
 UPDATE WebsiteUserInfo SET [PagesVisited] = 5
WHERE [UserID] = 1;

It is important to notice that the update query doesn't need to know the exact time when the actual operation
occurred nor how historical data will be preserved for future analysis. Both aspects are automatically handled by
Azure SQL Database and Azure SQL Managed Instance. The following diagram illustrates how history data is
being generated on every update.

Step 3: Perform historical data analysis

Now when temporal system-versioning is enabled, historical data analysis is just one query away from you. In
this article, we will provide a few examples that address common analysis scenarios - to learn all details, explore
various options introduced with the FOR SYSTEM_TIME clause.
To see the top 10 users ordered by the number of visited web pages as of an hour ago, run this query:

DECLARE @hourAgo datetime2 = DATEADD(HOUR, -1, SYSUTCDATETIME());

SELECT TOP 10 * FROM dbo.WebsiteUserInfo FOR SYSTEM_TIME AS OF @hourAgo
ORDER BY PagesVisited DESC

You can easily modify this query to analyze the site visits as of a day ago, a month ago or at any point in the past
you wish.
To perform basic statistical analysis for the previous day, use the following example:

DECLARE @twoDaysAgo datetime2 = DATEADD(DAY, -2, SYSUTCDATETIME());

DECLARE @aDayAgo datetime2 = DATEADD(DAY, -1, SYSUTCDATETIME());

SELECT UserID, SUM (PagesVisited) as TotalVisitedPages, AVG (PagesVisited) as AverageVisitedPages,

MAX (PagesVisited) AS MaxVisitedPages, MIN (PagesVisited) AS MinVisitedPages,
STDEV (PagesVisited) as StDevViistedPages
FROM dbo.WebsiteUserInfo
FOR SYSTEM_TIME BETWEEN @twoDaysAgo AND @aDayAgo
GROUP BY UserId

To search for activities of a specific user, within a period of time, use the CONTAINED IN clause:
 DECLARE @hourAgo datetime2 = DATEADD(HOUR, -1, SYSUTCDATETIME());
DECLARE @twoHoursAgo datetime2 = DATEADD(HOUR, -2, SYSUTCDATETIME());
SELECT * FROM dbo.WebsiteUserInfo
FOR SYSTEM_TIME CONTAINED IN (@twoHoursAgo, @hourAgo)
WHERE [UserID] = 1;

Graphic visualization is especially convenient for temporal queries as you can show trends and usage patterns in
an intuitive way very easily:

Evolving table schema

Typically, you will need to change the temporal table schema while you are doing app development. For that,
simply run regular ALTER TABLE statements and Azure SQL Database or Azure SQL Managed Instance
appropriately propagates changes to the history table. The following script shows how you can add additional
attribute for tracking:

/*Add new column for tracking source IP address*/

ALTER TABLE dbo.WebsiteUserInfo
ADD [IPAddress] varchar(128) NOT NULL CONSTRAINT DF_Address DEFAULT 'N/A';

Similarly, you can change column definition while your workload is active:

/*Increase the length of name column*/

ALTER TABLE dbo.WebsiteUserInfo
ALTER COLUMN UserName nvarchar(256) NOT NULL;

Finally, you can remove a column that you do not need anymore.

/*Drop unnecessary column */

ALTER TABLE dbo.WebsiteUserInfo
DROP COLUMN TemporaryColumn;
Alternatively, use latest SSDT to change temporal table schema while you are connected to the database (online
mode) or as part of the database project (offline mode).

Controlling retention of historical data

With system-versioned temporal tables, the history table may increase the database size more than regular
tables. A large and ever-growing history table can become an issue both due to pure storage costs as well as
imposing a performance tax on temporal querying. Hence, developing a data retention policy for managing data
in the history table is an important aspect of planning and managing the lifecycle of every temporal table. With
Azure SQL Database and Azure SQL Managed Instance, you have the following approaches for managing
historical data in the temporal table:
Table Partitioning
Custom Cleanup Script

Next steps
For more information on temporal tables, see check out Temporal Tables.
 Dynamically scale database resources with minimal
downtime
12/6/2021 • 5 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database and SQL Managed Instance enable you to dynamically add more resources to your
database with minimal downtime; however, there is a switch over period where connectivity is lost to the
database for a short amount of time, which can be mitigated using retry logic.

Overview
When demand for your app grows from a handful of devices and customers to millions, Azure SQL Database
and SQL Managed Instance scale on the fly with minimal downtime. Scalability is one of the most important
characteristics of platform as a service (PaaS) that enables you to dynamically add more resources to your
service when needed. Azure SQL Database enables you to easily change resources (CPU power, memory, IO
throughput, and storage) allocated to your databases.
You can mitigate performance issues due to increased usage of your application that cannot be fixed using
indexing or query rewrite methods. Adding more resources enables you to quickly react when your database
hits the current resource limits and needs more power to handle the incoming workload. Azure SQL Database
also enables you to scale-down the resources when they are not needed to lower the cost.
You don't need to worry about purchasing hardware and changing underlying infrastructure. Scaling a database
can be easily done via the Azure portal using a slider.

Azure SQL Database offers the DTU-based purchasing model and the vCore-based purchasing model, while
Azure SQL Managed Instance offers just the vCore-based purchasing model.
The DTU-based purchasing model offers a blend of compute, memory, and I/O resources in three service
tiers to support lightweight to heavyweight database workloads: Basic, Standard, and Premium. Performance
levels within each tier provide a different mix of these resources, to which you can add additional storage
resources.
The vCore-based purchasing model lets you choose the number of vCores, the amount or memory, and the
amount and speed of storage. This purchasing model offers three service tiers: General Purpose, Business
Critical, and Hyperscale.
The service tier, compute tier, and resource limits for a database, elastic pool, or managed instance can be
changed at any time. For example, you can build your first app on a single database using the serverless
compute tier and then change its service tier manually or programmatically at any time, to the provisioned
compute tier, to meet the needs of your solution.

NOTE
Notable exceptions where you cannot change the service tier of a database are:
Databases in the Hyperscale service tier cannot currently be changed to a different service tier.
Databases using features which are only available in the Business Critical / Premium service tiers, cannot be changed
to use the General Purpose / Standard service tier.
You can adjust the resources allocated to your database by changing service objective, or scaling, to meet
workload demands. This also enables you to only pay for the resources that you need, when you need them.
Please refer to the note on the potential impact that a scale operation might have on an application.

NOTE
Dynamic scalability is different from autoscale. Autoscale is when a service scales automatically based on criteria, whereas
dynamic scalability allows for manual scaling with a minimal downtime. Single databases in Azure SQL Database can be
scaled manually, or in the case of the Serverless tier, set to automatically scale the compute resources. Elastic pools, which
allow databases to share resources in a pool, can currently only be scaled manually.

Azure SQL Database offers the ability to dynamically scale your databases:
With a single database, you can use either DTU or vCore models to define maximum amount of resources
that will be assigned to each database.
Elastic pools enable you to define maximum resource limit per group of databases in the pool.
Azure SQL Managed Instance allows you to scale as well:
SQL Managed Instance uses vCores mode and enables you to define maximum CPU cores and maximum of
storage allocated to your instance. All databases within the managed instance will share the resources
allocated to the instance.

Impact of scale up or scale down operations

Initiating a scale up, or scale down action, in any of the flavors mentioned above, restarts the database engine
process, and moves it to a different virtual machine if needed. Moving the database engine process to a new
virtual machine is an online process during which you can continue using your existing Azure SQL Database
service. Once the target database engine is ready to process queries, open connections to the current database
engine will be terminated, and uncommitted transactions will be rolled back. New connections will be made to
the target database engine.

NOTE
It is not recommended to scale your managed instance if a long-running transaction, such as data import, data
processing jobs, index rebuild, etc., is running, or if you have any active connection on the instance. To prevent the scaling
from taking longer time to complete than usual, you should scale the instance upon the completion of all long-running
operations.

NOTE
You can expect a short connection break when the scale up/scale down process is finished. If you have implemented Retry
logic for standard transient errors, you will not notice the failover.

Alternative scale methods

Scaling resources is the easiest and the most effective way to improve performance of your database without
changing either the database or application code. In some cases, even the highest service tiers, compute sizes,
and performance optimizations might not handle your workload in a successful and cost-effective way. In that
case you have these additional options to scale your database:
Read scale-out is an available feature where you are getting one read-only replica of your data where you
can execute demanding read-only queries such as reports. A read-only replica will handle your read-only
 workload without affecting resource usage on your primary database.
Database sharding is a set of techniques that enables you to split your data into several databases and scale
them independently.

Next steps
For information about improving database performance by changing database code, see Find and apply
performance recommendations.
For information about letting built-in database intelligence optimize your database, see Automatic tuning.
For information about read scale-out in Azure SQL Database, see how to use read-only replicas to load
balance read-only query workloads.
For information about a Database sharding, see Scaling out with Azure SQL Database.
For an example of using scripts to monitor and scale a single database, see Use PowerShell to monitor and
scale a single SQL Database.
 Use read-only replicas to offload read-only query
workloads
12/6/2021 • 11 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

As part of High Availability architecture, each single database, elastic pool database, and managed instance in
the Premium and Business Critical service tier is automatically provisioned with a primary read-write replica
and several secondary read-only replicas. The secondary replicas are provisioned with the same compute size as
the primary replica. The read scale-out feature allows you to offload read-only workloads using the compute
capacity of one of the read-only replicas, instead of running them on the read-write replica. This way, some
read-only workloads can be isolated from the read-write workloads, and will not affect their performance. The
feature is intended for the applications that include logically separated read-only workloads, such as analytics. In
the Premium and Business Critical service tiers, applications could gain performance benefits using this
additional capacity at no extra cost.
The read scale-out feature is also available in the Hyperscale service tier when at least one secondary replica is
added. Hyperscale secondary named replicas provide independent scaling, access isolation, workload isolation,
massive read scale-out, and other benefits. Multiple secondary HA replicas can be used for load-balancing read-
only workloads that require more resources than available on one secondary HA replica.
The High Availability architecture of Basic, Standard, and General Purpose service tiers does not include any
replicas. The read scale-out feature is not available in these service tiers. However, geo-replicas can provide
similar functionality in these service tiers.
The following diagram illustrates the feature for Premium and Business Critical databases and managed
instances.
The read scale-out feature is enabled by default on new Premium, Business Critical, and Hyperscale databases.

NOTE
Read scale-out is always enabled in the Business Critical service tier of Managed Instance, and for Hyperscale databases
with at least one secondary replica.

If your SQL connection string is configured with ApplicationIntent=ReadOnly , the application will be redirected
to a read-only replica of that database or managed instance. For information on how to use the
ApplicationIntent property, see Specifying Application Intent.

If you wish to ensure that the application connects to the primary replica regardless of the ApplicationIntent
setting in the SQL connection string, you must explicitly disable read scale-out when creating the database or
when altering its configuration. For example, if you upgrade your database from Standard or General Purpose
tier to Premium or Business Critical and want to make sure all your connections continue to go to the primary
replica, disable read scale-out. For details on how to disable it, see Enable and disable read scale-out.

NOTE
Query Store and SQL Profiler features are not supported on read-only replicas.

Data consistency
Data changes made on the primary replica propagate to read-only replicas asynchronously. Within a session
connected to a read-only replica, reads are always transactionally consistent. However, because data
propagation latency is variable, different replicas can return data at slightly different points in time relative to
the primary and each other. If a read-only replica becomes unavailable and the session reconnects, it may
connect to a replica that is at a different point in time than the original replica. Likewise, if an application
changes data using a read-write session and immediately reads it using a read-only session, it is possible that
the latest changes are not immediately visible on the read-only replica.
Typical data propagation latency between the primary replica and read-only replicas varies in the range from
tens of milliseconds to single-digit seconds. However, there is no fixed upper bound on data propagation latency.
Conditions such as high resource utilization on the replica can increase latency substantially. Applications that
require guaranteed data consistency across sessions, or require committed data to be readable immediately
should use the primary replica.

NOTE
To monitor data propagation latency, see Monitoring and troubleshooting read-only replica.

Connect to a read-only replica

When you enable read scale-out for a database, the ApplicationIntent option in the connection string provided
by the client dictates whether the connection is routed to the write replica or to a read-only replica. Specifically, if
the ApplicationIntent value is ReadWrite (the default value), the connection will be directed to the read-write
replica. This is identical to the behavior when ApplicationIntent is not included in the connection string. If the
ApplicationIntent value is ReadOnly , the connection is routed to a read-only replica.

For example, the following connection string connects the client to a read-only replica (replacing the items in the
angle brackets with the correct values for your environment and dropping the angle brackets):

Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=
<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Either of the following connection strings connects the client to a read-write replica (replacing the items in the
angle brackets with the correct values for your environment and dropping the angle brackets):

Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;User ID=
<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

Server=tcp:<server>.database.windows.net;Database=<mydatabase>;User ID=<myLogin>;Password=
<myPassword>;Trusted_Connection=False; Encrypt=True;

Verify that a connection is to a read-only replica

You can verify whether you are connected to a read-only replica by running the following query in the context of
your database. It will return READ_ONLY when you are connected to a read-only replica.

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');

NOTE
In Premium and Business Critical service tiers, only one of the read-only replicas is accessible at any given time.
Hyperscale supports multiple read-only replicas.

Monitoring and troubleshooting read-only replicas

When connected to a read-only replica, Dynamic Management Views (DMVs) reflect the state of the replica, and
can be queried for monitoring and troubleshooting purposes. The database engine provides multiple views to
expose a wide variety of monitoring data.
The following views are commonly used for replica monitoring and troubleshooting:

NAME P URP O SE

sys.dm_db_resource_stats Provides resource utilization metrics for the last hour,

including CPU, data IO, and log write utilization relative to
service objective limits.

sys.dm_os_wait_stats Provides aggregate wait statistics for the database engine

instance.

sys.dm_database_replica_states Provides replica health state and synchronization statistics.

Redo queue size and redo rate serve as indicators of data
propagation latency on the read-only replica.

sys.dm_os_performance_counters Provides database engine performance counters.

sys.dm_exec_query_stats Provides per-query execution statistics such as number of

executions, CPU time used, etc.

sys.dm_exec_query_plan() Provides cached query plans.

sys.dm_exec_sql_text() Provides query text for a cached query plan.

sys.dm_exec_query_profiles Provides real time query progress while queries are in

execution.

sys.dm_exec_query_plan_stats() Provides the last known actual execution plan including

runtime statistics for a query.

sys.dm_io_virtual_file_stats() Provides storage IOPS, throughput, and latency statistics for

all database files.

NOTE
The sys.resource_stats and sys.elastic_pool_resource_stats DMVs in the logical master database return
resource utilization data of the primary replica.

Monitoring read-only replicas with Extended Events

An extended event session cannot be created when connected to a read-only replica. However, in Azure SQL
Database, the definitions of database-scoped Extended Event sessions created and altered on the primary replica
replicate to read-only replicas, including geo-replicas, and capture events on read-only replicas.
An extended event session on a read-only replica that is based on a session definition from the primary replica
can be started and stopped independently of the primary replica. When an extended event session is dropped
on the primary replica, it is also dropped on all read-only replicas.
Transaction isolation level on read-only replicas
Queries that run on read-only replicas are always mapped to the snapshot transaction isolation level. Snapshot
isolation uses row versioning to avoid blocking scenarios where readers block writers.
In rare cases, if a snapshot isolation transaction accesses object metadata that has been modified in another
concurrent transaction, it may receive error 3961, "Snapshot isolation transaction failed in database '%.*ls'
because the object accessed by the statement has been modified by a DDL statement in another concurrent
transaction since the start of this transaction. It is disallowed because the metadata is not versioned. A
concurrent update to metadata can lead to inconsistency if mixed with snapshot isolation."
Long-running queries on read-only replicas
Queries running on read-only replicas need to access metadata for the objects referenced in the query (tables,
indexes, statistics, etc.) In rare cases, if object metadata is modified on the primary replica while a query holds a
lock on the same object on the read-only replica, the query can block the process that applies changes from the
primary replica to the read-only replica. If such a query were to run for a long time, it would cause the read-only
replica to be significantly out of sync with the primary replica. For replicas that are potential failover targets
(secondary replicas in Premium and Business Critical service tiers, Hyperscale HA replicas, and all geo-replicas),
this would also delay database recovery if a failover were to occur, causing longer than expected downtime.
If a long-running query on a read-only replica directly or indirectly causes this kind of blocking, it may be
automatically terminated to avoid excessive data latency and potential database availability impact. The session
will receive error 1219, "Your session has been disconnected because of a high priority DDL operation", or error
3947, "The transaction was aborted because the secondary compute failed to catch up redo. Retry the
transaction."

NOTE
If you receive error 3961, 1219, or 3947 when running queries against a read-only replica, retry the query. Alternatively,
avoid operations that modify object metadata (schema changes, index maintenance, statistics updates, etc.) on the
primary replica while long-running queries execute on secondary replicas.

TIP
In Premium and Business Critical service tiers, when connected to a read-only replica, the redo_queue_size and
redo_rate columns in the sys.dm_database_replica_states DMV may be used to monitor data synchronization process,
serving as indicators of data propagation latency on the read-only replica.

Enable and disable read scale-out

Read scale-out is enabled by default on Premium, Business Critical, and Hyperscale service tiers. Read scale-out
cannot be enabled in Basic, Standard, or General Purpose service tiers. Read scale-out is automatically disabled
on Hyperscale databases configured with zero secondary replicas.
You can disable and re-enable read scale-out on single databases and elastic pool databases in the Premium or
Business Critical service tiers using the following methods.

NOTE
For single databases and elastic pool databases, the ability to disable read scale-out is provided for backward
compatibility. Read scale-out cannot be disabled on Business Critical managed instances.

Azure portal
You can manage the read scale-out setting on the Configure database blade.
PowerShell
 IMPORTANT
The PowerShell Azure Resource Manager module is still supported, but all future development is for the Az.Sql module.
The Azure Resource Manager module will continue to receive bug fixes until at least December 2020. The arguments for
the commands in the Az module and in the Azure Resource Manager modules are substantially identical. For more
information about their compatibility, see Introducing the new Azure PowerShell Az module.

Managing read scale-out in Azure PowerShell requires the December 2016 Azure PowerShell release or newer.
For the newest PowerShell release, see Azure PowerShell.
You can disable or re-enable read scale-out in Azure PowerShell by invoking the Set-AzSqlDatabase cmdlet and
passing in the desired value ( Enabled or Disabled ) for the -ReadScale parameter.
To disable read scale-out on an existing database (replacing the items in the angle brackets with the correct
values for your environment and dropping the angle brackets):

Set-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName

<databaseName> -ReadScale Disabled

To disable read scale-out on a new database (replacing the items in the angle brackets with the correct values for
your environment and dropping the angle brackets):

New-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName

<databaseName> -ReadScale Disabled -Edition Premium

To re-enable read scale-out on an existing database (replacing the items in the angle brackets with the correct
values for your environment and dropping the angle brackets):

Set-AzSqlDatabase -ResourceGroupName <resourceGroupName> -ServerName <serverName> -DatabaseName

<databaseName> -ReadScale Enabled

REST API
To create a database with read scale-out disabled, or to change the setting for an existing database, use the
following method with the readScale property set to Enabled or Disabled , as in the following sample request.

Method: PUT
URL:
https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{GroupName}/providers/Microsoft.S
ql/servers/{ServerName}/databases/{DatabaseName}?api-version= 2014-04-01-preview
Body: {
"properties": {
"readScale":"Disabled"
}
}

For more information, see Databases - Create or update.

Using the tempdb database on a read-only replica

The tempdbdatabase on the primary replica is not replicated to the read-only replicas. Each replica has its own
tempdb database that is created when the replica is created. This ensures that tempdb is updateable and can be
modified during your query execution. If your read-only workload depends on using tempdb objects, you
should create these objects as part of the same workload, while connected to a read-only replica.
Using read scale-out with geo-replicated databases
Geo-replicated secondary databases have the same High Availability architecture as primary databases. If you're
connecting to the geo-replicated secondary database with read scale-out enabled, your sessions with
ApplicationIntent=ReadOnly will be routed to one of the high availability replicas in the same way they are
routed on the primary writeable database. The sessions without ApplicationIntent=ReadOnly will be routed to
the primary replica of the geo-replicated secondary, which is also read-only.
In this fashion, creating a geo-replica can provide multiple additional read-only replicas for a read-write primary
database. Each additional geo-replica provides another set of read-only replicas. Geo-replicas can be created in
any Azure region, including the region of the primary database.

NOTE
There is no automatic round-robin or any other load-balanced routing between the replicas of a geo-replicated secondary
database, with the exception of a Hyperscale geo-replica with more than one HA replica. In that case, sessions with read-
only intent are distributed over all HA replicas of a geo-replica.

Feature support on read-only replicas

A list of the behavior of some features on read-only replicas is below:
Auditing on read-only replicas is automatically enabled. For further details about the hierarchy of the storage
folders, naming conventions, and log format, see SQL Database Audit Log Format.
Query Performance Insight relies on data from the Query Store, which currently does not track activity on the
read-only replica. Query Performance Insight will not show queries which execute on the read-only replica.
Automatic tuning relies on the Query Store, as detailed in the Automatic tuning paper. Automatic tuning only
works for workloads running on the primary replica.

Next steps
For information about SQL Database Hyperscale offering, see Hyperscale service tier.
 Distributed transactions across cloud databases
(preview)
12/6/2021 • 12 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

IMPORTANT
Distributed transactions for Azure SQL Managed Instance are now generally available. Elastic Database Transactions for
Azure SQL Database are in preview.

Elastic database transactions for Azure SQL Database (Preview) and Azure SQL Managed Instance allow you to
run transactions that span several databases. Elastic database transactions are available for .NET applications
using ADO.NET and integrate with the familiar programming experience using the System.Transaction classes. To
get the library, see .NET Framework 4.6.1 (Web Installer). Additionally, for managed instance distributed
transactions are available in Transact-SQL.
On premises, such a scenario usually requires running Microsoft Distributed Transaction Coordinator (MSDTC).
Since MSDTC isn't available for Platform-as-a-Service application in Azure, the ability to coordinate distributed
transactions has now been directly integrated into SQL Database or SQL Managed Instance. Applications can
connect to any database to launch distributed transactions, and one of the databases or servers will
transparently coordinate the distributed transaction, as shown in the following figure.
In this document terms "distributed transactions" and "elastic database transactions" are considered synonyms
and will be used interchangeably.

Common scenarios
Elastic database transactions enable applications to make atomic changes to data stored in several different
databases. Both SQL Database and SQL Managed Instance support client-side development experiences in C#
and .NET. A server-side experience (code written in stored procedures or server-side scripts) using Transact-SQL
is available for SQL Managed Instance only.

IMPORTANT
Running elastic database transactions between Azure SQL Database and Azure SQL Managed Instance is not supported.
Elastic database transaction can only span across a set of databases in SQL Database or a set databases across managed
instances.

Elastic database transactions target the following scenarios:

Multi-database applications in Azure: With this scenario, data is vertically partitioned across several
databases in SQL Database or SQL Managed Instance such that different kinds of data reside on different
databases. Some operations require changes to data, which is kept in two or more databases. The application
uses elastic database transactions to coordinate the changes across databases and ensure atomicity.
Sharded database applications in Azure: With this scenario, the data tier uses the Elastic Database client
library or self-sharding to horizontally partition the data across many databases in SQL Database or SQL
Managed Instance. One prominent use case is the need to perform atomic changes for a sharded multi-
tenant application when changes span tenants. Think for instance of a transfer from one tenant to another,
both residing on different databases. A second case is fine-grained sharding to accommodate capacity needs
for a large tenant, which in turn typically implies that some atomic operations need to stretch across several
databases used for the same tenant. A third case is atomic updates to reference data that are replicated
across databases. Atomic, transacted, operations along these lines can now be coordinated across several
databases. Elastic database transactions use two phase commit to ensure transaction atomicity across
databases. It's a good fit for transactions that involve fewer than 100 databases at a time within a single
transaction. These limits aren't enforced, but one should expect performance and success rates for elastic
database transactions to suffer when exceeding these limits.

Installation and migration

The capabilities for elastic database transactions are provided through updates to the .NET libraries
System.Data.dll and System.Transactions.dll. The DLLs ensure that two-phase commit is used where necessary to
ensure atomicity. To start developing applications using elastic database transactions, install .NET Framework
4.6.1 or a later version. When running on an earlier version of the .NET framework, transactions will fail to
promote to a distributed transaction and an exception will be raised.
After installation, you can use the distributed transaction APIs in System.Transactions with connections to SQL
Database and SQL Managed Instance. If you have existing MSDTC applications using these APIs, rebuild your
existing applications for .NET 4.6 after installing the 4.6.1 Framework. If your projects target .NET 4.6, they'll
automatically use the updated DLLs from the new Framework version and distributed transaction API calls in
combination with connections to SQL Database or SQL Managed Instance will now succeed.
Remember that elastic database transactions don't require installing MSDTC. Instead, elastic database
transactions are directly managed by and within the service. This significantly simplifies cloud scenarios since a
deployment of MSDTC isn't necessary to use distributed transactions with SQL Database or SQL Managed
Instance. Section 4 explains in more detail how to deploy elastic database transactions and the required .NET
framework together with your cloud applications to Azure.

.NET installation for Azure Cloud Services

Azure provides several offerings to host .NET applications. A comparison of the different offerings is available in
Azure App Service, Cloud Services, and Virtual Machines comparison. If the guest OS of the offering is smaller
than .NET 4.6.1 required for elastic transactions, you need to upgrade the guest OS to 4.6.1.
For Azure App Service, upgrades to the guest OS are currently not supported. For Azure Virtual Machines,
simply log into the VM and run the installer for the latest .NET framework. For Azure Cloud Services, you need
to include the installation of a newer .NET version into the startup tasks of your deployment. The concepts and
steps are documented in Install .NET on a Cloud Service Role.
Note that the installer for .NET 4.6.1 may require more temporary storage during the bootstrapping process on
Azure cloud services than the installer for .NET 4.6. To ensure a successful installation, you need to increase
temporary storage for your Azure cloud service in your ServiceDefinition.csdef file in the LocalResources section
and the environment settings of your startup task, as shown in the following sample:

<LocalResources>
...
<LocalStorage name="TEMP" sizeInMB="5000" cleanOnRoleRecycle="false" />
<LocalStorage name="TMP" sizeInMB="5000" cleanOnRoleRecycle="false" />
</LocalResources>
<Startup>
<Task commandLine="install.cmd" executionContext="elevated" taskType="simple">
<Environment>
...
<Variable name="TEMP">
<RoleInstanceValue
xpath="/RoleEnvironment/CurrentInstance/LocalResources/LocalResource[@name='TEMP']/@path" />
</Variable>
<Variable name="TMP">
<RoleInstanceValue
xpath="/RoleEnvironment/CurrentInstance/LocalResources/LocalResource[@name='TMP']/@path" />
</Variable>
</Environment>
</Task>
</Startup>

.NET development experience

Multi-database applications
The following sample code uses the familiar programming experience with .NET System.Transactions. The
TransactionScope class establishes an ambient transaction in .NET. (An "ambient transaction" is one that lives in
the current thread.) All connections opened within the TransactionScope participate in the transaction. If
different databases participate, the transaction is automatically elevated to a distributed transaction. The
outcome of the transaction is controlled by setting the scope to complete to indicate a commit.

using (var scope = new TransactionScope())

{
using (var conn1 = new SqlConnection(connStrDb1))
{
conn1.Open();
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = new SqlConnection(connStrDb2))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into T2 values(2)");
cmd2.ExecuteNonQuery();
}
scope.Complete();
}

Sharded database applications

Elastic database transactions for SQL Database and SQL Managed Instance also support coordinating
distributed transactions where you use the OpenConnectionForKey method of the elastic database client library
to open connections for a scaled out data tier. Consider cases where you need to guarantee transactional
consistency for changes across several different sharding key values. Connections to the shards hosting the
different sharding key values are brokered using OpenConnectionForKey. In the general case, the connections
can be to different shards such that ensuring transactional guarantees requires a distributed transaction. The
following code sample illustrates this approach. It assumes that a variable called shardmap is used to represent
a shard map from the elastic database client library:

using (var scope = new TransactionScope())

{
using (var conn1 = shardmap.OpenConnectionForKey(tenantId1, credentialsStr))
{
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = shardmap.OpenConnectionForKey(tenantId2, credentialsStr))
{
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into T1 values(2)");
cmd2.ExecuteNonQuery();
}
scope.Complete();
}

Transact-SQL development experience

A server-side distributed transactions using Transact-SQL are available only for Azure SQL Managed Instance.
Distributed transaction can be executed only between Managed Instances that belong to the same Server trust
group. In this scenario, Managed Instances need to use linked server to reference each other.
The following sample Transact-SQL code uses BEGIN DISTRIBUTED TRANSACTION to start distributed
transaction.
 -- Configure the Linked Server
-- Add one Azure SQL Managed Instance as Linked Server
EXEC sp_addlinkedserver
@server='RemoteServer', -- Linked server name
@srvproduct='',
@provider='sqlncli', -- SQL Server Native Client
@datasrc='managed-instance-server.46e7afd5bc81.database.windows.net' -- SQL Managed Instance
endpoint

-- Add credentials and options to this Linked Server

EXEC sp_addlinkedsrvlogin
@rmtsrvname = 'RemoteServer', -- Linked server name
@useself = 'false',
@rmtuser = '<login_name>', -- login
@rmtpassword = '<secure_password>' -- password

USE AdventureWorks2012;
GO
SET XACT_ABORT ON;
GO
BEGIN DISTRIBUTED TRANSACTION;
-- Delete candidate from local instance.
DELETE AdventureWorks2012.HumanResources.JobCandidate
WHERE JobCandidateID = 13;
-- Delete candidate from remote instance.
DELETE RemoteServer.AdventureWorks2012.HumanResources.JobCandidate
WHERE JobCandidateID = 13;
COMMIT TRANSACTION;
GO

Combining .NET and Transact-SQL development experience

.NET applications that use System.Transaction classes can combine TransactionScope class with Transact-SQL
statement BEGIN DISTRIBUTED TRANSACTION. Within TransactionScope, inner transaction that executes BEGIN
DISTRIBUTED TRANSACTION will explicitly be promoted to distributed transaction. Also, when second
SqlConnecton is opened within the TransactionScope it will be implicitly promoted to distributed transaction.
Once distributed transaction is started, all subsequent transactions requests, whether they are coming from .NET
or Transact-SQL, will join the parent distributed transaction. As consequence all nested transaction scopes
initiated by BEGIN statement will end up in same transaction and COMMIT/ROLLBACK statements will have
following effect on overall outcome:
COMMIT statement will not have any effect on transaction scope initiated by BEGIN statement, that is, no
results will be committed before Complete() method is invoked on TransactionScope object. If
TransactionScope object is destroyed before being completed, all changes done within the scope are rolled
back.
ROLLBACK statement will cause entire TransactionScope to roll back. Any attempts to enlist new transactions
within TransactionScope will fail afterwards, as well as attempt to invoke Complete() on TransactionScope
object.
Here is an example where transaction is explicitly promoted to distributed transaction with Transact-SQL.
 using (TransactionScope s = new TransactionScope())
{
using (SqlConnection conn = new SqlConnection(DB0_ConnectionString)
{
conn.Open();

// Transaction is here promoted to distributed by BEGIN statement

//
Helper.ExecuteNonQueryOnOpenConnection(conn, "BEGIN DISTRIBUTED TRAN");
// ...
}

using (SqlConnection conn2 = new SqlConnection(DB1_ConnectionString)

{
conn2.Open();
// ...
}

s.Complete();
}

Following example shows a transaction that is implicitly promoted to distributed transaction once the second
SqlConnecton was started within the TransactionScope.

using (TransactionScope s = new TransactionScope())

{
using (SqlConnection conn = new SqlConnection(DB0_ConnectionString)
{
conn.Open();
// ...
}

using (SqlConnection conn = new SqlConnection(DB1_ConnectionString)

{
// Because this is second SqlConnection within TransactionScope transaction is here implicitly
promoted distributed.
//
conn.Open();
Helper.ExecuteNonQueryOnOpenConnection(conn, "BEGIN DISTRIBUTED TRAN");
Helper.ExecuteNonQueryOnOpenConnection(conn, lsQuery);
// ...
}

s.Complete();
}

Transactions for SQL Database

IMPORTANT
Distributed transactions for Azure SQL Database are in preview.

Elastic database transactions are supported across different servers in Azure SQL Database. When transactions
cross server boundaries, the participating servers first need to be entered into a mutual communication
relationship. Once the communication relationship has been established, any database in any of the two servers
can participate in elastic transactions with databases from the other server. With transactions spanning more
than two servers, a communication relationship needs to be in place for any pair of servers.
Use the following PowerShell cmdlets to manage cross-server communication relationships for elastic database
transactions:
 New-AzSqlSer verCommunicationLink : Use this cmdlet to create a new communication relationship
between two servers in Azure SQL Database. The relationship is symmetric, which means both servers can
initiate transactions with the other server.
Get-AzSqlSer verCommunicationLink : Use this cmdlet to retrieve existing communication relationships
and their properties.
Remove-AzSqlSer verCommunicationLink : Use this cmdlet to remove an existing communication
relationship.

Transactions for SQL Managed Instance

IMPORTANT
Distributed transactions for Azure SQL Managed Instance are now generally available.

Distributed transactions are supported across databases within multiple instances. When transactions cross
managed instance boundaries, the participating instances need to be in a mutual security and communication
relationship. This is done by creating a Server Trust Group, which can be done by using the Azure portal or
Azure PowerShell or the Azure CLI. If instances are not on the same Virtual network then you must configure
Virtual network peering and Network security group inbound and outbound rules need to allow ports 5024 and
11000-12000 on all participating Virtual networks.

The following diagram shows a Server Trust Group with managed instances that can execute distributed
transactions with .NET or Transact-SQL:
Monitoring transaction status
Use Dynamic Management Views (DMVs) to monitor status and progress of your ongoing elastic database
transactions. All DMVs related to transactions are relevant for distributed transactions in SQL Database and SQL
Managed Instance. You can find the corresponding list of DMVs here: Transaction Related Dynamic Management
Views and Functions (Transact-SQL).
These DMVs are particularly useful:
sys.dm_tran_active_transactions : Lists currently active transactions and their status. The UOW (Unit Of
Work) column can identify the different child transactions that belong to the same distributed transaction. All
transactions within the same distributed transaction carry the same UOW value. For more information, see
the DMV documentation.
sys.dm_tran_database_transactions : Provides additional information about transactions, such as
placement of the transaction in the log. For more information, see the DMV documentation.
sys.dm_tran_locks : Provides information about the locks that are currently held by ongoing transactions.
For more information, see the DMV documentation.

Limitations
The following limitations currently apply to elastic database transactions in SQL Database:
Only transactions across databases in SQL Database are supported. Other X/Open XA resource providers and
databases outside of SQL Database can't participate in elastic database transactions. That means that elastic
database transactions can't stretch across on premises SQL Server and Azure SQL Database. For distributed
transactions on premises, continue to use MSDTC.
Only client-coordinated transactions from a .NET application are supported. Server-side support for T-SQL
such as BEGIN DISTRIBUTED TRANSACTION is planned, but not yet available.
 Transactions across WCF services aren't supported. For example, you have a WCF service method that
executes a transaction. Enclosing the call within a transaction scope will fail as a
System.ServiceModel.ProtocolException.
The following limitations currently apply to distributed transactions in SQL Managed Instance:
Only transactions across databases in managed instances are supported. Other X/Open XA resource
providers and databases outside of Azure SQL Managed Instance can't participate in distributed transactions.
That means that distributed transactions can't stretch across on-premises SQL Server and Azure SQL
Managed Instance. For distributed transactions on premises, continue to use MSDTC.
Transactions across WCF services aren't supported. For example, you have a WCF service method that
executes a transaction. Enclosing the call within a transaction scope will fail as a
System.ServiceModel.ProtocolException.
Azure SQL Managed Instance must be part of a Server trust group in order to participate in distributed
transaction.
Limitations of Server trust groups affect distributed transactions.
Managed Instances that participate in distributed transactions need to have connectivity over private
endpoints (using private IP address from the virtual network where they are deployed) and need to be
mutually referenced using private FQDNs. Client applications can use distributed transactions on private
endpoints. Additionally, in cases when Transact-SQL leverages linked servers referencing private endpoints,
client applications can use distributed transactions on public endpoints as well. This limitation is explained on
the following diagram.

Next steps
For questions, reach out to us on the Microsoft Q&A question page for SQL Database.
For feature requests, add them to the SQL Database feedback forum or SQL Managed Instance forum.
 An overview of Azure SQL Database and SQL
Managed Instance security capabilities
12/6/2021 • 9 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
This article outlines the basics of securing the data tier of an application using Azure SQL Database, Azure SQL
Managed Instance, and Azure Synapse Analytics. The security strategy described follows the layered defense-in-
depth approach as shown in the picture below, and moves from the outside in:

Network security
Microsoft Azure SQL Database, SQL Managed Instance, and Azure Synapse Analytics provide a relational
database service for cloud and enterprise applications. To help protect customer data, firewalls prevent network
access to the server until access is explicitly granted based on IP address or Azure Virtual network traffic origin.
IP firewall rules
IP firewall rules grant access to databases based on the originating IP address of each request. For more
information, see Overview of Azure SQL Database and Azure Synapse Analytics firewall rules.
Virtual network firewall rules
Virtual network service endpoints extend your virtual network connectivity over the Azure backbone and enable
Azure SQL Database to identify the virtual network subnet that traffic originates from. To allow traffic to reach
Azure SQL Database, use the SQL service tags to allow outbound traffic through Network Security Groups.
Virtual network rules enable Azure SQL Database to only accept communications that are sent from selected
subnets inside a virtual network.
 NOTE
Controlling access with firewall rules does not apply to SQL Managed Instance . For more information about the
networking configuration needed, see Connecting to a managed instance

Access management
IMPORTANT
Managing databases and servers within Azure is controlled by your portal user account's role assignments. For more
information on this article, see Azure role-based access control in the Azure portal.

Authentication
Authentication is the process of proving the user is who they claim to be. Azure SQL Database and SQL
Managed Instance support two types of authentication:
SQL authentication :
SQL authentication refers to the authentication of a user when connecting to Azure SQL Database or
Azure SQL Managed Instance using username and password. A ser ver admin login with a username
and password must be specified when the server is being created. Using these credentials, a ser ver
admin can authenticate to any database on that server or instance as the database owner. After that,
additional SQL logins and users can be created by the server admin, which enable users to connect using
username and password.
Azure Active Director y authentication :
Azure Active Directory authentication is a mechanism of connecting to Azure SQL Database, Azure SQL
Managed Instance and Azure Synapse Analytics by using identities in Azure Active Directory (Azure AD).
Azure AD authentication allows administrators to centrally manage the identities and permissions of
database users along with other Azure services in one central location. This includes the minimization of
password storage and enables centralized password rotation policies.
A server admin called the Active Director y administrator must be created to use Azure AD
authentication with SQL Database. For more information, see Connecting to SQL Database By Using
Azure Active Directory Authentication. Azure AD authentication supports both managed and federated
accounts. The federated accounts support Windows users and groups for a customer domain federated
with Azure AD.
Additional Azure AD authentication options available are Active Directory Universal Authentication for
SQL Server Management Studio connections including Multi-Factor Authentication and Conditional
Access.

IMPORTANT
Managing databases and servers within Azure is controlled by your portal user account's role assignments. For more
information on this article, see Azure role-based access control in Azure portal. Controlling access with firewall rules does
not apply to SQL Managed Instance. Please see the following article on connecting to a managed instance for more
information about the networking configuration needed.

Authorization
Authorization refers to controlling access on resources and commands within a database. This is done by
assigning permissions to a user within a database in Azure SQL Database or Azure SQL Managed Instance.
Permissions are ideally managed by adding user accounts to database roles and assigning database-level
permissions to those roles. Alternatively an individual user can also be granted certain object-level permissions.
For more information, see Logins and users
As a best practice, create custom roles when needed. Add users to the role with the least privileges required to
do their job function. Do not assign permissions directly to users. The server admin account is a member of the
built-in db_owner role, which has extensive permissions and should only be granted to few users with
administrative duties. To further limit the scope of what a user can do, the EXECUTE AS can be used to specify
the execution context of the called module. Following these best practices is also a fundamental step towards
Separation of Duties.
Row-level security
Row-Level Security enables customers to control access to rows in a database table based on the characteristics
of the user executing a query (for example, group membership or execution context). Row-Level Security can
also be used to implement custom Label-based security concepts. For more information, see Row-Level security.

Threat protection
SQL Database and SQL Managed Instance secure customer data by providing auditing and threat detection
capabilities.
SQL auditing in Azure Monitor logs and Event Hubs
SQL Database and SQL Managed Instance auditing tracks database activities and helps maintain compliance
with security standards by recording database events to an audit log in a customer-owned Azure storage
account. Auditing allows users to monitor ongoing database activities, as well as analyze and investigate
historical activity to identify potential threats or suspected abuse and security violations. For more information,
see Get started with SQL Database Auditing.
Advanced Threat Protection
Advanced Threat Protection is analyzing your logs to detect unusual behavior and potentially harmful attempts
to access or exploit databases. Alerts are created for suspicious activities such as SQL injection, potential data
infiltration, and brute force attacks or for anomalies in access patterns to catch privilege escalations and
breached credentials use. Alerts are viewed from the Microsoft Defender for Cloud, where the details of the
suspicious activities are provided and recommendations for further investigation given along with actions to
mitigate the threat. Advanced Threat Protection can be enabled per server for an additional fee. For more
information, see Get started with SQL Database Advanced Threat Protection.
Information protection and encryption
Transport Layer Security (Encryption-in-transit)
SQL Database, SQL Managed Instance, and Azure Synapse Analytics secure customer data by encrypting data in
motion with Transport Layer Security (TLS).
SQL Database, SQL Managed Instance, and Azure Synapse Analytics enforce encryption (SSL/TLS) at all times
for all connections. This ensures all data is encrypted "in transit" between the client and server irrespective of
the setting of Encr ypt or TrustSer verCer tificate in the connection string.
As a best practice, recommend that in the connection string used by the application, you specify an encrypted
connection and not trust the server certificate. This forces your application to verify the server certificate and
thus prevents your application from being vulnerable to man in the middle type attacks.
For example when using the ADO.NET driver this is accomplished via Encr ypt=True and
TrustSer verCer tificate=False . If you obtain your connection string from the Azure portal, it will have the
correct settings.

IMPORTANT
Note that some non-Microsoft drivers may not use TLS by default or rely on an older version of TLS (<1.2) in order to
function. In this case the server still allows you to connect to your database. However, we recommend that you evaluate
the security risks of allowing such drivers and application to connect to SQL Database, especially if you store sensitive
data.
For further information about TLS and connectivity, see TLS considerations

Transparent Data Encryption (Encryption-at-rest)

Transparent data encryption (TDE) for SQL Database, SQL Managed Instance, and Azure Synapse Analytics adds
a layer of security to help protect data at rest from unauthorized or offline access to raw files or backups.
Common scenarios include data center theft or unsecured disposal of hardware or media such as disk drives
and backup tapes.TDE encrypts the entire database using an AES encryption algorithm, which doesn't require
application developers to make any changes to existing applications.
In Azure, all newly created databases are encrypted by default and the database encryption key is protected by a
built-in server certificate. Certificate maintenance and rotation are managed by the service and require no input
from the user. Customers who prefer to take control of the encryption keys can manage the keys in Azure Key
Vault.
Key management with Azure Key Vault
Bring Your Own Key (BYOK) support forTransparent Data Encryption (TDE)allows customers to take ownership
of key management and rotation usingAzure Key Vault, Azure's cloud-based external key management system. If
the database's access to the key vault is revoked, a database cannot be decrypted and read into memory. Azure
Key Vault provides a central key management platform, leverages tightly monitored hardware security modules
(HSMs), and enables separation of duties between management of keys and data to help meet security
compliance requirements.
Always Encrypted (Encryption-in-use )

Always Encrypted is a feature designed to protect sensitive data stored in specific database columns from access
(for example, credit card numbers, national identification numbers, or data on a need to know basis). This
includes database administrators or other privileged users who are authorized to access the database to
perform management tasks, but have no business need to access the particular data in the encrypted columns.
The data is always encrypted, which means the encrypted data is decrypted only for processing by client
applications with access to the encryption key. The encryption key is never exposed to SQL Database or SQL
Managed Instance and can be stored either in the Windows Certificate Store or in Azure Key Vault.
Dynamic data masking

Dynamic data masking limits sensitive data exposure by masking it to non-privileged users. Dynamic data
masking automatically discovers potentially sensitive data in Azure SQL Database and SQL Managed Instance
and provides actionable recommendations to mask these fields, with minimal impact to the application layer. It
works by obfuscating the sensitive data in the result set of a query over designated database fields, while the
data in the database is not changed. For more information, see Get started with SQL Database and SQL
Managed Instance dynamic data masking.

Security management
Vulnerability assessment
Vulnerability assessment is an easy to configure service that can discover, track, and help remediate potential
database vulnerabilities with the goal to proactively improve overall database security. Vulnerability assessment
(VA) is part of the Microsoft Defender for SQL offering, which is a unified package for advanced SQL security
capabilities. Vulnerability assessment can be accessed and managed via the central Microsoft Defender for SQL
portal.
Data discovery and classification
Data discovery and classification (currently in preview) provides basic capabilities built into Azure SQL Database
and SQL Managed Instance for discovering, classifying and labeling the sensitive data in your databases.
Discovering and classifying your utmost sensitive data (business/financial, healthcare, personal data, etc.) can
play a pivotal role in your organizational Information protection stature. It can serve as infrastructure for:
Various security scenarios, such as monitoring (auditing) and alerting on anomalous access to sensitive data.
Controlling access to, and hardening the security of, databases containing highly sensitive data.
Helping meet data privacy standards and regulatory compliance requirements.
For more information, see Get started with data discovery and classification.
Compliance
In addition to the above features and functionality that can help your application meet various security
requirements, Azure SQL Database also participates in regular audits, and has been certified against a number
of compliance standards. For more information, see the Microsoft Azure Trust Center where you can find the
most current list of SQL Database compliance certifications.

Next steps
For a discussion of the use of logins, user accounts, database roles, and permissions in SQL Database and
SQL Managed Instance, see Manage logins and user accounts.
For a discussion of database auditing, see auditing.
For a discussion of threat detection, see threat detection.
 Playbook for addressing common security
requirements with Azure SQL Database and Azure
SQL Managed Instance
12/6/2021 • 39 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

This article provides best practices on how to solve common security requirements. Not all requirements are
applicable to all environments, and you should consult your database and security team on which features to
implement.

Solving common security requirements

This document provides guidance on how to solve common security requirements for new or existing
applications using Azure SQL Database and Azure SQL Managed Instance. It's organized by high-level security
areas. For addressing specific threats, refer to the Common security threats and potential mitigations section.
Although some of the presented recommendations are applicable when migrating applications from on-
premises to Azure, migration scenarios are not the focus of this document.
Azure SQL Database deployment offers covered in this guide
Azure SQL Database: single databases and elastic pools in servers
Azure SQL Managed Instance
Deployment offers not covered in this guide
Azure Synapse Analytics
Azure SQL VMs (IaaS)
SQL Server
Audience
The intended audiences for this guide are customers facing questions on how to secure Azure SQL Database.
The roles interested in this best practice article include, but not limited to:
Security Architects
Security Managers
Compliance Officers
Privacy Officers
Security Engineers
Using this guide
This document is intended as a companion to our existing Azure SQL Database security documentation.
Unless otherwise stated, we recommend you follow all best practices listed in each section to achieve the
respective goal or requirement. To meet specific security compliance standards or best practices, important
regulatory compliance controls are listed under the Requirements or Goals section wherever applicable. These
are the security standards and regulations that are referenced in this paper:
FedRAMP: AC-04, AC-06
SOC: CM-3, SDL-3
ISO/IEC 27001: Access Control, Cryptography
 Microsoft Operational Security Assurance (OSA) practices: Practice #1-6 and #9
NIST Special Publication 800-53 Security Controls: AC-5, AC-6
PCI DSS: 6.3.2, 6.4.2
We plan on continuing to update the recommendations and best practices listed here. Provide input or any
corrections for this document using the Feedback link at the bottom of this article.

Authentication
Authentication is the process of proving the user is who they claim to be. Azure SQL Database and SQL
Managed Instance support two types of authentication:
SQL authentication
Azure Active Directory authentication

NOTE
Azure Active Directory authentication may not be supported for all tools and 3rd party applications.

Central management for identities

Central identity management offers the following benefits:
Manage group accounts and control user permissions without duplicating logins across servers, databases
and managed instances.
Simplified and flexible permission management.
Management of applications at scale.
How to implement :
Use Azure Active Directory (Azure AD) authentication for centralized identity management.
Best practices :
Create an Azure AD tenant and create users to represent human users and create service principals to
represent apps, services, and automation tools. Service principals are equivalent to service accounts in
Windows and Linux.
Assign access rights to resources to Azure AD principals via group assignment: Create Azure AD groups,
grant access to groups, and add individual members to the groups. In your database, create contained
database users that map your Azure AD groups. To assign permissions inside the database, put the users
that are associated with your Azure AD groups in database roles with the appropriate permissions.
See the articles, Configure and manage Azure Active Directory authentication with SQL and Use Azure
AD for authentication with SQL.

NOTE
In SQL Managed Instance, you can also create logins that map to Azure AD principals in the master database. See
CREATE LOGIN (Transact-SQL).

Using Azure AD groups simplifies permission management and both the group owner, and the resource
owner can add/remove members to/from the group.
Create a separate group for Azure AD administrators for each server or managed instance.
See the article, Provision an Azure Active Directory administrator for your server.
 Monitor Azure AD group membership changes using Azure AD audit activity reports.
For a managed instance, a separate step is required to create an Azure AD admin.
See the article, Provision an Azure Active Directory administrator for your managed instance.

NOTE
Azure AD authentication is recorded in Azure SQL audit logs, but not in Azure AD sign-in logs.
Azure RBAC permissions granted in Azure do not apply to Azure SQL Database or SQL Managed Instance permissions.
Such permissions must be created/mapped manually using existing SQL permissions.
On the client-side, Azure AD authentication needs access to the internet or via User Defined Route (UDR) to a virtual
network.
The Azure AD access token is cached on the client side and its lifetime depends on token configuration. See the article,
Configurable token lifetimes in Azure Active Directory
For guidance on troubleshooting Azure AD Authentication issues, see the following blog: Troubleshooting Azure AD.

Azure AD Multi-Factor Authentication

Mentioned in: OSA Practice #2, ISO Access Control (AC)

Azure AD Multi-Factor Authentication helps provides additional security by requiring more than one form of
authentication.
How to implement :
Enable Multi-Factor Authentication in Azure AD using Conditional Access and use interactive
authentication.
The alternative is to enable Multi-Factor Authentication for the entire Azure AD or AD domain.
Best practices :
Activate Conditional Access in Azure AD (requires Premium subscription).
See the article, Conditional Access in Azure AD.
Create Azure AD group(s) and enable Multi-Factor Authentication policy for selected groups using Azure
AD Conditional Access.
See the article, Plan Conditional Access Deployment.
Multi-Factor Authentication can be enabled for the entire Azure AD or for the whole Active Directory
federated with Azure AD.
Use Azure AD Interactive authentication mode for Azure SQL Database and Azure SQL Managed Instance
where a password is requested interactively, followed by Multi-Factor Authentication:
Use Universal Authentication in SSMS. See the article, Using Multi-factor Azure AD authentication with
Azure SQL Database, SQL Managed Instance, Azure Synapse (SSMS support for Multi-Factor
Authentication).
Use Interactive Authentication supported in SQL Server Data Tools (SSDT). See the article, Azure Active
Directory support in SQL Server Data Tools (SSDT).
Use other SQL tools supporting Multi-Factor Authentication.
SSMS Wizard support for export/extract/deploy database
sqlpackage.exe: option '/ua'
sqlcmd Utility: option -G (interactive)
bcp Utility: option -G (interactive)
 Implement your applications to connect to Azure SQL Database or Azure SQL Managed Instance using
interactive authentication with Multi-Factor Authentication support.
See the article, Connect to Azure SQL Database with Azure AD Multi-Factor Authentication.

NOTE
This authentication mode requires user-based identities. In cases where a trusted identity model is used that is
bypassing individual Azure AD user authentication (e.g. using managed identity for Azure resources), Multi-Factor
Authentication does not apply.

Minimize the use of password-based authentication for users

Mentioned in: OSA Practice #4, ISO Access Control (AC)

Password-based authentication methods are a weaker form of authentication. Credentials can be compromised
or mistakenly given away.
How to implement :
Use an Azure AD integrated authentication that eliminates the use of passwords.
Best practices :
Use single sign-on authentication using Windows credentials. Federate the on-premises AD domain with
Azure AD and use integrated Windows authentication (for domain-joined machines with Azure AD).
See the article, SSMS support for Azure AD Integrated authentication.
Minimize the use of password-based authentication for applications
Mentioned in: OSA Practice #4, ISO Access Control (AC)

How to implement :
Enable Azure Managed Identity. You can also use integrated or certificate-based authentication.
Best practices :
Use managed identities for Azure resources.
System-assigned managed identity
User-assigned managed identity
Use Azure SQL Database from Azure App Service with managed identity (without code changes)
Use cert-based authentication for an application.
See this code sample.
Use Azure AD authentication for integrated federated domain and domain-joined machine (see section
above).
See the sample application for integrated authentication.
Protect passwords and secrets
For cases when passwords aren't avoidable, make sure they're secured.
How to implement :
Use Azure Key Vault to store passwords and secrets. Whenever applicable, use Multi-Factor Authentication
for Azure SQL Database with Azure AD users.
Best practices :
If avoiding passwords or secrets aren't possible, store user passwords and application secrets in Azure
Key Vault and manage access through Key Vault access policies.
Various app development frameworks may also offer framework-specific mechanisms for protecting
secrets in the app. For example: ASP.NET core app.
Use SQL authentication for legacy applications
SQL authentication refers to the authentication of a user when connecting to Azure SQL Database or SQL
Managed Instance using username and password. A login will need to be created in each server or managed
instance, and a user created in each database.
How to implement :
Use SQL authentication.
Best practices :
As a server or instance admin, create logins and users. Unless using contained database users with
passwords, all passwords are stored in master database.
See the article, Controlling and granting database access to SQL Database, SQL Managed Instance and
Azure Synapse Analytics.

Access management
Access management (also called Authorization) is the process of controlling and managing authorized users'
access and privileges to Azure SQL Database or SQL Managed Instance.
Implement principle of least privilege
Mentioned in: FedRamp controls AC-06, NIST: AC-6, OSA Practice #3

The principle of least privilege states that users shouldn't have more privileges than needed to complete their
tasks. For more information, see the article Just enough administration.
How to implement :
Assign only the necessary permissions to complete the required tasks:
In SQL Databases:
Use granular permissions and user-defined database roles (or server-roles in Managed Instance):
1. Create the required roles
CREATE ROLE
CREATE SERVER ROLE
2. Create required users
CREATE USER
3. Add users as members to roles
ALTER ROLE
ALTER SERVER ROLE
4. Then assign permissions to roles.
GRANT
Make sure to not assign users to unnecessary roles.
In Azure Resource Manager:
 Use built-in roles if available or Azure custom roles and assign the necessary permissions.
Azure built-in roles
Azure custom roles
Best practices :
The following best practices are optional but will result in better manageability and supportability of your
security strategy:
If possible, start with the least possible set of permissions and start adding permissions one by one if
there's a real necessity (and justification) – as opposed to the opposite approach: taking permissions away
step by step.
Refrain from assigning permissions to individual users. Use roles (database or server roles) consistently
instead. Roles helps greatly with reporting and troubleshooting permissions. (Azure RBAC only supports
permission assignment via roles.)
Create and use custom roles with the exact permissions needed. Typical roles that are used in practice:
Security deployment
Administrator
Developer
Support personnel
Auditor
Automated processes
End user
Use built-in roles only when the permissions of the roles match exactly the needed permissions for the
user. You can assign users to multiple roles.
Remember that permissions in the database engine can be applied within the following scopes (the
smaller the scope, the smaller the impact of the granted permissions):
Server (special roles in master database) in Azure
Database
Schema
It is a best practice to use schemas to grant permissions inside a database. (also see: Schema-
design: Recommendations for Schema design with security in mind)
Object (table, view, procedure, etc.)

NOTE
It is not recommended to apply permissions on the object level because this level adds unnecessary complexity to
the overall implementation. If you decide to use object-level permissions, those should be clearly documented. The
same applies to column-level-permissions, which are even less recommendable for the same reasons. Also be
aware that by default a table-level DENY does not override a column-level GRANT. This would require the
common criteria compliance Server Configuration to be activated.

Perform regular checks using Vulnerability Assessment (VA) to test for too many permissions.
Implement Separation of Duties
Mentioned in: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

Separation of Duties, also called Segregation of Duties describes the requirement to split sensitive tasks into
multiple tasks that are assigned to different users. Separation of Duties helps prevent data breaches.
How to implement :
Identify the required level of Separation of Duties. Examples:
Between Development/Test and Production environments
Security-wise sensitive tasks vs Database Administrator (DBA) management level tasks vs developer
tasks.
Examples: Auditor, creation of security policy for Role-level Security (RLS), Implementing SQL
Database objects with DDL-permissions.
Identify a comprehensive hierarchy of users (and automated processes) that access the system.
Create roles according to the needed user-groups and assign permissions to roles.
For management-level tasks in Azure portal or via PowerShell-automation use Azure roles. Either find
a built-in role matching the requirement, or create an Azure custom role using the available
permissions
Create Server roles for server-wide tasks (creating new logins, databases) in a managed instance.
Create Database Roles for database-level tasks.
For certain sensitive tasks, consider creating special stored procedures signed by a certificate to execute
the tasks on behalf of the users. One important advantage of digitally signed stored procedures is that if
the procedure is changed, the permissions that were granted to the previous version of the procedure are
immediately removed.
Example: Tutorial: Signing Stored Procedures with a Certificate
Implement Transparent Data Encryption (TDE) with customer-managed keys in Azure Key Vault to enable
Separation of Duties between data owner and security owner.
See the article, Configure customer-managed keys for Azure Storage encryption from the Azure
portal.
To ensure that a DBA can't see data that is considered highly sensitive and can still do DBA tasks, you can
use Always Encrypted with role separation.
See the articles, Overview of Key Management for Always Encrypted, Key Provisioning with Role
Separation, and Column Master Key Rotation with Role Separation.
In cases where the use of Always Encrypted isn't feasible, or at least not without major costs and efforts
that may even render the system near unusable, compromises can be made and mitigated through the
use of compensating controls such as:
Human intervention in processes.
Audit trails – for more information on Auditing, see, Audit critical security events.
Best practices :
Make sure that different accounts are used for Development/Test and Production environments. Different
accounts help to comply with separation of Test and Production systems.
Refrain from assigning permissions to individual users. Use roles (database or server roles) consistently
instead. Having roles helps greatly with reporting and troubleshooting permissions.
Use built-in roles when the permissions match exactly the needed permissions – if the union of all
permissions from multiple built-in roles leads to a 100% match, you can assign multiple roles
concurrently as well.
Create and use user-defined roles when built-in roles grant too many permissions or insufficient
permissions.
Role assignments can also be done temporarily, also known as Dynamic Separation of Duties (DSD),
 either within SQL Agent Job steps in T-SQL or using Azure PIM for Azure roles.
Make sure that DBAs don't have access to the encryption keys or key stores, and that Security
Administrators with access to the keys have no access to the database in turn. The use of Extensible Key
Management (EKM) can make this separation easier to achieve. Azure Key Vault can be used to
implement EKM.
Always make sure to have an Audit trail for security-related actions.
You can retrieve the definition of the Azure built-in roles to see the permissions used and create a custom
role based on excerpts and cumulations of these via PowerShell.
Because any member of the db_owner database role can change security settings like Transparent Data
Encryption (TDE), or change the SLO, this membership should be granted with care. However, there are
many tasks that require db_owner privileges. Task like changing any database setting such as changing
DB options. Auditing plays a key role in any solution.
It is not possible to restrict permissions of a db_owner, and therefore prevent an administrative account
from viewing user data. If there's highly sensitive data in a database, Always Encrypted can be used to
safely prevent db_owners or any other DBA from viewing it.

NOTE
Achieving Separation of Duties (SoD) is challenging for security-related or troubleshooting tasks. Other areas like
development and end-user roles are easier to segregate. Most compliance related controls allow the use of alternate
control functions such as Auditing when other solutions aren't practical.

For the readers that want to dive deeper into SoD, we recommend the following resources:
For Azure SQL Database and SQL Managed Instance:
Controlling and granting database access
Engine Separation of Duties for the Application Developer
Separation of Duties
Signing Stored Procedures
For Azure Resource Management:
Azure built-in roles
Azure custom roles
Using Azure AD Privileged Identity Management for elevated access
Perform regular code reviews
Mentioned in: PCI: 6.3.2, SOC: SDL-3

Separation of Duties is not limited to the data in a database, but includes application code. Malicious code can
potentially circumvent security controls. Before deploying custom code to production, it is essential to review
what's being deployed.
How to implement :
Use a database tool like Azure Data Studio that supports source control.
Implement a segregated code deployment process.
Before committing to main branch, a person (other than the author of the code itself) has to inspect the
code for potential elevation of privileges risks as well as malicious data modifications to protect against
 fraud and rogue access. This can be done using source control mechanisms.
Best practices :
Standardization: It helps to implement a standard procedure that is to be followed for any code updates.
Vulnerability Assessment contains rules that check for excessive permissions, the use of old encryption
algorithms, and other security problems within a database schema.
Further checks can be done in a QA or test environment using Advanced Threat Protection that scans for
code that is vulnerable to SQL-injection.
Examples of what to look out for:
Creation of a user or changing security settings from within an automated SQL-code-update
deployment.
A stored procedure, which, depending on the parameters provided, updates a monetary value in a cell
in a non-conforming way.
Make sure the person conducting the review is an individual other than the originating code author and
knowledgeable in code-reviews and secure coding.
Be sure to know all sources of code-changes. Code can be in T-SQL Scripts. It can be ad-hoc commands
to be executed or be deployed in forms of Views, Functions, Triggers, and Stored Procedures. It can be
part of SQL Agent Job definitions (Steps). It can also be executed from within SSIS packages, Azure Data
Factory, and other services.

Data protection
Data protection is a set of capabilities for safeguarding important information from compromise by encryption
or obfuscation.

NOTE
Microsoft attests to Azure SQL Database and SQL Managed Instance as being FIPS 140-2 Level 1 compliant. This is done
after verifying the strict use of FIPS 140-2 Level 1 acceptable algorithms and FIPS 140-2 Level 1 validated instances of
those algorithms including consistency with required key lengths, key management, key generation, and key storage. This
attestation is meant to allow our customers to respond to the need or requirement for the use of FIPS 140-2 Level 1
validated instances in the processing of data or delivery of systems or applications. We define the terms "FIPS 140-2 Level
1 compliant" and "FIPS 140-2 Level 1 compliance" used in the above statement to demonstrate their intended
applicability to U.S. and Canadian government use of the different term "FIPS 140-2 Level 1 validated."

Encrypt data in transit

Mentioned in: OSA Practice #6, ISO Control Family: Cryptography

Protects your data while data moves between your client and server. Refer to Network Security.
Encrypt data at rest
Mentioned in: OSA Practice #6, ISO Control Family: Cryptography

Encryption at rest is the cryptographic protection of data when it is persisted in database, log, and backup files.
How to implement :
Transparent Database Encryption (TDE) with service managed keys are enabled by default for any databases
created after 2017 in Azure SQL Database and SQL Managed Instance.
 In a managed instance, if the database is created from a restore operation using an on-premises server, the
TDE setting of the original database will be honored. If the original database doesn't have TDE enabled, we
recommend that TDE be manually turned on for the managed instance.
Best practices :
Don't store data that requires encryption-at-rest in the master database. The master database can't be
encrypted with TDE.
Use customer-managed keys in Azure Key Vault if you need increased transparency and granular control
over the TDE protection. Azure Key Vault allows the ability to revoke permissions at any time to render
the database inaccessible. You can centrally manage TDE protectors along with other keys, or rotate the
TDE protector at your own schedule using Azure Key Vault.
If you're using customer-managed keys in Azure Key Vault, follow the articles, Guidelines for configuring
TDE with Azure Key Vault and How to configure Geo-DR with Azure Key Vault.
Protect sensitive data in use from high-privileged, unauthorized users
Data in use is the data stored in memory of the database system during the execution of SQL queries. If your
database stores sensitive data, your organization may be required to ensure that high-privileged users are
prevented from viewing sensitive data in your database. High-privilege users, such as Microsoft operators or
DBAs in your organization should be able to manage the database, but prevented from viewing and potentially
exfiltrating sensitive data from the memory of the SQL process or by querying the database.
The policies that determine which data is sensitive and whether the sensitive data must be encrypted in memory
and not accessible to administrators in plaintext, are specific to your organization and compliance regulations
you need to adhere to. Please see the related requirement: Identify and tag sensitive data.
How to implement :
Use Always Encrypted to ensure sensitive data isn't exposed in plaintext in Azure SQL Database or SQL
Managed Instance, even in memory/in use. Always Encrypted protects the data from Database
Administrators (DBAs) and cloud admins (or bad actors who can impersonate high-privileged but
unauthorized users) and gives you more control over who can access your data.
Best practices :
Always Encrypted isn't a substitute to encrypt data at rest (TDE) or in transit (SSL/TLS). Always Encrypted
shouldn't be used for non-sensitive data to minimize performance and functionality impact. Using Always
Encrypted in conjunction with TDE and Transport Layer Security (TLS) is recommended for
comprehensive protection of data at-rest, in-transit, and in-use.
Assess the impact of encrypting the identified sensitive data columns before you deploy Always
Encrypted in a production database. In general, Always Encrypted reduces the functionality of queries on
encrypted columns and has other limitations, listed in Always Encrypted - Feature Details. Therefore, you
may need to rearchitect your application to re-implement the functionality, a query does not support, on
the client side or/and refactor your database schema, including the definitions of stored procedures,
functions, views and triggers. Existing applications may not work with encrypted columns if they do not
adhere to the restrictions and limitations of Always Encrypted. While the ecosystem of Microsoft tools,
products and services supporting Always Encrypted is growing, a number of them do not work with
encrypted columns. Encrypting a column may also impact query performance, depending on the
characteristics of your workload.
Manage Always Encrypted keys with role separation if you're using Always Encrypted to protect data
from malicious DBAs. With role separation, a security admin creates the physical keys. The DBA creates
the column master key and column encryption key metadata objects describing the physical keys in the
database. During this process, the security admin doesn't need access to the database, and the DBA
 doesn't need access to the physical keys in plaintext.
See the article, Managing Keys with Role Separation for details.
Store your column master keys in Azure Key Vault for ease of management. Avoid using Windows
Certificate Store (and in general, distributed key store solutions, as opposed central key management
solutions) that make key management hard.
Think carefully through the tradeoffs of using multiple keys (column master key or column encryption
keys). Keep the number of keys small to reduce key management cost. One column master key and one
column encryption key per database is typically sufficient in steady-state environments (not in the middle
of a key rotation). You may need additional keys if you have different user groups, each using different
keys and accessing different data.
Rotate column master keys per your compliance requirements. If you also need to rotate column
encryption keys, consider using online encryption to minimize application downtime.
See the article, Performance and Availability Considerations.
Use deterministic encryption if computations (equality) on data need to be supported. Otherwise, use
randomized encryption. Avoid using deterministic encryption for low-entropy data sets, or data sets with
publicly known distribution.
If you're concerned about third parties accessing your data legally without your consent, ensure that all
application and tools that have access to the keys and data in plaintext run outside of Microsoft Azure
Cloud. Without access to the keys, the third party will have no way of decrypting the data unless they
bypass the encryption.
Always Encrypted doesn't easily support granting temporary access to the keys (and the protected data).
For example, if you need to share the keys with a DBA to allow the DBA to do some cleansing operations
on sensitive and encrypted data. The only way to reliability revoke the access to the data from the DBA
will be to rotate both the column encryption keys and the column master keys protecting the data, which
is an expensive operation.
To access the plaintext values in encrypted columns, a user needs to have access to the Column Master
Key (CMK) that protects columns, which is configured in the key store holding the CMK. The user also
needs to have the VIEW ANY COLUMN MASTER KEY DEFINITION and VIEW ANY COLUMN
ENCRYPTION KEY DEFINITION database permissions.
Control access of application users to sensitive data through encryption
Encryption can be used as a way to ensure that only specific application users who have access to cryptographic
keys can view or update the data.
How to implement :
Use Cell-level Encryption (CLE). See the article, Encrypt a Column of Data for details.
Use Always Encrypted, but be aware of its limitation. The limitations are listed below.
Best practices
When using CLE:
Control access to keys through SQL permissions and roles.
Use AES (AES 256 recommended) for data encryption. Algorithms, such RC4, DES and TripleDES, are
deprecated and shouldn't be used because of known vulnerabilities.
Protect symmetric keys with asymmetric keys/certificates (not passwords) to avoid using 3DES.
Be careful when migrating a database using Cell-Level Encryption via export/import (bacpac files).
 See the article, Recommendations for using Cell Level Encryption in Azure SQL Database on how to
prevent losing keys when migrating data, and for other best practice guidance.
Keep in mind that Always Encrypted is primarily designed to protect sensitive data in use from high-privilege
users of Azure SQL Database (cloud operators, DBAs) - see Protect sensitive data in use from high-privileged,
unauthorized users. Be aware of the following challenges when using Always Encrypted to protect data from
application users:
By default, all Microsoft client drivers supporting Always Encrypted maintain a global (one per application)
cache of column encryption keys. Once a client driver acquires a plaintext column encryption key by
contacting a key store holding a column master key, the plaintext column encryption key is cached. This
makes isolating data from users of a multi-user application challenging. If your application impersonates end
users when interacting with a key store (such as Azure Key Vault), after a user's query populates the cache
with a column encryption key, a subsequent query that requires the same key but is triggered by another
user will use the cached key. The driver won't call the key store and it won't check if the second user has a
permission to access the column encryption key. As a result, the user can see the encrypted data even if the
user doesn't have access to the keys. To achieve the isolation of users within a multi-user application, you can
disable column encryption key caching. Disabling caching will cause additional performance overheads, as
the driver will need to contact the key store for each data encryption or decryption operation.
Protect data against unauthorized viewing by application users while preserving data format
Another technique for preventing unauthorized users from viewing data is to obfuscate or mask the data while
preserving data types and formats to ensure that user applications can continue handle and display the data.
How to implement :
Use Dynamic Data Masking to obfuscate table columns.

NOTE
Always Encrypted does not work with Dynamic Data Masking. It is not possible to encrypt and mask the same column,
which implies that you need to prioritize protecting data in use vs. masking the data for your app users via Dynamic Data
Masking.

Best practices :

NOTE
Dynamic Data Masking cannot be used to protect data from high-privilege users. Masking policies do not apply to users
with administrative access like db_owner.

Don't permit app users to run ad-hoc queries (as they may be able to work around Dynamic Data
Masking).
See the article, Bypassing masking using inference or brute-force techniques for details.
Use a proper access control policy (via SQL permissions, roles, RLS) to limit user permissions to make
updates in the masked columns. Creating a mask on a column doesn't prevent updates to that column.
Users that receive masked data when querying the masked column, can update the data if they have
write-permissions.
Dynamic Data Masking doesn't preserve the statistical properties of the masked values. This may impact
query results (for example, queries containing filtering predicates or joins on the masked data).

Network security
Network security refers to access controls and best practices to secure your data in transit to Azure SQL
Database.
Configure my client to connect securely to SQL Database/SQL Managed Instance
Best practices on how to prevent client machines and applications with well-known vulnerabilities (for example,
using older TLS protocols and cipher suites) from connecting to Azure SQL Database and SQL Managed
Instance.
How to implement :
Ensure that client machines connecting to Azure SQL Database and SQL Managed Instance are using the
latest Transport Layer Security (TLS) version.
Best practices :
Enforce a minimal TLS version at the SQL Database server or SQL Managed Instance level using the
minimal TLS version setting. We recommend setting the minimal TLS version to 1.2, after testing to
confirm your applications supports it. TLS 1.2 includes fixes for vulnerabilities found in previous versions.
Configure all your apps and tools to connect to SQL Database with encryption enabled
Encrypt = On, TrustServerCertificate = Off (or equivalent with non-Microsoft drivers).
If your app uses a driver that doesn't support TLS or supports an older version of TLS, replace the driver,
if possible. If not possible, carefully evaluate the security risks.
Reduce attack vectors via vulnerabilities in SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 by disabling them on
client machines connecting to Azure SQL Database per Transport Layer Security (TLS) registry
settings.
Check cipher suites available on the client: Cipher Suites in TLS/SSL (Schannel SSP). Specifically,
disable 3DES per Configuring TLS Cipher Suite Order.
Minimize attack surface
Minimize the number of features that can be attacked by a malicious user. Implement network access controls
for Azure SQL Database.

Mentioned in: OSA Practice #5

How to implement :
In SQL Database:
Set Allow Access to Azure services to OFF at the server-level
Use VNet Service endpoints and VNet Firewall Rules.
Use Private Link.
In SQL Managed Instance:
Follow the guidelines in Network requirements.
Best practices :
Restricting access to Azure SQL Database and SQL Managed Instance by connecting on a private
endpoint (for example, using a private data path):
A managed instance can be isolated inside a virtual network to prevent external access. Applications
and tools that are in the same or peered virtual network in the same region could access it directly.
Applications and tools that are in different region could use virtual-network-to-virtual-network
connection or ExpressRoute circuit peering to establish connection. Customer should use Network
 Security Groups (NSG) to restrict access over port 1433 only to resources that require access to a
managed instance.
For a SQL Database, use the Private Link feature that provides a dedicated private IP for the server
inside your virtual network. You can also use Virtual network service endpoints with virtual network
firewall rules to restrict access to your servers.
Mobile users should use point-to-site VPN connections to connect over the data path.
Users connected to their on-premises network should use site-to-site VPN connection or
ExpressRoute to connect over the data path.
You can access Azure SQL Database and SQL Managed Instance by connecting to a public endpoint (for
example, using a public data path). The following best practices should be considered:
For a server in SQL Database, use IP firewall rules to restrict access to only authorized IP addresses.
For SQL Managed Instance, use Network Security Groups (NSG) to restrict access over port 3342 only
to required resources. For more information, see Use a managed instance securely with public
endpoints.

NOTE
The SQL Managed Instance public endpoint is not enabled by default and it and must be explicitly enabled. If company
policy disallows the use of public endpoints, use Azure Policy to prevent enabling public endpoints in the first place.

Set up Azure Networking components:

Follow Azure best practices for network security.
Plan Virtual Network configuration per best practices outlined in Azure Virtual Network frequently
asked questions (FAQ) and plan.
Segment a virtual network into multiple subnets and assign resources for similar role to the same
subnet (for example, front-end vs back-end resources).
Use Network Security Groups (NSGs) to control traffic between subnets inside the Azure virtual
network boundary.
Enable Azure Network Watcher for your subscription to monitor inbound and outbound network
traffic.
Configure Power BI for secure connections to SQL Database/SQL Managed Instance
Best practices :
For Power BI Desktop, use private data path whenever possible.
Ensure that Power BI Desktop is connecting using TLS1.2 by setting the registry key on the client machine
as per Transport Layer Security (TLS) registry settings.
Restrict data access for specific users via Row-level security (RLS) with Power BI.
For Power BI Service, use the on-premises data gateway, keeping in mind Limitations and Considerations.
Configure App Service for secure connections to SQL Database/SQL Managed Instance
Best practices :
For a simple Web App, connecting over public endpoint requires setting Allow Azure Ser vices to ON.
Integrate your app with an Azure Virtual Network for private data path connectivity to a managed
instance. Optionally, you can also deploy a Web App with App Service Environments (ASE).
For Web App withASEorvirtual network Integrated Web Appconnecting to a database in SQL Database,
you can use virtual network service endpoints and virtual network firewall rules to limit access from a
specific virtual network and subnet. Then set Allow Azure Ser vices to OFF. You can also connect ASE to
 a managed instance in SQL Managed Instance over a private data path.
Ensure that your Web App is configured per the article, Best practices for securing platform as a service
(PaaS) web and mobile applications using Azure App Service.
Install Web Application Firewall (WAF) to protect your web app from common exploits and vulnerabilities.
Configure Azure virtual machine hosting for secure connections to SQL Database/SQL Managed Instance
Best practices :
Use a combination of Allow and Deny rules on the NSGs of Azure virtual machines to control which
regions can be accessed from the VM.
Ensure that your VM is configured per the article, Security best practices for IaaS workloads in Azure.
Ensure that all VMs are associated with a specific virtual network and subnet.
Evaluate if you need the default route 0.0.0.0/Internet per the guidance at about forced tunneling.
If yes – for example, front-end subnet - then keep the default route.
If no – for example, middle tier or back-end subnet – then enable force tunneling so no traffic goes
over Internet to reach on-premises (a.k.a cross-premises).
Implement optional default routes if you're using peering or connecting to on-premises.
Implement User Defined Routes if you need to send all traffic in the virtual network to a Network Virtual
Appliance for packet inspection.
Use virtual network service endpoints for secure access to PaaS services like Azure Storage via the Azure
backbone network.
Protect against Distributed Denial of Service (DDoS ) attacks
Distributed Denial of Service (DDoS) attacks are attempts by a malicious user to send a flood of network traffic
to Azure SQL Database with the aim of overwhelming the Azure infrastructure and causing it to reject valid
logins and workload.

Mentioned in: OSA Practice #9

How to implement :
DDoS protection is automatically enabled as part of the Azure Platform. It includes always-on traffic monitoring
and real-time mitigation of network-level attacks on public endpoints.
Use Azure DDoS Protection to monitor public IP addresses associated to resources deployed in virtual
networks.
Use Advanced Threat Protection for Azure SQL Database to detect Denial of Service (DoS) attacks against
databases.
Best practices :
Follow the practices described in Minimize Attack Surface helps minimize DDoS attack threats.
The Advanced Threat Protection Brute force SQL credentials alert helps to detect brute force attacks.
In some cases, the alert can even distinguish penetration testing workloads.
For Azure VM hosting applications connecting to SQL Database:
Follow recommendation to Restrict access through Internet-facing endpoints in Microsoft Defender
for Cloud.
 Use virtual machine scale sets to run multiple instances of your application on Azure VMs.
Disable RDP and SSH from Internet to prevent brute force attack.

Monitoring, Logging, and Auditing

This section refers to capabilities to help you detect anomalous activities indicating unusual and potentially
harmful attempts to access or exploit databases. It also describes best practices to configure database auditing
to track and capture database events.
Protect databases against attacks
Advanced threat protection enables you to detect and respond to potential threats as they occur by providing
security alerts on anomalous activities.
How to implement :
Use Advanced Threat Protection for SQL to detect unusual and potentially harmful attempts to access or
exploit databases, including:
SQL injection attack.
Credentials theft/leak.
Privilege abuse.
Data exfiltration.
Best practices :
Configure Microsoft Defender for SQLfor a specific server or a managed instance. You can also configure
Microsoft Defender for SQL for all servers and managed instances in a subscription by enabling
Microsoft Defender for Cloud.
For a full investigation experience, it's recommended to enableSQL Database Auditing. With auditing, you
can track database events and write them to an audit log in an Azure Storage account or Azure Log
Analytics workspace.
Audit critical security events
Tracking of database events helps you understand database activity. You can gain insight into discrepancies and
anomalies that could indicate business concerns or suspected security violations. It also enables and facilitates
adherence to compliance standards.
How to implement :
EnableSQL Database Auditing or Managed Instance Auditing to track database events and write them to
an audit log in your Azure Storage account, Log Analytics workspace (preview), or Event Hubs (preview).
Audit logs can be written to an Azure Storage account, to a Log Analytics workspace for consumption by
Azure Monitor logs, or to event hub for consumption using event hub. You can configure any
combination of these options, and audit logs will be written to each.
Best practices :
By configuring SQL Database Auditing on your server or Managed Instance Auditing to audit events, all
existing and newly created databases on that server will be audited.
By default auditing policy includes all actions (queries, stored procedures and successful and failed logins)
against the databases, which may result in high volume of audit logs. It's recommended for customers to
configure auditing for different types of actions and action groups using PowerShell. Configuring this will
help control the number of audited actions, and minimize the risk of event loss. Custom audit configurations
allow customers to capture only the audit data that is needed.
Audit logs can be consumed directly in the Azure portal, or from the storage location that was configured.
 NOTE
Enabling auditing to Log Analytics will incur cost based on ingestion rates. Please be aware of the associated cost with
using this option, or consider storing the audit logs in an Azure storage account.

Fur ther resources :

SQL Database Auditing
SQL Server Auditing
Secure audit logs
Restrict access to the storage account to support Separation of Duties and to separate DBA from Auditors.
How to implement :
When saving Audit logs to Azure Storage, make sure that access to the Storage Account is restricted to the
minimal security principles. Control who has access to the storage account.
For more information, see Authorizing access to Azure Storage.
Best practices :
Controlling Access to the Audit Target is a key concept in separating DBA from Auditors.
When auditing access to sensitive data, consider securing the data with data encryption to avoid
information leakage to the Auditor. For more information, see the section Protect sensitive data in use
from high-privileged, unauthorized users.

Security Management
This section describes the different aspects and best practices for managing your databases security posture. It
includes best practices for ensuring your databases are configured to meet security standards, for discovering
and for classifying and tracking access to potentially sensitive data in your databases.
Ensure that the databases are configured to meet security best practices
Proactively improve your database security by discovering and remediating potential database vulnerabilities.
How to implement :
Enable SQL Vulnerability Assessment (VA) to scan your database for security issues, and to automatically run
periodically on your databases.
Best practices :
Initially, run VA on your databases and iterate by remediating failing checks that oppose security best
practices. Set up baselines for acceptable configurations until the scan comes out clean, or all checks has
passed.
Configure periodic recurring scans to run once a week and configure the relevant person to receive
summary emails.
Review the VA summary following each weekly scan. For any vulnerabilities found, evaluate the drift from
the previous scan result and determine if the check should be resolved. Review if there's a legitimate
reason for the change in configuration.
Resolve checks and update baselines where relevant. Create ticket items for resolving actions and track
these until they're resolved.
Fur ther resources :
 SQL Vulnerability Assessment
SQL Vulnerability Assessment service helps you identify database vulnerabilities
Identify and tag sensitive data
Discover columns that potentially contain sensitive data. What is considered sensitive data heavily depends on
the customer, compliance regulation, etc., and needs to be evaluated by the users in charge of that data. Classify
the columns to use advanced sensitivity-based auditing and protection scenarios.
How to implement :
Use SQL Data Discovery and Classification to discover, classify, label, and protect the sensitive data in your
databases.
View the classification recommendations that are created by the automated discovery in the SQL Data
Discovery and Classification dashboard. Accept the relevant classifications, such that your sensitive
data is persistently tagged with classification labels.
Manually add classifications for any additional sensitive data fields that were not discovered by the
automated mechanism.
For more information, see SQL Data Discovery and Classification.
Best practices :
Monitor the classification dashboard on a regular basis for an accurate assessment of the database's
classification state. A report on the database classification state can be exported or printed to share for
compliance and auditing purposes.
Continuously monitor the status of recommended sensitive data in SQL Vulnerability Assessment. Track
the sensitive data discovery rule and identify any drift in the recommended columns for classification.
Use classification in a way that is tailored to the specific needs of your organization. Customize your
Information Protection policy (sensitivity labels, information types, discovery logic) in the SQL
Information Protection policy in Microsoft Defender for Cloud.
Track access to sensitive data
Monitor who accesses sensitive data and capture queries on sensitive data in audit logs.
How to implement :
Use SQL Audit and Data Classification in combination.
In your SQL Database Audit log, you can track access specifically to sensitive data. You can also view
information such as the data that was accessed, as well as its sensitivity label. For more information,
see Data Discovery and Classification and Auditing access to sensitive data.
Best practices :
See best practices for the Auditing and Data Classification sections:
Audit critical security events
Identify and tag sensitive data
Visualize security and compliance status
Use a unified infrastructure security management system that strengthens the security posture of your data
centers (including databases in SQL Database). View a list of recommendations concerning the security of your
databases and compliance status.
How to implement :
Monitor SQL-related security recommendations and active threats in Microsoft Defender for Cloud.
Common security threats and potential mitigations
This section helps you find security measures to protect against certain attack vectors. It's expected that most
mitigations can be achieved by following one or more of the security guidelines above.
Security threat: Data exfiltration
Data exfiltration is the unauthorized copying, transfer, or retrieval of data from a computer or server. See a
definition for data exfiltration on Wikipedia.
Connecting to server over a public endpoint presents a data exfiltration risk as it requires customers open their
firewalls to public IPs.
Scenario 1 : An application on an Azure VM connects to a database in Azure SQL Database. A rogue actor gets
access to the VM and compromises it. In this scenario, data exfiltration means that an external entity using the
rogue VM connects to the database, copies personal data, and stores it in a blob storage or a different SQL
Database in a different subscription.
Scenario 2 : A Rouge DBA. This scenario is often raised by security sensitive customers from regulated
industries. In this scenario, a high privilege user might copy data from Azure SQL Database to another
subscription not controlled by the data owner.
Potential mitigations :
Today, Azure SQL Database and SQL Managed Instance offers the following techniques for mitigating data
exfiltration threats:
Use a combination of Allow and Deny rules on the NSGs of Azure VMs to control which regions can be
accessed from the VM.
If using a server in SQL Database, set the following options:
Allow Azure Services to OFF.
Only allow traffic from the subnet containing your Azure VM by setting up a VNet Firewall rule.
Use Private Link
For SQL Managed Instance, using private IP access by default addresses the first data exfiltration concern of a
rogue VM. Turn on the subnet delegation feature on a subnet to automatically set the most restrictive policy
on a SQL Managed Instance subnet.
The Rogue DBA concern is more exposed with SQL Managed Instance as it has a larger surface area and
networking requirements are visible to customers. The best mitigation for this is applying all of the practices
in this security guide to prevent the Rogue DBA scenario in the first place (not only for data exfiltration).
Always Encrypted is one method to protect sensitive data by encrypting it and keeping the key inaccessible
for the DBA.

Security aspects of business continuity and availability

Most security standards address data availability in terms of operational continuity, achieved by implementing
redundancy and fail-over capabilities to avoid single points of failure. For disaster scenarios, it's a common
practice to keep backups of Data and Log files.The following section provides a high-level overview of the
capabilities that are built-into Azure. It also provides additional options that can be configured to meet specific
needs:
Azure offers built-in high-availability: High-availability with SQL Database and SQL Managed Instance
The Business Critical tier includes failover groups, full and differential log backups, and point-in-time-
restore backups enabled by default:
Automated backups
Recover a database using automated database backups - Point-in-time restore
 Additional business continuity features such as the zone redundant configuration and auto-failover
groups across different Azure geos can be configured:
High-availability - Zone redundant configuration for Premium & Business Critical service tiers
High-availability - Zone redundant configuration for General Purpose service tier
Overview of business continuity

Next steps
See An overview of Azure SQL Database security capabilities
 Azure Policy Regulatory Compliance controls for
Azure SQL Database & SQL Managed Instance
12/6/2021 • 56 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance

Regulatory Compliance in Azure Policy provides Microsoft created and managed initiative definitions, known as
built-ins, for the compliance domains and security controls related to different compliance standards. This
page lists the compliance domains and security controls for Azure SQL Database and SQL Managed
Instance. You can assign the built-ins for a security control individually to help make your Azure resources
compliant with the specific standard.
The title of each built-in policy definition links to the policy definition in the Azure portal. Use the link in the
Policy Version column to view the source on the Azure Policy GitHub repo.

IMPORTANT
Each control below is associated with one or more Azure Policy definitions. These policies may help you assess compliance
with the control; however, there often is not a one-to-one or complete match between a control and one or more policies.
As such, Compliant in Azure Policy refers only to the policies themselves; this doesn't ensure you're fully compliant with
all requirements of a control. In addition, the compliance standard includes controls that aren't addressed by any Azure
Policy definitions at this time. Therefore, compliance in Azure Policy is only a partial view of your overall compliance status.
The associations between controls and Azure Policy Regulatory Compliance definitions for these compliance standards
may change over time.

Australian Government ISM PROTECTED

To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - Australian Government ISM PROTECTED. For more information about this
compliance standard, see Australian Government ISM PROTECTED.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Guidelines for System 940 When to patch SQL databases 4.0.0

Management - security should have
System patching vulnerabilities - 940 vulnerability findings
resolved

Guidelines for System 940 When to patch Vulnerability 2.0.0

Management - security Assessment settings
System patching vulnerabilities - 940 for SQL server
should contain an
email address to
receive scan reports

Guidelines for System 940 When to patch Vulnerability 1.0.1

Management - security assessment should
System patching vulnerabilities - 940 be enabled on SQL
Managed Instance
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Guidelines for System 940 When to patch Vulnerability 2.0.0

Management - security assessment should
System patching vulnerabilities - 940 be enabled on your
SQL servers

Guidelines for System 1144 When to patch SQL databases 4.0.0

Management - security should have
System patching vulnerabilities - 1144 vulnerability findings
resolved

Guidelines for System 1144 When to patch Vulnerability 2.0.0

Management - security Assessment settings
System patching vulnerabilities - 1144 for SQL server
should contain an
email address to
receive scan reports

Guidelines for System 1144 When to patch Vulnerability 1.0.1

Management - security assessment should
System patching vulnerabilities - 1144 be enabled on SQL
Managed Instance

Guidelines for System 1144 When to patch Vulnerability 2.0.0

Management - security assessment should
System patching vulnerabilities - 1144 be enabled on your
SQL servers

Guidelines for 1260 Database An Azure Active 1.0.0

Database Systems - administrator Directory
Database accounts - 1260 administrator should
management system be provisioned for
software SQL servers

Guidelines for 1261 Database An Azure Active 1.0.0

Database Systems - administrator Directory
Database accounts - 1261 administrator should
management system be provisioned for
software SQL servers

Guidelines for 1262 Database An Azure Active 1.0.0

Database Systems - administrator Directory
Database accounts - 1262 administrator should
management system be provisioned for
software SQL servers

Guidelines for 1263 Database An Azure Active 1.0.0

Database Systems - administrator Directory
Database accounts - 1263 administrator should
management system be provisioned for
software SQL servers

Guidelines for 1264 Database An Azure Active 1.0.0

Database Systems - administrator Directory
Database accounts - 1264 administrator should
management system be provisioned for
software SQL servers
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Guidelines for 1425 Protecting database Transparent Data 2.0.0

Database Systems - server contents - Encryption on SQL
Database servers 1425 databases should be
enabled

Guidelines for System 1472 When to patch SQL databases 4.0.0

Management - security should have
System patching vulnerabilities - 1472 vulnerability findings
resolved

Guidelines for System 1472 When to patch Vulnerability 2.0.0

Management - security Assessment settings
System patching vulnerabilities - 1472 for SQL server
should contain an
email address to
receive scan reports

Guidelines for System 1472 When to patch Vulnerability 1.0.1

Management - security assessment should
System patching vulnerabilities - 1472 be enabled on SQL
Managed Instance

Guidelines for System 1472 When to patch Vulnerability 2.0.0

Management - security assessment should
System patching vulnerabilities - 1472 be enabled on your
SQL servers

Guidelines for System 1494 When to patch SQL databases 4.0.0

Management - security should have
System patching vulnerabilities - 1494 vulnerability findings
resolved

Guidelines for System 1494 When to patch Vulnerability 2.0.0

Management - security Assessment settings
System patching vulnerabilities - 1494 for SQL server
should contain an
email address to
receive scan reports

Guidelines for System 1494 When to patch Vulnerability 1.0.1

Management - security assessment should
System patching vulnerabilities - 1494 be enabled on SQL
Managed Instance

Guidelines for System 1494 When to patch Vulnerability 2.0.0

Management - security assessment should
System patching vulnerabilities - 1494 be enabled on your
SQL servers

Guidelines for System 1495 When to patch SQL databases 4.0.0

Management - security should have
System patching vulnerabilities - 1495 vulnerability findings
resolved
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Guidelines for System 1495 When to patch Vulnerability 2.0.0

Management - security Assessment settings
System patching vulnerabilities - 1495 for SQL server
should contain an
email address to
receive scan reports

Guidelines for System 1495 When to patch Vulnerability 1.0.1

Management - security assessment should
System patching vulnerabilities - 1495 be enabled on SQL
Managed Instance

Guidelines for System 1495 When to patch Vulnerability 2.0.0

Management - security assessment should
System patching vulnerabilities - 1495 be enabled on your
SQL servers

Guidelines for System 1496 When to patch SQL databases 4.0.0

Management - security should have
System patching vulnerabilities - 1496 vulnerability findings
resolved

Guidelines for System 1496 When to patch Vulnerability 2.0.0

Management - security Assessment settings
System patching vulnerabilities - 1496 for SQL server
should contain an
email address to
receive scan reports

Guidelines for System 1496 When to patch Vulnerability 1.0.1

Management - security assessment should
System patching vulnerabilities - 1496 be enabled on SQL
Managed Instance

Guidelines for System 1496 When to patch Vulnerability 2.0.0

Management - security assessment should
System patching vulnerabilities - 1496 be enabled on your
SQL servers

Guidelines for System 1537 Events to be logged - Azure Defender for 2.0.1
Monitoring - Event 1537 SQL should be
logging and auditing enabled for
unprotected Azure
SQL servers

Guidelines for System 1537 Events to be logged - Azure Defender for 1.0.2
Monitoring - Event 1537 SQL should be
logging and auditing enabled for
unprotected SQL
Managed Instances

Azure Security Benchmark

The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on
Azure. To see how this service completely maps to the Azure Security Benchmark, see the Azure Security
Benchmark mapping files.
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - Azure Security Benchmark.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Network Security NS-1 Implement security Public network access 1.1.0

for internal traffic on Azure SQL
Database should be
disabled

Network Security NS-2 Connect private Private endpoint 1.1.0

networks together connections on Azure
SQL Database should
be enabled

Network Security NS-3 Establish private Private endpoint 1.1.0

network access to connections on Azure
Azure services SQL Database should
be enabled

Identity IM-1 Standardize Azure An Azure Active 1.0.0

Management Active Directory as Directory
the central identity administrator should
and authentication be provisioned for
system SQL servers

Data Protection DP-1 Discovery, classify Sensitive data in your 3.0.0-preview

and label sensitive SQL databases
data should be classified

Data Protection DP-2 Protect sensitive data Azure Defender for 1.0.2
SQL should be
enabled for
unprotected SQL
Managed Instances

Data Protection DP-2 Protect sensitive data Transparent Data 2.0.0

Encryption on SQL
databases should be
enabled

Data Protection DP-3 Monitor for Azure Defender for 1.0.2

unauthorized transfer SQL should be
of sensitive data enabled for
unprotected SQL
Managed Instances

Data Protection DP-5 Encrypt sensitive SQL managed 1.0.2

data at rest instances should use
customer-managed
keys to encrypt data
at rest

Data Protection DP-5 Encrypt sensitive SQL servers should 2.0.1

data at rest use customer-
managed keys to
encrypt data at rest
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Data Protection DP-5 Encrypt sensitive Transparent Data 2.0.0

data at rest Encryption on SQL
databases should be
enabled

Logging and Threat LT-1 Enable threat Azure Defender for 1.0.2
Detection detection for Azure SQL should be
resources enabled for
unprotected SQL
Managed Instances

Logging and Threat LT-2 Enable threat Azure Defender for 1.0.2
Detection detection for Azure SQL should be
identity and access enabled for
management unprotected SQL
Managed Instances

Logging and Threat LT-4 Enable logging for Auditing on SQL 2.0.0
Detection Azure resources server should be
enabled

Logging and Threat LT-6 Configure log SQL servers with 3.0.0
Detection storage retention auditing to storage
account destination
should be configured
with 90 days
retention or higher

Incident Response IR-3 Detection and Azure Defender for 1.0.2

analysis - create SQL should be
incidents based on enabled for
high quality alerts unprotected SQL
Managed Instances

Incident Response IR-5 Detection and Azure Defender for 1.0.2

analysis - prioritize SQL should be
incidents enabled for
unprotected SQL
Managed Instances

Posture and PV-6 Perform software SQL databases 4.0.0

Vulnerability vulnerability should have
Management assessments vulnerability findings
resolved

Posture and PV-6 Perform software Vulnerability 1.0.1

Vulnerability vulnerability assessment should
Management assessments be enabled on SQL
Managed Instance

Posture and PV-6 Perform software Vulnerability 2.0.0

Vulnerability vulnerability assessment should
Management assessments be enabled on your
SQL servers
Azure Security Benchmark v1
The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on
Azure. To see how this service completely maps to the Azure Security Benchmark, see the Azure Security
Benchmark mapping files.
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - Azure Security Benchmark.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Network Security 1.1 Protect resources SQL Server should 1.0.0

using Network use a virtual network
Security Groups or service endpoint
Azure Firewall on
your Virtual Network

Logging and 2.3 Enable audit logging Auditing on SQL 2.0.0

Monitoring for Azure resources server should be
enabled

Logging and 2.3 Enable audit logging SQL Auditing 1.0.0

Monitoring for Azure resources settings should have
Action-Groups
configured to capture
critical activities

Logging and 2.5 Configure security SQL servers with 3.0.0

Monitoring log storage retention auditing to storage
account destination
should be configured
with 90 days
retention or higher

Logging and 2.7 Enable alerts for Azure Defender for 2.0.1
Monitoring anomalous activity SQL should be
enabled for
unprotected Azure
SQL servers

Logging and 2.7 Enable alerts for Azure Defender for 1.0.2
Monitoring anomalous activity SQL should be
enabled for
unprotected SQL
Managed Instances

Identity and Access 3.9 Use Azure Active An Azure Active 1.0.0
Control Directory Directory
administrator should
be provisioned for
SQL servers

Data Protection 4.1 Maintain an Sensitive data in your 3.0.0-preview

inventory of sensitive SQL databases
Information should be classified
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Data Protection 4.5 Use an active Azure Defender for 2.0.1

discovery tool to SQL should be
identify sensitive data enabled for
unprotected Azure
SQL servers

Data Protection 4.5 Use an active Azure Defender for 1.0.2

discovery tool to SQL should be
identify sensitive data enabled for
unprotected SQL
Managed Instances

Data Protection 4.5 Use an active Sensitive data in your 3.0.0-preview

discovery tool to SQL databases
identify sensitive data should be classified

Data Protection 4.8 Encrypt sensitive SQL managed 1.0.2

information at rest instances should use
customer-managed
keys to encrypt data
at rest

Data Protection 4.8 Encrypt sensitive SQL servers should 2.0.1

information at rest use customer-
managed keys to
encrypt data at rest

Data Protection 4.8 Encrypt sensitive Transparent Data 2.0.0

information at rest Encryption on SQL
databases should be
enabled

Vulnerability 5.1 Run automated Vulnerability 1.0.1

Management vulnerability scanning assessment should
tools be enabled on SQL
Managed Instance

Vulnerability 5.1 Run automated Vulnerability 2.0.0

Management vulnerability scanning assessment should
tools be enabled on your
SQL servers

Vulnerability 5.5 Use a risk-rating SQL databases 4.0.0

Management process to prioritize should have
the remediation of vulnerability findings
discovered resolved
vulnerabilities

Data Recovery 9.1 Ensure regular Long-term geo- 2.0.0

automated back ups redundant backup
should be enabled
for Azure SQL
Databases
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Data Recovery 9.2 Perform complete Long-term geo- 2.0.0

system backups and redundant backup
backup any customer should be enabled
managed keys for Azure SQL
Databases

Canada Federal PBMM

To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - Canada Federal PBMM. For more information about this compliance
standard, see Canada Federal PBMM.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Access Control AC-2(7) Account An Azure Active 1.0.0

Management | Role- Directory
Based Schemes administrator should
be provisioned for
SQL servers

Audit and AU-5 Response to Audit Auditing on SQL 2.0.0

Accountability Processing Failures server should be
enabled

Audit and AU-5 Response to Audit Azure Defender for 2.0.1

Accountability Processing Failures SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-5 Response to Audit Azure Defender for 1.0.2

Accountability Processing Failures SQL should be
enabled for
unprotected SQL
Managed Instances

Audit and AU-12 Audit Generation Auditing on SQL 2.0.0

Accountability server should be
enabled

Audit and AU-12 Audit Generation Azure Defender for 2.0.1

Accountability SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-12 Audit Generation Azure Defender for 1.0.2

Accountability SQL should be
enabled for
unprotected SQL
Managed Instances
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Risk Assessment RA-5 Vulnerability Azure Defender for 2.0.1

Scanning SQL should be
enabled for
unprotected Azure
SQL servers

Risk Assessment RA-5 Vulnerability Azure Defender for 1.0.2

Scanning SQL should be
enabled for
unprotected SQL
Managed Instances

Risk Assessment RA-5 Vulnerability SQL databases 4.0.0

Scanning should have
vulnerability findings
resolved

System and SC-28 Protection of Azure Defender for 2.0.1

Communications Information at Rest SQL should be
Protection enabled for
unprotected Azure
SQL servers

System and SC-28 Protection of Azure Defender for 1.0.2

Communications Information at Rest SQL should be
Protection enabled for
unprotected SQL
Managed Instances

System and SC-28 Protection of Transparent Data 2.0.0

Communications Information at Rest Encryption on SQL
Protection databases should be
enabled

System and SI-2 Flaw Remediation SQL databases 4.0.0

Information Integrity should have
vulnerability findings
resolved

System and SI-4 Information System Azure Defender for 2.0.1

Information Integrity Monitoring SQL should be
enabled for
unprotected Azure
SQL servers

System and SI-4 Information System Azure Defender for 1.0.2

Information Integrity Monitoring SQL should be
enabled for
unprotected SQL
Managed Instances

CIS Microsoft Azure Foundations Benchmark 1.1.0

To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - CIS Microsoft Azure Foundations Benchmark 1.1.0. For more information
about this compliance standard, see CIS Microsoft Azure Foundations Benchmark.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Security Center 2.14 Ensure ASC Default Auditing on SQL 2.0.0

policy setting server should be
"Monitor SQL enabled
Auditing" is not
"Disabled"

Security Center 2.15 Ensure ASC Default Transparent Data 2.0.0

policy setting Encryption on SQL
"Monitor SQL databases should be
Encryption" is not enabled
"Disabled"

Database Services 4.1 Ensure that 'Auditing' Auditing on SQL 2.0.0

is set to 'On' server should be
enabled

Database Services 4.2 Ensure that SQL Auditing 1.0.0

'AuditActionGroups' settings should have
in 'auditing' policy for Action-Groups
a SQL server is set configured to capture
properly critical activities

Database Services 4.3 Ensure that 'Auditing' SQL servers with 3.0.0
Retention is 'greater auditing to storage
than 90 days' account destination
should be configured
with 90 days
retention or higher

Database Services 4.4 Ensure that Azure Defender for 2.0.1

'Advanced Data SQL should be
Security' on a SQL enabled for
server is set to 'On' unprotected Azure
SQL servers

Database Services 4.4 Ensure that Azure Defender for 1.0.2

'Advanced Data SQL should be
Security' on a SQL enabled for
server is set to 'On' unprotected SQL
Managed Instances

Database Services 4.8 Ensure that Azure An Azure Active 1.0.0

Active Directory Directory
Admin is configured administrator should
be provisioned for
SQL servers

Database Services 4.9 Ensure that 'Data Transparent Data 2.0.0

encryption' is set to Encryption on SQL
'On' on a SQL databases should be
Database enabled
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Database Services 4.10 Ensure SQL server's SQL managed 1.0.2

TDE protector is instances should use
encrypted with BYOK customer-managed
(Use your own key) keys to encrypt data
at rest

Database Services 4.10 Ensure SQL server's SQL servers should 2.0.1
TDE protector is use customer-
encrypted with BYOK managed keys to
(Use your own key) encrypt data at rest

CIS Microsoft Azure Foundations Benchmark 1.3.0

To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - CIS Microsoft Azure Foundations Benchmark 1.3.0. For more information
about this compliance standard, see CIS Microsoft Azure Foundations Benchmark.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Database Services 4.1.1 Ensure that 'Auditing' Auditing on SQL 2.0.0

is set to 'On' server should be
enabled

Database Services 4.1.2 Ensure that 'Data Transparent Data 2.0.0

encryption' is set to Encryption on SQL
'On' on a SQL databases should be
Database enabled

Database Services 4.1.3 Ensure that 'Auditing' SQL servers with 3.0.0
Retention is 'greater auditing to storage
than 90 days' account destination
should be configured
with 90 days
retention or higher

Database Services 4.2.1 Ensure that Azure Defender for 2.0.1

Advanced Threat SQL should be
Protection (ATP) on a enabled for
SQL server is set to unprotected Azure
'Enabled' SQL servers

Database Services 4.2.1 Ensure that Azure Defender for 1.0.2

Advanced Threat SQL should be
Protection (ATP) on a enabled for
SQL server is set to unprotected SQL
'Enabled' Managed Instances

Database Services 4.2.2 Ensure that Vulnerability 1.0.1

Vulnerability assessment should
Assessment (VA) is be enabled on SQL
enabled on a SQL Managed Instance
server by setting a
Storage Account
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Database Services 4.2.2 Ensure that Vulnerability 2.0.0

Vulnerability assessment should
Assessment (VA) is be enabled on your
enabled on a SQL SQL servers
server by setting a
Storage Account

Database Services 4.2.4 Ensure that VA Vulnerability 2.0.0

setting Send scan Assessment settings
reports to is for SQL server
configured for a SQL should contain an
server email address to
receive scan reports

Database Services 4.4 Ensure that Azure An Azure Active 1.0.0

Active Directory Directory
Admin is configured administrator should
be provisioned for
SQL servers

Database Services 4.5 Ensure SQL server's SQL managed 1.0.2

TDE protector is instances should use
encrypted with customer-managed
Customer-managed keys to encrypt data
key at rest

Database Services 4.5 Ensure SQL server's SQL servers should 2.0.1
TDE protector is use customer-
encrypted with managed keys to
Customer-managed encrypt data at rest
key

CMMC Level 3
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - CMMC Level 3. For more information about this compliance standard, see
Cybersecurity Maturity Model Certification (CMMC).

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Access Control AC.1.001 Limit information Public network access 1.1.0

system access to on Azure SQL
authorized users, Database should be
processes acting on disabled
behalf of authorized
users, and devices
(including other
information systems).

Access Control AC.1.002 Limit information Public network access 1.1.0

system access to the on Azure SQL
types of transactions Database should be
and functions that disabled
authorized users are
permitted to execute.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Access Control AC.2.016 Control the flow of Public network access 1.1.0
CUI in accordance on Azure SQL
with approved Database should be
authorizations. disabled

Audit and AU.2.041 Ensure that the Auditing on SQL 2.0.0

Accountability actions of individual server should be
system users can be enabled
uniquely traced to
those users so they
can be held
accountable for their
actions.

Audit and AU.2.041 Ensure that the Azure Defender for 2.0.1
Accountability actions of individual SQL should be
system users can be enabled for
uniquely traced to unprotected Azure
those users so they SQL servers
can be held
accountable for their
actions.

Audit and AU.2.041 Ensure that the Azure Defender for 1.0.2
Accountability actions of individual SQL should be
system users can be enabled for
uniquely traced to unprotected SQL
those users so they Managed Instances
can be held
accountable for their
actions.

Audit and AU.2.042 Create and retain Auditing on SQL 2.0.0

Accountability system audit logs server should be
and records to the enabled
extent needed to
enable the
monitoring, analysis,
investigation, and
reporting of unlawful
or unauthorized
system activity.

Audit and AU.2.042 Create and retain Azure Defender for 2.0.1
Accountability system audit logs SQL should be
and records to the enabled for
extent needed to unprotected Azure
enable the SQL servers
monitoring, analysis,
investigation, and
reporting of unlawful
or unauthorized
system activity.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Audit and AU.2.042 Create and retain Azure Defender for 1.0.2
Accountability system audit logs SQL should be
and records to the enabled for
extent needed to unprotected SQL
enable the Managed Instances
monitoring, analysis,
investigation, and
reporting of unlawful
or unauthorized
system activity.

Audit and AU.3.046 Alert in the event of Auditing on SQL 2.0.0

Accountability an audit logging server should be
process failure. enabled

Audit and AU.3.046 Alert in the event of Azure Defender for 2.0.1
Accountability an audit logging SQL should be
process failure. enabled for
unprotected Azure
SQL servers

Audit and AU.3.046 Alert in the event of Azure Defender for 1.0.2
Accountability an audit logging SQL should be
process failure. enabled for
unprotected SQL
Managed Instances

Security Assessment CA.2.158 Periodically assess Auditing on SQL 2.0.0

the security controls server should be
in organizational enabled
systems to determine
if the controls are
effective in their
application.

Security Assessment CA.2.158 Periodically assess Vulnerability 1.0.1

the security controls assessment should
in organizational be enabled on SQL
systems to determine Managed Instance
if the controls are
effective in their
application.

Security Assessment CA.2.158 Periodically assess Vulnerability 2.0.0

the security controls assessment should
in organizational be enabled on your
systems to determine SQL servers
if the controls are
effective in their
application.

Security Assessment CA.3.161 Monitor security Auditing on SQL 2.0.0

controls on an server should be
ongoing basis to enabled
ensure the continued
effectiveness of the
controls.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Security Assessment CA.3.161 Monitor security Vulnerability 1.0.1

controls on an assessment should
ongoing basis to be enabled on SQL
ensure the continued Managed Instance
effectiveness of the
controls.

Security Assessment CA.3.161 Monitor security Vulnerability 2.0.0

controls on an assessment should
ongoing basis to be enabled on your
ensure the continued SQL servers
effectiveness of the
controls.

Configuration CM.2.064 Establish and enforce Azure Defender for 2.0.1

Management security configuration SQL should be
settings for enabled for
information unprotected Azure
technology products SQL servers
employed in
organizational
systems.

Configuration CM.2.064 Establish and enforce Azure Defender for 1.0.2

Management security configuration SQL should be
settings for enabled for
information unprotected SQL
technology products Managed Instances
employed in
organizational
systems.

Configuration CM.3.068 Restrict, disable, or Public network access 1.1.0

Management prevent the use of on Azure SQL
nonessential Database should be
programs, functions, disabled
ports, protocols, and
services.

Incident Response IR.2.092 Establish an Vulnerability 2.0.0

operational incident- Assessment settings
handling capability for SQL server
for organizational should contain an
systems that includes email address to
preparation, receive scan reports
detection, analysis,
containment,
recovery, and user
response activities.

Recovery RE.2.137 Regularly perform Long-term geo- 2.0.0

and test data back- redundant backup
ups. should be enabled
for Azure SQL
Databases
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Recovery RE.3.139 Regularly perform Long-term geo- 2.0.0

complete, redundant backup
comprehensive and should be enabled
resilient data backups for Azure SQL
as organizationally- Databases
defined.

Risk Assessment RM.2.141 Periodically assess Azure Defender for 2.0.1

the risk to SQL should be
organizational enabled for
operations (including unprotected Azure
mission, functions, SQL servers
image, or reputation),
organizational assets,
and individuals,
resulting from the
operation of
organizational
systems and the
associated
processing, storage,
or transmission of
CUI.

Risk Assessment RM.2.141 Periodically assess Azure Defender for 1.0.2

the risk to SQL should be
organizational enabled for
operations (including unprotected SQL
mission, functions, Managed Instances
image, or reputation),
organizational assets,
and individuals,
resulting from the
operation of
organizational
systems and the
associated
processing, storage,
or transmission of
CUI.

Risk Assessment RM.2.141 Periodically assess Vulnerability 2.0.0

the risk to Assessment settings
organizational for SQL server
operations (including should contain an
mission, functions, email address to
image, or reputation), receive scan reports
organizational assets,
and individuals,
resulting from the
operation of
organizational
systems and the
associated
processing, storage,
or transmission of
CUI.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Risk Assessment RM.2.141 Periodically assess Vulnerability 1.0.1

the risk to assessment should
organizational be enabled on SQL
operations (including Managed Instance
mission, functions,
image, or reputation),
organizational assets,
and individuals,
resulting from the
operation of
organizational
systems and the
associated
processing, storage,
or transmission of
CUI.

Risk Assessment RM.2.141 Periodically assess Vulnerability 2.0.0

the risk to assessment should
organizational be enabled on your
operations (including SQL servers
mission, functions,
image, or reputation),
organizational assets,
and individuals,
resulting from the
operation of
organizational
systems and the
associated
processing, storage,
or transmission of
CUI.

Risk Assessment RM.2.142 Scan for Azure Defender for 2.0.1

vulnerabilities in SQL should be
organizational enabled for
systems and unprotected Azure
applications SQL servers
periodically and when
new vulnerabilities
affecting those
systems and
applications are
identified.

Risk Assessment RM.2.142 Scan for Azure Defender for 1.0.2

vulnerabilities in SQL should be
organizational enabled for
systems and unprotected SQL
applications Managed Instances
periodically and when
new vulnerabilities
affecting those
systems and
applications are
identified.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Risk Assessment RM.2.142 Scan for Vulnerability 2.0.0

vulnerabilities in Assessment settings
organizational for SQL server
systems and should contain an
applications email address to
periodically and when receive scan reports
new vulnerabilities
affecting those
systems and
applications are
identified.

Risk Assessment RM.2.142 Scan for Vulnerability 1.0.1

vulnerabilities in assessment should
organizational be enabled on SQL
systems and Managed Instance
applications
periodically and when
new vulnerabilities
affecting those
systems and
applications are
identified.

Risk Assessment RM.2.142 Scan for Vulnerability 2.0.0

vulnerabilities in assessment should
organizational be enabled on your
systems and SQL servers
applications
periodically and when
new vulnerabilities
affecting those
systems and
applications are
identified.

Risk Assessment RM.2.143 Remediate Azure Defender for 2.0.1

vulnerabilities in SQL should be
accordance with risk enabled for
assessments. unprotected Azure
SQL servers

Risk Assessment RM.2.143 Remediate Azure Defender for 1.0.2

vulnerabilities in SQL should be
accordance with risk enabled for
assessments. unprotected SQL
Managed Instances

Risk Assessment RM.2.143 Remediate SQL databases 4.0.0

vulnerabilities in should have
accordance with risk vulnerability findings
assessments. resolved
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Risk Assessment RM.2.143 Remediate Vulnerability 2.0.0

vulnerabilities in Assessment settings
accordance with risk for SQL server
assessments. should contain an
email address to
receive scan reports

Risk Assessment RM.2.143 Remediate Vulnerability 1.0.1

vulnerabilities in assessment should
accordance with risk be enabled on SQL
assessments. Managed Instance

Risk Assessment RM.2.143 Remediate Vulnerability 2.0.0

vulnerabilities in assessment should
accordance with risk be enabled on your
assessments. SQL servers

Risk Management RM.3.144 Periodically perform Vulnerability 2.0.0

risk assessments to Assessment settings
identify and prioritize for SQL server
risks according to the should contain an
defined risk email address to
categories, risk receive scan reports
sources and risk
measurement criteria.

System and SC.1.175 Monitor, control, and Public network access 1.1.0
Communications protect on Azure SQL
Protection communications (i.e., Database should be
information disabled
transmitted or
received by
organizational
systems) at the
external boundaries
and key internal
boundaries of
organizational
systems.

System and SC.3.177 Employ FIPS- SQL managed 1.0.2

Communications validated instances should use
Protection cryptography when customer-managed
used to protect the keys to encrypt data
confidentiality of CUI. at rest

System and SC.3.177 Employ FIPS- SQL servers should 2.0.1

Communications validated use customer-
Protection cryptography when managed keys to
used to protect the encrypt data at rest
confidentiality of CUI.

System and SC.3.177 Employ FIPS- Transparent Data 2.0.0

Communications validated Encryption on SQL
Protection cryptography when databases should be
used to protect the enabled
confidentiality of CUI.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

System and SC.3.181 Separate user An Azure Active 1.0.0

Communications functionality from Directory
Protection system management administrator should
functionality. be provisioned for
SQL servers

System and SC.3.183 Deny network Public network access 1.1.0

Communications communications on Azure SQL
Protection traffic by default and Database should be
allow network disabled
communications
traffic by exception
(i.e., deny all, permit
by exception).

System and SC.3.191 Protect the Azure Defender for 2.0.1

Communications confidentiality of CUI SQL should be
Protection at rest. enabled for
unprotected Azure
SQL servers

System and SC.3.191 Protect the Azure Defender for 1.0.2

Communications confidentiality of CUI SQL should be
Protection at rest. enabled for
unprotected SQL
Managed Instances

System and SC.3.191 Protect the Transparent Data 2.0.0

Communications confidentiality of CUI Encryption on SQL
Protection at rest. databases should be
enabled

System and SI.1.210 Identify, report, and SQL databases 4.0.0

Information Integrity correct information should have
and information vulnerability findings
system flaws in a resolved
timely manner.

System and SI.2.216 Monitor Azure Defender for 2.0.1

Information Integrity organizational SQL should be
systems, including enabled for
inbound and unprotected Azure
outbound SQL servers
communications
traffic, to detect
attacks and
indicators of
potential attacks.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

System and SI.2.216 Monitor Azure Defender for 1.0.2

Information Integrity organizational SQL should be
systems, including enabled for
inbound and unprotected SQL
outbound Managed Instances
communications
traffic, to detect
attacks and
indicators of
potential attacks.

System and SI.2.217 Identify unauthorized Azure Defender for 2.0.1

Information Integrity use of organizational SQL should be
systems. enabled for
unprotected Azure
SQL servers

System and SI.2.217 Identify unauthorized Azure Defender for 1.0.2

Information Integrity use of organizational SQL should be
systems. enabled for
unprotected SQL
Managed Instances

FedRAMP High
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - FedRAMP High. For more information about this compliance standard,
see FedRAMP High.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Access Control AC-2 Account An Azure Active 1.0.0

Management Directory
administrator should
be provisioned for
SQL servers

Access Control AC-2 (1) Automated System An Azure Active 1.0.0

Account Directory
Management administrator should
be provisioned for
SQL servers

Access Control AC-2 (7) Role-based Schemes An Azure Active 1.0.0

Directory
administrator should
be provisioned for
SQL servers

Access Control AC-2 (12) Account Monitoring / Azure Defender for 1.0.2
Atypical Usage SQL should be
enabled for
unprotected SQL
Managed Instances
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Access Control AC-3 Access Enforcement An Azure Active 1.0.0

Directory
administrator should
be provisioned for
SQL servers

Access Control AC-4 Information Flow Private endpoint 1.1.0

Enforcement connections on Azure
SQL Database should
be enabled

Access Control AC-4 Information Flow Public network access 1.1.0

Enforcement on Azure SQL
Database should be
disabled

Access Control AC-17 Remote Access Private endpoint 1.1.0

connections on Azure
SQL Database should
be enabled

Access Control AC-17 (1) Automated Private endpoint 1.1.0

Monitoring / Control connections on Azure
SQL Database should
be enabled

Audit and AU-6 Audit Review, Azure Defender for 2.0.1

Accountability Analysis, and SQL should be
Reporting enabled for
unprotected Azure
SQL servers

Audit and AU-6 Audit Review, Azure Defender for 1.0.2

Accountability Analysis, and SQL should be
Reporting enabled for
unprotected SQL
Managed Instances

Audit and AU-6 (4) Central Review and Auditing on SQL 2.0.0
Accountability Analysis server should be
enabled

Audit and AU-6 (4) Central Review and Azure Defender for 2.0.1
Accountability Analysis SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-6 (4) Central Review and Azure Defender for 1.0.2
Accountability Analysis SQL should be
enabled for
unprotected SQL
Managed Instances
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Audit and AU-6 (5) Integration / Auditing on SQL 2.0.0

Accountability Scanning and server should be
Monitoring enabled
Capabilities

Audit and AU-6 (5) Integration / Azure Defender for 2.0.1

Accountability Scanning and SQL should be
Monitoring enabled for
Capabilities unprotected Azure
SQL servers

Audit and AU-6 (5) Integration / Azure Defender for 1.0.2

Accountability Scanning and SQL should be
Monitoring enabled for
Capabilities unprotected SQL
Managed Instances

Audit and AU-11 Audit Record SQL servers with 3.0.0

Accountability Retention auditing to storage
account destination
should be configured
with 90 days
retention or higher

Audit and AU-12 Audit Generation Auditing on SQL 2.0.0

Accountability server should be
enabled

Audit and AU-12 Audit Generation Azure Defender for 2.0.1

Accountability SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-12 Audit Generation Azure Defender for 1.0.2

Accountability SQL should be
enabled for
unprotected SQL
Managed Instances

Audit and AU-12 (1) System-wide / Time- Auditing on SQL 2.0.0

Accountability correlated Audit Trail server should be
enabled

Audit and AU-12 (1) System-wide / Time- Azure Defender for 2.0.1
Accountability correlated Audit Trail SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-12 (1) System-wide / Time- Azure Defender for 1.0.2
Accountability correlated Audit Trail SQL should be
enabled for
unprotected SQL
Managed Instances
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Contingency CP-6 Alternate Storage Site Long-term geo- 2.0.0

Planning redundant backup
should be enabled
for Azure SQL
Databases

Contingency CP-6 (1) Separation from Long-term geo- 2.0.0

Planning Primary Site redundant backup
should be enabled
for Azure SQL
Databases

Identification and IA-2 Identification and An Azure Active 1.0.0

Authentication Authentication Directory
(organizational Users) administrator should
be provisioned for
SQL servers

Identification and IA-4 Identifier An Azure Active 1.0.0

Authentication Management Directory
administrator should
be provisioned for
SQL servers

Incident Response IR-4 Incident Handling Azure Defender for 2.0.1

SQL should be
enabled for
unprotected Azure
SQL servers

Incident Response IR-4 Incident Handling Azure Defender for 1.0.2

SQL should be
enabled for
unprotected SQL
Managed Instances

Incident Response IR-5 Incident Monitoring Azure Defender for 2.0.1

SQL should be
enabled for
unprotected Azure
SQL servers

Incident Response IR-5 Incident Monitoring Azure Defender for 1.0.2

SQL should be
enabled for
unprotected SQL
Managed Instances

Risk Assessment RA-5 Vulnerability Azure Defender for 2.0.1

Scanning SQL should be
enabled for
unprotected Azure
SQL servers
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Risk Assessment RA-5 Vulnerability Azure Defender for 1.0.2

Scanning SQL should be
enabled for
unprotected SQL
Managed Instances

Risk Assessment RA-5 Vulnerability SQL databases 4.0.0

Scanning should have
vulnerability findings
resolved

Risk Assessment RA-5 Vulnerability Vulnerability 1.0.1

Scanning assessment should
be enabled on SQL
Managed Instance

Risk Assessment RA-5 Vulnerability Vulnerability 2.0.0

Scanning assessment should
be enabled on your
SQL servers

System and SC-7 Boundary Protection Private endpoint 1.1.0

Communications connections on Azure
Protection SQL Database should
be enabled

System and SC-7 Boundary Protection Public network access 1.1.0

Communications on Azure SQL
Protection Database should be
disabled

System and SC-7 (3) Access Points Private endpoint 1.1.0

Communications connections on Azure
Protection SQL Database should
be enabled

System and SC-7 (3) Access Points Public network access 1.1.0
Communications on Azure SQL
Protection Database should be
disabled

System and SC-12 Cryptographic Key SQL managed 1.0.2

Communications Establishment and instances should use
Protection Management customer-managed
keys to encrypt data
at rest

System and SC-12 Cryptographic Key SQL servers should 2.0.1

Communications Establishment and use customer-
Protection Management managed keys to
encrypt data at rest

System and SC-28 Protection of Sensitive data in your 3.0.0-preview

Communications Information at Rest SQL databases
Protection should be classified
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

System and SC-28 Protection of Transparent Data 2.0.0

Communications Information at Rest Encryption on SQL
Protection databases should be
enabled

System and SC-28 (1) Cryptographic Sensitive data in your 3.0.0-preview

Communications Protection SQL databases
Protection should be classified

System and SC-28 (1) Cryptographic Transparent Data 2.0.0

Communications Protection Encryption on SQL
Protection databases should be
enabled

System and SI-2 Flaw Remediation SQL databases 4.0.0

Information Integrity should have
vulnerability findings
resolved

System and SI-4 Information System Azure Defender for 2.0.1

Information Integrity Monitoring SQL should be
enabled for
unprotected Azure
SQL servers

System and SI-4 Information System Azure Defender for 1.0.2

Information Integrity Monitoring SQL should be
enabled for
unprotected SQL
Managed Instances

FedRAMP Moderate
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - FedRAMP Moderate. For more information about this compliance
standard, see FedRAMP Moderate.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Access Control AC-2 Account An Azure Active 1.0.0

Management Directory
administrator should
be provisioned for
SQL servers

Access Control AC-2 (1) Automated System An Azure Active 1.0.0

Account Directory
Management administrator should
be provisioned for
SQL servers
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Access Control AC-2 (7) Role-based Schemes An Azure Active 1.0.0

Directory
administrator should
be provisioned for
SQL servers

Access Control AC-2 (12) Account Monitoring / Azure Defender for 1.0.2
Atypical Usage SQL should be
enabled for
unprotected SQL
Managed Instances

Access Control AC-3 Access Enforcement An Azure Active 1.0.0

Directory
administrator should
be provisioned for
SQL servers

Access Control AC-4 Information Flow Private endpoint 1.1.0

Enforcement connections on Azure
SQL Database should
be enabled

Access Control AC-4 Information Flow Public network access 1.1.0

Enforcement on Azure SQL
Database should be
disabled

Access Control AC-17 Remote Access Private endpoint 1.1.0

connections on Azure
SQL Database should
be enabled

Access Control AC-17 (1) Automated Private endpoint 1.1.0

Monitoring / Control connections on Azure
SQL Database should
be enabled

Audit and AU-6 Audit Review, Azure Defender for 2.0.1

Accountability Analysis, and SQL should be
Reporting enabled for
unprotected Azure
SQL servers

Audit and AU-6 Audit Review, Azure Defender for 1.0.2

Accountability Analysis, and SQL should be
Reporting enabled for
unprotected SQL
Managed Instances

Audit and AU-11 Audit Record SQL servers with 3.0.0

Accountability Retention auditing to storage
account destination
should be configured
with 90 days
retention or higher
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Audit and AU-12 Audit Generation Auditing on SQL 2.0.0

Accountability server should be
enabled

Audit and AU-12 Audit Generation Azure Defender for 2.0.1

Accountability SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-12 Audit Generation Azure Defender for 1.0.2

Accountability SQL should be
enabled for
unprotected SQL
Managed Instances

Contingency CP-6 Alternate Storage Site Long-term geo- 2.0.0

Planning redundant backup
should be enabled
for Azure SQL
Databases

Contingency CP-6 (1) Separation from Long-term geo- 2.0.0

Planning Primary Site redundant backup
should be enabled
for Azure SQL
Databases

Identification and IA-2 Identification and An Azure Active 1.0.0

Authentication Authentication Directory
(organizational Users) administrator should
be provisioned for
SQL servers

Identification and IA-4 Identifier An Azure Active 1.0.0

Authentication Management Directory
administrator should
be provisioned for
SQL servers

Incident Response IR-4 Incident Handling Azure Defender for 2.0.1

SQL should be
enabled for
unprotected Azure
SQL servers

Incident Response IR-4 Incident Handling Azure Defender for 1.0.2

SQL should be
enabled for
unprotected SQL
Managed Instances
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Incident Response IR-5 Incident Monitoring Azure Defender for 2.0.1

SQL should be
enabled for
unprotected Azure
SQL servers

Incident Response IR-5 Incident Monitoring Azure Defender for 1.0.2

SQL should be
enabled for
unprotected SQL
Managed Instances

Risk Assessment RA-5 Vulnerability Azure Defender for 2.0.1

Scanning SQL should be
enabled for
unprotected Azure
SQL servers

Risk Assessment RA-5 Vulnerability Azure Defender for 1.0.2

Scanning SQL should be
enabled for
unprotected SQL
Managed Instances

Risk Assessment RA-5 Vulnerability SQL databases 4.0.0

Scanning should have
vulnerability findings
resolved

Risk Assessment RA-5 Vulnerability Vulnerability 1.0.1

Scanning assessment should
be enabled on SQL
Managed Instance

Risk Assessment RA-5 Vulnerability Vulnerability 2.0.0

Scanning assessment should
be enabled on your
SQL servers

System and SC-7 Boundary Protection Private endpoint 1.1.0

Communications connections on Azure
Protection SQL Database should
be enabled

System and SC-7 Boundary Protection Public network access 1.1.0

Communications on Azure SQL
Protection Database should be
disabled

System and SC-7 (3) Access Points Private endpoint 1.1.0

Communications connections on Azure
Protection SQL Database should
be enabled
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

System and SC-7 (3) Access Points Public network access 1.1.0
Communications on Azure SQL
Protection Database should be
disabled

System and SC-12 Cryptographic Key SQL managed 1.0.2

Communications Establishment and instances should use
Protection Management customer-managed
keys to encrypt data
at rest

System and SC-12 Cryptographic Key SQL servers should 2.0.1

Communications Establishment and use customer-
Protection Management managed keys to
encrypt data at rest

System and SC-28 Protection of Sensitive data in your 3.0.0-preview

Communications Information at Rest SQL databases
Protection should be classified

System and SC-28 Protection of Transparent Data 2.0.0

Communications Information at Rest Encryption on SQL
Protection databases should be
enabled

System and SC-28 (1) Cryptographic Sensitive data in your 3.0.0-preview

Communications Protection SQL databases
Protection should be classified

System and SC-28 (1) Cryptographic Transparent Data 2.0.0

Communications Protection Encryption on SQL
Protection databases should be
enabled

System and SI-2 Flaw Remediation SQL databases 4.0.0

Information Integrity should have
vulnerability findings
resolved

System and SI-4 Information System Azure Defender for 2.0.1

Information Integrity Monitoring SQL should be
enabled for
unprotected Azure
SQL servers

System and SI-4 Information System Azure Defender for 1.0.2

Information Integrity Monitoring SQL should be
enabled for
unprotected SQL
Managed Instances

HIPAA HITRUST 9.2

To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - HIPAA HITRUST 9.2. For more information about this compliance
standard, see HIPAA HITRUST 9.2.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Segregation in 0805.01m1Organizat The organization's SQL Server should 1.0.0

Networks ional.12 - 01.m security gateways use a virtual network
(e.g. firewalls) enforce service endpoint
security policies and
are configured to
filter traffic between
domains, block
unauthorized access,
and are used to
maintain segregation
between internal
wired, internal
wireless, and external
network segments
(e.g., the Internet)
including DMZs and
enforce access
control policies for
each of the domains.

Segregation in 0806.01m2Organizat The organizations SQL Server should 1.0.0

Networks ional.12356 - 01.m network is logically use a virtual network
and physically service endpoint
segmented with a
defined security
perimeter and a
graduated set of
controls, including
subnetworks for
publicly accessible
system components
that are logically
separated from the
internal network,
based on
organizational
requirements; and
traffic is controlled
based on
functionality required
and classification of
the data/systems
based on a risk
assessment and their
respective security
requirements.

Segregation in 0894.01m2Organizat Networks are SQL Server should 1.0.0

Networks ional.7 - 01.m segregated from use a virtual network
production-level service endpoint
networks when
migrating physical
servers, applications
or data to virtualized
servers.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Audit Logging 1211.09aa3System.4 The organization Auditing on SQL 2.0.0

- 09.aa verifies every ninety server should be
(90) days for each enabled
extract of covered
information recorded
that the data is
erased or its use is
still required.

Back-up 1616.09l1Organizati Backup copies of Long-term geo- 2.0.0

onal.16 - 09.l information and redundant backup
software are made should be enabled
and tests of the for Azure SQL
media and Databases
restoration
procedures are
regularly performed
at appropriate
intervals.

Back-up 1621.09l2Organizati Automated tools are Long-term geo- 2.0.0

onal.1 - 09.l used to track all redundant backup
backups. should be enabled
for Azure SQL
Databases

Network Controls 0862.09m2Organizat The organization SQL Server should 1.0.0

ional.8 - 09.m ensures information use a virtual network
systems protect the service endpoint
confidentiality and
integrity of
transmitted
information,
including during
preparation for
transmission and
during reception.

Management of 0301.09o1Organizati The organization, Transparent Data 2.0.0

Removable Media onal.123 - 09.o based on the data Encryption on SQL
classification level, databases should be
registers media enabled
(including laptops)
prior to use, places
reasonable
restrictions on how
such media be used,
and provides an
appropriate level of
physical and logical
protection (including
encryption) for media
containing covered
information until
properly destroyed
or sanitized.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Management of 0304.09o3Organizati The organization SQL managed 1.0.2

Removable Media onal.1 - 09.o restricts the use of instances should use
writable removable customer-managed
media and keys to encrypt data
personally-owned at rest
removable media in
organizational
systems.

Management of 0304.09o3Organizati The organization SQL servers should 2.0.1

Removable Media onal.1 - 09.o restricts the use of use customer-
writable removable managed keys to
media and encrypt data at rest
personally-owned
removable media in
organizational
systems.

Control of Technical 0709.10m1Organizat Technical SQL databases 4.0.0

Vulnerabilities ional.1 - 10.m vulnerabilities are should have
identified, evaluated vulnerability findings
for risk and corrected resolved
in a timely manner.

Control of Technical 0709.10m1Organizat Technical Vulnerability 1.0.1

Vulnerabilities ional.1 - 10.m vulnerabilities are assessment should
identified, evaluated be enabled on SQL
for risk and corrected Managed Instance
in a timely manner.

Control of Technical 0709.10m1Organizat Technical Vulnerability 2.0.0

Vulnerabilities ional.1 - 10.m vulnerabilities are assessment should
identified, evaluated be enabled on your
for risk and corrected SQL servers
in a timely manner.

Control of Technical 0710.10m2Organizat A hardened Vulnerability 1.0.1

Vulnerabilities ional.1 - 10.m configuration assessment should
standard exists for all be enabled on SQL
system and network Managed Instance
components.

Control of Technical 0716.10m3Organizat The organization SQL databases 4.0.0

Vulnerabilities ional.1 - 10.m conducts an should have
enterprise security vulnerability findings
posture review as resolved
needed but no less
than once within
every three-
hundred-sixty-five
(365) days, in
accordance with
organizational IS
procedures.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Control of Technical 0719.10m3Organizat The organization Vulnerability 1.0.1

Vulnerabilities ional.5 - 10.m updates the list of assessment should
information system be enabled on SQL
vulnerabilities Managed Instance
scanned within every
thirty (30) days or
when new
vulnerabilities are
identified and
reported.

IRS 1075 September 2016

To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - IRS 1075 September 2016. For more information about this compliance
standard, see IRS 1075 September 2016.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Access Control 9.3.1.2 Account An Azure Active 1.0.0

Management (AC-2) Directory
administrator should
be provisioned for
SQL servers

Awareness and 9.3.3.5 Response to Audit Auditing on SQL 2.0.0

Training Processing Failures server should be
(AU-5) enabled

Awareness and 9.3.3.5 Response to Audit Azure Defender for 2.0.1

Training Processing Failures SQL should be
(AU-5) enabled for
unprotected Azure
SQL servers

Awareness and 9.3.3.5 Response to Audit Azure Defender for 1.0.2

Training Processing Failures SQL should be
(AU-5) enabled for
unprotected SQL
Managed Instances

Awareness and 9.3.3.11 Audit Generation Auditing on SQL 2.0.0

Training (AU-12) server should be
enabled

Awareness and 9.3.3.11 Audit Generation Azure Defender for 2.0.1

Training (AU-12) SQL should be
enabled for
unprotected Azure
SQL servers
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Awareness and 9.3.3.11 Audit Generation Azure Defender for 1.0.2

Training (AU-12) SQL should be
enabled for
unprotected SQL
Managed Instances

Risk Assessment 9.3.14.3 Vulnerability Azure Defender for 2.0.1

Scanning (RA-5) SQL should be
enabled for
unprotected Azure
SQL servers

Risk Assessment 9.3.14.3 Vulnerability Azure Defender for 1.0.2

Scanning (RA-5) SQL should be
enabled for
unprotected SQL
Managed Instances

Risk Assessment 9.3.14.3 Vulnerability SQL databases 4.0.0

Scanning (RA-5) should have
vulnerability findings
resolved

System and 9.3.16.15 Protection of Azure Defender for 2.0.1

Communications Information at Rest SQL should be
Protection (SC-28) enabled for
unprotected Azure
SQL servers

System and 9.3.16.15 Protection of Azure Defender for 1.0.2

Communications Information at Rest SQL should be
Protection (SC-28) enabled for
unprotected SQL
Managed Instances

System and 9.3.16.15 Protection of Transparent Data 2.0.0

Communications Information at Rest Encryption on SQL
Protection (SC-28) databases should be
enabled

System and 9.3.17.2 Flaw Remediation (SI- SQL databases 4.0.0

Information Integrity 2) should have
vulnerability findings
resolved

System and 9.3.17.4 Information System Azure Defender for 2.0.1

Information Integrity Monitoring (SI-4) SQL should be
enabled for
unprotected Azure
SQL servers

System and 9.3.17.4 Information System Azure Defender for 1.0.2

Information Integrity Monitoring (SI-4) SQL should be
enabled for
unprotected SQL
Managed Instances
ISO 27001:2013
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - ISO 27001:2013. For more information about this compliance standard,
see ISO 27001:2013.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Asset management 8.2.1 Classification of SQL databases 4.0.0

information should have
vulnerability findings
resolved

Access control 9.2.3 Management of An Azure Active 1.0.0

privileged access Directory
rights administrator should
be provisioned for
SQL servers

Cryptography 10.1.1 Policy on the use of Transparent Data 2.0.0

cryptographic Encryption on SQL
controls databases should be
enabled

Cryptography 10.1.1 Policy on the use of Transparent Data 2.0.0

cryptographic Encryption on SQL
controls databases should be
enabled

Operations security 12.4.1 Event Logging Auditing on SQL 2.0.0

server should be
enabled

Operations security 12.4.1 Event Logging Auditing on SQL 2.0.0

server should be
enabled

Operations security 12.4.3 Administrator and Auditing on SQL 2.0.0

operator logs server should be
enabled

Operations security 12.4.3 Administrator and Auditing on SQL 2.0.0

operator logs server should be
enabled

Operations security 12.4.4 Clock Auditing on SQL 2.0.0

Synchronization server should be
enabled

Operations security 12.4.4 Clock Auditing on SQL 2.0.0

Synchronization server should be
enabled

Operations security 12.6.1 Management of SQL databases 4.0.0

technical should have
vulnerabilities vulnerability findings
resolved
New Zealand ISM Restricted
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - New Zealand ISM Restricted. For more information about this compliance
standard, see New Zealand ISM Restricted.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Information security ISM-3 6.2.5 Conducting Vulnerability 1.0.1

monitoring vulnerability assessment should
assessments be enabled on SQL
Managed Instance

Information security ISM-3 6.2.5 Conducting Vulnerability 2.0.0

monitoring vulnerability assessment should
assessments be enabled on your
SQL servers

Information security ISM-4 6.2.6 Resolving SQL databases 4.0.0

monitoring vulnerabilities should have
vulnerability findings
resolved

Information security ISM-4 6.2.6 Resolving Vulnerability 2.0.0

monitoring vulnerabilities Assessment settings
for SQL server
should contain an
email address to
receive scan reports

Infrastructure INF-9 10.8.35 Security Private endpoint 1.1.0

Architecture connections on Azure
SQL Database should
be enabled

Access Control and AC-11 16.4.30 Privileged An Azure Active 1.0.0

Passwords Access Management Directory
administrator should
be provisioned for
SQL servers

Access Control and AC-17 16.6.9 Events to be Auditing on SQL 2.0.0

Passwords logged server should be
enabled

Cryptography CR-3 17.1.46 Reducing SQL managed 1.0.2

storage and physical instances should use
transfer requirements customer-managed
keys to encrypt data
at rest

Cryptography CR-3 17.1.46 Reducing SQL servers should 2.0.1

storage and physical use customer-
transfer requirements managed keys to
encrypt data at rest
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Cryptography CR-3 17.1.46 Reducing Transparent Data 2.0.0

storage and physical Encryption on SQL
transfer requirements databases should be
enabled

Gateway security GS-2 19.1.11 Using Public network access 1.1.0

Gateways on Azure SQL
Database should be
disabled

Data management DM-6 20.4.4 Database files Azure Defender for 2.0.1
SQL should be
enabled for
unprotected Azure
SQL servers

Data management DM-6 20.4.4 Database files Azure Defender for 1.0.2
SQL should be
enabled for
unprotected SQL
Managed Instances

NIST SP 800-171 R2
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - NIST SP 800-171 R2. For more information about this compliance
standard, see NIST SP 800-171 R2.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Audit and 3.3.1 Create and retain Auditing on SQL 2.0.0

Accountability system audit logs server should be
and records to the enabled
extent needed to
enable the
monitoring, analysis,
investigation, and
reporting of unlawful
or unauthorized
system activity.

Audit and 3.3.1 Create and retain Azure Defender for 2.0.1
Accountability system audit logs SQL should be
and records to the enabled for
extent needed to unprotected Azure
enable the SQL servers
monitoring, analysis,
investigation, and
reporting of unlawful
or unauthorized
system activity.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Audit and 3.3.1 Create and retain Azure Defender for 1.0.2
Accountability system audit logs SQL should be
and records to the enabled for
extent needed to unprotected SQL
enable the Managed Instances
monitoring, analysis,
investigation, and
reporting of unlawful
or unauthorized
system activity.

Audit and 3.3.2 Ensure that the Auditing on SQL 2.0.0

Accountability actions of individual server should be
system users can be enabled
uniquely traced to
those users, so they
can be held
accountable for their
actions.

Audit and 3.3.2 Ensure that the Azure Defender for 2.0.1
Accountability actions of individual SQL should be
system users can be enabled for
uniquely traced to unprotected Azure
those users, so they SQL servers
can be held
accountable for their
actions.

Audit and 3.3.2 Ensure that the Azure Defender for 1.0.2
Accountability actions of individual SQL should be
system users can be enabled for
uniquely traced to unprotected SQL
those users, so they Managed Instances
can be held
accountable for their
actions.

Audit and 3.3.4 Alert in the event of Auditing on SQL 2.0.0

Accountability an audit logging server should be
process failure. enabled

Audit and 3.3.4 Alert in the event of Azure Defender for 2.0.1
Accountability an audit logging SQL should be
process failure. enabled for
unprotected Azure
SQL servers

Audit and 3.3.4 Alert in the event of Azure Defender for 1.0.2
Accountability an audit logging SQL should be
process failure. enabled for
unprotected SQL
Managed Instances
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Risk Assessment 3.11.2 Scan for Azure Defender for 2.0.1

vulnerabilities in SQL should be
organizational enabled for
systems and unprotected Azure
applications SQL servers
periodically and when
new vulnerabilities
affecting those
systems and
applications are
identified.

Risk Assessment 3.11.2 Scan for Azure Defender for 1.0.2

vulnerabilities in SQL should be
organizational enabled for
systems and unprotected SQL
applications Managed Instances
periodically and when
new vulnerabilities
affecting those
systems and
applications are
identified.

Risk Assessment 3.11.2 Scan for SQL databases 4.0.0

vulnerabilities in should have
organizational vulnerability findings
systems and resolved
applications
periodically and when
new vulnerabilities
affecting those
systems and
applications are
identified.

System and 3.13.16 Protect the Azure Defender for 2.0.1

Communications confidentiality of CUI SQL should be
Protection at rest. enabled for
unprotected Azure
SQL servers

System and 3.13.16 Protect the Azure Defender for 1.0.2

Communications confidentiality of CUI SQL should be
Protection at rest. enabled for
unprotected SQL
Managed Instances

System and 3.13.16 Protect the Transparent Data 2.0.0

Communications confidentiality of CUI Encryption on SQL
Protection at rest. databases should be
enabled

System and 3.14.1 Identify, report, and SQL databases 4.0.0

Information Integrity correct system flaws should have
in a timely manner. vulnerability findings
resolved
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

System and 3.14.6 Monitor Azure Defender for 2.0.1

Information Integrity organizational SQL should be
systems, including enabled for
inbound and unprotected Azure
outbound SQL servers
communications
traffic, to detect
attacks and
indicators of
potential attacks.

System and 3.14.6 Monitor Azure Defender for 1.0.2

Information Integrity organizational SQL should be
systems, including enabled for
inbound and unprotected SQL
outbound Managed Instances
communications
traffic, to detect
attacks and
indicators of
potential attacks.

NIST SP 800-53 Rev. 4

To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - NIST SP 800-53 Rev. 4. For more information about this compliance
standard, see NIST SP 800-53 Rev. 4.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Access Control AC-2 Account An Azure Active 1.0.0

Management Directory
administrator should
be provisioned for
SQL servers

Access Control AC-2 (1) Automated System An Azure Active 1.0.0

Account Directory
Management administrator should
be provisioned for
SQL servers

Access Control AC-2 (7) Role-based Schemes An Azure Active 1.0.0

Directory
administrator should
be provisioned for
SQL servers

Access Control AC-2 (12) Account Monitoring / Azure Defender for 1.0.2
Atypical Usage SQL should be
enabled for
unprotected SQL
Managed Instances
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Access Control AC-3 Access Enforcement An Azure Active 1.0.0

Directory
administrator should
be provisioned for
SQL servers

Access Control AC-4 Information Flow Private endpoint 1.1.0

Enforcement connections on Azure
SQL Database should
be enabled

Access Control AC-4 Information Flow Public network access 1.1.0

Enforcement on Azure SQL
Database should be
disabled

Access Control AC-16 Security Attributes Azure Defender for 2.0.1

SQL should be
enabled for
unprotected Azure
SQL servers

Access Control AC-16 Security Attributes Azure Defender for 1.0.2

SQL should be
enabled for
unprotected SQL
Managed Instances

Access Control AC-17 Remote Access Private endpoint 1.1.0

connections on Azure
SQL Database should
be enabled

Access Control AC-17 (1) Automated Private endpoint 1.1.0

Monitoring / Control connections on Azure
SQL Database should
be enabled

Audit and AU-6 Audit Review, Azure Defender for 2.0.1

Accountability Analysis, and SQL should be
Reporting enabled for
unprotected Azure
SQL servers

Audit and AU-6 Audit Review, Azure Defender for 1.0.2

Accountability Analysis, and SQL should be
Reporting enabled for
unprotected SQL
Managed Instances

Audit and AU-6 (4) Central Review and Auditing on SQL 2.0.0
Accountability Analysis server should be
enabled
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Audit and AU-6 (4) Central Review and Azure Defender for 2.0.1
Accountability Analysis SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-6 (4) Central Review and Azure Defender for 1.0.2
Accountability Analysis SQL should be
enabled for
unprotected SQL
Managed Instances

Audit and AU-6 (5) Integration / Auditing on SQL 2.0.0

Accountability Scanning and server should be
Monitoring enabled
Capabilities

Audit and AU-6 (5) Integration / Azure Defender for 2.0.1

Accountability Scanning and SQL should be
Monitoring enabled for
Capabilities unprotected Azure
SQL servers

Audit and AU-6 (5) Integration / Azure Defender for 1.0.2

Accountability Scanning and SQL should be
Monitoring enabled for
Capabilities unprotected SQL
Managed Instances

Audit and AU-11 Audit Record SQL servers with 3.0.0

Accountability Retention auditing to storage
account destination
should be configured
with 90 days
retention or higher

Audit and AU-12 Audit Generation Auditing on SQL 2.0.0

Accountability server should be
enabled

Audit and AU-12 Audit Generation Azure Defender for 2.0.1

Accountability SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-12 Audit Generation Azure Defender for 1.0.2

Accountability SQL should be
enabled for
unprotected SQL
Managed Instances

Audit and AU-12 (1) System-wide / Time- Auditing on SQL 2.0.0

Accountability correlated Audit Trail server should be
enabled
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Audit and AU-12 (1) System-wide / Time- Azure Defender for 2.0.1
Accountability correlated Audit Trail SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-12 (1) System-wide / Time- Azure Defender for 1.0.2
Accountability correlated Audit Trail SQL should be
enabled for
unprotected SQL
Managed Instances

Contingency CP-6 Alternate Storage Site Long-term geo- 2.0.0

Planning redundant backup
should be enabled
for Azure SQL
Databases

Contingency CP-6 (1) Separation from Long-term geo- 2.0.0

Planning Primary Site redundant backup
should be enabled
for Azure SQL
Databases

Identification and IA-2 Identification and An Azure Active 1.0.0

Authentication Authentication Directory
(organizational Users) administrator should
be provisioned for
SQL servers

Identification and IA-4 Identifier An Azure Active 1.0.0

Authentication Management Directory
administrator should
be provisioned for
SQL servers

Incident Response IR-4 Incident Handling Azure Defender for 2.0.1

SQL should be
enabled for
unprotected Azure
SQL servers

Incident Response IR-4 Incident Handling Azure Defender for 1.0.2

SQL should be
enabled for
unprotected SQL
Managed Instances

Incident Response IR-5 Incident Monitoring Azure Defender for 2.0.1

SQL should be
enabled for
unprotected Azure
SQL servers
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Incident Response IR-5 Incident Monitoring Azure Defender for 1.0.2

SQL should be
enabled for
unprotected SQL
Managed Instances

Risk Assessment RA-5 Vulnerability Azure Defender for 2.0.1

Scanning SQL should be
enabled for
unprotected Azure
SQL servers

Risk Assessment RA-5 Vulnerability Azure Defender for 1.0.2

Scanning SQL should be
enabled for
unprotected SQL
Managed Instances

Risk Assessment RA-5 Vulnerability SQL databases 4.0.0

Scanning should have
vulnerability findings
resolved

Risk Assessment RA-5 Vulnerability Vulnerability 1.0.1

Scanning assessment should
be enabled on SQL
Managed Instance

Risk Assessment RA-5 Vulnerability Vulnerability 2.0.0

Scanning assessment should
be enabled on your
SQL servers

System and SC-7 Boundary Protection Private endpoint 1.1.0

Communications connections on Azure
Protection SQL Database should
be enabled

System and SC-7 Boundary Protection Public network access 1.1.0

Communications on Azure SQL
Protection Database should be
disabled

System and SC-7 (3) Access Points Private endpoint 1.1.0

Communications connections on Azure
Protection SQL Database should
be enabled

System and SC-7 (3) Access Points Public network access 1.1.0
Communications on Azure SQL
Protection Database should be
disabled
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

System and SC-12 Cryptographic Key SQL managed 1.0.2

Communications Establishment and instances should use
Protection Management customer-managed
keys to encrypt data
at rest

System and SC-12 Cryptographic Key SQL servers should 2.0.1

Communications Establishment and use customer-
Protection Management managed keys to
encrypt data at rest

System and SC-28 Protection of Sensitive data in your 3.0.0-preview

Communications Information at Rest SQL databases
Protection should be classified

System and SC-28 Protection of Transparent Data 2.0.0

Communications Information at Rest Encryption on SQL
Protection databases should be
enabled

System and SC-28 (1) Cryptographic Sensitive data in your 3.0.0-preview

Communications Protection SQL databases
Protection should be classified

System and SC-28 (1) Cryptographic Transparent Data 2.0.0

Communications Protection Encryption on SQL
Protection databases should be
enabled

System and SI-2 Flaw Remediation SQL databases 4.0.0

Information Integrity should have
vulnerability findings
resolved

System and SI-4 Information System Azure Defender for 2.0.1

Information Integrity Monitoring SQL should be
enabled for
unprotected Azure
SQL servers

System and SI-4 Information System Azure Defender for 1.0.2

Information Integrity Monitoring SQL should be
enabled for
unprotected SQL
Managed Instances

NIST SP 800-53 Rev. 5

To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - NIST SP 800-53 Rev. 5. For more information about this compliance
standard, see NIST SP 800-53 Rev. 5.
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Access Control AC-2 Account An Azure Active 1.0.0

Management Directory
administrator should
be provisioned for
SQL servers

Access Control AC-2 (1) Automated System An Azure Active 1.0.0

Account Directory
Management administrator should
be provisioned for
SQL servers

Access Control AC-2 (7) Privileged User An Azure Active 1.0.0

Accounts Directory
administrator should
be provisioned for
SQL servers

Access Control AC-2 (12) Account Monitoring Azure Defender for 1.0.2
for Atypical Usage SQL should be
enabled for
unprotected SQL
Managed Instances

Access Control AC-3 Access Enforcement An Azure Active 1.0.0

Directory
administrator should
be provisioned for
SQL servers

Access Control AC-4 Information Flow Private endpoint 1.1.0

Enforcement connections on Azure
SQL Database should
be enabled

Access Control AC-4 Information Flow Public network access 1.1.0

Enforcement on Azure SQL
Database should be
disabled

Access Control AC-16 Security and Privacy Azure Defender for 2.0.1
Attributes SQL should be
enabled for
unprotected Azure
SQL servers

Access Control AC-16 Security and Privacy Azure Defender for 1.0.2
Attributes SQL should be
enabled for
unprotected SQL
Managed Instances

Access Control AC-17 Remote Access Private endpoint 1.1.0

connections on Azure
SQL Database should
be enabled
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Access Control AC-17 (1) Monitoring and Private endpoint 1.1.0

Control connections on Azure
SQL Database should
be enabled

Audit and AU-6 Audit Record Review, Azure Defender for 2.0.1
Accountability Analysis, and SQL should be
Reporting enabled for
unprotected Azure
SQL servers

Audit and AU-6 Audit Record Review, Azure Defender for 1.0.2
Accountability Analysis, and SQL should be
Reporting enabled for
unprotected SQL
Managed Instances

Audit and AU-6 (4) Central Review and Auditing on SQL 2.0.0
Accountability Analysis server should be
enabled

Audit and AU-6 (4) Central Review and Azure Defender for 2.0.1
Accountability Analysis SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-6 (4) Central Review and Azure Defender for 1.0.2
Accountability Analysis SQL should be
enabled for
unprotected SQL
Managed Instances

Audit and AU-6 (5) Integrated Analysis Auditing on SQL 2.0.0

Accountability of Audit Records server should be
enabled

Audit and AU-6 (5) Integrated Analysis Azure Defender for 2.0.1
Accountability of Audit Records SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-6 (5) Integrated Analysis Azure Defender for 1.0.2
Accountability of Audit Records SQL should be
enabled for
unprotected SQL
Managed Instances

Audit and AU-11 Audit Record SQL servers with 3.0.0

Accountability Retention auditing to storage
account destination
should be configured
with 90 days
retention or higher
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Audit and AU-12 Audit Record Auditing on SQL 2.0.0

Accountability Generation server should be
enabled

Audit and AU-12 Audit Record Azure Defender for 2.0.1

Accountability Generation SQL should be
enabled for
unprotected Azure
SQL servers

Audit and AU-12 Audit Record Azure Defender for 1.0.2

Accountability Generation SQL should be
enabled for
unprotected SQL
Managed Instances

Audit and AU-12 (1) System-wide and Auditing on SQL 2.0.0

Accountability Time-correlated server should be
Audit Trail enabled

Audit and AU-12 (1) System-wide and Azure Defender for 2.0.1
Accountability Time-correlated SQL should be
Audit Trail enabled for
unprotected Azure
SQL servers

Audit and AU-12 (1) System-wide and Azure Defender for 1.0.2
Accountability Time-correlated SQL should be
Audit Trail enabled for
unprotected SQL
Managed Instances

Contingency CP-6 Alternate Storage Site Long-term geo- 2.0.0

Planning redundant backup
should be enabled
for Azure SQL
Databases

Contingency CP-6 (1) Separation from Long-term geo- 2.0.0

Planning Primary Site redundant backup
should be enabled
for Azure SQL
Databases

Identification and IA-2 Identification and An Azure Active 1.0.0

Authentication Authentication Directory
(organizational Users) administrator should
be provisioned for
SQL servers

Identification and IA-4 Identifier An Azure Active 1.0.0

Authentication Management Directory
administrator should
be provisioned for
SQL servers
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Incident Response IR-4 Incident Handling Azure Defender for 2.0.1

SQL should be
enabled for
unprotected Azure
SQL servers

Incident Response IR-4 Incident Handling Azure Defender for 1.0.2

SQL should be
enabled for
unprotected SQL
Managed Instances

Incident Response IR-5 Incident Monitoring Azure Defender for 2.0.1

SQL should be
enabled for
unprotected Azure
SQL servers

Incident Response IR-5 Incident Monitoring Azure Defender for 1.0.2

SQL should be
enabled for
unprotected SQL
Managed Instances

Risk Assessment RA-5 Vulnerability Azure Defender for 2.0.1

Monitoring and SQL should be
Scanning enabled for
unprotected Azure
SQL servers

Risk Assessment RA-5 Vulnerability Azure Defender for 1.0.2

Monitoring and SQL should be
Scanning enabled for
unprotected SQL
Managed Instances

Risk Assessment RA-5 Vulnerability SQL databases 4.0.0

Monitoring and should have
Scanning vulnerability findings
resolved

Risk Assessment RA-5 Vulnerability Vulnerability 1.0.1

Monitoring and assessment should
Scanning be enabled on SQL
Managed Instance

Risk Assessment RA-5 Vulnerability Vulnerability 2.0.0

Monitoring and assessment should
Scanning be enabled on your
SQL servers

System and SC-7 Boundary Protection Private endpoint 1.1.0

Communications connections on Azure
Protection SQL Database should
be enabled
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

System and SC-7 Boundary Protection Public network access 1.1.0

Communications on Azure SQL
Protection Database should be
disabled

System and SC-7 (3) Access Points Private endpoint 1.1.0

Communications connections on Azure
Protection SQL Database should
be enabled

System and SC-7 (3) Access Points Public network access 1.1.0
Communications on Azure SQL
Protection Database should be
disabled

System and SC-12 Cryptographic Key SQL managed 1.0.2

Communications Establishment and instances should use
Protection Management customer-managed
keys to encrypt data
at rest

System and SC-12 Cryptographic Key SQL servers should 2.0.1

Communications Establishment and use customer-
Protection Management managed keys to
encrypt data at rest

System and SC-28 Protection of Sensitive data in your 3.0.0-preview

Communications Information at Rest SQL databases
Protection should be classified

System and SC-28 Protection of Transparent Data 2.0.0

Communications Information at Rest Encryption on SQL
Protection databases should be
enabled

System and SC-28 (1) Cryptographic Sensitive data in your 3.0.0-preview

Communications Protection SQL databases
Protection should be classified

System and SC-28 (1) Cryptographic Transparent Data 2.0.0

Communications Protection Encryption on SQL
Protection databases should be
enabled

System and SI-2 Flaw Remediation SQL databases 4.0.0

Information Integrity should have
vulnerability findings
resolved

System and SI-4 System Monitoring Azure Defender for 2.0.1

Information Integrity SQL should be
enabled for
unprotected Azure
SQL servers
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

System and SI-4 System Monitoring Azure Defender for 1.0.2

Information Integrity SQL should be
enabled for
unprotected SQL
Managed Instances

UK OFFICIAL and UK NHS

To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see
Azure Policy Regulatory Compliance - UK OFFICIAL and UK NHS. For more information about this compliance
standard, see UK OFFICIAL.

P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E ( A ZURE PO RTA L) ( GIT HUB)

Asset protection and 2.3 Data at rest Transparent Data 2.0.0

resilience protection Encryption on SQL
databases should be
enabled

Operational security 5.2 Vulnerability Azure Defender for 2.0.1

management SQL should be
enabled for
unprotected Azure
SQL servers

Operational security 5.2 Vulnerability Azure Defender for 1.0.2

management SQL should be
enabled for
unprotected SQL
Managed Instances

Operational security 5.2 Vulnerability SQL databases 4.0.0

management should have
vulnerability findings
resolved

Operational security 5.2 Vulnerability Vulnerability 1.0.1

management assessment should
be enabled on SQL
Managed Instance

Operational security 5.2 Vulnerability Vulnerability 2.0.0

management assessment should
be enabled on your
SQL servers

Identity and 10 Identity and An Azure Active 1.0.0

authentication authentication Directory
administrator should
be provisioned for
SQL servers
 P O L IC Y P O L IC Y VERSIO N
DO M A IN C O N T RO L ID C O N T RO L T IT L E

Audit information for 13 Audit information for Auditing on SQL 2.0.0

users users server should be
enabled

Audit information for 13 Audit information for Azure Defender for 2.0.1
users users SQL should be
enabled for
unprotected Azure
SQL servers

Next steps
Learn more about Azure Policy Regulatory Compliance.
See the built-ins on the Azure Policy GitHub repo.
 Microsoft Defender for SQL
12/6/2021 • 3 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
Microsoft Defender for SQL is a unified package for advanced SQL security capabilities. Microsoft Defender for
Cloud is available for Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics. It
includes functionality for surfacing and mitigating potential database vulnerabilities, and detecting anomalous
activities that could indicate a threat to your database. It provides a single go-to location for enabling and
managing these capabilities.

What are the benefits of Microsoft Defender for SQL?

Microsoft Defender for Cloud provides a set of advanced SQL security capabilities, including SQL Vulnerability
Assessment and Advanced Threat Protection.
Vulnerability Assessment is an easy-to-configure service that can discover, track, and help you remediate
potential database vulnerabilities. It provides visibility into your security state, and it includes actionable steps
to resolve security issues and enhance your database fortifications.
Advanced Threat Protection detects anomalous activities indicating unusual and potentially harmful attempts
to access or exploit your database. It continuously monitors your database for suspicious activities, and it
provides immediate security alerts on potential vulnerabilities, Azure SQL injection attacks, and anomalous
database access patterns. Advanced Threat Protection alerts provide details of the suspicious activity and
recommend action on how to investigate and mitigate the threat.
Enable Microsoft Defender for SQL once to enable all these included features. With one click, you can enable
Microsoft Defender for all databases on your server in Azure or in your SQL Managed Instance. Enabling or
managing Microsoft Defender for Cloud settings requires belonging to the SQL security manager role, or one of
the database or server admin roles.
For more information about Microsoft Defender for SQL pricing, see the Microsoft Defender for Cloud pricing
page.

Enable Microsoft Defender for Cloud

There are multiple ways to enable Microsoft Defender plans. You can enable it at the subscription level
(recommended ) from:
Microsoft Defender for Cloud
Enable Defender plans programmatically with the REST API, Azure CLI, PowerShell, or Azure Policy
Alternatively, you can enable it at the resource level as described in Enable Microsoft Defender for Azure SQL
Database at the resource level
Enable Microsoft Defender for Azure SQL Database at the subscription level from Microsoft Defender for
Cloud
To enable Microsoft Defender for Azure SQL Database at the subscription level from within Microsoft Defender
for Cloud:
1. From the Azure portal, open Defender for Cloud .
2. From Defender for Cloud's menu, select Pricing and settings .
3. Select the relevant subscription.
4. Change the plan setting to On .

5. Select Save .
Enable Microsoft Defender plans programatically
The flexibility of Azure allows for a number of programmatic methods for enabling Microsoft Defender plans.
Use any of the following tools to enable Microsoft Defender for your subscription:

M ET H O D IN ST RUC T IO N S

REST API Pricings API

Azure CLI az security pricing

PowerShell Set-AzSecurityPricing

Azure Policy Bundle Pricings

Enable Microsoft Defender for Azure SQL Database at the resource level
We recommend enabling Microsoft Defender plans at the subscription level and this can help the creation of
protected resources. However, if you have an organizational reason to enable Microsoft Defender for Cloud at
the server level, use the following steps:
1. From the Azure portal, open your server or managed instance.
2. Under the Security heading, select Defender for Cloud .
3. Select Enable Microsoft Defender for SQL .
 NOTE
A storage account is automatically created and configured to store your Vulnerability Assessment scan results. If
you've already enabled Microsoft Defender for another server in the same resource group and region, then the existing
storage account is used.
The cost of Microsoft Defender for SQL is aligned with Microsoft Defender for Cloud standard tier pricing per node, where
a node is the entire server or managed instance. You are thus paying only once for protecting all databases on the server
or managed instance with Microsoft Defender for Cloud. You can evaluate Microsoft Defender for Cloud via a free trial.

Manage Microsoft Defender for Cloud settings

To view and manage Microsoft Defender for Cloud settings:
1. From the Security area of your server or managed instance, select Defender for Cloud .
On this page, you'll see the status of Microsoft Defender for SQL:
2. If Microsoft Defender for SQL is enabled, you'll see a Configure link as shown in the previous graphic. To
edit the settings for Microsoft Defender for SQL, select Configure .

3. Make the necessary changes and select Save .

Next steps
Learn more about Vulnerability Assessment
Learn more about Advanced Threat Protection
Learn more about Microsoft Defender for Cloud
 SQL Advanced Threat Protection
12/6/2021 • 2 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
SQL Server on Azure VM Azure Arc-enabled SQL Server
Advanced Threat Protection for Azure SQL Database, Azure SQL Managed Instance, Azure Synapse Analytics,
SQL Server on Azure Virtual Machines and Azure Arc-enabled SQL Server detects anomalous activities
indicating unusual and potentially harmful attempts to access or exploit databases.
Advanced Threat Protection is part of the Microsoft Defender for SQL offering, which is a unified package for
advanced SQL security capabilities. Advanced Threat Protection can be accessed and managed via the central
Microsoft Defender for SQL portal.

Overview
Advanced Threat Protection provides a new layer of security, which enables customers to detect and respond to
potential threats as they occur by providing security alerts on anomalous activities. Users receive an alert upon
suspicious database activities, potential vulnerabilities, and SQL injection attacks, as well as anomalous database
access and queries patterns. Advanced Threat Protection integrates alerts with Microsoft Defender for Cloud,
which include details of suspicious activity and recommend action on how to investigate and mitigate the threat.
Advanced Threat Protection makes it simple to address potential threats to the database without the need to be
a security expert or manage advanced security monitoring systems.
For a full investigation experience, it is recommended to enable auditing, which writes database events to an
audit log in your Azure storage account. To enable auditing, see Auditing for Azure SQL Database and Azure
Synapse or Auditing for Azure SQL Managed Instance.

Alerts
Advanced Threat Protection detects anomalous activities indicating unusual and potentially harmful attempts to
access or exploit databases. For a list of alerts, see the Alerts for SQL Database and Azure Synapse Analytics in
Microsoft Defender for Cloud.

Explore detection of a suspicious event

You receive an email notification upon detection of anomalous database activities. The email provides
information on the suspicious security event including the nature of the anomalous activities, database name,
server name, application name, and the event time. In addition, the email provides information on possible
causes and recommended actions to investigate and mitigate the potential threat to the database.
1. Click the View recent SQL aler ts link in the email to launch the Azure portal and show the Microsoft
Defender for Cloud alerts page, which provides an overview of active threats detected on the database.

2. Click a specific alert to get additional details and actions for investigating this threat and remediating
future threats.
For example, SQL injection is one of the most common Web application security issues on the Internet
that is used to attack data-driven applications. Attackers take advantage of application vulnerabilities to
 inject malicious SQL statements into application entry fields, breaching or modifying data in the
database. For SQL Injection alerts, the alert’s details include the vulnerable SQL statement that was
exploited.

Explore alerts in the Azure portal

Advanced Threat Protection integrates its alerts with Microsoft Defender for Cloud. Live SQL Advanced Threat
Protection tiles within the database and SQL Microsoft Defender for Cloud blades in the Azure portal track the
status of active threats.
Click Advanced Threat Protection aler t to launch the Microsoft Defender for Cloud alerts page and get an
overview of active SQL threats detected on the database.
Next steps
Learn more about Advanced Threat Protection in Azure SQL Database & Azure Synapse.
Learn more about Advanced Threat Protection in Azure SQL Managed Instance.
Learn more about Microsoft Defender for SQL.
Learn more about Azure SQL Database auditing
Learn more about Microsoft Defender for Cloud For more information on pricing, see the Azure SQL
Database pricing page
 Data Discovery & Classification
12/6/2021 • 7 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
Data Discovery & Classification is built into Azure SQL Database, Azure SQL Managed Instance, and Azure
Synapse Analytics. It provides basic capabilities for discovering, classifying, labeling, and reporting the sensitive
data in your databases.
Your most sensitive data might include business, financial, healthcare, or personal information. It can serve as
infrastructure for:
Helping to meet standards for data privacy and requirements for regulatory compliance.
Various security scenarios, such as monitoring (auditing) access to sensitive data.
Controlling access to and hardening the security of databases that contain highly sensitive data.

NOTE
For information about SQL Server on-premises, see SQL Data Discovery & Classification.

What is Data Discovery & Classification?

Data Discovery & Classification currently supports the following capabilities:
Discover y and recommendations: The classification engine scans your database and identifies
columns that contain potentially sensitive data. It then provides you with an easy way to review and apply
recommended classification via the Azure portal.
Labeling: You can apply sensitivity-classification labels persistently to columns by using new metadata
attributes that have been added to the SQL Server database engine. This metadata can then be used for
sensitivity-based auditing scenarios.
Quer y result-set sensitivity: The sensitivity of a query result set is calculated in real time for auditing
purposes.
Visibility: You can view the database-classification state in a detailed dashboard in the Azure portal. Also,
you can download a report in Excel format to use for compliance and auditing purposes and other needs.

Discover, classify, and label sensitive columns

This section describes the steps for:
Discovering, classifying, and labeling columns that contain sensitive data in your database.
Viewing the current classification state of your database and exporting reports.
The classification includes two metadata attributes:
Labels : The main classification attributes, used to define the sensitivity level of the data stored in the column.
Information types : Attributes that provide more granular information about the type of data stored in the
column.
Define and customize your classification taxonomy
Data Discovery & Classification comes with a built-in set of sensitivity labels and a built-in set of information
types and discovery logic. You can customize this taxonomy and define a set and ranking of classification
constructs specifically for your environment.
You define and customize of your classification taxonomy in one central place for your entire Azure organization.
That location is in Microsoft Defender for Cloud, as part of your security policy. Only someone with
administrative rights on the organization's root management group can do this task.
As part of policy management, you can define custom labels, rank them, and associate them with a selected set
of information types. You can also add your own custom information types and configure them with string
patterns. The patterns are added to the discovery logic for identifying this type of data in your databases.
For more information, see Customize the SQL information protection policy in Microsoft Defender for Cloud
(Preview).
After the organization-wide policy has been defined, you can continue classifying individual databases by using
your customized policy.
Classify your database

NOTE
The below example uses Azure SQL Database, but you should select the appropriate product that you want to configure
Data Discovery & Classification.

1. Go to the Azure portal.

2. Go to Data Discover y & Classification under the Security heading in your Azure SQL Database pane.
The Overview tab includes a summary of the current classification state of the database. The summary
includes a detailed list of all classified columns, which you can also filter to show only specific schema
parts, information types, and labels. If you haven’t classified any columns yet, skip to step 4.

3. To download a report in Excel format, select Expor t in the top menu of the pane.
4. To begin classifying your data, select the Classification tab on the Data Discover y & Classification
page.
The classification engine scans your database for columns containing potentially sensitive data and
provides a list of recommended column classifications.
5. View and apply classification recommendations:
 To view the list of recommended column classifications, select the recommendations panel at the
bottom of the pane.
To accept a recommendation for a specific column, select the check box in the left column of the
relevant row. To mark all recommendations as accepted, select the leftmost check box in the
recommendations table header.
To apply the selected recommendations, select Accept selected recommendations .

6. You can also classify columns manually, as an alternative or in addition to the recommendation-based
classification:
a. Select Add classification in the top menu of the pane.
b. In the context window that opens, select the schema, table, and column that you want to classify,
and the information type and sensitivity label.
c. Select Add classification at the bottom of the context window.

7. To complete your classification and persistently label (tag) the database columns with the new
 classification metadata, select Save in the Classification page.

Audit access to sensitive data

An important aspect of the classification is the ability to monitor access to sensitive data. Azure SQL Auditing
has been enhanced to include a new field in the audit log called data_sensitivity_information . This field logs
the sensitivity classifications (labels) of the data that was returned by a query. Here's an example:

These are the activites that are actually auditable with sensitivity information:
ALTER TABLE ... DROP COLUMN
BULK INSERT
DELETE
INSERT
MERGE
UPDATE
UPDATETEXT
WRITETEXT
DROP TABLE
BACKUP
DBCC CloneDatabase
SELECT INTO
INSERT INTO EXEC
TRUNCATE TABLE
DBCC SHOW_STATISTICS
sys.dm_db_stats_histogram
Use sys.fn_get_audit_file to returns information from an audit file stored in an Azure Storage account.

Permissions
These built-in roles can read the data classification of a database:
Owner
Reader
Contributor
SQL Security Manager
User Access Administrator
These are the required actions to read the data classification of a database are:
Microsoft.Sql/servers/databases/currentSensitivityLabels/*
Microsoft.Sql/servers/databases/recommendedSensitivityLabels/*
Microsoft.Sql/servers/databases/schemas/tables/columns/sensitivityLabels/*
These built-in roles can modify the data classification of a database:
Owner
 Contributor
SQL Security Manager
This is the required action to modify the data classification of a database are:
Microsoft.Sql/servers/databases/schemas/tables/columns/sensitivityLabels/*
Learn more about role-based permissions in Azure RBAC.

Manage classifications
You can use T-SQL, a REST API, or PowerShell to manage classifications.
Use T -SQL
You can use T-SQL to add or remove column classifications, and to retrieve all classifications for the entire
database.

NOTE
When you use T-SQL to manage labels, there's no validation that labels that you add to a column exist in the
organization's information-protection policy (the set of labels that appear in the portal recommendations). So, it's up to
you to validate this.

For information about using T-SQL for classifications, see the following references:
To add or update the classification of one or more columns: ADD SENSITIVITY CLASSIFICATION
To remove the classification from one or more columns: DROP SENSITIVITY CLASSIFICATION
To view all classifications on the database: sys.sensitivity_classifications
Use PowerShell cmdlets
Manage classifications and recommendations for Azure SQL Database and Azure SQL Managed Instance using
PowerShell.
PowerShell cmdlets for Azure SQL Database
Get-AzSqlDatabaseSensitivityClassification
Set-AzSqlDatabaseSensitivityClassification
Remove-AzSqlDatabaseSensitivityClassification
Get-AzSqlDatabaseSensitivityRecommendation
Enable-AzSqlDatabaSesensitivityRecommendation
Disable-AzSqlDatabaseSensitivityRecommendation
PowerShell cmdlets for Azure SQL Managed Instance
Get-AzSqlInstanceDatabaseSensitivityClassification
Set-AzSqlInstanceDatabaseSensitivityClassification
Remove-AzSqlInstanceDatabaseSensitivityClassification
Get-AzSqlInstanceDatabaseSensitivityRecommendation
Enable-AzSqlInstanceDatabaseSensitivityRecommendation
Disable-AzSqlInstanceDatabaseSensitivityRecommendation
Use the Rest API
You can use the REST API to programmatically manage classifications and recommendations. The published
REST API supports the following operations:
Create Or Update: Creates or updates the sensitivity label of the specified column.
 Delete: Deletes the sensitivity label of the specified column.
Disable Recommendation: Disables sensitivity recommendations on the specified column.
Enable Recommendation: Enables sensitivity recommendations on the specified column. (Recommendations
are enabled by default on all columns.)
Get: Gets the sensitivity label of the specified column.
List Current By Database: Gets the current sensitivity labels of the specified database.
List Recommended By Database: Gets the recommended sensitivity labels of the specified database.

Retrieve classifications metadata using SQL drivers

You can use the following SQL drivers to retrieve classification metadata:
ODBC Driver
OLE DB Driver
JDBC Driver
Microsoft Drivers for PHP for SQL Server

FAQ - Advanced classification capabilities

Question : Will Azure Purview replace SQL Data Discovery & Classification or will SQL Data Discovery &
Classification be retired soon? Answer : We continue to support SQL Data Discovery & Classification and
encourage you to adopt Azure Purview which has richer capabilities to drive advanced classification capabilities
and data governance. If we decide to retire any service, feature, API or SKU, you will receive advance notice
including a migration or transition path. Learn more about Microsoft Lifecycle policies here.

Next steps
Consider configuring Azure SQL Auditing for monitoring and auditing access to your classified sensitive data.
For a presentation that includes data Discovery & Classification, see Discovering, classifying, labeling &
protecting SQL data | Data Exposed.
To classify your Azure SQL Databases and Azure Synapse Analytics with Azure Purview labels using T-SQL
commands, see Classify your Azure SQL data using Azure Purview labels.
 Dynamic data masking
12/6/2021 • 4 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics support dynamic data
masking. Dynamic data masking limits sensitive data exposure by masking it to non-privileged users.
Dynamic data masking helps prevent unauthorized access to sensitive data by enabling customers to designate
how much of the sensitive data to reveal with minimal impact on the application layer. It’s a policy-based
security feature that hides the sensitive data in the result set of a query over designated database fields, while
the data in the database is not changed.
For example, a service representative at a call center might identify a caller by confirming several characters of
their email address, but the complete email address shouldn't be revealed to the service representative. A
masking rule can be defined that masks all the email address in the result set of any query. As another example,
an appropriate data mask can be defined to protect personal data, so that a developer can query production
environments for troubleshooting purposes without violating compliance regulations.

Dynamic data masking basics

You set up a dynamic data masking policy in the Azure portal by selecting the Dynamic Data Masking blade
under Security in your SQL Database configuration pane. This feature cannot be set using portal for SQL
Managed Instance. For more information, see Dynamic Data Masking.
Dynamic data masking policy
SQL users excluded from masking - A set of SQL users or Azure AD identities that get unmasked data in
the SQL query results. Users with administrator privileges are always excluded from masking, and see the
original data without any mask.
Masking rules - A set of rules that define the designated fields to be masked and the masking function that
is used. The designated fields can be defined using a database schema name, table name, and column name.
Masking functions - A set of methods that control the exposure of data for different scenarios.

M A SK IN G F UN C T IO N M A SK IN G LO GIC

Default Full masking according to the data types of the

designated fields

• Use XXXX or fewer Xs if the size of the field is less than 4

characters for string data types (nchar, ntext, nvarchar).
• Use a zero value for numeric data types (bigint, bit,
decimal, int, money, numeric, smallint, smallmoney, tinyint,
float, real).
• Use 01-01-1900 for date/time data types (date, datetime2,
datetime, datetimeoffset, smalldatetime, time).
• For SQL variant, the default value of the current type is
used.
• For XML the document <masked/> is used.
• Use an empty value for special data types (timestamp
table, hierarchyid, GUID, binary, image, varbinary spatial
types).
 M A SK IN G F UN C T IO N M A SK IN G LO GIC

Credit card Masking method, which exposes the last four digits
of the designated fields and adds a constant string as a
prefix in the form of a credit card.

XXXX-XXXX-XXXX-1234

Email Masking method, which exposes the first letter and

replaces the domain with XXX.com using a constant
string prefix in the form of an email address.

[email protected]

Random number Masking method, which generates a random number

according to the selected boundaries and actual data types.
If the designated boundaries are equal, then the masking
function is a constant number.

Custom text Masking method, which exposes the first and last
characters and adds a custom padding string in the middle.
If the original string is shorter than the exposed prefix and
suffix, only the padding string is used.
prefix[padding]suffix

Recommended fields to mask

The DDM recommendations engine, flags certain fields from your database as potentially sensitive fields, which
may be good candidates for masking. In the Dynamic Data Masking blade in the portal, you will see the
recommended columns for your database. All you need to do is click Add Mask for one or more columns and
then Save to apply a mask for these fields.

Manage dynamic data masking using T-SQL

To create a dynamic data mask, see Creating a Dynamic Data Mask.
To add or edit a mask on an existing column, see Adding or Editing a Mask on an Existing Column.
To grant permissions to view unmasked data, see Granting Permissions to View Unmasked Data.
To drop a dynamic data mask, see Dropping a Dynamic Data Mask.

Set up dynamic data masking for your database using PowerShell

cmdlets
Data masking policies
Get-AzSqlDatabaseDataMaskingPolicy
 Set-AzSqlDatabaseDataMaskingPolicy
Data masking rules
Get-AzSqlDatabaseDataMaskingRule
New-AzSqlDatabaseDataMaskingRule
Remove-AzSqlDatabaseDataMaskingRule
Set-AzSqlDatabaseDataMaskingRule

Set up dynamic data masking for your database using the REST API
You can use the REST API to programmatically manage data masking policy and rules. The published REST API
supports the following operations:
Data masking policies
Create Or Update: Creates or updates a database data masking policy.
Get: Gets a database data masking policy.
Data masking rules
Create Or Update: Creates or updates a database data masking rule.
List By Database: Gets a list of database data masking rules.

Permissions
These are the built-in roles to configure dynamic data masking is:
SQL Security Manager
SQL DB Contributor
SQL Server Contributor
These are the required actions to use dynamic data masking:
Read/Write:
Microsoft.Sql/servers/databases/dataMaskingPolicies/* Read:
Microsoft.Sql/servers/databases/dataMaskingPolicies/read Write:
Microsoft.Sql/servers/databases/dataMaskingPolicies/write
To learn more about permissions when using dynamic data masking with T-SQL command, see Permissions

See also
Dynamic Data Masking for SQL Server.
Data Exposed episode about Granular Permissions for Azure SQL Dynamic Data Masking on Channel 9.
 SQL vulnerability assessment helps you identify
database vulnerabilities
12/6/2021 • 10 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
SQL vulnerability assessment is an easy-to-configure service that can discover, track, and help you remediate
potential database vulnerabilities. Use it to proactively improve your database security.
Vulnerability assessment is part of the Microsoft Defender for SQL offering, which is a unified package for
advanced SQL security capabilities. Vulnerability assessment can be accessed and managed via the central
Microsoft Defender for SQL portal.

NOTE
Vulnerability assessment is supported for Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse
Analytics. Databases in Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics are referred to
collectively in the remainder of this article as databases, and the server is referring to the server that hosts databases for
Azure SQL Database and Azure Synapse.

What is SQL vulnerability assessment?

SQL vulnerability assessment is a service that provides visibility into your security state. Vulnerability
assessment includes actionable steps to resolve security issues and enhance your database security. It can help
you to monitor a dynamic database environment where changes are difficult to track and improve your SQL
security posture.
Vulnerability assessment is a scanning service built into Azure SQL Database. The service employs a knowledge
base of rules that flag security vulnerabilities. It highlights deviations from best practices, such as
misconfigurations, excessive permissions, and unprotected sensitive data.
The rules are based on Microsoft's best practices and focus on the security issues that present the biggest risks
to your database and its valuable data. They cover database-level issues and server-level security issues, like
server firewall settings and server-level permissions.
Results of the scan include actionable steps to resolve each issue and provide customized remediation scripts
where applicable. You can customize an assessment report for your environment by setting an acceptable
baseline for:
Permission configurations
Feature configurations
Database settings

Configure vulnerability assessment

Take the following steps to configure the vulnerability assessment:
1. In the Azure portal, open the specific resource in Azure SQL Database, SQL Managed Instance Database,
or Azure Synapse.
2. Under the Security heading, select Defender for Cloud .
3. Select Configure on the link to open the Microsoft Defender for SQL settings pane for either the entire
server or managed instance.

NOTE
SQL vulnerability assessment requires Microsoft Defender for SQL plan to be able to run scans. For more
information about how to enable Microsoft Defender for SQL, see Microsoft Defender for SQL.

4. In the Ser ver settings page, define the Microsoft Defender for SQL settings:

a. Configure a storage account where your scan results for all databases on the server or managed
 instance will be stored. For information about storage accounts, see About Azure storage accounts.

TIP
For more information about storing vulnerability assessment scans behind firewalls and VNets, see Store
vulnerability assessment scan results in a storage account accessible behind firewalls and VNets.

b. To configure vulnerability assessments to automatically run weekly scans to detect security

misconfigurations, set Periodic recurring scans to On . The results are sent to the email
addresses you provide in Send scan repor ts to . You can also send email notification to admins
and subscription owners by enabling Also send email notification to admins and
subscription owners .
5. SQL vulnerability assessment scans can also be run on-demand:
a. From the resource's Defender for Cloud page, select View additional findings in
Vulnerability Assessment to access the scan results from previous scans.

b. To run an on-demand scan to scan your database for vulnerabilities, select Scan from the toolbar:
 NOTE
The scan is lightweight and safe. It takes a few seconds to run and is entirely read-only. It doesn't make any changes to
your database.

Remediate vulnerabilities
When a vulnerability scan completes, the report is displayed in the Azure portal. The report presents:
An overview of your security state
The number of issues that were found, and
A summary by severity of the risks
A list of the findings for further investigations

To remediate the vulnerabilities discovered:

1. Review your results and determine which of the report's findings are true security issues for your
environment.
2. Select each failed result to understand its impact and why the security check failed.

TIP
The findings details page includes actionable remediation information explaining how to resolve the issue.
3. As you review your assessment results, you can mark specific results as being an acceptable baseline in
your environment. A baseline is essentially a customization of how the results are reported. In
subsequent scans, results that match the baseline are considered as passes. After you've established your
baseline security state, vulnerability assessment only reports on deviations from the baseline. In this way,
you can focus your attention on the relevant issues.

4. If you change the baselines, use the Scan button to run an on-demand scan and view the customized
report. Any findings you've added to the baseline will now appear in Passed with an indication that
they've passed because of the baseline changes.
Your vulnerability assessment scans can now be used to ensure that your database maintains a high level of
security, and that your organizational policies are met.

Advanced capabilities
Export an assessment report
Select Expor t Scan Results to create a downloadable Excel report of your scan result. This report contains a
summary tab that displays a summary of the assessment. The report includes all failed checks. It also includes a
Results tab that contains the full set of results from the scan. The results include all checks that were run and
the result details for each.
View scan history
Select Scan Histor y in the vulnerability assessment pane to view a history of all scans previously run on this
database. Select a particular scan in the list to view the detailed results of that scan.
Disable specific findings from Microsoft Defender for Cloud (preview)
If you have an organizational need to ignore a finding, rather than remediate it, you can optionally disable it.
Disabled findings don't impact your secure score or generate unwanted noise.
When a finding matches the criteria you've defined in your disable rules, it won't appear in the list of findings.
Typical scenarios include:
Disable findings with severity below medium
Disable findings that are non-patchable
Disable findings from benchmarks that aren't of interest for a defined scope

IMPORTANT
To disable specific findings, you need permissions to edit a policy in Azure Policy. Learn more in Azure RBAC permissions in
Azure Policy.

To create a rule:
1. From the recommendations detail page for Vulnerability assessment findings on your SQL
ser vers on machines should be remediated , select Disable rule .
2. Select the relevant scope.
3. Define your criteria. You can use any of the following criteria:
 Finding ID
Severity
Benchmarks

4. Select Apply rule . Changes might take up to 24hrs to take effect.

5. To view, override, or delete a rule:
a. Select Disable rule .
b. From the scope list, subscriptions with active rules show as Rule applied .

c. To view or delete the rule, select the ellipsis menu ("...").

Manage vulnerability assessments programmatically

Azure PowerShell
Azure CLI
 NOTE
This article uses the Azure Az PowerShell module, which is the recommended PowerShell module for interacting with
Azure. To get started with the Az PowerShell module, see Install Azure PowerShell. To learn how to migrate to the Az
PowerShell module, see Migrate Azure PowerShell from AzureRM to Az.

IMPORTANT
The PowerShell Azure Resource Manager module is still supported, but all future development is for the Az.Sql module.
For these cmdlets, see AzureRM.Sql. The arguments for the commands in the Az module and in the AzureRm modules are
substantially identical.

You can use Azure PowerShell cmdlets to programmatically manage your vulnerability assessments. The
supported cmdlets are:

C M DL ET N A M E A S A L IN K DESC RIP T IO N

Clear-AzSqlDatabaseVulnerabilityAssessmentRuleBaseline Clears the vulnerability assessment rule baseline.

First, set the baseline before you use this cmdlet to clear it.

Clear-AzSqlDatabaseVulnerabilityAssessmentSetting Clears the vulnerability assessment settings of a database.

Clear- Clears the vulnerability assessment rule baseline of a

AzSqlInstanceDatabaseVulnerabilityAssessmentRuleBaseline managed database.
First, set the baseline before you use this cmdlet to clear it.

Clear-AzSqlInstanceDatabaseVulnerabilityAssessmentSetting Clears the vulnerability assessment settings of a managed

database.

Clear-AzSqlInstanceVulnerabilityAssessmentSetting Clears the vulnerability assessment settings of a managed

instance.

Convert-AzSqlDatabaseVulnerabilityAssessmentScan Converts vulnerability assessment scan results of a database

to an Excel file.

Convert-AzSqlInstanceDatabaseVulnerabilityAssessmentScan Converts vulnerability assessment scan results of a managed

database to an Excel file.

Get-AzSqlDatabaseVulnerabilityAssessmentRuleBaseline Gets the vulnerability assessment rule baseline of a database

for a given rule.

Get- Gets the vulnerability assessment rule baseline of a managed

AzSqlInstanceDatabaseVulnerabilityAssessmentRuleBaseline database for a given rule.

Get-AzSqlDatabaseVulnerabilityAssessmentScanRecord Gets all vulnerability assessment scan records associated

with a given database.

Get- Gets all vulnerability assessment scan records associated

AzSqlInstanceDatabaseVulnerabilityAssessmentScanRecord with a given managed database.

Get-AzSqlDatabaseVulnerabilityAssessmentSetting Returns the vulnerability assessment settings of a database.

Get-AzSqlInstanceDatabaseVulnerabilityAssessmentSetting Returns the vulnerability assessment settings of a managed

database.
 C M DL ET N A M E A S A L IN K DESC RIP T IO N

Set-AzSqlDatabaseVulnerabilityAssessmentRuleBaseline Sets the vulnerability assessment rule baseline.

Set- Sets the vulnerability assessment rule baseline for a

AzSqlInstanceDatabaseVulnerabilityAssessmentRuleBaseline managed database.

Start-AzSqlDatabaseVulnerabilityAssessmentScan Triggers the start of a vulnerability assessment scan on a

database.

Start-AzSqlInstanceDatabaseVulnerabilityAssessmentScan Triggers the start of a vulnerability assessment scan on a

managed database.

Update-AzSqlDatabaseVulnerabilityAssessmentSetting Updates the vulnerability assessment settings of a database.

Update- Updates the vulnerability assessment settings of a managed

AzSqlInstanceDatabaseVulnerabilityAssessmentSetting database.

Update-AzSqlInstanceVulnerabilityAssessmentSetting Updates the vulnerability assessment settings of a managed

instance.

For a script example, see Azure SQL vulnerability assessment PowerShell support.
Using Resource Manager templates
To configure vulnerability assessment baselines by using Azure Resource Manager templates, use the
Microsoft.Sql/servers/databases/vulnerabilityAssessments/rules/baselines type.

Ensure that you have enabled vulnerabilityAssessments before you add baselines.
Here's an example for defining Baseline Rule VA2065 to master database and VA1143 to user database as
resources in a Resource Manager template:
 "resources": [
{
"type": "Microsoft.Sql/servers/databases/vulnerabilityAssessments/rules/baselines",
"apiVersion": "2018-06-01-preview",
"name": "[concat(parameters('server_name'),'/', parameters('database_name') ,
'/default/VA2065/master')]",
"properties": {
"baselineResults": [
{
"result": [
"FirewallRuleName3",
"StartIpAddress",
"EndIpAddress"
]
},
{
"result": [
"FirewallRuleName4",
"62.92.15.68",
"62.92.15.68"
]
}
]
},
"type": "Microsoft.Sql/servers/databases/vulnerabilityAssessments/rules/baselines",
"apiVersion": "2018-06-01-preview",
"name": "[concat(parameters('server_name'),'/', parameters('database_name'),
'/default/VA2130/Default')]",
"dependsOn": [
"[resourceId('Microsoft.Sql/servers/vulnerabilityAssessments', parameters('server_name'),
'Default')]"
],
"properties": {
"baselineResults": [
{
"result": [
"dbo"
]
}
]
}
}
]

For master database and user database, the resource names are defined differently:
Master database - "name": "[concat(parameters('server_name'),'/', parameters('database_name') ,
'/default/VA2065/master ')]",
User database - "name": "[concat(parameters('server_name'),'/', parameters('database_name') ,
'/default/VA2065/default ')]",
To handle Boolean types as true/false, set the baseline result with binary input like "1"/"0".
 {
"type": "Microsoft.Sql/servers/databases/vulnerabilityAssessments/rules/baselines",
"apiVersion": "2018-06-01-preview",
"name": "[concat(parameters('server_name'),'/', parameters('database_name'),
'/default/VA1143/Default')]",

"dependsOn": [
"[resourceId('Microsoft.Sql/servers/vulnerabilityAssessments', parameters('server_name'),
'Default')]"
],

"properties": {
"baselineResults": [
{
"result": [
"1"
]
}
]
}

Permissions
One of the following permissions is required to see vulnerability assessment results in the Microsoft Defender
for Cloud recommendation SQL databases should have vulnerability findings resolved :
Security Admin
Security Reader
The following permissions are required to changes vulnerability assessment settings:
SQL Security Manager
Storage Blob Data Reader
Owner role on the storage account
The following permissions are required to open links in email notifications about scan results or to view scan
results at the resource-level:
SQL Security Manager
Storage Blob Data Reader

Data residency
SQL Vulnerability Assessment queries the SQL server using publicly available queries under Defender for Cloud
recommendations for SQL Vulnerability Assessment, and stores the query results. The data is stored in the
configured user-owned storage account.
SQL Vulnerability Assessment allows you to specify the region where your data will be stored by choosing the
location of the storage account. The user is responsible for the security and data resiliency of the storage
account.

Next steps
Learn more about Microsoft Defender for SQL.
Learn more about data discovery and classification.
Learn more about Storing vulnerability assessment scan results in a storage account accessible behind
firewalls and VNets.
 SQL Vulnerability Assessment rules reference guide
12/6/2021 • 32 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
SQL Server (all supported versions)
This article lists the set of built-in rules that are used to flag security vulnerabilities and highlight deviations from
best practices, such as misconfigurations, excessive permissions, and unprotected sensitive data. The rules are
based on Microsoft's best practices and focus on the security issues that present the biggest risks to your
database and its valuable data. They cover both database-level issues as well as server-level security issues, like
server firewall settings and server-level permissions. These rules also represent many of the requirements from
various regulatory bodies to meet their compliance standards.
The rules shown in your database scans depend on the SQL version and platform that was scanned.
To learn about how to implement Vulnerability Assessment in Azure, see Implement Vulnerability Assessment.
For a list of changes to these rules, see SQL Vulnerability Assessment rules changelog.

Rule categories
SQL Vulnerability Assessment rules have five categories, which are in the following sections:
Authentication and Authorization
Auditing and Logging
Data Protection
Installation Updates and Patches
Surface Area Reduction
1 SQL Ser ver 2012+ refers to all versions of SQL Server 2012 and above.
2 SQL Ser ver 2017+ refers to all versions of SQL Server 2017 and above.
3 SQL Ser ver 2016+ refers to all versions of SQL Server 2016 and above.

Authentication and Authorization

RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1017 Execute permissions High The xp_cmdshell SQL Server 2012+1

on xp_cmdshell from extended stored
all users (except dbo) procedure spawns a
should be revoked Windows command
shell, passing in a
string for execution.
This rule checks that
no users (other than
users with the
CONTROL SERVER
permission like
members of the
sysadmin server role)
have permission to
execute the
xp_cmdshell
extended stored
procedure.

VA1020 Database user GUEST High The guest user SQL Server 2012+
should not be a permits access to a
member of any role database for any SQL Database
logins that are not
mapped to a specific
database user. This
rule checks that no
database roles are
assigned to the
Guest user.

VA1042 Database ownership High Cross database SQL Server 2012+

chaining should be ownership chaining is
disabled for all an extension of SQL Managed
databases except for ownership chaining, Instance
master , msdb , and except it does cross
tempdb the database
boundary. This rule
checks that this
option is disabled for
all databases except
for master , msdb ,
and tempdb . For
master , msdb , and
tempdb , cross
database ownership
chaining is enabled
by default.

VA1043 Principal GUEST Medium The guest user SQL Server 2012+
should not have permits access to a
access to any user database for any SQL Managed
database logins that are not Instance
mapped to a specific
database user. This
rule checks that the
guest user cannot
connect to any
database.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1046 CHECK_POLICY Low CHECK_POLICY SQL Server 2012+

should be enabled option enables
for all SQL logins verifying SQL logins SQL Managed
against the domain Instance
policy. This rule
checks that
CHECK_POLICY
option is enabled for
all SQL logins.

VA1047 Password expiration Low Password expiration SQL Server 2012+

check should be policies are used to
enabled for all SQL manage the lifespan SQL Managed
logins of a password. When Instance
SQL Server enforces
password expiration
policy, users are
reminded to change
old passwords, and
accounts that have
expired passwords
are disabled. This rule
checks that password
expiration policy is
enabled for all SQL
logins.

VA1048 Database principals High A database principal SQL Server 2012+

should not be that is mapped to
mapped to the sa the sa account can SQL Managed
account be exploited by an Instance
attacker to elevate
permissions to
sysadmin

VA1052 Remove Low The SQL Server 2012+

BUILTIN\Administrat BUILTIN\Administrat
ors as a server login ors group contains
the Windows Local
Administrators
group. In older
versions of Microsoft
SQL Server this
group has
administrator rights
by default. This rule
checks that this
group is removed
from SQL Server.

VA1053 Account with default Low sa is a well-known SQL Server 2012+

name sa should be account with
renamed or disabled principal ID 1. This SQL Managed
rule verifies that the Instance
sa account is either
renamed or disabled.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1054 Excessive permissions Low Every SQL Server SQL Server 2012+
should not be login belongs to the
granted to PUBLIC public server role. SQL Database
role on objects or When a server
columns principal has not
been granted or
denied specific
permissions on a
securable object the
user inherits the
permissions granted
to public on that
object. This rule
displays a list of all
securable objects or
columns that are
accessible to all users
through the PUBLIC
role.

VA1058 sa login should be High sa is a well-known SQL Server 2012+

disabled account with
principal ID 1. This SQL Managed
rule verifies that the Instance
sa account is
disabled.

VA1059 xp_cmdshell should High xp_cmdshell spawns SQL Server 2012+

be disabled a Windows command
shell and passes it a SQL Managed
string for execution. Instance
This rule checks that
xp_cmdshell is
disabled.

VA1067 Database Mail XPs Medium This rule checks that SQL Server 2012+
should be disabled Database Mail is
when it is not in use disabled when no
database mail profile
is configured.
Database Mail can be
used for sending e-
mail messages from
the SQL Server
Database Engine and
is disabled by default.
If you are not using
this feature, it is
recommended to
disable it to reduce
the surface area.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1068 Server permissions Low Server level SQL Server 2012+

shouldn't be granted permissions are
directly to principals associated with a SQL Managed
server level object to Instance
regulate which users
can gain access to
the object. This rule
checks that there are
no server level
permissions granted
directly to logins.

VA1070 Database users Low Database users may SQL Server 2012+
shouldn't share the share the same name
same name as a as a server login. This SQL Managed
server login rule validates that Instance
there are no such
users.

VA1072 Authentication mode Medium There are two SQL Server 2012+
should be Windows possible
Authentication authentication
modes: Windows
Authentication mode
and mixed mode.
Mixed mode means
that SQL Server
enables both
Windows
authentication and
SQL Server
authentication. This
rule checks that the
authentication mode
is set to Windows
Authentication.

VA1094 Database Low Permissions are rules SQL Server 2012+

permissions shouldn't associated with a
be granted directly to securable object to SQL Managed
principals regulate which users Instance
can gain access to
the object. This rule
checks that there are
no DB permissions
granted directly to
users.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1095 Excessive permissions Medium Every SQL Server SQL Server 2012+
should not be login belongs to the
granted to PUBLIC public server role. SQL Managed
role When a server Instance
principal has not
been granted or SQL Database
denied specific
permissions on a
securable object the
user inherits the
permissions granted
to public on that
object. This displays a
list of all permissions
that are granted to
the PUBLIC role.

VA1096 Principal GUEST Low Each database SQL Server 2012+

should not be includes a user called
granted permissions GUEST. Permissions SQL Managed
in the database granted to GUEST Instance
are inherited by users
who have access to SQL Database
the database but
who do not have a
user account in the
database. This rule
checks that all
permissions have
been revoked from
the GUEST user.

VA1097 Principal GUEST Low Each database SQL Server 2012+

should not be includes a user called
granted permissions GUEST. Permissions SQL Managed
on objects or granted to GUEST Instance
columns are inherited by users
who have access to SQL Database
the database but
who do not have a
user account in the
database. This rule
checks that all
permissions have
been revoked from
the GUEST user.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1099 GUEST user should Low Each database SQL Server 2012+
not be granted includes a user called
permissions on GUEST. Permissions SQL Managed
database securables granted to GUEST Instance
are inherited by users
who have access to SQL Database
the database but
who do not have a
user account in the
database. This rule
checks that all
permissions have
been revoked from
the GUEST user.

VA1246 Application roles Low An application role is SQL Server 2012+

should not be used a database principal
that enables an SQL Managed
application to run Instance
with its own user-like
permissions. SQL Database
Application roles
enable that only
users connecting
through a particular
application can
access specific data.
Application roles are
password-based
(which applications
typically hardcode)
and not permission
based which exposes
the database to app
role impersonation
by password-
guessing. This rule
checks that no
application roles are
defined in the
database.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1248 User-defined Medium To easily manage the SQL Server 2012+

database roles permissions in your
should not be databases SQL SQL Managed
members of fixed Server provides Instance
roles several roles, which
are security principals SQL Database
that group other
principals. They are Azure Synapse
like groups in the
Microsoft Windows
operating system.
Database accounts
and other SQL Server
roles can be added
into database-level
roles. Each member
of a fixed-database
role can add other
users to that same
role. This rule checks
that no user-defined
roles are members of
fixed roles.

VA1267 Contained users Medium Contained users are SQL Server 2012+
should use Windows users that exist
Authentication within the database SQL Managed
and do not require a Instance
login mapping. This
rule checks that
contained users use
Windows
Authentication.

VA1280 Server Permissions Medium Every SQL Server SQL Server 2012+
granted to public login belongs to the
should be minimized public server role. SQL Managed
When a server Instance
principal has not
been granted or
denied specific
permissions on a
securable object the
user inherits the
permissions granted
to public on that
object. This rule
checks that server
permissions granted
to public are
minimized.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1282 Orphan roles should Low Orphan roles are SQL Server 2012+
be removed user-defined roles
that have no SQL Managed
members. Eliminate Instance
orphaned roles as
they are not needed SQL Database
on the system. This
rule checks whether Azure Synapse
there are any orphan
roles.

VA2020 Minimal set of High Every SQL Server SQL Server 2012+
principals should be securable has
granted ALTER or permissions SQL Managed
ALTER ANY USER associated with it Instance
database-scoped that can be granted
permissions to principals. SQL Database
Permissions can be
scoped at the server Azure Synapse
level (assigned to
logins and server
roles) or at the
database level
(assigned to
database users and
database roles).
These rules check
that only a minimal
set of principals are
granted ALTER or
ALTER ANY USER
database-scoped
permissions.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2033 Minimal set of Low This rule checks SQL Server 2012+
principals should be which principals are
granted database- granted EXECUTE SQL Managed
scoped EXECUTE permission on Instance
permission on objects or columns to
objects or columns ensure this SQL Database
permission is granted
to a minimal set of Azure Synapse
principals. Every SQL
Server securable has
permissions
associated with it
that can be granted
to principals.
Permissions can be
scoped at the server
level (assigned to
logins and server
roles) or at the
database level
(assigned to
database users,
database roles, or
application roles). The
EXECUTE permission
applies to both
stored procedures
and scalar functions,
which can be used in
computed columns.

VA2103 Unnecessary execute Medium Extended stored SQL Server 2012+

permissions on procedures are DLLs
extended stored that an instance of SQL Managed
procedures should be SQL Server can Instance
revoked dynamically load and
run. SQL Server is
packaged with many
extended stored
procedures that allow
for interaction with
the system DLLs. This
rule checks that
unnecessary execute
permissions on
extended stored
procedures have
been revoked.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2107 Minimal set of High SQL Database SQL Database

principals should be provides two
members of fixed restricted Azure Synapse
Azure SQL DB master administrative roles
database roles in the master
database to which
user accounts can be
added that grant
permissions to either
create databases or
manage logins. This
rule check that a
minimal set of
principals are
members of these
administrative roles.

VA2108 Minimal set of High SQL Server provides SQL Server 2012+
principals should be roles to help manage
members of fixed the permissions. SQL Managed
high impact database Roles are security Instance
roles principals that group
other principals. SQL Database
Database-level roles
are database-wide in Azure Synapse
their permission
scope. This rule
checks that a minimal
set of principals are
members of the fixed
database roles.

VA2109 Minimal set of Low SQL Server provides SQL Server 2012+
principals should be roles to help manage
members of fixed low the permissions. SQL Managed
impact database Roles are security Instance
roles principals that group
other principals. SQL Database
Database-level roles
are database-wide in Azure Synapse
their permission
scope. This rule
checks that a minimal
set of principals are
members of the fixed
database roles.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2110 Execute permissions High Registry extended SQL Server 2012+

to access the registry stored procedures
should be revoked allow Microsoft SQL SQL Managed
Server to read write Instance
and enumerate
values and keys in
the registry. They are
used by Enterprise
Manager to
configure the server.
This rule checks that
the permissions to
execute registry
extended stored
procedures have
been revoked from
all users (other than
dbo).

VA2113 Data Transformation Medium Data Transformation SQL Server 2012+

Services (DTS) Services (DTS), is a
permissions should set of objects and SQL Managed
only be granted to utilities that allow the Instance
SSIS roles automation of
extract, transform,
and load operations
to or from a
database. The objects
are DTS packages
and their
components, and the
utilities are called DTS
tools. This rule checks
that only the SSIS
roles are granted
permissions to use
the DTS system
stored procedures
and the permissions
for the PUBLIC role
to use the DTS
system stored
procedures have
been revoked.

VA2114 Minimal set of High SQL Server provides SQL Server 2012+
principals should be roles to help manage
members of high permissions. Roles SQL Managed
impact fixed server are security principals Instance
roles that group other
principals. Server-
level roles are server-
wide in their
permission scope.
This rule checks that
a minimal set of
principals are
members of the fixed
server roles.
 RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2129 Changes to signed High You can sign a stored SQL Server 2012+
modules should be procedure, function,
authorized or trigger with a SQL Database
certificate or an
asymmetric key. This SQL Managed
is designed for Instance
scenarios when
permissions cannot
be inherited through
ownership chaining
or when the
ownership chain is
broken, such as
dynamic SQL. This
rule checks for
changes made to
signed modules,
which could be an
indication of
malicious use.

VA2130 Track all users with Low This check tracks all SQL Database
access to the users with access to a
database database. Make sure Azure Synapse
that these users are
authorized according
to their current role
in the organization.

Auditing and Logging

RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1045 Default trace should Medium Default trace SQL Server 2012+
be enabled provides
troubleshooting SQL Managed
assistance to Instance
database
administrators by
ensuring that they
have the log data
necessary to
diagnose problems
the first time they
occur. This rule
checks that the
default trace is
enabled.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1091 Auditing of both Low SQL Server Login SQL Server 2012+
successful and failed auditing
login attempts configuration enables
(default trace) should administrators to
be enabled when track the users
'Login auditing' is set logging into SQL
up to track logins Server instances. If
the user chooses to
count on 'Login
auditing' to track
users logging into
SQL Server instances,
then it is important
to enable it for both
successful and failed
login attempts.

VA1093 Maximum number of Low Each SQL Server SQL Server 2012+
error logs should be Error log will have all
12 or more the information
related to failures /
errors that have
occurred since SQL
Server was last
restarted or since the
last time you have
recycled the error
logs. This rule checks
that the maximum
number of error logs
is 12 or more.

VA1258 Database owners are High Database owners can SQL Server 2016+3
as expected perform all
configuration and SQL Database
maintenance
activities on the Azure Synapse
database and can
also drop databases
in SQL Server.
Tracking database
owners is important
to avoid having
excessive permission
for some principals.
Create a baseline
that defines the
expected database
owners for the
database. This rule
checks whether the
database owners are
as defined in the
baseline.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1264 Auditing of both Low SQL Server auditing SQL Server 2012+
successful and failed configuration enables
login attempts administrators to SQL Managed
should be enabled track the users Instance
logging into SQL
Server instances that
they're responsible
for. This rule checks
that auditing is
enabled for both
successful and failed
login attempts.

VA1265 Auditing of both Medium SQL Server auditing SQL Server 2012+
successful and failed configuration enables
login attempts for administrators to SQL Managed
contained DB track users logging Instance
authentication to SQL Server
should be enabled instances that they're
responsible for. This
rule checks that
auditing is enabled
for both successful
and failed login
attempts for
contained DB
authentication.

VA1281 All memberships for Medium User-defined roles SQL Server 2012+
user-defined roles are security principals
should be intended defined by the user SQL Managed
to group principals to Instance
easily manage
permissions. SQL Database
Monitoring these
roles is important to Azure Synapse
avoid having
excessive
permissions. Create a
baseline that defines
expected
membership for each
user-defined role.
This rule checks
whether all
memberships for
user-defined roles are
as defined in the
baseline.
 RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1283 There should be at Low Auditing an instance SQL Server 2012+

least 1 active audit in of the SQL Server
the system Database Engine or SQL Managed
an individual Instance
database involves
tracking and logging
events that occur on
the Database Engine.
The SQL Server Audit
object collects a
single instance of
server or database-
level actions and
groups of actions to
monitor. This rule
checks that there is
at least one active
audit in the system.

VA2061 Auditing should be High Azure SQL Database SQL Database

enabled at the server Auditing tracks
level database events and Azure Synapse
writes them to an
audit log in your
Azure storage
account. Auditing
helps you
understand database
activity and gain
insight into
discrepancies and
anomalies that could
indicate business
concerns or
suspected security
violations as well as
helps you meet
regulatory
compliance. For more
information, see
Azure SQL Auditing.
This rule checks that
auditing is enabled.

Data Protection
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1098 Any Existing SSB or High Service Broker and SQL Server 2012+
Mirroring endpoint Mirroring endpoints
should require AES support different
connection encryption
algorithms including
no-encryption. This
rule checks that any
existing endpoint
requires AES
encryption.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1219 Transparent data Medium Transparent data SQL Server 2012+

encryption should be encryption (TDE)
enabled helps to protect the SQL Managed
database files against Instance
information
disclosure by SQL Database
performing real-time
encryption and Azure Synapse
decryption of the
database, associated
backups, and
transaction log files
'at rest', without
requiring changes to
the application. This
rule checks that TDE
is enabled on the
database.

VA1220 Database High Microsoft SQL Server SQL Server 2012+

communication using can use Secure
TDS should be Sockets Layer (SSL) SQL Managed
protected through or Transport Layer Instance
TLS Security (TLS) to
encrypt data that is
transmitted across a
network between an
instance of SQL
Server and a client
application. This rule
checks that all
connections to the
SQL Server are
encrypted through
TLS.

VA1221 Database Encryption High SQL Server uses SQL Server 2012+
Symmetric Keys encryption keys to
should use AES help secure data SQL Managed
algorithm credentials and Instance
connection
information that is SQL Database
stored in a server
database. SQL Server Azure Synapse
has two kinds of
keys: symmetric and
asymmetric. This rule
checks that Database
Encryption
Symmetric Keys use
AES algorithm.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1222 Cell-Level Encryption High Cell-Level Encryption SQL Server 2012+

keys should use AES (CLE) allows you to
algorithm encrypt your data SQL Managed
using symmetric and Instance
asymmetric keys. This
rule checks that Cell-
Level Encryption
symmetric keys use
AES algorithm.

VA1223 Certificate keys High Certificate keys are SQL Server 2012+
should use at least used in RSA and
2048 bits other encryption SQL Managed
algorithms to protect Instance
data. These keys
need to be of SQL Database
enough length to
secure the user's Azure Synapse
data. This rule checks
that the key's length
is at least 2048 bits
for all certificates.

VA1224 Asymmetric keys' High Database asymmetric SQL Server 2012

length should be at keys are used in
least 2048 bits many encryption SQL Server 2014
algorithms these
keys need to be of SQL Database
enough length to
secure the encrypted
data this rule checks
that all asymmetric
keys stored in the
database are of
length of at least
2048 bits

VA1279 Force encryption High When the Force SQL Server 2012+
should be enabled Encryption option for
for TDS the Database Engine
is enabled all
communications
between client and
server is encrypted
regardless of whether
the 'Encrypt
connection' option
(such as from SSMS)
is checked or not.
This rule checks that
Force Encryption
option is enabled.

VA1288 Sensitive data Medium This rule checks if the SQL Database
columns should be scanned database
classified has potentially
sensitive data that
has not been
classified.
 RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2060 SQL Threat Detection Medium SQL Threat Detection

should be enabled at provides a layer of SQL Managed
the server level security that detects Instance
potential
vulnerabilities and SQL Database
anomalous activity in
databases such as Azure Synapse
SQL injection attacks
and unusual behavior
patterns. When a
potential threat is
detected Threat
Detection sends an
actionable real-time
alert by email and in
Microsoft Defender
for Cloud, which
includes clear
investigation and
remediation steps for
the specific threat.
For more
information, please
see Configure threat
detection. This check
verifies that SQL
Threat Detection is
enabled

Installation Updates and Patches

RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1018 Latest updates High Microsoft periodically SQL Server 2005

should be installed releases Cumulative
Updates (CUs) for SQL Server 2008
each version of SQL
Server. This rule SQL Server 2008
checks whether the
latest CU has been SQL Server 2012
installed for the
particular version of SQL Server 2014
SQL Server being
used, by passing in a SQL Server 2016
string for execution.
This rule checks that SQL Server 2017
all users (except dbo)
do not have
permission to
execute the
xp_cmdshell
extended stored
procedure.
 RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2128 Vulnerability High To run a Vulnerability SQL Server 2012+

Assessment is not Assessment scan on
supported for SQL your SQL Server the SQL Managed
Server versions lower server needs to be Instance
than SQL Server upgraded to SQL
2012 Server 2012 or SQL Database
higher, SQL Server
2008 R2 and below Azure Synapse
are no longer
supported by
Microsoft. For more
information, see
https://www.microsof
t.com/cloud-
platform/windows-
sql-server-2008

Surface Area Reduction

RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1022 Ad hoc distributed Medium Ad hoc distributed SQL Server 2012+

queries should be queries use the
disabled OPENROWSET and
OPENDATASOURCE
functions to connect
to remote data
sources that use OLE
DB. This rule checks
that ad hoc
distributed queries
are disabled.

VA1023 CLR should be High The CLR allows SQL Server 2012+
disabled managed code to be
hosted by and run in
the Microsoft SQL
Server environment.
This rule checks that
CLR is disabled.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1026 CLR should be Medium The CLR allows SQL Server 2017+2
disabled managed code to be
hosted by and run in SQL Managed
the Microsoft SQL Instance
Server environment.
CLR strict security
treats SAFE and
EXTERNAL_ACCESS
assemblies as if they
were marked
UNSAFE and requires
all assemblies be
signed by a
certificate or
asymmetric key with
a corresponding
login that has been
granted UNSAFE
ASSEMBLY
permission in the
master database. This
rule checks that CLR
is disabled.

VA1027 Untracked trusted High Assemblies marked SQL Server 2017+

assemblies should be as UNSAFE are
removed required to be signed SQL Managed
by a certificate or Instance
asymmetric key with
a corresponding
login that has been
granted UNSAFE
ASSEMBLY
permission in the
master database.
Trusted assemblies
may bypass this
requirement.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1044 Remote Admin Medium This rule checks that SQL Server 2012+
Connections should remote dedicated
be disabled unless admin connections SQL Managed
specifically required are disabled if they Instance
are not being used
for clustering to
reduce attack surface
area. SQL Server
provides a dedicated
administrator
connection (DAC).
The DAC lets an
administrator access
a running server to
execute diagnostic
functions or Transact-
SQL statements, or
to troubleshoot
problems on the
server and it
becomes an
attractive target to
attack when it is
enabled remotely.

VA1051 AUTO_CLOSE should Medium The AUTO_CLOSE SQL Server 2012+

be disabled on all option specifies
databases whether the
database shuts down
gracefully and frees
resources after the
last user disconnects.
Regardless of its
benefits it can cause
denial of service by
aggressively opening
and closing the
database, thus it is
important to keep
this feature disabled.
This rule checks that
this option is
disabled on the
current database.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1066 Unused service Low Service Broker SQL Server 2012+

broker endpoints provides queuing
should be removed and reliable
messaging for SQL
Server. Service Broker
is used both for
applications that use
a single SQL Server
instance and
applications that
distribute work
across multiple
instances. Service
Broker endpoints
provide options for
transport security
and message
forwarding. This rule
enumerates all the
service broker
endpoints. Remove
those that are not
used.

VA1071 'Scan for startup Medium When 'Scan for SQL Server 2012+
stored procedures' startup procs' is
option should be enabled SQL Server
disabled scans for and runs all
automatically run
stored procedures
defined on the server.
If this option is
enabled SQL Server
scans for and runs all
automatically run
stored procedures
defined on the server.
This rule checks that
this option is
disabled.

VA1092 SQL Server instance Low SQL Server uses the SQL Server 2012+
shouldn't be SQL Server Browser
advertised by the service to enumerate
SQL Server Browser instances of the
service Database Engine
installed on the
computer. This
enables client
applications to
browse for a server
and helps clients
distinguish between
multiple instances of
the Database Engine
on the same
computer. This rule
checks that the SQL
instance is hidden.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1102 The Trustworthy bit High The TRUSTWORTHY SQL Server 2012+
should be disabled database property is
on all databases used to indicate SQL Managed
except MSDB whether the instance Instance
of SQL Server trusts
the database and the
contents within it. If
this option is enabled
database modules
(for example user-
defined functions or
stored procedures)
that use an
impersonation
context can access
resources outside the
database. This rule
verifies that the
TRUSTWORTHY bit is
disabled on all
databases except
MSDB.

VA1143 'dbo' user should not Medium The 'dbo' or database SQL Server 2012+
be used for normal owner is a user
service operation account that has SQL Managed
implied permissions Instance
to perform all
activities in the SQL Database
database. Members
of the sysadmin fixed Azure Synapse
server role are
automatically
mapped to dbo. This
rule checks that dbo
is not the only
account allowed to
access this database.
Note that on a newly
created clean
database this rule will
fail until additional
roles are created.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1144 Model database Medium The Model database SQL Server 2012+
should only be is used as the
accessible by 'dbo' template for all SQL Managed
databases created on Instance
the instance of SQL
Server. Modifications
made to the model
database such as
database size
recovery model and
other database
options are applied
to any databases
created afterward.
This rule checks that
dbo is the only
account allowed to
access the model
database.

VA1230 Filestream should be High FILESTREAM SQL Server 2012+

disabled integrates the SQL
Server Database
Engine with an NTFS
file system by storing
varbinary (max)
binary large object
(BLOB) data as files
on the file system.
Transact-SQL
statements can
insert, update, query,
search, and back up
FILESTREAM data.
Enabling Filestream
on SQL server
exposes additional
NTFS streaming API,
which increases its
attack surface and
makes it prone to
malicious attacks.
This rule checks that
Filestream is disabled.

VA1235 Server configuration Medium Disable the SQL Server 2012+

'Replication XPs' deprecated server
should be disabled configuration SQL Managed
'Replication XPs' to Instance
limit the attack
surface area. This is
an internal only
configuration setting.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1244 Orphaned users Medium A database user that SQL Server 2012+
should be removed exists on a database
from SQL server but has no SQL Managed
databases corresponding login Instance
in the master
database or as an
external resource (for
example, a Windows
user) is referred to as
an orphaned user
and it should either
be removed or
remapped to a valid
login. This rule checks
that there are no
orphaned users.

VA1245 The dbo information High There is redundant SQL Server 2012+
should be consistent information about
between the target the dbo identity for SQL Managed
DB and master any database: Instance
metadata stored in
the database itself
and metadata stored
in master DB. This
rule checks that this
information is
consistent between
the target DB and
master.

VA1247 There should be no High When SQL Server SQL Server 2012+
SPs marked as auto- has been configured
start to 'scan for startup
procs' the server will
scan master DB for
stored procedures
marked as auto-
start. This rule checks
that there are no SPs
marked as auto-
start.

VA1256 User CLR assemblies High CLR assemblies can SQL Server 2012+
should not be be used to execute
defined in the arbitrary code on SQL Managed
database SQL Server process. Instance
This rule checks that
there are no user-
defined CLR
assemblies in the
database.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA1277 Polybase network High PolyBase is a SQL Server 2016+

encryption should be technology that
enabled accesses and
combines both non-
relational and
relational data all
from within SQL
Server. Polybase
network encryption
option configures
SQL Server to
encrypt control and
data channels when
using Polybase. This
rule verifies that this
option is enabled.

VA1278 Create a baseline of Medium The SQL Server SQL Server 2012+
External Key Extensible Key
Management Management (EKM) SQL Managed
Providers enables third-party Instance
EKM / Hardware
Security Modules
(HSM) vendors to
register their
modules in SQL
Server. When
registered SQL
Server users can use
the encryption keys
stored on EKM
modules,this rule
displays a list of EKM
providers being used
in the system.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2062 Database-level High The Azure SQL SQL Database

firewall rules should Database-level
not grant excessive firewall helps protect Azure Synapse
access your data by
preventing all access
to your database
until you specify
which IP addresses
have permission.
Database-level
firewall rules grant
access to the specific
database based on
the originating IP
address of each
request. Database-
level firewall rules for
master and user
databases can only
be created and
managed through
Transact-SQL (unlike
server-level firewall
rules, which can also
be created and
managed using the
Azure portal or
PowerShell). For more
information, see
Azure SQL Database
and Azure Synapse
Analytics IP firewall
rules. This check
verifies that
database-level
firewall rules do not
grant access to more
than 255 IP
addresses.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2063 Server-level firewall High The Azure SQL SQL Database

rules should not server-level firewall
grant excessive helps protect your Azure Synapse
access server by preventing
all access to your
databases until you
specify which IP
addresses have
permission. Server-
level firewall rules
grant access to all
databases that
belong to the server
based on the
originating IP
address of each
request. Server-level
firewall rules can only
be created and
managed through
Transact-SQL as well
as through the Azure
portal or PowerShell.
For more
information, see
Azure SQL Database
and Azure Synapse
Analytics IP firewall
rules. This check
verifies that server-
level firewall rules do
not grant access to
more than 255 IP
addresses.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2064 Database-level High The Azure SQL SQL Database

firewall rules should Database-level
be tracked and firewall helps protect Azure Synapse
maintained at a strict your data by
minimum preventing all access
to your database
until you specify
which IP addresses
have permission.
Database-level
firewall rules grant
access to the specific
database based on
the originating IP
address of each
request. Database-
level firewall rules for
master and user
databases can only
be created and
managed through
Transact-SQL (unlike
server-level firewall
rules, which can also
be created and
managed using the
Azure portal or
PowerShell). For more
information, see
Azure SQL Database
and Azure Synapse
Analytics IP firewall
rules. This check
enumerates all the
database-level
firewall rules so that
any changes made to
them can be
identified and
addressed.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2065 Server-level firewall High The Azure SQL SQL Database

rules should be server-level firewall
tracked and helps protect your Azure Synapse
maintained at a strict data by preventing
minimum all access to your
databases until you
specify which IP
addresses have
permission. Server-
level firewall rules
grant access to all
databases that
belong to the server
based on the
originating IP
address of each
request. Server-level
firewall rules can be
created and
managed through
Transact-SQL as well
as through the Azure
portal or PowerShell.
For more
information, see
Azure SQL Database
and Azure Synapse
Analytics IP firewall
rules. This check
enumerates all the
server-level firewall
rules so that any
changes made to
them can be
identified and
addressed.

VA2111 Sample databases Low Microsoft SQL Server SQL Server 2012+
should be removed comes shipped with
several sample SQL Managed
databases. This rule Instance
checks whether the
sample databases
have been removed.

VA2120 Features that may High SQL Server is capable SQL Server 2012+
affect security should of providing a wide
be disabled range of features and SQL Managed
services. Some of the Instance
features and services
provided by default
may not be
necessary and
enabling them could
adversely affect the
security of the
system. This rule
checks that these
features are disabled.
RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2121 'OLE Automation High SQL Server is capable SQL Server 2012+
Procedures' feature of providing a wide
should be disabled range of features and SQL Managed
services. Some of the Instance
features and services,
provided by default,
may not be
necessary, and
enabling them could
adversely affect the
security of the
system. The OLE
Automation
Procedures option
controls whether OLE
Automation objects
can be instantiated
within Transact-SQL
batches. These are
extended stored
procedures that allow
SQL Server users to
execute functions
external to SQL
Server. Regardless of
its benefits it can also
be used for exploits,
and is known as a
popular mechanism
to plant files on the
target machines. It is
advised to use
PowerShell as a
replacement for this
tool. This rule checks
that 'OLE
Automation
Procedures' feature is
disabled.
 RUL E ID RUL E T IT L E RUL E SEVERIT Y RUL E DESC RIP T IO N P L AT F O RM

VA2122 'User Options' Medium SQL Server is capable SQL Server 2012+
feature should be of providing a wide
disabled range of features and SQL Managed
services. Some of the Instance
features and services
provided by default
may not be
necessary and
enabling them could
adversely affect the
security of the
system. The user
options specifies
global defaults for all
users. A list of default
query processing
options is established
for the duration of a
user's work session.
The user options
allows you to change
the default values of
the SET options (if
the server's default
settings are not
appropriate). This
rule checks that 'user
options' feature is
disabled.

VA2126 Extensibility-features Medium SQL Server provides SQL Server 2016+

that may affect a wide range of
security should be features and services.
disabled if not Some of the features
needed and services,
provided by default,
may not be
necessary, and
enabling them could
adversely affect the
security of the
system. This rule
checks that
configurations that
allow extraction of
data to an external
data source and the
execution of scripts
with certain remote
language extensions
are disabled.

Removed rules
RUL E ID RUL E T IT L E

VA1021 Global temporary stored procedures should be removed

RUL E ID RUL E T IT L E

VA1024 C2 Audit Mode should be enabled

VA1069 Permissions to select from system tables and views should

be revoked from non-sysadmins

VA1090 Ensure all Government Off The Shelf (GOTS) and Custom
Stored Procedures are encrypted

VA1103 Use only CLR with SAFE_ACCESS permission

VA1229 Filestream setting in registry and in SQL Server

configuration should match

VA1231 Filestream should be disabled (SQL)

VA1234 Common Criteria setting should be enabled

VA1252 List of events being audited and centrally managed via

server audit specifications.

VA1253 List of DB-scoped events being audited and centrally

managed via server audit specifications

VA1263 List all the active audits in the system

VA1266 The 'MUST_CHANGE' option should be set on all SQL logins

VA1276 Agent XPs feature should be disabled

VA1286 Database permissions shouldn't be granted directly to

principals (OBJECT or COLUMN)

VA2000 Minimal set of principals should be granted high impact

database-scoped permissions

VA2001 Minimal set of principals should be granted high impact

database-scoped permissions on objects or columns

VA2002 Minimal set of principals should be granted high impact

database-scoped permissions on various securables

VA2010 Minimal set of principals should be granted medium impact

database-scoped permissions

VA2021 Minimal set of principals should be granted database-scoped

ALTER permissions on objects or columns

VA2022 Minimal set of principals should be granted database-scoped

ALTER permission on various securables

VA2030 Minimal set of principals should be granted database-scoped

SELECT or EXECUTE permissions
 RUL E ID RUL E T IT L E

VA2031 Minimal set of principals should be granted database-scoped

SELECT

VA2032 Minimal set of principals should be granted database-scoped

SELECT or EXECUTE permissions on schema

VA2034 Minimal set of principals should be granted database-scoped

EXECUTE permission on XML Schema Collection

VA2040 Minimal set of principals should be granted low impact

database-scoped permissions

VA2041 Minimal set of principals should be granted low impact

database-scoped permissions on objects or columns

VA2042 Minimal set of principals should be granted low impact

database-scoped permissions on schema

VA2050 Minimal set of principals should be granted database-scoped

VIEW DEFINITION permissions

VA2051 Minimal set of principals should be granted database-scoped

VIEW DEFINITION permissions on objects or columns

VA2052 Minimal set of principals should be granted database-scoped

VIEW DEFINITION permission on various securables

VA2100 Minimal set of principals should be granted high impact

server-scoped permissions

VA2101 Minimal set of principals should be granted medium impact

server-scoped permissions

VA2102 Minimal set of principals should be granted low impact

server-scoped permissions

VA2104 Execute permissions on extended stored procedures should

be revoked from PUBLIC

VA2105 Login password should not be easily guessed

VA2112 Permissions from PUBLIC for Data Transformation Services

(DTS) should be revoked

VA2115 Minimal set of principals should be members of medium

impact fixed server roles

VA2123 'Remote Access' feature should be disabled

VA2127 'External Scripts' feature should be disabled

Next steps
Vulnerability Assessment
SQL Vulnerability Assessment rules changelog
 SQL Vulnerability assessment rules changelog
12/6/2021 • 3 minutes to read • Edit Online

This article details the changes made to the SQL Vulnerability Assessment service rules. Rules that are updated,
removed, or added will be outlined below. For an updated list of SQL Vulnerability assessment rules, see SQL
Vulnerability Assessment rules.

June 2021
RUL E ID RUL E T IT L E C H A N GE DETA IL S

VA1220 Database communication using TDS Logic change

should be protected through TLS

VA2108 Minimal set of principals should be Logic change

members of fixed high impact
database roles

December 2020
RUL E ID RUL E T IT L E C H A N GE DETA IL S

VA1017 Execute permissions on xp_cmdshell Title and description change

from all users (except dbo) should be
revoked

VA1021 Global temporary stored procedures Removed rule

should be removed

VA1024 C2 Audit Mode should be enabled Removed rule

VA1042 Database ownership chaining should Description change

be disabled for all databases except for
master , msdb , and tempdb

VA1044 Remote Admin Connections should be Title and description change

disabled unless specifically required

VA1047 Password expiration check should be Title and description change

enabled for all SQL logins

VA1051 AUTO_CLOSE should be disabled on all Description change

databases

VA1053 Account with default name 'sa' should Description change

be renamed or disabled

VA1067 Database Mail XPs should be disabled Title and description change
when it is not in use
RUL E ID RUL E T IT L E C H A N GE DETA IL S

VA1068 Server permissions shouldn't be Logic change

granted directly to principals

VA1069 Permissions to select from system Removed rule

tables and views should be revoked
from non-sysadmins

VA1090 Ensure all Government Off The Shelf Removed rule

(GOTS) and Custom Stored Procedures
are encrypted

VA1091 Auditing of both successful and failed Description change

login attempts (default trace) should
be enabled when 'Login auditing' is set
up to track logins

VA1098 Any Existing SSB or Mirroring endpoint Logic change

should require AES connection

VA1103 Use only CLR with SAFE_ACCESS Removed rule

permission

VA1219 Transparent data encryption should be Description change

enabled

VA1229 Filestream setting in registry and in Removed rule

SQL Server configuration should
match

VA1230 Filestream should be disabled Description change

VA1231 Filestream should be disabled (SQL) Removed rule

VA1234 Common Criteria setting should be Removed rule

enabled

VA1235 Replication XPs should be disabled Title, description, and Logic change

VA1252 List of events being audited and Removed rule

centrally managed via server audit
specifications.

VA1253 List of DB-scoped events being Removed rule

audited and centrally managed via
server audit specifications.

VA1263 List all the active audits in the system Removed rule

VA1264 Auditing of both successful and failed Description change

login attempts should be enabled

VA1266 The 'MUST_CHANGE' option should be Removed rule

set on all SQL logins
RUL E ID RUL E T IT L E C H A N GE DETA IL S

VA1276 Agent XPs feature should be disabled Removed rule

VA1281 All memberships for user-defined roles Logic change

should be intended

VA1282 Orphan roles should be removed Logic change

VA1286 Database permissions shouldn't be Removed rule

granted directly to principals (OBJECT
or COLUMN)

VA1288 Sensitive data columns should be Description change

classified

VA2030 Minimal set of principals should be Removed rule

granted database-scoped SELECT or
EXECUTE permissions

VA2033 Minimal set of principals should be Description change

granted database-scoped EXECUTE
permission on objects or columns

VA2062 Database-level firewall rules should not Description change

grant excessive access

VA2063 Server-level firewall rules should not Description change

grant excessive access

VA2100 Minimal set of principals should be Removed rule

granted high impact server-scoped
permissions

VA2101 Minimal set of principals should be Removed rule

granted medium impact server-scoped
permissions

VA2102 Minimal set of principals should be Removed rule

granted low impact server-scoped
permissions

VA2103 Unnecessary execute permissions on Logic change

extended stored procedures should be
revoked

VA2104 Execute permissions on extended Removed rule

stored procedures should be revoked
from PUBLIC

VA2105 Login password should not be easily Removed rule

guessed

VA2108 Minimal set of principals should be Logic change

members of fixed high impact
database roles
 RUL E ID RUL E T IT L E C H A N GE DETA IL S

VA2111 Sample databases should be removed Logic change

VA2112 Permissions from PUBLIC for Data Removed rule

Transformation Services (DTS) should
be revoked

VA2113 Data Transformation Services (DTS) Description and logic change

permissions should only be granted to
SSIS roles

VA2114 Minimal set of principals should be Logic change

members of high impact fixed server
roles

VA2115 Minimal set of principals should be Removed rule

members of medium impact fixed
server roles

VA2120 Features that may affect security Logic change

should be disabled

VA2121 'OLE Automation Procedures' feature Title and description change

should be disabled

VA2123 'Remote Access' feature should be Removed rule

disabled

VA2126 Features that may affect security Title, description, and logic change
should be disabled

VA2127 'External Scripts' feature should be Removed rule

disabled

VA2129 Changes to signed modules should be Platform update

authorized

VA2130 Track all users with access to the Description and logic change
database

Next steps
SQL Vulnerability Assessment rules
SQL Vulnerability Assessment overview
Store Vulnerability Assessment scan results in a storage account accessible behind firewalls and VNets
 Store Vulnerability Assessment scan results in a
storage account accessible behind firewalls and
VNets
12/6/2021 • 4 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
If you are limiting access to your storage account in Azure for certain VNets or services, you'll need to enable
the appropriate configuration so that Vulnerability Assessment (VA) scanning for SQL Databases or Managed
Instances have access to that storage account.

Prerequisites
The SQL Vulnerability Assessment service needs permission to the storage account to save baseline and scan
results. There are three methods:
Use Storage Account key : Azure creates the SAS key and saves it (though we don't save the account key)
Use Storage SAS key : The SAS key must have: Write | List | Read | Delete permissions
Use SQL Ser ver managed identity : The SQL Server must have a managed identity. The storage account
must have a role assignment for the SQL Managed Identity as Storage Blob Data Contributor. When you
apply the settings, the VA fields storageContainerSasKey and storageAccountAccessKey must be empty.
When storage is behind a firewall or virtual network, then the SQL managed identity is required.
When you use the Azure portal to save SQL VA settings, Azure checks if you have permission to assign a new
role assignment for the managed identity as Storage Blob Data Contributor on the storage. If permissions are
assigned, Azure uses SQL Server managed identity, otherwise Azure uses the key method.

Enable Azure SQL Database VA scanning access to the storage

account
If you have configured your VA storage account to only be accessible by certain networks or services, you'll
need to ensure that VA scans for your Azure SQL Database are able to store the scans on the storage account.
You can use the existing storage account, or create a new storage account to store VA scan results for all
databases on your logical SQL server.

NOTE
The vulnerability assessment service can't access storage accounts protected with firewalls or VNets if they require storage
access keys.

Go to your Resource group that contains the storage account and access the Storage account pane. Under
Settings , select Firewall and vir tual networks .
Ensure that Allow trusted Microsoft ser vices access to this storage account is checked.
To find out which storage account is being used, go to your SQL ser ver pane in the Azure portal, under
Security , and then select Defender for Cloud .
 NOTE
You can set up email alerts to notify users in your organization to view or access the scan reports. To do this, ensure that
you have SQL Security Manager and Storage Blob Data Reader permissions.

Store VA scan results for Azure SQL Managed Instance in a storage

account that can be accessed behind a firewall or VNet
Since Managed Instance is not a trusted Microsoft Service and has a different VNet from the storage account,
executing a VA scan will result in an error.
To support VA scans on Managed Instances, follow the below steps:
1. In the SQL managed instance pane, under the Over view heading, click the Vir tual network/subnet
link. This takes you to the Vir tual network pane.
2. Under Settings , select Subnets . Click Subnet in the new pane to add a subnet, and delegate it to
Microsoft.Sql\managedInstance. For more information, see Manage subnets.

3. In your Vir tual network pane, under Settings , select Ser vice endpoints . Click Add in the new pane,
and add the Microsoft.Storage Service as a new service endpoint. Make sure the ManagedInstance
Subnet is selected. Click Add .

4. Go to your Storage account that you've selected to store your VA scans. Under Settings , select
Firewall and vir tual networks . Click on Add existing vir tual network . Select your managed
instance virtual network and subnet, and click Add .
You should now be able to store your VA scans for Managed Instances in your storage account.

Troubleshoot vulnerability assessment scan-related issues

Troubleshoot common issues related to vulnerability assessment scans.
Failure to save vulnerability assessment settings
You might not be able to save changes to vulnerability assessment settings if your storage account doesn't meet
some prerequisites or if you have insufficient permissions.
Storage account requirements
The storage account in which vulnerability assessment scan results are saved must meet the following
requirements:
Type : StorageV2 (General Purpose V2) or Storage (General Purpose V1)
Performance : Standard (only)
Region : The storage must be in the same region as the instance of Azure SQL Server.
If any of these requirements aren't met, saving changes to vulnerability assessment settings fails.
Permissions
The following permissions are required to save changes to vulnerability assessment settings:
SQL Security Manager
Storage Blob Data Reader
Owner role on the storage account
Setting a new role assignment requires owner or user administrator access to the storage account and the
following permissions:
Storage Blob Data Owner
Storage account isn't visible for selection in vulnerability assessment settings
The storage account might not appear in the storage account picker for several reasons:
The storage account you're looking for isn't in the selected subscription.
 The storage account you're looking for isn't in the same region as the instance of Azure SQL Server.
You don't have Microsoft.Storage/storageAccounts/read permissions on the storage account.
Failure to open an email link for scan results or can't view scan results
You might not be able to open a link in a notification email about scan results or to view scan results if you don't
have the required permissions or if you use a browser that doesn't support opening or displaying scan results.
Permissions
The following permissions are required to open links in email notifications about scan results or to view scan
results:
SQL Security Manager
Storage Blob Data Reader
Browser requirements
The Firefox browser doesn't support opening or displaying scan results view. We recommend that you use
Chrome or Microsoft Edge to view vulnerability assessment scan results.

Next steps
Vulnerability Assessment
Create an Azure Storage account
Microsoft Defender for SQL
 Authorize database access to SQL Database, SQL
Managed Instance, and Azure Synapse Analytics
12/6/2021 • 10 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
In this article, you learn about:
Options for configuring Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics to
enable users to perform administrative tasks and to access the data stored in these databases.
The access and authorization configuration after initially creating a new server.
How to add logins and user accounts in the master database and user accounts and then grant these
accounts administrative permissions.
How to add user accounts in user databases, either associated with logins or as contained user accounts.
Configure user accounts with permissions in user databases by using database roles and explicit
permissions.

IMPORTANT
Databases in Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse are referred to collectively in the
remainder of this article as databases, and the server is referring to the server that manages databases for Azure SQL
Database and Azure Synapse.

Survey to improve Azure SQL!

Authentication and authorization

Authentication is the process of proving the user is who they claim to be. A user connects to a database using
a user account. When a user attempts to connect to a database, they provide a user account and authentication
information. The user is authenticated using one of the following two authentication methods:
SQL authentication.
With this authentication method, the user submits a user account name and associated password to
establish a connection. This password is stored in the master database for user accounts linked to a login
or stored in the database containing the user accounts not linked to a login.
Azure Active Directory Authentication
With this authentication method, the user submits a user account name and requests that the service use
the credential information stored in Azure Active Directory (Azure AD).
Logins and users : A user account in a database can be associated with a login that is stored in the master
database or can be a user name that is stored in an individual database.
A login is an individual account in the master database, to which a user account in one or more databases
can be linked. With a login, the credential information for the user account is stored with the login.
A user account is an individual account in any database that may be, but does not have to be, linked to a
login. With a user account that is not linked to a login, the credential information is stored with the user
account.
Authorization to access data and perform various actions are managed using database roles and explicit
permissions. Authorization refers to the permissions assigned to a user, and determines what that user is
allowed to do. Authorization is controlled by your user account's database role memberships and object-level
permissions. As a best practice, you should grant users the least privileges necessary.

Existing logins and user accounts after creating a new database

When you first deploy Azure SQL, you specify an admin login and an associated password for that login. This
administrative account is called Ser ver admin . The following configuration of logins and users in the master
and user databases occurs during deployment:
A SQL login with administrative privileges is created using the login name you specified. A login is an
individual user account for logging in to SQL Database, SQL Managed Instance, and Azure Synapse.
This login is granted full administrative permissions on all databases as a server-level principal. The login has
all available permissions and can't be limited. In a SQL Managed Instance, this login is added to the sysadmin
fixed server role (this role does not exist in Azure SQL Database).
A user account called dbo is created for this login in each user database. The dbo user has all database
permissions in the database and is mapped to the db_owner fixed database role. Additional fixed database
roles are discussed later in this article.
To identify the administrator accounts for a database, open the Azure portal, and navigate to the Proper ties tab
of your server or managed instance.
 IMPORTANT
The admin login name can't be changed after it has been created. To reset the password for the server admin, go to the
Azure portal, click SQL Ser vers , select the server from the list, and then click Reset Password . To reset the password for
the SQL Managed Instance, go to the Azure portal, click the instance, and click Reset password . You can also use
PowerShell or the Azure CLI.

Create additional logins and users having administrative permissions

At this point, your server or managed instance is only configured for access using a single SQL login and user
account. To create additional logins with full or partial administrative permissions, you have the following
options (depending on your deployment mode):
Create an Azure Active Director y administrator account with full administrative permissions
Enable Azure Active Directory authentication and create an Azure AD administrator login. One Azure
Active Directory account can be configured as an administrator of the Azure SQL deployment with full
administrative permissions. This account can be either an individual or security group account. An Azure
AD administrator must be configured if you want to use Azure AD accounts to connect to SQL Database,
SQL Managed Instance, or Azure Synapse. For detailed information on enabling Azure AD authentication
for all Azure SQL deployment types, see the following articles:
Use Azure Active Directory authentication for authentication with SQL
Configure and manage Azure Active Directory authentication with SQL
In SQL Managed Instance, create SQL logins with full administrative permissions
 Create an additional SQL login in the master database.
Add the login to the sysadmin fixed server role using the ALTER SERVER ROLE statement. This login
will have full administrative permissions.
Alternatively, create an Azure AD login using the CREATE LOGIN syntax.
In SQL Database, create SQL logins with limited administrative permissions
Create an additional SQL login in the master database.
Create a user account in the master database associated with this new login.
Add the user account to the dbmanager , the loginmanager role, or both in the master database using
the ALTER ROLE statement (for Azure Synapse, use the sp_addrolemember statement).

NOTE
dbmanager and loginmanager roles do not pertain to SQL Managed Instance deployments.

Members of these special master database roles for Azure SQL Database have authority to create and
manage databases or to create and manage logins. In databases created by a user that is a member of the
dbmanager role, the member is mapped to the db_owner fixed database role and can log into and
manage that database using the dbo user account. These roles have no explicit permissions outside of
the master database.

IMPORTANT
You can't create an additional SQL login with full administrative permissions in SQL Database.

Create accounts for non-administrator users

You can create accounts for non-administrative users using one of two methods:
Create a login
Create a SQL login in the master database. Then create a user account in each database to which that user
needs access and associate the user account with that login. This approach is preferred when the user
must access multiple databases and you wish to keep the passwords synchronized. However, this
approach has complexities when used with geo-replication as the login must be created on both the
primary server and the secondary server(s). For more information, see Configure and manage Azure SQL
Database security for geo-restore or failover.
Create a user account
Create a user account in the database to which a user needs access (also called a contained user).
With SQL Database, you can always create this type of user account.
With SQL Managed Instance supporting Azure AD server principals, you can create user accounts to
authenticate to the SQL Managed Instance without requiring database users to be created as a
contained database user.
With this approach, the user authentication information is stored in each database, and replicated to geo-
replicated databases automatically. However, if the same account exists in multiple databases and you are
using Azure SQL Authentication, you must keep the passwords synchronized manually. Additionally, if a
user has an account in different databases with different passwords, remembering those passwords can
become a problem.
 IMPORTANT
To create contained users mapped to Azure AD identities, you must be logged in using an Azure AD account that is an
administrator in the database in Azure SQL Database. In SQL Managed Instance, a SQL login with sysadmin permissions
can also create an Azure AD login or user.

For examples showing how to create logins and users, see:

Create login for Azure SQL Database
Create login for Azure SQL Managed Instance
Create login for Azure Synapse
Create user
Creating Azure AD contained users

TIP
For a security tutorial that includes creating users in Azure SQL Database, see Tutorial: Secure Azure SQL Database.

Using fixed and custom database roles

After creating a user account in a database, either based on a login or as a contained user, you can authorize that
user to perform various actions and to access data in a particular database. You can use the following methods
to authorize access:
Fixed database roles
Add the user account to a fixed database role. There are 9 fixed database roles, each with a defined set of
permissions. The most common fixed database roles are: db_owner , db_ddladmin , db_datawriter ,
db_datareader , db_denydatawriter , and db_denydatareader . db_owner is commonly used to grant
full permission to only a few users. The other fixed database roles are useful for getting a simple database
in development quickly, but are not recommended for most production databases. For example, the
db_datareader fixed database role grants read access to every table in the database, which is more than
is strictly necessary.
To add a user to a fixed database role:
In Azure SQL Database, use the ALTER ROLE statement. For examples, see ALTER ROLE
examples
Azure Synapse, use the sp_addrolemember statement. For examples, see sp_addrolemember
examples.
Custom database role
Create a custom database role using the CREATE ROLE statement. A custom role enables you to create
your own user-defined database roles and carefully grant each role the least permissions necessary for
the business need. You can then add users to the custom role. When a user is a member of multiple roles,
they aggregate the permissions of them all.
Grant permissions directly
Grant the user account permissions directly. There are over 100 permissions that can be individually
granted or denied in SQL Database. Many of these permissions are nested. For example, the UPDATE
permission on a schema includes the UPDATE permission on each table within that schema. As in most
permission systems, the denial of a permission overrides a grant. Because of the nested nature and the
number of permissions, it can take careful study to design an appropriate permission system to properly
 protect your database. Start with the list of permissions at Permissions (Database Engine) and review the
poster size graphic of the permissions.

Using groups
Efficient access management uses permissions assigned to Active Directory security groups and fixed or custom
roles instead of to individual users.
When using Azure Active Directory authentication, put Azure Active Directory users into an Azure Active
Directory security group. Create a contained database user for the group. Add one or more database
users as a member to custom or builtin database roles with the specific permissions appropriate to that
group of users.
When using SQL authentication, create contained database users in the database. Place one or more
database users into a custom database role with specific permissions appropriate to that group of users.

NOTE
You can also use groups for non-contained database users.

You should familiarize yourself with the following features that can be used to limit or elevate permissions:
Impersonation and module-signing can be used to securely elevate permissions temporarily.
Row-Level Security can be used limit which rows a user can access.
Data Masking can be used to limit exposure of sensitive data.
Stored procedures can be used to limit the actions that can be taken on the database.

Next steps
For an overview of all Azure SQL Database and SQL Managed Instance security features, see Security overview.
 Use Azure Active Directory authentication
12/6/2021 • 10 minutes to read • Edit Online

APPLIES TO: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
Azure Active Directory (Azure AD) authentication is a mechanism for connecting to Azure SQL Database, Azure
SQL Managed Instance, and Synapse SQL in Azure Synapse Analytics by using identities in Azure AD.

NOTE
This article applies to Azure SQL Database, SQL Managed Instance, and Azure Synapse Analytics.

With Azure AD authentication, you can centrally manage the identities of database users and other Microsoft
services in one central location. Central ID management provides a single place to manage database users and
simplifies permission management. Benefits include the following:
It provides an alternative to SQL Server authentication.
It helps stop the proliferation of user identities across servers.
It allows password rotation in a single place.
Customers can manage database permissions using external (Azure AD) groups.
It can eliminate storing passwords by enabling integrated Windows authentication and other forms of
authentication supported by Azure Active Directory.
Azure AD authentication uses contained database users to authenticate identities at the database level.
Azure AD supports token-based authentication for applications connecting to SQL Database and SQL
Managed Instance.
Azure AD authentication supports:
Azure AD cloud-only identities.
Azure AD hybrid identities that support:
Cloud authentication with two options coupled with seamless single sign-on (SSO) Pass-
through authentication and password hash authentication.
Federated authentication.
For more information on Azure AD authentication methods and which one to choose, see the
following article:
Choose the right authentication method for your Azure Active Directory hybrid identity
solution
Azure AD supports connections from SQL Server Management Studio that use Active Directory Universal
Authentication, which includes Multi-Factor Authentication. Multi-Factor Authentication includes strong
authentication with a range of easy verification options — phone call, text message, smart cards with pin,
or mobile app notification. For more information, see SSMS support for Azure AD Multi-Factor
Authentication with Azure SQL Database, SQL Managed Instance, and Azure Synapse
Azure AD supports similar connections from SQL Server Data Tools (SSDT) that use Active Directory
Interactive Authentication. For more information, see Azure Active Directory support in SQL Server Data
Tools (SSDT)
 NOTE
Connecting to a SQL Server instance that's running on an Azure virtual machine (VM) is not supported using an Azure
Active Directory account. Use a domain Active Directory account instead.

The configuration steps include the following procedures to configure and use Azure Active Directory
authentication.
1. Create and populate Azure AD.
2. Optional: Associate or change the active directory that is currently associated with your Azure Subscription.
3. Create an Azure Active Directory administrator.
4. Configure your client computers.
5. Create contained database users in your database mapped to Azure AD identities.
6. Connect to your database by using Azure AD identities.

NOTE
To learn how to create and populate Azure AD, and then configure Azure AD with Azure SQL Database, SQL Managed
Instance, and Synapse SQL in Azure Synapse Analytics, see Configure Azure AD with Azure SQL Database.

Trust architecture
Only the cloud portion of Azure AD, SQL Database, SQL Managed Instance, and Azure Synapse is considered
to support Azure AD native user passwords.
To support Windows single sign-on credentials (or user/password for Windows credential), use Azure Active
Directory credentials from a federated or managed domain that is configured for seamless single sign-on for
pass-through and password hash authentication. For more information, see Azure Active Directory Seamless
Single Sign-On.
To support Federated authentication (or user/password for Windows credentials), the communication with
ADFS block is required.
For more information on Azure AD hybrid identities, the setup, and synchronization, see the following articles:
Password hash authentication - Implement password hash synchronization with Azure AD Connect sync
Pass-through authentication - Azure Active Directory Pass-through Authentication
Federated authentication - Deploying Active Directory Federation Services in Azure and Azure AD Connect
and federation
For a sample federated authentication with ADFS infrastructure (or user/password for Windows credentials), see
the diagram below. The arrows indicate communication pathways.
The following diagram indicates the federation, trust, and hosting relationships that allow a client to connect to a
database by submitting a token. The token is authenticated by an Azure AD, and is trusted by the database.
Customer 1 can represent an Azure Active Directory with native users or an Azure AD with federated users.
Customer 2 represents a possible solution including imported users, in this example coming from a federated
Azure Active Directory with ADFS being synchronized with Azure Active Directory. It's important to understand
that access to a database using Azure AD authentication requires that the hosting subscription is associated to
the Azure AD. The same subscription must be used to create the Azure SQL Database, SQL Managed Instance, or
Azure Synapse resources.

Administrator structure
When using Azure AD authentication, there are two Administrator accounts: the original Azure SQL Database
administrator and the Azure AD administrator. The same concepts apply to Azure Synapse. Only the
administrator based on an Azure AD account can create the first Azure AD contained database user in a user
database. The Azure AD administrator login can be an Azure AD user or an Azure AD group. When the
administrator is a group account, it can be used by any group member, enabling multiple Azure AD
administrators for the server. Using group account as an administrator enhances manageability by allowing you
to centrally add and remove group members in Azure AD without changing the users or permissions in SQL
Database or Azure Synapse. Only one Azure AD administrator (a user or group) can be configured at any time.

Permissions
To create new users, you must have the ALTER ANY USER permission in the database. The ALTER ANY USER
permission can be granted to any database user. The ALTER ANY USER permission is also held by the server
administrator accounts, and database users with the CONTROL ON DATABASE or ALTER ON DATABASE permission for
that database, and by members of the db_owner database role.
To create a contained database user in Azure SQL Database, SQL Managed Instance, or Azure Synapse, you must
connect to the database or instance using an Azure AD identity. To create the first contained database user, you
must connect to the database by using an Azure AD administrator (who is the owner of the database). This is
demonstrated in Configure and manage Azure Active Directory authentication with SQL Database or Azure
Synapse. Azure AD authentication is only possible if the Azure AD admin was created for Azure SQL Database,
SQL Managed Instance, or Azure Synapse. If the Azure Active Directory admin was removed from the server,
existing Azure Active Directory users created previously inside SQL Server can no longer connect to the
database using their Azure Active Directory credentials.

Azure AD features and limitations

The following members of Azure AD can be provisioned for Azure SQL Database:
Native members: A member created in Azure AD in the managed domain or in a customer domain.
For more information, see Add your own domain name to Azure AD.
Members of an Active Directory domain federated with Azure Active Directory on a managed domain
configured for seamless single sign-on with pass-through or password hash authentication. For more
information, see Microsoft Azure now supports federation with Windows Server Active Directory and
Azure Active Directory Seamless Single Sign-On.
Imported members from other Azure AD's who are native or federated domain members.
 Active Directory groups created as security groups.
Azure AD users that are part of a group that has db_owner server role cannot use the CREATE
DATABASE SCOPED CREDENTIAL syntax against Azure SQL Database and Azure Synapse. You will see
the following error:
SQL Error [2760] [S0001]: The specified schema name '[email protected]' either does not exist or you
do not have permission to use it.

Grant the db_owner role directly to the individual Azure AD user to mitigate the CREATE DATABASE
SCOPED CREDENTIAL issue.
These system functions return NULL values when executed under Azure AD principals:
SUSER_ID()
SUSER_NAME(<admin ID>)
SUSER_SNAME(<admin SID>)
SUSER_ID(<admin name>)
SUSER_SID(<admin name>)

SQL Managed Instance

Azure AD server principals (logins) and users are supported for SQL Managed Instance.
Setting Azure AD server principals (logins) mapped to an Azure AD group as database owner is not
supported in SQL Managed Instance.
An extension of this is that when a group is added as part of the dbcreator server role, users from
this group can connect to the SQL Managed Instance and create new databases, but will not be able to
access the database. This is because the new database owner is SA, and not the Azure AD user. This
issue does not manifest if the individual user is added to the dbcreator server role.
SQL Agent management and jobs execution are supported for Azure AD server principals (logins).
Database backup and restore operations can be executed by Azure AD server principals (logins).
Auditing of all statements related to Azure AD server principals (logins) and authentication events is
supported.
Dedicated administrator connection for Azure AD server principals (logins) which are members of sysadmin
server role is supported.
Supported through SQLCMD Utility and SQL Server Management Studio.
Logon triggers are supported for logon events coming from Azure AD server principals (logins).
Service Broker and DB mail can be setup using an Azure AD server principal (login).

Connect by using Azure AD identities

Azure Active Directory authentication supports the following methods of connecting to a database using Azure
AD identities:
Azure Active Directory Password
Azure Active Directory Integrated
Azure Active Directory Universal with Multi-Factor Authentication
Using Application token authentication
The following authentication methods are supported for Azure AD server principals (logins):
Azure Active Directory Password
Azure Active Directory Integrated
Azure Active Directory Universal with Multi-Factor Authentication
Additional considerations
 To enhance manageability, we recommend you provision a dedicated Azure AD group as an administrator.
Only one Azure AD administrator (a user or group) can be configured for a server in SQL Database or Azure
Synapse at any time.
The addition of Azure AD server principals (logins) for SQL Managed Instance allows the possibility of
creating multiple Azure AD server principals (logins) that can be added to the sysadmin role.
Only an Azure AD administrator for the server can initially connect to the server or managed instance using
an Azure Active Directory account. The Active Directory administrator can configure subsequent Azure AD
database users.
Azure AD users and service principals (Azure AD applications) that are members of more than 2048 Azure
AD security groups are not supported to login into the database in SQL Database, Managed Instance, or
Azure Synapse.
We recommend setting the connection timeout to 30 seconds.
SQL Server 2016 Management Studio and SQL Server Data Tools for Visual Studio 2015 (version
14.0.60311.1April 2016 or later) support Azure Active Directory authentication. (Azure AD authentication is
supported by the .NET Framework Data Provider for SqlSer ver ; at least version .NET Framework 4.6).
Therefore the newest versions of these tools and data-tier applications (DAC and BACPAC) can use Azure AD
authentication.
Beginning with version 15.0.1, sqlcmd utility and bcp utility support Active Directory Interactive
authentication with Multi-Factor Authentication.
SQL Server Data Tools for Visual Studio 2015 requires at least the April 2016 version of the Data Tools
(version 14.0.60311.1). Currently, Azure AD users are not shown in SSDT Object Explorer. As a workaround,
view the users in sys.database_principals.
Microsoft JDBC Driver 6.0 for SQL Server supports Azure AD authentication. Also, see Setting the Connection
Properties.
PolyBase cannot authenticate by using Azure AD authentication.
Azure AD authentication is supported for Azure SQL Database and Azure Synapse by using the Azure portal
Impor t Database and Expor t Database blades. Import and export using Azure AD authentication is also
supported from a PowerShell command.
Azure AD authentication is supported for SQL Database, SQL Managed Instance, and Azure Synapse with
using the CLI. For more information, see Configure and manage Azure AD authentication with SQL Database
or Azure Synapse and SQL Server - az sql server.

Next steps
To learn how to create and populate an Azure AD instance and then configure it with Azure SQL Database,
SQL Managed Instance, or Azure Synapse, see Configure and manage Azure Active Directory authentication
with SQL Database, SQL Managed Instance, or Azure Synapse.
For a tutorial of using Azure AD server principals (logins) with SQL Managed Instance, see Azure AD server
principals (logins) with SQL Managed Instance
For an overview of logins, users, database roles, and permissions in SQL Database, see Logins, users,
database roles, and permissions.
For more information about database principals, see Principals.
For more information about database roles, see Database roles.
For syntax on creating Azure AD server principals (logins) for SQL Managed Instance, see CREATE LOGIN.
For more inform