Some trivia for Azure Public cloud computing

 

The Azure public cloud offers several resources for use in cloud-based solutions for customers. Even the experts resort to documentation on the resources for ambiguities and when the details escape them. The following is a list of trivia that are generally looked up and go unnoticed in the beginning.

1.       [ NOTE: This continues from the previous article but the numbering has not been restarted. ]

2.      A policy is a default allow and explicit deny system focused on resource properties during deployment and for already existing resources. It supports cloud governance with compliance.

3.      An Azure Sentinel is useful to respond to security incidents but internal analysis via logs and metrics are best done by Azure Security center.

4.      Network traffic can be studied with Azure Network Watcher but the Azure Monitoring helps with application outages and SLA investigations

5.      Filter network traffic with a Network security group. It is associated with a subnet. An application security group enables us to group together servers with similar functions.

6.      Azure Migrate helps with migrating compute and databases. It requires permissions on the source instance.

7.      Unlike the Azure SQL resource, the Azure SQL VM IaaS deployment gives full control over the SQL server instance and best serves migration when server and database permissions are granted on the source instance.

8.      If a database has become slow on a target instance of the SQL Server, leverage the auto-tuning feature to improve performance.

9.      A single Azure SQL instance can host many databases, and many write regions. There is no need to provision a dedicated instance for every region or application. This strategy is different from that of key Ault.

10.  When many virtual machines are deployed to a subscription, they may need to have prerequisites installed. This is easy to specify with a policy.

11.  There is only one storage account that can be bound to the log analytics workspace. Logs from many places can flow to the account but there must only be one account.

12.  If there are many subscriptions within the account, it will help with cost management. Resource groups help with the segregation of resources just like tags, but the billing cannot be based on tags. It must be at the subscription level. So, tags can be used for querying but cannot be relied upon for costing.

13.  Accidental delete of resource can be prevented by applying locks on the higher-level containers such as resource groups and subscriptions. If any one of them needs to be exempted, this can be based on policy.

14.  Role-based access control (RBAC) facilitates principle of least privilege. A higher privilege role such as the domain administrator need not be used to work with AD connect or for deployment purposes. A deployment operator is sufficient in this regard.

15.  Role based access control also enforce the most restrictive permission set so a general ability to read can be taken away for specific cases.

16.  A role-based access control can allow dynamic assignment of users to roles. So, when a person leaves an organization and goes to another, then a scheduled background job can revoke the privileges and perform cleanup.

17.  When it comes to securing KeyVault, the access control policies are pretty much the resorted technique. But the role-based access control is less maintenance. Besides, there is no need to keep adding and removing polices from the KeyVault because they end up being transient even if they are persisted. Instead, the role-based access control for KeyVault requires zero-touch.

These are some of the details that affect cloud capabilities planning.