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:
VPN IPSec Tunnels for Azure Gateway
| Network Firewall Rules |
eway
Recent Comments