Use tags to drill into Azure Enterprise Billing with Power BI

Whilst Power BI's Azure Enterprise Content Pack gives you pre-built dashboards to expose your Azure Enterprise costs, it may not provide the level of detail required to really drill-down into the finer detail of resource costs for your Azure subscriptions.

What if you wanted to tag resources to identify those that belong to your enterprises products or services and report on costs for each. For example, perhaps you'd like to be able to find out how much was spent on Azure Compute resources (Virtual Machines) and storage during the first month of an online service that you've just launched. Your VMs might be spread across Resource Groups, with their storage being held in storage accounts in multiple regions. In order to easily differentiate those resources that are dedicated to the new service from existing resources you could tag those resources as follows:

"service" : "ournewservice"

Using Microsoft's Power BI you can then connect to your Azure Enterprise billing data via the Azure Enterprise (Beta) Data Connection, see here.

The Power BI approach then enables reports and dashboards to be built that display Azure Resource costs per service, by grouping and filtering on resource tags. If you have multiple tag names, then Power BI gives you the ability to split these out into dedicated columns from which tag-specific reports can be built.

PowerShell Pea - Check Disk Usage on Remote Windows Servers using PowerShell

Found this useful script today that (given a list of Windows server names) will check the disk usage on each Windows Server (whose name is supplied in a file) and can also report results back via email.

It demonstrates an alternative to PowerShell remoting, if you want to build reports across a number of servers using a script and need to avoid labour-intensive checks of each server via RDP, for example.

Deploying Azure Virtual Networks with multiple CIDR addresses using ARM templates

I recently had to craft an ARM template in Azure for a Virtual Network that had an address space that wasn't sized as a "to the power of two".

i.e. this would be simple if you're creating a Vnet for an address space of say 256 addresses, such as

10.1.0.0 - 10.1.0.255 = 10.1.0.0/24

You can use a parameter of type "string" in the template, so assuming you arrange your parameters and template into 2 files, the parameters would include:
"vnetAddressPrefix": {
    "value": "10.1.0.0/24",
}
And the template itself would include the parameters and resource definitions for the Vnet as follows:
"vnetAddressPrefix": {
    "type": "string"
}
...
"resources": [ {
    "type": "Microsoft.Network/virtualNetworks",
    "name": "my256Vnet",
    "apiVersion": "2016-03-30",
    "location": "[resourceGroup().location]",
    "properties": {
        "addressSpace": {
            "addressPrefixes": [
                "[parameters('vnetAddressPrefix')]"
            ]
        },
        "subnets": [ {
            "name": "default",
            "properties": {
                "addressPrefix": "10.1.0.0/28"
            }
        }
        ]
    }
}
]

But, lets say you need a Vnet with 384 addresses, such as

10.1.0.0 - 10.1.1.127

Because you can't specify this range in a single CIDR address, you would instead need to create an address space in CIDR notation of

10.1.0.0/24

10.1.1.0/25

The simple "string" parameter used in the first example will not work here, instead you should use a parameter of type "array", modifying the parameter file to include the CIDR ranges as follows:

"vnetAddressPrefixes": {
    "value": [
            "10.1.0.0/24",
            "10.1.1.0/25"
    ]
}
And then changing your template file to include parameters and resource definitions as follows:
"vnetAddressPrefixes": {
    "type": "array"
}
...
"resources": [ {
    "apiVersion": "2016-03-30",
    "type": "Microsoft.Network/virtualNetworks",
    "name": "my384Vnet",
    "location": "[resourceGroup().location]",
    "properties": {
        "addressSpace": {
            "addressPrefixes": 
                "[parameters('vnetAddressPrefixes')]"
        },
        "subnets": [ {
            "name": "default",
            "properties": {
                "addressPrefix": "10.1.0.63/24"
            }
        }
        ]
    }
}
]

That's it! Although it's unlikely that a deploying Vnets in a greenfield environment would require this solution, it still may happen, and is more likely to happen in an environment where address space is already constrained by other Vnets and addressing conventions.

AWS Glue: The future of ETL is nigh

AWS will soon be launching a fully managed ETL as-a-service which promises to automate "data discovery, conversion, mapping, and job scheduling tasks" wherever your data lives, this is not just for your data stored in AWS.

AWS Glue, will provide the ETL layer that links AWS data services (S3, RDS and Redshift etc) to their and analytics services, such as Quicksight.

I for one am fascinated to see what it can do and discover real-world use-cases that can take advantage of AWS Glue, building it into the architecture of Big Data Cloud solutions.