diff --git a/docs/configure.md b/docs/configure.md
new file mode 100644
index 00000000..94a55d8e
--- /dev/null
+++ b/docs/configure.md
@@ -0,0 +1,213 @@
+# Using the AWS Gateway API Controller
+
+The first part of this section provides an example of setting up of service-to-service communications on a single cluster.
+The second section extends that example by creating another inventory service on a second cluster on a different VPC, and spreading traffic to that service across the two clusters and VPCs.
+Both clusters are created using `eksctl`, with both clusters created from the same account by the same cluster admin.
+
+## Set up single-cluster/VPC service-to-service communications
+
+This example creates a single cluster in a single VPC, then configures two routes (rates and inventory) and three services (parking, review, and inventory-1). The following figure illustrates this setup:
+
+![Single cluster/VPC service-to-service communications](images/example1.png)
+
+**Steps**
+
+   **Set up Service-to-Service communications**
+
+1. Create the Kubernetes Gateway `my-hotel`:
+   ```bash
+   kubectl apply -f examples/my-hotel-gateway.yaml
+   ```
+1. Verify that `my-hotel` gateway is created (this could take about five minutes):
+   ```bash
+   kubectl get gateway  
+   ```
+   ```
+   NAME       CLASS         ADDRESS   READY   AGE
+   my-hotel   aws-lattice                     7d12h
+   ```
+1. Once the gateway is created, find the VPC Lattice service network:
+   ```bash
+   kubectl get gateway my-hotel -o yaml
+   ```
+   ```
+   apiVersion: gateway.networking.k8s.io/v1alpha2
+   kind: Gateway
+   ...
+   status:
+   conditions:
+   message: 'aws-gateway-arn: arn:aws:vpc-lattice:us-west-2:694065802095:servicenetwork/sn-0ab6bb70055929edd'
+   reason: Reconciled
+   status: "True"
+   ```
+1. Create the Kubernetes HTTPRoute rates for the parking service, review service, and HTTPRoute rate:
+   ```bash
+   kubectl apply -f examples/parking.yaml
+   kubectl apply -f examples/review.yaml
+   kubectl apply -f examples/rate-route-path.yaml
+   ```
+1. Create the Kubernetes HTTPRoute inventory (this could take about five minutes):
+   ```bash
+   kubectl apply -f examples/inventory-ver1.yaml
+   kubectl apply -f examples/inventory-route.yaml
+   ```
+1. Find out HTTPRoute's DNS name from HTTPRoute status:
+   ```bash
+   kubectl get httproute
+   ```
+   ```
+   NAME        HOSTNAMES   AGE
+   inventory               51s
+   rates                   6m11s
+   ```
+1. List the route’s yaml file to see the DNS address (highlighted here on the `message` line):
+
+      ```bash
+      kubectl get httproute inventory -o yaml
+      ```
+
+      ```
+      apiVersion: gateway.networking.k8s.io/v1alpha2
+      kind: HTTPRoute
+      metadata:
+      annotations:
+         kubectl.kubernetes.io/last-applied-configuration: |
+            {"apiVersion":"gateway.networking.k8s.io/v1alpha2","kind":"HTTPRoute","metadata":{"annotations":{},"name":"inventory","namespace":"default"}... }}]}]}}
+      ...
+      status:
+      parents:
+      - conditions:
+         - lastTransitionTime: "2022-11-22T02:29:22Z"
+            message: 'DNS Name: <b><i>inventory-default-0f326944c3d681c0d.7d67968.vpc-lattice-svcs.us-west-2.on.aws</i></b>'
+            reason: Reconciled
+            status: "True"
+            type: httproute
+         controllerName: application-networking.k8s.aws/gateway-api-controller
+         parentRef:
+            group: gateway.networking.k8s.io
+            kind: Gateway
+            name: my-hotel
+      ...
+      ```
+      
+      ```bash
+      kubectl get httproute rates inventory -o yaml
+      ```
+
+**Check service connectivity**
+
+1. Check Service-Inventory Pod access for Service-Rates/parking or Service-Rates/review by execing into the pod, then curling each service.
+   ```bash
+   kubectl get pod
+   ```
+   ```
+   NAME                                    READY   STATUS    RESTARTS   AGE
+   inventory-ver1-7bb6989d9d-2p2hk         1/1     Running   0          7d13h
+   inventory-ver1-7bb6989d9d-464rk         1/1     Running   0          7d13h
+   parking-6cdcd5b4b4-bbzvt                1/1     Running   0          103m
+   parking-6cdcd5b4b4-g8dkb                1/1     Running   0          103m
+   review-5888566ff6-2plsj                 1/1     Running   0          101m
+   review-5888566ff6-89fqk                 1/1     Running   0          101m
+   ```
+1. Exec into an inventory pod to check connectivity to parking and review services:
+   ```bash
+   kubectl exec -ti inventory-ver1-7bb6989d9d-2p2hk sh
+   ```
+1. From inside of the inventory pod, use `curl` to connect to the parking service (using the DNS Name from the previous `kubectl get httproute` command):
+   ```bash
+   curl rates-00422586e3362607e.7d67968.vpc-service-network-svcs.us-west-2.amazonaws.com/parking 
+   ```
+   ```
+   Requesting to Pod(parking-6cdcd5b4b4-g8dkb): parking handler pod
+   ```
+1. From inside of the pod, use `curl` to connect to the review service:
+   ```bash
+   curl rates-00422586e3362607e.7d67968.vpc-service-network-svcs.us-west-2.amazonaws.com/review 
+   ```
+   ```
+   Requesting to Pod(review-5888566ff6-89fqk): review handler pod
+   ```
+1. Exit the pod:
+   ```bash
+   exit
+   ```
+1. Exec into a parking pod to check connectivity to the inventory-ver1 service:
+   ```bash
+   kubectl exec -ti parking-6cdcd5b4b4-bbzvt sh
+   ```
+1. From inside of the parking pod, use `curl` to connect to the inventory-ver1 service:
+   ```bash
+   curl inventory-00422586e3362607e.7d67968.vpc-service-network-svcs.us-west-2.amazonaws.com
+   ```
+   ```
+   Requesting to Pod(inventory-ver1-7bb6989d9d-2p2hk): inventory-ver1 handler pod 
+   ```
+## Set up multi-cluster/multi-VPC service-to-service communications
+
+This sections builds on the previous section by migrating a Kubernetes service (HTTPRoute inventory) from one Kubernetes cluster to a different Kubernetes cluster.
+For example, it will:
+
+* Migrate the Kubernetes inventory service from a Kubernetes v1.21 cluster to a Kubernetes v1.23 cluster in a different VPC.
+* Scale up the Kubernetes inventory service to run it in another cluster (and another VPC) in addition to the current cluster.
+
+The following figure illustrates this:
+
+![Multiple clusters/VPCs service-to-service communications](images/example2.png)
+
+**Steps**
+
+   **Set up inventory on a second cluster** 
+
+1. Create a second cluster (using the same instructions used to create the first).
+
+1. Ensure you're using the second cluster profile. 
+   ```bash
+   kubectl config get-contexts 
+   ```
+   If your profile is set to the first cluster, switch your credentials to use the second cluster:
+   ```bash
+   kubectl config use-context <yourcluster2info>
+   ```
+1. Create a Kubernetes inventory-ver2 service in the second cluster:
+   ```bash
+   kubectl apply -f examples/inventory-ver2.yaml
+   ```
+1. Export this Kubernetes inventory-ver2 from the second cluster, so that it can be referenced by HTTPRoute in the other cluster:
+   ```bash
+   kubectl apply -f examples/inventory-ver2-export.yaml
+   ```
+   **Switch back to the first cluster**
+
+1. Switch credentials back to the first cluster
+   ```bash
+   kubectl config use-context <yourcluster1info>
+   ```
+1. Import the Kubernetes inventory-ver2 into first cluster:
+   ```bash
+   kubectl apply -f examples/inventory-ver2-import.yaml
+   ```
+1. Update the HTTPRoute inventory to route 10% traffic to the first cluster and 90% traffic to the second cluster:
+   ```bash
+   kubectl apply -f examples/inventory-route-bluegreen.yaml
+   ```
+1. Check the Service-Rates/parking pod access to Service-Inventory by execing into the parking pod:
+   ```bash
+   kubectl exec -ti parking-6cdcd5b4b4-bbzvt sh
+   ```
+1. From inside of the pod, use `curl` to connect to the inventory service:
+ 
+      ```bash
+      for ((i=1;i<=30;i++)); do   curl   "inventory-default-0f89d8ff5e98400d0.7d67968.vpc-lattice-svcs.us-west-2.on.aws"; done
+      ```
+      ```
+      Requsting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod <----> in 2nd cluster
+      Requsting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
+      Requsting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
+      Requsting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
+      Requsting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver1 handler pod <----> in 1st cluster
+      Requsting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
+      Requsting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver2 handler pod
+      Requsting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver2 handler pod
+      Requsting to Pod(inventory-ver1-74fc59977-wg8br): Inventory-ver1 handler pod....
+      ```
+      You can see that the traffic is distributed between *inventory-ver1* and *inventory-ver2* as expected.
\ No newline at end of file
diff --git a/docs/deploy.md b/docs/deploy.md
new file mode 100644
index 00000000..dc9d8860
--- /dev/null
+++ b/docs/deploy.md
@@ -0,0 +1,85 @@
+# Deploying the AWS Gateway API Controller
+
+Follow these instructions to create a cluster and deploy the AWS Gateway API Controller.
+Run through them again for a second cluster to use with the extended example shown later.
+
+1. You can use an existing EKS cluster or create a new one as shown here:
+   ```bash
+   eksctl create cluster --name <my-cluster> --region us-west-2
+   ```
+1. Configure security group: To receive traffic from the VPC Lattice fleet, you must set up security groups so that they allow all Pods communicating with VPC Lattice to allow traffic on all ports from the 169.254.171.0/24 address range. See [Control traffic to resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) for details. You can use the following managed prefix to provide the values:
+   ```bash
+   aws ec2 get-managed-prefix-list-entries --region us-west-2 --prefix-list-id pl-0721453c7ac4ec009
+   ```
+   ```
+   ENTRIES 169.254.171.0/24
+   ```
+1. Create an IAM OIDC provider: See [Creating an IAM OIDC provider for your cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html) for details.
+   ```bash
+   eksctl utils associate-iam-oidc-provider --cluster <my-cluster> --approve
+   ```
+1. Create a policy (`recommended-inline-policy.json`) in IAM with the following content that can invoke the gateway API and copy the policy arn for later use:
+   ```bash
+   {
+       "Version": "2012-10-17",
+       "Statement": [
+           {
+               "Effect": "Allow",
+               "Action": [
+                   "vpc-lattice:*",
+                   "iam:CreateServiceLinkedRole",
+                   "ec2:DescribeVpcs",
+                   "ec2:DescribeSubnets"
+               ],
+               "Resource": "*"
+           }
+       ]
+   }
+   ```
+   ```bash
+   aws iam create-policy \
+      --policy-name VPCLatticeControllerIAMPolicy \
+      --policy-document file://examples/recommended-inline-policy.json
+   ```
+1. Create the `system` namespace:
+   ```bash
+   kubectl apply -f examples/deploy-namesystem.yaml
+   ```
+1. Retrieve the policy ARN:
+   ```bash
+   export VPCLatticeControllerIAMPolicyArn=$(aws iam list-policies --query 'Policies[?PolicyName==`VPCLatticeControllerIAMPolicy`].Arn' --output text)
+   ```
+1. Create an iamserviceaccount for pod level permission:
+   ```bash
+   eksctl create iamserviceaccount \
+      --cluster=<my-cluster> \
+      --namespace=system \
+      --name=gateway-api-controller \
+      --attach-policy-arn=$VPCLatticeControllerIAMPolicyArn \
+      --override-existing-serviceaccounts \
+      --region us-west-2 \
+      --approve
+   ```
+
+1. Run either `kubectl` or `helm` to deploy the controller:
+
+      ```bash
+      kubectl apply -f examples/deploy-v0.0.1.yaml
+      ```
+      
+      or
+
+      ```bash
+      # login to ECR
+      aws ecr-public get-login-password --region us-east-1 | helm registry login --username AWS --password-stdin public.ecr.aws
+      # Run helm with either install or upgrade
+      helm install gateway-api-controller \
+         oci://public.ecr.aws/aws-application-networking-k8s/aws-gateway-controller-chart\
+         --version=v0.0.2 \
+         --set=aws.region=us-west-2 --set=serviceAccount.create=false --namespace system
+      ```
+
+1. Create the amazon-vpc-lattice GatewayClass:
+   ```bash
+   kubectl apply -f examples/gatewayclass.yaml
+   ```
diff --git a/docs/examples/bluegreen.md b/docs/examples/bluegreen.md
deleted file mode 100644
index 5a6a54f5..00000000
--- a/docs/examples/bluegreen.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: Multi-cluster Blue/Green Deployment
----
-
-# Multi-cluster Blue/Green Deployment
\ No newline at end of file
diff --git a/docs/how-it-works.md b/docs/how-it-works.md
deleted file mode 100644
index 205b6f36..00000000
--- a/docs/how-it-works.md
+++ /dev/null
@@ -1,390 +0,0 @@
-# AWS Gateway API Controller User Guide
-
-The AWS Gateway API Controller lets you connect services across multiple Kubernetes clusters through the Kubernetes Gateway API interface.
-It is also designed to connect services running on EC2 instances, containers, and as serverless functions.
-It does this by leveraging Amazon VPC Lattice, which works with Kubernetes Gateway API calls to manage Kubernetes objects. 
-
-This document describes how to set up the AWS Gateway API Controller and provides example use cases.
-With the controller deployed and running, you will be able to manage services for multiple Kubernetes clusters and other targets on AWS through the following:
-
-* **CLI**: Use `aws` and `eksctl` to create clusters and set up AWS policies. Then use `kubectl` and YAML files to set up Kubernetes objects.
-* **AWS Console**: View VPC Lattice assets through the VPC area of the AWS console.
-
-While separating the application developer from the details of the underling infrastructure, the controller also provides a Kubernetes-native experience, rather than creating a lot of new AWS ways of managing services.
-It does this by integrating with the Kubernetes Gateway API.
-This lets you work with Kubernetes service-related resources using Kubernetes APIs and custom resource definitions (CRDs) defined by the Kubernetes [networking.k8s.io specification](https://gateway-api.sigs.k8s.io/references/spec/).
-
-For more information on this technology, see [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/). 
-
-A few things to keep in mind:
-* If you are new to the VPC Lattice service, keep in mind that names you use for objects must be unique across your entire account and not just across each cluster used by that account.
-* Your AWS CNI must be v1.8.0 or later to work with VPC Lattice.
-
-## Deploying the AWS Gateway API Controller
-
-Follow these instructions to create a cluster and deploy the AWS Gateway API Controller.
-Run through them again for a second cluster to use with the extended example shown later.
-
-1. You can use an existing EKS cluster or create a new one as shown here:
-   ```bash
-   eksctl create cluster --name <my-cluster> --region us-west-2
-   ```
-1. Configure security group: To receive traffic from the VPC Lattice fleet, you must set up security groups so that they allow all Pods communicating with VPC Lattice to allow traffic on all ports from the 169.254.171.0/24 address range. See [Control traffic to resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) for details. You can use the following managed prefix to provide the values:
-   ```bash
-   aws ec2 get-managed-prefix-list-entries --region us-west-2 --prefix-list-id pl-0721453c7ac4ec009
-   ```
-   ```
-   ENTRIES 169.254.171.0/24
-   ```
-1. Create an IAM OIDC provider: See [Creating an IAM OIDC provider for your cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html) for details.
-   ```bash
-   eksctl utils associate-iam-oidc-provider --cluster <my-cluster> --approve
-   ```
-1. Create a policy (`recommended-inline-policy.json`) in IAM with the following content that can invoke the gateway API and copy the policy arn for later use:
-   ```bash
-   {
-       "Version": "2012-10-17",
-       "Statement": [
-           {
-               "Effect": "Allow",
-               "Action": [
-                   "vpc-lattice:*",
-                   "iam:CreateServiceLinkedRole",
-                   "ec2:DescribeVpcs",
-                   "ec2:DescribeSubnets"
-               ],
-               "Resource": "*"
-           }
-       ]
-   }
-   ```
-   ```bash
-   aws iam create-policy \
-      --policy-name VPCLatticeControllerIAMPolicy \
-      --policy-document file://examples/recommended-inline-policy.json
-   ```
-1. Create the `system` namespace:
-   ```bash
-   kubectl apply -f examples/deploy-namesystem.yaml
-   ```
-1. Retrieve the policy ARN:
-   ```bash
-   export VPCLatticeControllerIAMPolicyArn=$(aws iam list-policies --query 'Policies[?PolicyName==`VPCLatticeControllerIAMPolicy`].Arn' --output text)
-   ```
-1. Create an iamserviceaccount for pod level permission:
-   ```bash
-   eksctl create iamserviceaccount \
-      --cluster=<my-cluster> \
-      --namespace=system \
-      --name=gateway-api-controller \
-      --attach-policy-arn=$VPCLatticeControllerIAMPolicyArn \
-      --override-existing-serviceaccounts \
-      --region us-west-2 \
-      --approve
-   ```
-
-1. Run either `kubectl` or `helm` to deploy the controller:
-
-   ```bash
-   kubectl apply -f examples/deploy-v0.0.1.yaml
-   ```
-   or
-
-   ```bash
-   # login to ECR
-   aws ecr-public get-login-password --region us-east-1 | helm registry login --username AWS --password-stdin public.ecr.aws
-   # Run helm with either install or upgrade
-   helm install gateway-api-controller \
-      oci://public.ecr.aws/aws-application-networking-k8s/aws-gateway-controller-chart\
-      --version=v0.0.2 \
-      --set=aws.region=us-west-2 --set=serviceAccount.create=false --namespace system
-   ```
-
-1. Create the amazon-vpc-lattice GatewayClass:
-   ```bash
-   kubectl apply -f examples/gatewayclass.yaml
-   ```
-
-## Using the AWS Gateway API Controller
-
-The first part of this section provides an example of setting up of service-to-service communications on a single cluster.
-The second section extends that example by creating another inventory service on a second cluster on a different VPC, and spreading traffic to that service across the two clusters and VPCs.
-Both clusters are created using `eksctl`, with both clusters created from the same account by the same cluster admin.
-
-### Set up single-cluster/VPC service-to-service communications
-
-This example creates a single cluster in a single VPC, then configures two routes (rates and inventory) and three services (parking, review, and inventory-1). The following figure illustrates this setup:
-
-![Single cluster/VPC service-to-service communications](images/example1.png)
-
-**Steps**
-
-   **Set up Service-to-Service communications**
-
-1. Create the Kubernetes Gateway `my-hotel`:
-   ```bash
-   kubectl apply -f examples/my-hotel-gateway.yaml
-   ```
-1. Verify that `my-hotel` gateway is created (this could take about five minutes):
-   ```bash
-   kubectl get gateway  
-   ```
-   ```
-   NAME       CLASS         ADDRESS   READY   AGE
-   my-hotel   aws-lattice                     7d12h
-   ```
-1. Once the gateway is created, find the VPC Lattice service network:
-   ```bash
-   kubectl get gateway my-hotel -o yaml
-   ```
-   ```
-   apiVersion: gateway.networking.k8s.io/v1alpha2
-   kind: Gateway
-   ...
-   status:
-   conditions:
-   message: 'aws-gateway-arn: arn:aws:vpc-lattice:us-west-2:694065802095:servicenetwork/sn-0ab6bb70055929edd'
-   reason: Reconciled
-   status: "True"
-   ```
-1. Create the Kubernetes HTTPRoute rates for the parking service, review service, and HTTPRoute rate:
-   ```bash
-   kubectl apply -f examples/parking.yaml
-   kubectl apply -f examples/review.yaml
-   kubectl apply -f examples/rate-route-path.yaml
-   ```
-1. Create the Kubernetes HTTPRoute inventory (this could take about five minutes):
-   ```bash
-   kubectl apply -f examples/inventory-ver1.yaml
-   kubectl apply -f examples/inventory-route.yaml
-   ```
-1. Find out HTTPRoute's DNS name from HTTPRoute status:
-   ```bash
-   kubectl get httproute
-   ```
-   ```
-   NAME        HOSTNAMES   AGE
-   inventory               51s
-   rates                   6m11s
-   ```
-1. List the route’s yaml file to see the DNS address (highlighted here on the `message` line):
-   ```bash
-   kubectl get httproute inventory -o yaml
-   ```
-   <pre>
-   apiVersion: gateway.networking.k8s.io/v1alpha2
-   kind: HTTPRoute
-   metadata:
-     annotations:
-       kubectl.kubernetes.io/last-applied-configuration: |
-         {"apiVersion":"gateway.networking.k8s.io/v1alpha2","kind":"HTTPRoute","metadata":{"annotations":{},"name":"inventory","namespace":"default"}... }}]}]}}
-   ...
-   status:
-     parents:
-     - conditions:
-       - lastTransitionTime: "2022-11-22T02:29:22Z"
-         message: 'DNS Name: <b><i>inventory-default-0f326944c3d681c0d.7d67968.vpc-lattice-svcs.us-west-2.on.aws</i></b>'
-         reason: Reconciled
-         status: "True"
-         type: httproute
-       controllerName: application-networking.k8s.aws/gateway-api-controller
-       parentRef:
-         group: gateway.networking.k8s.io
-         kind: Gateway
-         name: my-hotel
-   ...
-   </pre>
-   
-   ```bash
-   kubectl get httproute rates inventory -o yaml
-   ```
-
-**Check service connectivity**
-
-1. Check Service-Inventory Pod access for Service-Rates/parking or Service-Rates/review by execing into the pod, then curling each service.
-   ```bash
-   kubectl get pod
-   ```
-   ```
-   NAME                                    READY   STATUS    RESTARTS   AGE
-   inventory-ver1-7bb6989d9d-2p2hk         1/1     Running   0          7d13h
-   inventory-ver1-7bb6989d9d-464rk         1/1     Running   0          7d13h
-   parking-6cdcd5b4b4-bbzvt                1/1     Running   0          103m
-   parking-6cdcd5b4b4-g8dkb                1/1     Running   0          103m
-   review-5888566ff6-2plsj                 1/1     Running   0          101m
-   review-5888566ff6-89fqk                 1/1     Running   0          101m
-   ```
-1. Exec into an inventory pod to check connectivity to parking and review services:
-   ```bash
-   kubectl exec -ti inventory-ver1-7bb6989d9d-2p2hk sh
-   ```
-1. From inside of the inventory pod, use `curl` to connect to the parking service (using the DNS Name from the previous `kubectl get httproute` command):
-   ```bash
-   curl rates-00422586e3362607e.7d67968.vpc-service-network-svcs.us-west-2.amazonaws.com/parking 
-   ```
-   ```
-   Requesting to Pod(parking-6cdcd5b4b4-g8dkb): parking handler pod
-   ```
-1. From inside of the pod, use `curl` to connect to the review service:
-   ```bash
-   curl rates-00422586e3362607e.7d67968.vpc-service-network-svcs.us-west-2.amazonaws.com/review 
-   ```
-   ```
-   Requesting to Pod(review-5888566ff6-89fqk): review handler pod
-   ```
-1. Exit the pod:
-   ```bash
-   exit
-   ```
-1. Exec into a parking pod to check connectivity to the inventory-ver1 service:
-   ```bash
-   kubectl exec -ti parking-6cdcd5b4b4-bbzvt sh
-   ```
-1. From inside of the parking pod, use `curl` to connect to the inventory-ver1 service:
-   ```bash
-   curl inventory-00422586e3362607e.7d67968.vpc-service-network-svcs.us-west-2.amazonaws.com
-   ```
-   ```
-   Requesting to Pod(inventory-ver1-7bb6989d9d-2p2hk): inventory-ver1 handler pod 
-   ```
-### Set up multi-cluster/multi-VPC service-to-service communications
-
-This sections builds on the previous section by migrating a Kubernetes service (HTTPRoute inventory) from one Kubernetes cluster to a different Kubernetes cluster.
-For example, it will:
-
-* Migrate the Kubernetes inventory service from a Kubernetes v1.21 cluster to a Kubernetes v1.23 cluster in a different VPC.
-* Scale up the Kubernetes inventory service to run it in another cluster (and another VPC) in addition to the current cluster.
-
-The following figure illustrates this:
-
-![Multiple clusters/VPCs service-to-service communications](images/example2.png)
-
-**Steps**
-
-   **Set up inventory on a second cluster** 
-
-1. Create a second cluster (using the same instructions used to create the first).
-
-1. Ensure you're using the second cluster profile. 
-   ```bash
-   kubectl config get-contexts 
-   ```
-   If your profile is set to the first cluster, switch your credentials to use the second cluster:
-   ```bash
-   kubectl config use-context <yourcluster2info>
-   ```
-1. Create a Kubernetes inventory-ver2 service in the second cluster:
-   ```bash
-   kubectl apply -f examples/inventory-ver2.yaml
-   ```
-1. Export this Kubernetes inventory-ver2 from the second cluster, so that it can be referenced by HTTPRoute in the other cluster:
-   ```bash
-   kubectl apply -f examples/inventory-ver2-export.yaml
-   ```
-   **Switch back to the first cluster**
-
-1. Switch credentials back to the first cluster
-   ```bash
-   kubectl config use-context <yourcluster1info>
-   ```
-1. Import the Kubernetes inventory-ver2 into first cluster:
-   ```bash
-   kubectl apply -f examples/inventory-ver2-import.yaml
-   ```
-1. Update the HTTPRoute inventory to route 10% traffic to the first cluster and 90% traffic to the second cluster:
-   ```bash
-   kubectl apply -f examples/inventory-route-bluegreen.yaml
-   ```
-1. Check the Service-Rates/parking pod access to Service-Inventory by execing into the parking pod:
-   ```bash
-   kubectl exec -ti parking-6cdcd5b4b4-bbzvt sh
-   ```
-1. From inside of the pod, use `curl` to connect to the inventory service:
- 
-   ```bash
-   for ((i=1;i<=30;i++)); do   curl   "inventory-default-0f89d8ff5e98400d0.7d67968.vpc-lattice-svcs.us-west-2.on.aws"; done
-   ```
-   ```
-   Requsting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod <----> in 2nd cluster
-   Requsting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
-   Requsting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
-   Requsting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
-   Requsting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver1 handler pod <----> in 1st cluster
-   Requsting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
-   Requsting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver2 handler pod
-   Requsting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver2 handler pod
-   Requsting to Pod(inventory-ver1-74fc59977-wg8br): Inventory-ver1 handler pod....
-   ```
-   You can see that the traffic is distributed between *inventory-ver1* and *inventory-ver2* as expected.
-
-## Understanding the Gateway API Controller
-
-For medium and large-scale customers, applications can often spread across multiple areas of a cloud.
-For example, information pertaining to a company’s authentication, billing, and inventory may each be served by services running on different VPCs in AWS.
-Someone wanting to run an application that is spread out in this way might find themselves having to work with multiple ways to configure:
-
-* Authentication and authorization
-* Observability
-* Service discovery
-* Network connectivity and traffic routing
-
-This is not a new problem.
-A common approach to interconnecting services that span multiple VPCs is to use service meshes. But these require sidecars, which can introduce scaling problems and present their own management challenges, such as dealing with control plane and data plane at scale.
-
-If you just want to run an application, you should be shielded from details needed to find assets across multiple VPCs and multiple clusters. You should also have consistent ways of working with assets across your VPCs, even if those assets include different combinations of instances, clusters, containers, and serverless. And while making it simpler to run multi-VPC applications easier for users, administrators still need the tools to control and audit their resources to suit their company’s compliance needs.
-
-### Service Directory, Networks, Policies and Gateways
-
-The goal of VPC Lattice is to provide a way to have a single, over-arching services view of all services across multiple VPCs.
-You should also have consistent ways of working with assets across your VPCs, even if those assets include different combinations of instances, clusters, containers, and serverless.
-The components making up that view include:
-
-* Service Directory: This is an account-level directory for gathering your services in once place.
-This can provide a view from the VPC Lattice section of the AWS console into all the services you own, as well as services that are shared with you.
-A service might direct traffic to a particular service type (such as HTTP) and port (such as port 80).
-However, using different rules, a request for the service could be sent to different targets such as a Kubernetes pod or a Lambda function, based on path or query string parameter.
-
-* Service Network: Because applications might span multiple VPCs and accounts, there is a need to create networks that span those items.
-  These networks let you register services to run across accounts and VPCs.
-  You can create common authorization rules to simplify connectivity.
-
-* Service Policies: You can build service policies to configure observability, access, and traffic management across any service network or gateway.
-  You configure rules for handling traffic and for authorizing access.
-  For now, you can assign IAM roles to allow certain requests.
-  These are similar to S3 or IAM resource policies.
-  Overall, this provides a common way to apply access rules at the service or service network levels.
-
-* Service Gateway: This feature is not yet implemented.
-  It is meant to centralize management of ingress and egress gateways.
-  The Service Gateway will also let you manage access to external dependencies and clients using a centrally managed VPC.
-
-If all goes well, you should be able to achieve some of the following goals:
-
-* Kubernetes multi-cluster connectivity: Say that you have multiple clusters across multiple VPCs.
-  After configuring your services with the Kubernetes Gateway API, you can facilitate communications between services on those clusters without dealing with the underlying infrastructure.
-  VPC Lattice handles a lot of the details for you without needing things like sidecars.
-* Serverless access: VPC Lattice allows access to serverless features, as well as Kubernetes cluster features.
-  This gives you a way to have a consistent interface to multiple types of platforms.
-
-With VPC Lattice you can also avoid some of these common problems:
-
-* Overlapping IP addresses: Even with well-managed IP addresses, overlapping address use can occur by mistake or when organizations or companies merge together.
-  IP address conflicts can also occur if you wanted to manage resources across multiple Kubernetes clusters.
-* Sidecar management: Changes to sidecars might require those sidecars to be reconfigured or rebooted.
-  While this might not be a big issue for a handful of sidecars, it can be disruptive if you have thousands of pods, each with its own sidecar.
-
-### Relationship between VPC Lattice and Kubernetes
-
-As a Kubernetes user, you can have a very Kubernetes-native experience using the VPC Lattice APIs.
-The following figure illustrates how VPC Lattice objects connect to [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) objects:
-
-![VPC Lattice objects relation to Kubernetes objects](images/personae.png)
-
-As shown in the figure, there are different personas associated with different levels of control in VPC Lattice.
-Notice that the Kubernetes Gateway API syntax is used to create the gateway, HTTPRoute and services, but Kubernetes gets the details of those items from VPC Lattice:
-
-* Infrastructure provider: Creates the Kubernetes GatewayClass to identify VPC Lattice as the GatewayClass.
-* Cluster operator: Creates the Kubernetes Gateway, which gets information from VPC Lattice related to the Service Gateway and Service Networks, as well as their related Service Policies.
-* Application developer: Creates HTTPRoute objects that point to Kubernetes services, which in turn are directed to particular pods, in this case.
-  This is all done by checking the related VPC Lattice Services (and related policies), Target Groups, and Targets
-  Keep in mind that Target Groups v1 and v2 can be on different clusters in different VPCs.
diff --git a/docs/index.md b/docs/index.md
index a0f314fa..0c6bcfe3 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,7 +1,24 @@
-# AWS Application Networking Controller
+# AWS Gateway API Controller User Guide
+
+The AWS Gateway API Controller lets you connect services across multiple Kubernetes clusters through the Kubernetes Gateway API interface.
+It is also designed to connect services running on EC2 instances, containers, and as serverless functions.
+It does this by leveraging Amazon VPC Lattice, which works with Kubernetes Gateway API calls to manage Kubernetes objects. 
+
+This document describes how to set up the AWS Gateway API Controller and provides example use cases.
+With the controller deployed and running, you will be able to manage services for multiple Kubernetes clusters and other targets on AWS through the following:
+
+* **CLI**: Use `aws` and `eksctl` to create clusters and set up AWS policies. Then use `kubectl` and YAML files to set up Kubernetes objects.
+* **AWS Console**: View VPC Lattice assets through the VPC area of the AWS console.
+
+While separating the application developer from the details of the underling infrastructure, the controller also provides a Kubernetes-native experience, rather than creating a lot of new AWS ways of managing services.
+It does this by integrating with the Kubernetes Gateway API.
+This lets you work with Kubernetes service-related resources using Kubernetes APIs and custom resource definitions (CRDs) defined by the Kubernetes [networking.k8s.io specification](https://gateway-api.sigs.k8s.io/references/spec/).
+
+For more information on this technology, see [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/). 
+
+A few things to keep in mind:
+
+* If you are new to the VPC Lattice service, keep in mind that names you use for objects must be unique across your entire account and not just across each cluster used by that account.
+* Your AWS CNI must be v1.8.0 or later to work with VPC Lattice.
 
-- Kubernetes Gateway API
-- AWS Application Networking Controller 
-- AWS Lattice
 
-AWS Application Networking is an implementation of the Kubernetes [Gateway API](https://gateway-api.sigs.k8s.io/). This project is designed to run in a Kubernetes cluster and orchestrates AWS VPC Lattice resources using Kubernetes Custom Resource Definitions like Gateway and HTTPRoute.
\ No newline at end of file
diff --git a/docs/overview.md b/docs/overview.md
new file mode 100644
index 00000000..dc3bdd98
--- /dev/null
+++ b/docs/overview.md
@@ -0,0 +1,71 @@
+# Understanding the Gateway API Controller
+
+For medium and large-scale customers, applications can often spread across multiple areas of a cloud.
+For example, information pertaining to a company’s authentication, billing, and inventory may each be served by services running on different VPCs in AWS.
+Someone wanting to run an application that is spread out in this way might find themselves having to work with multiple ways to configure:
+
+* Authentication and authorization
+* Observability
+* Service discovery
+* Network connectivity and traffic routing
+
+This is not a new problem.
+A common approach to interconnecting services that span multiple VPCs is to use service meshes. But these require sidecars, which can introduce scaling problems and present their own management challenges, such as dealing with control plane and data plane at scale.
+
+If you just want to run an application, you should be shielded from details needed to find assets across multiple VPCs and multiple clusters. You should also have consistent ways of working with assets across your VPCs, even if those assets include different combinations of instances, clusters, containers, and serverless. And while making it simpler to run multi-VPC applications easier for users, administrators still need the tools to control and audit their resources to suit their company’s compliance needs.
+
+## Service Directory, Networks, Policies and Gateways
+
+The goal of VPC Lattice is to provide a way to have a single, over-arching services view of all services across multiple VPCs.
+You should also have consistent ways of working with assets across your VPCs, even if those assets include different combinations of instances, clusters, containers, and serverless.
+The components making up that view include:
+
+* Service Directory: This is an account-level directory for gathering your services in once place.
+This can provide a view from the VPC Lattice section of the AWS console into all the services you own, as well as services that are shared with you.
+A service might direct traffic to a particular service type (such as HTTP) and port (such as port 80).
+However, using different rules, a request for the service could be sent to different targets such as a Kubernetes pod or a Lambda function, based on path or query string parameter.
+
+* Service Network: Because applications might span multiple VPCs and accounts, there is a need to create networks that span those items.
+  These networks let you register services to run across accounts and VPCs.
+  You can create common authorization rules to simplify connectivity.
+
+* Service Policies: You can build service policies to configure observability, access, and traffic management across any service network or gateway.
+  You configure rules for handling traffic and for authorizing access.
+  For now, you can assign IAM roles to allow certain requests.
+  These are similar to S3 or IAM resource policies.
+  Overall, this provides a common way to apply access rules at the service or service network levels.
+
+* Service Gateway: This feature is not yet implemented.
+  It is meant to centralize management of ingress and egress gateways.
+  The Service Gateway will also let you manage access to external dependencies and clients using a centrally managed VPC.
+
+If all goes well, you should be able to achieve some of the following goals:
+
+* Kubernetes multi-cluster connectivity: Say that you have multiple clusters across multiple VPCs.
+  After configuring your services with the Kubernetes Gateway API, you can facilitate communications between services on those clusters without dealing with the underlying infrastructure.
+  VPC Lattice handles a lot of the details for you without needing things like sidecars.
+* Serverless access: VPC Lattice allows access to serverless features, as well as Kubernetes cluster features.
+  This gives you a way to have a consistent interface to multiple types of platforms.
+
+With VPC Lattice you can also avoid some of these common problems:
+
+* Overlapping IP addresses: Even with well-managed IP addresses, overlapping address use can occur by mistake or when organizations or companies merge together.
+  IP address conflicts can also occur if you wanted to manage resources across multiple Kubernetes clusters.
+* Sidecar management: Changes to sidecars might require those sidecars to be reconfigured or rebooted.
+  While this might not be a big issue for a handful of sidecars, it can be disruptive if you have thousands of pods, each with its own sidecar.
+
+## Relationship between VPC Lattice and Kubernetes
+
+As a Kubernetes user, you can have a very Kubernetes-native experience using the VPC Lattice APIs.
+The following figure illustrates how VPC Lattice objects connect to [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/) objects:
+
+![VPC Lattice objects relation to Kubernetes objects](images/personae.png)
+
+As shown in the figure, there are different personas associated with different levels of control in VPC Lattice.
+Notice that the Kubernetes Gateway API syntax is used to create the gateway, HTTPRoute and services, but Kubernetes gets the details of those items from VPC Lattice:
+
+* Infrastructure provider: Creates the Kubernetes GatewayClass to identify VPC Lattice as the GatewayClass.
+* Cluster operator: Creates the Kubernetes Gateway, which gets information from VPC Lattice related to the Service Gateway and Service Networks, as well as their related Service Policies.
+* Application developer: Creates HTTPRoute objects that point to Kubernetes services, which in turn are directed to particular pods, in this case.
+  This is all done by checking the related VPC Lattice Services (and related policies), Target Groups, and Targets
+  Keep in mind that Target Groups v1 and v2 can be on different clusters in different VPCs.
diff --git a/docs/reference/index.md b/docs/reference/index.md
deleted file mode 100644
index e69de29b..00000000
diff --git a/mkdocs.yml b/mkdocs.yml
index b4b45822..ebd697b9 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -1,4 +1,4 @@
-site_name: AWS Application Networking Controller
+site_name: AWS Gateway API Controller
 repo_name: aws/aws-application-networking-k8s
 repo_url: https://github.com/aws/aws-application-networking-k8s
 edit_uri: edit/main/docs/
@@ -6,13 +6,10 @@ strict: true
 
 
 nav:
-  - Home:
-    - Welcome: index.md
-    - How it works: how-it-works.md
-  - Deployment: deployment/index.md
-  - Reference: reference/index.md
-  - Examples:
-    - Blue/Green Deployment: examples/bluegreen.md
+  - Home: index.md
+  - Deployment: deploy.md
+  - Configuration: configure.md
+  - Design Overview: overview.md
 
 plugins:
   - search
@@ -25,8 +22,8 @@ theme:
   font:
     text: Roboto
     code: Roboto Mono
-  features:
-    - navigation.tabs
+#  features:
+#    - navigation.tabs
 # Extensions
 markdown_extensions:
   - admonition