‘RapidStart’ Azure Landing Zones from LA NET

Start your cloud journey with RapidStart from LA NET

RapidStart from LA NET ensures that cloud services launched using Microsoft Azure Landing Zones are implemented faster and at lower cost.  The RapidStart approach 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.

Click Here to Talk To Us

Here is a sales type slide to show the high level offering.

RapidStart Azure Landing Zones

The following illustration shows an example of how objects are 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. this can also include automated approvals. Office 365 license assignment and welcome email and internal notifications. We also have an app for deploying resources to Azure from a service catalog which we will talk about in another article.

RapidStart Azure Landing Zones

Our platforms include our custom policies as well as some built-in Microsoft Initiatives where required. For example when we work with NHS or UK government organisations we can apply the built-in NHS initiative which provides a large set of controls that can be used for auditing your environment. Whilst many of these built-in initiatives aim to highlight gaps only, our custom policies help to prevent many of these gaps from happening at all.

RapidStart for Data Analytics Workloads

The Data warehouse subscriptions are shown above as we also have a module to deploy on top of the base landing zone 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 and Data Lake.

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

We would strongly recommend using a trusted partner to build out your Azure environment as they will have learned from all the pitfalls that go with building a cloud environment and will have the scars to prove it! Using an experienced team will also ensure you get up and running quickly and correctly minimizing the need for rework and disruption further down the line. 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 and hope they help to at least understand how important it is to get your cloud environment as solid as you can 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 issues 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

This is usually due to users having too much access to the cloud environment with no controls in place to limit what they can do. The users creating the resources may not even be properly trained and those in charge of spend are not seeing or looking at enough granular detail.

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, setup 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 meta data 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. Policies can be put into place to prevent this common scenario specifically, such as “deny premium SSD drives”. This is just one of the policies we are generally asked to put in. What if someone does want to implement Premium SSD Drives? Then we can simply exclude the policy on the required resource group when required.

3. Insecure Networks

This surprisingly is still very 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 find SQL Port 1433 is open to the internet! Again, very easy to do, and there is nothing to stop you in the platform from doing this by default. I won’t go into details on why that would be a bad thing. This is also unfortunately very common for VM workloads where RDP Port 3389 is also left open.

Mitigation: Azure Policy can be used to stop anyone setting up any NSG (firewall) rules that allow source “Any” to any of these and similar ports. We generally block out inbound ports 22, 3389 and 1433 as a default from day one for all environments.

Understanding the Defaults

As eluded to above, our RapidStart Azure Landing Zones by LA NET generally do not go with any default options as we have worked very hard to understand the platform from our 9 years of building them. The table below is just a small example of what we mean here : –

Component / Service Default 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 and make sure no one can make resources such as VMs 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. Do let us know 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.
You need to agree with the terms to proceed