Friday, July 30, 2021

Use CLI to operate managed databases without VMs

[Created on 30 July, 2021]

The original entry (Japanese) 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) Following our strategy, 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 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, cost 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 "CloudShell".

Overview of Azure Cloud Shell


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

Features & tools for Azure Cloud Shell


However, can CloudShell be deployed on their VNet? 


Deploy CloudShell to VNet

Following the document below, CloudShell can be deployed to VNet.

Deploy Cloud Shell into an Azure virtual network


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

Azure Cloud Shell – VNet


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

Get-AzADServicePrincipal -DisplayNameBeginsWith 'Azure Container Instance'

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


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


$ cat /etc/issue
Linux: CBL (Common Base Linux) Delridge 10
$ uname -r
Kernel: 4.15.0-1113-azure


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.

Virtual network deployment limitations


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

  1. Connect between CloudShell deployed VNet and service deployed VNet via VNet peering. CloudShell 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 used services. Basically, I recommend using private endpoint to connect the target database. For example, both options are available 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. 

Unsupported virtual network scenarios
PostgreSQL (Flexible Server)
MySQL (Flexible Server)



Startup of VNet deployed CloudShell is slower than that of ordinal CloudShell since Azure relay is used. However, VNet deployed CloudShell 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.

Posted at