Azure Cosmos DB Networking options
Tags: azure, cosmos
Published: 2020-09-13 13:20:01

---
title: Azure Cosmos DB Networking options
published: true
description: How to configure the various Networking options for securely connecting to Azure Cosmos DB
tags: azure, cosmos
---

Over the past sevral months or so, enhancements to the Networking options have become more active in the PaaS/Serverless area of Azure. Even for Azure Cosmos DB, which is called serverless DB, [Private Link For Cosmos DB was generally available](https://azure.microsoft.com/en-us/updates/azure-private-link-for-azure-cosmos-db-is-now-generally-available/) in spring 2020.

I would like to take this opportunity to summarize the network configuration of Cosmos DB, as we have been using this feature more and more in our real projects.

## Three approaches for Cosmos DB Networking

Most Azure PaaS services, not just Cosmos DB, offer three types of network connections,

- All networks
- Service endpoints
- Private endpoints

In fact, even with Cosmos DB provisioning, you can choose from three options (even after provisioning)

![Cosmos DB provisioning (Networking)](https://dev-to-uploads.s3.amazonaws.com/i/jhj58rladvmy8teo9ohy.png)

On the configuration screen, the expression is slightly different: `Public endpoint` is a connection via Service endpoint and `Private endpoint` is a connection using Private Link.

## Service endpoints

Connection to Cosmos DB via Service endpoint is completed by adding a virtual network in the `Firewall and virtual networks` menu. When selecting a VNET, you need to specify a subnet to connect to Cosmos DB service endpoint (Public IP endpoint). The configuration may take up to 15 minutes to take effect, so you may have to wait until the `Endpoint Status` becomes `Enable`.

- [Configure access from virtual networks (VNet) | Microsoft Docs](https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-configure-vnet-service-endpoint)

One thing to keep in mind when setting up Service endpoint is that unless the client is participating in the virtual network, you won't be able to use Data Explorer or Azure Storage Explorer to manipulate the data. The easiest solution is to add the client IP address to the Firewall (also configurable in CIDR Range). In addition, you should also check the `Allow access from Azure Portal` if you are operating from the Azure Portal.

With the virtual network and IP firewall configured, it looks like this

![Firewall and virtual networks settings](https://dev-to-uploads.s3.amazonaws.com/i/oeurd18jiz8dgw9avxin.png)

## Private endpoints

This is the connection via Plivate Link, where a private IP is assigned to the Cosmos DB endpoint, which is easy to use in an environment where you are using ExpressRoute to connect on-premises networks and virtual networks.

- [Configure Azure Private Link for an Azure Cosmos account | Microsoft Docs](https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-configure-private-endpoints)

For configuration, go to the `Private Endpoint Connections` menu and click on `+ Private Endpoint` to configure private endpoints (create a private endpoint, specify a subnet, set a private DNS zone). When the configuration is complete, a Private endpoint resource will be created as shown below.

![Private Endpoint settings](https://dev-to-uploads.s3.amazonaws.com/i/56pyhv3whdx4zuxfr1xn.png)

For client environments with Private endpoint, Cosmos DB can be used in conjunction with IP Firewalls. If you have policy constraints, you may need to connect to a virtual network using ExpressRoute or via Azure Bastion.

---

In this entry, I have introduced Networking options in Azure Cosmos DB. You can configure Service endpoints and Private endpoints in other Azure PaaS/Serverless services with almost similar settings.

With more network configuration options in the Azure Paas/Serverless area, not only has there been a wider range of network designs, but also enterprise projects that tend to have strict network policies have been helped by the fact that PaaS networks don't become an issue that stops discussions from moving forward.