Storage Concurrency and resource state premium

ETag

ETag is a version marker returned by Azure services that lets clients detect whether a resource changed since they last read it. In Azure, it usually appears when applications, operators, or deployment tools need to update data safely without overwriting a newer change made by another process. Teams use it to read the current ETag, send it back with an If-Match or equivalent condition, and let the service accept or reject the update. Operators should document ownership, scope, dependency health, evidence, and rollback before changing production behavior.

Back to glossary browser Open Microsoft Learn source
Aliases
etag
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-14

Microsoft Learn

An ETag is an opaque identifier that represents the current version of a resource and is commonly used for optimistic concurrency checks.

Microsoft Learn: Manage concurrency in Blob Storage2026-05-14

Technical context

Technically, ETag sits in Azure Blob Storage, Table Storage, Cosmos DB items, Azure Resource Manager resources, REST APIs, SDK clients, and optimistic concurrency control. It depends on a resource that exposes ETags, client support for conditional writes, retry-safe application design, and clear handling for precondition failures and is usually validated through blob properties, table entity details, Cosmos DB item metadata, REST responses, Activity Log, and application dependency telemetry. The configuration connects to optimistic concurrency, entity group transactions, blob updates, Cosmos DB item writes, ARM deployments, conflict resolution, and retry policies.

Why it matters

ETag matters because it prevents accidental overwrites when multiple clients or automation paths update the same resource, especially in distributed applications. Without it, teams often blindly replace newer data, turn concurrency conflicts into data loss, or retry failed updates without re-reading current state. A strong implementation gives architects a clear decision point, gives operators measurable evidence, and gives security reviewers proof that the intended boundary or workflow is real. It also prevents confusing this term with adjacent Azure concepts that look similar but solve a different problem. That shared vocabulary is important when support, compliance, platform engineering, and application owners all need to reason about the same production behavior.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

In blob properties, an ETag appears as a quoted version value that changes when the blob is updated by another writer during production review and support triage.

Signal 02

In Table Storage or Cosmos DB, it appears as entity or item metadata used for optimistic concurrency during conditional updates during production review and support triage.

Signal 03

In REST failures, it appears when an If-Match condition fails and the service rejects the write to prevent overwriting newer state during production review and support triage.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

  • Use ETag when production behavior depends on the concept being configured, monitored, or governed correctly.
  • Prevent lost updates when multiple clients modify the same blob, table entity, item, or resource.
  • Diagnose HTTP 412 precondition failures and stale-write behavior.

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 01

ETag in action for retail

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Fourth Coffee, a retail organization, needed to solve a production challenge: two inventory services updated the same product blob and sometimes overwrote each other during supplier imports. The architecture team had to improve the workflow without weakening governance or disrupting users.

Business/Technical Objectives
  • Prevent lost inventory updates
  • Detect stale writes immediately
  • Keep import retries safe
  • Reduce support corrections
Solution Using ETag

Developers changed the import workflow to read the blob ETag before applying supplier changes. The update request used an If-Match condition, and a failed precondition forced the service to re-read the blob and recalculate the merge. Application Insights tracked precondition failures separately from storage throttling. Operators received a runbook explaining when an ETag conflict was expected and when repeated conflicts indicated a hot product record that needed design review. The implementation record captured accountable owners, rollback steps, monitoring thresholds, test evidence, and the exact checks operators would use before changing ETag in production. Security, application, and platform teams reviewed the design together so identity, network, logging, cost, and lifecycle controls matched the ETag operating model.

Results & Business Impact
  • Lost inventory updates stopped for the import path
  • Manual corrections dropped by 54 percent
  • Repeated conflicts identified three hot products needing workflow changes
  • Retry logic no longer overwrote newer data
Key Takeaway for Glossary Readers

ETags protect data by making stale writes fail visibly instead of silently replacing current state.

Case study 02

ETag in action for healthcare

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Wide World Health, a healthcare organization, needed to solve a production challenge: patient intake forms stored in Table Storage were updated by nurses and automated eligibility checks at the same time. The architecture team had to improve the workflow without weakening governance or disrupting users.

Business/Technical Objectives
  • Avoid overwriting clinical intake changes
  • Expose concurrency conflicts to support
  • Keep table storage as the system of record
  • Protect sensitive conflict logs
Solution Using ETag

The application used entity ETags for optimistic concurrency on each intake row. When a nurse submitted updates, the client included the ETag from the last read. If an eligibility service had already changed the entity, the write failed and the UI asked the nurse to refresh rather than overwriting fields. Logs recorded conflict categories without storing patient details, and support engineers used table entity evidence to verify the latest version. The implementation record captured accountable owners, rollback steps, monitoring thresholds, test evidence, and the exact checks operators would use before changing ETag in production.

Results & Business Impact
  • Stale write incidents fell to zero in audited workflows
  • Support could explain conflicts without seeing protected health information
  • The team avoided a costly database redesign
  • Nurse refresh prompts reduced hidden data loss risk
Key Takeaway for Glossary Readers

An ETag is a small piece of metadata that can prevent serious business data errors.

Case study 03

ETag in action for utilities

Scenario, objectives, solution, measured impact, and takeaway.

Scenario

CityGrid Utilities, a utilities organization, needed to solve a production challenge: automation scripts updated ARM resource settings while platform engineers changed the same resources during maintenance windows. The architecture team had to improve the workflow without weakening governance or disrupting users.

Business/Technical Objectives
  • Stop automation from overwriting manual changes
  • Capture evidence for rejected updates
  • Improve change-window coordination
  • Reduce resource drift incidents
Solution Using ETag

Platform engineers added ETag awareness to the automation workflow. Scripts retrieved the resource state, recorded the ETag, and used conditional logic before submitting updates through REST. If the ETag changed, the job stopped, attached evidence to the change ticket, and waited for human review. Azure Activity Log and deployment records helped teams confirm whether a manual change or another pipeline caused the conflict. The implementation record captured accountable owners, rollback steps, monitoring thresholds, test evidence, and the exact checks operators would use before changing ETag in production. Security, application, and platform teams reviewed the design together so identity, network, logging, cost, and lifecycle controls matched the ETag operating model.

Results & Business Impact
  • Resource drift incidents dropped by 32 percent
  • Rejected updates included clear before-and-after evidence
  • Maintenance scripts stopped overwriting emergency fixes
  • Change coordinators had fewer conflicting updates to reconcile
Key Takeaway for Glossary Readers

ETags are useful beyond storage because they help automation respect current resource state.

Why use Azure CLI for this?

CLI checks for ETag turn portal assumptions into repeatable evidence. Start with read-only show, list, query, or metrics commands, capture the exact scope, and compare output with source control and runbooks. Mutating commands should run only through an approved change because the wrong subscription, project, table, event subscription, or resource can change customer-facing behavior.

CLI use cases

  • Confirm the live resource, setting, subscription, or project that owns ETag before a production change.
  • Collect repeatable evidence for ETag during support, audit, cost, reliability, or security review.
  • Run approved update commands only after validating scope, owner, rollback path, and expected downstream impact.

Before you run CLI

  • Run az account show and confirm the tenant, subscription, environment, and signed-in identity before collecting evidence.
  • Confirm the exact resource group, resource name, deployment name, owner, and ticket before running mutating commands.
  • Use read-only commands first, save sanitized JSON output, and compare it with source control, runbooks, and approved design notes.

What output tells you

  • Whether the resource, deployment, identity, event subscription, tag, table entity, or monitored component exists at the expected scope.
  • Which IDs, names, states, filters, tags, headers, metrics, timestamps, and linked resources explain the current production behavior.
  • Whether follow-up work should focus on access, schema, routing, monitoring, retry behavior, cost allocation, or application configuration.

Mapped Azure CLI commands

ETag operational checks

direct
az storage blob show --account-name <storage-account> --container-name <container> --name <blob> --query properties.etag
az storage blobdiscoverStorage
read-only Microsoft docs
az storage entity show --table-name <table-name> --account-name <storage-account> --partition-key <partition-key> --row-key <row-key>
az storage entitydiscoverStorage
read-only Microsoft docs
az resource show --ids <resource-id> --query etag
az resourcediscoverStorage
read-only Microsoft docs
az cosmosdb sql container show --account-name <account> --database-name <database> --name <container> --resource-group <resource-group>
az cosmosdb sql containerdiscoverDatabases
read-only Microsoft docs

Architecture context

ETag belongs to Storage architecture decisions where identity, data handling, monitoring, reliability, cost, and operations must be designed together instead of patched after deployment.

Security

Security for ETag starts with data-plane permissions, secrets in request logs, conditional-write authorization, protected metadata, RBAC, SAS scope, and secure handling of conflict evidence. Review the control at the Azure scope where it is configured, not only in a diagram. Confirm who can create, update, disable, or delete it and whether those actions are visible in logs. Sensitive data, secrets, identities, endpoints, and telemetry should be treated as part of one design. Prefer least privilege, managed identity where appropriate, private access where required, and documented approvals for changes that affect production users or regulated data. Operators should document ownership, scope, dependency health, evidence, and rollback before changing production behavior.

Cost

Cost for ETag is driven by extra read-before-write calls, failed retries, duplicated processing, support labor, conflict repair work, and unnecessary migration caused by poor concurrency design. The direct Azure charge may be only part of the total; operator time, reprocessing, duplicate environments, support tickets, and audit preparation can be larger than the visible line item. Teams should estimate steady-state usage, rollout spikes, test activity, and failure-driven retries. They should tag owners and environments so costs can be explained later. A practical review asks whether the design prevents waste, avoids unnecessary duplication, and makes cleanup easy when the workload ends.

Reliability

Reliability for ETag depends on precondition failure handling, retry behavior, stale reads, idempotent updates, conflict detection, and runbooks that tell operators when to re-read state. Operators need a known-good baseline, a way to detect drift, and a rollback or retry path that has been rehearsed before an emergency. Dependencies should be named explicitly so responders know which service, identity, schema, quota, endpoint, or configuration can block the workload. Test failure modes, not only happy paths, because many Azure issues appear as partial degradation. Reliable use means the feature keeps doing the expected job after releases, scaling, rotation, and regional events.

Performance

Performance for ETag depends on conditional request overhead, extra reads, high-contention hot records, SDK retry settings, storage latency, and avoiding update loops on frequently changed resources. The useful measurement is usually not just average latency; teams should inspect tail latency, throughput, throttling, retry behavior, dependency response time, and user-visible outcomes. Testing should use realistic inputs and production-like scale because small tests hide bottlenecks. Operators need dashboards that separate platform behavior, application code, network paths, and downstream dependencies. When performance changes after a release, the team should be able to compare old and new configuration quickly. Operators should document ownership, scope, dependency health, evidence, and rollback before changing production behavior.

Operations

Operations for ETag should focus on capturing current ETags, documenting update paths, training support on HTTP 412 responses, auditing write clients, and tracking conflict frequency. The term should appear in runbooks with the resource name, owner, environment, normal state, and approved change procedure. Operators should know which portal page, CLI command, metric, log, or REST response proves current state. Alerts should be actionable instead of only proving something exists. Good operations include periodic review, cleanup of stale configuration, evidence capture for audits, and a clear escalation path when application, platform, and security teams share ownership. Operators should document ownership, scope, dependency health, evidence, and rollback before changing production behavior.

Common mistakes

  • Assuming a matching display name proves the right tenant, subscription, project, table, endpoint, or event subscription was checked.
  • Running an update before capturing read-only evidence, owner approval, expected post-change behavior, and rollback instructions.
  • Ignoring related identity, network, monitoring, schema, partitioning, and lifecycle dependencies that make the term work in production.