Merge pull request #293597 from MicrosoftDocs/main

Publish to live, Sunday 4 AM PST, 1/26

Author: ttorble

articles/cdn/cdn-add-to-web-app.md

@@ -48,7 +48,7 @@ Open a browser and sign in to the [Azure portal](https://portal.azure.com).
 ### Dynamic site acceleration optimization
 
 If you want to optimize your content delivery network endpoint for dynamic site acceleration (DSA), you should use the [content delivery network portal](cdn-create-new-endpoint.md) to create your profile and endpoint. With [DSA optimization](cdn-dynamic-site-acceleration.md), the performance of web pages with dynamic content is measurably improved. For instructions about how to optimize a content delivery network endpoint for DSA from the content delivery network portal, see [content delivery network endpoint configuration to accelerate delivery of dynamic files](cdn-dynamic-site-acceleration.md#cdn-endpoint-configuration-to-accelerate-delivery-of-dynamic-files).
-Otherwise, if you don't want to optimize your new endpoint, you can use the web app portal to create it by following the steps in the next section. For **Azure CDN from Edgio** profiles, you can't change the optimization of a content delivery network endpoint after it has been created.
+Otherwise, if you don't want to optimize your new endpoint, you can use the web app portal to create it by following the steps in the next section.
 
 <a name='create-a-cdn-profile-and-endpoint'></a>
 
@@ -80,9 +80,7 @@ Otherwise, if you don't want to optimize your new endpoint, you can use the web
 
 ### Test the content delivery network endpoint
 
-Because it takes time for the registration to propagate, the endpoint isn't immediately available for use:
-   - For **Azure CDN Standard from Microsoft (classic)** profiles, propagation usually completes in 10 minutes.
-   - For **Azure CDN Standard from Edgio** and **Azure CDN Premium from Edgio** profiles, propagation usually completes within 90 minutes.
+Because it takes time for the registration to propagate, the endpoint isn't immediately available for use. For **Azure CDN Standard from Microsoft (classic)** profiles, propagation usually completes within 10 minutes.
 
 The sample app has an *index.html* file and *css*, *img*, and *js* folders that contain other static assets. The content paths for all of these files are the same at the content delivery network endpoint. For example, both of the following URLs access the *bootstrap.css* file in the *css* folder:
 

articles/cdn/cdn-app-dev-net.md

@@ -298,8 +298,7 @@ private static void PromptPurgeCdnEndpoint(CdnManagementClient cdn)
 ```
 
 > [!NOTE]
-> In the example previously, the string `/*` denotes that I want to purge everything in the root of the endpoint path. This is equivalent to checking **Purge All** in the Azure portal's "purge" dialog. In the `CreateCdnProfile` method, I created our profile as an **Azure CDN from Edgio** profile using the code `Sku = new Sku(SkuName.StandardVerizon)`, so this will be successful.
->
+> In the example previously, the string `/*` denotes that I want to purge everything in the root of the endpoint path. This is equivalent to checking **Purge All** in the Azure portal's "purge" dialog.
 >
 
 ## Delete CDN profiles and endpoints

articles/cdn/cdn-azure-diagnostic-logs.md

@@ -226,11 +226,7 @@ Here's how you can use the tool:
 
 ## Log data delays
 
-The following table shows log data delays for **Azure CDN Standard from Microsoft**, and **Azure CDN Standard/Premium from Edgio**.
-
-| Microsoft log data delays | Edgio log data delays |
-| --- | --- |
-| Delayed by 1 hour. | Delayed by 1 hour and can take up to 2 hours to start appearing after endpoint propagation completion. |
+Microsoft log data is delayed by up to 1 hour. This delay is due to the time it takes to process and store the data.
 
 <a name='diagnostic-log-types-for-cdn-core-analytics'></a>
 
@@ -240,42 +236,37 @@ Microsoft currently offers core analytics logs only, which contain metrics showi
 
 ### Core analytics metrics details
 
-The following table shows a list of metrics available in the core analytics logs for:
-
-- **Azure CDN Standard from Microsoft**
-- **Azure CDN Standard/Premium from Edgio**
+The following table shows a list of metrics available in the core analytics logs.
 
 Not all metrics are available from all providers, although such differences are minimal. The table also displays whether a given metric is available from a provider. The metrics are available for only those content delivery network endpoints that have traffic on them.
 
-| Metric | Description | Microsoft | Edgio |
-|--|--|--|--|
-| RequestCountTotal | Total number of request hits during this period. | Yes | Yes |
-| RequestCountHttpStatus2xx | Count of all requests that resulted in a 2xx HTTP code (for example, 200, 202). | Yes | Yes |
-| RequestCountHttpStatus3xx | Count of all requests that resulted in a 3xx HTTP code (for example, 300, 302). | Yes | Yes |
-| RequestCountHttpStatus4xx | Count of all requests that resulted in a 4xx HTTP code (for example, 400, 404). | Yes | Yes |
-| RequestCountHttpStatus5xx | Count of all requests that resulted in a 5xx HTTP code (for example, 500, 504). | Yes | Yes |
-| RequestCountHttpStatusOthers | Count of all other HTTP codes (outside of 2xx-5xx). | Yes | Yes |
-| RequestCountHttpStatus200 | Count of all requests that resulted in a 200 HTTP code response. | Yes | No |
-| RequestCountHttpStatus206 | Count of all requests that resulted in a 206 HTTP code response. | Yes | No |
-| RequestCountHttpStatus302 | Count of all requests that resulted in a 302 HTTP code response. | Yes | No |
-| RequestCountHttpStatus304 | Count of all requests that resulted in a 304 HTTP code response. | Yes | No |
-| RequestCountHttpStatus404 | Count of all requests that resulted in a 404 HTTP code response. | Yes | No |
-| RequestCountCacheHit | Count of all requests that resulted in a Cache hit. The asset was served directly from the POP to the client. | Yes | Yes |
-| RequestCountCacheMiss | Count of all requests that resulted in a Cache miss. A Cache miss means the asset wasn't found on the POP closest to the client, and was retrieved from the origin. | Yes | Yes |
-| RequestCountCacheNoCache | Count of all requests to an asset that are prevented from being cached because of a user configuration on the edge. | Yes | Yes |
-| RequestCountCacheUncacheable | Count of all requests to assets that are prevented from getting cached by the asset's Cache-Control and Expires headers. This count indicates that it shouldn't be cached on a POP or by the HTTP client. | Yes | Yes |
-| RequestCountCacheOthers | Count of all requests with cache status not covered by metrics listed previously. | No | Yes |
-| EgressTotal | Outbound data transfer in GB | Yes | Yes |
-| EgressHttpStatus2xx | Outbound data transfer* for responses with 2xx HTTP status codes in GB. | Yes | Yes |
-| EgressHttpStatus3xx | Outbound data transfer for responses with 3xx HTTP status codes in GB. | Yes | Yes |
-| EgressHttpStatus4xx | Outbound data transfer for responses with 4xx HTTP status codes in GB. | Yes | Yes |
-| EgressHttpStatus5xx | Outbound data transfer for responses with 5xx HTTP status codes in GB. | Yes | Yes |
-| EgressHttpStatusOthers | Outbound data transfer for responses with other HTTP status codes in GB. | Yes | Yes |
-| EgressCacheHit | Outbound data transfer for responses that were delivered directly from the content delivery network cache on the content delivery network POPs/Edges. | Yes | Yes |
-| EgressCacheMiss. | Outbound data transfer for responses that weren't found on the nearest POP server, and retrieved from the origin server. | Yes | Yes |
-| EgressCacheNoCache | Outbound data transfer for assets that are prevented from being cached because of a user configuration on the edge. | Yes | Yes |
-| EgressCacheUncacheable | Outbound data transfer for assets that are prevented from getting cached by the asset's Cache-Control and, or Expires headers. Indicates that it shouldn't be cached on a POP or by the HTTP client. | Yes | Yes |
-| EgressCacheOthers | Outbound data transfers for other cache scenarios. | No | Yes |
+| Metric | Description |
+|--|--|
+| RequestCountTotal | Total number of request hits during this period. |
+| RequestCountHttpStatus2xx | Count of all requests that resulted in a 2xx HTTP code (for example, 200, 202). |
+| RequestCountHttpStatus3xx | Count of all requests that resulted in a 3xx HTTP code (for example, 300, 302). |
+| RequestCountHttpStatus4xx | Count of all requests that resulted in a 4xx HTTP code (for example, 400, 404). |
+| RequestCountHttpStatus5xx | Count of all requests that resulted in a 5xx HTTP code (for example, 500, 504). |
+| RequestCountHttpStatusOthers | Count of all other HTTP codes (outside of 2xx-5xx). |
+| RequestCountHttpStatus200 | Count of all requests that resulted in a 200 HTTP code response. |
+| RequestCountHttpStatus206 | Count of all requests that resulted in a 206 HTTP code response. |
+| RequestCountHttpStatus302 | Count of all requests that resulted in a 302 HTTP code response. |
+| RequestCountHttpStatus304 | Count of all requests that resulted in a 304 HTTP code response. |
+| RequestCountHttpStatus404 | Count of all requests that resulted in a 404 HTTP code response. |
+| RequestCountCacheHit | Count of all requests that resulted in a Cache hit. The asset was served directly from the POP to the client. |
+| RequestCountCacheMiss | Count of all requests that resulted in a Cache miss. A Cache miss means the asset wasn't found on the POP closest to the client, and was retrieved from the origin. |
+| RequestCountCacheNoCache | Count of all requests to an asset that are prevented from being cached because of a user configuration on the edge. |
+| RequestCountCacheUncacheable | Count of all requests to assets that are prevented from getting cached by the asset's Cache-Control and Expires headers. This count indicates that it shouldn't be cached on a POP or by the HTTP client. |
+| EgressTotal | Outbound data transfer in GB |
+| EgressHttpStatus2xx | Outbound data transfer* for responses with 2xx HTTP status codes in GB. |
+| EgressHttpStatus3xx | Outbound data transfer for responses with 3xx HTTP status codes in GB. |
+| EgressHttpStatus4xx | Outbound data transfer for responses with 4xx HTTP status codes in GB. |
+| EgressHttpStatus5xx | Outbound data transfer for responses with 5xx HTTP status codes in GB. |
+| EgressHttpStatusOthers | Outbound data transfer for responses with other HTTP status codes in GB. |
+| EgressCacheHit | Outbound data transfer for responses that were delivered directly from the content delivery network cache on the content delivery network POPs/Edges. |
+| EgressCacheMiss | Outbound data transfer for responses that weren't found on the nearest POP server, and retrieved from the origin server. |
+| EgressCacheNoCache | Outbound data transfer for assets that are prevented from being cached because of a user configuration on the edge. |
+| EgressCacheUncacheable | Outbound data transfer for assets that are prevented from getting cached by the asset's Cache-Control and, or Expires headers. Indicates that it shouldn't be cached on a POP or by the HTTP client. |
 
 *Outbound data transfer refers to traffic delivered from content delivery network POP servers to the client.
 

articles/cdn/cdn-billing.md

@@ -61,7 +61,7 @@ If you're using Azure Blob storage as the origin for your content, you also incu
 - Transfers in GB: The amount of data transferred to fill the content delivery network caches.
 
 > [!NOTE]
-> Starting October 2019, if you are using Azure Content Delivery Network from Microsoft, the cost of data transfer from origins hosted in Azure to content delivery network PoPs is free of charge. Azure Content Delivery Network from Edgio is subject to the rates described as followed.
+> Starting October 2019, if you are using Azure Content Delivery Network from Microsoft, the cost of data transfer from origins hosted in Azure to content delivery network PoPs is free of charge.
 
 For more information about Azure Storage billing, see [Plan and manage costs for Azure Storage](../storage/common/storage-plan-manage-costs.md).
 

articles/cdn/cdn-caching-rules-tutorial.md

@@ -16,9 +16,6 @@ ms.custom: mvc
 
 [!INCLUDE [Azure CDN from Microsoft (classic) retirement notice](../../includes/cdn-classic-retirement.md)]
 
-> [!NOTE]
-> Caching rules are available only for **Azure CDN Standard from Edgio** profiles. For **Azure CDN from Microsoft** profiles, you must use the [Standard rules engine](cdn-standard-rules-engine-reference.md) For **Azure CDN Premium from Edgio** profiles, you must use the [Edgio Premium rules engine](./cdn-verizon-premium-rules-engine.md) in the **Manage** portal for similar functionality.
-
 This tutorial describes how you can use Azure Content Delivery Network caching rules to set or modify default cache expiration behavior both globally and with custom conditions, such as a URL path and file extension. Azure Content Delivery Network provides two types of caching rules:
 - Global caching rules: You can set one global caching rule for each endpoint in your profile, which affects all requests to the endpoint. The global caching rule overrides any HTTP cache-directive headers, if set.
 

articles/cdn/cdn-caching-rules.md

@@ -16,9 +16,6 @@ ms.author: duau
 
 This article describes how you can use content delivery network caching rules to set or modify default cache expiration behavior. These caching rules can either be global or with custom conditions, such as a URL path and file extension.
 
-> [!NOTE]
-> Caching rules are available only for **Azure CDN Standard from Edgio** profiles. For **Azure CDN from Microsoft** profiles, you must use the [Standard rules engine](cdn-standard-rules-engine-reference.md) For **Azure CDN Premium from Edgio** profiles, you must use the [Edgio Premium rules engine](./cdn-verizon-premium-rules-engine.md) in the **Manage** portal for similar functionality.
-
 Azure Content Delivery Network offers two ways to control how your files get cached:
 
 **Caching rules:** Azure Content Delivery Network provides two types of caching rules: global and custom.
@@ -109,8 +106,6 @@ When you set these rules, a request for *<endpoint hostname>*.azureedge.ne
 > Files that are cached before a rule change maintain their origin cache duration setting. To reset their cache durations, you must [purge the file](cdn-purge-endpoint.md).
 >
 > Azure Content Delivery Network configuration changes can take some time to propagate through the network:
-> - For **Azure CDN Standard from Edgio** profiles, propagation usually completes in 10 minutes.
-
 >
 
 ## See also

articles/cdn/cdn-change-provider.md

@@ -25,8 +25,6 @@ The purpose of this article is to share best practices when migrating from one c
 
 **Azure Front Door:** release two new tiers (Standard and Premium) on March 29, 2022, which is the next generation Azure Front Door. It combines the capabilities of Azure Front Door (classic), Microsoft content delivery network (classic), and Web Application Firewall. With features such as private link integration, enhancements to rules engine, diagnostics, and a one-stop secure application acceleration for Azure customers. For more information about Azure Front Door, see [Azure Front Door overview](../frontdoor/front-door-overview.md).
 
-**Azure CDN Standard/Premium from Edgio:** is an alternative to Azure Front Door for your general content delivery network and media solutions. Azure Content Delivery Network from Edgio is optimized for large media streaming workloads. It has unique content delivery network features such as cache warmup, log delivery services, and reporting features.
-
 ## Pricing comparison
 
 Switching between content delivery network profiles might introduce changes to your content delivery overall cost. For more information about service pricing, see [Azure Front Door pricing](https://azure.microsoft.com/pricing/details/frontdoor/) and [Azure content delivery network pricing](https://azure.microsoft.com/pricing/details/cdn/).
@@ -57,7 +55,7 @@ Create a small-scale proof of concept testing environment with your potential re
 - Define success criteria:
     - Cost - does the new content delivery network profile meet your cost requirements?
     - Performance - does the new content delivery network profile meet the performance requirements of your workload?
-- Create a new profile - for example, Azure Content Delivery Network with Edgio.
+- Create a new profile.
 - Configure your new profile with similar configuration settings as your existing profile.
 - Fine tune caching and compression configuration settings to meet your requirements.
 
@@ -94,4 +92,3 @@ For more information, see [Failover content delivery network endpoints with Traf
 ## Next Steps
 
 - Create an [Azure Front Door](../frontdoor/create-front-door-portal.md) profile.
-- Create an [Azure Content Delivery Network from Edgio](cdn-create-endpoint-how-to.md) profile.

articles/cdn/cdn-china-delivery.md

@@ -29,8 +29,6 @@ Azure Content Delivery Network global and Azure Content Delivery Network China h
 
      - Performs content delivery outside of China
 
-     - Three pricing tiers: Microsoft standard, Edgio standard, and Edgio premium
-
      - [Documentation](./index.yml)
 
 - Azure Content Delivery Network China:

articles/cdn/cdn-cors.md

@@ -70,14 +70,6 @@ On Azure CDN Standard from Microsoft, you can create a rule in the [Standard rul
 > You can add additional actions to your rule to modify additional response headers, such as **Access-Control-Allow-Methods**.
 >
 
-<a name='azure-cdn-premium-from-verizon'></a>
-
-### Azure CDN Premium from Edgio
-
-Using the Edgio Premium rules engine, you need to [create a rule](./cdn-verizon-premium-rules-engine.md) to check the **Origin** header on the request. If it's a valid origin, your rule sets the **Access-Control-Allow-Origin** header with the origin provided in the request. If the origin specified in the **Origin** header isn't allowed, your rule should omit the **Access-Control-Allow-Origin** header, which causes the browser to reject the request.
-
-There are two ways to resolve this problem with the Premium rules engine. In both cases, the **Access-Control-Allow-Origin** header from the file's origin server is ignored and the CDN's rules engine completely manages the allowed CORS origins.
-
 #### One regular expression with all valid origins
 
 In this case, you create a regular expression that includes all of the origins you want to allow:
@@ -86,11 +78,6 @@ In this case, you create a regular expression that includes all of the origins y
 https?:\/\/(www\.contoso\.com|contoso\.com|www\.microsoft\.com|microsoft.com\.com)$
 ```
 
-> [!TIP]
-> **Azure CDN Premium from Edgio** uses [Perl Compatible Regular Expressions](https://pcre.org/) as its engine for regular expressions. You can use a tool like [Regular Expressions 101](https://regex101.com/) to validate your regular expression. Note that the "/" character is valid in regular expressions and doesn't need to be escaped, however, escaping that character is considered a best practice and is expected by some regex validators.
->
->
-
 If the regular expression matches, your rule replaces the **Access-Control-Allow-Origin** header (if any) from the origin with the origin that sent the request. You can also add extra CORS headers, such as **Access-Control-Allow-Methods**.
 
 ![Rules example with regular expression](./media/cdn-cors/cdn-cors-regex.png)
@@ -104,4 +91,3 @@ Rather than regular expressions, you can instead create a separate rule for each
 > [!TIP]
 > In the example, the use of the wildcard character * tells the rules engine to match both HTTP and HTTPS.
 >
->