Extra tips about Connectivity and High Availability (#4359)

* docs: Add connectivity and failover clarifications from field feedback

- GCP PSC: Add troubleshooting callout that Connectivity Rules are mandatory
- AWS PrivateLink: Document direct VPCE targeting without per-namespace DNS
- Failovers: Clarify that successful failover API calls guarantee completion
- HA connectivity: Warn about Private Hosted Zones blocking failover routing

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* Quick updates about failover and connectivity

* move sections and point to alternative early

* fix build error

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Lenny Chen <lenny.chen@temporal.io>

Author: 3 people

docs/cloud/connectivity/aws-connectivity.mdx

@@ -29,6 +29,8 @@ This one-way connection means Temporal cannot establish a connection back to you
 This is useful if normally you block traffic egress as part of your security protocols.
 If you use a private environment that does not allow external connectivity, you will remain isolated.
 
+After creating the PrivateLink endpoint, configure your clients to use it through either [private DNS](#configuring-private-dns-for-aws-privatelink) or [direct VPCE targeting](#direct-vpce) (single-region Namespaces only).
+
 ## Requirements
 
 Your AWS PrivateLink endpoint must be in the same region as your Temporal Cloud namespace. If using [replication for High Availability](/cloud/high-availability), the PL connection must be in the same region as one of the replicas.
@@ -74,14 +76,10 @@ Individual Namespaces do not use separate services.
     This can take up to 10 minutes.
 12. Once the status is "Available", the AWS PrivateLink is ready for use.
 
-:::caution
-You still need to set up private DNS or override client configuration for your clients to actually use the new PrivateLink connection to connect to Temporal Cloud.
-
-See [configure private DNS for AWS PrivateLink](#configuring-private-dns-for-aws-privatelink)
-:::
-
     ![Highlighted DNS names section shows your hostname](/img/cloud/privatelink/details.png)
 
+The next step is to [configure private DNS](#configuring-private-dns-for-aws-privatelink) so your clients can use the PrivateLink connection. For single-region Namespaces that don't need per-Namespace DNS records, you can use [direct VPCE targeting](#direct-vpce) instead.
+
 ## Configuring Private DNS for AWS PrivateLink
 
 ### Why configure private DNS?
@@ -230,6 +228,26 @@ Consider how you’ll configure Workers for this setup.
 You can either have Workers run in both regions continuously or establish connectivity between regions using Transit Gateway or VPC Peering.
 This way, Workers can access the newly activated region once failover occurs.
 
+## Direct VPCE targeting without per-Namespace DNS {#direct-vpce}
+
+For single-region Namespaces, you can avoid creating DNS records for each Namespace by pointing Workers directly at the VPC Endpoint and overriding the TLS Server Name Indicator (SNI):
+
+1. Create the PrivateLink VPC Endpoint (one per region — all Namespaces in that region share it).
+2. Configure each Worker with:
+   - **Endpoint**: the VPC Endpoint DNS name (e.g., `vpce-0123456789abcdef-abc.us-east-1.vpce.amazonaws.com:7233`)
+   - **Server name** (SNI override): the Namespace Endpoint value (e.g., `my-namespace.my-account.tmprl.cloud`)
+
+With this approach, new Namespaces do not require new DNS records.
+
+:::warning Not compatible with High Availability Namespaces
+
+This approach does not work for Namespaces with High Availability features.
+HA Namespaces rely on Temporal's public DNS CNAME records to route traffic to the active region during failover.
+If you bypass DNS, your Workers cannot follow the CNAME to the new region.
+For HA Namespaces, use [private DNS](#configuring-private-dns-for-aws-privatelink) instead.
+
+:::
+
 ## Available AWS regions, PrivateLink endpoints, and DNS record overrides
 
 The following table lists the available Temporal regions, PrivateLink endpoints, and regional endpoints used for DNS record overrides:

docs/cloud/connectivity/gcp-connectivity.mdx

@@ -79,6 +79,14 @@ Individual Namespaces do not use separate services.
 
 7. Once the status is "Accepted", the GCP Private Service Connect endpoint is ready for use.
 
+:::tip Connectivity Rule required
+
+If your Private Service Connect connection status is not becoming "Active", verify that you have [created a Connectivity Rule](/cloud/connectivity#creating-a-connectivity-rule).
+Connectivity Rules are mandatory for GCP Private Service Connect connections.
+The connection will not become active without one.
+
+:::
+
 - Take note of the **IP address** that has been assigned to your endpoint, as it will be used to connect to Temporal Cloud.
 
 :::caution

docs/cloud/high-availability/failovers.mdx

@@ -278,6 +278,10 @@ Both methods return a [`FailoverNamespaceRegionResponse`](https://buf.build/temp
 
 </Tabs>
 
+Once the failover async operation returns successfully, the Namespace will be failed over.
+Temporal manages retries for the failover workflow.
+In the rare event that an internal error prevents the failover from completing, the Temporal on-call team is automatically paged to intervene and force the failover to completion.
+
 Temporal fails over the primary to the replica.
 When you're ready to fail back, follow these failover instructions to move the primary back to the original.
 

docs/with-ai.mdx

@@ -8,8 +8,6 @@ description: Give your AI coding agent Temporal expertise and real-time access t
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-# Develop with AI
-
 Give your AI coding agent Temporal expertise with Skills and real-time documentation access with the Temporal Docs MCP
 Server.