It takes time to learn any platform, and Azure is no different. Azure is generally speaking quite easy to use, belying the complexity and hidden pitfalls one might encounter when provisioning and managing resources.
In this article, I will try to give some practical advice from what I have learned during our NML Azure journey.
The first thing that will save you loads of pain and frustration is to choose a region and stick to it. When provisioning a resource you can select the region you where you want the resource to be hosted. There is no "default", and so at times, the default selected value in the region dropdown will be different from what you previously selected. It has often happened that we have had, by accident, resources and resource groups in widely different regions.
The choice of the Azure region you want to target will depend on your precise criteria, but generally, you will want to choose the region that gives you the least amount of network latency. For South Africa, that used to be West Europe or North Europe. You also now have West UK and South UK with comparable latencies to the prior regions. However, at the time of writing, Northern South Africa is generally available, with most of the Azure resources one needs for a common software system. Southern South Africa is running and used for regional replication and backups, but not generally available yet.
NML is a services company and we host our development, testing, user acceptance criteria, and production environments on behalf of our clients on Azure. Over time we learned that provisioning a dedicated subscription for a client or project, and then grouping resources by environment in the subscription works best.
By dedicating a subscription per project or client you make billing much easier, as Azure is able to give you cost per subscription at a glance. It will also help with managing costs as you can setup cost alerts and budget on a subscription.
Grouping resources by a target environment is essential to configuring secure infrastructure for a project. Probably the most important and helpful tip here is to find a naming convention and stick to it. It will make your maintenance much more bearable.
At NML, we use the following convention: <PROJECT_ACCRONYM>-<ENVIRONMENT>. For a project, say AdventureWorks, we would have the following resource groups:
Azure costs can add up quickly if one is not careful, and so at NML we generally have a shared resource group for our development and testing environments with resources that can be shared and reused. Production is always isolated to ensure a good security posture. The resource types that are most responsible for ballooning costs and that can be shared readily are:
Role Based Access Control (or RBAC) is the heart and soul of resource security on Azure. When hosting a solution for a client, you need to ensure that you protect their interests as best you can. With RBAC you can go along way towards ensuring that goal.
RBAC works by assigning users one or more roles on any particular resource group or subscription. Each role has a strictly defined set of allowed operations that can be performed, and any action that falls outside will be denied.
The most import piece of advice here is to assign access via Azure AD security groups. Assigning roles individually quickly turns into a management nightmare. By leveraging on user security groups, you can easily swap and change user access by only having to update the security groups they belong to. You can then assign the relevant security groups on a resource group level to the roles that are needed. As far as possible, do not assign subscription wide roles to any user or group. That is because, at the time of writing, Azure does not have deny rights configuration. Roles added on a subscription level will, therefore, apply to all resource groups and resources on and inheritance basis.
We generally make a distinction between development users and production users and will, therefore, have at least two sets of security groups. The groups are named for the project or client and the role that they will be assigned to. For example, for the Contributor role on the AdventureWorks project, we will have the following security groups:
There will be similar security groups for each role to be assigned. Examples of roles we generally have are:
Using this scheme allows us to configure developer access to the development environments and to have restricted access to production environments and only temporarily assign access where and when needed.
Azure has some built-in features, some for pay, that is essential for running deployments successfully on the platform.
Security center helps in identifying and rectifying potential security risks to your resources. It will identify various platform configuration issues that you can improve, for example, configuring firewalls on key resources like Azure SQL Server, Key Vault, etc. It will also identify configuration on virtual machines that need attention.
Review Security Center recommendations frequently. Not everything is practical or applicable, but most of it is gold.
Advisor is there to help to get the most out of your resources. It checks and recommends improvements on the following:
Keep checking back in with Advisor, as it will highlight areas in your Azure ecosystem that need attention.
Here you can, at a glance, see your current monetary exposure over your all Azure resources. You should configure budgets and alerts on subscriptions and/or resource groups. It is a rather unpleasant feeling to receive a bill at the end of the month that is hugely inflated because of a development mistake or infrastructure configuration issue that could have been prevented with a timeous alert.
Be careful of racking up a slew of underutilized App Service Plans. They are mostly used for Web Apps, Logic Apps, and Functions, and should be shared. Some features are only available on higher-priced tiers, and over time you might realize you are paying more than is necessary because App Service Plans had been scaled up to unlock some needed features.
Cosmos DB is a wonderful piece of technology, but its costing is a little like black magic. It is not priced by what you use, but rather by what you think you are going to use (reserved resource model). Be conservative when you configure Cosmos DB, and scale up once you have data indicating that you need to reserve more resources.
Azure has a wonderful search feature to find resources quickly. A standard, practical naming convention across all resources (not just resource groups) will save you oodles of time. It is much better to have an advwrks-dev-frontend web app in the advwrks-dev resource group, than to just have frontend in there. Make sure everybody that has permissions to create resources follows the scheme as closely as practically possible.
Azure is a tremendously useful and pleasant platform to work on. However, one can safeguard your experience (and wallet!) by implementing and following some basic guidelines like that described above.