docs: updated multi-az docs
## Overview
-By default, the control plane of a workload cluster created by CAPA will not span multiple availability zones (AZs) (also referred to as "failure domains"), even when using multiple control plane nodes. This is because CAPA will, by default, only create resources in the first discovered AZ of a region. However, if CAPA is specifically configured to create resources in multiple AZs, then control plane nodes will be automatically distributed across multiple AZs. This document explains how to instruct CAPA to create resources in multiple AZs.
+By default, the control plane of a workload cluster created by CAPA will span multiple availability zones (AZs) (also referred to as "failure domains") when using multiple control plane nodes. This is because CAPA will, by default, create public and private subnets in all the AZs of a region (up to a maximum of 3 AZs). If a region has more than 3 AZs then CAPA will pick 3 AZs by random to use.
-## Configuring CAPA to Use Multiple AZs
+## Configuring CAPA to Use Specific AZs
-To explicitly instruct CAPA to create resources in multiple AZs, users must add a `networkSpec` object to the AWSCluster specification. Here is an example `networkSpec` that creates resources across three AZs in the "us-west-2" region:
+To explicitly instruct CAPA to create resources in specific AZs (and not by random), users can add a `networkSpec` object to the AWSCluster specification. Here is an example `networkSpec` that creates resources across three AZs in the "us-west-2" region:
```yaml
spec:
@@ -37,6 +37,8 @@ Note that CAPA insists that there must be a public subnet (and associated Intern
Once CAPA is provided with a `networkSpec` that spans multiple AZs, the KubeadmControlPlane controller will automatically distribute control plane nodes across multiple AZs. No further configuration from the user is required.
+> Note: this method can also be used if you do not want to split your EC2 instance across multiple AZs.
+
## Caveats
Deploying control plane nodes across multiple AZs is not a panacea to cure all availability concerns. The sizing and overall utilization of the cluster will greatly affect the behavior of the cluster and the workloads hosted there in the event of an AZ failure. Careful planning is needed to maximize the availability of the cluster even in the face of an AZ failure. There are also other considerations, like cross-AZ traffic charges, that should be taken into account.
