diff --git a/docs/cloud/get-started/namespaces.mdx b/docs/cloud/get-started/namespaces.mdx
index 0d11d8b4eb..8ca131a9c6 100644
--- a/docs/cloud/get-started/namespaces.mdx
+++ b/docs/cloud/get-started/namespaces.mdx
@@ -131,16 +131,16 @@ utility at a command line interface (CLI). Follow these steps.
 
 </Tabs>
 
-## What is a Cloud Namespace Id? {#temporal-cloud-namespace-id}
+## What is a Cloud Namespace ID? {#temporal-cloud-namespace-id}
 
-A Cloud Namespace Id is a globally unique identifier for a [Namespace](/namespaces) in Temporal Cloud. A Namespace Id is
+A Cloud Namespace ID is a globally unique identifier for a [Namespace](/namespaces) in Temporal Cloud. A Namespace ID is
 formed by concatenating the following:
 
 1. A [Namespace Name](#temporal-cloud-namespace-name)
 1. A period (.)
 1. The [Account ID](#temporal-cloud-account-id) to which the Namespace belongs
 
-For example, for the Account ID `123de` and Namespace Name `accounting-production`, the Namespace Id is
+For example, for the Account ID `123de` and Namespace Name `accounting-production`, the Namespace ID is
 `accounting-production.123de`.
 
 ## What is a Cloud gRPC Endpoint? {#temporal-cloud-grpc-endpoint}
@@ -158,7 +158,8 @@ A gRPC endpoint appears on the detail page for each Cloud Namespace. Follow thes
 2. Navigate to the Namespace list page from the left-side vertical navigation.
 3. Tap or click on the Namespace Name to select and open the page for the Namespace whose endpoint you want to retrieve.
 4. On the Namespace detail page, click on the "Connect" button in the top right corner of the page.
-5. Click the copy icon next to the gRPC address to copy it to your clipboard.
+5. If multiple endpoints are displayed, choose which [type of endpoint](/cloud/namespaces/#access-namespaces) best fits your use case.
+6. Click the copy icon next to the gRPC address to copy it to your clipboard.
 
 See [How to access a Namespace in Temporal Cloud](/cloud/namespaces/#access-namespaces) for more information on
 different gRPC endpoint types and how to access them.
@@ -235,155 +236,124 @@ See the [`tcld` namespace create](/cloud/tcld/namespace/#create) command referen
 
 ## What are some Namespace best practices? {#best-practices}
 
-This section provides general guidance for organizing [Namespaces](/namespaces) across use cases, services,
-applications, or domains. Temporal Cloud provides Namespace–as-a-service, so the Namespace is the endpoint. Customers
-should consider not only a Namespace naming convention but also how to group or isolate workloads using the Namespace as
-a boundary.
+See [Namespace Best Practices](/best-practices/managing-namespace) for an overview of:
 
-Each team can have their own Namespace for improved modularity, security, debugging, and fault isolation. Namespaces
-contain the blast radius of misbehaving Workers that may exhaust rate limits. Sensitive Workflow state (PCI data) can be
-secured with per-Namespace permissions and encrypted with a separate encryption key.
+- naming conventions
+- typical organizational patterns
+- safeguards for production
+- tagging
+
+## How to call Workflows from different Namespaces?
 
 Temporal Applications in different Namespaces may be connected with [Nexus](/cloud/nexus) by exposing a clean service
 contract for others to use with built-in [Nexus access controls](/cloud/nexus/security). Nexus supports cross-team,
 cross-domain, multi-region, and multi-cloud use cases.
 
-### Constraints and limitations
+## Namespace Constraints and Limitations {#limits}
 
-Before considering an appropriate Namespace configuration, you should be aware of the following constraints:
+Temporal Cloud Namespaces operate under the following constraints:
 
 - By default, each account is allocated with a limit of ten Namespaces. As you create and use your Namespaces, for
   example by scheduling Workflows, Temporal Cloud automatically raises your limit. Our service identifies your usage
   patterns. It responds by slowly increasing your allowance, up to 100 Namespaces. You can request further increases
   beyond the 100 Namespace limit by opening a [support ticket](/cloud/support#support-ticket).
-- Each Namespace has a rate limit, which is measured in Actions per second (APS). A namespace may be throttled when its
-  throughput becomes too high. Throttling means limiting the rate at which actions are performed to prevent overloading
-  the system. A Namespace's default limit is set at 400 APS and automatically adjusts based on recent usage (over the
-  prior 7 days). Your APS limit will never fall below this default value.
-- Each Namespace has a default service-level agreement (SLA) of 99.9% uptime.
-- You can opt-in to using [High Availability features](https://docs.temporal.io/cloud/high-availability) with a 99.99%
-  contractual SLA.
+- Each Namespace has [rate limits](/cloud/limits#namespace-level) for actions, operations, schedules, requests, and visibility requests.
+  A namespace may be rate limited when its throughput becomes too high to prevent overloading the system.
+  Namespace limits automatically adjust based on the prior 7 days of usage.
+- By default, Namespaces have a [service-level agreement (SLA)](/cloud/sla) of 99.9% availability against service errors.
+- You can opt-in to using [High Availability features](https://docs.temporal.io/cloud/high-availability) to increase the 
+  SLA to 99.99%.
+  - Note: If a Namespace's [action per second limit](/cloud/limits#actions-per-second) has been raised above the default, 
+    then it will require a support ticket to enable High Availability.
+    Support will ensure that Temporal Cloud has capacity to handle the additional APS before it adds the replica.
 - A Namespace is a security isolation boundary. Access to Temporal by [Worker Processes](/workers#worker-process) is
   permitted at the Namespace level. Isolating applications or environments (development, test, staging, production)
-  should take this into consideration.
-- A Namespace is provisioned with an endpoint for executing your Workflows. Accessing a Namespace from a Temporal Client
+  should take this into consideration. See the [best practices for organizing Namespaces](/best-practices/managing-namespace)
+- A Namespace is provisioned with [endpoints](constraints-and-limitations) for executing your Workflows. Accessing a Namespace from a Worker or Temporal Client
   requires [API keys](/cloud/api-keys) or [mTLS](/cloud/certificates) authentication.
-- [Workflow Id](/workflow-execution/workflowid-runid#workflow-id)uniqueness is per Namespace.
+- Every open Workflow in a Namespace needs a unique [Workflow ID](/workflow-execution/workflowid-runid#workflow-id).
+  This does not apply to closed Workflows, which may have the same Workflow ID in the same Namespace.
+  Open Workflows in different Namespaces may have the same Workflow ID.
 - [Task Queue](/task-queue) names are unique per Namespace.
 - Closed Workflow retention is per Namespace.
 - RBAC [permissions](/cloud/users#namespace-level-permissions) are implemented at the Namespace level.
-
-### General guidance
-
-Namespace configuration requires some consideration. Following are some general guidelines to consider.
-
-- Namespaces are usually defined per use case. A use case can encompass a broad range of Workflow types and a nearly
-  unlimited scale of concurrent [Workflow Executions](/workflow-execution).
-- Namespaces can be split along additional boundaries such as service, application, domain or even sub-domain.
-- Environments such as production and development usually have requirements for isolation. We recommend that each
-  environment has its own Namespace.
-- Namespaces should be used to reduce the "blast radius" for mission-critical applications.
-- Workflows that need to communicate with each other should (for now) be in the same Namespace.
-- If you need to share Namespaces across team or domain boundaries, be sure to ensure the uniqueness of Workflow Ids.
-
-### Examples
-
-Following are some ideas about how to organize Namespaces.
-
-#### Example 1: Namespace per use case and environment
-
-We recommend using one Namespace for each use case and environment combination for simple configurations in which
-multiple services and team or domain boundaries don't exist.
-
-Sample naming convention:
-
-<pre>&lt;use-case>_&lt;environment></pre>
-
-#### Example 2: Namespace per use case, service, and environment
-
-We recommend using one Namespace for each use case, service, and environment combination when multiple services that are
-part of same use case communicate externally to Temporal via API (HTTP/gRPC).
-
-Sample naming convention:
-
-<pre>&lt;use-case>_&lt;service>_&lt;environment></pre>
-
-#### Example 3: Namespace per use case, domain, and environment
-
-We recommend using one namespace per use case, domain, and environment combination when multiple services that are part
-of the same use case need to communicate with each another via [Signals](/sending-messages#sending-signals) or by
-starting [Child Workflows](/child-workflows). In this case, though, you must be mindful about Workflow Id uniqueness by
-prefixing each Workflow Id with a service-specific string. The name of each Task Queue must also be unique. If multiple
-teams are involved, the domain could also represent a team boundary.
-
-Sample naming convention:
-
-<pre>&lt;use-case>_&lt;domain>_&lt;environment></pre>
-
-Sample workflowId convention:
-
-<pre>&lt;service-string>_&lt;workflow-id></pre>
+- For Workflows in different Namespaces to communicate with each other, they must use Nexus.
 
 ## How to access a Namespace in Temporal Cloud {#access-namespaces}
 
 {/* How to access a Namespace in Temporal Cloud */}
 
-Temporal Cloud normally supports authentication to Namespaces using [API keys](/cloud/api-keys) _or_
-[mTLS](/cloud/certificates). If you need to migrate from one authentication method to another, or you require both API
-key and mTLS authentication to be enabled on your Namespace, please contact
+Temporal Cloud supports authentication to Namespaces using [API keys](/cloud/api-keys) _or_
+[mTLS](/cloud/certificates). To migrate a Namespace from one authentication method to another, or to use both API
+key and mTLS authentication on the same Namespace, please contact
 [Support](https://docs.temporal.io/cloud/support#support-ticket).
 
 :::info
 
-Namespace authentication requiring both API key and mTLS is in
-[pre-release](/evaluate/development-production-features/release-stages), and doesn't support
+Using both API key and mTLS authentication on the same Namespace is in
+[pre-release](/evaluate/development-production-features/release-stages) and cannot be used along with
 [High Availability features](/cloud/high-availability).
 
 :::
 
-See the documentation for [API keys](/cloud/api-keys) and [mTLS certificates](/cloud/certificates) for more information
-on how to create and manage your credentials.
-
-Programmatically accessing your Namespace requires specific endpoints based on your authentication method. There are two
-types of gRPC endpoints for accessing a Namespace in Temporal Cloud:
-
-- A namespace endpoint (`<namespace>.<account>.tmprl.cloud:7233`)
-- A regional endpoint (`<region>.<cloud_provider>.api.temporal.io:7233`).
-
-Which one to use depends on your authentication method and whether your Namespace has
-[High Availability features](/cloud/high-availability) enabled, as shown in the table below.
-
-|                        | Not High Availability | High Availability                                                                                                            |
-| ---------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
-| mTLS Authentication    | Namespace             | Namespace                                                                                                                    |
-| API Key Authentication | Regional              | Both work, but we reommend using the Namespace endpoint because it reduces the unavailability window during a failover event |
+Connecting to your Namespace requires a specific endpoint that works for the given Namespace.
+There are two types of gRPC endpoints for accessing a Namespace in Temporal Cloud: a Namespace endpoint and a regional endpoint.
+
+- Namespace endpoint (`<namespace>.<account>.tmprl.cloud:7233`)
+    - Benefits:
+        - This endpoint is unique to each Namespace. It will always connect to the Namespace, no matter which region(s) the Namespace is using. (Recommended for Namespaces with High Availability)
+        - A Temporal Client that uses a Namespace endpoint doesn't have to be aware of which region the Namespace is in.
+    - Restrictions:
+        - If [High Availability](/cloud/high-availability) is not enabled, then accessing a Namespace via API key + Namespace endpoint is not supported. To use the Namespace endpoint with API keys, a Namespace must have [High Availability](/cloud/high-availability) enabled.
+- Regional endpoint (`<region>.<cloud_provider>.api.temporal.io:7233`)
+    - Benefits:
+        - Temporal Cloud has only one regional endpoint for each cloud region. The same regional endpoint can access any Namespace that is active in that region (or that has a [replica](/cloud/high-availability) in that region).
+        - A Temporal Client can use a regional endpoint to ensure connection to a Namespace always happens within that region.
+    - Restrictions:
+        - When using mTLS to authenticate, the Temporal Client override the Server Name Indication (SNI) in the TLS configuration with the value of the Namespace endpoint.
+          In the Temporal SDKs, this can be done using the "TLS Server Name" property in requests to Temporal Cloud.
+          For example, in the [Temporal CLI](/cloud/certificates#configure-temporal-cli, this can be done by using `TEMPORAL_TLS_SERVER_NAME=<namespace endpoint>` or `--tls-server-name <namespace endpoint>`.
+
+This table summarizes which endpoints are available for a Namespace based on which features the Namespace has enabled:
+
+|                            | Not High Availability                                                 | High Availability                                                                   |
+|----------------------------|-----------------------------------------------------------------------|-------------------------------------------------------------------------------------|
+| **mTLS Authentication**    | Namespace endpoint or regional endpoint (must override `server_name`) | Namespace endpoint (recommended) or regional endpoint (must override `server_name`) |
+| **API Key Authentication** | Regional endpoint only                                                | Namespace endpoint (recommended) or regional endpoint                               |
 
 :::info
 
 When switching on or off High Availability features for a Namespace, you may need to update the gRPC endpoint used by
-your clients and Workers, because the Namespace endpoint changes based on whether High Availability features are
-enabled. See [Disable High Availability](/cloud/high-availability/enable#disable) for more information.
+Temporal Clients and Workers. See [Disable High Availability](/cloud/high-availability/enable#disable) for more information.
 
 :::
 
-For information on how to connect to Clients using a specific authentication method see the following documentation.
+### Authenticating with API keys or mTLS
 
-- To use API keys to connect with the [Temporal CLI](/cli), [Client SDK](/develop), [tcld](/cloud/tcld),
-  [Cloud Ops API](/ops), and [Terraform](/cloud/terraform-provider), see
+To use API keys with [supported SDKs](/cloud/api-keys#api-key-supported-tooling), see
   [Use API keys to authenticate](/cloud/api-keys#using-apikeys).
-- To use mTLS to connect with the [Temporal CLI](/cli) and [Client SDK](/develop), see
+  
+To use mTLS to connect with the [Temporal CLI](/cli) and [Client SDK](/develop), see
   [Configure Clients to use Client certificates](/cloud/certificates#configure-clients-to-use-client-certificates).
 
+### Accessing the Temporal Web UI
+
 For accessing the Temporal Web UI, use the HTTPS endpoint in the form:
 `https://cloud.temporal.io/namespaces/<namespace>.<account>`. For example:
 `https://cloud.temporal.io/namespaces/accounting-production.f45a2`.
 
-To ensure the security of your data, all traffic to and from your Namespace is encrypted. However, for enhanced
-protection, you have additional options:
+### Accessing Namespaces with Encryption and Private Connectivity
+
+To ensure the security of your data, all traffic to and from your Namespace is encrypted with TLS 1.3. 
+
+For enhanced protection:
 
-- (Recommended) Set up private connectivity by [creating a ticket for Temporal Support](/cloud/support#support-ticket).
-- Set up your allow list for outgoing network requests from your Clients and Workers with the IP address ranges of the
-  Cloud Provider region in which your Namespace is located:
+- Set up [private connectivity](/cloud/connectivity#private-network-connectivity-for-namespaces) to the Namespace.
+- When not using private connectivity, always connect to a Namespace from the same cloud provider.
+  If the Namespace is on AWS, then only connect to it from Workers that are also on AWS.
+  This keeps all traffic between Workers and Temporal Cloud on the cloud's backbone (see [AWS docs](https://aws.amazon.com/vpc/faqs/#:~:text=the%20Internet%20gateway.-,Q.,AWS%20use%20AWS's%20private%20network.), [GCP docs](https://cloud.google.com/network-tiers/docs/overview))
+- In your own networking architecture, set up an allow list for outgoing network requests from your Clients and Workers with the IP address ranges of the
+  Cloud Provider region(s) in which your Namespace is located:
   - [AWS IP address ranges](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html)
   - [GCP IP address ranges](https://cloud.google.com/compute/docs/faq#find_ip_range)
 
diff --git a/docs/cloud/high-availability/enable.mdx b/docs/cloud/high-availability/enable.mdx
index 3e7e571869..084f3523e8 100644
--- a/docs/cloud/high-availability/enable.mdx
+++ b/docs/cloud/high-availability/enable.mdx
@@ -34,6 +34,9 @@ Using private network connectivity with a HA namespace requires extra setup. See
 There are charges associated with Replication and enabling High Availability features. For pricing details, visit
 Temporal Cloud's [Pricing](/cloud/pricing) page.
 
+If the Namespace's APS limit has been raised above the [default limit](https://docs.temporal.io/cloud/namespaces#constraints-and-limitations), then it will require a support ticket to to add a replica. Support will ensure that Temporal Cloud has capacity in the replica's region to handle the additional APS. Please
+[contact support](/cloud/support#support-ticket) with the Namespace ID and the region where you want to add a replica.
+
 ## Create a Namespace with High Availability features {#create}
 
 To create a new Namespace with High Availability features, you can use the Temporal Cloud UI or the tcld command line
diff --git a/docs/encyclopedia/namespaces/namespaces.mdx b/docs/encyclopedia/namespaces/namespaces.mdx
index 6ba739aae3..fc3c7dded9 100644
--- a/docs/encyclopedia/namespaces/namespaces.mdx
+++ b/docs/encyclopedia/namespaces/namespaces.mdx
@@ -27,8 +27,9 @@ When a Workflow Execution is spawned, it does so within a specific Namespace.
 
 ## Usage
 
-- **Workflow ID uniqueness**: Temporal guarantees a unique Workflow Id within a Namespace.
-  Workflow Executions may have the same Workflow Id if they are in different Namespaces.
+- **Workflow ID uniqueness**: Temporal guarantees that each running Workflow Exeecution within a Namespace has a unique Workflow ID.
+  Closed Workflow Executions may have the same Workflow ID.
+  Running Workflow Executions may have the same Workflow ID if they are in different Namespaces.
 - **Resource isolation**: Heavy traffic from one Namespace will not impact other Namespaces running on the same Temporal Service.
 - **Configuration boundaries**: Options like the [Retention Period](/temporal-service/temporal-server#retention-period) and [Archival](/temporal-service/archival) destination are configured per Namespace.
 - **Default Namespace**: If no Namespace is specified, the Temporal Service uses the Namespace "default" for all Temporal SDKs and the Temporal CLI.