An Azure storage account contains all of your Azure Storage data objects: blobs, files, queues, tables, and disks. The storage account provides a unique namespace for your Azure Storage data that is accessible from anywhere in the world over HTTP or HTTPS. Data in your Azure storage account is durable and highly available, secure, and massively scalable.
To learn how to create an Azure storage account, see Create a storage account.
Types of storage accounts
Azure Storage offers several types of storage accounts. Each type supports different features and has its own pricing model. Consider these differences before you create a storage account to determine the type of account that is best for your applications. The types of storage accounts are:
- General-purpose v2 accounts: Basic storage account type for blobs, files, queues, and tables. Recommended for most scenarios using Azure Storage.
- General-purpose v1 accounts: Legacy account type for blobs, files, queues, and tables. Use general-purpose v2 accounts instead when possible.
- BlockBlobStorage accounts: Storage accounts with premium performance characteristics for block blobs and append blobs. Recommended for scenarios with high transactions rates, or scenarios that use smaller objects or require consistently low storage latency.
- FileStorage accounts: Files-only storage accounts with premium performance characteristics. Recommended for enterprise or high performance scale applications.
- BlobStorage accounts: Legacy Blob-only storage accounts. Use general-purpose v2 accounts instead when possible.
The following table describes the types of storage accounts and their capabilities:
| Storage account type | Supported services | Supported performance tiers | Supported access tiers | Replication options | Deployment model1 | Encryption2 |
|---|---|---|---|---|---|---|
| General-purpose V2 | Blob, File, Queue, Table, Disk, and Data Lake Gen26 | Standard, Premium5 | Hot, Cool, Archive3 | LRS, GRS, RA-GRS, ZRS, GZRS (preview), RA-GZRS (preview)4 | Resource Manager | Encrypted |
| General-purpose V1 | Blob, File, Queue, Table, and Disk | Standard, Premium5 | N/A | LRS, GRS, RA-GRS | Resource Manager, Classic | Encrypted |
| BlockBlobStorage | Blob (block blobs and append blobs only) | Premium | N/A | LRS, ZRS4 | Resource Manager | Encrypted |
| FileStorage | File only | Premium | N/A | LRS, ZRS4 | Resource Manager | Encrypted |
| BlobStorage | Blob (block blobs and append blobs only) | Standard | Hot, Cool, Archive3 | LRS, GRS, RA-GRS | Resource Manager | Encrypted |
1Using the Azure Resource Manager deployment model is recommended. Storage accounts using the classic deployment model can still be created in some locations, and existing classic accounts continue to be supported. For more information, see Azure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources.
2All storage accounts are encrypted using Storage Service Encryption (SSE) for data at rest. For more information, see Azure Storage Service Encryption for Data at Rest.
3 Archive storage and blob-level tiering only support block blobs. The Archive tier is available at the level of an individual blob only, not at the storage account level. For more information, see Azure Blob storage: Hot, Cool, and Archive storage tiers.
4Zone-redundant storage (ZRS) and geo-zone-redundant storage (GZRS/RA-GZRS) (preview) are available only for standard general-purpose V2, BlockBlobStorage, and FileStorage accounts in certain regions. For more information about Azure Storage redundancy options, see Azure Storage redundancy.
5Premium performance for general-purpose v2 and general-purpose v1 accounts is available for disk and page blob only. Premium performance for block or append blobs are only available on BlockBlobStorage accounts. Premium performance for files are only available on FileStorage accounts.
6Azure Data Lake Storage Gen2 is a set of capabilities dedicated to big data analytics, built on Azure Blob storage. Data Lake Storage Gen2 is only supported on General-purpose V2 storage accounts with Hierarchical namespace enabled. For more information on Data Lake Storage Gen2, see Introduction to Azure Data Lake Storage Gen2.
General-purpose v2 accounts
General-purpose v2 storage accounts support the latest Azure Storage features and incorporate all of the functionality of general-purpose v1 and Blob storage accounts. General-purpose v2 accounts deliver the lowest per-gigabyte capacity prices for Azure Storage, as well as industry-competitive transaction prices. General-purpose v2 storage accounts support these Azure Storage services:
- Blobs (all types: Block, Append, Page)
- Data Lake Gen2
- Files
- Disks
- Queues
- Tables
Note
Microsoft recommends using a general-purpose v2 storage account for most scenarios. You can easily upgrade a general-purpose v1 or Blob storage account to a general-purpose v2 account with no downtime and without the need to copy data.
For more information on upgrading to a general-purpose v2 account, see Upgrade to a general-purpose v2 storage account.
General-purpose v2 storage accounts offer multiple access tiers for storing data based on your usage patterns. For more information, see Access tiers for block blob data.
General-purpose v1 accounts
General-purpose v1 storage accounts provide access to all Azure Storage services, but may not have the latest features or the lowest per gigabyte pricing. General-purpose v1 storage accounts support these Azure Storage services:
- Blobs (all types)
- Files
- Disks
- Queues
- Tables
You should use general-purpose v2 accounts in most cases. You can use general-purpose v1 accounts for these scenarios:
- Your applications require the Azure classic deployment model. General-purpose v2 accounts and Blob storage accounts support only the Azure Resource Manager deployment model.
- Your applications are transaction-intensive or use significant geo-replication bandwidth, but don’t require large capacity. In this case, general-purpose v1 may be the most economical choice.
- You use a version of the Storage Services REST API that is earlier than 2014-02-14 or a client library with a version lower than 4.x. You can’t upgrade your application.
BlockBlobStorage accounts
A BlockBlobStorage account is a specialized storage account in the premium performance tier for storing unstructured object data as block blobs or append blobs. Compared with general-purpose v2 and BlobStorage accounts, BlockBlobStorage accounts provide low, consistent latency and higher transaction rates.
BlockBlobStorage accounts don’t currently support tiering to hot, cool, or archive access tiers. This type of storage account does not support page blobs, tables, or queues.
FileStorage accounts
A FileStorage account is a specialized storage account used to store and create premium file shares. This storage account kind supports files but not block blobs, append blobs, page blobs, tables, or queues.
FileStorage accounts offer unique performance dedicated characteristics such as IOPS bursting. For more information on these characteristics, see the File share storage tiers section of the Files planning guide.
Naming storage accounts
When naming your storage account, keep these rules in mind:
- Storage account names must be between 3 and 24 characters in length and may contain numbers and lowercase letters only.
- Your storage account name must be unique within Azure. No two storage accounts can have the same name.
Performance tiers
Depending on the type of storage account you create, you can choose between standard and premium performance tiers.
General-purpose storage accounts
General-purpose storage accounts may be configured for either of the following performance tiers:
- A standard performance tier for storing blobs, files, tables, queues, and Azure virtual machine disks. For more information about scalability targets for standard storage accounts, see Scalability targets for standard storage accounts.
- A premium performance tier for storing unmanaged virtual machine disks. Microsoft recommends using managed disks with Azure virtual machines instead of unmanaged disks. For more information about scalability targets for the premium performance tier, see Scalability targets for premium page blob storage accounts.
BlockBlobStorage storage accounts
BlockBlobStorage storage accounts provide a premium performance tier for storing block blobs and append blobs. For more information, see Scalability targets for premium block blob storage accounts.
FileStorage storage accounts
FileStorage storage accounts provide a premium performance tier for Azure file shares. For more information, see Azure Files scalability and performance targets.
Access tiers for block blob data
Azure Storage provides different options for accessing block blob data based on usage patterns. Each access tier in Azure Storage is optimized for a particular pattern of data usage. By selecting the right access tier for your needs, you can store your block blob data in the most cost-effective manner.
The available access tiers are:
- The Hot access tier. This tier is optimized for frequent access of objects in the storage account. Accessing data in the hot tier is most cost-effective, while storage costs are higher. New storage accounts are created in the hot tier by default.
- The Cool access tier. This tier is optimized for storing large amounts of data that is infrequently accessed and stored for at least 30 days. Storing data in the cool tier is more cost-effective, but accessing that data may be more expensive than accessing data in the hot tier.
- The Archive tier. This tier is available only for individual block blobs. The archive tier is optimized for data that can tolerate several hours of retrieval latency and that will remain in the archive tier for at least 180 days. The archive tier is the most cost-effective option for storing data. However, accessing that data is more expensive than accessing data in the hot or cool tiers.
If there’s a change in the usage pattern of your data, you can switch between these access tiers at any time. For more information about access tiers, see Azure Blob storage: hot, cool, and archive access tiers.
Important
Changing the access tier for an existing storage account or blob may result in additional charges. For more information, see the Storage account billing section.
Redundancy
Redundancy options for a storage account include:
- Locally redundant storage (LRS): A simple, low-cost redundancy strategy. Data is copied synchronously three times within the primary region.
- Zone-redundant storage (ZRS): Redundancy for scenarios requiring high availability. Data is copied synchronously across three Azure availability zones in the primary region.
- Geo-redundant storage (GRS): Cross-regional redundancy to protect against regional outages. Data is copied synchronously three times in the primary region, then copied asynchronously to the secondary region. For read access to data in the secondary region, enable read-access geo-redundant storage (RA-GRS).
- Geo-zone-redundant storage (GZRS) (preview): Redundancy for scenarios requiring both high availability and maximum durability. Data is copied synchronously across three Azure availability zones in the primary region, then copied asynchronously to the secondary region. For read access to data in the secondary region, enable read-access geo-zone-redundant storage (RA-GZRS).
For more information about redundancy options in Azure Storage, see Azure Storage redundancy.
Encryption
All data in your storage account is encrypted on the service side. For more information about encryption, see Azure Storage Service Encryption for data at rest.
Storage account endpoints
A storage account provides a unique namespace in Azure for your data. Every object that you store in Azure Storage has an address that includes your unique account name. The combination of the account name and the Azure Storage service endpoint forms the endpoints for your storage account.
For example, if your general-purpose storage account is named mystorageaccount, then the default endpoints for that account are:
- Blob storage:
https://*mystorageaccount*.blob.core.windows.net - Table storage:
https://*mystorageaccount*.table.core.windows.net - Queue storage:
https://*mystorageaccount*.queue.core.windows.net - Azure Files:
https://*mystorageaccount*.file.core.windows.net
Note
Block blob and blob storage accounts expose only the Blob service endpoint.
Construct the URL for accessing an object in a storage account by appending the object’s location in the storage account to the endpoint. For example, a blob address might have this format: http://mystorageaccount.blob.core.windows.net/mycontainer/myblob.
You can also configure your storage account to use a custom domain for blobs. For more information, see Configure a custom domain name for your Azure Storage account.
Control access to account data
By default, the data in your account is available only to you, the account owner. You have control over who may access your data and what permissions they have.
Every request made against your storage account must be authorized. At the level of the service, the request must include a valid Authorization header. Specifically, this header includes all of the information necessary for the service to validate the request before executing it.
You can grant access to the data in your storage account using any of the following approaches:
- Azure Active Directory: Use Azure Active Directory (Azure AD) credentials to authenticate a user, group, or other identity for access to blob and queue data. If authentication of an identity is successful, then Azure AD returns a token to use in authorizing the request to Azure Blob storage or Queue storage. For more information, see Authenticate access to Azure Storage using Azure Active Directory.
- Shared Key authorization: Use your storage account access key to construct a connection string that your application uses at runtime to access Azure Storage. The values in the connection string are used to construct the Authorization header that is passed to Azure Storage. For more information, see Configure Azure Storage connection strings.
- Shared access signature: Use a shared access signature to delegate access to resources in your storage account, if you aren’t using Azure AD authorization. A shared access signature is a token that encapsulates all of the information needed to authorize a request to Azure Storage on the URL. You can specify the storage resource, the permissions granted, and the interval over which the permissions are valid as part of the shared access signature. For more information, see Using shared access signatures (SAS).
Note
Authenticating users or applications using Azure AD credentials provides superior security and ease of use over other means of authorization. While you can continue to use Shared Key authorization with your applications, using Azure AD circumvents the need to store your account access key with your code. You can also continue to use shared access signatures (SAS) to grant fine-grained access to resources in your storage account, but Azure AD offers similar capabilities without the need to manage SAS tokens or worry about revoking a compromised SAS.
Microsoft recommends using Azure AD authorization for your Azure Storage blob and queue applications when possible.
Copying data into a storage account
Microsoft provides utilities and libraries for importing your data from on-premises storage devices or third-party cloud storage providers. Which solution you use depends on the quantity of data you’re transferring.
When you upgrade to a general-purpose v2 account from a general-purpose v1 or Blob storage account, your data is automatically migrated. Microsoft recommends this pathway for upgrading your account. However, if you decide to move data from a general-purpose v1 account to a Blob storage account, then you’ll migrate your data manually, using the tools and libraries described below.
AzCopy
AzCopy is a Windows command-line utility designed for high-performance copying of data to and from Azure Storage. You can use AzCopy to copy data into a Blob storage account from an existing general-purpose storage account, or to upload data from on-premises storage devices. For more information, see Transfer data with the AzCopy Command-Line Utility.
Data movement library
The Azure Storage data movement library for .NET is based on the core data movement framework that powers AzCopy. The library is designed for high-performance, reliable, and easy data transfer operations similar to AzCopy. You can use the data movement library to take advantage of AzCopy features natively. For more information, see Azure Storage Data Movement Library for .NET
REST API or client library
You can create a custom application to migrate your data from a general-purpose v1 storage account into a Blob storage account. Use one of the Azure client libraries or the Azure storage services REST API. Azure Storage provides rich client libraries for multiple languages and platforms like .NET, Java, C++, Node.JS, PHP, Ruby, and Python. The client libraries offer advanced capabilities such as retry logic, logging, and parallel uploads. You can also develop directly against the REST API, which can be called by any language that makes HTTP/HTTPS requests.
For more information about the Azure Storage REST API, see Azure Storage Services REST API Reference.
Important
Blobs encrypted using client-side encryption store encryption-related metadata with the blob. If you copy a blob that is encrypted with client-side encryption, ensure that the copy operation preserves the blob metadata, and especially the encryption-related metadata. If you copy a blob without the encryption metadata, the blob content cannot be retrieved again. For more information regarding encryption-related metadata, see Azure Storage Client-Side Encryption.
Storage account billing
You’re billed for Azure Storage based on your storage account usage. All objects in a storage account are billed together as a group.
Storage costs are calculated according to the following factors:
- Region refers to the geographical region in which your account is based.
- Account type refers to the type of storage account you’re using.
- Access tier refers to the data usage pattern you’ve specified for your general-purpose v2 or Blob storage account.
- Storage Capacity refers to how much of your storage account allotment you’re using to store data.
- Replication determines how many copies of your data are maintained at one time, and in what locations.
- Transactions refer to all read and write operations to Azure Storage.
- Data egress refers to any data transferred out of an Azure region. When the data in your storage account is accessed by an application that isn’t running in the same region, you’re charged for data egress. For information about using resource groups to group your data and services in the same region to limit egress charges, see What is an Azure resource group?.
The Azure Storage Pricing page provides detailed pricing information based on account type, storage capacity, replication, and transactions. The Data Transfers Pricing Details provides detailed pricing information for data egress. You can use the Azure Storage Pricing Calculator to help estimate your costs.
Azure services cost money. Azure Cost Management helps you set budgets and configure alerts to keep spending under control. Analyze, manage, and optimize your Azure costs with Cost Management. To learn more, see the quickstart on analyzing your costs.
Reference: https://docs.microsoft.com/en-us/azure/storage/common/storage-account-overview