As part of the Cloud Infrastructure and Applications team here at Vuzion. I’ve previously blogged about real life use cases for Azure storage.
In this blog, I want to cover more about Azure storage, particularly around security, replication and access, and starting with replication and protecting your data inside an Azure storage account.
There are 4 types of replication you can choose from when setting up an Azure storage account.
- Locally Redundant Storage (LRS) – three copies of your data are stored in a single region. Data is written Synchronously.
- Zone Redundant Storage (ZRS) – three copies of your data are stored in a single region, but across multiple facilities. Data is written synchronously.
- Geo Redundant Storage (GRS) – three copies of your data are stored in a primary region, written synchronously, with a further three copies written asynchronously to a sister region.
- Read Access Geo Redundant Storage (RA-GRS) – this is the same as GRS, but giving you the ability to read your storage from the secondary region. This is ideal for a performance perspective when working with global applications that need to be able to bring files back to customers all over the world at low latency.
So, in this blog we’ve looked at replication, and in a previous blog (Looking at Azure Storage – by Will Jones) looked at use cases. We’ll now consider how to access the data, to either read or write to.
Azure Cloud Storage was one of the first services to come online in Azure and is a PaaS service, really orientated at being accessed programmatically by an application.
An application can gain access to a storage account and perform operations using an access key. This key is generated when the account is created, and you have two keys to choose from, allowing you to roll over keys if required.
As an example, you can create a .NET web application and use the Azure storage SDK, with the storage account name and key, to store files uploaded by a user of the web application. The application can then perform additional operations, such as providing access back to the file for the user, by generating a shared access signature or SAS.
A SAS key is essentially a URL to the file with various rights assigned to it. This SAS key can be time sensitive, and restricted to an IP address. The allows for sharing of files in a secure and controlled manner.
For those of you that don't do development, but want to be able to utilize Azure storage, then Azure Storage Explorer
This desktop application interfaces on your behalf to the Azure storage account and can be accessed using your Azure AD credentials, storage account key, or even an individual SAS key. It's a great way of being able to use Azure storage without development overhead.
Azure storage is fundamentally accessed via a REST API over HTTP/S and your application, Storage Explorer, or the SDK is simply crafting those REST requests for you.
Finally, I want to briefly cover security. As discussed earlier there is a set of master keys for performing operations against a storage account, SAS keys for individual access to blobs and you can use your Azure AD credentials. All storage accounts are encrypted at rest using Microsoft managed keys and access is recommended over HTTPS.
There is a huge amount to storage accounts, and that can't be covered even in a series of blogs. But, I hope this has helped demystify them somewhat for you.