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.       While certain resources need to be provisioned only once during the application process, KeyVaults can be numerous with instances isolated per application per region. This helps with overcoming a high volume of requests and the KeyVault service limits.

2.       Ensure throttling is in place and that the client honor exponential back-off policies for 429’s with retries

3.       Cache the secrets retrieved from KeyVault in memory and reuse them from memory whenever possible.

4.       Use AzCopy with cron jobs for high-rate data transfer such as for logs. This will cut costs when compared to Azure Data Factory and Azure Data Lake resources

5.       Create diagnostic settings to send platform logs and metrics to different destinations. A single diagnostic setting can define no more than one of each destination. A resource can have up to 5 destination settings.

6.       If metrics must flow into logs, leverage the Azure monitor metrics REST API and import them into the Azure Monitor logs using the Azure monitor Data Collector API.

7.       Access Tiers for Azure blob storage can be one of hot, cool, or archive.  Infrequently accessed items are best served by the last one of the tiers. Data in the archive tier can take several hours to retrieve depending on the specified rehydration priority. 

8.       Account-level tiering – Blobs in all three tiers can co-exist within the same account.

9.       AD Connect is required to enable SSO between on-premises and cloud-based Azure Active Directory instances. A password hash mechanism will allow the cloud instance to complete authentication requests even when the on-premises instance goes down.

10.   Azure AD Conditional access can help author conditions when the password authentication must be turned off for legacy applications based on DateTime or other such criteria.

11.   Azure account lockout policy can be specified to thwart unwanted repeated authentication requests from clients

12.   Resources can be locked to prevent unexpected changes. For example, the lock level can be set to CanNotDelete or ReadOnly which is the equivalent of restricting all authorized users to the permissions granted by the Reader role.

13.   When a lock is applied at a parent scope, all resources within that scope inherit the same lock. Resources added later will inherit the lock from the parent. The most restrictive lock in the inheritance takes precedence.

14.   Azure Blueprints can be used to assign policies in how resource templates are deployed which can affect multiple resources, it helps adhere to an organization’s standards, patterns, and best practices. It cannot be used to specify role assignments. It can consist of one or more policies.

15.   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.

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