Update hot frozen reference architecture to include deployment applies to statements (#367)

* Update hotfrozen-high-availability.md

* adding eck

* Update links

* Update reference-architectures.md

* Update reference-architectures.md

* Update reference-architectures.md

* Update deploy-manage/reference-architectures/hotfrozen-high-availability.md

Co-authored-by: shainaraskas <[email protected]>

* Update reference-architectures.md

* Update reference-architectures.md

* Update reference-architectures.md

* Update reference-architectures.md

* Update deploy-manage/reference-architectures.md

Co-authored-by: shainaraskas <[email protected]>

* Update deploy-manage/reference-architectures.md

Co-authored-by: shainaraskas <[email protected]>

* Update reference-architectures.md

* Fixing brackets

---------

Co-authored-by: shainaraskas <[email protected]>

Author: georgewallace

deploy-manage/reference-architectures.md

@@ -1,6 +1,11 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/reference-architectures/current/reference-architectures-overview.html
+applies:
+  stack: all
+  hosted: all
+  ece: all
+  eck: all
 ---
 
 # Reference architectures [reference-architectures-overview]
@@ -9,19 +14,20 @@ Elasticsearch reference architectures are blueprints for deploying Elasticsearch
 
 These architectures are designed by architects and engineers to provide standardized, proven solutions that help you to follow best practices when deploying {{es}}.
 
-::::{tip}
-These architectures are specific to running your deployment on-premises or on cloud. If you are using Elastic serverless your {{es}} clusters are autoscaled and fully managed by Elastic. For all the deployment options, refer to [Run Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/elasticsearch-intro-deploy.html).
+::::{tip} 
+These architectures are specific to deploying Elastic on {{ech}}, {{eck}}, {{ece}}, or deploying a self-managed instance. If you are using {{serverless-full}}, your {{es}} clusters are autoscaled and fully managed by Elastic. To learn about all of the deployment options, refer to the [Deploy and manage overview](/deploy-manage/index.md).
 ::::
 
 
-These reference architectures are recommendations and should be adapted to fit your specific environment and needs. Each solution can vary based on the unique requirements and conditions of your deployment. In these architectures we discuss about how to deploy cluster components. For information about designing ingest architectures to feed content into your cluster, refer to [Ingest architectures](https://www.elastic.co/guide/en/ingest/current/use-case-arch.html)
+These reference architectures are recommendations and should be adapted to fit your specific environment and needs. Each solution can vary based on the unique requirements and conditions of your deployment. In these architectures we discuss about how to deploy cluster components. For information about designing ingest architectures to feed content into your cluster, refer to [Ingest architectures](../manage-data/ingest/ingest-reference-architectures/use-case-arch.md)
 
-
-## Architectures [reference-architectures-time-series-2]
+## Architectures [reference-architectures-time-series] 
 
 |     |     |
 | --- | --- |
 | **Architecture** | **When to use** |
-| [*Hot/Frozen - High Availability*](https://www.elastic.co/guide/en/reference-architectures/current/hot-frozen-architecture.html)<br>A high availability architecture that is cost optimized for large time-series datasets. | * Have a requirement for cost effective long term data storage (many months or years).<br>* Provide insights and alerts using logs, metrics, traces, or various event types to ensure optimal performance and quick issue resolution for applications.<br>* Apply Machine Learning and Search AI to assist in dealing with the large amount of data.<br>* Deploy an architecture model that allows for maximum flexibility between storage cost and performance.<br> |
+| [*Hot/Frozen - High Availability*](/deploy-manage/reference-architectures/hotfrozen-high-availability.md)<br>A high availability architecture that is cost optimized for large time-series datasets. | * Have a requirement for cost effective long term data storage (many months or years).<br>* Provide insights and alerts using logs, metrics, traces, or various event types to ensure optimal performance and quick issue resolution for applications.<br>* Apply Machine Learning and Search AI to assist in dealing with the large amount of data.<br>* Deploy an architecture model that allows for maximum flexibility between storage cost and performance.<br> |
 | Additional architectures are on the way.<br>Stay tuned for updates. |  |
 
+
+

deploy-manage/reference-architectures/hotfrozen-high-availability.md

@@ -1,6 +1,11 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/reference-architectures/current/hot-frozen-architecture.html
+applies:
+  stack: all
+  hosted: all
+  ece: all
+  eck: all
 ---
 
 # Hot/Frozen - High Availability [hot-frozen-architecture]
@@ -50,15 +55,15 @@ Machine learning nodes are optional but highly recommended for large scale time
 
 ## Recommended hardware specifications [hot-frozen-hardware]
 
-With {{ecloud}} you can deploy clusters in AWS, Azure, and Google Cloud.  Available hardware types and configurations vary across all three cloud providers but each provides instance types that meet our recommendations for the node types used in this architecture. For more details on these instance types, see our documentation on {{ecloud}} hardware for [AWS](https://www.elastic.co/guide/en/cloud/current/ec-default-aws-configurations.html), [Azure](https://www.elastic.co/guide/en/cloud/current/ec-default-azure-configurations.html), and [GCP](https://www.elastic.co/guide/en/cloud/current/ec-default-gcp-configurations.html). The **Physical** column below is guidance, based on the cloud node types, when self-deploying {{es}} in your own data center.
+With {{ech}}, you can deploy clusters in AWS, Azure, and Google Cloud. Available hardware types and configurations vary across all three cloud providers but each provides instance types that meet our recommendations for the node types used in this architecture. For more details on these instance types, see our documentation on {{ech}} hardware for [AWS](https://www.elastic.co/guide/en/cloud/current/ec-default-aws-configurations.html), [Azure](https://www.elastic.co/guide/en/cloud/current/ec-default-azure-configurations.html), and [GCP](https://www.elastic.co/guide/en/cloud/current/ec-default-gcp-configurations.html). The **Physical** column below is guidance, based on the cloud node types, when self-deploying {{es}} in your own data center.
 
-In the links provided above, Elastic has performance tested hardware for each of the cloud providers to find the optimal hardware for each node type. We use ratios to represent the best mix of CPU, RAM, and disk for each type.   In some cases the CPU to RAM ratio is key, in others the disk to memory ratio and type of disk is critical. Significantly deviating from these ratios may seem like a way to save on hardware costs, but may result in an {{es}} cluster that does not scale and perform well.
+In the links provided above, Elastic has performance tested hardware for each of the cloud providers to find the optimal hardware for each node type. We use ratios to represent the best mix of CPU, RAM, and disk for each type. In some cases the CPU to RAM ratio is key, in others the disk to memory ratio and type of disk is critical. Significantly deviating from these ratios may seem like a way to save on hardware costs, but may result in an {{es}} cluster that does not scale and perform well.
 
 This table shows our specific recommendations for nodes in a Hot/Frozen architecture.
 
 |     |     |     |     |     |
 | --- | --- | --- | --- | --- |
-| **Type** | **AWS*** | ***Azure*** | ***GCP** | **Physical** |
+| **Type** | **AWS** | **Azure** | **GCP** | **Physical** |
 | ![Hot data node](../../images/reference-architectures-hot.png "") | c6gd | f32sv2 | N2 | 16-32 vCPU<br>64 GB RAM<br>2-6 TB NVMe SSD |
 | ![Frozen data node](../../images/reference-architectures-frozen.png "") | i3en | e8dsv4 | N2 | 8 vCPU<br>64 GB RAM<br>6-20+ TB NVMe SSD<br>Depending on days cached |
 | ![Machine learning node](../../images/reference-architectures-machine-learning.png "") | m6gd | f16sv2 | N2 | 16 vCPU<br>64 GB RAM<br>256 GB SSD |
@@ -82,7 +87,7 @@ This table shows our specific recommendations for nodes in a Hot/Frozen architec
 
 **Snapshots:**
 
-* If auditable or business critical events are being logged, a backup is necessary.  The choice to back up data will depend on each individual business’s needs and requirements. Refer to our [snapshot repository](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-register-repository.html) documentation to learn more.
+* If auditable or business critical events are being logged, a backup is necessary. The choice to back up data will depend on each individual business’s needs and requirements. Refer to our [snapshot repository](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-register-repository.html) documentation to learn more.
 * To automate snapshots and attach to Index lifecycle management policies, refer to [SLM (Snapshot lifecycle management)](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-take-snapshot.html#automate-snapshots-slm).
 
 **Kibana:**