Azure is a cloud computing platform that provides a wide range of services and capabilities for building and deploying applications and workloads in the cloud. In contrast, hosting your own datacenter involves setting up and managing a physical infrastructure, including servers, storage, networking, and other components, in a location controlled by the organization.

Azure and hosting your own datacenter are two different approaches for deploying and managing applications and workloads.

There are several key differences between Azure and hosting your own datacenter, including the following:

• Capital expenditure and operational costs: Azure is a pay-as-you-go service, with no upfront costs or long-term commitments, while hosting your own datacenter involves a significant capital expenditure, and ongoing costs for maintenance, support, and infrastructure upgrades.
• Scalability and elasticity: Azure provides automatic scalability and elasticity, with the ability to scale up and down on demand, and pay only for the resources that are used, while hosting your own datacenter requires manual scaling and capacity planning, and may result in underutilized or overutilized resources.
• Security and compliance: Azure provides built-in security and compliance features, with the ability to deploy and manage applications and workloads in a secure and compliant manner, while hosting your own datacenter requires the implementation and maintenance of security and compliance controls, and may expose the organization to security and compliance risks.
• Integration and interoperability: Azure integrates well with other Azure services and technologies, as well as with on-premises environments, while hosting your own datacenter may require the use of complex integration and interoperability solutions, and may result in vendor lock-in and interoperability challenges.

Overall, Azure and hosting your own datacenter are two different approaches, with different advantages and disadvantages. Azure can provide a more cost-effective, scalable, and secure solution, but may require the adoption of a different operating model and a learning curve, while hosting your own datacenter can provide more control and flexibility, but may require a larger investment and ongoing operational costs.

The total cost of ownership (TCO) of Azure and on-premises can vary depending on several factors, including the specific services and resources that are used, the usage patterns and workloads, the pricing options and discounts, and the cost optimization strategies and techniques that are implemented.

In general, the TCO of Azure can be lower than the TCO of on-premises, for the following reasons:

• Azure provides a pay-as-you-go pricing model, with no upfront costs or long-term commitments, and the ability to scale up and down on demand, and pay only for the resources that are used. This can help to reduce the overall TCO, compared to the upfront capital expenditure and ongoing operational costs of on-premises infrastructure.
• Azure provides built-in support and maintenance services, as part of the subscription fees, and the ability to choose from different support and maintenance plans, depending on the specific needs and requirements of the organization. This can help to reduce the TCO, compared to the costs of hiring and maintaining a dedicated IT staff for on-premises infrastructure.
• Azure provides built-in security and compliance features, and the ability to deploy and manage applications and workloads in a secure and compliant manner. This can help to reduce the TCO, compared to the costs of implementing and maintaining security and compliance controls for on-premises infrastructure.

Overall, the TCO of Azure can be lower than the TCO of on-premises, due to the pay-as-you-go pricing model, the built-in support and maintenance services, and the built-in security and compliance features. However, the actual TCO may vary depending on the specific needs and requirements of the organization, and on the implementation and cost optimization strategies that are used.

Azure Storage account SFTP functionality has now gone GA (Generally Available) across most regions as part of the GA release - SFTP support for Azure Storage accounts was free while it was in preview - but now that the service is GA - there is an additional charge for SFTP (Secure File Transfer) functionality.

Enabling the SFTP endpoint has a cost of $0.30 per hour. We will start applying this hourly cost on or after December 1, 2022.

This service has worked for me without a hitch for months, but as with most resources in Microsoft Azure - you pay for what you use! Therefore, there may be instances where you do not need SFTP support 24 hours a day, seven days a week! This is where the following Azure Automation runbook can help.

Feel free to check out a previous article on setting up SFTP support for an Azure storage account.

Overview​

Using an Azure Automation PowerShell runbook and Schedules (as part of the Azure Automation account) - we can turn on the SFTP endpoint - when we need it and disable it - the rest of the time - which is excellent from a security and cost perspective.

Prerequisites​

To do this, we will need an:

• Azure Automation Account
• System Managed Identity set with Storage Account Contributor rights
• PowerShell runbook (supplied below)

For this article, I will assume you already have an Azure Automation account - if you do not - then follow the Microsoft documentation: Create a standalone Azure Automation account.

Deploy & Configure​

Now that the Azure Automation account has been configured and set up - we need to add the Runbook, but before we can do that - there are some dependencies. For example, SFTP is a new service that the currently installed Az Modules in the Azure Automation don't have visibility on - so to configure the SFTP service - we need to update 2 Modules to the most recent version.

These modules are:

• Az.Accounts (≥ 2.10.3)
• Az.Storage

Az.Accounts are a dependent service of the latest Az.Storage account, so let us import that first.

Update Az.Accounts module​

1. In the Azure Portal, navigate to Azure Automation accounts.
2. Find your Azure Automation account and, click on it, navigate to Modules (under Shared resources).
3. Select Browse Gallery
4. Search for: Az.Accounts
5. 
6. Click 'Az.Accounts' and select Select.
7. Set the runtime version to: 5.1 & select import
8. Wait for 5 minutes while the module imports.

Update Az.Storage module​

Note: the Az.The accounts module will need to finish its import before the Az.The storage module is updated.

1. In the Azure Portal, navigate to Azure Automation accounts.
2. Find your Azure Automation account and, click on it, navigate to Modules (under Shared resources).
3. Select Browse Gallery
4. Search for: Az.Storage
5. 
6. Click 'Az.Storage' and select Select.
7. Set the runtime version to: 5.1 & select import
8. Wait for 5 minutes while the module imports.

Create System Managed Identity​

Now that the base Modules have been updated, we need to create a System Managed Identity - this Managed Identity will allow the Azure Automation runbook to authenticate to your Azure resources - and, in our example - make changes, such as Disabling or Enabling the SFTP service. This System Managed Identity will need Storage Account Contributor rights.

1. In the Azure Portal, navigate to Azure Automation accounts.
2. Find your Azure Automation account and click on it; click on Identity (under Account Settings)
3. Select Status to: On and select Save
4. Click on: Azure role assignments
   1. Select your Scope (in our example, we will go with Storage - to limit what changes this Azure Automation account can make)
   2. Select the Subscription and Storage account Resource on which you want to disable or enable the SFTP service.
   3. For the role, select Storage Account Contributor.
   4. Click Save

You should now see the Azure automation account, listed as having Storage account contributor rights - under your Automation account's Access Control (IAM) blade.

Import Runbook - Set-AzStgFTP.ps1​

Now that the AzAccounts, Az.Storage modules have been updated, and the Azure Automation account has been given permission - to enable and disable the SFTP service on the storage account- it's time to import the Runbook that will make this happen.

1. In the Azure Portal, navigate to Azure Automation accounts.

2. Find your Azure Automation account and, click on it, navigate to Runbooks (under Process Automation).

3. Click + Create a Runbook

4. Enter your runbook name (i.e. Set-AzSFTP)

5. Select the Runbook type as PowerShell

6. Select the Runtime version as: 5.1

7. [Optional] Add a description of what this Runbook does and who to contact.

8. Click Create

9. Open the newly created blank Runbook, and select Edit

10. Copy the following PowerShell script into the Edit pane:

     param
        (
            [Parameter(Mandatory=$true,Position = 0, HelpMessage = 'Enter the Azure Resource Group, that contains your Azure Storage account')]
            [string]
            $resourceGroupName,
        
            [Parameter(Position = 1, Mandatory = $true, HelpMessage = 'Enter the Azure Storage account name')]
            [string]
            $storageAccountName,
        
            [Parameter(Mandatory = $true, HelpMessage = '$True = Enable SFTP & $False = Disable SFTP')][ValidateSet('False','True')]
            $enableSftp
        )
      
          <#
        .SYNOPSIS
        Disables or enables SFTP support on an Azure Storage Account.
        .DESCRIPTION
        Disables or enables SFTP support on an Azure Storage Account. The intention is for this script to be used in Azure Automation, alongside a Schedule to enable or disable SFTP support on an Azure Storage Account.
    
        .EXAMPLE
        Set-AzStgSFTP -resourceGroupName sftp_prod -storageAccountName sftpprod0 -EnableSFTP $true
      #>
    
      
      # Ensures you do not inherit an AzContext in your runbook
    Disable-AzContextAutosave -Scope Process
    
    Import-Module -Name Az.Storage
    # Connect to Azure with system-assigned managed identity
    $AzureContext = (Connect-AzAccount -Identity).context
    
    Write-Output -InputObject $AzureContext
    Write-Output -InputObject $AzureContext.Subscription
    Write-Output -InputObject $resourceGroupName 
    Write-Output -InputObject $storageAccountName
    Write-Output -InputObject $EnableSFTP
    # set and store context
    $AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext
    
      
      $SetSFTP = [System.Convert]::ToBoolean($enableSftp)
    
        $SFTPStatusBefore = Get-AzStorageAccount -DefaultProfile $AzureContext -ResourceGroupName $resourceGroupName -Name $storageAccountName | Select-Object -ExpandProperty EnableSftp
    
        $Status = $SFTPStatusBefore -replace 'True', 'Enabled' -replace 'False', 'Disabled'
    
        Write-Output -InputObject ('SFTP for {0} currently has SFTP set to: {1} before update.' -f $storageAccountName, $Status)
      
        Set-AzStorageAccount -DefaultProfile $AzureContext -ResourceGroupName $resourceGroupName -Name $storageAccountName -EnableSftp $SetSFTP 
       
    
        $SFTPStatusAfter = Get-AzStorageAccount -DefaultProfile $AzureContext -ResourceGroupName $resourceGroupName -Name $storageAccountName | Select-Object -ExpandProperty EnableSftp
    
        $Status = $SFTPStatusAfter -replace 'True', 'Enabled' -replace 'False', 'Disabled'
    
        Write-Output -InputObject ('SFTP for {0} currently has SFTP set to: {1} after update.' -f $storageAccountName, $Status)
    

11. Click Save

12. Click Publish

Run Runbook - Set-AzStgFTP​

Now that the Runbook is imported, we need to run it.

The Runbook uses the following parameters:

1. Next, find your Runbook, and select Start.
2. Enter your parameters, Resource Group, Storage Account and Enable SFTP.
3. 
4. Click Ok
5. The Runbook will run, and as you can see - outputs its state Before the Runbook ran and after.
6. 

Once working correctly, you can set up an Azure Automation schedule to trigger the runbook to enable and disable the SFTP when needed only!

Azure-Firewall-mon is a near real-time Azure Firewall log viewer.

Azure-Firewall-mon provides an alternative_and_opinable 😊 way to access and inspect Azure Firewall logs. The recommended approach for analysing Azure Firewall logs is to set up a Log Analytics Workspace to collect all the data and use Kusto (KQL) queries to check what's happening.

In Azure-Firewall-mon, the idea is to provide an approach much more like Sysinternals Process Monitor or Check Point's SmartView, where there is no queries or dashboards that you need to implement first to get working. Still, all events are available as a log stream. In addition, a full-text search at the top of the page lets you quickly filter the content displayed on the screen, helping you understand what is happening right now (or close to present).

Overview​

Azure-Firewall-mon (AFM or Azure Firewall Monitor) is a custom solution (currently in a functional beta) created by an Italian Microsoft Cloud Solution Architect called: Nicola Delfino, its worth mentioning that although a Microsoft CSA makes AFM, IT IS NOT A SUPPORTED MICROSOFT PRODUCT.

Monitoring Azure Firewall can be a pain - with trawling through logs - using the Azure Firewall Workbook - helps fill in the gap - especially around the application and network rule traffic. Still, you may want something more straightforward and designed for real-time traffic to assist with in-the-moment troubleshooting.

Azure-Firewall-mon is an open-source, single Page Application written in Angular and hosted on an Azure WebApp - so to use this, you don't need to deploy to your environment.. add in an Event Hub connection string, and away you go (there is also a demo mode - so you can see what the experience will be like)!

We can deploy it to an Azure Static Web App for those who would instead host it in our environment.

"Azure Static Web Apps is a service that automatically builds and deploys full-stack web apps to Azure from a code repository. When you create an Azure Static Web Apps resource, Azure interacts directly with GitHub or Azure DevOps to monitor a branch of your choice. Every time you push commits or accept pull requests into the watched branch, a build is automatically run and your app and API is deployed to Azure."

Deployment​

Prerequisites​

Today, we are going to deploy Azure-Firewall-mon into an Azure Static Web App - to do this; we will need the following prerequisites:

• A GitHub account
• An Azure subscription_(with permissions to deploy Event Hub, deploy an Azure Static WebApp, and configure Diagnostics on the Azure Firewall)_
• Azure Firewall (provisioned)

Note: Also, ensure that your Event Hub is in the same region as your Azure Firewall so that you can use Diagnostics settings. Regarding the Azure Static WebApp - it doesn't matter; this is a global service - and you will be entering the Event Hub listener.

We will use the Azure Portal and a browser to provision the workflow (however, I will have added Azure Bicep to the bottom of the article for reference).

This article - assumes you have basic knowledge of GitHub and Microsoft Azure.

For this demo, I am using a Hub & Spoke Azure topology.

Fork the GitHub repository​

The first thing we need to do is clone the Azure-Firewall-mon repository; this repository holds the source control of Azure-Firewall-mon. First, however, we need a clone of it - to use in our Static Web App - this will also allow us to pull down and build the latest changes and updates of the Azure-Firewall-mon tool while having the stability of maintaining your version of the device.

1. In your favourite browser of choice, navigate to: https://github.com/nicolgit/azure-firewall-mon.
2. Click Fork (top right of the repository)
3. 
4. Click Create fork
5. You have now created a fork of the 'azure-firewall-mon' repository; when a new update of Azure-Firewall-mon comes out - you can also select 'Sync fork' - to keep your fork up-to-date and trigger a new build.

Create Static Web App and deploy azure-firewall-mon​

Now that you have created a fork, it's time to make your Azure Static WebApp!

1. Navigate to the Azure Portal
2. Click + Create a resource
3. Type in: Static Web App
4. Select and click Create
5. Create or select a Resource Group
6. Type in the name of your Static Web App
7. For the plan type, we will go with Free
8. Please select your region (this is the staging environment used to create your resource so the Azure Static Web App can then be replicated geographically).
9. Select Source, as GitHub
10. Click Sign in with GitHub (and sign in with an account with access to the GitHub Repository fork of azure-firewall-mon created earlier).
11. Authorise the Azure Static Web Apps to have access to your repositories
12. Select your organisation and the azure-firewall-mon repository you forked earlier.
13. Select 'main' for the branch
14. Under Build Presents, select Angular
15. For App location, enter "/firewall-mon-app/"
16. Leave the API location empty
17. For the Output location, enter: "dist/firewall-mon-app"
18. 
19. If you navigate to your own forked GitHub repository, you should see a new folder created under .github/workflows - and a new GitHub Actions workflow file!
20. 
21. If you select Actions in GitHub, you should see a deployment start.
22. After roughly 5 minutes, your Azure Static App - will have deployed azure-firewall-mon!
23. Navigate to your newly created Azure Static App in the Azure Portal
24. Click Browse
25. You should now see azure-firewall-mon!
26. 

Note: In GitHub, under Actions and the Build and Deploy Job, you may see a message about Note.js 12 actions being deprecated; you can set the node version to be higher.

Add the step to set the node version below submodules and above the Build and Deploy step:

      - uses: actions/setup-node@v1
        with:
          node-version: "18.x"

Refer to a copy of my Github Actions file here: AzureStaticWebAppsCICD.yml for a comparison of GitHub action - a setup-node step running on the latest version of 18.

Create Event Hub namespace and shared access policy​

Even if you use the externally hosted version of Azure Firewall Monitor, you still need an Event Hub and Namespace to stream the events from our Azure Firewall to the Azure Firewall Monitor.

1. Navigate to the Azure Portal

2. Click + Create a resource

3. Type in: Event Hubs

4. Select and click Create

5. Select your subscription and Resource Group;

6. Type in the Namespace of the event hub (i.e. AzureFirewallMonitor)

7. Select your location (make sure this is the same region as your Azure Firewall)

8. Select your Pricing Tier (in this example, I am going with Basic)

9. Click Review + create

10. Once the Namespace has been created, it's time to make our Event Hub; navigate to your newly created AzFirewallMonitor namespace.

11. Under Entitles, click + Event Hub

12. Under the name, enter the Event Hub name (i.e. AzMonitorCapture)

13. Leave the defaults (and Message retention to 1 day)

14. Click Review + Create

15. Click Create

16. 

17. Now that the Event Hub is created, we need to create a Shared access policy; in the Event Hub namespace, click on Shared access policies.

18. Click + Add

19. Type in a Policy name(i.e. AzMonitorListener)

20. Select Send

21. Click Create

22. 

    Configure Azure Firewall to stream to Event Hub and run Azure Firewall monitor​

    Now that we have an Event Hub configured and a Shared access policy set to Listen - it's time to configure the Azure Firewall to direct logs to the Namespace.

23. Navigate to the Azure Portal

24. Navigate to your Azure Firewall

25. Select Diagnostic Settings

26. Click + Add diagnostic setting

27. 

28. Type in a Diagnostic setting name (i.e. AzureFirewallMonitor)

29. Select All Logs

30. Select Stream to an event hub

31. Select your subscription, event hub namespace, event hub and policy created earlier.

32. 

33. Click Save

34. Please navigate back to your Event Hub namespace and select your Event Hub entity; now, we need to create a Shared access policy to Listen (for the entity, not the Namespace)

35. Click Shared access policies, and create a new Shared access policy with Listen.

36. Copy the Connection string-primary key

37. Navigate to your newly created Azure Static App in the Azure Portal

38. Click Browse

39. You should now see azure-firewall-mon, and enter in the Connection string-primary key copied earlier!

40. Congratulations you have now set up Azure Firewall Monitor on an Azure Static Web App and can troubleshoot your Azure Firewall quickly in real-time!

41. 

References: GitHub Action​

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    steps:
      - uses: actions/checkout@v2
        with:
          submodules: true

      - uses: actions/setup-node@v1
        with:
          node-version: "18.x"
      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_POLITE_CLIFF_06D4C2810 }}
          repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments)
          action: "upload"
          ###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
          # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig
          app_location: "/firewall-mon-app/" # App source code path
          api_location: "" # Api source code path - optional
          output_location: "dist/firewall-mon-app" # Built app content directory - optional

          ###### End of Repository/Build Configurations ######

  close_pull_request_job:
    if: github.event_name == 'pull_request' && github.event.action == 'closed'
    runs-on: ubuntu-latest
    name: Close Pull Request Job
    steps:
      - name: Close Pull Request
        id: closepullrequest
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_POLITE_CLIFF_06D4C2810 }}
          action: "close"

References: Azure Bicep​

Below are some Azure Bicep references:

Azure Static Web App​

param staticSites_AzFw_Mon_name string = 'AzFw-Mon'

resource staticSites_AzFw_Mon_name_resource 'Microsoft.Web/staticSites@2022-03-01' = {
  name: staticSites_AzFw_Mon_name
  location: 'Central US'
  sku: {
    name: 'Free'
    tier: 'Free'
  }
  properties: {
    repositoryUrl: 'https://github.com/lukemurraynz/azure-firewall-mon'
    branch: 'main'
    stagingEnvironmentPolicy: 'Enabled'
    allowConfigFileUpdates: true
    provider: 'GitHub'
    enterpriseGradeCdnStatus: 'Disabled'
  }
}

Event Hub​

param namespaces_AzFirewallMonitor_name string = 'AzFirewallMonitor'
param location string = resourceGroup().location


resource namespaces_AzFirewallMonitor_name_resource 'Microsoft.EventHub/namespaces@2022-01-01-preview' = {
  name: namespaces_AzFirewallMonitor_name
  location: 'Australia East'
  sku: {
    name: 'Basic'
    tier: 'Basic'
    capacity: 1
  }
  properties: {
    minimumTlsVersion: '1.2'
    publicNetworkAccess: 'Enabled'
    disableLocalAuth: false
    zoneRedundant: true
    isAutoInflateEnabled: false
    maximumThroughputUnits: 0
    kafkaEnabled: false
  }
}

resource namespaces_AzFirewallMonitor_name_AzMonitorListner 'Microsoft.EventHub/namespaces/authorizationrules@2022-01-01-preview' = {
  parent: namespaces_AzFirewallMonitor_name_resource
  name: 'AzMonitorListner'
  location: location
  properties: {
    rights: [
      'Listen'
      'Send'
    ]
  }
}


resource namespaces_AzFirewallMonitor_name_azmonitorcapture 'Microsoft.EventHub/namespaces/eventhubs@2022-01-01-preview' = {
  parent: namespaces_AzFirewallMonitor_name_resource
  name: 'azmonitorcapture'
  location: location
  properties: {
    messageRetentionInDays: 1
    partitionCount: 2
    status: 'Active'
  }
}

resource namespaces_AzFirewallMonitor_name_default 'Microsoft.EventHub/namespaces/networkRuleSets@2022-01-01-preview' = {
  parent: namespaces_AzFirewallMonitor_name_resource
  name: 'default'
  location: location
  properties: {
    publicNetworkAccess: 'Enabled'
    defaultAction: 'Allow'
    virtualNetworkRules: []
    ipRules: []
  }
}

resource namespaces_AzFirewallMonitor_name_azmonitorcapture_AzMonitor 'Microsoft.EventHub/namespaces/eventhubs/authorizationrules@2022-01-01-preview' = {
  parent: namespaces_AzFirewallMonitor_name_azmonitorcapture
  name: 'AzMonitor'
  location: location
  properties: {
    rights: [
      'Listen'
    ]
  }
  dependsOn: [

    namespaces_AzFirewallMonitor_name_resource
  ]
}

resource namespaces_AzFirewallMonitor_name_azmonitorcapture_Default 'Microsoft.EventHub/namespaces/eventhubs/consumergroups@2022-01-01-preview' = {
  parent: namespaces_AzFirewallMonitor_name_azmonitorcapture
  name: '$Default'
  location: location
  properties: {
  }
  dependsOn: [

    namespaces_AzFirewallMonitor_name_resource
  ]
}

You don't have a be a Microsoft MVP to engage with Microsoft product teams, and help give feedback! One of the best ways that the Microsoft product teams engage with the community- is through Public Community Calls!

Here is a list of the community calls across Microsoft Azure products.

There may be other communities I have missed - so feel free to add links in the comments.

Up-to-date links to additional public Microsoft community calls can also be found on the AWESOME-Azure-Architecture list.

Microsoft Ignite is an annual conference held by Microsoft for IT Professionals and Cloud builders - each year is a flurry of new announcements and updates! Keeping track of the changes can be a full-time job during the week (and beyond!)!

Make sure you check out the Microsoft Ignite 2022 Book of News! For a consolidated list of features and releases!

Also, check out AzureFeeds - for a consolidated feed across all Microsoft changes!

Along with the product pages, current and new Microsoft documentation have been updated to align with these new products, features and changes!

The pages that have been updated focussed on:

• Azure Infrastructure
• M365
• Security

It can be found here: