Merge branch 'main' into roles-xref-toc

Author: yetanothertw

.github/CODEOWNERS

@@ -11,7 +11,7 @@
 /deploy-manage/                             @elastic/admin-docs
 /explore-analyze/                           @elastic/core-docs @elastic/experience-docs 
 /extend/                                    @elastic/core-docs
-/get-started/                               @elastic/core-docs
+/get-started/                               @elastic/core-docs @elastic/project-docs
 
 /manage-data/                               @elastic/admin-docs
 /manage-data/data-store/                    @elastic/admin-docs @elastic/developer-docs 
@@ -35,7 +35,7 @@
 /release-notes/                             @elastic/docs
 
 /release-notes/apm-agents/                  @elastic/ingest-docs
-/release-notes/elastic-cloud-serverless/    @elastic/admin-docs
+/release-notes/elastic-cloud-serverless/    @elastic/admin-docs @elastic/docs-serverless-release-team
 /release-notes/elastic-observability/       @elastic/ski-docs
 /release-notes/elastic-security/            @elastic/ski-docs
 /release-notes/elasticsearch-clients/       @elastic/developer-docs
@@ -44,9 +44,11 @@
 
 /solutions/                                 @elastic/experience-docs @elastic/developer-docs 
 /solutions/observability/                   @elastic/experience-docs
-/solutions/observability/get-started/       @elastic/ski-docs
+/solutions/observability/get-started/       @elastic/ski-docs @elastic/project-docs
 /solutions/search/                          @elastic/developer-docs
+/solutions/search/get-started/              @elastic/developer-docs @elastic/project-docs
 /solutions/security/                        @elastic/experience-docs
+/solutions/security/get-started             @elastic/experience-docs @elastic/project-docs
 
 /troubleshoot/                              @elastic/docs
 /troubleshoot/deployments/                  @elastic/admin-docs

.github/workflows/update-kube-stack-version.yml

@@ -0,0 +1,65 @@
+name: Update Kube-Stack Version
+
+on:
+  schedule:
+    # Run every Monday at 9:00 AM UTC
+    - cron: '0 9 * * 1'
+  workflow_dispatch: # Allow manual triggering
+
+jobs:
+  update-kube-stack-version:
+    runs-on: ubuntu-latest
+    
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v4
+      with:
+        token: ${{ secrets.GITHUB_TOKEN }}
+    
+    - name: Set up Python
+      uses: actions/setup-python@v4
+      with:
+        python-version: '3.9'
+    
+    - name: Run kube-stack version update script
+      run: |
+        cd scripts
+        python update_kube_stack_version.py
+    
+    - name: Check for changes
+      id: verify-changed-files
+      run: |
+        if [ -n "$(git status --porcelain)" ]; then
+          echo "changed=true" >> $GITHUB_OUTPUT
+        else
+          echo "changed=false" >> $GITHUB_OUTPUT
+        fi
+    
+    - name: Commit and push changes
+      if: steps.verify-changed-files.outputs.changed == 'true'
+      run: |
+        git config --local user.email "[email protected]"
+        git config --local user.name "GitHub Action"
+        git add docs/docset.yml
+        git commit -m "chore: update kube-stack version [skip ci]"
+        git push
+    
+    - name: Create Pull Request
+      if: steps.verify-changed-files.outputs.changed == 'true'
+      uses: peter-evans/create-pull-request@v5
+      with:
+        token: ${{ secrets.GITHUB_TOKEN }}
+        commit-message: "chore: update kube-stack version"
+        title: "chore: update kube-stack version"
+        body: |
+          This PR automatically updates the kube-stack version in `docs/docset.yml` based on the latest version from the elastic-agent repository.
+          
+          **Changes:**
+          - Updated kube-stack version in docset.yml
+          
+          This PR was created automatically by the weekly kube-stack version update workflow.
+        branch: update-kube-stack-version
+        delete-branch: true
+        labels: |
+          automated
+          documentation

cloud-account/multifactor-authentication.md

@@ -21,7 +21,11 @@ Multifactor authentication (MFA) is **mandatory** when you log in to {{ecloud}}
 You can no longer configure SMS as a multifactor authentication method. 
 ::::
 
-Elastic recommends that you enable multiple methods so that you can still access your account if you lose access to one method.
+::::{important} 
+
+For enhanced security, we recommend you configure at least two different authentication methods. This redundancy ensures that losing access to one method doesn't impair access to your {{ecloud}} account.
+
+::::
 
 If you use only a Google or Microsoft account to log in, then you can’t configure MFA in {{ecloud}}. You can check and manage your multifactor authentication options in your Google or Microsoft account security settings.
 

deploy-manage/api-keys.md

@@ -6,9 +6,10 @@ applies_to:
     ece: ga
     self: ga
   serverless: ga
+navigation_title: API keys
 ---
 
-# API keys
+# Elastic API keys
 
 API keys are security mechanisms used to authenticate and authorize access to your deployments and {{es}} resources. 
 

deploy-manage/cloud-organization/billing.md

@@ -20,11 +20,11 @@ Elastic charges a recurring fee for using our offerings on {{ecloud}}. In this s
 
 {{ecloud}} pricing and billing is based on your usage across a number of dimensions. These dimensions are different for {{ech}} deployments and {{serverless-full}} projects. Each {{serverless-full}} project type also has its own billing dimensions.
 
-* [{{ech}} deployments](/deploy-manage/cloud-organization/billing/cloud-hosted-deployment-billing-dimensions.md)
-* [{{serverless-full}}](/deploy-manage/cloud-organization/billing/serverless-project-billing-dimensions.md)
-  * [{{es}} projects](/deploy-manage/cloud-organization/billing/elasticsearch-billing-dimensions.md)
-  * [Elastic Observability projects](/deploy-manage/cloud-organization/billing/elastic-observability-billing-dimensions.md)
-  * [Elastic Security projects](/deploy-manage/cloud-organization/billing/security-billing-dimensions.md)
+* [](/deploy-manage/cloud-organization/billing/cloud-hosted-deployment-billing-dimensions.md)
+* [](/deploy-manage/cloud-organization/billing/serverless-project-billing-dimensions.md)
+  * [](/deploy-manage/cloud-organization/billing/elasticsearch-billing-dimensions.md)
+  * [](/deploy-manage/cloud-organization/billing/elastic-observability-billing-dimensions.md)
+  * [](/deploy-manage/cloud-organization/billing/security-billing-dimensions.md)
 
 For more information, you can also refer to our [{{ech}}](https://www.elastic.co/pricing) and [{{serverless-full}}](https://www.elastic.co/pricing/serverless-search) pricing pages.
 

deploy-manage/cloud-organization/billing/cloud-hosted-deployment-billing-dimensions.md

@@ -39,16 +39,19 @@ Data Transfer accounts for the volume of data (payload) going into, out of, and
 
 We meter and bill data transfer using three dimensions:
 
-1. Data in (free)
-:   *Data in* accounts for all of the traffic going into the deployment. It includes index requests with data payload, as well as queries sent to the deployment (although the byte size of the latter is typically much smaller).
+1. **Data in (free)**
+   
+   *Data in* accounts for all of the traffic going into the deployment. It includes index requests with data payload, as well as queries sent to the deployment (although the byte size of the latter is typically much smaller).
 
-2. Data out
-:   *Data out* accounts for all of the traffic coming out of the deployment. This includes search results, as well as monitoring data sent from the deployment. The same rate applies regardless of the destination of the data, whether to the internet, to another region, or to a cloud provider account in the same region. Data coming out of the deployment through AWS PrivateLink, GCP Private Service Connect, or Azure Private Link, is also considered *Data out*.
+2. **Data out**
+   
+   *Data out* accounts for all of the traffic coming out of the deployment. This includes search results, as well as monitoring data sent from the deployment. The same rate applies regardless of the destination of the data, whether to the internet, to another region, or to a cloud provider account in the same region. Data coming out of the deployment through AWS PrivateLink, GCP Private Service Connect, or Azure Private Link, is also considered *Data out*.
 
-3. Data inter-node
-:   *Data inter-node* accounts for all of the traffic sent between the components of the deployment. This includes the data sync between nodes of a cluster which is managed automatically by {{es}} cluster sharding. It also includes data related to search queries executed across multiple nodes of a cluster. Note that single-node {{es}} clusters typically have lower charges, but may still incur inter-node charges accounting for data exchanged with {{kib}} nodes or other nodes, such as machine learning or APM.
-
-We provide a free allowance of 100GB per month, which includes the sum of *data out* and *data inter-node*, across all deployments in the account. Once this threshold is passed, a charge is applied for any data transfer used in excess of the 100GB monthly free allowance.
+3. **Data inter-node**
+   
+   *Data inter-node* accounts for all of the traffic sent between the components of the deployment. This includes the data sync between nodes of a cluster which is managed automatically by {{es}} cluster sharding. It also includes data related to search queries executed across multiple nodes of a cluster. Note that single-node {{es}} clusters typically have lower charges, but may still incur inter-node charges accounting for data exchanged with {{kib}} nodes or other nodes, such as machine learning or APM.
+   
+   We provide a free allowance of 100GB per month, which includes the sum of *data out* and *data inter-node*, across all deployments in the account. Once this threshold is passed, a charge is applied for any data transfer used in excess of the 100GB monthly free allowance.
 
 ::::{note} 
 Data inter-node charges are currently waived for Azure deployments.
@@ -71,22 +74,24 @@ Storage costs are tied to the cost of storing the backup snapshots in the underl
 
 As is common with Cloud providers, we meter and bill snapshot storage using two dimensions:
 
-1. Storage size (GB/month)
-:   This is calculated by metering the storage space (GBs) occupied by all snapshots of all deployments tied to an account. The same unit price applies to all regions. To calculate the due charges, we meter the amount of storage on an hourly basis and produce an average size (in GB) for a given month. The average amount is then used to bill the account for the GB/month used within a billing cycle (a calendar month).
-
-    For example, if the storage used in April 2019 was 100GB for 10 days, and then 130GB for the remaining 20 days of the month, the average storage would be 120 GB/month, calculated as (100*10 + 130*20)/30.
-
-    We provide a free allowance of 100 GB/month to all accounts across all the account deployments. Any metered storage usage below that amount will not be billed. Whenever the 100 GB/month threshold is crossed, we bill for the storage used in excess of the 100GB/month free allowance.
-
-
-2. Storage API requests (1K Requests/month)
-:   These costs are calculated by counting the total number of calls to backup or restore snapshots made by all deployments associated with an account. Unlike storage size, this dimension is cumulative, summed up across the billing cycle, and is billed at a price of 1,000 requests.
-
-    We provide a free allowance of 100,000 API requests to all accounts each month across all the account deployments. Once this threshold is passed, we bill only for the use of API requests in excess of the free allowance.
-
-    ::::{note} 
-    A single snapshot operation does not equal a single API call. There could be thousands of API calls associated with a single snapshot operation, as different files are written, deleted, and modified. The price we list is per 1000 API calls, so a rate of $0.0018 for 1000 API calls would cost $1.80 for a million calls.
-    ::::
+1. **Storage size (GB/month)**
+   
+   This is calculated by metering the storage space (GBs) occupied by all snapshots of all deployments tied to an account. The same unit price applies to all regions. To calculate the due charges, we meter the amount of storage on an hourly basis and produce an average size (in GB) for a given month. The average amount is then used to bill the account for the GB/month used within a billing cycle (a calendar month).
+    
+   For example, if the storage used in April 2019 was 100GB for 10 days, and then 130GB for the remaining 20 days of the month, the average storage would be 120 GB/month, calculated as (100*10 + 130*20)/30.
+   
+   We provide a free allowance of 100 GB/month to all accounts across all the account deployments. Any metered storage usage below that amount will not be billed. Whenever the 100 GB/month threshold is crossed, we bill for the storage used in excess of the 100GB/month free allowance.
+
+
+2. **Storage API requests (1K Requests/month)**
+   
+   These costs are calculated by counting the total number of calls to backup or restore snapshots made by all deployments associated with an account. Unlike storage size, this dimension is cumulative, summed up across the billing cycle, and is billed at a price of 1,000 requests.
+   
+   We provide a free allowance of 100,000 API requests to all accounts each month across all the account deployments. Once this threshold is passed, we bill only for the use of API requests in excess of the free allowance.
+   
+   ::::{note} 
+   A single snapshot operation does not equal a single API call. There could be thousands of API calls associated with a single snapshot operation, as different files are written, deleted, and modified. The price we list is per 1000 API calls, so a rate of $0.0018 for 1000 API calls would cost $1.80 for a million calls.
+   ::::
 
 
 

deploy-manage/cloud-organization/billing/elastic-observability-billing-dimensions.md

@@ -1,5 +1,5 @@
 ---
-navigation_title: Elastic for Observability
+navigation_title: Observability projects
 mapped_pages:
   - https://www.elastic.co/guide/en/serverless/current/observability-billing.html
 applies_to:
@@ -8,7 +8,7 @@ products:
   - id: cloud-serverless
 ---
 
-# Elastic for Observability billing dimensions [observability-billing]
+# {{obs-serverless}} billing dimensions [observability-billing]
 
 {{obs-serverless}} projects provide you with all the capabilities of Elastic Observability to monitor critical applications. Projects are provided using a Software as a Service (SaaS) model, and pricing is entirely consumption-based. {{obs-serverless}} projects are available in the following tiers of carefully selected features to enable common observability operations:
 

deploy-manage/cloud-organization/billing/elasticsearch-billing-dimensions.md

@@ -1,5 +1,5 @@
 ---
-navigation_title: Elasticsearch
+navigation_title: Elasticsearch projects
 mapped_pages:
   - https://www.elastic.co/guide/en/serverless/current/elasticsearch-billing.html
 applies_to:
@@ -10,7 +10,7 @@ products:
 description: Learn about how costs for Elasticsearch Serverless projects are calculated, and strategies you can use to lower your costs.
 ---
 
-# {{es}} billing dimensions [elasticsearch-billing]
+# {{es-serverless}} billing dimensions [elasticsearch-billing]
 
 {{es-serverless}} projects are priced based on consumption of the underlying infrastructure that supports your use case with the performance characteristics you need.
 Measurements are in virtual compute units (VCUs).
@@ -48,7 +48,7 @@ You can control costs using the following strategies:
 * **Machine learning trained model autoscaling**: [Trained model autoscaling](/deploy-manage/autoscaling/trained-model-autoscaling.md) is always enabled and cannot be disabled, ensuring efficient resource usage, reduced costs, and optimal performance without manual configuration.
 
   Trained model deployments automatically scale down to zero allocations after 24 hours without any inference requests. When they scale up again, they remain active for 5 minutes before they can scale down. During these cooldown periods, you will continue to be billed for the active resources.
-* **Indexing strategies** Consider your indexing strategies and how they might impact overall VCU usage and costs.
+* **Indexing strategies**: Consider your indexing strategies and how they might impact overall VCU usage and costs.
   To ensure optimal performance and cost-effectiveness for your project, it's important to consider how you structure your data.
 
   Consolidate small indices for better efficiency.
@@ -59,3 +59,8 @@ You can control costs using the following strategies:
   Higher resource consumption can lead to higher costs and potentially impact the overall performance of your project.
 
   If your use case naturally generates many small, separate streams of data, the recommended approach is to implement a process to consolidate them into fewer, larger indices. This practice leads to more efficient resource utilization. By grouping your data into larger indices, you can ensure a more performant and cost-efficient experience with {{es-serverless}}.
+* **Project subtype or profile**: When you use the [API]({{cloud-serverless-apis}}operation/operation-createelasticsearchproject) to create projects, be aware that the `optimized_for` option affects the VCU allocation and costs.
+
+  The `general_purpose` option is suitable for most search use cases. For example, it is the right profile for full-text search, sparse vectors, and dense vectors that use compression such as BBQ. It is used by default when you create projects from the UI.
+
+  The `vector` option is recommended only for uncompressed dense vectors ([dense_vector](elasticsearch://reference/elasticsearch/mapping-reference/dense-vector.md) fields with `int4` or `int8` quantization strategies) and high dimensionality. Though the per VCU cost is the same for general purpose and vector profiles, the latter allocates more VCUs for searchable data. This leads to higher VCU consumption in order to improve the performance for uncompressed vector data.

deploy-manage/cloud-organization/billing/security-billing-dimensions.md

@@ -1,5 +1,5 @@
 ---
-navigation_title: Elastic for Security
+navigation_title: Security projects
 mapped_pages:
   - https://www.elastic.co/guide/en/serverless/current/security-billing.html
 applies_to:
@@ -8,7 +8,7 @@ products:
   - id: cloud-serverless
 ---
 
-# Elastic for Security billing dimensions [security-billing]
+# {{elastic-sec}} billing dimensions [security-billing]
 
 {{elastic-sec}} serverless projects provide you with all the capabilities of {{elastic-sec}} to perform SIEM, security analytics, endpoint security, and cloud security workflows. Projects are provided using a Software as a Service (SaaS) model, and pricing is entirely consumption based. Security Analytics/SIEM is available in two tiers of carefully selected features to enable common security operations:
 

deploy-manage/cloud-organization/billing/serverless-project-billing-dimensions.md

@@ -21,9 +21,9 @@ Specific prices can be found in the [Cloud Pricing Table](https://cloud.elastic.
 
 To learn about billing dimensions for specific offerings, refer to:
 
-* [{{es}} billing dimensions](elasticsearch-billing-dimensions.md)
-* [Elastic for Observability billing dimensions](elastic-observability-billing-dimensions.md)
-* [Elastic for Security dimensions](security-billing-dimensions.md)
+* [](elasticsearch-billing-dimensions.md)
+* [](elastic-observability-billing-dimensions.md)
+* [](security-billing-dimensions.md)
 
 
 ## Add-ons [add-ons]