diff --git a/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md b/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md
index a5f83df2b65..d8d19368108 100644
--- a/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md
+++ b/content/rancher/v2.x/en/cluster-admin/tools/alerts/_index.md
@@ -177,7 +177,7 @@ This alert type monitors for the overload from Prometheus expression querying, i
 
   - [**Node**](https://github.com/prometheus/node_exporter)
   - [**Container**](https://github.com/google/cadvisor)
-  - [**ETCD**](https://etcd.io/docs/v3.3.12/op-guide/monitoring/)
+  - [**ETCD**](https://etcd.io/docs/v3.4.0/op-guide/monitoring/)
   - [**Kubernetes Components**](https://github.com/kubernetes/metrics)
   - [**Kubernetes Resources**](https://github.com/kubernetes/kube-state-metrics)
   - [**Fluentd**](https://docs.fluentd.org/v1.0/articles/monitoring-prometheus) (supported by [Logging]({{< baseurl >}}/rancher/v2.x/en/tools/logging))
@@ -233,4 +233,4 @@ After you set up cluster alerts, you can manage each alert object. To manage ale
 - Edit alert settings
 - Delete unnecessary alerts
 - Mute firing alerts
-- Unmute muted alerts
\ No newline at end of file
+- Unmute muted alerts
diff --git a/content/rancher/v2.x/en/cluster-provisioning/production/recommended-architecture/_index.md b/content/rancher/v2.x/en/cluster-provisioning/production/recommended-architecture/_index.md
index 1925a794cc0..fc893cb079e 100644
--- a/content/rancher/v2.x/en/cluster-provisioning/production/recommended-architecture/_index.md
+++ b/content/rancher/v2.x/en/cluster-provisioning/production/recommended-architecture/_index.md
@@ -54,7 +54,7 @@ The number of nodes that you can lose at once while maintaining cluster availabi
 
 References:
 
-* [Official etcd documentation on optimal etcd cluster size](https://github.com/bmizerany/etcd-team/blob/master/Documentation/optimal-cluster-size.md)
+* [Official etcd documentation on optimal etcd cluster size](https://etcd.io/docs/v3.4.0/faq/#what-is-failure-tolerance)
 * [Official Kubernetes documentation on operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)
 
 ### Number of Worker Nodes
@@ -71,4 +71,4 @@ You may have noticed that our [High Availability (HA) Install]({{<baseurl>}}/ran
 
 # References
 
-* [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components)
\ No newline at end of file
+* [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components)
diff --git a/content/rancher/v2.x/en/installation/options/etcd/_index.md b/content/rancher/v2.x/en/installation/options/etcd/_index.md
index dfe02cabb98..32e25f5d7ec 100644
--- a/content/rancher/v2.x/en/installation/options/etcd/_index.md
+++ b/content/rancher/v2.x/en/installation/options/etcd/_index.md
@@ -6,7 +6,7 @@ aliases:
 
 When running larger Rancher installations with 15 or more clusters it is recommended to increase the default keyspace for etcd from the default 2GB. The maximum setting is 8GB and the host should have enough RAM to keep the entire dataset in memory. When increasing this value you should also increase the size of the host. The keyspace size can also be adjusted in smaller installations if you anticipate a high rate of change of pods during the garbage collection interval.
 
-The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.3.12/op-guide/maintenance/#space-quota) setting on the etcd servers.
+The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota) setting on the etcd servers.
 
 ### Example: This snippet of the RKE cluster.yml file increases the keyspace size to 5GB
 
@@ -21,7 +21,7 @@ services:
 
 ## Scaling etcd disk performance
 
-You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.3.12/tuning/#disk) on how to tune the disk priority on the host.
+You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.4.0/tuning/#disk) on how to tune the disk priority on the host.
 
 Additionally, to reduce IO contention on the disks for etcd, you can use a dedicated device for the data and wal directory. Based on etcd best practices, mirroring RAID configurations are unnecessary because etcd replicates data between the nodes in the cluster. You can use stripping RAID configurations to increase available IOPS.