Contents

Azure SQL Documentation

Azure SQL
What is Azure SQL?
Migrate to Azure SQL
Migrating SQL Server Workloads FAQ
Shared SQL DB & SQL MI docs
Billing options
vCore purchasing model
Azure Hybrid Benefit
Reserved capacity
Service tiers
General Purpose
Business Critical
Shared concepts
Feature comparison
Multi-model features
In-memory OLTP
Temporal tables
Scale up / down
Read Scale-Out
Distributed transactions
Scheduled maintenance
Maintenance window
Configure maintenance window
Maintenance window FAQ
Advance notifications
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
Server principals (logins)
Service principals (Applications)
Directory Readers role
Azure AD-only authentication
Azure Policy for Azure AD-only authentication
User-assigned managed identity
Transparent Data Encryption (TDE)
Overview
Bring Your Own Key (BYOK)
Managed identities with BYOK
Business continuity
Overview
High availability
Backup and recovery
 Accelerated database recovery
Long-term backup retention
Monitor and tune
Documentation
Overview
Intelligent Insights
SQL Analytics
SQL Insights (preview)
Overview
Enable
Alerts
Troubleshoot
Automatic tuning
In-memory OLTP
Extended events
Extended events
Extended events - event file
Extended events - ring buffer
Shared how-to's
Connect and query from apps
.NET with Visual Studio
.NET with Windows, Linux, and macOS
Go
Node.js
PHP
Python
Ruby
Business continuity
Configure temporal retention policy
Configure long-term backup retention
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
Create and utilize Azure AD server logins
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
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?
Try for free
Quickstarts
Create database
Azure portal, PowerShell, Az CLI
Hyperscale
Bicep
ARM template
With ledger and digest storage
With user-assigned managed identity
Configure
Server-level IP firewall rules
Database project in a local dev environment
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
Concepts
Single databases
Elastic pools
Logical servers
Serverless
Hyperscale
Overview
Hyperscale architecture
Hyperscale backups
Replicas
FAQ
Purchasing models
Overview
vCore model
DTU model
Connectivity
 Connectivity architecture
Connectivity settings
Local development
Local dev experience
The Azure SQL DB emulator
SQL Database Projects extension >>
The mssql extension >>
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
Database verification
Monitor digest uploads
Recover ledger database after tampering
Ledger limitations
Network access controls
Outbound firewall rules
Private Link
VNet endpoints
 Server roles
Business continuity
Automated backups
Active geo-replication
Auto-failover groups
Outage recovery guidance
Recovery drills
SQL Data Sync
Overview
Data Sync Agent
Best practices for Data Sync
Troubleshoot Data Sync
Database sharding
Database sharding
Elastic transactions
Elastic queries
Elastic client library
Shard maps
Query routing
Manage credentials
Move sharded data
Elastic tools FAQ
Glossary
Resource limits
Logical server limits
Single database resources
vCore resource limits
DTU resource limits
Elastic pool resources
vCore resource limits
DTU resource limits
Migration guides
 From Access
From Db2
From Oracle
From MySQL
From SAP ASE
From SQL Server
Overview
Migrate
Assessment rules
How to
T-SQL differences
Plan and manage costs
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
Develop locally
Set up local dev environment
Create a database project
Publish a database project to the local emulator
Monitor & Tune
Identify query performance bottlenecks
Use DMVs to monitor performance
Azure Monitor for SQL Database
 Azure Monitor for SQL Database reference
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
Manage Hyperscale databases
Hyperscale performance diagnostics
Block T-SQL CRUD
Azure Automation
Elastic jobs (preview)
Job automation with elastic jobs
Configure jobs
Create and manage (PowerShell)
Create and manage (T-SQL)
Migrate (from old Elastic jobs)
Secure
Audit to storage account behind VNet or firewall
Configure threat detection
Configure dynamic data masking
Create server configured with UMI and customer-managed TDE
IP-based firewall
Ledger
Create append-only ledger tables
Create updatable ledger tables
Convert regular tables into ledger tables
How to configure automatic database digests
 Verify ledger database for tampering
vNet endpoints - PowerShell
Business continuity
Change automated backup settings
Configure backup retention using Azure Blob storage
Recover using backups
Create auto-failover group
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
Diagnose and troubleshoot high CPU
Understand and resolve blocking
Analyze and prevent deadlocks
Configure the max degree of parallelism (MAXDOP)
Load and move data
Migrate to SQL Database
Manage SQL Database after migration
Import/export (allow Azure services disabled)
Import/export using Private endpoints
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
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
Samples overview
Create databases
Create single database
Create pooled database
Scale databases
Scale single database
Scale pooled database
Configure geo-replication
Single database
Pooled database
Configure failover group
Failover group
Single database
Pooled database
Database back up, restore, copy, and import
Back up a database
Restore a database
Copy a database to a new server
Import a database from a BACPAC file
Azure PowerShell
Azure Resource Manager
 Code samples
Azure Resource Graph queries
Azure SQL Managed Instance (SQL MI)
Documentation
Overview
What is Azure SQL Managed Instance?
What's new?
Resource limits
vCore purchasing model
Frequently asked questions
Quickstarts
Create Azure SQL Managed Instance
Azure portal
PowerShell
Bicep
ARM template
Create instance pools
With user-assigned managed identity
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
Connectivity architecture
Automated backups
Auto-failover groups
T-SQL differences
Transactional replication
Managed Instance link
Instance pools
Data virtualization
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
Windows Auth for Azure AD Principals
Overview
Implementation with Kerberos
Setup summary
Set up the modern interactive flow
Set up the incoming trust-based flow
Set up managed instances
Run a trace using Windows Auth
Troubleshoot
How to
How-to documentation
Connect applications
Job automation with SQL Agent
Monitor & Tune
Identify query performance bottlenecks
Use DMVs to monitor performance
Azure Monitor for Azure SQL Managed Instance
Azure Monitor for Azure SQL Managed Instance reference
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
Find management endpoint IP address
Verify built-in firewall protection
Migrate
Database using Log Replay Service
TDE certificate
Managed Instance link
Prepare environment for link
SQL Server 2016 prerequisites
Replicate databases in SSMS
Replicate databases with scripts
Failover databases in SSMS
Failover databases with scripts
Best practices
Configure business continuity
Change backup settings
Recover using backups
Restore to a point in time
Monitor backup
Auto-failover groups
 Create failover group
Manually initiate a failover
Samples
Azure CLI
Samples overview
Create Azure SQL Managed Instance
Configure transparent data encryption (TDE)
Restore geo-backup
Azure PowerShell
Samples overview
Configure transparent data encryption (TDE)
Azure Resource Manager
Code samples
SQL Server on Azure VMs
Documentation
What's new?
Windows
Overview
What is a SQL Server VM?
SQL IaaS Agent extension
Quickstarts
Portal
PowerShell
Bicep
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
Dedicated host
Extend support for SQL Server
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 best practices 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)
Using distributed AG
Prerequisites
Standalone instance
Availability group
Complete migration
Reference
Azure SQL glossary of terms
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
DTU benchmark
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 Azure 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?
9/13/2022 • 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.
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 platform as a service (PaaS) and infrastructure as a service (IaaS) options include base price that
covers underlying infrastructure and licensing. However, with the 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 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.

Migration from SQL Server might be There is still some minimal number of You may use manual or automated
challenging. SQL Server features that are not backups.
Some SQL Server features are not available. You need to implement your own
available. Configurable maintenance windows. High-Availability solution.
Configurable maintenance windows. Compatibility with the SQL Server There is a downtime while changing
Compatibility with the SQL Server version can be achieved only using the resources(CPU/storage)
version can be achieved only using database compatibility levels.
database compatibility levels.
Private IP address support with Azure
Private Link.
 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

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 Server on Azure virtual machines (VMs).
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 databases in Azure SQL Database as well as the logical server hosting them, SQL Managed Instances, and SQL
Server on Azure VMs. 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 +
Create .

After selecting + Create , 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.
 Migrate SQL Server workloads (FAQ)
9/13/2022 • 22 minutes to read • Edit Online

Applies to: SQL Server Azure SQL Database Azure SQL Managed Instance SQL Server on
Azure VM
Migrating on-premises SQL Server workloads and associated applications to the cloud usually brings a wide
range of questions which go beyond mere product feature information.
This article provides a holistic view and helps understand how to fully unlock the value when migrating to Azure
SQL. The Modernize applications and SQL section covers questions about Azure SQL in general as well as
common application and SQL modernization scenarios. The Business and technical evaluation section
covers cost saving, licensing, minimizing migration risk, business continuity, security, workloads and
architecture, performance and similar business and technical evaluation questions. The last section covers the
actual Migration and modernization process , including guidance on migration tools.

Modernize applications and SQL

Azure SQL
What are the benefits of moving applications and SQL Server workloads to Azure?
A migration to Azure brings optimized costs, flexibility and scalability, enhanced security, compliance, improved
business continuity, and simplified management and monitoring.
What is Azure SQL?
Azure SQL is a family of services that use the SQL Server database engine in the Azure Cloud. The following
services belong to Azure SQL: Azure SQL Database (SQL Database), Azure SQL Managed Instance (SQL
Managed Instance) and SQL Server on Azure VMs.
What is the difference between migration and modernization to Azure SQL?
Migration to Azure SQL involves moving applications, infrastructure, and data from one location (for
example, a company's on-premises datacenter) to Azure infrastructure. For SQL Server customers, this means
migrating your workloads while minimizing impact to operations. You can reduce IT costs, enhance security and
resilience, and achieve on-demand scale.
Modernization to Azure SQL involves updating existing applications for newer computing approaches and
application frameworks and use of cloud-native technologies. This can be achieved by using PaaS services such
as Azure SQL Database and Azure SQL Managed Instance, which provides extra benefits of app innovation,
agility, developer velocity, and cost optimization.
What does IaaS and PaaS mean?
Infrastructure as a ser vice (IaaS) is a type of cloud computing service that offers essential compute, storage,
and networking resources on demand.
Platform as a ser vice (PaaS) is a complete development and deployment environment in the cloud, with
resources that enable you to deliver everything from simple cloud-based apps to sophisticated, cloud-enabled
enterprise applications.
PaaS provides additional advantages over IaaS, such as shorter development cycles, extra development
capabilities without adding staff, affordable access to sophisticated tools, to mention a few. Azure SQL provides
both PaaS (SQL Managed Instance, SQL Database) and IaaS (SQL VM) services.
How do I decide if I should move my SQL Server to a Virtual Machine, SQL Managed Instance or SQL Database?
SQL Managed Instance is the right PaaS target to modernize your existing SQL Server applications at
 scale providing almost all SQL Server features (including instance-level features) while reducing the costs
of server and database management.
SQL Database is the most appropriate choice when building native cloud applications, as it offers high
elasticity and flexibility of choosing between architectural and compute tiers, such as Serverless tier for
increased elasticity and Hyperscale tier for a highly scalable storage and compute resources.
If you need full control and customization, including OS access, you can opt for SQL Ser ver on Azure
VM . The service comparison provides more details. A range of migration tools helps making the optimal
choice by providing an assessment of target service compatibility and costs.
How can I reduce costs by moving to Azure SQL?
Moving to Azure brings savings in resource, maintenance, and real estate costs, in addition to the ability to
optimize workloads so that they cost less to run. Azure SQL Managed Instance and SQL Database bring all the
advantages of PaaS services, providing automated performance tuning, backups, software patching and high-
availability, all of which entails enormous effort and cost when performing manually.
For example, SQL Managed Instance and SQL Database (single database and elastic pool) come with built-in HA.
Also, Business Critical (SQL Managed Instance) and Premium (SQL Database) tiers provide read-only replicas at
no additional cost, while SQL Database Hyperscale tier allows HA and named secondary replicas for read scale-
out at no license cost. Additionally, Software Assurance customers can use their on-premises SQL Server license
on Azure by applying Azure Hybrid Benefit (AHB). Software Assurance also lets you implement free passive HA
and DR secondaries using SQL VM.
In addition, every Azure SQL service provides you the option to reserve instances in advance (1-3 years) and
obtain significant additional savings. Dev/Test pricing plans provide a way to further reduce development costs.
Finally, check the following article on how you can Optimize your Azure SQL Managed Instance cost with
Microsoft Azure Well-Architected Framework.
What is the best licensing path to save costs when moving existing SQL Server workloads to Azure?
Unique to Azure, Azure Hybrid Benefit (AHB) is a licensing benefit that allows you bringing your existing
Windows Server and SQL Server licenses with Software Assurance (SA) to Azure. Combined with reservations
savings and extended security updates, AHB can bring you up to 85% savings compared to pay-as-you-go
pricing in Azure SQL. In addition, make sure to check different Dev/Test pricing plans.
Applications and SQL modernization scenarios
Scenario 1: Data center move to the cloud: what is the modernization path for applications and SQL Server databases?
Updating an organization's existing apps to a cloud first model can be achieved by using fully managed
application and data services including Azure App Service, Azure Spring Apps, Azure SQL Database, Azure SQL
Managed Instance and other PaaS services. Azure Kubernetes Services (AKS) provides a managed container-
based approach within Azure. Application and Data Modernization in Azure is achieved through several stages,
with the most common scenario examples described within the Cloud Adoption Framework.
Scenario 2: Reducing SQL Server costs: How can I reduce the cost for my existing SQL Server fleet?
Moving to Azure SQL VMs, SQL Managed Instance or SQL Database brings savings in resource, maintenance,
and real estate costs. Using your SQL Server on-premises licenses in Azure via Azure Hybrid Benefit, using
Azure Reservations for SQL VM, SQL Managed Instance and SQL Database vCores, and using constrained vCPU
capable Virtual Machines will give you a wide variety of options to build a cost-effective solution.
For implementing BCDR solutions in Azure SQL, you benefit from built-in HA replicas of SQL Managed Instance
and SQL Database or free passive HA and DR secondaries using SQL VM. Also, Business Critical (SQL Managed
Instance) and Premium (SQL Database) tiers provide read-only replicas at no additional cost, while SQL
Database Hyperscale tier allows HA and named secondary replicas for read scale-out at no license cost. In
addition, make sure to check different Dev/Test pricing plans.
If you're interested to understand how you can save up to 64% by moving to Azure SQL please check ESG report
on The Economic Value of Migrating On-Premises SQL Server Instances to Microsoft Azure SQL Solutions.
Finally, check the following article on how you can Optimize your Azure SQL Managed Instance cost with
Microsoft Azure Well-Architected Framework.
Scenario 3: Optimize application portfolio: How can I at the same time modernize both my application portfolio and SQL Server
instances?
Application and Data Modernization in Azure is achieved through several stages, with the most common
scenario examples described within the Cloud Adoption Framework.
Scenario 4: SQL Server end of support: Which options do I have to move to Azure SQL?
Once your SQL Server has reached the end of support stage, you have several modernization options towards
Azure SQL. One of the options is to migrate your workload to an Azure SQL Managed Instance, which provides
high feature parity with the on-premises SQL Server product. Alternatively, with some additional effort, you can
move the workload to Azure SQL Database. These services run on SQL Server evergreen features, effectively
granting you "the end of End of Support".
Backward compatibility is provided via compatibility levels and database compatibility level settings. Tools like
Azure SQL Migration extension in Azure Data Studio or Data Migration Assistant will help you identify possible
incompatibilities.
Whenever a Platform-as-a-Service (PaaS) solution doesn't fit your workload, Azure SQL Virtual Machines
provide the possibility to do an as-is migration. By moving to Azure SQL VM, you'll also receive free extended
security patches which can provide significant savings (for example, up to 69% for SQL Server 2012).
Scenario 5: Meeting regulatory compliance: How does Azure SQL help meet regulatory compliance requirements?
Azure Policy has built-in policies that help organizations meet regulatory compliance. Ad-hoc and customized
policies can also be created. For more information, see Azure Policy Regulatory Compliance controls for Azure
SQL Database and SQL Managed Instance. For an overview of compliance offerings, you can consult Azure
compliance documentation.
Getting started, the holistic approach
How to prepare a migration business case?
The Microsoft Cloud Adoption Framework for Azure is a great starting point to help you create and implement
the business and technology strategy necessary for your move to Azure.
Where can I find migration guides for Azure SQL?
The following guides help you discover, assess, and migrate from SQL Server to SQL VM, SQL Managed
Instance and SQL Database.
Do I have to modernize applications and SQL at the same time? What are my options?
No. Feel free to take an iterative approach to modernizing each workload and component.
Can I modernize SQL Server to SQL Managed Instance and just lift and shift my application to a VM?
Yes. You can Connect your application to Azure SQL Managed Instance through different scenarios, including
when hosting it on a VM.

Business and technical evaluation

Total cost of ownership, licensing and benefits
How can I estimate Total Cost of Ownership (TCO) savings when moving to Azure SQL?
Moving to Azure SQL brings significant TCO savings by improving operational efficiency and business agility, as
well as eliminating the need for on-premises hardware and software. According to ESG report on The Economic
Value of Migrating On-Premises SQL Server Instances to Microsoft Azure SQL Solutions, you can save up to
47% when migrating from on-premises to Azure SQL Virtual Machines (IaaS), and up to 64% when migrating to
Azure SQL Managed Instance or Azure SQL Database (PaaS).
What is the licensing model for SQL Managed Instance?
SQL Managed Instance licensing follows vCore-based licensing model, where you pay for compute, storage, and
backup storage resources. You can choose between several service tiers (General Purpose, Business Critical) and
hardware generations. The SQL Managed Instance pricing page provides a full overview of possible SKUs and
prices.
What is the licensing model for SQL Database?
SQL Database provides a choice between the vCore-based purchasing model and Database transaction unit
purchasing model. You can explore Pricing - Azure SQL Database Single Database and learn about pricing
options.
What subscription types are supported in SQL Managed Instance?
Check Supported subscription types for SQL Managed Instance.
Can I use my on-premises SQL Server license when moving to Azure SQL?
If you own Software Assurance for core-based or qualifying subscription licenses for SQL Server Standard
Edition or SQL Server Enterprise Edition, you can use your existing SQL Server license when moving to SQL
Managed Instance, SQL Database or Azure VM by applying Azure Hybrid Benefit (AHB). You can also
simultaneously use these licenses both in on-premises and Azure environments (dual use rights) for up to 180
days.
How do I move from SQL VM to SQL Managed Instance?
You can follow the same migration guide as for the on-premises SQL Server.
I'm using SQL Server subscription license. Can I use it to move to Azure SQL?
Yes, qualifying subscription licenses can be used to pay Azure SQL services at a reduced (base) rate by applying
Azure Hybrid Benefit (AHB).
I'm using SQL Server CAL licenses. How can I move to Azure SQL?
SQL Server CAL licenses with appropriate license mobility rights can be used on Azure SQL VMs, and on Azure
SQL Dedicated Host.
What is Azure Hybrid Benefit (AHB)?
Unique to Azure, Azure Hybrid Benefit (AHB) is a licensing benefit that allows you bringing your existing
Windows Server and SQL Server licenses with Software Assurance (SA) to Azure. AHB can bring you up to 85%
savings compared to pay-as-you-go pricing in Azure SQL, when combined with reservations savings and
extended security updates.
How do I translate my SQL Server on-premises license to vCore license in SQL Managed Instance, SQL Database, and SQL VM?
For every one (1) core of SQL Server Enterprise Edition, you get four (4) vCores of SQL Managed Instance
General Purpose tier or one (1) vCore of SQL Managed Instance Business Critical tier. Similarly, one (1) core of
SQL Server Standard Edition translates to one (1) vCore of SQL Managed Instance General Purpose tier, while
four (4) vCores of SQL Server Standard Edition translate to one (1) vCore of SQL Managed Instance Business
Critical.
The Azure Hybrid Benefit August 2020 update provides an overview of possible core-to-vCore conversions for
SQL Managed Instance, SQL Database and SQL VM. Applicable AHB rights are also described in the Product
Terms. You can also use the Azure Hybrid Benefit Savings Calculator to calculate the exact savings for your SQL
Server estate.
Is Software Assurance (SA) required for using SQL Server license on Azure SQL?
Software Assurance is a licensing program that can be applied to on-premises SQL Server licenses, allowing
license mobility, AHB, and other benefits. SA is required if AHB is to be invoked for using existing SQL Server
licenses (with SA) when moving to Azure SQL. Without SA + AHB, customers are charged with PAYG pricing.
Alternatively, the outsourcing software management terms applicable to SQL server licenses acquired prior to
October 1, 2019 permit you to allocate your existing licenses to Azure Dedicated Host just as you would license
a server in your own data center: see Pricing - Dedicated Host Virtual Machines.
Do I have to pay for high availability (HA) in SQL Managed Instance and SQL Database?
Both General Purpose and Business Critical tiers of SQL Managed Instance and SQL Database are built on top of
inherent high availability architecture. This way, there's no extra charge for HA. For SQL Database Hyperscale tier
HA replica is charged.
Do I have to pay for HA and DR replicas for Azure SQL?
If you have Software Assurance, on Azure SQL VM you can implement high availability (HA) and disaster
recovery (DR) plans with SQL Server without incurring additional licensing costs for the passive disaster
recovery instance. See the SQL VM documentation for more details.
Do I have to pay for disaster recovery (DR) in SQL Managed Instance and SQL Database?
Yes. These are separate costs.
Can I centrally manage Azure Hybrid Benefit for SQL Server across the entire Azure subscription?
Yes. You can centrally manage your Azure Hybrid Benefit for SQL Server across the scope of an entire Azure
subscription or overall billing account. This feature is currently in preview.
If I move some of SQL Servers, my workloads to SQL Managed Instance and leave some workloads on-premises, can I manage all
my SQL licenses in one place?
You can centrally manage your licenses that are covered by Azure Hybrid Benefit for SQL Server across the
scope of an entire Azure subscription or overall billing account. This data can be combined with an overview
maintained by your licensing partner/procurement department or obtaining licensing information by creating
your own custom licensing overview. Your licenses must be used either on-premises or in the cloud, but you'll
have 180 days of concurrent use rights while migrating servers.
How can I minimize downtime during the online migration?
The Link feature for Azure SQL Managed Instance offers the best possible minimum downtime online
migrations solution, meeting the needs of the most critical tier-1 applications. You can consult a full range of
migration tools and technologies choose the optimal for your use scenario.
Risk free migration with a hybrid strategy
Can I keep running on-premises, while modernizing my applications in Azure?
With SQL Server 2016, 2017, 2019, and 2022, you can use the Link feature for Azure SQL Managed Instance to
create a hybrid connection between SQL Server and Azure SQL Managed Instance. Data is replicated near real-
time from SQL Server to Azure, and can be used to modernize your workloads in Azure. You can use the
replicated data in Azure for read scale-out and for offloading analytics.
For how long can I keep the hybrid solution using Link feature for Azure SQL Managed Instance running?
You can keep running the hybrid link for as long as needed: weeks, months, years at a time, there are no
restrictions on this.
Can I apply a hybrid approach and use Link feature for Azure SQL Managed Instance in order to validate my migration strategy,
before migrating to Azure?
Yes, you can use your replicated data in Azure to test and validate your migration strategy (performance,
workloads and applications) prior to migrating to Azure.
Can I reverse migrate out of Azure SQL and go back to SQL Server if necessary?
With SQL Server 2022, we offer the best possible solution to seamlessly move data back with native backup and
restore from SQL Managed Instance to SQL Server, completely de-risking the migrations strategy to Azure.
Workloads and architecture
How do I determine which SQL Server workloads should be moved to SQL Managed Instance?
When migrating SQL Server workloads to Azure SQL Managed Instance is normally the first option, as most
databases are "as-is" ready to migrate to SQL Managed Instance. There are several tools available to help you
assess your workload for compatibility with Azure SQL Managed Instance.
You can use the Azure SQL Migration extension in Azure Data Studio or Data Migration Assistant. Both tools
provide help to detect issues that can affect the Azure SQL Managed Instance migration and provide guidance
on how to resolve them. After verifying compatibility, you can run the SKU recommendation tool to analyze
performance data and recommend a minimal Azure SQL Managed Instance SKU. Make sure to visit Azure
Migrate which is a centralized hub to assess and migrate on-premises servers, infrastructure, applications, and
data to Azure.
How do I determine the appropriate SQL Managed Instance target for a particular SQL Server on-premises workload: SQL Managed
Instance General Purpose or Business Critical tier?
SQL Managed Instance tier choice is guided by availability, performance (for example, throughput, OIPS, latency)
and feature (for example, in-memory OLTP) requirements. The General Purpose tier is suitable for most generic
workloads, as it already provides HA architecture and a fully managed database engine with a storage latency
between 5 ms and 10 ms. The Business Critical tier is designed for applications that require low-latency (1-2 ms)
responses from the storage layer, fast recovery, strict availability requirements, and the ability to off-load
analytics workloads.
How can I move a highly automated SQL Server to SQL Managed Instance?
Infrastructure deployment automation of Azure SQL can be done with PowerShell and CLI. Useful examples
can be found in the Azure PowerShell samples for Azure SQL Database and Azure SQL Managed Instance article.
You can use Azure DevOps Continuous Integration (CI) and Deployment (CD) Pipelines to fully embed
automation within your Infrastructure-as-Code practices.
Building your database models and scripts can also be integrated through Database Projects with Visual
Studio Code or Visual Studio. The use of Azure DevOps CI/CD pipelines will enable deployment of your
Database Projects to an Azure SQL destination of your choice. Finally, service automation via third party tools is
also possible. For more information, see Azure SQL Managed Instance – Terraform command.
Can I move only a specific workload out of an on-premises cluster and what will be the impact to licensing and cost?
It's possible to only migrate the databases related to one workload towards an Azure SQL Managed Instance.
Creating and operating an Azure SQL Managed Instance will require SQL Server licenses. Azure Hybrid Benefit
will provide you with the ability to reuse your licenses. Reach out to your licensing partner to review what
possibilities can be used with license mobility and restructuring your current licenses.
I maintain a highly consolidated SQL Server with multiple applications running against it. Can I move it to SQL Managed Instance?
Similarly as with on-premises SQL Server, you can consolidate and run multiple databases on a single SQL
Managed Instance instance, at the same time benefiting from inherent high-availability architecture as well as
shared security and management. SQL Managed Instance also supports cross database queries.
How do I migrate SQL Server Business Intelligence workloads (including Reporting Services and Analysis Services ) that aren't
compatible with SQL Managed Instance?
Least effort migration path will be to move as-is and host the Business Intelligence components on an Azure
VM. The Reporting Services database can be hosted on Azure SQL Managed Instance and Azure Data Factory
provides the capability to lift and shift SSIS solutions to the cloud. When building a modern solution is part of
the migration effort, Azure is providing a wide variety of services to build an Enterprise data warehouse
solution.
I'm using an application from an ISV that doesn't support SQL Managed Instance / Azure. What are my options to move my
application to Azure and SQL Server to Azure SQL?
Migrating your environment as-is to an Azure Virtual Machine will be the safest option when the ISV or vendor
isn't providing any options. However, we encourage ISVs and vendors that are working closely with Microsoft to
review the options with Azure SQL Managed Instance. Azure SQL Managed Instance provides backward
compatibility options through database compatibility level, guidance for Transact-SQL differences and has
implemented major features to Azure SQL Managed instance.
How do I keep the compatibility of my current SQL Server database version in SQL Managed Instance?
Database compatibility level can be set in Managed Instance, as described on the Azure SQL Blog.
Security
How does Azure SQL help in enhancing the database security posture?
The security strategy follows the layered defense-in-depth approach: Network security + Access management +
Threat protection + Information Protection. You can read more about SQL Database and SQL Managed Instance
security capabilities. Azure-wide, Microsoft Defender for Cloud provides a solution for Cloud Security Posture
Management (SCPM) and Cloud Workload Protection (CWP).
Business continuity
How can I adapt on-premises business continuity and disaster recovery (BCDR) concepts into Azure SQL Managed Instance
concepts?
Most Azure SQL BCDR concepts have an equivalent in on-premises SQL Server implementations. For example,
the inherent high availability of SQL Managed Instance General Purpose tier can be seen as a cloud equivalent
for SQL Server FCI. Similarly, SQL Managed Instance Business Critical tier can be seen as a cloud equivalent for
an Always On Availability Group with synchronous commit to a minimum number of replicas. As a Disaster
Recovery concept, an Auto-failover Group on SQL Managed Instance is comparable to an Asynchronous Always
On Availability Group with asynchronous commit. SQL Database and SQL Managed Instance HA are backed by
Service-Level Agreements. You can find more on SQL Database and SQL Managed Instance Business Continuity
in the official documentation.
How are backups handled in Azure SQL PaaS services?
You can check documentation for automated backups in SQL Managed Instance and SQL Database to learn
about RPO, RTO, retention, scheduling and other backup capabilities and features.
How is high availability (HA) achieved in SQL Managed Instance and SQL Database?
SQL Managed Instance and Database are built on top of inherent high availability (HA) architecture. This
includes support for auto-failover groups and various other features. You can choose between two HA
architecture models: Standard availability model in General Purpose service tier, or Premium availability model
in Business Critical service tier.
How does disaster recovery work in SQL Managed Instance and SQL Database?
See the SQL Database and SQL Managed Instance documentation. The SQL Managed Instance Frequently Asked
Questions provide information on DR options.
Performance and scale
How do I obtain better performance by moving on-premises SQL Server to SQL Managed Instance, SQL Database or SQL VM?
Moving from on-premises will provide you with performance benefits due to the latest SQL Server database
engine features, cloud scaling flexibility and the newest generation of underlying hardware. Find out why your
SQL Server data belongs on Azure. You can also read a recently published study by Principled Technologies
benchmarking SQL Managed Instance and SQL Server on Amazon Web Services (AWS) RDS. It's important to
ensure a proper sizing based on your requirements for CPU, memory and storage (IOPS, latency, transaction log
throughput and size). SQL Managed Instance and SQL Database also provide a choice between different
hardware configurations and service tiers that provide additional means to reach target performance.
Applications can also take advantage of read scale-out abilities including with named replicas and geo-replicas,
and techniques such as database sharding.
How can I compare SQL Managed Instance performance to SQL Server performance?
See the Performance section of the SQL Managed Instance FAQ for guidance on performance comparison and
tuning.

Migration and modernization process

I want to modernize SQL Server workloads to Azure SQL. What is the next step?
A great place to start is joining the Azure Migration and Modernization Program. When you start a migration
project, a good practice is to form a dedicated Migration team to formulate and execute the migration plan. If
your company has an assigned Microsoft or Microsoft Partner account team, they can provide guidance
regarding Migration team required skill set and overall process.
Where can I find migration guides to Azure SQL?
The following guides help you discover, assess, and migrate from SQL Server to SQL VM, SQL Managed
Instance and SQL Database. You can consult Azure Database Migration Guides that also contains guides for
migrating to another database targets.
Which migration tools can I use?
You can use the Azure SQL migration extension for Azure Data Studio for SQL Server assessment and migration,
or choose among other migration tools.
How do I minimize downtime during the online migration?
The Link feature for Azure SQL Managed Instance offers the best possible minimum downtime online
migrations solution, meeting the needs of the most critical tier-1 applications.
How can I optimize the costs once I migrate to Azure SQL?
Cost Optimization guidelines of Microsoft Azure Well-Architected Framework (WAF) provide methodology to
optimize costs for every Azure SQL service. You can also find out more about WAF cost optimization highlights
for SQL Managed Instance.

See also
Frequently asked questions for SQL Server on Azure VMs
Azure SQL Managed Instance frequently asked questions (FAQ)
Azure SQL Database Hyperscale FAQ
Azure Hybrid Benefit FAQ
 vCore purchasing model overview - Azure SQL
Database and Azure SQL Managed Instance
9/13/2022 • 5 minutes to read • Edit Online

Applies to: Azure SQL Database Azure SQL Managed Instance

This article provides a brief overview of the vCore purchasing model used by both Azure SQL Database and
Azure SQL Managed Instance. To learn more about the vCore model for each product, review Azure SQL
Database and Azure SQL Managed Instance.

Overview
A virtual core (vCore) represents a logical CPU and offers you the option to choose 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 optimizes price,
and allows you to choose compute, memory, and storage resources based on your workload needs.
In the vCore-based purchasing model, your costs depend on the choice and usage of:
Service tier
Hardware configuration
Compute resources (the number of vCores and the amount of memory)
Reserved database storage
Actual backup storage

IMPORTANT
In Azure SQL Database, compute resources (CPU and memory), I/O, and data and log storage are charged per database
or elastic pool. Backup storage is charged per each database.

The vCore purchasing model provides transparency in database CPU, memory, and storage resource allocation,
hardware configuration, higher scaling granularity, and pricing discounts with the Azure Hybrid Benefit (AHB)
and Reserved Instance (RI).
In the case of Azure SQL Database, the vCore purchasing model provides higher compute, memory, I/O, and
storage limits than the DTU model.

Service tiers
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.
The Hyperscale service tier is also available for single databases in Azure SQL Database. This service tier is
designed for most business workloads, providing highly scalable storage, read scale-out, fast scaling, and fast
database restore capabilities.
Resource limits
For more information on resource limits, see:
Azure SQL Database: logical server, single databases, pooled databases
Azure SQL Managed Instance

Compute cost
The vCore-based purchasing model has a provisioned compute tier for both Azure SQL Database and Azure
SQL Managed Instance, and a serverless compute tier for Azure SQL Database.
In the provisioned compute tier, the compute cost reflects the total compute capacity continuously provisioned
for the application independent of workload activity. Choose the resource allocation that best suits your
business needs based on vCore and memory requirements, then scale resources up and down as needed by
your workload.
In the serverless compute tier for Azure SQL database, compute resources are auto-scaled based on workload
capacity and billed for the amount of compute used, per second.
Since three additional replicas are automatically allocated in the Business Critical service tier, the price is
approximately 2.7 times higher 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 local SSD storage.

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.
Each compute size supports a configurable maximum data size, with a default of 32 GB.
When you configure maximum data size, an additional 30 percent of billable storage is automatically added
for the log file.
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.
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.
For SQL Database, you can select any maximum data size between 1 GB and the supported storage size
maximum, in 1 GB increments. For SQL Managed Instance, select data sizes in multiples of 32 GB up to the
supported storage size maximum.
To monitor the current allocated and used data storage size in SQL Database, use the allocated_data_storage and
storage Azure Monitor metrics respectively.
For both SQL Database and SQL Managed instance, to monitor the current allocated and used storage size of
individual data and log files in a database by 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.
Backup 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 Azure 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 Azure Blob 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
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
9/13/2022 • 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

Diagram of vCore pricing structure for SQL Database. 'License Included' pricing is made up of base compute
and SQL license components. Azure Hybrid Benefit pricing is made up of base compute and software assurance
components.
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
9/13/2022 • 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. Hence, by
purchasing a reserved capacity, existing resources infrastucture would not be modified and thus no
failover/downtime is triggered on existing resources. 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 configuration.
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
 General Purpose service tier - Azure SQL Database
and Azure SQL Managed Instance
9/13/2022 • 4 minutes to read • Edit Online

Applies to: Azure SQL Database Azure SQL Managed Instance

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 default availability even in the cases of
infrastructure failures.
This article describes and compares the General Purpose service tier used by Azure SQL Database and Azure
SQL Managed instance. The General Purpose service tier is best used for budget-oriented, balanced compute
and storage options.

Overview
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 by default and 99.995% availability when zone redundancy is enabled. There may be 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 a
default SLA and storage latency between 5 and 10 ms, the General Purpose tier is the option for you.

Compare General Purpose resource limits

Review the table in this section for a brief overview comparison of the resource limits for Azure SQL Database
and Azure SQL managed Instance in the General Purpose service tier.
For comprehensive details about resource limits, review:
Azure SQL Database: vCore single database, vCore pooled database , Hyperscale, DTU single database and
DTU pooled databases
Azure SQL Managed Instance: vCore instance limits
To compare features between SQL Database and SQL Managed Instance, see the database engine features.
The following table shows resource limits for both Azure SQL Database and Azure SQL Managed Instance in the
General Purpose service tier:

C AT EGO RY A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Compute size 1 - 80 vCores 4, 8, 16, 24, 32, 40, 64, 80 vCores

Storage type Remote storage Remote storage

Storage size 1 GB - 4 TB 2 GB - 16 TB

Tempdb size 32 GB per vCore 24 GB per vCore

Log write throughput Single databases: 4.5 MB/s per vCore General Purpose: 3 MB/s per vCore
(max 50 MB/s) (max 120 MB/s)
Elastic pools: 6 MB/s per vCore (max Business Critical: 4 MB/s per vCore
62.5 MB/s) (max 96 MB/s)

Availability Default SLA Default SLA

99.995% SLA with zone redundancy

Backups 1-35 days (7 days by default) 1-35 days (7 days by default)

Read-only replicas 0 built-in 0 built-in

0 - 4 geo-replicas 0 - 1 geo-replicas using auto-failover
groups
 C AT EGO RY A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Pricing/Billing vCore, reserved storage, backup vCore, reserved storage, backup

storage, and geo-replicas are charged. storage, and geo-replicas are charged.
IOPS is not charged. IOPS is not charged.

Discount models Reserved instances Reserved instances

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

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 service 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
9/13/2022 • 5 minutes to read • Edit Online

Applies to: Azure SQL Database Azure SQL Managed Instance

Azure SQL Database and Azure SQL Managed Instance are both based on the SQL Server database engine
architecture adjusted for the cloud environment in order to ensure default SLA availability even in cases of
infrastructure failures.
This article describes and compares the Business Critical service tier used by Azure SQL Database and Azure
SQL Managed instance. The Business Critical service tier is best used for applications requiring high transaction
rate, low IO latency, and high IO throughput. This service tier offers the highest resilience to failures and fast
failovers using multiple synchronously updated replicas.

Overview
The Business Critical service tier model is based on a cluster of database engine processes. This architectural
model relies on a fact that there's always a quorum of available database engine nodes and has minimal
performance impact on your workload even during maintenance activities.
Azure upgrades and patches underlying operating system, drivers, and SQL Server database engine
transparently with the minimal down-time for end users.
In the Business Critical model, compute and storage is integrated on each node. High availability is achieved by
replication of data between database engine processes on each node of a four node cluster, with each node
using locally attached SSD as data storage. This technology is 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, the Business Critical cluster has built-in Read Scale-Out capability that provides free-of charge built-
in read-only replica that can be used to run read-only queries (for example reports) that shouldn't affect
performance of your primary workload.

When to choose this service tier

The 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.
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 . The 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 can't 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 - The Business Critical tier in Multi-AZ configuration provides resiliency to zonal failures
and a higher availability SLA.
Fast geo-recover y - When active geo-replication is configured, the Business Critical tier has a guaranteed
Recovery Point Objective (RPO) of 5 seconds and Recovery Time Objective (RTO) of 30 seconds for 100% of
deployed hours.

Compare Business Critical resource limits

Review the table in this section for a brief overview comparison of the resource limits for Azure SQL Database
and Azure SQL managed Instance in the Business Critical service tier.
For comprehensive details about resource limits, review:
Azure SQL Database: vCore single database, vCore pooled database , Hyperscale, DTU single database and
DTU pooled databases
Azure SQL Managed Instance: vCore instance limits
To compare features between SQL Database and SQL Managed Instance, see the database engine features.
The following table shows resource limits for both Azure SQL Database and Azure SQL Managed Instance in the
Business Critical service tier.

C AT EGO RY A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Compute size 1 to 128 vCores 4, 8, 16, 24, 32, 40, 64, 80 vCores

Storage type Local SSD storage Local SSD storage

Storage size 1 GB – 4 TB 32 GB – 16 TB

Tempdb size 32 GB per vCore Up to 4 TB - limited by storage size

Log write throughput Single databases: 12 MB/s per vCore 4 MB/s per vCore (max 48 MB/s)
(max 96 MB/s)
Elastic pools: 15 MB/s per vCore (max
120 MB/s)

Availability Default SLA Default SLA

99.995% SLA with zone redundancy

Backups RA-GRS, 1-35 days (7 days by default) RA-GRS, 1-35 days (7 days by default)
 C AT EGO RY A Z URE SQ L DATA B A SE A Z URE SQ L M A N A GED IN STA N C E

Read-only replicas 1 built-in high availability replica is 1 built-in high availability replica is
readable readable
0 - 4 geo-replicas 0 - 1 geo-replicas using auto-failover
groups

Pricing/Billing vCore, reserved storage, backup vCore, reserved storage, backup

storage, and geo-replicas are charged. storage, and geo-replicas are charged.
High availability replicas aren't charged. High availability replicas aren't charged.
IOPS isn't charged. IOPS isn't charged.

Discount models Reserved instances Reserved instances

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

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 service 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
9/13/2022 • 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

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

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.
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

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, for S3 tier and above. Basic, S0, S1, Yes
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

queries

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
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

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, use native cross-DB queries and
Linked Server instead

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

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
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

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

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

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

Polybase No. You can query data in the files Yes, for Azure Data Lake Storage
placed on Azure Blob Storage using (ADLS) and Azure Blob Storage as data
OPENROWSET function or use an source. See Data Virtualization with
external table that references a Azure SQL Managed Instance for more
serverless SQL pool in Synapse details.
Analytics.

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

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
 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

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 service tiers
only.

Windows authentication No Yes, see Windows Authentication for

Azure Active Directory principals
(Preview).

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. No, see Auto-failover groups as an
alternative.

Auto-failover groups Yes - all service tiers. Yes, see Auto-failover groups.
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

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

Short-term 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. Long-term retention up to 10 years.
policies are not yet supported for
Hyperscale databases.

Pause/resume Yes, in serverless model No

Policy-based management No No

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. See SQL Yes - see SQL Database recovery
Database recovery
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

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.

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 Yes

VNet Global peering Yes, using Private IP and service Yes, using Virtual network peering.
endpoints
 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

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. Host MDS on an Azure VM. While
SQL Managed Instance cannot run
MDS as a service, it can host MDS
databases for an MDS service installed
on Azure Virtual Machine, using SQL
Server authentication.

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-premises, 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
9/13/2022 • 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
 Optimize performance by using in-memory
technologies in Azure SQL Database and Azure
SQL Managed Instance
9/13/2022 • 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
9/13/2022 • 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
9/13/2022 • 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 using features which are only available in the Business Critical / Premium service tiers, cannot be changed
to use the General Purpose / Standard service tier.
Databases originally created in the Hyperscale service tier cannot be migrated to other service tiers. If you migrate an
existing database in Azure SQL Database to the Hyperscale service tier, you can reverse migrate to the General
Purpose service tier within 45 days of the original migration to Hyperscale. If you wish to migrate the database to
another service tier, such as Business Critical, first reverse migrate to the General Purpose service tier, then perform a
further migration. Learn more in How to reverse migrate from Hyperscale.

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
9/13/2022 • 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,
support for a variety of read scale-out scenarios, 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 are persisted on read-only replicas synchronously or asynchronously
depending on replica type. However, for all replica types, reads from a read-only replica are always
asynchronous with respect to the primary. Within a session connected to a read-only replica, reads are always
transactionally consistent. 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 a 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 on the primary and immediately reads it
using a read-only session on a read-only replica, it is possible that the latest changes will not be immediately
visible.
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;

To connect to a read-only replica using SQL Server Management Studio (SSMS), select Options

Select Additional Connection Parameters and enter ApplicationIntent=ReadOnly and then select Connect
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
Transactions on read-only replicas always use the snapshot transaction isolation level, regardless of transaction
isolation level of the session, and regardless of any query hints. 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
9/13/2022 • 12 minutes to read • Edit Online

Applies to: Azure SQL Database Azure SQL Managed Instance

Elastic database transactions for Azure SQL Database 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

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

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.
 Maintenance window
9/13/2022 • 10 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.

Advance notifications (Preview) are available for databases configured to use a non-default maintenance
window. Advance notifications enable customers to configure notifications to be sent up to 24 hours in advance
of any planned event.

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 is free of charge and 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.

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

Feature availability
Supported subscription types
Configuring and using maintenance window is available for the following offer types: Pay-As-You-Go, Cloud
Solution Provider (CSP), Microsoft Enterprise Agreement, or Microsoft Customer Agreement.
Offers restricted to dev/test usage only are not eligible (like Pay-As-You-Go Dev/Test or Enterprise Dev/Test as
examples).

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.

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

Brazil South Yes Yes

Brazil Southeast 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

 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

Norway East Yes

Norway West Yes

South Africa North Yes

South Africa West Yes

South Central US Yes Yes Yes

South India Yes Yes

Southeast Asia Yes Yes Yes

Switzerland North Yes Yes

Switzerland West Yes

UAE Central Yes

UAE North Yes Yes

UK South Yes Yes Yes

UK West Yes Yes

US Gov Arizona Yes

US Gov Texas Yes Yes

US Gov Virginia 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

West US 3 Yes

Gateway maintenance
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 a 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 operation of configuring maintenance window and typically lasts up to
8 seconds even in case of interrupted long-running transactions. To minimize the impact of the reconfiguration, initiate
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.

Retrieving list of maintenance events

Azure Resource Graph is an Azure service designed to extend Azure Resource Management. The Azure Resource
Graph Explorer provides efficient and performant resource exploration with the ability to query at scale across a
given set of subscriptions so that you can effectively govern your environment.
You can use the Azure Resource Graph Explorer to query for maintenance events. For an introduction on how to
run these queries, see Quickstart: Run your first Resource Graph query using Azure Resource Graph Explorer.
To check for the maintenance events for all SQL databases in your subscription, use the following sample query
in Azure Resource Graph Explorer:

servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where impactedService =~ 'SQL Database'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title,
trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority,
impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime =
todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc

To check for the maintenance events for all managed instances in your subscription, use the following sample
query in Azure Resource Graph Explorer:

servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where impactedService =~ 'SQL Managed Instance'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title,
trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority,
impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime =
todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc

For the full reference of the sample queries and how to use them across tools like PowerShell or Azure CLI, visit
Azure Resource Graph sample queries for Azure Service Health.

Next steps
Configure maintenance window
 Advance notifications

Learn more
Maintenance window FAQ
Azure SQL Database
Azure SQL Managed Instance
Plan for Azure maintenance events in Azure SQL Database and Azure SQL Managed Instance
 Configure maintenance window
9/13/2022 • 11 minutes to read • Edit Online

Applies to: Azure SQL Database Azure SQL Managed Instance

Configure the maintenance window 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 feature 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.
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)
9/13/2022 • 4 minutes to read • Edit Online

Applies to: Azure SQL Database Azure SQL Managed Instance

Advance notifications (Preview) are available for databases configured to use a non-default maintenance
window and managed instances with any configuration (including the default one). 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.

IMPORTANT
For Azure SQL Database, 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 maintenance windows are generally available, advance notifications for maintenance windows are in public preview
for Azure SQL Database and Azure SQL Managed Instance.

Configure 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 Received 24 hours prior to the maintenance event.

Maintenance is planned on DATE between 5pm - 8am1 (local
time) in region xyz.

InProgress Maintenance for database(s) in regionxyzis starting.

Complete Maintenance of database(s) in region xyz is complete.

1 Start and end time depend on the selected maintenance window.

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

STAT US DESC RIP T IO N

Rescheduled 1) Maintenance is in progress but didn't complete inside

maintenance window. 2) there was a problem during
maintenance and it could not start. 3) Planned maintenance
has started but couldn't progress to the end and will
continue in next maintenance window.

Canceled Maintenance for database(s) in region xyz is canceled and

will be rescheduled for later.

Permissions
While Advance Notifications can be sent to any email address, Azure subscription RBAC (role-based access
control) policy determines who can access the links in the email. Querying resource graph is covered by Azure
RBAC access management. To enable read access, each recipient should have resource group level read access.
For more information, see Steps to assign an Azure role.

Retrieve the list of impacted resources

Azure Resource Graph is an Azure service designed to extend Azure Resource Management. The Azure Resource
Graph Explorer provides efficient and performant resource exploration with the ability to query at scale across a
given set of subscriptions so that you can effectively govern your environment.
You can use the Azure Resource Graph Explorer to query for maintenance events. For an introduction on how to
run these queries, see Quickstart: Run your first Resource Graph query using Azure Resource Graph Explorer.
When the advanced notification for planned maintenance is received, you will get a link that opens Azure
Resource Graph and executes the query for the exact event, similar to the following. Note that the
notificationId value is unique per maintenance event.
 resources
| project resource = tolower(id)
| join kind=inner (
maintenanceresources
| where type == "microsoft.maintenance/updates"
| extend p = parse_json(properties)
| mvexpand d = p.value
| where d has 'notificationId' and d.notificationId == 'LNPN-R9Z'
| project resource = tolower(name), status = d.status, resourceGroup, location, startTimeUtc =
d.startTimeUtc, endTimeUtc = d.endTimeUtc, impactType = d.impactType
) on resource
| project resource, status, resourceGroup, location, startTimeUtc, endTimeUtc, impactType

In Azure Resource Graph (ARG) explorer you might find values for the status of deployment that are bit different
than the ones displayed in the notification content.

STAT US DESC RIP T IO N

Pending 1) Maintenance is planned on upcoming date. 2) Previously

planned maintenance was rescheduled and is waiting to
start in the next window. 3) Maintenance started but didn't
complete in previous window and will continue in the next
one.

InProgress Maintenance for resourcexyzis starting or is in progress.

Completed Maintenance for resource xyz is complete.

NoUpdatesPending Previously planned maintenance for resource xyz is canceled

and will be rescheduled for later.

Retr yLater Planned maintenance for resource xyz has started but
couldn't progress to the end and will continue in next
maintenance window.

For the full reference of the sample queries and how to use them across tools like PowerShell or Azure CLI, visit
Azure Resource Graph sample queries for Azure Service Health.

Next steps
Maintenance window
Maintenance window FAQ
Overview of alerts in Microsoft Azure
Email Azure Resource Manager Role
 An overview of Azure SQL Database and SQL
Managed Instance security capabilities
9/13/2022 • 10 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 SQL authentication and Azure AD authentication. SQL Managed instance additionally
supports Windows Authentication for Azure AD principals.
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.
Windows Authentication for Azure AD Principals (Preview) :
Kerberos authentication for Azure AD Principals (Preview) enables Windows Authentication for Azure
SQL Managed Instance. Windows Authentication for managed instances empowers customers to move
existing services to the cloud while maintaining a seamless user experience and provides the basis for
infrastructure modernization.
To enable Windows Authentication for Azure Active Directory (Azure AD) principals, you will turn your
Azure AD tenant into an independent Kerberos realm and create an incoming trust in the customer
domain. Learn how Windows Authentication for Azure SQL Managed Instance is implemented with Azure
Active Directory and Kerberos.
 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
9/13/2022 • 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.

Solve 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 aren't 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
How to use 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 SQL 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 the 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.

NOTE
Some items considered customer content, such as table names, object names, and index names, may be transmitted in
log files for support and troubleshooting by Microsoft.

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 reimplement 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 reliably 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 rogue 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
9/13/2022 • 52 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-2 Secure cloud services Private endpoint 1.1.0

with network connections on Azure
controls SQL Database should
be enabled

Network Security NS-2 Secure cloud services Public network access 1.1.0
with network on Azure SQL
controls Database should be
disabled

Identity IM-1 Use centralized An Azure Active 1.0.0

Management identity and Directory
authentication administrator should
system be provisioned for
SQL servers

Data Protection DP-2 Monitor anomalies Azure Defender for 1.0.2

and threats targeting SQL should be
sensitive data enabled for
unprotected SQL
Managed Instances

Data Protection DP-4 Enable data at rest Transparent Data 2.0.0

encryption by default Encryption on SQL
databases should be
enabled

Data Protection DP-5 Use customer- SQL managed 2.0.0

managed key option instances should use
in data at rest customer-managed
encryption when keys to encrypt data
required at rest

Data Protection DP-5 Use customer- SQL servers should 2.0.1

managed key option use customer-
in data at rest managed keys to
encryption when encrypt data at rest
required

Logging and Threat LT-1 Enable threat Azure Defender for 2.0.1
Detection detection capabilities SQL should be
enabled for
unprotected Azure
SQL servers

Logging and Threat LT-1 Enable threat Azure Defender for 1.0.2
Detection detection capabilities 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

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

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

Logging and Threat LT-3 Enable logging for Auditing on SQL 2.0.0
Detection security investigation 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 2.0.1

analysis - create SQL should be
incidents based on enabled for
high-quality alerts unprotected Azure
SQL servers

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 2.0.1

analysis - prioritize SQL should be
incidents enabled for
unprotected Azure
SQL servers

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-5 Perform vulnerability Vulnerability 1.0.1

Vulnerability assessments assessment should
Management be enabled on SQL
Managed Instance

Posture and PV-5 Perform vulnerability Vulnerability 2.0.0

Vulnerability assessments assessment should
Management be enabled on your
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

Posture and PV-6 Rapidly and SQL databases 4.0.0

Vulnerability automatically should have
Management remediate vulnerability findings
vulnerabilities resolved

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
 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

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.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.8 Encrypt sensitive SQL managed 2.0.0

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 CIS Microsoft Azure Ensure ASC Default Auditing on SQL 2.0.0
Foundations policy setting server should be
Benchmark "Monitor SQL enabled
recommendation Auditing" is not
2.14 "Disabled"

Security Center CIS Microsoft Azure Ensure ASC Default Transparent Data 2.0.0
Foundations policy setting Encryption on SQL
Benchmark "Monitor SQL databases should be
recommendation Encryption" is not enabled
2.15 "Disabled"

Database Services CIS Microsoft Azure Ensure that 'Auditing' Auditing on SQL 2.0.0
Foundations is set to 'On' server should be
Benchmark enabled
recommendation 4.1

Database Services CIS Microsoft Azure Ensure SQL server's SQL managed 2.0.0
Foundations TDE protector is instances should use
Benchmark encrypted with BYOK customer-managed
recommendation (Use your own key) keys to encrypt data
4.10 at rest

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

Database Services CIS Microsoft Azure Ensure that SQL Auditing 1.0.0
Foundations 'AuditActionGroups' settings should have
Benchmark in 'auditing' policy for Action-Groups
recommendation 4.2 a SQL server is set configured to capture
properly critical activities

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

Database Services CIS Microsoft Azure Ensure that Azure Defender for 2.0.1
Foundations 'Advanced Data SQL should be
Benchmark Security' on a SQL enabled for
recommendation 4.4 server is set to 'On' unprotected Azure
SQL servers

Database Services CIS Microsoft Azure Ensure that Azure Defender for 1.0.2
Foundations 'Advanced Data SQL should be
Benchmark Security' on a SQL enabled for
recommendation 4.4 server is set to 'On' 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

Database Services CIS Microsoft Azure Ensure that Azure An Azure Active 1.0.0
Foundations Active Directory Directory
Benchmark Admin is configured administrator should
recommendation 4.8 be provisioned for
SQL servers

Database Services CIS Microsoft Azure Ensure that 'Data Transparent Data 2.0.0
Foundations encryption' is set to Encryption on SQL
Benchmark 'On' on a SQL databases should be
recommendation 4.9 Database enabled

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 CIS Microsoft Azure Ensure that 'Auditing' Auditing on SQL 2.0.0
Foundations is set to 'On' server should be
Benchmark enabled
recommendation
4.1.1

Database Services CIS Microsoft Azure Ensure that 'Data Transparent Data 2.0.0
Foundations encryption' is set to Encryption on SQL
Benchmark 'On' on a SQL databases should be
recommendation Database enabled
4.1.2

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

Database Services CIS Microsoft Azure Ensure that Azure Defender for 2.0.1
Foundations Advanced Threat SQL should be
Benchmark Protection (ATP) on a enabled for
recommendation SQL server is set to unprotected Azure
4.2.1 'Enabled' SQL servers

Database Services CIS Microsoft Azure Ensure that Azure Defender for 1.0.2
Foundations Advanced Threat SQL should be
Benchmark Protection (ATP) on a enabled for
recommendation SQL server is set to unprotected SQL
4.2.1 'Enabled' 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

Database Services CIS Microsoft Azure Ensure that Vulnerability 1.0.1

Foundations Vulnerability assessment should
Benchmark Assessment (VA) is be enabled on SQL
recommendation enabled on a SQL Managed Instance
4.2.2 server by setting a
Storage Account

Database Services CIS Microsoft Azure Ensure that Vulnerability 2.0.0

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

Database Services CIS Microsoft Azure Ensure that VA Vulnerability 2.0.0

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

Database Services CIS Microsoft Azure Ensure that Azure An Azure Active 1.0.0
Foundations Active Directory Directory
Benchmark Admin is configured administrator should
recommendation 4.4 be provisioned for
SQL servers

Database Services CIS Microsoft Azure Ensure SQL server's SQL managed 2.0.0
Foundations TDE protector is instances should use
Benchmark encrypted with customer-managed
recommendation 4.5 Customer-managed keys to encrypt data
key at rest

Database Services CIS Microsoft Azure Ensure SQL server's SQL servers should 2.0.1
Foundations TDE protector is use customer-
Benchmark encrypted with managed keys to
recommendation 4.5 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).
 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.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.

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.
 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 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.

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.
 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.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.

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.
 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.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

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.
 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 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.

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.
 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 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.

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.
 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 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

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.
 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.177 Employ FIPS- SQL managed 2.0.0

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.

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.
 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 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 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
 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-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 2.0.0

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 Transparent Data 2.0.0

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

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
 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 (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

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
 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-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

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
 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 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

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
 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 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 2.0.0

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 Transparent Data 2.0.0

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

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 2.0.0

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

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
 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 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

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

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

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

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)

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.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.6.1 Management of SQL databases 4.0.0

technical should have
vulnerabilities vulnerability findings
resolved

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

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
 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

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 2.0.0

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

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
 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 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-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
 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-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

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
 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) 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

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
 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

Monitoring and SQL should be
Scanning 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

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

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 2.0.0

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 Transparent Data 2.0.0

Communications Information at Rest Encryption on SQL
Protection databases 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-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

System and SI-4 System Monitoring Azure Defender for 1.0.2

Information Integrity SQL should be
enabled for
unprotected SQL
Managed Instances

PCI DSS 3.2.1

To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see PCI
DSS 3.2.1. For more information about this compliance standard, see PCI DSS 3.2.1.

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)

Requirement 1 PCI DSS v3.2.1 1.3.4 PCI DSS requirement Auditing on SQL 2.0.0
1.3.4 server should be
enabled

Requirement 10 PCI DSS v3.2.1 10.5.4 PCI DSS requirement Auditing on SQL 2.0.0
10.5.4 server should be
enabled

Requirement 11 PCI DSS v3.2.1 11.2.1 PCI DSS requirement SQL databases 4.0.0
11.2.1 should have
vulnerability findings
resolved

Requirement 3 PCI DSS v3.2.1 3.2 PCI DSS requirement An Azure Active 1.0.0
3.2 Directory
administrator should
be provisioned for
SQL servers

Requirement 3 PCI DSS v3.2.1 3.4 PCI DSS requirement Transparent Data 2.0.0
3.4 Encryption on SQL
databases 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

Requirement 4 PCI DSS v3.2.1 4.1 PCI DSS requirement Transparent Data 2.0.0
4.1 Encryption on SQL
databases should be
enabled

Requirement 5 PCI DSS v3.2.1 5.1 PCI DSS requirement SQL databases 4.0.0
5.1 should have
vulnerability findings
resolved

Requirement 6 PCI DSS v3.2.1 6.2 PCI DSS requirement SQL databases 4.0.0
6.2 should have
vulnerability findings
resolved

Requirement 6 PCI DSS v3.2.1 6.5.3 PCI DSS requirement Transparent Data 2.0.0
6.5.3 Encryption on SQL
databases should be
enabled

Requirement 6 PCI DSS v3.2.1 6.6 PCI DSS requirement SQL databases 4.0.0
6.6 should have
vulnerability findings
resolved

Requirement 7 PCI DSS v3.2.1 7.2.1 PCI DSS requirement An Azure Active 1.0.0
7.2.1 Directory
administrator should
be provisioned for
SQL servers

Requirement 8 PCI DSS v3.2.1 8.3.1 PCI DSS requirement An Azure Active 1.0.0
8.3.1 Directory
administrator should
be provisioned for
SQL servers

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

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)

Cryptography RMiT 10.16 Cryptography - SQL managed 2.0.0

10.16 instances should 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

Cryptography RMiT 10.16 Cryptography - Transparent Data 2.0.0

10.16 Encryption on SQL
databases should be
enabled

Cryptography RMiT 10.19 Cryptography - SQL servers should 2.0.1

10.19 use customer-
managed keys to
encrypt data at rest

Network Resilience RMiT 10.33 Network Resilience - Configure Azure SQL 1.0.0
10.33 Server to disable
public network access

Network Resilience RMiT 10.33 Network Resilience - Configure Azure SQL 1.0.0
10.33 Server to enable
private endpoint
connections

Network Resilience RMiT 10.33 Network Resilience - Private endpoint 1.1.0

10.33 connections on Azure
SQL Database should
be enabled

Network Resilience RMiT 10.39 Network Resilience - SQL Server should 1.0.0
10.39 use a virtual network
service endpoint

Cloud Services RMiT 10.49 Cloud Services - SQL Database should 2.0.0
10.49 avoid using GRS
backup redundancy

Cloud Services RMiT 10.49 Cloud Services - SQL Managed 2.0.0

10.49 Instances should
avoid using GRS
backup redundancy

Cloud Services RMiT 10.51 Cloud Services - Long-term geo- 2.0.0

10.51 redundant backup
should be enabled
for Azure SQL
Databases

Cloud Services RMiT 10.53 Cloud Services - SQL servers should 2.0.1
10.53 use customer-
managed keys to
encrypt data at rest

Access Control RMiT 10.54 Access Control - An Azure Active 1.0.0

10.54 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

Security of Digital RMiT 10.66 Security of Digital Deploy - Configure 3.0.0

Services Services - 10.66 diagnostic settings
for SQL Databases to
Log Analytics
workspace

Data Loss Prevention RMiT 11.15 Data Loss Prevention Configure Azure SQL 1.0.0
(DLP) (DLP) - 11.15 Server to disable
public network access

Data Loss Prevention RMiT 11.15 Data Loss Prevention SQL managed 2.0.0
(DLP) (DLP) - 11.15 instances should use
customer-managed
keys to encrypt data
at rest

Data Loss Prevention RMiT 11.15 Data Loss Prevention Transparent Data 2.0.0
(DLP) (DLP) - 11.15 Encryption on SQL
databases should be
enabled

Security Operations RMiT 11.17 Security Operations Vulnerability 2.0.0

Centre (SOC) Centre (SOC) - 11.17 Assessment settings
for SQL server
should contain an
email address to
receive scan reports

Security Operations RMiT 11.17 Security Operations Vulnerability 2.0.0

Centre (SOC) Centre (SOC) - 11.17 Assessment settings
for SQL server
should contain an
email address to
receive scan reports

Security Operations RMiT 11.18 Security Operations Auditing on SQL 2.0.0

Centre (SOC) Centre (SOC) - 11.18 server should be
enabled

Security Operations RMiT 11.18 Security Operations Auditing on SQL 2.0.0

Centre (SOC) Centre (SOC) - 11.18 server should be
enabled

Security Operations RMiT 11.18 Security Operations SQL Auditing 1.0.0

Centre (SOC) Centre (SOC) - 11.18 settings should have
Action-Groups
configured to capture
critical activities

Security Operations RMiT 11.18 Security Operations SQL Auditing 1.0.0

Centre (SOC) Centre (SOC) - 11.18 settings should have
Action-Groups
configured to capture
critical activities
 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

Cybersecurity RMiT 11.8 Cybersecurity Vulnerability 1.0.1

Operations Operations - 11.8 assessment should
be enabled on SQL
Managed Instance

Cybersecurity RMiT 11.8 Cybersecurity Vulnerability 2.0.0

Operations Operations - 11.8 assessment should
be enabled on your
SQL servers

Control Measures on RMiT Appendix 5.6 Control Measures on Azure SQL Database 2.0.0
Cybersecurity Cybersecurity - should be running
Appendix 5.6 TLS version 1.2 or
newer

Control Measures on RMiT Appendix 5.6 Control Measures on Public network access 1.1.0
Cybersecurity Cybersecurity - on Azure SQL
Appendix 5.6 Database should be
disabled

Control Measures on RMiT Appendix 5.6 Control Measures on SQL Managed 1.0.1
Cybersecurity Cybersecurity - Instance should have
Appendix 5.6 the minimal TLS
version of 1.2

Control Measures on RMiT Appendix 5.6 Control Measures on Virtual network 1.0.0
Cybersecurity Cybersecurity - firewall rule on Azure
Appendix 5.6 SQL Database should
be enabled to allow
traffic from the
specified subnet

Control Measures on RMiT Appendix 5.7 Control Measures on Configure Azure SQL 1.0.0
Cybersecurity Cybersecurity - Server to enable
Appendix 5.7 private endpoint
connections

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)

Identity and 10 Identity and An Azure Active 1.0.0

authentication authentication Directory
administrator should
be provisioned for
SQL servers

Audit information for 13 Audit information for Auditing on SQL 2.0.0

users users 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 information for 13 Audit information for Azure Defender for 2.0.1
users users SQL should be
enabled for
unprotected Azure
SQL servers

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

Next steps
Learn more about Azure Policy Regulatory Compliance.
See the built-ins on the Azure Policy GitHub repo.
 Microsoft Defender for SQL
9/13/2022 • 3 minutes to read • Edit Online

Applies to: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
Microsoft Defender for SQL is a Defender plan in Microsoft Defender for Cloud. Microsoft Defender for SQL
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 SQL 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 SQL 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 SQL

There are multiple ways to enable Microsoft Defender plans. You can enable it at the subscription level
(recommended ) either:
In Microsoft Defender for Cloud in the Azure portal
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.
When you enable on the subscription level, all databases in Azure SQL Database and Azure SQL Managed
Instance are protected. You can then disable them individually if you choose. If you want to manually manage
which databases are protected, disable at the subscription level and enable each database that you want
protected.
Enable Microsoft Defender for Azure SQL Database at the subscription level in 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 Environment 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 so that new resources are
automatically protected. 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 SQL. You can evaluate Microsoft Defender for Cloud with a free trial.

Manage Microsoft Defender for SQL settings

To view and manage Microsoft Defender for SQL 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
9/13/2022 • 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
9/13/2022 • 9 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.
Information Protection policy
Azure SQL offers both SQL Information Protection policy and Microsoft Information Protection policy in data
classification, and you can choose either of these two policies based on your requirement.

SQL Information Protection policy

Data Discovery & Classification comes with a built-in set of sensitivity labels and information types with
discovery logic which is native to the SQL logical server. You can continue using the protection labels available in
the default policy file, or you can customize this taxonomy. You can define a set and ranking of classification
constructs specifically for your environment.
Define and customize your classification taxonomy
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 database in SQL Information Protection policy mode

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.
Microsoft Information Protection policy
Microsoft Information Protection (MIP) labels provide a simple and uniform way for users to classify sensitive
data uniformly across different Microsoft applications. MIP sensitivity labels are created and managed in
Microsoft 365 compliance center. To learn how to create and publish MIP sensitive labels in Microsoft 365
compliance center, see the article, Create and publish sensitivity labels.
Prerequisites to switch to MIP policy
The current user has tenant wide security admin permissions to apply policy at the tenant root management
group level. For more information, see Grant tenant-wide permissions to yourself.
Your tenant has an active Microsoft 365 subscription and you have labels published for the current user. For
more information, see Create and configure sensitivity labels and their policies.
Classify database in Microsoft Information Protection policy mode
1. Go to the Azure portal.
2. Navigate to your database in Azure SQL Database
3. Go to Data Discover y & Classification under the Security heading in your database pane.
4. To select Microsoft Information Protection policy , select the Over view tab, and select Configure .
5. Select Microsoft Information Protection policy in the Information Protection policy options, and
select Save .
6. If you go to the Classification tab, or select Add classification , you will now see M365 sensitivity
labels appear in the Sensitivity label dropdown.

Information type is [n/a] while you are in MIP policy mode and automatic data discovery &
recommendations remain disabled.
A warning icon may appear against an already classified column if the column was classified using a
different Information Protection policy than the currently active policy. For example, if the column was
 classified with a label using SQL Information Protection policy earlier and now you are in Microsoft
Information Protection policy mode. You will see a warning icon against that specific column. This
warning icon does not indicate any problem, but is used only for information purposes.

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 activities 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 return 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.

NOTE
The Azure SQL built-in roles in this section apply to a dedicated SQL pool (formerly SQL DW) but are not available for
dedicated SQL pools and other SQL resources within Azure Synapse workspaces. For SQL resources in Azure Synapse
workspaces, use the available actions for data classification to create custom Azure roles as needed for labelling. For more
information on the Microsoft.Synapse/workspaces/sqlPools provider operations, see Microsoft.Synapse.

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 Microsoft 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 Microsoft 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 Microsoft Purview labels using T-
SQL commands, see Classify your Azure SQL data using Microsoft Purview labels.
 Dynamic data masking
9/13/2022 • 6 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

Granular permission example

Prevent unauthorized access to sensitive data and gain control by masking it to an unauthorized user at
different levels of the database. You can grant or revoke UNMASK permission at the database-level, schema-
level, table-level or at the column-level to a user. Using UNMASK permission provides a more granular way to
control and limit unauthorized access to data stored in the database and improve data security management.
1. Create schema to contain user tables

CREATE SCHEMA Data;

GO

2. Create table with masked columns

 CREATE TABLE Data.Membership (
MemberID int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,
FirstName varchar(100) MASKED WITH (FUNCTION = 'partial(1, "xxxxx", 1)') NULL,
LastName varchar(100) NOT NULL,
Phone varchar(12) MASKED WITH (FUNCTION = 'default()') NULL,
Email varchar(100) MASKED WITH (FUNCTION = 'email()') NOT NULL,
DiscountCode smallint MASKED WITH (FUNCTION = 'random(1, 100)') NULL,
BirthDay datetime MASKED WITH (FUNCTION = 'default()') NULL
);

3. Insert sample data

INSERT INTO Data.Membership (FirstName, LastName, Phone, Email, DiscountCode, BirthDay)

VALUES
('Roberto', 'Tamburello', '555.123.4567', '[email protected]', 10, '1985-01-25 03:25:05'),
('Janice', 'Galvin', '555.123.4568', '[email protected]', 5,'1990-05-14 11:30:00'),
('Shakti', 'Menon', '555.123.4570', '[email protected]', 50,'2004-02-29 14:20:10'),
('Zheng', 'Mu', '555.123.4569', '[email protected]', 40,'1990-03-01 06:00:00');

4. Create schema to contain service tables

CREATE SCHEMA Service;

GO

5. Create service table with masked columns

CREATE TABLE Service.Feedback (

MemberID int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,
Feedback varchar(100) MASKED WITH (FUNCTION = 'default()') NULL,
Rating int MASKED WITH (FUNCTION='default()'),
Received_On datetime
);

6. Insert sample data

INSERT INTO Service.Feedback(Feedback,Rating,Received_On)

VALUES
('Good',4,'2022-01-25 11:25:05'),
('Excellent', 5, '2021-12-22 08:10:07'),
('Average', 3, '2021-09-15 09:00:00');

7. Create different users in the database

CREATE USER ServiceAttendant WITHOUT LOGIN;

GO

CREATE USER ServiceLead WITHOUT LOGIN;

GO

CREATE USER ServiceManager WITHOUT LOGIN;

GO

CREATE USER ServiceHead WITHOUT LOGIN;

GO

8. Grant read permissions to the users in the database

 ALTER ROLE db_datareader ADD MEMBER ServiceAttendant;

ALTER ROLE db_datareader ADD MEMBER ServiceLead;

ALTER ROLE db_datareader ADD MEMBER ServiceManager;

ALTER ROLE db_datareader ADD MEMBER ServiceHead;

9. Grant different UNMASK permissions to users

--Grant column level UNMASK permission to ServiceAttendant

GRANT UNMASK ON Data.Membership(FirstName) TO ServiceAttendant;

-- Grant table level UNMASK permission to ServiceLead

GRANT UNMASK ON Data.Membership TO ServiceLead;

-- Grant schema level UNMASK permission to ServiceManager

GRANT UNMASK ON SCHEMA::Data TO ServiceManager;
GRANT UNMASK ON SCHEMA::Service TO ServiceManager;

--Grant database level UNMASK permission to ServiceHead;

GRANT UNMASK TO ServiceHead;

10. Query the data under the context of user ServiceAttendant

EXECUTE AS USER='ServiceAttendant';
SELECT MemberID,FirstName,LastName,Phone,Email,BirthDay FROM Data. Membership;
SELECT MemberID,Feedback,Rating FROM Service.Feedback;
REVERT;

11. Query the data under the context of user ServiceLead

EXECUTE AS USER='ServiceLead';
SELECT MemberID,FirstName,LastName,Phone,Email,BirthDay FROM Data. Membership;
SELECT MemberID,Feedback,Rating FROM Service.Feedback;
REVERT;

12. Query the data under the context of user ServiceManager

EXECUTE AS USER='ServiceManager';
SELECT MemberID,FirstName,LastName,Phone,Email FROM Data.Membership;
SELECT MemberID,Feedback,Rating FROM Service.Feedback;
REVERT;

13. Query the data under the context of user ServiceHead

EXECUTE AS USER='ServiceHead';
SELECT MemberID,FirstName,LastName,Phone,Email,BirthDay FROM Data.Membership;
SELECT MemberID,Feedback,Rating FROM Service.Feedback;
REVERT;

14. To revoke UNMASK permissions, use the following T-SQL statements:

 REVOKE UNMASK ON Data.Membership(FirstName) FROM ServiceAttendant;

REVOKE UNMASK ON Data.Membership FROM ServiceLead;

REVOKE UNMASK ON SCHEMA::Data FROM ServiceManager;

REVOKE UNMASK ON SCHEMA::Service FROM ServiceManager;

REVOKE UNMASK FROM ServiceHead;

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
9/13/2022 • 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 .

NOTE
Each database is randomly assigned a scan time on a set day of the week. Email notifications are
scheduled randomly per server on a set day of the week. The email notification report includes data from
all recurring database scans that were executed during the preceding week (does not include on-demand
scans).

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
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
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 may 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
1. To disable specific findings, you need permissions to edit a policy in Azure Policy. Learn more in Azure RBAC
permissions in Azure Policy.
2. Disabled findings will still be included in the weekly SQL Vulnerability Assessment email report.

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 (export).

Convert-AzSqlInstanceDatabaseVulnerabilityAssessmentScan Converts vulnerability assessment scan results of a managed

database to an Excel file (export).

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
9/13/2022 • 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 and excessive permissions. 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.

VA2201 SQL logins with High This rule checks the SQL Server 2012+
commonly used accounts with
names should be database owner
disabled permission for
commonly used
names. Assigning
commonly used
names to accounts
with database owner
permission increases
the likelihood of
successful brute force
attacks.

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
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.

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.
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

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.

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.
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

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.

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.
 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

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.

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.
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

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.

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.
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

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.

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.

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

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.
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

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.

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
9/13/2022 • 4 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 2022
RUL E ID RUL E T IT L E C H A N GE DETA IL S

VA2129 Changes to signed modules should be Logic change

authorized

VA1219 Transparent data encryption should be Logic change

enabled

VA1047 Password expiration check should be Logic change

enabled for all SQL logins

January 2022
RUL E ID RUL E T IT L E C H A N GE DETA IL S

VA1288 Sensitive data columns should be Removed rule

classified

VA1054 Minimal set of principals should be Logic change

members of fixed high impact
database roles

VA1220 Database communication using TDS Logic change

should be protected through TLS

VA2120 Features that may affect security Logic change

should be disabled

VA2129 Changes to signed modules should be Logic change

authorized

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
 RUL E ID RUL E T IT L E C H A N GE DETA IL S

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

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
RUL E ID RUL E T IT L E C H A N GE DETA IL S

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

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
RUL E ID RUL E T IT L E C H A N GE DETA IL S

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

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
 RUL E ID RUL E T IT L E C H A N GE DETA IL S

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
9/13/2022 • 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
Microsoft Edge or Chrome 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
9/13/2022 • 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.

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 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
9/13/2022 • 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 Azure
Active Directory or Azure Active Directory Domain Services. Use an Active Directory domain 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 information about firewall rules in SQL Database, see SQL Database firewall rules.
 Configure and manage Azure AD authentication
with Azure SQL
9/13/2022 • 25 minutes to read • Edit Online

Applies to: Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics
This article shows you how to create and populate an Azure Active Directory (Azure AD) instance, and then use
Azure AD with Azure SQL Database, Azure SQL Managed Instance, and Azure Synapse Analytics. For an
overview, see Azure Active Directory authentication.

Azure AD authentication methods

Azure AD authentication supports the following authentication methods:
Azure AD cloud-only identities
Azure AD hybrid identities that support:
Cloud authentication with two options coupled with seamless single sign-on (SSO)
Azure AD password hash authentication
Azure AD pass-through authentication
Federated authentication
For more information on Azure AD authentication methods, and which one to choose, see Choose the right
authentication method for your Azure Active Directory hybrid identity solution.
For more information on Azure AD hybrid identities, setup, and synchronization, see:
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

Create and populate an Azure AD instance

Create an Azure AD instance and populate it with users and groups. Azure AD can be the initial Azure AD
managed domain. Azure AD can also be an on-premises Active Directory Domain Services that is federated with
the Azure AD.
For more information, see:
Integrating your on-premises identities with Azure Active Directory
Add your own domain name to Azure AD
Microsoft Azure now supports federation with Windows Server Active Directory
What is Azure Active Directory?
Manage Azure AD using Windows PowerShell
Hybrid Identity Required Ports and Protocols.

Associate or add an Azure subscription to Azure Active Directory

1. Associate your Azure subscription to Azure Active Directory by making the directory a trusted directory
for the Azure subscription hosting the database. For details, see Associate or add an Azure subscription to