Merge pull request #299872 from vgs-msft/vgs_lcm_autoupt

Update lifecycle-management-overview.md

Author: prmerger-automator[bot]

articles/storage/blobs/lifecycle-management-overview.md

@@ -77,7 +77,7 @@ Each rule within the policy has several parameters, described in the following t
 
 When you add or edit the rules of a lifecycle policy, it can take up to 24 hours for changes to go into effect and for the first execution to start. 
 
-An active policy processes objects periodically, and is interrupted if changes are made to the policy. If you disable a policy, then no new policy runs will be scheduled, but if a run is already in progress, that run will continue until it completes and you're billed for any actions that are required to complete the run. If you disable or delete all of the rules in a policy, then the policy becomes inactive, and no new runs will be scheduled. 
+An active policy processes objects periodically, and is interrupted if changes are made to the policy. If you delete a policy, then no new policy runs will be scheduled, but if a run is already in progress, that run will continue until it completes and you're billed for any actions that are required to complete the run. If you disable all of the rules in a policy, then the policy becomes inactive. If a run is already in progress, that run will come to a stop within 24 hours, and no new runs will be scheduled. It is recommended to disable a policy first, wait 24 hours and then delete policy.
 
 The time required for a run to complete depends on the number of blobs evaluated and operated on. The latency with which a blob is evaluated and operated on may be longer if the request rate for the storage account approaches the storage account limit. All requests made to storage account, including requests made by policy runs, accrue to the same limit on requests per second, and as that limit approaches, priority is given to requests made by workloads.  To request an increase in account limits, contact [Azure Support](https://azure.microsoft.com/support/faq/).
 Learn more about [Lifecycle Management Performance Characteristics](lifecycle-management-performance-characteristics.md).
@@ -210,6 +210,9 @@ The `LifecyclePolicyCompleted` event is generated when the actions defined by a
     "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
     "data": {
         "scheduleTime": "2022/05/24 22:57:29.3260160",
+        “policyRunSummary”: { 
+            “completionStatus”: “Completed/CompletedWithError/Incomplete” 
+        },
         "deleteSummary": {
             "totalObjectsCount": 16,
             "successCount": 14,
@@ -300,6 +303,9 @@ In the following example, blobs are moved to cool storage if they haven't been a
 > [!TIP]
 > If a blob is moved to the cool tier, and then is automatically moved back before 30 days has elapsed, an early deletion fee is charged. Before you set the `enableAutoTierToHotFromCool` property, make sure to analyze the access patterns of your data so you can reduce unexpected charges.
 
+Automatic uptiering of objects on access is limited to once in 30 days. This safeguard is in place to avoid multiple early deletion penalties from the cool tier. If the object tiers back to cool due to the policy, any transactions on the blob is charged at the cool tier prices. It is cost-efficient to keep the blob in hot tier if it needs to be auto-uptiered more than once in a 30-day period.
+Enabling a rule with "enableAutoTierToHotFromCool" applies only to objects that are tiered down with this rule. The enableAutoTierToHotFromCool property can't be enabled for blobs that are already in the cool tier. Therefore, the access tier of those blobs won't automatically change to hot when they are accessed.
+
 ```json
 {
   "enabled": true,

articles/storage/blobs/lifecycle-management-performance-characteristics.md

@@ -57,7 +57,7 @@ It might be more cost effective for the small objects to stay in their current t
 
 ### Set appropriate time-based rules
 
-Avoid policy conditions that use a short duration between object creation, modification or last access time, and the intended operation by the policy. Lifecycle management can take up to 24 hours to begin processing after the prior run is completed. Policy changes and updates can also take up to 24 hours to go into effect. This includes deleting all the rules to make a policy inactive. Policies that take multiple days to complete might not operate on objects that were evaluated earlier in the run even though they meet the conditions over the run period.
+Avoid policy conditions that use a short duration between object creation, modification or last access time, and the intended operation by the policy. Lifecycle management can take up to 24 hours to begin processing after the prior run is completed. Policy changes and updates can also take up to 24 hours to go into effect. Policies that take multiple days to complete might not operate on objects that were evaluated earlier in the run even though they meet the conditions over the run period.
 
 
 ### Be aware of scalability and performance limits