production guidance content refined

Author: eedugon

deploy-manage/deploy/elastic-cloud/cloud-hosted.md

@@ -106,7 +106,7 @@ Of course, you can choose to follow your own path and use Elastic components ava
 
 **Adjust the capacity and capabilities of your deployments for production**
 
-There are a few things that can help you make sure that your production deployments remain available, healthy, and ready to handle your data in a scalable way over time, with the expected level of performance. Check [](/deploy-manage/production-guidance/plan-for-production-elastic-cloud.md).
+There are a few things that can help you make sure that your production deployments remain available, healthy, and ready to handle your data in a scalable way over time, with the expected level of performance. Check [](/deploy-manage/production-guidance.md).
 
 **Secure your environment**
 

deploy-manage/deploy/elastic-cloud/create-an-elastic-cloud-hosted-deployment.md

@@ -65,7 +65,7 @@ You can also create a deployment using the [Elastic Cloud API](https://www.elast
 
 To make sure you’re all set for production, consider the following actions:
 
-* [Plan for your expected workloads](/deploy-manage/production-guidance/plan-for-production-elastic-cloud.md) and consider how many availability zones you’ll need.
+* [Plan for your expected workloads](/deploy-manage/production-guidance.md) and consider how many availability zones you’ll need.
 * [Create a deployment](/deploy-manage/deploy/elastic-cloud/create-an-elastic-cloud-hosted-deployment.md) on the region you need and with a hardware profile that matches your use case.
 * [Change your configuration](/deploy-manage/deploy/elastic-cloud/ec-customize-deployment-components.md) by turning on autoscaling, adding high availability, or adjusting components of the Elastic Stack.
 * [Add extensions and plugins](/deploy-manage/deploy/elastic-cloud/add-plugins-extensions.md) to use Elastic supported extensions or add your own custom dictionaries and scripts.

deploy-manage/deploy/kibana-reporting-configuration.md

@@ -28,4 +28,4 @@ $$$grant-user-access$$$
 The documentation team is working to combine content pulled from the following pages:
 
 * [/raw-migrated-files/kibana/kibana/secure-reporting.md](/raw-migrated-files/kibana/kibana/secure-reporting.md)
-* [/raw-migrated-files/kibana/kibana/reporting-production-considerations.md](/raw-migrated-files/kibana/kibana/reporting-production-considerations.md)
+* [/raw-migrated-files/kibana/kibana/reporting-production-considerations.md](/deploy-manage/production-guidance/kibana-reporting-production-considerations.md)

deploy-manage/production-guidance.md

@@ -10,12 +10,6 @@ applies_to:
     eck: all
     self: all
 ---
-$$$ec-best-practices-data$$$
-
-% start bringing https://www.elastic.co/guide/en/elasticsearch/reference/current/scalability.html here
-
-% try to merge https://www.elastic.co/guide/en/cloud/current/ec-planning.html and https://www.elastic.co/guide/en/cloud/current/ec-best-practices-data.html
-% mention all deployment types! what the user needs to be aware for orchestrated deployments.
 
 # Production guidance
 
@@ -35,24 +29,27 @@ By following this guidance, you can ensure your {{stack}} deployment is robust,
 
 ## Deployment types
 
-Production guidelines described in this section apply to all [deployment types](/deploy-manage/deploy.md#choosing-your-deployment-type)-including {{ech}}, {{ece}}, {{eck}}, and self-managed clusters-**except** {{serverless-full}}. However, certain parts may be relevant only to self-managed clusters, as orchestration systems automate some of the configurations discussed here.
+Production guidelines and concepts described in this section apply to all [deployment types](/deploy-manage/deploy.md#choosing-your-deployment-type)-including {{ech}}, {{ece}}, {{eck}}, and self-managed clusters-**except** {{serverless-full}}.
 
-Check the headers of each document or section to confirm whether the content applies to your deployment type.
+However, certain parts may be relevant only to self-managed clusters, as orchestration systems automate some of the configurations discussed here. Check the headers of each document or section to confirm whether the content applies to your deployment type.
 
 ::::{note}
-**{{serverless-full}}** projects are fully managed and automatically scaled by Elastic. Your project’s performance and general data retention are controlled by the [Search AI Lake settings](/deploy/elastic-cloud/project-settings.md#elasticsearch-manage-project-search-ai-lake-settings).
+**{{serverless-full}}** projects are fully managed and automatically scaled by Elastic. Your project’s performance and general data retention are controlled by the [Search AI Lake settings](/deploy-manage/deploy/elastic-cloud/project-settings.md#elasticsearch-manage-project-search-ai-lake-settings).
 ::::
 
 ## Section overview
 
+This section is divided into {{es}} and {{kib}} production-ready concepts and best practices.
+
 **{{es}}**
 
 * [](./production-guidance/getting-ready-for-production-elasticsearch.md)
   * [](./production-guidance/availability-and-resilience.md)
     * [](./production-guidance/availability-and-resilience/resilience-in-small-clusters.md)
     * [](./production-guidance/availability-and-resilience/resilience-in-larger-clusters.md)
+    * [](./production-guidance/availability-and-resilience/resilience-in-ech.md)
+  * [](./production-guidance/scaling-considerations.md)
   * [](./production-guidance/optimize-performance.md)
-  * [Scaling considerations](./production-guidance/plan-for-production-elastic-cloud.md)
 
 **{{kib}}**
 
@@ -61,10 +58,6 @@ Check the headers of each document or section to confirm whether the content app
     * [](./production-guidance/kibana-alerting-production-considerations.md)
     * [](./production-guidance/kibana-reporting-production-considerations.md)
 
-
-
-
-
 ## Other sections
 
 Other sections of the documentation provide important guidance for running {{stack}} applications in production.
@@ -85,7 +78,7 @@ Other sections of the documentation provide important guidance for running {{sta
 
 ### Security and monitoring [security-and-monitoring] 
 
-As with any enterprise system, you need tools to secure, manage, and monitor your deployments. Security, monitoring, and administrative features that are integrated into {{es}} enable you to use [Kibana](../../get-started/the-stack.md) as a control center for managing a cluster.
+As with any enterprise system, you need tools to secure, manage, and monitor your deployments. Security, monitoring, and administrative features that are integrated into {{es}} enable you to use [Kibana](/get-started/the-stack.md) as a control center for managing a cluster.
 
 [Learn about securing an {{es}} cluster](./security.md).
 

deploy-manage/production-guidance/availability-and-resilience.md

@@ -1,12 +1,29 @@
 ---
+navigation_title: Design for resilience
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/high-availability-cluster-design.html
+applies_to:
+  deployment:
+    ess: all
+    ece: all
+    eck: all
+    self: all
 ---
 
-# Availability and resilience [high-availability-cluster-design]
+# Design for resilience [high-availability-cluster-design]
 
 Distributed systems like {{es}} are designed to keep working even if some of their components have failed. As long as there are enough well-connected nodes to take over their responsibilities, an {{es}} cluster can continue operating normally if some of its nodes are unavailable or disconnected.
 
+{{es}} implements high availability at three key levels:
+
+* Node level – Running multiple nodes within the cluster to avoid single points of failure and maintain operational stability.
+* Cluster level – Ensuring redundancy by distributing nodes across availability zones to prevent failures from affecting the entire cluster.
+* Index level – Configuring shard replication to protect against data loss and improve search performance by distributing queries across multiple copies.
+
+Each of these HA mechanisms contributes to {{es}}’s resilience and scalability. The appropriate strategy depends on factors such as data criticality, query patterns, and infrastructure constraints. It is up to you to determine the level of resiliency and high availability that best fits your use case. This sections provides detailed guidance on designing a production-ready {{es}} deployment that balances availability, performance, and scalability.
+
+## Cluster sizes
+
 There is a limit to how small a resilient cluster can be. All {{es}} clusters require the following components to function:
 
 * One [elected master node](../distributed-architecture/discovery-cluster-formation/modules-discovery-quorums.md)
@@ -31,6 +48,4 @@ Depending on your needs and budget, an {{es}} cluster can consist of a single no
 
 * [Resilience in small clusters](availability-and-resilience/resilience-in-small-clusters.md)
 * [Resilience in larger clusters](availability-and-resilience/resilience-in-larger-clusters.md)
-
-
-
+* [Resilience in {{ech}} deployments](./availability-and-resilience/resiliente-in-ech.md)

deploy-manage/production-guidance/availability-and-resilience/resilience-in-ech.md

@@ -0,0 +1,45 @@
+---
+navigation_title: Resilience in Elastic Cloud Hosted deployments
+applies_to:
+  deployment:
+    ess: all
+---
+
+# Resiliency in Elastic Cloud Hosted deployments [ec-ha] 
+
+With {{ech}}, your deployment can be spread across up to three separate availability zones, each hosted in an isolated infrastructure domain, such as separate data centers in the case of {{ech}}.
+
+::::{note}
+While this document focuses on {{ech}}, the concepts also apply to {{ece}} and {{eck}} deployments. In ECK, you will have to manually configure [availability zone distribution and node scheduling](/deploy-manage/deploy/cloud-on-k8s/advanced-elasticsearch-node-scheduling.md) through your Kubernetes platform.
+::::
+
+Why this matters:
+
+* Data centers can have issues with availability. Internet outages, earthquakes, floods, or other events could affect the availability of a single data center. With a single availability zone, you have a single point of failure that can bring down your deployment.
+* Multiple availability zones help your deployment remain available. This includes your {{es}} cluster, provided that your cluster is sized so that it can sustain your workload on the remaining data centers and that your indices are configured to have at least one replica.
+* Multiple availability zones enable you to perform changes to resize your deployment with zero downtime.
+
+### Recommendations
+
+We recommend that you use at least two availability zones for production and three for mission-critical systems. Just one zone might be sufficient, if your {{es}} cluster is mainly used for testing or development and downtime is acceptable, but should never be used for production.
+
+With multiple {{es}} nodes in multiple availability zones you have the recommended hardware, the next thing to consider is having the recommended index replication. Each index, with the exception of searchable snapshot indexes, should have one or more replicas. Use the index settings API to find any indices with no replica:
+
+```sh
+GET _all/_settings/index.number_of_replicas
+```
+
+Moreover, a high availability (HA) cluster requires at least three master-eligible nodes. For clusters that have fewer than six {{es}} nodes, any data node in the hot tier will also be a master-eligible node. You can achieve this by having hot nodes (serving as both data and master-eligible nodes) in three availability zones, or by having data nodes in two zones and a tiebreaker (will be automatically added if you choose two zones). For clusters that have six {{es}} nodes and beyond, dedicated master-eligible nodes are introduced. When your cluster grows, consider separating dedicated master-eligible nodes from dedicated data nodes. We recommend using at least 4GB RAM for dedicated master nodes.
+
+The data in your {{es}} clusters is also backed up every 30 minutes, 4 hours, or 24 hours, depending on which snapshot interval you choose. These regular intervals provide an extra level of redundancy. We do support [snapshot and restore](../../../deploy-manage/tools/snapshot-and-restore.md), regardless of whether you use one, two, or three availability zones. However, with only a single availability zone and in the event of an outage, it might take a while for your cluster come back online. Using a single availability zone also leaves your cluster exposed to the risk of data loss, if the backups you need are not useable (failed or partial snapshots missing the indices to restore) or no longer available by the time that you realize that you might need the data (snapshots have a retention policy).
+
+### Important considerations
+
+::::{warning} 
+* Clusters that use only one availability zone are not highly available and are at risk of data loss. To safeguard against data loss, you must use at least two availability zones.
+* Indices with no replica, except for searchable snapshot indices, are not highly available. You should use replicas to mitigate against possible data loss.
+* Clusters that only have one master node are not highly available and are at risk of data loss. You must have three master-eligible nodes.
+::::
+
+
+

deploy-manage/production-guidance/availability-and-resilience/resilience-in-larger-clusters.md

@@ -1,6 +1,12 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/high-availability-cluster-design-large-clusters.html
+applies_to:
+  deployment:
+    ess: all
+    ece: all
+    eck: all
+    self: all
 ---
 
 # Resilience in larger clusters [high-availability-cluster-design-large-clusters]

deploy-manage/production-guidance/availability-and-resilience/resilience-in-small-clusters.md

@@ -1,6 +1,12 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/high-availability-cluster-small-clusters.html
+applies_to:
+  deployment:
+    ess: all
+    ece: all
+    eck: all
+    self: all
 ---
 
 # Resilience in small clusters [high-availability-cluster-small-clusters]

deploy-manage/production-guidance/general-recommendations.md

@@ -1,6 +1,12 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/general-recommendations.html
+applies_to:
+  deployment:
+    ess: all
+    ece: all
+    eck: all
+    self: all
 ---
 
 # General recommendations [general-recommendations]

deploy-manage/production-guidance/getting-ready-for-production-elasticsearch.md

@@ -1,19 +1,25 @@
 ---
+navigation_title: Run Elasticsearch in production
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/scalability.html
+applies_to:
+  deployment:
+    ess: all
+    ece: all
+    eck: all
+    self: all
 ---
 
-# Getting ready for production (Elasticsearch) [scalability]
+# Getting ready for production [scalability]
 
-Many teams rely on {{es}} to run their key services. To keep these services running, you can design your {{es}} deployment to keep {{es}} available, even in case of large-scale outages. To keep it running fast, you also can design your deployment to be responsive to production workloads.
+Many teams rely on {{es}} to run their key services. To keep these services running, you can [design your {{es}} deployment for resilience](./availability-and-resilience.md), to keep {{es}} available even in case of large-scale outages. To keep it running fast, you can also design your deployment with [performance optimizations](./optimize-performance.md) that make it responsive to production workloads.
 
-{{es}} is built to be always available and to scale with your needs. It does this using a distributed architecture. By distributing your cluster, you can keep Elastic online and responsive to requests.
+{{es}} is built to be always available and to scale with your needs. It does this using a [distributed architecture](/deploy-manage/distributed-architecture.md). By distributing your cluster, you can keep Elastic online and responsive to requests.
 
-In case of failure, {{es}} offers tools for cross-cluster replication and cluster snapshots that can help you fall back or recover quickly. You can also use cross-cluster replication to serve requests based on the geographic location of your users and your resources.
+In case of failure, {{es}} offers tools for [cross-cluster replication](../tools/cross-cluster-replication.md) and [cluster snapshots](../tools/snapshot-and-restore.md) that can help you fall back or recover quickly. You can also use cross-cluster replication to serve requests based on the geographic location of your users and your resources.
 
 {{es}} also offers security and monitoring tools to help you keep your cluster highly available.
 
-
 ## Use multiple nodes and shards [use-multiple-nodes-shards] 
 
 When you move to production, you need to introduce multiple nodes and shards to your cluster. Nodes and shards are what make {{es}} distributed and scalable. The size and number of these nodes and shards depends on your data, your use case, and your budget.
@@ -37,34 +43,21 @@ CCR provides a way to automatically synchronize indices from your primary cluste
 
 You can also use CCR to create secondary clusters to serve read requests in geo-proximity to your users.
 
-Learn more about [cross-cluster replication](../tools/cross-cluster-replication.md) and about [designing for resilience](availability-and-resilience.md).
+Learn more about [cross-cluster replication](../tools/cross-cluster-replication.md) and about [designing for resilience](./availability-and-resilience.md).
 
 ::::{tip} 
 You can also take [snapshots](../tools/snapshot-and-restore.md) of your cluster that can be restored in case of failure.
-
 ::::
 
-
-
-## Security and monitoring [security-and-monitoring] 
-
-As with any enterprise system, you need tools to secure, manage, and monitor your {{es}} clusters. Security, monitoring, and administrative features that are integrated into {{es}} enable you to use [Kibana](../../get-started/the-stack.md) as a control center for managing a cluster.
-
-[Learn about securing an {{es}} cluster](../security.md).
-
-[Learn about monitoring your cluster](../monitor.md).
-
-
-## Cluster design [cluster-design] 
-% moved to landing page.
+## Cluster design and performance optimizations [cluster-design] 
 
 {{es}} offers many options that allow you to configure your cluster to meet your organization’s goals, requirements, and restrictions. You can review the following guides to learn how to tune your cluster to meet your needs:
 
-* [Designing for resilience](availability-and-resilience.md)
-* [Tune for indexing speed](optimize-performance/indexing-speed.md)
-* [Tune for search speed](optimize-performance/search-speed.md)
-* [Tune for disk usage](optimize-performance/disk-usage.md)
-* [Tune for time series data](../../manage-data/use-case-use-elasticsearch-to-manage-time-series-data.md)
+::::{note}
+In orchestrated deployments, some of the settings mentioned in the referenced documents may not apply. Check the section headers to determine whether a topic is relevant to your deployment type.
+::::
 
-Many {{es}} options come with different performance considerations and trade-offs. The best way to determine the optimal configuration for your use case is through [testing with your own data and queries](https://www.elastic.co/elasticon/conf/2016/sf/quantitative-cluster-sizing).
+* [Designing for resilience](./availability-and-resilience.md)
+* [Performance optimizations](./optimize-performance.md) 
 
+Many {{es}} options come with different performance considerations and trade-offs. The best way to determine the optimal configuration for your use case is through [testing with your own data and queries](https://www.elastic.co/elasticon/conf/2016/sf/quantitative-cluster-sizing).