Microsoft Azure
Published in

Microsoft Azure

Use database CLI to operate databases without either VMs or remote clients

[As of July 30, 2021]

The original entry in English is here.

Japanese edition is here.

Inquiry from customer

My customer asked me about the following topic.

“We’re creating some system on Azure. This system consists of VNet, App Service, and Azure Database for PostgreSQL.
1) The App Service instance is connected to VNet via VNet Integration, and private endpoint is deployed on VNet to connect the managed database instance.
2) Our deployment strategy is to use managed services as many as possible. Following this strategy, we don’t want to use any VMs (virtual machine).
3) Furthermore, neither VPN nor ExpressRoute is used to connect between VNet and on-premise environment.
4) Even though using managed database, a few database configuration is required.

So, we would like to use database CLI to maintain the database instance. In this circumstance listed above, what option can we use?”

According to their comment, their system topology seems the image below.

Their deployment strategy is reasonable, because…

  • indeed, costs for VMs are small, but both applying security patches to VMs and upgrading OS are mandatory in case of deploying VMs for maintenance.
  • they want to focus on valuable tasks instead of system management.

What is an alternative for VMs?

What I proposed to the customer is “Cloud Shell”.

As the following document says, psql (PostgreSQL client) is available on Cloud Shell.

However, can Cloud Shell be deployed on their VNet?

Deploy Cloud Shell to VNet

Following the document below, Cloud Shell can be deployed to VNet.

In this document, ARM template is introduced to deploy Cloud Shell on VNet.

When using the ARM template, OID (object id) is required. This value can be derived from the following command.

PS /home/logico> Get-AzADServicePrincipal -DisplayNameBeginsWith 'Azure Container Instance'

The ARM template allows us to create Cloud Shell environment deployed on VNet.

As you might know, Cloud Shell container (running on Azure Container Instances) is connected to the subnet of “CloudShellSubnet”. Storage account is attached to Cloud Shell container in order to persist content under $HOME. At the time of writing this article, Cloud Shell container seems like this.

$ cat /etc/issue
Common Base Linux Delridge 10
$ uname -r

If using PowerShell, $PSVersionTable allows us to check component versions.

PS /home/logico> $PSVersionTable

Name Value
---- -----
PSVersion 7.1.3
PSEdition Core
GitCommitId 7.1.3
OS Linux 4.15.0-1113-azure #126~16.04.1-Ubuntu SMP Tue Apr 13 16:55:24 UTC 2021
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
WSManStackVersion 3.0


As the document says, all Cloud Shell regions apart from Central India are currently supported.

As this customer’s system is not deployed in supported regions mentioned above, they have to connect their database with either of the following options.

  1. Connect between Cloud Shell VNet and service VNet via VNet peering. Cloud Shell VNet is linked to Private DNS used in service VNet.
  2. Create another subnet and deploy private endpoint to their database in the subnet.

Which options should be used? It depends upon what services you use. Basically, I recommend deploying private endpoint on Cloud Shell VNet to connect the target database and using the endpoint. For example, both options are applicable in case of MySQL/PostgreSQL Single Server, while the only option is the latter in case of Flexible Server since cross region VNet peering is not supported.


Startup of VNet deployed Cloud Shell is slower than that of ordinal Cloud Shell since Azure relay is used. However, VNet deployed Cloud Shell seems a good option if you have to use VM-like environment to maintain service(s) but you don’t want to deploy any VMs on VNet.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Akihiro Nishikawa

Akihiro Nishikawa


Cloud Solution Architect @ Microsoft. Passionate about Java (JVM/GraalVM) and open source technologies. All views are my own.