Announcing VNet service endpoints general availability for MySQL and PostgreSQL
This blog post was co-authored by Anitha Adusumilli, Principal Program Manager, Azure Networking.
We recently made Azure database services for MySQL and PostgreSQL generally available. These services offer the community versions of MySQL and PostgreSQL with built-in high availability, a 99.99 percent availability SLA, elastic scaling for performance, and industry-leading security and compliance on Azure. Since general availability, we have continued to bring new features and capabilities like increased storage and availability across more regions worldwide.
We are excited to announce the general availability of Virtual Network (VNet) service endpoints for Azure Database for MySQL and PostgreSQL in all regions where the service is available for General Purpose and Memory Optimized servers. Visit region expansion for MySQL and PostgreSQL for service availability. VNet service endpoints enable you to isolate connectivity to your logical server from only a given subnet or set of subnets within your virtual network. The traffic to Azure Database for MySQL and/or PostgreSQL from your VNet always stays within the Azure backbone network. Preference for this direct route is over any specific ones that route Internet traffic through virtual appliances or on-premises.
There is no additional billing for virtual network access through service endpoints. The current pricing model for Azure Database for MySQL and PostgreSQL applies as is.
Using firewall rules and VNet service endpoints together
Turning on VNet service endpoints does not override firewall rules that you have provisioned on your Azure Database for MySQL or PostgreSQL. Both continue to be applicable.
VNet service endpoints don’t extend to on-premises. To allow access from on-premises, firewall rules can be used to limit connectivity only to your public (NAT) IPs.
To enable VNet protection, visit these articles for Azure Database for MySQL and PostgreSQL.
Turning on service endpoints for servers with pre-existing firewall rules
When you connect to your server with service endpoints turned on, the source IP of database connections switches to the private IP space of your VNet. Configuration is via the “Microsoft.Sql” shared service tag for all Azure Databases including Azure Database for MySQL, PostgreSQL, Azure SQL Database Managed Instance, and Azure SQL Data Warehouse. If at present your server or database firewall rules allow specific Azure public IPs, then the connectivity breaks until you allow the given VNet/subnet by specifying it in the VNet firewall rules. To ensure connectivity, you can preemptively specify VNet firewall rules before turning on service endpoints by using IgnoreMissingServiceEndpoint flag.
Support for App Service Environment
As part of the general availability, we support service endpoints for App Service Environment (ASE) subnets deployed into your VNets.
Next steps
To get started, refer to the documentation “Virtual Network Service Endpoints” and “How to configure VNET Service Endpoints for MySQL and PostgreSQL”.
For feature details and scenarios, please watch the Microsoft Ignite session, Network security for applications in Azure.
Source: Azure Blog Feed