Securely connecting to Azure Cosmos DB using Service endpoints and Private Endpoints - Episode 11
ฝัง
- เผยแพร่เมื่อ 7 ก.พ. 2025
- In this episode, Thomas Weiss returns to show off Azure Cosmos DB's support for both Service Endpoints and Private Endpoints that can secure access to your Azure Cosmos DB endpoints as well as reduce the risk of data exfiltration.
Chapters
00:01:54 - Opening
00:03:09 - A reminder of the importance of network security in the cloud
00:06:04 - Network security might seem daunting
00:09:05 - What is an IP Firewall?
00:13:52 - A Virtual Machine in the same Virtual Network
00:17:08 - Security boundaries for your VNET
00:20:54 - Private VNET connections
00:26:39 - DNS configuration
00:37:07 - Adding the security features developers need
#nosql #azurecosmosdb #security
really helpful, the fact this has only 2k views shows not many people are securing their DB cause this was the only resource that made it obvious of what to do
Very helpful , thank you
Glad it was helpful!
how do developes connect toendpoint using Private end point using ADS or studio3t. Getting error "failed to connect" for CRUD operations
how add the my ip address in without overriding in azure cosmos DB azure cli
Can u share any official documentation about connecting to cosmos db through private Ip
Check out this doc: learn.microsoft.com/azure/cosmos-db/how-to-configure-private-endpoints?tabs=arm-bicep
I'm puzzled by the Private Endpoint failover. You say (at about 31 minutes in) that the SDK doesn't care.. But surely IP routing cares? If we have an on-premise app, that connects to Cosmos DB (with a primary in EastUS) the Private Endpoint is in East US and on a subnet in East US... Then East US region fails. CosmosDB failover to the secondary region, but how do the clients on-premise actually connect to the secondary region copy when DNS resolves the FQDNs to IPs that reside on Subnets in a failed Region??
If we do a manual failover, then the IP addresses for the Private Endpoint all remain the same, but in this case the original region (with its Private Endpoint, NIC and Subnet) is obviously still available, so it's not a like-for-like test. In a real failure these would be gone.
So if an entire region fails you'd need a way to redirect your users to a secondary region using a DNS load balancer such as Traffic Manager. In fact, this is something you'd normally have in place anyway when building apps running in multiple regions. If the region is otherwise healthy and its just Cosmos that is unreachable for that region, the Cosmos SDK will automatically failover to another region based upon the order in which you specify these in the region preference array in the options for the Cosmos client.
@@AzureCosmosDB Thanks. That's made it clearer and makes more sense. Everything I'd read and watched so far seemed to suggest that failover 'just works' (out of the box). Which didn't add up from a networking/DNS point of view..
That there needs to be 'something' extra to balance queries to the failover instance in the event of a complete region failure is what I'd expect. The video in that case is a little misleading, 30 minutes in the statement does suggest that failover is "completely transparent in the event of regional issues". I guess it depends on what you define as "regional issues". If those issues are limited to CosmosDB, then the failover "will just work". If the issues are a catastrophic loss of the entire region (very unlikely I know, but we have to plan for it), then it isn't transparent as you need 'something' to direct client requests to the failover instance (whether Traffic manager or some other solution).
Thanks for the quick response. That's clarified it for me.
@@AzureCosmosDB @BobbyD thank you for this discussion, I have been searching for a viable solution to this same question for weeks
Helpful, but certainly could be more concise