Theoretical Foundation: Create and Configure Storage Accounts

1. Initial Intuition

Imagine you need to store documents, photos, videos, and backups for an entire company. In the physical world, you would hire a storage service: you'd choose the space size, security level, warehouse location, and access rules.

An Azure Storage Account is exactly that: a logical and manageable container within Azure that groups different types of storage under a single identity, a single bill, and a single set of security and replication configurations.

Everything you store in Azure (files, blobs, queues, tables) lives within a Storage Account. It's the fundamental storage unit in Azure.

2. Context

The Storage Account exists because Azure needed an abstraction that:

Groups storage resources under a unique namespace (mystorageaccount.blob.core.windows.net)
Allows applying global configurations (replication, security, performance) at once
Provides billing isolation and access control

Within the Azure ecosystem, the Storage Account is used by:

Azure VMs (for unmanaged disks and diagnostics)
Azure Functions (for internal state)
Azure Logic Apps
AKS (Kubernetes) for persistent volumes
Web applications to store assets, logs, and structured data

3. Concept Building

3.1 Types of data that a Storage Account supports

A Storage Account is not a single service: it's an umbrella that houses four internal services:

Service	Portal Name	Purpose
Blob Storage	Containers	Unstructured files: images, videos, backups, logs
Azure Files	File shares	File sharing via SMB/NFS (like a network drive)
Queue Storage	Queues	Message queues for asynchronous communication between systems
Table Storage	Tables	NoSQL key-value structured data, without rigid schema

Each of these services has its own endpoint within the same account.

3.2 Storage Account Types

This is one of the most tested points in AZ-104. There are different account types, each with distinct capabilities:

Type	Technical Name	Supported Services	Recommended Use
Standard General Purpose v2	StorageV2	Blob, Files, Queue, Table	Standard for most cases
Premium Block Blobs	BlockBlobStorage	Blob only (block)	High I/O workloads, frequent transactions
Premium File Shares	FileStorage	Azure Files only	High-performance shares (SMB/NFS)
Premium Page Blobs	StorageV2 Premium	Page Blobs only	Unmanaged VM disks

Important point: The Standard General Purpose v2 type is recommended by Microsoft for almost all new scenarios. GPv1 exists for compatibility but should not be chosen for new projects.

3.3 Access Tiers

Within Blob Storage, Azure allows defining access tiers that balance storage cost versus access cost:

Tier	Storage Cost	Access Cost	Latency	Typical Use
Hot	High	Low	Immediate	Frequently accessed data
Cool	Medium	Medium	Immediate	Rarely accessed data (30+ days)
Cold	Low	High	Immediate	Very rarely accessed data (90+ days)
Archive	Very low	Very high	Hours (rehydration)	Rarely accessed data (180+ days)

The default tier is set at the account level but can be overridden individually per blob.

Non-obvious behavior: The Archive tier doesn't allow direct reading. Before accessing an archived blob, you must "rehydrate" it to Hot or Cool, which can take 1 to 15 hours depending on the chosen priority.

3.4 Replication

Replication defines how many copies of the data exist and where. This is a durability and availability decision:

Option	Abbreviation	Copies	Where	Protects Against
Locally Redundant Storage	LRS	3	Same datacenter	Hardware failures
Zone Redundant Storage	ZRS	3	3 zones in same region	Entire datacenter failure
Geo-Redundant Storage	GRS	6	2 regions (primary + secondary)	Regional disaster
Geo-Zone Redundant Storage	GZRS	6	3 primary zones + 1 secondary region	Zonal failure + regional disaster
Read-Access GRS	RA-GRS	6	Same as GRS	Same + read access in secondary
Read-Access GZRS	RA-GZRS	6	Same as GZRS	Same + read access in secondary

Critical point: With GRS and GZRS, failover to the secondary region is not automatic by default. You need to initiate failover manually or configure customer-managed failover. The RA-GRS and RA-GZRS variants allow reading from the secondary region without needing failover.

4. Structural View

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Practical Operation

5.1 Creating a Storage Account: what you define

When creating a Storage Account, you make decisions that cannot be changed later and others that can be modified. Knowing the difference is essential.

Immutable decisions (defined at creation):

Account name (globally unique, 3 to 24 characters, lowercase and numbers only)
Region (location)
Account type (Standard/Premium, GPv2/BlockBlobStorage/FileStorage)
Replication type (can change with restrictions)

Modifiable decisions later:

Default access tier (Hot/Cool)
Network configurations (firewalls, private endpoints)
Lifecycle policies
Soft delete, versioning
Access keys

5.2 Namespace and endpoints

Each Storage Account automatically generates public endpoints in the format:

https://<account-name>.blob.core.windows.net
https://<account-name>.file.core.windows.net
https://<account-name>.queue.core.windows.net
https://<account-name>.table.core.windows.net
https://<account-name>.dfs.core.windows.net  (if ADLS Gen2 enabled)

The account name must be globally unique across all of Azure, not just within your subscription.

5.3 Hierarchical Namespace (ADLS Gen2)

By enabling the Hierarchical Namespace (HNS) during creation, the Storage Account becomes an Azure Data Lake Storage Gen2, allowing:

Real directory structure (not just simulated prefixes)
POSIX-style permissions per directory
Superior performance for analytics workloads

Warning: The Hierarchical Namespace cannot be enabled after account creation. It's a decision that must be made beforehand.

6. Implementation Methods

6.1 Azure Portal

When to use: Single creations, exploring options, development environments.

The portal guides you through tabs (Basics, Advanced, Networking, Data Protection, Encryption, Tags) and presents all options with descriptions. Ideal for understanding what each configuration does.

Limitations: Slow for multiple creations; not consistently reproducible.

6.2 Azure CLI

When to use: Simple automation, provisioning scripts, CI/CD pipelines.

az storage account create \
  --name mystorageaccount \
  --resource-group myResourceGroup \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true \
  --min-tls-version TLS1_2

The --sku and --kind parameters together determine the account type:

`--kind`	`--sku`	Result
StorageV2	Standard_LRS / ZRS / GRS / GZRS	Standard GPv2
BlockBlobStorage	Premium_LRS / ZRS	Premium Block Blob
FileStorage	Premium_LRS / ZRS	Premium File Shares

6.3 Azure PowerShell

New-AzStorageAccount `
  -ResourceGroupName "myResourceGroup" `
  -Name "mystorageaccount" `
  -Location "EastUS" `
  -SkuName "Standard_LRS" `
  -Kind "StorageV2" `
  -AccessTier "Hot" `
  -EnableHttpsTrafficOnly $true `
  -MinimumTlsVersion "TLS1_2"

6.4 Bicep / ARM Template

When to use: Infrastructure as code, repeatable deployments, standardized environments.

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
  }
}

Advantage: Idempotent, versionable, integrable with DevOps.

7. Control and Security

7.1 Authentication and authorization

There are four ways to control access to a Storage Account:

1. Access keys (Storage Account Keys)

Two automatically generated key pairs
Full access to the account
Should be rotated regularly
Never exposed in code or repositories

2. Shared Access Signatures (SAS)

Tokens with defined permissions and validity
Types: Account SAS, Service SAS, User Delegation SAS
User Delegation SAS is the most secure form (uses Azure AD credentials)

3. Azure AD + RBAC

Role-based control
Relevant roles:

Role	What it allows
Storage Blob Data Owner	Read, write, delete and permission control on blobs
Storage Blob Data Contributor	Read, write and delete on blobs
Storage Blob Data Reader	Read-only access to blobs
Storage File Data SMB Share Contributor	Read, write on file shares via SMB

4. Public access (anonymous)

Can be enabled per container (not recommended)
Should be disabled at account level in production environments

7.2 Network configurations

By default, Storage Accounts accept traffic from any IP. For production, restrict:

IP Firewall: Allows only specific CIDRs.

Virtual Network Service Endpoints: Traffic from authorized VNets doesn't go through the public internet.

Private Endpoints: Creates a private network interface within the VNet, with private IP. DNS resolves the account name to this internal IP. This is the most secure option.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

7.3 Encryption

At rest: All data is automatically encrypted with AES-256. This is not optional.
Managed keys: By default, keys are managed by Microsoft (MMK). You can use Customer-Managed Keys (CMK) via Azure Key Vault for greater control.
In transit: Enabling "Secure transfer required" forces HTTPS on all connections. Always recommended.
Minimum TLS version: Configure as TLS 1.2 at minimum.

7.4 Data protection

Feature	What it does	When to use
Soft Delete (Blobs)	Keeps deleted blobs for N days	Protection against accidental deletion
Soft Delete (Containers)	Keeps deleted containers for N days	Protection against container deletion
Versioning	Maintains previous versions automatically	History and version recovery
Change Feed	Log of all blob changes	Auditing and custom replication
Point-in-time Restore	Restores blobs to previous state	Logical disaster recovery
Immutability Policies	Prevents modification or deletion (WORM)	Regulatory compliance

Important dependency: Point-in-time Restore requires Soft Delete, Versioning, and Change Feed to be enabled simultaneously.

8. Decision Making

8.1 Which replication type to choose?

Situation	Choice	Reason
Non-critical data, lower cost	LRS	3 copies in same datacenter
Regional high availability mandatory	ZRS	Protection against zone failure
Geographic business continuity requirement	GRS or GZRS	Copy in second region
Reading from secondary region without failover	RA-GRS or RA-GZRS	Read access in secondary
High-volume analytics data	LRS + external backup	Lower cost, durability managed separately

8.2 Which access tier to choose?

Access Pattern	Tier	Reason
Daily or weekly access	Hot	Low access cost compensates
Monthly access or less	Cool	Balance between storage and access
90 to 180 days retention	Cold	Cheaper storage
Long retention, rare access	Archive	Lowest storage cost

8.3 Which account type to choose?

Scenario	Account Type
General case (applications, backups, logs)	Standard GPv2
Intensive blob transaction workload	Premium Block Blob
High-performance file sharing	Premium File Shares
Analytics with hierarchical structure	Standard GPv2 + HNS (ADLS Gen2)
Unmanaged VM disks	Premium Page Blob

9. Best Practices

One Storage Account per environment: Separate dev, staging, and production in distinct accounts for access and billing isolation.
Disable public blob access at account level in production (allowBlobPublicAccess: false).
Force HTTPS (supportsHttpsTrafficOnly: true) always.
Configure TLS 1.2 as minimum version.
Use Azure AD + RBAC instead of access keys whenever possible.
Enable Soft Delete with at least 7 days retention.
Use Private Endpoints for Storage Accounts that should only be accessed from within VNet.
Rotate access keys regularly and use Azure Key Vault to store them.
Apply lifecycle management policies to automatically move data between tiers (Hot → Cool → Archive) based on age.
Name standardly: <environment><project><type><region> (ex: prodmyappstgeastus).

10. Common Errors

Error	Why it happens	How to avoid
Account name already in use	Namespace is global in Azure	Use unique prefix per organization
Cannot enable HNS after creation	HNS is immutable	Decide before creating
Blob in Archive cannot be read	Requires rehydration	Plan for access latency
Access denied even with correct key	"Secure transfer required" active and HTTP connection	Always use HTTPS
Failover doesn't occur automatically with GRS	GRS doesn't have automatic failover	Use RA-GRS and plan manual failover
Unexpectedly high cost	Data in Hot being rarely accessed	Configure lifecycle policies
SAS token expired in production	Incorrectly defined short validity	Automate rotation or use User Delegation SAS
Accidental container deletion	Container soft delete wasn't enabled	Enable at creation

11. Operation and Maintenance

11.1 Monitoring

Azure Monitor collects Storage Account metrics automatically:

Transactions: Number of requests by type and status
Ingress / Egress: Volume of data transferred
Availability: Percentage of successful requests
SuccessE2ELatency / SuccessServerLatency: End-to-end and server latencies

Configure alerts for:

Availability below 99.9%
Latency above expected
Authentication errors (possible unauthorized access attempt)

11.2 Lifecycle Management

Lifecycle policies automate the movement and deletion of blobs:

{
  "rules": [
    {
      "name": "tiering-rule",
      "type": "Lifecycle",
      "definition": {
        "filters": { "blobTypes": ["blockBlob"] },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

11.3 Important limits

Resource	Limit
Maximum capacity per account	5 PiB
Maximum request rate	20,000 requests/s
Maximum throughput per account	60 Gbps (ingress) / 60 Gbps (egress) for GRS; 120 Gbps for LRS/ZRS
Maximum size of a single blob	190.7 TiB (Block Blob)
Number of containers per account	Unlimited

12. Integration and Automation

12.1 Azure Event Grid

Storage Accounts emit events to Event Grid when:

A blob is created or deleted
A container is created or deleted

These events can trigger Azure Functions, Logic Apps, or any HTTP endpoint. Common pattern for data processing pipelines.

12.2 Azure Data Factory and Synapse

Use Storage Accounts as source and destination in ETL pipelines. The ADLS Gen2 format (HNS enabled) is the standard for modern Data Lake in Azure.

12.3 AzCopy

Command-line tool optimized for high-volume transfers:

azcopy copy 'https://source.blob.core.windows.net/container' \
             'https://destination.blob.core.windows.net/container' \
             --recursive

Supports authentication via SAS token or Azure AD.

12.4 Azure Policy

Ensure compliance at scale by assigning policies such as:

"Storage accounts should use customer-managed keys"
"Secure transfer to storage accounts should be enabled"
"Storage accounts should restrict network access"

13. Final Summary

Essential concepts:

A Storage Account is the logical container that groups Blob, Files, Queue, and Table under a single namespace, configuration, and billing.
The Standard GPv2 type is the recommended default for most scenarios.
Premium types exist for high-performance workloads and are restricted to a single storage service.
Replication defines durability and availability: LRS is local, ZRS is zonal, GRS is geographical.
Access tiers (Hot, Cool, Cold, Archive) balance storage cost versus access cost.

Immutable decisions (define before creating):

Account name
Region
Account type (kind/sku)
Hierarchical Namespace (ADLS Gen2)

Critical differences:

GRS vs RA-GRS: GRS replicates to second region but doesn't allow reading without failover. RA-GRS allows reading from secondary directly.
Archive vs Cool/Cold: Archive requires rehydration (hours) before access. Cool and Cold have immediate access.
Access keys vs RBAC: Keys give full access to account. RBAC is granular and auditable.
Service Endpoint vs Private Endpoint: Service Endpoint keeps traffic on Microsoft network but public IP remains. Private Endpoint eliminates public IP completely.

What needs to be remembered:

Storage Account name is globally unique across all of Azure.
Soft Delete, Versioning, and Change Feed must be enabled to use Point-in-time Restore.
Disable public blob access and require HTTPS in all production environments.
Lifecycle Management policies are essential for cost control in environments with large data volumes.
TLS 1.2 is the minimum acceptable; configure explicitly.

1. Initial Intuition​

2. Context​

3. Concept Building​

3.1 Types of data that a Storage Account supports​

3.2 Storage Account Types​

3.3 Access Tiers​

3.4 Replication​

4. Structural View​

5. Practical Operation​

5.1 Creating a Storage Account: what you define​

5.2 Namespace and endpoints​

5.3 Hierarchical Namespace (ADLS Gen2)​

6. Implementation Methods​

6.1 Azure Portal​

6.2 Azure CLI​

6.3 Azure PowerShell​

6.4 Bicep / ARM Template​

7. Control and Security​

7.1 Authentication and authorization​

7.2 Network configurations​

7.3 Encryption​

7.4 Data protection​

8. Decision Making​

8.1 Which replication type to choose?​

8.2 Which access tier to choose?​

8.3 Which account type to choose?​

9. Best Practices​

10. Common Errors​

11. Operation and Maintenance​

11.1 Monitoring​

11.2 Lifecycle Management​

11.3 Important limits​

12. Integration and Automation​

12.1 Azure Event Grid​

12.2 Azure Data Factory and Synapse​

12.3 AzCopy​

12.4 Azure Policy​

13. Final Summary​

1. Initial Intuition

2. Context

3. Concept Building

3.1 Types of data that a Storage Account supports

3.2 Storage Account Types

3.3 Access Tiers

3.4 Replication

4. Structural View

5. Practical Operation

5.1 Creating a Storage Account: what you define

5.2 Namespace and endpoints

5.3 Hierarchical Namespace (ADLS Gen2)

6. Implementation Methods

6.1 Azure Portal

6.2 Azure CLI

6.3 Azure PowerShell

6.4 Bicep / ARM Template

7. Control and Security

7.1 Authentication and authorization

7.2 Network configurations

7.3 Encryption

7.4 Data protection

8. Decision Making

8.1 Which replication type to choose?

8.2 Which access tier to choose?

8.3 Which account type to choose?

9. Best Practices

10. Common Errors

11. Operation and Maintenance

11.1 Monitoring

11.2 Lifecycle Management

11.3 Important limits

12. Integration and Automation

12.1 Azure Event Grid

12.2 Azure Data Factory and Synapse

12.3 AzCopy

12.4 Azure Policy

13. Final Summary