Network Security: Firewalls, VNets, and Private Endpoints
Secure Cosmos DB network access with IP firewall rules, VNet service endpoints, Private Link/private endpoints, and CORS configuration — including when to use each approach.
Securing the front door
Think of network security as the locks on your database’s front door. IP firewall is a guest list — only listed IP addresses can enter. VNet service endpoints keep traffic on Microsoft’s private highway. Private endpoints bring the door inside your own building — no one on the internet can even see it exists.
Marcus’s security requirements
⚙️ Marcus at FinSecure must meet SOC 2 security controls:
- Production databases accessible only from the application VNet (no public internet)
- Development databases accessible from the office IP range
- Azure portal access for emergency troubleshooting
- No direct browser access to production data
IP firewall rules
The simplest network restriction — allow specific IP addresses or ranges:
# Allow office IP range and Azure portal
az cosmosdb update --name finsecure-dev \
--resource-group rg-finsecure \
--ip-range-filter "203.0.113.0/24,104.42.195.92"| Setting | Description |
|---|---|
| Empty IP filter | All public IPs allowed (default) |
| Specific IPs/ranges | Only listed IPs can connect |
104.42.195.92 | Legacy Azure portal IP (use “Add Azure Portal Middleware IPs” instead) |
0.0.0.0 | Accept connections from within Azure datacentres |
Exam tip: Azure portal access exception
When you enable IP firewall rules, you may lose Azure portal access to your Cosmos DB account’s Data Explorer. To keep portal access, either:
- Use the “Add Azure Portal Middleware IPs” option in the portal (recommended — adds the current required IPs automatically), or
- Check the “Allow access from Azure portal” checkbox in the portal UI
Note: The old portal IP 104.42.195.92 is now legacy. The portal has transitioned to new Middleware IP addresses. The exam tests the concept — “after enabling IP firewall, the developer can no longer browse data in the portal” → add the portal exception.
VNet service endpoints
Restrict access to specific Azure Virtual Networks — traffic stays on Microsoft’s backbone:
# Enable service endpoint on the subnet
az network vnet subnet update \
--resource-group rg-finsecure \
--vnet-name vnet-production \
--name subnet-apps \
--service-endpoints "Microsoft.AzureCosmosDB"
# Configure Cosmos DB to accept from this subnet
az cosmosdb network-rule add \
--name finsecure-cosmos \
--resource-group rg-finsecure \
--vnet-name vnet-production \
--subnet subnet-appsKey characteristics:
- Traffic stays on Microsoft’s backbone network (not the public internet)
- The Cosmos DB public endpoint is still used, but only from allowed subnets
- Quick to set up — no DNS changes needed
- Cannot extend to on-premises networks
Private endpoints (Private Link)
The most secure option — Cosmos DB gets a private IP address inside your VNet:
# Create a private endpoint
az network private-endpoint create \
--name pe-cosmos-prod \
--resource-group rg-finsecure \
--vnet-name vnet-production \
--subnet subnet-data \
--private-connection-resource-id "/subscriptions/.../databaseAccounts/finsecure-cosmos" \
--group-ids "Sql" \
--connection-name "cosmos-connection"Key characteristics:
- Cosmos DB accessible via a private IP (e.g.,
10.0.1.5) inside your VNet - Public endpoint can be disabled entirely
- Works with on-premises via VPN/ExpressRoute
- Requires DNS configuration (private DNS zone or custom DNS)
Network isolation comparison
| Feature | IP Firewall | VNet Service Endpoints | Private Endpoints |
|---|---|---|---|
| Traffic path | Public internet (filtered) | Microsoft backbone | Private network only |
| Public endpoint | Used (filtered by IP) | Used (filtered by subnet) | Can be disabled entirely |
| On-premises access | ✅ Via public IP | ❌ Azure VNets only | ✅ Via VPN/ExpressRoute |
| DNS changes | None | None | Required (private DNS zone) |
| Setup complexity | Low | Medium | High |
| Security level | Basic | Medium | Highest |
| Cost | Free | Free | Per-hour + data processing |
CORS (Cross-Origin Resource Sharing)
CORS controls which web domains can make direct browser-to-Cosmos-DB API calls:
# Allow a specific web app to call Cosmos DB from the browser
az cosmosdb update --name finsecure-cosmos \
--resource-group rg-finsecure \
--cors "https://app.finsecure.com"When CORS matters: Only for browser-based applications that call the Cosmos DB REST API directly. Server-side applications (APIs, Functions) don’t need CORS.
Exam tip: combine multiple layers
In production, you typically combine multiple layers:
- Private endpoints for application access (highest security)
- IP firewall with portal exception for emergency admin access
- Disable public endpoint when private endpoints are the only access method
The exam may present a scenario requiring both private endpoint access for apps AND portal access for admins — the answer is private endpoints + IP firewall exception for the portal.
🎬 Video walkthrough
Flashcards
Knowledge Check
Marcus needs to ensure FinSecure's production Cosmos DB is only accessible from the application VNet with no public internet exposure. Which approach should he use?
After enabling IP firewall on the dev Cosmos DB account, a developer can no longer access Data Explorer in the Azure portal. What's the fix?
Next up: Data Security — encryption at rest, customer-managed keys, RBAC, resource tokens, and Always Encrypted for protecting your data.