Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Applies to: 
Azure SQL Database
The network security perimeter (preview) secures both inbound and outbound network traffic between Azure SQL Database and other platform as a service (PaaS) resources, such as Azure Storage and Azure Key Vault. It blocks attempts to communicate with Azure resources outside the perimeter.
Note
As a preview feature, the technology presented in this article is subject to Supplemental Terms of Use for Microsoft Azure Previews.
Get started
In the Azure portal, search for Network Security Perimeter in the resource list and then select Create.
Provide a Name and Region and choose the subscription.
Under the Resources section, select the Add button and navigate to the SQL Database you want to associate with the perimeter.
Add an inbound access rule. The source type can be either an IP address, a subscription, or other network security perimeters.
Add an outbound access rule to allow resources inside the perimeter to connect to resources outside the perimeter.
If you already have an Azure SQL Database and want to add a network security perimeter, use the following steps:
In the Azure portal, search for the existing Network Security Perimeter.
Select Associated Resources from the Settings menu.
Select the Add button and select Associate resources with an existing profile.
Select your Profile from the dropdown list and select Add.
Search for your SQL Database resource, select the required resource, and then select Associate.
Use SQL Database with a network security perimeter
By default, a network security perimeter uses transition mode, formerly called learning mode, which you can use to log all traffic to and from SQL Database. You can log the network traffic to a Log Analytics workspace or an Azure Storage account by using Diagnostic logging for Azure Network Security Perimeter. When you're ready, switch the perimeter to Enforced mode. In Enforced mode, denied access returns the following error:
Error 42118
Login failed because the network security perimeter denied inbound access.
Feature support
Not every Azure SQL Database feature interacts with a network security perimeter in the same way. Some features move data between logical servers, some connect outbound to other Azure services, and some don't work inside a perimeter at all. The following table covers the features documented so far. This list grows as more features complete perimeter validation. Select a feature to learn more about how it works with a network security perimeter, including setup steps and any limitations.
| Feature | Perimeter support | What you need to know |
|---|---|---|
| Active geo-replication | Supported | In enforced mode, each logical server in a perimeter needs both an inbound and an outbound rule for every other server in the geo-replication set that isn't in its perimeter. Rules run in both directions because a geo-failover reverses the direction of data movement. Replication on an established link keeps running even if you later change the rules to disallow it. |
| Change event streaming | Supported | The database connects outbound to Azure Event Hubs or Fabric Eventstream. In enforced mode, add an outbound rule that names the destination FQDN. Without that rule, you can't create a stream group, and an existing stream stops publishing and holds the transaction log open. |
| Database copy | Supported | In enforced mode, a source server in a perimeter needs an outbound rule, and a target server in a perimeter needs an inbound rule. Neither needs a rule if both servers are in the same perimeter or the copy stays on one server. When a logical server belongs to a perimeter, Transact-SQL isn't a supported way to copy to a different logical server. |
| Elastic jobs | Supported | The job agent's logical server needs an outbound rule to each target server. The perimeter is checked at run time, so a job can be created successfully and then fail during execution. |
| Elastic query | Supported within a single perimeter | The database that runs the query and the remote database must be in the same perimeter. Elastic query needs no perimeter configuration of its own. |
| Extended Events | Supported | The event_file target and the functions that read event data connect outbound to Azure Storage. In enforced mode, use a managed identity, or add an outbound FQDN rule for the storage account when you use a SAS token. |
| Long-term retention restore | Supported | In enforced mode, a source server in a perimeter needs an outbound rule, and a target server in a perimeter needs an inbound rule. Neither needs a rule if both are in the same perimeter. After the source server is deleted, only the target side can be validated. |
| SQL Data Sync | Not supported by design | Data Sync runs as a proxy service rather than an Azure resource, so it has no FQDN or IP address to write perimeter rules against. A perimeter blocks the network paths Data Sync requires in both transition and enforced mode. |
Limitations
- A logical server in Azure SQL Database can't be associated with a network security perimeter if it contains one or more dedicated SQL pools (formerly SQL DW).
- Network security perimeter support for Azure SQL Database is available in Azure public cloud regions. It isn't available in Azure Government. For the current list of onboarded services, see Onboarded private link resources.