RapidStart Azure Landing Zones from LA NET ensures customers wanting to move to the cloud quickly can do so, without compromising on governance, security and best practice guidance.

RapidStart from LA NET has been built using our extensive experience and guidelines from the Microsoft Cloud Adoption Framework for Azure and the Microsoft Azure Well-Architected Framework.

Here is a slide to show the high-level offering:

Use the following illustration to see how objects can be organised in our RapidStart Azure Landing Zones by LA NET. The top left shows the option of using an app to create users for your environment with approval workflows. This can provide automated Office 365 license assignment, welcome emails and internal notifications. Our app can also be used to deploy resources to Azure from a service catalogue.

Our platforms include our custom policies as well as some built-in Microsoft Initiatives where required. When we work with NHS or UK government organisations we apply the built-in NHS initiatives. Initiatives are collections of policies that provide controls and audit checks. Whilst many of these built-in initiatives aim to highlight gaps, our custom policies help to prevent many of these gaps.

RapidStart for Data Analytics Workloads

The Data warehouse subscriptions are shown above as we also have a module we can deploy specifically aimed to help with cost management and governance of Data Analytics workloads.   This is suitable for any organisation looking to take advantage of services such as but not limited to Synapse, SQL Server, Data Factory, Data Bricks and Data Lake.

Why Use Experienced Deployment Teams for your Azure Landing Zones Build?

Work with a trusted partner to build your Azure environment, as they will have learned from all the pitfalls that go with it and will have the scars to prove it! Using an experienced team will ensure you get up and running quickly and correctly, minimizing the need for future rework and disruption. It is certainly no dark art, but it still requires experience to avoid common issues. We have listed some common pitfalls below to help you on your journey. These are just some of the many examples we see daily. We hope tips below help to understand how important it is to build a solid cloud environment from the start.

Some common Azure specific pitfalls and how to prevent them

We have put together this little list of some of the most common scenarios we see in customer Azure cloud environments. Many of these have been set up in house and sometimes by other consultants who may not be completely infrastructure or security focused.

1. Cloud Overspend

Example: User X is given contributor access to a resource group. The user then spins up a very large database and/or large spec VM, no one uses it, and it is forgotten about. Azure spend reports are not analysed correctly or at all.

Mitigation: To prevent this use case, set up Azure AD Groups and Custom Roles (if required), then grant access at the correct scope to the correct user group/s. Use Azure Policy to limit the types of resources and the specification of the resources. Use Tagging and tag enforcement for metadata on each resource for billing reporting and analysis by Cost Centre and Department for example. Make sure billing reports are available to the business with at least a high-level analysis to highlight any key issues or trends.

2. Incorrect Resource Specifications

This can happen when there is no standard build process and users can build objects in the Azure Portal or their home grown scripts. This DOES lead to inconsistent environments as well as potential for increased costs. Some objects such as VMs currently have a default option for disks to be Premium SSD which are a lot more expensive than standard HDD or even standard SSD drives.

Mitigation: Users should be able to request environments using a standard form or App. The app can generate an approval workflow which in turn can trigger an Azure DevOps pipeline or even an Azure Automation job to build the environment correctly as required. Use Azure Policy to prevent this common scenario specifically, such as “deny premium SSD drives”. If we do want to use Premium SSD Drives we simply exclude the policy on the required resource group as required.

3. Insecure Networks

This surprisingly isstillvery common, even when setup by competent engineers. We have seen highly secured SQL Server (e.g. Managed Instances) environments using Private Link, secure VPN tunnels, role-based access etc. Upon further analysis we have often found SQL Port 1433 to be open to the internet! Again, very easy to do, and there is nothing to stop you in the platform from doing this by default. We won’t go into details on why that would be a bad thing. Please also do not leave RDP port 3389 (or SSH port 22) open to VMs from the internet. This is also unfortunately very common and there should be no need for this.

Mitigation: Use Azure Policy to prevent NSG (firewall) rules that allow open access to common ports  such as 22, 3389 and 1433.  We block out these ports by default from day one for all environments.  Use services such as Azure Bastion to access servers securely without opening these ports to the internet.

Understanding the Defaults

Our RapidStart Azure Landing Zones by LA NET take into account our 9 years of experience building them. The table below is just a small example of what we mean by default options here:

Component / Service
Our policies

VPN IPSec Tunnels for Azure Gateway

The IPSec Policies are very low to ensure they cater for most devices.
Our IPSec policies are turned up to the highest level supported by our customer devices. Or we would use security specialist vendor appliances for further enhanced security.
Network Firewall Rules


Users can intentionally or accidentally leave ports open from the internet.
By Default, we block common inbound ports and public IP addresses to resources. We route the traffic through firewalls and other services to prevent resources such as VMs from becoming publicly available.
Resource Creation in any region to any spec
Users with access can generally create a resource in any region they select and with any SKU of the resource.
Our policies are locked down by default to only approved regions and only approved SKUs. Our Data module for our landing zones provides the ability to limit Synapse and SQL Server SKUs also.
The above table just gives a small example of the additional measures we add to our environments. Others include automated on-boarding of VMs to patch management, backup vaults, log analytics and anti-virus configuration. Well, we hope you enjoyed the article. Let us know of some of the common issues you see or if you are currently experiencing some of the problems highlighted above. Thank you for reading!
Reach out to us to find out more or for an informal chat.