Azure Container Storage Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Containers

1. Introduction

Azure Container Storage is Microsoft’s Kubernetes-focused storage offering for running stateful Containers on Azure. It’s designed to make persistent storage for Kubernetes feel more “platform-native” by packaging storage provisioning, lifecycle operations, and Kubernetes integration into an Azure-managed experience—rather than requiring you to assemble and operate multiple storage components yourself.

In simple terms: Azure Container Storage helps you give Kubernetes pods reliable, persistent storage (so data survives restarts and rescheduling) using Azure-managed building blocks, with an emphasis on operational simplicity for platform teams.

In technical terms: Azure Container Storage integrates with Kubernetes through the Container Storage Interface (CSI) model and is typically surfaced as an Azure-managed capability for clusters such as Azure Kubernetes Service (AKS) (and, depending on current product scope, potentially Arc-enabled Kubernetes). It provisions storage that is consumed through Kubernetes objects like StorageClass, PersistentVolumeClaim (PVC), and PersistentVolume (PV) while relying on Azure resource management, identity, monitoring, and governance patterns.

The problem it solves: Kubernetes can run stateful apps, but “day-2” storage operations—capacity planning, performance tuning, consistent provisioning standards, access control, and cost governance—often become complicated. Azure Container Storage aims to reduce that complexity for Azure-hosted Kubernetes.

Important: Azure’s container storage landscape evolves quickly (features may be in preview/GA, region-limited, or product-scope-limited). Verify the current status, supported regions, and supported Kubernetes distributions in official documentation before committing to a design or rollout: https://learn.microsoft.com/search/?terms=Azure%20Container%20Storage

2. What is Azure Container Storage?

Official purpose (high-level): Azure Container Storage is intended to provide a managed, Kubernetes-aligned persistent storage experience for containerized workloads on Azure—especially for stateful applications running on Kubernetes.

Core capabilities (what it does)

At its core, Azure Container Storage provides:

Kubernetes-integrated persistent storage consumed via PVC/PV.
Dynamic provisioning through Kubernetes StorageClasses (so developers request storage on demand).
Azure-managed lifecycle aligned with Azure control-plane management (resource groups, policies, RBAC, monitoring).
A standardized approach for platform teams to offer storage to application teams in AKS environments.

Because Azure Container Storage is implemented to work with Kubernetes storage patterns, it typically centers on:

StorageClass definitions (how storage is provisioned)
PVCs (claims by workloads)
PVs (backing volumes)
CSI components (the mechanism Kubernetes uses to attach/mount storage)

Major components (conceptual)

Exact component names can vary by release; validate in current docs. Common building blocks include:

Azure control plane integration
Managed via Azure Resource Manager (ARM)
Governed by Azure RBAC, Policy, and tagging
Kubernetes-side components
CSI driver(s) and controller components in the cluster
StorageClass objects presented to users
Backing storage
Azure-managed storage resources behind the scenes (for example, Azure Disks, Azure Elastic SAN, Azure Files, or other supported backends—verify what is currently supported)

Service type

Azure Container Storage is best understood as a managed Kubernetes storage service/capability rather than a generic object storage service. You use it through Kubernetes APIs (kubectl/Helm) and Azure cluster management, not as a standalone “storage account” experience.

Scope (how it is scoped)

In practice, Azure Container Storage is typically:

Cluster-associated (enabled/installed per AKS cluster or per Kubernetes cluster type it supports)
Regional (aligned with the region of the cluster and backing storage resources)
Subscription and resource-group governed (because the cluster and backing resources live in your Azure subscription/resource groups)

How it fits into the Azure ecosystem

Azure Container Storage sits at the intersection of:

AKS (Containers / orchestration)
Azure storage backends (block/file services)
Identity & governance (Microsoft Entra ID, managed identities, Azure RBAC, Azure Policy)
Monitoring & operations (Azure Monitor, Container insights, Log Analytics)

It is most relevant when you want a “platform” storage solution for Kubernetes that aligns with Azure’s operational controls and enterprise governance.

3. Why use Azure Container Storage?

Business reasons

Faster platform enablement for stateful workloads: Reduce time-to-serve persistent storage to application teams.
Standardization: Establish approved storage profiles (performance/cost tiers) across teams.
Reduced operational overhead: Fewer custom scripts and ad-hoc storage configurations.

Technical reasons

Kubernetes-native consumption: Developers request storage with PVCs; the platform handles provisioning.
Separation of concerns: Platform team curates storage classes; app teams just request what they need.
Integration with Azure primitives: Aligns with Azure’s identity, governance, and resource lifecycle.

Operational reasons

Repeatable provisioning patterns: Storage defined as code (StorageClass + PVC manifests).
Simplified day-2 ops: Easier auditing, monitoring, and standardized troubleshooting paths.
Supports GitOps workflows: Storage objects can be managed in cluster configuration repos.

Security/compliance reasons

Governable with Azure RBAC and policy: Helps keep storage configuration compliant.
Auditable resource changes: Activity logs for Azure-level actions; Kubernetes audit logs for cluster actions (if enabled).
Encryption expectations: Azure storage backends generally support encryption at rest; validate exact encryption options and key management for your chosen backend.

Scalability/performance reasons

Right storage for the workload: Provide multiple storage classes suited to different performance/cost needs.
Predictable provisioning: Avoid manual volume creation bottlenecks.

When teams should choose it

Choose Azure Container Storage when:

You run AKS and need a consistent way to offer persistent storage to many teams.
You want Kubernetes-aligned storage provisioning with Azure-managed governance.
You have multiple stateful workloads (databases, queues, caches, analytics) and need standardized storage tiers and operational controls.

When teams should not choose it

Azure Container Storage may not be a fit when:

Your workloads are mostly stateless and don’t need PV/PVC.
You only need basic storage and can rely on standard CSI drivers directly (for example, direct Azure Disk/Azure Files CSI usage) and your operational needs are simple.
You need specialized enterprise storage features not offered by the current Azure Container Storage backend options (e.g., very specific latency/SLA/replication semantics). In that case, consider specialized Azure offerings (like Azure NetApp Files) or approved third-party Kubernetes storage solutions—after validation.

4. Where is Azure Container Storage used?

Industries

Common in industries with strict data and operational requirements:

Financial services (risk engines, pricing services, transaction systems)
Healthcare (patient analytics, integration services)
Retail/e-commerce (catalog/search indexes, session stores, order pipelines)
Gaming (player state, matchmaking metadata)
Manufacturing/IoT (telemetry processing, edge-to-cloud ingestion)
SaaS providers (multi-tenant app services with persistent state)

Team types

Platform engineering teams building AKS platforms
DevOps/SRE teams operating production clusters
Application teams deploying stateful microservices
Security teams defining guardrails for storage usage

Workloads

StatefulSets (PostgreSQL, MySQL, MongoDB, Elasticsearch/OpenSearch)
Eventing/streaming (Kafka-compatible systems, queues)
CI/CD and artifact workloads (if supported and appropriate)
Data processing pipelines needing durable scratch space

Architectures

Microservices with a mix of stateless and stateful components
Multi-namespace, multi-team AKS clusters (shared platform)
GitOps-managed clusters (Flux/Argo CD) with infrastructure-as-code

Real-world deployment contexts

Production: Strong governance, monitored storage classes, controlled expansion, backups.
Dev/Test: Lower-cost storage classes, fewer replicas, smaller PV sizes, relaxed performance tiers.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Azure Container Storage can be a good fit. Each includes the problem, why it fits, and a short example.

1) Standardized PVC provisioning for many teams

Problem: Each team provisions PVs differently, causing drift and incidents.
Why Azure Container Storage fits: Centralizes and standardizes StorageClasses and provisioning behavior.
Example: A platform team offers sc-standard and sc-premium classes; app teams request PVCs without learning backend details.

2) Running production PostgreSQL in AKS (operator-based)

Problem: PostgreSQL needs durable, reliable volumes with predictable performance.
Why it fits: Enables consistent PVC provisioning for StatefulSets/operators.
Example: A PostgreSQL operator requests 500Gi PVCs from a “db-tier” StorageClass; platform controls performance tier and policies.

3) Multi-tenant SaaS with namespace isolation

Problem: Shared clusters need safe patterns for storage usage and access boundaries.
Why it fits: Kubernetes RBAC + curated storage classes + Azure governance reduce risky variations.
Example: Each tenant namespace has quotas and only approved StorageClasses; PVC sizes are controlled via policy.

4) Stateful caching layer (Redis or similar) with persistence

Problem: Cache rebuilds cause slow recovery; some persistence required.
Why it fits: Supports durable volumes for append-only files or snapshots (capability depends on backend—verify).
Example: Redis pods write to PVC-backed volumes so failover doesn’t require full warm-up.

5) Search/index workloads (OpenSearch/Elasticsearch-like)

Problem: Index shards require fast I/O and stable storage.
Why it fits: Allows platform-provided storage tiers for indexing nodes.
Example: Index nodes use a high-performance StorageClass; query nodes remain stateless.

6) CI runners needing durable workspace between jobs (selective)

Problem: Some build steps benefit from persisting dependencies.
Why it fits: PVC-based caching improves performance and repeatability (be cautious with concurrency and security).
Example: Build runners mount PVCs for dependency caches with strict access controls.

7) Data processing pipelines (durable intermediate storage)

Problem: Jobs need to persist intermediate outputs for retries and handoffs.
Why it fits: PVCs provide durable scratch space for batch jobs.
Example: ETL jobs write intermediate parquet files to PVCs; downstream jobs read after rescheduling.

8) Lift-and-shift of VM-based apps to AKS (stateful pieces)

Problem: Legacy apps moved to containers still need persistent disks.
Why it fits: Reduces friction in mapping “disk-per-instance” patterns to Kubernetes.
Example: A Windows/Linux line-of-business service becomes a Deployment + PVC with a stable mount path.

9) Platform “golden path” for stateful services

Problem: Teams repeatedly reinvent storage choices and get it wrong.
Why it fits: Platform teams can provide curated documentation and safe defaults around Azure Container Storage.
Example: Internal templates create namespaces, resource quotas, and recommended PVC specs.

10) Regulated environments requiring auditability and governance

Problem: Storage must be auditable and compliant.
Why it fits: Aligns with Azure governance and standard Kubernetes audit patterns.
Example: Azure Policy enforces tags; activity logs record changes; cluster policies restrict StorageClass usage.

6. Core Features

Feature availability can vary by region, backend type, and release stage. Confirm current capabilities in official docs: https://learn.microsoft.com/search/?terms=Azure%20Container%20Storage%20features

1) Kubernetes-native storage consumption (PVC/PV)

What it does: Lets workloads request storage using standard Kubernetes objects.
Why it matters: Developers use familiar patterns; less platform-specific glue code.
Practical benefit: Faster onboarding for teams already using Kubernetes.
Caveats: You must still design for Kubernetes storage realities (pod rescheduling, access modes, topology).

2) Dynamic provisioning through StorageClasses

What it does: Automatically provisions storage when a PVC is created.
Why it matters: Removes manual PV creation and reduces operator error.
Practical benefit: Self-service storage with guardrails.
Caveats: StorageClass parameters and defaults must be controlled carefully; mistakes can scale quickly.

3) Azure-managed integration and lifecycle

What it does: Aligns cluster storage operations with Azure resource management patterns.
Why it matters: Supports enterprise governance, tagging, and operational consistency.
Practical benefit: Easier auditing and lifecycle management across environments.
Caveats: The exact resource footprint and “who manages what” depends on backend and configuration—verify.

4) Works with AKS operational model

What it does: Designed to be enabled/operated in AKS contexts.
Why it matters: Reduces friction compared to self-managed in-cluster storage stacks.
Practical benefit: More consistent support boundaries and operational playbooks.
Caveats: AKS versions and regions supported may be limited; check prerequisites.

5) Support for multiple storage “profiles” (tiers)

What it does: Allows platform teams to offer different StorageClasses for different needs.
Why it matters: Prevents one-size-fits-all storage decisions.
Practical benefit: Cost and performance optimization by workload.
Caveats: Over-proliferation of classes becomes confusing; keep it minimal.

6) Integration with Kubernetes scheduling and topology (where supported)

What it does: Helps ensure volumes are attachable/mountable where pods run (zone/region constraints).
Why it matters: Avoids pods stuck Pending due to storage topology mismatches.
Practical benefit: More predictable scheduling outcomes.
Caveats: Behavior depends on backend type and cluster configuration.

7) Operational visibility via Kubernetes status + Azure monitoring

What it does: Exposes provisioning and attachment/mount states through Kubernetes events/status; can integrate with Azure Monitor/Container insights.
Why it matters: Faster troubleshooting for Pending PVCs and mount failures.
Practical benefit: Clearer root-cause signals for SRE/ops teams.
Caveats: Monitoring costs can grow quickly; tune log/metric collection.

8) Policy-friendly design (guardrails)

What it does: Pairs well with Kubernetes admission controls (e.g., Gatekeeper/Kyverno) and Azure Policy for AKS.
Why it matters: Prevents insecure or excessively expensive storage requests.
Practical benefit: Enforce allowed StorageClasses, max PVC sizes, required labels/tags.
Caveats: Requires deliberate policy design; too strict blocks deployments.

9) Automation-friendly for IaC/GitOps

What it does: Storage objects can be declared in Git and applied via GitOps.
Why it matters: Repeatability and auditability.
Practical benefit: Environment parity across dev/test/prod.
Caveats: Secrets and credentials must be handled securely; avoid storing sensitive values in repos.

10) Fits into Azure security model (identity, encryption, audit)

What it does: Leverages Azure authentication/authorization patterns and encryption features of underlying storage.
Why it matters: Easier compliance alignment.
Practical benefit: Centralized controls and auditing.
Caveats: Encryption key management (Microsoft-managed vs customer-managed keys) depends on the backend—verify.

7. Architecture and How It Works

High-level architecture

At a high level, Azure Container Storage provides a Kubernetes-facing storage layer that translates Kubernetes storage requests (PVCs) into backing Azure storage resources and then attaches/mounts volumes to worker nodes where pods run.

Typical lifecycle:

A developer applies a PVC referencing a StorageClass.
Kubernetes calls the storage provisioner (CSI controller components) for that StorageClass.
Azure Container Storage provisions or allocates backing storage (depending on backend).
Kubernetes binds the PVC to a PV.
When a pod starts, Kubernetes requests volume attachment/mount.
The node plugin mounts the volume to the node; the pod sees it at the mount path.

Request/data/control flow

Control plane flow: Kubernetes API → CSI controller → Azure APIs (ARM) to provision/attach
Data plane flow: Application pod → filesystem/block device mounted on node → backing storage over Azure network or local pathways (backend-dependent)

Integrations with related services

Common integrations in Azure environments:

AKS (cluster hosting and identity integration)
Azure Monitor / Log Analytics (observability)
Microsoft Entra ID (human identity; Kubernetes RBAC integration)
Azure Policy for AKS (guardrails)
Key Vault (for secrets used by apps; storage encryption key scenarios depend on backend)
Backup tooling (Kubernetes-aware backups; backend snapshots depend on current support—verify)

Dependency services

Dependencies vary. Typical dependencies include:

A supported Kubernetes cluster (commonly AKS)
Azure storage backends (block/file services)
Azure networking (VNet integration, DNS, private endpoints if used)
Azure identity (managed identity for cluster operations)

Security/authentication model (typical)

Cluster to Azure: AKS uses a managed identity or service principal to manage Azure resources.
User to cluster: Kubernetes RBAC (often integrated with Entra ID).
Azure governance: Azure RBAC controls who can enable/configure Azure Container Storage and who can create/modify backing resources.

Networking model (typical)

Nodes must reach backing storage endpoints.
If using private networking patterns (Private Link/private endpoints), ensure DNS and routing are correct.
Cross-zone behavior depends on backend; topology constraints must be understood.

Monitoring/logging/governance

Kubernetes events (kubectl get events) often show PVC/PV provisioning problems.
CSI component logs (in kube-system or the extension namespace) are crucial for debugging.
Azure Monitor can collect node and pod metrics/logs; tune retention and collection.

Simple architecture diagram

flowchart LR
  Dev[Developer / CI] -->|kubectl apply PVC| K8s[Kubernetes API Server]
  K8s -->|provision request| CSI[Azure Container Storage CSI Controller]
  CSI -->|ARM calls| AzureAPI[Azure Resource Manager APIs]
  AzureAPI --> Backend[Backing Azure Storage]
  Pod[Stateful Pod] -->|read/write| Vol[Mounted Volume on Node]
  Vol --> Backend

Production-style architecture diagram

flowchart TB
  subgraph Azure["Azure Subscription"]
    subgraph RG["Resource Group"]
      AKS[AKS Cluster]
      MON[Azure Monitor / Log Analytics]
      POL[Azure Policy]
      KV[Key Vault]
      STG[Backing Storage (e.g., Disks / Files / Elastic SAN - verify)]
    end
    AAD[Microsoft Entra ID]
  end

  Dev[Platform Team / App Team] -->|Entra ID auth| AAD
  Dev -->|kubectl/CI| AKS

  AKS -->|Kubernetes events/logs| MON
  POL -->|enforce guardrails| AKS

  AKS -->|Managed identity / Azure RBAC| STG
  AKS -->|Workload uses secrets| KV

  subgraph Workloads["Stateful Workloads"]
    SS[StatefulSet / Operator-managed DB]
    PVC[PVC]
  end

  SS --> PVC
  PVC -->|provision/attach/mount via CSI| STG

8. Prerequisites

Because Azure Container Storage is cluster-associated, prerequisites are mostly about your cluster and permissions.

Account/subscription requirements

An Azure subscription with permission to create and manage:
Resource groups
AKS clusters
Azure storage resources used by the chosen backend
Monitoring resources (optional but recommended)

Permissions / IAM roles

At minimum (exact needs vary by org policy):

Azure: Contributor (or a more scoped custom role) on the target resource group/subscription to create cluster resources and enable storage capability.
AKS/Kubernetes: Cluster-admin privileges for installing/enabling cluster components and creating StorageClasses (if needed).

In enterprise environments, responsibilities are often split: – Platform team: enable/configure Azure Container Storage, create StorageClasses – App team: create PVCs and deploy apps

Billing requirements

A payment method configured in the subscription.
Awareness that storage and monitoring costs are usage-based.

Tools needed

Azure CLI: https://learn.microsoft.com/cli/azure/install-azure-cli
kubectl: https://kubernetes.io/docs/tasks/tools/
Optional:
Helm (for deploying charts)
GitOps tooling (Flux/Argo CD)

Region availability

Availability may be limited by region and backend type.
Verify supported regions in official docs: https://learn.microsoft.com/search/?terms=Azure%20Container%20Storage%20region%20availability

Quotas/limits

Expect relevant quotas such as: – AKS node limits (cores, node pools) – Storage quotas (disk counts/sizes, IOPS limits, snapshots) – API rate limits (Azure Resource Manager operations) – Kubernetes object quotas (if you enforce them)

Always validate the specific limits that apply to the backing storage type you choose.

Prerequisite services

Typically required: – AKS cluster Optional but recommended: – Azure Monitor / Log Analytics workspace (for cluster and CSI logs) – Azure Policy for AKS (guardrails) – Key Vault (app secrets)

9. Pricing / Cost

Azure Container Storage cost is usually a combination of:

AKS costs
Backing storage costs
Networking costs
Monitoring/logging costs
Backup/snapshot costs (if used)

There may or may not be a separate “Azure Container Storage” line-item; in many designs, the primary cost drivers come from the underlying storage backend and operations. Verify the current pricing model in official sources.

Official pricing references (start here)

Azure Pricing Calculator: https://azure.microsoft.com/pricing/calculator/
Azure pricing overview: https://azure.microsoft.com/pricing/
Common backing storage pricing pages (depending on your backend):
Azure Managed Disks: https://azure.microsoft.com/pricing/details/managed-disks/
Azure Files: https://azure.microsoft.com/pricing/details/storage/files/
Azure Elastic SAN: https://azure.microsoft.com/pricing/details/elastic-san/
Azure NetApp Files: https://azure.microsoft.com/pricing/details/netapp/

For Azure Container Storage-specific pricing details (if published), use: https://learn.microsoft.com/search/?terms=Azure%20Container%20Storage%20pricing

Pricing dimensions (what you typically pay for)

You commonly pay for:

Provisioned storage capacity (GiB/TiB per month)
Performance tier (e.g., premium vs standard; IOPS/throughput characteristics)
Snapshots/backups (capacity stored and operations)
Transactions/operations (more relevant for file/object-style backends)
Compute (AKS nodes that run your workloads and storage components)
Data transfer
Zone-to-zone or region-to-region (if applicable)
Egress to Internet (rare for storage traffic if private networking is used)
Monitoring logs
Log Analytics ingestion + retention can become a large recurring cost

Free tier

AKS has a free control plane tier for some configurations, but node compute is billed.
Storage backends generally do not have meaningful “free tiers” for production usage.
Always confirm current promotions/free grants in the pricing pages.

Cost drivers (most important)

Over-provisioned PVC sizes (unused allocated storage)
Premium storage tiers used broadly rather than selectively
High log ingestion (verbose CSI logs, container logs)
Large snapshot retention
Frequent provisioning/deprovisioning (operational churn)
Multi-zone replication requirements (backend-dependent)

Hidden or indirect costs

Operational time: debugging scheduling/topology/storage issues
Observability: logs/metrics retention
Backups: storage of backups plus restore testing environments
Network design: private endpoints and DNS can add complexity (and sometimes costs)

Network/data transfer implications

Storage traffic typically stays within Azure’s network when using Azure storage.
If your architecture crosses regions or uses DR replicas, data transfer costs can appear.
Private endpoints may be used for tighter security; validate any cost impacts for your design.

How to optimize cost

Offer a small number of StorageClasses aligned to cost tiers:
dev/test low-cost tier
production general-purpose tier
performance tier for I/O-heavy databases
Use quotas and policy:
max PVC size
allowed StorageClasses per namespace
Right-size PVs and implement expansion policies where supported.
Tune Azure Monitor:
collect only required logs
set retention appropriately
Use scheduled cleanup in dev/test namespaces (PVCs and snapshots are often forgotten).

Example low-cost starter estimate (no fabricated numbers)

A low-cost starter lab typically includes: – 1 small AKS cluster (1 node pool, small VM size) – 1 namespace – 1 PVC (a few GiB to tens of GiB depending on minimums) – Minimal monitoring retention

Use the Azure Pricing Calculator to estimate: – AKS node VM cost – Storage capacity cost for the chosen backend – Log Analytics ingestion (if enabled)

Example production cost considerations

In production, costs often come from: – Multiple node pools across zones – Many PVCs (databases per service/team) – Premium tiers for performance workloads – Snapshot/backup storage and retention – 30–90+ day logging retention – DR or multi-region replication (where used)

A practical approach: model costs per “stateful service unit” (e.g., one PostgreSQL cluster = X PVCs, Y size, Z snapshot retention, plus compute).

10. Step-by-Step Hands-On Tutorial

This lab focuses on a safe, low-cost pattern: enable Azure Container Storage on an AKS cluster, then deploy a simple pod that writes data to a PVC and verify persistence across restarts.

Because Azure Container Storage enablement steps can change (preview → GA, portal wording, CLI flags), this lab uses a hybrid approach: – Azure CLI for AKS creation (stable) – Portal-based enablement for Azure Container Storage (less fragile than guessing CLI flags) – kubectl for Kubernetes objects (stable)

Objective

Deploy a small Kubernetes workload on AKS using Azure Container Storage-provided persistent storage, then validate: – PVC binds successfully – Pod can write/read data – Data persists after pod restart

Lab Overview

You will: 1. Create an AKS cluster. 2. Enable Azure Container Storage on the cluster. 3. Identify the StorageClass created or recommended by Azure Container Storage. 4. Create a PVC using that StorageClass. 5. Deploy a pod that mounts the PVC and writes data. 6. Restart the pod and confirm the data remains. 7. Clean up all resources to avoid ongoing charges.

Step 1: Create a resource group

Expected outcome: Resource group exists.

az login
az account set --subscription "<YOUR_SUBSCRIPTION_ID>"

export RG="rg-acs-lab"
export LOCATION="eastus"   # pick a supported region for Azure Container Storage (verify)
az group create --name "$RG" --location "$LOCATION"

Verify:

az group show --name "$RG" --query "{name:name, location:location}" -o table

Step 2: Create an AKS cluster

Expected outcome: AKS cluster is created and ready.

Notes: – Keep node count small to reduce cost. – Use a Kubernetes version supported by Azure Container Storage (verify in docs).

export AKS="aks-acs-lab"

az aks create \
  --resource-group "$RG" \
  --name "$AKS" \
  --location "$LOCATION" \
  --node-count 1 \
  --generate-ssh-keys

Get credentials:

az aks get-credentials --resource-group "$RG" --name "$AKS" --overwrite-existing
kubectl get nodes

You should see one node in Ready state.

Step 3: Enable Azure Container Storage on the AKS cluster

Expected outcome: Azure Container Storage components are installed/enabled and at least one StorageClass is available for use.

Because exact enablement steps can vary, use the most current official guidance: https://learn.microsoft.com/search/?terms=Enable%20Azure%20Container%20Storage%20AKS

A typical Azure Portal flow (verify wording in your portal): 1. Open the Azure Portal: https://portal.azure.com 2. Go to Kubernetes services → select your AKS cluster (aks-acs-lab) 3. Find the area for Extensions, Add-ons, or Storage capabilities (names can vary) 4. Select Azure Container Storage and follow the enablement wizard 5. Wait for deployment to complete

After enablement, validate from Kubernetes:

kubectl get pods -A
kubectl get storageclass

Look for a StorageClass that is documented/recommended for Azure Container Storage. The exact name varies by configuration and release. If you’re unsure which StorageClass to use: – Check the Azure Container Storage docs for the expected StorageClass name(s), or – Inspect StorageClasses and look for annotations/provisioners that match the Azure Container Storage CSI driver (verify).

To inspect details:

kubectl get storageclass -o wide
kubectl describe storageclass <STORAGECLASS_NAME>

Step 4: Create a namespace for the lab

Expected outcome: Namespace exists.

kubectl create namespace acs-lab

Step 5: Create a PVC using the Azure Container Storage StorageClass

Expected outcome: PVC is created and becomes Bound.

Create a file named pvc.yaml. Replace <STORAGECLASS_NAME> with the StorageClass you identified in Step 3.

cat > pvc.yaml <<'EOF'
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: acs-pvc
  namespace: acs-lab
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: <STORAGECLASS_NAME>
EOF

Apply it:

kubectl apply -f pvc.yaml
kubectl get pvc -n acs-lab

If it stays Pending, describe it:

kubectl describe pvc acs-pvc -n acs-lab
kubectl get events -n acs-lab --sort-by=.metadata.creationTimestamp

Step 6: Deploy a pod that writes to the PVC

Expected outcome: Pod is running and can write data to the mounted volume.

Create pod.yaml:

cat > pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: pvc-writer
  namespace: acs-lab
spec:
  containers:
  - name: writer
    image: busybox:1.36
    command: ["/bin/sh", "-c"]
    args:
      - |
        set -e
        echo "hello from $(date -Iseconds)" >> /data/out.txt
        echo "Wrote a line. Now sleeping..."
        tail -f /dev/null
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: acs-pvc
EOF

Apply and check:

kubectl apply -f pod.yaml
kubectl get pod -n acs-lab -w

Once Running, view the file:

kubectl exec -n acs-lab pvc-writer -- cat /data/out.txt

Step 7: Restart the pod and confirm persistence

Expected outcome: After deleting and recreating the pod, the file still contains the previous content.

Delete the pod:

kubectl delete pod -n acs-lab pvc-writer

Re-apply:

kubectl apply -f pod.yaml
kubectl get pod -n acs-lab -w

Check the file again:

kubectl exec -n acs-lab pvc-writer -- cat /data/out.txt

You should see the line written before the restart and an additional line written after the restart.

Validation

Run these checks:

PVC is bound:

kubectl get pvc -n acs-lab

PV exists and is bound to the claim:

kubectl get pv
kubectl describe pv <PV_NAME>

Pod is running and mounted:

kubectl describe pod -n acs-lab pvc-writer

Data persists after pod recreation (already verified via /data/out.txt).

Troubleshooting

Common issues and fixes:

Issue: PVC stuck in Pending – Check events: bash kubectl describe pvc -n acs-lab acs-pvc kubectl get events -n acs-lab --sort-by=.metadata.creationTimestamp – Common causes: – Wrong storageClassName – Azure Container Storage not fully enabled/ready – Backend quota exceeded (disk limits, capacity limits) – Region/feature not supported for your cluster version – Fix: – Confirm supported regions and AKS versions in official docs – Re-check available StorageClasses and use the recommended one

Issue: Pod stuck in ContainerCreating or mount errors – Describe the pod: bash kubectl describe pod -n acs-lab pvc-writer – Look for mount/attach errors; then check CSI-related pods logs (namespace varies): bash kubectl get pods -A | grep -i csi Then: bash kubectl logs -n <NAMESPACE> <CSI_POD_NAME> – Fix: – Ensure node has network access to the backend – Ensure cluster identity has rights to manage required Azure resources – Confirm backend and topology constraints (zone alignment)

Issue: No StorageClass appears after enabling – Wait a few minutes; some components take time to deploy. – Re-check portal deployment status. – Confirm enablement succeeded in the AKS resource. – Consult official docs and release notes for the current enablement behavior.

Cleanup

To avoid charges, delete Kubernetes objects and the AKS cluster resources.

Delete objects:

kubectl delete namespace acs-lab

Delete the AKS cluster (and all resources in the RG) by deleting the resource group:

az group delete --name "$RG" --yes --no-wait

Verify deletion:

az group exists --name "$RG"

11. Best Practices

Architecture best practices

Offer curated StorageClasses, not dozens. Keep 2–4 tiers maximum (dev, general prod, high-perf, shared-file if applicable).
Match workload to access mode:
ReadWriteOnce is common for block storage per pod.
ReadWriteMany requires a file-capable backend (if supported).
Design for failure domains: If the backend is zone-scoped, ensure node pools and pod topology align.
Avoid coupling storage to ephemeral node pools unless explicitly designed for it.

IAM/security best practices

Use least privilege for:
Azure permissions to enable/configure Azure Container Storage
Kubernetes RBAC for creating PVCs and StorageClasses
Restrict StorageClass creation to platform admins.
Use policies to restrict which StorageClasses can be used per namespace.

Cost best practices

Enforce namespace ResourceQuotas and limit ranges for storage requests.
Use policy to prevent accidental large PVC requests.
Regularly audit:
orphaned PVCs
unused PVs (retained by reclaim policy)
snapshot accumulation
Tune logging/metrics to avoid runaway Log Analytics costs.

Performance best practices

Benchmark with realistic I/O patterns (latency/IOPS/throughput) before production rollout.
Separate workloads:
performance-critical databases on dedicated node pools and storage tiers
general workloads on standard tiers
Avoid noisy neighbor issues by limiting shared cluster usage for heavy stateful workloads unless you implement isolation (node pools, taints/tolerations, quotas).

Reliability best practices

Use multiple replicas for stateful apps where the app supports it (DB replication).
Test node replacement scenarios and upgrades:
confirm volumes reattach cleanly
confirm pod rescheduling works
Implement backup/restore testing as a routine, not a one-time setup.

Operations best practices

Create runbooks for:
PVC Pending
mount/attach failures
slow I/O
backend quota exhaustion
Centralize monitoring:
Kubernetes events
CSI component logs
node disk/memory pressure
Track changes:
use GitOps for StorageClass and policy manifests
document approved storage tiers and SLAs

Governance/tagging/naming best practices

Use naming conventions for:
StorageClasses (include tier and intended workload)
namespaces (team/environment)
Apply Azure tags consistently (environment, owner, cost center) to resource groups and any backing resources that are taggable (backend-dependent).
Use Azure Policy to enforce tags where possible.

12. Security Considerations

Identity and access model

Security spans two planes:

Azure plane – Who can enable/configure Azure Container Storage on clusters – Who can create/modify backing resources – Controlled by Azure RBAC and possibly management groups/policies
Kubernetes plane – Who can create PVCs (consuming storage) – Who can create/modify StorageClasses (defining how storage is provisioned) – Controlled by Kubernetes RBAC and admission policies

Best practice: – Platform team owns StorageClasses and Azure Container Storage configuration. – App teams can create PVCs only in their namespaces.

Encryption

At rest: Most Azure storage backends encrypt at rest by default. Customer-managed keys (CMK) options vary by backend and configuration—verify in backend documentation.
In transit: Kubernetes-to-Azure API traffic uses TLS. Data plane encryption depends on backend and protocol—verify if you have strict requirements.

Network exposure

Prefer private networking patterns:
Use private endpoints where supported by the chosen backend.
Ensure correct private DNS integration.
Minimize public endpoint use for storage backends in regulated environments.

Secrets handling

Azure Container Storage itself is typically managed through cluster identity. For application secrets: – Use Kubernetes secrets carefully (base64 is not encryption). – Prefer managed secret solutions: – Azure Key Vault + CSI Secrets Store driver (where appropriate) – External Secrets operators (with strong RBAC)

Audit/logging

Enable Kubernetes audit logs if required by your compliance posture (AKS supports audit log integrations; verify current options).
Use Azure Activity Logs for tracking Azure resource changes.
Consider centralized SIEM integration (Microsoft Sentinel) if needed.

Compliance considerations

Validate data residency (region), encryption requirements, and retention requirements.
Confirm the compliance certifications of the underlying storage backend (Azure compliance offerings vary by service and region).

Common security mistakes

Allowing developers to create arbitrary StorageClasses (can lead to insecure/expensive configs).
Not limiting PVC sizes (cost and risk).
Using shared file volumes without correct POSIX permissions/FSGroup configuration.
Over-permissive cluster identity with broad subscription rights.

Secure deployment recommendations

Lock down StorageClass and extension management to a small admin group.
Use Azure Policy + admission policies to enforce allowed classes and maximum PVC sizes.
Prefer private networking for storage backends where possible.
Monitor for unexpected PV/PVC growth and unusual I/O patterns.

13. Limitations and Gotchas

Because features and support boundaries can change, treat this list as a planning checklist and verify current limitations in official docs: https://learn.microsoft.com/search/?terms=Azure%20Container%20Storage%20limitations

Common limitations and gotchas in Kubernetes storage designs (often applicable here):

Region and Kubernetes-version constraints: Some capabilities may only be available in certain regions or AKS versions.
Access mode constraints: Some backends are ReadWriteOnce only; ReadWriteMany may require a file-based backend.
Topology/zone constraints: A pod may not schedule if the volume is constrained to a zone that doesn’t match the node pool.
PVC expansion behavior: Online expansion and filesystem resize behavior depends on the StorageClass settings and backend.
Reclaim policy surprises: Deleting a PVC may or may not delete the underlying storage (depends on reclaim policy). Orphaned volumes can be a cost leak.
Upgrades and node rotation: Volume detach/attach during upgrades can cause downtime if apps aren’t resilient.
Monitoring cost: CSI logs and container logs can create high Log Analytics ingestion.
Quota exhaustion: Azure backend quotas (disk count, IOPS limits, capacity) can block provisioning at scale.
Backup expectations: Not all backends/snapshot mechanisms behave the same; validate your backup/restore workflow early.

14. Comparison with Alternatives

Azure Container Storage sits in a broader ecosystem of Kubernetes and cloud storage options. The best choice depends on your workload, performance needs, and operational preferences.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Azure Container Storage	AKS platform teams standardizing Kubernetes storage	Kubernetes-aligned provisioning with Azure-managed integration; consistent operational model	Feature/region/version support may vary; backend-specific constraints	When you want a curated, Azure-aligned storage experience for Kubernetes
AKS + Azure Disk CSI (direct)	Simple block storage for single-pod volumes	Mature, widely used; straightforward	More DIY standardization; RWO focus	When needs are basic and teams can manage StorageClasses directly
AKS + Azure Files CSI (direct)	Shared file storage (RWX)	RWX support; common for shared content	Throughput/latency not for all DBs; permissions complexity	When multiple pods need shared files (web content, shared artifacts)
Azure NetApp Files	High-performance enterprise NAS for stateful workloads	Strong performance and enterprise features	Higher cost; requires design expertise	When you need premium file performance and enterprise capabilities
Azure Elastic SAN (direct via CSI where supported)	Consolidated block storage for many volumes (verify CSI integration path)	Centralized capacity/performance model	Requires careful planning; not always simplest	When you want SAN-like pooling and performance management
Self-managed Ceph / Rook	Teams wanting full control inside Kubernetes	Portable; feature-rich	High operational burden	When you need cloud portability and accept ops complexity
Portworx / other third-party Kubernetes storage	Enterprise Kubernetes storage features	Rich feature sets, replication, mobility	Licensing cost; vendor dependency	When you need advanced Kubernetes storage features beyond built-in options
AWS EBS/EFS (other cloud)	Stateful Kubernetes on AWS	Native integrations in AWS ecosystem	Different governance and tooling	When your platform is on AWS
GCP Persistent Disk/Filestore (other cloud)	Stateful Kubernetes on GCP	Native integrations in GCP ecosystem	Different governance and tooling	When your platform is on GCP

15. Real-World Example

Enterprise example: Shared AKS platform for regulated workloads

Problem: A large enterprise runs multiple product teams on shared AKS clusters. Teams deploy PostgreSQL, Redis, and search indexes. Incidents occur due to inconsistent StorageClasses, oversized PVCs, and unclear ownership of storage costs.
Proposed architecture:
Platform team enables Azure Container Storage on AKS clusters.
Defines three StorageClasses:
- dev-standard (lower cost)
- prod-general (baseline production)
- prod-performance (I/O intensive)
Enforces Azure Policy/Kubernetes admission policies:
- only approved StorageClasses allowed
- maximum PVC size by namespace
Central observability:
- Container insights
- alerts on PVC provisioning failures and PV growth
Backup strategy validated for each stateful service (tooling chosen based on backend support).
Why Azure Container Storage was chosen:
Fits platform engineering model: curated, standardized, auditable Kubernetes storage provisioning.
Integrates with Azure governance and operational tooling.
Expected outcomes:
Reduced storage-related incidents (fewer ad-hoc configs)
Predictable cost allocation (namespace tagging and quota enforcement)
Faster onboarding for new teams (golden path templates)

Startup/small-team example: SaaS with a single AKS cluster

Problem: A small SaaS team wants to run a few stateful components (PostgreSQL and background workers) on AKS but lacks time to engineer a complex storage stack.
Proposed architecture:
Single AKS cluster
Azure Container Storage enabled with one “general” StorageClass
Operator-managed PostgreSQL with PVCs
Basic monitoring and weekly backup/restore tests
Why Azure Container Storage was chosen:
Faster implementation with fewer moving parts than self-managed storage.
Kubernetes-native pattern allows the team to keep everything in manifests.
Expected outcomes:
Simple persistent storage setup with reasonable defaults
Clear upgrade and troubleshooting path via AKS + Azure documentation
Ability to introduce additional tiers later as the workload grows

16. FAQ

1) Is Azure Container Storage a standalone storage service like Blob Storage?
No. It’s primarily a Kubernetes-facing storage capability used through PV/PVC and StorageClasses, usually associated with AKS (and potentially other supported Kubernetes environments—verify).

2) Do I still need PVCs and StorageClasses?
Yes. Azure Container Storage is consumed using standard Kubernetes storage objects.

3) Does Azure Container Storage replace Azure Disks or Azure Files?
Typically it uses Azure storage backends rather than replacing them. The backend depends on what Azure Container Storage supports in your configuration (verify).

4) Can I use Azure Container Storage for ReadWriteMany (RWX) volumes?
RWX depends on having a file-capable backend. Confirm which backends and access modes Azure Container Storage supports in your region and release.

5) How do I know which StorageClass to use?
After enabling Azure Container Storage, list StorageClasses (kubectl get sc) and use the one recommended by official docs for your scenario.

6) Is Azure Container Storage production-ready?
This depends on current release status (preview vs GA), supported regions, and workload fit. Verify status and SLA statements in official docs.

7) How do I back up PVC data?
Backup methods vary: CSI snapshots (if supported), application-level backups, or Kubernetes backup tools. Validate snapshot support and consistency requirements for your databases.

8) What happens if I delete a PVC?
It depends on the PV reclaim policy. You might delete the underlying storage (data loss) or retain it (cost leak). Always check reclaim behavior.

9) Can I expand a PVC after creation?
Often yes if the StorageClass allows volume expansion and the backend supports it. Verify your StorageClass settings and test expansion in non-prod.

10) Why is my PVC stuck in Pending?
Common reasons: wrong StorageClass name, backend quota exhausted, region/version not supported, or provisioning components not healthy. Use kubectl describe pvc and events.

11) Do I need to open inbound network ports for storage?
Usually not; storage traffic is outbound from nodes to Azure services. If using private endpoints, ensure correct routing/DNS.

12) Does Azure Container Storage work with GitOps?
Yes. Storage manifests (PVCs, quota policies, app deployments) are Kubernetes objects and fit GitOps well.

13) How do I control costs across teams?
Use quotas and policy to limit PVC sizes and allowed StorageClasses, and apply tagging/cost allocation at Azure resource boundaries where possible.

14) How do I monitor storage health?
Monitor Kubernetes events, CSI pod logs, and backend storage metrics. Use Azure Monitor/Container insights with tuned retention.

15) Can I migrate existing PVs to Azure Container Storage?
Migration depends on backend compatibility and existing PV types. Plan migrations at the application level (backup/restore or replication), and validate on a staging cluster.

17. Top Online Resources to Learn Azure Container Storage

Resource Type	Name	Why It Is Useful
Official documentation	https://learn.microsoft.com/search/?terms=Azure%20Container%20Storage	Canonical starting point; find overview, quickstarts, and supported backends/regions
Official docs (AKS storage concepts)	https://learn.microsoft.com/azure/aks/concepts-storage	Helps you understand PV/PVC/StorageClass patterns in AKS
Official pricing calculator	https://azure.microsoft.com/pricing/calculator/	Model end-to-end cost (AKS + storage + monitoring)
Official pricing pages	https://azure.microsoft.com/pricing/details/managed-disks/	Understand managed disk pricing dimensions relevant to many Kubernetes volume scenarios
Official pricing pages	https://azure.microsoft.com/pricing/details/storage/files/	Understand file share pricing if your use case needs RWX
Official architecture guidance	https://learn.microsoft.com/azure/architecture/	Patterns and best practices for production Azure architectures
Monitoring for containers	https://learn.microsoft.com/azure/azure-monitor/containers/container-insights-overview	Operational monitoring guidance for AKS
Kubernetes storage concepts	https://kubernetes.io/docs/concepts/storage/	Vendor-neutral understanding of Kubernetes storage primitives
CSI concept and drivers	https://kubernetes-csi.github.io/docs/	Understand CSI behavior, troubleshooting patterns, and lifecycle
Azure updates (to track status changes)	https://azure.microsoft.com/updates/	Track GA/preview announcements and region expansions (search for Azure Container Storage)

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams, beginners to advanced	DevOps, Kubernetes, AKS, CI/CD, cloud operations	Check website	https://www.devopsschool.com
ScmGalaxy.com	Developers, build/release engineers, DevOps learners	SCM, CI/CD, DevOps fundamentals, tooling	Check website	https://www.scmgalaxy.com
CLoudOpsNow.in	Cloud engineers, operations teams, architects	Cloud operations, reliability, monitoring, cost	Check website	https://www.cloudopsnow.in
SreSchool.com	SREs, operations engineers, platform teams	SRE practices, observability, incident response	Check website	https://www.sreschool.com
AiOpsSchool.com	Ops teams, SREs, engineers exploring AIOps	AIOps concepts, automation, monitoring analytics	Check website	https://www.aiopsschool.com

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	Cloud/DevOps training content (verify offerings)	Learners seeking practical DevOps/cloud guidance	https://rajeshkumar.xyz
devopstrainer.in	DevOps and tooling training (verify offerings)	Beginners to intermediate DevOps practitioners	https://www.devopstrainer.in
devopsfreelancer.com	Freelance DevOps expertise marketplace/info (verify offerings)	Teams/individuals needing targeted help	https://www.devopsfreelancer.com
devopssupport.in	DevOps support/training resources (verify offerings)	Ops teams seeking troubleshooting and operational guidance	https://www.devopssupport.in

20. Top Consulting Companies

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify portfolio)	AKS platform setup, DevOps pipelines, cloud operations	AKS landing zone, GitOps rollout, observability baseline	https://cotocus.com
DevOpsSchool.com	DevOps consulting and training services (verify offerings)	Kubernetes enablement, CI/CD modernization, SRE practices	AKS production readiness review, pipeline standardization	https://www.devopsschool.com
DEVOPSCONSULTING.IN	DevOps consulting services (verify offerings)	DevOps transformation, automation, operational support	Kubernetes adoption planning, monitoring and alerting design	https://www.devopsconsulting.in

21. Career and Learning Roadmap

What to learn before Azure Container Storage

Kubernetes fundamentals:
Pods, Deployments, StatefulSets
Services and networking basics
Kubernetes storage basics:
PV, PVC, StorageClass
Access modes (RWO/RWX) and reclaim policies
AKS fundamentals:
node pools, upgrades, identity basics
Azure fundamentals:
resource groups, RBAC, networking (VNets), monitoring

What to learn after

Advanced Kubernetes operations:
upgrades, node rotation, disruption budgets
GitOps:
Flux or Argo CD
Policy and governance:
Azure Policy for AKS, Gatekeeper/Kyverno
Observability:
Azure Monitor tuning, SLOs, alerting
Stateful workload operations:
database operators, backup/restore, DR patterns

Job roles that use it

Platform Engineer
DevOps Engineer
Site Reliability Engineer (SRE)
Cloud Solutions Architect
Kubernetes Administrator
Security Engineer (governance/policy)

Certification path (if available)

There is no known dedicated “Azure Container Storage certification.” Typical Azure/Kubernetes certifications that align with this skill set: – Microsoft: AKS and Azure administrator/architect certifications (verify current certification names/paths on Microsoft Learn) – CNCF Kubernetes certifications (CKA/CKAD/CKS)

Start here: https://learn.microsoft.com/credentials/

Project ideas for practice

Build a “golden path” AKS namespace template:
quotas + approved StorageClasses + sample StatefulSet
Create a policy pack:
restrict allowed StorageClasses
enforce max PVC size per namespace
Implement a backup/restore drill for a StatefulSet database
Run a performance benchmark suite comparing two storage tiers (with cost tracking)

22. Glossary

AKS (Azure Kubernetes Service): Managed Kubernetes service on Azure.
Azure Container Storage: Azure-managed Kubernetes storage capability for persistent storage in container environments (verify exact supported scopes/backends).
CSI (Container Storage Interface): Standard interface for exposing storage systems to Kubernetes.
PersistentVolume (PV): Kubernetes object representing provisioned storage.
PersistentVolumeClaim (PVC): Kubernetes object requesting storage resources.
StorageClass: Kubernetes object defining how storage is dynamically provisioned.
StatefulSet: Kubernetes workload controller for stateful apps requiring stable identity and storage.
Access modes (RWO/RWX): Define whether a volume can be mounted read-write by one node or many.
Reclaim policy: What happens to storage when the PVC is deleted (Delete vs Retain).
Managed identity: Azure identity used by services (like AKS) to access Azure APIs securely.
Azure RBAC: Role-based access control for Azure resources.
Kubernetes RBAC: Role-based access control within a Kubernetes cluster.
Container insights: Azure Monitor feature for collecting logs/metrics from Kubernetes clusters.
Private Endpoint / Private Link: Azure networking feature to access PaaS services privately from a VNet.
Quota: Limits on resources (including storage) applied at namespace level in Kubernetes.

23. Summary

Azure Container Storage is an Azure-managed way to provide persistent storage for Kubernetes workloads—especially on AKS—using standard Kubernetes primitives like StorageClasses and PVCs while aligning storage operations with Azure governance and operational tooling.

It matters because stateful Containers are common in real systems (databases, indexes, pipelines), and reliable storage is where many Kubernetes platforms struggle operationally. Azure Container Storage helps platform teams standardize provisioning, improve operational consistency, and apply guardrails.

Cost-wise, the biggest drivers are usually the backing storage capacity/performance tier, AKS node compute, monitoring/log retention, and snapshots/backups. Security-wise, focus on least privilege, restricting StorageClass creation, enforcing policy on PVC sizes/classes, and using private networking where required.

Use Azure Container Storage when you want a Kubernetes-native storage experience that fits Azure operations and governance. If you only need basic volumes, direct use of CSI drivers and simpler storage patterns may be sufficient. Next step: review the current official documentation for supported regions/backends and run the hands-on lab in a dev subscription: https://learn.microsoft.com/search/?terms=Azure%20Container%20Storage

Category