Moving Cloud to first-class in nav (#4116)

* Moving Cloud to first-class in nav

* fix(service health): fixed broken links

---------

Co-authored-by: flippedcoder <milecia.mcgregor@aol.com>

Author: brianmacdonald-temporal

COMPONENTS.md

@@ -216,10 +216,10 @@ Usage:
   <RelatedReadItem path="/cloud/metrics/prometheus-grafana"
     text="How to set up Grafana with Temporal Cloud observability"
     archetype="feature-guide" />
-  <RelatedReadItem path="/production-deployment/cloud/worker-health"
+  <RelatedReadItem path="/cloud/worker-health"
     text="How to monitor Worker Health with Temporal Cloud Metrics"
     archetype="feature-guide" />
-  <RelatedReadItem path="/production-deployment/cloud/service-health"
+  <RelatedReadItem path="/cloud/service-health"
     text="How to monitor Service Health with Temporal Cloud Metrics"
     archetype="feature-guide" />
 </RelatedReadContainer>

docs/best-practices/cloud-access-control.mdx

@@ -48,11 +48,11 @@ One convention is to give certificates a common name that matches the namespace.
 ## Best practices: 
 #### 1. Establish clear guidelines on authentication methods: Teams should standardize on either [mTLS certificates](https://docs.temporal.io/cloud/certificates) or [API keys](https://docs.temporal.io/cloud/api-keys) for the following operations:
 - Connect Temporal clients to Temporal Cloud (e.g. Worker processes)
-- Automation (e.g. Temporal Cloud [Operations API](https://docs.temporal.io/ops), [Terraform provider](https://docs.temporal.io/production-deployment/cloud/terraform-provider), [Temporal CLI](https://docs.temporal.io/cli/setup-cli))
+- Automation (e.g. Temporal Cloud [Operations API](https://docs.temporal.io/ops), [Terraform provider](https://docs.temporal.io/cloud/terraform-provider), [Temporal CLI](https://docs.temporal.io/cli/setup-cli))
 
     By default, it is recommended for teams to use API keys and [service accounts](https://docs.temporal.io/cloud/service-accounts) for both operations because API keys are easier to manage and rotate for most teams. In addition, you can control account-level and namespace-level roles for service accounts. 
 
-    If your organization requires mutual authentication and stronger cryptographic guarantees, then it is encouraged for your teams to use mTLS certificates to authenticate Temporal clients to Temporal Cloud and use API keys for automation (because Temporal Cloud [Operations API](https://docs.temporal.io/ops) and [Terraform provider](https://docs.temporal.io/production-deployment/cloud/terraform-provider) only supports API key for authentication)
+    If your organization requires mutual authentication and stronger cryptographic guarantees, then it is encouraged for your teams to use mTLS certificates to authenticate Temporal clients to Temporal Cloud and use API keys for automation (because Temporal Cloud [Operations API](https://docs.temporal.io/ops) and [Terraform provider](https://docs.temporal.io/cloud/terraform-provider) only supports API key for authentication)
 
 #### 2. Use Certificate Filters to restrict access when using shared CAs (e.g., `dev` vs `prod`):
 

docs/best-practices/managing-aps-limits.mdx

@@ -218,7 +218,7 @@ See [Capacity Modes Pricing](/cloud/pricing#capacity-modes-pricing) for billing
 
 Since you understand your workload patterns better than any auto-scaling system, consider building your own TRU automation:
 
-- **Use the [Cloud Ops API](/ops), [Terraform Provider](/production-deployment/cloud/terraform-provider), or [tcld CLI](/cloud/tcld)** to programmatically scale capacity based on your application's signals
+- **Use the [Cloud Ops API](/ops), [Terraform Provider](/cloud/terraform-provider), or [tcld CLI](/cloud/tcld)** to programmatically scale capacity based on your application's signals
 - **Set utilization thresholds**: For example, scale up when hitting 70-80% of your limit, scale down after sustained low usage
 - **Schedule capacity changes**: Use [Temporal Schedules](/schedule) or Workflows to increase TRUs before known events
 - **React to leading indicators**: If your application has upstream signals (incoming order queue depth, marketing campaign start), use those to trigger capacity changes proactively
@@ -227,7 +227,7 @@ Since you understand your workload patterns better than any auto-scaling system,
 
 In addition to understanding the patterns that can affect APS limits on a Temporal Namespace, it's also important to know if you're approaching (or exceeding) these limits.
 Temporal Cloud provides several metrics that, if tracked, will tell you if you're being rate limited due to APS.
-See the documentation on [detecting resource exhaustion](/production-deployment/cloud/service-health#rps-aps-rate-limits) for an explanation of those metrics as well as a sample Grafana dashboard that shows how they could be viewed.
+See the documentation on [detecting resource exhaustion](/cloud/service-health#rps-aps-rate-limits) for an explanation of those metrics as well as a sample Grafana dashboard that shows how they could be viewed.
 
 ### Monitoring for TRU Decisions
 

docs/best-practices/managing-namespace.mdx

@@ -118,7 +118,7 @@ For business-critical use cases with strict uptime requirements, enable [High Av
 
 ### Use Infrastructure as Code (Temporal Cloud only) {#terraform}
 
-Use the [Temporal Cloud Terraform provider](/production-deployment/cloud/terraform-provider) to manage Namespaces.
+Use the [Temporal Cloud Terraform provider](/cloud/terraform-provider) to manage Namespaces.
 If Terraform isn't suitable, scripting against the [Cloud Ops API](/ops) or [tcld](/cloud/tcld) is a good alternative.
 
 This provides:

…tion-deployment/cloud/audit-logs-aws.mdx docs/cloud/audit-logs-aws.mdxdocs/production-deployment/cloud/audit-logs-aws.mdx renamed to docs/cloud/audit-logs-aws.mdx docs/production-deployment/cloud/audit-logs-aws.mdx renamed to docs/cloud/audit-logs-aws.mdx

@@ -73,7 +73,7 @@ Your work is never lost and will continue at the limited pace until APS returns
 Your rate limits can be adjusted automatically over time or provisioned manually with Capacity Modes.
 
 We recommend tracking your Actions Rate and Limits using Temporal metrics to assess your use cases specific needs. 
-See [Monitoring Trends Against Limits](/production-deployment/cloud/service-health#rps-aps-rate-limits) to track usage trends.
+See [Monitoring Trends Against Limits](/cloud/service-health#rps-aps-rate-limits) to track usage trends.
 
 :::note Actions that don't count against APS
 Actions that are external to the core Temporal service do not contribute to your APS. These Calls include:
@@ -189,7 +189,7 @@ To switch to Provisioned capacity:
 
 In addition to the Capacity Mode selections, a summary of APS usage over the last seven days is included to help you estimate your current usage. 
 For more detailed information, we recommend setting up metrics that track your APS and Limits. 
-See [Monitoring Trends Against Limits](/production-deployment/cloud/service-health#rps-aps-rate-limits) to track usage trends.
+See [Monitoring Trends Against Limits](/cloud/service-health#rps-aps-rate-limits) to track usage trends.
 
 ![Manage Capacity panel in the Temporal UI](/img/cloud/provisioned-capacity/manage_capacity_panel.png)
 

…tion-deployment/cloud/audit-logs-gcp.mdx docs/cloud/audit-logs-gcp.mdxdocs/production-deployment/cloud/audit-logs-gcp.mdx renamed to docs/cloud/audit-logs-gcp.mdx docs/production-deployment/cloud/audit-logs-gcp.mdx renamed to docs/cloud/audit-logs-gcp.mdx

@@ -234,6 +234,6 @@ This way, Workers can access the newly activated region once failover occurs.
 
 The following table lists the available Temporal regions, PrivateLink endpoints, and regional endpoints used for DNS record overrides:
 
-import AWSRegions from '@site/docs/production-deployment/cloud/references/regions/awsregions.md';
+import AWSRegions from '@site/docs/cloud/references/regions/awsregions.md';
 
 <AWSRegions />