A few months back I saw a post on Linked In, that got me thinking about mistakes I had either made or seen in Azure over the years.

For this years Azure Back To school, I have decided to share my top 10 Azure mistakes and pitfalls to avoid, so hopefully others will not make the same mistakes. As this post is part of the Azure Back to School series, I would encourage you to look at the schedule for the rest of this year’s Azure Back to school sessions.

Not Setting Budget Alerts

If I gave someone only one tip when using Azure, this would be it. Forgetting to set budget alerts can lead to many unexpected costs. Individual services billed by the minute can initially seem inexpensive, however a server running 24/7 can lead to surprisingly high costs. Even if you are diligent in stopping the services, things like auto scaling and any costs directly linked to the amount of traffic you are receiving can lead to unplanned expenses.

Budgets can sound like a feature that may only be used by large organizations, but I feel they are essential for anyone using Azure. The cost management tools in Azure help you monitor your spending, however you can also set budgets and budget alerts. As part of setting your budget, you can then set to be alerted when you reach a certain percentage of your actual or forecasted spend.

It is worth a note that budgets are not blocks on spending, so it is possible to exceed them, they are just a way to alert you to potential issues.

Inconsistent Naming

When starting in Azure it is easy to create resources with just any name. You may later then start to build out a naming convention, but it can be difficult to manage as the number of resources and team members grow. This can lead to confusion and make it difficult to manage resources over time.

Starting with a clear thought out naming strategy can help avoid these issues. These can also be enforced with Azure policy if you wish.

To get started the cloud adoption framework has a great naming convention guide. There is also a list of abbreviations and acronyms that can be used to help with naming resources.

Remember that some resource names are restricted, such as not having hyphens in storage account names, therefore you need to include this when you plan a naming strategy.

Ignoring Infrastructure as Code

The Azure portal is great to get infrastructure up and running quickly, and something I still use for quick demos. However, it is easy to forget about the setup of resources you have created and how they are configured. As the system grows and you need to deploy multiple copies of the same resources, it becomes increasingly important to manage your infrastructure as code.

If you have looked before at Infrastructure as Code and discovered ARM templates, it could be off putting. Bicep (that is converted to ARM) and Terraform are now the preferred choices with the Azure Portal showing how to implement these for each resource.

Skipping Managed Identities

When building applications we nearly always need to connect to other Azure resources, such as databases, storage accounts or Key Vaults. These all can provide authentication via connection strings, secrets and passwords. The downside is that you need to store these securely and rotate them on a regular basis. When starting out with Azure it is easy to rely on connection strings in your application code but there is now a better alternative. This is where Managed Identities come in, they allow your applications to authenticate to Azure services without the need for credentials in your code.

You can either use System-assigned Managed Identities attached to a single resource such as a Azure App Service or a standalone User-assigned Managed Identity. You can then grant the identities permissions to other Azure resources. Finally your code can access the resources with the Azure SDKs with no need to manage any secrets.

Orphaned Resources

It can be easy to spin up resources and then forget about them. It is also possible to accidentally leave resources behind that used to be part of a larger system. The easiest things to miss are IP addresses no longer attached to machines, VMs that are not doing anything, detached disks or empty subscriptions and resource groups.

Although these do not always lead to extra cost, in some cases they can. These resources also can be a security risk or in the best case scenario just lead to confusion years down the line.

Luckily there are a number of ways to detect and clean up orphaned resources. Azure cost advisor can help you identify orphaned resources, App Service Plans with no apps, and other underutilized resources. Azure Resource Graph can be used to query for resources that are not attached to anything or are in a particular state.

No Monitoring and Alerting

By default when you deploy resources in Azure, they do not have any alerting set up automatically. This means that if something goes wrong, you may not be aware of it until it is too late. Its always better to know about issues before your users tell you.

Alerts can be configured for various metrics and logs, allowing you to proactively monitor the health and performance of your applications. By setting up alerts, you can receive notifications via email, SMS, or other channels when specific conditions are met, enabling you to take action before users are impacted.

Not Using KeyVault References

Key Vault is a great way to store secrets, but we can often still find secrets in environment variables and configuration files. This can lead to security risks, and need to maintain these secrets in multiple places.

By using Key Vault references, we can securely point to the secrets from these locations without having a copy of them. They can be used with Azure App Service Plans, Azure App Configuration and other Azure services.

Keeping Development and Production in Same Subscription

Azure offers many RBAC options to control access to resources, however it is easy to give too much access to developers. This can lead to accidental changes in production or even worse, deleting production resources. Microsoft recommends using separate subscriptions for different environments (production, staging, development etc.) to minimize the risk of accidental changes and to better manage access controls.

If you are interested in reading more I have another post covering on How to Separate Production, Test and Development Resources in Azure that covers this topic in more detail.

Unfiltered Log Ingestion

It is important to filter log data to redact sensitive information. If you are using C# you can use the Redaction Nuget to help with this.

The next consideration is the volume of data being sent to Log Analytics. By default, when sending to Log Analytics all log data is sent, which can lead to high costs if not managed properly. You can sample the data either before you send it to app insights (this is recommended) or during the ingestion process to reduce costs.

To further help prevent unexpected high costs you can set a daily Log Analytics workspace cap which is designed to protect against unexpected spikes in data volume. This can be useful if there is a surge in application activity or errors. This can however lead to data loss, as once the cap is hit you receive no more logs.

There is a Microsoft article on logging best practices which has many more tips.

Forgetting about Tags

Nearly all resources in Azure can have tags applied. These are plain text key value pairs that allow you to categorize and manage your resources more effectively. As you get more resources managed by more people it can be easy to forget what they are for or who created them (The audit of who created them only persists for a short time). By applying tags, you can easily identify resources based on their purpose, environment, or owner. Once these are in place you can use them when filtering costs and automating tasks via policies.

It is useful to design a tagging strategy upfront to ensure consistency and make it easier to manage resources over time.

There are loads of great tips on tagging on the Cloud Adoption Framework pages.

Bonus: Committing Azure Secrets

This is not exclusively an Azure tip however it is worth mentioning. As with all cloud platforms Azure has many secrets that developers need to manage. We can reduce these using the tips above however, there may still be other sensitive information we need to access.

We can use Azure Key Vault or other secret management solutions to securely store and manage secrets. To protect developers from pushing sensitive information into source control we can use tools like GitHub Secret Protection. If you do accidentally push secrets it must be remembered to rotate them, before then removing them carefully and fully as they can persist in the GIT history.

Conclusion

Azure is a large and complex platform with many services and features. It can be easy, especially when starting out to overlook certain areas or leave them to later.

There are many other areas to consider but hopefully my top 10 list has highlighted some key points to keep in mind as you work with Azure.

Title Photo by Muhammad Daudy on Unsplash