Here is the third episode of my AZ-303 study notes series.
Azure has 4 storage services.
Azure blobs: A highly scalable, object oriented storage. Suitable for modern cloud application object storage.
Azure Queues: Messaging and integration service. Aids in integration of loosely coupled solutions, like micro-services.
Azure files: a cloud version of q traditional file share.
Azure tables: simple storage for non-relational semi-structured data, kind of like a watered-down version of Cosmos DB. Useful for storing key pair information.
All these are grouped together because they share one thing in common, a storage account.
Like any resource in Azure, a storage account will exist inside of a resource account. Let's create one using PowerShell via the Azure Portal.
# Create an Azure Storage Account using PowerShell $rgName = "gps-storage-rg" $storageAccountName = "gpsstorageaccountdemo" $location = "East US 2" # Create a resource group New-AzResourceGroup -Name $rgName -Location $location
A few properties we should highlight.
Account Kind: Influences the features and pricing. GPv2 most of the time you'll work with this one, the others are legacy options or premium kinds.
Performance tier: Determines performance characteristics. Standard or Premium.
Replication: Configures redundancy and high availability for the underlying storage and infrastructure.
- Locally-redundant storage (LRS lowest cost option): Synchronous replication to three other scale units within the region. Low cost option.
- Zone-redundant storage (ZRS): Synchronous replication to three availability zones within the region.
- Geo-redundant storage (GRS): Asynchronous replication to a secondary region. Also includes LRS-like replication.
- Geo-zone-redundant storage (GZRS, highest cost option): A combination of ZRS and GRS (without LRS replication).
Access tier: Changes pricing models based on access levels. Hot (modified frequently), cool (less frequently), archive (remains offline for long periods of time).
# Create a new Storage Account New-AzStorageAccount -Name $storeName ` -ResourceGroupName $rgName ` -Location $location ` -Kind StorageV2 ` -SkuName Standard_GRS ` -AccessTier Hot
Public Endpoints: Storage services are built for public accessibility first, by default all services have a publicly accessible endpoint.
Firewall: Aids in restricting network access to all services that exist within a storage account.
Network Integration: Other services like Service Endpoints, Private Link, etc, allow you to change the network accessibility of Azure Storage services.
Data layer: Access keys and account and service SAS (shared access signatures).
Management layer: RBAC roles. ****
Let's spend some more time covering blobs and storage as those are the most relevant for the AZ-303.
Object oriented storage. Think of a bucket, you can put anything in it, unstructured or semi-structured data. Built for scale and performance and designed to be accessible.
Block blob: Optimized for streaming content.
Append blob: Optimized for append operations (log files)
Page blob: Optimized for random read/write operations. Used for VM disks.
Access level: keep private if you can. Change access level.
You can also host static websites on azure, I have a video covering how to deploy a Blazor project.
Access tier: hot or cool. Can be configured on blob level, not just container.
Azure files is built for centralized data, designed for SMB connectivity. In contrast to blob, it does provide a true folder hierarchy.
You can connect to the file share with SMB 2.1 (only Within region) , SMB 3.0+ and REST/HTTP.
You want security in transit (encryption). When you enforce this, you can no longer use SMB2.1 even from within the region.
Account keys and SAS can be used via rest.
Account keys and Azure AD domain Services can be used via SMB.
I plan on creating more content around Azure; it's great to share what I've been learning.
If you have any feedback at all, please let me know in the comments below or reach out to me on socials.
Thanks for reading and possibly watching!