Welcome to our latest blog post in the AZ-104 series. Today, we will explore Azure Storage Accounts, a service provided by Microsoft. Azure Storage Accounts offer four distinct services: Blob Storage, Files, Queues, and Tables, each designed to meet specific storage needs, from managing large volumes of unstructured data to handling application messages and non-relational data. With various replication strategies and flexible access methods, Azure Storage ensures data durability, high availability, and ease of management.

Blob Storage

Azure Blob Storage is perfect for storing large amounts of unstructured data like text or binary data. Blob Storage use containers to allow files to be accessible from the internet. Whether you're streaming videos or serving up documents directly to a browser, Blob Storage has got you covered. Azure Storage can also be used for archiving files, or disaster recovery. Storage Accounts are also used by other Azure services for storage.

Accessing your data is easy. You can use URLs, the Azure Storage REST API, PowerShell, the Azure CLI, or even an Azure Storage client library in multiple languages.

Azure Files

Azure Files provides the capability to set up highly available network file shares. These shares can be accessed through the Server Message Block (SMB) protocol as well as the Network File System (NFS) protocol. Some use cases for Azure Files include migrating on-premises applications that utilize file shares to Azure with minimal modification, storing configuration files accessible by multiple virtual machines, writing diagnostic logs, metrics, and crash dumps for subsequent processing and analysis.

Azure Queue Storage

Azure Queue Storage is designed for storing and retrieving messages. If you have tasks that need to be processed asynchronously Queue Storage offers this functionality. Each message in the queue can be up to 64 KB in size, with each queue storing millions of messages, which are processed by your applications when possible.

Azure Table Storage

Azure Table storage is a cloud service for storing nonrelational structured data (NoSQL) in a schemaless key/attribute format. This flexibility allows easy data adaptation as application needs change. It provides fast, affordable access for many uses, often cheaper than traditional SQL or NoSQL services like AzureSQL and CosmosDB.

Replication Strategies

The data within your Azure storage account is consistently replicated to ensure both durability and high availability. Azure Storage replication safeguards your data against planned and unplanned events, which may include transient hardware failures, network or power outages, and significant natural disasters. Replication options allow for data replication within the same data center, across zonal data centers within the same region, and even across different regions. This replication capability ensures that your storage account meets the Service-Level Agreement (SLA) for Azure Storage, even in the event of failures.

We examine four replication strategies:

· Locally redundant storage (LRS)

· Zone redundant storage (ZRS)

· Geo-redundant storage (GRS)

· Geo-zone-redundant storage (GZRS)

LRS

Locally redundant storage (LRS) is the cheapest replication option but has the least durability. In a disaster, like fire or flooding, all replicas could be lost. However, LRS is suitable when:

· Data can be easily reconstructed.

· Constant data changes make storage non-essential.

· Data governance requires replication within a specific country or region.

ZRS

Zone redundant storage (ZRS) synchronously replicates data across three storage clusters in one region. Each storage cluster is physically separated and located in its own availability zone. Each availability zone, along with its ZRS cluster, operates independently with distinct utilities and networking capabilities. Storing data in a ZRS account allows access and management of data even if one zone becomes unavailable. ZRS offers high performance and low latency. Please note that ZRS is not currently available in all regions.

GRS

Geo-redundant storage (GRS) replicates data to a secondary region far from the primary location, ensuring high durability even during regional outages. With GRS enabled, your data remains safe despite a complete regional outage or disaster.

There are two GRS options:

· Geo-redundant storage (GRS): Data is replicated to another data center in a secondary region and is readable only if Microsoft initiates a failover.

· Read-access geo-redundant storage (RA-GRS): Similar to GRS but allows reading from the secondary region at any time, even without a failover.

Both GRS and RA-GRS begin with locally redundant storage (LRS). Updates are first committed to the primary location using LRS, then asynchronously replicated to the secondary region using GRS. Both regions manage replicas across separate fault and upgrade domains within a storage scale unit, which is replicated using LRS.

GZRS

Geo-zone-redundant storage (GZRS) combines zone-redundant and geo-redundant storage for high availability and regional outage protection. Data is replicated across three availability zones in the primary region and to a secondary geographic region. This ensures data durability even during regional disasters. GZRS supports the same scalability as LRS, ZRS, GRS, and RA-GRS. Read-access geo-zone-redundant storage (RA-GZRS) can be enabled for read access in the secondary region.

Storage Account Types

General purpose Azure storage accounts are available in two types: Standard and Premium.

Standard storage accounts utilize magnetic hard disk drives (HDD). They provide the lowest cost per gigabyte and are suitable for applications requiring bulk storage or infrequent data access. These accounts support Blob Storage (including Data Lake Storage), Queue Storage, Table Storage, and Azure Files, making them ideal for most scenarios involving blobs, file shares, queues, tables, and disks (page blobs).

Premium storage accounts leverage solid-state drives (SSD) to deliver consistent, low-latency performance. Premium storage is recommended for several specific uses:

· Block Blobs: Ideal for applications with high transaction rates, such as those handling smaller objects or requiring consistent low storage latency. Suitable for Blob Storage (including Data Lake Storage).

· File Shares: Designed for high-performance or enterprise-grade applications that necessitate both Server Message Block (SMB) and Network File System (NFS) file shares.

· Page Blobs: High-performance storage specifically for page blobs, optimal for index-based and sparse data structures, including operating systems, data disks for virtual machines, and databases.

The detailed segmentation of Standard and Premium storage options ensures that users can select the most appropriate storage type to meet their unique performance and budgetary requirements.

Access and Endpoints

Every object stored in Azure Storage possesses a unique URL address. The storage account name constitutes the subdomain portion of the URL address. The combination of the subdomain and the domain name, specific to each service, forms an endpoint for the storage account.

For example, if the storage account name is mystorageaccount, the default endpoints for the Azure services are as follows:

· Container service: mystorageaccount.blob.core.windows.net

· Table service: mystorageaccount.table.core.windows.net

· Queue service: mystorageaccount.queue.core.windows.net

· File service: mystorageaccount.file.core.windows.net

The URL to access an object within the storage account is constructed by appending the object's location in the storage account to the endpoint.

To access the myblob data in the mycontainer location within your storage account, the following URL address is used:

mystorageaccount.blob.core.windows.net/mycontainer/myblob

Each Azure service can be configured for public access but if required you can restrict access in various ways. To access these settings for your storage account, use the Firewalls and virtual networks settings found in the Networking blade. Add the virtual networks that should have access to the service for the account. This setting limits access to your storage account from particular subnets on virtual networks or public IPs.

Private Endpoints allow you to connect to a storage account via a private IP address within your virtual network, enhancing security by preventing public internet access. Service Endpoints, on the other hand, extend your virtual network to Azure services over the Azure backbone network, enabling secure access to storage accounts from virtual networks or public IP ranges in the same region. Both types of endpoint can be used to further secure access to your storage account.

Summary

In conclusion, Azure Storage Accounts offer a versatile and robust solution for various data storage needs, including Blob Storage for unstructured data, Azure Files for network file shares, Queue Storage for message management, and Table Storage for non-relational data. With multiple replication strategies like LRS, ZRS, GRS, and GZRS, Azure ensures data durability and high availability. The flexibility in access methods and endpoints further enhances the usability of Azure Storage, making it an essential component for modern cloud-based applications.

Understanding Azure Storage Accounts: A Comprehensive Guide