docs: Removing and updating broken links on docs/addons (#381)

docs/addons/aws-cloudwatch-metrics.md

@@ -1,20 +1,19 @@
 # AWS CloudWatch Metrics
 
-Use CloudWatch Container Insights to collect, aggregate, and summarize metrics and logs from your containerized applications and microservices. CloudWatch automatically collects metrics for many resources, such as CPU, memory, disk, and network. Container Insights also provides diagnostic information, such as container restart failures, to help you isolate issues and resolve them quickly. You can also set CloudWatch alarms on metrics that Container Insights collects.
+Use [AWS CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) to collect, aggregate, and summarize metrics and logs from your containerized applications and microservices. CloudWatch automatically collects metrics for many resources, such as CPU, memory, disk, and network. Container Insights also provides diagnostic information, such as container restart failures, to help you isolate issues and resolve them quickly. You can also set CloudWatch alarms on metrics that Container Insights collects.
 
 Container Insights collects data as performance log events using embedded metric format. These performance log events are entries that use a structured JSON schema that enables high-cardinality data to be ingested and stored at scale. From this data, CloudWatch creates aggregated metrics at the cluster, node, pod, task, and service level as CloudWatch metrics. The metrics that Container Insights collects are available in CloudWatch automatic dashboards, and also viewable in the Metrics section of the CloudWatch console.
 
 ## Usage
 
-[aws-cloudwatch-metrics](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/modules/kubernetes-addons/aws-cloudwatch-metrics) can be deployed by enabling the add-on via the following.
+AWS CloudWatch Metrics can be deployed by enabling the add-on via the following.
 
 ```hcl
 enable_aws_cloudwatch_metrics = true
 ```
 
 You can also customize the Helm chart that deploys `aws-cloudwatch-metrics` via the following configuration:
 
-
 ```hcl
   enable_aws_cloudwatch_metrics        = true
 

docs/addons/aws-efs-csi-driver.md

@@ -4,7 +4,7 @@ This add-on deploys the [AWS EFS CSI driver](https://docs.aws.amazon.com/eks/lat
 
 ## Usage
 
-The [AWS EFS CSI driver](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/modules/kubernetes-addons/aws-efs-csi-driver) can be deployed by enabling the add-on via the following. Check out the full [example](https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/examples/stateful/main.tf) to deploy an EKS Cluster with EFS backing the dynamic provisioning of persistent volumes.
+The AWS EFS CSI driver can be deployed by enabling the add-on via the following. Check out the full [example](https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/examples/stateful/main.tf) to deploy an EKS Cluster with EFS backing the dynamic provisioning of persistent volumes.
 
 ```hcl
   enable_aws_efs_csi_driver = true

docs/addons/aws-for-fluentbit.md

@@ -1,6 +1,6 @@
 # AWS for Fluent Bit
 
-AWS provides a Fluent Bit image with plugins for both CloudWatch Logs and Kinesis Data Firehose. We recommend using Fluent Bit as your log router because it has a lower resource utilization rate than Fluentd.
+AWS provides a [Fluent Bit](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html) image with plugins for both CloudWatch Logs and Kinesis Data Firehose. We recommend using Fluent Bit as your log router because it has a lower resource utilization rate than Fluentd.
 
 ## Usage
 
@@ -73,22 +73,21 @@ aws-for-fluent-bit-sbn9b   1/1     Running   0          15m
 aws-for-fluent-bit-svhwq   1/1     Running   0          15m
 ```
 
-Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/
-
+Open the [CloudWatch console](https://console.aws.amazon.com/cloudwatch/)
 
 In the navigation pane, choose Log groups.
 
 Make sure that you're in the Region where you deployed Fluent Bit.
 
 Check the list of log groups in the Region. You should see the following:
 
-```
+```sh
 /aws/eks/complete/aws-fluentbit-logs
 ```
 
 If you enabled Container Insights, you should also see the following Log Groups in your CloudWatch Console.
 
-```
+```sh
 /aws/containerinsights/Cluster_Name/application
 
 /aws/containerinsights/Cluster_Name/host

docs/addons/aws-fsx-csi-driver.md

@@ -4,7 +4,7 @@ This add-on deploys the [Amazon FSx CSI Driver](https://docs.aws.amazon.com/eks/
 
 ## Usage
 
-The [Amazon FSx CSI Driver](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/modules/kubernetes-addons/aws-fsx-csi-driver) can be deployed by enabling the add-on via the following.
+The Amazon FSx CSI Driver can be deployed by enabling the add-on via the following.
 
 ```hcl
   enable_aws_fsx_csi_driver = true
@@ -63,7 +63,7 @@ metadata:
   name: fsx-sc
 provisioner: fsx.csi.aws.com
 parameters:
-  subnetId:	<YOUR_SUBNET_IDs>
+  subnetId: <YOUR_SUBNET_IDs>
   securityGroupIds: <YOUR_SG_ID>
   perUnitStorageThroughput: "200"
   deploymentType: PERSISTENT_1

docs/addons/aws-load-balancer-controller.md

@@ -1,12 +1,11 @@
-# AWS Load Balancer Controller.
+# AWS Load Balancer Controller
 
-[AWS Load Balancer Controller ](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) is a controller to help manage Elastic Load Balancers for a Kubernetes cluster. This Add-on deploys this controller in an Amazon EKS Cluster.
+[AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) is a controller to help manage Elastic Load Balancers for a Kubernetes cluster. This Add-on deploys this controller in an Amazon EKS Cluster.
 
 ## Usage
 
 In order to deploy the AWS Load Balancer Controller Addon via [EKS Blueprints Addons](https://github.com/aws-ia/terraform-aws-eks-blueprints-addons), reference the following parameters under the `module.eks_blueprints_addons`.
 
-
 > **_NOTE_**: In versions 2.5 and newer, the AWS Load Balancer Controller becomes the default controller for Kubernetes service resources with the type: LoadBalancer and makes an AWS Network Load Balancer (NLB) for each service. It does this by making a mutating webhook for services, which sets the spec.loadBalancerClass field to service.k8s.aws/nlb for new services of type: LoadBalancer. You can turn off this feature and revert to using the legacy Cloud Provider as the default controller, by setting the helm chart value enableServiceMutatorWebhook to false. The cluster won't provision new Classic Load Balancers for your services unless you turn off this feature. Existing Classic Load Balancers will continue to work.
 
 ```hcl
@@ -30,6 +29,7 @@ module "eks_blueprints_addons" {
     ]
   }
 ```
+
 ### Helm Chart customization
 
 It's possible to customize your deployment using the Helm Chart parameters inside the `aws_load_balancer_controller` configuration block:
@@ -60,7 +60,6 @@ It's possible to customize your deployment using the Helm Chart parameters insid
 
 You can find all available Helm Chart parameter values [here](https://github.com/kubernetes-sigs/aws-load-balancer-controller/blob/main/helm/aws-load-balancer-controller/values.yaml).
 
-
 ## Validate
 
 1. To validate the deployment, check if the `aws-load-balancer-controller` Pods were created in the `kube-system` Namespace, as the following example.

docs/addons/cert-manager.md

@@ -56,7 +56,7 @@ NAME                        READY   STATUS   AGE
 selfsigned-cluster-issuer   True             3m
 ```
 
-2. Create a Certificate in a given Namespace.
+3. Create a Certificate in a given Namespace.
 
 ```yaml
 apiVersion: cert-manager.io/v1
@@ -77,7 +77,7 @@ spec:
     group: cert-manager.io
 ```
 
-3.  Check the `certificate` status in it should be in `Ready` state, and be pointing to a `secret` created in the same Namespace.
+4. Check the `certificate` status in it should be in `Ready` state, and be pointing to a `secret` created in the same Namespace.
 
 ```sh
 kubectl get certificate -o wide

docs/addons/external-dns.md

@@ -37,6 +37,6 @@ To further configure external-dns, refer to the examples:
 
 * [AWS Load Balancer Controller](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws-load-balancer-controller.md)
 * [Route53](docs/tutorials/aws.md)
-    * [Same domain for public and private Route53 zones](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/public-private-route53.md)
+  * [Same domain for public and private Route53 zones](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/public-private-route53.md)
 * [Cloud Map](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws-sd.md)
 * [Kube Ingress AWS Controller](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/kube-ingress-aws.md)

docs/addons/fargate-fluentbit.md

@@ -26,6 +26,7 @@ It's possible to customize the CloudWatch Log Group parameters in the `fargate_f
   retention_in_days = 7
   kms_key_id        = "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
   skip_destroy      = true
+  }
 ```
 
 ## Validation

docs/addons/velero.md

@@ -7,7 +7,7 @@
 
 ## Usage
 
-[Velero](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/modules/kubernetes-addons/velero) can be deployed by enabling the add-on via the following.
+Velero can be deployed by enabling the add-on via the following.
 
 ```hcl
 enable_velero           = true
@@ -36,7 +36,6 @@ To see a working example, see the [`stateful`](https://github.com/aws-ia/terrafo
 
 ## Validate
 
-
 1. Run `update-kubeconfig` command:
 
 ```bash

docs/addons/vertical-pod-autoscaler.md

@@ -1,4 +1,5 @@
 # Vertical Pod Autoscaler
+
 [VPA](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) Vertical Pod Autoscaler (VPA) automatically adjusts the CPU and memory reservations for your pods to help "right size" your applications. When configured, it will automatically request the necessary reservations based on usage and thus allow proper scheduling onto nodes so that the appropriate resource amount is available for each pod. It will also maintain ratios between limits and requests that were specified in initial container configuration.
 
 NOTE: Metrics Server add-on is a dependency for this addon