Bastion Updates
Bastion is one of Microsoft’s newer features within Azure, it is a service that allows you to connect to virtual machines from the Azure portal using a browser. It provides RDP and SSH connectivity to your deployed VMs over TLS connections.
Using Azure Bastion allows you to connect to machines within them having a public IP address or requiring you to expose RDP/SSH ports to the outside world.
Until recently there has been one restriction that can cause some headaches. Bastion was restricted to the Virtual Network it was deployed into. This meant if you had peered networks you would need to deploy multiple Bastion hosts to access all your deployed resources. This has now changed…
In a recent blog post, Microsoft has announced Bastion will now work across peered VNets, this means if you have a Mesh or Hub and Spoke setup, deploying a single Bastion host in a single VNet (the hub in H&S’s case) you will be able to access all VMs in the peered networks. Meaning you do not have to spend as much money deploying the Bastion Hosts into your environments.
Bastion is a great service that can increase security around Virtual Machines, but can be costly for something that gets periodic use. Therefore with this news of VNet Peering it got me thinking of ways to save money.
I decided to have a quick play around with Schedule Jobs within Azure DevOps. I created a couple of simple AzureCLI scripts that would create the Bastion service with associated VNet and Resource Group, and the other script just deletes everything. This was with a view of deploying a Bastion Service into a standalone VNet that could then be peered on Demand with necessary VNets when access is needed. (This peering could be done as part of the script)
Using Azure DevOps I created a couple of Pipelines (BastionDeploy and BastionDestroy), these pipelines are set to run on a schedule rather than on Pull Requests or Commits, and regardless of whether the scripts have changed. Both pipelines have a single stage that runs a basic shell script in AzureCLI.
These scheduled tasks mean the Bastion service is deployed before work starts and is destroyed after the working day is complete. Great to save the costs of running the service for 12-16 hours of downtime. So not only reducing the number of Bastion Services needed to be deployed they are removed from the subscription Out of Hours.
As with many things within Azure and Microsoft this is not the other way this scheduled deployment could be achieved, whilst I was playing with Azure DevOps I saw Twitter posts about using both Logic Apps and Azure Functions.