Announced in September 2019 Azure PrivateLink is a "secure and scalable way for Azure customers to consume Azure Services like Azure Storage or SQL, Microsoft Partner Services or their own services privately from their Azure Virtual Network (VNet). The technology is based on a provider and consumer model where the provider and the consumer are both hosted in Azure. A connection is established using a consent-based call flow and once established, all data that flows between the service provider and service consumer is isolated from the internet and stays on the Microsoft network. There is no need for gateways, network address translation (NAT) devices, or public IP addresses to communicate with the service".
Currently supporting only a handful of PaaS services such as a Azure Storage, Azure CosmosDB and SQL database, Microsoft promised back in September, "We will also be adding more Azure PaaS services to Azure Private Link including...Azure MySQL, Azure PostgreSQL, Azure MariaDB, Azure Application Service, and Azure Key Vault, and Partner Services in coming months". This week, THREE new services were added in preview - Azure Database for PostgreSQL, Azure Database for MySQL and Azure Database for MariaDB.
Why should you care?
First lets understand the challenge...but before we can do that, we need to talk about Data.
The biggest concern and obstacle in Cloud operations is the Data, for three reasons:
Data has mass. Servers, Containers and Server-less functions come and go, the Data will always remain. This mass is also a major blocker to Cloud portability - the ability to pickup an application and move it to another Cloud Provider. Customers have gone down this road, deployed the application stack in Provider B, then tried to move the data over from Provider A, only to be rudely awakened by the exorbitant network egress transfer charges for Terabyte and Petabyte scale data.
Data requires reachability. Regardless of where an application is deployed, at some point it needs to touch the data - either to create, read, update or delete it. This reachability coupled with other factors such as transfer costs and compliance requirements translate to limiting factors regarding application architecture and placement.
Data has security implications. Depending on the data characteristics, certain regulatory compliance requirements may apply governing how and where the data may or may not be stored geographically, and for how long - not to mention the usual access control requirements.
Okay, back to the show...
You care about PrivateLink and these new features for three key reasons:
Private connectivity to Azure PaaS services - Some multi-tenant services such as Azure Storage and Azure SQL Database do not reside in your VNet and are reachable only via public endpoints. Yes, you can secure the connection using VNet service endpoints which keep the traffic within the Microsoft backbone network and locks down the PaaS resource to just your VNet, but the PaaS endpoint is still served over a public IP address and therefore not reachable from on-premises through Azure ExpressRoute private peering or VPN gateway. With PrivateLink, you simply create a private endpoint in your VNet and map it to your PaaS resource (Your Azure Storage account blob or SQL Database server). These resources are then accessible over a private IP address in your VNet, enabling connectivity from on-premises through Azure ExpressRoute private peering and/or VPN gateway.
Private connectivity to your own service - PrivateLink also supports custom services. If you offer application services hosted in Azure, you have to expose your service over...you guessed it... a public interface in order for other consumers running in Azure to access it. Sure, you can use VNet peering and make a private connection to your consumers’ VNets but this is hardly scalable and at some point you're bound to run into IP address conflicts, the main limitation of VNet peering. With PrivateLink, you can "run your service completely private in your own VNet behind an Azure Standard Load Balancer, enable it for Azure PrivateLink, and allow it to be accessed by consumers running in different VNets or Subscriptions all using simple clicks and approval call flow". Your service consumer only has to create a private endpoint in their own VNet and access the Azure PrivateLink service completely private without opening access control lists (ACLs) to any public IP address space.
Private connectivity to SaaS service - Microsoft’s SaaS partners offer many different solutions to Azure customers today, but these are offered over - drumroll - public endpoints. To consume these solutions, Azure customers must open their private networks to the public internet, giving Network Security experts the fits which leads to corporate infighting between application owners and InfoSec. If only application users could consume these services as if they were deployed right within their own networks... Well, with PrivateLink they can, because PrivateLink, extends the private connectivity experience to Microsoft partners using the same VNet endpoint-to-endpoint mapping process.
This was quite a mouthful, but hopefully the value of PrivateLink was proven. The support for these 3 new services is a welcome addition which should excite a tremendous number of application owners and quite possibly ease the minds of a few InfoSec professionals. Kudos to Microsoft for promises kept!
More info
コメント