Codespell / whitespace fixes

fast/plugins/2-networking-serverless-connector/README.md

@@ -10,7 +10,7 @@ This plugin does not manage
 The plugin only requires a specific configuration if the defaults it uses need to be changed:
 
 - the connector-specific subnets default to the `10.255.255.0` range
-- the machine type, number of instances and thoughput use the API defaults
+- the machine type, number of instances and throughput use the API defaults
 
 To enable the plugin, simply copy or link its files in the networking stage.
 

fast/stages/0-bootstrap/identity-providers.tf

@@ -73,7 +73,7 @@ resource "google_iam_workload_identity_pool_provider" "default" {
   oidc {
     # Setting an empty list configures allowed_audiences to the url of the provider
     allowed_audiences = each.value.custom_settings.audiences
-    # If users don't provide an issuer_uri, we set the public one for the platform choosed.
+    # If users don't provide an issuer_uri, we set the public one for the platform chosen.
     issuer_uri = (
       each.value.custom_settings.issuer_uri != null
       ? each.value.custom_settings.issuer_uri

fast/stages/1-tenant-factory/tenant-fast-identity-providers.tf

@@ -63,7 +63,7 @@ resource "google_iam_workload_identity_pool_provider" "default" {
   oidc {
     # Setting an empty list configures allowed_audiences to the url of the provider
     allowed_audiences = each.value.custom_settings.audiences
-    # If users don't provide an issuer_uri, we set the public one for the platform choosed.
+    # If users don't provide an issuer_uri, we set the public one for the platform chosen.
     issuer_uri = (
       each.value.custom_settings.issuer_uri != null
       ? each.value.custom_settings.issuer_uri

fast/stages/1-vpcsc/README.md

@@ -33,9 +33,9 @@ The approach to VPC-SC design implemented in this stage aims at providing the si
 
 This stage uses a single VPC-SC perimeter by default, which is enough to provide protection against data exfiltration and use of credentials from outside of established boundaries, while minimizing operational toil.
 
-The perimeter is set to dry-run mode by default, but the suggestion is to switch to enforced mode immediately after definining the initial set of access level and ingress/egress policies. This prevents the common situation where a complex design is deployed in dry-run mode, and then never enforced as the burden of addressing all violations is too high. A simpler design like the one presented here that employs very coarse access levels can be enforced quickly, and then refined iteratively as operations are streamlined and familiarity with VPC-SC quirks increases.
+The perimeter is set to dry-run mode by default, but the suggestion is to switch to enforced mode immediately after defining the initial set of access level and ingress/egress policies. This prevents the common situation where a complex design is deployed in dry-run mode, and then never enforced as the burden of addressing all violations is too high. A simpler design like the one presented here that employs very coarse access levels can be enforced quickly, and then refined iteratively as operations are streamlined and familiarity with VPC-SC quirks increases.
 
-The stage is designed to allow definining additional perimeters via the `perimeters` variable, with a few caveats:
+The stage is designed to allow defining additional perimeters via the `perimeters` variable, with a few caveats:
 
 - there's no support for perimeter bridges, if those are needed they need to be integrated via code (which is easy enough to do anyway)
 - resource discovery is only supported for the default perimeter, using the `default` key in the `perimeters` variable (again, that is reasonably easy to change via code if needed)

fast/stages/2-networking-b-nva/README.md

@@ -10,7 +10,7 @@ It adopts the common “hub and spoke” reference design, which is well suited
 - the "dmz" or "untrusted" VPC centralizes the external connectivity towards untrusted network resources, such as Internet (inbound and outbound) or 3P service providers or parties connected through VPN or Interconnect.
 - the "spoke" VPCs allow partitioning workloads (e.g. by environment like in this setup), while still retaining controlled access to central connectivity and services
 - Shared VPCs -both in hub and spokes- split the management of the network resources into specific (host) projects, while still allowing them to be consumed from the workload (service) projects
-- if Regional VPC network mode is selected two additional regional trusted hub VPCs are deployed to provide connectivity to GCP services (eg. GCVE) that don't support multi-regional routing. 
+- if Regional VPC network mode is selected two additional regional trusted hub VPCs are deployed to provide connectivity to GCP services (eg. GCVE) that don't support multi-regional routing.
 - the design facilitates DNS centralization
 
 Connectivity between the hub and the spokes is established via [VPC network peerings](https://cloud.google.com/vpc/docs/vpc-peering), which offer uncapped bandwidth, lower latencies, at no additional costs and with a very low management overhead. Different ways of implementing connectivity, and related some pros and cons, are discussed below.
@@ -82,7 +82,7 @@ The final number of subnets, and their IP addressing will depend on the user-spe
 ## Design overview and choices
 
 ### Deployment models
-This stage support three different deployment models that can be controlled by `var.network_mode`. The stage deploys networking resources in two different regions and supports both regional and multi-regional VPCs. Depending on the selected deployment model different routing strategies and NVAs failover modes can be implemented. 
+This stage support three different deployment models that can be controlled by `var.network_mode`. The stage deploys networking resources in two different regions and supports both regional and multi-regional VPCs. Depending on the selected deployment model different routing strategies and NVAs failover modes can be implemented.
 
 - **Simple NVA**: This network mode deploys multi-regional VPCs, the network appliances are configured behind a "ILB Sandwitch" (two different network passthrough internal load balancers on each of `dmz` and `landing` VPCs), with static routes sending traffic for specific destinations to specific network appliances group through the load balancer.
 - **NCC-RA**: This network mode deploys multi-regional VPCs as the simple mode but provides a different routing strategy. The network appliances establish BGP sessions with a Cloud Router on both `dmz` and `landing` VPCs, which comes with the following benefits, at the cost of additional initial setup complexity:
@@ -113,7 +113,7 @@ The landing network area acts as a hub: the multi-region landing VPC bridges int
 Each virtual network is a [shared VPC](https://cloud.google.com/vpc/docs/shared-vpc): shared VPCs are managed in dedicated *host projects* and shared with other *service projects* that consume the network resources.
 Shared VPC lets organization administrators delegate administrative responsibilities, such as creating and managing instances, to Service Project Admins while maintaining centralized control over network resources like subnets, routes, and firewalls.
 
-When the **regional network mode** is selected, the stage deploys two additional landing VPCs each one with a regional scope. If required the regional VPCs can be exteded as shared VPC and cosumed by other service (spoke) projects.   
+When the **regional network mode** is selected, the stage deploys two additional landing VPCs each one with a regional scope. If required the regional VPCs can be extended as shared VPC and consumed by other service (spoke) projects.
 
 Users can easily extend the design to host additional environments, or adopt different logical mappings for the spokes (for example, in order to create a new spoke for each company entity). Adding spokes is trivial and it does not increase the design complexity. The steps to add more spokes are provided in the following sections.
 In multi-organization scenarios, where production and non-production resources use different Cloud Identity and GCP organizations, the hub/landing VPC is usually part of the production organization. It establishes connections with the production spokes within the same organization, and with non-production spokes in a different organization.

fast/stages/2-networking-b-nva/net-prod.tf

@@ -24,7 +24,7 @@ locals {
     primary   = (var.network_mode == "regional_vpc" ? module.ilb-regional-nva-landing["primary"].forwarding_rule_addresses[""] : null)
     secondary = (var.network_mode == "regional_vpc" ? module.ilb-regional-nva-landing["secondary"].forwarding_rule_addresses[""] : null)
   }
-  # On the basis of the network modes slects the NVA internal load balacer as next hop for spoke VPC routing
+  # On the basis of the network modes selects the NVA internal load balancer as next hop for spoke VPC routing
   nva_load_balancers = (var.network_mode == "ncc_ra") ? null : {
     primary   = (var.network_mode == "simple" ? local._simple_nva_lb.primary : local._regional_nva_lb.primary)
     secondary = (var.network_mode == "simple" ? local._simple_nva_lb.secondary : local._regional_nva_lb.secondary)

fast/stages/2-project-factory/README.md

@@ -149,7 +149,7 @@ The YAML data files are self-explanatory and the included [schema files](./schem
 
 The project factory manages its folder hierarchy via a filesystem tree, rooted in the path defined via the `factories_config.hierarchy_data` variable.
 
-Filesystem folders which contain a `_config.yaml` file are mapped to folders in the resource management hierarchy. Their YAML configuration files allow definining folder attributes like descriptive name, IAM bindings, organization policies, tag bindings.
+Filesystem folders which contain a `_config.yaml` file are mapped to folders in the resource management hierarchy. Their YAML configuration files allow defining folder attributes like descriptive name, IAM bindings, organization policies, tag bindings.
 
 This is the simple filesystem hierarchy provided here as an example.
 

fast/stages/3-data-platform/dev/README.md

@@ -46,7 +46,7 @@ A Shared VPC is used here, either from one of the FAST networking stages (e.g. [
 
 ### Encryption
 
-Cloud KMS crypto keys can be configured wither from the [FAST security stage](../../2-security) or from an external source. This step is optional and depends on customer policies and security best practices.
+Cloud KMS crypto keys can be configured either from the [FAST security stage](../../2-security) or from an external source. This step is optional and depends on customer policies and security best practices.
 
 To configure the use of Cloud KMS on resources, you have to specify the key id on the `service_encryption_keys` variable. Key locations should match resource locations.