Understanding Azure Service Level Agreements and the Resource Requirements Part 2 – Storage Accounts

Achieving High Availability and Uptime with Storage Accounts

Introduction

Data is the lifeblood of modern applications, and ensuring its durability and availability is paramount. Azure Storage Accounts provide a robust and scalable solution for data storage, with multiple replication options designed to protect your data even in the event of hardware or data center failures. In this post, we examine the different replication models—Locally Redundant Storage (LRS), Zone-Redundant Storage (ZRS), Geo-Redundant Storage (GRS), and Read-Access Geo-Redundant Storage (RA-GRS)—and discuss how each impacts the Storage Account SLA. Whether you are a developer, architect, or IT professional, understanding these configurations will empower you to design storage solutions that meet or exceed SLA requirements, often achieving 99.9% or higher availability.

A Architecture Diagram

I have always find it best to understand these concepts using diagrams

Here is an example of Local Redundant Storage Local Redundancy Storage

Here is an example of Zone Redundant Storage Zone Redundant Storage

Here is an example of Geo and Read Access Geo Redundant Storage Geo-Redundant Storage

Here is an example of Geo Zonal Redundant Storage Geo And Zone-Redundant Storage

Focus Areas

  • Storage Replication Options and Their Impact on SLA:
    Azure Storage offers multiple replication strategies, and each one carries its own availability and durability guarantees:

    • Locally Redundant Storage (LRS):
      LRS stores your data within a single data center and typically provides an SLA of around 99.9%. While this option is cost-effective, its availability is lower because it does not protect against data center-wide failures.
    • Zone-Redundant Storage (ZRS):
      ZRS replicates data synchronously across multiple availability zones within the same region. This configuration can elevate the storage SLA to approximately 99.99% by mitigating the risk of a single zone failure.
    • Geo-Redundant Storage (GRS):
      GRS asynchronously replicates your data to a secondary region, ensuring data durability in the event of a full regional outage. Due to the inherent delay in replication and the absence of read access in the secondary region by default, GRS generally offers an SLA around 99.9%.
    • Read-Access Geo-Redundant Storage (RA-GRS):
      RA-GRS builds upon GRS by enabling read access to the data in the secondary region. This extra accessibility can enhance overall availability, often providing an SLA of up to 99.99% for read operations and improved service continuity during regional failures.
  • Deployment Considerations for Data Protection:
    An effective storage solution not only depends on picking the right replication model but also on deploying it appropriately:

    • Selecting the Right Replication Option:
      Choose a replication strategy based on your application’s resilience requirements and data locality needs. For mission-critical applications needing maximum availability, ZRS or RA-GRS can be ideal.
    • Planning for Region-Based Failover:
      Ensure your architecture supports seamless failover between the primary and secondary regions, particularly if using GRS or RA-GRS.
    • Cost and Performance Trade-Offs:
      Evaluate the balance between higher SLA availability and the associated costs or latency implications—determining the best fit for your application’s operational needs.

Example Implementation

A. Configuring a Resilient Storage Account Using the Azure Portal

  1. Create a New Storage Account:

    • Sign in to the Azure Portal.
    • Click Create a resource and select Storage Account.
    • In the Basics tab, enter a unique Storage Account name, choose your subscription, resource group, and region.
  2. Select Replication Option:

    • In the Basics or Replication tab, choose your desired replication option:
      • To maximize data durability and availability, select Read-Access Geo-Redundant Storage (RA-GRS).
    • RA-GRS replicates your data to a secondary region and provides read access in case the primary region becomes unavailable.
  3. Configure Additional Settings and Review:

    • Configure networking, performance, and access tiers according to your application’s requirements.
    • Review your configuration and create the Storage Account.
  4. Verification:

    • After the Storage Account is deployed, navigate to its Configuration settings to verify that RA-GRS is active.

B. Configuring a Resilient Storage Account Using Bicep

Below is a sample Bicep template that deploys a Storage Account with RA-GRS enabled:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// Parameters for the Storage Account deployment
@description('Name of the Storage Account. This needs to be globally unique. I have used a unique set of characters based on resource group id')
param storageAccountName string = 'mystorageacct${uniqueString(resourceGroup().id)}'

@description('Location for all resources.')
param location string = resourceGroup().location

@description('Replication type for the Storage Account')
@allowed([
  'Standard_LRS'
  'Standard_ZRS'
  'Standard_GRS'
  'Standard_RAGRS'
])
param skuName string = 'Standard_RAGRS'

@description('Kind of Storage Account')
@allowed([
  'StorageV2'
  'BlobStorage'
])
param kind string = 'StorageV2'

// Deploy the Storage Account with RA-GRS replication for maximum durability and availability
resource storage 'Microsoft.Storage/storageAccounts@2024-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: skuName
  }
  kind: kind
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

Deployment Instructions:

  1. Save the above template as storageAccountDeployment.bicep.

  2. Open your terminal and log in to Azure:

    1
    
    az login
    
  3. Deploy the template with the following command:

    1
    2
    3
    
    az deployment group create \
      --resource-group MyResourceGroup \
      --template-file storageAccountDeployment.bicep
    

This Bicep template deploys a Storage Account with RA-GRS, ensuring that your data is not only protected within your primary region but is also available for read operations if needed during an outage.

Conclusion

Configuring a resilient Storage Account is a crucial step in meeting Azure’s SLA requirements for data durability and availability. By carefully selecting the appropriate replication strategy—whether LRS, ZRS, GRS, or RA-GRS—and implementing additional deployment considerations, you can ensure that your data remains both accessible and durable even during adverse events. Whether you opt for the guided experience of the Azure Portal or opt for automated deployments with Bicep, the strategies discussed in this post will help you maintain high availability, often achieving 99.9% or higher.

Learn More