Some trivia for Azure public cloud (continued from previous article)

Operational requirements for hosting solutions on Azure public cloud:

·        Applications can be installed in Virtual machine scale sets with an Azure Template. A custom script extension can be added to the template. The reference to location of the script can be passed in as a parameter. Alternatively, http calls can also be made.

·        A site-to-site VPN gateway can be configured between Azure and on-premises. Site to Site VPN gateway can provide better continuity for the workload in hybrid cloud setup with Azure. A load balancer front-end ip address cannot be reached with Virtual network peering across regions. Support for basic load balancer only exists within the same region but gateway transit can be allowed in globally peered network

·        An Azure AD Connect server can be set up with either passthrough authentication or password hash authentication. The latter is supportive even when on-premises goes down. Connections must be allowed through the *.msappproxy.net and Azure datacenter IP ranges.

·        Notify Azure Sentinel alert to your email automatically.  This step requires a playbook to be created with designer user-interface and does not require code to be written. Completing this step is required since there is no built-in feature for Sentinel.

·        Network traffic inbound and outbound from a virtual network subnet can be filtered with a network security group using the Azure portal. Security rules can be applied to resources deployed in a subnet. Firewall rules and NSGs both support restricting and allowing traffic.

·        Servers running on Hyper-V can be discovered and assessed via Azure Migrate. Azure account, Hyper-V host and the Azure Migrate appliance is required for this purpose.

·        Diagnostic settings to send platform logs and metrics to different destinations can be authored. Logs include Azure Activity logs and resource logs. Platform metrics are collected by default and stored in the Azure monitor metrics database. Each Azure resource requires its own diagnostic settings, and a single setting can define no more than one of each of the destinations. The available categories will vary for different resource types. The destinations for the logs could include the Log Analytics workspace, Event Hubs and Azure Storage. Metrics are sent automatically to the Azure Monitor Metrics. Optionally, settings can be used to send metrics to Azure monitor logs for analysis with other monitoring data using restricted queries. Multi-dimensional metrics (MDM) are not supported. They must be flattened

·        Data collection rules (DCR) specify whether data coming to Azure monitor should be sent or stored. Input sources include Azure Monitor agents running on virtual machines, virtual machine scale sets, and Azure Arc for servers. A rule includes data sources, streams which is a unique handle that transforms and schematizes as one type, destinations for where the data should be sent and data flows for definitions of which streams should be sent to which destinations.

·        Automatic tuning in Azure SQL database and Azure SQL managed database instance can help with tuning on peak performance and stable workloads. There is support for continuous performance tuning based on AI and machine learning.

·        Limited access to Azure storage resources can be granted using shared access signatures (SAS). With a SAS there is granular control over how a client can access data, what resources it has access to, what permissions it has on the resources and how long it is valid. There are three types of SAS - user delegation SAS, Service SAS and account SAS.  The SAS token is generated on the client side using one of the Azure storage libraries. If this is leaked, it can be used by anyone, but it is set to expire.