Fixes

website/content/docs/connect/cluster-peering/index.mdx

@@ -8,28 +8,27 @@ description: >-
 # Cluster peering overview
 
 This topic provides an overview of cluster peering, which lets you connect two or more independent Consul clusters so that services deployed to different partitions or datacenters can communicate.
-
 Cluster peering is enabled in Consul by default. For specific information about cluster peering configuration and usage, refer to following pages.
 
 **Reference information:**
 
 - [HTTP API reference: `/peering/` endpoint](/consul/api-docs/peering)
 - [CLI reference: `peering` command](/consul/commands/peering).
-- [Cluster peering technical specifications](/docs/consul/connect/cluster-peering/configuration)
+- [Cluster peering technical specifications](/consul/docs/connect/cluster-peering/configuration)
 
 **Usage information:**
 
-- [Establish cluster peering connections](/docs/connect/cluster-peering/create-manage-peering)
-- [Manage cluster peering connections](/consul/docs/cluster-peering/usage/manage-connections)
-- [L7 traffic management for cluster peering connections](/consul/docs/cluster-peering/usage/peering-traffic-management)
+- [Establish cluster peering connections](/consul/docs/connect/cluster-peering/usage/establish-peering)
+- [Manage cluster peering connections](/consul/docs/connect/cluster-peering/usage/manage-connections)
+- [L7 traffic management for cluster peering connections](/consul/docs/connect/cluster-peering/usage/peering-traffic-management)
 
 **Runtime-specific information:**
 
 - [Cluster peering on Kubernetes](/consul/docs/connect/cluster-peering/usage/k8s)
 
 **Tutorials:**
 
-- To learn how to peer clusters and connect services across peers in AWS Elastic Kubernetes Service (EKS) environments, complete the [Consul Cluster Peering on Kubernetes tutorial](/consul/tutorials/developer-mesh/cluster-peering-aws).
+- To learn how to peer clusters and connect services across peers in AWS Elastic Kubernetes Service (EKS) and Google Kubernetes Engine (GKE) environments, complete the [Consul Cluster Peering on Kubernetes tutorial](/consul/tutorials/developer-mesh/cluster-peering).
 
 ## Background
 
@@ -39,11 +38,11 @@ The following diagram describes Consul's cluster peering architecture.
 
 ![Diagram of cluster peering with admin partitions](/img/cluster-peering-diagram.png)
 
-In this diagram, the `default` partition in the Consul DC 1 has a cluster peering connection with the `web` partition in Consul DC 2. Enforced by their respective mesh gateways, this cluster peering connection enables `Service B` to communicate with `Service C` as a service upstream. 
+In this diagram, the `default` partition in the first datacenter has a cluster peering connection with the `web` partition in the second datacenter. Enforced by their respective mesh gateways, this cluster peering connection enables `Service B` to communicate with `Service C` as a service upstream. 
 
 Cluster peering leverages several components of Consul's architecture to enforce secure communication between services:
 
-- A _peering token_ contains an embedded secret that securely establishes communication when shared symmetrically between datacenters. Sharing this token enables each datacenter's server agents to recognize requests from authorized peers, similar to how the [gossip encryption key secures agent LAN gossip](/consul/docs/security/encryption#gossip-encryption).
+- A _peering token_ contains an embedded secret that securely establishes communication when shared symetrically between datacenters. Sharing this token enables each datacenter's server agents to recognize requests from authorized peers, similar to how the [gossip encryption key secures agent LAN gossip](/consul/docs/security/encryption#gossip-encryption).
 - A _mesh gateway_ encrypts outgoing traffic, decrypts incoming traffic, and directs traffic to healthy services. Consul's service mesh features must be enabled in order to use mesh gateways. Mesh gateways support the specific admin partitions they are deployed on. Refer to [Mesh gateways](/consul/docs/connect/gateways/mesh-gateway) for more information.
 - An _exported service_ communicates with downstreams deployed in other admin partitions. They are explicitly defined in an [`exported-services` configuration entry](/consul/docs/connect/config-entries/exported-services).
 - A _service intention_ secures [service-to-service communication in a service mesh](/consul/docs/connect/intentions). Intentions enable identity-based access between services by exchanging TLS certificates, which the service's sidecar proxy verifies upon each request.