AHEAD helps us launch the Strategic Azure Storage Services Partner Program
AHEAD becomes the first Azure Storage Strategic Channel Partner by demonstrating their expertise in helping customers select the ideal Azure Storage, or Azure Storage ISV, Service to offer the ideal price / performance solution for their application and helping customers to migrate to Azure quickly and safely.
Prefix-scoped access for User Delegation SAS is now generally available for Azure Blob Storage
We would like to share that prefix-scoped access for User Delegation SAS for Azure Blob Storage is generally available in all Azure regions. SAS tokens for Blob Storage have historically supported two levels of scope: container and individual blob. With this release, you can now scope access to a prefix or virtual directory within a container, granting access to all blobs beneath the path. This is especially valuable for applications that organize data by tenant, workspace, project, or department within a shared container. Instead of granting access to an entire container or generating many blob-level tokens, you can now issue a single SAS token scoped to a set of blobs through a prefix. For example, if a container has these blobs: contoso/sales/Q1-report.csv contoso/sales/Q2-report.csv contoso/invoice.pdf A SAS token scoped to the prefix contoso/sales would grant access only to the two sales reports. This simplifies manageability by not having to generate multiple blob scoped tokens which significantly reduces overhead to manage permissions for large scale data storage estates. In addition, it helps customers provide more scoped permissions to a certain set of blobs rather than broader permissions at a container level. Prefix-scoped access is supported for both Blob and Data Lake storage accounts. As a best practice, we recommend using Entra ID with RBAC or ABAC for least privilege access. If you need to use SAS for your use cases, we recommend using user delegation SAS and prefix-based scoping is a good option to consider for more scoped permissions for a certain set of blobs. Pricing and Availability There is no additional cost for prefix-scoped access for user delegation SAS. Pricing is based on standard transaction costs for your storage account type. To learn more, see Azure Storage Pricing. Prefix-scoped access for user delegation SAS is available in all Azure regions. How to generate a prefix-scoped SAS To generate and use a prefix-scoped SAS: Identify the prefix (or virtual directory) you want to authorize. Follow the steps in the documentation to create a prefix-scoped SAS for user delegation SAS. Use the SAS token with your application. Notes Support for prefix-scoped access parameters is available with authorization version 2020-02-10 or later via REST API and .NET Blob SDKs starting with version 12.35.0-beta.1 and newer. The semantics for prefix scope (sr=d) are similar to container scope (sr=c), except that access is restricted to a prefix. When creating a prefix-scoped SAS, you must specify the signedDirectoryDepth (sdd) to indicate how many directory levels from the container root to the specified directory. For example, to grant access to dir2 on path container1/dir1/dir2, set the directory depth (sdd) = 2 to indicate the SAS is scoped to dir2 and everything beneath it. Below are .NET SDK and REST API examples for reference. .NET SDK Sample Definition BlobSasBuilder blobSasBuilder = new BlobSasBuilder( permissions: BlobContainerSasPermissions.All, expiresOn: Recording.UtcNow.AddDays(1)) { BlobContainerName = test.Container.Name, BlobName = blobName, IsDirectory = true, }; // Test using same name as SAS BlobUriBuilder blobUriBuilder1 = new BlobUriBuilder(test.Container.Uri) { BlobName = blobName, Sas = blobSasBuilder.ToSasQueryParameters(Tenants.GetNewSharedKeyCredentials()) }; AppendBlobClient appendBlobClient1 = new AppendBlobClient(blobUriBuilder1.ToUri(), GetOptions()); await appendBlobClient1.CreateAsync(); // Test using SAS name + suffix BlobUriBuilder blobUriBuilder2 = new BlobUriBuilder(test.Container.Uri) { BlobName = blobName + "/test", Sas = blobSasBuilder.ToSasQueryParameters(Tenants.GetNewSharedKeyCredentials()) }; AppendBlobClient appendBlobClient2 = new AppendBlobClient(blobUriBuilder2.ToUri(), GetOptions()); await appendBlobClient2.CreateAsync(); REST API Sample Request GET https://myaccount.blob.core.windows.net/mycontainer ?restype=container &comp=list &prefix=dir1/dir2/ &sr=d &sdd=2 &sp=rl &sv=2024-11-04 &se=2026-04-22T06:00:00Z &skoid=<signed-oid> &sktid=<signed-tid> &skt=2026-04-22T00:00:00Z &ske=2026-04-22T08:00:00Z &sks=b &skv=2024-11-04 &sig=<signature> Next Steps For a deeper dive, explore these resources: Grant limited access to data with shared access signatures (SAS) Create a user delegation SAS Create a service SAS Monitor Azure Blob Storage Help and Support If you have questions, get answers from community experts in Microsoft Q&A. If you have a support plan and you need technical help, create a support request: For Issue type, select Technical. For Subscription, select your subscription. For Service, select My services. For Service type, select Blob Storage. For Resource, select the Azure resource you are creating a support request for. For Summary, type a description of your issue. For Problem type, select Authentication and Authorization . For Problem subtype, select Issues using Shared Access Signature (SAS Token).Unlocking AI-Ready Unstructured Data at Scale with Komprise and Azure
Why Move Unstructured Data to Azure On-premises storage environments are often over-provisioned to accommodate future growth, driving costs and operational complexity. Azure’s cloud-based storage platform enables organizations to right-size their environments through elastic scaling and Microsoft’s global economies of scale. This flexibility is especially critical for regulated industries managing sensitive data at massive scale. Azure also delivers enterprise-grade security capabilities, including immutability and object locking, which protect data against ransomware and malicious deletion. By moving unstructured data to Azure, organizations gain not only cost efficiency, but also a more resilient and secure data foundation. A strong example of this approach is the Florida Department of Environmental Protection. With support from Komprise and funding through Microsoft’s Azure Migrate program, the department successfully migrated large volumes of data to Azure, enabling the phase-out of on-premises data centers while maintaining access to data for analysis across regions. This demonstrates how organizations can modernize data infrastructure without disrupting business operations. Hybrid Cloud and Intelligent Tiering Most enterprises operate in hybrid environments, balancing on-premises systems with cloud storage. Komprise and Microsoft address this reality by enabling intelligent tiering of unstructured data across environments. Using Azure Blob Storage, organizations can transparently move cold and infrequently accessed data to lower-cost cloud tiers while keeping frequently accessed data close to applications and users. This approach reduces pressure on expensive on-premises storage infrastructure without sacrificing accessibility. For example, a major healthcare organization achieved approximately $2.5 million in storage cost savings by tiering cold data to Azure while maintaining seamless access for clinicians and applications. AI Depends on Data Curation AI's efficacy is reliant on data quality. The need for high-quality and curated data cannot be enough emphasized so AI can generate meaningful and accurate results. In partnership with Komprise, organizations can efficiently cleanse and enhance their data by identifying and eliminating redundancies. By curating data before AI processes, organizations have achieved impressive accuracy improvements—as demonstrated by a financial services firm that increased their AI output accuracy by 135%. Making Data AI-Ready on Azure Azure provides a powerful execution platform for AI and Komprise enhances this by bringing structure to unstructured data through its data classification, metadata extraction capabilities and with search, curation and intelligent ingestion via its data workflow and governance capabilities. These ensure only high-quality, relevant and compliant data feeds AI workflows. This approach enables smoother integration with AI services and applications such as Microsoft Foundry and Copilot, while preserving flexibility. By treating data readiness as a foundational step, organizations can accelerate time to value from AI while reducing risk. Security, Governance, and Responsible AI As cyber threats and regulatory requirements continue to intensify, security and governance are no longer optional. Organizations must manage data flows carefully, maintain auditability, and protect sensitive information—especially when using data for AI. Azure’s built-in security capabilities, including immutability, versioning, and backup, provide a strong foundation for protecting unstructured data. Komprise complements these capabilities by automating data governance policies, enforcing compliance, and helping organizations maintain visibility and control across hybrid environments. Together, they enable organizations to use data safely and responsibly, supporting both regulatory compliance and responsible AI practices. Conclusion As AI adoption accelerates, success increasingly depends on data readiness rather than algorithms alone. Clean, well-governed, and properly placed data is the foundation for meaningful AI outcomes. By combining Azure’s scalable and secure cloud platform with Komprise’s intelligent data management, organizations can reduce costs, strengthen security, and unlock real value from unstructured data at scale. To learn more, watch the Microsoft–Komprise fireside chat, where we discuss customer examples, architectural best practices, and proven approaches for managing unstructured data across hybrid environments. We also invite you to explore our joint Azure and Komprise solutions to see how you can move from data sprawl to AI value while maintaining control, security, and flexibility. In a recent fireside chat now available on YouTube, Azure Storage VP Aung Oo joined Komprise COO Krishna Subramanian to explore how Azure and Komprise are empowering customers to mobilize, curate, and optimize unstructured data to make it AI-ready. To leverage the Storage Migration Program with Komprise to migrate your data to Azure find more information at Microsoft Marketplace. To take advantage of the full Komprise suite including automated tiering and smart workflows – additional details are available here.Enterprise Identity Meets Secure File Transfer: Entra ID Public Preview on Azure Blob Storage SFTP
We are excited to announce the public preview of Entra ID-based access for Azure Blob Storage SFTP. This new capability enables you to use Microsoft Entra ID (formerly Azure Active Directory) identities (including guest users via Entra External Identities) to securely connect to Azure Blob Storage via SFTP without needing local users. This feature eliminates the operational overhead of managing local SFTP users and passwords by introducing enterprise-grade identity management powered by Microsoft Entra ID. For IT administrators and security teams, this means no more creating, tracking, rotating, or decommissioning local SFTP credentials. For developers and architects, it means seamless integration with your existing identity infrastructure. For business users, it means faster, more secure access to the data they need, all while maintaining compliance with enterprise security policies. Azure Blob Storage SFTP Azure Blob Storage SFTP natively enables secure file access and management without third-party solutions. This simplifies operations for customers and removes the need for complex, custom SFTP solutions. Until this Public Preview, Azure Blob Storage SFTP utilized a form of identity management called local users as the only authorization mechanism. Local users must use either a password or a Secure Shell (SSH) private key credential for authentication. Learn more about local users here. The Challenge: SFTP Local User Management Organizations currently face challenges when managing SFTP access at scale with Azure Storage SFTP Local Users. Local User based SFTP access require IT teams to: Manually create and provision local user accounts for each SFTP user Generate, distribute, and securely store SSH keys or passwords Implement custom workflows for lifecycle management Manage offboarding processes to ensure departed users lose access immediately Audit and track access across disconnected identity silos Handle external partner and vendor access through ad-hoc, often insecure methods The Solution: Enterprise Identity Meets Secure File Transfer With Entra ID-based access for Azure Blob Storage SFTP, you can now leverage your organization's centralized identity platform to authenticate and authorize SFTP users. This integration brings the full power of Microsoft Entra ID to your file transfer workflows, delivering the following benefits: 1. Eliminate Local User Management Simplify SFTP management by assigning access with Entra ID—no separate SFTP accounts needed. No local credential generation or distribution—users authenticate with their existing corporate credentials No orphaned accounts when users change roles or leave the organization Reduced attack surface by eliminating static, long-lived local credentials Centralized user lifecycle management through your existing identity platform 2. Enterprise-Grade Identity and Security Leverage the full security capabilities of Microsoft Entra ID for your SFTP infrastructure: Multi-Factor Authentication (MFA): Require additional verification factors beyond passwords, significantly reducing the risk of account compromise Conditional Access: Define policies that grant or block access based on user location, device compliance, sign-in risk, and other conditions Identity Protection: Benefit from Microsoft threat intelligence and risk detection to identify and respond to compromised accounts Privileged Identity Management (PIM): Provide just-in-time elevated access for administrative operations 3. Native Azure RBAC, ABAC, and ACL Integration Your SFTP access control seamlessly integrates with Azure comprehensive authorization framework: Role-Based Access Control (RBAC): Assign built-in or custom roles at the storage account, container, or even blob level Attribute-Based Access Control (ABAC): Create sophisticated access policies based on resource tags, user attributes, and environmental conditions Access Control Lists (ACLs): Apply fine-grained permissions at the directory and file level for hierarchical namespace-enabled accounts Unified Permission Model: SFTP access respects the same permissions as REST API, Azure CLI, and other access methods—no separate permission system to manage 4. Faster SFTP Onboarding and Time-to-Value Onboard new SFTP users or partners in minutes instead of hours or days, saving significant time and boosting business agility. 5. Secure External Collaboration with Entra External Identities Seamlessly enable secure external SFTP access by allowing partners to authenticate with their own credentials using Entra External Identities (Azure AD B2B). External users authenticate with credentials they already manage Full audit trail of external user activity Ability to apply Conditional Access policies to external users Automatic access revocation when B2B relationships end Real World Scenarios Financial Services: A bank receives daily transaction files from merchants via SFTP. Merchants authenticate with their own Entra ID credentials (B2B collaboration), MFA is enforced, and access is restricted to assigned directories. Access is instantly revoked when a merchant is removed from the B2B directory. Healthcare: A hospital exchanges patient data with insurers and labs. Entra ID authentication ensures only authorized staff access sensitive PII, with full audit logs for HIPAA compliance. Conditional Access restricts connections to approved locations and devices. Media & Entertainment: A production company enables freelance editors and agencies to transfer large media files. Entra External Identities provide time-limited access and automatic revocation when projects end—no need for local SFTP accounts. Manufacturing: A manufacturer receives CAD files and orders from suppliers using SFTP. With Entra ID, suppliers use unified credentials and access policies across all systems, streamlining supply chain management. How It Works Entra ID simplifies SFTP access to Azure Blob Storage by authenticating users with their corporate credentials. After authentication, users receive a short-lived Open SSH certificate to connect. The service verifies certificate validity and user permissions, enabling secure file operations and automatic access revocation in line with current identity policies. Learn more here. Getting started with the Public Preview We encourage you to try Entra ID-based access for Azure Blob Storage SFTP in your non-production environments today. Learn more about how to register for the preview and get started with the detailed ms docs learn guide here. This preview gives you an opportunity to shape the feature development by providing feedback on what works well and what could be improved. Note: Local user accounts for SFTP access are still supported, but we strongly recommend switching to Entra ID-based access for greater security, simpler management, and automatic access control. Questions or feedback? We would love to hear from you! Reach out to our team at blobsftp@microsoft.com We are excited to bring enterprise-grade identity management to Azure Blob Storage SFTP, and we cannot wait to see how you use this capability to simplify operations, enhance security, and enable new collaboration scenarios. Happy transferring!
Public Preview: Restrict usage of user delegation SAS to an Entra ID identity
Shared access signatures (SAS) grant time-bound, scoped access to Azure Storage resources without sharing account keys. Over time, Azure Storage has continued to strengthen SAS security, moving from account keys to user delegation (UD) SAS secured by Microsoft Entra ID. Today, we’re taking the next step forward by announcing public preview for user-bound user delegation SAS, an extension of UD SAS that ensures a SAS token can only be used by a specific Entra ID identity. This new capability helps customers significantly reduce the risk of unintended access while preserving the flexibility of SAS. UD SAS is an existing feature which utilizes Entra ID and Azure role-based access control (RBAC). Users retrieve a user delegation key tied to their Entra ID account and then use it to create SAS tokens granting a subset of their own access rights. The resulting token can be traced to the delegator and can only be valid for up to 7 days. User-bound UD SAS is an extension of user delegation (UD) SAS which allows users to create a more secure SAS token by restricting the usage of the SAS token to an end user identity. The delegator specifies the Entra identity (security principal) of the end user in the SAS token and the end user needs to authenticate to Entra ID to use the token. The end user can either be in the same tenant or a different tenant as the delegator. Pricing and availability There is no additional cost for user-bound user delegation SAS. Pricing is based on the standard read/write transaction costs for your storage account type. To learn more, please see Azure Storage Pricing. User-bound user delegation SAS is in preview in all public regions. This preview will be available via REST APIs, SDKs, PowerShell, and CLI experiences. Getting started Getting started is simple: User-bound user delegation SAS is available on all GPv2 storage accounts in public regions. If the end user of the SAS token is in a different tenant, the allowCrossTenantDelegationSas setting must be enabled on the storage account. If you are not planning on using this feature cross-tenant, the account setting can remain disabled. Perform the following steps in the create a user delegation SAS documentation to generate and use a user-bound UD SAS token: Ensure you have the correct RBAC roles assigned to the delegator to create a user delegation key. These roles will include the Storage <Service> Data Contributor and Storage <Service> Delegator (replace Service with the respective service you are using). Here are all of the applicable roles for each service: Azure Blob Azure Table Azure Files Azure Queue Storage Blob Data Contributor Storage Table Data Contributor Storage Files Data Contributor Storage Queue Data Contributor Storage Blob Delegator Storage Table Delegator Storage Files Delegator Storage Queue Delegator Get a user delegation key (instructions here) Get the OAuth object ID and tenant ID from your end user. They will have to get these IDs (instructions here) and provide them to you. Create the user-bound user delegation SAS token (instructions here. Note that the steps are the same as for a normal UD SAS token; you will just have to specify the end user and tenant if applicable). Share the SAS token to the application/user intended to access Azure Storage. Tokens should be passed within applications automatically or shared via key vault for best practice. Feedback If you have questions or feedback, please fill out this feedback form. If you need help, create a support request.
Transforming Data migration using Azure Copilot
Introduction Data migration is critical, yet it is one of the most complex tasks in any cloud adoption journey. Whether you’re moving workloads from on-premises environments, consolidating hybrid deployments, or transitioning from other cloud providers, the migration process involves multiple tools, intricate planning, and risk management. What’s New in Azure Copilot With the new “Storage Migration Solutions Advisor” capability in Azure Copilot, Microsoft is transforming this experience into a conversational, AI-driven workflow that accelerates decision-making and reduces operational friction. Why This Matters Traditionally, customers faced challenges such as: Weeks of advisory time spent choosing the right migration tool amongst the many (Azure Storage Mover, AzCopy, Data Box, File Sync etc., and various Partner solutions). High support overhead due to missteps during migration if a sub-optimal tool or service is used. The Storage Migration Solutions Advisor feature introduces: Conversational Guidance: Share your migration needs with Copilot, like talking with an Azure advisor. Scenario-Based Recommendations: Tailored suggestions based on transfer data size, protocol, and bandwidth. Expanded Coverage: Supports on-premises to Azure, cloud-to-cloud (AWS/GCP to Azure), and hybrid scenarios. Native and Partner solutions: Copilot can recommend Microsoft-native (1P) solutions and third-party (3P) tools for specialized scenarios —ensuring flexibility for enterprise needs. User Workflow: Step-by-Step Initiate Migration: Start with a prompt like “How can I migrate my data into Azure?” or “What’s the best tool for moving 1 PB from AWS S3 to Azure Blob?” Provide Details: Copilot will guide you by asking for details about your requirement, such as source type (e.g., NAS, SAN, AWS S3, GCS), protocol (e.g., NFS, SMB, S3 API), target (e.g., Azure Blob, Files, Elastic SAN), data size, and bandwidth. Azure and Partner Solutions: Based on your requirements, Copilot recommends the best-fit Azure solution. If a partner solution is better suited to your requirement, Copilot will also select and recommend the appropriate solution with links to its documentation and/or its Azure marketplace page. Examples Copilot generates recommendations for migrating an on-premises file share to Azure Files. Figure 1 Prompt from user invokes Copilot Migration recommendation workflow Figure 2 Copilot understanding protocols that customer environment has access to Figure 3 Copilot asking user's target Storage type Figure 4 Copilot gathering inputs on data size, network bandwidth availability and transfer direction Figure 5 Copilot recommendation for user scenario Copilot recommends Partner solutions for specialized migration scenarios Figure 1 Prompt from user invokes Copilot Migration recommendation workflow Figure 2 Copilot understanding protocols that customer environment has access to Figure 3 Copilot asking user's target Storage type Figure 4 Copilot gathering inputs on data size, network bandwidth availability and transfer direction Figure 5 Copilot recommendation for user scenario Pro Tips Run a small proof-of-concept migration to estimate throughput and timing, especially for large datasets or small file sizes. Combine Copilot’s recommendations with Azure Storage Discovery for visibility into your storage estate after migration. Getting Started Navigate to Azure Portal → Copilot. Try prompts like: o “Help me migrate an NFS share to Azure Files.” o “What’s the best tool for moving 1 PB from AWS S3 to Azure Blob?” Explore Manage and migrate storage accounts using Azure Copilot | Microsoft Learn for detailed guidance. Ready to simplify your migration journey? Start using Azure Copilot’s Storage Migration Solutions Advisor today and experience AI-driven efficiency for your cloud transformation.
Unlocking Storage Optimizations: Smart Tiering for Blobs and ADLS in Azure Storage
We are excited to introduce the public preview of smart tier for Azure Blob and Azure Data Lake Storage. Smart tier is a fully managed, automated data tiering solution that takes the guesswork and manual effort out of optimizing your storage costs. Smart tier continuously analyzes your data’s access patterns and automatically moves objects between the hot, cool, and cold tiers. Smart tier will keep regularly accessed objects on the hot capacity tier to optimize transaction costs and moves inactive objects after 30 days to the cool tier capacity tier and after an additional 60 days of inactivity to the cold capacity tier. If you access an object in cool or cold tiers again, it’s instantly promoted back to the hot tier, restarting the cycle. This ensures your data is always in the most cost-effective tier with zero manual intervention, making it the ideal online tier for datasets with mixed or unknown access patterns. Getting started Using smart tier is quick and easy: Enabling smart tier is simple: Just select smart tier as the default access tier through the storage account configuration for any storage account with zonal redundancy. Smart tier is available in all zonal public cloud regions, supporting both flat and hierarchical namespaces. Billing is straightforward: You will pay the regular hot, cool, and cold capacity rates, with no extra charges for tier transitions, early deletion, or data retrieval. Even moving existing objects into smart tier does not incur tier change fees. There’s just a small monitoring fee for the orchestration. Smart tier is configured at the account level. It can be configured via API or the Azure portal as the default access tier setting for new and existing storage accounts. Existing objects following the default access tier setting from the account will be moved to smart tier automatically. Objects that are explicitly tiered, i.e. to the hot tier, will remain in the same account and will not be moved to other capacity tiers. Smart tier will always keep small objects that are below 128 KiB in size in the hot capacity tier for efficiency and those objects will not incur a monitoring charge. If objects below 128 KiB increase in size, the smart tiering patterns apply for those objects as well. The automatic down tiering of inactive data, paired with the billing model simplifications of Smart tier can lead to large cost savings over time. In the metrics view of the storage account you can see the distribution across the capacity tiers for smart tiered objects by both object count and capacity. This account shows smart tier in action, moving inactive objects to the cool and cold capacity tier, thereby drastically reducing the capacity charges without any manual intervention. "2 years ago, Qumulo partnered with Microsoft to deliver the first truly elastic, unlimited capacity, fully managed file system, Azure Native Qumulo, which was built on Azure Blob," said Brandon Whitelaw SVP of Product at Qumulo. "Qumulo shared feedback with Microsoft on our ideal solution for data tiering and Microsoft clearly delivered, meeting all expectations. With today's smart tier announcement, Qumulo will immediately enhance our offerings with these new capabilities, delivering greater functionality and control over data lifecycle management. We are thrilled with the feature set Azure is delivering at launch” Note that smart tier is not supported with append and page blobs. Smart tier is the ideal tier to choose when you are looking to store your data on standard online tiers but are not fully aware of the data access patterns or do not want to manage data transitions across online tiers. Objects managed by smart tier are not subject to lifecycle management policies, ensuring that automated tiering decisions are based solely on access patterns. Smart tier for block blobs is now available in public preview for both Azure Blob Storage and Azure Data Lake Storage for storage accounts with zonal redundancies, including ZRS, GZRS and RA-GZRS. Unlock cost savings by adding smart tier to your blob storage accounts in one easy step: https://aka.ms/BlobSmarttier. Please reach out to us for any feedback or questions, we would love to hear from you: smartblob@microsoft.com
Manage/restore metadata when blob is updated
I'm using an Azure Storage container of block blobs as a data source for an Azure AI Search Index, and I'm using Blob metadata key value pairs for some custom data. But metadata gets wiped when a blob is updated. How are folks managing that? For reference, I've got a CosmosDB set up also for now with a cross-reference I can restore from, but it's manual. I considered using Cosmos as my data source instead, but I also need a place to store/serve media files from related to these records.
Priority Replication for Geo Redundant Storage and Object Replication is Generally Available
We are excited to announce the General Availability of priority replication for Geo Redundant Storage (GRS) and Object Replication (OR). Priority replication enhances the replication process of GRS/GZRS and OR, ensuring guaranteed 15 minute synchronization between regions and improved replication times. Enabling priority replication will also provide an official Service Level Agreement (SLA) for all user workloads that meet the SLA criteria. What is Geo Priority Replication? Azure Storage has offered users the choice of geo-redundant (GRS) or geo-zone-redundant (GZRS) replication for their storage accounts for several years. As displayed in the diagram below, with GRS/GZRS, data in the storage account is asynchronously replicated from the primary region to the secondary region: Since the data is asynchronously replicated, in the event there is a disaster in the primary region, and an unplanned failover is initiated, there is a possibility of some data loss. The Last Sync Time (LST) property of a GRS/GZRS account is currently used to provide users with the recovery point objective (RPO) of their account. The LST of the account indicates the most recent time that data from the primary region is guaranteed to have been written to the secondary region. All data and metadata written prior to the LST is guaranteed to be available on the secondary. However, any data or metadata written after the LST may not have been replicated to the secondary and could be lost in the event of a disaster impacting the primary region or an unplanned failover. Azure Blob Storage is now introducing Geo priority replication which will provide an SLA guarantee for the LST/RPO of Block Blob data in GRS/GZRS accounts. Geo priority replication enhances the replication process of GRS/GZRS storage accounts allowing for accelerated replication between the primary and secondary regions. The SLA guarantees the Last Sync Time of Block Blob data will be 15 minutes or less 99.0% of the billing month. With this guaranteed sync time, users can feel more confident about their data’s durability and availability, especially if there is an unexpected outage and failover in the primary region. Please refer to the official SLA Terms for a comprehensive list of eligibility requirements. Geo Priority Replication supports the following SKUs: GRS, RA-GRS, GZRS and RA-GZRS for Block Blob data. What is Object Replication Priority Replication? Without priority replication, object replication asynchronously copies all operations from a source storage account to one or more destination accounts, but completion time is not guaranteed. Object replication priority replication will allow users to obtain prioritized replication from the source storage account to the destination storage account of their replication policy. When you enable priority replication, you can benefit from the associated Service Level Agreement if your source and destination account are located within the same continent. The SLA will guarantee that 99.0% of operations are replicated from the source container to the destination container of their OR policy within 15 minutes for the billing month. Please refer to the official SLA Terms for a comprehensive list of eligibility requirements. How to monitor SLA compliance for Geo and OR Priority Replication? Geo Priority Replication: Geo priority replication introduces a new metric, Geo Blob Lag. This metric allows users to monitor their Blob Replication lag, the number of seconds since the last full data synchronization between the primary and secondary region. This will allow users to track the SLA compliance of their GRS/GZRS account. If an account’s Geo Blob Lag remains within 900 seconds (15 minutes), they can confirm the data replication is within SLA. To learn more about the Geo Blob Lag metric view, Geo Blob Lag Metric. Object Replication Priority Replication: Replication Metrics for Object Replication is now Generally Available. These metrics empower users to troubleshoot replication delays and will help users with priority replication enabled monitor their SLA compliance. Metrics now supported are: Pending Operations: Tracks the total number of operations pending replication from the source to the destination storage account of your OR policy Pending Bytes: Tracks the total volume of data pending replication from the source to the destination storage account of your OR policy These metrics are grouped into various time buckets including 0-5 minutes, 10-15 minutes and > 24 hours. Users with OR priority replication that would like to ensure all their operations are replicating within 15 minutes; can monitor the larger time buckets (ex: 30 mins – 2hours or 8-24 hours) and ensure they are at zero or near zero. Users also have other options such as checking the replication status of their source blob. Users can check the replication status of a source blob to determine whether replication to the destination has been completed. Once the replication status is marked as “Completed,” the user can guarantee the blob is available in the destination account. How to get started? Getting started is simple, to learn more about the step-by-step process to opt-in to Geo priority replication: Azure Storage Geo Priority Replication - Azure Storage | Microsoft Learn. Or if you would like to learn about the step-by-step process to enable OR Priority Replication, view: Object Replication Priority Replication - Azure Storage | Microsoft Learn. Feedback If you have questions or feedback, reach out at priorityreplication@microsoft.com.
