- Through virtual network service endpoints
- Endpoints allow you to secure your critical Azure service resources to only your virtual networks.
- Available for: • Azure Storage • Azure SQL • PostgreSQL • MySQL • Cosmos DB • Key Vault • Service Bus • Event Hubs
- Through a virtual network
- Some resources can be deployed directly to a virtual network.
- E.g. Redis, Azure Kubernetes Service, App Service Environment...
- Some resources can be deployed directly to a virtual network.
- Gateway to gateway connections.
- Requires shared key that both parts know.
- Azure VPN gateways provide secure tunnel using IPSec/IKE.
- You can see & verify established connections in VNet → Gateway → Connections blade as "Status: Connected"
- Works across regions, subscriptions, deployment models, cloud/on-prem.
- 💡 Use one VNet as gateway and peer other ones on Azure. Gateways on every VNet is costly & slow!
- On Azure the connection does not go over the internet.
- Deploy Gateway on each VNet.
- Set-up connection in VNet1 gateway to VNet2
- Set-up connection in VNet2 gateway to VNet1
- If one VNet is on-prem it's called Site-to-site (S2S)
- On-premises VPN device <=> Azure VPN Gateway
- The local gateway is configured manually
- Problem: All users download VPN client to connect Azure.
- Easier: Have a hardware device as jumpbox and use it as gateway through secure ip tunneling.
- Even easier: ExpressRoute.
- Or Point-to-site virtual private network (VPN)
- Configure =>
- IP address space for clients.
- Configure virtual gateway
- Create root and client certificates & upload to azure
- Install VPN client configuration created by Azure
- Connect to VPN
- Private connection that does not go over the internet.
- BDP is the only routing way.
- Reliable => Circuits consist of two connection to Microsoft Enterprise Edge.
- Facilitated by a connectivity provider (e.g. Telia, Tele2)
- The virtual networks you connect are across subscriptions and regions.
- All traffic is routed over Azure internal networks, handled by Azure infrastructure.
- Faster & easer to setup than VPN
- No public IP required
- No downtime when creating/configuring peering.
- Regional network peering => In same VNet
- Global network peering => Cross region VNets (in preview)
- Requirements:
- Public clouds (not Azure national clouds)
- Resources in one VNet cannot communicate with load balancer in the peered VNet. Load balancer and resources that communicate with it must be in same VNet.
- ❗ Limitations:
- Not transitive.
- E.g.: VNet1<=>VNet2 and VNet2<=>VNet3 does not mean VNet1<=>VNet3
- No overlapping address spaces
- Any address space changing => Destroy peering re-deploy
- Not transitive.
- Allow forwarded traffic
- Allows traffic not originated from within peer VNet to VNet.
- Allow gateway transit
- Peer VNet uses your network gateway.
- Allows you to have single gateway, instead of gateway per VNet (called hub-spoke topology)
- Examples:
- Site-to-site VPN <=> On-prem network
- VNet-to-VNet <=> Another VNet
- Point-to-site VPN <=> Connect client
- Use remote gateways
- Uses peer's virtual gateway.