How to Delete Unused Azure Network Interfaces

Blog post cover

Try Relay to clean up your cloud environments

More and more, companies from small businesses to global enterprises are migrating or deploying workloads in public cloud environments. Typically, their goal is cost optimization, as public clouds can dramatically reduce on-premises infrastructure costs and corresponding maintenance labor costs. Instead of installing more servers, storage, and networking components in your own datacenter, public cloud environments allow you to deploy dynamic cloud resources, usually with a short to medium lifespan.

While there definitely is an immediate benefit to public cloud deployments, organizations also face new challenges. Some of the main issues I have seen growing over the last few years are over-commissioning, under-usage, and failure to delete old resources. With exciting new projects to code and fires to put out, developers lack time to spring clean their cloud resources. Meanwhile, these unused resources continue driving up the monthly cloud bill and creating a bigger surface area for hackers.

One solution is Relay by Puppet. This tool provides automation workflows (using YAML and Python as standards) to identify and remove such lingering objects in your cloud environments. In this article, I will guide you through, step-by-step, how to easily remove unused resources from Azure.

Clean up Azure

When you delete an Azure Virtual Machine resource, related resources — like virtual storage, virtual network, and network interfaces cards (NIC) — are not automatically deleted, unless you select multiple individual resources for deletion or delete the Virtual Machine’s resource group.

There are five main steps to clean up Azure using Relay:

  1. Activate your Relay.sh account.
  2. Define a connection between Relay and Azure, using an Azure service principal.
  3. Create your Relay workflow, which performs the cleanup.
  4. Use and manage your workflow processes.
  5. Enjoy your clean Azure environment with no unused resources, and your lower cloud bill.

If you already have an Azure subscription with administrative access, you can go through these steps in your own environment. Or, you can sign up for a free Azure subscription.

Initial Relay Setup

Relay is a hosted software-as-a-service (SaaS) solution, so you don’t have to deploy any servers or install any software yourself.

⁣1. Navigate to the Relay sign up page and create a new account by completing the required fields. A Community account is free. Or, for collaboration across bigger teams and access to hundreds more workflows, you can upgrade to a Team or Enterprise plan.

Relay sign up form

⁣2. Wait for the activation link in your inbox and confirm it. Now, you can begin to enjoy your new account.

⁣3. Authenticate to the Relay.sh service portal. From there, you can browse sample workflows or start creating a new workflow from scratch.

Relay main navigation

⁣4. Before you can actually use a workflow, you must specify the necessary connections between Relay workflows and the cloud back end. Relay supports many different public and private cloud environments including Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, and several others.

Relay Connections list

⁣5. In our example, we will use Azure. The process is similar for other cloud environments.

Create an Azure Connection

An Azure connection relies on an Azure service principal, also referred to as an app registration in the Azure Active Directory. When the service principal is created, you can apply Azure role-based access control (RBAC) permissions to it, limiting the administrative capabilities of this account. This is a security requirement in most organizations. Note that, by design, a service principal has Contributor permissions.

Microsoft has good documentation on service principals.

There are several ways to create a service principal, including Azure Portal, Azure Cloud Shell, PowerShell, ARM Template, or REST API. I chose Azure Cloud Shell, as it is easy to use.

⁣1. From the Azure Portal, open Azure Cloud Shell from the top right menu options, and choose Bash as the interface.

Azure Cloud Shell

⁣2. Type the following Azure command line interface (CLI) command:

az ad sp create-for-rbac -n "Relaysp"

⁣3. This creates the service principal in your Azure Active Directory (AD) and shows the account credential details as shell output. Copy this information and set it aside for later use. Also identify the name of the Azure subscription, which you can find by searching for “subscriptions” from the portal search field. Copy this information and set it aside for later use.

Create the service principal in your Azure Active Directory

⁣4. Back in the Relay.sh portal, navigate to Connections. Here, select Add Connection, then select Azure from the list. Complete the fields, copying the information from the Cloud Shell output, as shown in the below example:

Relay terms             Azure Service Connection terms
- Subscription ID       - Subscription
- Client ID             - appId
- Tenant ID             - tenant
- Secret                - password

Set up you Azure connection in Relay

⁣5. Don’t forget to save your connection.

Relay Azure connection

⁣6. We are now ready to create our workflow scenario.

Author a Workflow

Relay workflows are based on the industry-standard YAML syntax, similar to what is used by Kubernetes, Azure DevOps, and many other cloud solutions.

The easiest way to get started is by selecting one of Relay’s many sample templates.

⁣1. From the Relay.sh portal, navigate to Workflows.

⁣2. Select Explore our workflow library.

Explore the Relay workflow library

⁣3. From the category list, select All use cases then select Delete unused Azure network interfaces.

Delete Unused Azure Network Interfaces workflow

⁣4. Selecting this workflow will show more details, as well as the sample YAML script. Click the Try this workflow button, give this workflow a unique name, and click Create workflow.

Create a new workflow in Relay

⁣5. This saves the workflow into the dashboard.

Edit your Relay workflow

⁣6. You will see a warning regarding a missing required connection. To resolve this issue, you need to tell the workflow which Azure connection to use. Click Fill in missing connections.

Fill in missing connections

⁣7. As highlighted below, the default connection is “my-azure-account”. You could add a new connection here but, for this example, we are going to use the one created in the previous steps. To make this change, select Code view and update the YAML file parameter connection.

Using code view in Relay

⁣8. Replace the default name “my-azure-account” with the Azure connection name you defined earlier. (For my setup, I used “Azure-Relay” as my connection name.) Make sure you save the changes.

Replace the default connection name in Relay

⁣9. Next, run the workflow. Click Run workflow and confirm by pressing run workflow in the popup window. Don’t worry that anything will destroy your NICs. Confirm that the option is set as dryRun=true, which means it will execute the script without making changes.

Run your Relay workflow

⁣10. When the workflow kicks off, it shows the step-by-step sequence:

Relay workflow in progress

⁣11. Once the dryRun workflow completes successfully, navigate to the step list-azure-nics and select View logs. The logs show the outcome of the workflow. My logs identify five network interfaces in my demo environment:

View step logs

⁣12. Select the next step in the flow, filter-nics, then select View logs. This tells you that one NIC was identified as not being used (meaning that it is not attached to an Azure Virtual Machine):

Locate unused network interfaces

⁣13. The magic to accessing this information is based on a Python script, which is picked up from the YAML script workflow:

Python script

⁣14. In here, there is a pointer to a Python script, which looks like this:

Details of Python script

You can see it is checking for any virtual machine with “append.nic”, meaning having NICs attached.

⁣15. Switch back to the Relay workflow and run the workflow once more, this time setting the dryRun to false, meaning it will force the removal of the unlinked NIC resource(s) it finds. Make sure you validate that the NIC can be deleted.

Rerun workflow with dryRun set to false

⁣16. This kicks off the workflow. A review step will prompt you for your approval before performing the actual deletion. Click Yes.

Approval steps in Relay

⁣17. After about a minute, you should receive confirmation — including confetti — of a successful workflow run.

Workflow is complete

⁣18. This is also visible from the workflow logs.

Revisit step logs to confirm success

⁣19. Now that you know you can successfully remove unneeded resources, you can set this workflow to run automatically — and cross it off your to-do list!

What’s Next?

In this article, I wanted to introduce you to Relay, a product by Puppet, to demonstrate how it optimizes Infrastructure as Code (IaC) and manages your cloud resources. Using a step-by-step example scenario, I showed you how to configure an Azure connection and used a sample delete-unused-nics workflow from the public GitHub repository.

Other example flows enable you to easily organize manual or time-triggered maintenance workflows for different resources — such as virtual machines (VMs), Disks, and Azure Load Balancers — across Azure, AWS, GCP, and other cloud services. To clean up your Azure resources and discover other powerful workflows that will save you time and money, check out Relay today.

About the Author - Peter De Tender

Peter has been working as an IT expert for 24+ years, with a background in Microsoft datacenter technologies. In early 2012, Peter started shifting to cloud technologies (Office 365, Intune), and quickly jumped onto the Azure platform, working as cloud solution architect and trainer, out of his own company. Mid 2019, Peter took on an FTE position as Azure Technical Trainer within Microsoft Corp, providing Azure Readiness Workshops to larger customers and partners within the EMEA Region and global, with a focus on Azure DevOps, Apps and Infra, and SAP workloads.

Peter was an Azure MVP for 5 years, is a Microsoft Certified Trainer (MCT) for 12+ years and is still actively involved in the community as public speaker, technical writer, book author, and publisher.