Merge branch 'main' into autoops-regions-availability

Author: alaudazzi

README.md

@@ -6,7 +6,7 @@ This repo contains source files for Elastic documentation.
 
 ## Contribute
 
-If you find any bugs in our documentation, or want to request an enhancement, please [open an issue](https://github.com/elastic/docs-content/issues). We also welcome contributions in the form of PRs. Before you submit a PR, make sure that you have signed our [Contributor License Agreement](https://www.elastic.co/contributor-agreement/).
+If you find any bugs in our documentation, or want to request an enhancement, [open an issue](https://github.com/elastic/docs-content/issues). We also welcome contributions in the form of PRs. Before you submit a PR, make sure that you have signed our [Contributor License Agreement](https://www.elastic.co/contributor-agreement/).
 
 We write our docs in markdown. See our [syntax guide](https://elastic.github.io/docs-builder/syntax/index.html) for examples and additional functionality.
 

archive.md

@@ -1,6 +1,6 @@
 ---
 layout: archive
-description: Browse the archived documentation for older Elastic product releases. Archived documentation is unmaintained and may be out-of-date.
+description: Browse the archive for legacy Elastic products and documentation. Archive documentation is unmaintained and may be out-of-date.
 ---
 
 # Documentation archive

deploy-manage/_snippets/deployment-options-overview.md

@@ -1,12 +1,12 @@
 **Quick start options**
 
-* [**Elastic Cloud**](/deploy-manage/deploy/elastic-cloud.md): Get a hosted solution up and running in minutes.
-   * [**Elastic Cloud Hosted**](/deploy-manage/deploy/elastic-cloud/cloud-hosted.md): Our hosted Elastic Stack offering, deployed in the cloud with your provider of choice. Sign up for a [14-day free trial](https://cloud.elastic.co/registration).
-   * [**Elastic Cloud Serverless**](/deploy-manage/deploy/elastic-cloud/serverless.md): Create serverless projects for autoscaled and fully managed Elastic deployments. Sign up for a [14-day free trial](https://cloud.elastic.co/serverless-registration).
+* [**{{ecloud}}**](/deploy-manage/deploy/elastic-cloud.md): Get a hosted solution up and running in minutes.
+   * [**{{ech}}**](/deploy-manage/deploy/elastic-cloud/cloud-hosted.md): Our hosted {{stack}} offering, deployed in the cloud with your provider of choice. Sign up for a [14-day free trial](https://cloud.elastic.co/registration).
+   * [**{{serverless-full}}**](/deploy-manage/deploy/elastic-cloud/serverless.md): Create serverless projects for autoscaled and fully managed Elastic deployments. Sign up for a [14-day free trial](https://cloud.elastic.co/serverless-registration).
 * [**Local development**](/solutions/search/run-elasticsearch-locally.md): Get started quickly with {{es}} and {{kib}} in Docker for local development and testing.
 
 **Advanced options**
 
 * [**Self-managed**](/deploy-manage/deploy/self-managed.md): Install, configure, and run Elastic on your own premises.
-* [**Elastic Cloud Enterprise**](https://www.elastic.co/guide/en/cloud-enterprise/current/Elastic-Cloud-Enterprise-overview.html): Deploy Elastic Cloud on public or private clouds, virtual machines, or your own premises.
-* [**Elastic Cloud on Kubernetes**](/deploy-manage/deploy/cloud-on-k8s.md): Deploy Elastic Cloud on Kubernetes.
+* [**{{ece}}**](https://www.elastic.co/guide/en/cloud-enterprise/current/Elastic-Cloud-Enterprise-overview.html): Deploy {{ecloud}} on public or private clouds, virtual machines, or your own premises.
+* [**{{eck}}**](/deploy-manage/deploy/cloud-on-k8s.md): Deploy {{eck}}.

deploy-manage/_snippets/ecloud-security.md

@@ -0,0 +1,11 @@
+{{ecloud}} has built-in security. For example, HTTPS communications between {{ecloud}} and the internet, as well as inter-node communications, are secured automatically, and cluster data is encrypted at rest.
+
+In {{ech}}, you can augment these security features in the following ways:
+* Configure [traffic filtering](/deploy-manage/security/traffic-filtering.md) to prevent unauthorized access to your deployments.
+* Encrypt your deployment with a [customer-managed encryption key](/deploy-manage/security/encrypt-deployment-with-customer-managed-encryption-key.md).
+* [Secure your settings](/deploy-manage/security/secure-settings.md) using {{es}} and {{kib}} keystores.
+* Use the list of [{{ecloud}} static IPs](/deploy-manage/security/elastic-cloud-static-ips.md) to allow or restrict communications in your infrastructure.
+
+{{ech}} doesn't support custom SSL certificates, which means that a custom CNAME for an {{ech}} endpoint such as *mycluster.mycompanyname.com* also is not supported.
+
+Refer to [{{ecloud}} security](https://www.elastic.co/cloud/security) for more details about Elastic security and privacy programs.

deploy-manage/api-keys/elasticsearch-api-keys.md

@@ -9,9 +9,9 @@ mapped_pages:
 
 Several types of {{es}} API keys exist:
 
-* **Personal/User** API key: allows external services to access the Elastic Stack on behalf of a user.
+* **Personal/User** API key: allows external services to access the {{stack}} on behalf of a user.
 * **Cross-cluster** API key: allows other clusters to connect to this cluster.
-* **Managed** API key: created and managed by Kibana to run background tasks.
+* **Managed** API key: created and managed by {{kib}} to run background tasks.
 
 To manage API keys in {{kib}}, go to the **API Keys** management page using the navigation menu or the [global search field](../../explore-analyze/find-and-organize/find-apps-and-objects.md).
 

deploy-manage/autoscaling.md

@@ -23,7 +23,7 @@ By default, {{serverless-full}} automatically scales your {{es}} resources based
 This feature is designed for indirect use by {{ech}}, {{ece}}, and {{eck}}. Direct use is not supported.
 ::::
 
-Cluster autoscaling allows an operator to create tiers of nodes that monitor themselves and determine if scaling is needed based on an operator-defined policy. An Elasticsearch cluster can use the autoscaling API to report when additional resources are required. For example, an operator can define a policy that scales a warm tier based on available disk space. Elasticsearch monitors disk space in the warm tier. If it predicts low disk space for current and future shard copies, the autoscaling API reports that the cluster needs to scale. It remains the responsibility of the operator to add the additional resources that the cluster signals it requires.
+Cluster autoscaling allows an operator to create tiers of nodes that monitor themselves and determine if scaling is needed based on an operator-defined policy. An {{es}} cluster can use the autoscaling API to report when additional resources are required. For example, an operator can define a policy that scales a warm tier based on available disk space. {{es}} monitors disk space in the warm tier. If it predicts low disk space for current and future shard copies, the autoscaling API reports that the cluster needs to scale. It remains the responsibility of the operator to add the additional resources that the cluster signals it requires.
 
 A policy is composed of a list of roles and a list of deciders. The policy governs the nodes matching the roles. The deciders provide independent estimates of the capacity required. See [Autoscaling deciders](../deploy-manage/autoscaling/autoscaling-deciders.md) for details on available deciders.
 

deploy-manage/autoscaling/autoscaling-deciders.md

@@ -16,7 +16,7 @@ applies_to:
 
 # Autoscaling deciders [autoscaling-deciders]
 
-[Autoscaling](/deploy-manage/autoscaling.md) in Elasticsearch enables dynamic resource allocation based on predefined policies. A key component of this mechanism is autoscaling deciders, which independently assess resource requirements and determine when scaling actions are necessary. Deciders analyze various factors, such as storage usage, indexing rates, and machine learning workloads, to ensure clusters maintain optimal performance without manual intervention.
+[Autoscaling](/deploy-manage/autoscaling.md) in {{es}} enables dynamic resource allocation based on predefined policies. A key component of this mechanism is autoscaling deciders, which independently assess resource requirements and determine when scaling actions are necessary. Deciders analyze various factors, such as storage usage, indexing rates, and machine learning workloads, to ensure clusters maintain optimal performance without manual intervention.
 
 ::::{admonition} Indirect use only
 This feature is designed for indirect use by {{ech}}, {{ece}}, and {{eck}}. Direct use is not supported.
@@ -96,7 +96,7 @@ The [autoscaling](../../deploy-manage/autoscaling.md) frozen shards decider (`fr
 ### Configuration settings [autoscaling-frozen-shards-decider-settings]
 
 `memory_per_shard`
-:   (Optional, [byte value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) The memory needed per shard, in bytes. Defaults to 2000 shards per 64 GB node (roughly 32 MB per shard). Notice that this is total memory, not heap, assuming that the Elasticsearch default heap sizing mechanism is used and that nodes are not bigger than 64 GB.
+:   (Optional, [byte value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#byte-units)) The memory needed per shard, in bytes. Defaults to 2000 shards per 64 GB node (roughly 32 MB per shard). Notice that this is total memory, not heap, assuming that the {{es}} default heap sizing mechanism is used and that nodes are not bigger than 64 GB.
 
 ## Frozen storage decider [autoscaling-frozen-storage-decider]
 

deploy-manage/autoscaling/autoscaling-in-ece-and-ech.md

@@ -39,7 +39,7 @@ Currently, autoscaling behavior is as follows:
 
 * **Data tiers**
 
-    * Each Elasticsearch [data tier](../../manage-data/lifecycle/data-tiers.md) scales upward based on the amount of available storage. When we detect more storage is needed, autoscaling will scale up each data tier independently to ensure you can continue and ingest more data to your hot and content tier, or move data to the warm, cold, or frozen data tiers.
+    * Each {{es}} [data tier](../../manage-data/lifecycle/data-tiers.md) scales upward based on the amount of available storage. When we detect more storage is needed, autoscaling will scale up each data tier independently to ensure you can continue and ingest more data to your hot and content tier, or move data to the warm, cold, or frozen data tiers.
     * In addition to scaling up existing data tiers, a new data tier will be automatically added when necessary, based on your [index lifecycle management policies](https://www.elastic.co/guide/en/cloud-enterprise/current/ece-configure-index-management.html).
     * To control the maximum size of each data tier and ensure it will not scale above a certain size, you can use the maximum size per zone field.
     * Autoscaling based on memory or CPU, as well as autoscaling downward, is not currently supported. In case you want to adjust the size of your data tier to add more memory or CPU, or in case you deleted data and want to scale it down, you can set the current size per zone of each data tier manually.
@@ -53,7 +53,7 @@ Currently, autoscaling behavior is as follows:
     * The determination of when to scale is based on the expected memory and CPU requirements for the currently configured machine learning jobs and trained models.
 
 ::::{note}
-For any Elasticsearch component the number of availability zones is not affected by autoscaling. You can always set the number of availability zones manually and the autoscaling mechanism will add or remove capacity per availability zone.
+For any {{es}} component the number of availability zones is not affected by autoscaling. You can always set the number of availability zones manually and the autoscaling mechanism will add or remove capacity per availability zone.
 ::::
 
 ## When does autoscaling occur?[ec-autoscaling-factors]
@@ -81,7 +81,7 @@ In {{ece}} deployments, a warning is also issued in the ECE `service-constructor
 
 The following are known limitations and restrictions with autoscaling:
 
-* Autoscaling will not run if the cluster is unhealthy or if the last Elasticsearch plan failed.
+* Autoscaling will not run if the cluster is unhealthy or if the last {{es}} plan failed.
 
 In {{ech}} the following additional limitations apply:
 
@@ -129,12 +129,12 @@ Each autoscaling setting is configured with a default value. You can adjust thes
 
 % ECE NOTE
 ::::{note} - {{ece}}
-On Elastic Cloud Enterprise, system-owned deployment templates include the default values for all deployment autoscaling settings.
+On {{ece}}, system-owned deployment templates include the default values for all deployment autoscaling settings.
 ::::
 
 ## Autoscaling example [ec-autoscaling-example]
 
-To help you better understand the available autoscaling settings, this example describes a typical autoscaling workflow on sample Elastic Cloud Enterprise or {{ech}} deployment.
+To help you better understand the available autoscaling settings, this example describes a typical autoscaling workflow on sample {{ece}} or {{ech}} deployment.
 
 1. Enable autoscaling:
 
@@ -145,14 +145,13 @@ To help you better understand the available autoscaling settings, this example d
 
 2. View and adjust autoscaling settings on data tiers:
 
-    1. Open the **Edit** page for your deployment to get the current and maximum size per zone of each Elasticsearch data tier. In this example, the hot data and content tier has the following settings:
+    1. Open the **Edit** page for your deployment to get the current and maximum size per zone of each {{es}} data tier. In this example, the hot data and content tier has the following settings:
 
-        |     |     |     |
-        | --- | --- | --- |
-        | **Current size per zone** | **Maximum size per zone** |  |
-        | 45GB storage | 1.41TB storage |  |
-        | 1GB RAM | 32GB RAM |  |
-        | Up to 2.5 vCPU | 5 vCPU |  |
+        | Current size per zone | Maximum size per zone |
+        | --- | --- |
+        | 45GB storage | 1.41TB storage |
+        | 1GB RAM | 32GB RAM |
+        | Up to 2.5 vCPU | 5 vCPU |
 
         The fault tolerance for the data tier is set to 2 availability zones.
 
@@ -166,11 +165,10 @@ To help you better understand the available autoscaling settings, this example d
 
     1. From the deployment **Edit** page you can check the minimum and maximum size of your deployment’s machine learning instances. In this example, the machine learning instance has the following settings:
 
-        |     |     |     |
-        | --- | --- | --- |
-        | **Minimum size per zone** | **Maximum size per zone** |  |
-        | 1GB RAM | 64GB RAM |  |
-        | 0.5 vCPU up to 8 vCPU | 32 vCPU |  |
+        | Minimum size per zone | Maximum size per zone |
+        | --- | --- |
+        | 1GB RAM | 64GB RAM |
+        | 0.5 vCPU up to 8 vCPU | 32 vCPU |
 
         The fault tolerance for the machine learning instance is set to 1 availability zone.
 
@@ -197,8 +195,8 @@ To learn more about the {{ece}} API, see the [RESTful API](cloud://reference/clo
 
 Note the following requirements when you run this API request:
 
-* All Elasticsearch components must be included in the request, even if they are not enabled (that is, if they have a zero size). All components are included in this example.
-* The request requires a format that supports data tiers. Specifically, all Elasticsearch components must contain the following properties:
+* All {{es}} components must be included in the request, even if they are not enabled (that is, if they have a zero size). All components are included in this example.
+* The request requires a format that supports data tiers. Specifically, all {{es}} components must contain the following properties:
 
     * `id`
     * `node_attributes`
@@ -218,7 +216,7 @@ $$$ece-autoscaling-api-example-requirements-table$$$
 | data tier | ✓ | ✕ | ✓ |
 | machine learning node | ✕ | ✓ | ✓ |
 | coordinating and master nodes | ✓ | ✕ | ✕ |
-| Kibana | ✓ | ✕ | ✕ |
+| {{kib}} | ✓ | ✕ | ✕ |
 | APM | ✓ | ✕ | ✕ |
 
 * ✓ = Include the property.