Azure Well-Architected Framework perspective on Azure Blob Storage

Use failure mode analysis: Minimize points of failure by considering internal dependencies such as the availability of virtual networks, Azure Key Vault, or Azure Content Delivery Network or Azure Front Door endpoints. Failures can occur if credentials required by workloads to access Blob Storage go missing from Key Vault, or if workloads use an endpoint based on a content delivery network that's removed. In these cases, workloads might need to use an alternative endpoint to connect. For general information about failure mode analysis, see Recommendations for performing failure mode analysis.

Define reliability and recovery targets: Review the Azure service-level agreements (SLAs). Derive the service-level objective (SLO) for the storage account. For example, the SLO might be affected by the redundancy configuration that you chose. Consider the effect of a regional outage, the potential for data loss, and the time required to restore access after an outage. Also consider the availability of any internal dependencies that you identified as part of your failure mode analysis.

Configure data redundancy: For maximum durability, choose a configuration that copies data across availability zones or global regions. For maximum availability, choose a configuration that allows clients to read data from the secondary region during an outage of the primary region.

Design applications: Design applications to seamlessly shift to reading data from the secondary region if the primary region becomes unavailable for any reason. This only applies to geo-redundant storage (GRS) and geo-zone-redundant storage (GZRS) configurations. Designing applications to handle outages reduces downtime for end users.

Explore features to help you meet your recovery targets: Make blobs restorable so that they can be recovered if they're corrupted, edited, or deleted by mistake.

Create a recovery plan: Consider data protection features, backup and restore operations, or failover procedures. Prepare for potential data loss and data inconsistencies and the time and cost of failing over. For more information, see Recommendations for designing a disaster recovery strategy.

Monitor potential availability problems: Subscribe to the Azure Service Health dashboard to monitor potential availability problems. Use storage metrics in Azure Monitor and diagnostic logs to investigate alerts.

Review the security baseline for Azure Storage: To get started, first review the security baseline for Storage.

Use network controls to restrict ingress and egress traffic: Disable all public traffic to the storage account. Use account network controls to grant the minimal level of access required by users and applications. For more information, see How to approach network security for your storage account.

Reduce the attack surface: Preventing anonymous access, account key access, or access over non-secure (HTTP) connections can reduce the attack surface. Require clients to send and receive data by using the latest version of the Transport Layer Security (TLS) protocol.

Authorize access without using passwords or keys: Microsoft Entra ID provides superior security and ease of use compared to shared keys and shared access signatures. Grant security principals only those permissions that are necessary for them to do their tasks.

Protect sensitive information: Protect sensitive information such as account keys and shared access signature tokens. While these forms of authorization are generally not recommended, you should make sure to rotate, expire, and store them securely.

Enable the secure transfer required option: Enabling this setting for all your storage accounts ensures that all requests made against the storage account must take place over secure connections. Any requests made over HTTP fail.

Protect critical objects: Apply immutability policies to protect critical objects. Policies protect blobs that are stored for legal, compliance, or other business purposes from being modified or deleted. Configure holds for set time periods or until restrictions are lifted by an administrator.

Detect threats: Enable Microsoft Defender for Storage to detect threats. Security alerts are triggered when anomalies in activity occur. The alerts notify subscription administrators via email with details of suspicious activity and recommendations on how to investigate and remediate threats.

Identify the meters that are used to calculate your bill: Meters are used to track the amount of data stored in the account (data capacity) and the number and type of operations that are performed to write and read data. There are also meters associated with the use of optional features such as blob index tags, blob inventory, change feed support, encryption scopes, and SSH File Transfer Protocol (SFTP) support. For more information, see How you're charged for Blob Storage.

Understand the price of each meter: Make sure to use the appropriate pricing page and apply the appropriate settings in that page. For more information, see Finding the unit price for each meter. Consider the number of operations associated with each price. For example, the price associated with write and read operations applies to 10,000 operations. To determine the price of an individual operation, divide the listed price by 10,000.

Estimate the cost of capacity and operations: You can model the costs associated with data storage, ingress, and egress by using the Azure pricing calculator. Use fields to compare the cost associated with various regions, account types, namespace types, and redundancy configurations. For certain scenarios, you can use sample calculations and worksheets available in Microsoft documentation. For example, you can estimate the cost of archiving data or estimate the cost of using the AzCopy command to transfer blobs.

Choose a billing model for capacity: Evaluate whether using a commitment-based model is more cost-efficient than using a consumption-based model. If you're unsure about how much capacity you need, you can start with a consumption-based model, monitor the capacity metrics, and then evaluate later.

Choose an account type, a redundancy level, and a default access tier: You must select a value for each of these settings when you create a storage account. All the values affect transaction charges and capacity charges. All these settings except for the account type can be changed after the account is created.

Choose the most cost-effective default access tier: Unless a tier is specified with each blob upload, blobs infer their access tier from the default access tier setting. A change to the default access tier setting of a storage account applies to all blobs in the account for which an access tier hasn't been explicitly set. This cost could be significant if you've collected a large number of blobs. For more information about how a tier change affects each existing blob, see Changing a blob's access tier.

Upload data directly to the most cost-efficient access tier: For example, if the default access tier setting of your account is hot, but you're uploading files for archiving purposes, specify a cooler tier as the archive or a cold tier as part of your upload operation. After uploading blobs, use lifecycle management policies to move blobs to the most cost-efficient tiers based on usage metrics such as the last accessed time. Choosing the most optimal tier up front can reduce costs. If you change the tier of a block blob that you already uploaded, then you pay the cost of writing to the initial tier when you first upload the blob, and then pay the cost of writing to the desired tier.

Have a plan for managing the data lifecycle: Optimize transaction and capacity costs by taking advantage of access tiers and lifecycle management. Data used less often should be placed in cooler access tiers while data that's accessed often should be placed in warmer access tiers.

Decide which features you need: Some features such as versioning and blob soft delete incur additional transaction and capacity costs as well as other charges. Make sure to review the pricing and billing sections in articles that describe those capabilities when you choose which capabilities to add to your account.

For example, if you enable the blob inventory feature, you're billed for the number of objects scanned. If you use blob index tags, you're billed for the number of index tags. If you enable SFTP support, you're billed an hourly charge, even if there are no SFTP transfers. If you decide against using a feature, confirm that the feature is disabled because some features are automatically enabled when you create the account.

Create guardrails: Create budgets based on subscriptions and resource groups. Use governance policies to restrict resource types, configurations, and locations. Additionally, use RBAC to block actions that can lead to overspending.

Monitor costs: Ensure costs stay within budgets, compare costs against forecasts, and see where overspending occurs. You can use the cost analysis pane in the Azure portal to monitor costs. You also can export cost data to a storage account and analyze that data by using Excel or Power BI.

Monitor usage: Continuously monitor usage patterns and detect unused or underutilized accounts and containers. Use Storage insights to identity accounts with no or low use. Enable blob inventory reports, and use tools such as Azure Databricks or Azure Synapse Analytics and Power BI to analyze cost data. Watch out for unexpected increases in capacity, which might indicate that you're collecting numerous log files, blob versions, or soft-deleted blobs. Develop a strategy for expiring or transitioning objects to more cost-effective access tiers.Have a plan for expiring objects or moving objects to more affordable access tiers.

Create maintenance and emergency recovery plans: Consider data protection features, backup and restore operations, and failover procedures. Prepare for potential data loss and data inconsistencies and the time and cost of failing over.

Monitor the health of your storage account: Create Storage insights dashboards to monitor availability, performance, and resilience metrics. Set up alerts to identify and address problems in your system before your customers notice them. Use diagnostic settings to route resource logs to an Azure Monitor Logs workspace. Then you can query logs to investigate alerts more deeply.

Enable blob inventory reports: Enable blob inventory reports to review the retention, legal hold, or encryption status of your storage account contents. You can also use blob inventory reports to understand the total data size, age, tier distribution, or other attributes of your data. Use tools such as Azure Databricks or Azure Synapse Analytics and Power BI to better visualize inventory data and to create reports for stakeholders.

Set up policies that delete blobs or move them to cost-efficient access tiers: Create a lifecycle management policy with an initial set of conditions. Policy runs automatically delete or set the access tier of blobs based on the conditions you define. Periodically analyze container use by using Monitor metrics and blob inventory reports so that you can refine conditions to optimize cost efficiency.

Plan for scale: Understand the scale targets for storage accounts.

Choose the optimal storage account type: If your workload requires high transaction rates, smaller objects, and a consistently low transaction latency, then consider using premium block blob storage accounts. A standard general-purpose v2 account is most appropriate in most cases.

Reduce travel distance between the client and server: Place data in regions nearest to connecting clients (ideally in the same region). Optimize for clients in regions far away by using object replication or a content delivery network. Default network configurations provide the best performance. Modify network settings only to improve security. In general, network settings don't decrease travel distance and don't improve performance.

Choose an efficient naming scheme: Decrease the latency of listing, list, query, and read operations by using hash tag prefixes nearest the beginning of the blob partition key (account, container, virtual directory, or blob name). This scheme benefits mostly accounts that have a flat namespace.

Optimize the performance of data clients: Choose a data transfer tool that's most appropriate for the data size, transfer frequency, and bandwidth of your workloads. Some tools such as AzCopy are optimized for performance and require little intervention. Consider the factors that influence latency, and fine-tune performance by reviewing the performance optimization guidance that's published with each tool.

Optimize the performance of custom code: Consider using Storage SDKs instead of creating your own wrappers for blob REST operations. Azure SDKs are optimized for performance and provide mechanisms to fine-tune performance. Before creating an application, review the performance and scalability checklist for Blob Storage. Consider using query acceleration to filter out unwanted data during the storage request and keep clients from needlessly transferring data across the network.

Collect performance data: Monitor your storage account to identify performance bottlenecks that occur from throttling. For more information, see Monitoring your storage service with Monitor Storage insights. Use both metrics and logs. Metrics provide numbers such as throttling errors. Logs describe activity. If you see throttling metrics, you can use logs to identity which clients are receiving throttling errors. For more information, see Auditing data plane operations.