What is storage account in Azure Cloud?

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.

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.
• Block blob storage accounts: Blob-only storage accounts with premium performance characteristics. Recommended for scenarios with high transactions rates, using smaller objects, or requiring consistently low storage latency.
• FileStorage storage accounts: Files-only storage accounts with premium performance characteristics. Recommended for enterprise or high performance scale applications.
• Blob storage accounts: 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 model 1	Encryption 2
General-purpose V2	Blob, File, Queue, Table, and Disk	Standard, Premium 5	Hot, Cool, Archive 3	LRS, GRS, RA-GRS, ZRS 4	Resource Manager	Encrypted
General-purpose V1	Blob, File, Queue, Table, and Disk	Standard, Premium 5	N/A	LRS, GRS, RA-GRS	Resource Manager, Classic	Encrypted
Block blob storage	Blob (block blobs and append blobs only)	Premium	N/A	LRS	Resource Manager	Encrypted
FileStorage	Files only	Premium	N/A	LRS	Resource Manager	Encrypted
Blob storage	Blob (block blobs and append blobs only)	Standard	Hot, Cool, Archive 3	LRS, GRS, RA-GRS	Resource Manager	Encrypted

Using 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.

All storage accounts are encrypted using Storage Service Encryption (SSE) for data at rest.

The Archive tier is available at level of an individual blob only, not at the storage account level. Only block blobs and append blobs can be archived.

Zone-redundant storage (ZRS) is available only for standard general-purpose v2 storage accounts. 

Premium performance for general-purpose v2 and general-purpose v1 accounts is available for disk and page blob only.

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)
• 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.

General-purpose v2 storage accounts offer multiple access tiers for storing data based on your usage patterns.

General-purpose v1 accounts

General-purpose v1 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

While general-purpose v2 accounts are recommended in most cases, general-purpose v1 accounts are best suited to 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 do not 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, and cannot upgrade your application.

Block blob storage accounts

A block blob storage account is a specialized storage account for storing unstructured object data as block blobs. This storage account type supports block blobs and append blobs, but not page blobs, tables or queues.

Compared with general-purpose v2 and blob storage accounts, block blob storage accounts provide low and consistent latency, and higher transaction rates.

Block blob storage accounts do not currently support tiering to hot, cool, or archive access tiers.

FileStorage storage accounts

A FileStorage storage account is a specialized storage account used to store and create premium file shares. FileStorage storage accounts offer unique performance dedicated characteristics such as IOPS bursting. For more information on these characteristics, see the File share performance tierssection 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

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.
• A premium performance tier for storing unmanaged virtual machine disks only.

Block blob storage accounts provide a premium performance tier for storing block blobs and append blobs.

FileStorage storage accounts provide a premium performance tier for Azure file shares.

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, which 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, which 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, which is available only for individual block blobs. The archive tier is optimized for data that can tolerate several hours of retrieval latency and will remain in the Archive tier for at least 180 days. The archive tier is the most cost-effective option for storing data, but accessing that data is more expensive than accessing data in the hot or cool tiers.

Note:-

Changing the access tier for an existing storage account or blob may result in additional charges.

Replication

Replication options for a storage account include:

• Locally-redundant storage (LRS): A simple, low-cost replication strategy. Data is replicated within a single storage scale unit.
• Zone-redundant storage (ZRS): Replication for high availability and durability. Data is replicated synchronously across three availability zones.
• Geo-redundant storage (GRS): Cross-regional replication to protect against region-wide unavailability.
• Read-access geo-redundant storage (RA-GRS): Cross-regional replication with read access to the replica.

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: http://mystorageaccount.blob.core.windows.net
• Table storage: http://mystorageaccount.table.core.windows.net
• Queue storage: http://mystorageaccount.queue.core.windows.net
• Azure Files: http://mystorageaccount.file.core.windows.net

Note: - Block blob and blob storage accounts expose only the blob service endpoint.

The URL for accessing an object in a storage account is constructed 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.

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, which 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 are not using Azure AD authentication. 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 authentication 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 are 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 need to 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.

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 it to take advantage of the features provided by AzCopy in your application natively without having to deal with running and monitoring external instances of AzCopy. 

REST API or client library

You can create a custom application to migrate your data into a Blob storage account using 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.

Note:

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.

Azure Import/Export service

If you have a large amount of data to import to your storage account, consider the Azure Import/Export service. The Import/Export service is used to securely import large amounts of data to Azure Blob storage and Azure Files by shipping disk drives to an Azure datacenter.

The Import/Export service can also be used to transfer data from Azure Blob storage to disk drives and ship to your on-premises sites. Data from one or more disk drives can be imported either to Azure Blob storage or Azure Files.

Storage account billing

You are 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/location, account type, access tier, storage capacity, replication scheme, storage transactions, and data egress.

• Region refers to the geographical region in which your account is based.
• Account type refers to the type of storage account you are using.
• Access tier refers to the data usage pattern you have specified for your general-purpose v2 or Blob storage account.
• Storage Capacity refers to how much of your storage account allotment you are 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 is not running in the same region, you are 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?.