docs: Update documentation to align format across project (as much as possible) (aws-ia#1759)

Author: bryantbiggs

CONTRIBUTING.md

@@ -46,7 +46,7 @@ Looking at the existing issues is a great way to find something to contribute on
 
 This project has adopted the [Amazon Open Source Code of Conduct](https://aws.github.io/code-of-conduct).
 For more information see the [Code of Conduct FAQ](https://aws.github.io/code-of-conduct-faq) or contact
-opensource-codeofconduct@amazon.com with any additional questions or comments.
+<opensource-codeofconduct@amazon.com> with any additional questions or comments.
 
 ## Security issue notifications
 

docs/_partials/destroy.md

@@ -0,0 +1,7 @@
+```sh
+terraform destroy -target="module.eks_blueprints_addons" -auto-approve
+terraform destroy -target="module.eks" -auto-approve
+terraform destroy -auto-approve
+```
+
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#destroy) for more details on cleaning up the resources created.

docs/patterns/sso-iam-identity-center.md

@@ -3,5 +3,5 @@ title: SSO - IAM Identity Center
 ---
 
 {%
-   include-markdown "../../patterns/single-sign-on/iam-identity-center/README.md"
+   include-markdown "../../patterns/sso-iam-identity-center/README.md"
 %}

docs/patterns/sso-okta.md

@@ -3,5 +3,5 @@ title: SSO - Okta
 ---
 
 {%
-   include-markdown "../../patterns/single-sign-on/okta/README.md"
+   include-markdown "../../patterns/sso-okta/README.md"
 %}

patterns/agones-game-controller/README.md

@@ -1,154 +1,63 @@
 # Amazon EKS Deployment with Agones Gaming Kubernetes Controller
 
-This example shows how to deploy and run Gaming applications on Amazon EKS with Agones Kubernetes Controller
+This pattern shows how to deploy and run gaming applications on Amazon EKS using the Agones Kubernetes Controller
 
-- Deploy Private VPC, Subnets and all the required VPC endpoints
-- Deploy EKS Cluster with one managed node group in an VPC
-- Deploy Agones Kubernetes Controller using Helm Providers
-- Deploy a simple gaming server and test the application
-
-# What is Agones
-
-Agones is an Open source Kubernetes Controller with custom resource definitions and is used to create, run, manage and scale dedicated game server processes within Kubernetes clusters using standard Kubernetes tooling and APIs.
+Agones is an open source Kubernetes controller that provisions and manages dedicated game server
+processes within Kubernetes clusters using standard Kubernetes tooling and APIs.
 This model also allows any matchmaker to interact directly with Agones via the Kubernetes API to provision a dedicated game server
 
-# What is GameLift
-
 Amazon GameLift enables developers to deploy, operate, and scale dedicated, low-cost servers in the cloud for session-based, multiplayer games.
-Built on AWS global computing infrastructure, GameLift helps deliver high-performance, high-reliability, low-cost game servers while dynamically scaling your resource usage to meet worldwide player demand.
-
-## How to Deploy
-
-### Prerequisites:
-
-Ensure that you have installed the following tools in your Mac or Windows Laptop before start working with this module and run Terraform Plan and Apply
-
-1. [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [Kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [Terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
-
-### Deployment Steps
-
-#### Step 1: Clone the repo using the command below
-
-```sh
-git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git
-```
-
-#### Step 2: Run Terraform INIT
-
-Initialize a working directory with configuration files
-
-```sh
-cd patterns/game-tech/agones-game-controller
-terraform init
-```
-
-#### Step 3: Run Terraform PLAN
-
-Verify the resources created by this execution
-
-```sh
-export AWS_REGION=<ENTER YOUR REGION>   # Select your own region
-terraform plan
-```
-
-#### Step 4: Finally, Terraform APPLY
-
-**Deploy the pattern**
-
-```sh
-terraform apply
-```
-
-Enter `yes` to apply.
+Built on AWS global computing infrastructure, GameLift helps deliver high-performance, high-reliability,
+low-cost game servers while dynamically scaling your resource usage to meet worldwide player demand. See below
+for more information on how GameLift FleetIQ can be integrated with Agones deployed on Amazon EKS.
 
+Amazon GameLift FleetIQ optimizes the use of low-cost Spot Instances for cloud-based game hosting with Amazon EC2.
+With GameLift FleetIQ, you can work directly with your hosting resources in Amazon EC2 and Auto Scaling while
+taking advantage of GameLift optimizations to deliver inexpensive, resilient game hosting for your players
+and makes the use of low-cost Spot Instances viable for game hosting
 
-#### Configure `kubectl` and test cluster
+This [blog](https://aws.amazon.com/blogs/gametech/introducing-the-gamelift-fleetiq-adapter-for-agones/) walks
+through the details of deploying EKS Cluster using eksctl and deploy Agones with GameLift FleetIQ.
 
-EKS Cluster details can be extracted from terraform output or from AWS Console to get the name of cluster.
-This following command used to update the `kubeconfig` in your local machine where you run kubectl commands to interact with your EKS Cluster.
+## Deploy
 
-#### Step 5: Run `update-kubeconfig` command
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
-`~/.kube/config` file gets updated with cluster details and certificate from the below command
+## Validate
 
-    $ aws eks --region <enter-your-region> update-kubeconfig --name <cluster-name>
-
-#### Step 6: List all the worker nodes by running the command below
-
-    $ kubectl get nodes
-
-#### Step 7: List all the pods running in `agones-system` namespace
-
-    $ kubectl get pods -n agones-system
-
-#### Step 8: Install K9s (OPTIONAL)
-
-This step is to install K9s client tool to interact with EKS Cluster
-
-     curl -sS https://webinstall.dev/k9s | bash
-
-Just type k9s after the installation and then you will see the output like this
-
-         k9s
-
-![Alt Text](https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/9c6f8ea3e710f7b0137be07835653a2bf4f9fdfe/images/k9s-agones-cluster.png "K9s")
-
-
-#### Step 9: Deploying the Sample game server
+1. Deploy the sample game server
 
+    ```sh
     kubectl create -f https://raw.githubusercontent.com/googleforgames/agones/release-1.32.0/examples/simple-game-server/gameserver.yaml
-
-
     kubectl get gs
+    ```
 
-Output looks like below
-
+    ```text
     NAME                       STATE   ADDRESS         PORT   NODE                                        AGE
     simple-game-server-7r6jr   Ready   34.243.345.22   7902   ip-10-1-23-233.eu-west-1.compute.internal   11h
+    ```
 
-#### Step 10: Testing the Sample Game Server
-
-    sudo yum install netcat
-
-    nc -u <ADDRESS> <PORT>
-
-    e.g.,  nc -u 34.243.345.22 7902
+2. Test the sample game server using [`netcat`](https://netcat.sourceforge.net/)
 
-Output looks like below
+    ```sh
+    echo -n "UDP test - Hello EKS Blueprints!" | nc -u 34.243.345.22 7902
+    ```
 
-    TeamRole:~/environment/eks-blueprints (main) $ echo -n "UDP test - Hello Workshop" | nc -u 34.243.345.22 7902
-    Hello Workshop
-    ACK: Hello Workshop
+    ```text
+    Hello EKS Blueprints!
+    ACK: Hello EKS Blueprints!
     EXIT
     ACK: EXIT
+    ```
 
-# Deploy GameLift FleetIQ
-
-Amazon GameLift FleetIQ optimizes the use of low-cost Spot Instances for cloud-based game hosting with Amazon EC2. With GameLift FleetIQ, you can work directly with your hosting resources in Amazon EC2 and Auto Scaling while taking advantage of GameLift optimizations to deliver inexpensive, resilient game hosting for your players and makes the use of low-cost Spot Instances viable for game hosting
-
-This [blog](https://aws.amazon.com/blogs/gametech/introducing-the-gamelift-fleetiq-adapter-for-agones/) will go through the details of deploying EKS Cluster using eksctl and deploy Agones with GameLift FleetIQ
-
-Download the sh and execute
+## Destroy
 
-    curl -O https://raw.githubusercontent.com/awslabs/fleetiq-adapter-for-agones/master/Agones_EKS_FleetIQ_Integration_Package%5BBETA%5D/quick_install/fleet_eks_agones_quickinstall.sh
-
-## Cleanup
-
-To clean up your environment, destroy the Terraform modules in reverse order.
-
-Destroy the Kubernetes Add-ons, EKS cluster with Node groups and VPC
+Delete the resources created by the sample game server first:
 
 ```sh
-terraform destroy -target="helm_release.agones" -auto-approve
-terraform destroy -target="module.eks_blueprints_addons" -auto-approve
-terraform destroy -target="module.eks" -auto-approve
-terraform destroy -target="module.vpc" -auto-approve
+kubectl -n default delete gs --all || true
 ```
 
-Finally, destroy any additional resources that are not in the above modules
-
-```sh
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/agones-game-controller/destroy.sh

@@ -71,6 +71,7 @@ module "eks" {
       max_size       = 5
       desired_size   = 2
     }
+
     agones_system = {
       instance_types = ["m5.large"]
       labels = {
@@ -87,6 +88,7 @@ module "eks" {
       max_size     = 1
       desired_size = 1
     }
+
     agones_metrics = {
       instance_types = ["m5.large"]
       labels = {
@@ -123,7 +125,6 @@ module "eks" {
       type                          = "ingress"
       source_cluster_security_group = true
     }
-
   }
 
   tags = local.tags
@@ -135,7 +136,7 @@ module "eks" {
 
 module "eks_blueprints_addons" {
   source  = "aws-ia/eks-blueprints-addons/aws"
-  version = "~> 1.0"
+  version = "~> 1.7"
 
   cluster_name      = module.eks.cluster_name
   cluster_endpoint  = module.eks.cluster_endpoint
@@ -153,32 +154,25 @@ module "eks_blueprints_addons" {
   enable_metrics_server     = true
   enable_cluster_autoscaler = true
 
-  tags = local.tags
-}
-
-################################################################################
-# Agones Helm Chart
-################################################################################
+  helm_releases = {
+    agones = {
+      description      = "A Helm chart for Agones game server"
+      namespace        = "agones-system"
+      create_namespace = true
+      chart            = "agones"
+      chart_version    = "1.32.0"
+      repository       = "https://agones.dev/chart/stable"
+      values = [
+        templatefile("${path.module}/helm_values/agones-values.yaml", {
+          expose_udp         = true
+          gameserver_minport = local.gameserver_minport
+          gameserver_maxport = local.gameserver_maxport
+        })
+      ]
+    }
+  }
 
-# NOTE: Agones requires a Node group in Public Subnets and enable Public IP
-resource "helm_release" "agones" {
-  name             = "agones"
-  chart            = "agones"
-  version          = "1.32.0"
-  repository       = "https://agones.dev/chart/stable"
-  description      = "Agones helm chart"
-  namespace        = "agones-system"
-  create_namespace = true
-
-  values = [templatefile("${path.module}/helm_values/agones-values.yaml", {
-    expose_udp         = true
-    gameserver_minport = local.gameserver_minport
-    gameserver_maxport = local.gameserver_maxport
-  })]
-
-  depends_on = [
-    module.eks_blueprints_addons
-  ]
+  tags = local.tags
 }
 
 ################################################################################

patterns/agones-game-controller/main.tf

@@ -94,7 +94,7 @@ module "eks" {
 
 module "eks_blueprints_addons" {
   source  = "aws-ia/eks-blueprints-addons/aws"
-  version = "~> 1.0"
+  version = "~> 1.7"
 
   cluster_name      = module.eks.cluster_name
   cluster_endpoint  = module.eks.cluster_endpoint

patterns/appmesh-mtls/README.md

@@ -1,58 +1,24 @@
 # Amazon EKS Cluster w/ ArgoCD
 
-This example shows how to provision an EKS cluster with:
+This pattern demonstrates an EKS cluster that uses ArgoCD for application deployments.
 
-- ArgoCD
-  - Workloads and addons deployed by ArgoCD
-
-To better understand how ArgoCD works with EKS Blueprints, read the EKS Blueprints ArgoCD [Documentation](https://aws-ia.github.io/terraform-aws-eks-blueprints/latest/add-ons/argocd/)
-
-## Reference Documentation
-
-- [Documentation](https://aws-ia.github.io/terraform-aws-eks-blueprints/latest/add-ons/argocd/)
+- [Documentation](https://argo-cd.readthedocs.io/en/stable/)
 - [EKS Blueprints Add-ons Repo](https://github.com/aws-samples/eks-blueprints-add-ons)
 - [EKS Blueprints Workloads Repo](https://github.com/aws-samples/eks-blueprints-workloads)
 
-## Prerequisites
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
-
-### Minimum IAM Policy
-
-> **Note**: The policy resource is set as `*` to allow all resources, this is not a recommended practice.
-
-You can find the policy [here](min-iam-policy.json)
-
 ## Deploy
 
-To provision this example:
-
-```sh
-terraform init
-terraform apply
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
-The following command will update the `kubeconfig` on your local machine and allow you to interact with your EKS Cluster using `kubectl` to validate the deployment.
-
-1. Run `update-kubeconfig` command:
-
-    ```sh
-    aws eks --region <REGION> update-kubeconfig --name <CLUSTER_NAME> --alias <CLUSTER_NAME>
-    ```
-
-2. List out the pods running currently:
+1. List out the pods running currently:
 
     ```sh
     kubectl get pods -A
+    ```
 
+    ```text
     NAMESPACE        NAME                                                        READY   STATUS    RESTARTS          AGE
     argo-rollouts    argo-rollouts-5d47ccb8d4-854s6                              1/1     Running   0                 23h
     argo-rollouts    argo-rollouts-5d47ccb8d4-srjk9                              1/1     Running   0                 23h
@@ -118,7 +84,7 @@ The following command will update the `kubeconfig` on your local machine and all
     team-riker       guestbook-ui-c86c478bd-zg2z4                                1/1     Running   0                 25m
     ```
 
-3. You can access the ArgoCD UI by running the following command:
+2. Access the ArgoCD UI by running the following command:
 
     ```sh
     kubectl port-forward svc/argo-cd-argocd-server 8080:443 -n argocd
@@ -140,17 +106,12 @@ The following command will update the `kubeconfig` on your local machine and all
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
 First, we need to ensure that the ArgoCD applications are properly cleaned up from the cluster, this can be achieved in multiple ways:
 
-1) Disabling the `argocd_applications` configuration and running `terraform apply` again
-2) Deleting the apps using `argocd` [cli](https://argo-cd.readthedocs.io/en/stable/user-guide/app_deletion/#deletion-using-argocd)
-3) Deleting the apps using `kubectl` following [ArgoCD guidance](https://argo-cd.readthedocs.io/en/stable/user-guide/app_deletion/#deletion-using-kubectl)
+- Disabling the `argocd_applications` configuration and running `terraform apply` again
+- Deleting the apps using `argocd` [cli](https://argo-cd.readthedocs.io/en/stable/user-guide/app_deletion/#deletion-using-argocd)
+- Deleting the apps using `kubectl` following [ArgoCD guidance](https://argo-cd.readthedocs.io/en/stable/user-guide/app_deletion/#deletion-using-kubectl)
 
-Then you can start delete the terraform resources:
-```sh
-terraform destroy -target=module.eks_blueprints_kubernetes_addons -auto-approve
-terraform destroy -target=module.eks -auto-approve
-terraform destroy -auto-approve
-````
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/appmesh-mtls/main.tf

@@ -1,245 +1,138 @@
 # EKS Cluster w/ Elastic Fabric Adapter
 
-This example shows how to provision an Amazon EKS Cluster with an EFA-enabled nodegroup.
-
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
+This pattern demonstrates an Amazon EKS Cluster with an EFA-enabled nodegroup.
 
 ## Deploy
 
-To provision this example:
-
-```sh
-terraform init
-terraform apply
-
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
-1. Run `update-kubeconfig` command, using the Terraform provided Output, replace with your `$AWS_REGION` and your `$CLUSTER_NAME` variables.
-
-```sh
-aws eks --region <$AWS_REGION> update-kubeconfig --name <$CLUSTER_NAME>
-```
-
-2. Test by listing Nodes in in the Cluster, you should see Fargate instances as your Cluster Nodes.
-
-```sh
-kubectl get nodes
-kubectl get nodes -o yaml | grep instance-type | grep node | grep -v f:
-```
-
-Your nodes and node types will be listed:
-
-```text
-# kubectl get nodes
-NAME                           STATUS   ROLES    AGE    VERSION
-ip-10-11-10-103.ec2.internal   Ready    <none>   4m1s   v1.25.7-eks-a59e1f0
-ip-10-11-19-28.ec2.internal    Ready    <none>   11m    v1.25.7-eks-a59e1f0
-ip-10-11-2-151.ec2.internal    Ready    <none>   11m    v1.25.7-eks-a59e1f0
-ip-10-11-2-18.ec2.internal     Ready    <none>   5m1s   v1.25.7-eks-a59e1f0
-# kubectl get nodes -o yaml | grep instance-type | grep node | grep -v f:
-      node.kubernetes.io/instance-type: g5.8xlarge
-      node.kubernetes.io/instance-type: m5.large
-      node.kubernetes.io/instance-type: m5.large
-      node.kubernetes.io/instance-type: g5.8xlarge
-```
-
-You should see two EFA-enabled (in this example `g5.8xlarge`) nodes in the list.
-This verifies that you are connected to your EKS cluster and it is configured with EFA nodes.
-
-3. Deploy Kubeflow MPI Operator
-
-Kubeflow MPI Operator is required for running MPIJobs on EKS. We will use an MPIJob to test EFA.
-To deploy the MPI operator execute the following:
-
-```sh
-kubectl apply -f https://raw.githubusercontent.com/kubeflow/mpi-operator/v0.3.0/deploy/v2beta1/mpi-operator.yaml
-```
-
-Output:
-
-```text
-namespace/mpi-operator created
-customresourcedefinition.apiextensions.k8s.io/mpijobs.kubeflow.org created
-serviceaccount/mpi-operator created
-clusterrole.rbac.authorization.k8s.io/kubeflow-mpijobs-admin created
-clusterrole.rbac.authorization.k8s.io/kubeflow-mpijobs-edit created
-clusterrole.rbac.authorization.k8s.io/kubeflow-mpijobs-view created
-clusterrole.rbac.authorization.k8s.io/mpi-operator created
-clusterrolebinding.rbac.authorization.k8s.io/mpi-operator created
-deployment.apps/mpi-operator created
-```
-
-In addition to deploying the operator, please apply a patch to the mpi-operator clusterrole
-to allow the mpi-operator service account access to `leases` resources in the `coordination.k8s.io` apiGroup.
-
-```sh
-kubectl apply -f https://raw.githubusercontent.com/aws-samples/aws-do-eks/main/Container-Root/eks/deployment/kubeflow/mpi-operator/clusterrole-mpi-operator.yaml
-```
-
-Output:
-
-```text
-clusterrole.rbac.authorization.k8s.io/mpi-operator configured
-```
-
-4. Test EFA
-
-We will run two tests. The first one will show the presence of EFA adapters on our EFA-enabled nodes. The second will test EFA performance.
-
-5. EFA Info Test
-
-To run the EFA info test, execute the following commands:
-
-```sh
-kubectl apply -f https://raw.githubusercontent.com/aws-samples/aws-do-eks/main/Container-Root/eks/deployment/efa-device-plugin/test-efa.yaml
-```
-
-Output:
-
-```text
-mpijob.kubeflow.org/efa-info-test created
-```
-
-```sh
-kubectl get pods
-```
+1. List the nodes by instance type:
 
-Output:
+    ```sh
+    kubectl get nodes -o yaml | grep instance-type | grep node | grep -v f:
+    ```
 
-```text
-NAME                           READY   STATUS      RESTARTS   AGE
-efa-info-test-launcher-hckkj   0/1     Completed   2          37s
-efa-info-test-worker-0         1/1     Running     0          38s
-efa-info-test-worker-1         1/1     Running     0          38s
-```
-
-Once the test launcher pod enters status `Running` or `Completed`, see the test logs using the command below:
-
-```sh
-kubectl logs -f $(kubectl get pods | grep launcher | cut -d ' ' -f 1)
-```
-
-Output:
-
-```text
-Warning: Permanently added 'efa-info-test-worker-1.efa-info-test-worker.default.svc,10.11.13.224' (ECDSA) to the list of known hosts.
-Warning: Permanently added 'efa-info-test-worker-0.efa-info-test-worker.default.svc,10.11.4.63' (ECDSA) to the list of known hosts.
-[1,1]<stdout>:provider: efa
-[1,1]<stdout>:    fabric: efa
-[1,1]<stdout>:    domain: rdmap197s0-rdm
-[1,1]<stdout>:    version: 116.10
-[1,1]<stdout>:    type: FI_EP_RDM
-[1,1]<stdout>:    protocol: FI_PROTO_EFA
-[1,0]<stdout>:provider: efa
-[1,0]<stdout>:    fabric: efa
-[1,0]<stdout>:    domain: rdmap197s0-rdm
-[1,0]<stdout>:    version: 116.10
-[1,0]<stdout>:    type: FI_EP_RDM
-[1,0]<stdout>:    protocol: FI_PROTO_EFA
-```
-
-This result shows that two EFA adapters are available (one for each worker pod).
-
-Lastly, delete the test job:
-
-```sh
-kubectl delete mpijob efa-info-test
-```
-
-Output:
-
-```text
-mpijob.kubeflow.org "efa-info-test" deleted
-```
-
-6. EFA NCCL Test
-
-To run the EFA NCCL test please execute the following kubectl command:
-
-```sh
-kubectl apply -f https://raw.githubusercontent.com/aws-samples/aws-do-eks/main/Container-Root/eks/deployment/efa-device-plugin/test-nccl-efa.yaml
-```
-
-Output:
-
-```text
-mpijob.kubeflow.org/test-nccl-efa created
-```
-
-Then display the pods in the current namespace:
-
-```sh
-kubectl get pods
-```
-
-Output:
-
-```text
-NAME                           READY   STATUS    RESTARTS      AGE
-test-nccl-efa-launcher-tx47t   1/1     Running   2 (31s ago)   33s
-test-nccl-efa-worker-0         1/1     Running   0             33s
-test-nccl-efa-worker-1         1/1     Running   0             33s
-```
-
-Once the launcher pod enters `Running` or `Completed` state, execute the following to see the test logs:
-
-```sh
-kubectl logs -f $(kubectl get pods | grep launcher | cut -d ' ' -f 1)
-```
-
-The following section from the beginning of the log, indicates that the test is being performed using EFA:
-
-```text
-[1,0]<stdout>:test-nccl-efa-worker-0:21:21 [0] NCCL INFO NET/OFI Selected Provider is efa (found 1 nics)
-[1,0]<stdout>:test-nccl-efa-worker-0:21:21 [0] NCCL INFO Using network AWS Libfabric
-[1,0]<stdout>:NCCL version 2.12.7+cuda11.4
-```
-
-Columns 8 and 12 in the output table show the in-place and out-of-place bus bandwidth calculated for the data size listed in column 1. In this case it is 3.13 and 3.12 GB/s respectively.
-Your actual results may be slightly different. The calculated average bus bandwidth is displayed at the bottom of the log when the test finishes after it reaches the max data size,
-specified in the mpijob manifest. In this result the average bus bandwidth is 1.15 GB/s.
-
-```
-[1,0]<stdout>:#       size         count      type   redop    root     time   algbw   busbw #wrong     time   algbw   busbw #wrong
-[1,0]<stdout>:#        (B)    (elements)                               (us)  (GB/s)  (GB/s)            (us)  (GB/s)  (GB/s)
-...
-[1,0]<stdout>:      262144         65536     float     sum      -1    195.0    1.34    1.34      0    194.0    1.35    1.35      0
-[1,0]<stdout>:      524288        131072     float     sum      -1    296.9    1.77    1.77      0    291.1    1.80    1.80      0
-[1,0]<stdout>:     1048576        262144     float     sum      -1    583.4    1.80    1.80      0    579.6    1.81    1.81      0
-[1,0]<stdout>:     2097152        524288     float     sum      -1    983.3    2.13    2.13      0    973.9    2.15    2.15      0
-[1,0]<stdout>:     4194304       1048576     float     sum      -1   1745.4    2.40    2.40      0   1673.2    2.51    2.51      0
-...
-[1,0]<stdout>:# Avg bus bandwidth    : 1.15327
-```
-
-Finally, delete the test mpi job:
-
-```sh
-kubectl delete mpijob test-nccl-efa
-```
-
-Output:
-
-```text
-mpijob.kubeflow.org "test-nccl-efa" deleted
-```
+    ```text
+    node.kubernetes.io/instance-type: g5.8xlarge
+    node.kubernetes.io/instance-type: m5.large
+    node.kubernetes.io/instance-type: m5.large
+    node.kubernetes.io/instance-type: g5.8xlarge
+    ```
+
+    You should see two EFA-enabled (in this example `g5.8xlarge`) nodes in the list.
+
+2. Deploy Kubeflow MPI Operator
+
+    Kubeflow MPI Operator is required for running MPIJobs on EKS. We will use an MPIJob to test EFA.
+    To deploy the MPI operator execute the following:
+
+    ```sh
+    kubectl apply -f https://raw.githubusercontent.com/kubeflow/mpi-operator/v0.3.0/deploy/v2beta1/mpi-operator.yaml
+    ```
+
+    ```text
+    namespace/mpi-operator created
+    customresourcedefinition.apiextensions.k8s.io/mpijobs.kubeflow.org created
+    serviceaccount/mpi-operator created
+    clusterrole.rbac.authorization.k8s.io/kubeflow-mpijobs-admin created
+    clusterrole.rbac.authorization.k8s.io/kubeflow-mpijobs-edit created
+    clusterrole.rbac.authorization.k8s.io/kubeflow-mpijobs-view created
+    clusterrole.rbac.authorization.k8s.io/mpi-operator created
+    clusterrolebinding.rbac.authorization.k8s.io/mpi-operator created
+    deployment.apps/mpi-operator created
+    ```
+
+    In addition to deploying the operator, please apply a patch to the mpi-operator clusterrole
+    to allow the mpi-operator service account access to `leases` resources in the `coordination.k8s.io` apiGroup.
+
+    ```sh
+    kubectl apply -f https://raw.githubusercontent.com/aws-samples/aws-do-eks/main/Container-Root/eks/deployment/kubeflow/mpi-operator/clusterrole-mpi-operator.yaml
+    ```
+
+    ```text
+    clusterrole.rbac.authorization.k8s.io/mpi-operator configured
+    ```
+
+3. EFA test
+
+    The results should shown that two EFA adapters are available (one for each worker pod)
+
+    ```sh
+    kubectl apply -f https://raw.githubusercontent.com/aws-samples/aws-do-eks/main/Container-Root/eks/deployment/efa-device-plugin/test-efa.yaml
+    ```
+
+    ```text
+    mpijob.kubeflow.org/efa-info-test created
+    ```
+
+    Once the test launcher pod enters status `Running` or `Completed`, see the test logs using the command below:
+
+    ```sh
+    kubectl logs -f $(kubectl get pods | grep launcher | cut -d ' ' -f 1)
+    ```
+
+    ```text
+    Warning: Permanently added 'efa-info-test-worker-1.efa-info-test-worker.default.svc,10.11.13.224' (ECDSA) to the list of known hosts.
+    Warning: Permanently added 'efa-info-test-worker-0.efa-info-test-worker.default.svc,10.11.4.63' (ECDSA) to the list of known hosts.
+    [1,1]<stdout>:provider: efa
+    [1,1]<stdout>:    fabric: efa
+    [1,1]<stdout>:    domain: rdmap197s0-rdm
+    [1,1]<stdout>:    version: 116.10
+    [1,1]<stdout>:    type: FI_EP_RDM
+    [1,1]<stdout>:    protocol: FI_PROTO_EFA
+    [1,0]<stdout>:provider: efa
+    [1,0]<stdout>:    fabric: efa
+    [1,0]<stdout>:    domain: rdmap197s0-rdm
+    [1,0]<stdout>:    version: 116.10
+    [1,0]<stdout>:    type: FI_EP_RDM
+    [1,0]<stdout>:    protocol: FI_PROTO_EFA
+    ```
+
+4. EFA NCCL test
+
+    To run the EFA NCCL test please execute the following kubectl command:
+
+    ```sh
+    kubectl apply -f https://raw.githubusercontent.com/aws-samples/aws-do-eks/main/Container-Root/eks/deployment/efa-device-plugin/test-nccl-efa.yaml
+    ```
+
+    ```text
+    mpijob.kubeflow.org/test-nccl-efa created
+    ```
+
+    Once the launcher pod enters `Running` or `Completed` state, execute the following to see the test logs:
+
+    ```sh
+    kubectl logs -f $(kubectl get pods | grep launcher | cut -d ' ' -f 1)
+    ```
+
+    ```text
+    [1,0]<stdout>:test-nccl-efa-worker-0:21:21 [0] NCCL INFO NET/OFI Selected Provider is efa (found 1 nics)
+    [1,0]<stdout>:test-nccl-efa-worker-0:21:21 [0] NCCL INFO Using network AWS Libfabric
+    [1,0]<stdout>:NCCL version 2.12.7+cuda11.4
+    ```
+
+    Columns 8 and 12 in the output table show the in-place and out-of-place bus bandwidth calculated for the data size listed in column 1. In this case it is 3.13 and 3.12 GB/s respectively.
+    Your actual results may be slightly different. The calculated average bus bandwidth is displayed at the bottom of the log when the test finishes after it reaches the max data size,
+    specified in the mpijob manifest. In this result the average bus bandwidth is 1.15 GB/s.
+
+    ```text
+    [1,0]<stdout>:#       size         count      type   redop    root     time   algbw   busbw #wrong     time   algbw   busbw #wrong
+    [1,0]<stdout>:#        (B)    (elements)                               (us)  (GB/s)  (GB/s)            (us)  (GB/s)  (GB/s)
+    ...
+    [1,0]<stdout>:      262144         65536     float     sum      -1    195.0    1.34    1.34      0    194.0    1.35    1.35      0
+    [1,0]<stdout>:      524288        131072     float     sum      -1    296.9    1.77    1.77      0    291.1    1.80    1.80      0
+    [1,0]<stdout>:     1048576        262144     float     sum      -1    583.4    1.80    1.80      0    579.6    1.81    1.81      0
+    [1,0]<stdout>:     2097152        524288     float     sum      -1    983.3    2.13    2.13      0    973.9    2.15    2.15      0
+    [1,0]<stdout>:     4194304       1048576     float     sum      -1   1745.4    2.40    2.40      0   1673.2    2.51    2.51      0
+    ...
+    [1,0]<stdout>:# Avg bus bandwidth    : 1.15327
+    ```
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
-```sh
-terraform destroy -target module.eks_blueprints_addons -auto-approve
-terraform destroy -target module.eks -auto-approve
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/argocd/README.md

@@ -1,83 +1,25 @@
 # Amazon EKS Cluster w/ External Secrets Operator
 
-This example deploys an EKS Cluster with the External Secrets Operator. The cluster is populated with a ClusterSecretStore and SecretStore example using SecretManager and Parameter Store respectively. A secret for each store is also created. Both stores use IRSA to retrieve the secret values from AWS.
+This pattern deploys an EKS Cluster with the External Secrets Operator.
+The cluster is populated with a ClusterSecretStore and SecretStore example
+using SecretManager and Parameter Store respectively. A secret for each
+store is also created. Both stores use IRSA to retrieve the secret values from AWS.
 
-## How to Deploy
+## Deploy
 
-### Prerequisites:
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
-Ensure that you have installed the following tools in your Mac or Windows Laptop before start working with this module and run Terraform Plan and Apply
+## Validate
 
-1. [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [Kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [Terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
+1. List the secret resources in the `external-secrets` namespace
 
-### Deployment Steps
+    ```sh
+    kubectl get externalsecrets -n external-secrets
+    kubectl get secrets -n external-secrets
+    ```
 
-#### Step 1: Clone the repo using the command below
+## Destroy
 
-```sh
-git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git
-```
-
-#### Step 2: Run Terraform INIT
-
-Initialize a working directory with configuration files
-
-```sh
-cd patterns/external-secrets/
-terraform init
-```
-
-#### Step 3: Run Terraform PLAN
-
-Verify the resources created by this execution
-
-```sh
-export AWS_REGION=<ENTER YOUR REGION>   # Select your own region
-terraform plan
-```
-
-#### Step 4: Finally, Terraform APPLY
-
-**Deploy the pattern**
-
-```sh
-terraform apply
-```
-
-Enter `yes` to apply.
-
-### Configure `kubectl` and test cluster
-
-EKS Cluster details can be extracted from terraform output or from AWS Console to get the name of cluster.
-This following command used to update the `kubeconfig` in your local machine where you run kubectl commands to interact with your EKS Cluster.
-
-#### Step 5: Run `update-kubeconfig` command
-
-`~/.kube/config` file gets updated with cluster details and certificate from the below command
-
-    $ aws eks --region <enter-your-region> update-kubeconfig --name <cluster-name>
-
-### Step 6: List the secret resources in the `external-secrets` namespace
-
-    $ kubectl get externalsecrets -n external-secrets
-    $ kubectl get secrets -n external-secrets
-
-## Cleanup
-
-To clean up your environment, destroy the Terraform modules in reverse order.
-
-Destroy the Kubernetes Add-ons, EKS cluster with Node groups and VPC
-
-```sh
-terraform destroy -target="module.eks_blueprints_kubernetes_addons" -auto-approve
-terraform destroy -target="module.eks_blueprints" -auto-approve
-terraform destroy -target="module.vpc" -auto-approve
-```
-
-Finally, destroy any additional resources that are not in the above modules
-
-```sh
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/argocd/min-iam-policy.json

@@ -1,193 +1,172 @@
 # Serverless Amazon EKS Cluster
 
-This example shows how to provision an Amazon EKS Cluster (serverless data plane) using Fargate Profiles.
+This pattern demonstrates an Amazon EKS Cluster that utilizes Fargate profiles for a serverless data plane.
 
-This example solution provides:
+## Deploy
 
-- AWS EKS Cluster (control plane)
-- AWS EKS Fargate Profiles for the `kube-system` namespace which is used by the `coredns`, `vpc-cni`, and `kube-proxy` addons, as well as profile that will match on `app-*` namespaces using a wildcard pattern.
-- AWS EKS managed addons `coredns`, `vpc-cni` and `kube-proxy`
-- AWS Load Balancer Controller add-on deployed through a Helm chart. The default AWS Load Balancer Controller add-on configuration is overridden so that it can be deployed on Fargate compute.
-- A sample-app is provided (in-line) to demonstrate how to configure the Ingress so that application can be accessed over the internet.
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
-## Prerequisites:
+## Validate
 
-Ensure that you have the following tools installed locally:
+1. List the nodes in in the cluster; you should see Fargate instances:
+
+    ```sh
+    kubectl get nodes
+    ```
+
+    ```text
+    NAME                                                STATUS   ROLES    AGE   VERSION
+    fargate-ip-10-0-17-17.us-west-2.compute.internal    Ready    <none>   25m   v1.26.3-eks-f4dc2c0
+    fargate-ip-10-0-20-244.us-west-2.compute.internal   Ready    <none>   71s   v1.26.3-eks-f4dc2c0
+    fargate-ip-10-0-41-143.us-west-2.compute.internal   Ready    <none>   25m   v1.26.3-eks-f4dc2c0
+    fargate-ip-10-0-44-95.us-west-2.compute.internal    Ready    <none>   25m   v1.26.3-eks-f4dc2c0
+    fargate-ip-10-0-45-153.us-west-2.compute.internal   Ready    <none>   77s   v1.26.3-eks-f4dc2c0
+    fargate-ip-10-0-47-31.us-west-2.compute.internal    Ready    <none>   75s   v1.26.3-eks-f4dc2c0
+    fargate-ip-10-0-6-175.us-west-2.compute.internal    Ready    <none>   25m   v1.26.3-eks-f4dc2c0
+    ```
+
+2. List the pods. All the pods should reach a status of `Running` after approximately 60 seconds:
+
+    ```sh
+    kubectl get pods -A
+    ```
+
+    ```text
+    NAMESPACE       NAME                                            READY   STATUS    RESTARTS   AGE
+    app-2048        app-2048-65bd744dfb-7g9rx                       1/1     Running   0          2m34s
+    app-2048        app-2048-65bd744dfb-nxcbm                       1/1     Running   0          2m34s
+    app-2048        app-2048-65bd744dfb-z4b6z                       1/1     Running   0          2m34s
+    kube-system     aws-load-balancer-controller-6cbdb58654-fvskt   1/1     Running   0          26m
+    kube-system     aws-load-balancer-controller-6cbdb58654-sc7dk   1/1     Running   0          26m
+    kube-system     coredns-7b7bddbc85-jmbv6                        1/1     Running   0          26m
+    kube-system     coredns-7b7bddbc85-rgmzq                        1/1     Running   0          26m
+    ```
+
+3. Validate the `aws-logging` configMap for Fargate Fluentbit was created:
+
+    ```sh
+    kubectl -n aws-observability get configmap aws-logging -o yaml
+    ```
+
+    ```yaml
+    apiVersion: v1
+    data:
+      filters.conf: |
+        [FILTER]
+          Name parser
+          Match *
+          Key_Name log
+          Parser regex
+          Preserve_Key True
+          Reserve_Data True
+      flb_log_cw: "true"
+      output.conf: |
+        [OUTPUT]
+          Name cloudwatch_logs
+          Match *
+          region us-west-2
+          log_group_name /fargate-serverless/fargate-fluentbit-logs20230509014113352200000006
+          log_stream_prefix fargate-logs-
+          auto_create_group true
+      parsers.conf: |
+        [PARSER]
+          Name regex
+          Format regex
+          Regex ^(?<time>[^ ]+) (?<stream>[^ ]+) (?<logtag>[^ ]+) (?<message>.+)$
+          Time_Key time
+          Time_Format %Y-%m-%dT%H:%M:%S.%L%z
+          Time_Keep On
+          Decode_Field_As json message
+    immutable: false
+    kind: ConfigMap
+    metadata:
+      creationTimestamp: "2023-05-08T21:14:52Z"
+      name: aws-logging
+      namespace: aws-observability
+      resourceVersion: "1795"
+      uid: d822bcf5-a441-4996-857e-7fb1357bc07e
+    ```
+
+    You can also validate if the CloudWatch LogGroup was created accordingly, and LogStreams were populated:
+
+    ```sh
+    aws logs describe-log-groups \
+        --log-group-name-prefix "/fargate-serverless/fargate-fluentbit"
+    ```
+
+    ```json
+    {
+        "logGroups": [
+            {
+                "logGroupName": "/fargate-serverless/fargate-fluentbit-logs20230509014113352200000006",
+                "creationTime": 1683580491652,
+                "retentionInDays": 90,
+                "metricFilterCount": 0,
+                "arn": "arn:aws:logs:us-west-2:111222333444:log-group:/fargate-serverless/fargate-fluentbit-logs20230509014113352200000006:*",
+                "storedBytes": 0
+            }
+        ]
+    }
+    ```
+
+    ```sh
+    aws logs describe-log-streams \
+        --log-group-name "/fargate-serverless/fargate-fluentbit-logs20230509014113352200000006" \
+        --log-stream-name-prefix fargate-logs --query 'logStreams[].logStreamName'
+    ```
+
+    ```json
+    [
+        "fargate-logs-flblogs.var.log.fluent-bit.log",
+        "fargate-logs-kube.var.log.containers.aws-load-balancer-controller-7f989fc6c-grjsq_kube-system_aws-load-balancer-controller-feaa22b4cdaa71ecfc8355feb81d4b61ea85598a7bb57aef07667c767c6b98e4.log",
+        "fargate-logs-kube.var.log.containers.aws-load-balancer-controller-7f989fc6c-wzr46_kube-system_aws-load-balancer-controller-69075ea9ab3c7474eac2a1696d3a84a848a151420cd783d79aeef960b181567f.log",
+        "fargate-logs-kube.var.log.containers.coredns-7b7bddbc85-8cxvq_kube-system_coredns-9e4f3ab435269a566bcbaa606c02c146ad58508e67cef09fa87d5c09e4ac0088.log",
+        "fargate-logs-kube.var.log.containers.coredns-7b7bddbc85-gcjwp_kube-system_coredns-11016818361cd68c32bf8f0b1328f3d92a6d7b8cf5879bfe8b301f393cb011cc.log"
+    ]
+    ```
 
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
+### Example
 
-## Deploy
+1. Create an ingress resource using the AWS load balancer controller deployed, pointing to our application service:
 
-To provision this example:
+    ```sh
+    kubectl get svc -n app-2048
+    ```
 
-```sh
-terraform init
-terraform apply
+    ```text
+    NAME       TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
+    app-2048   NodePort   172.20.33.217   <none>        80:32568/TCP   2m48s
+    ```
 
-```
+    ```sh
+    kubectl -n app-2048 create ingress app-2048 --class alb --rule="/*=app-2048:80" \
+    --annotation alb.ingress.kubernetes.io/scheme=internet-facing \
+    --annotation alb.ingress.kubernetes.io/target-type=ip
+    ```
 
-Enter `yes` at command prompt to apply
+    ```sh
+    kubectl -n app-2048 get ingress
+    ```
 
-## Validate
+    ```text
+    NAME       CLASS   HOSTS   ADDRESS                                                                 PORTS   AGE
+    app-2048   alb     *       k8s-app2048-app2048-6d9c5e92d6-1234567890.us-west-2.elb.amazonaws.com   80      4m9s
+    ```
 
-The following command will update the `kubeconfig` on your local machine and allow you to interact with your EKS Cluster using `kubectl` to validate the CoreDNS deployment for Fargate.
-
-1. Check the Terraform provided Output, to update your `kubeconfig`
-
-```hcl
-Apply complete! Resources: 63 added, 0 changed, 0 destroyed.
-
-Outputs:
-
-configure_kubectl = "aws eks --region us-west-2 update-kubeconfig --name fargate-serverless"
-```
-
-2. Run `update-kubeconfig` command, using the Terraform provided Output, replace with your `$AWS_REGION` and your `$CLUSTER_NAME` variables.
-
-```sh
-aws eks --region <$AWS_REGION> update-kubeconfig --name <$CLUSTER_NAME>
-```
-
-3. Test by listing Nodes in in the Cluster, you should see Fargate instances as your Cluster Nodes.
-
-
-```sh
-kubectl get nodes
-NAME                                                STATUS   ROLES    AGE   VERSION
-fargate-ip-10-0-17-17.us-west-2.compute.internal    Ready    <none>   25m   v1.26.3-eks-f4dc2c0
-fargate-ip-10-0-20-244.us-west-2.compute.internal   Ready    <none>   71s   v1.26.3-eks-f4dc2c0
-fargate-ip-10-0-41-143.us-west-2.compute.internal   Ready    <none>   25m   v1.26.3-eks-f4dc2c0
-fargate-ip-10-0-44-95.us-west-2.compute.internal    Ready    <none>   25m   v1.26.3-eks-f4dc2c0
-fargate-ip-10-0-45-153.us-west-2.compute.internal   Ready    <none>   77s   v1.26.3-eks-f4dc2c0
-fargate-ip-10-0-47-31.us-west-2.compute.internal    Ready    <none>   75s   v1.26.3-eks-f4dc2c0
-fargate-ip-10-0-6-175.us-west-2.compute.internal    Ready    <none>   25m   v1.26.3-eks-f4dc2c0
-```
-
-4. Test by listing all the Pods running currently. All the Pods should reach a status of `Running` after approximately 60 seconds:
-
-```sh
-kubectl get pods -A
-NAMESPACE       NAME                                            READY   STATUS    RESTARTS   AGE
-app-2048        app-2048-65bd744dfb-7g9rx                       1/1     Running   0          2m34s
-app-2048        app-2048-65bd744dfb-nxcbm                       1/1     Running   0          2m34s
-app-2048        app-2048-65bd744dfb-z4b6z                       1/1     Running   0          2m34s
-kube-system     aws-load-balancer-controller-6cbdb58654-fvskt   1/1     Running   0          26m
-kube-system     aws-load-balancer-controller-6cbdb58654-sc7dk   1/1     Running   0          26m
-kube-system     coredns-7b7bddbc85-jmbv6                        1/1     Running   0          26m
-kube-system     coredns-7b7bddbc85-rgmzq                        1/1     Running   0          26m
-```
-
-5. Check if the `aws-logging` configMap for Fargate Fluentbit was created.
-
-```sh
-kubectl -n aws-observability get configmap aws-logging -o yaml
-apiVersion: v1
-data:
-  filters.conf: |
-    [FILTER]
-      Name parser
-      Match *
-      Key_Name log
-      Parser regex
-      Preserve_Key True
-      Reserve_Data True
-  flb_log_cw: "true"
-  output.conf: |
-    [OUTPUT]
-      Name cloudwatch_logs
-      Match *
-      region us-west-2
-      log_group_name /fargate-serverless/fargate-fluentbit-logs20230509014113352200000006
-      log_stream_prefix fargate-logs-
-      auto_create_group true
-  parsers.conf: |
-    [PARSER]
-      Name regex
-      Format regex
-      Regex ^(?<time>[^ ]+) (?<stream>[^ ]+) (?<logtag>[^ ]+) (?<message>.+)$
-      Time_Key time
-      Time_Format %Y-%m-%dT%H:%M:%S.%L%z
-      Time_Keep On
-      Decode_Field_As json message
-immutable: false
-kind: ConfigMap
-metadata:
-  creationTimestamp: "2023-05-08T21:14:52Z"
-  name: aws-logging
-  namespace: aws-observability
-  resourceVersion: "1795"
-  uid: d822bcf5-a441-4996-857e-7fb1357bc07e
-```
-
-You can also validate if the CloudWatch LogGroup was created accordingly, and LogStreams were populated.
-
-```sh
-aws logs describe-log-groups --log-group-name-prefix "/fargate-serverless/fargate-fluentbit"
-{
-    "logGroups": [
-        {
-            "logGroupName": "/fargate-serverless/fargate-fluentbit-logs20230509014113352200000006",
-            "creationTime": 1683580491652,
-            "retentionInDays": 90,
-            "metricFilterCount": 0,
-            "arn": "arn:aws:logs:us-west-2:111222333444:log-group:/fargate-serverless/fargate-fluentbit-logs20230509014113352200000006:*",
-            "storedBytes": 0
-        }
-    ]
-}
-```
-
-```sh
-aws logs describe-log-streams --log-group-name "/fargate-serverless/fargate-fluentbit-logs20230509014113352200000006" --log-stream-name-prefix fargate-logs --query 'logStreams[].logStreamName'
-[
-    "fargate-logs-flblogs.var.log.fluent-bit.log",
-    "fargate-logs-kube.var.log.containers.aws-load-balancer-controller-7f989fc6c-grjsq_kube-system_aws-load-balancer-controller-feaa22b4cdaa71ecfc8355feb81d4b61ea85598a7bb57aef07667c767c6b98e4.log",
-    "fargate-logs-kube.var.log.containers.aws-load-balancer-controller-7f989fc6c-wzr46_kube-system_aws-load-balancer-controller-69075ea9ab3c7474eac2a1696d3a84a848a151420cd783d79aeef960b181567f.log",
-    "fargate-logs-kube.var.log.containers.coredns-7b7bddbc85-8cxvq_kube-system_coredns-9e4f3ab435269a566bcbaa606c02c146ad58508e67cef09fa87d5c09e4ac0088.log",
-    "fargate-logs-kube.var.log.containers.coredns-7b7bddbc85-gcjwp_kube-system_coredns-11016818361cd68c32bf8f0b1328f3d92a6d7b8cf5879bfe8b301f393cb011cc.log"
-]
-```
-
-6. (Optional) Test that the sample application.
-
-Create an Ingress using the AWS LoadBalancer Controller deployed with the EKS Blueprints Add-ons module, pointing to our application Service.
-
-```sh
-kubectl get svc -n app-2048
-NAME       TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
-app-2048   NodePort   172.20.33.217   <none>        80:32568/TCP   2m48s
-```
-
-```sh
-kubectl -n app-2048 create ingress app-2048 --class alb --rule="/*=app-2048:80" \
---annotation alb.ingress.kubernetes.io/scheme=internet-facing \
---annotation alb.ingress.kubernetes.io/target-type=ip
-```
-
-```sh
-kubectl -n app-2048 get ingress
-NAME       CLASS   HOSTS   ADDRESS                                                                 PORTS   AGE
-app-2048   alb     *       k8s-app2048-app2048-6d9c5e92d6-1234567890.us-west-2.elb.amazonaws.com   80      4m9s
-```
-
-Open the browser to access the application via the URL address shown in the last output in the ADDRESS column. In our example `k8s-app2048-app2048-6d9c5e92d6-1234567890.us-west-2.elb.amazonaws.com`.
-
-> You might need to wait a few minutes, and then refresh your browser.
-> If your Ingress isn't created after several minutes, then run this command to view the AWS Load Balancer Controller logs:
-
-```sh
-kubectl logs -n kube-system deployment.apps/aws-load-balancer-controller
-```
+2. Open the browser to access the application via the URL address shown in the last output in the ADDRESS column.
 
-## Destroy
+    In our example: `k8s-app2048-app2048-6d9c5e92d6-1234567890.us-west-2.elb.amazonaws.com`
+
+    !!! info
+        You might need to wait a few minutes, and then refresh your browser.
+        If your Ingress isn't created after several minutes, then run this command to view the AWS Load Balancer Controller logs:
 
-To teardown and remove the resources created in this example:
+    ```sh
+    kubectl logs -n kube-system deployment.apps/aws-load-balancer-controller
+    ```
+
+## Destroy
 
-```sh
-kubectl -n app-2048 delete ingress app-2048
-terraform destroy -target module.eks_blueprints_addons -auto-approve
-terraform destroy -target module.eks -auto-approve
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/elastic-fabric-adapter/README.md

@@ -1,94 +1,66 @@
 # Fully Private Amazon EKS Cluster
 
-This examples demonstrates how to deploy an Amazon EKS cluster that is deployed on the AWS Cloud, but doesn't have outbound internet access. For that your cluster must pull images from a container registry that's in your VPC, and also must have endpoint private access enabled. This is required for nodes to register with the cluster endpoint.
+This pattern demonstrates an Amazon EKS cluster that does not have internet access.
+The private cluster must pull images from a container registry that is within in your VPC,
+and also must have endpoint private access enabled. This is required for nodes
+to register with the cluster endpoint.
 
 Please see this [document](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html) for more details on configuring fully private EKS Clusters.
 
-For fully Private EKS clusters requires the following VPC endpoints to be created to communicate with AWS services. This example solution will provide these endpoints if you choose to create VPC. If you are using an existing VPC then you may need to ensure these endpoints are created.
+For fully Private EKS clusters requires the following VPC endpoints to be created to communicate with AWS services.
+This example solution will provide these endpoints if you choose to create VPC.
+If you are using an existing VPC then you may need to ensure these endpoints are created.
 
-    com.amazonaws.region.aps-workspaces            - For AWS Managed Prometheus Workspace
-    com.amazonaws.region.ssm                       - Secrets Management
+    com.amazonaws.region.aps-workspaces       - If using AWS Managed Prometheus Workspace
+    com.amazonaws.region.ssm                  - Secrets Management
     com.amazonaws.region.ec2
     com.amazonaws.region.ecr.api
     com.amazonaws.region.ecr.dkr
-    com.amazonaws.region.logs                       – For CloudWatch Logs
-    com.amazonaws.region.sts                        – If using AWS Fargate or IAM roles for service accounts
-    com.amazonaws.region.elasticloadbalancing       – If using Application Load Balancers
-    com.amazonaws.region.autoscaling                – If using Cluster Autoscaler
-    com.amazonaws.region.s3                         – Creates S3 gateway
-
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
+    com.amazonaws.region.logs                 – For CloudWatch Logs
+    com.amazonaws.region.sts                  – If using AWS Fargate or IAM roles for service accounts
+    com.amazonaws.region.elasticloadbalancing – If using Application Load Balancers
+    com.amazonaws.region.autoscaling          – If using Cluster Autoscaler
+    com.amazonaws.region.s3
 
 ## Deploy
 
-Since this is a Fully Private Amazon EKS Cluster, make sure that you'll have access to the Amazon VPC where the cluster will be deployed, otherwise you won't be able to access it.
-
-See the [`privatelink-access`](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/patterns/privatelink-access) pattern for using AWS PrivateLink to access the private cluster from another VPC.
-
-To provision this example:
-
-```sh
-terraform init
-terraform apply
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
-The following command will update the `kubeconfig` on your local machine and allow you to interact with your EKS Cluster using `kubectl` to validate the CoreDNS deployment for Fargate.
-
-1. Check the Terraform provided Output, to update your `kubeconfig`
-
-```hcl
-Apply complete! Resources: 63 added, 0 changed, 0 destroyed.
-
-Outputs:
-
-configure_kubectl = "aws eks --region us-west-2 update-kubeconfig --name fully-private-cluster"
-```
-
-2. Run `update-kubeconfig` command, using the Terraform provided Output, replace with your `$AWS_REGION` and your `$CLUSTER_NAME` variables.
-
-```sh
-aws eks --region <$AWS_REGION> update-kubeconfig --name <$CLUSTER_NAME>
-```
-
-3. Test by listing Nodes in in the Cluster.
-
-```sh
-kubectl get nodes
-NAME                                        STATUS   ROLES    AGE     VERSION
-ip-10-0-19-90.us-west-2.compute.internal    Ready    <none>   8m34s   v1.26.2-eks-a59e1f0
-ip-10-0-44-110.us-west-2.compute.internal   Ready    <none>   8m36s   v1.26.2-eks-a59e1f0
-ip-10-0-9-147.us-west-2.compute.internal    Ready    <none>   8m35s   v1.26.2-eks-a59e1f0
-```
-
-4. Test by listing all the Pods running currently. All the Pods should reach a status of `Running` after approximately 60 seconds:
-
-```sh
-kubectl $ kubectl get pods -A
-NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
-kube-system   aws-node-jvn9x             1/1     Running   0          7m42s
-kube-system   aws-node-mnjlf             1/1     Running   0          7m45s
-kube-system   aws-node-q458h             1/1     Running   0          7m49s
-kube-system   coredns-6c45d94f67-495rr   1/1     Running   0          14m
-kube-system   coredns-6c45d94f67-5c8tc   1/1     Running   0          14m
-kube-system   kube-proxy-47wfh           1/1     Running   0          8m32s
-kube-system   kube-proxy-f6chz           1/1     Running   0          8m30s
-kube-system   kube-proxy-xcfkc           1/1     Running   0          8m31s
-```
+1. Test by listing Nodes in in the cluster:
+
+    ```sh
+    kubectl get nodes
+    ```
+
+    ```text
+    NAME                                        STATUS   ROLES    AGE     VERSION
+    ip-10-0-19-90.us-west-2.compute.internal    Ready    <none>   8m34s   v1.26.2-eks-a59e1f0
+    ip-10-0-44-110.us-west-2.compute.internal   Ready    <none>   8m36s   v1.26.2-eks-a59e1f0
+    ip-10-0-9-147.us-west-2.compute.internal    Ready    <none>   8m35s   v1.26.2-eks-a59e1f0
+    ```
+
+2. Test by listing all the Pods running currently. All the Pods should reach a status of `Running` after approximately 60 seconds:
+
+    ```sh
+    kubectl get pods -A
+    ```
+
+    ```text
+    NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
+    kube-system   aws-node-jvn9x             1/1     Running   0          7m42s
+    kube-system   aws-node-mnjlf             1/1     Running   0          7m45s
+    kube-system   aws-node-q458h             1/1     Running   0          7m49s
+    kube-system   coredns-6c45d94f67-495rr   1/1     Running   0          14m
+    kube-system   coredns-6c45d94f67-5c8tc   1/1     Running   0          14m
+    kube-system   kube-proxy-47wfh           1/1     Running   0          8m32s
+    kube-system   kube-proxy-f6chz           1/1     Running   0          8m30s
+    kube-system   kube-proxy-xcfkc           1/1     Running   0          8m31s
+    ```
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
-```sh
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/external-secrets/README.md

@@ -1,66 +1,45 @@
 # Amazon EKS Cluster w/ IPv6 Networking
 
-This example shows how to create an EKS cluster that utilizes IPv6 networking.
-
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
+This pattern demonstrates an EKS cluster that utilizes IPv6 networking.
 
 ## Deploy
 
-To provision this example:
-
-```sh
-terraform init
-terraform apply
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
-The following command will update the `kubeconfig` on your local machine and allow you to interact with your EKS Cluster using `kubectl` to validate the CoreDNS deployment for Fargate.
+1. Test by listing all the pods running currently; the `IP` should be an IPv6 address.
 
-1. Run `update-kubeconfig` command:
+    ```sh
+    kubectl get pods -A -o wide
+    ```
 
-```sh
-aws eks --region <REGION> update-kubeconfig --name <CLUSTER_NAME>
-```
+    ```text
+    # Output should look like below
+    NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE     IP                                       NODE                                        NOMINATED NODE   READINESS GATES
+    kube-system   aws-node-bhd2s             1/1     Running   0          3m5s    2600:1f13:6c4:a703:ecf8:3ac1:76b0:9303   ip-10-0-10-183.us-west-2.compute.internal   <none>           <none>
+    kube-system   aws-node-nmdgq             1/1     Running   0          3m21s   2600:1f13:6c4:a705:a929:f8d4:9350:1b20   ip-10-0-12-188.us-west-2.compute.internal   <none>           <none>
+    kube-system   coredns-799c5565b4-6wxrc   1/1     Running   0          10m     2600:1f13:6c4:a705:bbda::                ip-10-0-12-188.us-west-2.compute.internal   <none>           <none>
+    kube-system   coredns-799c5565b4-fjq4q   1/1     Running   0          10m     2600:1f13:6c4:a705:bbda::1               ip-10-0-12-188.us-west-2.compute.internal   <none>           <none>
+    kube-system   kube-proxy-58tp7           1/1     Running   0          4m25s   2600:1f13:6c4:a703:ecf8:3ac1:76b0:9303   ip-10-0-10-183.us-west-2.compute.internal   <none>           <none>
+    kube-system   kube-proxy-hqkgw           1/1     Running   0          4m25s   2600:1f13:6c4:a705:a929:f8d4:9350:1b20   ip-10-0-12-188.us-west-2.compute.internal   <none>           <none>
+    ```
 
-2. Test by listing all the pods running currently; the `IP` should be an IPv6 address.
+2. Test by listing all the nodes running currently; the `INTERNAL-IP` should be an IPv6 address.
 
-```sh
-kubectl get pods -A -o wide
+    ```sh
+    kubectl nodes -A -o wide
+    ```
 
-# Output should look like below
-NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE     IP                                       NODE                                        NOMINATED NODE   READINESS GATES
-kube-system   aws-node-bhd2s             1/1     Running   0          3m5s    2600:1f13:6c4:a703:ecf8:3ac1:76b0:9303   ip-10-0-10-183.us-west-2.compute.internal   <none>           <none>
-kube-system   aws-node-nmdgq             1/1     Running   0          3m21s   2600:1f13:6c4:a705:a929:f8d4:9350:1b20   ip-10-0-12-188.us-west-2.compute.internal   <none>           <none>
-kube-system   coredns-799c5565b4-6wxrc   1/1     Running   0          10m     2600:1f13:6c4:a705:bbda::                ip-10-0-12-188.us-west-2.compute.internal   <none>           <none>
-kube-system   coredns-799c5565b4-fjq4q   1/1     Running   0          10m     2600:1f13:6c4:a705:bbda::1               ip-10-0-12-188.us-west-2.compute.internal   <none>           <none>
-kube-system   kube-proxy-58tp7           1/1     Running   0          4m25s   2600:1f13:6c4:a703:ecf8:3ac1:76b0:9303   ip-10-0-10-183.us-west-2.compute.internal   <none>           <none>
-kube-system   kube-proxy-hqkgw           1/1     Running   0          4m25s   2600:1f13:6c4:a705:a929:f8d4:9350:1b20   ip-10-0-12-188.us-west-2.compute.internal   <none>           <none>
-```
-
-3. Test by listing all the nodes running currently; the `INTERNAL-IP` should be an IPv6 address.
-
-```sh
-kubectl nodes -A -o wide
-
-# Output should look like below
-NAME                                        STATUS   ROLES    AGE     VERSION               INTERNAL-IP                              EXTERNAL-IP   OS-IMAGE         KERNEL-VERSION                 CONTAINER-RUNTIME
-ip-10-0-10-183.us-west-2.compute.internal   Ready    <none>   4m57s   v1.24.7-eks-fb459a0   2600:1f13:6c4:a703:ecf8:3ac1:76b0:9303   <none>        Amazon Linux 2   5.4.226-129.415.amzn2.x86_64   containerd://1.6.6
-ip-10-0-12-188.us-west-2.compute.internal   Ready    <none>   4m57s   v1.24.7-eks-fb459a0   2600:1f13:6c4:a705:a929:f8d4:9350:1b20   <none>        Amazon Linux 2   5.4.226-129.415.amzn2.x86_64   containerd://1.6.6
-```
+    ```text
+    # Output should look like below
+    NAME                                        STATUS   ROLES    AGE     VERSION               INTERNAL-IP                              EXTERNAL-IP   OS-IMAGE         KERNEL-VERSION                 CONTAINER-RUNTIME
+    ip-10-0-10-183.us-west-2.compute.internal   Ready    <none>   4m57s   v1.24.7-eks-fb459a0   2600:1f13:6c4:a703:ecf8:3ac1:76b0:9303   <none>        Amazon Linux 2   5.4.226-129.415.amzn2.x86_64   containerd://1.6.6
+    ip-10-0-12-188.us-west-2.compute.internal   Ready    <none>   4m57s   v1.24.7-eks-fb459a0   2600:1f13:6c4:a705:a929:f8d4:9350:1b20   <none>        Amazon Linux 2   5.4.226-129.415.amzn2.x86_64   containerd://1.6.6
+    ```
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
-```sh
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/fargate-serverless/README.md

@@ -1,14 +1,7 @@
 # Amazon EKS Multi-Cluster w/ Istio
 
-This example shows how to provision 2 Amazon EKS clusters with Istio setup on each of them.
-The Istio will be set-up to operate in a [Multi-Primary](https://istio.io/latest/docs/setup/install/multicluster/multi-primary/) way where services are shared across clusters.
-
-* Deploy a VPC with additional security groups to allow cross-cluster communication and communication from nodes to the other cluster API Server endpoint
-* Deploy 2 EKS Cluster with one managed node group in an VPC
-* Add node_security_group rules for port access required for Istio communication
-* Install Istio using Helm resources in Terraform
-* Install Istio Ingress Gateway using Helm resources in Terraform
-* Deploy/Validate Istio communication using sample application
+This pattern demonstrates 2 Amazon EKS clusters configured with Istio.
+Istio will be set-up to operate in a [Multi-Primary](https://istio.io/latest/docs/setup/install/multicluster/multi-primary/) configuration, where services are shared across clusters.
 
 Refer to the [documentation](https://istio.io/latest/docs/concepts/) for `Istio` concepts.
 

patterns/fully-private-cluster/README.md

@@ -6,42 +6,17 @@ This example shows how to provision an EKS cluster with Istio.
 * Add node_security_group rules for port access required for Istio communication
 * Install Istio using Helm resources in Terraform
 * Install Istio Ingress Gateway using Helm resources in Terraform
-  *  This step deploys a Service of type `LoadBalancer` that creates an AWS Network Load Balancer.
+  * This step deploys a Service of type `LoadBalancer` that creates an AWS Network Load Balancer.
 * Deploy/Validate Istio communication using sample application
 
 Refer to the [documentation](https://istio.io/latest/docs/concepts/) on Istio
 concepts.
 
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
-4. [helm](https://helm.sh/docs/intro/install/)
-
 ## Deploy
 
-To provision this example:
-
-```sh
-terraform init
-terraform apply -target=module.vpc -target=module.eks
-terraform apply
-```
-
-Enter `yes` at command prompt to apply
-
-### Update local kubeconfig
-
-Run the following command to update your local `kubeconfig` with latest cluster:
-
-```sh
-aws eks --region <REGION> update-kubeconfig --name <CLUSTER_NAME>
-```
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
-### Istio Observability Add-ons
+### Observability Add-ons
 
 Use the following code snippet to add the Istio Observability Add-ons on the EKS
 cluster with deployed Istio.
@@ -56,33 +31,14 @@ done
 
 ## Validate
 
-The following command will update the `kubeconfig` on your local machine and
-allow you to interact with your EKS Cluster using `kubectl` to validate the
-deployment.
-
-1. List all the worker nodes
-
-   ```sh
-   kubectl get nodes
-   ```
+1. List out all pods and services in the `istio-system` namespace:
 
-   Output should be similar to:
-    ```
-    NAME                                       STATUS   ROLES    AGE     VERSION
-    ip-10-0-2-141.us-west-2.compute.internal   Ready    <none>   9m36s   v1.27.3-eks-a5565ad
-    ip-10-0-30-86.us-west-2.compute.internal   Ready    <none>   9m37s   v1.27.3-eks-a5565ad
-    ip-10-0-47-71.us-west-2.compute.internal   Ready    <none>   9m21s   v1.27.3-eks-a5565ad
+    ```sh
+    kubectl get pods,svc -n istio-system
+    kubectl get pods,svc -n istio-ingress
     ```
 
-2. List out all pods and services in the `istio-system` namespace:
-
-   ```sh
-   kubectl get pods,svc -n istio-system
-   kubectl get pods,svc -n istio-ingress
-   ```
-
-   Output should be similar to:
-    ```
+    ```text
     NAME                             READY   STATUS    RESTARTS   AGE
     pod/grafana-7d4f5589fb-4xj9m     1/1     Running   0          4m14s
     pod/istiod-ff577f8b8-c8ssk       1/1     Running   0          4m40s
@@ -106,23 +62,26 @@ deployment.
     service/istio-ingress   LoadBalancer   172.20.104.27   k8s-istioing-istioing-844c89b6c2-875b8c9a4b4e9365.elb.us-west-2.amazonaws.com   15021:32760/TCP,80:31496/TCP,443:32534/TCP   4m28s
     ```
 
-3. Verify all the Helm releases installed in the `istio-system` and
-`istio-ingress` namespaces:
+2. Verify all the Helm releases installed in the `istio-system` and `istio-ingress` namespaces:
 
-   ```sh
-   helm list -n istio-system
-   helm list -n istio-ingress
-   ```
+    ```sh
+    helm list -n istio-system
+    ```
 
-   Output should be similar to:
-   ```
-   NAME          	NAMESPACE   	REVISION	UPDATED                             	STATUS  	CHART         	APP VERSION
-   istio-base   	istio-system	1       	2023-07-19 11:05:41.599921 -0700 PDT	deployed	base-1.18.1   	1.18.1
-   istiod       	istio-system	1       	2023-07-19 11:05:48.087616 -0700 PDT	deployed	istiod-1.18.1 	1.18.1
+    ```text
+    NAME           NAMESPACE    REVISION UPDATED                              STATUS   CHART          APP VERSION
+    istio-base    istio-system 1        2023-07-19 11:05:41.599921 -0700 PDT deployed base-1.18.1    1.18.1
+    istiod        istio-system 1        2023-07-19 11:05:48.087616 -0700 PDT deployed istiod-1.18.1  1.18.1
+    ```
+
+    ```sh
+    helm list -n istio-ingress
+    ```
 
-   NAME          	NAMESPACE   	REVISION	UPDATED                             	STATUS  	CHART         	APP VERSION
-   istio-ingress	istio-ingress	1       	2023-07-19 11:06:03.41609 -0700 PDT 	deployed	gateway-1.18.1	1.18.1
-   ```
+    ```text
+    NAME           NAMESPACE    REVISION UPDATED                              STATUS   CHART          APP VERSION
+    istio-ingress istio-ingress 1        2023-07-19 11:06:03.41609 -0700 PDT  deployed gateway-1.18.1 1.18.1
+    ```
 
 ### Observability Add-ons
 
@@ -131,7 +90,6 @@ and accessing each of the service endpoints using this URL of the form
 [http://localhost:\<port>](http://localhost:<port>) where `<port>` is one of the
 port number for the corresponding service.
 
-
 ```sh
 # Visualize Istio Mesh console using Kiali
 kubectl port-forward svc/kiali 20001:20001 -n istio-system
@@ -146,7 +104,7 @@ kubectl port-forward svc/grafana 3000:3000 -n istio-system
 kubectl port-forward svc/jaeger 16686:16686 -n istio-system
 ```
 
-## Test
+### Example
 
 1. Create the `sample` namespace and enable the sidecar injection on it
 
@@ -155,8 +113,7 @@ kubectl port-forward svc/jaeger 16686:16686 -n istio-system
     kubectl label namespace sample istio-injection=enabled
     ```
 
-    Output should be:
-    ```
+    ```text
     namespace/sample created
     namespace/sample labeled
     ```
@@ -212,8 +169,7 @@ kubectl port-forward svc/jaeger 16686:16686 -n istio-system
     kubectl apply -f helloworld.yaml -n sample
     ```
 
-    Output should be:
-    ```
+    ```text
     service/helloworld created
     deployment.apps/helloworld-v1 created
     ```
@@ -275,8 +231,7 @@ kubectl port-forward svc/jaeger 16686:16686 -n istio-system
     kubectl apply -f sleep.yaml -n sample
     ```
 
-    Output should be:
-    ```
+    ```text
     serviceaccount/sleep created
     service/sleep created
     deployment.apps/sleep created
@@ -287,23 +242,23 @@ kubectl port-forward svc/jaeger 16686:16686 -n istio-system
     ```sh
     kubectl get pods -n sample
     ```
-    Output should be similar to:
-    ```
+
+    ```text
     NAME                           READY   STATUS    RESTARTS   AGE
     helloworld-v1-b6c45f55-bx2xk   2/2     Running   0          50s
     sleep-9454cc476-p2zxr          2/2     Running   0          15s
     ```
-5. Connect to `helloworld` app from `sleep` app and verify if the connection
-uses envoy proxy
+
+5. Connect to `helloworld` app from `sleep` app and verify if the connection uses envoy proxy
 
     ```sh
     kubectl exec -n sample -c sleep \
         "$(kubectl get pod -n sample -l \
         app=sleep -o jsonpath='{.items[0].metadata.name}')" \
         -- curl -v helloworld.sample:5000/hello
     ```
-    Output should be similar to:
-    ```
+
+    ```text
     * processing: helloworld.sample:5000/hello
     % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
@@ -329,9 +284,6 @@ uses envoy proxy
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
-```sh
-terraform destroy -target="helm_release.istio_ingress" --auto-approve
-terraform destroy --auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/ipv6-eks-cluster/README.md

@@ -108,78 +108,69 @@ module "eks_blueprints_addons" {
   cluster_version   = module.eks.cluster_version
   oidc_provider_arn = module.eks.oidc_provider_arn
 
-  # This is required to expose Istio Ingress Gateway
-  enable_aws_load_balancer_controller = true
-
-  tags = local.tags
-
   eks_addons = {
     coredns    = {}
     vpc-cni    = {}
     kube-proxy = {}
   }
-}
 
-################################################################################
-# Istio
-################################################################################
-
-resource "helm_release" "istio_base" {
-  repository = local.istio_chart_url
-  chart      = "base"
-  name       = "istio-base"
-  namespace  = "istio-system"
-  version    = local.istio_chart_version
-  wait       = false
+  # This is required to expose Istio Ingress Gateway
+  enable_aws_load_balancer_controller = true
 
-  create_namespace = true
+  helm_releases = {
+    istio-base = {
+      chart            = "base"
+      version          = local.istio_chart_version
+      repository       = local.istio_chart_url
+      name             = "istio-base"
+      namespace        = "istio-system"
+      create_namespace = true
+    }
 
-  depends_on = [
-    module.eks_blueprints_addons
-  ]
-}
+    istiod = {
+      chart            = "istiod"
+      version          = local.istio_chart_version
+      repository       = local.istio_chart_url
+      name             = "istiod"
+      namespace        = "istio-system"
+      create_namespace = false
+
+      set = [
+        {
+          name  = "meshConfig.accessLogFile"
+          value = "/dev/stdout"
+        }
+      ]
+    }
 
-resource "helm_release" "istiod" {
-  repository = local.istio_chart_url
-  chart      = "istiod"
-  name       = "istiod"
-  namespace  = helm_release.istio_base.metadata[0].namespace
-  version    = local.istio_chart_version
-  wait       = false
-
-  set {
-    name  = "meshConfig.accessLogFile"
-    value = "/dev/stdout"
+    istio-ingress = {
+      chart            = "gateway"
+      version          = local.istio_chart_version
+      repository       = local.istio_chart_url
+      name             = "istio-ingress"
+      namespace        = "istio-ingress" # per https://github.com/istio/istio/blob/master/manifests/charts/gateways/istio-ingress/values.yaml#L2
+      create_namespace = true
+
+      values = [
+        yamlencode(
+          {
+            labels = {
+              istio = "ingressgateway"
+            }
+            service = {
+              annotations = {
+                "service.beta.kubernetes.io/aws-load-balancer-type"       = "nlb"
+                "service.beta.kubernetes.io/aws-load-balancer-scheme"     = "internet-facing"
+                "service.beta.kubernetes.io/aws-load-balancer-attributes" = "load_balancing.cross_zone.enabled=true"
+              }
+            }
+          }
+        )
+      ]
+    }
   }
-}
 
-resource "helm_release" "istio_ingress" {
-  repository = local.istio_chart_url
-  chart      = "gateway"
-  name       = "istio-ingress"
-  namespace  = "istio-ingress" # per https://github.com/istio/istio/blob/master/manifests/charts/gateways/istio-ingress/values.yaml#L2
-  version    = local.istio_chart_version
-  wait       = false
-
-  create_namespace = true
-
-  values = [
-    yamlencode(
-      {
-        labels = {
-          istio = "ingressgateway"
-        }
-        service = {
-          annotations = {
-            "service.beta.kubernetes.io/aws-load-balancer-type"       = "nlb"
-            "service.beta.kubernetes.io/aws-load-balancer-scheme"     = "internet-facing"
-            "service.beta.kubernetes.io/aws-load-balancer-attributes" = "load_balancing.cross_zone.enabled=true"
-          }
-        }
-      }
-    )
-  ]
-  depends_on = [helm_release.istiod]
+  tags = local.tags
 }
 
 ################################################################################

patterns/istio-multi-cluster/README.md

@@ -1,43 +1,24 @@
 # Karpenter
 
-This example demonstrates how to provision a Karpenter on a serverless cluster (serverless data plane) using Fargate Profiles.
-
-This example solution provides:
-
-- Amazon EKS Cluster (control plane)
-- Amazon EKS Fargate Profiles for the `kube-system` namespace which is used by the `coredns`, `vpc-cni`, and `kube-proxy` addons, as well as profile that will match on the `karpenter` namespace which will be used by Karpenter.
-- Amazon EKS managed addons `coredns`, `vpc-cni` and `kube-proxy`
-    `coredns` has been patched to run on Fargate, and `vpc-cni` has been configured to use prefix delegation to better support the max pods setting of 110 on the Karpenter provisioner
-- A sample deployment is provided to demonstrates scaling a deployment to view how Karpenter responds to provision, and de-provision, resources on-demand
-
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
+This pattern demonstrates how to provision Karpenter on a serverless cluster (serverless data plane) using Fargate Profiles.
 
 ## Deploy
 
-To provision this example:
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
-```sh
-terraform init
-terraform apply -target module.vpc
-terraform apply -target module.eks
-terraform apply
-```
+## Validate
 
-Enter `yes` at command prompt to apply
+!!! danger "TODO"
+    Add in validation steps
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
+Scale down the deployment to de-provision Karpenter created resources first:
 
 ```sh
 kubectl delete deployment inflate
-terraform destroy -target="module.eks_blueprints_addons" -auto-approve
-terraform destroy -target="module.eks" -auto-approve
-terraform destroy -auto-approve
 ```
+
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/istio/README.md

@@ -1,47 +1,23 @@
 # Multi-Tenancy w/ Teams
 
-This example demonstrates how to provision and configure a multi-tenancy Amazon EKS cluster with safeguards for resource consumption and namespace isolation.
+This pattern demonstrates how to provision and configure a multi-tenancy Amazon EKS cluster with safeguards for resource consumption and namespace isolation.
 
 This example solution provides:
 
-- Amazon EKS Cluster (control plane)
-- Amazon EKS managed nodegroup (data plane)
 - Two development teams - `team-red` and `team-blue` - isolated to their respective namespaces
 - An admin team with privileged access to the cluster (`team-admin`)
 
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
-
 ## Deploy
 
-To provision this example:
-
-```sh
-terraform init
-terraform apply
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
-The following command will update the `kubeconfig` on your local machine and allow you to interact with your EKS Cluster using `kubectl`.
-
-1. Run `update-kubeconfig` command:
-
-```sh
-aws eks --region <REGION> update-kubeconfig --name <CLUSTER_NAME>
-```
+!!! danger "TODO"
+    Add in validation steps
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
-```sh
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/istio/main.tf

@@ -3,38 +3,25 @@
 This example demonstrates how to provision an Amazon EKS cluster with two  ingress-nginx controllers; one to expose applications publicly and the other to expose applications internally. It also assigns security groups to the Network Load Balancers used to expose the internal and external ingress controllers.
 
 This solution:
-* Deploys Amazon EKS, with 1 Managed Node Group using the Bottlerocket Amazon EKS Optimized AMI spread accross 3 availability zones.
-* Installs the AWS Load Balancer controller for creating Network Load Balancers and Application Load Balancers. This is the recommended approach instead of the in-tree AWS cloud provider load balancer controller.
-* Installs an ingress-nginx controller for public traffic
-* Installs an ingress-nginx controller for internal traffic
+
+- Installs an ingress-nginx controller for public traffic
+- Installs an ingress-nginx controller for internal traffic
 
 To expose your application services via an `Ingress` resource with this solution you can set the respective `ingressClassName` as either `ingress-nginx-external` or `ingress-nginx-internal`.
 
 Refer to the [documentation](https://kubernetes-sigs.github.io/aws-load-balancer-controller) for `AWS Load Balancer controller` configuration options.
 
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
-
 ## Deploy
 
-To provision this example:
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
-```sh
-terraform init
-terraform apply
-```
+## Validate
 
-Enter `yes` at command prompt to apply
+!!! danger "TODO"
+    Add in validation steps
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
-```sh
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/karpenter/README.md

@@ -1,38 +1,13 @@
 # Private EKS cluster access via AWS PrivateLink
 
-This example demonstrates how to access a private EKS cluster using AWS PrivateLink.
+This pattern demonstrates how to access a private EKS cluster using AWS PrivateLink.
 
 Refer to the [documentation](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html)
 for further details on  `AWS PrivateLink`.
 
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
-
 ## Deploy
 
-To provision this example, first deploy the Lambda function that responds to
-`CreateNetworkInterface` API calls. This needs to exist before the cluster is
-created so that it can respond to the ENIs created by the EKS control plane:
-
-```sh
-terraform init
-terraform apply -target=module.eventbridge -target=module.nlb
-```
-
-Enter `yes` at command prompt to apply
-
-Next, deploy the remaining resources:
-
-```sh
-terraform apply
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
@@ -48,17 +23,17 @@ be `ok`.
 COMMAND="curl -ks https://9A85B21811733524E3ABCDFEA8714642.gr7.us-west-2.eks.amazonaws.com/readyz"
 
 COMMAND_ID=$(aws ssm send-command --region us-west-2 \
---document-name "AWS-RunShellScript" \
---parameters "commands=[$COMMAND]" \
---targets "Key=instanceids,Values=i-0a45eff73ba408575" \
---query 'Command.CommandId' \
---output text)
+   --document-name "AWS-RunShellScript" \
+   --parameters "commands=[$COMMAND]" \
+   --targets "Key=instanceids,Values=i-0a45eff73ba408575" \
+   --query 'Command.CommandId' \
+   --output text)
 
 aws ssm get-command-invocation --region us-west-2 \
---command-id $COMMAND_ID \
---instance-id i-0a45eff73ba408575 \
---query 'StandardOutputContent' \
---output text
+   --command-id $COMMAND_ID \
+   --instance-id i-0a45eff73ba408575 \
+   --query 'StandardOutputContent' \
+   --output text
 ```
 
 ### Cluster Access
@@ -73,10 +48,11 @@ add additional entries to the ConfigMap; we can only access the cluster from
 within the private network of the cluster's VPC or from the client VPC using AWS
 PrivateLink access.
 
-> :warning: The "client" EC2 instance provided and copying of AWS credentials to
- that instance are merely for demonstration purposes only. Please consider
- alternate methods of network access such as AWS Client VPN to provide more
- secure access.
+!!! info
+      The "client" EC2 instance provided and copying of AWS credentials to
+      that instance are merely for demonstration purposes only. Please consider
+      alternate methods of network access such as AWS Client VPN to provide more
+      secure access.
 
 Perform the following steps to access the cluster with `kubectl` from the
 provided "client" EC2 instance.
@@ -100,8 +76,9 @@ instance.
 3. Once logged in, export the following environment variables from the output
 of step #1:
 
-   > :exclamation: The session credentials are only valid for 1 hour; you can
-   adjust the session duration in the command provided in step #1
+    !!! warning
+        The session credentials are only valid for 1 hour; you can
+        adjust the session duration in the command provided in step #1
 
    ```sh
    export AWS_ACCESS_KEY_ID=XXXX
@@ -122,19 +99,16 @@ access to the cluster:
    kubectl get pods -A
    ```
 
-   The test succeeded if you see an output like the one shown below:
-
-       NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
-       kube-system   aws-node-4f8g8             1/1     Running   0          1m
-       kube-system   coredns-6ff9c46cd8-59sqp   1/1     Running   0          1m
-       kube-system   coredns-6ff9c46cd8-svnpb   1/1     Running   0          2m
-       kube-system   kube-proxy-mm2zc           1/1     Running   0          1m
-
+   ```text
+   NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
+   kube-system   aws-node-4f8g8             1/1     Running   0          1m
+   kube-system   coredns-6ff9c46cd8-59sqp   1/1     Running   0          1m
+   kube-system   coredns-6ff9c46cd8-svnpb   1/1     Running   0          2m
+   kube-system   kube-proxy-mm2zc           1/1     Running   0          1m
+   ```
 
 ## Destroy
 
-Run the following command to destroy all the resources created by Terraform:
-
-```sh
-terraform destroy --auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/multi-tenancy-with-teams/README.md

@@ -2,31 +2,9 @@
 
 This example demonstrates how to deploy an Amazon EKS cluster that is deployed on the AWS Cloud, integrated with IAM Identity Center (former AWS SSO) as an the Identity Provider (IdP) for Single Sign-On (SSO) authentication. The configuration for authorization is done using Kubernetes Role-based access control (RBAC).
 
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
-
-Also make sure you have enabled the following AWS resource:
-
-1. Enable [IAM Identity Center](https://console.aws.amazon.com/singlesignon/home/)
-    This will also create an AWS Organization in your account.
-
 ## Deploy
 
-To provision these examples, run the following commands:
-
-```sh
-terraform init
-terraform apply -target module.vpc
-terraform apply -target module.eks
-terraform apply
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
@@ -99,7 +77,7 @@ EOT
 With the `kubeconfig` configured, you'll be able to run `kubectl` commands in your Amazon EKS Cluster with the impersonated user. The read-only user has a `cluster-viewer` Kubernetes role bound to it's group, whereas the admin user, has the `admin` Kubernetes role bound to it's group.
 
 ```
-kubectl get pods -A  
+kubectl get pods -A
 NAMESPACE          NAME                        READY   STATUS    RESTARTS   AGE
 amazon-guardduty   aws-guardduty-agent-bl2v2   1/1     Running   0          3h54m
 amazon-guardduty   aws-guardduty-agent-sqvcx   1/1     Running   0          3h54m
@@ -122,8 +100,6 @@ configure_kubectl = "aws eks --region us-west-2 update-kubeconfig --name iam-ide
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
-```sh
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/private-public-ingress/README.md

@@ -2,43 +2,9 @@
 
 This example demonstrates how to deploy an Amazon EKS cluster that is deployed on the AWS Cloud, integrated with Okta as an the Identity Provider (IdP) for Single Sign-On (SSO) authentication. The configuration for authorization is done using Kubernetes Role-based access control (RBAC).
 
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
-4. [kubelogin](https://github.com/int128/kubelogin)
-
-Also make sure you have enabled the following Okta resource:
-
-1. [Okta Account](https://okta.com).
-2. [Okta Organization](https://developer.okta.com/docs/concepts/okta-organizations/)
-3. [Okta API Token](https://developer.okta.com/docs/guides/create-an-api-token/main/)
-
 ## Deploy
 
-To provision this example, populate the Okta provider credentials, in the `okta.tf` file.
-
-```
-provider "okta" {
-  org_name  = "dev-<ORG_ID>
-  base_url  = "okta.com"
-  api_token = "<OKTA_APU_TOKEN>"
-}
-```
-
-Then run the following commands:
-
-```sh
-terraform init
-terraform apply -target module.vpc
-terraform apply -target module.eks
-terraform apply
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
@@ -65,7 +31,7 @@ With the `kubeconfig` configured, you'll be able to run `kubectl` commands in yo
 The read-only user has a `cluster-viewer` Kubernetes role bound to it's group, whereas the admin user, has the `admin` Kubernetes role bound to it's group.
 
 ```
-kubectl get pods -A  
+kubectl get pods -A
 NAMESPACE          NAME                        READY   STATUS    RESTARTS   AGE
 amazon-guardduty   aws-guardduty-agent-bl2v2   1/1     Running   0          3h54m
 amazon-guardduty   aws-guardduty-agent-sqvcx   1/1     Running   0          3h54m
@@ -94,8 +60,6 @@ okta_login = "kubectl oidc-login setup --oidc-issuer-url=https://dev-ORGID.okta.
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
-```sh
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/privatelink-access/README.md

@@ -36,114 +36,101 @@ In addition, the following properties are configured on the nodegroup volumes:
 - EBS encryption using a customer managed key (CMK)
 - Configuring the volumes to use GP3 storage
 
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
-
 ## Deploy
 
-To provision this example:
-
-```sh
-terraform init
-terraform apply
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
 For validating `velero` see [here](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/modules/kubernetes-addons/velero#validate)
 
 The following command will update the `kubeconfig` on your local machine and allow you to interact with your EKS Cluster using `kubectl` to validate the deployment.
 
-1. Run `update-kubeconfig` command:
-
-```sh
-aws eks --region <REGION> update-kubeconfig --name <CLUSTER_NAME>
-```
-
-2. List the storage classes to view that `efs`, `gp2`, and `gp3` classes are present and `gp3` is the default storage class
-
-```sh
-kubectl get storageclasses
-NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
-efs             efs.csi.aws.com         Delete          Immediate              true                   2m19s
-gp2             kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  15m
-gp3 (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   2m19s
-```
-
-3. From an instance launched with instance store(s), check that the instance store has been mounted correctly. To verify, first install the `nvme-cli` tool and then use it to verify. To verify, you can access the instance using SSM Session Manager:
-
-```sh
-# Install the nvme-cli tool
-sudo yum install nvme-cli -y
-
-# Show NVMe volumes attached
-sudo nvme list
-
-# Output should look like below - notice the model is `EC2 NVMe Instance Storage` for the instance store
-Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
----------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
-/dev/nvme0n1     vol0546d3c3b0af0bf6d Amazon Elastic Block Store               1          25.77  GB /  25.77  GB    512   B +  0 B   1.0
-/dev/nvme1n1     AWS24BBF51AF55097008 Amazon EC2 NVMe Instance Storage         1          75.00  GB /  75.00  GB    512   B +  0 B   0
-
-# Show disks, their partitions and mounts
-sudo lsblk
-
-# Output should look like below
-NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
-nvme0n1       259:0    0   24G  0 disk
-├─nvme0n1p1   259:2    0   24G  0 part /
-└─nvme0n1p128 259:3    0    1M  0 part
-nvme1n1       259:1    0 69.9G  0 disk /local1 # <--- this is the instance store
-```
-
-4. From an instance launched with multiple volume(s), check that the instance store has been mounted correctly. To verify, first install the `nvme-cli` tool and then use it to verify. To verify, you can access the instance using SSM Session Manager:
-
-```sh
-# Install the nvme-cli tool
-sudo yum install nvme-cli -y
-
-# Show NVMe volumes attached
-sudo nvme list
-
-# Output should look like below, where /dev/nvme0n1 is the root volume and /dev/nvme1n1 is the second, additional volume
-Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
----------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
-/dev/nvme0n1     vol0cd37dab9e4a5c184 Amazon Elastic Block Store               1          68.72  GB /  68.72  GB    512   B +  0 B   1.0
-/dev/nvme1n1     vol0ad3629c159ee869c Amazon Elastic Block Store               1          25.77  GB /  25.77  GB    512   B +  0 B   1.0
-```
-
-5. From the same instance used in step 4, check that the containerd directories are using the second `/dev/nvme1n1` volume:
-
-```sh
-df /var/lib/containerd/
-
-# Output should look like below, which shows the directory on the /dev/nvme1n1 volume and NOT on /dev/nvme0n1 (root volume)
-Filesystem     1K-blocks    Used Available Use% Mounted on
-/dev/nvme1n1    24594768 2886716  20433380  13% /var/lib/containerd
-```
-
-```sh
-df /run/containerd/
-
-# Output should look like below, which shows the directory on the /dev/nvme1n1 volume and NOT on /dev/nvme0n1 (root volume)
-Filesystem     1K-blocks    Used Available Use% Mounted on
-/dev/nvme1n1    24594768 2886716  20433380  13% /run/containerd
-```
+1. List the storage classes to view that `efs`, `gp2`, and `gp3` classes are present and `gp3` is the default storage class
+
+    ```sh
+    kubectl get storageclasses
+    ```
+
+    ```text
+    NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
+    efs             efs.csi.aws.com         Delete          Immediate              true                   2m19s
+    gp2             kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  15m
+    gp3 (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   2m19s
+    ```
+
+2. From an instance launched with instance store(s), check that the instance store has been mounted correctly. To verify, first install the `nvme-cli` tool and then use it to verify. To verify, you can access the instance using SSM Session Manager:
+
+    ```sh
+    # Install the nvme-cli tool
+    sudo yum install nvme-cli -y
+
+    # Show NVMe volumes attached
+    sudo nvme list
+    ```
+
+    ```text
+    # Notice the model is `EC2 NVMe Instance Storage` for the instance store
+    Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
+    ---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
+    /dev/nvme0n1     vol0546d3c3b0af0bf6d Amazon Elastic Block Store               1          25.77  GB /  25.77  GB    512   B +  0 B   1.0
+    /dev/nvme1n1     AWS24BBF51AF55097008 Amazon EC2 NVMe Instance Storage         1          75.00  GB /  75.00  GB    512   B +  0 B   0
+
+    # Show disks, their partitions and mounts
+    sudo lsblk
+
+    # Output should look like below
+    NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
+    nvme0n1       259:0    0   24G  0 disk
+    ├─nvme0n1p1   259:2    0   24G  0 part /
+    └─nvme0n1p128 259:3    0    1M  0 part
+    nvme1n1       259:1    0 69.9G  0 disk /local1 # <--- this is the instance store
+    ```
+
+3. From an instance launched with multiple volume(s), check that the instance store has been mounted correctly. To verify, first install the `nvme-cli` tool and then use it to verify. To verify, you can access the instance using SSM Session Manager:
+
+    ```sh
+    # Install the nvme-cli tool
+    sudo yum install nvme-cli -y
+
+    # Show NVMe volumes attached
+    sudo nvme list
+    ```
+
+    ```text
+    # /dev/nvme0n1 is the root volume and /dev/nvme1n1 is the second, additional volume
+    Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
+    ---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
+    /dev/nvme0n1     vol0cd37dab9e4a5c184 Amazon Elastic Block Store               1          68.72  GB /  68.72  GB    512   B +  0 B   1.0
+    /dev/nvme1n1     vol0ad3629c159ee869c Amazon Elastic Block Store               1          25.77  GB /  25.77  GB    512   B +  0 B   1.0
+    ```
+
+4. From the same instance used in step 4, check that the containerd directories are using the second `/dev/nvme1n1` volume:
+
+    ```sh
+    df /var/lib/containerd/
+    ```
+
+    ```text
+    # Output should look like below, which shows the directory on the
+    # /dev/nvme1n1 volume and NOT on /dev/nvme0n1 (root volume)
+    Filesystem     1K-blocks    Used Available Use% Mounted on
+    /dev/nvme1n1    24594768 2886716  20433380  13% /var/lib/containerd
+    ```
+
+    ```sh
+    df /run/containerd/
+    ```
+
+    ```text
+    # Output should look like below, which shows the directory on the
+    # /dev/nvme1n1 volume and NOT on /dev/nvme0n1 (root volume)
+    Filesystem     1K-blocks    Used Available Use% Mounted on
+    /dev/nvme1n1    24594768 2886716  20433380  13% /run/containerd
+    ```
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
-```bash
-terraform destroy -target module.eks_blueprints_addons
-terraform destroy
-```
-
-Enter `yes` at each command prompt to destroy
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/single-sign-on/README.md

@@ -1,87 +1,42 @@
 # TLS with AWS PCA Issuer
 
-This example deploys the following
-
-- Basic EKS Cluster with VPC
-- Creates a new sample VPC, 3 Private Subnets and 3 Public Subnets
-- Creates Internet gateway for Public Subnets and NAT Gateway for Private Subnets
-- Enables cert-manager module
-- Enables cert-manager CSI driver module
-- Enables aws-privateca-issuer module
-- Creates AWS Certificate Manager Private Certificate Authority, enables and activates it
-- Creates the CRDs to fetch `tls.crt`, `tls.key` and `ca.crt` , which will be available as Kubernetes Secret. Now you may mount the secret in the application for end to end TLS.
-
-## How to Deploy
-
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
+This pattern demonstrates how to enable TLS with AWS PCA issuer on an Amazon EKS cluster.
 
 ## Deploy
 
-To provision this example:
-
-```sh
-terraform init
-terraform apply -target module.vpc
-terraform apply -target module.eks
-terraform apply
-
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
-The following command will update the `kubeconfig` on your local machine and allow you to interact with your EKS Cluster using `kubectl` to validate the CoreDNS deployment for Fargate.
-
-1. Check the Terraform provided Output, to update your `kubeconfig`
-
-```hcl
-Apply complete! Resources: 63 added, 0 changed, 0 destroyed.
-
-Outputs:
-
-configure_kubectl = "aws eks --region us-west-2 update-kubeconfig --name fully-private-cluster"
-```
-
-2. Run `update-kubeconfig` command, using the Terraform provided Output, replace with your `$AWS_REGION` and your `$CLUSTER_NAME` variables.
-
-```sh
-aws eks --region <$AWS_REGION> update-kubeconfig --name <$CLUSTER_NAME>
-```
-
-3. List all the pods running in `aws-privateca-issuer` and `cert-manager` Namespace.
+1. List all the pods running in `aws-privateca-issuer` and `cert-manager` Namespace.
 
-```sh
-kubectl get pods -n aws-privateca-issuer
-kubectl get pods -n cert-manager
-```
+    ```sh
+    kubectl get pods -n aws-privateca-issuer
+    kubectl get pods -n cert-manager
+    ```
 
-4. View the `certificate` status in the `default` Namespace. It should be in `Ready` state, and be pointing to a `secret` created in the same Namespace.
+2. View the `certificate` status in the `default` Namespace. It should be in `Ready` state, and be pointing to a `secret` created in the same Namespace.
 
-```sh
-kubectl get certificate -o wide
-NAME      READY   SECRET                  ISSUER                    STATUS                                          AGE
-example   True    example-clusterissuer   tls-with-aws-pca-issuer   Certificate is up to date and has not expired   41m
+    ```sh
+    kubectl get certificate -o wide
+    ```
 
-kubectl get secret example-clusterissuer
-NAME                    TYPE                DATA   AGE
-example-clusterissuer   kubernetes.io/tls   3      43m
-```
+    ```text
+    NAME      READY   SECRET                  ISSUER                    STATUS                                          AGE
+    example   True    example-clusterissuer   tls-with-aws-pca-issuer   Certificate is up to date and has not expired   41m
+    ```
 
-## Cleanup
+    ```sh
+    kubectl get secret example-clusterissuer
+    ```
 
-To clean up your environment, destroy the Terraform modules in reverse order.
+    ```text
+    NAME                    TYPE                DATA   AGE
+    example-clusterissuer   kubernetes.io/tls   3      43m
+    ```
 
-Destroy the Kubernetes Add-ons, EKS cluster with Node groups and VPC
+## Destroy
 
-```sh
-terraform destroy -target module.eks_blueprints_kubernetes_addons -auto-approve
-terraform destroy -target module.eks -auto-approve
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}

patterns/single-sign-on/iam-identity-center/README.md patterns/sso-iam-identity-center/README.md

@@ -1,110 +1,70 @@
 # Transparent Encryption with Cilium and Wireguard
 
-This example shows how to provision an EKS cluster with:
-- Managed node group based on Bottlerocket AMI
-- Cilium configured in CNI chaining mode with VPC CNI and with Wireguard transparent encryption enabled
-
-## Reference Documentation:
+This pattern demonstrates Cilium configured in CNI chaining mode with VPC CNI and with Wireguard transparent encryption enabled on an Amazon EKS cluster.
 
 - [Cilium CNI Chaining Documentation](https://docs.cilium.io/en/v1.12/gettingstarted/cni-chaining-aws-cni/)
 - [Cilium Wireguard Encryption Documentation](https://docs.cilium.io/en/v1.12/gettingstarted/encryption-wireguard/)
 
-## Prerequisites:
-
-Ensure that you have the following tools installed locally:
-
-1. [aws cli](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-2. [kubectl](https://Kubernetes.io/docs/tasks/tools/)
-3. [terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli)
-
 ## Deploy
 
-To provision this example with a sample app for testing:
-
-```sh
-terraform init
-terraform apply
-```
-
-To provision this example without sample app for testing:
-
-```sh
-terraform init
-terraform apply -var enable_example=false
-```
-
-Enter `yes` at command prompt to apply
+See [here](https://aws-ia.github.io/terraform-aws-eks-blueprints/main/getting-started/#prerequisites) for the prerequisites and steps to deploy this pattern.
 
 ## Validate
 
-The following command will update the `kubeconfig` on your local machine and allow you to interact with your EKS Cluster using `kubectl` to validate the deployment.
-
-1. Run `update-kubeconfig` command:
-
-```sh
-aws eks --region <REGION> update-kubeconfig --name <CLUSTER_NAME>
-```
-
-2. List the daemonsets
+1. List the daemonsets
 
-```sh
-kubectl get ds -n kube-system
+    ```sh
+    kubectl get ds -n kube-system
+    ```
 
-# Output should look something similar
-NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
-aws-node     2         2         2       2            2           <none>                   156m
-cilium       2         2         2       2            2           kubernetes.io/os=linux   152m
-kube-proxy   2         2         2       2            2           <none>                   156m
-```
+    ```text
+    NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
+    aws-node     2         2         2       2            2           <none>                   156m
+    cilium       2         2         2       2            2           kubernetes.io/os=linux   152m
+    kube-proxy   2         2         2       2            2           <none>                   156m
+    ```
 
-3. Open a shell inside the cilium container
+2. Open a shell inside the cilium container
 
-```sh
-kubectl -n kube-system exec -ti ds/cilium -- bash
-```
+    ```sh
+    kubectl -n kube-system exec -ti ds/cilium -- bash
+    ```
 
-4. Verify Encryption is enabled
+3. Verify Encryption is enabled
 
-```sh
-cilium status | grep Encryption
+    ```sh
+    cilium status | grep Encryption
+    ```
 
-# Output should look something similar
-Encryption:              Wireguard   [cilium_wg0 (Pubkey: b2krgbHgaCsVWALMnFLiS/RekhhcE36PXEjQ7T8+mW0=, Port: 51871, Peers: 1)]
-```
+    ```text
+    Encryption:              Wireguard   [cilium_wg0 (Pubkey: b2krgbHgaCsVWALMnFLiS/RekhhcE36PXEjQ7T8+mW0=, Port: 51871, Peers: 1)]
+    ```
 
-5. Install tcpdump
+4. Install [`tcpdump`](https://www.tcpdump.org/)
 
-```sh
-apt-get update
-apt-get install -y tcpdump
-```
+    ```sh
+    apt-get update
+    apt-get install -y tcpdump
+    ```
 
-6. Start a packet capture on `cilium_wg0` and verify you see payload in clear text, it means the traffic is encrypted with wireguard
+5. Start a packet capture on `cilium_wg0` and verify you see payload in clear text, it means the traffic is encrypted with wireguard
 
-```sh
-tcpdump -A -c 40 -i cilium_wg0 | grep "Welcome to nginx!"
+    ```sh
+    tcpdump -A -c 40 -i cilium_wg0 | grep "Welcome to nginx!"
+    ```
 
-# Output should look similar below
+    ```text
+    <title>Welcome to nginx!</title>
+    <h1>Welcome to nginx!</h1>
+    ...
 
-<title>Welcome to nginx!</title>
-<h1>Welcome to nginx!</h1>
-...
-
-40 packets captured
-40 packets received by filter
-0 packets dropped by kernel
-```
-7. Exit the container shell
-
-```sh
-exit
-```
+    40 packets captured
+    40 packets received by filter
+    0 packets dropped by kernel
+    ```
 
 ## Destroy
 
-To teardown and remove the resources created in this example:
-
-```sh
-terraform destroy -target=module.eks -auto-approve
-terraform destroy -auto-approve
-```
+{%
+   include-markdown "../../docs/_partials/destroy.md"
+%}