Skip to article
Storage Storage accounts

Storage account kind

A storage feature or access model in Storage accounts that helps teams store, protect, move, and govern application or analytics data with clearer ownership, safety, and operational context.

Source: Microsoft Learn - Storage account overview Reviewed 2026-05-25

Exam trap
Creating a storage account from an old template without checking whether the account kind still fits modern requirements.
Production check
Show the storage account kind and SKU before enabling a new feature.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
storage account type, account kind, Azure Storage account type, StorageV2 kind
Difficulty
advanced
CLI mappings
10
Last verified
2026-05-25
Article depth
field-manual-complete
Learning paths Graph Storage concept cluster Storage account kind
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Storage account kind is the type of Azure Storage account you choose when creating the resource. It shapes which services the account supports, which features are available, and which pricing or performance model applies. General-purpose v2 is the common default for broad storage needs across blobs, files, queues, and tables. Premium kinds are specialized for workloads such as low-latency block blobs, file shares, or page blobs. For learners, account kind is an early design decision that can be painful to reverse later.

Why it matters

Account kind matters because it quietly defines the storage platform underneath an application. A team may need lifecycle management, archive access, Data Lake hierarchical namespace, Azure Files premium performance, queues, tables, static website hosting, or page blob behavior, and not every kind supports every scenario. Choosing by habit can create missing features, higher cost, or migration work when a new requirement appears. It also affects governance because policy may require StorageV2 for standard workloads or allow premium kinds only for approved performance cases. Good architects choose kind from workload requirements, not from muscle memory. This is why review boards should ask what the account must support in the next year, not only what it stores today.

Official wording and source

Microsoft Learn describes storage account types, often surfaced as account kind, as choices that determine supported Azure Storage services, features, pricing model, and redundancy options. Recommended kinds include general-purpose v2 accounts for most workloads and specialized premium accounts for block blob, file share, or page blob scenarios.

Open Microsoft Learn

Technical context

In Azure architecture, account kind is a control-plane property of the storage account resource. It appears beside SKU, redundancy, access tier, hierarchical namespace, encryption, networking, and service feature choices. Common values include StorageV2 for general-purpose accounts and premium-specialized kinds for block blob, file share, or page blob workloads. The kind influences which services are available, what performance tier is possible, and which options can be configured later. Operators inspect it before enabling features, applying policy, or planning migrations.

Exam context

Compare with

Storage account Resource group

Where it is used

Where you see it

  1. In the Azure portal Overview and Configuration areas, account kind appears with SKU, replication, access tier, hierarchical namespace, and supported service options. during architecture reviews.
  2. Azure CLI az storage account show returns the kind field, helping operators compare whether development, test, and production accounts use compatible account types. during migration planning.
  3. ARM, Bicep, and Terraform definitions set account kind during creation, usually beside SKU, redundancy, hierarchical namespace, access tier, and encryption settings. during architecture and migration reviews.

Common situations

  • Choose StorageV2 for a broad application account that needs blobs, files, queues, tables, and modern storage features.
  • Select a premium file or blob account when latency and throughput requirements justify a specialized storage backend.
  • Inventory legacy accounts before enabling lifecycle management, Data Lake features, or policy standards that assume StorageV2.
  • Explain cost differences between accounts that look similar but use different kinds, SKUs, and performance tiers.
  • Plan migration when an existing account kind cannot support a required feature for a new production workload.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Legal e-discovery team avoids a feature dead end Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A legal e-discovery team planned to add lifecycle management and archive tiering, but several evidence accounts had been created years earlier from old templates.

Goals
  • Identify storage accounts whose kind could block required blob features.
  • Choose a target account type for long-term evidence storage.
  • Avoid disrupting active legal holds during migration planning.
  • Standardize account creation templates for future matters.
Approach using Storage account kind

The cloud architect used Azure CLI to list account kind, SKU, redundancy, access tier, and legal-hold related settings. Accounts that did not fit the desired StorageV2 standard were flagged for review, but data under active legal hold was not moved until counsel approved a matter-by-matter plan. New evidence accounts were created as StorageV2 with explicit redundancy, encryption, diagnostics, and lifecycle settings. The team updated Bicep templates so account kind was never inherited from legacy defaults. Migration candidates were prioritized by age, capacity, and whether archive tiering would reduce storage cost.

Potential outcomes
  • Thirty-two legacy evidence accounts were identified before lifecycle rules were promised to attorneys.
  • New legal storage accounts reached 100 percent template compliance in the next quarter.
  • The team avoided moving four matters under active hold without legal approval.
  • Projected archive-tier savings of 28 percent became credible because the target account kind supported the plan.
What to learn

Account kind should be verified before architects commit to storage features that may not be available.

Scenario 02 Robotics company selects premium file storage intentionally Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A robotics manufacturer saw poor build performance when engineers compiled large firmware artifacts from a standard file share used by many teams.

Goals
  • Determine whether the bottleneck was account type, share configuration, or build tooling.
  • Provide low-latency file access for firmware build agents.
  • Avoid moving unrelated archival blobs into a premium-cost account.
  • Document why the premium account exception was justified.
Approach using Storage account kind

Platform engineers compared existing storage account kind, SKU, share metrics, and build agent access patterns. The problem was concentrated on SMB file operations, not blob archives or queue workloads. Instead of upgrading every storage account, they created a specialized premium file-share account for firmware builds and left ordinary artifacts in general-purpose accounts. Azure CLI reports showed the new kind, premium SKU, and performance tier for governance approval. Build pipelines were updated to mount the new share, while old standard storage remained available for low-frequency package retention.

Potential outcomes
  • Firmware build time fell from 47 minutes to 19 minutes after moving hot build files.
  • Premium storage spend was limited to one workload instead of twelve general-purpose accounts.
  • Build timeout incidents dropped by 83 percent during the next release cycle.
  • Governance approved the premium exception because account kind matched measured workload behavior.
What to learn

The right account kind can solve a performance problem without turning every storage account into premium storage.

Scenario 03 City open-data portal standardizes general-purpose accounts Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A city open-data program had storage accounts created by different departments, causing inconsistent support for queues, blob hosting, and analytics exports.

Goals
  • Standardize future accounts on a broadly supported kind.
  • Find department accounts with surprising or unsupported storage types.
  • Reduce deployment failures caused by feature mismatches.
  • Explain cost and performance tradeoffs to nontechnical data owners.
Approach using Storage account kind

The civic platform team inventoried every department storage account with Azure CLI and grouped results by kind, SKU, redundancy, and owner tag. Most workloads needed ordinary blob storage, queue messages, and occasional static data publishing, so StorageV2 became the default template. A few specialized accounts were retained with documented reasons. Deployment pipelines began rejecting templates that omitted account kind, and data owners received a plain-language comparison of general-purpose versus premium-specialized choices. The team also aligned dev and production account kinds so features tested in one environment behaved the same in the other.

Potential outcomes
  • Unexpected account-kind mismatches fell from 14 to two after template enforcement.
  • Open-data deployment failures caused by unsupported features dropped by 67 percent.
  • Department onboarding time decreased from ten days to four because the default account design was clear.
  • Premium account exceptions were reduced to workloads with documented performance evidence.
What to learn

A standard account kind makes storage behavior predictable across departments while still allowing justified exceptions.

Azure CLI

I use Azure CLI for account kind because estate-level consistency is impossible through portal browsing alone. CLI can show kind, SKU, redundancy, access tier, hierarchical namespace, public network access, and encryption settings together. That is exactly what operators need before approving a change or planning migration. It also makes inventory simple: find old account kinds, compare dev and production, and export results for application owners. During automation, CLI and templates enforce the correct kind so teams do not create random account types that block future features. The command output is also easy to join with tags and cost data, which helps owners understand why exceptions exist.

Useful for

  • Show an account’s kind, SKU, region, access tier, and redundancy before approving a storage feature change.
  • List all storage accounts and group them by kind to find legacy or unexpected account types.
  • Create a new storage account with a specific kind through automation so environments stay consistent.
  • Compare production and nonproduction accounts to identify kind mismatches that could hide feature or performance differences.
  • Export account kind evidence for governance reviews that require StorageV2 or approved premium exceptions.

Before you run a command

  • Confirm subscription, resource group, region, desired account kind, SKU, redundancy, and workload service requirements.
  • Check whether the kind can be changed for the account or whether a new account and data migration are required.
  • Verify feature requirements such as hierarchical namespace, lifecycle management, premium file shares, or archive access tiers.
  • Understand cost and performance implications before creating premium-specialized accounts for production.
  • Use consistent output queries so account kind, SKU, and feature flags are visible together during review.

What the output tells you

  • The kind field identifies the account type and helps explain which storage services and features are available.
  • SKU and redundancy fields show performance tier and replication posture, which must be interpreted with account kind.
  • Access tier and hierarchical namespace values reveal whether blob lifecycle or Data Lake scenarios may be configured.
  • Provisioning state confirms whether a newly created account is ready before dependent services write configuration.
  • Tags and resource IDs help map account type decisions back to workload owners and governance exceptions.

Mapped commands

Storage accounts operations

direct 
az storage account list --resource-group <resource-group>
az storage accountdiscoverStorage
read-only Microsoft Learn 
az storage account show --name <storage-account> --resource-group <resource-group>
az storage accountdiscoverStorage
read-only Microsoft Learn 
az storage account create --name <storage-account> --resource-group <resource-group> --location <region> --sku Standard_LRS
az storage accountprovisionStorage
cost-impacting Microsoft Learn 
az storage account update --name <storage-account> --resource-group <resource-group>
az storage accountconfigureStorage
mutating Microsoft Learn 
az storage account delete --name <storage-account> --resource-group <resource-group>
az storage accountremoveStorage
destructive Microsoft Learn

Storage Account operations

direct 
az storage account update --name <storage-account> --resource-group <resource-group> --https-only true
az storage accountconfigureStorage
mutating Microsoft Learn 
az storage account blob-service-properties show --account-name <storage-account>
az storage account blob-service-propertiesdiscoverStorage
read-only Microsoft Learn 
az storage account network-rule list --account-name <storage-account> --resource-group <resource-group>
az storage account network-rulediscoverStorage
read-only Microsoft Learn 
az storage account network-rule add --account-name <storage-account> --resource-group <resource-group> --ip-address <ip-address>
az storage account network-rulesecureStorage
security-impacting Microsoft Learn 
az storage account keys list --account-name <storage-account> --resource-group <resource-group>
az storage account keysdiscoverStorage
security-impacting Microsoft Learn

Architecture context

Architecturally, storage account kind is a workload-fit decision made before data lands. I start with service needs and access patterns: general object storage, analytics lake, SMB file share, low-latency premium file workload, VM disk page blob scenario, queue processing, or archive-heavy repository. Then I choose account kind, SKU, redundancy, access tier, and feature flags together. StorageV2 usually wins for broad compatibility, but premium kinds are valid when the workload shape justifies them. I also document whether the path can be changed later or whether migration is the realistic rollback. That documentation matters when a future team asks why an account is premium, legacy, or unable to support a new feature.

Security
Security impact is indirect but still important. Account kind does not grant access by itself, yet it determines which services, features, and security controls are available. A kind that blocks a needed feature can push teams into awkward workarounds, extra accounts, or unsupported patterns. Premium and legacy choices may also change how workloads use files, blobs, queues, or disks, affecting network rules, private endpoints, encryption scopes, and monitoring. Security review should confirm the chosen kind supports required encryption, identity, logging, network isolation, and policy controls before production data is stored. This prevents a late surprise where the account type blocks the security pattern the workload was expected to use.
Cost
Account kind has a direct cost path because it influences pricing model, performance tier, redundancy options, and supported access tiers. Premium kinds can be the right choice for latency-sensitive workloads, but they are wasteful when used for ordinary archival or low-throughput storage. General-purpose v2 usually offers broad feature coverage, yet lifecycle, redundancy, transaction, egress, and access-tier choices still matter. A wrong kind can also create migration cost later. FinOps review should compare account kind with actual workload behavior, not just monthly capacity, because performance and feature constraints drive spend. The cheapest account type is not always the right one if it causes performance rework, extra accounts, or later migration.
Reliability
Reliability impact comes from feature fit and migration pressure. Choosing the wrong kind can prevent redundancy options, performance tiers, lifecycle behavior, or service combinations that the workload later needs. Fixing that mistake may require creating a new account, copying data, changing endpoints, updating secrets, retesting clients, and coordinating cutover. Reliable design compares account kind with region, redundancy, access tier, hierarchical namespace, backup expectations, and recovery objectives. The safest time to correct account kind is before dependencies, DNS names, firewall rules, and application configurations have hardened around the account. That decision also reduces rollback pressure during feature enablement because unsupported combinations are caught before deployment.
Performance
Performance impact can be significant because account kind helps determine the storage backend and available performance tier. A premium file share or block blob account can solve low-latency and high-transaction scenarios, while a standard general-purpose account may be better for mixed workloads and cost efficiency. The wrong kind can create bottlenecks that no application tuning will fix. Performance reviews should inspect account kind together with SKU, redundancy, object size, access pattern, concurrency, throttling, and client retry behavior. Do not choose premium by default; choose it when measurements justify it. Measure workload behavior before and after kind-related migrations so the chosen account type proves its value.
Operations
Operators encounter account kind during provisioning, inventory, troubleshooting, policy review, and migration planning. They check it before enabling lifecycle management, static websites, Data Lake features, premium file shares, or other service-specific capabilities. They also compare account kind across environments when dev works but production cannot enable the same option. Mature operations keep approved account types in templates, block risky legacy choices with policy, and tag exceptions with an owner and reason. A clear account-kind standard prevents storage sprawl from becoming a feature-compatibility guessing game. Operators should include account kind in every storage readiness review, not only after a feature fails to enable.

Common mistakes

  • Creating a storage account from an old template without checking whether the account kind still fits modern requirements.
  • Assuming every storage feature is available on every kind, then discovering a blocker during implementation.
  • Using premium-specialized accounts for ordinary workloads because premium sounds safer or more enterprise-ready.
  • Comparing costs between accounts without considering kind, SKU, redundancy, access tier, and transaction patterns together.
  • Letting development and production use different account kinds, which hides deployment and performance issues until release.